HBASE-26638 Cherry-pick the ReflectionUtils improvements in HBASE-215…

…15 to branch-2

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 37s
branch-2 passed

+1 :green_heart:
compile
0m 27s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 23s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

_ Other Tests _

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

29m 36s

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-3993/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 5ffc4d067c7f 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / a67fb0a85c

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

Max. process+thread count
243 (vs. ulimit of 12500)

modules
C: hbase-common U: hbase-common

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3993/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 28s
Docker mode activated.

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 37s
branch-2 passed

+1 :green_heart:
compile
0m 27s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 23s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

_ Other Tests _

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

29m 36s

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-3993/1/artifact/yetus-jdk8-hadoop2-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 5ffc4d067c7f 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / a67fb0a85c

Default Java
AdoptOpenJDK-1.8.0_282-b08

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

Max. process+thread count
243 (vs. ulimit of 12500)

modules
C: hbase-common U: hbase-common

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3993/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
0m 41s
Docker mode activated.

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 46s
branch-2 passed

+1 :green_heart:
compile
0m 29s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 28s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

_ Other Tests _

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

30m 33s

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-3993/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 23df547cfadb 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / a67fb0a85c

Default Java
AdoptOpenJDK-11.0.10+9

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

Max. process+thread count
370 (vs. ulimit of 12500)

modules
C: hbase-common U: hbase-common

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3993/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
0m 41s
Docker mode activated.

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

_ Prechecks _

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 46s
branch-2 passed

+1 :green_heart:
compile
0m 29s
branch-2 passed

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

+1 :green_heart:
javadoc
0m 28s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

_ Other Tests _

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

30m 33s

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-3993/1/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 23df547cfadb 4.15.0-156-generic #163-Ubuntu SMP Thu Aug 19 23:31:58 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / a67fb0a85c

Default Java
AdoptOpenJDK-11.0.10+9

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

Max. process+thread count
370 (vs. ulimit of 12500)

modules
C: hbase-common U: hbase-common

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3993/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 14s
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.

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 17s
branch-2 passed

+1 :green_heart:
compile
0m 48s
branch-2 passed

+1 :green_heart:
checkstyle
0m 25s
branch-2 passed

+1 :green_heart:
spotbugs
0m 47s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

+1 :green_heart:
hadoopcheck
13m 56s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
0m 54s
the patch passed

_ Other Tests _

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

36m 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-3993/1/artifact/yetus-general-check/output/Dockerfile

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 05582b004572 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / a67fb0a85c

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
86 (vs. ulimit of 12500)

modules
C: hbase-common U: hbase-common

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3993/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
1m 14s
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.

_ branch-2 Compile Tests _

+1 :green_heart:
mvninstall
4m 17s
branch-2 passed

+1 :green_heart:
compile
0m 48s
branch-2 passed

+1 :green_heart:
checkstyle
0m 25s
branch-2 passed

+1 :green_heart:
spotbugs
0m 47s
branch-2 passed

_ Patch Compile Tests _

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

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

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

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

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

+1 :green_heart:
hadoopcheck
13m 56s
Patch does not cause any errors with Hadoop 3.1.2 3.2.1.

+1 :green_heart:
spotbugs
0m 54s
the patch passed

_ Other Tests _

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

36m 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-3993/1/artifact/yetus-general-check/output/Dockerfile

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti checkstyle compile

uname
Linux 05582b004572 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2 / a67fb0a85c

Default Java
AdoptOpenJDK-1.8.0_282-b08

Max. process+thread count
86 (vs. ulimit of 12500)

modules
C: hbase-common U: hbase-common

Console output
https://ci-hadoop.apache.org/job/HBase/job/HBase-PreCommit-GitHub-PR/job/PR-3993/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.


Weird crash - game is launching without trinkets but it shouldn't.

It should stop and say that trinkets is required because it's mentioned in the fabric.mod.json but for some reason this gets ignored.
https://paste.ee/p/JniAB

Version 1.5.0 doesn't need trinkets, and is incompatible with trinkets. This will be fixed in the next version. Trinkets didn't put out a 1.17.1 version in time for our 1.5.0 update, so we had to use a custom fork of trinkets. If a 1.17.1 version of trinkets is released by our next update, it'll be sure to be used instead.

If you have no other mods that require trinkets, you can remove it entirely, and the aether should work just fine.

If you have no other mods that require trinkets, you can remove it entirely, and the aether should work just fine.

The point is - it crashes when I don't add Trinkets.

Closing as Invalid, as in 1.5.0+, Trinkets is Jar-In-Jar'd with the Aether. The crash itself was also resolved in Trinkets 3.0.1+ (Which is now packaged with new Aether Builds)


Fix compilation error in HttpServer example

Tangentially related, for a future pull request, not this one, what do you think of something like this:
struct SocketContextOptions : us_socket_context_options_t {
SocketContextOptions() : us_socket_context_options_t({}) {
}
};
The idea is that the member variables would all be initialized to default values without the need to be kept in sync between two structs and there would be no need for a conversion operator since SocketContextOptions would inherit from us_socket_context_options_t.

Yes SocketContextOptions was added very recently to fix a warning, it can be improved


The public score in readme comes from dev set or test set?

I have a simple question:

Those scores in the readme, are those comes from dev set or test set?
Are they all median score of many times experiment?

These are single run dev set results with early stopping.

OK. Thank you!


Introduce --enable-pprof flag to optionally run pprof server

Proposed Changes
This patch introduces the ability to start a pprof server as part of k3s. This enables various types of profiling, including CPU and memory profiling.
Types of Changes

Verification

Example usage:
igor@k3s:~$ sudo cat /etc/rancher/k3s/config.yaml

enable-pprof: true

igor@k3s:~$ curl --insecure https://localhost:6443/debug/pprof/profile > cpu.pprof

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 26163    0 26163    0     0    870      0 --:--:--  0:00:30 --:--:--  6822

igor@k3s:~$ go tool pprof cpu.pprof

File: containerd
Type: cpu
Time: May 1, 2022 at 2:20pm (UTC)
Duration: 30.02s, Total samples = 1.84s ( 6.13%)
Entering interactive mode (type "help" for commands, "o" for options)

(pprof) top
Showing nodes accounting for 960ms, 52.17% of 1840ms total
Showing top 10 nodes out of 534
      flat  flat%   sum%        cum   cum%
     320ms 17.39% 17.39%      320ms 17.39%  runtime.futex
     150ms  8.15% 25.54%      150ms  8.15%  runtime.epollwait
     100ms  5.43% 30.98%      100ms  5.43%  syscall.Syscall6
      90ms  4.89% 35.87%       90ms  4.89%  syscall.Syscall
      80ms  4.35% 40.22%       80ms  4.35%  runtime.cgocall
      50ms  2.72% 42.93%       50ms  2.72%  github.com/prometheus/client_golang/prometheus.hashAdd
      50ms  2.72% 45.65%       50ms  2.72%  runtime.siftdownTimer
      40ms  2.17% 47.83%       40ms  2.17%  runtime.findObject
      40ms  2.17% 50.00%      510ms 27.72%  runtime.findrunnable
      40ms  2.17% 52.17%      190ms 10.33%  runtime.netpoll

(pprof) png
Generating report in profile001.png

Generated png:

Linked Issues

This feature was previously discussed in https://github.com/k3s-io/k3s/issues/1635.
User-Facing Change

Introduce --enable-pprof flag to optionally run pprof server

Further Comments

This can be useful to identify sources of CPU resource usage, and perhaps reduce the baseline CPU utilization.
Another tool that can be useful for this kind of diagnosis (and account for system time and more) is perf. However, it requires unstripped binaries which k3s does not currently ship. Having unstripped binaries optionally available would be really useful to be able to capture more complete profiles.

As a side-note, I ran a 10 minute profile, and the resulting flamegraph already highlights some potential opportunities.

24.4% of the profile is spent in WithLabelValues. Looking at the code in apiserver, it may be possible to cache the metric label lookup: sample_and_watermark.go.
8.25% of the profile is spent in Kubelet's HandlePodCleanups, while performing a readdir. Since this appears to be a cleanup task, it may be possible to run this less frequently.
4.5% of the profile is spent in cgo (from sqlite) -- optimizing those paths or switching to a different backend (leveldb or such?) could buy a few cycles.
4.5% of the profile is spent in cadvisor housekeeping. This may be able to run less frequently.

I also saw a lot of frequently scheduled goroutines, such as https://github.com/kubernetes/kubernetes/issues/94811 when running the execution tracer. These are likely putting pressure on the golang scheduler.

It looks like just accepting the suggestion breaks DCO because the commit isn't signed. Once that's resolved I think we're good to go.

@igorwwwwwwwwwwwwwwwwwwww We are in code freeze this week for the May K8s releases, but I will make sure this gets in for the June releases.


Feat/ens reverse lookup

Added resolving from address to ens + avatar.
Possibly there are more than one ens for address. Showing ens resolved by wagmi.
Fixed autocomplete styles
https://user-images.githubusercontent.com/25638585/218565427-3e4d585f-88d5-4fb7-bab8-7d405c9e7cfd.mov

Looks great !! tested it out and works well 🙌


Ensure Erlang track is ready for v2 launch

There are a number of things we're going to want to check before the v2 site goes live. There are notes below that flesh out all the checklist items.

[ ] The track has a page on the v2 site: https://v2.exercism.io/tracks/erlang
[ ] The track page has a short description under the name (not starting with TODO)
[ ] The "About" section is a friendly, colloquial, compelling introduction
[ ] The "About" section follows the formatting guidelines
[ ] The code example gives a good taste of the language and fits within the boundaries of the background image
[ ] There are exercises marked as core
[ ] Exercises have rough estimates of difficulty
[ ] Exercises have topics associated with them
[ ] The first exercise is auto_approve: true

Track landing page
The v2 site has a landing page for each track, which should make people want to join it. If the track page is missing, ping @kytrinyx to get it added.
Blurb
If the header of the page starts with TODO, then submit a pull request to https://github.com/exercism/erlang/blob/master/config.json with a blurb key.  Remember to get configlet and run configlet fmt . from the root of the track before submitting.
About section
If the "About" section feels a bit dry, then submit a pull request to https://github.com/exercism/erlang/blob/master/docs/ABOUT.md with suggested tweaks.
Formatting guidelines
In order to work well with the design of the new site, we're restricting the formatting of the ABOUT.md. It can use:

Bold
Italics
Links
Bullet lists
Number lists

Additionally:

Each sentence should be on its own line
Paragraphs should be separated by an empty line
Explicit <br/> can be used to split a paragraph into lines without spacing between them, however this is discouraged.

Code example
If the code example is too short or too wide or too long or too uninteresting, submit a pull request to https://github.com/exercism/ocaml/blob/master/docs/SNIPPET.txt with a suggested replacement.
Exercise metadata
Where the v1 site has a long, linear list of exercises, the v2 site has organized exercises into a small set of required exercises ("core").
If you update the track config, remember to get configlet and run configlet fmt . from the root of the track before submitting.
Topic and difficulty
Core exercises unlock optional additional exercises, which can be filtered by topic an difficulty, however that will only work if we add topics and difficulties to the exercises in the track config, which is in https://github.com/exercism/erlang/blob/master/config.json
Auto-approval
We've currently made any hello-world exercises auto-approved in the backend of v2. This means that you don't need mentor approval in order to move forward when you've completed that exercise.
Not all tracks have a hello-world, and some tracks might want to auto approve other (or additional) exercises.
Track mentors
There are no bullet points for this one :)
As we move towards the launch of the new version of Exercism we are going to be ramping up on actively recruiting people to help provide feedback. Our goal is to get to 100%: everyone who submits a solution and wants feedback should get feedback. Good feedback.
If you're interested in helping mentor the track, check out http://mentoring.exercism.io/

When all of the boxes are ticked off, please close the issue.
Tracking progress in https://github.com/exercism/meta/issues/104

Things that can be checked off:

The track has a page on the v2 site: https://v2.exercism.io/tracks/erlang
The "About" section follows the formatting guidelines
The code example gives a good taste of the language and fits within the boundaries of the background image
Exercises have rough estimates of difficulty

I've submitted a new about section #249, added core exercises, topics, and auto_approve #251, and added a blurb #250


CSV upload not working

Neither Manifold running locally nor http://manifold.mlvis.io/ returns any result after uploading .csv feature, prediction and ground truths data sets.
I have tried following the instructions  on how to format .csv files, but it does not seem to work for me.
The csv files I have tried it with are attached (renamed extension to .txt, to be able to attach to issue).
What am I missing?
truth.txt
prediction.txt
features.txt

@sar2160 Could you share the files that caused the issues? And are you using the website or running the application locally?

Hi,
it does not work both locally and on the website.
The files are attached to the questions.
Best regards
Alex
On Sun, Feb 23, 2020 at 1:10 AM Firenze11<EMAIL_ADDRESS>wrote:

@sar2160 https://github.com/sar2160 Could you share the files that
caused the issues? And are you using the website or running the application
locally?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/uber/manifold/issues/103?email_source=notifications&email_token=AL44T7WOCVYIY5TPL3AVNSLREG5GVA5CNFSM4KNVRFU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMVNZQQ#issuecomment-590011586,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AL44T7WU46ZLNNEAZHKZVFDREG5GVANCNFSM4KNVRFUQ
.


Kubernetes 1.26 Release

From https://github.com/kubernetes/sig-release/blob/master/releases/release-1.26/README.md:
The 1.26 release cycle is as follows:

Monday 5th September 2022: Week 1 — Release cycle begins
Monday 24th - Friday 28th October 2022: Week 8 - KubeCon NA
Wednesday 9th November 2022: Week 10 — Code Freeze
Tuesday 6th December 2022: Week 14 — Kubernetes v1.26.0 released

Pre-release Code Changes
Before publishing each release, the following code updates must be made:

[ ] (Optional, but recommended) Bump k8s.io dependencies to the -rc tags. These tags are usually published around upstream code freeze. Example
[ ] Bump k8s.io dependencies to GA tags once they are published (following the upstream release). Example
[ ] Ensure that Go is updated to the same version as upstream. Example
[ ] Make CI changes in github.com/kubernetes/test-infra to add the new version's tests (note, this may also include a Go bump). Example
[ ] Update local CI versions for utils (such as golang-ci), kind, and go. Example - e2e, Example - helm
[ ] Update version references in docs and Readme. Example

I'd like to take the pre-release code changes to become more familiar with the process.
/assign

Thanks @a7i, fyi all for this release I'd like to organize our tasks through a Github project so we can better keep track of what is in progress. I'm looking into how we can set one up for our project

Yes, I saw your comment after the assignment. Makes sense 👍🏼

/unassign

Got the project set up at https://github.com/orgs/kubernetes-sigs/projects/22 and filled in with draft issues
Let's wrap up v0.25.0 first, and then we can start organizing those. It will be great if we can get a dedicated meeting time set up for this from https://github.com/kubernetes-sigs/descheduler/issues/944

cool, looks more transparency and funny ~~

Just created new issues for this release: https://github.com/kubernetes-sigs/descheduler/issues/1007 https://github.com/kubernetes-sigs/descheduler/issues/1008 https://github.com/kubernetes-sigs/descheduler/issues/1009. Please feel free to self-assign if you are interested!

Last call: going to tag v0.26.0 this afternoon if there are no last minute changes waiting to get in (https://github.com/kubernetes-sigs/descheduler/issues/1021)

/close


fix(ios): wait dispatch_queue_t finished on stopTranscribe

Fix #107.
Currently we used encoder_begin_callback for the abort method, but it does not directly terminate the thread. This PR change the context uses an own dispatch_queue_t & wait it finished on stop method or release.
It probably have the same issue on Android, I'll investigating for it later.

[ ] Release queue on invalidating

I had an issue that sometimes after I call stop, the capturing isn't being updated to false, can this be related to that? not sure how to reproduce yet to open a issue, not happening often

I had an issue that sometimes after I call stop, the capturing isn't being updated to false, can this be related to that? not sure how to reproduce yet to open a issue, not happening often

I think it's not related to this PR. I can check this out, currently it check the state before stop the audio queue, and can't promising not has some side effect.


POC to investigate what is delta of gas we save if we include a transfer function on TokenRules

Goal
To reduce two hops from TH → Rule and Rule-> Token Rule, to one and reduce gas consumed to execute a transaction.
Current Implementation

Every transfer are done through transfer rule contract.
So calls are first done from TH to transferRule contract which then calls TokenRule executeTransfers. - executeTransfers does the actual transfer.

POC

Create a method transfer in TokenRules contract.
Call TH.executeRule. After Ekey verification TR.transfer is called. TR.transfer is acting as rule here.
Calculate the gas difference between the two approaches.

Below flow of steps followed for analysis
Approach1

EIP20TokenMock contract is deployed.
Organization contract is deployed and worker is set.
TokenRules contract is deployed.
TransferRule contract is deployed and it is registered in TokenRules.
TokenHolder contract is deployed by providing the wallets and
required confirmations.
Validation of deployed contract and its parameters are done.
We generate executable data for TransferRule contract's transferFrom
method.
Relayer calls executeRule method of tokenholder contract.

ExecuteRule Gas Consumed(1 transfer): 144855
Approach2

EIP20TokenMock contract is deployed.
Organization contract is deployed and worker is set.
TokenRules contract is deployed.
TransferRule contract is deployed and it is registered in TokenRules.
TokenHolder contract is deployed by providing the wallets and
required confirmations.
Validation of deployed contract and its parameters are done.
We generate executable data for TokenRule processTransfers method.
Relayer calls executeRule method of tokenholder contract.

ExecuteRule Gas Consumed(1 transfer): 118163
Gas saved: 26692
Gas saved in %:  18.4%
Note

TokenRule transfer method accept single to address and amount for transfer.

Branch: https://github.com/abhayks1/openst-contracts/tree/tr_transfer

Closing this ticket as we have 2 tickets already which clearly defines analysis for single and multiple transfers.


Sample Update - Create Colored Folder

What's in the pull request

Added CLI for Microsoft 365 script sample that creates a Colored Folder in a SharePoint document library.

Hey @ganesh-sanap, thank you for the CLI sample and congratulations for making MVP! This will be live shortly 🎉👏

Thank you @pkbullock!


doc: fix multiple issues

Summary:
doc: doxygen: do not use separate member pages
When this option is enabled some data structures have missing pages. Use
the default setting (NO).

doc: warnings: make expressions more generic
When duplicates exist the problem may come from two or more distinct
constructs. When running parallel builds there is no guarantee on which
one will come first (or if all), so allow any C construct.

drivers: display: fix doxygen issues
The way some structures were documented was causing issues on the
Sphinx/Breathe side. Move to a more "standard" format.

doc: enable members option by default when using breathe
Enable the :members: option by default when using breathe directives.
This exposes automatically stuff like structure fields.

doc: remove redundant usage of :members: in breathe directives
:members: is now enabled by default.

ref:https://zephyrproject.slack.com/archives/C18PLHN8H/p1621107917366000

just need to fix reference/bluetooth/gatt.rst

I think this is a great change, I just am concerned about the possibility of it accidentally making some private members publicly documented within stable APIs.
I'm guessing that we have not audited the APIs in this page as a result of this PR:
https://docs.zephyrproject.org/latest/reference/api/overview.html
I think we should make sure that any newly visible structure members in stable APIs are either deliberately there for users to access, or explicitly documented as for internal use, so we can change them later without having to go through the stable API process.
@gmarull have you done something like that?
cc @carlescufi

I think this is a great change, I just am concerned about the possibility of it accidentally making some private members publicly documented within stable APIs.
I'm guessing that we have not audited the APIs in this page as a result of this PR:
https://docs.zephyrproject.org/latest/reference/api/overview.html
I think we should make sure that any newly visible structure members in stable APIs are either deliberately there for users to access, or explicitly documented as for internal use, so we can change them later without having to go through the stable API process.
@gmarull have you done something like that?
cc @carlescufi

I haven't performed an exhaustive analysis, but as far as I understand :members: displays public members, i.e. struct fields in our case (if they are documented, since we're not using :undoc-members:). This information is already displayed on the Doxygen side.

Maybe we can give the maintainers until rc3 to check their APIs to make sure they aren't accidentally overdocumenting as a result of this PR?

Maybe we can give the maintainers until rc3 to check their APIs to make sure they aren't accidentally overdocumenting as a result of this PR?

I'm ok with that, how can we notify?

I'm ok with that, how can we notify?

per offline discussion with @carlescufi , this can be done via email to devel

@gmarull is there a doc build up somewhere people can click on, so they don't have to build it themselves?

Do we have an example where this is wrong? The docs for members was always published, just differently. IMO this should be merged and issues should be addressed as we find them, if any. delaying this with no indication that someone is actually working on reviewing all APIs in the background is just pushing any potential issues for later, i.e. rc3...

Do we have an example where this is wrong? The docs for members was always published, just differently. IMO this should be merged and issues should be addressed as we find them, if any. delaying this with no indication that someone is actually working on reviewing all APIs in the background is just pushing any potential issues for later, i.e. rc3...

+1

Fine, removing my -1

@nashif I'm preparing my "I told you so" when we have to deal with this in the stable API process down the line ... :P


Can't handle different package with the same repo name ?

I have web-server installed a long time ago,

https://github.com/eschulte/emacs-web-server
~/.emacs.d/straight/repos/emacs-web-server

today I install ein and use it, I get
Cannot open load file: No such file or directory, simple-httpd

straight.el thinks simple-httpd is installed but it is not. I seems it is because both web-server and simple-httpd are using the same repo name: emacs-web-server

https://github.com/eschulte/emacs-web-server (web-server)
https://github.com/skeeto/emacs-web-server (simple-httpd)

Yes, you have to rename one of the local repositories. E.g. use the recipe
(simple-httpd :type git :host github :repo "skeeto/emacs-web-server" :local-repo "simple-httpd")

There's not really anything that can be done on the straight.el side, except to emit a warning when two automatically generated local repository names happen to be the same (since it's probably not intentional).

want to add that I found two other packages with the same conflict; dracula-theme and challenger-deep-theme.

I encountered exact same problem as OP today. took me a while to figure out that this was what was going on. finally can use https://github.com/ancane/markdown-preview-mode
(requires web-server)

Migrated to #500.


Fixing policy improvement equation

Similar typo as reported earlier for value iteration.
s -> s_prime (because we calculate Q value based on expected value of the next state)

Thanks for spotting these.

Not a problem, I found these notes as a good ready reference for various RL algorithms, thought it'd help others.


Please add the modes of 4-5-6 filters in a row

3 rows is still too wide if I want to have a top bar of filters and use all the horisontal space for linecharts, barchats or other timeline related widgets:

This is implemented and working. The issue can be closed

done


Big Design Matrix overhaul to make working with multiple-runs much easier/intuitive.

Also address issues: #175, #228, #181, #154 and reworked tutorial for Design Matrix with better section headings and realistic workflow example to make first level regression easier.

Coverage decreased (-0.4%) to 63.846% when pulling 0fa3615a341924b174387aea1f5eadb0f16d3d86 on ejolly:master into b87476290e627045a048bef1ceee6180fc61cddc on ljchang:master.


Naming and organization should be coherent through the different docs and in the graphic.

From Javier Quniteros:
For instance, the concept “metadata” is present in the Swagger only once “metadataIsMutable”, so what is exactly “metadata". There we refer to the “properties”. Probably we should reduce the number of concepts with a formal meaning in the document to the ones that are used in the JSON representation of the Collection/Member. So many subdivisions do not help. In the Swagger page it’s much clear. I would suggest to go for a description in the document that goes closer to what we have at the Swagger description.

metadataIsMutable: This should only be understood as covering collection properties, not properties at the member level. So the best way would be to change this to "propertiesAreMutable". We could also leave it at the current name and only update the description, but that leaves a level of ambiguity for implementors if they don't follow every word in the docs.

I agree. We should change CollectionObject.metadataIsMutable to CollectionOption.propertiesAreMutable.


Rename Camlistore into Perkeep

Camlistore has changed its name to Perkeep in December 2017: https://github.com/perkeep/perkeep/issues/981.
Therefore, is it possible to rename this image?

It should not just be renamed. The image (Dockerfile) would have to be modified to pull the correct sources as well. The Dockerfile could use some updating anyway. I would advise to wait for the rename (and other pending changes, like the switch to sha224) to be completely done though.


fix broken links.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: morvencao
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: rshriram
If they are not already assigned, you can assign the PR to them by writing /assign @rshriram in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@morvencao: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-integ-k8s-tests.sh
4463098f8dd45e485afc1282e21a48d04290858a
link
/test istio-integ-k8s-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: geeknoid, morvencao
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [geeknoid]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


WithProperties sink not working in ASP.NET Core 2.1 app

Hi,
I'm trying to use the 'AzureTableStorageWithProperties' sink in my ASP.NET Core 2.1.3 application. I've added the Serilog configuration to my appsettings.json file as follows:
"Serilog": {
    "MinimumLevel": "Debug",
    "WriteTo": [
      {
        "Name": "AzureTableStorageWithProperties",
        "Args": {
          "storageTableName": "logs",
          "connectionString": "MyConnectionString"
        }
      }
    ],
    "Enrich": [ "FromLogContext", "WithMachineName", "WithThreadId" ],
    "Properties": {
      "Application": "My App"
    }
}

And configured my logger in my Startup.cs - ConfigureServices() method class like so:
Log.Logger = new LoggerConfiguration().ReadFrom.Configuration(this.Configuration).CreateLogger();

The above configuration doesn't work - I get no logs in my Azure Table. If I change the sink to 'AzureTableStorage' it does work, but does not include the 'RequestId' column which is the one I'm after.
Does this sink fully support ASP.NET Core 2.1.3? Any ideas?
Thanks.

@Jaffacakes82 Is there any progress about this issue on ASP.NET CORE 2.1?

@Jaffacakes82 Is there any progress about this issue on ASP.NET CORE 2.1?

@ozkank I haven't heard anything back and didn't manage to get this working. I am using the configuration out of the box which seems to work but extending new fields didn't work.

I want to use same implementation. I need to store the log files on Azure tables. I'll be glad if you share your solution. Thanks.


Move SampleFormat check out of the main stream loop

Currently CPAL requires matching on an UnknownTypeBuffer enum upon every iteration of the audio loop, despite being able to query compatible sample formats prior to running the loop using Voice::format.
The beep example demonstrates how each format might be handled in this manner:
    loop {
        match channel.append_data(32768) {
            cpal::UnknownTypeBuffer::U16(mut buffer) => {
                for (sample, value) in buffer.chunks_mut(format.channels.len()).zip(&mut data_source) {
                    let value = ((value * 0.5 + 0.5) * std::u16::MAX as f32) as u16;
                    for out in sample.iter_mut() { *out = value; }
                }
            },

            cpal::UnknownTypeBuffer::I16(mut buffer) => {
                for (sample, value) in buffer.chunks_mut(format.channels.len()).zip(&mut data_source) {
                    let value = (value * std::i16::MAX as f32) as i16;
                    for out in sample.iter_mut() { *out = value; }
                }
            },

            cpal::UnknownTypeBuffer::F32(mut buffer) => {
                for (sample, value) in buffer.chunks_mut(format.channels.len()).zip(&mut data_source) {
                    for out in sample.iter_mut() { *out = value; }
                }
            },
        }

        channel.play();
    }

In any serious audio applications, the work contained in each branch would likely be required to be abstracted into some function, where the application either:

Does all its work in one format and then converts the final buffer to the stream's sample format or
Remains entirely generic over the sample type, using some Sample trait.

In either case, we likely end up using some generic function within the branching like so:
    loop {
        match channel.append_data(32768) {
            cpal::UnknownTypeBuffer::U16(mut buffer) =>
                fill_buffer_with_data::<u16>(&mut buffer, &mut data_source),
            cpal::UnknownTypeBuffer::I16(mut buffer) =>
                fill_buffer_with_data::<i16>(&mut buffer, &mut data_source),
            cpal::UnknownTypeBuffer::F32(mut buffer) =>
                fill_buffer_with_data::<f32>(&mut buffer, &mut data_source),
        }

        channel.play();
    }

Considering we already know whether or not certain formats are supported before we start the stream, we should be able to move this branching to occur before the stream even begins:
fn main() {
    let endpoint = cpal::get_default_endpoint().expect("Failed to get default endpoint");

    if run_stream::<f32>(&end_point, &mut data_source).is_ok() {}
    else if run_stream::<i32>(&end_point, &mut data_source).is_ok() {}
    else if run_stream::<i16>(&end_point, &mut data_source).is_ok() {}
    ...
    else {
        panic!("No compatible audio stream formats found for the device");
    }
}

This could of course be refactored to only try different sample formats if some specific UnsupportedFormat error is returned, or by iterating on the EndPoint's supported formats, matching on them and attempting to run the stream that way.
I'm curious to get your thoughts on this, as the current in-loop matching seems both unnecessary and to question whether the sample_format field in the Format struct yielded by endpoint.get_supported_formats_list() is useful at all?

This has become impossible to implement since the introduction of the EventLoop type, as all streams must now be handled within a single callback, and each stream might be of some different sample format depending on the device it is associated with. #278 may make this possible again, but some serious thought has to be put into how to achieve this while being able to support web audio APIs (see this comment).

I think I'll implement this sometime after the EventLoop deal, but one question is: is there a "default" format that we should expose? I think on most platforms you can choose arbitrary format, but if we need to provide "default" then it would be polymorphic, which doesn't play well with generic API design.

I'm currently looking into implementing this now that #354 has landed.
As a part of this change, I'm thinking about how to best approach the "callback" API for the new Device::build_input_stream/build_output_stream methods.
Rather than the current signature that looks like this:
FnMut(crate::StreamData) + Send + 'static

I'm imagining we could go with something like this.
Input:
FnMut(InputData<T>, &StreamInfo) + Send + 'static

Output:
FnMut(OutputData<T>, &StreamInfo) + Send + 'static

where the *Data type represents the audio data and StreamInfo provides access to other potentially useful information about the stream such as timing information or flags.
The reason I'm thinking we provide a type around the "data" is in case we decide to add support for non-interleaved data in the future. Currently on platforms that only support non-interleaved data (ASIO comes to mind, not sure if there are others) we do the conversion to interleaved behind the scenes, but I can imagine we might want to provide a more transparent API for this in the future.
As for StreamInfo, I might leave this out for now. I plan on looking into adding stream timing in a follow-up API - I might add the StreamInfo type then. I'm also open to better names for this type if anything comes to mind.

I wonder if it is also worth removing the data_type: SampleFormat field from the Format struct? The Format type is solely used to specify the desired format when calling build_input/output_stream, however with these changes the desired SampleFormat can be inferred from the sample type used within the user's data callback function.

On second thoughts, the Format type is also used to specify the default format via the Device::default_input/output_format methods.
One option would be to remove the data_type field and have the default_input/output_format return a (Format, SampleFormat)?
An alternative option might be to leave the Format type as is, and instead change the build_input/output_stream methods to take sample rate and number of channels as individual arguments.
Otherwise, we could just leave it as is and assert_eq!(format.data_type, T::FORMAT) at the beginning of each of the build_input/output_stream methods.


Importing a fligh-track into MSCOlab does not create a new version

After importing a flight track, it was not updated to MSColab. Changing a table view longitude coordinate updated then the full plan to the server.
Desired behaviour:
After import, a new version should be generated immediately.

Please provide more details
example_ftml_import.webm

OK, I had a closer look. The Version Window - in contrast to other View windows - is not automatically updated.
This is surprising and thus not Pythonic. :-)
Manually refreshing helps indeed.
Is there a design reason for this?

The default is to look on named versions, you need to toggle to All versions too.
To get this updated it requires to implement a handler which act on 'file-changed' (because any user can update), signal_reload.
It was not implemented because it does make on many edits the table flicker.
That should be covered by a  test too.

If there is a good reason against this update, no worries. But the current situation is confusing. We updated a file to something veery similar and had the apparently bad idea to have a look into the Version History if the import worked as intented instead of looking at the TableView, which would have worked?
I am not sure how  this is a performance problem. In particular if the VersionHistory is not open it should not have an effect?
However, I requalify this as a feature request.


Fix for incorrect values from CompositeByteBuf#component(int)

Motivation
This is a "simpler" alternative to #9416 which fixes the same CompositeByteBuf bugs described there, originally reported by @jingene in #9398.
Modifications

Add fields to Component class for the original buffer along with its adjustment, which may be different to the already-stored unwrapped buffer. Use it in appropriate places to ensure correctness and equivalent behaviour to that prior to the earlier optimizations
Add comments explaining purpose of each of the Component fields
Unwrap more kinds of buffers in newComponent method to extend scope of the existing indirection-reduction optimization
De-duplicate common buffer consolidation logic
Unit test for the original bug provided by @jingene

Result

Correct behaviour / fixed bugs
Some code deduplication / simplification
Unwrapping optimization applied to more types of buffers

The downside is increased mem footprint from the two new fields, and additional allocations in some specific cases, though those should be rare.
Co-authored-by: jingene<EMAIL_ADDRESS>

@netty-bot test this please

LGTM 👍

@netty-bot test this please

Thanks @franz1981 @jingene @normanmaurer, updated to address comments

@netty-bot test this please

@njhill @jingene thanks a lot!


Support for bare repo

Now we can use git_hooks inside bare repo.

If we were inside a bare repository, those paths would not work, since we are essentially inside the repo's .git folder. The directories would have to be inside the file tree of the repo to work, and the file tree doesn't exist in a bare repository (or at least, not in a form we can access).


Point lights and spot lights don't work on desktop

Never been able to get lights other than directional to actually work
https://user-images.githubusercontent.com/1667289/103274569-e6822b80-49b9-11eb-9b1a-3a78c714d13a.mp4

They work but you need to make sure their intensity and falloff radius are properly set.

This is unchanged, compiled directly off the github. If intensity and falloff radius need to be properly set then your lightbulb example is broken.

The sample works, what you are seeing is the fog that's enabled in this sample. When you are looking up at the object the camera is inside the fog. Maybe disabling the fog would make sense in this sample, it's probably a leftover from a test since this executable is mostly for internal testing.

You can use the "disco ball" mode to see a bunch of lights. Here are two examples in "disco ball" and "more lights" mode with a larger asset:

Note: a better test is gltf_viewer with a glTF file containing point/spot lights (like https://www.dropbox.com/s/uffti7xfl2m0bvw/bistro_gltf.zip?dl=0).

https://user-images.githubusercontent.com/1667289/103323323-491b0c00-4a3a-11eb-9cd6-bd7118059435.mp4
FEngine (64 bits) created at<PHONE_NUMBER>FBD080 (threading is enabled) FEngine resolved backend: OpenGL NVIDIA Corporation, GeForce RTX 2080 Ti/PCIe/SSE2, 4.1.0 NVIDIA 441.20, 4.10 NVIDIA via Cg compiler OS version: 0

https://github.com/google/filament/issues/1119 Same issue as this?

Pass -s to disable scene scaling, otherwise the scene is fit into a unit cube but the lights photometric units will be too bright with too large falloffs.

Disabling scene scaling just doesn't render lights at all. Fitting the scene in a x10 unit cube shows the lights but they still flicker.
https://user-images.githubusercontent.com/1667289/103323902-e5461280-4a3c-11eb-8dcc-3565142e0e58.mp4

Reopening because I'm able to reproduce this, but only on Windows. Investigating...

Maybe try playing with the -g option in matc, who knows! 🤣


BROOKLYN-286: docs for entity-config merging

LGTM, worth mentioning the special treatment of templateOptions for locations.

Thanks @neykov - I've added a section on templateOptions. Merging now.


Make ODL dir version indepedent

Currently, OpenDaylight's archive is (ether via the tarball or RPM install method) eventually put in /opt/opendaylight-0.2.2/. There are two critical problems with this:

It'd be a massive maintenance headache to update it every time a new version is released.
One major feature of the tarball install method is the ability to install any ODL version, including custom/pre-release builds (like Lithium weekly builds for the ODL+OpenStack CI effort I'm driving).

In the super long term, we may want to split up the ODL archive and store various parts in different file system locations per Linux conventions, but for now the most helpful/low-hanging TODO is just to make the ODL dir not include version info (so /opt/opendaylight/).
This will need to touch the ODL RPM as well.

Did this in 5b52b994eb7885e6ddb2e17c383ad016d7a6733e, 9a53fbdf60a7120190ded1701027e8ee7ec531e7 and 81d99d68d5ac5c686342e378529f33c0e5144cba. All main tests (bundle exec rake test, bundle exec rake centos, bundle exec rake centos_tarball) run and passing perfectly.


docs: update-configuration-file.mdx

What/Why/How?
Substantive edit of our current https://redocly.com/docs/cli/configuration/configuration-file/ page. Also consumes the https://redocly.com/docs/cli/guides/lint/ page content (page to be retired in a separate PR once this PR is approved).
Reference
Testing
Screenshots (optional)
Check yourself

[ ] Code is linted
[ ] Tested with redoc/reference-docs/workflows
[ ] All new/updated code is covered with tests

Security

[ ] Security impact of change has been considered
[ ] Code follows company security practices and guidelines

Hi team @adamaltman @JodyWinter, I've managed to carve out some time for open-source contributions :blush: so I'd like to try working on this project again. Before I go in, I'd just like to check if you need any feedback on this PR or is it considered stale at this point? Thanks!

@ivana-isadora I'm not sure about the current status of this PR. As you know, I stopped working on docs several months back, and I know that the configuration file is undergoing changes. Might be best for Adam to comment on this one.

This area has been refactored already and is stale, so I'll close this one.


Leverage SimpleThreadPool for improving importtable performance

Importtable reads the mappings.txt file (which in turn is created here) and renames files. The rename calls are done on a single calling thread, and thereby it does not bode well if there are large numbers (1000s) of files to be processed.
I believe it would help to implement a thread pool similar to what is in place for Bulk Import so that the operation scales.
Before going down that path, I would appreciate any inputs / feedback on this proposal, so that I can accordingly target my efforts.

You would need to be very careful to catch and propagate any exceptions from the renames in the executor, so that the FaTE operation fails properly, without leaving behind a bunch of threads, and without breaking any reproducibility or rollback problems.
Looking at the bulk import code you linked, it seems like it's trying to handle failures, so if that same design can be adopted here, it seems like it could be a good thing.
Another thing to consider is conflicting with the unfinished work in #1060 to ensure multi-volume support works for import table. I'm not sure what the status of that is.

FYI I'm starting to work on this, so if this issue can be assigned to me it would be appreciated.


Merge CSM-489 CSM-485 and CSM-491 to exchanges branch

Branch (& PR) to combine and test the following fixes:

[X] CSM-489 / PR #1729 keep the history cache as a map
[ ] CSM-491 / PR #1722 smaller acid-state DB tx logs
[ ] CSM-485 / PR #1726 further improvements to getHistory

These existing PRs need to be rebased on this branch (so on top of the history cache representation change). My recommendation is to merge in the order above. In particular #1722 also changes the DB transactions and that could be simplified slightly by merging next.
Then we need:

[ ] test DB migration works, ie test with a non-empty DB and non-empty DB tx log.
[ ] test that the epoch boundary bug is solved (ie CSM-489)
[ ] check overall getHistory performance improvements
[ ] test to make sure timestamps of transactions are stable, needed by deadalus UI and perhaps could be confusing for exchanges if this were off.

We can test between merging #1722 and #1726 or just at the end.

@dcoutts, you and @flyingleafe requested changes in #1722. Is the plan to wait for those changes before merging?

I think the main issue could be addressed as part of a rebase. The two other things are minor and just style points.


Old PRs on the Automation Runbook

Was working on updating the referenced AzureAutomation-Account-Modules-Update to support Managed Identities and noticed there are PRs over a year old. Is this repo still active?

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

ID: 55d92628-d657-759d-d301-06029cd61138
Version Independent ID: ca381b85-2be5-24af-be18-00c13a7e53df
Content: Update Azure PowerShell modules in Azure Automation
Content Source: articles/automation/automation-update-azure-modules.md
Service: automation
Sub-service: process-automation
GitHub Login: @MGoedtel
Microsoft Alias: magoedte

@JFolberth Thanks for your comment. We will review the issue and get back to you shortly.

@JFolberth  Apologies for late response. Can you please share which repository are you referring to ? As I could see there are no PR's related to automation service in the current repository.

It is in the repo the document refers to for automatically running module updates. https://github.com/microsoft/AzureAutomation-Account-Modules-Update

@JFolberth Thanks for sharing repository details. Yes, the repository is still active. You can submit PR's to this repository.
As there are no further documentation changes, we will close the issue for now. If there are further questions , please revert and we will be glad to assist you.


ansible-lint < 3.5 warning for 5.0.0

√ ceph-ansible % ansible-lint --version
ansible-lint 5.0.0
√ ceph-ansible %

√ ceph-ansible % ansible-lint -T
Added ANSIBLE_ROLES_PATH=roles
# List of tags and rules they cover
command-shell:  # Specific to use of command and shell modules
  - command-instead-of-module
  - command-instead-of-shell
  - deprecated-command-syntax
  - inline-env-var
  - no-changed-when
  - risky-shell-pipe
core:  # Related to internal implementation of the linter
  - internal-error
  - load-failure
  - parser-error
  - syntax-check
deprecations:  # Indicate use of features that are removed from Ansible
  - deprecated-bare-vars
  - deprecated-command-syntax
  - deprecated-local-action
  - deprecated-module
  - no-jinja-when
  - role-name
experimental:  # Newly introduced rules, by default triggering only warnings
  - risky-file-permissions
formatting:  # Related to code-style
  - no-jinja-nesting
  - no-tabs
  - playbook-extension
  - risky-octal
  - var-spacing
  - yaml
idempotency:  # Possible indication that consequent runs would produce different results
  - git-latest
  - hg-latest
  - no-changed-when
  - package-latest
idiom:  # Anti-pattern detected, likely to cause undesired behavior
  - command-instead-of-module
  - command-instead-of-shell
  - empty-string-compare
  - inline-env-var
  - literal-compare
  - missing-import
  - no-handler
  - no-loop-var-prefix
  - no-relative-paths
  - unnamed-task
metadata:  # Invalid metadata, likely related to galaxy, collections or roles
  - meta-incorrect
  - meta-no-info
  - meta-no-tags
  - meta-video-links
unpredictability:
  - partial-become
  - risky-file-permissions
yaml:  # External linter which will also produce its own rule codes.
  - yaml

The output from ansible-lint -T changed significantly, and the check for version number checks for a specific tag instead of the actual version number as reported by --version
https://github.com/ferhaty/linter-ansible/blob/ee10187b7f5dee24a2ad4f3e58e2157d2bf7f014/lib/main.js#L64-L74
Comparing ansible-lint 5.0.0 to 4.3.7 I see the "repeatability" checks are still there, but the tags themselves are handled significantly differently and I did not investigate further.


android notification not receive when app closed

Is there any way to make it happen ?

It should be already working. Would you share a push payload example?

I just found out that if running on android 8 (asus zen4) and Mi Pad 4 it not working but if I run it on emulator android 10 it’s working.
So, it might be os or phone model problem

Check if the OSs are set in a battery saving mode. This should not block, but lower push communication.

Thank you so much I will try it 😄


Bugfix/responsive

@cesar-tonnoir
Good day, mate!
This PR fix KPIs display on mobile, and avoid having too much blank space between the tabs and dashboard, also on mobile.
Cheers.
:wink:

@cesar-tonnoir Changed the nesting thing and rebuilt, ready to merge


Title elements contain a concise, descriptive title

Application's links all function correctly.

Application's CSS selectors and properties are consolidated and organized to follow semantic structure.

Application's CSS file is properly commented.


The evaluation results are very strange

I use the trained model to evaluate the score and the generated sentence is reasonable. But the score of BLEU is very strange. If anyone have ideas?

Have you solve the problem? I have also enchanted the same problem with you. Are you willing to talk about it with me? Looking forward to your reply. Thank you. You can contact me through my<EMAIL_ADDRESS>


Android: out of memory notification

When doing a simple project test for Android, opening the camera shows an out of memory error.
How can this be? This is easily reproduced by a simple sample app.
Tested on Android 8.1 on Pixel 2 XL.

Okay this is something absolutely new. Did this sample app have any other plugins? Do you have the stack trace?

As soon as I can reproduce this I will send stack trace and repo. Not happening in the sample project now (typical).

Let me try and reproduce.

I managed to get a screenshot!


Update quick_guide_maxwell.rst

To simplify: let's present only fields in matter and also order them so that they are:
Faraday
Ampere-Maxwell
Gauss (magnetic)
Gauss (electric)

@dccowan: can you touch-base with @dougoldenburg if you have questions on the intended changes here?

Redundant eqs in a vacuum have been removed.
Improved description of variables for each set of maxwell's equations.
Found and fixed typos and grammatical issues.
Added necessary hyperlinks and citations.


Add Emoji Reactions to Updates

Related to https://github.com/opencollective/opencollective/issues/4185
Related Front End PR: https://github.com/opencollective/opencollective-frontend/pull/6523

That looks awesome! Some feedback below, but it's mostly cosmetic; the code itself seems robust.

Thanks much. 😄


Update themes.css

Screenshot of my A11y card:
For assistance: https://help.github.com/en/articles/file-attachments-on-issues-and-pull-requests

Hi!
I see that you've added a theme to the CSS file, however didn't add the theme to the ThemePicker.vue file.
If you need assistance with how to make this addition, you can find a walk-through here: https://dev.to/tvanblargan/make-your-first-pull-request-3iai

Hi! This is a great start, but currently doesn't pass the WCAG requirements to be accessible.
If you could adjust the colors so that the A11y card displays "AA" or "AAA" compliant for each of the 3 lines, we can merge it in.


GA request for signalfx / splunk-otel-js

Which GDI repository do you wish to GA?
https://github.com/signalfx/splunk-otel-js
Does the repository follow the latest tagged minor release in GDI specification?
Yes, except:

referenced OTel JS is still in beta

How long has the GDI repository been public?
Since around March 2021.
Is the repository known to be used today?
Yes, couple hundred downloads per week via NPM.
Is there a date by which this approval is needed?
No.
Additional context
Nope.

And the latest release to check all the boxes in gdi-specification: https://github.com/signalfx/splunk-otel-js/releases/tag/v0.12.0

Configuration
Reviewing: https://github.com/signalfx/splunk-otel-js/blob/326819403700d2d30ffde47df072d489c9109b28/docs/advanced-config.md
Specs: https://github.com/signalfx/gdi-specification/blob/v1.0.0/specification/configuration.md
It would be good if the format stays very similar across different languages/ecosystems. See these for reference:

https://github.com/signalfx/splunk-otel-java/blob/main/docs/advanced-config.md
https://github.com/signalfx/splunk-otel-python/blob/main/docs/advanced-config.md

One or more configuration variables MAY be needed to properly configure GDI
repositories. Configuration of these variables MUST be supported by environment
variables and MAY be supported by additional methods. GDI repositories MUST adopt
stable and SHOULD adopt experimental configuration variables in the
OpenTelemetry
Specification
before proposing variables to the GDI specification. If a new configuration
variable is needed by a GDI repository it MUST be brought to the GDI specification
as a GitHub issue. The GDI specification maintainers SHOULD consider
introducing needed configuration variables to the OpenTelemetry repository before
approving Splunk-specific configuration variables.

❌ "Support" column missing to indicate if the configuration is stable or experimental.
❌  SPLUNK_MAX_ATTR_LENGTH - should we not support OTEL_ATTRIBUTE_VALUE_LENGTH_LIMIT which is defined by the OTel specification?
❌ SPLUNK_LOGS_INJECTION - the configuration is not brought to the GDI specification as a GitHub issue. is it proposed to OpenTelemetry specification?

If a GDI repository requires an immediate configuration variable that is not
available in the OpenTelemetry specification and not available in the GDI
specification, the repository MAY introduce a repository-specific configuration
variable until the GDI specification maintainers make a decision. Any
repository-specific configuration variable defined SHOULD be prefixed with
SPLUNK_ and MUST NOT be marked as stable unless added to the GDI
specification. Upon resolution by the GDI specification, the GDI repository MUST
change the repository-specific configuration variable by the repository's next minor
release. This change MAY result in a breaking change so caution should be
exhibited when considering repository-specific configuration variables.

Splunk-specific configuration variables defined in the GDI specification MUST
be prefixed with SPLUNK_. If a Splunk-specific configuration variable is
declared as stable in the GDI specification and later the OpenTelemetry
specification declares a similar variable as stable, the GDI specification
MUST adopt the OpenTelemetry configuration variable and SHOULD mark the GDI
specification configuration variable as deprecated by the next minor release.
In addition to defining Splunk-specification configuration variables, the GDI
specification MAY require specific OpenTelemetry configuration variables be
supported. If it does, the GDI specification MAY require certain values be
supported including a specific default value.

Whenever a configuration variable changes its name, a stable GDI repository
(version >= 1.0) MUST support both old and new names until the next major
release is done. The old configuration variable MUST NOT be removed in a minor
release. GDI repositories that are not yet stable (version < 1.0) SHOULD follow
this rule, but they are not required to. When it is detected that a user uses
the old configuration variable a warning SHOULD be logged: the warning SHOULD
state that the old variable is deprecated, the new one should be used instead,
and that the old one will be removed in the next major release (not stable GDI
repositories MAY remove deprecated features in any future release).

⚠  SPLUNK_LOGS_INJECTION is not defined in GDI specification

Installation and configuration MUST optimize for customer experience and
time-to-value. Installation and configuration MAY provide a mechanism for
advanced or custom settings. As an example, the default installation for
instrumentation libraries should provide everything needed to configure W3C and
B3 as well as OTLP and Jaeger Thrift even though the default configuration is
set to W3C and OTLP. Installing all of these dependencies by default may result
in a large package, but makes it easy for users to switch settings via
configuration. An advanced installation process can be provided where the user
chooses what to install limiting the configuration options.

⚠ You may consider having similar Advanced configuration section in the README.md like Java and Python distros. A similar structure makes life easier for the reader.
Environment variables

Name (default value)
Description

SPLUNK_ACCESS_TOKEN ()
Access token added to exported data. [1]

SPLUNK_TRACE_RESPONSE_HEADER_ENABLED (true)
Whether Server-Timing header is added to HTTP responses. [2]

[1]: Not user required if another system performs the authentication. For
example, instrumentation libraries SHOULD send data to a locally running
agent. The agent MAY define the access token that is used. If the
instrumentation library is configured to send data directly to a Splunk
back-end then this variable MUST be defined. Even when sending to an agent,
instrumentation libraries MAY define this option (to support
access_token_passthrough).
This environment variable MUST work for otlp and jaeger-thrift-splunk
exporters.
[2]: If stitching of RUM spans and APM spans is desired then this parameter
MUST be set to true.

⚠  Regarding the SPLUNK_ACCESS_TOKEN description: "SignalFx API" - I think it would be better to replace with "Splunk cloud". Consider taking the description from Java or Python distribution docs.
⚠ SPLUNK_TRACE_RESPONSE_HEADER_ENABLED while the description is OK. I prefer the one used in Java and Python distribution docs.
I will make a PR in GDI specification to use the description from the distributions.

In addition to Splunk-specific environment variables, several requirements
beyond the OpenTelemetry specification exist.
OpenTelemetry Environment Variable

OTEL_RESOURCE_ATTRIBUTES

User MUST define service.name
resource attribute.
Distribution MUST log a warning when the service.name resource attribute is not set. The
warning message MUST clearly describe how to set the attribute or link to relevant documentation.
E.g.service.name attribute is not set, your service is unnamed and will be difficult to identify.
set your service name using the OTEL_RESOURCE_ATTRIBUTES environment variable.
E.g. `OTEL_RESOURCE_ATTRIBUTES="service.name=<YOUR_SERVICE_NAME_HERE>"`

User SHOULD define deployment.environment
resource attribute.
User SHOULD define service.version

OTEL_PROPAGATORS

Distribution MUST default to "tracecontext,baggage"
Distribution MUST support and document how to switch to b3multi

Span Collection Limits

Distribution MUST default to 1000 for OTEL_SPAN_LINK_COUNT_LIMIT (not OpenTelemetry default)
Distribution MUST be unset (unlimited) for all others (not OpenTelemetry default)

Zipkin exporter

Distribution MUST NOT list Zipkin exporter as supported (not supported by Smart Agent)

OTEL_TRACES_EXPORTER

Distribution MUST default to otlp
Distribution MUST offer jaeger-thrift-splunk that defaults to http://<IP_ADDRESS>:9080/v1/trace

❓ Is this done? Distribution MUST log a warning when the service.name resource attribute is not set. The warning message MUST clearly describe how to set the attribute or link to relevant documentation.
❓ What about: Distribution MUST default to 1000 for OTEL_SPAN_LINK_COUNT_LIMIT (not OpenTelemetry default)?

Legend:
❓ questions
❌ does not meet the GDI specs
⚠ remarks are not breaking GDI specs, however they may be worth addressing

The SPLUNK_LOGS_INJECTION env var is a remnant of the SFX lib. However it now only controls service name, environment and version injection as trace_id and span_id are injected via the logging instrumentations themselves. Rauno already pointed this out and think we can either get rid of it or move it to advanced configuration while enabling it by default.

Yes. We're in the process of removing those.

Please see: https://github.com/signalfx/splunk-otel-js/pull/294 — docs are being modified there.

OTEL_TRACES_EXPORTER

Distribution MUST default to otlp

@flands @MrAlias Splunk OTel Java and Python are using the grpc protocol. Splunk OTel JS is currently using http/protobuf. Is it OK? The specification does not define which one should be used https://github.com/signalfx/gdi-specification/issues/131. My concern is that having different default settings may confuse the users.

We should default to gRPC -- opened: #132

Logs injection is done here: https://github.com/signalfx/splunk-otel-js/pull/312

PR still not merged in OTel.

It is now.

Once https://github.com/open-telemetry/opentelemetry-js/pull/2626 is merged an released version 0.27 of the exporter will be released as 1.0 as well and we can bump the version among our deps as well.
@MrAlias, @pellared, how can we proceed?

US people are off till Jan 3, and Robert isn't working on GA reviews anymore I think. I'll keep pinging Steve and Michał about this.

Repository

Teams

MUST have a maintainers team and teams MAY be shared between repositories

MUST have -maintainers suffix
MUST include at least two currently full-time Splunkers
MUST NOT include any non-full-time Splunkers

SHOULD have an approvers team and teams MAY be shared between repositories

MUST have -approvers suffix

Verified: https://github.com/orgs/signalfx/teams/gdi-js-approvers, https://github.com/orgs/signalfx/teams/gdi-js-maintainers

Permissions

MUST grant Admin permission
level
to admins team
MUST grant Maintain permission
level
to maintainers team
MUST grant Write permission
level
to approvers team and the signalfx/docs, signalfx/gdi-specification-approvers and signalfx/gdi-specification-maintainers teams
MUST NOT grant Write, Maintain, Admin permission
level
to any other user nor team
MUST NOT grant any permission (including Read) to any individual

Branch protection

MUST have a primary branch named main
MUST NOT allow anyone (including administrators) pushing directly to main
MUST require status checks to pass before merge to main
MUST require at least one CODEOWNER to approve a PR prior to merge
MUST require signed commits on main
MUST NOT allow merge commit (squash or rebase merging only)

I do not have access to these settings (permissions or branch protection). @flands can you please verify?

Dependencies

MUST lock the versions of all build dependencies (e.g. libraries, binaries,
scripts, docker images) or vendor them; EXCEPTION: tools that are
available out-of-the-box

Verified: package-lock.json

MUST have Dependabot configured

Verified: dependabot.yml

GitHub Actions

MUST use GitHub
secrets to
store sensitive data (auth tokens, passwords) and limit their usage to only
required places
MUST NOT use Personal Access
Tokens
MUST limit permissions of
GITHUB_TOKEN
when used

MUST set the repository's default permission
to just read access for the contents scope.
MUST only set the absolutely required permissions (least privilege)
MUST set permissions for individual jobs

I do not have access to these settings. @flands can you please verify?

GitHub Applications

MUST have Jira GitHub App configured

@jtmal-signalfx or @Rauno56 can you verify and post confirmation of this?

SHOULD have Codecov GitHub App configured

:warning: I think it is configured here? @jtmal-signalfx  or @Rauno56 can you verify this?

SHOULD have Lychee Link Checker GitHub Action configured

:x: This does not look configured.

Required Files

MUST have a CHANGELOG.md updated for every release

The CHANGELOG.md is intended to be consumed by humans, and not machines.
The file SHOULD contain an Unreleased section at the top, which includes changes that
have not yet been released.
The file MUST be in reverse chronological order, with the most recent
releases at the top of the file, after the Unreleased section.
Each release SHOULD be separated by a line separator (---) from the other relases.
Each release SHOULD contain separate sections for each major functionality area (if applicable).
The following sub-sections MAY be used, as appropriate or specified.

General - General comments about the release that users should know about.
Breaking Changes - Any changes that will break backward compatibility
with previous versions. MUST list all breaking changes.
Bugfixes - Details of bugs that were fixed. SHOULD list all bug fixes.
Enhancements - New features that have been added to the repository. SHOULD
list all new features.

The CHANGELOG.md SHOULD NOT list every PR, but only changes significant
from an end-user point of view. Anyone who is interested in all the details
of every change in the repository can use the git log for that.

MUST have a badge on the README.md with GDI specification version supported
SHOULD have a badge on the README.md with code coverage, if appropriate.
SHOULD have badges on the README.md for other relevant things including artifacts
MUST have getting started information in README.md
MUST have troubleshooting information in README.md
MUST link to official Splunk docs in README.md
MUST have license information in README.md

:x: Missing "badge on the README.md with GDI specification version"
Otherwise verified: README.md

MAY have a RELEASING.md file that documents the release process, but this
file MUST NOT document private processes. For repositories that use private release
jobs, the RELEASING.md file SHOULD be absent or, if included, just contain the following note:

The release process involves signing built packages and binaries and thus
must be kept private and not exposed publicly.

Verified: RELEASING.md

MUST add the SECURITY.md

SHOULD add dependabot information to SECURITY.md if applicable

Verified: SECURITY.md

SHOULD NOT contain comprehensive application examples. Application examples
showing multi-system interactions or even cross-language use cases SHOULD be
put in the Splunk OpenTelemetry example
repository.
Smaller, developer focused, examples MAY be included in the repository if it
is customary to do so for the coding language used.

IDK, looks fine to me: https://github.com/signalfx/splunk-otel-js/tree/v0.15.0/examples

GitHub Releases

MUST have a signature or a checksum with signature for all release artifacts

SHOULD use Splunk signing key

Looks to be the case for all current published releases (i.e. https://github.com/signalfx/splunk-otel-js/releases/download/v0.15.0/checksums.txt)

MUST use signed tags

:x: Many releases do not use signed tags. These need to be recreated.

MUST state version of OpenTelemetry repository built against if applicable

Verified.

MUST update all examples in the Splunk OpenTelemetry example
repository
that depends on the repository to use the latest release.

n/a

Instrumentation Libraries

MUST document all supported configuration parameters

Verified: https://github.com/signalfx/splunk-otel-js/blob/v0.15.0/docs/advanced-config.md#list-of-settings

MUST document how to configure manual instrumentation

Verified: https://github.com/signalfx/splunk-otel-js#manually-instrument-an-application

MUST document how to configure log correlation

Verified: https://github.com/signalfx/splunk-otel-js#correlate-traces-and-logs

MUST define minimum supported version of each auto-instrumentation framework

SHOULD define maximum supported version of each auto-instrumentation framework

:x: This does not seem to be satisfied: https://github.com/signalfx/splunk-otel-js#default-instrumentation-packages
@jtmal-signalfx or @Rauno56 can you please double check this requirement and point me to docs that satisfy this if I missed them?

Semantic Conventions

OpenTelemetry Resource Attributes
Description: Required and recommended OpenTelemetry resource semantic
conventions.
All Splunk distributions of OpenTelemetry,

MUST set the following OpenTelemetry resource attributes according to the
OpenTelemetry Semantic
Conventions:

telemetry.sdk.name
telemetry.sdk.version
telemetry.sdk.language

SHOULD set the following resource attributes when applicable:

telemetry.auto.version

Note: this section does not apply to Real User Monitoring libraries, as they do
not use the OpenTelemetry Resource.

@jtmal-signalfx or @Rauno56 can you verify this is satisfied? I do not have enough familiarity with the JS implementation to do so.

Splunk Resource Attributes
Description: Set of attributes used to uniquely identify a Splunk distro
version in combination with OpenTelemetry's telemetry.sdk.* attributes.

Attribute
Type
Description
Examples
Required

splunk.distro.version
string
The version number of the Splunk distribution being used.
1.5.0
Yes

Note: this section does not apply to Real User Monitoring libraries, as they do
not use the OpenTelemetry Resource.

:x: A search of the repository did not return an implementation of this. @jtmal-signalfx or @Rauno56 can you verify this is satisfied or needs to be added?

To be sure, the profiling capabilities are not being included here because they do not look to be ready for a stable release. @Rauno56 or @jtmal-signalfx can you verify the plan is to not include profiling in the stable release?

Versioning

All GDI repositories MUST be versioned according to Semantic Versioning
2.0. GDI repositories are versioned
separately from OpenTelemetry repositories as Splunk-specific breaking changes
MAY be introduced. GDI repositories MUST indicate what version of OpenTelemetry
repositories they are based on through release notes and SHOULD indicate through
logging. Additional version number constraints can be found in the sections
below.

Verified.

@MrAlias, thanks for the reveiw. I collected your comments in the following list:

[ ] GitHub Actions - MUST have Jira GitHub App configured
[ ] SHOULD have Codecov GitHub App configured - your comment about that is correct. The library has recently been deprecated though.
[ ] SHOULD have Lychee Link Checker GitHub Action configured
[ ] Missing "badge on the README.md with GDI specification version"
[ ] Many releases do not use signed tags. These need to be recreated.
[ ] MUST set the OpenTelemetry resource attributes telemetry.*
[ ] Set splunk.distro.version resource attribute

@MrAlias, what comes to releases, since they're old ones and no one in the node ecosystem uses GH Releases for any authority I'll skip redoing the releases.
I would kindly ask someone(@iNikem / @flands ?) with permission to

Enable Require signed commits if it's not already.
Check whether the Jira GH App is configured - I don't have the access to the settings page and don't know how to check it otherwise. I don't know how this app would be useful though.

I checked and "Require signed commits" is correctly set
I checked and the Jira GH app is configured

Cool! Then we're all set.

Cool! Then we're all set.

Agreed! :tada:
Closing with the conclusion that this is complete, the JS distribution is ready for GA!


Duplicating project not working properly

When duplicating a project with all parts of the project, all tasks from the original project end up in the first column/backlog and not in the same column as in the original project.
Version: 1.0.18.

There seem to be an issue with the swimlanes as well. All tasks are duplicated into one swimlane.

I just changed that in the development branch. Now, duplicated tasks will be copied in the same column.
Thanks.


⚠ PrivateHD has degraded performance

In d1e17a9, PrivateHD ($PHD) experienced degraded performance:

HTTP code: 200
Response time: 5336 ms

Resolved: PrivateHD performance has improved in dda837a.


[TypeSpecValidation] Validates all folders under cognitiveservices

TSV is running on all the specs under "specification/cognitiveservices", even though only one folder under here was changed in the PR as shown here:
https://github.com/Azure/azure-rest-api-specs/pull/23965
https://dev.azure.com/azure-sdk/internal/_build/results?buildId=2772420&view=logs&j=33174e5f-e491-5dfc-305d-c09df824202b&t=0f377f82-3711-5097-078f-1ce87e974d2b

it's by design in the new TSV


Failed to start Aries Toolbox on Windows

I'm running Aries Toolbox on Windows (10, git-bash) and received this error on the console and in the Aries Toolbox window.  Any ideas?
I've recently run it with the same commands on Linux.
 ERROR in Template execution failed: ReferenceError: process is not defined

  ERROR in   ReferenceError: process is not defined

    - index.ejs:11 eval
      [.]/[html-webpack-plugin]/lib/loader.js!./src/index.ejs:11:2

    - index.ejs:16 module.exports
      [.]/[html-webpack-plugin]/lib/loader.js!./src/index.ejs:16:3

    - index.js:284
      [aries-toolbox]/[html-webpack-plugin]/index.js:284:18

    - runMicrotasks

    - task_queues.js:97 processTicksAndRejections
      internal/process/task_queues.js:97:5

Commands run:
git clone https://github.com/hyperledger/aries-toolbox
cd aries-toolbox
npm i
npm run dev

$ npm --version
6.13.6
$ node --version
v13.7.0

Tried this solution and it seemed to at least get the main window started. However, I don't know enough about why this would work vs. what was already there (which was a different solution):
https://github.com/SimulatedGREG/electron-vue/issues/871#issuecomment-574627835
Notably, I changed this part of src/index.eps to the following:
<!-- Set `__static` path to static files in production -->
<% if (!htmlWebpackPlugin.options.isBrowser && !htmlWebpackPlugin.options.isDevelopment) { %>
    <script>
      window.__static = require('path').join(__dirname, '/static').replace(/\\/g, '\\\\')
    </script>
<% } %>

<!-- webpack builds are automatically injected -->

Unfortunately, I can't go further right now as I would have to do a lot of system updates to continue. I'll try to get a Windows and Mac person to try this out.

I also noticed this warning on the Windows operation:
npm WARN optional SKIPPING OPTIONAL DEPENDENCY<EMAIL_ADDRESS>(node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for<EMAIL_ADDRESS>wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

Not sure what the impact of not having fsevents available affects the operation of the app.

@TelegramSam have you run the toolbox on windows recently?

@burdettadam was this the error you were seeing that required your fix in #143?

Changing Confirmed that fix worked for bringing up the main window on Windows 10.
I'll open another issue if the fsevents() thing is a big issue.
Thanks.


Token expiration while annotating files synced with a s3 bucket

Describe the bug
Hi,
We have been dealing with a bug that throwing us 403 - Forbidden Error when we click on a file in a project. But the same file, you can open it some time later or if you refresh the browser. This keeps happening randomly over all the files in different projects, or happens immediately after submitting/updating any annotation. These files are all synced with a s3 bucket. Our understanding is, there is a token generation happening in the backend, but this token expires while doing annotations. We tried to change the "Expiration Minutes", but whatever number you put there and save, it returns to 1 automatically. It just ignores the value you set.
To Reproduce
Steps to reproduce the behavior:
I don't know how you can reproduce this error. It just happens when sync your project, which contains txt files, with a s3 bucket, and it happens with no obvious pattern. Same file can both work without any issue and with this issue at different times
Expected behavior
Don't expect to see this error when we click on the file, especially when we are sure that file actually works fine at different times
Screen

shots
Environment (please complete the following information):

Labelstudio app
Label Studio Version 1.7.2

Additional context
Add any other context about the problem here.

Could you try doing this:

remove your current source storage
add new one and specify Expiration minutes since the beginning
try using LS and check whether you register this error or not?


Upgrading to bevy 0.15

Do you have any plans to upgrade quill to use bevy 0.15? I see you have bunch of other bevy ui experiments ongoing so understandable if not.
I had a quick look and just getting a quick port done doesn't look too bad, mainly changes in stylebuilder as Style is no more and then bevy_{mod,}_picking changes.
The complexities that GhostNodes would solve I don't fully understand but should not be a blocker to get something working with 0.15.

That's a great question. I've thought about doing this, but as you mentioned I have been focused on other things.
I have one project that uses Quill, and I plan to eventually migrate it to a different UI framework. This work would be easier if Quill could work in bevy 0.15, since it means I wouldn't have to migrate everything all at once.
Migrating Style shouldn't be all that hard, the more challenging part is migrating off of bevy_mod_picking.

I just discovered this library. It looks awesome, and its clear a lot of work has already been invested, but I don't know how to interpret this last message from @viridia. Is this library effectively no longer maintained / future updates not planned?

I've been in discussions with cart about the best way to move forward on reactivity.
My original motivation for creating this was to fill in the missing holes in the BSN (Bevy Scene Notation) design doc - that is, to prototype potential solutions for reactivity in Bevy that could eventually be incorporated into BSN. To this end, I ended up exploring a bunch of different approaches - in fact I started from scratch about 8 times, producing guise, quill v1, bevy_reactor v1, quill v2, bevy_reactor v2, and finally thorium_ui. Each of these different tries is substantially different in architecture:

Quill is a coarse-grained (like React and Dioxus) reactivity solution. It is the only framework that actually has a published crate, the others are simply github repos.
Bevy_reactor is a fine-grained (like Solid and Leptos) reactivity solution.
Thorium is a much leaner version of Bevy reactor that gets rid of explicit tracking scopes, relying on memoization rather than bevy change detection.

Quill's biggest drawback is that it requires Rust nightly.
Bevy_reactor's biggest drawback is that it's not very ECS-like, and requires you to learn an entirely different API for accessing data in the Bevy world.
Thorium provides an API which is very much like ECS systems, supporting dependency injection. However, certain performance optimizations in bevy_reactor are not possible in this simpler system, whether these optimizations are significant is yet to be determined.
My eventual goal is not to be the maintainer of my own library, but rather to have the best of these ideas incorporated into Bevy itself. On this front, there is progress, and there's been slow but steady movement towards a solution and agreement on general approach.

With the patches that has landed on main I've been able to move my (toy) project over to bevy 0.15 now. I'm not using the obsidian crates but those should be easy enough to get working as well.
Until bevy has BSN with a good reactivity story it would be great to keep quill going. Out of the different options I looked at I liked quill the best, maybe because it reminded me a bit of React.


Unable to set stream resource to non-blocking mode [not STDIN or STDOUT]

I was able to reproduce the following error in several Windows machines: when trying to read a text file using ReadableResourceStream I receive RuntimeException: Unable to set stream resource to non-blocking mode.
Here is an example code:
<?php

use React\EventLoop\Factory;
use React\Stream\ReadableResourceStream;

require_once 'vendor/autoload.php';

$loop = Factory::create();

$arquivo = fopen('existing_file.txt', 'r+');
$stream = new ReadableResourceStream($arquivo, $loop);

$stream->on('data', function (string $data) {
    echo $data;
});

$loop->run();

And here is the full output:
PHP Fatal error:  Uncaught RuntimeException: Unable to set stream resource to non-blocking mode in C:\Users\carlo\OneDrive\Documentos\reactphp-windows\vendor\react\stream\src\ReadableResourceStream.php:58
Stack trace:
#0 C:\Users\carlo\OneDrive\Documentos\reactphp-windows\index.php(11): React\Stream\ReadableResourceStream->__construct(Resource id #17, Object(React\EventLoop\StreamSelectLoop))
#1 {main}
  thrown in C:\Users\carlo\OneDrive\Documentos\reactphp-windows\vendor\react\stream\src\ReadableResourceStream.php on line 58

Fatal error: Uncaught RuntimeException: Unable to set stream resource to non-blocking mode in C:\Users\carlo\OneDrive\Documentos\reactphp-windows\vendor\react\stream\src\ReadableResourceStream.php on line 58

RuntimeException: Unable to set stream resource to non-blocking mode in C:\Users\carlo\OneDrive\Documentos\reactphp-windows\vendor\react\stream\src\ReadableResourceStream.php on line 58

Call Stack:
    0.0002     393608   1. {main}() C:\Users\carlo\OneDrive\Documentos\reactphp-windows\index.php:0
    0.0046     612240   2. React\Stream\ReadableResourceStream->__construct($stream = resource(17) of type (stream), $loop = class React\EventLoop\StreamSelectLoop { private $futureTickQueue = class React\EventLoop\Tick\FutureTickQueue { private $queue = class SplQueue { ... } }; private $timers = class React\EventLoop\Timer\Timers { private $time = NULL; private $timers = [...]; private $schedule = [...]; private $sorted = TRUE; private $useHighResolution = TRUE }; private $readStreams = []; private $readListeners = []; private $writeStreams = []; private $writeListeners = []; private $running = NULL; private $pcntl = FALSE; private $pcntlPoll = FALSE; private $signals = class React\EventLoop\SignalsHandler { private $signals = [...] } }, $readChunkSize = ???) C:\Users\carlo\OneDrive\Documentos\reactphp-windows\index.php:11

System info:

Windows 11
PHP 8.1.5
react/event-loop version: v1.3.0
react/stream version: v1.2.0

Hey @CViniciusSDias, thanks for all the input :+1:
When it comes to working with the filesystem it gets a bit tricky. The problem is that the filesystem is inherently blocking, so we have no choice to be blocking as well (fopen() is also blocking).
It is described inside the documentation that when you try to give something blocking into the ReadableResourceStream class, it tries to enable non-blocking mode on the stream resource which is not supported under Windows and will throw a RuntimeException.
As you can see we're aware of this behavior. If you want, you can get rid of the RuntimeException inside your project, but we can't do that inside our reactphp/stream component. You can also try the same under another operating system or take a look a the reactphp/filesystem (still experimental).
Maybe a non async approach is the way to go here, even if it's blocking, in most cases it might be fast enough.
I hope this helps.

The documentation states that

this is not supported by pipes on Windows (STDIN etc.)

But what I am trying to open is not a pipe. It's a regular file. Is that also not supported?

Beware not to take this sentence out of context. The full section of the documentation states:

Internally, this class tries to enable non-blocking mode on the stream resource which may not be supported for all stream resources. Most notably, this is not supported by pipes on Windows (STDIN etc.). If this fails, it will throw a RuntimeException:

We know this is not supported by pipes on Windows and your use case doesn't appear to be supported either. When it comes to working with the filesystem in combination with streams, the documentation also says this inside the usage chapter:

Note that this example uses fopen() for illustration purposes only. This should not be used in a truly async program because the filesystem is inherently blocking and each call could potentially take several seconds. See also creating streams for more sophisticated examples.

I hope this clears things up 👍

@SimonFrings , actually that was not very clear but while I was writing an example of non-blocking code that runs on Windows I saw the note on PHP's documentation:

On Windows, this has no affect on local files. Non-blocking IO for local files is not supported on Windows.

So yes, now I understand the behavior. Thank you for replying. :-D

I believe this has been answered, so I'm closing this for now. Please come back with more details if this problem persists and we can always reopen this :+1:


Crash after implementing shader stuff

Hi, after i implemented the following mods (check screenshot) i got this error:
crash-2023-08-20_11.51.38-client.txt

Update to 1.0.5.

Thanks for the fast help and reply. :)


Fix scrollbar on galleryview when there are no images

thumbnail images now cover
fix to 'load more' breaking when deleting images
@assertchris

Added styles specific to the insert-media dialog based on https://github.com/open-sausages/silverstripe-framework/tree/insert-media-gallery

Rebased @assertchris