Deprecation Warning for sass

What happened?

Minimal Mistakes version: 4.24.0
Ruby gem or remote theme version: Ruby Gem
Jekyll version: 4.3.1
Git repository URL: private repo
Hosted on GitHub Pages (if yes provide URL to site): No
Operating system: Linux

Expected behavior
expected output: (ignore the remote: part)
remote: Configuration file: /home/mattrose/tmp/newrepo/_config.yml
remote:             Source: /home/mattrose/tmp/newrepo
remote:        Destination: /var/www/html
remote:  Incremental build: disabled. Enable with --incremental
remote:       Generating...
remote:        Jekyll Feed: Generating feed for posts
remote:                     done in 1.481 seconds.
remote:  Auto-regeneration: disabled. Use --watch to enable.

Steps to reproduce the behavior
Multiple instances of: Deprecation Warning: Using / for division outside of calc() is deprecated and will be removed in Dart Sass 2.0.0. like this
Deprecation Warning: Using / for division outside of calc() is deprecated and will be removed in Dart Sass 2.0.0.

Recommendation: math.div($gutters, $container) or calc($gutters / $container)

More info and automated migrator: https://sass-lang.com/d/slash-div

    ╷
144 │   @return percentage($gutters / $container);
    │                      ^^^^^^^^^^^^^^^^^^^^^
    ╵
    ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_su-math.scss 144:22         su-gutter()
    ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_syntax-helpers.scss 190:11  su-call()
    ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_api.scss 205:11             susy-gutter()
    ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_unprefix.scss 37:11         gutter()
    ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_archive.scss 166:20                          @content
    ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/breakpoint/_breakpoint.scss 66:7       breakpoint()
    ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_archive.scss 155:3                           @import
    minimal-mistakes.scss 38:9                                                                                @import
    /netvol/home/mattrose/Code/newblog/assets/css/main.scss 4:9

Other
Full out:
remote: Configuration file: /home/mattrose/tmp/newrepo/_config.yml
remote: To use retry middleware with Faraday v2.0+, install `faraday-retry` gem
remote:             Source: /home/mattrose/tmp/newrepo
remote:        Destination: /var/www/html
remote:  Incremental build: disabled. Enable with --incremental
remote:       Generating...
remote:        Jekyll Feed: Generating feed for posts
remote: DEPRECATION WARNING: Using / for division is deprecated and will be removed in Dart Sass 2.0.0.
remote:
remote: Recommendation: math.div(9, 16)
remote:
remote: More info and automated migrator: https://sass-lang.com/d/slash-div
remote:
remote:    ╷
remote: 31 │ $mfp-iframe-ratio:                    9/16;                       // Ratio of iframe (9/16 = widescreen, 3/4 = standard, etc.)
remote:    │                                       ^^^^
remote:    ╵
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/magnific-popup/_settings.scss 31:39      @import
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/magnific-popup/_magnific-popup.scss 3:9  @import
remote:     minimal-mistakes.scss 13:9                                                                                @import
remote:     /home/mattrose/tmp/newrepo/assets/css/main.scss 4:9                                                               root stylesheet
remote: DEPRECATION WARNING: Using / for division outside of calc() is deprecated and will be removed in Dart Sass 2.0.0.
remote:
remote: Recommendation: math.div($value, 16px) or calc($value / 16px)
remote:
remote: More info and automated migrator: https://sass-lang.com/d/slash-div
remote:
remote:    ╷
remote: 28 │     @return $value / 16px * 1em;
remote:    │             ^^^^^^^^^^^^^
remote:    ╵
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/breakpoint/_helpers.scss 28:13                base-conversion()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/breakpoint/_helpers.scss 20:13                breakpoint-to-base-em()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/breakpoint/parsers/single/_default.scss 8:29  breakpoint-parse-default()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/breakpoint/parsers/_single.scss 22:14         breakpoint-parse-single()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/breakpoint/_parsers.scss 153:18               breakpoint-parse()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/breakpoint/_parsers.scss 48:22                breakpoint()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/breakpoint/_breakpoint.scss 46:16             breakpoint()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_reset.scss 13:3                                     @import
remote:     minimal-mistakes.scss 18:9                                                                                @import
remote:     /home/mattrose/tmp/newrepo/assets/css/main.scss 4:9                                                                    root stylesheet
remote: DEPRECATION WARNING: Using / for division outside of calc() is deprecated and will be removed in Dart Sass 2.0.0.
remote:
remote: Recommendation: math.div(5px, 2) or calc(5px / 2)
remote:
remote: More info and automated migrator: https://sass-lang.com/d/slash-div
remote:
remote:    ╷
remote: 28 │     margin-bottom: (5px / 2);
remote:    │                     ^^^^^^^
remote:    ╵
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_forms.scss 28:21  @import
remote:     minimal-mistakes.scss 20:9                                                           @import
remote:     /home/mattrose/tmp/newrepo/assets/css/main.scss 4:9                                  root stylesheet
remote: DEPRECATION WARNING: Using / for division outside of calc() is deprecated and will be removed in Dart Sass 2.0.0.
remote:
remote: Recommendation: math.div(($red * 299) + ($green * 587) + ($blue * 114), 1000) or calc((($red * 299) + ($green * 587) + ($blue * 114)) / 1000)
remote:
remote: More info and automated migrator: https://sass-lang.com/d/slash-div
remote:
remote:    ╷
remote: 68 │   $yiq: (($red*299)+($green*587)+($blue*114))/1000;
remote:    │         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
remote:    ╵
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_mixins.scss 68:9   yiq-is-light()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_mixins.scss 81:14  yiq-contrast-color()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_mixins.scss 91:10  yiq-contrasted()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_buttons.scss 46:7  @import
remote:     minimal-mistakes.scss 25:9                                                            @import
remote:     /home/mattrose/tmp/newrepo/assets/css/main.scss 4:9                                   root stylesheet
remote: DEPRECATION WARNING: Using / for division outside of calc() is deprecated and will be removed in Dart Sass 2.0.0.
remote:
remote: Recommendation: math.div($span-width, $container) or calc($span-width / $container)
remote:
remote: More info and automated migrator: https://sass-lang.com/d/slash-div
remote:
remote:    ╷
remote: 93 │     @return percentage($span-width / $container);
remote:    │                        ^^^^^^^^^^^^^^^^^^^^^^^^
remote:    ╵
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_su-math.scss 93:24          su-span()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_syntax-helpers.scss 190:11  su-call()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_api.scss 146:13             susy-span()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_unprefix.scss 19:11         span()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_utilities.scss 185:24                        @content
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/breakpoint/_breakpoint.scss 66:7       breakpoint()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_utilities.scss 184:3                         @import
remote:     minimal-mistakes.scss 34:9                                                                                @import
remote:     /home/mattrose/tmp/newrepo/assets/css/main.scss 4:9                                                             root stylesheet
remote: DEPRECATION WARNING: Using / for division outside of calc() is deprecated and will be removed in Dart Sass 2.0.0.
remote:
remote: Recommendation: math.div($gutters, $container) or calc($gutters / $container)
remote:
remote: More info and automated migrator: https://sass-lang.com/d/slash-div
remote:
remote:     ╷
remote: 144 │   @return percentage($gutters / $container);
remote:     │                      ^^^^^^^^^^^^^^^^^^^^^
remote:     ╵
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_su-math.scss 144:22         su-gutter()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_syntax-helpers.scss 190:11  su-call()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_api.scss 205:11             susy-gutter()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/susy/susy/_unprefix.scss 37:11         gutter()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_archive.scss 166:20                          @content
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/vendor/breakpoint/_breakpoint.scss 66:7       breakpoint()
remote:     ../../../../minimal-mistakes-jekyll-4.24.0/_sass/minimal-mistakes/_archive.scss 155:3                           @import
remote:     minimal-mistakes.scss 38:9                                                                                @import
remote:     /home/mattrose/tmp/newrepo/assets/css/main.scss 4:9                                                             root stylesheet
remote:                     done in 2.493 seconds.
remote:  Auto-regeneration: disabled. Use --watch to enable.

I see this too. Would you appreciate a PR for this? I can do it.

yes, me too

same

I see this too. Would you appreciate a PR for this? I can do it.

I would love a PR.  I could struggle through it, but you could probably do a much better job of it.

ok, @mattrose, to be specific, I was asking the maintainer of the repo @mmistakes if he would accept one, because I would like to see if it's worth the effort.

I saw similar issues after doing a bundle update

jekyll-sass-converter was updated to use a different implimentation of Sass. This is why you're seeing warnings and errors because the Sass written for this theme uses the Ruby version (now deprecated) and would need to be refactored to support Dart Sass.
The problem with doing this is remote theme version which leans on the github-pages gem doesn't use the latest and greatest version of Jekyll or jekyll-sass-converter. So I don't think the Sass can be updated as it would break for the tons of users building sites on GH Pages.
The solution is to lock jekyll-sass-converter to the previous version.
https://github.com/jekyll/jekyll-sass-converter/issues/145#issuecomment-1363069829

remote theme version which leans on the github-pages gem doesn't use the latest and greatest version of Jekyll or jekyll-sass-converter.

I doubt that github-pages is ever going to bump to Jekyll 4+ and adopt major releases of plugins now that they have GitHub Actions to ensure sandboxed builds.
Besides, remote-theme users have the option to lock to a working git ref of the theme as well.

+1

To anyone interested in submitting a pull request, you may try updating the theme documentation to recommend setting quiet_deps: true to the sass config object:
# _config.yml

sass:
  quiet_deps: true    # Disable printing deprecation warnings to terminal

I guess the question of whether to update this theme to support dart sass or not comes down to whether the theme should pin itself to old versions of dependencies to remain compatible with old gh_pages users, or should look to move forward with dependencies.
IMHO, I think there is a strong argument to move forward with dependencies.  New users should build github pages via actions, so things will work fine for them.  Existing users using actions are also OK with this. It's only existing users using the out dated way of building GH pages that are affected.  I'd document they have two options:

Switch to using actions
Pin the theme version.

Personally, keeping this theme up to date is much better than pinning it in the past, just for the sake of users using outdated ways of using the theme, who have the two above choices to work around things.
To put this another way, you've got two broad sets of users: those updating dependencies & processes and those that don't. The first group is being affected by this issue as they're trying to do the right thing and keep things up to date. Where are the second group probably are mostly unaware of the issue as they don't update their dependencies, including the theme version.

I am also in favour of updating to the newer versions, as over time more and more other features will require them.
It would be good to get a maintainer call on this before someone does the work.

So what is the recommended path forward on this? I saw some suggestions, but not sure what the best path forward is. I can certainly silence the deprecation warnings (and will temporarily), but that seems fraught with peril.

I wonder how many people buying him a coffee would be enough to encourage him to spend some time on this? :)

add @use "sass:math"; in minimal-mistakes.scss

and change all a / b to math.div(a, b)

add @use "sass:math"; in minimal-mistakes.scss  and change all a / b to math.div(a, b)

Does this work with sassc though?


Selection sort

Selection Sort successfully added in Java. Solves #69 .

[x] I've checked the issue list BEFORE deciding what to submit
[x] I've read the contribution guidelines
[x] I've edited the README.md link to my code

@ricardoprins  Please review.

Good work :) thank you @parjanyaacoder


Indentation rules not working correctly?

Hopefully this is just me, but using the playground I added this:
monaco.languages.setLanguageConfiguration('mySpecialLanguage', {
indentationRules: {
decreaseIndentPattern: /(| project)/,
increaseIndentPattern: /(| LinkedWorkItems)/,
indentNextLinePattern: null,
unIndentedLinePattern: null
}
});
When I enter a "| LinkedWorkItems" it correctly indents. However, at no time afterwards does entering "| project" outdent the indentation again. Did I miss something here? I can't figure out how to even verify what text pattern it is trying to match against. I tried using tabs, spaces, heck I even went to .*| project to no avail.

One other note - I tried this rule:
monaco.languages.setLanguageConfiguration('mySpecialLanguage', {
indentationRules: {
decreaseIndentPattern: /(| project .)/,
increaseIndentPattern: /(| LinkedWorkItems)/,
indentNextLinePattern: /(| project .)/,
unIndentedLinePattern: null
}
});
And it did indeed indent a further level after the | project abcdef line and then outdented. So I know it's recognizing the | project .* pattern but it just seems like the decreaseIndentPattern rule is not working. If I set it to \w* it does decrease the indent but obviously that pattern is too broad for use. I just can't figure out where/how it is interpreting this rule to see if it's an actual bug.

@jefflevinson this PR https://github.com/Microsoft/vscode/pull/16568 aims to mitigate this issue.

The PR got merged so this issue must have been fixed in the meantime.


Smooth all ppem sizes

The current GASP setting in the fix_unhinted_font tooling actually turns on hinting across the entire range.  This fix corrects that.
Additionally, once the hinting has been turned off, the prep table modification has no impact on font rendering, so that code has been removed as well.

Thanks for the pr. Unfortunately, I think the current implementation is correct. I've implemented something similar in fonttools-rs and copied the current implementation here due to the following comment/thread, https://github.com/googlefonts/fontbakery/issues/2672#issuecomment-722027792

Hm. The PR aligns with the recommendation I've always received from Microsoft for how to treat unhinted fonts. Perhaps it is worth doing some tests.

+1 to tests. Please also look at how the fonts perform on a browser which uses GDI since our current implementation is optimised for this.


QUESTION: roadmap - When will be the next release date of main branch

Hi,
There is planty of new features in the main branch, did you have an idea of the next release date?
I've take a look in the milestone, but i didn't find information
I'm interessted by all this features:

Transform
Kibana space
Rules
...

Thanks to all contributors for this provider, which is really usefull

I was just coming in to raise the exact same question.  Looking forward to the new features being available.

Same question for me, really waiting for new features. Can we have visibility about next release pls?

We also would love to know. We have a very large environment with over 75 spaces and 100+ fleet policies, along with default alerting and index patterns customized for each space. The functionality being worked on, along with the unreleased completd functionality would benefit us immensely.

I can close this issue, the new version "0.0.6" has been released.
Thanks


Checking for zero doesn't work with halo2

For the program
def isZero x = {def xi = fresh (1 | x); x * (1 - xi * x) = 0; 1 - xi * x};
isZero x = 0;

I use
> vamp-ir halo2 compile -s halo.pir -o circuit.halo2
> vamp-ir halo2 prove -c circuit.halo2 -o proof.halo2
> [input 2]

I get:
thread 'main' panicked at 'internal error: entered unreachable code: encountered unexpected expression: (1|x[12])', src/halo2/synth.rs:114:14

Easy problem with an easy fix. evaluate_expr in halo2 synth doesn't have a DivideZ case. I'll implement one and make a PR.


python311Packages.pysigma: 0.10.10 -> 0.11.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python311Packages.pysigma is: Library to parse and convert Sigma rules into queries
meta.homepage for python311Packages.pysigma is: https://github.com/SigmaHQ/pySigma
meta.changelog for python311Packages.pysigma is: https://github.com/SigmaHQ/pySigma/releases/tag/v0.11.0
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 0.11.0 with grep in /nix/store/llqs6z352yv403qj36afj9lc45z83x0k-python3.11-pysigma-0.11.0
found 0.11.0 in filename of file in /nix/store/llqs6z352yv403qj36afj9lc45z83x0k-python3.11-pysigma-0.11.0

Rebuild report (if merged into master) (click to expand)

19 total rebuild path(s)

19 package rebuild(s)

First fifty rebuilds by attrpath
python310Packages.pysigma
python310Packages.pysigma-backend-elasticsearch
python310Packages.pysigma-backend-insightidr
python310Packages.pysigma-backend-opensearch
python310Packages.pysigma-backend-qradar
python310Packages.pysigma-backend-splunk
python310Packages.pysigma-pipeline-crowdstrike
python310Packages.pysigma-pipeline-sysmon
python310Packages.pysigma-pipeline-windows
python311Packages.pysigma
python311Packages.pysigma-backend-elasticsearch
python311Packages.pysigma-backend-insightidr
python311Packages.pysigma-backend-opensearch
python311Packages.pysigma-backend-qradar
python311Packages.pysigma-backend-splunk
python311Packages.pysigma-pipeline-crowdstrike
python311Packages.pysigma-pipeline-sysmon
python311Packages.pysigma-pipeline-windows
sigma-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/llqs6z352yv403qj36afj9lc45z83x0k-python3.11-pysigma-0.11.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python311Packages.pysigma https://github.com/r-ryantm/nixpkgs/archive/da8e96ccffbf6013c60135a68abf94786d62013b.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/da8e96ccffbf6013c60135a68abf94786d62013b#python311Packages.pysigma

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/llqs6z352yv403qj36afj9lc45z83x0k-python3.11-pysigma-0.11.0
ls -la /nix/store/llqs6z352yv403qj36afj9lc45z83x0k-python3.11-pysigma-0.11.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package failed to build:

sigma-cli

18 packages built:

python310Packages.pysigma
python310Packages.pysigma-backend-elasticsearch
python310Packages.pysigma-backend-insightidr
python310Packages.pysigma-backend-opensearch
python310Packages.pysigma-backend-qradar
python310Packages.pysigma-backend-splunk
python310Packages.pysigma-pipeline-crowdstrike
python310Packages.pysigma-pipeline-sysmon
python310Packages.pysigma-pipeline-windows
python311Packages.pysigma
python311Packages.pysigma-backend-elasticsearch
python311Packages.pysigma-backend-insightidr
python311Packages.pysigma-backend-opensearch
python311Packages.pysigma-backend-qradar
python311Packages.pysigma-backend-splunk
python311Packages.pysigma-pipeline-crowdstrike
python311Packages.pysigma-pipeline-sysmon
python311Packages.pysigma-pipeline-windows

Maintainer pings
cc @fabaff for testing.

Superseded by #282264.


macOS: brew cask install virtualbox fails (probably due to the kext issue)

Describe the bug
brew cask install virtualbox fails
Area for Triage:

Question, Bug, or Feature?:
Question
Virtual environments affected

[X] macOS 10.15

Expected behavior
brew cask install virtualbox  should succeed.
Ideally it should be installed by default.
Actual behavior
yaml:
name: foo
on: [push]
jobs:
  build:
    runs-on: macos-latest
    steps:
    - run: brew cask install virtualbox

log:
2020-02-20T04:04:16.4213269Z ##[section]Starting: Request a runner to run this job
2020-02-20T04:04:16.7145011Z Requesting a hosted runner in current repository's account/organization with labels: 'macos-latest', require runner match: True
2020-02-20T04:04:16.8709239Z Labels matched hosted runners has been found, waiting for one of them get assigned for this job.
2020-02-20T04:04:16.9065891Z ##[section]Finishing: Request a runner to run this job
2020-02-20T04:04:33.7751230Z Current runner version: '2.165.2'
2020-02-20T04:04:33.7752600Z Prepare workflow directory
2020-02-20T04:04:33.8599150Z Prepare all required actions
2020-02-20T04:04:33.9791800Z ##[group]Run uname -a
2020-02-20T04:04:33.9792270Z uname -a
2020-02-20T04:04:34.2328130Z shell: /bin/bash -e {0}
2020-02-20T04:04:34.2328540Z ##[endgroup]
2020-02-20T04:04:34.2692910Z Darwin Mac-1313.local 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan  9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64
2020-02-20T04:04:34.2983360Z ##[group]Run brew cask install virtualbox
2020-02-20T04:04:34.2983690Z brew cask install virtualbox
2020-02-20T04:04:34.3120490Z shell: /bin/bash -e {0}
2020-02-20T04:04:34.3121120Z ##[endgroup]
2020-02-20T04:04:42.5394490Z ==> Caveats
2020-02-20T04:04:42.5396050Z To install and/or use virtualbox you may need to enable its kernel extension in:
2020-02-20T04:04:42.5403790Z   System Preferences 竊� Security & Privacy 竊� General
2020-02-20T04:04:42.5408150Z For more information refer to vendor documentation or this Apple Technical Note:
2020-02-20T04:04:42.5410150Z   https://developer.apple.com/library/content/technotes/tn2459/_index.html
2020-02-20T04:04:42.5411850Z
2020-02-20T04:04:42.6162040Z ==> Downloading https://download.virtualbox.org/virtualbox/6.1.2/VirtualBox-6.1.2-135662-OSX.dmg
2020-02-20T04:04:49.3507080Z ==> Verifying SHA-256 checksum for Cask 'virtualbox'.
2020-02-20T04:04:50.6102940Z ==> Installing Cask virtualbox
2020-02-20T04:05:09.9505060Z ==> Running installer for virtualbox; your password may be necessary.
2020-02-20T04:05:09.9506980Z ==> Package installers may write to any location; options such as --appdir are ignored.
2020-02-20T04:05:17.8446560Z Error: Failure while executing; `/usr/bin/sudo -E -- /usr/bin/env LOGNAME=runner USER=runner USERNAME=runner /usr/sbin/installer -pkg /usr/local/Caskroom/virtualbox/6.1.2,135662/VirtualBox.pkg -target / -applyChoiceChangesXML /var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/choices20200220-1671-1smh716.xml` exited with 1. Here's the output:
2020-02-20T04:05:17.8449970Z installer: Package name is Oracle VM VirtualBox
2020-02-20T04:05:17.8451060Z installer: choices changes file '/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/choices20200220-1671-1smh716.xml' applied
2020-02-20T04:05:17.8451590Z installer: Installing at base path /
2020-02-20T04:05:17.8452740Z installer: The install failed. (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance. An error occurred while running scripts from the package 窶弖irtualBox.pkg窶�.)
2020-02-20T04:05:17.8453180Z Follow the instructions here:
2020-02-20T04:05:17.8453920Z   https://github.com/Homebrew/homebrew-cask#reporting-bugs
2020-02-20T04:05:17.8454650Z /usr/local/Homebrew/Library/Homebrew/system_command.rb:176:in `assert_success!'
2020-02-20T04:05:17.8455350Z /usr/local/Homebrew/Library/Homebrew/system_command.rb:53:in `run!'
2020-02-20T04:05:17.8455980Z /usr/local/Homebrew/Library/Homebrew/system_command.rb:29:in `run'
2020-02-20T04:05:17.8456640Z /usr/local/Homebrew/Library/Homebrew/system_command.rb:33:in `run!'
2020-02-20T04:05:17.8457340Z /usr/local/Homebrew/Library/Homebrew/cask/artifact/pkg.rb:59:in `block in run_installer'
2020-02-20T04:05:17.8458010Z /usr/local/Homebrew/Library/Homebrew/cask/artifact/pkg.rb:70:in `block in with_choices_file'
2020-02-20T04:05:17.8458650Z /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/tempfile.rb:295:in `open'
2020-02-20T04:05:17.8459410Z /usr/local/Homebrew/Library/Homebrew/cask/artifact/pkg.rb:67:in `with_choices_file'
2020-02-20T04:05:17.8460020Z /usr/local/Homebrew/Library/Homebrew/cask/artifact/pkg.rb:52:in `run_installer'
2020-02-20T04:05:17.8460700Z /usr/local/Homebrew/Library/Homebrew/cask/artifact/pkg.rb:34:in `install_phase'
2020-02-20T04:05:17.8461880Z /usr/local/Homebrew/Library/Homebrew/cask/installer.rb:218:in `block in install_artifacts'
2020-02-20T04:05:17.8462660Z /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/set.rb:777:in `each'
2020-02-20T04:05:17.8464110Z /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/lib/ruby/2.6.0/set.rb:777:in `each'
2020-02-20T04:05:17.8465600Z /usr/local/Homebrew/Library/Homebrew/cask/installer.rb:209:in `install_artifacts'
2020-02-20T04:05:17.8466150Z /usr/local/Homebrew/Library/Homebrew/cask/installer.rb:101:in `install'
2020-02-20T04:05:17.8466660Z /usr/local/Homebrew/Library/Homebrew/cask/cmd/install.rb:22:in `block in run'
2020-02-20T04:05:17.8467670Z /usr/local/Homebrew/Library/Homebrew/cask/cmd/install.rb:16:in `each'
2020-02-20T04:05:17.8468280Z /usr/local/Homebrew/Library/Homebrew/cask/cmd/install.rb:16:in `run'
2020-02-20T04:05:17.8468800Z /usr/local/Homebrew/Library/Homebrew/cask/cmd/abstract_command.rb:36:in `run'
2020-02-20T04:05:17.8469280Z /usr/local/Homebrew/Library/Homebrew/cask/cmd.rb:92:in `run_command'
2020-02-20T04:05:17.8469780Z /usr/local/Homebrew/Library/Homebrew/cask/cmd.rb:158:in `run'
2020-02-20T04:05:17.8470220Z /usr/local/Homebrew/Library/Homebrew/cask/cmd.rb:123:in `run'
2020-02-20T04:05:17.8470820Z /usr/local/Homebrew/Library/Homebrew/cmd/cask.rb:9:in `cask'
2020-02-20T04:05:17.8471300Z /usr/local/Homebrew/Library/Homebrew/brew.rb:103:in `<main>'
2020-02-20T04:05:17.8472660Z installer: Package name is Oracle VM VirtualBox
2020-02-20T04:05:17.8479130Z installer: choices changes file '/var/folders/24/8k48jl6d249_n_qfxwsl6xvm0000gn/T/choices20200220-1671-1smh716.xml' applied
2020-02-20T04:05:17.8482050Z installer: Installing at base path /
2020-02-20T04:05:17.8483280Z installer: The install failed. (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance. An error occurred while running scripts from the package 窶弖irtualBox.pkg窶�.)
2020-02-20T04:05:17.8483520Z ==> Purging files for version 6.1.2,135662 of Cask virtualbox
2020-02-20T04:05:17.8496580Z ##[error]Process completed with exit code 1.
2020-02-20T04:05:17.8599480Z Cleaning up orphan processes

Probably due to a kext issue (https://developer.apple.com/library/archive/technotes/tn2459/_index.html)

Hi @AkihiroSuda! Thanks for reporting this issue. Indeed, Virtualbox installation is failing due to kext user consent restrictions. Unfortunately we can't provide workaround for kext due to enabled SIP on macOS images.
Can you, please create new issue (or change description in current) about adding preinstalled Virtualbox on macOS images?

Sure: https://github.com/actions/virtual-environments/issues/433


architecture visio

Moved from here: https://github.com/MicrosoftDocs/architecture-center.pl-pl/issues/2
@maciejgajownik commented 9 hours ago
there is wrong visio file linked for this architecture

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

ID: be033e7f-d78f-f63f-c9b5-f08130315704
Version Independent ID: d66f5650-fffb-79a6-ee59-40eaad06cd4f
Content: Multi-region N-tier application - Azure Architecture Center
Content Source: docs/reference-architectures/n-tier/multi-region-sql-server.md
Service: architecture-center
Sub-service: reference-architecture
GitHub Login: @MikeWasson
Microsoft Alias: pnp

Thanks for reporting - this issue is under review.  This is a Microsoft Internal DevOps Bug ID AB#233798

@CeciAc , the linked file has several tabs.  One of the tabs named "Windows multi-region" has the diagram referred to in this article.


Integrate CSL with the wrapper

What
Integrate CSL library into wrapper
How
To make the already defined actions used across govtool pillars wrap up some commonly used CSL services into one Provider & Service (including eg.: cert builders, transaction builders and so on).

Such service should be stateless to make it able to use on the server-side frameworks.

Logic might be reused from the current govtool implementation (having in mind that copy&paste is rather not intended as current solution requires refactor)

Should be part of GovTool wrapper based on this issue.

Wallet connection should be separate (as it is already done with the wallet-connector package)

No negative impact on functionality was noticed.


inform user when there are infra problems

The problem:
Underlying infrastructure problems make us look bad - e.g. a build is in pending state for hours while something is wrong with services we relay on (copr queue full, fedora-messaging outage, something else) - even though it's not our problem, we are the bad ones.
Possible solution:

watchdog-like task that babysits the build and if not done in time (1 hour), gives not to user (and us ideally, via sentry e.g.)

From a quick team brainstorm:

For every task we can schedule a validation task that is triggered after with reasonalbe postpone (e.g. 2 hours after copr_build is triggered) and checks whether the build is in the expected state.

Still relevant.

hm, this is very close to #25


yubikey 2FA support

support storage of substrate account keys protected with a Yubikey as 2FA (FIDO2?)
https://github.com/wisespace-io/yubico-rs

not gonna happen. api-client is not a wallet

well, why not?


Mirgation Issue: 6.5 > 8.5 | Launch fails: 'env' not defined

Environment
Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

CLI: 8.5.7
Cross-platform modules:
Android Runtime: 8.5.0
iOS Runtime (if applicable):
Plugin(s):

Describe the bug
The project builds successfully, but crashes on launch with this error:
"An uncaught Exception occurred on "main" thread.
Unable to create application com.tns.NativeScriptApplication: com.tns.NativeScriptException: Error calling module function
TypeError: Cannot read properties of undefined (reading 'env')
File: (file: app/webpack:/com.app.game/webpack/bootstrap:27:0)"
StackTrace:
./node_modules/util/util.js(file: app/webpack:/com.app.game/node_modules/util/util.js:109:11)
at webpack_require(file: app/webpack:/com.app.game/webpack/bootstrap:24:0)
at fn(file: app/webpack:/com.app.game/webpack/runtime/hot module replacement:62:0)
at ./node_modules/console-browserify/index.js(file: app/webpack:/com.app.game/node_modules/console-browserify/index.js:2:11)
at webpack_require(file: app/webpack:/com.app.game/webpack/bootstrap:24:0)
at fn(file: app/webpack:/com.app.game/webpack/runtime/hot module replacement:62:0)
at ./node_modules/@nativescript/core/data/observable/index.js(file:///data/data/com.app.game/files/app/vendor.js:6780:41)
at webpack_require(file: app/webpack:/com.app.game/webpack/bootstrap:24:0)
at fn(file: app/webpack:/com.app.game/webpack/runtime/hot module replacement:62:0)
at ./node_modules/@nativescript/core/globals/index.js(file:///data/data/com.app.game/files/app/vendor.js:10525:74)
at webpack_require(file: app/webpack:/com.app.game/webpack/bootstrap:24:0)
at webpack_exec(file:///data/data/com.app.game/files/app/bundle.js:29616:39)
at (file:///data/data/com.app.game/files/app/bundle.js:29617:71)
at webpack_require.X(file: app/webpack:/com.app.game/webpack/runtime/startup entrypoint:6:0)
at (file:///data/data/com.app.game/files/app/bundle.js:29617:47)
at (file:///data/data/com.app.game/files/app/bundle.js:29622:3)
at require(:1:266)
Package.json
{
  "name": "com.app.game",
  "version": "1.0.0",
  "description": "NativeScript vue client",
  "author": "test",
  "license": "MIT",
  "nativescript": {
    "id": "com.app.game"
  },
  "dependencies": {
    "@nativescript/core": "~8.5.0",
    "@nativescript/payments": "^1.0.6",
    "@nativescript/theme": "~3.0.2",
    "axios": "^0.21.1",
    "nativescript-numeric-keyboard": "~5.0.2",
    "nativescript-signalr-core": "^2.0.0",
    "nativescript-theme-core": "^2.0.24",
    "nativescript-ui-chart": "~15.2.3",
    "nativescript-ui-core": "~15.2.3",
    "nativescript-ui-listview": "~15.2.3",
    "nativescript-ui-sidedrawer": "~15.2.3",
    "nativescript-vue": "^2.6.4",
    "nativescript-websockets": "~2.0.0",
    "next": "^13.4.7",
    "node-polyfill-webpack-plugin": "^2.0.1",
    "sass": "~1.49.9",
    "vuex": "^3.3.0"
  },
  "devDependencies": {
    "@babel/core": "^7.0.0",
    "@babel/preset-env": "^7.0.0",
    "@nativescript/android": "^8.5.0",
    "babel-loader": "^8.1.0",
    "nativescript-vue-template-compiler": "^2.6.0",
    "sass": "~1.49.9",
    "vue-loader": "^15.9.1",
    "@nativescript/webpack": "~5.0.0"
  },
  "main": "./app/main.js"
}

WebPack
const webpack = require("@nativescript/webpack");
const NodePolyfillPlugin = require("node-polyfill-webpack-plugin")

module.exports = (env) => {
	webpack.init(env);

	webpack.chainWebpack(config => {
		// we add the plugin
		config.plugin('node-polyfill-webpack-plugin').use(NodePolyfillPlugin)
	  })

	return webpack.resolveConfig()
};

Additional context

I know axios and a couple of other packages are not up to date and use the util.js which could be where the issue is. However, I removed those packages & references to them which resulted in the same error.
I also added the polyfill package in webpack config so I don't think it is a polyfill issue?
I have looked at SO questions, reported issues, etc. without any progress. Any help would be appreciated.

Hi @devingrayt6 see this, pinned on core repo:
https://github.com/NativeScript/NativeScript/issues/10329

@NathanWalker unfortunately this solution did not work for me. Could there potentially be other dependencies causing this issue?

Does it work if you run with --no-hmr?

It does not

Hi @devingrayt6 when get a chance, could you include your package-lock.json or yarn.lock here either inline or as attachment?

package-lock.txt

Also experiencing this. I did try adding "qs"<EMAIL_ADDRESS>with no success.

System.err: An uncaught Exception occurred on "main" thread.
System.err: Unable to create application com.tns.NativeScriptApplication: com.tns.NativeScriptException: Error calling module function
System.err: TypeError: Cannot read properties of undefined (reading 'env')
System.err: File: (file: src/webpack:/naturesNotebookMobile/node_modules/util/util.js:110:27)
System.err:
System.err: StackTrace:
System.err: exports.debuglog(file: src/webpack:/naturesNotebookMobile/node_modules/util/util.js:110:27)
System.err: 	at ./node_modules/readable-stream/lib/_stream_readable.js(file: src/webpack:/naturesNotebookMobile/node_modules/readable-stream/lib/_stream_readable.js:56:20)
System.err: 	at webpack_require(file: src/webpack:/naturesNotebookMobile/webpack/bootstrap:19:0)

my webpack config:
const webpack = require("@nativescript/webpack");
const { resolve } = require('path');
module.exports = (env) => {
        webpack.init(env);
        webpack.chainWebpack(config => {
            config.resolve.set('fallback', {
                "crypto": require.resolve("crypto-browserify"),
                "url": require.resolve("url"),
                "http": require.resolve("stream-http"),
                "stream": require.resolve("stream-browserify")
            });
            config.resolve.alias.set('tns-core-modules', '@nativescript/core');
            config.resolve.alias.set('./map-view', resolve(__dirname, 'node_modules/@nativescript/core'));
        });
        return webpack.resolveConfig();
};

package-lock.json:
package-lock.txt

For me, the line that it's blowing up on in node_modules/util/util.js:110:27 is
debugEnviron =  process.env.NODE_DEBUG || '';
if I console.log(process); right before that line I get that process is undefined.

In my case I comment this block on node_modules/util/util.js:109:
/*
if (process.env.NODE_DEBUG) {
var debugEnv = process.env.NODE_DEBUG;
debugEnv = debugEnv.replace(/[|\{}()[]^$+?.]/g, '\$&')
.replace(/* /g, '.*')
.replace(/,/g, '$|^')
.toUpperCase();
debugEnvRegex = new RegExp('^' + debugEnv + '$', 'i');
}
*/
I know is not the best option.  But, this is the immediate solution. My app is running now

We have the same solution pinned over here:
https://github.com/NativeScript/NativeScript/issues/10329#issuecomment-1793618962

We can probably just ensure env is defined on process when a .env file is not present in next webpack patch.

I'm hitting this same error, but none of the suggestions here or in https://github.com/NativeScript/NativeScript/issues/10329#issuecomment-1793618962 make a difference.  If I remove the lines @FlavioShift3 commented out, then I get the same error but elsewhere.  Based on @NathanWalker 's comment above I  created a .env file, but that made no difference either.  Like @jeffswitzer found, process itself is undefined.

@dlcole - I had gotten around this in some hacky way via webpack config. Trying to remember, it was something like
config.plugin('DefinePlugin').tap(args => {
    Object.assign(args[0], {
        'global.isProduction': !!env.production,
    })
    Object.assign(args[0], {
        "process": JSON.stringify('HELLO'),
        "process.env": JSON.stringify('HELLO'),
    })
    return args
})

I remember that it was by searching in the nativescript discord channel, that I found some tips.

@jeffswitzer - Thanks!!  I tried a few things, and this addition to webpack.config.js got me past those errors:
config.plugin('DefinePlugin').tap(args => {
     Object.assign(args[0], {
       "process": JSON.stringify('HELLO'),
       "process.env": JSON.stringify('HELLO'),
     })
     return args

I'm not sure why this works or if it's even a good thing, but I'll run with it for now.


ci(deps): update terraform-ibm-modules/common-pipeline-assets action to v1.5.0

This PR contains the following updates:

Package
Type
Update
Change

terraform-ibm-modules/common-pipeline-assets
action
minor
v1.4.3 -> v1.5.0

Release Notes

terraform-ibm-modules/common-pipeline-assets
v1.5.0
Compare Source
Features

install exact dependency versions during common pipeline execution + lock into stable tag image (#105) (1c1251c)

v1.4.4
Compare Source
Bug Fixes

deps: update icr.io/goldeneye_images/goldeneye-ci-image docker digest to d25f336 (#103) (49e416b)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 1.0.2 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


How to provide defaults for prism plugins

In the latest release of ember-prism, normalize white space was added. We handle our whitespace a little differently than the default setting. Is there a way to change the values? I found https://prismjs.com/plugins/normalize-whitespace/ but I am not sure how to set these values.

Hi @chrisvdp I'm not sure we actually do allow passing a config currently. We probably should make that an option though.


生成Java代码报错

deploy
pinpoint is developed by java,so you should convert the node plugin to java plugin(the web will show some undefined value if you don't use the relative java plugin)
cd pinpoint/agent/utils/tools && node java_code_generator.js ${pluginName}
it will generate the java plugin directory,and then compile it with maven.Finally you can use the war file deployed in collector and web module.
你好，按照你的方法生成java代码报错啊？？

报什么错？log？


refactor(irohad): add config order ENV -> FILE

Description of the Change
This makes it possible to change the precedence order via
the passing in of a new flag called --legacy_config_precedence
which takes a boolean true/false and defaults to true in order
to make this change backwards compatible.
In order to override the pg creds via the enviornment variables
you need to do two things:

Specify the postgres credentials via environment variables
Pass in to the irohad binary the --legacy_config_precedence=false
command line argument when starting it.

Issue
Closes #1314
Signed-off-by: Peter Somogyvari<EMAIL_ADDRESS>

Benefits
Flexibility in containerized environments where the config file is set at build time and tricky to change.
Possible Drawbacks
People may get confused  by the additional flag I had to add to maintain backwards compatibility, but I wanted to make sure it's not a breaking change.
Usage Examples or Tests [optional]
Shell 1
docker run --rm -p 5432:5432 -e POSTGRES_PASSWORD=x postgres:9.5

Shell 2
IROHA_POSTGRES_HOST=<IP_ADDRESS> IROHA_POSTGRES_PORT=5432 IROHA_POSTGRES_USER=postgres IROHA_POSTGRES_PASSWORD=x IROHA_POSTGRES_DATABASE=postgres IROHA_POSTGRES_MAINTENANCE_DATABASE=postgres  ./build/bin/irohad --config ./example/config.sample --verbosity=trace --legacy_config_precedence=false

Then you can observe that it connects to the postgres that was specified in the environment variables which was the point.
You can also observe that if you omit the --legacy_config_precedence=false flag or say --legacy_config_precedence=true instead then it reverts back to ignoring the env variables for the legacy behavior for those who need it.

It is not a big dial to change config.docker. Just use doker volume mounts:
docker run ..... -vpath/on/host/to/config:/path/in/container/to/config

@kuvaldini Should I also rebase this to develop ? (I saw your comment on my other PR with the documentation update)

@kuvaldini Thank you for the most recent proposed changes of yours, I've applied both of them. Now I'll squash everything together into a single commit, rebase and fix the conflicts and then it should be good to go.

@petermetz, yes, we accept pull requests to branch develop

@petermetz, yes, we accept pull requests to branch develop

@kuvaldini Got it, rebased it onto develop.

Is this PR still relevant?

Based on the lack of response. Closing. If you need to merge this functionality, please re-open.


Add python container

Hey Gang
Has anybody added support for Python container (I specifically need it available in the workspace and mysql containers).   If not, please let me know and I will take care of it.
Specifically need Python 2.7, but if I create container I will also expose Python 3.x support

Integrate pip as well when performing this task
https://github.com/laradock/laradock/issues/791

Hi, just curious what's the use case for a python container, supervisord?

I use http://mycli.net/ which is written in python, thus requires python to exist :-)
It is quite an edge case, thus reason I have just thrown it out there to see if it sticks.  I can surely install it on an as needed basis.  I was in a situation where I was having to kill / recreate my containers so frequently, it was frustrating.
However, now that my workflow has stabilized, this is not as "important".   If I have to recreate the mysql container, I just run a bash script to install the extra stuff I use.
At some point, I will readdress this issue, but for now, I am just moving forward with what is on by default.

https://github.com/laradock/laradock/pull/1077

@mikeerickson why closing your issue! I guess it's a good suggestion to have a Python container.

@Mahmoudz I am not quite sure why I closed it, surely something that is still a good addition (as you have stated).

@mikeerickson any news?

I too have a need for this, although with recent developments and the announcement of the EOL of Python 2.7 it might be good to get other versions working too.
I have a Laravel project which includes some more advanced UI features, and so we utilize the node-gyp and node-sass packages (which needs python to build)
TLDR
+1 :)

Python 2.7 is EOL for more than 6 months. So is it now possible to also support Python 3? Could this be done in same way as #1077 except with WORKSPACE_INSTALL_PYTHON3 environment variable and Python 3 packages?


Integrate with exam api (get student exams / get exam overview)

Real data: http://api.judgegirl.beta.pdlab.csie.ntu.edu.tw/api/exams/1/overview
http://api.judgegirl.beta.pdlab.csie.ntu.edu.tw/api/students/2/exams

LGTM.
It's not that important but I think the score field in current response is the maximum score of a question instead of the score the student got.

LGTM.
It's not that important but I think the score field in current response is the maximum score of a question instead of the score the student got.

yes this should mind us in the next sprint.


Hyperparam optimization

This PR introduces a new module (param_optim.py) that allows to launch several runs of training for a same tuple model (feature detection, semantic segmentation) - dataset (shapes, mapillary, ...), with different hyperparameters (batch size, learning rate, learning rate decay, dropout rate, or even network architecture).
During the hyperparameter optimization, each instance configuration produces a model backup on the file system (datapath/dataset/output/model/checkpoints/instance/backup.h5), as this would be done on a standard training process. In addition to that, at the end of the optimization process, a "best model" is stored one the file system as well (datapath/dataset/output/model/checkpoints/best-model-imsize-aggregationpolicy.h5), this backup coming with an instance description in .json format.
The hyperparameter optimization process does not take into account image size and label aggregation policy (aggregate vs full). That's why these parameters appear to characterize the best model files (and as a consequence, several "best models" may exist).
In further developments (in particular when using training results), the best models will be used by default to infer on testing image labels.
Fix issue #28 : the code provides the functions to do hyperparameter optimization, this process will be run as a background task in the next weeks.

looks good for me.


Update Showcase Hub image

I added a few more utilities and jupyter-book extensions for the Handbook Authoring image on the Showcase Hub.

Self-merging as per the 2i2c infrastructure docs.


Simplify exception handling in ClientInvocationHandler

Motivation:
ClientInvocationHandler wraps an exception raised by
RemoteInvoker.invoke() with UndeclaredThrowableException if it is a
checked exception that's not listed in the method's 'throws' clause.
However, this behavioe is redundant because Java's proxy generator
(sun.misc.ProxyGenerator) already does that for us:
Modifications:

Simplify exception handling code
Miscellaneous:

Refrain from using PlatformDependent wherever possible

Result:
Less code

@inch772 PTAL

@inch772 Let me merge some time today :-)

LGTM! sorry for late response.


Enhancement Idea - Max Value to be dynamic based on measure.

For instance, each month x amount of units are built by lets say 10 individuals, with a target of xx per month. The page consists the entire year's data with a month and individual user slicer for filtering into the data, It would be great to have the ability to have the visual adjust its max value using measures.
When a month is selected,
The visual should show the total units for the month with a target for the month.
When no month is selected,
The visual should show total units for the year with a target for the year.
Hope my explanation make sense.
Best Regards
& thank you for the awesome visual

@Raynok - Apologies, but binding a measure to a format property is not supported.  I'll gladly update once the PBI team adds that capability, but for now we are blocked on that.  I'll do my best to track that feature.


Correct way to determine stats on remote filesystems

I have remote file storage mounted with nfs.
For some files dirent reported DT_UNKNOWN type.
As mentioned here stackoverflow article we need to call (l)stat manually for that systems.
I've added this ability. Please check if it is okey.
P.S. I'm not a pro in C, so if you know how to rewrite good - pls rewrite.

hmm thanks for finding this. apparently this is valid behaviour and your patch is required. i'd probably replace the strcat stuff by something like snprintf such that we are sure to never exceed the buffer.


Re-enable ODSP GetOps

There has been a server side fix for the issue surrounding get ops. This change re-enables get ops by default on the client for the next release.

ahh. clicked merge too soon. the check is wrong. will follow up shortly with a fix

@anthony-murphy My bad, I signed off before I had coffee 😵💫

@anthony-murphy My bad, I signed off before I had coffee 😵💫

I wish i had an excuse that good. I was just moving too fast.
Regardless here's the fix:
https://github.com/microsoft/FluidFramework/pull/8733


Find bar line numbering issue

When showing the find bar, the line numbering is incorrect. The textview gets pushed down, but the line number view does not.

After this fix:

Sweet, thanks Simon!


DEP: remove all deprecated scipy.<numpy-func> objects

As evidenced by gh-19065, changes to the contents of numpy's main namespace or __all__ dict have a direct impact on scipy's main namespace. It may cause warnings, import errors in test suites where warnings get converted to errors directly, and it changes the actual contents of the scipy namespace.
The above was always the case, however in the run-up to NumPy 2.0, we can expect a very large amount of changes in NumPy's main namespace. We don't want to expose newly added NumPy functions in the scipy namespace, nor have new breakage each time something in numpy gets deprecated or removed. Hence, let's remove these long-deprecated items now. Our deprecation message said "scipy 2.0" as a way of saying "this is not urgent, these things will be removed eventually". However, it has become urgent now (I'll note that the issue in gh-19065 also affected two of our own CI jobs with obscure errors, e.g. see this CI log). Changing this in SciPy 1.12.0, which will roughly coincide with the NumPy 2.0 release date, should be fine and healthy.

Our deprecation message said "scipy 2.0" as a way of saying "this is not urgent, these things will be removed eventually". However, it has become urgent now

I don't think that's so self-explanatory; at least it's not ideal messaging:

we want people to react to deprecation warnings, of course without overwhelming them; some deprecations are also more impactful than others, but 2.0 seems so mythically far off that it probably encourages laziness rather than action
however it does make an explicit promise, which we then either have to keep (e.g. carry around privatized modules around for a long time[^1]), or break (like in this case), neither of which is ideal IMO.

I think it would be less friction all around to extend the warning period to e.g.  4 releases (rather than 2) for a particularly impactful deprecation, but still provide an explicit date and then execute it. I think that would give a clearer guidance to users (not breaking promises or giving indefinite timelines), and cause less maintenance to keep certain deprecated-in-2.0 bits around for a really long time.
That's less about this PR though, just a comment about the 2.0-situation. If you think it's worth it, we can move this to an issue.
[^1]: this was done in 1.8; how many users do we think have not yet seen this, but will react to it in 1.12+? If that number is low, is it still worth the maintenance effort to keep them?

I think it would be less friction all around to extend the warning period to e.g. 4 releases (rather than 2) for a particularly impactful deprecation, but still provide an explicit date and then execute it

That's fine with me. That would also match the 2 year window given in https://scientific-python.org/specs/spec-0000/.

I would be happy to see if this address the warnings I am ignoring downstream when it is in a nightly wheel. I just need to know when. Thank you, all!

@pllim this may have been enough, but I'll follow up in NumPy, I think these warnings being emitted is turning out to be a bit too disruptive, so I'll fix them there. I'll follow up on gh-19067.


refactor: move admin-config to resource directory and extract common …

refactor: move admin-config to resource directory and extract common dependencies to pom.xml

Make sure that:

[X] You have read the contribution guidelines.
[X] You submit test cases (unit or integration tests) that back your changes.
[X] Your local test passed mvn clean install -Dmaven.javadoc.skip=true.

@flycash, please help to review this PR

Hi, please  merge master branch to resolve conflict before pr. And pls modify your title name by Apache ShenYu Issue And Pull Request . Your pr name like this: [ISSUE #your issue No.] refactor: move admin-config to resource directory and extract common dependencies to pom.xml

@flycash, please help to review this PR

@flycash, please help to check this PR

@flycash, please help to review this PR

LGTM

@CarolineZhang666 Please check the ci.

Codecov Report

Merging #1900 (93386ae) into master (af9d608) will decrease coverage by 0.55%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master    #1900      +/-   ##
============================================
- Coverage     67.84%   67.29%   -0.56%
+ Complexity     2799     2787      -12
============================================
  Files           501      501
  Lines         11583    11580       -3
  Branches       1118     1116       -2
============================================
- Hits           7859     7793      -66
- Misses         3160     3220      +60
- Partials        564      567       +3

Impacted Files
Coverage Δ

...ache/shenyu/client/tars/common/dto/TarsRpcExt.java
0.00% <0.00%> (-30.77%)
:arrow_down:

...ache/shenyu/plugin/grpc/cache/GrpcClientCache.java
64.70% <0.00%> (-29.42%)
:arrow_down:

...enyu/client/tars/TarsServiceBeanPostProcessor.java
26.47% <0.00%> (-29.42%)
:arrow_down:

...che/shenyu/sync/data/http/HttpSyncDataService.java
63.10% <0.00%> (-18.45%)
:arrow_down:

...che/shenyu/admin/model/vo/SelectorConditionVO.java
71.42% <0.00%> (-14.29%)
:arrow_down:

...a/org/apache/shenyu/common/utils/VersionUtils.java
67.85% <0.00%> (-10.72%)
:arrow_down:

...henyu/plugin/grpc/resolver/ShenyuNameResolver.java
56.84% <0.00%> (-7.37%)
:arrow_down:

...henyu/plugin/httpclient/NettyHttpClientPlugin.java
58.00% <0.00%> (-2.00%)
:arrow_down:

...elimiter/handler/RateLimiterPluginDataHandler.java
69.69% <0.00%> (-1.52%)
:arrow_down:

...rg/apache/shenyu/plugin/hystrix/HystrixPlugin.java
74.07% <0.00%> (-0.93%)
:arrow_down:

... and 3 more

Continue to review full report at Codecov.

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

@CarolineZhang666 please check the CI, there maybe some version conflicts of okhttp library

hi, @CarolineZhang666 , you need to resolve conflict and check ci , then resubmit. if you have any question? please contact me.


Add support of vgc://-keys

Currently, when trying to add a configuration to the client using a key like vgc://SCoQYzqLAHdCWgc…, an "Invalid Link" error message appears. This is a VPN Generator configuration supported by the VPN Generator and Amnezia VPN applications.

Currently, when trying to add a configuration to the client using a key like vgc://SCoQYzqLAHdCWgc…, an "Invalid Link" error message appears. This is a VPN Generator configuration supported by the VPN Generator and Amnezia VPN applications.

VPN Generator has export support vless keys. You can use them to import into this application.


update reva to v2.5.1-0.20220608092821-954c578109df

update to include https://github.com/cs3org/reva/pull/2918 and https://github.com/cs3org/reva/pull/2931

:boom: Acceptance test cs3ApiTests-ocis failed. Further test are cancelled...


Full PL translation done

[x] I agree to follow the Code of Conduct that this project adheres to.
[x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Is your feature request related to a problem? Please describe.
I made an update in the translation for PL... now everything is translated.
Describe the solution you'd like
Please upload translations for PL for Dwaw.IO
Describe alternatives you've considered
Additional context
You can check the full translation for PL at https://docs.google.com/spreadsheets/d/1FoYdyEraEQuWofzbYCDPKN7EdKgS_2ZrsDrOA8scgwQ

Cool, thanks very much. It will automatical import into the next build.


Feedback link includes spurious moustache }

https://github.com/hmrc/address-lookup-frontend/blob/8096e5d888e599412a4685f964fb2f4611f20425/app/model/JourneyConfigDefaults.scala#L103
Same is true for Welsh:
https://github.com/hmrc/address-lookup-frontend/blob/8096e5d888e599412a4685f964fb2f4611f20425/app/model/JourneyConfigDefaults.scala#L142

Fixed by @MJCallahanPage - I have approved and merged the corresponding fix. Closing this issue.


Adding African Stopwords

Hello NLTK dev team,
The NLTK package is a renowned NLP package, supporting a host of crucial and foundational NLP processes like stemming, parsing, etc. The NLTK package is used by many practitioners, both in academia and industry.
However, the NLTK package does not have much support for African languages. Currently no African language stopwords are supported by NLTK (from my last query of the supported languages today).
We are trying to mitigate this issue with our work called African Stopwords project, where we curated (and verified) the largest African stopwords to date. We currently have stopwords for 13 African languages and are reaching out to ask if it would be possible to include these stopwords in the NLTK package, thereby enabling support for many NLP tasks in these African languages.
This is just the beginning: the African stopwords project is an ever-ongoing project to curate trusted stopwords for African languages. At the Masakhane and Lanfrica communities, we have a team of dedicated African language experts who take pains to curate and verify the stopwords, as well as add new stopwords for other languages.. We are also working on automatically gathering these stopwords and then having human evaluators do the review (see our paper for more about that). We support an open discussion forum to encourage talks around African stopwords.  That is to say, we will be adding more stopwords
I am proposing a collaboration between NLTK.org, Masakhane and Lanfrica to enable the inclusion of African languages in the NTLK, starting with stopwords. While we plan to build our own packages for unique support of African languages (like the Preprocessor), I strongly believe that also integrating some of our efforts into the widely used NLTK ecosystem will enable a wider adoption, thus fostering the inclusion of African languages in language technologies.
Please let me know if this is something the NLTK team would be interested in, and how we could go about it.
Chris Emezue

Thank you Chris. This is very welcome. Please submit links to the wordlists and metadata here.


Remove old package name

Import is not needed, it is the same package.

Just checked it: you are right, it's not required here. Thanks


Use gopkg for gocheck.

"Rich testing framework for the Go language. PROJECT MOVED: https://github.com/go-check/check"

@Aigeruth thanks. :)


Improve the accuracy of Classification models by using SOTA recipes and primitives

🚀 Feature
Update the weights of all pre-trained models to improve their accuracy.
Motivation
New Recipe + FixRes mitigations
torchrun --nproc_per_node=8 train.py --model $MODEL_NAME --batch-size 128 --lr 0.5 \
--lr-scheduler cosineannealinglr --lr-warmup-epochs 5 --lr-warmup-method linear \
--auto-augment ta_wide --epochs 600 --random-erase 0.1 --weight-decay 0.00002 \
--norm-weight-decay 0.0 --label-smoothing 0.1 --mixup-alpha 0.2 --cutmix-alpha 1.0 \
--train-crop-size 176 --model-ema --val-resize-size 232

Using a recipe which includes Warmup, Cosine Annealing, Label Smoothing, Mixup, Cutmix, Random Erasing, TrivialAugment, No BN weight decay, EMA and long training cycles and optional FixRes mitigations we are able to improve the resnet50 accuracy by over 4.5 points. For more information on the training recipe, check here:
Old ResNet50:
Acc@1 76.130 Acc@5 92.862

New ResNet50:
Acc@1 80.674 Acc@5 95.166

Running other models through the same recipe, achieves the following improved accuracies:
ResNet101:
Acc@1 81.728 Acc@5 95.670

ResNet152:
Acc@1 82.042 Acc@5 95.926

ResNeXt50_32x4d:
Acc@1 81.116 Acc@5 95.478

ResNeXt101_32x8d:
Acc@1 82.834 Acc@5 96.228

MobileNetV3 Large:
Acc@1 74.938 Acc@5 92.496

Wide ResNet50 2:
Acc@1 81.602 Acc@5 95.758 (@prabhat00155)

Wide ResNet101 2:
Acc@1 82.492 Acc@5 96.110 (@prabhat00155)

regnet_x_400mf:
Acc@1 74.864 Acc@5 92.322 (@kazhang)

regnet_x_800mf:
Acc@1 77.522 Acc@5 93.826 (@kazhang)

regnet_x_1_6gf:
Acc@1 79.668 Acc@5 94.922 (@kazhang)

New Recipe (without FixRes mitigations)
torchrun --nproc_per_node=8 train.py --model $MODEL_NAME --batch-size 128 --lr 0.5 \
--lr-scheduler cosineannealinglr --lr-warmup-epochs 5 --lr-warmup-method linear \
--auto-augment ta_wide --epochs 600 --random-erase 0.1 --weight-decay 0.00002 \
--norm-weight-decay 0.0 --label-smoothing 0.1 --mixup-alpha 0.2 --cutmix-alpha 1.0 \
--model-ema --val-resize-size 232

Removing the optional FixRes mitigations seems to yield better results for some deeper architectures and variants with larger receptive fields:
ResNet101:
Acc@1 81.886 Acc@5 95.780

ResNet152:
Acc@1 82.284 Acc@5 96.002

ResNeXt50_32x4d:
Acc@1 81.198 Acc@5 95.340

ResNeXt101_32x8d:
Acc@1 82.812 Acc@5 96.226

MobileNetV3 Large:
Acc@1 75.152 Acc@5 92.634

Wide ResNet50_2:
Acc@1 81.452 Acc@5 95.544 (@prabhat00155)

Wide ResNet101_2:
Acc@1 82.510 Acc@5 96.020 (@prabhat00155)

regnet_x_3_2gf:
Acc@1 81.196 Acc@5 95.430

regnet_x_8gf:
Acc@1 81.682 Acc@5 95.678

regnet_x_16g:
Acc@1 82.716 Acc@5 96.196

regnet_x_32gf:
Acc@1 83.014 Acc@5 96.288

regnet_y_400mf:
Acc@1 75.804 Acc@5 92.742

regnet_y_800mf:
Acc@1 78.828 Acc@5 94.502

regnet_y_1_6gf:
Acc@1 80.876 Acc@5 95.444

regnet_y_3_2gf:
Acc@1 81.982 Acc@5 95.972

regnet_y_8gf:
Acc@1 82.828 Acc@5 96.330

regnet_y_16gf:
Acc@1 82.886 Acc@5 96.328

regnet_y_32gf:
Acc@1 83.368 Acc@5 96.498

New Recipe + Regularization tuning
torchrun --nproc_per_node=8 train.py --model $MODEL_NAME --batch-size 128 --lr 0.5 \
--lr-scheduler cosineannealinglr --lr-warmup-epochs 5 --lr-warmup-method linear \
--auto-augment ta_wide --epochs 600 --random-erase 0.1 --weight-decay 0.00001 \
--norm-weight-decay 0.0 --label-smoothing 0.1 --mixup-alpha 0.2 --cutmix-alpha 1.0 \
--model-ema --val-resize-size 232

Adjusting slightly the regularization can help us improve the following:
MobileNetV3 Large:
Acc@1 75.274 Acc@5 92.566

In addition to regularization adjustment we can also apply the Repeated Augmentation trick  --ra-sampler --ra-reps 4:
MobileNetV2:
Acc@1 72.154 Acc@5 90.822

Post-Training Quantized models
ResNet50:
Acc@1 80.282 Acc@5 94.976

ResNeXt101_32x8d:
Acc@1 82.574 Acc@5 96.132

New Recipe (LR+weight_decay+train_crop_size tuning)
torchrun --ngpus 8 --nodes 1 --model $MODEL_NAME --batch-size 128 --lr 1 \
--lr-scheduler cosineannealinglr --lr-warmup-epochs 5 --lr-warmup-method linear \
--auto-augment ta_wide --epochs 600 --random-erase 0.1 --weight-decay 0.000002 \
--norm-weight-decay 0.0 --label-smoothing 0.1 --mixup-alpha 0.2 --cutmix-alpha 1.0 \
--train-crop-size 208 --model-ema --val-crop-size 240 --val-resize-size 255

EfficientNet-B1:
Acc@1 79.838 Acc@5 94.934

Pitch
To be able to improve the pre-trained model accuracy, we need to complete the "Batteries Included" work as #3911. Moreover we will need to extend our existing model builders to support multiple weights as described at #4611. Then we will be able to:

Update our reference scripts for classification to support the new primitives added by the "Batteries Included" initiative.
Find a good training recipe for the most important pre-trained models and re-train them. Note that different training configuration might be required for different types of models (for example mobile models are less likely to overfit comparing to bigger models and thus make use of different recipes/primitives)
Update the weights of the models in the library.

cc @datumbox @vfdev-5

@datumbox Can you release the training code, maybe the configs of training because the reference training code has already implemented the training tricks.

@xiaohu2015 Of course! I'm in the middle of writing a blogpost that will include the configs, the training methodology, detailed ablations etc. It should be out next week. :)

@datumbox For the commands that start with torchrun --nproc_per_node=8 train.py, could you tell me how many nodes were used for the trainings? Thanks.

Hi @datumbox. I have tried your New Recipe (without FixRes mitigations) on ResNet101 and obtained only a peak top-1 accuracy of 81.328 (at epoch 418), which is 0.558 behind your result (81.886).
I launched the following command on 64 GPUs:
python train.py --model $MODEL_NAME --batch-size 64 --lr 0.5  \
  --lr-scheduler cosineannealinglr --lr-warmup-epochs 5 --lr-warmup-method linear  \
  --auto-augment ta_wide --epochs 600 --random-erase 0.1 \
  --weight-decay 0.00002  --norm-weight-decay 0.0 \
  --label-smoothing 0.1 --mixup-alpha 0.2 --cutmix-alpha 1.0  --model-ema \
--val-resize-size 232  --data-path /home/user/data/imagenet

I only used a batch size of 64 because 128 led to out of memory (on 16GB GPUs). Thus the effective batch size in my training is 64*64 = 4096. Could you please tell me how many GPUs you used in your training? Or even better, could you please share the training configurations shown in your training logs? For example, mine is:
Namespace(amp=False, auto_augment='ta_wide', batch_size=64, cache_dataset=False, clip_grad_norm=None, clonefuse=1, cutmix_alpha=1.0, data_path='/home/user/data/imagenet', dataset='imagenet', device='cuda', dist_backend='nccl', dist_url='env://', distributed=True, epochs=600, gpu=0, interpolation='bilinear', label_smoothing=0.1, lr=0.5, lr_gamma=0.1, lr_scheduler='cosineannealinglr', lr_step_size=30, lr_warmup_decay=0.01, lr_warmup_epochs=5, lr_warmup_method='linear', mixup_alpha=0.2, model='resnet101', model_ema=True, model_ema_decay=0.99998, model_ema_steps=32, momentum=0.9, norm_weight_decay=0.0, opt='sgd', output_dir='/home/user/experiments/output/imagenet_resnet101_new', pretrained=False, print_freq=10, ra_reps=3, ra_sampler=False, random_erase=0.1, rank=0, resume='', resume_from_fused=False, skip_resumed_lr_steps=False, start_epoch=0, sync_bn=False, test_only=False, train_crop_size=224, train_samples=-1, use_deterministic_algorithms=False, val_crop_size=224, val_resize_size=232, val_samples=-1, weight_decay=2e-05, weights=None, workers=16, world_size=64)

The number of GPUs is important information because it affects the effective batch size. I would need to scale my learning rate accordingly to match your results (and for that I would need to know the number of GPUs, and the learning rate, that you used).
FYI the following file contains the metrics values at each epoch of my training.
imagenet_resnet101.txt
Unfortunately the training log file is too big (700MB) to be shared. It is filled with the following annoying warning message:

/home/user/.local/lib/python3.8/site-packages/torch/utils/data/utils/collate.py:138: UserWarning: An output with one or more elements was resized since it had shape [9633792], which does not match the required output shape [64, 3, 224, 224].This behavior is deprecated, and in a future PyTorch release outputs will not be resized unless they have zero elements. You can explicitly reuse an out tensor t by resizing it, inplace, to zero elements with t.resize(0). (Triggered internally at  ../aten/src/ATen/native/Resize.cpp:24.)
return torch.stack(batch, 0, out=out)

(By the way, do you know how to get rid of this kind of messages please? Should I create a GitHub issue somewhere?)
Thank you very much in advance for your reply!

@datumbox Great, thanks a lot for your reply! I'll try again and keep you informed about the results.

@datumbox As per the discussion in #5084, below is a recipe that achieved the following result on ResNet-50 and ImageNet:
Acc@1 80.858 Acc@5 95.434
torchrun --nproc_per_node=4 train.py --model resnet50 --batch-size 256 --lr 0.5 --lr-scheduler cosineannealinglr --lr-warmup-epochs 5 --lr-warmup-method linear --auto-augment ta_wide --epochs 600 --random-erase 0.1 --weight-decay 0.00002 --norm-weight-decay 0.0 --label-smoothing 0.1 --mixup-alpha 0.2 --cutmix-alpha 1.0 --train-crop-size 176 --model-ema --val-resize-size 232 --ra-sampler --ra-reps=4

Overview of changes to the current recipe (New Recipe + FixRes mitigations):

Repeated Augmentation (--ra-sampler --ra-reps=4): In each batch, we sample 1/4 of the original batch size and reuse each sample 4 times with different data augmentations (taken from the same set of augmentations as the original recipe). Repeated Augmentations (RA, also called Batch Augmentation) was successfully used to boost generalization on various models and datasets via gradient variance reduction. In particular, RA with four repetitions was used on ImageNet in prior literature.

Reference used for four repeated augmentations: E. Hoffer et al. "Augment Your Batch: Improving Generalization Through Instance Repetition", CVPR 2020.

Since I ran this on a 4-GPU node, I changed the number of processes per node to 4 and batch size to 256. It should be equivalent to the 8x128 batch size in the current recipe.
--cache-dataset (omitted) was also used to speed up initial Python loading time. Should have no effect on the recipe.

@tbennun Great contributions. I guess increasing the number of repetitions also leads to slower training. Could you tell me how much slower it was for your training?
I am about to launch a few trainings and if --ra-reps=4 would not make them much slower I would go for it and skip the default option.
Thanks in advance for your reply.

@netw0rkf10w Actually, this didn't slow down training at all. The current version of RA in the classifier example uses the DeiT scheme, in which the epoch length is also 1/reps long. I'm assuming this will have diminishing returns, though, but would be really cool to know!

@tbennun I see, thanks. Let me try --ra-reps=4 and see what will happen.

I was able to reach Acc@1 81.901 Acc@5 95.772 for ResNet101 with
--batch-size 64 --lr 2.0 --ra-sampler --ra-reps 4 on 64 GPUs.
The effective batch size is 64*64 = 4096 thus I scaled the learning rate to 2.0, which seems to work, though I am not sure how much --ra-sampler --ra-reps 4 contributed.
@datumbox You said in #5084 that you were about to launch a new set of trainings with --ra-sampler --ra-reps 4. Have you observed any improvements? Thanks.

@netw0rkf10w Thanks for confirming, good to know you matched the accuracy.
No plans to retrain all the models for now. It's very expensive and time consuming to train everything from scratch and not sure it makes sense to do this as the improvement is expected to be in the scale of 0.1-0.2 points.

I have modified the scope of the ticket to focus on Classification so that we can conclude the phase 1 of our Batteries Included project. We will focus on Detection and Segmentation on our phase 2.
Big thanks to everyone involved to this project for helping us keep TorchVision fresh!

@datumbox As per the discussion in #5084, below is a recipe that achieved the following result on ResNet-50 and ImageNet: Acc@1 80.858 Acc@5 95.434
torchrun --nproc_per_node=8 train.py --model resnet50 --batch-size 128 --lr 0.5 \
--lr-scheduler cosineannealinglr --lr-warmup-epochs 5 --lr-warmup-method linear \
--auto-augment ta_wide --epochs 600 --random-erase 0.1 --weight-decay 0.00002 \
--norm-weight-decay 0.0 --label-smoothing 0.1 --mixup-alpha 0.2 --cutmix-alpha 1.0 \
--train-crop-size 176 --model-ema --val-resize-size 232 \
--ra-sampler --ra-reps=4

Overview of changes to the current recipe (New Recipe + FixRes mitigations):

Repeated Augmentation (--ra-sampler --ra-reps=4): In each batch, we sample 1/4 of the original batch size and reuse each sample 4 times with different data augmentations (taken from the same set of augmentations as the original recipe). Repeated Augmentations (RA, also called Batch Augmentation) was successfully used to boost generalization on various models and datasets via gradient variance reduction. In particular, RA with four repetitions was used on ImageNet in prior literature.

Reference used for four repeated augmentations: E. Hoffer et al. "Augment Your Batch: Improving Generalization Through Instance Repetition", CVPR 2020.

Since I ran this on a 4-GPU node, I changed the number of processes per node to 4 and batch size to 256. It should be equivalent to the 8x128 batch size in the current recipe.

--cache-dataset (omitted) was also used to speed up initial Python loading time. Should have no effect on the recipe.

Hi @tbennun , follow your recipe, i tried to reappear the result. Download the latest pytorch/vision code and do it like below:
torchrun --nproc_per_node=8 train.py --model resnet50 --batch-size 128 --lr 0.5 --lr-scheduler cosineannealinglr --lr-warmup-epochs 5 --lr-warmup-method linear --auto-augment ta_wide --epochs 600 --random-erase 0.1 --weight-decay 0.00002 --norm-weight-decay 0.0 --label-smoothing 0.1 --mixup-alpha 0.2 --cutmix-alpha 1.0 --train-crop-size 176 --model-ema --val-resize-size 232 --ra-sampler --ra-reps 4 --data-path /data/imagenet/ --output-dir outputs/vision/

The only modified is the way to loading resnet50
    print("Creating model")
    # model = torchvision.models.get_model(args.model, weights=args.weights, num_classes=num_classes)
    model = torchvision.models.resnet50(weights=args.weights, num_classes=num_classes)
    model.to(device)

>>> import torch
>>> torch.__version__
'1.12.1+cu113'
>>> import torchvision
>>> torchvision.__version__
'0.13.1+cu113'

The result is not very ideal, even worse than the original training.
Best Epoch: [599] Acc@1 72.642 Acc@5 90.316
Best Epoch: [515] ENA Acc@1 73.768 Acc@5 91.384

I'm not sure if I need to load the trained resnet50. This result is a reference for everyone.
...
...


Update Overview.md

Docs Build status updates of commit 81504ab:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

Skype/Skype-For-Business-Bot-Framework/docs/Overview.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Add ExpressionTrackingActive

As part of the larger Lip -> Expression update
Seem to have been missed in the overall update, I know the special case handling the parameter changing in game making it back to VRCFT is commented out for now but that was the only place I could find it actually in the code, so this should be what's needed to have it actually function.
Of note also ExpressionTrackingActive would then also need to be on the wiki docs.

Hey, sorry but why are we adding this? Don't we have LipTrackingActive with the exact same functionality? Am I missing something here? 😆

Might be better left to @regzo2 for further rationale, but as I understand it everywhere else where Lip was used previously has been moved to Expression with the UE update (such as the launch args), so in this case LipTrackingActive should act as an alias/backwards compatibility for ExpressionTrackingActive

Hey, sorry but why are we adding this? Don't we have LipTrackingActive with the exact same functionality? Am I missing something here? 😆

This is just to align with the rest of the changes done with VRCFT. Expressions is a soft replacement for Lips, and it includes even more than just lips now including 'Eye' expressions like eye widen, squinting, etc.


[help]  Enabling +nightly binary wrapper functionality

Heads up: I'm not advocating to change any part of this project, just merely trying to get advice.
Situation
The overlay does not handle +nightly directives, which is rustup binary wrapper functionality as explained in this rust-lang thread.
So executing cargo +nightly fmt naturally returns:
error: no such command: `+nightly`

	Cargo does not handle `+toolchain` directives.
	Did you mean to invoke `cargo` through `rustup` instead?

Workaround
In my personal projects this is fine.
I can specify my mkShell with the following snippet to get the nightly formatter when executing cargo fmt:
buildInputs = [
    (lib.hiPrio rust-bin.nightly."2024-04-01".rustfmt)
]

A full example can be seen in trade_aggregation-rs
The Problem
However, there is a codebase I'm working on that contains a build.rs which executes cargo +nightly fmt on some code.
The team wants to keep an explicit invocation of the nightly toolchain as their environments are not nixified yet :smile: .
My initial though was to replace that line with rustup run nightly cargo fmt which errors out:
rustfmt: symbol lookup error: /nix/store/03kbs44xggcldf52xwrmmbnxcvv1i8hc-rustc-1.79.0-nightly-2024-04-01-x86_64-unknown-linux-gnu/lib/librustc_driver-f82cffb7eb0c3efe.so: undefined symbol: _ZN58_$LT$std..io..error..Error$u20$as$u20$core..fmt..Debug$GT$3fmt17habdca9cfa0f750d0E

Which indicates that some expected symbols could not be found in the path, but I'm not sure how to fix it.
This leaves me with two options:

Fix the above symbol lookup error
Somehow enable the rustup binary wrapper functionality that would allow +nightly to work properly.

Does anyone have an Idea on how to best achieve either?
Notes
The full flake.nix can be found here: https://pastebin.com/Frq345DT
A similar Issue is described for fenix in this Issue
Any advice would be appreciated.

I've gotten around the issue as follows, although reproducibility wise this solution is sub-optimal because rustup manges the toolchain and not nix.
outputs = {
    nixpkgs,
    flake-utils,
    ...
  }:
    flake-utils.lib.eachDefaultSystem (
      system: let
        pkgs = import nixpkgs {
          inherit system overlays;
        };
        rust_toolchain = builtins.fromTOML (builtins.readFile ./rust-toolchain.toml);
      in
        with pkgs; {
          RUSTC_VERSION = rust_toolchain.toolchain.channel;

          devShells.default = mkShell {
            buildInputs = [
              rustup
            ];
            shellHook = ''
              # `rustup` reproducibility leaves a lot to be desired as it relies on user configuration from the home directory.
              # Because we use `+nightly` directly in our sourcecode, we have to rely on this `rustup` binary wrapper functionality.
              # Else we could use a rust overlay for way better reproducibility.
              rustup install nightly
            '';
          };
        }
    );

This works in the sense that you can use +nighlty when invoking cargo, because rustup is used instead of the rust-overlay.
Not a big fan of it, but it solves this particular niche case.
Hope this can be benefit to someone else as well.

A while back I wrote a little script that emulates rustup's +<toolchain> syntax using rust-overlay via nix shell: https://github.com/Nemo157/dotfiles/blob/2e81eed9a2ab88b60c8e38811306cb67133edf41/packages/rust-shim.sh


fix(server): Listen only to <IP_ADDRESS> by default

This pull request supersedes #2865, after discussion that one should rely on the --host parameter to determine public/private network interface setup.

Copying my comment from the prev PR for reference:
I think we should implement the same scheme as sirv: https://github.com/lukeed/sirv/tree/master/packages/sirv-cli#network-access

For security reasons, sirv-cli does not expose your server to the network by default. This means that your machine, and only your machine, will be able to access the localhost server.
If, however, your coworker wants to access the server from their computer, or you want to preview your work on a mobile device, you must use the --host flag. Only then will your server be accessible to other devices on the same network.
Using --host without a value is equivalent to --host <IP_ADDRESS>, which is makes it discoverable publicly. You may customize this by passing a different value – but you probably don't need to!

@eirslett We should add an equivalent paragraph to the docs. And this PR doesn't implement support for --host without a value being equivalent to --host <IP_ADDRESS>, no?
If the logic in preview.ts and server/index.ts is shared, we may want to take the opportunity to create a helper now that it is getting more complex. In the case of preview, it is not a big security issue but since sirv is doing this for its server, I agree that it would be good to be consistent.

Also it seems there are some failing tests 🤔
https://github.com/vitejs/vite/pull/2977/checks?check_run_id=2337683223#step:10:16
At least on windows 🤔 @patak-js Do you have windows? Can you reproduce this on your machine?

@Shinigami92 I can reproduce this on my machine, but I don't understand how this is related to this PR. Head is green.

Yes, we should refactor it, my suggestion is that since this is a security fix, we could merge it (after code review) and do the other improvements in a separate PR. The code duplication should definitely be refactored, and supporting --host without arguments sounds like possibly a good idea.
My suspicion is that Windows tries to use the public IP in the tests, but by default the server now only listens to <IP_ADDRESS>, which might be the reason why the tests fail?

@eirslett I should consider to create a PR/branch on top of eirslett:bugfix-security-use-host-param-correctly

And this PR doesn't implement support for --host without a value being equivalent to --host <IP_ADDRESS>, no?

FWIW, Luke mentioned he only made that the default due to a few complaints about having to type more to expose. You certainly could make the argument that forcing users to be more explicit when exposing could be of benefit.
Just something to consider.

Ok, I agree with @rschristian. We can have --host default to --host <IP_ADDRESS> if there are a lot of users asking for the shortcut, it is safer to avoid it.

About the hint message, I think that it could be less intrusive. I think we should copy sirv here:

It could be:
    Network:      Use `--host` to expose

Instead of add if we don't default to <IP_ADDRESS> in this PR

The failing example in windows is working well when launching the dev server, but not in the jest tests. This may be an issue with untilUpdated. Just in case, @eirslett would you merge main in the PR?

Agree to keep the Network: for hinting. My preference:
  > Local:    http://localhost:4000/
  > Network:  (use `--host` to expose)

Where the (...) is colored with gray or dim.

There we go:

CLI output looks like @antfu suggested
The --host parameter can be used without arguments

🤞 the tests will pass...

It is still failing in Windows, but it should be because of our tests and not because of the feature itself. @eirslett maybe we can force to use the server.host option for test so we keep testing in the same environment as before this PR? Tests are working in head, so if we do that, this should also pass, no?

Some findings about the failing tests:
Previous to this PR, we are passing undefined as the host by default ( httpServer.listen(port, undefined) )

This is equivalent to using httpServer.listen(port, '::'), I checked that the tests are passing in Windows passing this string.
If I force manually the use of httpServer.listen(port, '<IP_ADDRESS>'), the HMR tests in Windows fails.
Forcing manually the use of httpServer.listen(port, '<IP_ADDRESS>'), the HMR tests in Windows also fails.

I don't understand why using '<IP_ADDRESS>' or '<IP_ADDRESS>' doesn't work for windows. And I don't know if it is a good idea to force the tests to use '::' because we wouldn't be testing the default setup after this PR.
Other details:

I don't see in the PR, how is host being defined as '<IP_ADDRESS>' in case the value is omitted.
In the PR If the host is not '<IP_ADDRESS>', the cli output will not replace <IP_ADDRESS> with localhost properly.

I don't see in the PR, how is host being defined as '<IP_ADDRESS>' in case the value is omitted.

I think the host will then be undefined which, when passed to node.js/express, means it will listen on <IP_ADDRESS>.

In the PR If the host is not '<IP_ADDRESS>', the cli output will not replace <IP_ADDRESS> with localhost properly.

I don't think it matters - the most valuable piece of information is the public IP address, which you can then pass on to coworkers, or your mobile phone, or whatever should access your dev server remotely.

I don't see in the PR, how is host being defined as '<IP_ADDRESS>' in case the value is omitted.

I think the host will then be undefined which, when passed to node.js/express, means it will listen on <IP_ADDRESS>.

If host is undefined, then hostname is going to be '<IP_ADDRESS>' with this PR, no?
const hostname = options.host || '<IP_ADDRESS>'

Note: Looks like if the system supports IPv6, passing undefined defaults to '::' instead of '<IP_ADDRESS>' (but sirv defaults to '<IP_ADDRESS>')

In the PR If the host is not '<IP_ADDRESS>', the cli output will not replace <IP_ADDRESS> with localhost properly.

I don't think it matters - the most valuable piece of information is the public IP address, which you can then pass on to coworkers, or your mobile phone, or whatever should access your dev server remotely.

Users may still want to use localhost and give the public IP to others at the same time, and this is how Vite works until this moment. Using --host after this PR should work the same way as it is now (so <IP_ADDRESS> should be replaced by localhost in the output)

I pushed a new change now, which makes the logic even more explicit.

Hey @eirslett, I just had a quick look over your PR
Some thoughts I had are:

Your are checking e.g. hostname === '<IP_ADDRESS>', would be 'loaclhost' also a valid value?
Is it possible to validate the users input that it is a valid IPv4 address?
Do you think IPv6 addresses could be also a valid input?

IPv6 support (if wanted) could be outsourced to another PR :thinking:

Your are checking e.g. hostname === '<IP_ADDRESS>', would be 'loaclhost' also a valid value?

It's not really checking that, it's just setting the default value to <IP_ADDRESS>.

Is it possible to validate the users input that it is a valid IPv4 address?

I'm sure it possible, but maybe that's a separate feature?

Do you think IPv6 addresses could be also a valid input?

Absolutely, there's not really anything in the way now for passing an IPv6 address as the --host parameter. This PR only sets the defaults. Anyways I think IPv6 is also a separate issue.

@eirslett using host: '::' is working. The only failing test is glob-import, because it doesn't have a vite.config.js.
Given that the current tests suite is already using '::', because of the default value when passing an undefined host:

If host is omitted, the server will accept connections on the unspecified IPv6 address (::) when IPv6 is available, or the unspecified IPv4 address (<IP_ADDRESS>) otherwise.

I think that we can continue to use the same for CI and the jest run, and push to another PR the modifications for only using localhost for the tests (if that is possible). We will not be testing the restricted setting at this moment.
But before merging, IMO we should modify host: true to pass an undefined host value instead of '<IP_ADDRESS>', so users have an easy way to choose the default behavior for server.listen.
With this change, we could use host: true in the tests. But we shouldn't add this to the playgrounds config files. We can add it to the test setup: https://github.com/vitejs/vite/blob/f3992984258ec47802f92f13fd99fc4e1747e1fd/scripts/jestPerTestSetup.ts#L76 only once and it will be applied to all tests that don't have a custom server.
There are two tests with a custom server: ssr-vue and ssr-react. In case these are failing, host: true can be added to:

https://github.com/vitejs/vite/blob/f3992984258ec47802f92f13fd99fc4e1747e1fd/packages/playground/ssr-vue/server.js#L40
https://github.com/vitejs/vite/blob/f3992984258ec47802f92f13fd99fc4e1747e1fd/packages/playground/ssr-react/server.js#L35

What do you think?

Looks like all the tests pass now! I'm not 100 % sure about making host: true mean hostname: undefined, but it's certainly possible. I have no idea why :: vs <IP_ADDRESS> should make a practical difference (or why the tests fail on Windows because of it)

I'm not 100 % sure about making host: true mean hostname: undefined, but it's certainly possible. I have no idea why :: vs <IP_ADDRESS> should make a practical difference (or why the tests fail on Windows because of it)

@eirslett let's do this change, and we can then use host: true in the tests instead of ::.

I mean, yes, the code in there should probably be refactored, prettified, extracted, nitpicked and all, but this is first and foremost a security patch, and it's already been 29 days since I opened the first PR. I'm getting a little bit tired of all the bike shedding, sorry. All I wanted to do was to make Vite more secure.

Thanks for the PR @eirslett. For later reference, this was not merged before because tests were not passing til yesterday.


Feature/Node Delete Behavior Improvements [ENG-877]

Purpose
Several items noticed lately around deleted nodes:
Restore node behavior is broken now that behavior introduced in December trashes the root folder, and restoring doesn't bring it back.  Lots of things happen when you delete a node, and these should be wrapped in a transaction.  get_auth doesn't factor in whether or not a resource has been deleted. Old restored nodes need to be taken care of.
Changes

Wrap node delete in a transaction
Remove behavior that trashes root folder as part of node deletion process
Add migration management command that restores deleted osfstorage root folders - double checking in prod data that this is a small percentage, just introduced late last year). This should fix those restored nodes whose osfstorage addons appear to be disconnected.
Make get_auth return a 404 if the node/preprint has been deleted

QA Notes
Multiple things to check:

Create a node, add a file to it, note the file's guid - access the file in the API, and get the move link. Something like - https://files.us.staging.osf.io/v1/resources/jxfkt/providers/osfstorage/5c262827bf85ca001685385d/"  Delete the node.   Revisit that WB move link. Should get a 404 now instead of a 500.

Pre-management command check.  Delete some nodes. Restore them in the admin app. Note that the osfstorage addon appears not to load.  After we run the management command, these restored node's osfstorage addons should work again.

Post-management command.  Note that after deleting nodes and restoring them in the admin app, the osfstorage addon loads fine.

Light testing of general nodes delete behavior, and the items that should be affected - addons are removed

Comment targets are updated
node is marked as deleted
subscriptions are removed
logs are added
search is updated
DOI's updated
files deleted

Documentation

Side Effects

Ticket
https://openscience.atlassian.net/browse/ENG-877

@pattisdr Could you update this with develop please? Then we can put this on staging to test.


Lost zero while replacing a digit in group

I have an inputmask with radix, (20,00), when i select the "2" and replace it with another digit, like "5", i get "5,00", instead of "50,00", could it be a problem in the leading zero handler?
http://jsfiddle.net/qmemcvdb/1/

@schmulschubiak ,
Fixed in the latest


Initialization bug in Qlib

After downloading data with the code:
python scripts/get_data.py qlib_data --target_dir ~/.qlib/qlib_data/cn_data --region cn
according to the instruction in https://qlib.readthedocs.io/en/latest/start/initialization.html
I cannot run the following one:
import qlib
region in [REG_CN, REG_US]
from qlib.config import REG_CN
provider_uri = "~/.qlib/qlib_data/cn_data"  # target_dir
qlib.init(provider_uri=provider_uri, region=REG_CN)

@phamanhtu17295
Please follow the prompted message.

Thanks for your report.


Progress bar for fsck

It will take a long time to list all the blocks, we should show the progress rather waiting blindly.

@davies How does this work dynamically? If the program is currently ListSlices, there will be a dynamic icon spinning behind it, and if the ListSlices are finished, the icon will disappear.
In addition, there is no performance loss because the total is not obtained.
Different types of metadata are displayed and handled in the same way
But for the ListSlices interface I added a parameter bar *mpb.Bar which can be passed as nil when the status display is not needed
Is this solution acceptable?

This one looks good. W can pass a updateProgress func (n int64) to ListSlices

Fixed by #683


[BUG] Quest macros don't work

Module Version: v0.7.3
Describe the bug
Executing a script macro with the code in the wiki does nothing and generates a JS error in the console
To Reproduce
Steps to reproduce the behavior:

Create a new script Macro
Enter any example from the wiki, e.g. https://github.com/Forien/foundryvtt-forien-quest-log/wiki/Macros#open-quest-log
Click execute Macro
See error in browser console ("Uncaught (in promise) ReferenceError: Quests is not defined")

Dragging a quest into the macro bar and clicking it works as expected.
Expected behavior
The macros to work.
Screenshots

Browser:
Brave
Foundry Version:
0.8.7
Game System:
DnD5e 1.3.5
More info
Hacking around I found that
game.modules.get('forien-quest-log').public.questLog.render(true)
opens the quest log okay

This is not going to work in FQL 0.7.4 which is launching soon.
Please use Hooks.call('ForienQuestLog.Open.QuestLog');
Also check out the active repo for FQL:
https://github.com/League-of-Foundry-Developers/foundryvtt-forien-quest-log