[WIP] Use PathBuf instead of String to handle paths

I think this is it. I want to take another look tomorrow to validate that I didn't miss something.
For #213
Make sure these boxes are checked! 📦✅

[x] You have the latest version of rustfmt installed and have your
cloned directory set to nightly

$ rustup override set nightly
$ rustup component add rustfmt-preview --toolchain nightly

[x] You ran rustfmt on the code base before submitting
[x] You reference which issue is being closed in the PR text

✨✨ 😄 Thanks so much for contributing to wasm-pack! 😄 ✨✨

This is going to conflict with #211 so one of us will have to rebase depending on which gets merged first.

@fitzgen thank you! I don't have the rights to merge. Do you?


tidy up links in cardy

The External link heading makes me think of a link which goes to another website, not sure what a better term is though.
Perhaps Internal link could be In page link?

@gestchild how about Link and Internal target?
source

Yeah, that works


fix(curriculum): typo in step 10

targetting -> targeting
Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[ ] My pull request has a descriptive title (not a vague title like Update index.md)
[ ] My pull request targets the main branch of freeCodeCamp.
[ ] I have tested these changes either locally on my machine, or GitPod.

Closes #XXXXX

Would you be interested in making similar change in one more step? https://github.com/freeCodeCamp/freeCodeCamp/blob/36363f277db1cefbdb3ea5db91a8dc7f4c244ca8/curriculum/challenges/english/14-responsive-web-design-22/learn-css-transforms-by-building-a-penguin/step-075.md

Would you be interested in making similar change in one more step? https://github.com/freeCodeCamp/freeCodeCamp/blob/36363f277db1cefbdb3ea5db91a8dc7f4c244ca8/curriculum/challenges/english/14-responsive-web-design-22/learn-css-transforms-by-building-a-penguin/step-075.md

PR for this fix: https://github.com/freeCodeCamp/freeCodeCamp/pull/44823/commits/b94369cbbf8e0eb7df4034d848ec9bd5eba3e432


HBASE-25778 The tracinig implementation for AsyncConnectionImpl.getHb…

…ck is incorrect

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 15s
Docker mode activated.

-0 :warning:
yetus
0m  4s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ HBASE-22120 Compile Tests _

+0 :ok:
mvndep
0m 21s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 52s
HBASE-22120 passed

+1 :green_heart:
compile
0m 57s
HBASE-22120 passed

+1 :green_heart:
shadedjars
8m 51s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 51s
HBASE-22120 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 45s
the patch passed

+1 :green_heart:
compile
0m 57s
the patch passed

+1 :green_heart:
javac
0m 57s
the patch passed

+1 :green_heart:
shadedjars
8m 58s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 49s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
2m 11s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 38s
hbase-client in the patch passed.

38m  5s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3165

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 617f41ab479d 4.15.0-128-generic #131-Ubuntu SMP Wed Dec 9 06:57:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-22120 / 39a227a1f3

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/1/testReport/

Max. process+thread count
218 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 33s
Docker mode activated.

-0 :warning:
yetus
0m  2s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ HBASE-22120 Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 32s
HBASE-22120 passed

+1 :green_heart:
compile
0m 53s
HBASE-22120 passed

+1 :green_heart:
shadedjars
8m 58s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 43s
HBASE-22120 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 19s
the patch passed

+1 :green_heart:
compile
0m 58s
the patch passed

+1 :green_heart:
javac
0m 58s
the patch passed

+1 :green_heart:
shadedjars
9m 35s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 47s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
2m 22s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 33s
hbase-client in the patch passed.

38m 20s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/1/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3165

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 53999a8066d5 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-22120 / 39a227a1f3

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/1/testReport/

Max. process+thread count
224 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/1/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 39s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ HBASE-22120 Compile Tests _

+0 :ok:
mvndep
0m 28s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 15s
HBASE-22120 passed

+1 :green_heart:
compile
2m  6s
HBASE-22120 passed

+1 :green_heart:
checkstyle
1m  2s
HBASE-22120 passed

+1 :green_heart:
spotbugs
2m  4s
HBASE-22120 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 28s
the patch passed

-1 :x:
compile
1m 10s
hbase-client in the patch failed.

-0 :warning:
javac
1m 10s
hbase-client in the patch failed.

+1 :green_heart:
checkstyle
1m  0s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
24m 25s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0.

+1 :green_heart:
spotbugs
2m 15s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 26s
The patch does not generate ASF License warnings.

56m 30s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/1/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3165

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux ea60722ce644 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-22120 / 39a227a1f3

Default Java
AdoptOpenJDK-1.8.0_282-b08

compile
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/1/artifact/yetus-general-check/output/patch-compile-hbase-client.txt

javac
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/1/artifact/yetus-general-check/output/patch-compile-hbase-client.txt

Max. process+thread count
96 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/1/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 34s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ HBASE-22120 Compile Tests _

+0 :ok:
mvndep
0m 22s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 39s
HBASE-22120 passed

+1 :green_heart:
compile
0m 59s
HBASE-22120 passed

+1 :green_heart:
shadedjars
8m 38s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 54s
HBASE-22120 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 16s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 17s
the patch passed

+1 :green_heart:
compile
0m 58s
the patch passed

+1 :green_heart:
javac
0m 58s
the patch passed

+1 :green_heart:
shadedjars
8m 46s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 53s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
2m  9s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 21s
hbase-client in the patch passed.

36m 17s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/2/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3165

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux eef4de5e56fe 4.15.0-112-generic #113-Ubuntu SMP Thu Jul 9 23:41:39 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-22120 / 39a227a1f3

Default Java
AdoptOpenJDK-11.0.10+9

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/2/testReport/

Max. process+thread count
312 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/2/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 27s
Docker mode activated.

-0 :warning:
yetus
0m  3s
Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --whitespace-eol-ignore-list --whitespace-tabs-ignore-list --quick-hadoopcheck

_ Prechecks _

_ HBASE-22120 Compile Tests _

+0 :ok:
mvndep
0m 32s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 30s
HBASE-22120 passed

+1 :green_heart:
compile
0m 57s
HBASE-22120 passed

+1 :green_heart:
shadedjars
9m 32s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 43s
HBASE-22120 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m  6s
the patch passed

+1 :green_heart:
compile
0m 50s
the patch passed

+1 :green_heart:
javac
0m 50s
the patch passed

+1 :green_heart:
shadedjars
9m 17s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 43s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
2m 14s
hbase-common in the patch passed.

+1 :green_heart:
unit
1m 30s
hbase-client in the patch passed.

38m  4s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/2/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3165

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux b816510026a7 4.15.0-136-generic #140-Ubuntu SMP Thu Jan 28 05:20:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-22120 / 39a227a1f3

Default Java
AdoptOpenJDK-1.8.0_282-b08

Test Results
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/2/testReport/

Max. process+thread count
228 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/2/console

versions
git=2.17.1 maven=3.6.3

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 29s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ HBASE-22120 Compile Tests _

+0 :ok:
mvndep
0m 23s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 50s
HBASE-22120 passed

+1 :green_heart:
compile
1m 47s
HBASE-22120 passed

+1 :green_heart:
checkstyle
0m 51s
HBASE-22120 passed

+1 :green_heart:
spotbugs
1m 43s
HBASE-22120 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 36s
the patch passed

+1 :green_heart:
compile
1m 46s
the patch passed

+1 :green_heart:
javac
1m 46s
the patch passed

+1 :green_heart:
checkstyle
0m 52s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
hadoopcheck
18m  3s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1 3.3.0.

+1 :green_heart:
spotbugs
2m  5s
the patch passed

_ Other Tests _

+1 :green_heart:
asflicense
0m 25s
The patch does not generate ASF License warnings.

44m 13s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/2/artifact/yetus-general-check/output/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/3165

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux f1964a4ded73 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-22120 / 39a227a1f3

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
96 (vs. ulimit of 30000)

modules
C: hbase-common hbase-client U: .

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3165/2/console

versions
git=2.17.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.12.0 https://yetus.apache.org

This message was automatically generated.


Issue with Flux git password

https://github.com/aws-samples/aws-cdk-eks-flux/blob/22285365f277542abf12cbeb7341a62283d134eb/fluxcd/fluxcd_cluster.py#L24
This is failing to properly encode the password.

Hi @rpavez
Would you mind to share more details about your error? OS version? CDK version? Python version and libraries?

Hi @rpavez ,
I am going to close this issue as I don't have updates since more than 60 days. Please, open a new issue if you are still facing this issue.
Regards


Release version 1.4.1

Hi there!
Would you be open to releasing a new patch version of the lib/image with any bugfixes since the last release? I can see there's a 'latest' tag in the Docker Hub from October 2020 but no corresponding tag, and it'd be awesome if there was a tagged release associated with it.
Thanks for the useful project!

We released 1.5.1


Added Invert Grab.

Thank you for your contribution, I'll publish this ASAP!
I'll just check real quick if I find a way to IL hook the dash coroutine here, this could be useful for other variants as well... I'll keep you updated on this PR!

I finally found a way to hook the dash coroutine here: https://github.com/max4805/Everest-ExtendedVariants/commit/bfb2cd7e9bab5dc5d2c6b8d36fd65c79e8022e34
To patch IL in "coroutine" methods, Everest looks for a nested type having a MoveNext() method. This method actually contains the code of the routine. Extended Variants has a way to find this method and IL-hook it as well. I applied it to Invert Grab and to the Stamina variant.

Nice, It's really fun to play games with your mod


Add mod download speed limit options

My internet connection is weak to the point that downloading mods can disrupt gameplay and possibly sever my connection to the server. It would be nice if there were a setting to manually limit the download speed.

Now add a way to remove the limit.

Now add a way to remove the limit.

easiest way to fill up your storage with pointless mods you're never gonna use/ nsfw mods


Add reflection support for mobs, reflective vest, shuttle walls, syndie CE suit

About the PR

it addresses this issue by adding ReflectComponent to BaseMobOrganic and some mentioned items*. it contains some SharedReflectSystem logic for extensible handling of multiple equipment reflection layers. this is my first time with this repo/C#/ECS programming; I'm hesitant to refactor ReflectComponent (having both Enabled and Layers is clunky) before review.
*i don't personally remember shuttle walls or the syndie CE jumpsuit having reflection, but that was like 10 years ago.
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl:

add: Added reflection to the reflective vest and a few other things...

Based. Will review today.

If you're adding reflection to the syndicate CE jumpsuit also add it to the Nanotrasen ship vs. ship variant please, or at least give it another similarly good buff. It'd be dumb if the NT-sided CE was just worse for no reason.

A few value tweaks for this review.

if reflectprob is going to be 1 I need to maintain a uid:prob map for cumulative probability instead of a pure numeric solution because of div0 errors. I'll write it tn

what other events cause item removal?

what other events cause item removal?

What do you mean by item removal?

what other events cause item removal?

What do you mean by item removal?

items being removed from players

okay, this is cleaner. the probabilities behaved as expected when tested. i hope i handled player slots correctly?

okay, this is cleaner. the probabilities behaved as expected when tested. i hope i handled player slots correctly? i used them instead of a mapping because it's safer. do you squash merge or should i rebase

We squash merge. Doesn't hurt to rebase tho cause that's how I do it.

Otherwise this looks fine.

Also please remove references to the Syndie CE suit since it's not part of the PR anymore.
Otherwise this looks fine.

done. i'll rebase my commits next time. thanks!

JUST noticed the CL.
Make the CL reflect the additions you made.


Update Jenkins spellbook to reflect PR 7881

Post-Commit Tests Status (on master branch)

Lang
SDK
Apex
Dataflow
Flink
Gearpump
Samza
Spark

Go

---
---
---
---
---
---

Java

Python

---

---
---
---

See .test-infra/jenkins/README for trigger phrase, status and link of all Jenkins jobs.

R: @pabloem, @markflyhigh


Add seam.devices.unmanaged.get method

Depends on https://github.com/seamapi/seam-connect/pull/4131

can someone slack dm me when this gets merged? I'll need to update docs.

Doc has been updated:
https://docs.seam.co/latest/core-concepts/devices#convert-managed-device-to-unmanaged


sequence loop layer

generative-art-opensource V3

how to do this?

If someone helps me write the code, I will not leave it without a reward


Module parse failed: Unexpected token (24:32)

installed version "x5-gmaps": "0.7.0"
any suggestions ?

@kberawala your error looks to be pointing to the optional chaining used  (?.) but I don't know why you would have that error. Only thing I can think of is an old node version?
Regardless, I have released v0.7.1 and removed optional chaining just in case. Not really important, it's just cleaner code.
Try that and let me know.

I am using x5-gmaps version 0.7.2 (vuestorefront for magento 2, node v16.15.0) and got the same error

Hey @Simbiryan, you are having the same error on the same line?
Can you try v0.7.3 which I just released?
Any chance you can try node v18 (just to test)?
I cannot replicate this and so can't really debug it.

Apologies for the slow reply. Can you edit the actual file in the npm folder to replace the optional chaining with the old way?
if (oldAPI && oldAPI.parentNode) oldAPI.parentNode.removeChild(oldAPI);

I can't replicate so can't see if this is the problem?

Actually, I found the error on codesandbox, made an update (v0.7.6) and seems to work now. Try that if you're still wanting to use this!


CurlHandler vs StreamHandler getSize for gzipped response

PHP version: 7.3.15
Description
I see different results for getSize requesting a page with Content-Encoding gzip. CurlHandler always returns 0 (but Content-Length header is present). StreamHandler returns the correct size. If a handler is not able to return the correct size it would be nice to return null as documented.

How to reproduce
<?php

require_once __DIR__ . '/vendor/autoload.php';

$handlers = [
    'Curl' => new \GuzzleHttp\Handler\CurlHandler(),
    'Stream' => new \GuzzleHttp\Handler\StreamHandler(),
];

foreach ($handlers as $handlerName => $handler) {
    $client = new GuzzleHttp\Client([
        'handler' => $handler,
    ]);

    $response = $client->get('http://rss.kicker.de/news/2bundesliga', [
        'debug' => false,
    ]);

    echo $handlerName . ' Status code: ' . $response->getStatusCode() . "\n";
    echo $handlerName . ' Body size: ' . $response->getBody()->getSize() . "\n";
}

Possible Solution

Additional context

cc @phillmac as we talked about that on gitter.

Found some time to run another test today with Guzzle 7.3.0. Curl and Stream report the same content lenght now :partying_face:


add support for extreme networks devices.

Like the X670-G2-48x

Hello @ckannan,
is this something you would like to work on? I am afraid that:

I am not familiar with that device.
I don't have any extreme switch to develop/test
I don't have time to support devices other than the ones I have in my network.

However, I do have time to help people extending NAPALM and adding support to new devices so if you have time and you want to work on this let me know.
Regards.
David

As nobody seems to pick up this task I am going to close it.


Use autosummary to generate API docs

Fixes #50
Use autosummary to generate the full API docs for each module. rst pages
for each module are created automatically. Each function/class has it's
own page to make it easier to find what you want.
This only works with imported members (in the __init__.py files)
because I separated the build in 2: 1) generate the rst stubs with
sphinx-autogen and the --imported-members flag 2) build the HTML with
sphinx-build. This is a recent change in sphinx and using
autosummary_generate = True in conf.py won't work
(sphinx-doc/sphinx#3235).
The stub pages are created in the generated folder. Added this folder
to make clean and included some new rules in the Makefile:

api: runs sphinx-autogen
serve: serve the _build/html folder on localhost:8015 (useful
for previewing)

It would be good to add a 1-sentence summary of each package in the
docstrings to populate the table of modules that autosummary makes.

Thanks for this, Leo... Not sure I'm doing it right. I run make html as before? I get this:
writing output... [100%] index
<autosummary>:: WARNING: toctree contains reference to nonexisting document 'generated/bruges.attribute'
<autosummary>:: WARNING: toctree contains reference to nonexisting document 'generated/bruges.filters'
<autosummary>:: WARNING: toctree contains reference to nonexisting document 'generated/bruges.noise'
<autosummary>:: WARNING: toctree contains reference to nonexisting document 'generated/bruges.reflection'
.
.
.

There are a lot of lines like that -- maybe one for each function?
I tried make api too, but I get this sort of thing:
(bruges) Agile-iMac:docs matt$ make api
sphinx-autogen --imported-members -t _templates -o generated index.rst
[autosummary] generating autosummary for: index.rst
[autosummary] writing to generated
WARNING: [autosummary] failed to import 'bruges.attribute': no module named bruges.attribute
WARNING: [autosummary] failed to import 'bruges.filters': no module named bruges.filters
WARNING: [autosummary] failed to import 'bruges.noise': no module named bruges.noise
WARNING: [autosummary] failed to import 'bruges.reflection': no module named bruges.reflection
WARNING: [autosummary] failed to import 'bruges.rockphysics': no module named bruges.rockphysics
WARNING: [autosummary] failed to import 'bruges.transform': no module named bruges.transform
WARNING: [autosummary] failed to import 'bruges.unit': no module named bruges.unit
WARNING: [autosummary] failed to import 'bruges.util': no module named bruges.util

Built API docs.

But the folder generated is empty.
Any thoughts?

But I do end up with documentation, so maybe it's all good?!

@kwinkunks that's weird. make html should build the API docs first before running sphinx-build. Oh, I forgot to mention that I enabled the sphinx_rtd_theme so you'll have to install that as well. It's on conda-forge.

As I feared, it's not working on RTD http://bruges.readthedocs.io/en/develop/
I googled for a way to make RTD run a specific command for building but I couldn't find a way. A workaround would be stop using sphinx-autogen and downgrade to a version of sphinx before the "feature" sphinx-doc/sphinx#3235 was added.


Selenium/Geckodriver consumes all memory

Mostly wanted to say Thanks! I'm not sure I can troubleshoot it.
Altair_saver is much faster (~6x for me) than doing geckodriver on charts one at a time.
On Linux with Firefox, altair_saver with selenium/geckodriver steadily consumes memory while running through iterations (done with multiprocessing) and crashes. Switching to node with method eliminates memory consumption.

Thanks for the report – there's probably some selenium cleanup or garbage collecting that is missing from the package.

Since Altair 5.2, the functionality of Altair Saver is now available in Altair via the vl-convert package. Most of the functionality has been available since 5.0, and the main addition in 5.2 was PDF export. See the docs on how to save charts for more details.
We are going to archive this repo, so I'm closing all the open issues and PRs before doing so. Try out the new options for saving charts mentioned above and if you run into issues, please open an issue directly in the altair or vl-convert repo.


Update Home Office guidance & standards link

GitHub repo has been deprecated and replaced with new site.

thanks @ezramorris


rewrite multiplayer spawner and synchronizer, making it a module

Fixes https://github.com/godotengine/godot/issues/62027
Fixes https://github.com/godotengine/godot/issues/61711
Fixes https://github.com/godotengine/godot/issues/62320
CC @Faless
Note for reviewers: replication_editor_plugin.* and scene_replication_config.* are not modified, except for #ifdef TOOLS_ENABLED and some imports.
multiplayer_spawner.* and multiplayer_synchronizer.* have changed considerably.

Note the use of RPCs. It isn't going to be perfectly space efficient, but there isn't much data being sent other than Variants (which are encoded the same way as the previous synchronizer), it's not a big deal. Only other issue is the methods are technically exposed to GDScript, allowing the user to override them. I worked around it by naming the methods _internal_rpc_..., but there should be a better solution. See https://github.com/godotengine/godot/issues/32585.
Edit: I am only naming them _rpc_ because thinking again, I think private methods should be inaccessible (un-overridable?) by default.

Nice work! I'm not qualified enough to review the code but I can confirm that it resolves the scene root syncing issue (https://github.com/godotengine/godot/issues/62027)
While you're at it, do you happen to have any ideas regarding #62320? That issue is still present here

I did take a look at #62320, but I don't think it'll be resolved here. I'll give it a test though!

Well, that took quite a while! I believe I got https://github.com/godotengine/godot/issues/62320 resolved, and I also got spawner subchildren working.
Explanation:
Problem:

Previously, when a client joined, the server would receive the peer_connected signal and each Spawner would send the client the nodes that were needed. However, since signals are not called in a deterministic order, it was possible for the player spawner to send its RPC before the World spawner even created it.
Solution:
Now, the server doesn't listen to peer_connected, but rather the client requests the spawns/syncs when the spawner is initialized. This also prevents errors if for whatever reason the Spawner/Synchronizer exists on the server but not the client. This also paves the way for proposals such as https://github.com/godotengine/godot-proposals/issues/3904, since the server no longer expects all clients to have the same Spawners and Synchronizers. (Lots of work is still needed, however, as there is nothing preventing a client from pretending to have those nodes)

I wish you had written a proposal, or contacted me about this, I've been doing work on interest management that will collide with this PR.

Also in general, using RPC this way is really not okay, since it causes each synchronizer to send it's own data alone, unlike the previous design where updates from multiple synchronizers would be bulked together saving a ton of bandwidth for small states.

I wish you had written a proposal, or contacted me about this, I've been doing work on interest management that will collide with this PR.

To expand on this, I really appreciate your work in trying to implement those features, and I like the idea of clients requesting spawns, which is something likely needed, but there are some issues with the way this has been rewritten:

The MultiplayerReplicationInterface is there specifically to allow modules/extensions to implement the replication API, and should not be removed, to the contrary, it should be exposed to GDExtension once completed.
The MultiplayerSynchronizer and MultiplayerSpawner are "configuration" nodes, they implement their behaviors by calling into the replication interface (which needs a global overview to perform the appropriate optimizations).
As I mentioned above, RPCs for synchronizations are not okay, because we really need to pack updates together as much as possible or it will perform poorly as soon as the number of synchronized objects grow.

I am currently finishing my work on the interest management proposal, which should also solve some of the issues, I would be happy to discuss further changes on top of that if needed.
Again, I really appreciate you working on this, and I think there are good ideas, but it cannot be accepted as is, and I would advise against putting more work on this before I finish the work on interest management proposal, because that should solve most of the issues already, and would certainly conflict with this. This came at an unfortunate timing, I am sorry about it :/ .

Attempting some trials:
Specification:

Client connects to server.
Server spawns N nodes for client using MultiplayerSpawner.
After some idle time, client picks a random location and sends it directly to the server in an rpc. time starts now.
Server receives the RPC, sets the position of all nodes, and should eventually synchronize all positions.
Once ALL nodes are in the correct position, time stops and is recorded.

Task
Synced 10 nodes
Synced 100 nodes
Synced 1000 nodes

Godot Master - Average latency after 10 trials
326ms
469ms
757ms

Pull request - Latency after 1 trials
318ms
333ms
700ms - 3000ms

The fundamental problem with too many nodes:

Assume connection has arbitrary bandwidth limit of 200 unreliable packets per frame
Each node sends a packet, meaning 1000 unreliable packets
Assuming 200 packets make it through every frame
It will take 30-40 frames for all nodes to be synced.

Layman's terms:

Given a group of 1000 people, every timestep 200 random people are given a glass of water. After 30 timesteps, it is still likely that some particular person has never received their water.

I think a great improvement would be bundling the data into a single packet

The MultiplayerReplicationInterface is there specifically to allow modules/extensions to implement the replication API, and should not be removed, to the contrary, it should be exposed to GDExtension once completed.

Hmm. I don't see what is particularly important about abstracting the replication interface. I'd imagine the biggest use case for multiplayer modules would be another multiplayer peer type (e.g. a Steamworks module that makes RPCs go through steam). Even if someone wants to modify the replication interface, they could disable the module and write their own (or copy some code).

The MultiplayerSynchronizer and MultiplayerSpawner are "configuration" nodes, they implement their behaviors by calling into the replication interface (which needs a global overview to perform the appropriate optimizations).

As I mentioned above, RPCs for synchronizations are not okay, because we really need to pack updates together as much as possible or it will perform poorly as soon as the number of synchronized objects grow.

I agree with both! How about, following your work with interest management and approval, I move all the functionality (e.g. networked spawning/syncing) to a singleton, which manages the spawners/syncs and bundles requests together?

The MultiplayerReplicationInterface is there specifically to allow modules/extensions to implement the replication API, and should not be removed, to the contrary, it should be exposed to GDExtension once completed.

Hmm. I don't see what is particularly important about abstracting the replication interface. I'd imagine the biggest use case for multiplayer modules would be another multiplayer peer type (e.g. a Steamworks module that makes RPCs go through steam). Even if someone wants to modify the replication interface, they could disable the module and write their own (or copy some code).

I just want give my opinion in that, I believe every piece of code that can be made abstract/extendable should be, as that is one of the ultimate reasons why I enjoy Godot as an engine in the first place, and should hopefully remain so into the future.
Generality is slower then specialization, but can often support specialization while still being generic.

See https://github.com/godotengine/godot/pull/63049 :heart:


Post-merge hook for lockfile sync

One workflow that could be quite nice is to automatically run uv sync post-merge if there are any incoming changes to the lock file. That way, everyone's development environments can stay synchronized automatically.

I think uv lock should suffice for pre-commit as added in #13. What benefit is there to doing uv sync? The virtual environment should not be committed.

Definitely don't want to be committing the virtual environment.
If you are working on a codebase with a frequently changing lockfile, then often the main branch will be merged back into a dev branch, updating the lockfile, but rendering your environment out of date. Yes, the lockfile might automatically get updated every commit on the dev branch with uv lock, but this doesn't do anything to ensure your environment is up-to-date.
One way to deal with this is to display a warning when the lockfile is out-of-sync with the current environment, but if it's happening frequently, users might just want to automatically run uv sync after any merge rather than having to remember to do it themselves. It might also make it easier to deal with merge conflicts in the lockfile (?).

This is exactly what I was looking for 😄
My projects are currently based on Poetry and I have these hooks set-up, and they are just great to keep project in sync, especially since dependabot updates my dependencies on a daily basis.

post-checkout would also be a good stage to run this after

I second this too.
For projects that frequently change the uv.lock file, I've added a post-merge hook to inform developers to run uv sync locally.
It would be nice to have this as a built-in post-merge hook.

@nathanjmcdougall
@zanieb
Correct me if wrong but I assume there is no perfect solution for this.
According to pre-commit documentation post-merge hooks always run, regardless of which files have changed.

post-merge hooks do not operate on files so they must be set as always_run: true or they will always be skipped.

Therefore, adding a post-merge hook to check if only uv.lock or pyproject.toml has changed and then running uv sync is not possible.
Basically, uv sync will always run after each merge, regardless of which files were modified.
With this consideration, a sample hook will look like this:
- id: uv-sync
      name: uv-lock
      description: "Automatically run 'uv sync' after merge or pull"
      entry: uv sync --locked
      language: python
      args: []
      stages: [post-merge]
      always_run: true
      pass_filenames: false
      additional_dependencies: []
      minimum_pre_commit_version: "2.9.2"

@nathanjmcdougall
@zanieb
Correct me if wrong but I assume there is no perfect solution for this.
According to pre-commit documentation post-merge hooks always run, regardless of which files have changed.

post-merge hooks do not operate on files so they must be set as always_run: true or they will always be skipped.

Therefore, adding a post-merge hook to check if only uv.lock or pyproject.toml has changed and then running uv sync is not possible.
Basically, uv sync will always run after each merge, regardless of which files were modified.
With this consideration, a sample hook will look like this:
      - id: uv-sync
      name: uv-sync
      description: "Automatically run 'uv sync' after merge or pull"
      entry: uv sync --locked
      language: python
      args: []
      stages: [post-merge]
      always_run: true
      pass_filenames: false
      additional_dependencies: []
      minimum_pre_commit_version: "2.9.2"

You are right, however uv being fast, the overhead would be acceptable for most of us.
Besides, I remember git hooks are providing base and head commits, I don't know if pre-commit passes them but we could check if pyproject.toml or uv.lock has changed between both to detect if sync is required.

@lachaib Another option is implementing a pure python script to do this and use it as entry point.
When stages is set to post-merge pre-commit does not pass file names even if pass_filenames is set to true.

I am looking after this feature too.
PDM provides such a hook, pdm-sync, it runs on post-checkout, post-merge and post-rewrite. I think it runs every time, but as pointed out by @lachaib uv is so fast this is acceptable. Moreover, it is an opt-in behaviour.
In the meantime, I am using an alternative solution using direnv. I set it up to watch for changes in uv.lock and to run uv sync, something along those lines:
# Rerun .envrc whenever uv.lock changes
watch_file uv.lock
uv sync --quiet
# Bonus: automatically active the virtual env
direnv_load uv run direnv dump


Support use of the Singularity runtime with Docker .tar archives

This did not appear to be supported in earlier versions of Singularity, but definitely is now. Just need to run:
singularity build image.simg docker-archive://<name>.tar

The problem mentioned above has been resolved. Docker archives, either .tar or .tgz work now with Singularity.


Add decorable multithread iterator

Add multithread version of decorable iterator

Coverage increased (+3.0%) to 89.113% when pulling fc37393a2a49ba930fa8a3fdffe8d7ff69c989ff on feature/decorable_multithread_iterator into 15e0b1f42bae6622d31a4692337c9014081f20ca on master.


initial gamma distribution

thanks @franrruiz i'll fix it up and ping you

@franrruiz I would be ready for another review... I think I have addressed all your issues

thanks @hbq1

Apologies for the delay with merging your PR, and thanks a lot for sending it in @kashif!


[DOCFIX] docfix for Running-Alluxio-on-a-Cluster.md

docfix for Running-Alluxio-on-a-Cluster.md

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/16453/
Test PASSed.

Merged build finished. Test PASSed.


Problems in current published v1.0 and beta metadata on 2020-09-21

When attempting to generate code from the current state of metadata from the service metadata urls on 2020-09-21, I found the following problems:
v1.0:

Entities without keys:

    microsoft.graph.policyRoot
    microsoft.graph.educationRoot
    microsoft.graph.cloudCommunications
    microsoft.graph.planner
    microsoft.graph.security
    microsoft.graph.appCatalogs
    microsoft.graph.teamwork
    microsoft.graph.informationProtection

beta:

Entities without keys:

    microsoft.graph.auditLogRoot
    microsoft.graph.policyRoot
    microsoft.graph.bitlocker
    microsoft.graph.compliance
    microsoft.graph.identityContainer
    microsoft.graph.trustFramework
    microsoft.graph.directory
    microsoft.graph.roleManagement
    microsoft.graph.educationRoot
    microsoft.graph.identityGovernance
    microsoft.graph.identityProtectionRoot
    microsoft.graph.officeConfiguration
    microsoft.graph.financials
    microsoft.graph.planner
    microsoft.graph.print
    microsoft.graph.security
    microsoft.graph.commsApplication
    microsoft.graph.external
    microsoft.graph.appCatalogs

The fix for all of these is to add the attribute BaseType="graph.entity" but of course that's for you guys to confirm. I notice that the current state of the metadata in this repository seems to have these issues fixed (I didn't check all of them). When will the new metadata be published?
BTW thanks for exposing this metadata repo! Just what I wanted (assuming that the Graph team address issues raised here!).

I've updated the description above with the complete list of entities without keys.  Would be nice if some sort of validation happened on the metadata before getting published to the v1.0 and beta endpoints.

@davidmoten We reported this issue and I expect the metadata to be reverted for those listed types in the next couple of days. We do our metadata capture in this repo on Tuesday morning around, 6pm PST. Moving forward, entities that represent a singleton will not have entity as a base type as there is no need for an identifier.

Thanks @MIchaelMainer. v1.0 metadata is fixed now but beta metadata is still broken as described. Can you suggest to the Graph teams that they validate their metadata before publishing?


Fails to process Azure DevOps PR URLs that include spaces

When attempting to run against an Azure DevOps URL that includes an URL encoded space (%20), PR Agent fails with a 404 error.
This is an issue when the Azure DevOps project name contains a space.
For example when running the Azure DevOps Webhook tag:
INFO:     <IP_ADDRESS>:55368 - "POST / HTTP/1.1" 202 Accepted
2024-03-05 02:34:30.642 | INFO     | pr_agent.agent.pr_agent:handle_request:77 - PR-Agent request handler started
ERROR:    Exception in ASGI application
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/uvicorn/protocols/http/h11_impl.py", line 428, in run_asgi
    result = await app(  # type: ignore[func-returns-value]
  File "/usr/local/lib/python3.10/site-packages/uvicorn/middleware/proxy_headers.py", line 78, in __call__
    return await self.app(scope, receive, send)
  File "/usr/local/lib/python3.10/site-packages/fastapi/applications.py", line 290, in __call__
    await super().__call__(scope, receive, send)
  File "/usr/local/lib/python3.10/site-packages/starlette/applications.py", line 122, in __call__
    await self.middleware_stack(scope, receive, send)
  File "/usr/local/lib/python3.10/site-packages/starlette/middleware/errors.py", line 184, in __call__
    raise exc
  File "/usr/local/lib/python3.10/site-packages/starlette/middleware/errors.py", line 162, in __call__
    await self.app(scope, receive, _send)
  File "/usr/local/lib/python3.10/site-packages/starlette_context/middleware/raw_middleware.py", line 92, in __call__
    await self.app(scope, receive, send_wrapper)
  File "/usr/local/lib/python3.10/site-packages/starlette/middleware/exceptions.py", line 79, in __call__
    raise exc
  File "/usr/local/lib/python3.10/site-packages/starlette/middleware/exceptions.py", line 68, in __call__
    await self.app(scope, receive, sender)
  File "/usr/local/lib/python3.10/site-packages/fastapi/middleware/asyncexitstack.py", line 20, in __call__
    raise e
  File "/usr/local/lib/python3.10/site-packages/fastapi/middleware/asyncexitstack.py", line 17, in __call__
    await self.app(scope, receive, send)
  File "/usr/local/lib/python3.10/site-packages/starlette/routing.py", line 718, in __call__
    await route.handle(scope, receive, send)
  File "/usr/local/lib/python3.10/site-packages/starlette/routing.py", line 276, in handle
    await self.app(scope, receive, send)
  File "/usr/local/lib/python3.10/site-packages/starlette/routing.py", line 69, in app
    await response(scope, receive, send)
  File "/usr/local/lib/python3.10/site-packages/starlette/responses.py", line 174, in __call__
    await self.background()
  File "/usr/local/lib/python3.10/site-packages/starlette/background.py", line 43, in __call__
    await task()
  File "/usr/local/lib/python3.10/site-packages/starlette/background.py", line 26, in __call__
    await self.func(*self.args, **self.kwargs)
  File "/app/pr_agent/agent/pr_agent.py", line 90, in handle_request
    await command2class[action](pr_url, ai_handler=self.ai_handler, args=args).run()
  File "/app/pr_agent/tools/pr_description.py", line 31, in __init__
    self.git_provider = get_git_provider()(pr_url)
  File "/app/pr_agent/git_providers/azuredevops_provider.py", line 54, in __init__
    self.set_pr(pr_url)
  File "/app/pr_agent/git_providers/azuredevops_provider.py", line 189, in set_pr
    self.pr = self._get_pr()
  File "/app/pr_agent/git_providers/azuredevops_provider.py", line 550, in _get_pr
    self.pr = self.azure_devops_client.get_pull_request_by_id(
  File "/usr/local/lib/python3.10/site-packages/azure/devops/v7_0/git/git_client_base.py", line 2066, in get_pull_request_by_id
    response = self._send(http_method='GET',
  File "/usr/local/lib/python3.10/site-packages/azure/devops/client.py", line 104, in _send
    response = self._send_request(request=request, headers=headers, content=content, media_type=media_type)
  File "/usr/local/lib/python3.10/site-packages/azure/devops/client.py", line 68, in _send_request
    self._handle_error(request, response)
  File "/usr/local/lib/python3.10/site-packages/azure/devops/client.py", line 294, in _handle_error
    raise AzureDevOpsClientRequestError(full_message_format.format(error_message=error_message,
azure.devops.exceptions.AzureDevOpsClientRequestError: Operation returned a 404 status code.

This also happens in the docker CLI version of PR Agent, with the same error:
Traceback (most recent call last):
  File "/app/pr_agent/cli.py", line 68, in <module>
    run()
  File "/app/pr_agent/cli.py", line 62, in run
    result = asyncio.run(PRAgent().handle_request(args.pr_url, [command] + args.rest))
  File "/usr/local/lib/python3.10/asyncio/runners.py", line 44, in run
    return loop.run_until_complete(main)
  File "/usr/local/lib/python3.10/asyncio/base_events.py", line 649, in run_until_complete
    return future.result()
  File "/app/pr_agent/agent/pr_agent.py", line 87, in handle_request
    await command2class[action](pr_url, ai_handler=self.ai_handler, args=args).run()
  File "/app/pr_agent/tools/pr_description.py", line 31, in __init__
    self.git_provider = get_git_provider()(pr_url)
  File "/app/pr_agent/git_providers/azuredevops_provider.py", line 51, in __init__
    self.set_pr(pr_url)
  File "/app/pr_agent/git_providers/azuredevops_provider.py", line 186, in set_pr
    self.pr = self._get_pr()
  File "/app/pr_agent/git_providers/azuredevops_provider.py", line 530, in _get_pr
    self.pr = self.azure_devops_client.get_pull_request_by_id(
  File "/usr/local/lib/python3.10/site-packages/azure/devops/v7_0/git/git_client_base.py", line 2066, in get_pull_request_by_id
    response = self._send(http_method='GET',
  File "/usr/local/lib/python3.10/site-packages/azure/devops/client.py", line 104, in _send
    response = self._send_request(request=request, headers=headers, content=content, media_type=media_type)
  File "/usr/local/lib/python3.10/site-packages/azure/devops/client.py", line 68, in _send_request
    self._handle_error(request, response)
  File "/usr/local/lib/python3.10/site-packages/azure/devops/client.py", line 294, in _handle_error
    raise AzureDevOpsClientRequestError(full_message_format.format(error_message=error_message,
azure.devops.exceptions.AzureDevOpsClientRequestError: Operation returned a 404 status code.

If I force the URL to be decoded before processing then it works as expected.
For example in the file pr_agent/servers/azuredevops_server_webhook.py:
from urllib.parse import unquote
...

pr_url = unquote(data["resource"]["_links"]["web"]["href"].replace("_apis/git/repositories", "_git"))

feel free to open a PR to address this


Use of np.float causes ghcnd.get_data to fail when numpy version greater than 1.20

Hi!
The np.float function is deprecated in versions greater than 1.20, so running the ghcnd.get_data function with the requirements as specified will fail. Can be fixed by changing to use np.float64. I will make PR with fix.
Cheers

Fixed by #6


Default overlay array merge behavior is append

this might be semantics, but is there a difference between default operation being append vs merge behaviour for array items being append (if no match annotation is specified)? im asking this to better understand should we be augmenting merge behaviour for arrays or should we be doing what this PR is doing and switching default operation.

here is another way to put it, are we actually talking about default for overlay/match for array items vs different default operation...

There is no difference. I can see how keeping the default operation for all types merge simplifies the implementation by isolating the special case of 'append' merge behavior to array items only. I'll update.

Heres some more feedback from talking with @pivotaljohn:

[ ] Order test variables so that expected is separate from inputs
[ ] Modify TestDocumentOverlayArrayItems to remove unnecessary keys to simplify test
[ ] Move data values overlay tests from data values test to the overlay test file
[ ]  (To think about) Would it make sense to assert on --data-values-inspect output for data values overlays test instead of template output

@pivotaljohn @cppforlife, updated PR with changes, feel free to take a look.

code looks fine at this point. circling back to wording in examples.

actually one thing i missed was tests: i see that we have added a lot of tests at a different level. there are tests here https://github.com/vmware-tanzu/carvel-ytt/tree/develop/pkg/yamltemplate/filetests/ytt-library that exercise various ytt modules including overlays. in this case go tests should only be added for cross cutting functionality. changing overlay/match by default behaviour for array items is not cross cutting however (very isolated to overlay module). i'd like to probably see removal of some of the new tests added (would be good to chat about that since diff is really hard to read)

@cppforlife appreciate the feedback. I think I need some clarification on what action to take next. What I hear from

go tests should only be added for cross cutting functionality

unit tests (or go tests) should only be added for functionality that relies on or affects other parts of the codebase. Is this what you mean?
So then would you say that since this feature is very isolated to the overlay module, and not relying on other parts of the codebase we do not need unit tests that test more than the basic overlay array item functionality here? Or is it that we do not need unit tests that test more than the basic overlay functionality?
Concretely:  in this PR we added 4 unit tests in cmd_overlays_test this is a short description of each:

'document' overlay with and without overlay/append annotation
data value array item overlay
empty array data value edge case
empty array overlay edge case

If we move the tests above to the following locations does this address your concerns?

Keep the basic overlay array item functionality tests in cmd_overlays_test:

'document' overlay with and without overlay/append annotation
data value array item overlay

Move the edge case tests into the https://github.com/vmware-tanzu/carvel-ytt/tree/develop/pkg/yamltemplate/filetests/ytt-library package?

empty array data value edge case
empty array overlay edge case

If not, can you elaborate on what testing structure you would like to see?

Here's a summary of the conversation @cppforlife and I had regarding this:
The level at which we need to test at depends on if the feature is "cross cutting functionality". For features that interact with others, for example testing data values and overlays together is "cross cutting" since they are two separate features and happen in 'go tests'.
For this PR, we introduced a change in behavior for overlays which is not cross cutting. So it is appropriate to test at a lower level like 'yamltemplate'.
In addition to moving the tests to 'yamltemplate', we should decouple testing data values and overlays together, and instead just test overlay functionality.
Lastly, a refactor that was done as part of this PR to move data values overlay tests from cmd_data_values_test to cmd_overlays_test should be reverted since data values is a separate feature from overlays, and when we use data values with overlays, that is a 'cross cutting' feature of data values and belongs to cmd_data_values_test.

@cppforlife Ready for review


.rename() and .xor() schema methods are ignored

OS: Linux pop-os 5.19.0-76051900-generic
Node: v16.17.0
Joi: 17.6.0
Joi-to-typescript: 4.0.5
Hi there,
I have the following schema which is intended to require only one of the keys described in .xor(), throwing an error if neither one or both are present in the object. Additionally, if the key provided was the one suffixed with "_FILE", it should be renamed to remove that suffix.
const ConfigSchema = Joi.object({
  JWT_SECRET: Joi.string(),
  JWT_SECRET_FILE: Joi.string(),
  MONGODB_NAME: Joi.string(),
  MONGODB_NAME_FILE: Joi.string()
})
  .xor('JWT_SECRET_FILE', 'JWT_SECRET')
  .xor('MONGODB_NAME_FILE', 'MONGODB_NAME')
  .rename('JWT_SECRET_FILE', 'JWT_SECRET')
  .rename('MONGODB_NAME_FILE', 'MONGODB_NAME')

This works fine at runtime, and I can write a TypeScript interface to work with the validated schema exactly as I intend to through the rest of my code:
export interface IConfig {
  JWT_SECRET: string;
  MONGODB_NAME: string;
}

However, when I use joi-to-typescript the resulting interface contains the properties that I need to remove as well:
export interface IConfig {
  JWT_SECRET: string;
  JWT_SECRET_FILE: string;
  MONGODB_NAME: string;
  MONGODB_NAME_FILE: string;
}

Is a missing feature of joi-to-typescript? Or perhaps I'm not using Joi's .xor() and .rename() methods properly (although they seem to work fine)? For reference, I have setup an npm script to run joi-to-typescript as follows (as I do not have ts-node installed globally):
"scripts": {
  "types": "node_modules/.bin/ts-node src/schemas/types.ts"
}

// src/schemas/types.ts

import { convertFromDirectory } from 'joi-to-typescript';

convertFromDirectory({
  schemaDirectory: './src/schemas',
  typeOutputDirectory: './src/interfaces',
  defaultToRequired: true,
  ignoreFiles: ['types.ts'],
  debug: true
});

For reference to other readers, there's another approach to solve my issue using a different syntax:
export const ConfigSchema = Joi.object({
  JWT_SECRET: Joi.string().required().when('JWT_SECRET_FILE', {
    is: Joi.exist(),
    then: Joi.forbidden()
  }),
  MONGODB_NAME: Joi.string().required().when('MONGODB_NAME_FILE', {
    is: Joi.exist(),
    then: Joi.forbidden()
  })
})

The only problem with this is that if I provide both mutually exclusive keys by mistake, the error message is a bit misleading: "JWT_SECRET is not allowed". It could probably be fixed with additional code that I would rather avoid to type (which is the point of using joi-to-typescript)

I haven't tried xor or rename before, I'm glad you were able to solve the issue another way.
If you want to look how joi-to-typescript works you can run .describe() on your schema and see what comes out that is what I base the code generation on

Hi, and thank you for the tip I will have to take some time to look into it and see if I can somehow improve it. But for now I'll stick with the workaround that I found as it's virtually just as effective. I'll be closing this issue for now, cheers!


Ses30

Added support for SES 3.0 in cloud7.

+1

+1, but needs to be merged with https://github.com/crowbar/crowbar-ceph/pull/46 and https://github.com/crowbar/crowbar-core/pull/483

The rebuild with https://github.com/crowbar/crowbar-ceph/pull/46 and https://github.com/crowbar/crowbar-core/pull/483 succeeded.


Feature: Add notes in expense

Related Issue: #110
See issue for problem statement.
Implementation :
Added notes field while creating/editing expense
Added notes as an optional field in schema

This is how create/expense page is looking after adding notes field
Please let me know @scastiel if there are any changes required

@scastiel  Please can you review this PR

Thanks @deepgolani4!
There was a missing notes initialization in the expense form, I updated your PR with it :)


issue #189: updated dockerfile

Closes #189

@ChromaticPanic Hi, would you have 2 minutes to look at the tests? I had to make some modifications because the npm run build was not working, but now the npm run test shows that some tests are not giving the correct result.

@ChromaticPanic Hi, would you have 2 minutes to look at the tests? I had to make some modifications because the npm run build was not working, but now the npm run test shows that some tests are not giving the correct result.

Looks like its G2G

GG


[DNM] Building the zip for a single product

I've identified the unlinked Firestore using a script and am tried to programmatically force link them via approach 1. That approach did not work so I'm trying to force link them via a .m rather than a .mm file.
I'm trying to iterate as fast as possible so I've removed all pods from the FirebaseManifest except Firestore, this yielded the following zip build error (I saw this locally as well.)
@paulb777 , any advice on speeding up zip build for iterating on a single product's zip distro?

The zip-builder is designed to build any CocoaPod, in addition to building Firebase releases. See the zip-builder instructions at https://github.com/firebase/firebase-ios-sdk/tree/master/ReleaseTooling to use it just to build Firestore. See the analytics instructions for a specific example.
Also you can use the platforms and archs flags to build for just a single slice, since you only need the simulator to test.

@paulb777: Sorry, where is the archs flags? I've been using  --platforms ios
‣ swift run --package-path ReleaseTooling zip-builder --help
USAGE: zip-builder-tool <options>

OPTIONS:
  --enable-apple-silicon-support/--disable-apple-silicon-support
                          Enables or disables building arm64 slices for Apple silicon Macs. (default: true)
  --enable-build-dependencies/--disable-build-dependencies
                          Whether or not to build dependencies of requested pods. (default: true)
  --enable-carthage-version-check/--disable-carthage-version-check
                          A flag for enabling or disabling versions checks for Carthage builds. (default: true)
  --dynamic/--no-dynamic  A flag specifying to build dynamic library frameworks. (default: false)
  --keep-build-artifacts/--no-keep-build-artifacts
                          A flag to indicate keeping (not deleting) the build artifacts. (default: false)
  --include-catalyst/--no-include-catalyst
                          A flag to indicate skip building the Catalyst slice. (default: true)
  --update-pod-repo/--no-update-pod-repo
                          A flag to run `pod repo update` and `pod cache clean -all` before building the "zip file". (default: true)
  --custom-spec-repos <custom-spec-repos>
                          A list of private CocoaPod Spec repos. If not provided, the tool will only use the CocoaPods master repo.
  --minimum-ios-version <minimum-ios-version>
                          The minimum supported iOS version. (default: 11.0)
  --minimum-mac-os-version <minimum-mac-os-version>
                          The minimum supported macOS version. (default: 10.13)
  --minimum-tvos-version <minimum-tvos-version>
                          The minimum supported tvOS version. (default: 12.0)
  --platforms <platforms> The list of platforms to build for. The default list is ["ios", "macos", "tvos"].
  --pods <pods>           List of pods to build.
  --zip-pods <zip-pods>   The path to a JSON file of the pods (with optional version) to package into a zip.
  --local-podspec-path <local-podspec-path>
                          Path to override podspec search with local podspec.
  --build-root <build-root>
                          The root directory for build artifacts. If `nil`, a temporary directory will be used.
  --output-dir <output-dir>
                          The directory to copy the built Zip file to. If this is not set, the path to the Zip file will be logged to the console.
  -h, --help              Show help information.

Nevermind, found it mentioned in ZipBuilderV2Plan.md. I don't think it is an available option yet.


Update dependencyanalyzer3 for Scala 3.5

Description
Avoids a future Scala 3.5 compatibility issue under Bzlmod. Part of #1482.
Motivation
PR #1604 added Scala 3.5 suppport. I updated my Bzlmod working branch to include those changes, and updated scala_3_5.bzl with dependencies I'd added or updated from scala_3_4.bzl. ./test_examples.sh then failed with the following error, which I recreated in the local examples/scala3 repo:
$ bazel build --repo_env=SCALA_VERSION=3.5.0 //...

ERROR: .../external/rules_scala~/third_party/dependency_analyzer/src/main/BUILD:4:39:
  scala @@rules_scala~//third_party/dependency_analyzer/src/main:dependency_analyzer
  failed: (Exit 1): scalac_bootstrap failed:
  error executing Scalac command
  (from target @@rules_scala~//third_party/dependency_analyzer/src/main:dependency_analyzer)
  bazel-out/.../bin/external/rules_scala~/src/java/io/bazel/rulesscala/scalac/scalac_bootstrap
    ... (remaining 1 argument skipped)

-- [E164] Declaration Error:
    external/rules_scala~/third_party/dependency_analyzer/src/main/io/bazel/rulesscala/dependencyanalyzer3/DependencyAnalyzer.scala:21:6
21 |  def init(options: List[String]): List[PluginPhase] =
   |      ^
   |error overriding method init in trait StandardPlugin of type (options: List[String]): List[dotty.tools.dotc.plugins.PluginPhase];
   |  method init of type (options: List[String]): List[dotty.tools.dotc.plugins.PluginPhase] needs `override` modifier

This may be because I bumped io_bazel_rules_scala_scala_library_2 from org.scala-lang:scala-library:2.13.12 to 2.13.14 in my Bzlmod branch. That's my guess based on information about the dotty packages from the following files:

third_party/utils/src/test/io/bazel/rulesscala/utils/Scala3CompilerUtils.scala
third_party/dependency_analyzer/src/test/analyzer_test_scala_3.bzl

It's interesting that Scala 3.{1,2,3,4} all passed with that scala-library version bump, but without this change, but I can't explain why.

It started to fail in Scala 3.5 because in this minor release we've added a def initialize(settings: List[String])(using Context) to replace def init(settings: List[String]). By having an additional context parameter we use reporter to correctly report warnings/errors, eg. when parsing passed settings. It was introduced in https://github.com/scala/scala3/pull/20330
Because of this change def init needs to use override modifier explicitly. It's a good practice to have it also when overriding abstract methods.
Probably an additional @nowarn("deprecation") annotation should be added to the init method, because now it would report that we should use initialize instead.

@WojciechMazur Thanks for the explanation! Not having one was bugging me. Now this loop feels closed.


Sublime-text-like subword navigation

In Sublime Text, subword navigation is a little different:

It positions the caret at the end of the subword if you're going to the right;
It positions the caret at the start of the subword if you're going to the left;
It treats numbers as part of the subwords.

I personally like it better this way, so I implemented it here.

Well it still doesn't really match Sublime's behavior. Sublime treats non-whitespace separators differently than this. Compare the two just navigating around in boundaries.ts.
Now, is the current behavior a bit too finicky? Perhaps. I don't even remember the thinking around numbers. I suppose I just thought I'd rather stop an extra time than not if a number was to be changed. But I like the feel overall and the jumps are never confusing unlike Sublime's version, especially with how they treat jumping into words differently if they begin with a capital letter or not.
Maybe if I take a look at configurable behavior some time but for now I'd rather leave it as it is.

Oh, right, I see the difference. I agree with everything you said, really I was just making this pull request to show the way I personally like it, in case anyone else liked it that way too. In fact, I will be changing that strange behavior with words that start with a capital letter.
Thanks for the feedback! You can close this pull request if you want.


Continue to next packet if received broken packet

Broken packet should be ignored and continue to next packet.
This goroutine should not exit until close.

Hi, sorry for a delay, will check it today.


Metadata based configuration unexpectedly using fingerprint signature validation

I've been working on adding Okta login to a Rails app through SAML, using this gem. While reviewing this work, someone flagged this section of the README:

In production also we highly recommend to register on the settings the IdP certificate instead of using the fingerprint method. The fingerprint, is a hash, so at the end is open to a collision attack that can end on a signature validation bypass. Other SAML toolkits deprecated that mechanism, we maintain it for compatibility and also to be used on test environment.

We are using OneLogin::RubySaml::IdpMetadataParser for configuration. Inspecting this configuration shows that settings.get_idp_cert_multi is nil, but settings.get_idp_cert is configured as expected.
To our surprise, this configuration results in OneLogin::RubySaml::Response#validate_signature only using the fingerprint for validation - not the actual certificate. This is because of two factors - settings.get_idp_cert_multi is nil here:
https://github.com/onelogin/ruby-saml/blob/63f43a7f9b830dfd690457a78a78fac48359944f/lib/onelogin/ruby-saml/response.rb#L844-L852
And that the document Okta is sending us includes a X509Certificate element that matches this query:
https://github.com/onelogin/ruby-saml/blob/63f43a7f9b830dfd690457a78a78fac48359944f/lib/xml_security.rb#L201-L209
In order to follow the recommendation against using the fingerprint method in production, we are setting idp_cert_multi manually to force OneLogin::RubySaml::Response#validate_signature into the branch that calls validate_document_with_cert. That code looks like this:
response.settings.idp_cert_multi = {
  signing: [response.settings.get_idp_cert.to_pem]
}
if response.is_valid?
...

This behavior was unexpected so I wanted to flag it. I'm new to SAML so didn't want to assume a best path for fixing this, but I may be able to make a PR with a solution. Would either of these options make sense?

Have validate_signature check against settings.get_idp_cert if available before using the fingerprint
Have the metadata parser load a single available certificate into idp_cert_multi.

Let me know what sounds best.

Sorry for the delayed reply.
In the call
https://github.com/onelogin/ruby-saml/blob/12790136f03424fef7099a4379a03e88d5535af4/lib/onelogin/ruby-saml/response.rb#L856
If you have registered a cert in settings.certificate, then that cert will be registered on the command
https://github.com/onelogin/ruby-saml/blob/12790136f03424fef7099a4379a03e88d5535af4/lib/onelogin/ruby-saml/response.rb#L854
and past to the validate_document method.
In that method, if the SAMLResponse contains an x509certData, then its calculated fingerprint is compared with the calculated fingerprint registered in the settings
https://github.com/onelogin/ruby-saml/blob/449dd6b6a415e37c5cf8962e647f11a83021d6e2/lib/xml_security.rb#L225-L226
but check that the certificate used in
https://github.com/onelogin/ruby-saml/blob/449dd6b6a415e37c5cf8962e647f11a83021d6e2/lib/xml_security.rb#L241
is in fact the one registered on the settings
https://github.com/onelogin/ruby-saml/blob/449dd6b6a415e37c5cf8962e647f11a83021d6e2/lib/xml_security.rb#L232

Sorry for never getting back to this - I'd need to spend a while tracing code paths before any of it makes sense again. If it's helpful, one of my coworkers did come up with a failing test for this situation that may be clearer:
diff --git a/test/xml_security_test.rb b/test/xml_security_test.rb
index 3d3e758..6c77bd0 100644
--- a/test/xml_security_test.rb
+++ b/test/xml_security_test.rb
@@ -392,6 +392,36 @@ class XmlSecurityTest < Minitest::Test
           assert document.name_id.nil?, 'Document should expose only signed, valid details'
         end
       end
+
+      describe 'a hash collision attack' do
+        # some random cert that isn't the one in the document
+        let(:idp_cert) { ruby_saml_cert2 }
+        let(:idp_cert_fingerprint) { "fingerprint" }
+        let(:document_data) { read_response('response_with_signed_message_and_assertion.xml') }
+        let(:malicious_document) { XMLSecurity::SignedDocument.new(document_data) }
+        let(:malicious_cert) {
+          OpenSSL::X509::Certificate.new(
+            Base64.decode64(
+              malicious_document.elements["//ds:X509Certificate"].text
+            )
+          )
+        }
+
+        it 'shouldnt validate' do
+          # confirm that the cert in the doc is *not* the IDP cert
+          refute_equal idp_cert.to_pem, malicious_cert.to_pem
+
+          # simulate hash collision
+          OpenSSL::Digest::SHA1.any_instance.stubs(:hexdigest).with(malicious_cert.to_der).returns(idp_cert_fingerprint)
+
+          exception = assert_raises(OneLogin::RubySaml::ValidationError) do
+            malicious_document.validate_document(idp_cert_fingerprint, false, :cert => idp_cert)
+          end
+
+          assert_equal("Key validation error", exception.message)
+          assert_includes document.errors, "Key validation error"
+        end
+      end

Sorry for never getting back to this - I'd need to spend a while tracing code paths before any of it makes sense again. If it's helpful, one of my coworkers did come up with a failing test for this situation that may be clearer:
diff --git a/test/xml_security_test.rb b/test/xml_security_test.rb
index 3d3e758..6c77bd0 100644
--- a/test/xml_security_test.rb
+++ b/test/xml_security_test.rb
@@ -392,6 +392,36 @@ class XmlSecurityTest < Minitest::Test
           assert document.name_id.nil?, 'Document should expose only signed, valid details'
         end
       end
+
+      describe 'a hash collision attack' do
+        # some random cert that isn't the one in the document
+        let(:idp_cert) { ruby_saml_cert2 }
+        let(:idp_cert_fingerprint) { "fingerprint" }
+        let(:document_data) { read_response('response_with_signed_message_and_assertion.xml') }
+        let(:malicious_document) { XMLSecurity::SignedDocument.new(document_data) }
+        let(:malicious_cert) {
+          OpenSSL::X509::Certificate.new(
+            Base64.decode64(
+              malicious_document.elements["//ds:X509Certificate"].text
+            )
+          )
+        }
+
+        it 'shouldnt validate' do
+          # confirm that the cert in the doc is *not* the IDP cert
+          refute_equal idp_cert.to_pem, malicious_cert.to_pem
+
+          # simulate hash collision
+          OpenSSL::Digest::SHA1.any_instance.stubs(:hexdigest).with(malicious_cert.to_der).returns(idp_cert_fingerprint)
+
+          exception = assert_raises(OneLogin::RubySaml::ValidationError) do
+            malicious_document.validate_document(idp_cert_fingerprint, false, :cert => idp_cert)
+          end
+
+          assert_equal("Key validation error", exception.message)
+          assert_includes document.errors, "Key validation error"
+        end
+      end


add RR-08

I hope it's fixed now. I have reverted the last commit and brought the required changes.


Dynamic Select don't work !

After selecting the files list from the database , it fails to remember the value of 'df-mytemplate

View example of vue:
https://github.com/jerosoler/drawflow-vue3-example/blob/master/src/components/nodes/node1.vue

It's working fine now. I tried applying it to v-select as well. I can retrieve its value, but I can't pass it through the output to the node. Thank you.

I tried to this


omg make it stop (changed lockbot config file)

I changed the lock bot config file to add a label instead of a comment so we don't get hundreds and hundreds of notifications 😭

Coverage remained the same at 100.0% when pulling 50c3e941b8d1ae575b19e746e9c2fd249c39d13a on lock-bot-shutup into ab359857412ec816780c4af738f0c43d917c5111 on master.

The problem is that it's still working its way through our backlog. It's locking hundreds of old+closed threads every hour. The benefits of this bot might show up once it's done with that so let's maybe give it another shot? In the meantime, I've set up a quick Gmail filter to auto-delete anything coming from lock-bot. Wanna maybe try that too?

Agreed


NaNs in diss_spikeship

I'm working on implementing SpikeShip on my data but I often have the issue that after running diss_spikeship = spikeship.distances(ripple_spike_times, ii_spike_times) there are NaNs in diss_spikeship. I've tried setting various minimum criteria (minimum number of neurons/events/spikes etc) which sometimes works, but not always. Under which conditions does the algorithm output a NaN exactly? Then I can make sure to exclude those.
Cheers!

Hey, Guido! The output is NaN when it's not possible to compare two epochs or trials. Ensure you have neurons that spike in the two epochs you're comparing. Perhaps increasing the window length of your analysis or adjusting the number of neurons might help. Let me know!

Thanks I'll try to do this. If it does fail for some trail pairs, is it ok to set only those pairs to 0 in the distance matrix before running TSNE? Excluding both entire trials if one trial pair fails would result in a lot of data loss

In this context, when a distance matrix contains a value of 0, it signifies that those epochs are considered identical. Since you cannot exclude those epochs, an alternative approach could involve inserting the maximum feasible value (e.g., the window length) in those instances instead.

That makes total sense, I wasn't thinking. Thanks for all your help!


Adds stackblitz sample app

I can give you ownership of the app. Just send me your email on stackblitz.

Hello, I freaking glad you decided to contribute to this library, but this example doesn't show how the decorator really works. Have you seen example I added to the topic on medium? Try to open devTools, where you can see that streams are removed after the component has destroing.

My mail<EMAIL_ADDRESS>and I have telegram, if you want to discuss something, you can write me) - nillcon248

Sounds great, but I am not sure that someone will check this PR) Maybe I must more popularize this approach for detect some issues and get support from the community)

The angular team will check the PR. I can assure you. You only need to label it properly (I think with proposal label).
It is a real good idea to have that capability out of the box as beginners tend not to use async pipe nor OnPush.
And feel free to ignore my PR and maybe add your demo url to the README.md so people that get here have a way to try it with their own cases.
Nice to meet you. Thanks for the lib. I'll use it for sure.


Introduce ToolArgs

This will introduce ToolArgs alias of Array used as arguments
when executing commands.
ONE-vscode-DCO-1.0-Signed-off-by: SaeHie Park<EMAIL_ADDRESS>

From draft #14


Go proxy override

Description of changes:
When developing with the products service locally and your network policy blocks access to the default Go module proxy, it's difficult to get the products service up and running in local Docker instance without having to manually hack the Dockerfile. These changes allow the Go proxy to be easily overridden using a build argument that is set in your .env file by setting GOPROXY_OVERRIDE build argument to direct.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

looks good but why only for the products service ?

looks good but why only for the products service ?

That is the only golang service that is currently using modules. When the others are switched to modules, they will need the same treatment.


Comments: How Artsy Hires Engineers

Interviewing is hard. Interviewers want to make sure they're hiring the person who will add the most value to their
team; candidates want to make sure they're joining a company that aligns with their goals and perspectives.

Recent trends in hiring are white-boarding sessions, trivia questions, and hours of take-home assignments. At
Artsy, we don't use any of these. We often get asked why not - and how we assess technical skill without them.

This is very true

The underlying presumption with "traditional" tech hiring practices is that candidates are somehow trying to trick their way into positions they aren’t qualified for.

This is beautiful. I appreciate companies who recognize relationships are why they succeed. The relationships are really the only reason to stay.
As a 15-year developer who's working to return from a 5-year-sabbatical, it's disheartening seeing how impersonal this process has become in the industry.

Very confusing interviews, they ask vague questions and expect specific questions. Interviewers just want to hear what they. I wasted 3 hours of my time.

@artsy it's ok ^ , you can delete my feedback here. I will eventually provide a more meaningful feedback on glassdoor. I just think it's ironic that you promote being open and now you are trying to silence my opinion
👏👏👏👏

@brangi If you'd like to send us feedback about your experience with our hiring process, you can send it to the hiring manager you worked with, or me at<EMAIL_ADDRESS>and I will make sure our hiring team gets it. The comments section on a blog post is not an appropriate place for this kind of personal feedback. Please take care.

@ashfurrow , I decide which is the right place to share my option, otherwise do not have the comment feature on this blog and thanks but no thanks I already said what I am going to do.


The turtle pkg's nautilus integration does not work on NixOS inside a nix-shell

Describe the bug
turtle's main feature is to add additional functionality to the gnome file explorer, nautilus, via extra icons and context menus when using nautilus to navigate inside a git repository; but when running nautilus from within a nix-shell on NixOS with turtle installed, that functionality does not seam to be working.
Steps To Reproduce
Steps to reproduce the behaviour:

Run nix-shell -p turtle -p gnome.nautilus
Run nautilus -q to kill any already running instances of nautilus.
Run nautilus
Navigate into a directory containing .git
Observe that no additional icons, information, or context actions have been added to nautilus, as shown in the below screenshot from the turtle gnome GitLab.

Expected behaviour
When the turtle package is installed from either nix-shell or environment.systemPackages it's integration with nautilus functions.
Screenshot from the gnome GitLab showing nautilus with extra icons representing a file's git status:

Screenshots
A screenshot of nautilus shows a .git folder, but none of the icons added by turtle are present.

Additional context
Looking at pkgs/by-name/tu/turtle/package.nix it does not appear that the gnome.nautilus-python package is listed as a dependency, but since turtle's nautilus integration is written in python that package would be required for the integration to work. This may be the reason why the integration isn't working, but I'm not sure, as when I tried using a nix-shell -p turtle -p gnome.nautilus -p gnome.nautilus-python it also didn't work. It could also be that something else about my system could be stopping it from working, and if anyone wants extra details, I'll be happy to share.
It might also be that turtle's install.py is trying to add the nautilus extension as if it was running on a mutable OS, and is trying to modify system files. Looking at the install.py there seams to be a few CLI options about installing to the user's home directory, which implies that by default it tries to install system-wide, which may be the problem. If this is the case, would what the install.py code copies into the system need to be named in the package.nix file or would a hole systemwide NixOS option in configuration.nix need to be set?
I'm new to using NixOS and if I'm doing anything wrong, please explain or point me to the relevant documentation, so I can learn.
The turtle package was added in pull request #313605
Notify maintainers

@aleksanaa
@aleksana
In the package.nix the maintainer was listed as aleksana (without a second a) but that didn't look like the right GitHub user, so I'm pinging both. This may also be a problem to fix.
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.6.33, NixOS, 24.05 (Uakari), 24.05.1409.cc54fb41d137`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - channels(root): `"nixos-24.05"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Add a :+1: reaction to issues you find important.

Have you tried adding turtle, gnome.nautilus-python and gnome.nautilus to the same output path (e.g. environment.systemPackages, users.users.<someone>.packages, home.packages, or using symlinkJoin)?

My preferred ID is aleksana, but you see, someone already took it. If you want to solve the problem please negotiate with them 😅

Sorry for the really late reply, I tried adding all of turtle, gnome.nautilus-python, and gnome.nautilus to my environment.systemPackages but still nautilus doesn't load turtle.
But now, running nautilus shows what looks to be the relevant error message:
Traceback (most recent call last):
  File "/run/current-system/sw/share/nautilus-python/extensions/turtle_nautilus.py", line 22, in <module>
    from turtlevcs.turtle_plugin import TurtlePlugin
  File "/nix/store/8jdkqwjw0kz1cc0x9bdxaf5a6rkapd62-turtle-0.8/lib/python3.11/site-packages/turtlevcs/turtle_plugin.py", line 24, in <module>
    from turtlevcs.turtle_service import TurtleServiceConnector
  File "/nix/store/8jdkqwjw0kz1cc0x9bdxaf5a6rkapd62-turtle-0.8/lib/python3.11/site-packages/turtlevcs/turtle_service.py", line 22, in <module>
    import dbus
ModuleNotFoundError: No module named 'dbus'

There's also:
Traceback (most recent call last):
  File "/run/current-system/sw/share/nautilus-python/extensions/turtle_nautilus_compare.py", line 60, in get_file_items
    if self.settings.get_boolean("show-compare"):
       ^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'get_boolean'

So, nautilus is finding and loading turtle, but the environment doesn't look like it includes the python dbus package, which turtle needs.

Got it. I'm updating turtle.

Upstream also made a small mistake: they didn't add dbus-python to the declared dependencies. This is fixed in 0.9.


feat(table): 3287-TableSearchRowCount

#689
Closes #
Summary
Right align the search icon and toggle open when clicked to display a search component.
Show table row count and should be appear on the left. i.e "Results: X", where X is equal to the number of rows in the table.
This field (Row count) should be configuration via boolean property and Result Label should allow to change.
Change List (commits, features, bugs, etc)
src/components/Dashboard/snapshots/Dashboard.story.storyshot
src/components/DataTable/_data-table.scss
src/components/Table/Table.jsx
src/components/Table/Table.story.jsx
src/components/Table/Table.test.jsx
src/components/Table/TablePropTypes.js
src/components/Table/TableToolbar/TableToolbar.jsx
src/components/Table/snapshots/Table.story.storyshot
src/components/TableCard/snapshots/TableCard.story.storyshot
Acceptance Test (how to verify the PR)
Two fields are provided in Storybook Knob to test.

Show row count checkbox use to display and hide Row count field
Row count label input field will be using to change the row count label value.

@stuckless @davidicus Please review PR 743.
It was delayed due to yarn test issue on windows


NET.Core 2.2 change log level for Kafka logs

Description
Is there any way to disable logs which are coming from Kafka?
The log sample (consumer):
%5|1570698786.790|LIBSASL|rdkafka#consumer-1| [thrd:GroupCoordinator]: GroupCoordinator/1001: GSSAPI client step 1

%5|1570698786.791|LIBSASL|rdkafka#consumer-1| [thrd:GroupCoordinator]: GroupCoordinator/1001: GSSAPI client step 2

%5|1570699386.919|LIBSASL|rdkafka#consumer-1| [thrd:GroupCoordinator]: GroupCoordinator/1001: GSSAPI client step 1

%5|1570699386.931|LIBSASL|rdkafka#consumer-1| [thrd:GroupCoordinator]: GroupCoordinator/1001: GSSAPI client step 1

%5|1570699386.933|LIBSASL|rdkafka#consumer-1| [thrd:GroupCoordinator]: GroupCoordinator/1001: GSSAPI client step 2

NuGet packages installed:
<PackageReference Include="Confluent.Kafka" Version="1.1.0" />
<PackageReference Include="Confluent.SchemaRegistry" Version="1.1.0" />
<PackageReference Include="Confluent.SchemaRegistry.Serdes" Version="1.1.0" />

"security.protocol" config is set to sasl_plaintext. I use Kerberos auth
Application framework: NET.Core 2.2.401.
It is possible to control all the logs from Microsoft libs by setting this:
"Logging": {
    "LogLevel": {
      "Microsoft": "#loglevel#",
    }
  }

Can I change the log level for logs that are coming from Kafka packages with more or less the same way?

if you set a log handler (in which you can do whatever you like) in the builder class, this will prevent the default behavior which is to log to stderr.
to control which log messages your applications receives, you use the debug config property. librdkafka does have a log_level config setting, but in practice this isn't useful and we don't even expose it on the config classes.


Included Oracle 11g XE build files and minor bug fixes

This PR has merge issues and looks the same as the previous PR #118 (at first glance). If you've updated since then, you need to pull from master first to merge 118 and then apply further changes on top.

Missed to pull from the master branch first


Added Inception Module to the Model.

The module basically acts as multiple convolution filter inputs, that are processed on the same input. It also does pooling at the same time. All the results are then concatenated. This allows the model to take advantage of multi-level feature extraction from each input. For instance, it extracts general (5x5) and local (1x1) features at the same time.

We are running code on FloydHub
floyd run "python train.py --dataset /input --savedir /output --train" --data WLVWALmiVEmDJRyd5c6YgY --gpu

I have corrected the issue. :)

2017-05-09 23:54:37,889 INFO - Traceback (most recent call last):
2017-05-09 23:54:37,890 INFO - File "train.py", line 77, in <module>
2017-05-09 23:54:37,891 INFO - x, y, y_true, optimizer = cnn.create_network(height, width, num_classes)
2017-05-09 23:54:37,891 INFO - File "/code/models/cnn.py", line 90, in create_network
2017-05-09 23:54:37,892 INFO - num_filter=16)
2017-05-09 23:54:37,892 INFO - File "/code/models/cnn.py", line 51, in inception2d
2017-05-09 23:54:37,893 INFO - input = tf.concat([one_by_one, three_by_three, five_by_five, pooling], axis=3)  # Concat in the 4th dim to stack
2017-05-09 23:54:37,894 INFO - TypeError: concat() got an unexpected keyword argument 'axis'

This worked
diff --git a/floyd_requirements.txt b/floyd_requirements.txt
new file mode 100644
index 0000000..79ced33
--- /dev/null
+++ b/floyd_requirements.txt
@@ -0,0 +1 @@
+tensorflow==1.0.1

:)


Respect period parameter in otpauth URI.

According to the Key Uri Format documentation the current google authenticator implementation
doesn't use the period parameter in the otpauth URI and defaults to 30 seconds.
This makes it difficult to use the google authenticator app as an alternative soft token generator mechanism in scenarios where one wants to use one OTP token policy in combination with hardware token generators which often come with a hard-wired default period.
A fallback is to use other apps like FreeOTP which respect the period parameter.

This issue was moved to google/google-authenticator-libpam#3

This also needs support in the app, so re-opening.

Any updates

Nope

Note that this is only a problem on Android. The iOS version supports period=60 at least. I just wrote a blog post where I tested that and a bunch of other stuff: https://labanskoller.se/blog/2019/07/11/many-common-mobile-authenticator-apps-accept-qr-codes-for-modes-they-dont-support/

This is the big problem seems no one care.