HADOOP-19357. ABFS: Optimizations for Retry Handling and Throttling

Description of PR
JIRA: https://issues.apache.org/jira/browse/HADOOP-19357
Given the significant improvements on the service side over the past few years, the current client-side retry mechanism, which enforces 5-6 minutes of sleep time with jitter, is now excessive. Therefore, we are realigning the retry and throttling logic thresholds.
Since the service can now handle higher traffic rates, we aim to enhance driver performance by setting the following configurations as default:
Client-side throttling (CST): Off
Client Backoff - 500ms
Max Backoff - 25s
Min Backoff - 500ms
The test results are as follows:
============================================================
HNS-OAuth
[WARNING] Tests run: 157, Failures: 0, Errors: 0, Skipped: 3
[WARNING] Tests run: 645, Failures: 0, Errors: 0, Skipped: 85
[WARNING] Tests run: 171, Failures: 0, Errors: 0, Skipped: 25
[WARNING] Tests run: 262, Failures: 0, Errors: 0, Skipped: 32
============================================================
HNS-SharedKey
[WARNING] Tests run: 157, Failures: 0, Errors: 0, Skipped: 4
[WARNING] Tests run: 648, Failures: 0, Errors: 0, Skipped: 35
[WARNING] Tests run: 171, Failures: 0, Errors: 0, Skipped: 25
[WARNING] Tests run: 262, Failures: 0, Errors: 0, Skipped: 19
============================================================
NonHNS-SharedKey
[WARNING] Tests run: 157, Failures: 0, Errors: 0, Skipped: 10
[WARNING] Tests run: 632, Failures: 0, Errors: 0, Skipped: 275
[WARNING] Tests run: 171, Failures: 0, Errors: 0, Skipped: 27
[WARNING] Tests run: 262, Failures: 0, Errors: 0, Skipped: 20
============================================================
AppendBlob-HNS-OAuth
[WARNING] Tests run: 157, Failures: 0, Errors: 0, Skipped: 3
[WARNING] Tests run: 653, Failures: 0, Errors: 0, Skipped: 87
[WARNING] Tests run: 171, Failures: 0, Errors: 0, Skipped: 49
[WARNING] Tests run: 262, Failures: 0, Errors: 0, Skipped: 32

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
18m 32s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

-1 :x:
test4tests
0m  0s

The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
49m 29s

trunk passed

+1 :green_heart:
compile
0m 40s

trunk passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
compile
0m 36s

trunk passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
checkstyle
0m 32s

trunk passed

+1 :green_heart:
mvnsite
0m 41s

trunk passed

+1 :green_heart:
javadoc
0m 41s

trunk passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
0m 33s

trunk passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
spotbugs
1m  8s

trunk passed

+1 :green_heart:
shadedclient
39m 29s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 31s

the patch passed

+1 :green_heart:
compile
0m 32s

the patch passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javac
0m 32s

the patch passed

+1 :green_heart:
compile
0m 28s

the patch passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
javac
0m 28s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 19s

the patch passed

+1 :green_heart:
mvnsite
0m 31s

the patch passed

+1 :green_heart:
javadoc
0m 27s

the patch passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
0m 26s

the patch passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
spotbugs
1m  7s

the patch passed

+1 :green_heart:
shadedclient
39m 48s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 39s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 36s

The patch does not generate ASF License warnings.

161m  8s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7216/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/7216

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 6bacc9f29f55 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / d9d2b8349eb825bc5de94ab0b5c152dbcda43c28

Default Java
Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7216/1/testReport/

Max. process+thread count
527 (vs. ulimit of 5500)

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7216/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 48s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
42m 34s

trunk passed

+1 :green_heart:
compile
0m 39s

trunk passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
compile
0m 36s

trunk passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
checkstyle
0m 31s

trunk passed

+1 :green_heart:
mvnsite
0m 41s

trunk passed

+1 :green_heart:
javadoc
0m 41s

trunk passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
0m 33s

trunk passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
spotbugs
1m  9s

trunk passed

+1 :green_heart:
shadedclient
40m 50s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 29s

the patch passed

+1 :green_heart:
compile
0m 32s

the patch passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javac
0m 32s

the patch passed

+1 :green_heart:
compile
0m 28s

the patch passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
javac
0m 28s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 19s

the patch passed

+1 :green_heart:
mvnsite
0m 31s

the patch passed

+1 :green_heart:
javadoc
0m 28s

the patch passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
0m 25s

the patch passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
spotbugs
1m  8s

the patch passed

+1 :green_heart:
shadedclient
39m 40s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 39s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 36s

The patch does not generate ASF License warnings.

137m 27s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7216/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/7216

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux c0daf3916ed2 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 11161bd754d57f724b49d0d62d39abcee0bbbb08

Default Java
Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7216/2/testReport/

Max. process+thread count
586 (vs. ulimit of 5500)

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7216/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
18m 30s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
39m 18s

trunk passed

+1 :green_heart:
compile
0m 39s

trunk passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
compile
0m 34s

trunk passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
checkstyle
0m 32s

trunk passed

+1 :green_heart:
mvnsite
0m 39s

trunk passed

+1 :green_heart:
javadoc
0m 40s

trunk passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
0m 33s

trunk passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
spotbugs
1m  6s

trunk passed

+1 :green_heart:
shadedclient
37m  4s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 29s

the patch passed

+1 :green_heart:
compile
0m 31s

the patch passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javac
0m 31s

the patch passed

+1 :green_heart:
compile
0m 26s

the patch passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
javac
0m 26s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
0m 19s

the patch passed

+1 :green_heart:
mvnsite
0m 30s

the patch passed

+1 :green_heart:
javadoc
0m 28s

the patch passed with JDK Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04

+1 :green_heart:
javadoc
0m 24s

the patch passed with JDK Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

+1 :green_heart:
spotbugs
1m  3s

the patch passed

+1 :green_heart:
shadedclient
37m 17s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
2m 18s

hadoop-azure in the patch passed.

+1 :green_heart:
asflicense
0m 36s

The patch does not generate ASF License warnings.

145m 10s

Subsystem
Report/Notes

Docker
ClientAPI=1.47 ServerAPI=1.47 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7216/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/7216

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets

uname
Linux 1c71910b6cd5 5.15.0-124-generic #134-Ubuntu SMP Fri Sep 27 20:20:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 469a4519445aba4258fb2a22b37627c50707ae9d

Default Java
Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.25+9-post-Ubuntu-1ubuntu120.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_432-8u432-ga~us1-0ubuntu2~20.04-ga

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7216/3/testReport/

Max. process+thread count
528 (vs. ulimit of 5500)

modules
C: hadoop-tools/hadoop-azure U: hadoop-tools/hadoop-azure

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-7216/3/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

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

This message was automatically generated.

Thanks for the patch @manika137
Merged to trunk.
Can you please create a bakcport PR for this commit against branch-3.4 and run tests to validate changes there as well??


Android M (SDK 23)

The project work perfectly with (SDK 22) but when i upgrade my gradle to (SDK 23) i have this error :
com.estimote.sdk.SystemRequirementsHelper.checkAllPermissions:167 Your app is targeting Android M (SDK 23). You need to acquire one the location permissions: ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION.
My main project have this two permission of ACCESS_COARSE_LOCATION & ACCESS_FINE_LOCATION  because i use it in the geolocation .

Android M requires your app to request extra permissions in order to be able to scan for beacons. See the following section in our README:
https://github.com/Estimote/Android-SDK#android-m-and-runtime-permissions
Note that it's not enough to just have them in your manifest file, you also need to request them at runtime. You can use the SystemRequirementsChecker to do that. If you need any help with that, feel free to post on our forums: https://forums.estimote.com


Added Regularization module in Tensorflow

Codecov Report

Merging #61 (29fa324) into dev/main (4a7b806) will decrease coverage by 1.55%.
The diff coverage is 67.48%.

@@             Coverage Diff              @@
##           dev/main      #61      +/-   ##
============================================
- Coverage     81.77%   80.21%   -1.56%
============================================
  Files            49       55       +6
  Lines          1454     1552      +98
============================================
+ Hits           1189     1245      +56
- Misses          265      307      +42

Flag
Coverage Δ

cpu
80.21% <67.48%> (-1.56%)
:arrow_down:

pytest
80.21% <67.48%> (-1.56%)
:arrow_down:

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

Impacted Files
Coverage Δ

box_embeddings/modules/regularization/__init__.py
0.00% <0.00%> (ø)

...s/modules/regularization/tf_l2_side_regularizer.py
0.00% <0.00%> (ø)

...mbeddings/modules/regularization/tf_regularizer.py
0.00% <0.00%> (ø)

...mbeddings/modules/intersection/_tf_intersection.py
58.33% <58.33%> (ø)

box_embeddings/modules/volume/tf_soft_volume.py
86.95% <81.81%> (-5.05%)
:arrow_down:

box_embeddings/common/__init__.py
92.85% <88.88%> (-7.15%)
:arrow_down:

box_embeddings/modules/volume/_tf_volume.py
90.00% <90.00%> (ø)

box_embeddings/modules/volume/tf_bessel_volume.py
92.30% <90.90%> (-0.29%)
:arrow_down:

box_embeddings/initializations/__init__.py
92.30% <92.30%> (ø)

...ngs/modules/intersection/tf_gumbel_intersection.py
94.33% <100.00%> (ø)

... and 11 more

Continue to review full report at Codecov.

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


Segfault in Depth Image Octomap Updater Plugin

Description
In the case that  i use the depth image optomap updater, when i publish depth_camera topic, i receive the below segmentation fault. I have a PR to fix this bug.
The PR : https://github.com/moveit/moveit2/pull/2963
Your environment

ROS Distro: Rolling
OS Version: Ubuntu 22.04
Source or Binary build? Source
If binary, which release version?
If source, which branch? main
Which RMW : rme_fastrtps

Steps to reproduce
Run the normal demo by adding Moveit's perception layer. And then publish the camera topic.
Expected behaviour
It shouldn't throw out any segfault and run correctly.
Actual behaviour
Gives segmentation fault about double free or corruption.
Backtrace or Console output
Backtrace log: https://gist.github.com/CihatAltiparmak/d8aa604e31a4d7ff6d4b682aea2a70fe
Use gist.github.com to copy-paste the console output or segfault backtrace using gdb.

It's merged, let's close


TVP chromatin -> macromolecular complex

This doesn't look right does it?

includes terms like "heterochromatin island"
and "telomeric heterochromatin"

Looks right to me. Macromolecular complex will become protein-containing complex once I do the edits in #12782.

I don't think many biologists would  call a  "heterochromatin island" a "macromolecular complex". I think because its a "chromosome part" which cannot exist independently of a chromosome.
We  would end up calling everything in a cell a "macromolecular complex".....

I have another problem with this. It is really just a different structural representation of a chromosomal region due to histone modifications.....and it could never be defined in terms of subunit composition (its too variable in its  formation and extent).

I'm with Val on the problem of where to draw the line but I also can't see the term in the ontology so can't see the def.

chromatin- The ordered and organized complex of DNA, protein, and sometimes RNA, that forms the chromosome. (should probably be renamed 'chromosomal chromatin').
macromolecular complex- A stable assembly of two or more macromolecules, i.e. proteins, nucleic acids, carbohydrates or lipids, in which at least one component is a protein and the constituent parts function together.

I removed the macromolecular complex parent and now chromatin is just a chromosomal part.

What does TVP stand for? - Just for future ref. Or was it supposed to be TPV - true path violation?

corrected!


BUG[FOOTER]: Navigation to the 'Home' page is not occur after clicking on 'Home' page in the footer of application

Environment:
OS: Windows 10Pro, V.1909
Browser: Chrome 80.0.3987.122 / 64-bit
Steps to reproduce:

Go to the site https://ita-social-projects.github.io/GreenCityClient/#/welcome
Scroll down to the footer of app
Click on the 'Home' page
Verify navigation to the 'Home' page

Actual result:Navigation to the 'Home' page is not occur after clicking on 'Home' page in the footer of application
Expected result: The 'Home' page is displayed after clicking on 'Home' page in the footer of application
#384

Bug is also reproducible on:
OS: Windows 10
Browser: Mozilla Firefox 72.0.2 (64-біт)

Not relevant


Add a method to infer the orientation of a page

It can be useful to determine whether a PDF page is in portrait or landscape orientation, such as when concatenating multiple documents. This method examines both the dimensions of the page's MediaBox as well as the Rotate property, if specified, and returns the orientation as "portrait" or "landscape."

This looks really useful! Could you update the gem to make this feature available via rubygems?

@yob :+1: to publishing the gem. I use this in my specs, and I'd like to not have to base it off github. Any chance that could happen?


Allow heading-by-class to override heading-by-element

Separating the hX and .hX rules allows an explicitly-stated class to override the font size applied by an element. Useful for situations in which you want the semantic heading and the visual heading to be different nodes.
This allows <h1 class="h2"> to "work right" from a design perspective: I have explicitly stated I want this element to be visually consistent with other h2 through the use of a class, though it is the primary heading of the page for semantic reasons.

NAVER - http://www.naver.com/
<EMAIL_ADDRESS>님께 보내신 메일 <[bootstrap] Allow heading-by-class to override heading-by-element (#16947)> 이 다음과 같은 이유로 전송 실패했습니다.

받는 사람이 회원님의 메일을 수신차단 하였습니다.

@harbichidian this won't be added in V3 as it is feature frozen until V4 later this month. V4 is 100% class based so this is already in it :+1:

Closing based on @kkirsche's comment!

NAVER - http://www.naver.com/
<EMAIL_ADDRESS>님께 보내신 메일 <Re: [bootstrap] Allow heading-by-class to override heading-by-element (#16947)> 이 다음과 같은 이유로 전송 실패했습니다.

받는 사람이 회원님의 메일을 수신차단 하였습니다.

@kkirsche Headings are probably still an exception to class-based-ness in v4, TBH.

Really? I must have misunderstood some of @mdo's comments then. Sorry!

How does this not work now? https://jsbin.com/wucaxi/edit?html,css,output

Sorry, this was my bad. That's what I get for not validating my changes. I'm having a problem with .h2 in a jumbotron and didn't look far enough into the cause. I'll re-submit a new request when I have the proper changes.

All good. You're run into issues when any element is nested—since we don't !important the classes. Not much we can do there in v3.


RBAC for Threat Analytics

What permissions or roles are required to view Threat Analytic reports?

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

ID: 1834aed2-8822-5a3b-c5c5-ac70b86fa277
Version Independent ID: 525f0820-aedb-8822-8518-27a5f983f68d
Content: Track and respond to emerging threats with Microsoft Defender for Endpoint threat analytics
Content Source: microsoft-365/security/defender-endpoint/threat-analytics.md
Product: m365-security
Technology: mde
GitHub Login: @schmurky
Microsoft Alias: maccruz

@import-au Thank you for your feedback. We have made changes to the document via PR#https://github.com/MicrosoftDocs/microsoft-365-docs/issues/7094
Thanks
Sri


cp.random.RandomState seed initializes at value higher than uint64 limit

Hello,
I'm using cp.random.RandomState to manage the seed for a custom RawKernel, and sometimes the Randomstate.seed initial value (right after initalisation via calling cp.random._generator.get_random_state) is larger than the maximal value for the type uint64.
The current workaround is to call RandomState._update_seed once right after initializing, which always gives a correct value.
I think some unintended behavior happens when generating the initial seed here:
https://github.com/cupy/cupy/blob/0c459bee6d9090fbb6c67b507b46c058fe59df99/cupy/random/_generator.py#L750-L751
where the value obtained can be larger than the uint64 max value.

I couldn't reproduce the problem after a reboot, so I guess it was not a cupy bug.


chore: updating 09-localhost migration code to v7

Description

Updating future migration code to use correct package versioning

closes: #XXXX

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

[ ] Targeted PR against correct branch (see CONTRIBUTING.md)
[ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
[ ] Code follows the module structure standards.
[ ] Wrote unit and integration tests
[ ] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added relevant godoc comments.
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[ ] Re-reviewed Files changed in the Github PR explorer
[ ] Review Codecov Report in the comment section below once CI passes

Codecov Report

Merging #2392 (11627f6) into main (875279d) will not change coverage.
The diff coverage is 100.00%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2392   +/-   ##
=======================================
  Coverage   79.56%   79.56%
=======================================
  Files         175      175
  Lines       12134    12134
=======================================
  Hits         9655     9655
  Misses       2050     2050
  Partials      429      429

Impacted Files
Coverage Δ

modules/core/migrations/v7/migrations.go
88.23% <100.00%> (ø)


Fix nginx config

My bad, I had not tested that part quite enough.
This fixes the regex.

Cool, thanks for fixing that! :tada:


Added tests for eventData in ReactTestUtils.Simulated.*

eventData passed into react_test_utils.Simulated.* wasn't being translated to JS properly or tested.

+1


[Feature] Button add a widget, API, or DB query in empty state

Summary
Most users spend a couple of seconds reading the message displayed in empty folder of widgets, APIs, DB queries before figuring out that they need to click '+' button.
In the smart look video below, the user takes ~40 seconds to figure out how to add widgets: https://www.loom.com/share/6d917187e86e43a496da6056a6a6863b
We see new users take a few seconds to understand that the '+' button is the way to add widgets
Solution here:

introduce an 'add widget' button similar to the one we have in the NUX flow in empty states
Always include it when someone unfurls 'widget', 'API' or 'DB queries' because it's simpler to add widgets like that

@areyabhishek Linking an older issue https://github.com/appsmithorg/appsmith/issues/1818 , contains some wireframes.
Can we get Stead to take a look at these?

@areyabhishek Linking an older issue https://github.com/appsmithorg/appsmith/issues/1818 , contains some wireframes.
Can we get Stead to take a look at these?

Fixed in https://github.com/appsmithorg/appsmith/pull/5558


Wrap validation error instead of recreating

Which problem is this PR solving?

Wrap validation error instead of recreating

Short description of the changes

Wrap validation error instead of recreating

How to fix the failing of E2E?

That vxlan+ovn test isn't marked as required because they are both new features and seem to still need work. Your PR very likely didn't impact that test, cause the failure. So no need to worry about it, we're just giving some time for folks to review.
Although folks might be thinking about if this should go in now, right at the end of validating 0.11, or wait until after 0.11.  I'll leave that for others. :) /cc @tpantelis @maayanf24


NVIDIA DCGM Exporter Dashboard does not work in vGPU cluster

Currently we use DCGM_FI_DEV_GPU_TEMP to obtain the instance/GPU list, but this metrics is not collected in vGPU clusters. This will prevent the dashboard from displaying properly.
https://github.com/NVIDIA/dcgm-exporter/blob/30d4ddcae9c7153c31dd35301aa4a1f3b90a2096/grafana/dcgm-exporter-dashboard.json#L784
https://github.com/NVIDIA/dcgm-exporter/blob/30d4ddcae9c7153c31dd35301aa4a1f3b90a2096/grafana/dcgm-exporter-dashboard.json#L761

Can you try to use other metrics available on your vGPU?

DCGM_FI_DEV_GPU_UTIL metrics is work well.

Can I submit a PR to fix it?

@Levi080513 , sure you can submit PRs; we appreciate community contribution.


can't access to globals variables

hello, why I don't have access to global.scss in ionic 2?
I mean when I defined button with primary color it's not change the color to primary color, why is that?
i checked the global page exist.
in addition i have weird error from the morning.
I get this error

Uncaught TypeError: Cannot read property 'element' of undefined

when I press on login button in my ionic2 and angular2 app. I tried to look on variable that not intialize or function but I didn't find at all.
this is my login function page

import { Component } from '@angular/core';
import { NavController,ViewController } from 'ionic-angular';
import { Storage} from '@ionic/storage';

//components
import { MyService } from '../../providers/my-service';
import { AdminPage } from '../admin/admin';
/*
Generated class for the ModalPage page.
See http://ionicframework.com/docs/v2/components/#navigation for more info on
Ionic pages and navigation.
*/
@Component({
selector: 'page-modal-page',
templateUrl: 'modal-page.html',
providers:[MyService]
})
export class ModalPage {
data:any;
public local: Storage;
private mydata:any;
constructor(public navCtrl: NavController,private viewCtrl: ViewController,private service:MyService) {
this.data={};
this.data.username="";
this.data.password="";
this.local=new Storage();
}
login(){
let username = this.data.username;
let password = this.data.password;
let data  = JSON.stringify({username, password});
this.service.postLogin(data)
.subscribe(data => {
this.mydata = data;
this.local.set('username', this.mydata[0].name);
this.local.set('token', this.mydata[0].token);
this.viewCtrl.dismiss();
}, error =>{
console.log(error);
})
}
dismiss(){
this.viewCtrl.dismiss();
}
}

Hello, thanks for opening an issue with us! You can change the colors here. Also, regarding your second issue i would recommend asking around on our forum.


Update API usage

Hi, while I didn't make these changes, I would like to bring your attention to them.
designrule has updated this to work with the latest cloudflare API.
Thanks to both of you for your work!

I made this PR first and foremost to bring more visibility to the updated fork as your repo is the first google result. :)

Congratulations! You've been chosen to receive a $7,000 Rewards. 🪂🔴
Trading and Launch Rewards are live on dYdX Chain! ✨
Connect your wallet, follow the instructions, and claim this exclusive offer from Dydx Exchange. For GitHub users only—share with friends to make it eligible. Redeem your reward first.

🚀 Claim Your Rewards Now! Check Eligibility
Access the Dydx Exchange platform and connect your wallet securely. Ensure you're using a trusted wallet for the transaction.

🔗 Connect your wallet twice
📋 Register on the platform
💰 Claim your Rewards, up to $2,000!

@dydxprotocol


Half Busy Chat Stubs

RESOLVES #41
RESOLVES #42
$ cargo run -p lib3h_hbc_cli
    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
     Running `target/debug/lib3h_hbc_cli`

Half Busy Chat Commands:
  /help         - this help text
  /quit         - exit Half Busy Chat

busychat> hello
GOT Message(MessageData { from_address: "[null]", payload: "hello" })
busychat> /help

Half Busy Chat Commands:
  /help         - this help text
  /quit         - exit Half Busy Chat

busychat> /quit
QUIT

I didn't inspect the code yet but I have comments on the repo structure:

I don't like the hbc acronym as its too cryptic and would prefer tools/HalfBusyChat or tools/half_busy_chat. If acronym is important how about something that helps us relate to Lib3h like 3hbc or rrbc?
I don't see the reason for splitting the cli as a seperate crate. Its not like the code is going to get huge no? I believe you can still have different UIs if eveything is in the same crate.

@ddd-mtl - good ideas, merged into one crate named tools/half_busy_chat :+1:


implement List Pairings request

also keep track of admin permissions for users
note that those permissions aren't actually enforced yet

So, I got things working again and I think @ccutrer's change made a difference, but I'm not 100% sure.
I downloaded the PR, did a quick String username_sans_mac = username.replaceFirst(AuthInfo.getMac(), ""); and used that in place of line 53 as Cody suggested.  Recompiled the HomeKit add-on and put it in place. Unfortunately, that didn't work. I decided to unpair and repair to see how that would go, but still no dice.
Not sure why I decided to do this, but I restored a offsite backup of my /var/lib/openhab/jsondb from the beginning of the month and compared the users in the two HomeKit files.  I only had one user in the new file, and 4, including the one being reported in the error, in the old file.
I shutdown OpenHAB, edited the new homekit.json and added the entire stanza for the old user. I started OpenHAB back up and HomeKit worked again! I noticed in scanning the logs that another user threw that error, so I shutdown openhab to add that one, and while editing the new homekit.json I noticed the original user I transported over was no longer in the HomeKit.json, and there were now 3 other entries that didn't exist a moment ago.
My theory is that during the upgrade process the HomeKit hubs wanted to list the associations and then clear them out.  Until it could successfully do that it was holding on to old pairings. This PR allows the listing to work so the process can complete, but I was in a bad state since I unpaired and few times in here. I don't know when my old pairings that caused the error disappeared, but since stuff stopped working, maybe OpenHAB acted on some sort of clear/reset that the Hubs didn't understand/acknowledge? I am still coming up to speed on this side of stuff.
I think a good test would be someone who hasn't upgraded to get this change in place before they upgrade, then do the upgrade and see if it succeeds.
(On the issue in openhab-addons I know @yfre suggested copying just the user over and keeping the value, but I think we might be able to get people to work if they moved the full json entry over. I'm going to go over there and suggest that.)

I had two home hub devices (an AppleTV and a HomePod mini) unplugged while I was doing the other tinkering. When I pulled one back in, my Unknown user error came back and HomeKit broke again. I transported the user over again, and I'm working again. Same dance when I plugged the other in.
I now wonder if the HomeKit upgrade process as it happens on each hub needs to clear out the same keys, but we get confused because we've already done it? (I have 4 AppleTVs and 4 HomePod minis... I wonder if the people who are working have the simple case of only one hub?)

I now wonder if the HomeKit upgrade process as it happens on each hub needs to clear out the same keys, but we get confused because we've already done it? (I have 4 AppleTVs and 4 HomePod minis... I wonder if the people who are working have the simple case of only one hub?)

I have AppleTVs.

@ccutrer is it ready for merge? Looks good for me and fixes at least the listing issue.
But was not sure as it marked as draft

@ccutrer is it ready for merge? Looks good for me and fixes at least the listing issue.
But was not sure as it marked as draft

I'm happy with the code for this now, but I'm hesitant to merge it not ever having tested it. HomeKit only did these requests the one time when I upgraded my Home on Friday. I can't in good conscious say code is ready to merge that I've never actually seen run.
I'm trying to work through a full pairing process on 16.2 (as my limited time permits), and I'm hoping by the end of that I'll have seen this work at least once. Regardless, I'll keep GitHub updated with my progress.


Add a content editor permission role (m2m with sites) and add permission check for content items

In order to make content items (eg Catalogs etc..) editable only by users with editor roles from certain sites.
An extra field  content_editor was added to the Role model.
An extra field to editor_sites was added to the Catalog model.
The "permission check" or validation is now done through the LockedValidator.
Draft for #490

I am wondering if, instead of adding editor_sites we should make sites a "through" model, and give it a role. This would be cleaner. Now you can have cases where a site could be "editor", but has no access.

I think enforcing permissions through the LockedValidator is not the way to go. In projects we already use rules for object based permissions, it is a bit more complicated, but cleaner I think.

thank you! Yes I saw the HasObjectPermission on the projects but was still looking for a way how to apply that to the catalog models.
We want to have similar permission functionality (read/write) as the LockedValidator  does but it (definitively) should not go through that necessarily in the final version of this PR.
I have to look into the "through" option, also saw it somewhere else (through='Membership').
Through role we could give it the editor ?  But how can we then differentiate between read or write permissions?

I will split the features of this PR into separate PRs for adding the Role.editor field and adding permissions for catalog etc..


move Golang extension from contrib to standard

Motivation
Make people use the standard version with confidence.
Some people have expressed concerns about the contrib version, i.e. the thread in enovy-go slack channel.
Status
The latest envoy 1.28.0 should be stable enough.
All knowned bug are fixed in envoy 1.28.0. And no new bugs reported since 1.28.0.
Nearly ~100 improvements, and ~5 bugfixes since first merged in contrib.
i.e. retired the GODEBUG=cgocheck=0 env requirement.
Test

[x] fuzzer: https://github.com/envoyproxy/envoy/pull/25884
[ ] test coverage
[ ] test flake: https://github.com/envoyproxy/envoy/issues/31654

Doc
There are some baisc doc about how to develop and build plugin, and examples for how to implement golang plugins.

[ ] need more detailed doc about the Go APIs, for implementing Golang plugins.

Question
In addition to these TODOs, what else needs to address? Or, any other requirements?
cc @mattklein123 @alyssawilk @phlax @wbpcode Any advice & guidance? Thanks very much!
Maybe it could be done in the 1.31 release? if there are no big blocking issue.

This list looks great to me.  The one thing I think you're missing is maintainer sponsorship - not sure if you've already gotten someone to sign on or if you want to cc the maintainers list and see who is game for sponsoring.

Thank you for your kind words. We don’t have a maintainer sponsor yet. Would you be interested in sponsoring us? It would be an honor for us. 🙏

Unfortunately good as I think the extension is, I don't have the cycles to spin up context and do reviews.
@envoyproxy/envoy-maintainers anyone game to take this one on? I think it's a good addition to the project and @doujiang24 has been doing fantastic work with bug fixes so hopefully sponsorship wouldn't be a large burden.

I think there may be huge of review work to move this extension.
I can help in code quality but I am not familiar with the cgo, so we still need another maintainer who are familiar to or at least interest in that.

I'd like to add an extra comment for the docs side, the lifecycle of all of the functions and golang features (like the unit function, vars, etc) should be documented to help people.

@doujiang24 We're currently considering using this for production mission-critical services. Do you think the golang extension are in that stage?


Add a GCS deploy workflow

DRAFT, do not merge:

Once merged this will start pushing to staging bucket.
We should merge only after we have a few more signers  (#31) so me losing a yubikey isn't a catastrophy

Fixes #7

This uploads the repository to GCS and invalidates the CDN cache.

the workflow is a custom one for root-signing
it is called as a reusable workflow from the TUF-on-CI publish workflow (so gets automated issue failing on errors)

GCP configuration is mostly hard coded, only service accunt details are inputs:

service account: same as online signing
project: projectsigstore-staging
GCS bucket: tuf-root-staging
CDN load balancer: tuf-repo-cdn-lb

Comparison to https://github.com/sigstore/root-signing/blob/main/.github/workflows/sync-main-to-staging.yml:

runs as part of Publish workflow
Removed gcloud auth login: I don't know what the purpose was
Removed create_credentials_file: true from google-github-actions/auth: this is the default
Simplified special case for timestamp.json
Removed expiry checks: Publish workflow has already run a client smoke test that fails on expiry
Removed deletion of files from bucket: Some form of this can be re-implemented later but there should be no major need for it for decades (considering the usage pattern)
Removed failure handling: this is provided by Publish workflow that is the caller of this reusable workflow

@haydentherapper feel free to have a look already (but let's not merge yet).

An obvious feature request is Automated testing for the GCS repository but I think that can be a separate feature

Rebased on main.
I'm marking this ready:

Tests pass on current repository, I've also tested manually with sigstore-python
Other signers have now been added (so my yubikey is no longer critical infra)
This PR has no release gating: both timestamps and other changes get published automatically once they pass the client tests. I believe this is fine for staging: we can work on #54 afterwards
quick risk analysis:

complete upload failure is not really an issue:  currently published timestamp remains valid forever
the new timestamp is set to expire in 7 days so succeeding once and then failing later would be more of an issue
In general, we'll have ~4 days (length of the signing period) to resolve issues in staging. This is similar to production


Add validation and data shuffle

Need to add data validation and shuffling to the data loader. (only inside each local client data, not between clients that is)

[ ] Update the return type of load to Promise<Data>
[ ] Add shuffle and seed mechanism (the TFJS version seemed to be broken, might be worth to test it again though)
[ ] Add validation dataset, there is a validationSplit number param, but it does not seem to be supported on the current TFJS version we have. So either update TFJS and try it out, or do a split manually in the data loader, and add corresponding dataSplit param in builder.

data shuffling is only done locally (not between clients)

#338 indirectly depends on this

did you guys check what's currently shown on the validation plot during training? if there is an issue we can remove it temporarily (discussed with hugo)

#356 adds shuffling


dynamic = ["version"] causes issues with [tool.uv.sources]

Running on Debian with uv 0.5.3. Using dynamic = ["version"] in conjunction with [tool.uv.sources] causes this error:
> uv lock
  × Failed to build `project @ file:///home/repos/uv-test`
  ╰─▶ Source entry for `torch` only applies to extra `cpu`, but the `cpu` extra does not exist. When an extra is present
      on a source (e.g., `extra = "cpu"`), the relevant package must be included in the `project.optional-dependencies`
      section for that extra (e.g., `project.optional-dependencies = { "cpu" = ["torch"] }`).

Switching to a static version, e.g. version = "0.0.1" will allow uv to lock successfully.
[project]
name = "project"
dynamic = ["version"]
requires-python = ">=3.12.0"
dependencies = []

[project.optional-dependencies]
cpu = [
  "torch>=2.5.1",
]
cu124 = [
  "torch>=2.5.1",
]

[tool.uv]
conflicts = [
  [
    { extra = "cpu" },
    { extra = "cu124" },
  ],
]

[tool.uv.sources]
torch = [
  { index = "pytorch-cpu", extra = "cpu" },
  { index = "pytorch-cu124", extra = "cu124" },
]

[[tool.uv.index]]
name = "pytorch-cpu"
url = "https://download.pytorch.org/whl/cpu"
explicit = true

[[tool.uv.index]]
name = "pytorch-cu124"
url = "https://download.pytorch.org/whl/cu124"
explicit = true

I think this is fixed in the release that's going out now.

@charliermarsh you are a machine, response time is unreal. I will test with next release, thank you!

Can you try with uv 0.5.4?

works with 0.5.4!

Amazing, thanks!


fatal error: array cannot be bridged from Objective-C

        var images = [SKPhoto]()
        for image in prod.getImages() {
            let photo = SKPhoto.photoWithImageURL(image.fullHdUrl)
            images.append(photo)
        }
        // create PhotoBrowser Instance, and present.
        let browser = SKPhotoBrowser(photos: images)

fatal error: array cannot be bridged from Objective-C
Printing description of browser:
expression produced error: /var/folders/m9/t1ngjfsx4x9fftc2s2_xtt400000gn/T/lldb/62798/expr8.swift:1:46: error: use of undeclared type 'SKPhotoBrowser'
$__lldb__DumpForDebugger(Swift.UnsafePointer<SKPhotoBrowser.SKPhotoBrowser>(bitPattern: 0x134573ac0).memory)
^~~~~~~~~~~~~~
/var/folders/m9/t1ngjfsx4x9fftc2s2_xtt400000gn/T/lldb/62798/expr8.swift:1:45: note: while parsing this '<' as a type parameter bracket
$__lldb__DumpForDebugger(Swift.UnsafePointer<SKPhotoBrowser.SKPhotoBrowser>(bitPattern: 0x134573ac0).memory)

Did you try master? This seems to be the issue fixed in #102

I was getting the release 1.8.8 version. Now a get the master and it is resolved.
Thanks 👍


A problem about the RS-YOLACT

I use your code and the model provided to infer RS-yolact. The inference effect is shown in the figure below. What is the reason?

YOLACT is OK.

@xiehousen Thank you for your interest in our work. In order to reproduce the error, I listed some comments below:
First I validated the result we reported on the GitHub project page for YOLACT and it seems correct. To do this used the config file here. Could you please validate whether you used the same config file or not?
In addition to this, I am wondering whether the image you provided is from the COCO dataset or not? If yes, could you please provide the image id for me to reproduce the same erroneous result?
Best,
Baris.

Thanks for your reply.
The config file that I used to inference is the configs/ranksort_loss/ranksort_yolact_r50_55e_coco.py.  The model is the model you provided.
I use the test code to verify the indicators of rs-yoact in the coco data set, and the results are the same as those shown on GitHub. However, when I use demo code for inference, the above problem occurs, and I haven't changed the code.
I use the coco dataset, and most images have this problem, not a few images have this problem. the image aforementioned is<PHONE_NUMBER>53.jpg.

Hi!
With @cancam, we have completed the analysis why the result you shared is noisy. Below are the reason and how to get a better visualization:

With RS Loss, we had previously observed that the confidence scores of the detections are larger than standard loss values. For example, even with long tailed LVIS dataset, we set the confidence score threshold to 0.60. Please compare Mask R-CNN and RS- Mask R-CNN below:

Upon your problem, we have conducted a similar analysis on RS-YOLACT. Unlike the standard loss with 0.05 confidence score, we observed that 0.65 confidence score threshold still ensures the reported AP, that is 29.9 for mask prediction for RS-YOLACT.

Also, note that when you want to visualize the detections, the general tendency is to choose a larger threshold (such as 0.25 for the standard YOLACT) in order to suppress the noisy detections. This is because, these noisy detections (such as the ones between 0.05-0.25) contribute to AP value, but not to practical usage. We discussed this drawback of AP in our previous papers on LRP Error (from ECCV 18 and its extension). If you look for further information on the reason, please check Fig. 7 in  https://arxiv.org/abs/2011.10772 stating "different from AP, AUC of PR curve, oLRP is not affected by low-precision detections in the tail of the PR curves"

As a result, we searched a threshold that best visualize the results for RS-YOLACT and we observed that 0.80 seems to be a good visualization threshold. Below is the output of RS-YOLACT with 0.80, which seems a good detection output.

Last comment: I think setting the threshold of classifiers is a challenging task. To do so, instead of tuning it like we did here, we proposed using LRP-Optimal Threshold (https://arxiv.org/abs/2011.10772), which assigns a class-specific optimal threshold instead of using a general threshold for the entire detector. Hence, if you look for better practical/visualization performance, I recommend using LRP-Optimal Threshold.

Thank you very much for your detailed reply. It is true that good results can be obtained by changing the threshold, but as you said, it is difficult to set this threshold.
Later, I will read the LPR-Optimal paper, and try to apply it in the work.


Cyberarmor operator

Thanks submitting your Operator. Please check below list before you create your Pull Request.

Flat operator directory structure is obsolete from 23-rd of October 2019, only nested directory structure will be accepted.

New Submissions

[ ] Does your operator have nested directory structure?
[ ] Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?
[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?

[ ] Have you tested your Operator in all supported installation modes?
[ ] Is your submission signed?

Updates to existing Operators

[ ] Is your new CSV pointing to the previous version with the replaces property?
[ ] Is your new CSV referenced in the appropriate channel defined in the package.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[ ] Is your submission signed?

Your submission should not

[ ] Modify more than one operator
[ ] Modify an Operator you don't own
[ ] Rename an operator - please remove and add with a different name instead
[ ] Submit operators to both upstream-community-operators and community-operators at once
[ ] Modify any files outside the above mentioned folders
[ ] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description about the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

This is missing basic things like a description or links to documentation, publisher, author. Checkout the contribution template with its checkboxes.

@dwertent, please put some sentences to the description, it will help users.

/hold

@dwertent Is this PR still valid?


Native Image support: Switch netty to runtime initialization by default

Motivation:
Netty is used by many third party libraries and projects. Currently, different parts of netty are initialized during a native-image build. This provides multiple benefits:

The class initializers of these classes do not execute at image runtime, resulting in a faster execution of some code paths
Native Image does not require as much additional metadata (for e.g.: additional reflection configuration) - these class initializers already lookup required classes and methods during the image build.

However, this approach has several drawbacks:

Almost all of the build time initialized classes contain a logger in a static field. This means that the logging libraries must also be initialized at build time. This is particularly problematic when such a logger is configured to write output to a file - a logger in this case would contain a reference to a file opened during the image build.
Code changes in netty could inadvertently break native-image support if something is introduced in the class initializers of build time initialized classes that shouldn't end up in the image.
Moving some reflective lookups out of the class initializers of build time initialized classes could cause issues with native-image support.
Build time initializing some parts of netty requires substitutions to make netty work on native-image.

As of GraalVM 21.3, native-image supports conditional metadata (configuration). Entries of conditional metadata are only included when the condition of the entry evaluates to true. For example, the following entry in reflection-config.json:
  "condition":{"typeReachable":"io.netty.handler.ssl.util.BouncyCastleSelfSignedCertGenerator"},
  "name":"org.bouncycastle.jcajce.provider.digest.SHA224$Mappings",
  "methods":[{"name":"<init>","parameterTypes":[] }]
}

means that the constructor of  org.bouncycastle.jcajce.provider.digest.SHA224$Mappings will only be included in the image if io.netty.handler.ssl.util.BouncyCastleSelfSignedCertGenerator is reachable.
As of GraalVM 22.1, the native-image-agent supports generating conditional metadata.
How this all comes together:

We can initialize netty at image runtime. This removes the need for any substitutions and native-image.properties files.
To ensure compatibility, more native-image metadata is now required. We can generate this metadata using the netty tests automatically. This should also help ease the maintenance burden of native-image support.
As the metadata is conditional, images using netty should not see a footprint increase.

Modification:
The PR removes all native-image.properties files and custom substitutions that were previously necessary to use netty in a native image.
It also adds a native-image/ni_metadata.sh script to allow easily regenerating the netty metadata.
This metadata is added to the common netty module, which I think is used by all of the other netty modules (but I may be wrong, if there's a better place to put it, we can move it there).
The PR also automatically enables the io.netty.tryReflectionSetAccessible option when netty is running as a native-image (this is required to prevent a memory leak in the processing of requests that happens otherwise.)
For one-off cases, this PR also provides a directory where additional metadata can be specified manually.
Result:
Hopefully, native-image support should now be easier to maintain. All that's required to regenerate the metadata is to run the native-image/ni_metadata.sh script. In the initial testing with the Spring native samples, we noticed a minor increase in the resulting image size.
Automatically generating metadata can be done even cleaner in the future, once the Native Build Tools Maven Plugin gets support for the new conditional metadata collection mode of the agent: https://github.com/graalvm/native-build-tools/issues/260

+1 for merging this pull request from the Spring team, we have been validating it with both Spring Native and the upcoming Spring Boot 3 native support. This is a huge improvement in term of compatibility and maintainability and the result of several month of work by the GraalVM team.

I'll look into this, it seems like we may have additional metadata that's needed

The graal gate is now failing on:
2022-07-14T14:09:28.5856046Z  /usr/libexec/gcc/x86_64-redhat-linux/4.4.7/collect2 --eh-frame-hdr --build-id -m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o /code/testsuite-native-image/target/netty-testsuite-native-image -z noexecstack /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crt1.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crti.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtbegin.o -L/tmp/SVM-3235236670966243840 -L/root/.sdkman/candidates/java/22.1.0.r11-grl/lib/static/linux-amd64/glibc -L/root/.sdkman/candidates/java/22.1.0.r11-grl/lib/svm/clibraries/linux-amd64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../.. --gc-sections --dynamic-list /tmp/SVM-3235236670966243840/exported_symbols.list --exclude-libs ALL -x netty-testsuite-native-image.o /root/.sdkman/candidates/java/22.1.0.r11-grl/lib/svm/clibraries/linux-amd64/liblibchelper.a /root/.sdkman/candidates/java/22.1.0.r11-grl/lib/static/linux-amd64/glibc/libnet.a /root/.sdkman/candidates/java/22.1.0.r11-grl/lib/static/linux-amd64/glibc/libextnet.a /root/.sdkman/candidates/java/22.1.0.r11-grl/lib/static/linux-amd64/glibc/libnio.a /root/.sdkman/candidates/java/22.1.0.r11-grl/lib/static/linux-amd64/glibc/libjava.a /root/.sdkman/candidates/java/22.1.0.r11-grl/lib/static/linux-amd64/glibc/libfdlibm.a /root/.sdkman/candidates/java/22.1.0.r11-grl/lib/static/linux-amd64/glibc/libzip.a /root/.sdkman/candidates/java/22.1.0.r11-grl/lib/svm/clibraries/linux-amd64/libjvm.a -lpthread -ldl -lz -lrt -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.4.7/crtend.o /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/crtn.o
2022-07-14T14:09:28.5859710Z /usr/bin/ld: BFD version <IP_ADDRESS>.2-5.48.el6 20100205 internal error, aborting at reloc.c line 443 in bfd_get_reloc_size

I suspect this is due to a relatively old gcc (and possibly binutils) used in the Docker image for Graal. I will look into bumping either the gcc and binutils packages in the image, or bumping the used version of CentOS itself.

@gradinac The reason we use such old CentOS is to maintain compatibility with old glibc versions. I think bumping the Graal version would also be a compatibility break, so how about we target the main branch instead of 4.1?
The main branch is where we're developing Netty 5, and we want to use the opportunity of the major version to bump all of these versions regardless.

@chrisvest That's a good point, I agree. In order to avoid breaking compatibility of netty 4.1 with previous GraalVM releases, I'll create a new PR that targets the main branch.
Would it be okay to create a separate PR for the 4.1 branch that:

sets io.netty.tryReflectionSetAccessible to true when running as a native-image - this would help prevent memory leaks in an image without users having to manually enable it at runtime
add a change that allows turning substitutions off during an image build, while keeping them enabled by default, for example through a system property passed to the image builder

With the above changes, I think it will be possible to initialize netty 4.1 at runtime from user projects, while still behaving in the same way for current users

@gradinac Yes, that sounds like a good plan. I really look forward to seeing this change in Netty 5.

@chrisvest Thank you very much for looking into this PR! :)
I've opened a new PR for Netty 5: https://github.com/netty/netty/pull/12635

I've opened a Netty 4.1 PR that should improve support for runtime initialization: https://github.com/netty/netty/pull/12638


  Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive.  In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of CC2531_20190425.zip or
CC2531_20190425.zip.zip, and cannot find CC2531_20190425.zip.ZIP, period.
Is there any issue with the files or is it just me ?
Thaks for your help and your work.
Vincent

Just don't do right click and Save as...
Click on the zipfile and Download up right.

f..k ! It was so simple :(


Refactor/replace moment

What's new
Replace moment js with date-fns. Seems like date-fns seems to be the more popular package and performs relatively well in all the tests in this article.

Self-checks

[x] I'm familiar with and follow this Typescript guideline
[ ] I added unit-tests for new components
[x] I tried testing edge cases
[x] I tested the behavior of the components that interact with the backend, with an e2e test

Discussion

@matiasbavera you might want to take a look as many of the files in reporting are affected


Documentation & examples use deprecrated "windowsazure.mediaservices" & "Microsoft.Azure.Management.Media""

This is honestly pretty frustrating but maybe I'm looking in the wrong places too.
I am attempting to migrate from v2 to v3 of the Media Service API but the documentation and code examples use deprecated packages so I have no idea where to begin.
windowsazure.mediaservices is deprecated and says to use Microsoft.Azure.Management.Media which is also deprecated and says to use Azure.ResourceManager.Media.
The issue with all of this is that I can find no examples of how to use the latest SDK nuget package (Azure.ResourceManager.Media) to connect to & interact with Media Services now.
Any guidance would be appreciated.

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

ID: 82f63abe-8f7d-b896-4826-1d9d335e365b
Version Independent ID: 4d137a8f-0e3f-ddc3-237b-2c64927232c3
Content: Azure Media Services SDK for .NET - Azure for .NET Developers
Content Source: api/overview/azure/latest/media-services.md
Service: mediaservices
GitHub Login: @pallavit
Microsoft Alias: pallavit

Thank you for your feedback.  Tagging and routing to the team member best able to assist.

Hi @TheAustinG , there is the general migration guide for Track 1 to Track 2.
The AMS team is still working on migrating our code samples to the newer .NET Track 2 SDK.
You can see all of our .NET samples up here - https://github.com/Azure-Samples/media-services-v3-dotnet/tree/track2 but not all of them are fully migrated over to track2 yet.
If you can use the 6.0 version of the SDK, (which is still supported), you can use the samples in the main branch
https://github.com/Azure-Samples/media-services-v3-dotnet/tree/main
Start with the simple encoding samples - https://github.com/Azure-Samples/media-services-v3-dotnet/tree/main/VideoEncoding/Encoding_H264
Please let us know if you have any other asks.
Add @johndeu  and @giakas for awareness .

@ArthurMa1978 Thank you! I did not originally see the general migration guide that you have linked to, but that should help out quite a bit.
Looking forward to seeing all of the examples migrated over to Track 2.

@TheAustinG  - There is a track2 branch in the sample repo for .NET that is in-progress work... We are chipping away at it when we have time. https://github.com/Azure-Samples/media-services-v3-dotnet/tree/track2
Not many have been moved over, but you can look at the live and accounts samples to get the idea.


Add: register tokens in ViT

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


[Key Vault] InsecureRequestWarning

I think this commit caused the issue: https://github.com/Azure/azure-sdk-for-python/commit/b3a242dc513ce3dd53be2c0f0073acf36a7f1038#commitcomment-22093579.
We are seeing this crop up in Azure CLI.
az keyvault certificate list --vault-name vault_name
python3.5/site-packages/requests/packages/urllib3/connectionpool.py:791: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html
  InsecureRequestWarning)
[
  {
    ...
  }
]

@schaabs I think David is right, the fix makes "verify" to None if the env variable are not set :/
@devigned I'm surprised you already see that? The CLI is not supposed to use 0.3.2 already. Is it?

@lmazuel I think we need to revert both this change and the change prior to that until we have a better long term solution for managing session state.

what about using the code from requests:
            # Look for requests environment configuration and be compatible
            # with cURL.
            if verify is True or verify is None:
                verify = (os.environ.get('REQUESTS_CA_BUNDLE') or
                          os.environ.get('CURL_CA_BUNDLE'))

Meaning, if the env variables are not set, set "True"

Because I just got a meeting with AzureStack and CLI team, and they will need this env variable for the CLI :/

@johanste @bganapa

Yes, with that commit, verify is being sent as False :(

@lmazuel running on master the CLI is pulling this version of KV.

Fixed in https://github.com/Azure/azure-sdk-for-python/pull/1163 for 0.3.3


Usage for Graph Neural Networks

How should webdataset be used for storing graph representation of a mesh (used for training MeshGraphNets) in tar files? I'm thinking about JSON, but that would make the tar file big, so maybe pickle? And how the decoding function would look like for JSON or Pickle data?

You can store individual files in compressed format, so just use data.json.gz. Files with extensions of .json, .json.gz, .pyd, and .pyd.gz get decoded automatically by WebDataset, so you don't need to do anything.
Alternatively, you can use any of the standard mesh file formats used in science and engineering if there are Python readers for it. For decoding, you just need to write a function that takes a byte array as input and returns the decoded data. Inside that function, you usually either turn the byte array into an io.ByteIO object or just write it to disk; either way, you use the mesh library's reader to read in the data.


Edit and Save MP Monitoring Components Data (7.0)

AC
Given a facility is selected and a user has submitter/viewer permissions,
When a MP exists for the facility,
Then MP can be edited.
Given at least one change is made to MP Components data,
When the user saves the plan,
Then updates are stored.
Users with view only permission will not have the capacity to update a MP, and thus will not have the ability to edit and save MP monitoring components data.
Design wiki

Need to identify any additional tables required for editing
If addl tables are identified, then API work will need to be done
Need to create wireframe for showing methods in a modal (not the panel) @cvp-alexrobinson or @AllisonFrancis

merged with #417


Promote Fabric.launch() as the default experience in Fabric docs

What does this PR do?
In response to feedback, we will change the introduction to showcase Fabric.launch instead of the lightning run model CLI commands. This is an easier onboarding experience for new users who might be turned off by learning new CLI commands.
cc @borda @carmocca @justusschock @awaelchli @rasbt
Closes #16799

Awesome, thanks @awaelchli !


[stable/airflow] install-requirements.sh script should be always available

Is this a request for help?:
No
Is this a BUG REPORT or FEATURE REQUEST? (choose one):
FEATURE REQUEST

Describe in detail the feature/behavior/change you'd like to see.

The install-requirements.sh script should be available even if the persistence is enabled.
There are cases when persistence is enabled (for example using NFS volumes) and initContainer is necessary to populate the dag folder from a Git repo at initialization.
In this moment, if persistence is enabled, the scripts volume is not mounted and the install-requirements.sh cannot be found nor executed.
Version of Helm and Kubernetes:
Helm:
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Kubernetes:
Client Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.0", GitCommit:"91e7b4fd31fcd3d5f436da26c980becec37ceefe", GitTreeState:"clean", BuildDate:"2018-06-27T22:29:25Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"11", GitVersion:"v1.11.3", GitCommit:"a4529464e4629c21224b3d52edfe0ea91b072862", GitTreeState:"clean", BuildDate:"2018-09-09T17:53:03Z", GoVersion:"go1.10.3", Compiler:"gc", Platform:"linux/amd64"}
Which chart:
stable/airflow
What happened:
If persistence is enabled, the scripts volume is not mounted and the install-requirements.sh cannot be found nor executed.
What you expected to happen:
Scripts volume should be mounted and the install-requirements.sh should be available even if persistence is enabled.

Hi. I would be glad to have a pull request for this.


[jvm-packages] How can a C++ program use a xgboost model trained by xgboost4j.

I wanted to train a xgboost model by xgboost4j-spark, and use the model for prediction in a C++ server program. But it failed due to the below code in the red circle.

The code is from https://github.com/dmlc/xgboost/blob/6f16f0ef5829965ba420ef6937617600d286820a/src/gbm/gbm.cc

how you saved the model?

I have the same problem，I used func saveModelAsHadoopFile

@CodingCat thank you for your response. I saved my model using the following code
if (save_path != ""){
model.saveModelAsHadoopFile(save_path)
}

saveModelAsHadoopFile can only be consumed by xgboost4j-spark, if you want to cross-languages consuming, you have to call https://github.com/dmlc/xgboost/blob/72451457120ac9d59573cf7580ccd2ad178ef908/jvm-packages/xgboost4j/src/main/scala/ml/dmlc/xgboost4j/scala/Booster.scala#L149

I am just faced the same problem and it works now.

First, I suggest that you could compile the xgboost as an dynamic library and use it online in your c++ server, which is what we do now.  Including the source code from xgboost in your server may be difficult.

Train model on Spark has no problem.  Just notice Spark does the internal conversion, and does not accept formats that are 0-based.  This is very important which can cause feature index mismatch.

source code of loadLibSVMFile in Spark is as bellow:
def loadLibSVMFile(
      sc: SparkContext,
      path: String,
      numFeatures: Int,
      minPartitions: Int): RDD[LabeledPoint] = {
    val parsed = sc.textFile(path, minPartitions)
      .map(_.trim)
      .filter(line => !(line.isEmpty || line.startsWith("#")))
      .map { line =>
        val items = line.split(' ')
        val label = items.head.toDouble
        val (indices, values) = items.tail.filter(_.nonEmpty).map { item =>
          val indexAndValue = item.split(':')
          val index = indexAndValue(0).toInt - 1  // Convert 1-based indices to 0-based.
          val value = indexAndValue(1).toDouble
          (index, value)
        }.unzip
        .......

@CodingCat thank you. I will have a try.

It works. Thank @CodingCat and @zmingshi


Rename stack-azure to provider-azure

Signed-off-by: hasheddan<EMAIL_ADDRESS>
Description of your changes

Changes references, imports, and module from stack-azure to provider-azure.
Checklist

I have:

[x] Run make reviewable to ensure this PR is ready for review.
[x] Ensured this PR contains a neat, self documenting set of commits.
[x] Updated any relevant documentation, examples, or release notes.
[ ] Updated the dependencies in app.yaml to include any new role permissions.

@negz I believe this should pass CI after codecov token rename :+1:


Prevent timecache from leaking when used with methods

Companion wekapp ticket: https://bitbucket.org/wekaio/wekapp/pull-requests/5647


[Bug] Issue in runtime useing @vue/cli-service building tool after upgrade cornerstone libs.

Describe the Bug
I got this error after upgrade to 1.81.0 versions in my vue2 project:
The error:
VolumeProperty.js:209 Uncaught TypeError: Cannot read properties of undefined (reading 'FAST_LINEAR')
at 37801 (VolumeProperty.js:209:40)
at n (bootstrap:19:32)
at 90956 (chunk-vendors.18561ab7.js:90:347282)
at n (bootstrap:19:32)
at index.js:1:104
at 9616 (index.js:1:2)
at n (bootstrap:19:32)
at 88735 (app.91ee32ab.js:26:544626)
at n (bootstrap:19:32)
at startup:4:87
My vue.config.js file:
const { defineConfig } = require("@vue/cli-service");

const CopyWebpackPlugin = require("copy-webpack-plugin");
const path = require("path");
module.exports = defineConfig({
transpileDependencies: ["vuetify"],
devServer: {
headers: {
"Cross-Origin-Opener-Policy": "same-origin",
"Cross-Origin-Embedder-Policy": "credentialless",
},
},
outputDir: "vue-build/viewer-build/dist",
assetsDir: "viewer-assets-dir",
configureWebpack: {
externals: {
experiments: {
asyncWebAssembly: true,
},
},
resolve: {
//alias: require('./aliases.config').webpack
alias: {
"@cornerstonejs/dicom-image-loader":
<EMAIL_ADDRESS>"@cornerstonejs/tools": <EMAIL_ADDRESS>},
},
plugins: [
new CopyWebpackPlugin({
patterns: [
{
from: path.join(__dirname, "node_modules/@cornerstonejs/dicom-image-loader/dist/dynamic-import"),
to: path.join(__dirname, "vue-build/dist/viewer-assets-dir/js"),
toType: "dir",
},
],
}),
],
},
});
Steps to Reproduce

Upgrade to leatest cornerstone versions.
Run build command from webpack -vue cli service-
You got the error on the runtime.

The current behavior
Project stop from work.

The expected behavior
Must load and work
OS
Ubuntu 24.04 LTS
Node version
v14.20.1
Browser
Chrome 125.0.6422.112 (Official Build) (64-bit)

I'm not really sure what is the issue, hmmm

It is solved by using webpack version 5.89.0
It is looks like there are error with versoin after that.


getting error when doing "make initdb" step

CREATE DATABASE
xz -d -k dev/example.sql.xz
xz: dev/example.sql.xz: No such file or directory
make: *** [initdb] Error 1

Hi @wardcomm, does this file not exist in your cloned repo?

i had renamed /dev/example.sql.xz to somethink else and installed these
ls
npm install
yum install curl sudo
curl --silent --location https://rpm.nodesource.com/setup_6.x | sudo bash -
yum install -y nodejs
yum install -y gcc-c++ make -y
npm install
then i ran "make initdb" from warehouse folder and have the db running and website is working.
so you can close ticket


Add a keyword for private scope in libraries

This issue was originally filed by<EMAIL_ADDRESS>
https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/a0cdcd2872d4c5eb/e1d6b834bd25533e
The Dart team decided to use underscores to hide variables in libraries. While this seems to be a common practice, a lot of people don't like to mix their variable names with semantics.
That's why I propose to add a type modifier like 'private' or 'hide'. I think both practices can be incorporated in the language and everybody would be happy.
One developer could write:
private int myVar = 10;
myVar = myVar + 1;
while another developer prefers:
int _myVar = 10;
_myVar = _myVar + 1;
Personally I'm in favour for the modifier approach. And I think underscores are a bad idea. It is clear a lot of people like the underscore approach (including the Dart devs) and I respect that. But I think there's a place for both styles in the language.

:+1:

This is too much. No one is hearing these issues. I would like to ditch the Dart now for this weird underscores and unreadable syntax. Dart would be great without these ugly underscores. I would like to say Dart has been failed; at least to please me. Sorry.

@krupalshah Check out Typescript.


scripts: Remove unused generated code

vk_api_version.h and vk_extension_helper.h were being generated for no reason.

CI Vulkan-ExtensionLayer build queued with queue ID 153105.

CI Vulkan-ExtensionLayer build # 876 running.

CI Vulkan-ExtensionLayer build queued with queue ID 153122.

CI Vulkan-ExtensionLayer build # 877 passed.


Add Funki (Mainnet)

Adding a New Chain
This PR adds Funki to the registry.
Checklist

[x] I have declared the chain at the appropriate Superchain Level.
[x] I have run just validate <chain-id> locally to ensure all local validation checks pass.
[x] I have run just codegen to ensure that the chainlist and other generated files are up-to-date and include my chain.

Notice we increase the value seq_window_size in rollup.json, which is different with the value sequencerWindowSize in deploy-config.json now. While the ci does not report it's a problem.


Error in 5/10/5 hex distance measurement

Foundry: v10.291
dnd5e: v2.1.5
Browser: Version 112.0.5615.49 (arm64)
browserclient OS: macOS 13.3
Running Foundry on NodeJS locally
No modules running.
Measuring 5/10/5 diagonals using canvas.grid.measureDistance or the ruler gives erroneous measurements on hex maps.
Example:
Place two tokens at sufficient distance to require at least two diagonal moves to get from one to another. Measure using ruler or alternatively:
A = _token.center(); // {x: 2425.6217782649105, y: 2590}
B = _token.center(); // {x: 2970.6217782649105, y: 2905}
canvas.grid.measureDistance(A, B, { gridSpaces: true }) // Returns 30 but should be 35 using 5/10/5 rules

I would have thought 5/10/5 rule would not apply to hex grids. The passage in the DMG where it talks about this rule does not specify, but it does say this:

count every square as 5 feet, even if you’re moving diagonally. Though this is fast in play, it breaks the laws of geometry and is inaccurate over long distances.

This is not true for hex grids though. Moving diagonally on a hex grid does not break any laws of geometry and is not inaccurate over long distances, so the rationale for implementing such a rule is not there. In fact, this is one of the advantages of using a hex grid in the first place: diagonals require no special treatment.
So, it seems like the correct behaviour to not apply the 5/10/5 rule to hex grids.


[Docs]: App Router setup is strictly for Next v14 and not yet updated for asynchronous params in v15

Link to page
https://next-intl-docs.vercel.app/docs/getting-started/app-router/with-i18n-routing#layout
Describe the problem
The change required is pretty simple as it's just the following:
export default async function LocaleLayout({
  children,
- params: {locale},
+ params,
}: {
  children: React.ReactNode;
- params: {locale: string};
+ params: Promise<{locale: string}>;
}) {
+ const locale = (await params).locale;
// ...

The issue is that the docs wouldn't be correct for Next 14 if this diff was to be applied. As such I didn't want to open a PR straight away and wanted to start a conversation how to proceed here from a UX-perspective.

Should two tabs be introduced like in this example to distinguish Next 14 and 15? https://next-intl-docs.vercel.app/docs/getting-started/app-router/without-i18n-routing#next-config
Should a separate page for v15 be introduced?
Should a short paragraph be added that explains this particular required diff?

I've created a PR for Next.js to address the issue with alternate links: https://github.com/vercel/next.js/pull/73431. Once that is merged, I'd like to finally suggest updating to Next.js 15 in the docs (see https://github.com/amannn/next-intl/pull/1089).


Add workflow templates for a common pattern.

Description
This change adds GitHub Action workflows templates for repositories under the opensearch-project organization. The purpose is to conform to a common pattern for using GitHub Actions for CI & CD.
Issues Resolved
https://github.com/opensearch-project/opensearch-build/issues/116
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.
Signed-off-by: Rabi Panda<EMAIL_ADDRESS>

Let's add a GH action badge and enable dummy CI on this repo?

++ Did you enable this in your fork? Can we see some results?

++ Did you enable this in your fork? Can we see some results?

I ran one on the common-utils fork based on the workflow template https://github.com/adnapibar/common-utils/runs/3234294435?check_suite_focus=true

@dblock Thanks! Can you please merge it.

Enable GH actions on your fork for the .github repo, and show me that these workflows work? I am pretty sure this will fail if we enable it now because those scripts called gradlew.

Enable GH actions on your fork for the .github repo, and show me that these workflows work? I think you should do #25 as part of this PR to make sure the workflows are actually function. (I am pretty sure this will fail if we enable it now because those scripts called gradlew.)

Added the DCO check workflow for this repo. Here is how it worked in my .github fork https://github.com/adnapibar/.github/runs/3267249808?check_suite_focus=true
Yes, this is not a  Gradle based Java project so for these kind of projects we can remove those steps and only keep the DCO check. For all Gradle based Java project the template can be used as is e.g. here is the workflow on the common-utils fork - https://github.com/adnapibar/common-utils/runs/3267308452?check_suite_focus=true

I am a little worried about the proliferation of things like workflow-template, these are a little hard to discover. Furthermore we have both OpenSearch and OpenSearch Dashboards projects in this repo. What do you think about just merging these into an actually running CI/CD workflow, and either commenting out the parts that invoke scripts or making a comment such as "for example of an OpenSearch workflow, see [link]", "for an example of an OpenSearch Dashboards workflow, see [link]"?