Cargo does not rebuild if project got changed in the same second

To reproduce, take a small crate (I am using https://github.com/rust-lang-nursery/rustc-perf/tree/master/collector/benchmarks/coercions), and run
cargo +nightly build # fill incremental cache
for i in $(seq 1 10); do touch src/main.rs && cargo +nightly build; done

These should give fairly consistent timings. However, they do not:
   Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.72s
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
   Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.70s
   Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.71s
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
   Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.70s
   Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.69s
    Finished dev [unoptimized + debuginfo] target(s) in 0.00s
   Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.70s
   Compiling issue-32278-big-array-of-strings v0.1.0 (file:///home/r/src/rust/rustc-perf/collector/benchmarks/coercions)
    Finished dev [unoptimized + debuginfo] target(s) in 0.70s

As you can see, it does not even recompile the project each time! Seems like it is (a) using a one-second granularity, and (b) if the last change and the last build happened in the same second, it assumes the build was first! The latter is a wrong assumption, leading to this bug.

Related: https://github.com/rust-lang/cargo/issues/2426 "cargo build does not rebuild if a source file was modified during a build"
Personally I think cargo should only rebuild a project if the contents change, not if the timestamp changes, so I feel compelled to say I disagree that it's a bug that it doesn't "even" recompile the project each time. 😀
But more to your point, perhaps cargo could trigger a rebuild if the current time and the last build time match.

That's what we have incremental compilation for. Please don't make it even harder to test that.^^ ;)
I proposed a fix for this at https://github.com/rust-lang/cargo/pull/5919

I don't understand why spurious rebuilds are traded for spuriously failing to notice changes -- IOW, spuriously doing too much work is traded for spuriously doing the wrong thing.  :(
You talk about touch src/lib.rs && cargo build (in a loop) being niche.  That's a standard benchmark setup.  In comparison, editing a file during the build seems extremely niche to me -- in fact it seems like a bug. It's all a matter of perspective, of course.
Can you at least provide guidance about how to run benchmarks for rebuilds after a NOP edit, now that the obvious way got broken again?

it should cryptographically hash all known inputs once the rustc invocation (or build script invocation) finishes.

Won't that hash the wrong thing if the file changed during the rustc invocation?

Yeah you have to hash first.
But with a long build or tests I've often changed some sources mid build and then had to touch files to get the edited files to actually recompile.
No disrespect intended but benchmarking incremental builds seems like the niche case.  One we'd want to find a way to support, but with some niche way to subvert the noop'ing (--rebuild or --assume-stale or something.)

But with a long build or tests I've often changed some sources mid build and then had to touch files to get the edited files to actually recompile.

Fair enough.  I have a reflex pretty deep in my muscle memory where I don't hit Ctrl-S while a build is ongoing, I guess that's why I never saw that.^^

#6529 would fix this.


llvm version: README say 4.0.1, while aflgo-build.sh use 4.0.0.

I'm not familiar with llvm, can anybody tell me which llvm version should I use?
I can build aflgo with clang 4.0.0, do I need to change to higher or latest llvm version for better performance or something else?
Please make README and the building script consistent.

Besides, aflgo-build.sh compile clang and llvm from source code, which takes long time, and makes DockerHub automated build time out.
I propose change to download and decompress pre-built binaries, like what Angora did: https://github.com/AngoraFuzzer/Angora/blob/master/build/install_llvm.sh

I use llvm version 4.0.0. AFLGo is currently "sensitive" with the clang version. We also plan to use the latest verion of llvm 8.
Please let me know if you can use pre-built binaries of llvm and clang to run AFLGo. We will update the building script. Thanks.

It seems not that easy to skip compiling LLVM, since the pre-built binaries does not include LLVM-Gold plugin. (Besides, llvm.org does not provide version 4.0.1 pre-built binaries for ubuntu, wierd...)
I will keep trying for easier using AFL-Go.

Thanks @zjuchenyuan for your tries. I think we have tried some cases, but got a conclusion to use oss-fuzz's building script. Also, if we use the newest version of clang and llvm, we may need to update llvm-mode.


Overriding of dry-container dependencies creates unexpected behaviour

Describe the bug
When including a module into a class that is extended with dry-initializer after including another module which imports a dependency using dry-container, unexpected behaviour is observed
To Reproduce
module Container
  extend Dry::Container::Mixin

  register(:deps) { 1 }
end

module Foo
  Import = Dry::AutoInject(Container)
end

module Bar
  def self.included(base)
    base.extend Dry::Initializer
    base.option :foo
  end
end

module Foobar
  def self.included(base)
    base.include Foo::Import['deps']
  end
end

class SomeService
  include Foobar
  include Bar
end

Behaviour observed
service = SomeService.new(foo: 1)
service.foo => 1
service.deps => nil # expected 1

I am currently running versions:
*dry-initializer (3.1.1)
*dry-auto_inject (0.9.0)
*dry-container (0.11.0)

Please don't do this. You're using two libraries that define constructors, pick one instead. We should make it clear in the documentation.


Makes snapshot fns pub only with dcou

Problem
There are snapshot utils functions that are only public so they can be called by tests. Instead, we can use DCOU to make them conditionally public.
The main impetus for this PR is to prevent/reduce new callers to package_and_archive_snapshot(). As mentioned in #1371,  I'm working to remove serde_snapshot::reserialize_bank_with_new_accounts_hash(), and instead only serialize the bank once. And since package_and_archive_snapshot() calls reserialize, preventing/reducing new callers is beneficial.
Summary of Changes
Make snapshot fns pub only with dcou

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 82.7%. Comparing base (e01278e) to head (73596be).

Additional details and impacted files
@@           Coverage Diff           @@
##           master    #1372   +/-   ##
=======================================
  Coverage    82.7%    82.7%
=======================================
  Files         872      872
  Lines      369436   369438    +2
=======================================
+ Hits       305779   305832   +53
+ Misses      63657    63606   -51


Update dart2aot help output

I really think this script should be written in Dart and be distributed in its own package, rather than in SDK.

This is now https://dart-review.googlesource.com/c/sdk/+/98820 ; please review there


the performance on object detection?

hello
do you have do some experiments to validate the effectiveness on object detection?

Our own testing of DLA on object detection gave encouraging results. A recent report on object detection shows that DLA can achieve a good balance between accuracy and efficiency: https://github.com/xingyizhou/CenterNet.


Spelling correction on Wasps ID page

In the Wasps ID page, point 3 has a spelling error:
bold back
should say
bold black
@kazlauskis can you correct this directly with the next update, then it will appear correctly for the Cyprus version too?

Thanks, I've done this now. This text lives in the shared excel document so you should be able to make these tweaks to the descriptions there yourselves.


Contribution/1472 faq shared intents

fix #1472 about Faq deletion
fix saves about shared intents and avoid double service call on BotAdminService when creating a FAQ with FAQ_CATEGORY
fix creation of a new intent when a new shared intent is not wanted in FAQ.
Fix the FAQ implementation for shared intent in the same namespace.

Thank you !


Fixed connection mock direct writeCharacteristic not callind setValue

The other variants of write writeCharacteristic are calling setValue to
change the internal value to this. In some of my tests, I was before
using the UUID version and was relying that setValue would be called acting
as a kind of holder for the read.
This assumption was broken with the writeCharacteristic variant that takes
a BluetoothGattCharacteristic and a byte array.
Resolved this minor thing by also calling setValue on the received
BluetoothGattCharacteristic.

Thanks!

Dear Contributor,
similar to many open source projects we kindly request to sign our CLA if you'd like to contribute to our project. This license is for your protection as a Contributor as well as the protection of Polidea; it does not change your rights to use your own Contributions for any other purpose.
You can find a link here: https://cla-assistant.io/Polidea/RxAndroidBle


npm start failing with below error

C:\Users\sanil\Desktop\React\ReduxSimpleStarter>npm start

<EMAIL_ADDRESS>start C:\Users\sanil\Desktop\React\ReduxSimpleStarter
node ./node_modules/webpack-dev-server/bin/webpack-dev-server.js

events.js:141
throw er; // Unhandled 'error' event
^
Error: listen EACCES <IP_ADDRESS>:8080
at Object.exports._errnoException (util.js:870:11)
at exports._exceptionWithHostPort (util.js:893:20)
at Server._listen2 (net.js:1221:19)
at listen (net.js:1270:10)
at net.js:1379:9
at GetAddrInfoReqWrap.asyncCallback [as callback] (dns.js:64:16)
at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:83:10)
npm ERR! Windows_NT 6.1.7601
npm ERR! argv "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "start"
npm ERR! node v4.4.3
npm ERR! npm  v2.15.1
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: node ./node_modules/webpack-dev-server/bin/webpack-dev-server.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script 'node ./node_modules/webpack-dev-server/bin/webpack-dev-server.js'.
npm ERR! This is most likely a problem with the redux-simple-starter package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node ./node_modules/webpack-dev-server/bin/webpack-dev-server.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs redux-simple-starter
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR!     npm owner ls redux-simple-starter
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     C:\Users\sanil\Desktop\React\ReduxSimpleStarter\npm-debug.log

You have a program running on port 8080. Either stop whatever process is running or change the port.

Thank You


When I trained the model, I got nan for train and validation loss!

When I trained the model, I got nan for train and validation loss! with tensorflow 1.4, python3.5

When I tried to train more kinds of traffic signs I got nan for train and validation loss. Can you tell me why?

I met the problem too,do you solve it? @sharpen4


Assymetric per core task placement drops the performance

Running algorithm with OpenMP multi threads scales the performance linearly with the increase in the number of threads when using SMT=1 mode. Hence for Firestone with 20 cores, 20 threads gives the best performance than having lesser threads.
For SMT=4 or 8 mode, this scaling is not linear as introducing one more thread gives poor performance compared to 20 threads.
Using threads in multiple of number of cores gives better result

For 21 threads, task placement becomes asymmetric and so faster threads has to stall for slower thread to synchronise with it. This drops performance of overall execution.
Core 8and 9 are slower threads making others threads to stall for the synchronisation

When spwaning 21 threads, OpenMP distributes equal tasks among all threads. Due to 20 cores and SMT=8, exactly 1 core will get 2 threads running in parallel with double tasks compared to other cores. This slows down the core.
The performance needs to be boosted by providing equal tasks to each core and using all SMT threads to make instructions use all computation unit in parallel.

This can be used to reduce spin locks in uneven workload distribution. When running workload in all the 20 cores in POWER8 and with SMT-4 enabled in 19 cores whereas last core having only SMT-3 will make load to distribute in uneven fashion. Last core will get less chunk of data compared to remaining cores and thus it has to process less data in each iteration making it to complete task faster than others. This core reaches synchronisation barrier earlier than others and so will spin lock while other threads will slowly reach there simultaneously. Thus aggregated spin locks reduces among all threads.

Since here algorithm distributes workload approximately in uniform manner to each thread, it don't give benefit but Intel gets benefit when all CPUs are used.
Stats:
POWER 8:
threads : 80 -->   21.5s
threads : 79 -->   21.65s
Intel KNL:
threads : 272 -->   32.4s
threads : 271 -->   30.9s


Headings H3 - H6 are assigned incorrect textmate scopes

Initial checklist

[X] I read the support docs
[X] I read the contributing guide
[X] I agree to follow the code of conduct
[X] I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions
v1.8.11
Link to runnable example
No response
Steps to reproduce

Paste the following text into a VSCode window:

# Heading 1

## Heading 2

### Heading 3

#### Heading 4

##### Heading 5

###### Heading 6

Execute "Developer: Inspect Editor Tokens and Scopes" through the Ctrl+Shift+P menu
Inspect the scopes of each heading

Expected behavior
Since H1 is assigned markup.heading.atx.1 and H2 is assigned markup.heading.atx.2, H3 - H6 should be assigned markup.heading.atx.3, markup.heading.atx.4, and so on.
Actual behavior
H3 - H6 are all assigned markup.heading.atx.2.
Affected runtime and version
Not sure, it's in the most recent version of VSCode
Affected package manager and version
No response
Affected OS and version
Ubuntu 22.04.5 LTS
Build and bundle tools
No response

A visual example of what's occurring, I'm writing a theme that differentiates each heading level with color and this is currently broken on MDX. Expected:

Actual:

Looks like the issue is upstream in https://github.com/wooorm/markdown-tm-language, should be an easy fix? H3 - H6 are already targeted in the TMLanguage file, just not assigned the right IDs

PR is in to hopefully fix this at https://github.com/wooorm/markdown-tm-language/pull/12

Hi!
Have you tested that your changes work with GitHub and some common/default VS Code themes?
Often, themes don’t support all scopes.

I think for GH this will be fine. That’s just looking at markup.heading.

It might be interesting to know of this breaks any things. But even if this breaks a theme, this change makes sense IMO. Themes can adapt.

Is there a reason H3 - H6 were assigned H2 scopes?

Okay so after looking a fair amount I can't really see anything that is explicitly relying on H3 - H6 all having H2 scope, but some that already rely on headings having the correct scope that get broken in MDX. For example, Catppuccin Frappe from Catppuccin for VSCode

Searching for files not using deeper headings shows that pretty much repo that references H2 scopes and not any deeper ones is just bundling https://github.com/wooorm/markdown-tm-language instead of doing something meaningful with it.
Now I can't speak on GitHub, as I don't know where I'd even begin to look for their implementations let alone if they're source available, but from my surface level lookover I can't see anywhere that they'd be relying on this behavior. They seem to not care what level a heading is wherever I look.

For GH, see my earlier comment https://github.com/mdx-js/mdx-analyzer/issues/483#issuecomment-2467876802. As for source, see e.g. https://github.com/primer/github-syntax-dark/blob/master/lib/github-dark.css.
Thanks for checking!

Ah, I think I missed that comment. Thanks!


Nested  elements in templates cause an error on initialization

JSFiddle: http://jsfiddle.net/p9fmhwnr/2/

Reproduction: attempt to initialize a Ractive element with this template string: '
This template has a
nested paragraph
 element, which isn\'t great but probably shouldn\'t error
'
Expected: the Ractive object should successfully initialize
Observed: an error is thrown with this message:

ParseError: Unexpected template content at line 1 character 112:

This template has a
nested paragraph
 element, which isn't great but probably shouldn't error

                                                                                ^----

Is this expected behavior?  I couldn't find any reference to this sort of behavior in the documentation.
I'm coming all the way from Ractive 0.4, so I have no idea when this might have been introduced.
Is there any way to disable this strictness?  I have a wiki-type cms that allows users to embed the html from Markdown documents inside of other html-from-Markdown documents, so enforcing this sort of by-the-books properness isn't going to be very practical for me.
Reproduced with latest and edge.

Nested
 elements are not allowed per W3C spec, see this SO questions.
If you don't need binding within that content (in other words it's pure html and template), You can work around be using inserting the content via triple stache (see http://jsfiddle.net/p9fmhwnr/4/):
 data: {
            content: '
nested paragraph
'
        },
        template: '
This template has a {{{content}}} element, which isn\'t great but probably shouldn\'t error
'

which, if it's static you might just use:
 data: {
            content: '
nested paragraph
'
        },
        template: '
This template has a [[[content]]] element, which isn\'t great but probably shouldn\'t error
'

So this is intended behavior?  Sadly, these nested documents can include Ractive expressions, so I guess I'll have to work out some way to clean them up.

So this is intended behavior?

Yes, it's specifically coded in the parser here

so I guess I'll have to work out some way to clean them up.

Could you use Ractive.parse or a third-party library to validate the user input?

All of the html comes from parsing markdown documents into valid template html - the difficulty is that I'm embedding one of these documents into the other after turning them into html.
It believe it's only going to be an issue for me on the server-side, so I think I can work around it by calling cheerio.parse(html).html() to clean up the html before handing it to Ractive.
I'm sad about this change in Ractive, but it makes sense.  Thanks!

Chiming in. I had this example once where when the browser sees an invalid element inside a parent, the parent closes and starts with the once invalid element. https://jsfiddle.net/uqq5Lrq8/4/ It appears that, while the spec says invalid, the browser does seem to render but it won't render the way you expect it to.

Yeah, the browser tends to make them all siblings of each other, which is fine for my purposes.

Just my two cents, but I feel like Unexpected template content is an unnecessarily cryptic error. It certainly doesn't really seem to be caused by a spec violation. Perhaps something like [parent] elements cannot contain [child] elements according to the HTML spec [here].

@Madgvox checklist item for https://github.com/ractivejs/ractive/pull/1915? :D

@fskreuz You read my mind :)


Release Polishing

Deadline December 11

[ ] Documentation

[ ] Testing

Will we be implementing the doc (RTD) or docsrc/docs (GHP) model for documentation?

I vote for GHP


Look for textures in ../textures as well.

This fixes #119

@petterarvidsson ready for review!

You know what? I did exacty the same. And I did it exactly the same time you did it. (Look https://github.com/Henningstone/client/commit/51a9f16680bb3099978b37dd614a8a45912c9135)
I can tell you, it's tested and it works :P

@Henningstone wow, we are synchronized :)

@nsg & @Henningstone Looking good!


bump nodemon from 2.0.7 to 3.0.1

Fixes M-Zuber/npm-watch#94

This change is

Big thumbs up! I've tested this patch myself and it works great (MacOS). The AppVeyor build failure has nothing to do with this patch, it appears to be some build configuration issue.
I've been dealing with this issue as an npm audit issued for a few years now. It would be so nice to be able quite those warning messages.
Thanks for the great tool!

@M-Zuber - any chance of getting this merged in and published? I am once again reviewing my npm audit and running into this.

@M-Zuber I'm also looking forward to this getting merged 👍🏼

Apologies for the delay, life was a long dark tunnel for a while


High - Create tutorial for using Makefile and going into container and using psql

Maybe also add role to Makefile that will exec user into container as postgres using psql

https://docs.google.com/document/d/1quaIUqJOqxGpvZewlbUrg7sYXXuDvFEfx8vAD88rgjA/edit?usp=sharing


engine: add known issues to 20.10.15 release notes

relates to https://github.com/docker/cli/issues/3595
relates to https://github.com/docker/cli/pull/3592

With this PR:

@usha-mandya @dockertopia ptal

Updated with your suggestions; changed the fix for the link to use fix for this issue (instead of the "has been merged"); PTAL if this looks good to you 🤗

Thanks @thaJeztah. Looks good. There's a broken link to the Extensions doc which isnt part of this PR. I've re-run the failed jobs to see if that fixes any issues.

Bleh.. looks to be still failing; broken link may be in the external repository though;
- ./_site/desktop/extensions-sdk/extensions/labels/index.html
Ran on 1666 files!

  *  linking to internal hash #design-principles that does not exist (line 197)
     CSS guidlines

Fix for the above is in https://github.com/docker/extensions-sdk/pull/160


SQL highlighting issue in helix-editor, using tree-sitter-sql

The original bug report can be found at https://github.com/helix-editor/helix/issues/5186
Other than in the bug report, I am using now helix at latest master commit (edd0ba7 right now), but that makes no difference.
I updated tree-sitter-sql by overriding https://github.com/helix-editor/helix/blob/8e10c592b90383a90b7e4a9335d323f8fab99ab5/languages.toml#L1435-L1437
followed by rebuilding grammers:
$ hx --grammar fetch
Fetching 128 grammars
127 up to date git grammars
1 updated grammars
        sql now on 6adc9578afb5c361858213adae5e2de990e46cb1

$ hx --grammar build
Building 128 grammars
127 grammars already built
1 grammars built now
        ["sql"]

however, the highlighting still fails, which makes me conclude this will rather be a tree-sitter-sql bug. (Or two, actually.)
Summary
Example SQL:
INSERT INTO ... SET ... syntax:
INSERT INTO some_table
  field = "String does not get highlight in INSERT SET syntax";

helix edd0ba7 with tree-sitter-sql 9d9802991aa1d1bc00eee7713a838dab1eb4f149: String value does not get highlight:

INSERT INTO ... (...) VALUES (...) syntax with multiple values records:
INSERT INTO some_table
  (field)
VALUES
  ("String value"),
  ("String value");

helix edd0ba7 with tree-sitter-sql 9d9802991aa1d1bc00eee7713a838dab1eb4f149: Values of second record do not get highlight:

GROUP_CONCAT with SEPARATOR:
SELECT GROUP_CONCAT(uid SEPARATOR ",")
FROM some_table
GROUP BY some_field;

SELECT GROUP_CONCAT(uid SEPARATOR ",")
FROM some_table
GROUP BY some_field;

helix edd0ba7 with tree-sitter-sql 9d9802991aa1d1bc00eee7713a838dab1eb4f149:  Separator string appears to not be expected (only "," should be yellow):

There is another weird behavior with UPDATE with multiple INNER JOIN, but the effect is unstable.
Screenshot:

"INNER" should be pink, but it is white.
If I edit the line with the white-instead-of-pink "INNER" join, then the "INNER" becomes pink. However, when I copy and paste the whole snippet again, then the "INNER" goes back to white.
I can trigger this by first pasting
UPDATE table_a a
INNER JOIN table_bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb b ON b.a = a.uid
INNER JOIN table_c c ON c.b = b.uid
SET
a.d = 5;

then removing the trailing bs from table_b:

Now INNER is white again:

UPDATE table_a a
INNER JOIN table_b b ON b.a = a.uid
INNER JOIN table_c c ON c.b = b.uid
SET
a.d = 5;

@LeoniePhiline you can re-open this issue if the issue still persists after testing with the updated grammar in the helix editor.
You'll probably want to update the highlights.scm file to include the new constants
(keyword_group_concat)
(keyword_separator)


Apprise Update to Version 1.4.5

Hello,
is it possible to update apprise within the docker image to the latest apprise version (1.4.5)? This version came out recently, see also the corresponding pull request (build(deps): bump apprise from 1.3.0 to 1.4.5 #76 ).
Thanks.

Yep, I will always make a new stable release. Thanks for using Mailrise.


Order of layers in the layer selector is different than the order of layers in the editor

@javisantana @saleiva feature or bug?

There has been no activity on this issue for several months and that's why we are closing it (automatically). If you think this still needs to be addressed please reopen it. The good news is that we are now working on the next version of CARTO.js, stay tuned.


Field name case

Creating a WebAPI provider with searchField that has the same case as the field name in the SGID doesn't always work.
Sherlock uses Provider searchField string to access object properties here and it caused problems when searchField is not uppercase.

I don't understand. Will you give an example.

Sure. This provider caused errors for me:
         var countiesProvider = new WebAPI(
                config.apiKey,
                'SGID10.LOCATION.ZoomLocations',
                'Name'
            );

The provider searchField 'Name' has the same case as the field in ZoomLocations but it will cause Sherlock to error unless you provide the searchField in uppercase to the Provider constructor.

What is the exact error and stack trace of you have it?

Here is the stack trace:
dojo/promise/instrumentation.js:20 Error: sherlock.Sherlock_processResults: Cannot read property 'slice' of undefined(…) "Error: sherlock.Sherlock_processResults: Cannot read property 'slice' of undefined
    at _processResults (sherlock/Sherlock.js:425:23)
    at eval (sherlock/Sherlock.js:382:22)
    at eval (dojo/_base/lang.js:386:55)
    at signalListener (dojo/Deferred.js:37:21)
    at signalWaiting (dojo/Deferred.js:28:4)
    at Deferred.resolve (dojo/Deferred.js:192:5)
    at eval (agrc/modules/WebAPI.js:149:25)
    at signalListener (dojo/Deferred.js:37:21)
    at signalWaiting (dojo/Deferred.js:28:4)
    at Deferred.resolve (dojo/Deferred.js:192:5)
    ----------------------------------------
    rejected at signalDeferred (dojo/Deferred.js:84:15)
    at signalListener (dojo/Deferred.js:55:5)
    at signalWaiting (dojo/Deferred.js:28:4)
    at Deferred.resolve (dojo/Deferred.js:192:5)
    at eval (agrc/modules/WebAPI.js:149:25)
    at signalListener (dojo/Deferred.js:37:21)
    at signalWaiting (dojo/Deferred.js:28:4)
    at Deferred.resolve (dojo/Deferred.js:192:5)
    at signalDeferred (dojo/Deferred.js:81:15)
    at signalListener (dojo/Deferred.js:52:6)
    ----------------------------------------
Error
    at Promise.Deferred.then.promise.then [as then] (dojo/Deferred.js:252:24)
    at _search (sherlock/Sherlock.js:378:48)
    at eval (sherlock/Sherlock.js:323:22)
    at eval (dojo/_base/lang.js:386:55)"logError @ dojo/promise/instrumentation.js:20(anonymous function) @ dojo/promise/instrumentation.js:67filter @ dojo/_base/array.js:333logRejected @ dojo/promise/instrumentation.js:62
sherlock/Sherlock.js:663 sherlock.Sherlock:_toggleTable [false]

In debugging I saw that accessing the object property by string is returning undefined here and then the slice is failing just after that.

That's strange. It should be making the request to the web api with the identical value for the attributeStyle option for that service. I'd like to take a look at the request on your machine when you get a chance.

This is an upstream bug in the web api. Closing in favor of: https://github.com/agrc/api.mapserv.utah.gov/issues/29


What will happen when cache consumes all allocated organization storage

This might be an edge case question but I think it's important form product team to have an answer ready for that.
Since currently no maximum cache size per pipeline and no way to clean up cache.  What will happen in case of many pipelines in an organization uses that feature to store many files till  organization run out of reserved space or maximum quota?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 77c20289-dab2-7a6e-4f63-4b30eaff2c71
Version Independent ID: d75cc196-90c1-8291-9907-ff405bde4edf
Content: Pipeline caching - Azure Pipelines
Content Source: docs/pipelines/caching/index.md
Product: devops
Technology: devops-cicd
GitHub Login: @chasewilson
Microsoft Alias: phwilson

@AElharouny Thank you for your feedback. Caches are scoped to a project, pipeline, and branch. A pipeline can have one or more caching task(s) and there is no limit on the caching storage capacity at the moment.


[Backport 2.x] Integration tests framework

Description
Test framework that allows for declaring within the test class all
related users, roles, and other security primitives.  Emphasis on
hamcrest Matchers for straight forward to read, author, and
troubleshoot test cases.
Special Note
This is a giant pull request - I would highly recommend using the github.dev [view] for reviewing and providing feedback.  I'll also provide comments for the initial reviewers where I call out any deviations I've taken from what is in main
Issues Resolved

Resolves https://github.com/opensearch-project/security/issues/3230

Check List

[X] New functionality includes testing
[ ] New functionality has been documented
[X] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Tests with failures  - tracking burndown:

[ ] org.opensearch.security.DefaultConfigurationTests.shouldLoadDefaultConfiguration
[ ] org.opensearch.security.PointInTimeOperationTest.listPitSegmentsCreatedWithIndexAlias_positive
[ ] org.opensearch.security.PointInTimeOperationTest.listPitSegments_negative
[ ] org.opensearch.security.PointInTimeOperationTest.listPitSegments_positive
[ ] org.opensearch.security.PointInTimeOperationTest.listPitSegmentsCreatedWithIndexAlias_negative
[ ] org.opensearch.security.api.DashboardsInfoTest.testDashboardsInfoValidationMessage
[ ] org.opensearch.security.api.DashboardsInfoWithSettingsTest.testDashboardsInfoValidationMessageWithCustomMessage
[ ] org.opensearch.security.rest.AuthZinRestLayerTests.testAccessDeniedForUserWithNoPermissions
[ ] org.opensearch.security.rest.AuthZinRestLayerTests.testShouldAllowAtRestAndTransport
[ ] org.opensearch.security.rest.AuthZinRestLayerTests.testBackwardsCompatibility
[ ] org.opensearch.security.rest.AuthZinRestLayerTests.testShouldAllowAtRestAndBlockAtTransport
[ ] org.opensearch.security.rest.AuthZinRestLayerTests.testShouldBlockAccessToEndpointForWhichUserHasNoPermission
[ ] org.opensearch.security.rest.WhoAmITests.testWhoAmIWithGetPermissionsLegacy
[ ] org.opensearch.security.rest.WhoAmITests.testWhoAmIWithoutGetPermissions
[ ] org.opensearch.security.rest.WhoAmITests.testWhoAmIWithGetPermissions
[ ] org.opensearch.security.rest.WhoAmITests.testAuditLogSimilarityWithTransportLayer

Note; Moving this to draft while I'm making sure these tests are stable, I've added a bunch of debug only changes that should be reverted before merging, I'll pull this out of draft when its mergeable - but feel free to review it as it stands

With CrossCluster tests disabled additional tests to look into:

[ ] org.opensearch.security.SearchOperationTest.shouldUpdateTemplate_positive
[ ] org.opensearch.security.SearchOperationTest.shouldCreateIndexTemplate_positive

... waiting on additional results, will edit this comment as they come in from the latest [run]

OK - I'm pretty sure this is ready to merge, or near as ready as I'm going to try to push it, I've made a number of annotations to ignore flaky tests, we should revisit these and I'll add several tracking issues, along with disabling windows due to the network trouble.
Proof that this test collection is stable - 10x runs on JDK 11 / 17

https://github.com/opensearch-project/security/actions/runs/6305277168/job/17118384937?pr=3388

@RyanL1997 @DarshitChanpura could I get another review?

@DarshitChanpura & @RyanL1997 see [1] for the fast follow up items.

[1] https://github.com/opensearch-project/security/pull/3427


Bookmark folder popup position not always ideal

Now that #1151 is merged we have bookmark folder popup position that is "good enough" for general use but the experience is not ideal in all scenarios.
For context, "top level" means a folder is on the bookmark bar itself and not nested inside another folder.
Folder popup position scenarios

Normal/default position

Top level: Show below the parent
Nested: Show beside the parent (on the right side)

Overflowing viewport to the right

Top level: Align the popup to the right edge of the viewport
Nested: Show beside the parent (on the left side)

Subsequent nested folder popups should also open to the left

At this point if a popup overflows to the left of the viewport then open to the right of the parent

Overflowing viewport both left and right

If the viewport is very narrow and the popup overflows on both sides there's basically nothing we can do. In this case the user will need to use the native bookmark bar or bookmark manager.

The current popup position logic from #1151 covers everything other than opening subsequent nested folder popups to the left (and then to the right if overflowing the left edge of the viewport).
Other issues

Popups remain in place when the parent is scrolled. Native chrome closes the popup upon scrolling the parent, perhaps we should do the same. TBH it's not such a big deal though.

I'll add that popups open beside the selected item, and if it's a folder near the bottom of the screen - there's no space to display its contents.
Getting a scroller with just one line visible.

We can now access Bookmarks using side panel on any page so this shouldn't be an issue any more.

@guest271314 it's more about having immediate access to the bookmarks on the new tab page and hiding bookmarks elsewhere. In the same vane the native bookmarks bar is available any time, however, there's no way to show and hide it programmatically.
Additionally, I've come to really enjoy this extension's bookmark bar implementation which shows folder on hover. It's really fast and convenient to access bookmarks.
That said, the UI still needs a lot of work. I've been following along with progress on the CSS anchor positioning API and the popover API as potential solutions to reduce the amount of code required compared to all the positioning JS needed.
Refactoring the UI and combustibility are things I'd definitely like to get to soon.

We can programmatically open the side panel, and provide any content we want there, besides the default list that includes the Bookmarks, here on the extension defined new tab page that I use

We can certainly create an element that is displayed the same window positioning as the native Chromium UI bookmarks panel.
Maybe I'm not getting what you are describing.

E.g.,


add API key and test fetch

Initially struggled with 'invalid API Key' - generated new key which is now working.
URL for API Weather App also not accepting template literals. Rewrote outside of VS Code and pasted in - worked!

Tested - entering cities in search box results in API data in console

Added if statement to dynamically change 'current weather' card - bug - error message saying 'cannot fetch data'

Fixed multiple bugs
Several typos in code preventing pull of weather data for main current weather card - now working - tested


[#70] Prevent bundled emails from flashing/appearing in inbox

@abasiri I implemented the fix for bundled email flashing that you described (No. 3 in issue #70)
Let me know if this is what you had in mind, seems to work for me.

Thanks for working on this, i'll take a look this evening.

@boukestam If you get a chance, could you test this one (I notice you just tested and merged the other related PR)
If you're not familiar, this is supposed to stop hidden bundled emails from briefly re-appearing in the inbox when returning from a bundle to the inbox, or when the inbox list redraws/polls for whatever reason.

I don't really see anything going wrong. I don't see what it is supposed to fix either, but I guess that is exactly the point of this :)

@boukestam I added a gif of what it was supposed to fix :P But either way, it works!


UIScrollView+Combine

I am not sure if this extension is relevant to this lib, but is worth trying 😊

Creating contentOffsetPublisher just because of contentOffset in RxCocoa
Creating reachedBottomPublisher(offset:), which is a publisher, emitting if the bottom of the UIScrollView is reached. Similar to what we have in RxSwiftExt

Forgot to write - excellent work!! Thank you so much 🙏 @jdisho

@jdisho will you have time to wrap this soon? let me know if you need help

Hey @freak4pc, apologies for the delay. I didn't find the time during the weekend. 😅
I will address your comments today/tonight.

Please have another look @freak4pc. 😊
I addressed your comments in the latests commits. I also updated the README.

How did you configure to use 2-spacing instead of a tab? Because by default, I have the tab one.

@jdisho

I just realised a weird problem with contentOffsetPublisher. It seems to crash the app when it is being used (checked in the Example.app), but it doesn't when reachedBottomPublisher(offset:) is being used.
This is what I get for  contentOffsetPublisher 🤷♂:
libsystem_platform.dylib`_os_unfair_lock_recursive_abort:
    0x7fff51355425 <+0>:  movl   %edi, %eax
    0x7fff51355427 <+2>:  leaq   0x7ae(%rip), %rcx         ; "BUG IN CLIENT OF LIBPLATFORM: Trying to recursively lock an os_unfair_lock"
    0x7fff5135542e <+9>:  movq   %rcx, 0x3879a02b(%rip)    ; gCRAnnotations + 8
    0x7fff51355435 <+16>: movq   %rax, 0x3879a054(%rip)    ; gCRAnnotations + 56
->  0x7fff5135543c <+23>: ud2

Oh wow that's nasty haha :)
I'd open a Feedback Assistant, or a bug on https://bugs.swift.org.
WDYT?

Fyi, it does not crash when I debounce(for:scheduler:options: it.
I will create a bug report. Thanks 😊


feat: support anonymization/pseudonymization for conditional references

See Issue Conditional references #50.

Any comments on this?

Now supports identifier search parameters in IfNoneExist properties of Bunde entry requests (Conditional creates).

Thanks for the PR! There's only a conflict in the Dockerfile which you can address by rebasing on master.
Do you think there will be any breaking changes, ie. things that previously weren't pseudonymized now are or things that were pseudonymized now no longer are? (We should probably add some sort of snapshot testing to better protect against such regressions eventually). If no breaking changes are expected I'd be OK with merging despite my comments and simply iterating on the feature later on since the raised concerns may not actually affect the users (you) at this point. Putting this feature behind a feature flag to avoid any unintended changes might also be an option for peace of mind.
Off-topic, but I think it might be better to eventually get rid of the copy-pasted Microsoft.Health.Fhir.Anonymizer.Shared.Core code and simply use the upstream nuget package: https://github.com/microsoft/Tools-for-Health-Data-Anonymization/issues/74. The solution implemented here could also be implemented by combining the generalize method which matches on an ifNoneExist identifier with a pseudonymize method. There's currently a PR open which allows extending the generalize method: https://github.com/microsoft/Tools-for-Health-Data-Anonymization/pull/169.

Do you think there will be any breaking changes, ie. things that previously weren't pseudonymized now are or things that were pseudonymized now no longer are? (We should probably add some sort of snapshot testing to better protect against such regressions eventually). If no breaking changes are expected I'd be OK with merging despite my comments and simply iterating on the feature later on since the raised concerns may not actually affect the users (you) at this point. Putting this feature behind a feature flag to avoid any unintended changes might also be an option for peace of mind.

I don't think this will be a breaking change. However, you made a valid point that this feature isn't quite ready as a general solution.
I was basically trying to solve a specific problem which is (possibly) the most common use case: Conditional references using identifiers and urls. At least, this is how we build our resources so that was my motivation behind this, obviously.
We use a separate fork of this project and have this feature in production for 5 months now. Along with other changes which are probably even more specific to our needs.
So there is currently no pressure to have this merged quickly from our side.

Off-topic, but I think it might be better to eventually get rid of the copy-pasted Microsoft.Health.Fhir.Anonymizer.Shared.Core code and simply use the upstream nuget package: microsoft/Tools-for-Health-Data-Anonymization#74. The solution implemented here could also be implemented by combining the generalize method which matches on an ifNoneExist identifier with a pseudonymize method. There's currently a PR open which allows extending the generalize method: microsoft/Tools-for-Health-Data-Anonymization#169.

That sounds promising. I will have a look at it when time permits. 😉

@jabberwoc I've rebased and put the conditional reference pseudonymization behind a feature flag (arguably excessive given that the change shouldn't really cause anything backwards-incompatible...). You can enable it by setting Features__ConditionalReferencePseudonymization=true. You can address the comments above in a seperate PR should the need ever arise.
But this way you don't have to maintain your own fork and can benefit from the latest upstream features (e.g. https://github.com/miracum/fhir-pseudonymizer#usesystemtextjsonfhirserializer). Let me know if the changes look OK to you and I can go ahead and merge it.

@chgl Yes, go ahead. Thanks!


Improve MeshDataTool.get_face_vertex method description

What I did

Improved the MeshDataTool.get_face_vertex method description by making it more clear about what is the data type that is returned and adding a code example.

Closes: #7852 (issue from godot-docs repo)

Would need a c# example as well, @raulsntos?

Looks great! The final step before merging is to squash all the commits together so that the whole PR only contains 1 big commit with all your changes. We like to merge one commit at a time to keep the git history clean and navigable.
If you don't know how to do that, we have a helpful tutorial in the official documentation https://docs.godotengine.org/en/latest/community/contributing/pr_workflow.html#the-interactive-rebase

I would also suggest rewording the commit message as we don't use this format usually. The title of this PR is a good match for our usual commit style (you can see other examples in git log).

I would also suggest rewording the commit message as we don't use this format usually. The title of this PR is a good match for our usual commit style (you can see other examples in git log).

@akien-mga thanks for this suggestion!

@clayjohn the commit description wasn't looking good so I just adjusted it, sorry for the delay!

Thanks!

Cherry-picked for 4.1.3.


Quick fix for Presto queries stuck in infinite loop

CATEGORY
Choose one

[X] Bug Fix
[ ] Enhancement (new features, refinement)
[ ] Refactor
[ ] Add tests
[ ] Build / Development Environment
[ ] Documentation

SUMMARY

We have seen a few Presto queries with nested types (arrays, structs) that get stuck in an infinite loop. This PR fixes the problem.
@khtruong I tried adding a unit test capturing the regression, but the repro I have returns so many columns that I wasn't able to fully understand the problem and create a minimal repro. I'm planning to merge this to unblock customers, and then work on a test case — maybe you can help me?

TEST PLAN

Tested problematic queries, they all worked.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Changes UI
[ ] Requires DB Migration.
[ ] Confirm DB Migration upgrade and downgrade tested.
[ ] Introduces new feature or API
[ ] Removes existing feature or API

REVIEWERS
@khtruong

Codecov Report

Merging #7843 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #7843      +/-   ##
==========================================
- Coverage   65.88%   65.88%   -0.01%
==========================================
  Files         460      460
  Lines       22028    22030       +2
  Branches     2418     2418
==========================================
  Hits        14514    14514
- Misses       7394     7396       +2
  Partials      120      120

Impacted Files
Coverage Δ

superset/db_engine_specs/presto.py
77.9% <0%> (-0.38%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8d81c30...027b044. Read the comment docs.

As we discussed briefly, the root issue is that datum/data does not have the array columns which is what causes the infinite loop to occur. I think the true fix will lie in the function _process_array_data. In there, the code takes the original rows of data we get back. It inserts additional rows to expand the array data. These expanded rows will have the full set of expanded columns while the original rows may not. I think the fix would be to modify the original rows to also include all the expanded columns.

Oops I approved without reading the previous comment (went straight to files diff view...). Looked good to me but didn't mean to override the previous comments...

@khtruong I'm going to merge this to unblock Zippy and work on the root cause today, is that ok?

Sounds good!


Offer a default TCP/TLS client implementation behind a feature flag

The code to setup a TCP/TLS connection isn't overly burdensome for a user of the crate but it has the potential to grow and be a source of avoidable inefficiency or problems for the client, e.g. supporting client certificate based authentication or custom CA certificate or timeouts on requests or connection re-use and pooling to avoid setup/teardown cost per KMIP request/response, etc.
So perhaps it makes sense to offer a default implementation. Users of this crate don't have to use it, and may want to use RustLS instead of OpenSSL or some other XXX instead of YYY so forcing a particular choice and dependencies on them isn't perhaps a good idea, but a default behind a feature flag gives the ease of use and baked in adherence to best practice to those who want it and flexibility to go their own way to those who don't.

Initial versions of TCP/TLS connection client code for various Rust TLS crates both async and sync was bundled with v0.2.0 behind optional features.


[WIP] Refactor CI

What do these changes do?

Reduce the complexity of CI infra
Reduce the time of running CI
Reduce the size of the final released image

Related issue number

Fixes #918
Fixes #865

@lidongze0629 Could you help to bump up the required vineyard version to v0.3.11?
Thanks~


⚠ GitLab Server has degraded performance

In 6a1f6be, GitLab Server (https://gitlab01.its-telekom.eu) experienced degraded performance:

HTTP code: 200
Response time: 6684 ms

Resolved: GitLab Server performance has improved in 9ab5183.


chore(main): release 2.104.1

:robot: I have created a release beep boop
2.104.1 (2024-03-26)
Bug Fixes

Create group should auto focus on the name input (#3632) (ddb0b7f)
No pagination when querying environments_v2 (#3661) (7e19f4f)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/Flagsmith/flagsmith/releases/tag/v2.104.1 :sunflower:


Incorrect GIR for appstream.SearchTokenMatch

This is a bit field where the underlying C type is a packed enum. The packed nature of the enum is not currently representable in GIR; currently, it is fixed using a custom extension (bits attribute on enum and bit field types).

Evidently this was removed from the public API a year ago: https://github.com/ximion/appstream/commit/eebb0f8c4c1226b3eef8b0b799465ef5cda5ecea The GNOME 47 SDK no longer contains a version with this problem.


Keep Chromium's v8 & io.js' v8 in sync?

Currently Atom runs on io.js but includes v8 3.30 from Chromium 40. Since io.js now follows v8 versions included in latest stable Chrome, how about making those versions match to prevent unpleasant surprises? That would mean including v8 4.1 for now (as it's included in latest io.js & Chrome 41) and updating io.js & Chrome at the same time each 6 weeks.

This is already the plan afaik, they're just out of sync until Chrome 41 lands in Atom Shell (which is very soon)

Once the upgrade to Chrome41 is done we will be synced with latest io.js.


vetting time: WE & contentaccesible & manifest & UUID

If we recommend a web extension, lets make sure it doesn't leak UUIDs
@gorhill @mrdokenny @idlewan @tumpio @einaregilsson @meh @Synzvato @EFForg @kkapsner @greasemonkey @sibiantony
^^ sorry for all the @'s, hopefully this will bring it to your attention if you weren't aware, and appreciate your time if you can spare it for a quick answer, otherwise we can dig in ourselves. This issue may be fixed by Mozilla, but it would be good to know if these WE's are not affected, or can be fixed to not leak - thanks

Issue is here and some subsequent comments
PoC is here
ghacks article is here
Whitepaper is here
Update: 1372288 - currently access denied, will be opened up soon

system addons
:x: Screenshots - requires user interaction with the WE
web extensions

[x] CanvasBlocker - not a WE yet
[ ] Cookie Auto-Delete
[ ] Decentraleyes
[ ] Greasemonkey (not sure where they are with WE)
[ ] HTTPS Everywhere
[ ] Link Cleaner
[ ] NoScript
[x] Request Control - v1.8.2 has no web_accessible_resources
[x] Redirector - v3.1.0 has no web_accessible_resources
[ ] Smart Referer
[ ] SSleuth
[ ] uBlock origin
[ ] uMatrix

...

Greasemonkey (not sure where they are with WE)

Not yet: https://github.com/greasemonkey/greasemonkey/issues/2551
GS version 4.0 eventaully will.

The system addons that came with nightly 57 can no longer be extracted with Windows Explorer on Win7.
Do I really need to use a linux VM whenever I want to extract one of those bastards?! Does someone know of another way to extract them?
Are there maybe even plans to pack normal addons in the same way in the future?! WTH mozilla, was that really necessary?!?

Greasemonkey (not sure where they are with WE)

Not yet: https://github.com/greasemonkey/greasemonkey/issues/2551
GM version 4.0 eventaully will.

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/web_accessible_resources

This UUID is randomly generated for every browser instance and is not your extension's ID. This prevents websites from fingerprinting the extensions a user has installed.

FWIW, you can check if an extension has web_accessible_resources by checking its manifest.json.

If we recommend a web extension, lets make sure it doesn't leak UUIDs

We'd have to re-check every new version of every WE we recommend.
Lets just wait and see what the fix will look like before we pack another shitload of work on our backs.

Does it only affect extensions that have a content script? Are extensions using exclusively a background script affected as well?

It's the websites that lurk via moz-extension://

Webextentions have limited access to behind-the-scene network requests, unlike uBO/legacy which has full access to all behind-the-scene network requests.

You won't be able to see (and block) network requests made by other extensions.

See: https://github.com/gorhill/uBlock/wiki/Firefox-WebExtensions#differences-with-ubolegacy

Does it only affect extensions that have a content script? Are extensions using exclusively a background script affected as well?

No, afaik only WebExtensions with web_accessible_resources

CanvasBlocker uses content scripts but I do not see how it could leak the UUID.
PS: CB is not yet a WebExtension because of a missing API.

We'd have to re-check every new version of every WE we recommend.
Lets just wait and see what the fix will look like before we pack another shitload of work on our backs.

I understand that. This was more of a wake up, initial check and if the WE devs are aware*, they know to steer clear of it. Its not an easy fix within Firefox by the sounds of it. The ticket is now open. 3 months and not much visible activity. Suddenly (90 days later?) the whitepaper is published. The PoC (and article) probably helped sway the decision to open the ticket. And we have a flurry of comments.
I do not see this being resolved in time for ESR, let alone 57. So it would be nice to know for those if any of these WE can leak - including those not WE yet.

3 months and not much visible activity

comment 0: "Last year we reported you a vulnerability" - they knew about it for at least 8 months now.
I guess sharing the PoC wasn't so bad after all, at least it got some action going xD

3 months and not much visible activity

Actually, I should say 3 months (since the UUID leak issue was reported, not the previous timing attack issue from last year) and no activity (some tag dancing sec-low - WTF?, one comment) .. aaaaand suddenly we have traction...
so FUKYEAH™ that PoC did something

SSleuth has no WE yet, due to missing API.
Also, very likely it wouldn't need web_accessible_resources

Does someone know of another way to extract them?

@earthlng: Let me know.  https://github.com/Theemim/GeckoScratchpadSnippets/blob/master/unzipper.js

Thanks @sibiantony - is it this one?: https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
PS: I don't expect devs to work around this. I expect Mozilla to work out a better permissions model, but it sounds complicated.

Does it only affect extensions that have a content script? Are extensions using exclusively a background script affected as well?

@idlewan see this reddit thread .. maybe earthling can explain it. My understanding is the same as yours - content must be injected

Thanks @sibiantony - is it this one?: https://bugzilla.mozilla.org/show_bug.cgi?id=1322748
PS: I don't expect devs to work around this. I expect Mozilla to work out a better permissions model, but it sounds complicated.

@Thorin-Oakenpants Yes, that's the one.
If you meant the TLS API to be worked around, I don't think there exist a work around. Chrome doesn't support such an API either. And there is recent push for an API, thanks to EFF.

In Link Cleaner's case, it doesn't inject anything into web pages and doesn't have any web_accessible_resources, so it shouldn't be affected.

lets make sure it doesn't leak UUIDs

uBO does not declare web_accessible_resources (webext), and neither expose resource:// (legacy) to outside world.

@idlewan Thanks. I already cleared Clean Links and checked your manifest
@gorhill - Thanks :kiss: .. what about uMatrix WE?

Same with uMatrix, no web_accessible_resources, neither resource://.

 Thanks mate!!
https://bugzilla.mozilla.org/show_bug.cgi?id=1352595 is responsible for the change but it looks like, hopefully, for the time being it will only be used for nightly.
Also found this: https://github.com/mcmilk/7-Zip-zstd/issues/26

I've added Stylus (becuz) and VM (becuz GM ain't WE yet) to the list. I know they are not on our Wiki. Scream out if you can think of anything else

Even though both Firefox Screenshots and Decentraleyes make use of the web_accessible_resources manifest key, they are not equally vulnerable. It's never good to expose secrets to untrusted code.
The proof of concept relies on the fact that Firefox Screenshots creates an anchor element with a src attribute, that points to a web accessible resource. It depends on the UUID being directly exposed within the DOM of the document in question. Decentraleyes does not write resource locations into pages.
Another way of obtaining the UUID, would be to send out an XHR, and then reading the value of the responseURL property of the corresponding XMLHttpRequest object. However, cross-origin requests will not leak the UUID either. They fail due to the absence of Access-Control-Allow-Origin headers.
Based on what I have stated above, I do not believe Decentraleyes is currently leaking out unique user identifiers. That said, of course, please do try to prove me wrong if you think I'm missing something.

Thanks for the info @Synzvato
Sorry if that :x: looks scary. I've changed it to a :question:  By no means am I denigrating any extensions etc, and by their very nature, some extensions are going to be susceptible.  The problem and fix lies with Mozilla. The :question: is a much fairer reflection. Sorry about that. Hopefully this is an exercise in futility, and Mozilla comes up with a workable solution.
PS: Thanks for all your work porting to WE

@Thorin-Oakenpants

what about uMatrix WE?

Today I prepped it up for release, but then I realized I will have to wait for Firefox 56, there is a bug that was fixed in it, which I consider crippling in Firefox 55: https://bugzilla.mozilla.org/show_bug.cgi?id=1324499.

Thanks for clarifying @Thorin-Oakenpants, and no worries! I completely understand.

PS: Thanks for all your work porting to WE

You're welcome, and I'm happy to hear you appreciate the work!

@earthlng :kiss: for checking the system addons :+1:

Thanks everyone..
Conclusion:
Everything looks great for WE we recommend - if there are no web accessible resources, it cannot leak! Even Stylus (popular) and VM (alternative to GM). Proven devs, quality work, and of those not yet ported, I cannot see them providing any either - NoScipt might warrant a check.
@Synzvato has talked about Decentraleyes: over my head a bit - it's not using any script injection (probably worded that wrong), so it shouldn't/can't be detected
The chances of anyone out there running scripts for this is slim to none right now, I do not think anything we use is leaky, and Mozilla will issue a patch in time (although the flurry of comments has now DIED to a slithering crawl - booo!).
Task completed AFAIC and time to slap a bug label on it

First, the "greasemonkey" user is a project user that no human ever logs in to (nor will ever see at-mentions of).  Second the above-linked bug is just the "port user data" (from legacy->webext) issue.
Third: I have always had issues with Mozilla's documentation ever since starting WebExt porting work, but this sounds like an even bigger one.  Hilariously:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/web_accessible_resources

This UUID is randomly generated for every browser instance and is not your extension's ID. This prevents websites from fingerprinting the extensions a user has installed.

If I've interpreted the giant thread above correctly, the true fact is that ever using web_accessible_resources creates a possible/likely privacy leak for users, but instead the documentation only talks about the benefits.  If so, that should be the giant/bold/red/first thing on the relevant page.  Either way, something about this issue should be.
My work-in-progress Greasemonkey port does use web_accessible_resources .  Because there are so few/crappy UI options available to WebExtensions.  Where are my chrome-free dialogs?  An entire tab, or a modal-only window with a giant UUID/URL covering the entire title bar is not enough.

@arantius Thanks for dropping by, and thanks for your porting work. Much appreciated.
I kind of assumed (and it may not even be an issue soon if Mozilla patch quickly enough), that since ViolentMonkey didn't use any web_accessible_resources (and I know GM and VM are not the same project), that you wouldn't either.
That said, if you're not injecting these resources into the page (and clearly you aren't), I think you're fine. Certainly not your fault, and not a reason for you to change your design at all. It's a mozilla problem. The mozilla documentation wouldn't reflect the bugzilla information, it was only opened up to the public a few days ago.
Giant thread? Nah mate, that's a dwarf :) PS: I agree about the few crappy UI options.

Ah, but I am injecting.  Into, I believe, (plain text) pages that could never observe the insertion with a script, but still.

Yes, I mean injecting those resources into WEB pages - not protected options/interfaces/settings/dialogs

https://github.com/greasemonkey/greasemonkey/blob/master/src/content/script-detect.js#L30
After mime type detection, we inject, into web content.

For whatever it's worth, uBO does use an iframe for its element picker. However, the iframe has the same origin as the page, and thus no need for web_accessible_resources. The trick is to fetch the HTML in plain text from the background page from the element picker content script, then parse the response using DOMParser, and just use the result into the iframe.contentDocument through adoptNode: https://github.com/gorhill/uBlock/blob/master/src/js/scriptlets/element-picker.js#L1434. A long while ago, @Deathamns designed it this way.

I have to admit, I stopped coding over a decade ago (and not in any web technologies), and some of this is a little over my head. @Earthlng understands this 100% 200% better than me, so I'll let him follow up and clarify this.
As far as I know:
ViolentMonkey injects (it has too right, otherwise it cannot control/change anything, right?). Greasemonkey does too. Screenshots does as well. Screenshots injects its own resources, and it is the resource path that is traced, revealing the UUID. So as long as you do not inject your own resources (and why would you?) then I think the UUID is not leaked.
^^ BUT i am NOT knowledgeable enough on this, and I may have misunderstood it.
OOh .. there's gorhill .. he knows lots :)

So as long as you do not inject your own resources (and why would you?)

As said above, because limited UI options.  I don't want to fire a whole tab, I can't open my own page action dialog (which would otherwise be perfect).  So I'm injecting an iframe wherein I can put my small bit of UI.
Theoretically, I could re-write to replace the document with my own, which injects the original content into a frame.  Not totally sure that would help, and I'd rather the platform just doesn't present this opportunity.  For my usage, an extra randomized/obfuscation of the result of runtime.getURL() (so it doesn't contain this UUID) would fix it.

Thanks @arantius ,, as far as I'm concerned, this is not your problem - it is Mozilla's. Please don't waste your time and resources on it too much
PS: Thanks ever so much for porting GM. Any idea of when it might land? I'm holding out for it - I do not want to go VM, and refuse to even look at TM. Cheers :)

@Thorin-Oakenpants

Conclusion:
Everything looks great for WE we recommend

What about recently added Neat URL?

@rekixex ... Neat URL has no web_accessible_resources in its manifest.json - added to the first post, thanks

@Thorin-Oakenpants Just to remind you about Skip Redirect.

[x] Skip Redirect - 2.2.1 has no web_accessible_resources

FYI: Updated versions

[x] Smart Referer - v0.2.3 has no web_accessible_resources
[x] ViolentMonkey - v2.8.10f - has no web_accessible_resources

Smart Referer AMO is now the WebExtension version
VM finally had an update after AMO got a wriggle on - also VM is now listed on the Wiki Extensions page, and I'm using it and ditched GM

added to first post:   * Update2: 1405971

FYI: CanvasBlocker is a WebExtension since version 0.4.0

^^ good point .. I'll also move greasemonkey up to the right section

woo .. GM web extension has no wen accessible resources

NoScript v10.x checked and updated in first post

Header Editor - v2.3.5 checked and added in first post

Is web_accessible_resources the only possible way for an add-on to be affected by this issue ?
Apparently Tree Style Tab is affected by this as it uses web_accessible_resources for resources/group-tab.html.
@piroor Do you see any way to get this feature to work in TST without web_accessible_resources ?

update: - added: ClearURLs - v1.2 has no web_accessible_resources

Update:
The manifest key web_accessible_resources is now declared in the dev build of uBO (1.15.7b0+).
This is the only solution for the following uBO's issues:

https://github.com/gorhill/uBlock/issues/3474
https://github.com/gorhill/uBlock/issues/2823

And this will also be the only solution to fix:

https://github.com/gorhill/uBlock/issues/3497

Firefox
These web accessible resources are never exposed to the DOM -- hence uBO's unique extension id on Firefox cannot be seen by web pages (just as with Decentraleyes).
Chromium
uBlock Origin (or any extension) on Chromium is not assigned a unique extension id, it is assigned a static extension id, used by all installations of uBO. This means that a web page could try to fetch a resource known to be "web accessible" in order to directly find out that uBO is installed -- hence more information for fingerprinting (see http://singularity.be/public/papers/extensions.pdf)
uBO foils such information leak by requiring that the fetching of any web accessible resource be done using a secret, which secret is randomly generated at launch time. Without the secret, known only to uBO, the fetch will fail as if the resource does not exist, as if web_accessible_resources is not declared.
Demonstration of such direct detection which is foiled by uBO:

Install AdBlock from the Chrome store: https://chrome.google.com/webstore/detail/adblock/gighmmpiobklfepjocnamgkkbiglidom
Open a new tab to any web page, say https://news.ycombinator.com/
Open dev console of the web page (press F12)
Paste the following in the console and hit Enter:var xhr = new XMLHttpRequest(); xhr.open('get', 'chrome-extension://gighmmpiobklfepjocnamgkkbiglidom/adblock-jquery-ui.custom.css'); xhr.onload = xhr.onerror = function(response) { console.log('AdBlock:', (this.status===200 ? 'DETECTED' : 'NOT detected')); }; xhr.send();
Result if AdBlock is installed and enabled: AdBlock: DETECTED
Result if AdBlock is not installed and enabled: AdBlock: NOT detected

However the above won't work with uBO despite it now declaring web_accessible_resources:

Install uBO dev build from the Chrome store: https://chrome.google.com/webstore/detail/ublock-origin-dev-build/cgbcahbpdhpcegmbfconppldiemgcoii
Open a new tab to any web page, say https://news.ycombinator.com/
Open dev console of the web page (press F12)
Paste the following in the console and hit Enter:var xhr = new XMLHttpRequest(); xhr.open('get', 'chrome-extension://cgbcahbpdhpcegmbfconppldiemgcoii/web_accessible_resources/to-import.txt'); xhr.onload = xhr.onerror = function(response) { console.log('uBO:', (this.status===200 ? 'DETECTED' : 'NOT detected')); }; xhr.send();
Result if uBO dev build is installed and enabled: uBO: NOT detected
Result if uBO dev build is not installed and enabled: uBO: NOT detected

Thanks for the detailed info @gorhill ! 👍

Yes, @gorhill thank you very much for the detailed info :kiss: I will update the first post

from gorhill's comment addendum three posts up

as noted by @Synzvato above

Gorhil thanks for blocking that responseURL + xmlhttprequest leak.
Synzvato I removed the red question mark for Decentraleyes in the first post since you clearly have this covered

might as well close this one as well, it's been 15 months and it's not a simple fix by the sounds of it (needs jesus!!). At least we vetted our extensions at the time, and spoke to a bunch of awesome devs etc. Something to always be mindful of sigh

FWIW - 1405971 has been fixed in FF73+ (so far)


ipam: Fix flaky test TestNodeManagerManyNodes

please see commit message
Related: #26617

@tommyp1ckles @christarazi Please take a look. This flake clearly happens more often lately, but I'm not quite sure why recent changes would introduce this.

/test

@jaffcheng Interesting, I've been looking into this as well,  I'm pretty sure its related to racey code related to appending to the AzureInterface Addresses array in the mock API implementation.
I have a local reproduction that can cause the failure to occur fairly quickly, let me validate if this fixes it.

Even with these changes, I stil run into the failure.

Even with these changes, I stil run into the failure.

Thanks for trying, could you share your reproduction method and test output? My local test is running pkg/ipam unit tests a lot of times with/without -race and lockdebug. But haven’t tried pkg/azure yet.

@jaffcheng Sure, my branch is quite messy, ill push that up later today.  The main part is here in the Upsert function in node_manager.go. Basically just removing the exponential backoff between triggers and running the poolMaintainer trigger in a loop causes this to occur usually in a couple seconds.  I'm running the test with
go test -count=100 -v -failfast -race

		poolMaintainer, err := trigger.NewTrigger(trigger.Parameters{
			Name:            fmt.Sprintf("ipam-pool-maintainer-%s", resource.Name),
			MinInterval:     10 * time.Millisecond,
			MetricsObserver: n.metricsAPI.PoolMaintainerTrigger(),
			TriggerFunc: func(reasons []string) {
				if err := node.MaintainIPPool(ctx); err != nil {
					node.logger().WithError(err).Warning("Unable to maintain ip pool of node")
					//backoff.Wait(ctx) Remove exponential backoff wait to increase chance of race occuring.
				}
			},
			ShutdownFunc: cancel,
		})
                // Trigger poolMaintainer continuously!
		go func() {
			for {
				<-time.After(time.Millisecond)
				poolMaintainer.Trigger()
			}
		}()

Race reveals a couple data races in this,  I was hoping fixing those would solve the problem but yet it still persists 😕

Although I think this patch should significantly lower the possibility of flakes, there are still some races found in /pkg/ipam with -race on. Need more digging...

Although I think this patch should significantly lower the possibility of flakes, there are still some races found in /pkg/ipam with -race on. Need more digging...

there appears to be many races there 😄 I have a few race fixes as well I'll put PRs for.  Considering how hard im finding it to get to a single cause, its possible the issue is caused by multiple races.  We can start fixing these and see if the flakes improve.

Change Fixes: to Related: since this does not fix all races.

/test

When I was looking at this, another place I thought it might be racing was here: https://github.com/cilium/cilium/blob/main/pkg/ipam/node.go#L430
i.e. the interfaces are checked in parallel and then on the next line they will race to get the Node lock, so in theory a stale set of values could overwrite the latest ones.
But... fixing this didn't fix the flake in practice.
I think these changes make sense, lock changes in this code scare me a bit, I'll do another review to double check that we aren't creating a deadlock somewhere in shortly.

I think these changes make sense, lock changes in this code scare me a bit, I'll do another review to double check that we aren't creating a deadlock somewhere in shortly.

Changed to GetNodesByIPWatermarkLocked and slightly changed the commit message given that this only fixes one source of the flake.

/test

@jaffcheng The integration tests are failing I believe to CI using a newer version of Go,  can you rebase your branch - that should fix it.

/test

What's the consequence of this bugfix? Should we backport it to v1.14 per the backport criteria? Does the race condition affect other branches too?

Reviews are in, CI is passing. LGTM to merge.

@joestringer The changes that causes this don't appear to be in the v1.14 branch


Not able to read the images using tesseract 4.0 please Help

Images.zip
Hi
I am trying to read the text from the images(attached zip file for images) but it returns wrong result and in many case a blank output. Please suggest what is gone wrong with code. I have also attached code for same

I have installed tesseract.net -Version <IP_ADDRESS>
Thanks in advance

Hi,
The code doesn't seem to use something from this repo. (e.g. TessBaseAPI)
Anyway, here is my recommendations :

From the wiki of Tesseract: By default Tesseract expects a page of text when it segments an image. If you're just seeking to OCR a small region try a different segmentation mode (https://github.com/tesseract-ocr/tesseract/wiki/ImproveQuality#page-segmentation-method)

From the wiki of Tesseract: Tesseract works best on images which have a DPI of at least 300 dpi, so it may be beneficial to resize images. (https://github.com/tesseract-ocr/tesseract/wiki/ImproveQuality#rescaling) (In your case, the image is maybe too small)

The text on a page is generally black. (maybe you can invert pixels?)

You may also want to read: https://github.com/tesseract-ocr/tesseract/wiki/ImproveQuality
Thanks!

Hi, I will close the issue for now. Feel free to open it again.


Holiday gun

Passed the following tests in both VR and Desktop; Please reassign to QA if fundamental changed in CR.
Full test pass located here:
https://docs.google.com/document/d/1CWdEZZBEM9WUxtSkNZiFh1b6KTdRpWEG57lhHzNNRl8/edit?usp=sharing


[Member Analytics] Refresh User List

Note: I deleted the actual data files as I'd like to sanitize them first for member PII


Use deployment primitives from travis

Need advice on this.
I may go further to improve building

This looks good to me
ping @containous/traefik

Needs a rebase

@errm id you are talking about multi-commit, maintainers can merge by squashing commits ;)

No just the branch was stale...

Ping @containous/traefik, we need a review on this ;)

@guilhem needs a rebase. How could we test that though ?

@guilhem are you sure that the behavior is the same in the case of a pull request (deploy-pr.sh removed) ?

Yeah looks like the behaviour from deploy-pr is not replicated, can we add that back in please @guilhem ?

@errm @emilevauge Yes, I didn't replicated deploy-pr.sh because it's just simply not working :)
https://travis-ci.org/containous/traefik/jobs/181516876#L1946
https://travis-ci.org/containous/traefik/jobs/181516879#L1949

@guilhem it is https://travis-ci.org/containous/traefik/jobs/183995719#L2089 ;)

humm...
So I have to fix it ^^

@emilevauge I think I've found the problem.
Only PR done by you (or people with write access) have this feature working because of this: https://docs.travis-ci.com/user/pull-requests#Pull-Requests-and-Security-Restrictions

@guilhem
https://github.com/containous/traefik/pull/936
https://travis-ci.org/containous/traefik/jobs/182236245#L2087

@emilevauge but https://travis-ci.org/containous/traefik/jobs/182320106#L2085 fail :)

But maybe we want to have a rolling docker for each commit pushed inside "master"

Yes, check the merge build, not the pull request build: https://travis-ci.org/containous/traefik/jobs/182236245#L2087

@emilevauge should be ok. Plus:

speed improved
right docker version tested

@guilhem I don't think creating a Docker image by commit is a good idea. Usually, we need to atomically take the whole pull request to get it working. Could you rollback to the old behavior?

@emilevauge docker image is pushed not by commit, but with "latest" commit (the merged if there is one).

Oops, you right ;)

gentleping @containous/traefik

@vdemeester done :)

@guilhem do you know why tests are failing ?

@emilevauge no idea. can you try to re-run failing tests?

@guilhem I relaunch the tests 2 times and still the same result :'(

@emilevauge I think bug come from github.com/libkermit/compose or github.com/docker/libcompose or association of it.
Test for docker 1.10 are ok but compose is failing with docker 1.9
It's quite hard to update dependencies between all this projects as it's used by traefik and traefik/integration and they are different packages.
Solutions can be:

remove docker 1.9 support (it's not really tested with current setup).
To include integrations test in same sources and use flag matching

it works with docker 1.10 and 1.12

@guilhem we agree with @vdemeester to remove Docker 1.9 support :)

@emilevauge I'm in holiday right now, but I will do this for Monday before meetup ;)

@vdemeester rebased, squashed, fixed etc
:)

FAIL: basic_test.go:76: SimpleSuite.TestPrintHelp
basic_test.go:89:
    c.Assert(string(output), checker.Contains, "Usage:")
... obtained string = ""
... substring string = "Usage:"

:(

@vdemeester, any idea on what's going on here ?

Hum I don't see in the failed build but it might be a weirdiness with how the test is written — if the run is particularly slow it might fail 😓 . I'll take a look.


Couldn't get Blizzard page (HTTP 403 error)

Describe the bug
{
"error": "Couldn't get Blizzard page (HTTP 403 error) : \r\n<title>403 Forbidden</title>\r\n\r\n
403 Forbidden
\r\n\r\n\r\n"
}

To Reproduce
Try to get any player profile, for example: https://overfast-api.tekrop.fr/players/Maevis-2125

Hello,
Thank you for the feedback ! It looks like there was a global issue that lasted a few hours. I believe it occurred because my server generated excessive traffic to overwatch.blizzard.com, which led to a temporary ban 🙈. I've resolved the issue for now by disabling the background cache refresh system to limit traffic.
Since I hadn’t anticipated such high traffic when designing the system, I'll be updating it to make it more resilient before reactivating it 👍.

Thanks @TeKrop , really appreciate it! 🥳 It seems to be working again now.
You can add my app to your community list if you'd like: www.counterwatch.app

Oh, very nice app, will do 😄


Retry requests that receive 429

Changes

Retry requests automatically on 429 errors and manually on any error

I was imagining was that the retry logic would live in OutputCell. That way we can message the user that a call got rate limited, and we're retrying in X seconds
I think this one also doesn't have a way to let you retry again once it fails 3 times?

Good idea.


Fetch missiion

Hi @sanieni6
I did the following activities:

Fetch data from the API.
Diispatch an action to store the selected data in Redux store

Thanks man for the review


安卓小白，打包的问题

项目启动 as编译都正常，但是在打包APK的时候就会报各种版本的错误，应该改哪里，对安卓不太熟，AS用的是2024.2，JDK17.
报错信息：
A problem occurred configuring root project 'TsddClient'.

Could not resolve all artifacts for configuration ':classpath'.
Could not resolve com.android.tools.build:gradle:8.7.2.
Required by:
project :
No matching variant of com.android.tools.build:gradle:8.7.2 was found. The consumer was configured to find a library for use during runtime, compatible with Java 8, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin.api-version' with value '8.7' but:
- Variant 'apiElements' declares a library, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component for use during compile-time, compatible with Java 11 and the consumer needed a component for use during runtime, compatible with Java 8
- Other compatible attribute:
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')
- Variant 'javadocElements' declares a component for use during runtime, and its dependencies declared externally:
- Incompatible because this component declares documentation and the consumer needed a library
- Other compatible attributes:
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about its target Java version (required compatibility with Java 8)
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')
- Variant 'runtimeElements' declares a library for use during runtime, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component, compatible with Java 11 and the consumer needed a component, compatible with Java 8
- Other compatible attribute:
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')
- Variant 'sourcesElements' declares a component for use during runtime, and its dependencies declared externally:
- Incompatible because this component declares documentation and the consumer needed a library
- Other compatible attributes:
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about its target Java version (required compatibility with Java 8)
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')
Could not resolve com.google.gms:google-services:4.4.2.
Required by:
project :
No matching variant of com.google.gms:google-services:4.4.2 was found. The consumer was configured to find a library for use during runtime, compatible with Java 8, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin.api-version' with value '8.7' but:
- Variant 'apiElements' declares a library, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component for use during compile-time, compatible with Java 11 and the consumer needed a component for use during runtime, compatible with Java 8
- Other compatible attribute:
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')
- Variant 'javadocElements' declares a component for use during runtime, and its dependencies declared externally:
- Incompatible because this component declares documentation and the consumer needed a library
- Other compatible attributes:
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about its target Java version (required compatibility with Java 8)
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')
- Variant 'runtimeElements' declares a library for use during runtime, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component, compatible with Java 11 and the consumer needed a component, compatible with Java 8
- Other compatible attribute:
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')
- Variant 'sourcesElements' declares a component for use during runtime, and its dependencies declared externally:
- Incompatible because this component declares documentation and the consumer needed a library
- Other compatible attributes:
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about its target Java version (required compatibility with Java 8)
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')
Could not resolve com.android.tools.build:gradle:3.1.4.
Required by:
project : > com.huawei.agconnect:agcp:<IP_ADDRESS>0 > com.huawei.agconnect:agconnect-apms-plugin:<IP_ADDRESS>2
No matching variant of com.android.tools.build:gradle:8.7.2 was found. The consumer was configured to find a library for use during runtime, compatible with Java 8, packaged as a jar, and its dependencies declared externally, as well as attribute 'org.gradle.plugin.api-version' with value '8.7' but:
- Variant 'apiElements' declares a library, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component for use during compile-time, compatible with Java 11 and the consumer needed a component for use during runtime, compatible with Java 8
- Other compatible attribute:
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')
- Variant 'javadocElements' declares a component for use during runtime, and its dependencies declared externally:
- Incompatible because this component declares documentation and the consumer needed a library
- Other compatible attributes:
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about its target Java version (required compatibility with Java 8)
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')
- Variant 'runtimeElements' declares a library for use during runtime, packaged as a jar, and its dependencies declared externally:
- Incompatible because this component declares a component, compatible with Java 11 and the consumer needed a component, compatible with Java 8
- Other compatible attribute:
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')
- Variant 'sourcesElements' declares a component for use during runtime, and its dependencies declared externally:
- Incompatible because this component declares documentation and the consumer needed a library
- Other compatible attributes:
- Doesn't say anything about its elements (required them packaged as a jar)
- Doesn't say anything about its target Java version (required compatibility with Java 8)
- Doesn't say anything about org.gradle.plugin.api-version (required '8.7')

如果是使用的demo。可以尝试通过以下方法
Android studio下载最新版本 下载地址
网络问题
清除 Gradle 缓存 ./gradlew cleanBuildCache后再重试


Rename packet_id to replay_id; message_id to packet_id

since it's a renaming, I'd be keen to merge it rather sooner than later... @reynir what are your thoughts about the renaming? does "replay ID" and "packet ID" make it clearer (also in respect to https://git.robur.coop/robur/openvpn-spec/issues/6)

we could as well rename the new packet id (former message id) as sequence number? WDYT?

I think I would like to avoid 'packet id'. I like sequence number. In the openvpn code the replay packet id (replay id) code mostly lives in packet_id.[ch] while the packet id (sequence number) lives mostly in reliable.c but uses the packet_id_type type from packet_id.h. It is highly confusing when reading the code that packet_id is used for both so I would prefer if we can avoid that term.
I like replay_id even if it's a half-truth as the timestamp is considered part of the replay packet id.

I force pushed the suggested sequence number change. I also found some more occurences of  "packet[_ ]id" and renamed them to replay_id or replay packet id.


No module named mos4d

Hello, I am trying to run 4dmos in google colab. However, it shows the "no module named mos4d" and can not run the program. Do you have any idea how to solve this problem?
Thank you.

Hi @E4CEeg,
did you install the project? To do this in colab, just run
!python3 -m pip install .

without the --editable option. Please note that we recommend the use of docker and our provided docker files to build and run the project.
Best regards
Benedikt

Hello, @E4CEeg,
I used my local Visual Studio Code to run the project and met the same problem as yours, then I solved the problem by moving the mos4d directory from /4DMOS-master/src/ to /4DMOS-master/scripts/.  Now I can train the model, and I hope this answer may help you. (However, I dont't know whether this change will trigger other problems...)

Hi @E4CEeg,
did you install the project? To do this in colab, just run
!python3 -m pip install .

without the --editable option. You should also pull the latest commit from the repo since you need an additional __init__.py file to import the MinkUNet in colab.
Please note that we recommend the use of docker and our provided docker files to build and run the project.
Best regards Benedikt

Hello   @benemer Thank you for your reply. Unfortunately, Google Colab does not support Docker.
After cloning the latest repo, now I can not even install the required installations.

Hello @benemer Thank you for your reply. Unfortunately, Google Colab does not support Docker.

Yes, what I meant is that you should use docker instead of google colab if you have a GPU. In general, I can not provide
support for colab because I am not using it in this project.

After cloning the latest repo, now I can not even install the required installations.

Which colab runtime are you using? Since colab outputs
Failed to build MinkowskiEngine

the problem seems to be the installation of the MinkowskiEngine with cuda support in colab.  Please check https://github.com/NVIDIA/MinkowskiEngine/issues/461 and https://github.com/NVIDIA/MinkowskiEngine/issues/95 for further reference. As far as I can see, there is only the way to install the CPU version of the MinkowsiEngine.
If you do not use the GPU/TPU runtime, the command !python3 -m pip install . will install the CPU_ONLY build set of the MinkowskiEngine:

In this case, the project is installed successfully and I can import it. Note that cuda will not be available in this setup.
Again, I recommend not using colab but installing the project with Docker if you have a GPU on your computer.
Best
Benedikt

Hello Benedikt, thank you for your reply. Because of the gpu I have to use the Google Colab. However, I have installed the Minkowski Engine separately.


Improve installation instructions

🦟 Bug fix
Improves installation instructions in README
Summary

Refer to https://brew.sh/ instead of duplicating the brew installation command.
List cmake variables in a markdown table.
Combine Ubuntu and macOS build-from-source instructions (https://github.com/gazebosim/sdformat/commit/85e50675bd7b975ca9130fbbd8832a0ae6105593)

Checklist

[X] Signed all commits for DCO
[ ] Added tests
[X] Updated documentation (as needed)
[ ] Updated migration guide (as needed)
[ ] Consider updating Python bindings (if the library has them)
[X] codecheck passed (See contributing)
[X] All tests passed (See test coverage)
[ ] While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

https://github.com/Mergifyio backport sdf14


Dev Server throws error when running Angular 17 app non-standalone with SSR

Command
serve
Is this a regression?

[X] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was
16
Description
When running an Angular 17 app with the module setup and SSR enabled, the dev server throws an error.
Building (ng b) works (unless prerender: true) and serving the client bundle directly works as well as running SSR: node dist/repro-app/server/server.mjs.
With prerender enabled, building throws the same error as the dev server.
Removing SSR (deleting ssr and server options in angular.json) causes the dev server to work as expected.
Minimal Reproduction
Run ng s in my repro.
See this branch for a repro of how removing SSR options fixes the issue.
Exception or Error
[vite] Internal server error: Cannot read properties of undefined (reading 'ɵmod')
      at getNgModuleDef (/workspace/repro-app/node_modules/@angular/core/fesm2022/core.mjs:2117:25)
      at assertNgModuleType (/workspace/repro-app/node_modules/@angular/core/fesm2022/core.mjs:2371:10)
      at compileNgModuleFactory (/workspace/repro-app/node_modules/@angular/core/fesm2022/core.mjs:31582:18)
      at _PlatformRef.bootstrapModule (/workspace/repro-app/node_modules/@angular/core/fesm2022/core.mjs:32472:16)
      at eval (/workspace/repro-app/node_modules/@angular/platform-server/fesm2022/platform-server.mjs:17111:39)
      at Generator.next (<anonymous>)
      at eval (/workspace/repro-app/.angular/vite-root/repro-app/chunk-VPSODEBW.mjs:64:61)
      at ZoneAwarePromise (/workspace/repro-app/node_modules/zone.js/fesm2015/zone-node.js:1353:21)
      at Module.__async (/workspace/repro-app/.angular/vite-root/repro-app/chunk-VPSODEBW.mjs:48:10)
      at renderModule (/workspace/repro-app/node_modules/@angular/platform-server/fesm2022/platform-server.mjs:17100:50)

Your Environment
_                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/

Angular CLI: 17.1.0
Node: 18.19.0
Package Manager: npm 10.2.3
OS: linux x64

Angular: 17.1.0
... animations, cli, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, platform-server
... router, ssr

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1701.0
@angular-devkit/build-angular   17.1.0
@angular-devkit/core            17.1.0
@angular-devkit/schematics      17.1.0
@schematics/angular             17.1.0
rxjs                            7.8.1
typescript                      5.2.2
zone.js                         0.14.3

Anything else relevant?
Maybe this isn't a supported usage since standalone is default now? Seems like modules should still be fully supported until they're officially deprecated.

The problem is caused because when updated the main.server.ts manually the default export in https://github.com/griest024/ng17-repro/blob/c54b47df03c804f8c39ed290efd930e3e4ff5eb5/src/main.server.ts#L1 has been removed.
You could update it the below if you'd also want to keep the named export.
 export {AppServerModule, AppServerModule as default} from './app/app.server.module';

We should however provide a more actionable error message here.

@alan-agius4 That fixed it! Good call. I definitely support a better error message.


feat(tonic-web): Create enable_with_cors method

Motivation
I've not had any luck using the recommended ways to enable custom CORS for GRPC-web using the recommended mechanisms.
Solution
This helper method is a much easier escape hatch for custom CORS layering.

For the next breaking change, considering making tower and tower-http crates internal dependencies to make tonic project less impactful when updates are made to the dependencies. Can the config be made to be tower_layer::Layer instead of tower_http::cors::CorsLayer?

For the future breaking change, considering making tower and tower-http crates internal dependencies to make tonic project less impactful against the updates of the dependencies. Can the config be made to be tower_layer::Layer instead of tower_http::cors::CorsLayer?