[-wATCH-]— S.e.x.y Indian s.e.x mms Video Original Video Link Ice Spice Video Viral On Social Media X Trending Now

Real women's sexy MMS videos
Everyone like to see real couples sexy MMS of people. Here, we provide the best and most vast collection of real women's videos.
 Amateur xxx mms porn leaked online.
Missing: Original | Show results with: Original
Free Desi Mms Porn Videos | xHamster
Desi Paki Collage Students Leaked Mms Sex Video, Desi Paki College Students Sex in College Hostel Room Cum in Hot Juicy Pussy. 13.8M views.
Indian Sex - Latest homemade leaked porn videos from India.
 Latest leaked Indian XXX clips exclusively featuring Indian couples and lovers.
 Explore tons of XXX movies with sex scenes in 2024 on xHamster!
  Luxcream ...  HOT INDIAN MMS VIRAL LEA𝚔ED VIDEO ...
4 days ago — (18+).) HOT INDIAN MMS VIRAL LEA𝚔ED VIDEO TELEGRAM LINKS XNXX - Hot Se𝚡 Indian po𝚛n Videos XXX. Hosted by jannasdaddy.
 Explore tons of XXX movies with sex scenes in 2024 on xHamster!
Free Indian Mms Porn Videos
Check out free Indian Mms porn videos on xHamster. Watch all Indian Mms XXX vids right now!

cvb


fix: Run popd to return to original working folder

fix: pushd issue on multiple directories for packer build files
When there are multiple folders containing individual Packer build files, with pushd only, the packer_validate.sh hook can't switch to the next folder for validation, popd at the end of each loop changes the working directory to original directory so that the pushd can work against multiple packer build directories
🗣 Description
This change adds a popd to switch to previous working directory on each loop in the packer_validate hook
💭 Motivation and context
Without this change, the packer_validate will run into the below errors
/Users/xxx/.cache/pre-commit/repox6kqm38u/hooks/packer_validate.sh: line 27: pushd: packer/windows: No such file or directory

on folder structure like below
packer/
├── linux
│   ├── linux.pkr.hcl
│   ├── plugins.pkr.hcl
│   └── variables.pkr.hcl
└── windows
    ├── plugins.pkr.hcl
    ├── variables.pkr.hcl
    └── windows.pkr.hcl

🧪 Testing
Tested locally, working fine
✅ Pre-approval checklist

[x] This PR has an informative and human-readable title.
[x] Changes are limited to a single goal - eschew scope creep!
[ ] All future TODOs are captured in issues, which are referenced
in code comments.
[ ] All relevant type-of-change labels have been added.
[x] I have read the CONTRIBUTING document.
[x] These code changes follow cisagov code standards.
[x] All relevant repo and/or project documentation has been updated
to reflect the changes in this PR.
[x] Tests have been added and/or modified to cover the changes in this PR.
[ ] All new and existing tests pass.

✅ Pre-merge checklist

[ ] Revert dependencies to default branches.
[ ] Finalize version.

✅ Post-merge checklist

[ ] Create a release.

I am closing this because as of #54 I believe this is a non-issue. If you believe this is in error please let me know and I can reopen the pull request.


Unminimized distribution lacks vendor specific selector properties

With version 1.6.0 and probably less... I stumbled upon that icons are not shown in latest Brave, Chromium based browser... mask isn't prefixed with -webkit- as with minimized version in "distribution" output.
Keep up the good job 👍

Good catch - can see that the dist/css/swiffy-slider.css does not contain the prefix - that file is just the original and not parsed with autoprefixer as the min version.
Will look into a solution.


Building example-client on Windows

Hi,
I am trying to build the example-client on Windows. Visual Studio is currently complaining about the call to emptyAndInflateBuffer within the depth namespace. Called from loadDepthTexture in functional.cpp
LNK2019	unresolved external symbol "void __cdecl depth::emptyAndInflateBuffer(class depth::Buffer &,class std::function<void __cdecl(void const *,unsigned __int64)>,struct depth::Opts const &)"
(?emptyAndInflateBuffer@depth@@YAXAEAVBuffer@1@V?$function@$$A6AXPEBX_K@Z@std@@AEBUOpts@1@@Z) referenced in function "void __cdecl ofxDepthStream::loadDepthTexture(class depth::Buffer &,class ofTexture &,struct ofxDepthStream::DepthLoaderOpts const &)"
(?loadDepthTexture@ofxDepthStream@@YAXAEAVBuffer@depth@@AEAVofTexture@@AEBUDepthLoaderOpts@1@@Z)

Any ideas how to fix this? The same code compiles ok on macOS with Xcode.

Solved by changing the name of functional.h and functional.cpp within DepthStream folder. I guess VS was getting confused with the funcational.h in the addon root.


Create codeql.yml

Enabling CodeQL for testing GitHub SAST Solution.

The scan will be triggered on merge


Make CI fail for PRs to azure-cli/master

Add pre-check to CI to immediately reject PRs made to the master branch, as this complicates the release process if something sneaks through (spoiler alert: something did!)

To add a little context for outside folks, our release docs are currently regenerated whenever the master branch is updated. For that reason, contributions come to us via the dev branch. When something accidentally sneaks into master unintentionally it breaks some of our partners and clutters our Git history when we go to fix things.


md-dialog: scrollbar Flash on opening

What is affected?
Component
Description
The scrollbar flashes when the dialog opens even in the case the content is not scrollable.
It's particularly more apparent in dark mode.
See below playground for a demonstration of this issue.
Reproduction
https://lit.dev/playground/#gist=825f3acbc05233df00a8cdb1bd9693c2
Workaround
Could this issue be fixed by hidding the overflow on animation start?
Is this a regression?
No or unsure. This never worked, or I haven't tried before.
Affected versions
<EMAIL_ADDRESS>Browser/OS/Node environment
Any browser/system

I'm not able to reproduce on Chrome macOS. Which browser/os environment are you seeing the issue? Can you upload a screen recording too?

I can reproduce on Linux Mint 21.2 Chrome 118.0.5993.88.
I cannot reproduce on FF.
https://github.com/material-components/material-web/assets/1168053/871fb0f6-b29b-497c-a96c-fce37b3e8f1c

I can reproduce on Windows with Edge.  No issue with FF.

Firefox is doing great (you can even select text in the dialogs 😹)

Can reproduce this with Chrome M114 and M122 running through Electron V0.25.X and V0.29.X, respectively

I found an interim fix, adding overflow: visible to the .scroller seems to be fix the issue. Not sure what side-effects will it cause, but works fine for small dialogs.
function fixScrollFlash(mdDialog: MdDialog) {
    const shadowRoot = mdDialog.shadowRoot;
    if (shadowRoot) {
      const scroller = shadowRoot.querySelector<HTMLElement>(".scroller");
      if (scroller) {
        scroller.style.overflow = "visible";
      } else {
        console.log("scrollernot found");
      }
    } else {
      console.log("shadowRoote not found");
    }
  }

My workaround. Slightly inspired by @shhdharmen workaround.
Using these 2 events it will make sure the scrollbar will work as needed after animation is played and the shadowRoot children are present - so no check for .scroller shouldn't be needed.

open: Dispatched when the dialog is opening before any animations.
opened: Dispatched when the dialog has opened after any animations.

static showDialog(dialog) {
    dialog.addEventListener("open", () => {
        this.changeScrollerOverflow(dialog, "visible");
    });

    dialog.addEventListener("opened", () => {
        this.changeScrollerOverflow(dialog, "hidden");
    });

    dialog.show();
}

static changeScrollerOverflow(mdDialog, overflowValue) {
    const shadowRoot = mdDialog.shadowRoot;
    const scroller = shadowRoot.querySelector(".scroller");
    scroller.style.overflow = overflowValue;
}


chore(spin.toml): update redirected contributing route

Actually, @tpmccallum, I'm wondering if the change should be in the developer repo to update the endpoint to developer.fermyon.com/bartholomew/contributing (and thus close this PR) -- thoughts?

I think this route might change based on how common docs are organized in developer.

@karthik2804 we've updated spin recently with similar: https://github.com/fermyon/spin/pull/1123
I'd actually like to see the endpoints be bartholomew/contributing and spin/contributing, but defer to you and @tpmccallum to make the change -- and we can sync up the changes here in tandem.
In the meantime, I'd say we get this in to match what currently exists.  WDYT?

Oh actually you are correct, contributing to docs is the one that is going to be common I assume, not the code itself,


Show batch status in submit queue

This shows the currently running batch in the submit queue, and also leaves better comments when batches are merged.

This change is

LGTM modulo Eric's comment (feel free to self lgtm)


A way to not set GEM_HOME if the installed ruby is under $HOME

I would like a way to tell chruby to not set $GEM_* variables, as this is much safer (i.e., does not mix gems of different Ruby implementations) when e.g., developing TruffleRuby and executing two different Rubies without a chruby in between (see https://github.com/postmodern/chruby/pull/410#issuecomment-515233038).
Currently I'm doing this by using a branch on my chruby fork, removing the code that sets GEM_HOME, but that's obviously not very convenient or maintainable, and I can't easily advise other TruffleRuby developers to do the same. I'd much rather this was possible in chruby itself.
Actually, there is already a way to do this, by running everything as root, but that's obviously not very safe for my use-case.
So I'm thinking to just extend the check if (( UID != 0 )); then to something like if (( UID != 0 )) && [ "$CHRUBY_SET_GEM_HOME" != "false" ]; then.
We could also automatically just detect if $RUBY_ROOT is under $HOME and not set $GEM_* vars in that case, but @postmodern had some concerns about that in https://github.com/postmodern/chruby/pull/410#issuecomment-515754740:

Furthermore, there is value in keeping user-installed gems separate from the ruby, in case you need to delete/re-install one or the other.

@postmodern @havenwood What do you think?
I would like to have this available in chruby 1.0.0, I'm happy to make a PR.

Proof-of-concept PR for $CHRUBY_SET_GEM_HOME: https://github.com/postmodern/chruby/pull/423

The reason why chruby sets GEM_HOME for non-root users is to protect the ruby's built-in gem home, which may not always be writable. This also helps keep the ruby's built-in gems from any user installed gems. Perhaps better logic would be to check if the ruby's GEM_HOME is writable? Another idea might be to split chruby_use into a lower-level function that only sets the ruby, which you could explicitly call instead of the main chruby function.
Also, for the record, I'm adverse to adding yet more CHRUBY_ env variables to user's shells.

The reason why chruby sets GEM_HOME for non-root users is to protect the ruby's built-in gem home, which may not always be writable.

Right, I know. This is very inconvenient when actually developing a Ruby implementation though, as it prevents using the current Ruby selected with chruby and the Ruby being developed without switching everytime when doing anything using gems.
(https://github.com/postmodern/chruby/pull/410#issuecomment-515233038 for another way to say that)

This also helps keep the ruby's built-in gems from any user installed gems. Perhaps better logic would be to check if the ruby's GEM_HOME is writable?

That would not keep built-in and user-installed gems separated, so I (maybe wrongly?) assumed it's not an approach you wanted to take.
I think it could actually be nice feature and work well, so if you're not against it, I'm happy to make a PR for that approach.
Then chruby would only set GEM_HOME when it's needed (i.e., when gems otherwise would need sudo to be installed).

Another idea might be to split chruby_use into a lower-level function that only sets the ruby, which you could explicitly call instead of the main chruby function.

I'd still want chruby MYRUBY to work and not set GEM_HOME.

Also, for the record, I'm adverse to adding yet more CHRUBY_ env variables to user's shells.

@postmodern  What other solution do you think is better for my use case presented in this issue?

@postmodern Any thoughts on my reply?
I like the idea of detecting if GEM_HOME is writable, it sounds like a much cleaner check than "is root" or "env var", should I proceed with that and make a PR then if you're not against it?

@postmodern Here is a PR implementing the idea of setting GEM_HOME only if the default gem directory is not writable. It looks very elegant to me, please review it: https://github.com/postmodern/chruby/pull/431

Due to this, I've been forced to switch to @eregon's fork of chruby that have #431: https://github.com/eregon/chruby/tree/do-no-set-gem-home
It was needed because I have a computer with Apple silicon (M2), and I want to be able run Ruby apps either on arm64 or x86_64 ("Intel").
Using ruby-build it was very easy to install Rubies for different architectures to different directories (and configure your shell for it), but I can't have them install native extensions (like for Nokogiri) to the same directory (GEM_HOME)
arm64 $ env | grep GEM
GEM_ROOT=/Users/dentarg/.arm64_rubies/2.7.6/lib/ruby/gems/2.7.0
GEM_HOME=/Users/dentarg/.gem/ruby/2.7.6
GEM_PATH=/Users/dentarg/.gem/ruby/2.7.6:/Users/dentarg/.arm64_rubies/2.7.6/lib/ruby/gems/2.7.0

intel $ env | grep GEM
GEM_ROOT=/Users/dentarg/.rubies/2.7.6/lib/ruby/gems/2.7.0
GEM_HOME=/Users/dentarg/.gem/ruby/2.7.6
GEM_PATH=/Users/dentarg/.gem/ruby/2.7.6:/Users/dentarg/.rubies/2.7.6/lib/ruby/gems/2.7.0

As an example, before switching to the chruby fork (using chruby 0.3.9 installed from Homebrew), I did bundle install for my app on arm64 (ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [arm64-darwin21]), then I also did bundle install for it on Intel (ruby 2.7.6p219 (2022-04-12 revision c9c2245c0a) [x86_64-darwin21]). When I tried to run my tests on arm64 I got this back:
arm64 $ b e rake
Traceback (most recent call last):
  13: from /Users/dentarg/.gem/ruby/2.7.6/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in `<main>'
  12: from /Users/dentarg/.gem/ruby/2.7.6/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in `select'
  11: from /Users/dentarg/.gem/ruby/2.7.6/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:21:in `block in <main>'
  10: from /Users/dentarg/.gem/ruby/2.7.6/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:21:in `require'
   9: from /Users/dentarg/starkast/wikimum/test/unit/markup_test.rb:4:in `<top (required)>'
   8: from /Users/dentarg/starkast/wikimum/test/unit/markup_test.rb:4:in `require_relative'
   7: from /Users/dentarg/starkast/wikimum/lib/services/markup.rb:3:in `<top (required)>'
   6: from /Users/dentarg/starkast/wikimum/lib/services/markup.rb:3:in `require'
   5: from /Users/dentarg/.gem/ruby/2.7.6/gems/html-pipeline-2.14.2/lib/html/pipeline.rb:3:in `<top (required)>'
   4: from /Users/dentarg/.gem/ruby/2.7.6/gems/html-pipeline-2.14.2/lib/html/pipeline.rb:3:in `require'
   3: from /Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri.rb:10:in `<top (required)>'
   2: from /Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri.rb:10:in `require_relative'
   1: from /Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri/extension.rb:7:in `<top (required)>'
/Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri/extension.rb:7:in `require_relative': cannot load such file -- /Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri/2.7/nokogiri (LoadError)
  14: from /Users/dentarg/.gem/ruby/2.7.6/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in `<main>'
  13: from /Users/dentarg/.gem/ruby/2.7.6/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:6:in `select'
  12: from /Users/dentarg/.gem/ruby/2.7.6/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:21:in `block in <main>'
  11: from /Users/dentarg/.gem/ruby/2.7.6/gems/rake-13.0.6/lib/rake/rake_test_loader.rb:21:in `require'
  10: from /Users/dentarg/starkast/wikimum/test/unit/markup_test.rb:4:in `<top (required)>'
   9: from /Users/dentarg/starkast/wikimum/test/unit/markup_test.rb:4:in `require_relative'
   8: from /Users/dentarg/starkast/wikimum/lib/services/markup.rb:3:in `<top (required)>'
   7: from /Users/dentarg/starkast/wikimum/lib/services/markup.rb:3:in `require'
   6: from /Users/dentarg/.gem/ruby/2.7.6/gems/html-pipeline-2.14.2/lib/html/pipeline.rb:3:in `<top (required)>'
   5: from /Users/dentarg/.gem/ruby/2.7.6/gems/html-pipeline-2.14.2/lib/html/pipeline.rb:3:in `require'
   4: from /Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri.rb:10:in `<top (required)>'
   3: from /Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri.rb:10:in `require_relative'
   2: from /Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri/extension.rb:4:in `<top (required)>'
   1: from /Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri/extension.rb:30:in `rescue in <top (required)>'
/Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri/extension.rb:30:in `require': dlopen(/Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri/nokogiri.bundle, 0x0009): tried: '/Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri/nokogiri.bundle' (mach-o file, but is an incompatible architecture (have (x86_64), need (arm64e))) - /Users/dentarg/.gem/ruby/2.7.6/gems/nokogiri-1.13.6/lib/nokogiri/nokogiri.bundle (LoadError)
rake aborted!

I know chruby 1.0.0 will bring changes to GEM_HOME (https://github.com/postmodern/chruby/pull/419) but I don't think using basename is enough, as it will be the same basename regardless of the architecture.

@dentarg Indeed, this is a clear real-world example of why sharing gem homes is problematic and AFAIK the only completely safe and solution is to just let gems be installed inside that Ruby's prefix, i.e., the default, which chruby unfortunately overrides. I am thinking to make my own Ruby switcher based on chruby for that, but I'm not sure I have the time.

@postmodern It has been 3 years since https://github.com/postmodern/chruby/pull/419.
In that time I had dozens of people mentioning this problem to me, and the only workaround for now is to use my fork's branch (https://github.com/eregon/chruby/tree/do-no-set-gem-home), which is of course inconvenient.
I know for instance Shopify's tooling uses chruby and some people there get this issue almost daily and have to workaround with unset GEM_HOME GEM_PATH (because chruby is pre-installed).
Do you plan to release chruby 1.0.0 one day?
I'm happy to help, if that means we release it sooner.
This bug existing since 3 years and having no release fixing it seems to clearly indicate chruby is completely unmaintained. This is very unfortunate given how widely chruby is used.
So let's fix it, whether it's https://github.com/postmodern/chruby/pull/419, https://github.com/postmodern/chruby/pull/431 or something based on it.
What are your concerns?
That chruby users using CRuby have to reinstall gems?
We can probably avoid that if that's the main issue.

@eregon I am currently busy working on another large refactoring project, before I can circle back around and work on chruby. I have not yet heard of other people having this issue besides you or other truffleruby developers. I am just curious, if this is such a critical issue, why can't truffleruby just workaround the problem?
Currently, I do not plan on optionally not setting GEM_HOME if the ruby's gem-root is writable, since like I said before it would lead to gems being potentially installed in two separate locations based on where or how the ruby was installed, and that could lead to confusion. I do however plan on adding additional function hooks to allow configuring how chruby sets GEM_HOME or GEM_PATH. These changes would be incremental and could be released before 1.0.0.

I have not yet heard of other people having this issue besides you or other truffleruby developers.

For instance:

CRuby master contributors using chruby (and notably Shopify devs). I believe that's one of the main reasons why https://github.com/ruby/ruby/pull/5474 was added. I know at least @byroot, @peterzhu2118, @noahgibbs, and the YJIT team were affected by this.
Quoting https://bugs.ruby-lang.org/issues/18249#note-9:

For dev builds, Ruby switchers has responsibility to handle the ABI compatibility breakage.

It's important for caching, e.g., https://bugs.ruby-lang.org/issues/18249#note-15. With this bug in chruby people disable gem caching, which is wasteful.
https://github.com/postmodern/chruby/issues/422#issuecomment-1232791999
https://twitter.com/schneems/status/1401248352562515968
https://twitter.com/jardonamron/status/1401250028778229770
https://twitter.com/tenderlove/status/1401253239064993792
https://twitter.com/jardonamron/status/1401253961701609472
A subset of the many many issues related to GEM_HOME on this repo: https://github.com/postmodern/chruby/issues?q=is%3Aissue+GEM_HOME I remember commenting on some of them.
Several direct messages on Slack, unfortunately I cannot link that.

I am just curious, if this is such a critical issue, why can't truffleruby just workaround the problem?

TruffleRuby already spent significant amount of effort to workaround this chruby bug.
Notably there is an ABI check when loading C extensions, so at least it fails early.
What workaround are you thinking of? I don't think truffleruby can workaround chruby setting the GEM_HOME incorrectly.
Whoever sets the GEM_HOME is responsible to set it correctly (or not set it), so that's chruby, isn't it?

I do however plan on adding additional function hooks to allow configuring how chruby sets GEM_HOME or GEM_PATH. These changes would be incremental and could be released before 1.0.0.

That would be nice. The defaults needs to change though, because the current GEM_HOME/GEM_PATH set by chruby are incorrect for all dev Rubies, and all non-CRuby. In other words, it only works for CRuby releases, in the case they are always built with the same flags (e.g., --enable-shared) and arch for a given release version on the same machine. It also fails for CRuby releases on platforms with multiple archs as said in https://github.com/postmodern/chruby/issues/422#issuecomment-1232791999 and https://github.com/postmodern/ruby-install/issues/413#issuecomment-1244762132.

I can verify that in my work on the YJIT team, and especially for speed.yjit.org, we have difficulties when shared dirs contain built native extensions. We handle this by deleting all gems in all shared directories on every build, as well as all built Ruby dirs we'll be using for that build. In general, my experience is that Rubygems/Bundler/etc deal poorly with trying to match up specific built native extensions to specific Rubies. So for benchmarking we use a Big Hammer to handle the situation: we delete everything, so there is clearly nothing stale or inappropriately shared.
This problem isn't unique to chruby, though we do have it when using chruby. We're a hard case - we build a lot of prerelease Rubies that all have the same version string, so RUBY_VERSION checking does nothing for us. We're prone to get crashes, slowdowns and other problems very regularly if we leave built gems sitting around. So we basically treat shared-across-multiple-Rubies gem dirs as a bug, and delete their contents when there's reason to care.
To preempt the same question: we do indeed work around the problem, by deleting everything. We need a fresh gem install of all native extensions for every build regardless, so saving old copies wouldn't do us any good. If we wanted shorter runs that didn't take multiple hours, or to reuse the same prerelease Ruby for multiple runs, we'd work around it by fiddling with dirs like GEM_HOME every time we changed versions. But if we need to manually manage our gem-related env vars every time we switch Rubies, chruby becomes a much less valuable tool.

I have not yet heard of other people having this issue besides you or other truffleruby developers.

??  – I'm no truffleruby developer :) Just a developer doing things with Ruby.
I've been a devote and happy chruby user for 10 years (yes, since start almost), but sadly, I no longer recommend friends and co-workers to use the released version of chruby. I now recommend people using eregon's branch. It would be great to change that.

As a compromise and to get the changes released faster, I am thinking of adding a separate dev.sh file which can be loaded along with chruby.sh and that changes how GEM_HOME/GEM_PATH are set, in order to support testing rubies of the same version but with different configurations.
As per @dentarg's use case of wanting to switch between aarm64 and x86-64 on Apple Silicon, I could also add a multi_arch.sh file which takes into account the current architecture.
Testing the same ruby version with different configurations or switching between aarch64 and x86-64 on specific hardware are niche use-cases vs. your more common Ruby app development. Providing opt-in solutions seems like a good compromise. Depending on whether these opt-in solutions become popular, they might become the default behavior in 1.0.0.

Testing the same ruby version with different configurations or switching between aarch64 and x86-64 on specific hardware are niche use-cases vs. your more common Ruby app development. Providing opt-in solutions seems like a good compromise. Depending on whether these opt-in solutions become popular, they might become the default behavior in 1.0.0.

I have to disagree that multiple architechtures are niche use cases. there are searches for it all over the web since apple silicone and rosetta have become main staple development machines. it has become a necessity even for many

I often invoke a ruby command from another ruby for benchmark reasons, which results in pointing to a wrong GEM_PATH in the child process. This resulted in workarounds for benchmark scripts like https://github.com/Shopify/yjit-bench/pull/138 and https://github.com/benchmark-driver/benchmark-driver/commit/19386555c03b5c72d9bdb3ea7fc63b9c2c8bf105, but it's still not ideal because it would not pick up gems installed under a normal environment.
In addition, I have the same problem as eregon; I develop ruby itself. I often have multiple installations of the same ruby version with different build flags. When build flags are different, I want them to not share the same extensions. I want to unset GEM_HOME for that reason as well.
All in all, if you contribute to or benchmark a ruby implementation and install that under a writable directory, you shouldn't set GEM_HOME or GEM_PATH. However, I understand that most users are not interested in developing/benchmarking ruby and some users install ruby to a non-writable directory, so I'd be happy with that feature being optional. I filed https://github.com/postmodern/chruby/pull/487 as per https://github.com/postmodern/chruby/issues/422#issuecomment-1292899140.

By the way, I was using master branch of chruby, which is why I didn't notice 1.0.0 branch has https://github.com/postmodern/chruby/pull/419. It does address the latter concern in my comment, but the former concern remains. So it'd be nice to have a way to keep GEM_HOME unset.

TBH I'm really annoyed about this, I spent a large amount of time to try to fix this in a way that pleases @postmodern in chruby, spent time to discuss the proper solution in RubyGems (where the general agreement has become to use the default gem home unless it's not writable, exactly the same behavior I proposed for chruby), but my PR is just hidden on a branch and not the best approach (which is to not set GEM_HOME) and chruby feels very much unmaintained. I think it's time I hard fork chruby and create a more sensible and actually maintained and sound Ruby switcher. The fact that chruby keeps an incorrect GEM_HOME for years without doing anything for its users seems unbelievable (also tracked as #451). The issue has been known for 4 years now.
https://github.com/postmodern/chruby/pull/431 is a log of how frustrating it can be to contribute to chruby, I think it's clear to anyone. That's also I believe the best solution for this issue as it aligns with how RubyGems will behave.
Anyway, good luck with your PR @k0kubun and getting it released. It would be good to finally see some progress here so maybe I can forget about this terrible experience of contributing to chruby and this bug.

I am just curious, if this is such a critical issue, why can't truffleruby just workaround the problem?

TruffleRuby already spent significant amount of effort to workaround this chruby bug. Notably there is an ABI check when loading C extensions, so at least it fails early.

BTW, this ABI check which now exists in TruffleRuby and CRuby has caused various issues and complications. Was it not for chruby and this long-time bug we would probably not need this ABI check. So while that's not chruby's direct doing, it's partly a consequence of not fixing this bug.

@eregon like we have discussed on multiple occasions, changing the path of the GEM_HOME is a breaking change and would cause chruby users to suddenly lose all of their installed gems after upgrading. Since chruby is widely used this would cause a great deal of confusion and frustration, so I decided to push that change back to 1.0.0 where we could safely break with backwards compatibility. Likewise, rubygems also has to maintain backwards compatibility and not change default behavior too much, otherwise that could possibly cause issues with downstream users and Linux distributions which expect gems to be installed into specific directories.
I would have accepted #451, however I am very hesitant about adding additional bifurcating logic. I could envision scenarios where you are debugging an issue for a use and you need to determine if the gems are being installed into the correct location, so you then have to determine if the ruby's gem directory is writable or not in order to determine if chruby is going to use the ruby's gem dir or ~/.gem/.... This would likely result in more debugging, troubleshooting, and complexity.
Since chruby is loaded into user's shells, and because it has to run under Bash 3+ and Zsh, I have to be very cautious about changing any functionality and debate every change, especially those that might break or change default behavior for users. chruby also has an explicit policy of not accepting workaround fixes for upstream issues, which means I scrutinize issues and whether they could be better solved by rubygems or upstream Ruby. I also have to balance the needs of regular users vs the more exotic edge-cases which Ruby maintainers discover while testing Rubies. chruby is not an easy project to contribute to and requires a great deal of patience and compromising.
I am now considering a different approach to handling GEM_HOME. Extracting the logic which sets GEM_HOME and GEM_PATH out as an additional function hook that could be overrode by additional opt-in configuration files much like how auto.sh is implemented. Additionally, we could extract that logic entirely into an additional gem_home.sh file and make isolating gems in ~/.gem/rubies/$ruby/ opt-in. This would provide an absolute bare minimum user experience of just switching the rubies, but not setting GEM_HOME by default. This would work seamlessly for users who have all rubies installed into ~/.rubies; which means their ruby gem directories are writable by default. If the GEM_HOME code is extracted entirely into an opt-in gems.sh or gem_home.sh file, and users have rubies installed into /opt/rubies (such as myself) , those users would then need to decide if they want gem isolated in ~/.gem/rubies/$ruby/ or allow rubygems to pick the gem installation directory for the user; this could potentially mean rubygems install gems of different /opt/rubies rubies into ~/.gem, but maybe some users might want that? By moving the logic out into functions, this opens the door for customization and different opt-in configurations.
Example Code
# potentially defined in a `gems.sh` or `gem_home.sh` file
function chruby_gems_set()
{
		export GEM_HOME="$HOME/.gem/$RUBY_ENGINE/$RUBY_VERSION" # could be extracted into another function in case people want to configure the `GEM_HOME` template string
		export GEM_PATH="$GEM_HOME${GEM_ROOT:+:$GEM_ROOT}${GEM_PATH:+:$GEM_PATH}"
		export PATH="$GEM_HOME/bin:$PATH"
}

# potentially defined in a `gems.sh` or `gem_home.sh` file
function chruby_post_hook() { chruby_set_gem_home }

function chruby_set()
{
    # add the ruby/bin directory to PATH and query the ruby's information ...
    chruby_post_hook
}

Sorry for not working on the 1.0.0 branch. I have been extremely busy over the last four-six years, with both commercial work (2014-2020) and other Open Source work (2020-2023). I will start working on 1.0.0 again; I just added relisting of rubies directories.

I think we can close this issue now that https://github.com/postmodern/chruby/pull/487 is merged.


Add scripts and notebooks for TPC-DS throughput test.

@jerrychenhf Hi, haifeng. I've refined the notebooks and validated these notebooks on Cloud. I've also added README content for throughput test. Thanks.

@jerrychenhf Hi haifeng. I've renamed the notebooks for throughput test. Thanks!


linuxPackages.exfat-nofuse: 2018-04-16 -> 2019-09-06

Motivation for this change
Upstream repository is unmaintained since 2018, maintainership got taken
over by AdrianBan ( https://github.com/dorimanx/exfat-nofuse/issues/145#issuecomment-528632096 )
Things done

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

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

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[N/A] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Notify maintainers
that would be me, i guess
cc @

@GrahamcOfBorg build linuxPackages.exfat-nofuse

This PR should solve all(tm) build errors related to exfat-nofuse in #68361

@GrahamcOfBorg build linuxPackages.exfat-nofuse linuxPackages_4_14.exfat-nofuse linuxPackages_4_19.exfat-nofuse linuxPackages_5_2.exfat-nofuse linuxPackages_5_1.exfat-nofuse linuxPackages_xen_dom0.exfat-nofuse

builds timed out, not sure what happened there. let me retry

@GrahamcOfBorg build linuxPackages.exfat-nofuse linuxPackages_4_14.exfat-nofuse linuxPackages_4_19.exfat-nofuse linuxPackages_5_2.exfat-nofuse linuxPackages_5_1.exfat-nofuse linuxPackages_xen_dom0.exfat-nofuse

mh seems to try to compile all the kernels(tm).

[detached HEAD 630bffe451e] linuxPackages.exfat-nofuse: 2018-04-16 -> 2019-09-06
Author: makefu<EMAIL_ADDRESS>Date: Fri Sep 13 08:43:15 2019 +0200
1 file changed, 5 insertions(+), 14 deletions(-)


Improve speed of fetching citation information

It takes a minute or so to fetch the abstracts and titles for all of the cited papers, the first time a specific arXiv paper is opened in the interactive reader, or the first time a paper is accessed after the API is restarted.
This is because the API fetches abstract and title information from the S2 API, and for the typical paper, needs to request summary information for dozens of papers. These requests take some time.
The interface makes it look like there's no data for a cited paper when the API is taking as long as it does to fetch paper details, showing this message:

To solve this issue, the API should be updated to fetch paper details more quickly. Potential solutions include:

Pre-fetching paper details for a large number of cited papers
Uploading paper details to the database as part of the pipeline, and joining on a paper details table when fetching citations

The UI could also display a loading spinner to more clearly indicate there's an in-flight request


what does the "_birth_year_df_mask" function means in the age_from_name.py?

Hello, Jason! I appreciate your great work - agefromname. I'm new to Python and I'm now working on a project similar to this, so I'm studying your code but I can't understand what does the "_birth_year_df_mask" function means in the age_from_name.py! Can u explain this to me? Thank u very much!

It's a protected function that returns a mask for the main dataframe st only the rows with the specified gender and birth year have True values.


Menu image not found in case library loaded as framework (use_framewo…

Menu image (hamburger) disappeared in case I add use_frameworks! to my Podfile
UIImage *image = [UIImage imageNamed] loads from main bundle only.

Hey @aryaxt , any news on when/if you are going to merge the Pull Request?
Thanks! :)

Any recent news on when this pull request is going be merged?

I use iOS-Slide-Menu in Swift project with use_frameworks!
In my case, when I setup rightMenu in AppDelegate menu button doesn't appear. But when I move it to first viewController, that has slideNavigationControllerShouldDisplayRightMenu: method button appears as expected.

sorry been busy haven't checked the repos recently. Will push this to cocoapods soon


Display exception message from contextrequestfilter

JIRA Ticket: https://jira.lyrasis.org/browse/FCREPO-3565
What does this Pull Request do?
Adds a utility method to build a response. Using the sendError(int, String) works for some messages and not others. It relies on the server to generate a HTML page.
Now we generate a direct response which is consistent.
How should this be tested?
Without this PR, start Fedora and try
> curl -u fedoraAdmin:fedoraAdmin http://localhost:8080/rest/ag-01/fcr-root -H "Link: <http://www.w3.org/ns/ldp#NonRDFSource>; rel=type" -H "Content-Type: text/plain" -X PUT --data-binary "testing" -i

HTTP/1.1 400 Bad Request
Set-Cookie: JSESSIONID=node014ceou6egqtht1u5uvjpgi6wnk0.node0; Path=/
Set-Cookie: rememberMe=deleteMe; Path=/; Max-Age=0; Expires=Fri, 04-Dec-2020 03:20:05 GMT; SameSite=lax
Content-Length: 0
Server: Jetty(9.4.34.v20201102)

or
> curl -u fedoraAdmin:fedoraAdmin http://localhost:8080/rest/ag-02/fcr:versions/whoops/fcr:versions/stuff -i

HTTP/1.1 400 Bad Request
Set-Cookie: JSESSIONID=node01v6enfimteuqf1x5mq607mwqaw1.node0; Path=/
Set-Cookie: rememberMe=deleteMe; Path=/; Max-Age=0; Expires=Fri, 04-Dec-2020 03:20:10 GMT; SameSite=lax
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 710
Server: Jetty(9.4.34.v20201102)

<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<title>Error 400 Path contains empty element! /rest/ag-02/fcr:versions/whoops/fcr:versions/stuff</title>

HTTP ERROR 400 Path contains empty element! /rest/ag-02/fcr:versions/whoops/fcr:versions/stuff

URI:	/rest/ag-02/fcr:versions/whoops/fcr:versions/stuff

STATUS:	400

MESSAGE:	Path contains empty element! /rest/ag-02/fcr:versions/whoops/fcr:versions/stuff

SERVLET:	jersey-servlet

Powered by Jetty:// 9.4.34.v20201102

With this PR, try the same
> curl -u fedoraAdmin:fedoraAdmin http://localhost:8080/rest/ag-01/fcr-root -H "Link: <http://www.w3.org/ns/ldp#NonRDFSource>; rel=type" -H "Content-Type: text/plain" -X PUT --data-binary "testing" -i

HTTP/1.1 400 Bad Request
Date: Sat, 05 Dec 2020 03:13:48 GMT
Set-Cookie: JSESSIONID=node09fl88h9xgjuud1spbj13rx700.node0; Path=/
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: rememberMe=deleteMe; Path=/; Max-Age=0; Expires=Fri, 04-Dec-2020 03:13:48 GMT; SameSite=lax
Content-Type: text/plain;charset=utf-8
Content-Length: 63
Server: Jetty(9.4.34.v20201102)

Invalid resource ID. IDs may not contain the string 'fcr-root'.

or
> curl -u fedoraAdmin:fedoraAdmin http://localhost:8080/rest/ag-02/fcr:versions/whoops/fcr:versions/stuff -i

HTTP/1.1 400 Bad Request
Date: Sat, 05 Dec 2020 03:14:43 GMT
Set-Cookie: JSESSIONID=node01g206nn8jgw4v17ev0kkt13e0z1.node0; Path=/
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: rememberMe=deleteMe; Path=/; Max-Age=0; Expires=Fri, 04-Dec-2020 03:14:43 GMT; SameSite=lax
Content-Type: text/plain;charset=utf-8
Content-Length: 62
Server: Jetty(9.4.34.v20201102)

Path is invalid: /ag-02/fcr:versions/whoops/fcr:versions/stuff

Interested parties
Tag (@ mention) interested parties or, if unsure, @fcrepo/committers

I'm wondering if we should have two levels of exceptions from the FedoraId. This PR works but I think the question is should the authentication layer be returning application errors. This check was because in the case of an empty path segment we couldn't go up the tree and would throw a stacktrace. So perhaps there should be fatal id errors and disallowed id errors and only the fatal ones are returned from the authentication layer.
That can be done after this and would still need this to return the message in a nice way. My 2 cents.


don't mangle AQL errors in web UI graph viewer

Scope & Purpose
Pass through proper AQL errors to web UI graph viewer, instead of turning them into HTTP 500 "Internal Server Error"s.

[x] Bug-Fix for devel-branch (i.e. no need for backports?)
[x] The behavior in this PR can be (and was) manually tested (support / qa / customers can test it)

Related Information

[x] There is an internal planning ticket: https://github.com/arangodb/release-qa/issues/317#issuecomment-640894681

Testing & Verification
This change is a trivial rework / code cleanup without any test coverage.
http://<IP_ADDRESS>:8080/view/PR/job/arangodb-matrix-pr/10380/

tests blue


Fix native collections leak on Unity v2021+

Dispose was not called on the UnityWebRequest, which in newer versions of unity causes a memory leak.
disposeUploadHandlerOnDispose  defaults to true, so it will also implicitly dispose that class.
This is backwards compatible to unity 2018, when the UnityWebRequest class was introduced, as it has always implement IDisposable (see: https://github.com/Unity-Technologies/UnityCsReference/blob/2018.1/Modules/UnityWebRequest/Public/UnityWebRequest.bindings.cs)

Actually. I don't think this fully fixes the issue. Investigating

Actually, this sometimes still has the issue.
I'll look into it some more

I would love to, but it ended up not fully fixing the issue. I haven't had time to come back and resolve it :(

I can confirm that on my machine this fixed the problem. It also wouldn't allow me to build before when I had the bug.


Update Composer dependencies (2021-09-26-00-10)

Visual regression test passed!
View the visual regression test report


Homebrew won't install SHA256 mismatch.

Has Hackintool been hacked or something? I previously installed it with Homebrew but when I opened it for the first time I received warnings to move it to the trash and was not able to open it. I tried the various permissions fixes and Malware overides but none of them worked. I uninstalled it and now I can't install via Homebrew. I get SHA256 mismatch. Is this an error on my side or the GitHub side?

I just did another release with a version bump that should fix this

Ok thanks. I just went ahead and downloaded it manually from your GitHub releases just now and that installed just fine.😁


RetinaNet with custom backbone and custom dataset

How to form the dataset for training?
for :
model.fit( X, Y)  #where model is the retinanet object with appropriate backbone using keras_cv.models.RetinaNet()
X would be the array of images.
So for X0 (first image), will Y0 be array of [class, xmin, xmax, ymin, ymax] for all  objects in the image?
What is the correct format?
Right now, I have the annotations saved in [class, xmin, xmax, ymin, ymax]  format in a separate text file for each image
Is there any alternative for such case?
Thank you for any help.

@adityaroy10,
RetinaNet, a popular single-stage detector, which is accurate and runs fast. RetinaNet uses a feature pyramid network to efficiently detect objects at multiple scales and introduces a new loss, the Focal loss function, to alleviate the problem of the extreme foreground-background class imbalance. Also there is COCO2017 dataset which has around 118k images for the training and testing.
https://keras.io/examples/vision/retinanet/
Also there is the data structure of the coco-dataset for the own custom data using TFDS.
https://www.tensorflow.org/datasets/add_dataset#version
Looks like this issue is not related to tf-keras. Could you please try to file an issue on tensorflow forum for such type of issues. Thank you!


Testing discussion/braindump

As mentioned in #99, I have been trying to find a reasonable way to test curses on and off. This issue will start as a braindump/rant and then continue as a discussion for what we should test and when.
For the repo, my initial reaction to testing is:

Get a high level test or 2 in place first

For example, something that launches Suplemon, presses a key, and verifies a key was written to the window
This serves as a good baseline to make sure that no PR ever fully breaks Suplemon

Test inner API parts on piece by piece basis

For example, verify that running the window command "move cursor left", moves the cursor left (mind blown)
This gives us more coverage with less setup/teardown (and maybe headaches) for each test
The negative side here is that if an internal API changes, then the test will need to be updated/rewritten; resulting in wasted time/effort

With those 2 goals in mind, I started attempting to take down the goliath that is "How do we test starting up and entering keys into a text editor?"
My different attempts at this can be found in a gist, scattered throughout its history. Unfortunately, nothing worked great.
https://gist.github.com/twolfson/e24af2d3d5424540492f
Here are the rough/quick notes:

Starting a child process to a curses application yielded non-useful errors for cbreak
As a result, I went to a simpler script that outputs letters (no stdin worries for now)
We could start that up as a child process
Unfortunately, there's no EOF. As a result, when we used subprocess.PIPE with stdout.read()/stderr.read(), the Python test.py would hang unless a byte count is entered (e.g. stdout.read(200))
Then, I was enlightened by a blog post saying we could provide an in-memory file descriptor instead (StringIO in Python 2, should be BytesIO in Python 3)
This kind of/sort of worked -- it would write out content if I had an time.sleep(1). However, if I used while 1 loop that looked for changes on the StringIO, it would never yield anything =(
Then, I tried to see if we could dodge the subprocess entirely by pointing curses to a StringIO instead of sys.stdout
Unfortunately, it wanted a file descriptor number which I didn't have
As a result, I created a pty via pty.fork() but after getting that stood up, we were still getting output on stdout
I wasn't sure if it was a problem in my setup or curses
I really wanted that to work
Then, I tried overwriting sys.stdout with a StringIO but curses also went around that
I now believe curses ignore the stdout provided to it via curses.setupterm but am not sure why

I have a few more thoughts beyond that:

See if there's any way to mock curses (similar to FakeRedis)
See if there's any way to read state from curses (e.g. get the contents of what curses is showing)
Find out what's really going wrong with pty/curses

END OF BRAINDUMP/RANT
Now we should both be on the same page. From here, I suggest we get at least some tests in place for API's which are never going to change. One very clear one:

Config's JSON parser (which does comment filtering)

https://github.com/richrd/suplemon/blob/v0.1.40/suplemon/config.py#L99-L108
Although, I think this probably already exists as an open source module
I believe it's sometimes called JSON5

https://pypi.python.org/pypi/json5/0.2.4

After that, I suggest we start building our equivalent of sublime_api. Then, we can write tests for those since we know Sublime's API is quite solid.

Great to hear you've been testing testing and thanks for the detailed report! :+1:
On the braindump:
I agree with 1. and 2. These tests would definitely be good to have. Right now I've been rather busy so I'll have to dive deeper into this when I have proper time.
And wow, curses seems to be a big pain for testing :/. You seem to have tried many things, most of which I wouldn't have thought about. Respect for that!
Mocking curses is probably possible, but it would be hard to cover all the situations that might occur:

Resizing the terminal
Different terminals interpret some key combinations differently For instance Ctrl - Page Up and Ctrl - Page Down result in different input on different terminals. They are used to push line(s) up and down but they perform other operations on some terminals.
You can't draw characters outside the terminal bounds
On some terminals colors entirely or more than eight colors aren't supported
Trying to input or display special characters on python 2 curses fails
Some others problems that I don't remember (and probably more that I haven't seen yet)

At least it's possible to retrieve characters from the curses windows with window.inch (https://docs.python.org/3/library/curses.html#curses.window.inch). That might be helpful.
Other stuff:
I hadn't heard about JSON5. That seems great and perfect for the config use case. On the other hand I would like to have minimal external dependencies and the possibility of installing Suplemon directly from a .tar.gz. Maybe JSON5 can be packaged within Suplemon...
Then about sublime_api: It would be great to have it implemented, but I'm afraid that many of it's features might be hard to implement or such that they can't be done in the terminal (will at least need fallbacks or mocks). One of my big concerns is that I've been a bit lazy and haven't implemented regions (at least yet). I feel they will require lots of work and testing. Another thing that would be nice is bracket matching, but I don't yet have much ideas on how to implement it.
But I do agree with you about the API. I'll need some time to work on the core first and break up the App class etc though.
Thanks again for your help and interest :)

Update:
I came across this: http://sublime-text-unofficial-documentation.readthedocs.org/en/latest/extensibility/syntaxdefs.html . One point there scares me a little in regard to implementing sublime_api:

Several editing features in Sublime Text make extensive use of this fine-grained contextual information.

What makes you worried about it? Context is pretty useful with respect to any key stroke =/

Well, mostly the amount of work required to implement this "fine grained contextual information" in regard to the syntax parsing. I agree that it's important, but I'm afraid I might not have the time (or skills in the worst case) to get it done. For now Pygments has provided nice syntax highlighting, but I'm not sure how well it could be utilized in this context.
I'll need to look into that more and think about it.

In Sublime, syntax parsing is typically handled by .tmLanguage files.
https://github.com/twolfson/sublime-files/blob/3083.0.0/Packages/ASP/ASP.tmLanguage
These are grammars designed by TextMate.
https://manual.macromates.com/en/language_grammars
We should be able to either find an existing library or use something that can interpret well defined grammars (e.g. Bison).
One hurdle that we should get over though is using external dependencies. I know you don't want to install anything via pip. However, there are options like what requests does where it keeps those external packages as part of its releases:
https://github.com/kennethreitz/requests/tree/v2.7.0/requests/packages

Oh, good to know how the grammars work. An existing lib would of course be great, I'll see if I can find a Python lib for that.
On dependencies: I'm not at all against external dependencies, but my goal is to have Suplemon work without them. It's fine if that means that some features won't work, as long as it's usable. Even though only Python 3.3 or higher is supported officially I personally (and unfortunately) need Suplemon to be usable even on Python 2.6 :(. I hope to get rid of this need in the future.
That said, I'll look for existing solutions for interpreting the syntax. I don't think I'll have the resources to do it myself. Lets see :+1:

For Config and everything related, uses only std lib:
https://github.com/ssato/python-anyconfig#python-anyconfig
For Auto-Save Auto-Backup every N time, uses only std lib:
https://github.com/dbader/schedule#usage

Now that I'm on the rewrite train, I have a terminal backend implementatin for abstracting away curses and the terminal (https://github.com/richrd/suplemon/tree/rewrite-dev/suplemon/backends). The only backend implementation right now is curses, but a mock backend should be easy to write for testing.
Hopefully that would fix this https://gist.github.com/twolfson/e24af2d3d5424540492f#file-main-py-L14

Closing for now. I aim to add tests to the rewrite branch.


Add text to adjust threshold slider

To the side of the slider bar (which is great!) add a manipulatable text box so use can input a specific value instead of using slider if they're having trouble with it.

0.1 is great, but maybe we want the user to interact with thresholds up a magnitude of 100 so they don't have to deal with the decimal point.
like, 0.56 * 100 = 56


Use script to fix DNS settings

This should hopefully accomplish these things:

The user will no longer be prompted with annoying GUI pop-ups for
their admin credentials, once per network interface (via using sudo)
Only try to write settings for the network interfaces not already
using Google DNS
By using sudo, these settings should hopefully “stick” better between
logins.

This aspires to impact issues:

https://github.com/kristovatlas/osx-config-check/issues/44
https://github.com/kristovatlas/osx-config-check/issues/133


Update CDN links on docs

The previous release candidate is outdated. Changed to latest version.

Closing this out since we just released 4.0.7 and pushed the docs changes.


FRAME_SIZE_ERROR while enabling HTTP/2 for reqwest client

Hi,
I am trying to use reqwest with HTTP/2
Code:
let client_builder = reqwest::ClientBuilder::new();
    let client = client_builder.http2_prior_knowledge().build()?;
    let res = client.get("https://http2.io/").send().await?;
    println!("Headers {:#?}", &res.headers());
    println!("Content length: {:?}", &res.content_length());
    let mut stream = res.bytes_stream();

    while let Some(chunk) = stream.next().await {
        println!("Chunk Size: {:?}", chunk?.len());
    }
    Ok(())

Cargo.toml
reqwest = { version = "0.11.1", features = ["stream", "rustls-tls"]}
tokio = { version = "1", features = ["full"] }
futures-util = "0.3.13"

However, I am getting the following error - Error: reqwest::Error { kind: Request, url: Url { scheme: "https", username: "", password: None, host: Some(Domain("http2.io")), port: None, path: "/", query: None, fragment: None }, source: hyper::Error(Http2, Error { kind: Proto(FRAME_SIZE_ERROR) }) }
Can someone please guide me on what I am doing wrong?

HTTP/2 prior knowledge implies that you have "prior knowledge" that the server uses HTTP/2 directly, even without an ALPN step. The frame size error is the client reading the bytes received from the server, trying to understand them as an HTTP/2 frame, and since it isn't, reports an error that the size doesn't make sense.
Are you certain the server you're talking to supports HTTP/2?

I tried https://tools.keycdn.com/http2-test and the site supports HTTP/2. Unable to attach a screenshot in the comments.
Furthermore, I am able to use hyper-tls to query the same page -
    let mut http = HttpConnector::new();
    http.enforce_http(false);
    let mut config = ClientConfig::new();
    config.set_protocols(&["h2".into()]);
    config
        .root_store
        .add_server_trust_anchors(&webpki_roots::TLS_SERVER_ROOTS);
    let https: HttpsConnector<HttpConnector> = (http, config).into();
    let client = Client::builder()
        .http2_only(true)
        .build::<_, hyper::Body>(https);

    let mut res = client.get("https://http2.io/".parse()?).await?;
    println!("Status: {}", res.status());
    let headers = res.headers();
    println!("Headers:\n{:#?}", headers);
    let body = res.body_mut();
    while let Some(chunk) = body.data().await {
        let chunk = chunk?;
        println!("Chunk Size: {}", chunk.len());
    }

Produces the given output, hence the server should supports HTTP/2.
Status: 200 OK
Headers:
{
   "server": "openresty/<IP_ADDRESS>",
   "date": "Fri, 26 Feb 2021 20:01:39 GMT",
   "content-type": "text/html; charset=utf-8",
   "vary": "Accept-Encoding",
   "x-frame-options": "SAMEORIGIN",
   "x-xss-protection": "1; mode=block",
   "x-content-type-options": "nosniff",
   "x-download-options": "noopen",
   "x-permitted-cross-domain-policies": "none",
   "referrer-policy": "strict-origin-when-cross-origin",
   "etag": "W/\"bd6161b74e3f2b20c17c8c8a4e034831\"",
   "cache-control": "max-age=0, private, must-revalidate",
   "set-cookie": "bc9bd58fe1b6ef954d6d794db6d30e25e8ff50634d24346cf8006ef422e3c05c6e48b07678e34d08c97ad3f91012c80ac690b50f51fbd49b16e301de58d9c5ca=x4iMHGlvMBC1z1lB6tbGwUMHA%2B24HzQhV3erThH4Z7bPCy52OWO4drSMEAcpiFLKsKbmhsULax7vtyOZoFI538V1ixL8bXDbu2nu0%2FhZRs%2BR1kLOUpp%2F%2Fxa7150%2B5lDqglODDz%2BhyD4iLLgrSkUlyAK1vWxm6q6nFZ4r7KhOl5enYxvIv1BvCcA4TkZObcnbr9%2BFE8TME1y0ym6NpxSITttdekyro9Ov2zp6fUDJAMtj9Ab4wUc3wO%2B%2BrCVyMO2UVGINbDIH38R%2BlW%2Ftmrz3vvljPKWCDKp8Czqu4gr6rgfhtkeN8FhgVmNGnmUQjlEFkCL62V6Xw9K4nHwtlaHLZ3gUU39kkBvAhP34WSZtgjgNP3Tv619LFssjephNPJuRgrvk5oodFZ%2B%2BRnJ2KRi5FgmFVS%2FqSz1gLA3QvnxYNYqYF6Did%2BvXZEUE%2FspanSUCAw3DoqeZUPwD939XVaQlqw%3D%3D--tyELFstlzzd1wJ%2Bw--hPGYCpIkmnvVy4p39Xh%2FTQ%3D%3D; path=/; secure; HttpOnly",
   "x-request-id": "e97295c8-928c-42be-bab8-85b04b04aa50",
   "x-runtime": "0.080099",
}
Chunk Size: 8192
Chunk Size: 8192
Chunk Size: 8192
Chunk Size: 1034
Chunk Size: 8192
Chunk Size: 8192
Chunk Size: 2870
Chunk Size: 0

Furthermore a segment from client.rs code for reqwest looks like this, which makes me think that it is building the correct client with  http2_prior_knowledge( ) enabled.
/// Only use HTTP/2.
   pub fn http2_prior_knowledge(mut self) -> ClientBuilder {
       self.config.http2_only = true;
       self
   }

   #[cfg(feature = "__tls")]
           match config.tls {
             ...........

               #[cfg(feature = "__rustls")]
               TlsBackend::BuiltRustls(conn) => {
                   Connector::new_rustls_tls(
                       http,
                       conn,
                       proxies.clone(),
                       user_agent(&config.headers),
                       config.local_address,
                       config.nodelay)
               },
               #[cfg(feature = "__rustls")]
               TlsBackend::Rustls => {
                   use crate::tls::NoVerifier;

                   let mut tls = rustls::ClientConfig::new();
                   if config.http2_only {
                       tls.set_protocols(&["h2".into()]);
                   } else {
                       tls.set_protocols(&["h2".into(), "http/1.1".into()]);
                   }
                   #[cfg(feature = "rustls-tls-webpki-roots")]
                   if config.tls_built_in_root_certs {
                   tls.root_store
                       .add_server_trust_anchors(&webpki_roots::TLS_SERVER_ROOTS);
                   }
                   #[cfg(feature = "rustls-tls-native-roots")]
                   if config.tls_built_in_root_certs {
                       let roots_slice = NATIVE_ROOTS.as_ref().unwrap().roots.as_slice();
                       tls.root_store.roots.extend_from_slice(roots_slice);
                   }

                   if !config.certs_verification {
                       tls.dangerous()
                           .set_certificate_verifier(Arc::new(NoVerifier));
                   }

                   for cert in config.root_certs {
                       cert.add_to_rustls(&mut tls)?;
                   }

                   if let Some(id) = config.identity {
                       id.add_to_rustls(&mut tls)?;
                   }

                   Connector::new_rustls_tls(
                       http,
                       tls,
                       proxies.clone(),
                       user_agent(&config.headers),
                       config.local_address,
                       config.nodelay,
                   )
               },
     ........
   }

I have updated my Crago.toml file to include all the features in the code above:
reqwest = { version = "0.11.1", features = ["stream", "__rustls", "rustls-tls-webpki-roots", "__tls", "rustls-tls-native-roots"]}
tokio = { version = "1", features = ["full"] }
futures-util = "0.3.13"

Let me know i my understanding is incorrect here?

Hi,
Just checking, if there are any updates here?

We'd need more info to understand why it doesn't work with that site. Like, why is it different? If you try your example with other sites that definitely support HTTP/2, they should work, right?

I am afraid that's not the case. "https://http2.io/" was just an example. It is not working for any HTTP/2 supported sites. I tried with https://www.google.com/ (HTTP/2 supported according to https://tools.keycdn.com/http2-test). This results in the following error.
Error: reqwest::Error { kind: Request, url: Url { scheme: "https", username: "", password: None, host: Some(Domain("www.google.com")), port: None, path: "/", query: None, fragment: None }, source: hyper::Error(Http2, Error { kind: Proto(FRAME_SIZE_ERROR) }) }

Ohhhh! I see the issue. The problem is that the default-tls feature is being used, which uses native-tls, and that doesn't support ALPN. And the servers don't support HTTP2 prior knowledge, only via ALPN.
If you either, set default-features = false, features = ["rustls-tls"] in your Cargo.toml, or you specifically tell the client builder to use rustls even if default-tls is enabled, via ClientBuilder::use_rustls_tls(), it should work. (Just tested locally it works with Google).

This works, thanks. :)
default-features = false did the trick. I already had features = ["rustls-tls"] included but looks like it needs default-features disabled.


Add volume control

+1 "unit" and -1 "unit" only

Add a "mopidy spot" for where the volume should be

I tapefied the amp.

I'm really amped for this PR.

We'll make sure nothing causes any impedance.

dj volume replies with the current volume level (0-10)
dj volume up|more|moar|+|++|+1 increases the volume by 1 level
dj volume down|less|-|--|-1 decreases the volume by 1 level
dj crank it increases the volume by 3 levels


Overzealous assumption of a dependency among two tasks if they work on the same directory.

Expected Behavior
If there are two tasks, say A and B, where task A produces output into a directory d and where task B uses d as an input, Gradle should not necessarily assume task B would depend on A. Assuming such a dependency merely on the fact that a directory is the output of some task and also the input of another task is overzealous.
For instance, if in fact it is known a priori that task A writes into d/a (meaning that a here is a subdirectory of d) and B reads from d/b there is no dependency between A and B, simply because they work on disjoint places; i.e., A and B may very well execute in any order, even concurrently, in this case (of course assuming that there are no other inputs/outputs of A and B that would not be disjoint). What is more, this is in fact independent of the fact whether d is an input or output of either task. As long as it is known that A and B work on disjoint files/directories below d, d could be very well an input and an output of both A and B.
Another example would be if it is known a priori that A only works on files that match the pattern *.css and task B only works on files that match the pattern *.js, while it is not actually known where they are located below d. A and B would equally work on disjoint resources; hence, a dependency should not necessarily be assumed (and execution may proceed in any order even concurrently).
The message/warning that Gradle 7 currently issues in such situations (see below) should be reformulated, at least. In fact, if you want to uphold the current behavior of Gradle 7, it appears to me that it is necessary to provide a way to explicitly specify that two tasks are independent in case they use the same directory as output/input, respectively. Conversely, you might want to consider abandoning this assumption entirely, meaning that two tasks that use the same directory as output/input respectively are considered independent unless an explicit dependsOn is specified. The latter appears cleaner and simpler to me, even if there might be a higher chance that someone shots itself into its feet; but this would be a programmer's error anyway. Am I right that this was in fact the behavior of Gradle until version 7?
Current Behavior
In the situation described above where /d is specified as an input and output of both A and B, Gradle 7.1.1 issues the following message at runtime:
Execution optimizations have been disabled for task ':B' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: '/d'. Reason: Task ':A' uses this output of task ':B' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.1.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.
  - Gradle detected a problem with the following location: '/d'. Reason: Task ':B' uses this output of task ':A' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.1.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.

Context
I'm using the gradle-minify-plugin and both tasks JsMinifyTask and CssMinifyTask to process *.js and *.css files, respectively. All these files are located below the same directory specified as the input and output for both tasks.
Your Environment
Gradle 7.1.1, Java 11.0.12, Mac OS 11.5.1.

Thank you for reporting!
Looking at the documentation of the minifier plugin, it actually suggest you use different input and output dirs:
minification {
    js { //this: JsMinifyTask
        srcDir = project.file("js")
        dstDir = project.file("build/js")
    }
    css { //this: CssMinifyTask
        srcDir = project.file("css")
        dstDir = project.file("build/css")
    }
}

So for your use-case, you are defining the src and dst dirs to be the same? Something like
minification {
    js { //this: JsMinifyTask
        srcDir = project.file("src")
        dstDir = project.file("src")
    }
    css { //this: CssMinifyTask
        srcDir = project.file("src")
        dstDir = project.file("src")
    }
}

In general, Gradle doesn't really handle the case well when the input and the output directory are the same. Note that it already does stop running tasks in parallel which work on the same output directories. We currently don't have a good solution for this, so we suggest folks to separate the input and output directories for the same task.
The deprecation message asks you to choose an ordering between the two tasks. This can be via dependsOn or mustRunAfter. So you should either do that or choose separate output directories.

The latter appears cleaner and simpler to me, even if there might be a higher chance that someone shots itself into its feet

The point of this deprecation message is to make sure you don't shoot yourself in the foot.

So for your use-case, you are defining the src and dst dirs to be the same?

Yes, indeed. However, the fact that the same directory should not be used doesn't mean it must not be used. I consider this a perfectly fine use case (provided on knows that this will not create conflicts that might result in arbitrary effects). Second, this aspect is actually just a side aspect and it is specific to the plugin. It should not be used to divert attention from the real problem - the problem that I wanted to make you aware of by opening this issue. Let me continue.
This issue shows that Gradle shifts to follow a principle in which it would be ok to get into the way of build script developers, justified by the initially noble goal that this would avoid making mistakes (e.g., not using the same directory as an input and output for the same plugin, or different plugins if their execution order is neither implicit nor explicit). Well, let me say this straight: this is small-man's behavior. If there exist use cases in which the situation described above will not cause problems you should not block them. Just because there have been substandard developers that f***ed up their build scripts by not really knowing what they were doing (missing knowledge that two Gradle plugins that work on shared resources might create unintended effects if their execution order is arbitrary) is poor justification for such a decision. Only if no such use case exists the decision would be justified.
More generally, the deprecation message mentioned above and the fact that you intend to disallow the situation described above in a future Gradle version (>= 8?) is one more instance of a violation of the famous design principle: be liberal in what you accept, be conservative in what you do.
The situation described above should be allowed and you should not get into the way of a build script developer by preventing him/her from doing this in future versions of Gradle. Don't take the substandard as the new standard - you are making yourself smaller. If you want to insist in the check and the message mentioned above, I hereby propose (i) to rephrase it to be more of a warning (something like "hey, you might have specified a build that might cause problems for you; go rather check this and that"), (ii) that does also not pop up as lifecycle message, and most importantly (iii) do not fail the build in such situations. It's the developer's responsibility to get it's stuff right; you can support him/her in doing so but keep your opinions for yourself as long as nobody explicitly asks for them.

(i) to rephrase it to be more of a warning (something like "hey, seems you have specified a build that might cause problems for you; go rather check this and that"), (ii) that does also not pop up as lifecycle message

Unrelated to this issue, the idea just jumped into my mind that a "Gradle Linter" should do such things. Having such a tool would be cool. I know that Build Scans already go into this direction but still, I think this would be a great extension to Gradle. Also, this would allow to better separate concerns. I guess many of the checks that are currently implemented in Gradle could be moved into such a dedicated tool and gradle[w] could concentrate on being a Gradle build engine (i.e., on the execution part).
(I'm just writing this to save this idea. If you equally find this a good idea, I could open a dedicated feature request issue.)

Yes, indeed. However, the fact that the same directory should not be used doesn't mean it must not be used.
This issue shows that Gradle shifts to follow a principle in which it would be ok to get into the way of build script developers, justified by the initially noble goal that this would avoid making mistakes

This is not only about novice developers shooting themselves in the foot, such practices have performance implications. For example, the task you described above can't be cacheable. Moreover, Gradle doesn't cache the state of the directory between builds, since it is currently not supported for file system watching.
So the practices you describe make it impossible or much harder for Gradle to do its optimizations. If you want to continue to use the practice, you can also opt-out of Gradle's optimizations by using Task.doNotTrackState().
In general, Gradle wants to make it simpler to write correct and performant tasks and plugins. Therefore, it won't be more liberal in what plugin code it accepts, it will become stricter over time.
Though we do not want to reduce the number of use-cases you can solve with Gradle. As you see yourself, this is a thin line with what we want to achieve. This brings me back to your use-case: Why is it important for your build that the minified and the non-minified files are in the same directory?

@wolfs This is just to inform you that I don't have time during the next days to give a detailed answer, especially to your last question. I'll try to find time on the weekend.

Why is it important for your build that the minified and the non-minified files are in the same directory?

As simple as it is, it keeps the build simpler. We want minified as well as non-minified files to be siblings (i.e., located in the same folder, with the additional difference that minified files have the classifier -min in their name. Both variants are processed afterwards by three more tasks down the pipe (filtering, deflating, see below, and finally packaging).
If we would need to specify another output folder for the minified variants (because a future Version of Gradle would force us to do so), we would inevitably have them temporarily in a different location. This would require us  to bring them back together into the same place (because we want them to be siblings of the non-minified variants), probably by yet another task.
What is more, we apply the same processing pattern to create GZipped variants of both the non- and minified variants, also as siblings (i.e., *.js, *-min.js, *.js.gz, *-min.js.gz are all siblings. The Gzip task also uses the same input and output folder. Finally, this processing pattern is equally applied to minify and Gzip CSS stylesheet files.
Obviously, there would be ways to get around a future limitation of not being allowed to specify the same folder as an input and output. But, why? It would be really just a limitation.
Which brings me to come back to these two statements:

In general, Gradle doesn't really handle the case well when the input and the output directory are the same.

So the practices you describe make it impossible or much harder for Gradle to do its optimizations.

So is the problem here the practices described, or is the problem the rather naive approach to deciding what optimizations can be applied when? Correct me if I'm wrong, from what I read, I conclude that at least one criteria to disable certain optimizations (most probably caching and concurrent execution) in Gradle is the situation that a task has an input and output that are the same folder; or the constellation described by me at the very beginning of this issue. Sorry to say, this is naive. I see no strategy that is worser than this. Even a simple MRSW strategy would be better. The moment I see such things, I have to think about how coordinating/optimzing concurrent access on shared resources in databases works. Perhaps you should think about an approach that follows how this is essentially done by all database coordination approaches: (i) define the notion of a changeset for a task (e.g., the files it is working on), (ii) define the operations a task may perform on the elements (files) of a changeset (e.g., read and write), (iii) come up with a conflict matrix over those operations (i.e., those operations that may run concurrently and those that don't - that conflict) and (iv) come up with a protocol to enforce sequential execution of conflicting operations. In such a model, even the case of a single task that may perform conflicting operations on shared resources concurrently would fit in.
Anyway, let me repeat what the intention of this issue was. A Gradle build that produces warnings like this
Execution optimizations have been disabled for task ':B' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: '/d'. Reason: Task ':A' uses this output of task ':B' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.1.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.
  - Gradle detected a problem with the following location: '/d'. Reason: Task ':B' uses this output of task ':A' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.1.1/userguide/validation_problems.html#implicit_dependency for more details about this problem.

finally completed by the message
Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

should not become incompatible with Gradle 8.


load_all_operators docs mistake

load_all_operators is displayed as load_operators in the docs.

That is actually correct. load_all_operators() is for versions 1.x.x while load_operators() is for versions 2.x.x.
I admit that putting that into the docs while the version is not fully out (but on another branch and on pypi as a pre-release), I've done the docs a while back and since v2 is public I've felt like having the docs for it is a good thing


Get the correct socket infor in case of ipv6.

That was quick, thank you :-)
My thoughts on the code:

We should probably wrap this up into a small helper function to reduce duplication: get_host_port(socket) -> host, port.
Explicit checks on AF_INET, rather than a simple else would ensure this can't happen again. If the address family isn't recognised at all, we should raise a ProtocolError.
Tests.

Have you signed our CLA? I'm happy to work on this otherwise.

Agree with all. I still didnt figure out yet how correctly run the tests.
Thanks.

./runtests.sh should do it though you'll need to pip install boltkit -r test/requirements.txt first.

Thanks. I just agreed the CLA and i the tests passed in my local machine but unfortunately they are failing in the CI

Closing this PR as this has now been added in https://github.com/neo4j/neo4j-python-driver/commit/6c5f6fb2e67c57ebdcb520e3ced38e180c476229


.Net: Advertise OpenAPI skills parameters

[!IMPORTANT]
Labeled High because it will not require a breaking change, but it's very important to complete by v1.0.0

when we load open ai skill we need to know what parameters can be used. Today, the planner is only told about a "payload" property for POST/PUT operations without any details on what should be in the payload.

Marking this as closed since this has been addressed.


libpng

A patch to allow for using the system library is included here: https://github.com/nicholas-rh/o3de-rpm/blob/ba85072e74feeca867ef3637e3b536cec6d14f4f/copr/o3de/SystemPackages_linux.patch#L77


Issue 471 provider fees

Fixes #471
Changes proposed in this PR:

Tracking providerFee event
Saving providerFee as a string inside order
Creating orderUtils.ts

looks ok for now, will wait for a full sync

Added providerFeeValidUntil for easy check.
@jamiehewitt15 i deleted my comment ,ignore it, didn't pay attention
@soonhuat is this structure ok for you?

Added providerFeeValidUntil for easy check. @jamiehewitt15 i deleted my comment ,ignore it, didn't pay attention
@soonhuat is this structure ok for you?

@mihaisc
i think should be fine, could deserialize on market or any client if need the full data, while using providerFeeValidUntil value most of the scenarios


CSS url() doesn't work

I haven't tested this, but I'm pretty sure it won't work because of the way we handle non-Svelte dependencies. We'd need to absolute-ify the paths in any .(s)css files that are entry dependencies.
CSS url() should work fine if it's inside of a style block in a Svelte component. Maybe this is a wont-fix, and that's the best workaround: can't put it in global styles, only in component-scoped styles. Sounds kind of annoying for the user to have to deal with.

Note: precinct could help with getting the url() deps.

So, this actually will work if your assets are in the public directory. That's where all static assets go; I don't know that there'd be a need for a non-static file, since it wouldn't get processed anyway?

Closing this, but need to add a note in the docs that it only works with an actual (remote) URL or a path within the public directory.

I think this is actually still a bug. The path in the output CSS is not resolved properly. If this is because of config, it needs to be documented.

Looking at this again, and the most reliable temporary fix is to use the relative path to the output files. This only works on the index page.
.bg-img {
  background: url('../background.jpg');
}

Assuming background.jpg is at: /static/background.jpg at the root of your project.
If you look at the .cayo/ folder, you'll see that this... actually doesn't make sense how it works in dev. I think we're witnessing some helpful Vite magic. During build, the path makes sense because the output .css is in the assets dir, to ../ up one level gets you to the root of the dist dir.
The real library solution is to process the CSS and properly add the right relative path based on the page that CSS belongs too (which determines the output file structure/where the CSS file will be, thus where the image will be, relatively). Or maybe something else... idk.

Alternatively, in a similar line of thought: maybe use global styles? This could be another workaround that could work for all pages, and components.
Create a global stylesheet in static/ that references the relative path. All Static files get copied into dist/, without adjusting where they are (i.e., like running cp static/* dist/). Using that global stylesheet might allow this url(<path>) to work inside of any component, as long as the global stylesheet is imported in the template, since all pages will get the template CSS as a dependency in their output.
Using an SCSS @import in the template style block might cause issues (pretty sure Sass import resolution is handled differently, but Sass). If it does, using a <link> in the template should likely work. E.g., <link rel="stylesheet" href="global.css"> with the actual stylesheet at /static/global.css.


setlanguage command

New property in GuildSpecifics controls language of returned messages to a guild. New command setlanguage to set that property.
Also nicknames DirectoryBot to localized name.

Use guild.preferredLocale as reasonable default.


Autoprompt the user to switch network in the connect button

If the user is connected to a network other than Goerli, ask the user to change network to Goerli

Hey @aguzmant103
I've got part of the fix. We send in the supported chains as 5. Basically, this means the user can't hook up their wallet unless they're on Goerli. Though, I'm not totally sure if the user experience will be great with this. By the way, we're using @web-react/core v6.

Do you have a working fork to test? I initially feel that's still an acceptable UX but dunno, @vplasencia what do you think?

Code : https://github.com/SrinivasJoshi/bandada. This is what it looks like :
https://github.com/privacy-scaling-explorations/bandada/assets/69837749/ae72863d-7f62-49a2-8900-3057f203ac2c

Hey @SrinivasJoshi ! Thank you so much for the idea, for implementing it and creating the video to show it. I think that your idea is a good alternative to solving this problem.
You are working on the client app. I think that this app is fine. Here, the wallet is used to sign a message to generate the Semaphore identity.
The problem is the dashboard app, it is http://localhost:3001 locally. When you connect your wallet in the dashboard app, it asks you to switch if you're not in the right network, but if after that, you change the network manually in the wallet and try to create an on-chain group or add a member to an on-chain group for example, it will say: Some error ocurred!. The idea is that the app knows at all times if you're on the right network, so in case you're not on the right network, it will ask you to change the network.
I think that the solution will be something like this button on the top right. The difference would be that when the user is not on the right network, the button should say Switch network instead if Wrong network.
https://www.rainbowkit.com/docs/introduction
The dashboard app is using @rainbow-me/rainbowkit.
Let us know if you have more ideas, questions or feedback.

Got it, thanks! I'll focus on the dashboard app issue 😅

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I’m a blockchain developer with a background in building decentralized apps on Ethereum. I’ve spent a lot of time working with React.js, focusing on creating user-friendly interfaces that integrate smoothly with blockchain technology.
With Next.js, I can ensure the network check and prompt are efficiently integrated into the app’s architecture, making the user experience smooth
How I plan on tackling this issue
Check the network the user is connected to.
Prompt the user to switch to Goerli if they are on a different network.
Handle errors when the network is not available in MetaMask and request to add it.
We can use ethers js to implement this feature.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I would like to contribute to this problem
could you assign this to me?

Hey @SIDHARTH20K4! Do you want me to assign this issue to you?

@vplasencia
yes please and kindly tell me how do I approach this problem.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
Hi I have been participating in hackathons from past 3 years and worked as full stack developer for 2 DEFI COMPANIES I have immense knowledge of how all dapps are built
How I plan on tackling this issue
When a user connect his wallet we check whether he is connected to our required network or not then he will have a request to change his network to our desired network just a simple task

@vplasencia
may I work on this issue?

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
As a blockchain developer specializing in Solidity, I have extensive experience deploying smart contracts across multiple Ethereum-compatible networks. I’ve worked on various decentralized applications (dApps) and smart contracts for token management, voting systems, and financial applications. My background includes deep familiarity with testnets such as Goerli (now deprecated) and Sepolia, which is currently the preferred testnet.
I have leveraged my Solidity and blockchain architecture to ensure that dApps run securely on the correct network. My ability to design contracts that integrate seamlessly with frontend requirements can help manage scenarios where users need to interact with the proper network, like Sepolia in this case.
How I plan on tackling this issue
Now that Goerli has been deprecated, I would prompt users to switch to the Sepolia testnet instead of Goerli. Here’s how I would approach the problem from a backend and Solidity perspective:
Firstly, I would ensure that the smart contract is restricted to be deployed and interacted with only on the Sepolia testnet. Also, I would collaborate closely with frontend developers to ensure that they are aware of the network requirement (Sepolia) and can implement the necessary Web3 wallet prompts for network switching. Then, If users attempt to interact with the contract on the wrong network, I would ensure that the contract returns informative error messages that make it clear they are on the wrong network. These errors can then be captured and displayed in the frontend, helping users understand the need to switch networks to Sepolia.

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
I am  full stack blockchain developer I have build dapps using solidity and typescript.
By leveraging my technical skills and industry knowledge I can add this feature
How I plan on tackling this issue
Call this checkNetwork() function when your app loads or when performing transactions to ensure the user is connected to Goerli.
Detect Current Network using chain ID . It checks if the user is on Goerli and prompts them to switch if not.
If Goerli is not available in MetaMask, it attempts to add it.
Use libraries like ether.js and web3.js if needed

I am applying to this issue via OnlyDust platform.
My background and how it can be leveraged
Hello i want to take on this task

Hey @SIDHARTH20K4 @Tchisom17 @Dhanraj30 @Benjtalkshow
Thank you very much for the interest on this issue. I had to assign the issue to myself because it will be part of another issue because it will be necessary to update the wallet dependencies. Since updating the dependencies can cause updating many parts of the project and take a lot of time because there was a similar situation when trying to update ethers recently, I removed the good first issue label and created a new issue (please see the new issue for more context: https://github.com/bandada-infra/bandada/issues/550) to solve some issues related to the Wallet.
Sorry about that. If you are still interested in contributing, please take a look at the good first issues here and feel free to ask for any other. I will be adding more good first issues soon. Thank you very much 🙏


"beforeSave" Cloud function causes an error during a POST command on Heroku.

My Parse-server-example repo on GitHub was deployed to Heroku (NOT via the Heroku button) via deployment of my GitHub repo.
I used a cURL POST command line trying to add a new record in the GCUR_OBSERVATION class on my MongoLab hosted database,
curl -X POST -H "X-Parse-Application-Id: MY_APP_ID" -H "X-Parse-Master-Key: MY_MASTER_KEY" -H "Content-Type: application/json" -d "{\"ObservationStatus\":0}" https://{MY_APP}.herokuapp.com/parse/classes/GCUR_OBSERVATION
A beforeSave Cloud function was defined in the Cloud code file "main.js" for the GCUR_OBSERVATION class as below:
Parse.Cloud.beforeSave("GCUR_OBSERVATION", function(request, response) {
	console.log("*** beforeSave on GCUR_OBSERVATION called");
	Parse.Cloud.useMasterKey();
	sharedWithJurisArr = [];
	console.log("*** FLAG 1");
	if(!request.object.existed()) {
		console.log("*** FLAG 2");
		var sharedJurisSettingsQ = new Parse.Query("GCUR_SHARED_JURIS_SETTINGS");
		console.log("*** FLAG 21");
		sharedJurisSettingsQ.find().then(function(sjsObjs) {
			console.log("*** FLAG 22");
			for (var i = 0; i < sjsObjs.length; i ++) {
				var jurisdiction = sjsObjs[i].get("Jurisdiction");
				console.log("*** jurisdiction:" + jurisdiction);
				sharedWithJurisArr.push(jurisdiction);
			}
			console.log("*** FLAG 23");

			var sharedByArr = [];
			console.log("*** FLAG 24");

			for (var i = 0; i < sharedWithJurisArr.length; i ++) {
				sharedByArr.push({
					"st" : sharedWithJurisArr[i],
					"sh" : true
				});
			}
			console.log("*** FLAG 25");

			request.object.set("SharedBy", JSON.stringify(sharedByArr));
			console.log("*** FLAG 3");
			response.success();
		});
	} else {
		console.log("*** FLAG 4");
		response.success();
	}
});

Heroku logs showed the following messages after the cURL POST request was made:
2016-02-25T11:50:54.199259+00:00 app[web.1]: *** beforeSave on GCUR_OBSERVATION called

2016-02-25T11:50:54.199268+00:00 app[web.1]: *** FLAG 1

2016-02-25T11:50:54.199293+00:00 app[web.1]: *** FLAG 2

2016-02-25T11:50:54.199326+00:00 app[web.1]: *** FLAG 21

2016-02-25T11:51:24.195056+00:00 heroku[router]: at=error code=H12 desc="Request timeout" method=POST path="/parse/classes/GCUR_OBSERVATION" host=nemp-qld-test.herokuapp.com request_id=d517a443-f264-4adb-83db-f2c077c9da71 fwd="<IP_ADDRESS>" dyno=web.1 connect=0ms service=30001ms status=503 bytes=0service=30001ms status=503 bytes=0

I have tried the similar cURL POST command line to add a new record to any other class that does **not **have a beforeSave cloud function defined. But that worked.
So I am guessing it was the beforeSave function that caused the error.

Seems that your query is failing, we have some issues reported with querying in CloudCode that would not work properly like #356. Can you confirm by adding a .fail(function(err) {console.error(err); response.error(err)}  to sharedJurisSettingsQ.find()

In the node environment, Parse.Cloud.useMasterKey() is not valid.  You should pass the useMasterKey: true option to query calls and saves to use the master key.
query.find({ useMasterKey: true }).then(...

obj.save(null, { useMasterKey: true }).then(...

Between this and adding the proper error handlers, I think you'll discover your issue.  Please re-open or create a new issue if you have problems.  Thanks.


Set visible data depending on a moving time window

Hi! I am trying to visualize the data in a TimeChart according to a moving window. By that I mean, for example, in a chart with 1000 data points:

On frame 1: Show data points with timestamps (x axis) from 1 to 100
On frame 2: show datapoints with timestamp from 2 to 101
Frame 3: 3 to 102

I have tried multiple different ways:

Set Plot Scale by Range updated on tick (freezes the editor)
Create a new datasource with only the visible subset of data points to be shown for that frame (it's slow, and also the chart's scale updates to include all points the chart has ever seen, so on frame 3 I see points 1 to 102)
On every tick, remove all series from the data source and re-add the data points to be shown for that frame only (same problem as above)

Is there another way to achieve this?
Thanks in advance!

Actually never mind, I saw your youtube video and realized that the primary use case you had in mind was to plot a moving window on realtime data. I was trying to get something slightly different, but if I just go for something similar to your example then it's obvious how to achieve it with the axis settings. Thanks!


Lost_And_Found

Added details about Lost_And_Found functionality

Docs Build status updates of commit 65a0777:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Update-PublicFolderMailbox.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 347271b:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Update-PublicFolderMailbox.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit bac43b9:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Update-PublicFolderMailbox.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 8029f75:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Update-PublicFolderMailbox.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit 3f95164:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

exchange/exchange-ps/exchange/Update-PublicFolderMailbox.md
:white_check_mark:Succeeded
View (exchange-ps)

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


Shared: Common static assets like images

#92 introduced a shared SPA experience across guardian and gateway UIs and these live in @fedimint/ui package. However, these UI's duplicate static assets in some scenarios (like the Fedimint logo, copy icons, etc.) because we don't have a good pipeline for bundling such assets.

SVGs nicely side-step this issue, since they can get bundled as React components. Static assets like images and fonts will always need to ultimately be imported by the app that uses them though, not the package itself. This is because it's the app's bundler that will manage linking static assets.
The approach in https://github.com/fedimint/ui/blob/master/packages/ui/src/Header.tsx is fine, but could be more ergonomic by using something like svgr to do the transformation of regular svg files into JSX components at compile time: https://github.com/egoist/tsup/discussions/811. That way assets could be kept as raw svg files rather than giant JSX blobs in the middle of components.

See #178 for an approach on how to share assets across projects (that PR handles fonts, but the same approach would work for any binary asset like images)


🐃 No code to check that review.rating is actually between 1-5

We currently don't check that a review rating coming from IPFS is between 1-5. This would allow an evil reviewer to mess up any future aggregated review rating score for someone by submitting an out of range review.

Good catch. Seems we should add some checks to cap rating between 1-5 in origin-js when writing and reading review data from IPFS.
BTW, what are we deciding on rating value. Is it an integer, one of [1,2,3,4,5] or is it a float between 1.0 and 5.0 ? I'd favor using integer for now to keep things simple. Any objections ?

I'm good with changing it to an integer.