v0.3 on crates.io

Hey, v0.3 doesn't seem to be published on crates.io
https://crates.io/crates/stm32-eth

@thalesfragoso I have invited you to the package owners on crates.io.

@astro Sorry, the invitation got lost in my inbox and it actually expired (I didn't even know that was a thing), could you please send it again ?

Fixed! v0.3.0 has been released on crates.io


Parallelize pre-processing

Right now I parallelize this step by different random number seeds.
Would be nicer to run just cone command with --threads

And update the docs


Update litmuschaos: use JES

Update artifacthub integration to use Job Executor Service. The litmuschaos service can be deprecated.
Signed-off-by: adamgardnerit<EMAIL_ADDRESS>

Christian is completely correct. The files reference locust which I see is already using JES so I'll close this and re-open if / when I'm ready with Litmus using JES. Sorry for the waste of time, no idea what happened here! :(


I Revoke the Rights to My Code

Didn't know you could do this but CONTRIBUTING.md made it clear.
Hehe there was no CONTRIBUTING.md or whitepaper when I was around.
Revert all my commits please.
Oh and don't just copy the code, revert the commit, and then paste it back in.

We can replace your code with additional commits, or you can open a pull request to remove code that you wish to have removed from the project so that your wishes are clearly represented by the request.

Similarly, I personally do not "lie for a living" - these allegations and others like them in your post are defamatory. It is unfortunate that you have chosen to respond to merely being criticized by your colleagues for inappropriate behavior in a way that is violent and immature. That defamatory material will not be permitted on this repository, but we will honor your pull requests or otherwise replace your contributions with code that is higher-quality as represented elsewhere in the project.

Sorry, one more note - there is little basis for you to claim any right to revoke your commits; the license is a shield, not a sword. As you were a collaborator on the project when you contributed and the project is designated with the MIT license, your commits are part of the project and subject to that license. Our efforts to replace your code or otherwise accept a pull request removing it are a show of good faith in response to your outburst, not an admission of ownership or other rights. Team OTG, the Repository, and PG85 retain all rights under the License to utilize contributed code.


Upgrading to 1.0.0-dev.83 cause previously working queries to fail

Expected Behavior
Same behavior between 1.0.0-dev.82 and 1.0.0-dev.83
Actual Behavior
Some requests fail with error like "You cannot use '!=' filters more than once", even in request where there is only isEqualTo where clauses, after updating to 1.0.0-dev.83.
Steps to Reproduce the Problem

Update cloud_firestore_odm from 1.0.0-dev.82 to 1.0.0-dev.83
flutter pub run build_runner build --delete-conflicting-outputs
run app

Specifications

Version: 1.0.0-dev.83 (and cloud_firestore either 4.14.0 or 4.15.4)
Platform: Android

+1

All my where queries return no result

Yep. I replaced all the queries with direct queries. The only dependency I
have is now on model objects.
On Wed, Feb 21, 2024 at 4:56 PM Dor Klein @.***> wrote:

All my where queries return no result
—
Reply to this email directly, view it on GitHub
https://github.com/FirebaseExtended/firestoreodm-flutter/issues/7#issuecomment-1956445140,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAQ4MLQBIPSUUMFNXPG7YH3YUXKXFAVCNFSM6AAAAABDCV466OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJWGQ2DKMJUGA
.
You are receiving this because you commented.Message ID:
@.***>

Same here. All get queries using any kind of .where now fail.
final configs = await configurationRef
          .whereCreatedBy(isEqualTo: userId)
          .wherePartNumber(isEqualTo: partNumber)
          .whereDeleted(isEqualTo: false)
          .get();

Switching to direct queries works

@rrousselGit This looks to be a pretty nasty bug. Do you have some free time to take a look? It might be related to the recent isEqual change.

I can confirm this behavior.
Turning on debug logging for cloud_firestore shows why the odm queries dont return results.
In my case the generated query with where clause is containing duplicated query fields with each a valid value and a null value using the AND operator. This is not limited to only to isEqual.
Duplicated query fields with null in bold below.

(24.10.1) [QueryEngine]: Using full collection scan to execute query: Query(target=Query(test_collection where created_by==X3xty1MuGBhb951AQ27p54WIU9p2 and created_by==null and is_completed==true and is_completed==null and expires_date>=time(1708821339,589398000) and expires_date!=null order by expires_date, name);limitType=LIMIT_TO_FIRST)

I have created a sample project you can use to reproduce this, if that helps.
https://github.com/urbanmania/test_project
If you run it as is you will get the error.
If you comment out this line the error is gone (but also the access control) https://github.com/urbanmania/test_project/blob/0931902c0feb202212a792f9cffe33d74363cd85/lib/main_list_view.dart#L15
It is not the first time I've seen this error, previously it broke and then magically got fixed but broke again with the latest update.

It appears no maintainer is actively watching this project anymore since the transfer ...
While beeing under firebase/flutterfire there was at least some kind of action.
To me it looks like an abandoned project.

It isn't abandoned by any means. It's not receiving any more or less updates than before.
The previous "weekly release" was just an automatic one made when Firebase was released – bumping side-packages alongside it.
Now that it's in a separate repo, the automatic release doesn't happen anymore, that's all.
There's no real bug here. It's because your ODM version is higher than your Firestore version. You use firestore <4.15.0, but the latest ODM.
I'll bump the minimum Firestore version necessary to fix – and fix a bug specific to arrayContains. But otherwise, it's working well.

@rrousselGit my ODM version is not higher than my firestore version; as written in the initial issue, I produce the bug with cloud_firestore version 4.15.4.
I tested again with:
cloud_firestore_odm: 1.0.0-dev.83
cloud_firestore: 4.15.6
and:
cloud_firestore_odm: 1.0.0-dev.84
cloud_firestore: 4.15.6
The bug is still there.

You're right, there is a separate issue specifically with how the ODM passes isNull. I'll fix it

I confirm it's fixed, thank you @rrousselGit.
As a side note, I don't know if it's intended but there is a discrepancy of version between cloud_firestore_odm which stayed 1.0.0-dev.84 while cloud_firestore_odm_generator have been pushed to 1.0.0-dev.85.

Confirming this issue is fixed ! Thx @rrousselGit !

Not quite sure why, but this isn't fixed for us.
Downgrading to 82 helps, but 84 isn't working.
Some sample code:
SomeCollectionReference(firestore)
      .whereFieldPath(FieldPath(const ["creator"]), isEqualTo: uid)
      .snapshots()

SomeCollectionReference(firestore)
      .whereCreator(isEqualTo: uid)
      .snapshots()

Both of these stopped working, creator is a string field.

@ciriousjoker dev version 84 of generator is flawed, you have to use the 85.
In my pubspeck.yaml:
cloud_firestore_odm: 1.0.0-dev.84
cloud_firestore_odm_generator: 1.0.0-dev.85

After upgrading and flutter pub get I just run flutter pub run build_runner build --delete-conflicting-outputs and it was all good.

@gmarizy ah yes thanks! Forgot to regenerate the files after updating. Now it's working!


xds rate limit: fixing lower bound for xDS rate limiting

Commit Message: xds rate limit: fixing lower bound for xDS rate limiting
Additional Description:
Current fill_rate must be above 0.0 (PGV constraint).
However, a low double value can cause an infinite value when computing 1/fill_rate and its cast to uint64_t fails.
This PR changes the minimal fill_rate to be once-per-year, and if a lower value is given, it is overridden and set to once-per-year.
Alternatives considered: changing the PGV value to 3.1709792e-8 (once-per-year).
Risk Level: Low - minor change in behavior
Testing: Added fuzz test case
Docs Changes: Updated API comments
Release Notes:  Added.
Platform Specific Features: N/A
Fixes fuzz bug 60974

Needs main merge due to conflict
@adisuissa

/retest for the problem hopefully fixed in #28876

/retest

/unassign @markdroth
Assigning Harvey for API review (and feel free to push back if you think a different solution should be done here)
/assign @htuch

/retest


Use SSLParameters#setEndpointIdentificationAlgorithm

See https://android-review.googlesource.com/#/c/243503

Duplicates https://github.com/square/okhttp/issues/2672


ernemq on RaspberryPi Unable to copy from /home/pi/vernemq/_build/default/bin/cuttlefish to /home/pi/vernemq/_build/rpi32/rel/vernemq/erts-9.2/bin/cuttlefish because of {copy_failed,enoent}

VerneMQ Version: not shure I install with this command:
time sh -c "$(curl -sSL https://raw.githubusercontent.com/suiluj/pi-adhoc-mqtt-cluster/master/install_scripts/vernemqinstall.txt)"

OS: raspbedian 4.14.98-v7+

Try to isntall on raspberry using command:
time sh -c "$(curl -sSL https://raw.githubusercontent.com/suiluj/pi-adhoc-mqtt-cluster/master/install_scripts/vernemqinstall.txt)"
Install fail with:
===> Unable to copy from /home/pi/vernemq/_build/default/bin/cuttlefish to /home/pi/vernemq/_build/rpi32/rel/vernemq/erts-9.2/bin/cuttlefish because of {copy_failed,enoent}
Makefile:56: recipe for target 'rel' failed
make: *** [rel] Error 127

Hi,
please try to simple clone and do a make rpi32 on the rpi. The recipe in that script is old.
Good luck!


[Bug]: Support S3 for crating paimon catalog

What happened?

Storage type only have Hadoop for paimon format
Affects Versions
master/0.6.0
What engines are you seeing the problem on?
AMS
How to reproduce
No response
Relevant log output
No response
Anything else
No response
Are you willing to submit a PR?

[ ] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

I think there should be support for a custom storage type that doesn't require filling in, because in addition to S3, there are also other storage options like Alibaba Cloud OSS.


Allow animation clips to animate arbitrary properties.

Currently, Bevy restricts animation clips to animating Transform::translation, Transform::rotation, Transform::scale, or MorphWeights, which correspond to the properties that glTF can animate. This is insufficient for many use cases such as animating UI, as the UI layout systems expect to have exclusive control over UI elements' Transforms and therefore the Style properties must be animated instead.
This commit fixes this, allowing for AnimationClips to animate arbitrary properties. The Keyframes structure has been turned into a low-level trait that can be implemented to achieve arbitrary animation behavior. Along with Keyframes, this patch adds a higher-level trait, AnimatableProperty, that simplifies the task of animating single interpolable properties. Built-in Keyframes implementations exist for translation, rotation, scale, and morph weights. For the most part, you can migrate by simply changing your code from
Keyframes::Translation(...) to TranslationKeyframes(...), and likewise for rotation, scale, and morph weights.
An example AnimatableProperty implementation for the font size of a text section follows:
 #[derive(Reflect)]
 struct FontSizeProperty;

 impl AnimatableProperty for FontSizeProperty {
     type Component = Text;
     type Property = f32;
     fn get_mut(component: &mut Self::Component) -> Option<&mut Self::Property> {
         Some(&mut component.sections.get_mut(0)?.style.font_size)
     }
 }

In order to keep this patch relatively small, this patch doesn't include an implementation of AnimatableProperty on top of the reflection system. That can be a follow-up.
This patch builds on top of the new EntityMutExcept<> type in order to widen the AnimationTarget query to include write access to all components. Because EntityMutExcept<> has some performance overhead over an explicit query, we continue to explicitly query Transform in order to avoid regressing the performance of skeletal animation, such as the many_foxes benchmark. I've measured the performance of that benchmark and have found no significant regressions.
A new example, animated_ui, has been added. This example shows how to use Bevy's built-in animation infrastructure to animate font size and color, which wasn't possible before this patch.
Showcase
https://github.com/user-attachments/assets/1fa73492-a9ce-405a-a8f2-4aacd7f6dc97
Migration Guide

Animation keyframes are now an extensible trait, not an enum. Replace Keyframes::Translation(...), Keyframes::Scale(...), Keyframes::Rotation(...), and Keyframes::Weights(...) with Box::new(TranslationKeyframes(...)), Box::new(ScaleKeyframes(...)), Box::new(RotationKeyframes(...)), and Box::new(MorphWeightsKeyframes(...)) respectively.

Comments addressed.

Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to https://github.com/bevyengine/bevy-website/issues/1692 if you'd like to help out.


Add example for Arduino MKR WAN 1310

Hi Nathan, could you tell more about kind of example you are looking for? What is the use case you are looking at?

I'm looking for an example to use the Arduino MKR WAN 1310 to send agriculture sensor data to AWS IoT core using LoRaWAN with BasicStation Rg1xx Gateway.

Hi Nathan, a first step in build the solution you a looking for is an implementation on the device side. This is indenpendent for used LoRaWAN network server and also typically independent from the used gateway. Once you have finished this this implementation, please let me know the format of the binary payload for agriculture sensor data you intend to use.
I will be happy to support you ingesting this data to AWS IoT Core for LoRaWAN (once the format is known).
Let me know if you have any questions

Hi Nathan, kindly ask you to react to my last message, if the issue is still relevant.


Back to static dispatch

This allows to run CPGs through ocular completely now.
Dynamic dispatch is TODO.
Also we are not allowed to remove method stubs as they might be required for typedecl bindings / refs.

E.g., this query runs now smoothly: https://github.com/ShiftLeftSecurity/codepropertygraph/issues/1361#issuecomment-901111179


Annotate algorithm parameters with more specific KISAO terms

CVODES, IDAS

KISAO_0000243: Flag to activate stability limit detection

Tentatively replaced with KISAO_0000543 (pending KISAO approval)

Done

Done


brew cleanup reports false warning

brew doctor output
❯ brew doctor
Your system is ready to brew.

Verification

[X] My "brew doctor output" above says Your system is ready to brew. and am still able to reproduce my issue.
[X] I ran brew update twice and am still able to reproduce my issue.
[X] This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

brew config output
❯ brew config
HOMEBREW_VERSION: 3.6.20-189-g3af2f0e
ORIGIN: https://github.com/Homebrew/brew
HEAD: 3af2f0ececc848bca34ddbd5b876d20dc24a6aaa
Last commit: 13 hours ago
Core tap origin: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 9d2fca0f48c1a7966a141aad47456dfb92bc934c
Core tap last commit: 10 days ago
Core tap branch: master
Core tap JSON: 03 Feb 13:25
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_DISPLAY: /private/tmp/com.apple.launchd.BacqqVunfU/org.xquartz:0
HOMEBREW_EDITOR: /usr/local/bin/mate -w
HOMEBREW_MAKE_JOBS: 10
HOMEBREW_NO_INSTALL_CLEANUP: set
Homebrew Ruby: 2.6.10 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: 10-core 64-bit arm_firestorm_icestorm
Clang: 14.0.0 build 1400
Git: 2.39.1 => /opt/homebrew/bin/git
Curl: 7.86.0 => /usr/bin/curl
macOS: 13.2-arm64
CLT: <IP_ADDRESS>.1.1668646533
Xcode: 14.2
Rosetta 2: false

What were you trying to do (and why)?
Running brew cleanup to cleanup old versions and caches.
What happened (include all command output)?
❯ brew cleanup
Warning: Skipping aom: most recent version 3.5.0_1 not installed
Warning: Skipping apr: most recent version 1.7.0_3 not installed
Warning: Skipping apr-util: most recent version 1.6.1_4 not installed
Warning: Skipping c-ares: most recent version 1.18.1_1 not installed
Warning: Skipping chezmoi: most recent version 2.29.3 not installed
Warning: Skipping deno: most recent version 1.29.4 not installed
Warning: Skipping dust: most recent version 0.8.3 not installed
Warning: Skipping erlang: most recent version 25.2 not installed
Warning: Skipping ffmpeg: most recent version 5.1.2_3 not installed
Warning: Skipping fontconfig: most recent version 2.14.1 not installed
Warning: Skipping fzf: most recent version 0.36.0 not installed
Warning: Skipping gmime: most recent version 3.2.7 not installed
Warning: Skipping graphicsmagick: most recent version 1.3.40 not installed
Warning: Skipping guile: most recent version 3.0.8_4 not installed
Warning: Skipping imagemagick: most recent version 7.1.0-58 not installed
Warning: Skipping ipython: most recent version 8.8.0 not installed
Warning: Skipping jpeg-xl: most recent version 0.7.0_1 not installed
Warning: Skipping jupyterlab: most recent version 3.4.8_1 not installed
Warning: Skipping libde265: most recent version 1.0.9 not installed
Warning: Skipping libheif: most recent version 1.14.2 not installed
Warning: Skipping mu: most recent version 1.8.13 not installed
Warning: Skipping node: most recent version 19.4.0_1 not installed
Warning: Skipping openjdk: most recent version 19.0.1 not installed
Warning: Skipping pandoc: most recent version 2.19.2 not installed
Warning: Skipping ruby-build: most recent version 20221225 not installed
Warning: Skipping rust-analyzer: most recent version 2023-01-23 not installed
Warning: Skipping sbcl: most recent version 2.3.0 not installed
Warning: Skipping swi-prolog: most recent version 9.0.3 not installed
Warning: Skipping tmux: most recent version 3.3a not installed
Warning: Skipping vim: most recent version 9.0.1200 not installed

What did you expect to happen?
The reported "most recent versions" are actually outdated and should be cleaned without warning.
e.g. I confirm like that:
❯ brew upgrade aom
Warning: aom 3.5.0_2 already installed

Noted that the warnings above says:
 Warning: Skipping aom: most recent version 3.5.0_1 not installed

which is an obvious mistake.
Step-by-step reproduction instructions (by running brew commands)
`brew cleanup` after several update and upgrade ops.

What's the output of brew info aom?

❯ brew info aom
==> aom: stable 3.5.0 (bottled)
Codec library for encoding and decoding AV1 video streams
https://aomedia.googlesource.com/aom
/opt/homebrew/Cellar/aom/3.5.0_2 (23 files, 8.5MB) *
  Poured from bottle using the formulae.brew.sh API on 2023-01-26 at 22:26:26
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/aom.rb
License: BSD-2-Clause
==> Dependencies
Build: cmake ✔, pkg-config ✔
Required: jpeg-xl ✘, libvmaf ✔
==> Analytics
install: 326,709 (30 days), 762,857 (90 days), 3,333,940 (365 days)
install-on-request: 30,208 (30 days), 57,954 (90 days), 145,162 (365 days)
build-error: 70 (30 days)

I guess my local version info out-of-sync somewhere, especially the part which inferences brew cleanup command. So I wonder which version data brew cleanup is using actually?

Can you produce the output of running brew outdated; brew outdated; brew upgrade; brew upgrade; brew cleanup; brew cleanup (yes, run each of them twice).
Thanks!

Got the same happening here
❯ brew outdated; brew outdated; brew upgrade; brew upgrade; brew cleanup; brew cleanup
Warning: Skipping aom: most recent version 3.5.0_1 not installed
Warning: Skipping argocd: most recent version 2.5.7 not installed
Warning: Skipping c-ares: most recent version 1.18.1_1 not installed
Warning: Skipping checkov: most recent version 2.2.285 not installed
Warning: Skipping circleci: most recent version 0.1.23241 not installed
Warning: Skipping docker-buildx: most recent version 0.10.0 not installed
Warning: Skipping fontconfig: most recent version 2.14.1 not installed
Warning: Skipping gh: most recent version 2.21.2 not installed
Warning: Skipping guile: most recent version 3.0.8_4 not installed
Warning: Skipping jpeg-turbo: most recent version 2.1.4 not installed
Warning: Skipping jpeg-xl: most recent version 0.7.0_1 not installed
Warning: Skipping micronaut: most recent version 3.8.2 not installed
Warning: Skipping openjdk: most recent version 19.0.1 not installed
Warning: Skipping pnpm: most recent version 7.26.0 not installed
Warning: Skipping sdl2_image: most recent version 2.6.2_1 not installed
Warning: Skipping aom: most recent version 3.5.0_1 not installed
Warning: Skipping argocd: most recent version 2.5.7 not installed
Warning: Skipping c-ares: most recent version 1.18.1_1 not installed
Warning: Skipping checkov: most recent version 2.2.285 not installed
Warning: Skipping circleci: most recent version 0.1.23241 not installed
Warning: Skipping docker-buildx: most recent version 0.10.0 not installed
Warning: Skipping fontconfig: most recent version 2.14.1 not installed
Warning: Skipping gh: most recent version 2.21.2 not installed
Warning: Skipping guile: most recent version 3.0.8_4 not installed
Warning: Skipping jpeg-turbo: most recent version 2.1.4 not installed
Warning: Skipping jpeg-xl: most recent version 0.7.0_1 not installed
Warning: Skipping micronaut: most recent version 3.8.2 not installed
Warning: Skipping openjdk: most recent version 19.0.1 not installed
Warning: Skipping pnpm: most recent version 7.26.0 not installed
Warning: Skipping sdl2_image: most recent version 2.6.2_1 not installed

Didn't help.

@csainty can I see your brew config and brew doctor too, thanks.

This is happening to me as well, and one thing I noticed is that the homebrew-core repository is now out of sync. This happens on every machine that I have homebrew installed.
I am unsure what change occurred in the brew tool that caused homebrew-core to go out of sync. One interesting thing is that running brew update --verbose shows that homebrew-core is up to date, when it is not.
➜ brew update --verbose
Checking if we need to fetch /usr/local/Homebrew...
Checking if we need to fetch /usr/local/Homebrew/Library/Taps/homebrew/homebrew-aliases...
Checking if we need to fetch /usr/local/Homebrew/Library/Taps/homebrew/homebrew-autoupdate...
Checking if we need to fetch /usr/local/Homebrew/Library/Taps/homebrew/homebrew-bundle...
Checking if we need to fetch /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask...
Checking if we need to fetch /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask-drivers...
Checking if we need to fetch /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask-fonts...
Checking if we need to fetch /usr/local/Homebrew/Library/Taps/homebrew/homebrew-cask-versions...
Checking if we need to fetch /usr/local/Homebrew/Library/Taps/homebrew/homebrew-command-not-found...
Checking if we need to fetch /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core...
Checking if we need to fetch /usr/local/Homebrew/Library/Taps/homebrew/homebrew-services...
Checking if we need to fetch /usr/local/Homebrew/Library/Taps/homebrew/homebrew-test-bot...
Already up-to-date.

The immediate fix was to pull latest changes on homebrew-core.
➜cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core
➜ git status
On branch master
Your branch is behind 'origin/master' by 1558 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

nothing to commit, working tree clean
➜git pull

As a followup, the last commit in homebrew-core before getting out of sync is this:
commit c21b2c69a048732cf8b9507dfebd5b94ee6a7d0f (HEAD -> master)
Author: Rui Chen<EMAIL_ADDRESS>Date:   Tue Jan 24 15:43:00 2023 +0000

    gnome-themes-extra: add 3.28 bottle.

This is happening to me as well, and one thing I noticed is that the homebrew-core repository is now out of sync. This happens on every machine that I have homebrew installed.

It is expected that homebrew-core is out of sync. It should no longer be necessary to have on your machine.

This is happening to me as well, and one thing I noticed is that the homebrew-core repository is now out of sync. This happens on every machine that I have homebrew installed.

It is expected that homebrew-core is out of sync. It should no longer be necessary to have on your machine.

Does this mean we can just untap homebrew-core and delete that repository?

@MikeMcQuaid

@csainty can I see your brew config and brew doctor too, thanks.

❯ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Some installed formulae are missing dependencies.
You should `brew install` the missing dependencies:
  brew install kubernetes-cli

Run `brew missing` for more details.

❯ brew config
HOMEBREW_VERSION: 3.6.20-189-g3af2f0e
ORIGIN: https://github.com/Homebrew/brew
HEAD: 3af2f0ececc848bca34ddbd5b876d20dc24a6aaa
Last commit: 15 hours ago
Core tap origin: https://github.com/Homebrew/homebrew-core
Core tap HEAD: c52df68eb53a8ca314bf4577167c77043281fb91
Core tap last commit: 9 days ago
Core tap branch: master
Core tap JSON: 03 Feb 18:21
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 10
Homebrew Ruby: 2.6.10 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: 10-core 64-bit arm_firestorm_icestorm
Clang: 14.0.0 build 1400
Git: 2.39.1 => /opt/homebrew/bin/git
Curl: 7.85.0 => /usr/bin/curl
macOS: 13.1-arm64
CLT: <IP_ADDRESS>.1.1668646533
Xcode: N/A
Rosetta 2: false

Eventually, yes. For now: set export HOMEBREW_NO_INSTALL_FROM_API=1.

Eventually, yes. For now: set export HOMEBREW_NO_INSTALL_FROM_API=1.

Thanks for the remedy.

Can confirm that HOMEBREW_NO_INSTALL_FROM_API fixed things here too

The issue disappears today. Don't know why.

@neolee I've deployed a few fixes here so think I may have addressed this. Thanks for reporting back!

@MikeMcQuaid Great! The speed is amazing 👍🏻


Add support for generating Brazilian phone numbers

I defined the language name as pt-BR according to navigator.language.
My reference for Brazilian numbers was:

https://en.wikipedia.org/wiki/List_of_dialling_codes_in_Brazil
http://www.teleco.com.br/num.asp (portuguese)

Changes Unknown when pulling 542b0a383933bd720445d9dbb61b9f7f15a1619c on patrickporto:develop into ** on chancejs:master**.


CrossConnectivity.Current.IsReachable always returns False on Android device

Please fill out either the bug or feature request section and remove whatever section you are not using.
Bug
statement = await CrossConnectivity.Current.IsReachable("http://www.google.com",5000);
always returns false on android side, iOS wise it's working perfectly. I tried with just google.com and www.google.com and any URL format that was coming into my head, nothing helped.
Version Number of Plugin: 2.2.12
Device Tested On: Samsung GT-P5210
Simulator Tested On:
Expected Behavior
Returns true because my device can access google.com
Actual Behavior
Returns false
Steps to reproduce the Behavior
Use it in PCL and try it on android device
Feature Request:
Please fill in what you would like
To be working I guess !

You need to use IsRemoteReachable:
 var status = await CrossConnectivity.Current.IsRemoteReachable("google.com");

IsReachable is for host names/ip addresses.

Hi @jamesmontemagno
Does it only work to query main domain or can we query specific action. For example, I want to check a slow get action of my webservice   because if it times out, i want show user that his connection is slow.
Something like below. because usually pinging and api is faster than a function in api. Thanks for your help.
                if (await current.IsRemoteReachable("https://mywebservice.azurewebsites.net/api/getItems/en")==false)

Not sure if the last question was answered. I have the same question. Thank you

So, the version 4.0 isn't available in Nuget ATM?

https://www.nuget.org/packages/Xam.Plugin.Connectivity/4.0.0-beta139


Resolve the weird RT=DATA vs RT= thing?

They are the same record type when - always? When is it safe to assume that?
Example from the ASEG page (Example_GroundMag_HillValley_1985). See lines 2 and 3 of the .dfn file:
DEFN   ST=RECD,RT=PROJ; RT: A4
DEFN 1 ST=RECD,RT=DATA;RT:A4;FLTLINE:F10.1:NAME=Line number
DEFN 2 ST=RECD,RT=;time:F10.2:NULL=-99999.99:NAME=time
DEFN 3 ST=RECD,RT=;EAST:F10.2:NULL=-99999.99:UNIT=m:NAME=Easting
DEFN 4 ST=RECD,RT=;NORTH:F10.2:NULL=-99999.99:UNIT=m:NAME=Northing
DEFN 5 ST=RECD,RT=;elevation:I10:NULL=-99999999:UNIT=m:NAME=elevation
DEFN 6 ST=RECD,RT=;Mag_raw:F10.2:NULL=-99999.99:UNIT=nT:NAME=Mag_raw
DEFN 7 ST=RECD,RT=;Mag_corr:F10.2:NULL=-99999.99:UNIT=nT:NAME=Mag_corr
DEFN 8 ST=RECD,RT=;Mag_corr_edit:F10.2:NULL=-99999.99:UNIT=nT:NAME=Mag_corr_edit
DEFN 9 ST=RECD,RT=;Mag_filt:F10.2:NULL=-99999.99:UNIT=nT:NAME=Mag_filt
DEFN 10 ST=RECD,RT=;Mag_lock:I10:NULL=-99999999:UNIT=nT:NAME=Mag_lock
DEFN 11 ST=RECD,RT=;Mag_mlev:F10.1:NULL=-999999.9:UNIT=nT:NAME=Mag_mlev
DEFN 12 ST=RECD,RT=;Mag_nfilt:F10.2:NULL=-99999.99:UNIT=nT:NAME=Mag_nfilt
DEFN 13 ST=RECD,RT=;num_sats:I10:NULL=-99999999:NAME=num_satellites
DEFN 14 ST=RECD,RT=;END DEFN

.dat file:
49390    151932    249393.84    6173429.07    651    57382.85    57713       57713       57712.56    1    57718.8    57713       9
49390    151933    249393.78    6173429.03    651    57382.85    57712.99    57712.99    57714.18    1    57719.7    57712.99    9
49390    151934    249393.52    6173429.17    651    57387.65    57717.79    57717.79    57717.67    1    57720.7    57717.79    9
49390    151935    249393.39    6173429.59    651    57391.95    57722.08    57722.08    57721.74    1    57724.1    57722.08    9
49390    151936    249393.17    6173430.03    651    57395.53    57725.66    57725.66    57724.63    1    57725.2    57725.66    9
49390    151937    249392.93    6173430.45    651    57400       57730.12    57730.12    57725.68    1    57723.7    57724.87    9
49390    151938    249392.87    6173431.03    651    57393.25    57723.37    57723.37    57725.42    1    57722.9    57724.92    9

Seems contradictory to the appendix in the standard, which gives an example where all the data has RT=DATA, followed by a different example where all the data has RT=.

[name] is defined as optional but this can be true for only one record type. This flexibility
was added to make it easy for companies to comply with the standard when a large file of
airborne geophysical data had been written as a multi-column file with no record identifier.
DEFN 1 ST=RECD,RT=; LINE: I6: NAME=Flight Line
The example above contains the first DEFN record in a DFN file that describes data from an
airborne geophysical survey where "RT=" indicates that a record type identifier is not
required. When reading a file of this type, it is important that the input data file does not
have records that commence with names that could be equivalent to another record type.
Note that the RT field format (RT:A4) is omitted in this case.

This is currently dealt with using
>>> gdf = aseg_gdf2.read(..., join_null_data_rts=True)

If True then RT=DATA is treated internally as null RT=.


Checkbox to toggle debug/demo modes

Previously we were showing all concepts in the webapp bc it's primarily a debug tool.  But, when we demo, it begs the question "Why are you getting that???"
So -- now this is optional.
I also added a constraint to require that a concept must contain something besides just a VBN (helps prevent "adjectivey" only concepts)
Minor change:

I rearranged the order of some methods in HomeController, and to make things semantically cleaner I swapped the polarity of the boolean for filtering CAG relevant in the EidosSystem extractFromText method

closes #375

well, once the tests pass

It seems to work even on my computer.


feat: remove gatsby client paths plugin

Checklist:

[X] I have read and followed the contribution guidelines.
[X] I have read and followed the how to open a pull request guide.
[X] My pull request targets the main branch of freeCodeCamp.
[X] I have tested these changes either locally on my machine, or GitPod.

Closes #56632

I was missing information when I created my initial issue. The core curriculum still works. I am still concerned about the following paths.
   '/certification/*',
          '/unsubscribed/*',
          '/user/*',
          '/settings/*',
          '/n/*'

But I was able to see the development user page and the settings and the unsubscribed page. The only confusing one was the n page.

for some reason some e2e tests is failing...

Of course it wasn't going to be that easy.

I checked the pr at gitpod, didn't notice any broken screens...

The unsubscribe page with the IDs is broken.

Okay this should bring back the unsubscribe page

looks like the unsubscribed ID problem wasnt the reason for e2e fail (or not the only reason)

I don't think this needed closing, see https://github.com/freeCodeCamp/freeCodeCamp/issues/56632#issuecomment-2464119189

If i understand correctly the situation -  the ci is fails after the change...  am i right?

The Continuous Integration is failing because my port of the certification path won't build.

may be the change is too radical and can be split to smaller parts...


pm2 reload

Is there a way to notify on a reload? Either from pm2 reload or due to the --max-memory-restart flag?

I am listening for all the events that pm2 provides to modules. Please review the options in the README for the events that you can subscribe to.

Well I have it set to the defaults with restart: true and error: false and I thought it would log reload due to restart but it does not. The options in the readme do not state reload. And I can't find docs for the events, do you have any clues?

Did some testing and there is a reload event that is fire that is undocumented by PM2. I have added the documentation to pm2-slack. Just set:
pm2 set pm2-slack:reload true
to turn it on.

@mattpker thanks a ton! 🎉


use gcp in trace command instead of aws

Description of your changes

Fixes #
I have: updated the example trace command to refer to gcp instead of aws

[x] Read and followed Upbound's contribution process.
[ ] Run make reviewable to ensure this PR is ready for review.
[ ] Added backport release-x.y labels to auto-backport this PR, as appropriate.

How has this code been tested
Manually previewed readme markdown.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Change default Type from int(11) to int

The (11) in int(11) is only used to denote display length, not the stored length - https://stackoverflow.com/a/27519793.  It's used for things that probably aren't used a whole lots like ZEROFILL.  Stored length is altered by using different types such as smallint
MySQL 8.0.17 deprecated ZEROFILL - https://dev.mysql.com/doc/refman/8.0/en/numeric-type-attributes.html
The default width for int is 11 - https://dev.mysql.com/doc/refman/8.0/en/integer-types.html - minimum value is -2147483648 which is 10 characters + 1 character for the negative sign.
Read more about numeric-type syntax - https://dev.mysql.com/doc/refman/8.0/en/numeric-type-syntax.html
framework 4.11 defaults to int(11), though it is persisted differently in MySQL 5.7 and MySQL 8
describe Page;
MySQL 5.7
+----------+---------+------+-----+---------+----------------+
| Field    | Type    | Null | Key | Default | Extra          |
+----------+---------+------+-----+---------+----------------+
| ID       | int(11) | NO   | PRI | NULL    | auto_increment |
| MyFileID | int(11) | NO   | MUL | 0       |                |
+----------+---------+------+-----+---------+----------------+

MySQL 8
+----------+------+------+-----+---------+----------------+
| Field    | Type | Null | Key | Default | Extra          |
+----------+------+------+-----+---------+----------------+
| ID       | int  | NO   | PRI | NULL    | auto_increment |
| MyFileID | int  | NO   | MUL | 0       |                |
+----------+------+------+-----+---------+----------------+

Notably, when running dev/build?flush in mysql 8, no matter how many times we do it, we get the following for every ID column in every table:
  + Field ErrorPage.ID: changed to int(11) not null auto_increment (from int not null auto_increment)
It's also likely what' causing this unit test to fail only in MySQL 8
1) SilverStripe\ORM\Tests\DataObjectSchemaGenerationTest::testFieldsDontRerequestChanges Failed asserting that true is false. /home/runner/work/silverstripe-framework/silverstripe-framework/tests/php/ORM/DataObjectSchemaGenerationTest.php:88 /home/runner/work/silverstripe-framework/silverstripe-framework/src/ORM/Connect/DBSchemaManager.php:164 /home/runner/work/silverstripe-framework/silverstripe-framework/tests/php/ORM/DataObjectSchemaGenerationTest.php:89 /home/runner/work/silverstripe-framework/silverstripe-framework/vendor/bin/phpunit:123
https://github.com/silverstripe/silverstripe-framework/runs/7441905051?check_suite_focus=true#step:12:113
Change the default the default for int columns from int(11) to int.  While this should be a safe - we should probably release make this update in either 4.12 or 5.0
ACs

[ ] 4.10 branch is merged up in 4.11
[ ] 4.10 build hacks is removed

PRs

https://github.com/silverstripe/silverstripe-framework/pull/10422

This was already fixed in 4.11 by https://github.com/silverstripe/silverstripe-framework/issues/9453
It's probably not worth backporting to 4.10.

Actually we need to revert a few changes on merge ups to make sure the MySQL8 build runs properly:

https://github.com/silverstripe/silverstripe-framework/pull/10416
https://github.com/silverstripe/silverstripe-framework/pull/10416/files#diff-278c44957454d6787a027732f39ca2527042af063d203a5b31dd0de05961ae31R145

Closing - all actions are complete.


When to release swift4.0 version of the code

When to release swift4.0 version of the code？

https://github.com/Haneke/HanekeSwift/releases/tag/0.11.0

Please reopen this issue as its taking 0.10.0 as by default when I install it. I tried to update it manually, by forcefully giving 0.11.0, It gave me error. Thank you!


Upgrade to lib-sass 3.5.6 with rgba vars support

Really waiting to use the fix from libsass (3.5.6) in reference to rgba and rgb using custom properties aka var.
Thanks in advance

I also need support for color: rgb(var(--my-var)); and such as well. People cannot use my library with Sass because of this.
@jrgcubano how is it known that libsass (3.5.6) will fix this? Also, I don't see a 3.5.6 release of libsass.

Any movement?
It's been more than two months

Yes, as referenced earlier, this security vulnerability exists for libsass, saw that Upgrading to LibSass 4.5.6 #2612 was closed referencing this ticket.

Closing as duplicate of https://github.com/sass/node-sass/issues/2251


Must tap twice to delete a phrase

Describe the bug
The user must tap twice on the trashcan icon to delete a phrase from a category in settings.
To Reproduce

Navigate to Settings > Categories and Phrases > Tap on any category > Edit Phrases
Tap the trash icon once to delete a phrase

Expected behavior
The delete popup shows up immediately
Actual Behavior
Nothing happens until the user taps the trash icon again
Smartphone (please complete the following information):

Device: [e.g. Pixel 4]
OS: [e.g. Android 10]

@cinadia I was not able to reproduce this issue on a variety of emulators & real devices - got any more info on how you found it?

@cinadia I was not able to reproduce this issue on a variety of emulators & real devices - got any more info on how you found it?

Hey! I just tried it out and I also wasn't able to reproduce it. Looks like it may have gotten fixed as a byproduct of some other change. I was previously able to get it on my Android 13 pixel 4


ZWave?

Any support for ZWave devices managed by the ISY?
ID's are in the format ZW_nnn_n on the ISY.
And will the module work with the new eisy?

Any support for ZWave devices managed by the ISY?
ID's are in the format ZW_nnn_n on the ISY.

It's a hacky workaround, but try naming the id's in the graphic like i_ZW001_1 and I think it should work. Eisy and polisy use ZY001_1 if using ZMatter.
I haven't used this module in a few years and don't have any Z-Wave devices so YMMV. I'll update when I can, but in the middle of a big update for automicus/PyISY and Home Assistant.


Improved maintanance of popups visibility

Motivation and context
Resolved #2713
Resolved #2230
How has this been tested?
Manual testing
@dvkruchinin
We need a test to cover this case
Good gif to reproducing: https://user-images.githubusercontent.com/1630974/105646611-0fa2b880-5ea1-11eb-95ea-45a9c214491e.gif
Checklist

[x] I submit my changes into the develop branch
[x] I have added description of my changes into CHANGELOG file
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[x] I have linked related issues (read github docs)
[x] I have increased versions of npm packages if it is necessary (cvat-canvas,
cvat-core, cvat-data and cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.
[x] I have updated the license header for each file (see an example below)

# Copyright (C) 2021 Intel Corporation
#
# SPDX-License-Identifier: MIT

Coverage remained the same at 70.828% when pulling 490a5c73475b392caebece150d373e9a0b40354b on bs/fixed_issue_2713_2230 into 7720a8f6c25af6a5bf4bcb2fa958ca36be6be820 on develop.

We need a test to cover this case

The test will be prepared.


Made responsive for mobile devices

Related Issue
home page was not responsive in mobile devices.
Closes: #244
Description of Changes
i made it responsive for mobile devices by adding  and removing some CSS in home page.

Refactored the home.css to fix the bug.

Checklist:

[x] My code adheres to the established style guidelines of this project.
[x] I have conducted a self-review of my code.
[x] I have included comments in areas that may be difficult to understand.
[ ] I have made corresponding updates to the project documentation.
[x] My changes have not introduced any new warnings.

Screenshots

Original
Updated

![

Resolve Conflicts, tag on discord with pr link.

Resolve Conflicts, tag on discord with pr link.
Hey,I've resolved the conflicts.


Color Input Behaving Weirdly in custom portable text

I am using simpler color input in portable text but it is not working properly i have shared a video of the same please check it also sharing the code of different files
https://jam.dev/c/e90f00b2-68ba-417f-a7b2-d93add43e394
pakage.json

{
  "name": "mediqlogix",
  "version": "0.1.0",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint",
    "postbuild": "next-sitemap"
  },
  "dependencies": {
    "@formfacade/embed-react": "^1.0.1",
    "@next/third-parties": "^14.1.4",
    "@sanity/image-url": "^1.0.2",
    "@sanity/vision": "^3.36.3",
    "@types/react-slick": "^0.23.13",
    "next": "14.1.3",
    "next-sanity": "^7.1.4",
    "next-sitemap": "^4.2.3",
    "react": "^18",
    "react-dom": "^18",
    "react-portable-text": "^0.6.0",
    "react-slick": "^0.30.2",
    "sanity": "^3.36.3",
    "sanity-plugin-simpler-color-input": "^2.2.1",
    "slick-carousel": "^1.8.1",
    "styled-components": "^6.1.8"
  },
  "devDependencies": {
    "@types/node": "^20",
    "@types/react": "^18",
    "@types/react-dom": "^18",
    "autoprefixer": "^10.0.1",
    "eslint": "^8",
    "eslint-config-next": "14.1.3",
    "postcss": "^8",
    "tailwindcss": "^3.3.0",
    "typescript": "^5"
  }
}

Sanity Config File

import { visionTool } from "@sanity/vision";
import { defineConfig } from "sanity";
import { structureTool } from "sanity/structure";

// Go to https://www.sanity.io/docs/api-versioning to learn how API versioning works
import { apiVersion, dataset, projectId } from "./sanity/env";
import { schema } from "./sanity/schema";
import { simplerColorInput } from "sanity-plugin-simpler-color-input";

export default defineConfig({
  basePath: "/studio",
  projectId,
  dataset,
  // Add and edit the content schema in the './sanity/schema' folder
  schema,
  plugins: [
    structureTool(),
    simplerColorInput({
      defaultColorFormat: "hex",
      enableSearch: true,
      defaultColorList: [
        { label: "primary-green", value: "#4ef721" },
        { label: "primary-blue", value: "#4387EA" },
        { label: "primary-black", value: "#333333" },
        { label: "secondary-black", value: "#000000" },
        { label: "secondary-gray", value: "#4ef721" },
      ],
    }),

    visionTool({ defaultApiVersion: apiVersion }),
  ],
});

schema file

import { defineField, defineType } from "sanity";

export default defineType({
  name: "portableText",
  title: "Portable Text",
  type: "object",
  fields: [
    defineField({
      title: "Portable Text",
      name: "portableText",
      type: "array",
      of: [
        {
          type: "block",
          styles: [
            { title: "Normal", value: "normal" },
            { title: "H1", value: "h1" },
            { title: "H2", value: "h2" },
            { title: "H3", value: "h3" },
            { title: "H4", value: "h4" },
            { title: "Quote", value: "blockquote" },
          ],
          lists: [{ title: "Bullet", value: "bullet" }],
          marks: {
            decorators: [
              { title: "Strong", value: "strong" },
              { title: "Emphasis", value: "em" },
            ],
            annotations: [
              {
                title: "URL",
                name: "link",
                type: "object",
                fields: [
                  {
                    title: "URL",
                    name: "href",
                    type: "url",
                  },
                ],
              },
              {
                type: "textColor",
              },
            ],
          },
        },
        {
          type: "image",
          options: { hotspot: true },
          fields: [
            {
              name: "alt",
              type: "string",
              title: "Alternative Text",
            },
          ],
        },
      ],
    }),
  ],
});

Plese help me with issue I have also google it but could not fine any source or reference

Hi @MurtazaKp sorry you're having this issue! Are you getting any console errors?

Hi @AlyssaKirstine I am not getting any console error

Hi @MurtazaKp are you still having this issue on the latest version of the plugin?

No the issue has been resolved thanks for the help

@MurtazaKp That's great to hear. Closing this issue :)


wasm-pack build panics on Installing wasm-bindgen... step

Finished release [optimized] target(s) in 0.08s
[INFO]: License key is set in Cargo.toml but no LICENSE file(s) were found; Please add the LICENSE file(s) to your project directory
[INFO]: Installing wasm-bindgen...
thread 'main' panicked at 'unknown instruction Block(Block { seq: Id { idx: 1 } })', crates/wasm-interpreter/src/lib.rs:367:18
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: wasm_bindgen_wasm_interpreter::Interpreter::call
3: wasm_bindgen_wasm_interpreter::Interpreter::interpret_descriptor
4: wasm_bindgen_cli_support::descriptors::execute
5: wasm_bindgen_cli_support::Bindgen::generate_output
6: wasm_bindgen_cli_support::Bindgen::generate
7: wasm_bindgen::main
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.
Error: Running the wasm-bindgen CLI
Caused by: failed to execute wasm-bindgen: exited with exit status: 101
full command: "/home/niedzwiedz/.cache/.wasm-pack/wasm-bindgen-5f26acfc988649a3/wasm-bindgen" "/home/niedzwiedz/crionis/crio-app/target/wasm32-unknown-unknown/release/editor.wasm" "--out-dir" "/home/niedzwiedz/crionis/crio-app/pkg" "--typescript" "--target" "bundler" "--out-name" "index"
EDIT: https://github.com/rustwasm/wasm-bindgen/blob/629a623adfe27c67a21408c120d3466965575e45/crates/wasm-interpreter/src/lib.rs#L367 this is the line that crashes

I also got panic with wasm-pack new hello-wasm

Please try out v0.12.0 from one of the following ways:

https://github.com/rustwasm/wasm-pack/releases/tag/v0.12.0
https://crates.io/crates/wasm-pack/0.12.0
https://www.npmjs.com/package/wasm-pack/v/0.12.0


Black text displays as white on red background in default dark and several other themes

Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.89.1
OS Version: Windows 10

Steps to Reproduce:

Open the terminal (under the workspace, the one under PROBLEMS OUTPUT DEBUG CONSOLE TERMINAL)
Launch Python3 with py
Run the line I was testing: print('\033[30m\033[41m🭪 All subprocesses were terminated 🭨\033[0m'

In Windows Terminal (app) and with some themes it displays correctly, in VSCode with default dark theme the text is white (should be black due to escape code \033[30m).
The following themes are affected:

2017 Dark
Dark (Visual Studio -- C/C++)
Dark (Visual Studio)
Dark Modern
Dark+
Kimble Dark
Monokai
Monokai Dimmed
Red
Selclouth
etc.

Examples of themes there the coloring is correct:

Solarized Light
Abyss
Solarized Dark
SynthWave '84
Tomorrow Night Blue

This issue seems to originate from an upstream component and is not something VSCode can fix by making a change to our code. As such, I will go ahead and close it. Please try to reproduce in Windows Terminal and report to microsoft/terminal with repro steps.
If you cannot reproduce in Windows Terminal, chances are it's fixed in a later version of Windows. You can read more about how we consume conpty here. Additionally, soon we plan on shipping conpty v2 with VS Code which should bring our behavior in line with Windows Terminal. Thanks for understanding.
/label upstream terminal-conpty windows


Science category, with sub-categories for each discipline

It would be great to be able to use this site to catalog science related open source initiatives across the GC.
Ideally, science category, but as (conditional) mandatory fields.
Please contact me etienne.low-decarie [at] ssc-spc.gc.ca .  I am part of a new team Data Solutions for Science/ Science program and we are exposed to numerous open source projects across the GC in the science .

Do you mean the categories on the current "Code" form https://code.open.canada.ca/en/open-source-codes.html?
That is driven by values from https://www.ungm.org/Public/UNSPSC that are mapped in https://github.com/canada-ca/ore-ero/blob/master/_data/i18n/categories.yml

It does not really matter to us where this information would be captured, just as long as whether the software is scientific in nature and to which discipline/branch it most closely associates would be captured and could be used to filter information so that we can contribute to and leverage this tool for inventory purposes.
To capture if it is or not scientific software, I was thinking of a Science software in the Category list as in https://github.com/canada-ca/ore-ero/blob/master/_data/i18n/categories.yml but now understand this comes from an existing ontology.
I was thinking of an additional variable that is mandatory only for scientific software that would capture scientific discipline.
It would probably make sense to use a GC categorization (e.g. https://www.tpsgc-pwgsc.gc.ca/app-acq/cral-sarc/lgcl-ctgr-eng.html), though this imperfectly captures scientific disciplines.
Wikipedia has a (translated) software categorization https://en.wikipedia.org/wiki/Category:Software_by_type including sub-categorization of Science software https://en.wikipedia.org/wiki/Category:Science_software
Wikipedia also has (translated) a list of branches of science https://en.wikipedia.org/wiki/Branches_of_science#:~:text= The branches of science%2C also referred to,its social and cultural aspects. [1] More  and https://en.wikipedia.org/wiki/Index_of_branches_of_science
Cheers


Warning: connect.session() MemoryStore in production

Sails version:0.12.14
Node version:v6.11.1
NPM version:5.3.0
DB adapter name:sails-mongo
DB adapter version:0.12.2
Operating system:Mac

I am trying to run sails app in production mode,
$ NODE_ENV=production npm start
But getting error/warning:
Warning: connect.session() MemoryStore is not
designed for a production environment, as it will leak
memory, and will not scale past a single process.
I tried with uncommenting the code from session.js file, but after doing this I am unable to call the apis. i.e. unable to run the sails apis.
Please suggest me, the solution to above error.

@sailsbot ok, fixed!

@sailsbot What extra I need to add. At least tell me ??

@sailsbot Ok, fixed!

@sailsbot Ok, fixed!

@sailsbot Ok, fixed!

@sailsbot Ok, fixed!

@sailsbot Ok, fixed!

@sailsbot Ok, fixed!

It is not an error but a warning. Sails will use MemoryStore as its session storage by default. In other words, Sails will save sessions into the memory instead of a database like MySQL, MariaDB or Redis that should be used in production environment (Honestly I don't know if Redis is a database). So what you need to do is changing your session storage to an appropriate database instead of using the default session storage, MemoryStore .
There are some databases you can choose:

MySQL
MariaDB
MongoDB
PostgreSQL
Redis (Memory based database?)

I hope the above info would help you :) .

Hi @vishalbiradar, @Luluno01 is exactly right.  The way to remove this message is to do what it says and not use the memory session store in production!  See the Session docs for an example of how to use Redis as your session store.

@sgress454 , Yes I followed all those steps, but after that apis are not working. Means i am unable to call or execute apis from my sails app.

@vishalbiradar Can you paste in the error you get when trying to lift Sails / execute APIs?


[UX] Recurring expense doesn't have a month selector

When creating recurring expenses, the only way to select 'monthly' is to either decide on 30 or 31 days which isn't accurate. It should probably be done daily, weekly, fortnightly, monthly, yearly with amount selection for each e.g. 1 monthly, 2 monthly/1 year, 2 years, etc.
At the moment for yearly expenses you have to select 365 days as another example, would be nicer to just be 1 Year.
I think this might be throwing out forecasting in the long term, so probably something worthwhile looking at since it will have a profound effect on what you see over a 365 day period.

This is done now - added 'months' to all interval selectors. Let me know of any problems, but I will be testing myself


xen-tools: Update package versions

Pull packages from Alpine 3.12 (too bad liburing only exists in edge)
Signed-off-by: Sergey Temerkhanov<EMAIL_ADDRESS>

Erik, 3.8 is out of support since May https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases so we need to switch to a newer version anyway

Hey @eriknordmark @temerkhanov -- we need to do this (see my email on eve-tsc@) but we need to do this move properly. First of all we need to update our eve-alpine build cache and go from there. I plan to tackle it this week.
In the meantime @temerkhanov -- please let us know what exactly will break in your qemu work if we stay on 3.8 for now.

please let us know what exactly will break in your qemu work if we stay on 3.8 for now.

Everything should be more or less alright with 3.8


BoxShape phases into CapsuleShape

If you stack (and balance) a boxshape ontop of a capsule shape laying on it's side, the box falls into the capsule by quite a bit, being pushed out only to fall in again. Is this a generally known robustness issue?

Looks like when the capsule shape has a large mass anything can go through it

Thanks for reporting this. No, it's not a known issue.
Could you please give me a little bit more information so that I can reproduce the issue ? For instance, what are the size of the shapes, their positions/orientations and the masses of the bodies ?

Full disclosure, I've vendored and made quite a few changes to the library so I'm not sure if it's broken as a result of something I did, going to compare to stock first before investigating further. I didn't change any of the core routines responsible for this though. That being said simple setup that does reproduce my issue is:
// static box shape collider (500, 10, 500) at (0, 0, 0)
auto ground = world->createRigidBody({{0, 0, 0}, Quaternion::identity()});
ground->setType(BodyType::STATIC);
auto box = common.createBoxShape({500.0, 10.0, 500.0});
auto collider1 = ground->addCollider(box, Transform::identity());

// capsule shape (radius=1, height=10), at (0, 10 + 10, 0)
// this also appears like a bug with capsules, their origin seems to be the cylinder's bottom
// rather than the bottom cap itself, adding 10 more here so it doesn't penetrate the ground
auto body = world->createRigidBody({{0.0, 10.0 + 10.0, 0.0}, Quaternion::identity()});
body->setMass(10.0);
auto capsule = common.createCapsuleShape(1.0, 10.0);
auto collider2 = body->addCollider(capsule, Transform::identity());

Here's what I've investigated, when the height of the capsule shape is not too tall, the capsule makes contact with the ground box collider and settles fine, when these values are anything else, the capsule just falls through the ground.
What is strange here is that contact is being made, using the DebugRenderer I can see the contacts where the capsule collides with the box.
I've attached a video:
https://user-images.githubusercontent.com/343195/110394191-011bf500-803a-11eb-888e-1d289cb218fe.mp4

I dunno if this is of any help but setting the mass of the capsule to 1 and radius to 1, it behaves correctly for all height sizes up to exactly 6.5, which is when it begins to penetrate the box and behave weird, height values larger than that is where robustness issues become very evident for me.

Thanks a lot for the details.
It might be an issue in the GJK algorithm used for collision detection between a CapsuleShape and a BoxShape but if the contact is created correctly, it might be something else.
I will try to investigate this.

Thanks for taking the time.
I've done some more investigation and have a finding that may be of interest.
In the function  SATAlgorithm::computeCapsulePolyhedronFaceContactPoints if I remove this conditional so it always evaluates true:
// If the clipped point is one that produce this penetration depth, we keep it
if (clipPointPenDepth > penetrationDepth - capsuleRadius - decimal(0.001)) {

Always adding the contact point, regardless of the penetration depth, it kind of works. It no longer phases through the box shape but it doesn't behave correctly either (the DebugRenderer contact points don't update correctly when the object has some linear velocity, and there's some jerky movements under high velocity, but it doesn't fall through at least.)
I know this is probably the wrong approach, but I'm just trying to understand the whole thing. I'm curious, why does this function not get passed the capsule height anywhere? It only accounts for radius. I don't know the details of these algorithms that well and the codebase has been lovingly commented and I'm learning a lot here, so thanks for such a great resource.
I'm going to keep investigating, thanks again.

Are you testing using the current "master" branch of ReactPhysics3D? If not, can you try with this branch? Do you observe the same result ?
Can I ask you what is the time step value that you use and also the number of iterations for the velocity and position solver?

The contacts are still not updating when under high velocity though and it still fails for very tall capsules.

I am not really sure I understand what you mean here

Using 16ms time steps, so 60fps. I use the default iterations for velocity and position solvers.

I am not really sure I understand what you mean here

The debug contact points (rendered as spheres) do not update when the object is moving fast, they lag behind the true contact points.
This happens in the current master branch, yes.

Actually, I think it might be an issue with the inertia tensor of the rigid body with the capsule shape.
Since you don't call body->updateMassPropertiesFromColliders() on your body after adding the capsule collider, the inertia tensor is not recomputed for a CapsuleShape and therefore not correct. That might be the problem.
Note that calling this method will use the mass density of the material of the rigid body and not the mass that you set with body->setMass(10.0). If you want to set the mass manually, you also need to manually set the inertia tensor using body->setLocalInertiaTensor(inertiaTensorDiag). You can use the CapsuleShape::getLocalInertiaTensor(mass) method to compute the local inertia tensor for a capsule with a given mass.
Let me know if it solves the issue or not.

Have you been able to try this change to see if it solves your issue ?

I am closing this issue. Feel free to reopen it if necessary.


Passing arguments

But how can we pass arguments to the environment?  I am struggling with that. I can do it using EnvContext for the training phase but for the prediction where you used gym.make???
Any tip?

Good question @javimontero ,
Will this help? => https://stackoverflow.com/questions/54259338/how-to-pass-arguments-to-openai-gym-environments-upon-init
The call to gym.make() now takes kwarg parameters
https://github.com/openai/gym/blob/643b648fe20371cd87cd332f374dcf4f172941d5/gym/envs/registration.py#L77


Fail CI builds on compiler warnings + some fixes

This causes the Linux and Mac builds to fail if any compiler warnings are raised during the build. We do this by setting the env var CXXFLAGS="-Wall -Werror". This spares C code, as we don't want to fail due to warnings in thirdparty code like Inchi, Avalon or Yaehmop, and there's too many of them...
Note that different compilers/versions raise different warnings, but any supported gcc or clang version should be able to catch the major issues (plus a bunch of annoying stuff like comparing signed vs unsigned). I'm not enabling -Werror on windows because the MSVC compiler is way too zealous...
Besides enabling the flags, this fixes the warnings that are currently showing up in the builds, so that they don't start failing right after we merge this. And then some mem errors too.

@ricrogz : you ready to have this merged?

Yeah, as long as it builds correctly

Finally!


Support forking repositories with az repos create

Is your feature request related to a problem? Please describe.
For the life of me I can't figure out how to fork a repo using Azure CLI. It seems like forks are supported by the Azure Repos create API, but Azure CLI does not expose that feature.
Describe the solution you'd like
Add additional arguments to az repos create to specify parent repository and refs.
Describe alternatives you've considered
Calling REST API directly.

@nahk-ivanov We are looking into it and get back to you for any additional information.

Route to CXP team

Hello @nahk-ivanov Thanks for the feedback and feature request!
We are sending it to the service team's attention!

@nahk-ivanov , Thank you for the suggestion!
but we are owning only CLI Service and as mentioned it is not supported by the CLI so we need to forward this issue to API team, we are trying to figure out the correct API team then we can redirect this issue.

@msftbot Please redirect issue to the API team


MAINT: Make tests less flaky

Closes #166

[x] Tests pass on my M1 laptop.
[x] Fix logic for mne._fiff import (must check 1.6 before checking 1.5)
[x] Treat warnings as errors as in MNE-Python
[x] Add pre-commit
[x] Enable pre-commit.ci
[x] Enable debug LSL logging (library and MNE-lsl levels)
[x] Change to test-specific Player use in fixtures
[x] Try on my Linux machine to see if I can replicate the failures seen in #166
[ ] Add debug lines before all or most lib calls
[ ] Fix intermittent failures
[ ] Fix segfaults

Okay now the tests fail with at least more verbose information at the MNE-lsl and liblsl levels now, e.g., this one where there is a segfault:
mne_lsl/lsl/tests/test_stream_inlet.py::test_processing_flags[float32-flags0] PASSED
2023-10-20 15:02:55.631 (  62.938s) [            3D80]         udp_server.cpp:35       2| test: Started unicast udp server at port 16572 (addr 0x7f7a4de00018)
2023-10-20 15:02:55.631 (  62.938s) [            3D80]         udp_server.cpp:89       2| test: Started multicast udp server at <IP_ADDRESS> port 16571 (addr 0x7f7a4ddef018)
2023-10-20 15:02:55.631 (  62.938s) [            3D80]         udp_server.cpp:89       2| test: Started multicast udp server at <IP_ADDRESS> port 16571 (addr 0x7f7a4ddcd018)
2023-10-20 15:02:55.631 (  62.938s) [            3D80]         udp_server.cpp:89       2| test: Started multicast udp server at <IP_ADDRESS> port 16571 (addr 0x7f7a4ddab018)
2023-10-20 15:02:55.631 (  62.938s) [            3D80]         udp_server.cpp:89       2| test: Started multicast udp server at <IP_ADDRESS> port 16571 (addr 0x7f7a4bb44018)
2023-10-20 15:02:55.631 (  62.938s) [            3D80]         udp_server.cpp:89       2| test: Started multicast udp server at <IP_ADDRESS> port 16571 (addr 0x7f7a4ddbc018)
2023-10-20 15:02:55.631 (  62.938s) [            3D80] stream_outlet_impl.cpp:77       2| test: Trying to listen at address ''
2023-10-20 15:02:55.631 (  62.938s) [            3D80]         udp_server.cpp:35       2| test: Started unicast udp server at port 16572 (addr 0x7f7a4ddde018)
2023-10-20 15:02:55.631 (  62.938s) [            3D80]         udp_server.cpp:82    WARN| Could not bind multicast responder for ff02:113d:6fdd:2c17:a643:ffe2:1bd1:3cd2 to interface ::1 (Can't assign requested address)
2023-10-20 15:02:55.631 (  62.938s) [            3D80]         udp_server.cpp:89       2| test: Started multicast udp server at ff02:113d:6fdd:2c17:a643:ffe2:1bd1:3cd2 port 16571 (addr 0x7f7a4bb22018)
2023-10-20 15:02:55.632 (  62.938s) [            3D80]         udp_server.cpp:82    WARN| Could not bind multicast responder for ff05:113d:6fdd:2c17:a643:ffe2:1bd1:3cd2 to interface ::1 (Can't assign requested address)
2023-10-20 15:02:55.632 (  62.938s) [            3D80]         udp_server.cpp:89       2| test: Started multicast udp server at ff05:113d:6fdd:2c17:a643:ffe2:1bd1:3cd2 port 16571 (addr 0x7f7a4bb55018)
2023-10-20 15:02:55.632 (  62.938s) [            3D80]         tcp_server.cpp:160      1| Created IPv4 TCP acceptor for test @ port 16577
2023-10-20 15:02:55.632 (  62.938s) [            3D80]         tcp_server.cpp:171      1| Created IPv6 TCP acceptor for test @ port 16577
2023-10-20 15:02:57.830 (  65.136s) [IO_test         ]         tcp_server.cpp:270      1| Destructing session 0x7f7a4e753468
Fatal Python error: Segmentation fault
mne_lsl/lsl/tests/test_stream_inlet.py::test_processing_flags[float32-flags1]

Thread 0x0000000106726600 (most recent call first):
  File 2023-10-20 15:02:58.473 (  65.778s) [R_test          ]      data_receiver.cpp:344    ERR| Stream transmission broke off (Input stream error.); re-connecting...
"/Users/runner/work/mne-lsl/mne-lsl/mne_lsl/lsl/stream_outlet.py", line 83 in __del__
  File "/Users/runner/hostedtoolcache/Python/3.9.18/x64/lib/python3.9/site-packages/_pytest/python.py", line 194 in pytest_pyfunc_call
  File "/Users/runner/hostedtoolcache/Python/3.9.18/x64/lib/python3.9/site-packages/pluggy/_callers.py", line 77 in _multicall

@mscheltienne do you want to look now that there is more information available? There is some logging stuff in there that is suspicious to my untrained eye like the "Stream transmission broke off". Locally running with stuff like pytest mne_lsl -k test_stream_add_reference_channels -sx you can see the output in real time during  the run which is nice.
For now I added -s to the pytest CI run to maybe help diagnose the segfaults. I think to diagnose these we should add more and more logger.debug calls just before LSL lib.whatever calls, e.g. maybe something like lib.lsl_destroy_inlet or lib.lsl_destroy_outlet is trying to free some memory as it's being accessed by some other thread. Knowing which lib calls occur just before the segfault might tell us this.
FYI each test now uses its own Player. This seemed like a cleaner approach to help isolate tests from one another.

Many thanks for looking into it and improving the logging.
I will try to have a look next week and I will let you know how it goes :)

@larsoner Looks like I got rid of the segfaults, the trick was to delete (and thus destroy) the inlet before destroying the outlet. Closing the inlet was not sufficient. This was also the point corresponding to the ERR| Stream transmission broke off (Input stream error.); re-connecting....
Erratum: And of course, as I'm writing this, I'm getting one more segfault in a run, first one in the last 10 CI runs.. It has some warnings about the multicast scope, so let's try to limit it to the local machine in CIs.

I'm still getting the channel selection flakiness described in #166 and this one is completely eluding me. It seems like 2 different failures:

one where an extra-sample is present
one where the last ~70% of the buffer is empty (zeros) -- which makes no sense as the buffer is filled from the right!

I do get them locally as well in pdb but I'm not making any progress... could you have a look as well, a fresh pair of eyes would help :pray: To reproduce, pytest mne_lsl/stream/tests/test_stream_lsl.py --sx --pdb ends up with a failure once in a while..

And it's now working way worst than 2 commits ago.. 😭

@mscheltienne I see you working on this again. Let me know when you're sick of it and hopefully I can look today or tomorrow

For https://github.com/mne-tools/mne-lsl/actions/runs/6865120608/job/18668396515?pr=168 at least it does look like there are some samples dropped:
Samples mismatch, after 2 fetch(es), with deltas:
  Raw: [23] ([-2048.])
  Stream: [23 70] ([-2048.    17.])

I think the player is configured to send 16 samples per chunk, so it looks like an entire chunk was lost?

Yes it seems that way. I don't know much about LSL but maybe there is some way to detect this chunk drop.
But from a practical standpoint would reliability in theory go up if we increased this chunk size to something like 32 or 64 at least for our tests? We could try it and then just pretend this bug does not exist :see_no_evil:

... or is the "player" something you implemented? If it is then we should look to see if there is a bug that needs to be fixed.
Like for example if it's a threaded thing and tries to figure out the next set of data using the current time (instead of just an incrementing counter or whatever) then it could drop if the Python interpreter lock (GIL) causes problems

Yes I want to understand those problems before we pretend they don't exist, e.g. by using a tool to rerun on failures.
I implemented the Player, there might be a bug somewhere; and I'm still a bit puzzled by those dropped samples/packets since LSL implements a buffer at both ends specifically to avoid this kind of issue. I just commented on the LSL Slack, let's see what Chadwick Boulay has to say ;)

I want to understand those problems before we pretend they don't exist

Agreed this would be best, not sure how easy it will be though!

e.g. by using a tool to rerun on failures.

I see how rerunning on failures would help get pytest to return green (just like bumping up the block size might) -- but how do you think it will help us understand the problem?

I implemented the Player, there might be a bug somewhere

Okay to me the next step is to say which sample numbers from the file are being pushed, e.g., logger.debug("PLAYER {name}: Pushing samples {start}:{stop}") just to make sure things are all correct at our end. @mscheltienne feel free to do something like this if you think it makes sense or I can try pushing some commits.

Already got a small piece of information from Chadwick Boulay:

LSL maintains a buffer for each consumer. The data are moved from the buffer into asio which (also buffers) and sends them to the OS. The OS uses TCP to transmit to the receiver.The only way you can drop data is if the OS's TCP protocol fails. If that happens then you have a bigger problem.

Actually, I suppose there's another way you can drop packets... If you set the buffer to be really small and you don't pull frequently enough. The default buffer max is 360-seconds worth of samples.

So it's possible we drop some packets, that could explain:

https://github.com/mne-tools/mne-lsl/actions/runs/6865120608/job/18668396515?pr=168
https://github.com/mne-tools/mne-lsl/actions/runs/6865120608/job/18668396851?pr=168

But not:

https://github.com/mne-tools/mne-lsl/actions/runs/6865120608/job/18668395983?pr=168
https://github.com/mne-tools/mne-lsl/actions/runs/6865120608/job/18668397170?pr=168

More digging required to understand those failures. And no the tools to rerun on failures would be useful if we understand those failures first and if we are convince they are rare/limited to CIs ;)

Anyway, my time is up for today, I will pick it up tomorrow; feel free to push some commits/test some stuff before if you want to!

Okay I'll see if I can push some logging stuff. 360 seconds worth of buffer seems like it should be plenty :confused:

Can you confirm that you're losing samples in between good samples (i.e., not at the beginning or end)?
And that this is not accompanied by logs of the stream breaking off and reconnecting?
If the answer to both is "yes" then the only way I can imagine losing samples is if you're overrunning the outlet buffer and that seems unlikely as long as you're not changing the default max_buffered.
The chunk size offers a tradeoff between CPU usage and latency. A small chunk size has higher CPU usage but lower latency, good for real time apps. A larger chunk size has less CPU usage but longer latency, good for storage apps (LabRecorder).
That being said, I can't get max_chunklen to work how I want. See this old issue: https://github.com/sccn/liblsl/issues/96

Can you confirm that you're losing samples in between good samples (i.e., not at the beginning or end)?

This part we can confirm because we hack in the increasing sample numbers as an EEG channel, and find that for example 70 samples in we get a 17-sample jump when we should get only 1-sample jumps.

And that this is not accompanied by logs of the stream breaking off and reconnecting?

This could be the culprit. Looking at https://github.com/mne-tools/mne-lsl/actions/runs/6865120608/job/18668396515?pr=168#step:9:1217 for example we see:
2023-11-14 14:45:33.212 ( 252.746s) [R_P_test_strea  ]      data_receiver.cpp:344    ERR| Stream transmission broke off (Input stream error.); re-connecting...

Any ideas on what could cause this part?

Let's see if we can summon @tstenner in here who I know has worked on the "Stream transmission broke off" problem in the past. I've encountered it too but I never looked into the origin.

We are using and limiting liblsl to recent version, IIRC, above 1.15 or 1.16, so I don't think we have a protocol mismatch.
In CIs, this Stream transmission broke off message is issued when the outlet is deleted (destroyed) before the inlet, which can happen at teardown sometimes (I thought I eliminated this problem but maybe not).
def test(...):
    outlet = StreamOutlet(...)
    inlet = StreamInlet(...)
    del outlet
    del inlet

Anyway, closing this for today 🙈 Back at it tomorrow ;)

@larsoner , after 4487567 the run only had a couple segfaults.
For a while, we had the same problem: segfaults in macos only, and only on GitHub CI -- we couldn't reproduce locally.
https://github.com/sccn/liblsl/actions
This kind of went away on its own with some other changes. We still have segfaults, but it doesn't seem to be platform specific. They mostly happen during liblsl\testing\ext\bench_pushpull.cpp. This one is a little weird. In one of its parameterizations, it creates a single outlet and quickly creates up to 10 inlets for that outlet. Then it pushes some samples to the outlet and pulls them in each inlet.
https://github.com/sccn/liblsl/blob/master/testing/ext/bench_pushpull.cpp#L29-L53
I hope this was helpful somehow.

Thanks a lot @larsoner; first green run in a long long time :see_no_evil:
I'm not sure how the threading.Lock is helping, could you detail your thought?
The same close_io magic for sphinx-gallery examples would be useful to prevent segfaults in the doc build.
One more CI rerun; still one failure on windows. The surprising part is that this match_stream_and_raw_data failures always occur in a function which adds or remove (pick) channels. They do not occur e.g. in test_stream. To be fair, that's also where 80-90% of the match_stream_and_raw_data are concentrated.. so maybe that's why it only fails those tests and I might have missed a couple of failures in test_stream or other non-pick related tests.

Happy to merge as is and to keep digging for the remaining points separately, that's already a huge improvements.
Do you think we should keep the LSL log level in test default to 2 or maybe do we bring it back to something less verbose and use the variable MNE_LSL_LOG_LEVEL when needed?

Do you think we should keep the LSL log level in test default to 2 or maybe do we bring it back to something less verbose and use the variable MNE_LSL_LOG_LEVEL when needed?

So far I'm happy with the CI output at least. We should probably make the LSL level configurable using an env var. Then we can have a default config for devs (maybe less verbose?) and set the verbosity in CIs however we want. But I'll merge this as-is and feel free to tweak those in a follow-up PR!

Let's see if we can summon @tstenner in here who I know has worked on the "Stream transmission broke off" problem in the past. I've encountered it too but I never looked into the origin.

The three big causes are handshake failures (mainly weird decimal point issues for some europeans) before the first sample, the outlet getting closed before the input and the outlet disappearing before the inlet. The MacOS problems happened (as Chadwick pointed out) mostly in a synthetic benchmark, but only on the CI systems and never on one of my local machines. If anyone manages to get a stack trace or dump, I could investigate this further.

Thanks @cboulay @tstenner We will keep you updated if we get a stack trace or something that helps figuring out the remaining issues :)


bug: Difference in (StatementIdx(97456), Bitwise): Some(2) != Some(0).

Bug Report
Cairo version:
2.4.0-rc3

Current behavior:
Compilation of the following function fails.
fn commit(self: @Account) -> Result<(), EVMError> {
        // The account can be deployed already, but can be `should_deploy` as well if we're deploying on a previously selfdestructed account.
        let is_deployed = self.address().evm.is_deployed();

        // If a Starknet account is already deployed for this evm address, we
        // should "EVM-Deploy" only if the bytecode length is different (!=0) or the nonce is different.
        let should_deploy = if is_deployed {
            let deployed_bytecode_len = ContractAccountTrait::fetch_bytecode_length(self)?;
            let deployed_nonce = ContractAccountTrait::fetch_nonce(self)?;
            if (deployed_bytecode_len != self.bytecode().len() || deployed_nonce != *self.nonce) {
                true
            } else {
                false
            }
        } else {
            // Otherwise, the deploy condition is simply has_code_or_nonce.
            self.should_deploy()
        };

        if should_deploy {
            // If SELFDESTRUCT, deploy empty SN account
            let (initial_nonce, initial_code) = if (*self.selfdestruct == true) {
                (0, Default::default().span())
            } else {
                (*self.nonce, *self.code)
            };
            ContractAccountTrait::deploy(
                self.address().evm,
                initial_nonce,
                initial_code,
                deploy_starknet_contract: !is_deployed
            )?;
            return Result::Ok(());
        //Storage is handled outside of the account and must be commited after all accounts are commited.
        };

        // If the account was not scheduled for deployment - then update it if it's deployed.
        if is_deployed {
            // Only CAs have components commited on starknet.
            if self.is_ca() {
                if *self.selfdestruct {
                    return ContractAccountTrait::selfdestruct(self);
                }
                self.store_nonce(*self.nonce);
            };
            return Result::Ok(());
        };
        return Result::Ok(());
    }

The error message is:
Difference in (StatementIdx(97456), Bitwise): Some(2) != Some(0).
Difference in (StatementIdx(97453), Bitwise): Some(0) != Some(2).
Difference in (StatementIdx(97471), Pedersen): Some(10) != Some(0).
Difference in (StatementIdx(97444), Pedersen): Some(0) != Some(10).
Difference in (StatementIdx(97385), Pedersen): Some(0) != Some(10).
Difference in (StatementIdx(97385), Bitwise): Some(0) != Some(2).
Difference in (StatementIdx(97471), Bitwise): Some(2) != Some(0).
Difference in (StatementIdx(97444), Bitwise): Some(0) != Some(2).
Difference in (StatementIdx(97456), Pedersen): Some(10) != Some(0).
Difference in (StatementIdx(97453), Pedersen): Some(0) != Some(10).
thread 'main' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cairo-lang-sierra-gas-2.4.0-rc3/src/gas_info.rs:73:9:
Comparison failed.
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: cairo_lang_sierra_to_casm::metadata::calc_metadata
   3: cairo_lang_starknet::casm_contract_class::CasmContractClass::from_contract_class
   4: <core::iter::adapters::GenericShunt<I,R> as core::iter::traits::iterator::Iterator>::next
   5: <scarb::compiler::compilers::starknet_contract::StarknetContractCompiler as scarb::compiler::Compiler>::compile
   6: scarb::commands::build::run
   7: scarb::commands::run
   8: scarb::main

The bug manifests when compiling our contracts crate with scarb build -p contracts.
However, it disappears if I comment line 213, with the explicit return in the if should_deploy block commented.
 if should_deploy {
            // If SELFDESTRUCT, deploy empty SN account
            let (initial_nonce, initial_code) = if (*self.selfdestruct == true) {
                (0, Default::default().span())
            } else {
                (*self.nonce, *self.code)
            };
            ContractAccountTrait::deploy(
                self.address().evm,
                initial_nonce,
                initial_code,
                deploy_starknet_contract: !is_deployed
            )?;
            // return Result::Ok(()); commenting this compiles.
        };

Expected behavior:
No unexpected compilation error.

Steps to reproduce:
Clone the Kakarot repository and clone the bugreport/22-11 branch.

Known issue - unfortunately will probably only be fixed in sierra-1.5.0.
It is because the update of gas costs is not in full effect just yet.
In general putting  pedersen and bitwise usages inside a non-inlined function should solve the issue.

In general putting pedersen and bitwise usages inside a non-inlined function should solve the issue.

How can I take action on this?
I just introduced a second if should_deploy branch where I did the return statement, so it's not a blocker anyway.

Linked PR solves the issue.
Will release a new rc when it is merged.


get tydom credentials from Delta Dore

Hi @CyrilP ,
That's awesome; thank you very much!
It will drastically reduce the burden of onboarding new users👍
=> I'm going to review it this week-end

Hi,
I tested your PR with success 👍
You can find my comments above that should improve code quality.
In addition, the documentation should also be enriched about the new available props.
The DELTADORE_LOGIN and DELTADORE_PASSWORD have to be described here in the documentation
And I think they deserve a clear explanation;

explain that DELTADORE credentials are only needed for the TYDOM_PASSWORD resolution
explain that DELTADORE credentials are not required when the TYDOM_PASSWORD is provided
...

Thank you! 👍

I did the requested changes

Thank you very much!
LGTM 👍

Just released as 3.1.0.
(the hass.io addon has been updated to allow passing the deltadore credentials)


Resolve & cache username/display names

Feature Request
We could make the dashboards easier to parse through if the user IDs were resolved to display names and usernames which could be bundled into the metrics.
I'm aware this would come at a significant API quota cost, and potentially would require some caching & persistence, so it should be opt-in.

I’ll take a look at it. For me it would be better if Grafana could map the user and server IDs to the real names via a simple rest api. I already had a look at this topic a while ago but could not figure out a good way to achieve this.
Opt in sounds good if there is no better solution 👍

A Grafana app is possible if you would like to develop custom panels for this; personally, I reckon it should be handled by this project to avoid additional overhead.

So you would also store the username as a new label for each metric?

I think that would be ideal, it'd be easier to work with on a dashboard.

I just opened https://github.com/nimarion/promcord/pull/139 which solved some of my issues with wanting user/channel names, to stop having to look up user IDs.


Missing option to change individual icon color

I don't seem to have the option in my context menu to change the color of individual icons as I see described in the features.
OS: windows 10

I don't seem to have the option in my context menu to change the color of individual icons as I see described in the features.
OS: windows 10

The icon has to be an individually set icon. That means, this doesn't work for custom rules. Please also make sure to update to the latest version.


Template's add_option() does add additional options if a section already exists

When I tried to create a second option item under an existing section [main], the second item is never added to the config file due to a bug in add_option() wherein the function returns an error and the section is left unchanged because [main] as a section already exists.

Hrmm. Not sure why it created #790 when I referenced #789 in my PR. :\ oops.

@lilchurro PR's get their own numbers that are on the same counter as issues, so you did it right, it just looks weird because they were created right next to each other.


nghttp2: 1.31.0 -> 1.32.0

1.31.1 has security fix for CVE-2018-1000168:
https://nghttp2.org/blog/2018/04/12/nghttp2-v1-31-1/
Quickly following our update to 1.31.0,
let's grab latest and in particular get
the security fix in 1.31.1.
I've only build-tested nghttp2 itself.

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

@GrahamcOfBorg build nghttp2
@GrahamcOfBorg test nghttpx

Success on x86_64-linux (full log)
Attempted: nghttp2
Partial log (click to expand)
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/dijqnm93i711w20k41a735dvfxpxw3jz-nghttp2-1.32.0-dev/lib
patching script interpreter paths in /nix/store/dijqnm93i711w20k41a735dvfxpxw3jz-nghttp2-1.32.0-dev
checking for references to /build in /nix/store/dijqnm93i711w20k41a735dvfxpxw3jz-nghttp2-1.32.0-dev...
shrinking RPATHs of ELF executables and libraries in /nix/store/hbbks12hhcv7v6lhc2wf9nbp3d9hg791-nghttp2-1.32.0-lib
shrinking /nix/store/hbbks12hhcv7v6lhc2wf9nbp3d9hg791-nghttp2-1.32.0-lib/lib/libnghttp2.so.14.16.2
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/hbbks12hhcv7v6lhc2wf9nbp3d9hg791-nghttp2-1.32.0-lib/lib
patching script interpreter paths in /nix/store/hbbks12hhcv7v6lhc2wf9nbp3d9hg791-nghttp2-1.32.0-lib
checking for references to /build in /nix/store/hbbks12hhcv7v6lhc2wf9nbp3d9hg791-nghttp2-1.32.0-lib...

@GrahamcOfBorg test nghttp2

Success on aarch64-linux (full log)
Attempted: nghttp2
Partial log (click to expand)
stripping (with command strip and flags -S) in /nix/store/bzfh65bfsva72qp4lidw5km2l1kabb8d-nghttp2-1.32.0-dev/lib
patching script interpreter paths in /nix/store/bzfh65bfsva72qp4lidw5km2l1kabb8d-nghttp2-1.32.0-dev
checking for references to /build in /nix/store/bzfh65bfsva72qp4lidw5km2l1kabb8d-nghttp2-1.32.0-dev...
shrinking RPATHs of ELF executables and libraries in /nix/store/50pj21xzq8siwrl0pix9gihsanhzvzic-nghttp2-1.32.0-lib
shrinking /nix/store/50pj21xzq8siwrl0pix9gihsanhzvzic-nghttp2-1.32.0-lib/lib/libnghttp2.so.14.16.2
strip is /nix/store/jk6j4lh9v5mvjdbdc35sj0zffhhf6s56-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/50pj21xzq8siwrl0pix9gihsanhzvzic-nghttp2-1.32.0-lib/lib
patching script interpreter paths in /nix/store/50pj21xzq8siwrl0pix9gihsanhzvzic-nghttp2-1.32.0-lib
checking for references to /build in /nix/store/50pj21xzq8siwrl0pix9gihsanhzvzic-nghttp2-1.32.0-lib...
/nix/store/dx2nw0nbvm9m68wjchcnaba2rfqblj27-nghttp2-1.32.0-bin

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: tests.nghttp2
Partial log (click to expand)
Cannot nix-instantiate `tests.nghttp2' because:
error: attribute 'nghttp2' in selection path 'tests.nghttp2' not found

No attempt on x86_64-linux (full log)
The following builds were skipped because they don't evaluate on x86_64-linux: tests.nghttp2
Partial log (click to expand)
Cannot nix-instantiate `tests.nghttp2' because:
error: attribute 'nghttp2' in selection path 'tests.nghttp2' not found

Oops, thanks for mentioning the security fix @xeji (https://github.com/NixOS/nixpkgs/pull/36462#issuecomment-386839085) sorry for not getting to it earlier! :)

Success on x86_64-darwin (full log)
Attempted: nghttp2
Partial log (click to expand)
patching script interpreter paths in /nix/store/z66pxjjsikc474rbjlgsn7710dvvwbwh-nghttp2-1.32.0-bin
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
patching script interpreter paths in /nix/store/58161wfkgfkr99ms6avbycba44a8p62b-nghttp2-1.32.0
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/mbkaq3f67gnpkjzv65py4zsvvy7qpngj-nghttp2-1.32.0-dev/lib
patching script interpreter paths in /nix/store/mbkaq3f67gnpkjzv65py4zsvvy7qpngj-nghttp2-1.32.0-dev
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/kxd5dgmw0mcjlhn6a6d8v3vnyzmnazpp-nghttp2-1.32.0-lib/lib
patching script interpreter paths in /nix/store/kxd5dgmw0mcjlhn6a6d8v3vnyzmnazpp-nghttp2-1.32.0-lib
/nix/store/z66pxjjsikc474rbjlgsn7710dvvwbwh-nghttp2-1.32.0-bin

Success on aarch64-linux (full log)
Attempted: nghttp2
Partial log (click to expand)
/nix/store/dx2nw0nbvm9m68wjchcnaba2rfqblj27-nghttp2-1.32.0-bin

Success on x86_64-darwin (full log)
Attempted: nghttp2
Partial log (click to expand)
patching script interpreter paths in /nix/store/z66pxjjsikc474rbjlgsn7710dvvwbwh-nghttp2-1.32.0-bin
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
patching script interpreter paths in /nix/store/58161wfkgfkr99ms6avbycba44a8p62b-nghttp2-1.32.0
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/mbkaq3f67gnpkjzv65py4zsvvy7qpngj-nghttp2-1.32.0-dev/lib
patching script interpreter paths in /nix/store/mbkaq3f67gnpkjzv65py4zsvvy7qpngj-nghttp2-1.32.0-dev
strip is /nix/store/kdff2gim6417493yha769kh00n63lnrw-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/kxd5dgmw0mcjlhn6a6d8v3vnyzmnazpp-nghttp2-1.32.0-lib/lib
patching script interpreter paths in /nix/store/kxd5dgmw0mcjlhn6a6d8v3vnyzmnazpp-nghttp2-1.32.0-lib
/nix/store/z66pxjjsikc474rbjlgsn7710dvvwbwh-nghttp2-1.32.0-bin

Success on x86_64-linux (full log)
Attempted: nghttp2
Partial log (click to expand)
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/dijqnm93i711w20k41a735dvfxpxw3jz-nghttp2-1.32.0-dev/lib
patching script interpreter paths in /nix/store/dijqnm93i711w20k41a735dvfxpxw3jz-nghttp2-1.32.0-dev
checking for references to /build in /nix/store/dijqnm93i711w20k41a735dvfxpxw3jz-nghttp2-1.32.0-dev...
shrinking RPATHs of ELF executables and libraries in /nix/store/hbbks12hhcv7v6lhc2wf9nbp3d9hg791-nghttp2-1.32.0-lib
shrinking /nix/store/hbbks12hhcv7v6lhc2wf9nbp3d9hg791-nghttp2-1.32.0-lib/lib/libnghttp2.so.14.16.2
strip is /nix/store/j75dgadrff2d1fyc4fczmcgqkid2imdx-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/hbbks12hhcv7v6lhc2wf9nbp3d9hg791-nghttp2-1.32.0-lib/lib
patching script interpreter paths in /nix/store/hbbks12hhcv7v6lhc2wf9nbp3d9hg791-nghttp2-1.32.0-lib
checking for references to /build in /nix/store/hbbks12hhcv7v6lhc2wf9nbp3d9hg791-nghttp2-1.32.0-lib...

Success on x86_64-linux (full log)
Attempted: tests.nghttpx
Partial log (click to expand)
webserver# [  145.668411] dhcpcd[661]: eth0: adding default route via <IP_ADDRESS>
webserver: exit status 0
test script finished in 147.97s
cleaning up
killing proxy (pid 593)
killing client (pid 605)
killing webserver (pid 617)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/build/vde1.ctl': Directory not empty
/nix/store/i7sbz05mgbmmkhhq22ras9rf5hbdp79g-vm-test-run-nghttpx

Success on aarch64-linux (full log)
Attempted: tests.nghttpx
Partial log (click to expand)
proxy# [   18.233192] nscd[759]: 759 monitoring directory `/etc` (2)
client: exit status 0
test script finished in 19.72s
cleaning up
killing webserver (pid 627)
killing proxy (pid 640)
killing client (pid 653)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/build/vde1.ctl': Directory not empty
/nix/store/mdksx14y457y0g8d0d8gacijx32hk12p-vm-test-run-nghttpx


Add chained sig syntax auto correct

Auto-correct prototype for #4251 as requested here https://github.com/sorbet/sorbet/pull/4251#discussion_r683015746
Note: this branch is based on the other one. Only the last commit contains the auto-correct.
Auto-correct old style method signatures into the new chained style. E.g.:
# These signatures
sig(:final) { void }
sig { abstract.void }
sig { overridable.void }
sig { override.void }

# are auto-corrected to
sig.final { void }
sig.abstract { void }
sig.overridable { void }
sig.override { void }

Motivation
Providing an auto-correct is important to facilitate moving over to the new syntax and avoiding having to support multiple ways of writing sigs in the future.
Test plan

For now, this is a prototype. I will add tests once we decide to move forward with it.
/cc @jez

Closing this one for now. We'll add an auto-correct at a later PR.


format .bbjrc

add indentation to .bbjrc so it will become much more readable

Good thinking. Sorry it took me a few days to notice this PR. merged.


Hello, Can you release the tensorflow code of paper "Agnostic Lane Detection"?

Sorry, I am quite busy this month and will not write the tensorflow version of the code. Just refer to the torch code, please.