HBASE-27998 Enhance region metrics to include prefetch ratio for each…

… region

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+0 :ok:
prototool
0m  0s
prototool was not available.

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

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

_ HBASE-27389 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 45s
HBASE-27389 passed

+1 :green_heart:
compile
3m 34s
HBASE-27389 passed

+1 :green_heart:
checkstyle
0m 52s
HBASE-27389 passed

+1 :green_heart:
spotless
0m 42s
branch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
4m  8s
HBASE-27389 passed

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 27s
the patch passed

+1 :green_heart:
compile
3m 30s
the patch passed

+1 :green_heart:
cc
3m 30s
the patch passed

+1 :green_heart:
javac
3m 30s
the patch passed

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

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

+1 :green_heart:
hadoopcheck
9m 30s
Patch does not cause any errors with Hadoop 3.2.4 3.3.5.

+1 :green_heart:
hbaseprotoc
1m 13s
the patch passed

+1 :green_heart:
spotless
0m 39s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
4m 31s
the patch passed

_ Other Tests _

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

42m 22s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile cc hbaseprotoc prototool

uname
Linux aef0902bf807 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27389 / 3a2333e6b5

Default Java
Eclipse Adoptium-11.0.17+8

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

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

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

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ HBASE-27389 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 26s
HBASE-27389 passed

+1 :green_heart:
compile
1m 17s
HBASE-27389 passed

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

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

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 12s
the patch passed

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

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

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 24s
hbase-protocol-shaded in the patch passed.

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

-1 :x:
unit
224m 18s
hbase-server in the patch failed.

249m 41s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 88a54a1b4b57 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27389 / 3a2333e6b5

Default Java
Temurin-1.8.0_352-b08

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/1/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

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

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ HBASE-27389 Compile Tests _

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

+1 :green_heart:
mvninstall
3m 15s
HBASE-27389 passed

+1 :green_heart:
compile
1m 50s
HBASE-27389 passed

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

+1 :green_heart:
javadoc
0m 53s
HBASE-27389 passed

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 35s
the patch passed

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

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

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 39s
hbase-protocol-shaded in the patch passed.

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

-1 :x:
unit
228m 58s
hbase-server in the patch failed.

258m 27s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux a08ccf42e7d3 5.4.0-152-generic #169-Ubuntu SMP Tue Jun 6 22:23:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27389 / 3a2333e6b5

Default Java
Eclipse Adoptium-11.0.17+8

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/1/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

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

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+0 :ok:
prototool
0m  0s
prototool was not available.

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

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

_ HBASE-27389 Compile Tests _

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

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

+1 :green_heart:
compile
5m  6s
HBASE-27389 passed

+1 :green_heart:
checkstyle
1m 14s
HBASE-27389 passed

-1 :x:
spotless
0m 55s
branch has 65 errors when running spotless:check, run spotless:apply to fix.

+1 :green_heart:
spotbugs
6m 35s
HBASE-27389 passed

_ Patch Compile Tests _

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

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

+1 :green_heart:
compile
5m 32s
the patch passed

+1 :green_heart:
cc
5m 32s
the patch passed

+1 :green_heart:
javac
5m 32s
the patch passed

+1 :green_heart:
checkstyle
0m  8s
The patch passed checkstyle in hbase-protocol-shaded

+1 :green_heart:
checkstyle
0m 17s
The patch passed checkstyle in hbase-client

+1 :green_heart:
checkstyle
0m 41s
hbase-server: The patch generated 0 new + 17 unchanged - 3 fixed = 17 total (was 20)

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

+1 :green_heart:
hadoopcheck
12m  8s
Patch does not cause any errors with Hadoop 3.2.4 3.3.5.

+1 :green_heart:
hbaseprotoc
1m 20s
the patch passed

+1 :green_heart:
spotless
0m 42s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
4m 52s
the patch passed

_ Other Tests _

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

55m  5s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile cc hbaseprotoc prototool

uname
Linux 751c70b030fa 5.4.0-156-generic #173-Ubuntu SMP Tue Jul 11 07:25:22 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27389 / 2469aca027

Default Java
Eclipse Adoptium-11.0.17+8

spotless
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/2/artifact/yetus-general-check/output/branch-spotless.txt

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

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

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

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.3

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ HBASE-27389 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 13s
HBASE-27389 passed

+1 :green_heart:
compile
1m 17s
HBASE-27389 passed

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

+1 :green_heart:
javadoc
0m 41s
HBASE-27389 passed

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 14s
the patch passed

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

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

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 26s
hbase-protocol-shaded in the patch passed.

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

-1 :x:
unit
231m 17s
hbase-server in the patch failed.

256m 36s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 351210cfe9e7 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27389 / 2469aca027

Default Java
Temurin-1.8.0_352-b08

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/2/artifact/yetus-jdk8-hadoop3-check/output/patch-unit-hbase-server.txt

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

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

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ HBASE-27389 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 47s
HBASE-27389 passed

+1 :green_heart:
compile
1m 46s
HBASE-27389 passed

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

+1 :green_heart:
javadoc
0m 52s
HBASE-27389 passed

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 37s
the patch passed

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

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

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 40s
hbase-protocol-shaded in the patch passed.

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

-1 :x:
unit
232m  1s
hbase-server in the patch failed.

260m 34s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 132a8bb9dd26 5.4.0-152-generic #169-Ubuntu SMP Tue Jun 6 22:23:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27389 / 2469aca027

Default Java
Eclipse Adoptium-11.0.17+8

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/2/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

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

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

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

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

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

re-check

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

+0 :ok:
prototool
0m  0s
prototool was not available.

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

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

_ HBASE-27389 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 48s
HBASE-27389 passed

+1 :green_heart:
compile
3m 36s
HBASE-27389 passed

+1 :green_heart:
checkstyle
0m 50s
HBASE-27389 passed

-1 :x:
spotless
0m 37s
branch has 65 errors when running spotless:check, run spotless:apply to fix.

+1 :green_heart:
spotbugs
4m 11s
HBASE-27389 passed

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 33s
the patch passed

+1 :green_heart:
compile
3m 31s
the patch passed

+1 :green_heart:
cc
3m 31s
the patch passed

+1 :green_heart:
javac
3m 31s
the patch passed

+1 :green_heart:
checkstyle
0m  5s
The patch passed checkstyle in hbase-protocol-shaded

+1 :green_heart:
checkstyle
0m 13s
The patch passed checkstyle in hbase-client

+1 :green_heart:
checkstyle
0m 32s
hbase-server: The patch generated 0 new + 17 unchanged - 3 fixed = 17 total (was 20)

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

+1 :green_heart:
hadoopcheck
9m 40s
Patch does not cause any errors with Hadoop 3.2.4 3.3.5.

+1 :green_heart:
hbaseprotoc
1m 17s
the patch passed

+1 :green_heart:
spotless
0m 39s
patch has no errors when running spotless:check.

+1 :green_heart:
spotbugs
4m 40s
the patch passed

_ Other Tests _

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

42m 57s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/3/artifact/yetus-general-check/output/Dockerfile

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

Optional Tests
dupname asflicense javac spotbugs hadoopcheck hbaseanti spotless checkstyle compile cc hbaseprotoc prototool

uname
Linux 3f5768c0e2f1 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27389 / 2469aca027

Default Java
Eclipse Adoptium-11.0.17+8

spotless
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/3/artifact/yetus-general-check/output/branch-spotless.txt

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

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/3/console

versions
git=2.34.1 maven=3.8.6 spotbugs=4.7.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 25s
Docker mode activated.

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

_ Prechecks _

_ HBASE-27389 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 12s
HBASE-27389 passed

+1 :green_heart:
compile
1m 18s
HBASE-27389 passed

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

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

_ Patch Compile Tests _

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

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

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

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

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 25s
hbase-protocol-shaded in the patch passed.

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

+1 :green_heart:
unit
228m 10s
hbase-server in the patch passed.

253m 22s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/3/artifact/yetus-jdk8-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 449ce452d48f 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27389 / 2469aca027

Default Java
Temurin-1.8.0_352-b08

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/3/testReport/

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

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/3/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

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

_ Prechecks _

_ HBASE-27389 Compile Tests _

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

+1 :green_heart:
mvninstall
2m 53s
HBASE-27389 passed

+1 :green_heart:
compile
1m 52s
HBASE-27389 passed

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

+1 :green_heart:
javadoc
0m 52s
HBASE-27389 passed

_ Patch Compile Tests _

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

+1 :green_heart:
mvninstall
2m 37s
the patch passed

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

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

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

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

_ Other Tests _

+1 :green_heart:
unit
0m 38s
hbase-protocol-shaded in the patch passed.

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

-1 :x:
unit
235m 29s
hbase-server in the patch failed.

264m 30s

Subsystem
Report/Notes

Docker
ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/3/artifact/yetus-jdk11-hadoop3-check/output/Dockerfile

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

Optional Tests
javac javadoc unit shadedjars compile

uname
Linux 1da89b2f8497 5.4.0-152-generic #169-Ubuntu SMP Tue Jun 6 22:23:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
HBASE-27389 / 2469aca027

Default Java
Eclipse Adoptium-11.0.17+8

unit
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/3/artifact/yetus-jdk11-hadoop3-check/output/patch-unit-hbase-server.txt

Test Results
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/3/testReport/

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

modules
C: hbase-protocol-shaded hbase-client hbase-server U: .

Console output
https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-5342/3/console

versions
git=2.34.1 maven=3.8.6

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

This message was automatically generated.

LGTM, just need to address the spotless errors before this can be merged.

Not sure why there are spotless error here. I do not see any errors in my local build. The 'mvn spotless:check' comes out clean.

re-check

The latest UT failures seem unrelated. I can't reproduce the spotless failures, so let's get this merged.


Refactor functions with pod runner

Change Overview
This PR contains refactoring of all invokers of PodRunner.Run as it was proposed in issue #2070
Now all invokers are using PodRunner.RunEx which invokes functor with PodController instance.
Pull request type
Please check the type of change your PR introduces:

[ ] :construction: Work in Progress
[x] :rainbow: Refactoring (no functional changes, no api changes)
[ ] :hamster: Trivial/Minor
[ ] :bug: Bugfix
[ ] :sunflower: Feature
[ ] :world_map: Documentation
[ ] :robot: Test

Issues

fixes #2070

Test Plan

[ ] :muscle: Manual
[ ] :zap: Unit test
[ ] :green_heart: E2E

I didn't split this PR to the train, because almost all changes are pretty similar.


Incomplete Launch Groups Creates group_barrier deadlock.

Bug summary
Kernel launches do not start all threads within a thread group simultaneously - resulting in deadlock.  I encountered this error launching an nd_range kernel with shape (1,256,4) by (1,1,4) -- using the last index as an intra-group index.  I don't think this is the expected behavior, but it's hard to find an explicit requirement for "all threads in a group are launched" in the spec.
To Reproduce
/* test.cc */
#include <stdio.h>
#include <CL/sycl.hpp>

namespace sycl = cl::sycl;

int main() {
    sycl::queue queue;
    queue.submit([&](sycl::handler &cgh) {
        cgh.parallel_for(sycl::nd_range<3>(
                         sycl::range(1, 128*2, 4),
                         sycl::range(1, 1, 4)),
                        [=](sycl::nd_item<3> item) {
            const size_t cid = item.get_group(0);
            const size_t a = item.get_group(1);
            const size_t k = item.get_local_id(2);

            printf("Started thread %d / %d\n", a, k);
            if(a%128 > 4) {
                return;
            }
            printf("Continuing thread %d / %d\n", a, k);
            sycl::group_barrier(item.get_group());
        });
    });
    queue.wait();
    return 0;
}

$SYCL/bin/syclcc -o test test.cc
$ ./test

Expected behavior
The program should complete without error.
Describe your setup
hipSYCL version "0.9.2", commit="49fd02499841ae884c61c738610e58c27ab51fdb"
installed via spack on OSX 11.6.8 using brew libomp.
$ $SYCL/bin/syclcc --version
Apple clang version 13.0.0 (clang-13<IP_ADDRESS>)
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

$ otool -L ./test
./test:
	@rpath/libhipSYCL-rt.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/spack/opt/spack/darwin-bigsur-skylake/apple-clang-13.0.0/boost-1.69.0-5viwyttojzzlsdaq7w7xbaah4pynbxlw/lib/libboost_context.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/spack/opt/spack/darwin-bigsur-skylake/apple-clang-13.0.0/boost-1.69.0-5viwyttojzzlsdaq7w7xbaah4pynbxlw/lib/libboost_fiber-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libomp.dylib (compatibility version 5.0.0, current version 5.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1200.3.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)

$ brew info libomp
libomp: stable 14.0.6 (bottled)
LLVM's OpenMP runtime library
https://openmp.llvm.org/
/usr/local/Cellar/libomp/14.0.6 (7 files, 1.6MB) *
  Poured from bottle on 2022-07-03 at 17:25:33
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/libomp.rb
License: MIT

Optional additional diagnostic information
Output of test code - showing only "continued" work items and sorting for clarity:
$ ./test | grep Continu
Continuing thread 0 / 0
Continuing thread 0 / 1
Continuing thread 0 / 2
Continuing thread 0 / 3
Continuing thread 1 / 0
Continuing thread 1 / 1
Continuing thread 1 / 2
Continuing thread 1 / 3
Continuing thread 2 / 0
Continuing thread 2 / 1
Continuing thread 2 / 2
Continuing thread 2 / 3
Continuing thread 3 / 0
Continuing thread 3 / 1
Continuing thread 3 / 2
Continuing thread 3 / 3
Continuing thread 4 / 0
Continuing thread 4 / 1
Continuing thread 4 / 2
Continuing thread 4 / 3
Continuing thread 128 / 0 # <- note: this actually printed last.
Continuing thread 130 / 0
Continuing thread 130 / 1
Continuing thread 130 / 2
Continuing thread 130 / 3
Continuing thread 131 / 0
Continuing thread 131 / 1
Continuing thread 131 / 2
Continuing thread 131 / 3
Continuing thread 132 / 0
Continuing thread 132 / 1
Continuing thread 132 / 2
Continuing thread 132 / 3

^C

Additional context
Add any other context about the problem here.

Does this happen both for --hipsycl-targetes="omp.library-only" as well as for --hipsycl-targets="omp.accelerated"?
What do you mean by "thread"? Note that what you call thread in your program output is unrelated to what is usually called a thread.
It is not required that all work items be launched at once, however the semantics of collective group algorithms must be preserved. In omp.library-only, hipSYCL first launches a single work item to probe whether a group contains a barrier, because the presence of barriers may require switching to a different less efficient execution model with different forward progress guarantees for each work item.

Thank you, I can reproduce with nd_range<3>{1,373,4} for the global work group size. It seems to be related to the early exit - removing the return statement fixes the issue for me.  I believe the return statement is legal though, since it only depends on the group id, not the local id.

I believe I have a fix in #814. Please let me know if this resolves the issue (It does for me :-) ).

I'm thinking about the CUDA sense, where my kernel uses a group of 4 CUDA threads (or hopes for a 4-element wide SIMD on CPU).

For the sake of completeness, please note that in the omp.library-only flow, if there are barriers present, you will not get vectorization across work items, so your hope that the 4-element work group is spread across a 4-element SIMD unit will not be true, and you might not get the performance you are expecting with this approach.
Background: The reason is that it is not possible to implement the SYCL nd_range model purely as a C++ library (as done by omp.library-only) without giving each work item its own stack (e.g. one OS thread per work item, or in our case, one fiber per work item). This is required to ensure that barriers can be implemented with the correct semantics and all work items can reach a barrier at the same time.
However, this prevents any vectorization across work items.
If you want to use omp.library-only and nd_range parallel for with barriers, for best performance I recommend

putting inner loops inside the work items which might then be vectorized (to compensate for lack of cross-work-item vectorization),
and increasing the computational load per work item and barrier invocation such that the relative cost of stack context switches caused by barrier invocations is reduced.

It is possible to get good performance with omp.library-only, but might require structuring your code somewhat differently than you might generally do on, say, a GPU.
Vectorization across work items with barriers and nd_range parallel for is only possible with dedicated compiler magic; if you want this (and typical GPU-like code perform well on CPU) please use omp.accelerated which provides additional compiler logic exactly for this purpose :-)
Of course, if you just want to use omp.library-only for development in order to later run with a different backend on e.g. GPUs all of  these performance considerations won't matter :-)

Hooray! This fixes the issue for me.
Yes - I'm developing on my laptop and running on MI250x in production.  Eventually I'll try and improve CPU performance as well, but it's not a priority at present.

Alright, thanks for the feedback! :)


Is there an existing issue for this?

[X] I have searched the existing issues.

Which plugins are affected?
cloud_firestore
Which platforms are affected?
Web
Description
All Streams stopped working in web version after upgrading cloud_firestore to 5.4.1. Starts only working again after downgrading to lower than 5.0.0.  On iOS and Android everything keeps working as before and no issues are detected
We experimented with making the data inside of the builder nullable and not nullable but both just gives back the document does not not exist.
Reproducing the issue
Steps to Reproduce the Issue

Set Up Firebase Firestore

Ensure that you have Firebase Firestore set up and connected to your Flutter project.
Use pub.dev cloud_firestore package minimum 5.0.0

Implement Document Stream

Create a method documentStream<T> which fetches and streams data from Firestore. Here's the code for this function:

Stream<T> documentStream<T>({
  required String path,
  required T builder(Map<String, dynamic>? data, String documentID),
}) {
  final reference = FirebaseFirestore.instance.doc(path);
  final snapshots = reference.snapshots();
  return snapshots.map((snapshot) => builder(snapshot.data(), snapshot.id));
}

Create a Stream for User Data
Use the documentStream method to build a stream for user data, as shown below:

Stream<UserData> userStream() => _service.documentStream(
  path: APIPath.userData(uid),
  builder: (data, documentId) => UserData.fromDS(documentId, data),
);

Use StreamBuilder in a Flutter Widget
To use the stream in the UI, implement a StreamBuilder widget to listen for changes to user data, only on web shows Document does not exist, but working on android and iOS.

return StreamBuilder<UserData>(
  stream: userStream(uid),
  builder: (context, snapshot) {
    if (snapshot.connectionState == ConnectionState.waiting) {
      // Connection is waiting for data
      return Center(child: CircularProgressIndicator());
    } else if (snapshot.connectionState == ConnectionState.active) {
      // Active connection and receiving data
      if (snapshot.hasData) {
        final userData = snapshot.data!;
        // Build your UI with userData
        return Text('Welcome ${userData.name}');
      } else if (!snapshot.hasData || snapshot.data == null) {
        return Center(child: Text('Document does not exist.'));
      }
    } else if (snapshot.hasError) {
      // Handle errors
      return Center(child: Text('Error: ${snapshot.error}'));
    } else {
      // Default fallback if none of the above conditions match
      return Center(child: Text('Something went wrong.'));
    }
  }
);

Firebase Core version
3.4.1
Flutter Version
3.22.2
Relevant Log Output
No response
Flutter dependencies

Expand Flutter dependencies snippet

Replace this line with the contents of your `flutter pub deps -- --style=compact`.

Additional context and comments
No response

Hi @operationcyberstorm , I'm unable to reproduce this issue. Kindly share a full sample code or repo reproducing this issue.

I think this issue may not be limited to firestore streams. It seems streams of auth changes for example have also stopped working.

firestore streams. It seems streams of auth changes for example have also stopped

Hi Josh, good to hear we are not the only ones having this problems, did you find any workarounds for this so far?

firestore streams. It seems streams of auth changes for example have also stopped

Hi Josh, good to hear we are not the only ones having this problems, did you find any workarounds for this so far?

Not so far. I spent some time trying to debug the issue but haven't found the cause yet and I'm not seeing any error logs.

We keep you updated if we figure out something new, we also do not see any error logs, just shows basically the doc is not existing.

Hi @operationcyberstorm , kindly provide a full sample code. I tried reproducing with the above code but I was unable to experience the behaviour you described.

I would appreciate it if you could create a minimal project that reproduces the issue.

This will take a while cause we are really busy, right now but send this to you as soon as possible

Hi @operationcyberstorm , I'll close this issue for now. Please don't hesitate to reach out once you have a reproducible code example, and we can revisit it. Thanks!


Speed problem

I tried to run the code, the speed is only 17 fps.
Not the same as the 82 fps described in the original text.
May I ask what is the reason?

I met the same problem on Pytorch04. When you test on Pytorch03, it seems is 82fps

I met the same problem on Pytorch04. When you test on Pytorch03, it seems is 82fps
Detect time per image: 14.0037ms
Nms time per image: 1.3876ms
Total time per image: 15.3912ms
FPS: 64.972 fps

@feixiangdekaka   when i test on pytorch0.3.1, i  met the problem Segmentation fault(Core Dump),  do you konw where is problem lie?


Magento 2 support?

Do you plan on supporting Magento 2?
Thanks!

bump

Yes, it's on the plan but won't be quick as extensions for Magento 2 require a complete re-write from Magento 1.x

Ok, thank you

@mixmastermike a new version for M2 is on the Marketplace: https://marketplace.magento.com/freshrelevance-digitaldatalayer.html


Session expiration handling

We need to let the user know when their session has expired and the need to re-login

Closing in favor of #224 and #164


eccodes_version.h is missing

When trying to build GribAPi.XP msbuild yells about it cannot find eccodes_version.h.
It seems to be left out on purpose in the grib_api\.gitignore?
Should this file be auto generated somehow?

This file is apparently generated by the Linux build. I downloaded eccodes onto an ubuntu box, fllowed the build instructions there, the eccodes_version.h was generated as part of the Linux build. I copied the resulting file back onto my windows machine and the windows build succeeded.

For version 2.7.0 the content of the file is:
/*

Copyright 2005-2018 ECMWF.

This software is licensed under the terms of the Apache Licence Version 2.0
which can be obtained at http://www.apache.org/licenses/LICENSE-2.0.

In applying this licence, ECMWF does not waive the privileges and immunities granted to it by
virtue of its status as an intergovernmental organisation nor does it submit to any jurisdiction.
*/

#ifndef eccodes_version_H
#define eccodes_version_H
#define ECCODES_VERSION_STR      "2.7.0"
#define ECCODES_MAJOR_VERSION    2
#define ECCODES_MINOR_VERSION    7
#define ECCODES_REVISION_VERSION 0
#define ECCODES_VERSION (ECCODES_MAJOR_VERSION10000+ECCODES_MINOR_VERSION100+ECCODES_REVISION_VERSION)
#endif /* eccodes_version_H */

Thanks @adamsg69 that helped.
Here's a complete script of what I did.
cd build
cmake ../grib_api -DENABLE_FORTRAN=OFF -DENABLE_NETCDF=OFF -DENABLE_PYTHON=OFF -DENABLE_PNG=OFF -DENABLE_JPG=OFF
cp src/eccodes_version.h ../grib_api/src


Updated "local" to be compatible with redux

It's at the point where the backend will start and you can launch the experiment.  Mostly I fixed issue 107 and updated the launch_experiment.py so that it played nicely with the new target manager syntax/launching procedure.  Basically just took the code from the ec2 folder and modified it so that it applied to the local scenario.
Note: the strangefruit experiment itself doesn't work correctly.  Right now it displays the text of the JSON file in the boxes instead of the images.  I'm unsure how to get it to display images that are hosted elsewhere, as the master local example tells you to do.

I believe this is no longer up to date with more recent changes to redux.

I thought these were the changes I pushed last week.
On Mon, Jun 13, 2016 at 10:27 AM, dconathan<EMAIL_ADDRESS>wrote:

I believe this is no longer up to date with more recent changes to redux.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nextml/NEXT/pull/109#issuecomment-225615823, or mute
the thread
https://github.com/notifications/unsubscribe/ABWhGI39egAr4KTYzJjMW5k63hmxth2tks5qLXbRgaJpZM4IoxSm
.

You incorporated these changes plus added a few things I believe... anyway I think we can close this is is what I mean.


Do not use log.Fatal()

Return error when the k8s client cannot be initalized. Setup procedure failure will exit the DHCP service anyway, do not use log.Fatal()
Fixes https://github.com/ironcore-dev/FeDHCP/issues/115

@lukasfrank Can you please review that one?


🐛 Bug Report: Missing information in the AWS Fargate via Flightcontrol documentation.

📜 Description
The Backstage documentation provides steps on using Flightcontrol to deploy to AWS Fargate:
AWS Fargate via Flightcontrol
Using this methodology, Flightcontrol is integrated into GitHub and pulls in the Dockerfile to kick off the process of deploying to AWS. However, the issue with this approach is that you need to pre-build some artifacts (zip files) to copy into the image for deployment. You can see more here in the Backstage docs where the precursor to building the image is described :
Building a Docker image
This approach creates a bit of a conundrum. Flightcontrol kicks off the deployment based on a change to a file in the repo, or via a webhook and then pulls directly from the repo. This means the build artifacts need to already be in place in the package directory packages/backend/dist/.
Based on this approach you'd need the zip files to be stored in GitHub as there is no way Flightcontrol can access a GitHub runner to grab the files directly based on the currently documentation/methodology provided by the Backstage docs. Flightcontrol also has no way at present of checking out the source code, running a build script (e.g. a sh file with the yarn commands) prior to creating the image.
The quick work around for this is to use a multi-stage build, as demonstrated here:
https://github.com/moduslabs/modus-backstage-tips-tricks/tree/master/Flightcontrol/packages/backend
👍 Expected behavior
The documentation should be updated to note you need a multistage build or some other mechanism for the Flightcontrol steps to work as written.

👎 Actual Behavior with Screenshots
When following the existing documentation, the deployment in Flightcontrol will fail. This is due to the zip files not being present.
👟 Reproduction steps
Setup a Flightcontrol account at:
https://www.flightcontrol.dev/
Using the default Dockerfile in the repository, follow the steps located at:
https://backstage.io/docs/deployment/flightcontrol
When Flightcontrol attempts to deploy to AWS it will fail due to the zip files referenced in the Dockerfile missing:
# Copy repo skeleton first, to avoid unnecessary docker cache invalidation.
# The skeleton contains the package.json of each package in the monorepo,
# and along with yarn.lock and the root package.json, that's enough to run yarn install.
COPY --chown=node:node yarn.lock package.json packages/backend/dist/skeleton.tar.gz ./
RUN tar xzf skeleton.tar.gz && rm skeleton.tar.gz

RUN --mount=type=cache,target=/home/node/.cache/yarn,sharing=locked,uid=1000,gid=1000 \
    yarn install --frozen-lockfile --production --network-timeout 300000

# Then copy the rest of the backend bundle, along with any other files we might want.
COPY --chown=node:node packages/backend/dist/bundle.tar.gz app-config*.yaml ./
RUN tar xzf bundle.tar.gz && rm bundle.tar.gz

📃 Provide the context for the Bug.
This gap in documentation was found when attempting to follow the official deploy steps to setup Backstage in AWS Fargate
🖥 Your Environment
No response
👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

@rpigu-i can you raise a PR with the suggested documentation changes 👍  sounds good!

@benjdlambert Absolutely!

PR can be found here:
https://github.com/backstage/backstage/pull/22844
Thanks!

Closing as this seems to be fixed in the PR that was merged. :tada:


Problem with a readme badge

Before requesting a feature, please search for existing issues.

Is your feature request related to a problem? Please describe.
Hi, you have a problem with you readme file. In the begining "Greenkeeper badge"
Describe the solution you'd like:
Show the badge correctly
Link to or name of a (La)TeX package that provides the same feature:
no apply
Describe alternatives you've considered:
no apply
Additional context:
In the readme file

This is likely because Greenkeeper is currently not enablet (#1858)

Ok, thank you @danielhollas

@danielhollas thank you for the reminder.  I need to take care of that.


support chinese

Thanks for this great repo!
Support Chinese segment will be great!
thanks again.

We could create another branch that integrate Chinese tokenizer as default tokenizer in next release.

Is it implemented now?

@andyhu , yes, I agree with you.
nodejieba is a good package for Chinese tokenization.
But one big issue is that this elasticlunr is supposed to be used in browser for offline.
So my concern is that if we support Chinese, we need to add the package into elasticlunr, and make it a isolated package that could be used in elasticlunr even without network connection.


Investigate and review code and create issues for refactoring

For instance, look for places where the input/output isn't consistent or changes based on a condition. Or when a function is doing too much (except for larger user-facing functions). Or when a function has too much code that could be split out more into smaller more composable functions.
The easier and simpler a function is that doesn't depend on too many other things, the easier it is to test. This follows the SOLID principles of software engineering: https://en.wikipedia.org/wiki/SOLID. It also follows functional programming.

List of issues with a focus on sprout:

https://github.com/seedcase-project/seedcase-sprout/issues/504
https://github.com/seedcase-project/seedcase-sprout/issues/512
https://github.com/seedcase-project/seedcase-sprout/issues/514
https://github.com/seedcase-project/seedcase-sprout/issues/515
https://github.com/seedcase-project/seedcase-sprout/issues/508
https://github.com/seedcase-project/seedcase-sprout/issues/509
https://github.com/seedcase-project/seedcase-sprout/issues/510
https://github.com/seedcase-project/seedcase-sprout/issues/513
https://github.com/seedcase-project/seedcase-sprout/issues/511
https://github.com/seedcase-project/seedcase-sprout/issues/516

Great! So we can close this one now 😁


ColumnEncodingUtility - new feature - diff of suggested/current encoding

I've been using this utility and it's been working great. I thought it would convenient if the utility could produce a diff of the suggested encodings and what is currently in-use for a table/schema.
Just thought I'd post this for feedback to see if others think this would be useful.
Thanks,
Patrick

So are you thinking something like a 'report' option?


Added release nodes from kubespray v2.23.0-ck8s2

⚠ IMPORTANT ⚠: This is a public repository. Make sure to not disclose:

[x] personal data beyond what is necessary for interacting with this Pull Request;
[x] business confidential information, such as customer names.

I would say for bug fixes like this we don't need to update public docs since it's not relevant for the devs

I'd say we just reword it into a "Fixed a bug that...." or similar, since we still want an entry for it.

:+1: I'm fine with that!


Question: How to use spies/mocks/stubs within stack, as well as properly Unit test components

This generator comes with Chai + Mocha but I'm finding that these packages aren't ideal for testing React (could be wrong). I'm finding it difficult to stub component methods or call on state. This may be related to the helper createComponent which uses createRenderer.
Is there a best practice or example on how to properly unit test components with this stack? This means only testing an existing component and not having it leak child components, as well as making outbound http requests.
Thank you

Hi @AdamT,
the answer would take a bit longer, but just in short:
Chai and Mocha are a perfect team for testing. I got test suites here at work that rely on this toolchain and we got more then 800 tests (counted with flux store tests and utils) that we are using this generator for.
When we implemented the createComponent stuff, react 0.13 was just released and it gave us the shallowRenderer, which should be perfect for unit tests of dumb (stateless) components. With it, you can test the created dom one level deep.
That does not make testing easier with react, as you may still have to use the react-addons-testutils package directly (e.g. for rendering the full component into the dom).
We are currently moving away from the current approach in favour of enzyme (http://airbnb.io/enzyme/), which makes testing react components a breeze. You may try the current version of the underlying template (https://github.com/weblogixx/react-webpack-template/tree/2.x) of this generator, it has this stuff already included. It still uses mocha + chai, but without karma (a virtual (js)dom is used instead).
For testing components da do stuff like requests (http, websocket) or have other behaviour that you do not want to run while testing, have a look at sinon. Set up sinon stubs before the unwanted behaviour is triggered and reset the stubs afterwards. With this approach, your scripts will not call the original function (e.g. ajax request), but stub it away so you can assert its function without touching the core.
Hope this helps.


Add theme Kidlat

Thanks for adding Kidlat theme.

Fix the link to license on your readme here: https://github.com/kidlat2024/kidlat?tab=readme-ov-file#license

Thanks!


Merge branch dev

@pi0 Could you review please?
Closes #6

:tada: This PR is included in version 1.0.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Feature] Authenticated API datasource creation

Description
Added a new card to datasources pane to create REST API datasource, directly from create new tab.
Fixes #5782
Type of change

New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Added a cypress test

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes

Test coverage results :test_tube:
:red_circle: Total coverage has decreased
// Code coverage diff between base branch:release and head branch: feature/oauth-datasource-creation

Status
File
% Stmts
% Branch
% Funcs
% Lines

:red_circle:
total
51.95 (-0.01)
33.64 (0)
29.98 (-0.01)
52.62 (-0.01)

:red_circle:
app/client/src/pages/Editor/IntegrationEditor/NewApi.tsx
48.78 (-13.72)
50 (-16.67)
0 (0)
54.05 (-10.47)

/ok-to-test sha=f902bf5

/ok-to-test sha=c06434f

@pranavkanade small change, can we call this authenticated API instead of OAuth

@pranavkanade small change, can we call this authenticated API instead of OAuth
@Nikhil-Nandagopal you mean to choose API Key option for authentication type, right?

/ok-to-test sha=cc6787d

Should we redirect to the view mode of the datasource after saving it, which has a create new query button? We could keep them on the same page as well since there's a new api button here.
Also we should keep the new api button disabled button until we save the datasource, as it still errors out even if the url is filled

@rishabhsaxena the new API button from edit mode needs to be removed, it's confusing. Redirecting to the view mode is to give reinforcement that it got saved and the next step is to create a new API

@Nikhil-Nandagopal will add saved state for this.

@Rishabh-Rathod this is a bug. I can see that on release as well.

/ok-to-test sha=72efc2a


Custom manager classes in both notebook vs. jupyter_server

Currently, the way we check the *_manager_class traits (i.e. kernel_manager_class, contents_manager_class, etc.) prevents anyone from creating a custom class that works with both notebook and jupyter_server. That's because the Type() trait checks that the custom class inherits from a manager of one of these packages, not both.
You will either see:
The 'contents_manager_class' trait of a ServerApp instance expected a subclass of 'jupyter_server.services.contents.manager.ContentsManager', ...

if you inherit the base class from notebook, or
The 'contents_manager_class' trait of a NotebookApp instance expected a subclass of 'notebook.services.contents.manager.ContentsManager',

if you inherit from jupyter_server. There is no way to make a manager compatible with both servers.
This is something we'll likely want nbclassic to address, since it acts as the bridge between the two packages.

After thinking about this further, I think this may only apply (practically speaking) to custom contents managers.

After thinking about this further, I think this may only apply (practically speaking) to custom contents managers.

Yes this is an issue that we encountered for Jupytext, and we found no other solution than building the contents manager class dynamically from the current contents manager:
https://github.com/mwouts/jupytext/blob/d2898da3771d224bab3c15a2ea3e8e6e30a20423/jupytext/__init__.py#L40-L42
In practice it works well, but maybe that's not the best design... happy to learn of better workarounds!

Yes this is an issue that we encountered for Jupytext, and we found no other solution than building the contents manager class dynamically from the current contents manager:
https://github.com/mwouts/jupytext/blob/d2898da3771d224bab3c15a2ea3e8e6e30a20423/jupytext/__init__.py#L40-L42
In practice it works well, but maybe that's not the best design... happy to learn of better workarounds!

We could maybe do something similar to this?
https://github.com/jupyter/nbdime/blob/c82362344e596efdc4f54c927d90338940e0fa41/nbdime/webapp/nb_server_extension.py#L16-L33

We could maybe do something similar to this?
https://github.com/jupyter/nbdime/blob/c82362344e596efdc4f54c927d90338940e0fa41/nbdime/webapp/nb_server_extension.py#L16-L33

Looks like this is getting handled in the respective server bases (https://github.com/jupyter-server/jupyter_server/pull/392, https://github.com/jupyter/notebook/pull/5957)- which makes sense.

Looks like this is getting handled in the respective server bases (https://github.com/jupyter-server/jupyter_server/pull/392, https://github.com/jupyter/notebook/pull/5957)- which makes sense.


Build fails when using supabase-js

What version of Remix are you using?
1.2.2
Steps to Reproduce

Select Cloudflare workers (or pages) as runtime.
Install @supabase/supabase-js.
Call createClient in loader or .server.ts
Start up a dev server (yarn dev)

Expected Behavior
The server comes up without error.
Actual Behavior
Error occurs. TypeError: globalThis.XMLHttpRequest is not a constructor

You can work around it by adapting such a patch.
If the runtime is Cloudflare Workers, the browser module should be the preferred solution.
diff --git<EMAIL_ADDRESS><EMAIL_ADDRESS>index 0705b93..72ed487 100644
---<EMAIL_ADDRESS>+++<EMAIL_ADDRESS>@@ -364,7 +364,7 @@ async function createServerBuild(config, options, assetsManifestPromiseRef) {
     format: config.serverModuleFormat,
     treeShaking: true,
     minify: options.mode === build$1.BuildMode.Production && !!config.serverBuildTarget && ["cloudflare-workers", "cloudflare-pages"].includes(config.serverBuildTarget),
-    mainFields: config.serverModuleFormat === "esm" ? ["module", "main"] : ["main", "module"],
+    mainFields: ["browser", "module", "main"],
     target: options.target,
     inject: [reactShim],
     loader: loaders.loaders,

It also happens with graphql-request.

Yeah it's happening to me too when using graphql-request. The small patch proposed by @aiji42 didn't help: it moved the problem from build-time to run-time (I get an application error in the browser: ReferenceError: XMLHttpRequest is not defined).

Yes, I'm using v1.2.2, and yes I updated createServerBuild. I think that graphql-request tries to determine if fetch is available or not in some way but it doesn't work.
Anyway see my prev comment that I edited, I got it to work.
Thanks for helping!

Same error goes for @notionhq/client

I see the same error when trying to use @sanity/client in a vanilla Remix 1.2.3 app with Cloudflare Pages as deploy target:
...
Compiled Worker successfully.
[pages:err] TypeError: globalThis.XMLHttpRequest is not a constructor
    at checkTypeSupport (/somepath/remix-starter/node_modules/rollup-plugin-node-polyfills/polyfills/http-lib/capability.js:20:11)
    at node_modules/rollup-plugin-node-polyfills/polyfills/http-lib/capability.js (/somepath/remix-starter/node_modules/rollup-plugin-node-polyfills/polyfills/http-lib/capability.js:39:45)
    at __init (/var/folders/f5/62nm5zbj5ss915gv70f465100000gn/T/functionsWorker.js:39:56)
    at node_modules/rollup-plugin-node-polyfills/polyfills/http-lib/request.js (/somepath/remix-starter/node_modules/rollup-plugin-node-polyfills/polyfills/http-lib/request.js:1:1)
    at __init (/var/folders/f5/62nm5zbj5ss915gv70f465100000gn/T/functionsWorker.js:39:56)
    at node-modules-polyfills:https (/somepath/remix-starter/functions/node-modules-polyfills:https:30:1)
    at __init (/var/folders/f5/62nm5zbj5ss915gv70f465100000gn/T/functionsWorker.js:39:56)
    at node-modules-polyfills-commonjs:https (/somepath/remix-starter/functions/node-modules-polyfills-commonjs:https:2:18)
    at __require (/var/folders/f5/62nm5zbj5ss915gv70f465100000gn/T/functionsWorker.js:42:50)
    at node_modules/eventsource/lib/eventsource.js (/somepath/remix-starter/node_modules/eventsource/lib/eventsource.js:4:13)
Could not start Miniflare.
ERROR: "dev:wrangler" exited with 1.

Thanks everyone for the reports.
I have already created a PR to solve this problem already but it is not merged easily.
As I indicated at the beginning, patching is one way to deal with the problem, but it is complicated to have to fix the patch together with every version upgrade on the Remix side.
I have therefore developed a library that allows overriding the esbuild settings in Remix, and I would like to introduce it to you.
https://github.com/aiji42/remix-esbuild-override
yarn add -D remix-esbuild-override

Update scripts.postinstall in package.json. Then run yarn instal again to run postinstall.
"scripts": {
  "postinstall": "yarn remix setup cloudflare-workers && yarn remix-esbuild-override"
}

Update remix.config.js
// remix.config.js
/**
 * @type {import('remix-esbuild-override').AppConfig}
 */
module.exports = {
  serverBuildTarget: "cloudflare-workers",
  server: "./server.js",
  devServerBroadcastDelay: 1000,
  ignoredRouteFiles: [".*"],
  esbuildOverride: (option, { isServer }) => {
    if (isServer) option.mainFields = ["browser", "module", "main"];

    return option;
  },
};

It will allow us to override esbuild settings, which will not only address this issue, but also various other compiler-dependent issues.

I submitted a PR for this feature to be added to the Remix side, but it was rejected because it was conceptually unacceptable. Therefore, I am developing this remix-esbuild-override as a third-party library.

#1977 was merged


NIFI-5420: Allow StandardProcessSession to calculate duration for provenance events

Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:

[x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?

[x] Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

[x] Has your PR been rebased against the latest commit within the target branch (typically master)?

[x] Is your initial contribution a single, squashed commit?

For code changes:

[x] Have you ensured that the full suite of tests is executed via mvn -Pcontrib-check clean install at the root nifi folder?
[x] Have you written or updated unit tests to verify your changes?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE file, including the main LICENSE file under nifi-assembly?
[ ] If applicable, have you updated the NOTICE file, including the main NOTICE file found under nifi-assembly?
[ ] If adding new Properties, have you added .displayName in addition to .name (programmatic access) for each of the new properties?

For documentation related changes:

[ ] Have you ensured that format looks appropriate for the output in which it is rendered?

Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

@markap14 Mind taking a look at this one? Please and thanks!

Reviewing...

+1 from me, code looks good. All unit tests pass. Did a quick sanity check testing and all appears to work as expected. Minor change but definitely will have a positive impact. Thanks, @mattyb149 !


Quantum kernel user guide has some typos

mostly missing letters or letter permutations -> Copy and paste into a language check capable editor (such as word) would resolve most of the problems.

We could add sphinxcontrib-spelling to the doc checks


dts: x86: intel: raptor_lake: Removes unavailable UARTs

Removes unavailable UART instances on RPL platform.
Signed-off-by: Anisetti Avinash Krishna<EMAIL_ADDRESS>

@akanisetti looks fine, but could you fix the commit message to use the consistent form of the verb, i.e. "Remove" instead of "Removes"


Improve type inference within callbacks

The following code snippet emits "WARNING - actual parameter 1 of f does not match formal parameter. found: (null|string), required: string"
/** @param {string} x */
function f(x) {}
function g() {
/** @type {?string} */
var x = null;
if (x) {
[].forEach(function() {
f(x);
});
}
}
I wish the compiler could prove that x can't be null when it's passed to f.

This is too difficult to do in the general case, and I don't think the compiler's heuristics will improve anytime soon.

This is pretty common and it is reasonable to (a) annotate immediately invoked parameter functions in externs (b) check the passed function itself doesn't escape itself.  In those cases using the type of x from the outer scope is reasonable.  The escape analysis for (a) for non-extern functions is also possible.
The basic reason functions can't use the value from the outer scope is that it isn't know if the type tightening applies as the function may be called later:
function f() {
     var x = null;
     return function() { return x++ }
}

But if we know the function is immediately invoke this reasoning doesn't apply:
function f() {
     var x = null;
     (function() { use(x) })();
}

As long as "arguments.x" isn't referenced it isn't possible to invoke this function later.  The same logic extends to "Array.prototype.forEach" and many other common methods.  This would actually reduce the need for "nullablity" checks and similiar type tightening quite a bit.

it might also be possible to attack this from the other direction. rather than trying to figure out where the inner function is called (john's suggestion), we might notice that x is used in a very limited way. It's assigned once, and all uses are guarded by the if (x).


Indented UI inputs don't show up

Describe the bug

As displayed, a ui component won't show up if it's indented.
Environment
{
"marimo": "0.3.4",
"OS": "Darwin",
"OS Version": "22.3.0",
"Processor": "arm",
"Python Version": "3.12.0",
"Binaries": {
"Chrome": "123.0.6312.59",
"Node": "v20.7.0"
},
"Requirements": {
"black": "23.9.1",
"click": "8.1.7",
"jedi": "0.19.1",
"pymdown-extensions": "10.7",
"starlette": "0.36.1",
"tomlkit": "0.12.3",
"typing_extensions": "4.8.0",
"uvicorn": "0.27.0"
}
}
Code to reproduce
No response

This isn't a bug, but I can understand why it is confusing. An if statement in Python has no value; marimo shows the value of the last expression in the cell. Hence why you get no output.
Your workaround is the correct way to conditionally show an output in marimo, since a ternary (... if ... else ...) is an expression in Python which has a value.


error : unknown flag: --execution-requirements

I setup k6-operator at my eks cluster.
It was working fine until about a week ago.
Today, when I created k6 and tried to test it, an error stating "unknown flag: --execution-requirements" occurred in the k6 initializer.
I don't know the cause at all. How should I check the operation?

Hi @joeunlog, are you using custom image for runner? If so, what version of k6 are you using to build it?

I use latest tag, so I don't know specific version.

@yorugac Since I made an image when installing k6, I think you can refer to the captured version of k6.

I think latest caused issues with cached versions just recently :thinking: Could you please build with a tag instead? So use the following to build your custom image:
FROM ghcr.io/grafana/operator:runner-v0.0.8rc1
...

v0.0.8rc1 was made just yesterday.

Same error occurred.
And, I tested grafana/k6:latest image as runner, it work fine. Could it be that xk6 build is the cause?

I think I've found the problem. That xk6 extension wasn't updated in awhile and it uses k6 0.32:
https://github.com/szkiba/xk6-prometheus/blob/b3eaefdbaa7f518d8186b934b10a26e7e3aceeeb/go.mod#L9
That version won't work with the operator anymore. Did you see that extension in Readme? We should update it - it came up before, in #114.
Please switch to using one of our officially supported extensions, i.e. the ones hosted at https://github.com/grafana.
Alternatively, Ivan Szkiba might be happy with the PR to his extension too :slightly_smiling_face:

@yorugac I checked xk6 officially supported extensions, but couldn't find proper extension.
Could you recommand extension for using with prometheus-stack?
I use podmonitor for scraping k6 http reponse metric while testing.
I read (xk6-output-prometheus-remote)[https://github.com/grafana/xk6-output-prometheus-remote] but I couldn't attach to podmonitor.

I solved the problem by using ghcr.io/grafana/operator:controller-v0.0.7 image.
This is temporary action. I will continue to look for available extensions to use the latest version of go.
I will close this issue. Thanks for the quick response.

@joeunlog @yorugac  I am still facing the issue. k6 pods are not getting created. I tried using ghcr.io/grafana/operator:controller-v0.0.7 image. This is Dockerfile that i created, as suggested above.

Pods not getting created. see below ss

below is my k6 resource. pulling image which i pushed from my private repo
apiVersion: k6.io/v1alpha1 kind: K6 metadata:   name: k6-req-otp-constant-rate-testing   namespace: perf-testing spec:   parallelism: 1   script:     configMap:       name: npci-req-otp-flow       file: req_otp.js   arguments: --out prometheus=subsystem=k6 --insecure-skip-tls-verify   ports:     - containerPort: 5656       name: metrics   runner:     image: us-central1-docker.pkg.dev/engineering-330305/governor-k8s-testing/k6-prometheus:0.0.1
kindly assist.

@prateek-pagaria
I use ghcr.io/grafana/operator:controller-v0.0.7 image as a k6 operator controller. Not k6 extention image.

This is my dockerfile.
You should use controller-v0.0.7 for k6-operator/controller.

@prateek-pagaria
I think you should edit k6-operator-controller's container image

@prateek-pagaria This issue is not because of controller - it is because of k6 version which is runner image. When you're building custom runner image of k6 with this specific extension (https://github.com/szkiba/xk6-prometheus), you're using outdated k6 libraries. Solution: do not use that extension until it is updated.
PS you didn't have to switch from forum to Github :slightly_smiling_face:


I wrote the code according to the access controller documentation, but an error occurs.

I tried copying the wildcard part of the access controller documentation. However, when I try to run it with nodejs, I get an error saying "The requested module '@orbitdb/core' does not provide an export named 'getAccessController'".
code executed
import { create } from 'ipfs-core'
import { createOrbitDB, Identities, getAccessController } from '@orbitdb/core'

const ipfs = await create()

const orbitdb = await createOrbitDB({ ipfs })

const IPFSAccessController = getAccessController('ipfs')

const db = orbitdb.open('my-db', { AccessController: IPFSAccessController({ write: ['*'] }) })

out
import { createOrbitDB, Identities, getAccessController } from '@orbitdb/core'
                                    ^^^^^^^^^^^^^^^^^^^
SyntaxError: The requested module '@orbitdb/core' does not provide an export named 'getAccessController'
    at ModuleJob._instantiate (node:internal/modules/esm/module_job:124:21)
    at async ModuleJob.run (node:internal/modules/esm/module_job:190:5)

When I looked at "@orbitdb/core", getAccessController was not exported.
export {
  useAccessController,
  IPFSAccessController,
  OrbitDBAccessController
} from './access-controllers/index.js'`

Have the specifications changed?

Thanks for the heads up. That documentation looks out-dated so we will update asap.
You should be able to use IPFSAccessController directly without having call it via getAccessController, so try changing the above to:
import { create } from 'ipfs-core'
import { createOrbitDB, Identities, IPFSAccessController } from '@orbitdb/core'

const ipfs = await create()

const orbitdb = await createOrbitDB({ ipfs })

const db = orbitdb.open('my-db', { AccessController: IPFSAccessController({ write: ['*'] }) })

and hopefully that will solve your issue.

Thanks all for the lighting fast response!

I'm going to close this issue but if you experience any further issues please re-open. We will also make a note to update the documentation accordingly.


Added code for sum of two binary numbers

Have you read the Contributing Guidelines on Pull Requests?
Yes
Description
I have tried explain the code to my best, and the code I have written is very simple to be understood by anyone.
Checklist

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

Related Issues or Pull Requests
#5514

@HarshCasper  sir I have put this pr, as per me the code that i have provided is correct , with all necessary explanation, Plz review it sir, and let me know if something is wrong.

@Nidhideveloper You have merge conflicts do resolve.


ROM_EXT bootstrap flash memory protection

This PR adds a new memory protection feature to the flash_ctrl driver.
This is how ROM_EXT bootstrap implements its promises without explicit bounds checks in software.
Issues #19151, #19438

Thanks for the review, @alphan!! I just need clarification on two of your comments from the last round.


Invite contributors to view our Trello board

A thumbs-up here is also a thumbs-up for making the board publicly visible. :)

Personally I'm 👎 on this; I don't think it's well maintained enough and I'd personally really rather we doubled-down on GitHub issues features (labels, assignments, milestones) for this stuff.

I'd personally really rather we doubled-down on GitHub issues features (labels, assignments, milestones) for this stuff

I think Trello can be better than it is but I'm ultimately agnostic to the system we use; what do you imagine this looking like?

@tdsmith A few things we could be doing that we're not (some are mutually exclusive):

Tracking issues using checkboxes that we link to other issues. These could perhaps even live in a Homebrew/planning repository to make it easier for the community to follow along
Use issue milestones: https://github.com/Homebrew/brew/milestones
Assign the issues that are being actively worked on (i.e. you'll do some work towards this issue in the next week)
For every "feature" PR mandate an issue describing and discussing the feature

Some of these are overkill but could improve communication with the community like you mention

Closing for now.


Name Registry Application

Application Description
Following on from Ethereum, which follows on from DNS, a name service application is one where a user is able to interact with some address that is in human readable form instead of the typical hash variation.
For example, an address may take the form of 0x01234... while a human readable form would be alice.fuel.
This allows a user to send funds to alice.fuel which is easier to remember and reduces the chance of making a mistake when writing out the address.
The application would allow a user to purchase a domain alice.fuel and allow them to expand the domain as they wish into many subdomains e.g. blog.alice.fuel, store.alice.fuel etc.
Furthermore, the domain would be tradeable with others since its representation is an NFT.
Features

[x] #137
[ ] #138
[x] #139

Hmmm. "Ethereum Name Service" is the name of a product, but the actual thing is a name registry. Would prefer this application be named boringly as a not-product, i.e. "name registry." Similar to "non-fungible token" and "auction."

I've started to work on a name registry service for Fuel at the EthCC hackathon. I will post updates.

Closing to consolidate to just https://github.com/FuelLabs/sway-applications/issues/138


Replace Linux utils with an Inbuilt application

Description
Build scratch based Image, with only statically built applications[calicoctl & calicoctl-wait]
Check this PR

Deploy preview for calico ready!
Built with commit 87b436d1e7ba10ea1a0b87fbe612288c4ad96f93
https://deploy-preview-3768--calico.netlify.app


In Discussion List/ Discussion Board Subject and Question are not coming in Flat view

Hi,
Currently I am using OfficeDevPnP.core to provision a site in Office365. When I am provisioning the site everything is being provisioned except Discussion board or Discussion List. For these two only, body is showing in Flat view. Subject and question are not being shown over there. But when I am adding from Site content—Add an App it is coming properly. I have attached template deck also here. It would be a great help if anybody can give the solution.
Thanks in advance.
Best Regards,
Nabhendu
PnPProvisioningDemo.txt

We closed this issue as it had not activity within last 180 days. This is a generic process we have decided to perform for issues, which have not been explicitly marked still to be "work in progress" based on tags. We are performing this cleaning to make sure that old issues that have already been solved (but not closed) or are no longer relevant are cleaned out and make the issues more manageable. If this issue still valid, we would ask you to open a new issue and follow the guidance in the issue template related on the recommended location. We do apologize any inconveniences this might cause. Please do remember that issues in the issue lists are also messages for others in the community, so you can also check if you can assist on any of them. “Sharing is caring!”


how to autopep8 a python file to --max-line-length 80

currently, it doesn't work, how to make this happen?
I could change in my private branch.

I think you just have to set the &textwidth property in your buffer?

how to set this to all *.py files?
I don't want to only set this to one buffer, which means I need to set buffer by buffer.

Use an autocommand. You can google or ask chatgpt on how to do this. It's a pretty common thing :)


chore: release main

:robot: I have created a release beep boop
biblo: 0.7.1
0.7.1 (2022-12-01)
Bug Fixes

Fix how addon Simple Markup makes line through text (6d4390d)

addon-simple-markup: 1.3.1
1.3.1 (2022-12-01)
Bug Fixes

Fix how addon Simple Markup makes line through text (6d4390d)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/saxofonsolo/biblo/releases/tag/biblo-v0.7.1 :sunflower:

:robot: Release is at https://github.com/saxofonsolo/biblo/releases/tag/addon-simple-markup-v1.3.1 :sunflower:


Document how to write commits

Reviewers often find themselves linking to blog posts to encourage newer devs to improve their commit logs, we can save everyones time by putting the links in the contributing docs, then we can just point devs there.

Review the rendered version of these changes here: https://github.com/tcharding/rust-bitcoin/blob/03-13-commit-tips/CONTRIBUTING.md#preparing-prs

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 84.043%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
19540

Relevant Lines:
23250

💛  - Coveralls

BTW. Instead of/along with writing it in a document, you might want to set up a git commit template and some simple hook to install it.

Fixed grammar as suggested.

This is docs only, could go in with a single ack.


V2 trace wire format

This is backwards compatible, old implementations can still report
version1  traces and we won't compare fields that aren't present yet (e.g. privilege level).

I believe this should work now. The code is probably not very well written. I last used Haskell almost 10 years ago, so I just copy-pasted and followed IDE suggestions and code formatting.


 doesn't work after update from 2.0.0 to 2.0.2

Hello. I notices that "value" doesn't work in version, 2.0.2. In Version 2.0.0 works fine.
<ReactSummernote                         value = {state.content}                         onChange={onChange}                       />

I have the same issue

me too..

@Vnkitaev please could you publish 2.0.2 to Github?  Thanks!

Same here "value" prop bug

use "children" instead of "value"

use "children" instead of "value"

Awsome, thank u a lot <3

When setting the value via children it does not display text with markup. If I pass in Test it shows as that exact string, instead of the the word Test in bold.

Was is something I said?

Was is something I said?

No, I just did't use this package for a long time to I decided to close tha issue. Probably some variants under messages works...


Unable to set args for v2 plugins

Unable to set args for v2 plugins
The plugin I'm using supports 3 arguments as seen in this output:
# docker plugin inspect nimble
[
    {
        "Config": {
            "Args": {
                "Description": "Group connection information",
                "Name": "group",
                "Settable": [
                    "ip",
                    "user",
                    "pass"
                ],
                "Value": [
                    "",
                    "",
                    ""
                ]
            },

However, I am not able to set the values.
# docker plugin set nimble group.ip=<IP_ADDRESS>
Error response from daemon: "group.ip" is not settable

Steps to reproduce the issue:

Create a plugin with 'Args' defined
Inspect the plugin
Attempt to set the arguments defined in the 'Args' configuration

Describe the results you received:
Unable to set args
DEBU[6382] Calling POST /v1.25/plugins/nimble/set
ERRO[6382] Handler for POST /v1.25/plugins/nimble/set returned error: "group.ip" is not settable

Describe the results you expected:
Args should be set.
Additional information you deem important (e.g. issue happens only occasionally):
None.
Output of docker version:
# docker version
Client:
 Version:      1.13.0
 API version:  1.25
 Go version:   go1.7.3
 Git commit:   49bf474
 Built:        Tue Jan 17 09:58:26 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.0
 API version:  1.25 (minimum version 1.12)
 Go version:   go1.7.3
 Git commit:   49bf474
 Built:        Tue Jan 17 09:58:26 2017
 OS/Arch:      linux/amd64
 Experimental: false

Output of docker info:
# docker info
Containers: 1
 Running: 0
 Paused: 0
 Stopped: 1
Images: 6
Server Version: 1.13.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 7
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.4.0-62-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.859 GiB
Name: eforgette-u16p2
ID: UQWP:CEW2:4P3T:AFR2:3R7U:SUL3:QH2Y:5JGY:AYIY:64YM:WRT5:AZRJ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 14
 Goroutines: 22
 System Time: 2017-02-07T09:53:59.166981721-08:00
 EventsListeners: 0
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Experimental: false
Insecure Registries:
 <IP_ADDRESS>/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):
None.

#dibs

@vieux and @anusha-ragunathan looks like v2/settable/isSettable() will only allow a settable named "value" to be set.  This seems like a bug.  In addition, args looks like it will be replaced with only that which is set (loosing all other values).

@e4jet I believe your plugin should look like this:
# docker plugin inspect nimble
[
    {
        "Config": {
            "Args": {
                "Description": "Group connection information",
                "Name": "group",
                "Settable": [
                    "ip",
                    "user",
                    "pass"
                ],
                "ip": "",
                "user": "",
                "pass": "",
            },

The values in Settable refer to an actual key in the config

Thanks for the quick reply @vieux.  Unfortunately, that didn't work.  The plugin starts, but the JSON gets converted.
snip from config.json
  "Args": {
    "Description": "Group connection information",
    "Name": "group",
    "Settable": [ "ip", "user", "pass" ],
    "ip": "",
    "user": "",
    "pass": ""
  },

snip from 'docker plugin inspect'
            "Args": {
                "Description": "Group connection information",
                "Name": "group",
                "Settable": [
                    "ip",
                    "user",
                    "pass"
                ],
                "Value": null
            },

This seems to be the right marshaling behavior because 'Value' is defined as a slice of strings in api/types/plugin/PluginConfigArgs.  I may still be missing something though...

ping @tiborvass  :)

I wonder if Args was supposed to be a slice of PluginConfigArgs like Env is a slice of PluginEnv.  It might be a bit too late for a change like that since this is out of experimental now (and would be a breaking API change)...

@e4jet So there are 2 solutions:
"Args": {
  "Description": "Arguments to be passed to the plugin",
  "Name": "args"
}

And then do docker plugin set $plugin args="--group-ip <IP_ADDRESS> --group-user username --group-pass password" but your program will have to parse the cli args. The problem with this solution is that it bypasses the settings mechanism. As a hack you could put in the description, what flags to put in the args setting but it's weird.
Or you can also do:
"Env": [
  {
    "Name": "group.ip",
    "Description": "Group IP"
  },{
    "Name": "group.user",
    "Description": "Group user"
  },{
    "Name": "group.pass",
    "Description": "Group password"
  }
]

And then run docker plugin set $plugin group.ip=... group.user=... group.pass=... but your program will have to read these as environment variables.
Hope this helps, we'll update the documentation to make things a bit clearer.

Docs explained in https://github.com/docker/docker/pull/32103


Configure IncludeCategories grouping for clang-format

Separate between STL, 3P, and local includes in blocks.

@Waifod—can you review this one?

Thanks myboi 🔥


Change Eamail to Email

Daniel changed Eamail to Email in the heading at the top of the repo's README.md


sxs.zenodo.download not found in sxs_catalog_download_example.ipynb

Hello all,
I just wanted to try out sxs_catalog_download_example.ipynb (git hash dac7198) using:
git clone https://github.com/sxs-collaboration/catalog_tools.git
cd catalog_tools/
cd Examples/
jupyter-notebook --browser=no --port 12345 --ip <IP_ADDRESS> sxs_catalog_download_example.ipynb

but get in the second cell:
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-2-083f8445225d> in <module>
----> 1 zen.download.matching("common-metadata.txt", "metadata.txt", \
      2                       "rhOverM_Asymptotic_GeometricUnits_CoM.h5", \
      3                       "Horizons.h5", \
      4                       sxs_ids = ['SXS:BBH:0444'], \
      5                       dry_run = True, \

AttributeError: module 'sxs.zenodo' has no attribute 'download'

when using pip install sxs. I ended up with sxs 2020.9.19 (so fairly new).

Please see #8 . We still need to update this repo to reflect that the download mechanisms have been superseded with a new sxs package API.

#8 is marked as closed. Shouldn't it be only closed once the issue no longer exists?

@rhaas80 that's valid, probably it shouldn't have been closed. Or, we should have opened a separate issue like 'Deprecate this repo' instead. @geoffrey4444 thoughts?

If deprecating the whole repo (which would be a shame as having a programmatic interface is quite useful) then care must be taken to remove all references to it on the website. Eg https://data.black-holes.org/waveforms/index.html

Is this issue has been resolved?
I am facing the same problem with
Name: sxs
Version: 2021.0.5

Many thanks for considering my request.

Is this issue has been resolved? I am facing the same problem with
Name: sxs
Version: 2021.0.5

Many thanks for considering my request.

You may try the following code
def download_file(common_meta, meta, com_file, horizon, sxs_ids=None, dry_run=True, highest_lev_only=False):
    # read all catalog list
    catalog_list_file="sxs_catalog_zen.json"
    json1_file = open(catalog_list_file)
    json1_str = json1_file.read()
    catalog_json = json.loads(json1_str)
    catalog_levels_file="sxs_catalog_zen_resolutions_available.json"
    json2_file = open(catalog_levels_file)
    json2_str = json2_file.read()
    catalog_levels_json = json.loads(json2_str)
    file_list = [common_meta, meta, com_file, horizon]
    if sxs_ids is None:
        sxs_ids=['SXS:BBH:0444']
    for sxs_id in sxs_ids:
        levels_json = catalog_levels_json[sxs_id]
        max_level = len(levels_json)
        max_level_label = 'Lev'+str(max_level)
        dir_name = sxs_id.replace(":", "_", 2)
        for file in np.array(catalog_json[sxs_id]['files']):
            file_name = file['filename']
            if highest_lev_only==False:
                if any(name in file_name for name in file_list):
                    download = file['links']['download']
                    file_path = dir_name + '/' + file_name
                    print("Downloading {0} and writing to file {1}...".format(file_name, file_path))
                    utils.download_file(download, file_path)
            else:
                if any(name in file_name for name in file_list) and max_level_label in file_name:
                    download = file['links']['download']
                    file_path = dir_name + '/' + file_name
                    print("Downloading {0} and writing to file {1}...".format(file_name, file_path))
                    utils.download_file(download, file_path)

and call as
download_file("common-metadata.txt", "metadata.txt", \
                      "rhOverM_Asymptotic_GeometricUnits_CoM.h5", \
                      "Horizons.h5", \
                      sxs_ids = ['SXS:BBH:0444'], \
                      dry_run = True, \
                      highest_lev_only = False)

Before you try the above code, you need to create two files, sxs_catalog_zen.json and sxs_catalog_zen_resolutions_available.json. These files can be generated by executing code Examples/sxs_zenodo_metadata_example.ipynb
Good luck!


VS code not taking PATH of g++ in tasks.json

VSCode Version: 1.38.1
OS Version: Windows 10

Steps to Reproduce:

Create tasks.json for your c++ program
In Command write only g++
Try to build your program with Ctrl+Shift+B
The terminal will through an error of "The term 'g++' is not recognized as the name of a
cmdlet..."
Change the command in tasks.json with the complete path of g++ in MingW folder, it starts
working

Does this issue occur when all extensions are disabled?: Yes

Does it work when you enter g++ in cmd window? Does it work when you enter it in the integrated terminal in VS Code?


Since Powerdale is bankrupt... now what ?

Hi Geert
You are aware that the company behind Nexxtmove (Powerdale) is bankrupt and is only kept alive for about 6 months ?
https://autonieuws.be/nieuws/powerdale-failliet-verklaard-onzekerheid-voor-duizenden-ev-rijders-en-fleetmanagers
https://www.tijd.be/ondernemen/milieu-energie/luxemburgers-nemen-laadpaalfacturatie-over-van-failliete-powerdale/10481126.html
Only a part of the companies activities were taken over.
(Just didn't know how to bring this to you in another way than here...)

Hi, I a of course well aware as I suppose all owners.
The integration I have made is the nexxtmove one. Nexxtmove was taken over by Diego in Luxembourg, I suppose they will continue a bit longer.
In my company we switched anyhow to the Eevee Mobility app and platform to follow charging and reimburse sessions


Shims for IE are not just for IE, are they?

The shims section at https://docs.angularjs.org/api/ngComponentRouter mentions that they're only needed for IE. However, in reality all non-ES6 browsers need them; this will include also Android <5.0 & iOS <8 users as well as Windows Mobile<10 ones.

Related: #410, #412.


Build repo specific PackageVersions.props w/dependencies declared in Version.Details.xml

Currently source-build build injects a PackageVersions.props into the repos builds that contains the current source-built package versions as well as all previously source built package versions.  The result of this is that source-build does not behave the same as repo builds.  Often times repos define Versions.props entries that are not auto-updated.  They do not have a corresponding dependency in the Version.Details.xml file.  Yet the way source-build works, these Versions.props entries are getting updated to use the source-built versions.
The solution to this is to build up a repo specific PackageVersions.props based on the dependencies defined in the Version.Details.xml.  This will get source-build to build like the microsoft build and will be a forcing function to ensure the appropriate dependencies are defined (in order to eliminate pre-builts).

This is required for Thttps://github.com/dotnet/source-build/issues/2979

Update on progress -> was finishing implementation for a different task (https://github.com/dotnet/source-build/issues/2655) + have a Bootcamp to attend this week, will properly start with the issue on Friday, 09/09/2022

Update on progress -> FR week + Hacathon next week, most probably will not produce meaningful progress in the next week

After initial investigation the current workload should probably be split into several separate issues due to the time and work required to accomplish a given milestone.
Based on introduction from @MichaelSimons and my own inspection, the steps taken should be as follows:

add functionality for reading VersionDetails.prop file and extracting dependency versions of declared projects -> https://github.com/dotnet/source-build/issues/3040. This will allow us to collect only auto-updated dependencies while not interfering with dependency versions that the project has pinned.
produce a project-specific PackageVersion.props file from the current and previous source-build versions -> https://github.com/dotnet/source-build/issues/3041.
consume projects' PackageVersion.props files when source-building the entire product -> https://github.com/dotnet/source-build/issues/3042.

Furthermore, there are several issues that are worth mentioning:

repositories should utilize the latest versions of project dependencies (enforcement of this rule is not part of MVP)

having non-latest versions would require additional support from SB in terms of adding a ref pack for every version
maintaining and upgrading the pack would be costly
additional packs would bloat the size of the end tarball
SBRP in general should not contain any pre-release versions

rollout of the proposed changes should be gradual

additional work would probably be required for on-boarding existing repositories to the new version handling (ex.: adding SBRPs or bumping dependencies to latest)

tarball should be offline-buildable

PackageVersion.props files can be resolved with access to the feeds (meaning online) before the actual build is started

Once this functionality is picked up by each repo and within the tarball build, the existing infrastructure should be removed.

tarball should be offline-buildable
PackageVersions.props files can be resolved with access to the feeds (meaning online) before the actual build is started

This is certainly doable today with the current tarball creation process but becomes significantly more difficult with the VMR.  We should discuss this at one of our syncs w/@premun and @crummel

Once this functionality is picked up by each repo and within the tarball build, the existing infrastructure should be removed.

Thank you for reminding me about it, I will create a separate issue for it since it can be achieved only after the repos are on the new system, which can take some time

tarball should be offline-buildable
PackageVersions.props files can be resolved with access to the feeds (meaning online) before the actual build is started

This is certainly doable today with the current tarball creation process but becomes significantly more difficult with the VMR. We should discuss this at one of our syncs w/@premun Premek Vysoky FTE and @crummel Chris Rummel FTE

Based on the info received on the sync, it seems that the PackageVersions.props files are resolved offline, so this might not be an issue anymore, correct?

@mmitche - Is this work completed?  I know we have the repo consumption side of this which is tracked in #3043.

Yep, this is completed.


Only require a program state per chord date for windowed features

Potentially we could even split a program in to windowed and non-windowed features when we do program fusion.

Optimisation. Perhaps too complicated for little gain


GH action Android NDK build failing

GH action Android NDK seems to fail:
https://github.com/openthread/openthread/actions/runs/5141290740/jobs/9266852284
2023-06-01T16:48:02.1826387Z ##[group]Run actions/checkout@ac593985615ec2ede58e132d2e21d2b1cbd6127c
2023-06-01T16:48:02.1826663Z with:
2023-06-01T16:48:02.1826839Z   submodules: true
2023-06-01T16:48:02.1827066Z   repository: openthread/openthread
2023-06-01T16:48:02.1827445Z   token: ***
2023-06-01T16:48:02.1827639Z   ssh-strict: true
2023-06-01T16:48:02.1827856Z   persist-credentials: true
2023-06-01T16:48:02.1828071Z   clean: true
2023-06-01T16:48:02.1828252Z   fetch-depth: 1
2023-06-01T16:48:02.1828441Z   lfs: false
2023-06-01T16:48:02.1828644Z   set-safe-directory: true
2023-06-01T16:48:02.1828842Z ##[endgroup]
2023-06-01T16:48:02.1832152Z ##[command]/usr/bin/docker exec  a302f54f5e3393ff720c846c9eda75a91372fd4174e190a8a9f4d9dc841b79bb sh -c "cat /etc/*release | grep ^ID"
2023-06-01T16:48:02.4809067Z Syncing repository: openthread/openthread
2023-06-01T16:48:02.4810712Z ##[group]Getting Git version info
2023-06-01T16:48:02.4811151Z Working directory is '/__w/openthread/openthread'
2023-06-01T16:48:02.4811689Z [command]/usr/bin/git version
2023-06-01T16:48:02.4811911Z git version 2.17.1
2023-06-01T16:48:02.4825770Z ##[endgroup]
2023-06-01T16:48:02.4829099Z Deleting the contents of '/__w/openthread/openthread'
2023-06-01T16:48:02.4834427Z The repository will be downloaded using the GitHub REST API
2023-06-01T16:48:02.4834814Z To create a local Git repository instead, add Git 2.18 or higher to the PATH
2023-06-01T16:48:02.4886356Z ##[error]Input 'submodules' not supported when falling back to download using the GitHub REST API. To create a local Git repository instead, add Git 2.18 or higher to the PATH.
2023-06-01T16:48:02.5017774Z Post job cleanup.

Looks like the issue is with the container used for this:
    container:
      image: openthread/environment

It needs to have git version > 2.18.
(relevant/similar discussion -> https://github.com/actions/checkout/issues/758#issuecomment-1426266741)
To unblock, for now, submitted https://github.com/openthread/openthread/pull/9123 to skip this job.

Thanks for looking into this, @abtink !
I triggered a new build of the openthread/environment image. The checks seems to be passing now.


construct search_paths response type with oneOf to avoid circular reference

search_paths should be oneOf "more search path", "end/leaf".

does not help. Hardcode search path depth instead!


Login Nodes are no longer reported in pcluster describe-cluster

In AWS ParallelCluster 3.8.0b1 the login nodes were reported in the pcluster describe-cluster output. This is now missing in 3.8.0. It would be great to find a way that this information can be extracted again for down-stream reporting purposes.
{
  "creationTime": "2023-12-15T11:34:10.265Z",
  "headNode": {
    ....
  },
  "version": "3.8.0b1",
  "clusterConfiguration": {
    "url": "XXXX"
  },
  "cloudFormationStackStatus": "UPDATE_COMPLETE",
  "clusterName": "XXX",
  "computeFleetStatus": "RUNNING",
  ....
  "scheduler": {
    "type": "slurm"
  },
**
  "loginNodes": {
    "status": "active",
    "address": "XXXX.elb.eu-west-1.amazonaws.com",
    "scheme": "internet-facing",
    "healthyNodes": 4,
    "unhealthyNodes": 0
  }
**
}

Apologies - the above is wrong - login nodes and elb are still listed with AWS ParallelCluster 3.8.0. Feel free to delete this issue.


Interactive bots: Create a translation bot.

Automated message from Dropbox CLA bot
@royabouhamad, it looks like you've already signed the Dropbox CLA. Thanks!

Hello, @royabouhamad! Thank you for working on this, it looks great.
I've made a few comments on your PR, could you address those?
I also noticed that you mix double and single quotes ('/") in your strings. Please, switch them all to single quotes, since it's how it looks in the majority of Zulip's codebase.
The Language_Codes.md file doesn't seem to be proper Markdown, maybe you were trying to show a table? In that case, the proper way to do so is like this:
| Language name | Code |
| ------------- | ---- |
| Afrikaans     | af   |
| Arabic        | ar   |
| etc           | etc  |

Thanks!

By the way, our convention for commit messages specifies that the tag in the title message (in your case, Interactive bots) should be lowercase (s/Interactive/interactive).
Don't worry, that's just me being picky. Just take it into account for future commits, if you don't mind :)