Bump kotlin to 1.4.10

Codecov Report

Merging #400 into master will decrease coverage by 0.25%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #400      +/-   ##
============================================
- Coverage     59.29%   59.04%   -0.26%
+ Complexity      792      787       -5
============================================
  Files            60       60
  Lines          5545     5545
  Branches        867      867
============================================
- Hits           3288     3274      -14
- Misses         2006     2020      +14
  Partials        251      251

Impacted Files
Coverage Δ
Complexity Δ

...om/microsoft/thrifty/gradle/ThriftyGradlePlugin.kt
35.71% <0.00%> (-50.01%)
2.00% <0.00%> (ø%)

...kotlin/com/microsoft/thrifty/gradle/ThriftyTask.kt
0.00% <0.00%> (-10.45%)
0.00% <0.00%> (-5.00%)

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 7cd69f0...76333ae. Read the comment docs.


fix exception info missing

Thanks a lot for contributing!
Console logs missing exception info when using talker.error('Message', exception, stackTrace).
Associated issue: https://github.com/Frezyx/talker/issues/205

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

Project coverage is 99.53%. Comparing base (450129e) to head (0cafff0).
Report is 7 commits behind head on master.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #210      +/-   ##
==========================================
- Coverage   99.67%   99.53%   -0.15%
==========================================
  Files          14       11       -3
  Lines         305      213      -92
==========================================
- Hits          304      212      -92
  Misses          1        1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

Hello @heiha100 !
Thanks you for this contribution ❤


add autoApproved status;

When the response had an autoApproved status, Gson could not correctly parse the status on this method:
protected <T> T handleResponse(HttpResponse<String> response, Class<T> classOfT) {
        String responseBody = response.body();
        if (!String.valueOf(response.statusCode()).startsWith("2")) {
            throw new TestRunException(responseBody);
        }
        return gson.fromJson(responseBody, classOfT);
    }

This resulted in a further NPE in the method track.

STR:

Create a new project, enable the autoApprove feature
Run a test on branch a (not base) with a new screenshot (with status new)
Approve a new screenshot
Run a test with the same screenshot in branch b

Expected result:
NPE in method track. Object testResultDTO contains status=null.

@vkostromin94 good catch! could you also add test for this case?

No problem, done.


Update the demo of SilverStripe 4

The demo is way out of date and should be available for the community to provide feedback. This could also be used as a testing ground without the risk of major breaking changes which are common in test sites.
https://www.silverstripe.org/4/

Moved issues to silverstripe-admin


Add TTFautohint into build / instantiation script

Do I have any options in the config.yaml or do I have to use ttfautohint manually for hinting? If it's the latter, may you share the settings for hinting this font?
I really miss the Duotone though, I remember it has been in a release 1 year ago or so, but now I can't find it in v84.
Anyway, many thanks in advance!

Hey @chrisdcao, thanks for asking!

I really miss the Duotone though, I remember it has been in a release 1 year ago or so, but now I can't find it in v84.

It’s still in release 1.084, in ArrowType-Recursive-1-2.084/Recursive_Code/RecMonoDuotone.
But actually, no, these "code" fonts don’t have hinting, even though they probably should.
For now, I would recommend using TTFautohint on the command line. Once you install TTFautohint, the command will be something like:
ttfautohint "<filepath>/RecMonoDuotone-Regular-1.084.ttf" "<filepath>/RecMonoDuotone-Regular-1.084-hinted.ttf"

Depending on the size you are using and the rendering results you get, a useful option to play with is --increase-x-height. So, for instance, if you are using the fonts above 14px and some counters are closing up / filling in, and rounding up the x-height might help, try this:
ttfautohint --increase-x-height=16 font.ttf font-hinted.ttf

The default is 14, so if you’re using the font below that, this argument won’t really matter. OR if the x-height is getting stretched and you don’t like that, you could try --increase-x-height=0.
I’ll convert this issue to a reminder to myself to add this into the build here, though. It would be sensible and helpful to add in.

Cool! Thanks for the reply!
May I ask what x-height settings you used for the static Desktop code version? I'm very satisfied with that version! Thus if possible, I want to replicate the exact settings you used to create those for my Duotone rendering! Many thanks!

@chrisdcao
Looks like the only TTFautohint option used in the build of the main static fonts is --composites:
https://github.com/arrowtype/recursive/blob/5b03122edeca493d04b38462c16cb00ef9070f84/mastering/build_static.py#L729-L733
But, as the TTFA docs say:

--composites, -c
By default, the components of a composite glyph get hinted separately. If this flag is set, the composite glyph itself gets hinted (and the hints of the components are ignored). Using this flag increases the bytecode size a lot, however, it might yield better hinting results – usually, it doesn’t.
If this option is used (and a font actually contains composite glyphs), ttfautohint currently cannot reprocess its own output for technical reasons, see below.

...it may or may not make much of a difference. Still, you probably might as well!

This has now been added to the script here, and seems to be working for me, in case you’d like to test it out with other configurations. The output fonts are updated in this repo, but not yet in the main recursive release.


254 Printing of util_transforms

Description

Solves #254
Let 'b' and c be:
@transform
class MyClass:
    def __init__(self, a):
        self.a = a
    def __call__(self, x):
         return self.a + x

a  = MyClass(4)
b = IfInfer(if_=a, else_=a)
c = Try(transform=a, catch_transform=a, exceptions=(TypeError, ZeroDivisionError), else_transform=a, finally_transform=a)

Before, the printing of 'b' was:
IfInfer(if_=MyClass(a=4), target_mode='infer', else_=MyClass(a=4)) - "b":

   from padl.util_transforms import IfInfer

Now, it is:
IfInfer(if_=MyClass(a=4), target_mode='infer', else_=MyClass(a=4)) - "b":

   if pd_mode == infer:

      class MyClass:
          def __init__(self, a):
              self.a = a
          def __call__(self, x):
              return self.a + x

   else:

      class MyClass:
          def __init__(self, a):
              self.a = a
          def __call__(self, x):
              return self.a + x

Before, the printing of 'c' was:
Try(transform=MyClass(a=4), catch_transform=MyClass(a=4), exceptions=(<class 'TypeError'>, <class 'ZeroDivisionError'>), else_transform=MyClass(a=4), finally_transform=MyClass(a=4)) - "c":

   from padl.util_transforms import Try

Now, it is:
Try(transform=MyClass(a=4), catch_transform=MyClass(a=4), exceptions=(<class 'TypeError'>, <class 'ZeroDivisionError'>), else_transform=MyClass(a=4), finally_transform=MyClass(a=4)) - "c":

   try:

      class MyClass:
          def __init__(self, a):
              self.a = a
          def __call__(self, x):
              return self.a + x

   except (TypeError, ZeroDivisionError):

      class MyClass:
          def __init__(self, a):
              self.a = a
          def __call__(self, x):
              return self.a + x

   else:

      class MyClass:
          def __init__(self, a):
              self.a = a
          def __call__(self, x):
              return self.a + x

   finally:

      class MyClass:
          def __init__(self, a):
              self.a = a
          def __call__(self, x):
              return self.a + x

How about making if and try except capitalized -If, Try, Except like the name of transforms?

How about making if and try except capitalized -If, Try, Except like the name of transforms?

Actually I think it is okay as is

How about making if and try except capitalized -If, Try, Except like the name of transforms?

Actually I think it is okay as is

Then we leave it like it is right?

How about making if and try except capitalized -If, Try, Except like the name of transforms?

Actually I think it is okay as is

Then we leave it like it is right?

yeah, was just an idea. Can leave it as it is. Looks good.


Could not find iPhone 6 simulator

Code I am executing:
react-native run-ios
Error:
Found Xcode project myrn.xcodeproj
Could not find iPhone 6 simulator
React Native Environment Info:
Environment:
OS: macOS 10.15.1
Node: 10.0.0
Yarn: 1.12.3
npm: 5.6.0
Watchman: 4.9.0
Xcode: Xcode 11.2 Build version 11B52
Android Studio: Not Found
Packages: (wanted => installed)
react: 16.3.1 => 16.3.1
react-native: 0.55.4 => 0.55.4

You can specify the device the simulator should run with the --simulator flag, followed by the device name as a string. The default is "iPhone X". If you wish to run your app on an iPhone 5s, run react-native run-ios --simulator="iPhone 5s".
There is more information here:
https://facebook.github.io/react-native/docs/running-on-simulator-ios

You can specify the device the simulator should run with the --simulator flag, followed by the device name as a string. The default is "iPhone X". If you wish to run your app on an iPhone 5s, run react-native run-ios --simulator="iPhone 5s".
There is more information here:
https://facebook.github.io/react-native/docs/running-on-simulator-ios

It is not work for me.

This is fixed in the latest CLI. Please update the @react-native-community/cli to the latest version.


How to use cargo-bisect-rustc with cross?

When running cargo-bisect-rustc -vv --script=./test.sh where test.sh is:
#!/bin/sh

exec cross run --target powerpc64le-unknown-linux-gnu

The cross command failed with:
error: `"rustup" "target" "list" "--toolchain" "bisector-nightly-2022-04-26-x86_64-unknown-linux-gnu"` failed with exit code: Some(1)

If I just run cargo-bisect-rustc -vv without using cross, then everything runs without problem.
Is there any way to fix the problem?

cross needs to know where the toolchain lives, I think it would be possible to support this, unless it's actually already supported.
The error is due to this: https://github.com/cross-rs/cross/blob/7599e1a513823a02ccdaf510a5f63c206c83f31a/src/rustup.rs#L42 not working correctly, why it doesn't work I'm unsure.
You should get a better output if you do exec cross run -vv --target powerpc64le-unknown-linux-gnu instead.
also, make sure you have the latest (unreleased) cross, as there have been some changes, but I doubt they would fix this.
My guess is that the way we discover sysroots and targets is not robust enough for bisect-rustc

OK, I've installed the trunk version of cross using:
cargo install --git https://github.com/cross-rs/cross --branch main cross

And cross gives me:
testing...
+ "rustc" "--print" "sysroot"
+ "rustup" "toolchain" "list"
+ "rustup" "target" "list" "--toolchain" "bisector-nightly-2022-04-27-x86_64-unknown-linux-gnu"
Error:
   0: `"rustup" "target" "list" "--toolchain" "bisector-nightly-2022-04-27-x86_64-unknown-linux-gnu"` failed with exit code: Some(1)

Location:
   src/extensions.rs:26

@Emilgardis I think the problem is that cargo-bisect-rustc adds a custom toolchain that cannot add new target.
After reading the cargo-bisect-rustc, it turns out that cargo-bisect-rustc support option --target for cross compiling.
cargo-bisect-rustc -vv --script=./test.sh --target powerpc64le-unknown-linux-gnu

but it gives me the same output:
+ "rustc" "--print" "sysroot"
+ "rustup" "toolchain" "list"
+ "rustup" "target" "list" "--toolchain" "bisector-nightly-2022-04-27-x86_64-unknown-linux-gnu"
Error:
   0: `"rustup" "target" "list" "--toolchain" "bisector-nightly-2022-04-27-x86_64-unknown-linux-gnu"` failed with exit code: Some(1)

Location:
   src/extensions.rs:26

for cross to work, you'll need a toolchain that is x86_64-unknown-linux-gnu with your target added. Unsure how it works completely but I don't see why this would not be possible to support, either from an added cfg-flag in cargo-bisect-rustc or with new functionality in cross, e.g a "TOOLCHAIN_PATH" variable

for cross to work, you'll need a toolchain that is x86_64-unknown-linux-gnu with your target added. Unsure how it works completely but I don't see why this would not be possible to support, either from an added cfg-flag in cargo-bisect-rustc or with new functionality in cross, e.g a "TOOLCHAIN_PATH" variable

@Emilgardis The main problem is that cargo-bisect-rustc sets up a custom toolchain, so rustup target list does not work:
+ rustup target list --toolchain bisector-nightly-2022-04-27-x86_64-unknown-linux-gnu
error: toolchain 'bisector-nightly-2022-04-27-x86_64-unknown-linux-gnu' does not support components: bisector-nightly-2022-04-27-x86_64-unknown-linux-gnu is a custom toolchain

So we would have to skip checking for available targets for carg-bisect-rustc, probably by checking whether the toolchain starts with bisector.

I'm fairly reticent to add specific exceptions for custom rustc wrappers, however, we might be able to add a command-line flag or determine if the rustc command is not actually rustc? I don't think we should add exceptions for specific crates acting like they're rustc to not be rustc.

I'm not reproducing this anymore: the error would have to be in rustup::available_targets, which is always run as long as Docker is invoked, which I think is because cargo-bisect-rust actually properly lists the toolchain? I'm not reproducing this anymore. For example, a simple script shows:
exec rustc --version

And cargo-bisect-rustc --script=./script.sh shows that we get rustc 1.63.0-nightly (ca122c7eb 2022-06-13), the default toolchain. Likewise, actually printing out the toolchain versions shows the same thing on the rustc end. This seems to have been patched in cargo-bisect-rustc. Can you check again?

Sure

@Alexhuszagh Still encounter the same error:
nobodyxu@comp:~/tests$ cargo bisect-rustc -vv --target powerpc-unknown-linux-gnu --script=./test.sh
installing nightly-2022-06-15
cargo for x86_64-unknown-linux-gnu: 6.56 MB / 6.56 MB [================================================================================================================================] 100.00 % 1.83 MB/s
testing...
+ exec cross run -vv --target powerpc64le-unknown-linux-gnu
+ "rustc" "--print" "sysroot"
+ "rustup" "toolchain" "list"
+ "rustup" "target" "list" "--toolchain" "bisector-nightly-2022-06-15-x86_64-unknown-linux-gnu"
Error:
   0: `"rustup" "target" "list" "--toolchain" "bisector-nightly-2022-06-15-x86_64-unknown-linux-gnu"` failed with exit code: Some(1)

Location:
   src/extensions.rs:26
RESULT: nightly-2022-06-15, ===> Yes
uninstalling nightly-2022-06-15

installing nightly-2022-06-13
rustc for x86_64-unknown-linux-gnu: 1.75 MB / 54.40 MB [===>------------------------------------------------------------------------------------------------------------------------] 3.21 % 885.28 KB/s 1m
^C

Can you provide the output of cargo bisect-rustc --version? Mine is cargo-bisect-rustc 0.6.3, which was released on April 20th.

Can you provide the output of cargo bisect-rustc --version? Mine is cargo-bisect-rustc 0.6.3, which was released on April 20th.

Should be the same since I just reinstalled it (because broken libssl.1.1).
I will post these info again below.

cross 0.2.1 (7599e1a 2022-04-23)
cargo 1.61.0 (a028ae4 2022-04-29)
cargo-bisect-rustc 0.6.3

rustup 1.24.3 (ce5817a94 2021-05-31)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.61.0 (fe5b13d68 2022-05-18)`

I think the issue is how we get our toolchain name, which might make this an issue for non-standard Rust installs too. There probably should be a more robust way to get the toolchain name.
https://github.com/cross-rs/cross/blob/d90b016d1d4dc40fe2cc8cb89a2c79db1443f451/src/lib.rs#L316-L320

Sorry for the many notifications, but I doubt this is an issue in cross itself and seems to be an issue with cargo-bisect-rustc or how it handles toolchains. We can't really handle custom toolchains, since they don't let us add additional targets, etc., and this prevents cross from working with tools that use custom toolchains:
#!/bin/bash

set -x

sysroot="$(rustc --print sysroot)"
toolchain=$(basename "${sysroot}")
rustup target add powerpc64le-unknown-linux-gnu --toolchain "${toolchain}"
exec "rustup" "target" "list" "--toolchain" "${toolchain}"

I've made a simple script that tries to add a target and then list the available targets, the former which is absolutely necessary for cross functioning.
$ cargo-bisect-rustc --script=./list.sh -vv
installing nightly-2022-06-15
cargo for x86_64-unknown-linux-gnu: 6.56 MB / 6.56 MB [========================================================================================================================] 100.00 % 9.69 MB/s
testing...
++ rustc --print sysroot
+ sysroot=/home/ahuszagh/.rustup/toolchains/bisector-nightly-2022-06-15-x86_64-unknown-linux-gnu
++ basename /home/ahuszagh/.rustup/toolchains/bisector-nightly-2022-06-15-x86_64-unknown-linux-gnu
+ toolchain=bisector-nightly-2022-06-15-x86_64-unknown-linux-gnu
+ rustup target add powerpc64le-unknown-linux-gnu --toolchain bisector-nightly-2022-06-15-x86_64-unknown-linux-gnu
error: toolchain 'bisector-nightly-2022-06-15-x86_64-unknown-linux-gnu' does not support components: bisector-nightly-2022-06-15-x86_64-unknown-linux-gnu is a custom toolchain
+ exec rustup target list --toolchain bisector-nightly-2022-06-15-x86_64-unknown-linux-gnu
error: toolchain 'bisector-nightly-2022-06-15-x86_64-unknown-linux-gnu' does not support components: bisector-nightly-2022-06-15-x86_64-unknown-linux-gnu is a custom toolchain

We can't add our target for cross-compilation to this toolchain, since it's custom. The reason why it works (spuriously) for me on nightly is because, and to quote their tutorial:

First, if you have a nightly version of the compiler already installed as the default toolchain and you don't pass an end flag, the tool is going to assume that that's the version that has regressed and use it as the "bad" version. Otherwise would use that start point or just use the latest nightly. If you have provided a start flag it would use that as the "good" version, otherwise is going to search for a good one backwards.

Look at cargo-bisect-rustc handles this, it seems to manually download components itself, which makes sense considering it can't use built-in rustup functionality for this:
https://github.com/rust-lang/cargo-bisect-rustc/blob/ab94c3b48e291f4bf100bb3edf4f273624918c17/src/toolchains.rs#L189-L195
So I guess the bigger question would be: can we support custom toolchains by adding the desired target in this case?


Local index files from remote fetch not getting cleaned up property

On the current develop branch:
$ git status -s
$ nosetests tests/end_to_end/test_remote_fetch.py
..
----------------------------------------------------------------------
Ran 2 tests in 3.429s

OK
$ git status -s
?? chr1.vcf.gz.tbi
?? wgEncodeUwRepliSeqBg02esG1bAlnRep1_sample.bam.bai

We should investigate why these downloaded index files are not getting cleaned up properly.

One solution is to add a tearDown method to these tests, but that doesn't address the root cause:
    def tearDown(self):
        # clean up downloaded local index file
        for indexFile in glob.glob("*.tbi"):
            os.remove(indexFile)

Okay, here's the problem: the downloaded index files never get into the temporary directory because they are only downloaded when the first operation is performed against the remote file (say, a reads-search), not during initialization, as we erroneously assume in the code.  So here is what happens:

server startup -- temp dir is created, but nothing is moved into it, since no index files exist
fetch -- the index file is downloaded to the pwd
server shutdown -- the empty temp dir is deleted, but the index files in the pwd remain

Possible solutions:
A) perform some dummy search operation against the remote file immediately after initialization (troublesome; would have to know values inside file for meaningful query) to download the file and move it into the temp dir
B) for each remote file, keep track of whether it has had a successful request against it or not; if that transitions from no to yes, check for the downloaded file and move it to the temp dir
C) forget the whole temp dir thing and just delete all of the index files from the pwd on server shutdown
D) come up with some new non-urls.json design
I guess I don't like A and B because they involve changing the server's pwd, which is probably not a good idea.  C is probably the temporary solution I favor.

I'm not a big fan of (C) I'm afraid. In my view, programs should never write anything into PWD. What if the user has files of the same name in there? Also, this doesn't get around the problem of multiple processes writing the same files in the same directory (a nasty mess).  I'm not sure what PWD is for an WSGI process running in apache; it might not even be writable. Writing to the working directory is evil, and htslib's behaviour here is really nasty. Hopefully this is being fixed at the moment though, and we'll be able to come up with a sensible design some time soon.
What we have used to work before --- perhaps this is a consequence of the file handle cache?

Oh, good call!  The commit before the file cache merge 068caf51beaf1ad840c6ab3ab84b8a2b9dc3865e does not feature this issue but the one in which the cache is merged in 40bdc60eee6e82981abb8f18e27f7be88c7193d9 does.  So it indeed looks like the file handle cache introduced this problem.

+1 for requesting htslib API support for:

whether remote index files are saved
controlling where remote index files are written

-Kevin
On Wed, Jul 22, 2015 at 9:24 AM, Jerome Kelleher<EMAIL_ADDRESS>wrote:

I'm not a big fan of (C) I'm afraid. In my view, programs should never
write anything into PWD. What if the user has files of the same name in
there? Also, this doesn't get around the problem of multiple processes
writing the same files in the same directory (a nasty mess). I'm not sure
what PWD is for an WSGI process running in apache; it might not even be
writable. Writing to the working directory is evil, and htslib's behaviour
here is really nasty. Hopefully this is being fixed at the moment though,
and we'll be able to come up with a sensible design some time soon.
What we have used to work before --- perhaps this is a consequence of the
file handle cache?
—
Reply to this email directly or view it on GitHub
https://github.com/ga4gh/server/issues/500#issuecomment-123757411.

Just filed this: https://github.com/samtools/htslib/issues/247

The htslib issue I filed has been closed; apparently they added support for this last month.

related: https://github.com/pysam-developers/pysam/issues/87

@jeromekelleher if we close this issue we should open up another one (with the blocked tag) that describes the root problem

Good spot @dcolligan  --- I think github closed this issue automatically.


Exception on running az aks check-acr cmd

Command Name
az aks check-acr
Errors:
The command failed with an unexpected error. Here is the traceback:
'serverVersion'
Traceback (most recent call last):
  File "/opt/az/lib/python3.6/site-packages/knack/cli.py", line 231, in invoke
    cmd_result = self.invocation.execute(args)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 657, in execute
    raise ex
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 720, in _run_jobs_serially
    results.append(self._run_job(expanded_arg, cmd_copy))
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 691, in _run_job
    result = cmd_copy(params)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/__init__.py", line 328, in __call__
    return self.handler(*args, **kwargs)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/core/commands/command_operation.py", line 121, in handler
    return op(**command_args)
  File "/opt/az/lib/python3.6/site-packages/azure/cli/command_modules/acs/custom.py", line 1586, in aks_check_acr
    kubectl_version["serverVersion"]["minor"])
KeyError: 'serverVersion'

To Reproduce:
Steps to reproduce the behavior. Note that argument values have been redacted, as they may contain sensitive information.

Put any pre-requisite steps here...
az aks check-acr -n {} -g {} --acr {}

Expected Behavior
Environment Summary
Linux-5.4.0-89-generic-x86_64-with-debian-bullseye-sid, Ubuntu 20.04.1 LTS
Python 3.6.10
Installer: DEB

azure-cli 2.28.0 *

Extensions:
log-analytics-solution 0.1.1
storage-preview 0.7.4
azure-devops 0.20.0

Additional Context

route to service team

@tanalam2411 Apologies for the late reply. I am not able to repro this issue. I was able to successfully validate my ACR access using the below command:
az aks check-acr -g MyaksRG -n MyAKSName --acr MyACRName.azurecr.io
Merged "MyAKSName" as current context in C:\Users\******\AppData\Local\Temp\tmp__aa0tlp
[2022-02-14T03:19:36Z] Validating image pull permission: SUCCEEDED
[2022-02-14T03:19:36Z]
Your cluster can pull images from MyACRName.azurecr.io!

Here is the AzCLI and Python version I am using in my box. Could you please try to upgrade the python libraries and the most recent version of Azure CLI version and run the command again ? Awaiting your reply.
az --version
azure-cli                         2.33.0
core                                2.33.0
telemetry                          1.0.6

Extensions:
aks-preview                       0.5.51
ssh                                1.0.0

Dependencies:
msal                              1.16.0
azure-mgmt-resource               20.0.0
Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Extensions directory 'C:\Users\****\.azure\cliextensions'
Python (Windows) 3.8.9 (tags/v3.8.9:a743f81, Apr  6 2021, 13:22:56) [MSC v.1928 32 bit (Intel)]
Your CLI is up-to-date.


Discovery simplified [4739]

Simplified the usage of discovery module removing the "chosen" feature.
Rationale:
The use of the attribute chosen do not add a feature itself, it only gives to the user a concrete result for a concrete case. The same result can only be also obtained with few lines of code by the user, and with better management for his side. Furthermore, the "chosen" feature was forcing the use of reserve data for the ip into the uxrAgentAddress structure instead of a reference to an existant ip string.
Modified the function names.
Rationale:
There were two diferent function names: unicast and multicast. However, the behavior behind theses functions is not exactly what the name means. The unicast version can also receive several multicast ips, and the multicast version can only serach agent into the default multicast with the default port. For that, theses names have been changed.

[ ] Updated API docs.

Build status:

Linux
Windows
NuttX

Build status:

Linux
Windows
NuttX

Build status:

Linux
Windows
NuttX


Could you add your license to package.json please

Automatic license checkers fail to see your package is MIT licensed because it is not declared in package.json. Could you please update that? Thanks!

fixed in 1.1.1

Ultra fast, thanks!


ListItem button props set to hard true.

[x] The issue is present in the latest release.
[x] I have searched the [issues] (https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

Current Behavior 😯
Looking to ListItem type definition in the following path<EMAIL_ADDRESS>I find button property taking type of true.
declare const ListItem: OverridableComponent<ListItemTypeMap<{ button?: false }, 'li'>> &
  ExtendButtonBase<ListItemTypeMap<{ button: true }, 'div'>>;

Expected Behavior 🤔
Shouldn't  be a boolean instead of hard true ??
What is the reason of setting it to hard true ?
Steps to Reproduce 🕹
We are using styled-components here.
Steps:

Import ListItem from @material-ui/core'.
Style it with styled-components.
Use ListItem component without button prop. Eslint will produce an error message.
Code sandbox

Context 🔦
We are using ListItem as a menu list with button. but some of them are not using button for some special condition. We have to make a turn around to solve it. With this error, we can't use ListItem anymore to prevent inconsistent code.
Your Environment 🌎

Tech
Version

Material-UI
v4.11.0

React
v16.13.1

Browser
v 84.0.4147.135 (Official Build) (64-bit)

TypeScript
v4.0.2

Duplicate of #14971


不知道如何实现APNS数据给灵动岛widget，然后进行刷新ui

Hi @tiayako, have you checked out this doc:
https://developer.apple.com/documentation/activitykit/update-and-end-your-live-activity-with-remote-push-notifications

Hi there @tiayako, I have just submitted a pull request for updating Live Activity/Dynamic Island using APNs with a script to send APNs from your Mac for debugging. In the meanwhile you can see it here: https://github.com/alexandrereol/iOS16-Live-Activities-APNs


Sometimes cached checklists are not cleared

Ran into a situation where:

Previously opened a connected note with a checklist on the card
Open an unconnected note
Connect the note to a card with no checklist
There is a checklist shown

Refreshing does not fix it.

+1. Just noticed that this morning.

Also saw this, almost immediately into first use. Not a huge deal, I can ignore it, but kinda funny.


PyTorch 0.4.0 compatibility

To run the code with PyTorch 0.4.0 I had to change some lines.
This may be helpful for others, too.
It is not compatible with older PyTorch Versions, as I did not include a version-check yet.
Changes:

Replaced multinomial by Categorical (https://hub.packtpub.com/pytorch-0-3-0-released/)
data[0] -> .item()
Added batch-dimension
explicit in-place use of clip_grad_norm_

Thanks for this! What I'm going to do is add this branch to my repository, but keep it separate from master- that way people can still benefit from your changes. Since PyTorch is going to be upgrading to 0.5 and soon to 1.0, I'd rather just wait till its more stable before updating the master branch.

Can you close this PR, update your branch with the current master, and then submit a new PR to the pytorch-0.4 branch?


Restore tableName functionality

Fix tableName functionality that was accidentally removed
Improve by only specifying tableName when it's not default value of nil

@JiriTrecak
@solidcell @Performat This PR fixes the same issue as #49, but restores the tableName functionality.

Hey Rob,
excellent, thank you for this. It was indeed removed by accident.

@JiriTrecak Yes, accidentally removed by me! 😳


Add gh-release to build & attach assets to release

As discussed with @grobie and @juliusv in IRC, here a simple bash script to build and upload binaries for existing github releases.
This expects that a build command, defaulting to make archive, produces a tarball with the binary for GOARCH/GOOS. This works for the Makefile.COMMON projects, but not with prometheus since this doesn't allow to set GOARCH/GOOS via env variables.
This also requires a working cross compiler for the given targets, not sure if this is the case with the pre-built go release the Makefile installs.

Awesome, thanks! Long-term I'm hoping for something non-bashy, but this is a great start.

Agreed, we want non-bashy on the long run but for that we need to decide first how to actually build all the things on the long run :)

Yep, :+1: from me for now, we can always evolve this easily later - just please don't let anyone depend on it yet :)


Minor update to the Statements page

Closes #4265

This change is

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/6dc2c43f1b89206824c40e9aa9bf05ccd0cbbaf7/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/e7e92eeb66972a1f31b3385d57838305837a37f7/

http://cockroach-docs-review.s3-website-us-east-1.amazonaws.com/d969b3c1fff0a0e0def29b384a512c744eeddf26/


Combating version churn

First of all I just want to thank the maintainers/Microsoft for making these crates, having a set of maintained bindings that can supplant winapi and be confident will be maintained in the future has been really great.
Problem
That being said, I think the current velocity of version changes in this repo is a bit problematic for the ecosystem, especially as more crates adopt windows or windows-sys over winapi. This is because, for the past several months, the crates in this repo have have had their minor version bumped on average every couple of weeks, essentially guaranteeing that with enough transitive dependencies on one of the crates in this repo, a project's crate graph will include multiple versions of one or more windows crates. Duplicate versions can be fine for short periods of time as various crates catch up to newer releases, however the velocity of this repo is far greater than many crates in the ecosystem, especially in the windows-sys crate case of being low level system bindings.
For a simple example, let's take parking_lot.

parking_lot currently depends on windows-sys:0.34, which is around 1.5 months old
Someone helpfully added a PR to bump to windows-sys:0.35 (22 days old) about a week ago
windows-sys was bumped to 0.36 a few hours ago

parking_lot is now in a conundrum. It could accept the 0.35 PR, and cut a release, but there's already a newer version, so they could bump directly to 0.36 instead, skipping 0.35 entirely. However, depending on what other crates you have in your graph, either decision is (or the none option of just staying on 0.34) almost guaranteed to result in multiple versions of windows-sys as

Some crates will have transitioned to 0.35 sometime since it was released, but might take several days/weeks/months to move to 0.36
Some crates will be on 0.34 (or even older) versions like parking_lot
Some crates might move to 0.36 quite quickly, which could mean you're depending on up to 3! different versions of windows-sys simultaneously

The real kicker is that parking_lot uses a grand total of 3 function bindings and a few type/constant bindings which, beyond fundamental changes such as #1439, are...."never" going to change, thanks to Windows' backwards compatibility guarantees.
If we take a step back I see there being multiple reasons for this version churn

All (or at least all the "user facing" ones) of crates in this repo share a single version. On the one hand this is nice since versioning is internally consistent and makes perusing version history more easy etc. However, it's also a very big hammer, particularly in the case of windows-sys, as it means that any change in any crate in this repo, regardless of the downstream usage, results in a new version.
The Windows API surface is positively massive, and due to how the windows/-sys crates are organized via feature flags, any breaking change to one sub-API is technically a breaking change to the crate as a whole. This is despite the fact that an overwhelming majority of downstream users will use an incredibly small fraction of that massive API surface, meaning (again, other than fundamental changes such as #1439) that they're very unlikely to actually observe such a breaking change in practice.
Reiterating from above, the release cadence of this repo is just much higher than most other crates in the ecosystem, but because the bindings in windows/-sys are essentially the libc of Windows, many crates depend (or will, once they transition from eg. winapi) on them which coupled together mean multiple versions of one or more crates in this repo become almost inevitable

Possible Solutions
Below are several options that I can see that could solve, or at least alleviate, this problem. Obviously it's up to the maintainers on what they think is best (or if it will be considered a problem at all), so these are just some thoughts.

Stabilize and use patches. The crates in this repo are still early days so I doubt this could happen anytime soon, but having a model similar to libc, where they've been on a 0.2 minor version for years and only ever bump the patch version, means semver compatibility across the ecosystem. libc obviously has a bit of a simpler problem since the API surface is orders of magnitude smaller than Windows, but it is a proven model.
windows-sys in particular (maybe not windows?) could be more lenient about breaking semver. What I mean be this is, in an overwhelming majority of use cases, a crate using windows-sys will use an incredibly small fraction of the API surface exposed by it. This means that (again, beyond fundamental changes like #1439) that a breaking change in windows-sys, such as a moving constants or functions to a different location, are not going to be observed by the downstream crate at all unless they were using those exact functions/constants. Speaking for myself, this kind of breakage would be entirely acceptable if it was clearly stated in the release notes, or even just as a general caveat clearly stated in the README as it is trivial to find where a function/constant was moved to in a newer version and change it to the new location/feature flag. This is unfortunately not a super viable method for transitive dependencies however, I just thought I would mention it.
Make windows-bindgen a first class citizen (related #1407). At least in my use cases, and I believe many others, using Windows bindings is a fairly "write once" operation that generally doesn't change much past the initial implementation. For this kind of use case, having a convenient way to do "generate functions x, y, and z, and these constants to this output file" would be frankly amazing. For example, here's a recent PR I made to add minidump writing. In grand total, this uses 5 functions, ~6 constants, and ~6 types. These will most likely never change again, and by generating only the bindings I need, once, and just including them as a single source file directly in the project, I could get rid of the windows-sys dependency altogether, avoiding the problem of multiple versions now and in the future. If we go back to the parking_lot case above, it's already manually creating its own bindings to Nt* functions that are not part of Win32 metadata, and could do the same for the few functions/constants that it is using from windows-sys, but having that functionality exposed in a friendly way by a windows-bindgen tool would mean generating the bindings once and never having to worry about version churn in the future, because again, these functions/constants/types are not going to change

Closing
I'm sure the maintainers have probably thought about this issue already, but I'm opening this issue because I couldn't find anything relevant that was already open and want to foster a discussion in the open about this, since I'm sure we're not the only ones that find the current situation problematic.
Sorry this was a bit of a braindump I've just been thinking about this the last few days and wanted to finally just write it down.

I would also love to see a solution here. Of the options currently suggested, personally I think the third would be the nicest of those given for reasons you've already brought up. So I'll just summarize my thoughts here.
I'm not sure that libc is a good role model for these crates at this time. As you say, it's effectively stuck on 0.2 because of fears of another "libcpocalypse", where bumping the version from 0.1 to 0.2 broke the world. Eternal 0.2 may be manageable for libc but both windows and windows-sys are currently under much more active development. More worryingly, the upstream metadata is still tagging releases as a "preview" and makes frequent changes to fix both major and minor issues.
I would also not be keen on breaking semver as tooling does rely on it, although I do agree that any individual crate is unlikely to break on updates too often unless they happen to be one of the unlucky ones.
Which leaves making windows-bindgen a first class citizen. I think this is the best option because it leaves windows and windows-sys free to evolve while giving crates a way to opt-out of the, currently frequent, upgrade cycle.

Great issue! We are indeed aware of it, but an obvious solution is elusive. I will re-read the comments thus far and add any of my own. Keep it coming - I'm confident that together we'll come up with a good solution in the end.

Thanks @Jake-Shadle for the write up! We have indeed been thinking about this, but we've yet to come up with a good solution. Let me try to talk through the considerations (many of which you've already touched on) so we're sure we're on the same page. Hopefully this makes it easier to talk through possible solutions.

windows-sys is basically a raw projection of the win32metadata project into Rust.

That project is itself relatively new and therefore far from being able to declare stability guarantees. I will note that we hope to work closely with that project on ways to think about stability not as either 100% stable or 100% unstable.  Stay tuned...
windows-sys has effectively no internal logic (i.e., it is essentially a 1 to 1 mapping of the metadata), so the stability of windows-sys is 100% tied to the stability of win32metadata.

A single monolith solution broken up by features (i.e., the status quo) means that changes to any part of the win32 projection will result in version bumps, even if the particular piece of the Windows API a downstream crate is using does not change.

This leads to fracturing of the ecosystem like you mentioned in your post above with parking_lot and what libc ran into.
What's more any changes to the metadata will likely result in a breaking change to the public API and thus, under strict semver, require a major release. You mention the possibility of playing fast and loose with semver, but we'd prefer a solution that plays by the rules if possible.

A multi-crate solution (i.e., breaking up windows-sys into more manageable chunks that can evolve independently) is difficult. Due to its long history, the Windows API is not that well factored and there are many cyclic dependencies between different pieces of the API. This is something that the crates model does not allow for - for good reason.

It certainly seems possible to break up the surface in some way, but whether that leads to a solution that addresses the issues you laid out in a sufficient way, remains to be seen.

Providing code generation tooling is problematic. It is much more preferable to provide a crates.io based solution for all the same reasons that Rust prefers declarative crate dependencies rather than copy/pasting source code. The latter makes providing bug fixes, security patches, code reuse, etc. difficult and is an antipattern we'd like to avoid if possible.

And as @poliorcetics pointed out this can also easily lead to fractured ecosystem issues if folks start using such a solution in any publicly visible way.

My personal opinion is that a multi-crate solution (if possible) would be the right way to go. This is essentially the solution that Cargo and crates.io push us towards. It also makes other issues we've run into go away (e.g., rustdoc struggles with such a massive monolithic crate). However, the Windows API surface does not make this easy, so we still have to do work to even understand how we would begin to break up windows-sys.

This was also previously discussed here: https://github.com/microsoft/windows-rs/issues/432

In the short term, I'll probably exclude windows-sys from the regular 3-week release cadence that we've been on to allow the current version (0.36) to establish itself. Notably, windows-sys 0.36 has now been adopted by both tokio and parking_lot.

A multi-crate solution (i.e., breaking up windows-sys into more manageable chunks that can evolve independently) is difficult. Due to its long history, the Windows API is not that well factored and there are many cyclic dependencies between different pieces of the API. This is something that the crates model does not allow for - for good reason.

Would having one crate for all type definitions and then several for function declarations work? Function declarations can't have cyclic dependencies. Or do the type definitions also regularly change?

Would having one crate for all type definitions and then several for function declarations work?

I'm not sure that the developer experience hit would be worth it. Normally folks tend to think of APIs as functions and types bundled under some logical namespace. For example, if you're making an app that relies on direct2d, it feels natural if all of the APIs that logically fall under the direct2d banner are in 1 dependency. Having to break up by type vs function might be confusing, and I don't think it wins us a whole lot. I'll think about this more.

The types can be re-exported by the individual function crates.

A huge portion of the Windows API is defined in terms of COM and WinRT types and those don't really make sense to split up in that way either.

FYI: I have introduced an RFC mechanism in https://github.com/microsoft/windows-rs/pull/1731. At some point, when someone feels they have a solid understanding of the problem and a solution that addresses the concerns outlined in this issue, it would be good to open an RFC proposing how to address this. I know, for example, some folks at Microsoft are investigating the feasibility of a multi-crate approach.

Just a quick update on this issue. While I've been exploring a multi-crate solution, it is far from a home run.
I have excluded the windows-sys crate from the regular release cadence which seems to largely deal with the version churn in practical terms. For the foreseeable future, we will release updates to the windows-sys crate only when there is sufficient demand.
We are also doing a lot of work to reduce the overall size of the windows crate and it too will get to a point where it needs few if any updates and will also be able to move into a demand-driven release model.

I also wanted to mention that windows-bindgen should continue to improve and stabilize as an alternative to the pre-generated windows and windows-sys crates for even more demanding scenarios. We continue to work hard on improving Windows support but I'm still holding out hope that Rust itself can improve to make this less of a problem, as @joshtriplett mentioned here: https://github.com/microsoft/windows-rs/issues/1285#issuecomment-963033403
Anyway, I'll close this issue for now as there isn't really any actionable work here. Feel free to keep the conversation going and if new information comes to light, we can always revisit this topic.

I don't really see any reasoning here for why a multi-crate solution is not viable. All that was written is " While I've been exploring a multi-crate solution, it is far from a home run." What about it was not a homerun? It would be really great to get a breakdown of the pros and cons of each approach so others can get insight into the decision-making process here.

I don't really see any reasoning here for why a multi-crate solution is not viable.

I'm not necessarily saying it's not viable, although I have my doubts. I'm saying the original issue - version churn of the windows-sys crate - has been addressed. There were many other ideas floated here and we may continue to explore some of them. The multi-crate idea in particular is one I spent at least two weeks exploring but didn't arrive at a promising proof of concept. I may continue to explore that idea as time allows.

The multi-crate idea in particular is one I spent at least two weeks exploring but didn't arrive at a promising proof of concept.

This is exactly what I mean - it would be really nice to know the issues that were run into. Perhaps others have ideas on how to overcome the limitations you've found. Writing up your findings gives others a way to check your assumptions and assist in finding solutions.

Agreed and still plan to do that when I get a moment, probably using the RFC model.

@kennykerr it looks like the RFC hasn't happened. Can you give a brief summary what you tried for multi-crate solution and why it didn't work?

Looks like @Jake-Shadle has started pushing to remove windows-sys dependencies from lower-level libraries, and the PR to parking_lot has been accepted. Might be a good time to have some actual discussion about a better way forward?

We continue to work hard on improving Windows support but I'm still holding out hope that Rust itself can improve to make this less of a problem, as @joshtriplett mentioned here: #1285 (comment)

This seems unlikely to happen? Semver compatibility will always affect the whole crate's API surface at the same time, which makes it unacttractive to have wide-interface crates like windows-sys (and windows).
It seems to me that a great approach here would be to have good support for code generation in integration tests, where a (potentially default #[ignore]) integration test can generate source code (conceivably using the win32metadata and windows-bindgen crates?), similar to what is possible with tonic-build (example here).

I can reopen this issue if that would help with the discussion, but simply going through and targeting crates that use windows-sys is not helpful or constructive way to move forward.

It'd be beneficial if windows crate tooling can be used to generate minimal API bindings for crates (like parking_lot) that don't expose them publicly. Even better so if it allows the safer and more convenient windows bindings to be used without taking the compile-time hit that windows-sys was originally created for.
This however requires splitting the hand-written bindings, primitive types and other helpers from the generated code in the windows crate though (i.e. how there was a single bindings.rs file originally to support just the primitive types) so that that bit does not need to be generated into every crate (unless it is worth omitting in a significant number of uses). Really curious what others think, and if this can be competitive with windows-sys compile-time-wise :slightly_smiling_face:!

@kennykerr it seems like it's anyone's prerogative to go through and submit PRs that they think are improvements to any crates, and it's on the maintainers of such crates to decide whether they agree the changes are an improvement?
Despite questions in July and a followup in November it looks like you still haven't written up your thoughts on why you think a multi-crate approach isn't viable, so working around the lack of followup in this issue seems constructive (for the ecosystem) to me.
FWIW, I still have two versions of windows-sys in my Cargo workspace at work, so even the version churn problem hasn't quite been resolved (though that might be a matter of time). I'm also aware of at least one other proficient Rust user who built some tooling to subset part of the Windows Rust API, see https://twitter.com/rikarends/status/1615496481007345664 (though that's also about windows-rs, not just windows-sys, https://twitter.com/rikarends/status/1613123323088494598).

I'm not hand-writing the bindings, they are generated with a tool using the same windows metadata that is used to generate windows-sys bindings, the output is essentially equivalent.

@Jake-Shadle on this note @GamePad64 made a valid remark about the downside of "hand-writing" bindings because none of your PRs make clear to the crate authors/maintainers what tool was being used (can't find it on your GitHub either) nor how to use it to "update" their bindings when they want to use more Windows functionality (or less, or regenerate in case your tool and/or winmd becomes more extensive).
If the community/ecosystem is going in this direction of (at least partially) generating minimal bindings into crates, this effort should IMO be shared with the existing tooling and infrastructure already available here within the windows-rs repo, and hence live within this repo to be developed in tandem. (@djc while true that it's in every maintainer's right to steer their own crates, it'd be convenient if they all settle on a same/similar solution for fundamental / low-level bindings.)

looks like you still haven't written up your thoughts on why you think a multi-crate approach isn't viable

Briefly, I spent a few weeks trying to make it work but the circular nature of many APIs definitions collides with Cargo's restriction on circular dependencies and even when I artificially broke those cycles, the transitive tendency of APIs combined with crates and features meant that you ended up spending more time compiling rather than less and resulting in a far more complex model for specifying dependencies than merely using Cargo features.
Instead, I have been working for some time on new metadata tooling that we can use to more accurately reason about and manipulate metadata so that we can, for example, frequently publish non-breaking updates to crates while batching up breaking changes separately. We could then also more intelligently rebalance API groupings to avoid some the cycles and negative transitive dependencies and even generate targeted bindings for automatically. The metadata and tooling we have today simply doesn't support this, but I'm getting closer to a viable solution for these problems. We could then satisfy the competing demands for API additions and avoidance of breaking changes.

I'm working on moving from winapi to windows-sys in several PR here and at work and I can say that windows-sys is just as fast to build in practice as winapi, I never saw anyone complaining about winapi build times either, despite its features also activating hundreds of unused functions.
windows is bigger yes, and there the build times are affected, but it's also often unneeded for foundational crates luckily
Overall, I find working with windows-sys much more pleasant than manual bindings (hand-written or generated by a tool) since using a new call or type is often already present in the active feature set, with the needed types and all, there is no need to add more bindings in a file that is never documented.
Also, if the metadatas are updated because they were wrong, you now have crates with outdated bindings and no dependabot to warn you about it
"Manual" bindings are much shorter but I'm not certain the compile-time and readability gains even exist and if they do I'm not certain they're worth it

And yes, once https://github.com/microsoft/windows-rs/issues/1720#issuecomment-1485076573 is done we could conceivably publish a multi-crate solution.

I'm curious how the bindings used by parking_lot can be a time bomb

The windows and windows-sys crates include a dependency on the windows-targets crate that provides the libs for supported toolchains in order to resolve imports. parking_lot now assumes that some other crate or toolchain will implicitly provide those libs for all targets by default.

You can of course use the windows-metadata crate along with the windows-bindgen crate to generate bindings for whatever APIs you wish.
https://github.com/microsoft/windows-rs/blob/f3ef2cdfa7d812f1951d0421999fd1bbfa9fb7ae/crates/tests/component/build.rs#L16-L18
Today this is geared towards producing bindings for whole namespaces, but this could be extended to support discrete APIs if needed as well.

Here you go: https://github.com/microsoft/windows-rs/pull/2396
Let me know if this addresses the need.

Sure.

Thanks all!
https://crates.io/crates/windows-bindgen v0.47.0 has now been released and includes the new standalone code generation support.

Briefly, I spent a few weeks trying to make it work but the circular nature of many API definitions collides with Cargo's restriction on circular dependencies and even when I artificially broke those cycles, the transitive tendency of APIs combined with crates and features meant that you ended up spending more time compiling rather than less and resulting in a far more complex model for specifying dependencies than merely using Cargo features.

I looked at this recently-ish, and while I haven't gone as far as implementing something concrete, it seemed, at least for windows-sys (not sure about windows, I haven't dug deep enough in what its APIs look like), that splitting types and functions would solve the circular dependency problem. Is that something you considered?

@kennykerr is standalone bindings generation for the windows (not windows-sys) crate, with COM support and high level bindings, also still on your radar for this year? I feel that will also address these "splitting" issues for the majority of the crates that only need to bind to Windows, but don't have any such types in their public API (github.com/Traverse-Research/gpu-allocator does though, unfortunately - and it needs D3D12 COM access).

That is a much bigger task and something I'm working on, but I'd like to see how well the existing standalone support is received and adopted before adding support for the windows style bindings.
I've fixed all reported issues to improve the usability of this feature and I hope to see this help the Rust community improve support for Windows (#2416 #2421 #2426 #2430).

@Jake-Shadle let me know if there's anything else you need to wrap up parking_lot_core - that's the only one that currently seems to be in limbo - happy to publish an update to the windows-bindgen crate if the repo has everything you need.

Today this is geared towards producing bindings for whole namespaces, but this could be extended to support discrete APIs if needed as well.

I almost invariably need only a few definitions at a time (e.g. in quinn-udp), so this is appealing.

Just a quick update for those still following along. I'm nearly ready to publish the windows-core crate that takes the foundational support in the windows crate's core module and splits it out into a dedicated crate so that it may be used without the hefty windows crate and then support standalone code generation of the windows-style bindings.

The windows-core crate is now ready for testing, along with standalone code generation support for COM: #2475

@kennykerr thanks, this is looking very promising already! While in the process of converting one of my apps to use these minimal COM bindings, I ran into not getting the From<> binding from crates/libs/bindgen/src/extensions/mod/Win32/Foundation/BOOL.rs: how do I get that with standalone_win()?
Also, #2475 doesn't explain what and how to use standalone_std: documentation seems to indicate that it's for internal Rust STD library use?

Thanks for kicking the tires - please create new issues for any problems you discover - that way I won't forget to address them.
Yes, standalone_std is only for the Rust Standard Library's internal use. I'll update the following with more info:
https://kennykerr.ca/rust-getting-started/standalone-code-generation.html

@kennykerr thanks, I'll file a separate issue for the lack of extensions soon. Working code here: https://github.com/MarijnS95/windows-rs/commit/e8f36652fc1848a314f8235c620f8467d67fc661
Perhaps standalone_std could be renamed? I was wondering whether it'd give me std-specific implementations (and the rest would purely be Windows/core).


Remove old boundaries when setting new ones

As reported in #155, boundaries are not updated on Android.
After few investigations, I have understood that boundaries are added as non-temp behaviors and hence are accumulated over time in PhysicsAnimator animator. Hence even if the boundary property changes in react, it will not replace the old boundary constraint but rather be added to it.
My solution simply consists in keeping a reference on the previous boundary and remove it as soon as a new one is set to keep only one of them.
It might not be the most sophisticated way of doing so but it was sufficient for me and seems to work exactly as expected.

Changed back to
this.boundaries = boundaries;
animator.removeBehavior(this.oldBoundariesBehavior);
addConstantBoundaries(boundaries);

I have amended last commit

great
tnx man
this commit will fix my problem

Currently using this and it's working perfectly. Would love to get it merged.

works for me
thanks

Does anyone know how we could get the merged? I have another PR that I would like to submit afterward (https://github.com/Mbompr/react-native-interactable/commit/b644cf59f0ffc40388210f543309c1a9d4fc95a0)

Code looks good. Let's get this merged.

Thanks for the contribution! I am merging this, but please see my comment.


[IconMenu] Close when another IconMenu is tapped

PR fixes closed issues #6996 and #7841. [IconMenu] will now close when another is tapped, instead of overlapping.
Before:

After:

[x] PR has tests / docs demo, and is linted.
[x] Commit and PR titles begin with [ComponentName], and are in imperative form: "[Component] Fix leaky abstraction".
[x] Description explains the issue / use-case resolved (http://tr.im/vFqem).

This is a regression between the v0.18.7 version. Most likely linked to the touch tap change.

I propose the following change instead. What do you think about it?
src/IconMenu/IconMenu.js
@@ -207,8 +207,6 @@ class IconMenu extends Component {
       menuInitiallyKeyboardFocused: Events.isKeyboard(event),
       anchorEl: event.currentTarget,
     });
-
-    event.preventDefault();
   }

   handleItemTouchTap = (event, child) => {

Thanks for raising this issue!

I believe I tried that initially and received some unexpected side effects/behavior. But I will make this change, take a closer look, and update this thread with what I find. Thanks for your advice.

I'm closing (so we keep only active PR open) feel free to resume the work 👍 .

Thanks for your help. Your proposed change worked perfectly. I've submitted a new, separate PR.


Refactor how we set/restore ownership of drupal settings file to allow reuse...

...in containers based on this one.
The net effect of this PR on its own is none - everything works as before, I have simply factored out these two functions.
I'll be submitting a PR against isle-dc shortly where I make use of these functions to fix an issue occurring there.

Here is the issue this refactoring helps to fix: https://github.com/Islandora-Devops/isle-dc/pull/208


Revert "replication factor to be obtained from tenant configuration in case of dimension table"

Reverts apache/pinot#7848
Hi @Manis99803 and @Jackie-Jiang,
I'm proposing a revert here since I don't think this is the right way to calculate the storage quota for a dimension tables. Dimension tables, by design, are expected to be distributed to all the servers in a tenant so there is not much value in multiplying the size with server count.
Using this logic, a table which used to satisfy quota requirements will exceed the limit even if you simply add more servers to a tenant, which is counterintuitive. Server administrators may need to update quota limits for all dimension tables with cluster size changes, which can be cumbersome.
I propose keeping the old notation where the quota value represents the limit for a single replica of the table, which is easier to reason about.
Let me know what you think

Codecov Report

Merging #7912 (60e1e84) into master (aa2da07) will decrease coverage by 0.92%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #7912      +/-   ##
============================================
- Coverage     71.32%   70.40%   -0.93%
+ Complexity     4092     4091       -1
============================================
  Files          1589     1589
  Lines         82139    82134       -5
  Branches      12270    12269       -1
============================================
- Hits          58589    57824     -765
- Misses        19578    20337     +759
- Partials       3972     3973       +1

Flag
Coverage Δ

integration1
29.09% <100.00%> (-0.16%)
:arrow_down:

integration2
?

unittests1
68.32% <ø> (-0.02%)
:arrow_down:

unittests2
14.37% <100.00%> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

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

The problem is from the meaning of the storage quota value, which counts storage for all replicas. E.g. Storage quota of 30G for a table with 3 replicas allow 10G segments per replica.
For a dimension table, the change is actually trying to apply the same logic, where storage for all replicas are counted. Without the change, storage quota for dimension table with different replicas has different per replica limit, but replication does not really apply to dimension table.
I feel a clean solution would be introducing the per replica storage quota. Add @jackjlli here who contributed the storage quota feature.

The goal of introducing the storage quota is safeguard the storage from being overused. The current logic to calculate total storage quota for a generic table is as follow:
long allowedStorageBytes = numReplicas * quotaConfig.getStorageInBytes();

The quota value above denotes the upper limit of a single replica, not for all the replicas. So the quota config has already been used for a single replica.
Since dimension table is a special case of table that is replicated to all the servers, which means that every server will hold a complete dataset for the dimension table. In this case, the replication isn't controlled by the replica config from table config but purely by the number of servers.
E.g. suppose the single replica for a dimension table is 8G and the storage quota is 10G. If there are 3 servers, the total table size would be 8G x 3 = 24GB, and the total storage quota would be 10G x 3 = 30GB, which is valid. If 2 more servers are added to the same tenant, the total table size would become 8G x 5 = 40G and the total storage quota would become 10G x 5 = 50G, which is still valid. Thus, the code change seems fine to me.


Cross database join

Does the current version support cross database join or not? I looked at some examples but they all seem to be in the standard sqlite3 library that comes with XCode. Thanks.

What do you mean by cross database join?


App Engine Connection Pool

This is currently very rough and early. I want to make sure I'm on the right track before continuing.
Outstanding questions:

What functionality should be covered by the connection pool? (retries, etc.)
Should I just inherit from TestConnectionPool and null out the tests that aren't applicable to GAE instead of duplicating code?
How should this connection class be wired in? On GAE Sandbox environments w/o sockets, I assume this should be default.
What exact edge cases should this class be aware; e.g, where does URLFetch behavior differ from what's expected of httplib/sockets? Do the tests already cover this?

[shazow edit: Fixes #664]

@Lukasa @sigmavirus24 Would love your thoughts on some of the open questions inline:

What functionality should be covered by the connection pool? (retries, etc.)

Hm, I've been thinking about this. I think it may make more sense to have the AppEngine URLFetch driver be at the Manager-level (see poolmanager.py) rather than ConnectionPool-level because it doesn't make sense for our PoolManager/ProxyManager/etc to manage pools of GAEConnectionPool, right?
This should make things a fair bit more straight-forward. Any other opinions/ideas?

Should I just inherit from TestConnectionPool and null out the tests that aren't applicable to GAE instead of duplicating code?

Ideally there shouldn't be too many duplicate tests. Any overlapping functionality should be inherited (and thus won't need to be exercised separately) whereas any new functionality should be tested explicitly, right?

How should this connection class be wired in? On GAE Sandbox environments w/o sockets, I assume this should be default.

This is a good question, and it'll depend if we go with the ConnectionPool-level or Manager-level. The other question is: How automatic/implicit vs explicit should this be?

What exact edge cases should this class be aware; e.g, where does URLFetch behavior differ from what's expected of httplib/sockets? Do the tests already cover this?

Honestly I was hoping that's something you could inform us about. We're not too sure how URLFetch differs, as we don't use it ourselves. :/
Another thought: It may be better to start this off as a urllib3/contrib/ submodule. Our standards for those are somewhat lower, so it'll be easier to get this work merged and start to be used by the community while we figure out how we want to integrate it into the core API.

@jonparrott Btw, thank you again for volunteering to tackle this. We very much appreciate your time and effort. :)

Hm, I've been thinking about this. I think it may make more sense to have the AppEngine URLFetch driver be at the Manager-level (see poolmanager.py) rather than ConnectionPool-level because it doesn't make sense for our PoolManager/ProxyManager/etc to manage pools of GAEConnectionPool, right?
This should make things a fair bit more straight-forward. Any other opinions/ideas?

The downside of this is that GAE no longer becomes transparent to users. The ideal case would be that libraries that use urllib3 just magically work on GAE, and I don't think that'd be true if the AppEngine driver was a replacement for PoolManager instead of a replacement for ConnectionPool. Though I'm a little concern that I missed what you were aiming for here.

This is a good question, and it'll depend if we go with the ConnectionPool-level or Manager-level. The other question is: How automatic/implicit vs explicit should this be?

My vote is for automatic and implicit. The reason to do explicit is to force users to know that something different happens on GAE, but what we're doing there is pushing responsibility for testing and debugging those differences onto our users, when we should be the ones bearing that burden.

Ideally there shouldn't be too many duplicate tests. Any overlapping functionality should be inherited (and thus won't need to be exercised separately) whereas any new functionality should be tested explicitly, right?

Cool, I'll inherit from the other test and null out the cases that aren't applicable.

Honestly I was hoping that's something you could inform us about. We're not too sure how URLFetch differs, as we don't use it ourselves. :/

I can help, absolutely, but as I mentioned before I'm not intimately familiar with how URLFetch works under the covers (though I guess I could look). Most importantly, I'd like to know what things you guys are already aware of.

It may be better to start this off as a urllib3/contrib/ submodule

Fine with me.

PoolManager vs ConnectionPool

I'm cool with it either way, it seems the implementation is basically the same (urlopen). Let me know what you guys decide.

@jonparrott Btw, thank you again for volunteering to tackle this. We very much appreciate your time and effort. :)

No worries, I'm here to help make GCP a great place for Python developers.

My vote is for automatic and implicit.

We should be aware of what we're doing to users if it's automatic and implicit, and the user should always be able to switch. Here's a comparison of App Engine's environments and the caveats I'm aware of:

_
Local Dev Server
GAE (Sandbox)
GAE (Managed VMs Compat)
GAE (Managed VMs Custom)

URLFetch
:heavy_check_mark:
:heavy_check_mark:
:heavy_check_mark:
:x:

Sockets
:heavy_check_mark:
limited1
:heavy_check_mark:
:heavy_check_mark:

PyOpenSSL
maybe2
optional3
optional4
optional5

Custom certs
:x:
depends6
:heavy_check_mark:
:heavy_check_mark:

Only paid apps, can't access google apis, etc. limitations
It's up to the user to have PyOpenSSL installed on their system.
Sandbox users have to explicitly list this, and it's a fixed, google-provided version.
Users can either use the method in 3 or modify their dockerfile / requirements to include it.
Users should be able to just add this to their requirements, but failing that, can add it to their dockerfile.
URLFetch doesn't support custom certs, but sockets + ssl do.

So, we need to figure out what the best implicit behavior is for each environment (I have code that can reliable detect this) and how to give users the ability to change it.

The downside of this is that GAE no longer becomes transparent to users. The ideal case would be that libraries that use urllib3 just magically work on GAE, and I don't think that'd be true if the AppEngine driver was a replacement for PoolManager instead of a replacement for ConnectionPool. Though I'm a little concern that I missed what you were aiming for here.

@Lukasa Why not? We could swap out PoolManager with GAEPoolManager at runtime same way we swap in VerifiedHTTPSConnectionPool. Or maybe we need to finally add another layer above PoolManager which would do this implicitly (we've been talking about adding a Session object? Or another name?).
The silly thing is that ConnectionPool objects are there to manage pools of connections (via our queue collections), which URLFetch does not have (those are managed behind the scenes by URLFetch). In effect, URLFetch is an interface to a ConnectionPool-type object. Then the PoolManager would make an instance of these ConnectionPool managers per host, which would really add nothing in terms of functionality—runtime complexity and stack depth (and possibly GAE-incompatible bugs therein).
Plus, it's not like any of our Manager-features would work with URLFetch without more interception too. For example, ProxyManager wouldn't work.

@shazow I've moved the pool into the contrib directory.

Why not? We could swap out PoolManager with GAEPoolManager at runtime same way we swap in VerifiedHTTPSConnectionPool.

I suppose, but...ewww. It feels really weird to do that at runtime if we can possibly avoid it, though I suppose it's an acceptable approach.
Basically, I don't like it, but I can't articulate a good reason. Consider me -0 on that idea. =P

Actually, no, I think that might be fine. If it were me I'd probably take the stack depth hit, but if that's off the table, the 'patch at runtime' approach is fine.

@Lukasa Please do me a favour, sleep on it and try to articulate why you feel negative about it, I'm curious. :) Either way it's going to be a patch at runtime, right? Whether we swap the ConnectionPool or the PoolManager. Only difference is that a ConnectionPool of ConnectionPools is an extra unnecessary layer of abstraction, as far as I can tell. There's no benefit, and some potential surprises (e.g. ProxyManager not working with it).
I'd really like to get somekind of consensus on this as I think this decision will inform how we move forward in our future designs. I still suspect that adding another layer above PoolManager which automagically manages the correct things might be the best and least-surprising option.

I still suspect that adding another layer above PoolManager which automagically manages the correct things might be the best and least-surprising option.

It's your library, but adding another layer of complexity just to support GAE's sandbox doesn't sound fun to me. If there's other use cases beyond just supporting GAE for this then I'm cool with it.

It's your library, but adding another layer of complexity just to support GAE's sandbox doesn't sound fun to me. If there's other use cases beyond just supporting GAE for this then I'm cool with it.

Yea it's something we've talked about before. urllib3 in general is largely about being very manual/explicit, but more and more we move towards autodetecting/autoconfiguring which creates a schism. Putting all that magic in one place might help keep things more sane: Things like setting up good TLS defaults, proxy settings from .netrc/env vars, platform-specific injections, maybe someday cookie handling (ugh).

Gotcha, sounds good to me.

AFAIK URLfetch does not support chunked encoding, so when we use it implicitly streaming APIs will not work anymore.

AFAIK URLfetch does not support chunked encoding, so when we use it implicitly streaming APIs will not work anymore.

From RFC 7230 Section 4.1:

A recipient MUST be able to parse and decode the chunked transfer coding.

The only way URLFetch gets around that requirement is by advertising themselves as a HTTP/1.0 client. Do they do that?

@Lukasa See #620. AppEngine handles chunking but only gives us the dechunked response.

@jonparrott Probably a dumb question: What was the advantage of using URLFetch explicitly instead of using implicitly via the httplib-URLFetch shim?

@jonparrott Probably a dumb question: What was the advantage of using URLFetch explicitly instead of using implicitly via the httplib-URLFetch shim?

It's more a decision for you guys, but it's one less layer of indirection. GAE's httplib just calls this under the covers. I figured it would be best to work directly with the fetch method ourselves than try to bend GAE httplib to our will.
Also, there's the case where users can replace httplib so there's no promise that it's using URLFetch anymore.

@shazow any decision on Pool vs Manager?

@Lukasa Any new thoughts on ConnectionPool vs Manager? I'm still leaning on Manager.

I think I'm still with you on Manager, tbh.
Altogether this is just one of those nasty areas where neither solution feels great to me, but avoiding the extra level of indirection is probably the way to go.

Cool, I'll switch it over to a manager class soon. I just pushed a new updated addressing some of @t-8ch's feedback.

Alright, it's been moved over to a connection manager. Still re-using the connection pool tests, as they seem to provide the most relevant tests.
Questions from here:

What functionality is missing from the connection manager? (retries?)
What exceptions are expected from urlopen? presently, I just have TimeoutError.

What functionality is missing from the connection manager? (retries?)

In approximate order of priority:

SSL/TLS configuration
Optional retries (based on retries field, using our Retry configuration object)
Optional redirects (based on redirect and retries configuration).
Proxy support (probably configured on init).

What exceptions are expected from urlopen? presently, I just have TimeoutError.

SSLError
MaxRetryError (if retry/redirects are a thing)
ProxyError (if proxy support is a thing)
ProtocolError (if the response violated HTTP expectations).
Regarding TimeoutError, note that there is ReadTimeoutError (request possibly sent but failed did not read the response successfully) and ConnectTimeoutError (failed before sending the request, safe to retry). Would be great to differentiate them if possible.

Any thoughts on naming classes AppEngine* rather than GAE*?

I'm cool with renaming.

SSL/TLS configuration

What configuration is there? For URLFetch, it's either "validate" or "don't validate".

Optional retries (based on retries field, using our Retry configuration object)

I can do this.

Optional redirects (based on redirect and retries configuration)

URLFetch can follow redirects, but I'm unsure about the error on depth, and there's no way to configure the depth.

Proxy support (probably configured on init)

No proxy options for URLFetch.

Granular timeout (using our Timeout configuration object)

Probably not possible.

Sounds good, thanks @jonparrott. Would be good to do a AppEnginePlatformWarning for anything that we're explicitly not supporting in urlopen that is otherwise available. Either way, this is already huge progress over what we had. :)

What configuration is there? For URLFetch, it's either "validate" or "don't validate".

Any way to supply your own cacerts?

Any way to supply your own cacerts?

Nope. :(

Renamed to AppEngineManager. I'm going to wire up the remainder of exceptions then move on to "features".
Any word on how to get this wired up? I'd like to write a real GAE app that can run through a bunch of cases and make sure everything works in the real environment.

Okay, all the exceptions that URLFetch can throw should be mapped appropriately. I also added a test case to verify that self-signed certs will fail.

@jonparrott This is great, thank you!
Re filename, I think urllib3/contrib/appengine.py is probably sufficient.
To start, we can do:
from urllib3.contrib.appengine import AppEngineManager

http = AppEngineManager()
# Now you can use `http` as any other urllib3 pool/manager

r = http.request('GET', 'https://google.com/')

I think where we are is good enough to merge? Next up we'll need to start thinking about how we want to make the instrumentation implicit with the normal urllib3 flow, so you don't need to be as aware of your environment to use urllib3. After that, move it out of contrib and documentation. :)

Got a few simple tests running on production app engine here: http://python-urllib3-gae-int-tests.appspot.com/
Discovered that URLFetch in the live environment handles deflate encoding but doesn't remove the header. Fun times. Pushed code to fix that.

Ah fantastic, thank you for your thoroughness. :)

Alright, I've finished the environment detection code and cleaned up the commit message. I think the outstanding things now are:

Implement retries?
Should AppEngineManager throw ProtocolErrors or AppEnginePlatformErrors?

Thanks for working with me here, hopefully this can make the "support app engine's weirdness" story much more contained for you guys.

Implement retries?

That would be great, at least some subset of retry functionality.

Should AppEngineManager throw ProtocolErrors or AppEnginePlatformErrors?

I vote for AppEnginePlatformError since the errors are specific to limitations of running on the AppEngine platform, or alternatively a new exception that subclasses it.

Cool, exceptions updated. Looking into retries now.

Okay, so I've noticed a inconsistency here:

Redirects are also considered to be a subset of retries but can be configured or disabled individually.

Presently, AppEngineManager has a separate redirect parameter. Should I remove that and use retries's redirect value instead? The issue is that URLFetch's follow redirects is boolean and doesn't allow you to configure how many times it'll try.

redirect controls whether redirects are enabled or disabled (boolean). retries.redirect controls how many redirects are followed before giving up and raising a MaxRetryError.
So you should primarily look at redirect to enable/disable same as URLFetch, then you can do the same platform warning if retries.redirect is set (since it's not supported). Also, assuming there is a max-redirects error, would be swell to wrap it in our MaxRetryError exception.

Solid, will do.

Retry logic implemented:

It'll redirect, but treat any truthy values of retries.redirect the same (and warn about it)
It'll raise a MaxRetryError if URLFetch indicates too many redirects occurred.
It will behave as normal for the forced retry stuff.

(that was way harder than it should've been)
I think that does it @shazow.

Looks sensible, just need to cleanup some debugging code and ideally match up logging messages with other pools.
Could use another pair of eyes, though. (@Lukasa @t-8ch @sigmavirus24?)

Removed the debugging stuff (that's what I get for trying to get this pushed before I left yesterday).

@Lukasa Can you give this a quick look-over? I want to include this in the v1.11 early next week.
@jonparrott Would you be up for adding a bit of docs for how to use this module? It can live here for now: https://github.com/shazow/urllib3/blob/master/docs/contrib.rst -> https://urllib3.readthedocs.org/en/latest/contrib.html
Something along the lines of...
from urllib3.contrib.appengine import AppEngineManager

http = AppEngineManager()
r = http.request('GET', 'https://google.com/')

And maybe a little blurb for detecting which AppEngine environment you're in, a recipe for swapping out the respective manager, and that this will happen automagically as soon as AppEngineManager graduates from contrib-land. :)

@shazow I'm certainly happy to have this in contrib land for the next release.

Fixed stuff in @Lukasa and added some docs in contrib (thanks for writing the sample for me, @shazow).

@jonparrott This is fantastic and invaluable. Thank you so much for helping us out here, I'm very excited about this and the urllib3/requests community really appreciates your contribution but even moreso: I'm sure all the AppEngine users will be just ecstatic! Make sure to link to this thread in your promo packet, you really deserve some recognition for your work. :) :heart: :custard: :sparkles:

Happy to help. I'm sure this will have bugs and fun edge cases, so please mention me on any bugs that get filed on this.

@jonparrott Thanks so much for responding when I sent up the Bat-Signal!


bug(autocomplete): Autocomplete's overlay panel overlaps element's which are in front of the input when scrolling

Reproduction
See: https://angular-rczreu.stackblitz.io (demo), https://stackblitz.com/edit/angular-rczreu (source)

Steps to reproduce:

Focus any autocomplete input and have option panel open
Scroll down until you see autocomplete's option panel move outside the scrollable area

Expected Behavior
Panel should not be visible outside the scrollable area, is this even possible based on how the CDK panel is rendered as a separate overlay layer in the DOM? I suspect this is a technical limitation.
An alternative to fixing this is to make autocomplete match mat-select's panel's behaviour -- no scrolling is possible at all if the mat-select's panel is open. This is not the case with mat-autocomplete's panel, perhaps it should be.
Actual Behavior
Panel moves outside the scrollable area
Environment

Angular: Version should not matter
CDK/Material: 10.1.2 (also occurs on 9.1.2) (and I'm assuming versions before and between those too stated version as well)
Browser(s): Firefox, Chrome, Should not matter
Operating System (e.g. Windows, macOS, Ubuntu): Should not matter, Ubuntu, Windows

Overlay does have an API for doing something when an item scrolls out of view:
https://github.com/angular/components/blob/d321d450c4102e2079041765bd7f01da2757d7e6/src/cdk/overlay/position/flexible-connected-position-strategy.ts#L994-L1023
This is just only turned on for tooltip at the moment.


chore: refactor pointer_view to reference-based get_all

Originally, pointer_view was a compromise as we didn't have a good way of making an iterable structure of references. Now with RefVector, we can move away from pointer_view

Benchmark results
Metrics with a significant change:

note_trial_decrypting_time_in_ms (32): 50.3 (-34%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit 8ff37800 and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
128 txs

l1_rollup_calldata_size_in_bytes
45,444
179,588
716,132

l1_rollup_calldata_gas
222,888
867,740
3,449,492

l1_rollup_execution_gas
841,975
3,594,848
22,204,861

l2_block_processing_time_in_ms
2,109 (+1%)
8,139
33,649

note_successful_decrypting_time_in_ms
311 (-3%)
924 (-3%)
3,370 (-3%)

note_trial_decrypting_time_in_ms
22.2 (-26%)
:warning: 50.3 (-34%)
200 (-1%)

l2_block_building_time_in_ms
20,540
82,401 (+1%)
334,220 (+2%)

l2_block_rollup_simulation_time_in_ms
16,940
68,179 (+1%)
276,076 (+2%)

l2_block_public_tx_process_time_in_ms
3,551 (+1%)
14,071 (+1%)
57,576 (+3%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
23,023
44,684

note_history_successful_decrypting_time_in_ms
2,159 (-1%)
4,175 (-1%)

note_history_trial_decrypting_time_in_ms
161 (-1%)
228 (-2%)

node_database_size_in_bytes
3,306,175
3,646,606

pxe_database_size_in_bytes
29,748
59,307

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
202 (+1%)
43,077
20,441

private-kernel-ordering
116 (+1%)
25,833
9,689

base-rollup
3,009 (+2%)
664,108
873

root-rollup
89.4 (-2%)
4,072
1,097

private-kernel-inner
264 (+2%)
64,484
20,441

public-kernel-private-input
174 (+1%)
25,203
20,441

public-kernel-non-first-iteration
171 (+1%)
25,245
20,441

merge-rollup
11.0 (-1%)
2,592
873

Miscellaneous
Transaction sizes based on how many contracts are deployed in the tx.

Metric
0 deployed contracts
1 deployed contracts

tx_size_in_bytes
10,323
25,938


TreeExplainer does not work for CatBoost

Hi!
I trained a Ctaboost model and wanted to do
explainer = shap.TreeExplainer(c), which gives an error.
`---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
 in
----> 1 explainer = shap.TreeExplainer(c, model_output='probability')
2 #shap_values = explainer.shap_values(X_train)
/opt/conda/lib/python3.6/site-packages/shap/explainers/tree.py in init(self, model, data, model_output, feature_dependence)
85         self.feature_dependence = feature_dependence
86         self.expected_value = None
---> 87         self.model = TreeEnsemble(model, self.data, self.data_missing)
88
89         assert feature_dependence in feature_dependence_codes, "Invalid feature_dependence option!"
/opt/conda/lib/python3.6/site-packages/shap/explainers/tree.py in init(self, model, data, data_missing)
643             self.input_dtype = np.float32
644             cb_loader = CatBoostTreeModelLoader(model)
--> 645             self.trees = cb_loader.get_trees(data=data, data_missing=data_missing)
646             self.tree_output = "log_odds"
647             self.objective = "binary_crossentropy"
/opt/conda/lib/python3.6/site-packages/shap/explainers/tree.py in get_trees(self, data, data_missing)
1230
1231             # load the per-tree params
-> 1232             depth = len(self.loaded_cb_model['oblivious_trees'][tree_index]['splits'])
1233
1234             # load the nodes
IndexError: list index out of range`
Shap version '0.31.0'
Catboost version '0.18'

I got same problem. If you fix the problem please update! thanks a lot

The following works for me:
import catboost
import shap
X,y = shap.datasets.boston()
model = catboost.CatBoostRegressor()
model.fit(X, y)
explainer = shap.TreeExplainer(model)
shap_values = explainer.shap_values(X)

Can you share a self contained example that does not work? Thanks!

I am also facing same issue , i am clueless about the error.
IndexError: list index out of range`

Works perfectly for me now! Sorry for the late reply.
Thank you very much!


Support RequestHeaderEncoding in ServiceFabric

Follows https://github.com/microsoft/reverse-proxy/pull/760

Thanks


publish co-browser.js to npm

When a repository lacks an .npmignore file, npm will fall back on .gitignore. Currently co's .gitignore specifies co-browser.js which is keeping it from being published to the npm even though it's generated in the prepublish npm step.
@jonathanong Looks good?

no, you should just be adding it to the .files array in the package.json instead :)

Done

@jonathanong Can we land this?

@tj ? It's been two weeks and this is a one line manifest change to get a browser build into the npm package. Curiously https://github.com/tj/co/commit/ab5815f7e874748c236655f98374ac00d3663721 seems to think it solved this issue...

+1

Wait for a moment, @gaye if using browserify, why do you need this file?

It's good to have around for non-browserify, browser consumers

Sound good.

@jonathanong Publish a new patch version to npm? Or add me to the npm owner list too?

I don't see co-browser in npm for 4.6.0. Does that mean that files array doesn't work?

This fix came in after 4.6.0 @szarouski . Can we get a 4.6.1 / 4.7.0 with this available please? :)


Remove storybook from web code

What this PR does / why we need it:
This is one of the steps to simplify our development process and codebase.
This PR removes all storybook files since they have become quite outdated compared to our recent UI changes and we don't use them much in our development process.
Which issue(s) this PR fixes:
Fixes #
Does this PR introduce a user-facing change?:

NONE

Thanks Storybook for your serve
/approve


Rotary encoder: Reboot on click, wrong order for volume

Hi there,
I followed the instructions on how to implement a KY-040 rotary encoder for volume changes.
The instructions worked, wiring was simple, service is running.
I ran into two issues:

The knob worked the wrong way: Turning it CW decreased the volume, CCW increased the volume. I was able to change that by switching the binary commands in rotary_encoder_base. So this is no longer an issue anymore, but it's still strange that I had to change this

When I push the button the RasPi reboots, I'm not exactly sure why. I checked the wiki as well as the rotary-encoder.py file itself and tried to include a switchPressed() but that didn't do anything.

Any help here would be appreciated because rebooting the Pi is really something that I don't want to do when this button is being pushed, ideally it should toggle the volume or don't do anything at all.
Thanks for this project by the way, it's awesome.

After a reboot the button click now mutes the volume which is fine. Not sure what changed though.

fix for the wrong direction had been submitted and merged into dev sometime ago. In order not to break existing installations, the documentation was changed instead of the code. So please revert the changes in the code and swap CLK and Data pins of your encoder to stay compatible with future releases.

I ran into the same issue. Funny enough, my test setup worked fine, but now after building the real box, turning the KY-040 CW lowered the volume instead of increasing it.
My first guess was to simply switch the GPIOs assigned to volU and volD in gpio-buttons.py, that did not do anything though.
Thanks to this issue here I had a look at rotary_encoder_base.py as well and checked the encoder state bits as mentioned above.
I found that my code looked like this
KeyIncr = 0b00000010
KeyDecr = 0b00000001

which is exactly the other way around than in the current version of the file.
I changed the settings to
KeyIncr = 0b00000001
KeyDecr = 0b00000010

and now setting the volume with the KY-040 works just fine.
By the way, I did a fresh install and followed the guide for the rotary encoder sometime around the beginning of December 2019.

GPIO control (since 2.2) completely overhauled the implementation.
Please try to use the new version. If the problem still occurs, feel free to reopen this issue.


run: forward to invenio run extra parameters

For example -h <IP_ADDRESS>, every other parameter accepted by invenio run or even by flask run (which are the same) should be forwarded.

+1 for -h <IP_ADDRESS> to allow dev mode to work on a non-localhost machine

Supported with -h and -p


How to send Mattermost authentication headers to check whether the socket is connected successfully using Starscream library?

I need to check whether the socket connection established successfully. In order to verify that how to send the following mattermost authentication header over the connection?

{ "seq": 1, "action": "authentication_challenge", "data": { "token": "mattermosttokengoeshere" } }

How can I verify that the socket is connected successfully in my project.

@daltoniam please suggest me an answer


MRG: Use fft instead of fftn

I suspect this should yield some modest speed gains. We were using an N-dimensional general fftn for 1D FFTs when I think we should be able to use the 1D fft instead.
cc @jona-sassenhagen

According to git blame this is another @agramfort 2011 relic :)

Current coverage is 86.84% (diff: 100%)

Merging #3498 into master will not change coverage

@@             master      #3498   diff @@
==========================================
  Files           339        339
  Lines         59442      59442
  Methods           0          0
  Messages          0          0
  Branches       9090       9090
==========================================
  Hits          51624      51624
- Misses         5086       5090     +4
+ Partials       2732       2728     -4

Powered by Codecov. Last update c0d956c...ad66071

thx @Eric89GXL


Basic support for Mapbox / OSRM endpoint

This PR approaches #1265.
So far the implementation is still quite limited, but works well in my tests with the Mapbox SDK. This PR tries not to change anything in the GraphHopper core.
Some of the current limitations are:

Some of the response data is faked, including, driving_side, maneuver bearings, intersection data
The available request parameters are very limited
Voice instructions generation is pretty simple, every instruction is only spoken once
Banner instruction generation is pretty simple

Let me know what you think about the current state :).

I updated this PR, improved the error logging and changed the way the points are parsed.
Let mw know if we can merge this or if there is anything else?

This feature will be developed in its separate repository: https://github.com/graphhopper/graphhopper-navigation