HBASE-28832 Upgrade from bootstrap 3.4.1 to non vulnerable version 5.3.3

This is the backport of https://github.com/apache/hbase/pull/6490/ for branch-2.6.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 43s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
jshint
0m  0s

jshint was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ branch-2.6 Compile Tests _

+0 :ok:
mvndep
0m 13s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m  2s

branch-2.6 passed

+1 :green_heart:
compile
5m 41s

branch-2.6 passed

+1 :green_heart:
checkstyle
1m 13s

branch-2.6 passed

+1 :green_heart:
spotbugs
10m  5s

branch-2.6 passed

+1 :green_heart:
spotless
0m 43s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 51s

the patch passed

+1 :green_heart:
compile
5m 33s

the patch passed

+1 :green_heart:
javac
5m 33s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
1m 11s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
spotbugs
10m 49s

the patch passed

+1 :green_heart:
hadoopcheck
15m 40s

Patch does not cause any errors with Hadoop 2.10.2 or 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 43s

patch has no errors when running spotless:check.

_ Other Tests _

+1 :green_heart:
asflicense
0m 53s

The patch does not generate ASF License warnings.

62m 28s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless jshint shellcheck shelldocs

uname
Linux 8dbd1b8dd909 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
branch-2.6 / d286744e94c8365062a505d0550d8951a2627a57

Default Java
Eclipse Adoptium-11.0.23+9

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

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

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

versions
git=2.34.1 maven=3.9.8 spotbugs=4.7.3 shellcheck=0.8.0

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 50s

Docker mode activated.

-0 :warning:
yetus
0m  7s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.6 Compile Tests _

+0 :ok:
mvndep
0m  7s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 50s

branch-2.6 passed

+1 :green_heart:
compile
2m  3s

branch-2.6 passed

+1 :green_heart:
javadoc
3m 19s

branch-2.6 passed

+1 :green_heart:
shadedjars
5m 15s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 16s

the patch passed

+1 :green_heart:
compile
1m 58s

the patch passed

+1 :green_heart:
javac
1m 58s

the patch passed

+1 :green_heart:
javadoc
4m 27s

the patch passed

+1 :green_heart:
shadedjars
5m 21s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
39m 48s
/patch-unit-root.txt
root in the patch failed.

73m 14s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux f47e24d1721e 5.4.0-200-generic #220-Ubuntu SMP Fri Sep 27 13:19:16 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/hbase-personality.sh

git revision
branch-2.6 / d286744e94c8365062a505d0550d8951a2627a57

Default Java
Eclipse Adoptium-17.0.11+9

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

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

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

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

versions
git=2.34.1 maven=3.9.8

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 49s

Docker mode activated.

-0 :warning:
yetus
0m  4s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.6 Compile Tests _

+0 :ok:
mvndep
0m 14s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
3m 19s

branch-2.6 passed

+1 :green_heart:
compile
2m  8s

branch-2.6 passed

+1 :green_heart:
javadoc
2m 59s

branch-2.6 passed

+1 :green_heart:
shadedjars
6m  2s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 59s

the patch passed

+1 :green_heart:
compile
2m  8s

the patch passed

+1 :green_heart:
javac
2m  8s

the patch passed

+1 :green_heart:
javadoc
2m 55s

the patch passed

+1 :green_heart:
shadedjars
6m  2s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
46m 12s
/patch-unit-root.txt
root in the patch failed.

79m  2s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux d22ad5e1ba12 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
branch-2.6 / d286744e94c8365062a505d0550d8951a2627a57

Default Java
Eclipse Adoptium-11.0.23+9

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

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

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

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

versions
git=2.34.1 maven=3.9.8

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 52s

Docker mode activated.

-0 :warning:
yetus
0m  4s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.6 Compile Tests _

+0 :ok:
mvndep
0m 14s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 52s

branch-2.6 passed

+1 :green_heart:
compile
1m 53s

branch-2.6 passed

+1 :green_heart:
javadoc
3m 14s

branch-2.6 passed

+1 :green_heart:
shadedjars
5m 34s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 41s

the patch passed

+1 :green_heart:
compile
1m 56s

the patch passed

+1 :green_heart:
javac
1m 56s

the patch passed

+1 :green_heart:
javadoc
3m 14s

the patch passed

+1 :green_heart:
shadedjars
6m 22s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
53m 53s
/patch-unit-root.txt
root in the patch failed.

86m 21s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux 9856126cd667 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
branch-2.6 / d286744e94c8365062a505d0550d8951a2627a57

Default Java
Temurin-1.8.0_412-b08

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

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

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

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

versions
git=2.34.1 maven=3.9.8

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

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  8s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+0 :ok:
jshint
0m  0s

jshint was not available.

+0 :ok:
shelldocs
0m  0s

Shelldocs was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
hbaseanti
0m  0s

Patch does not have any anti-patterns.

_ branch-2.6 Compile Tests _

+0 :ok:
mvndep
0m 11s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 33s

branch-2.6 passed

+1 :green_heart:
compile
7m 50s

branch-2.6 passed

+1 :green_heart:
checkstyle
1m 20s

branch-2.6 passed

+1 :green_heart:
spotbugs
13m 43s

branch-2.6 passed

+1 :green_heart:
spotless
1m  2s

branch has no errors when running spotless:check.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 25s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 54s

the patch passed

+1 :green_heart:
compile
7m 14s

the patch passed

+1 :green_heart:
javac
7m 14s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
checkstyle
2m  8s

the patch passed

+1 :green_heart:
shellcheck
0m  0s

No new issues.

+1 :green_heart:
spotbugs
13m 57s

the patch passed

+1 :green_heart:
hadoopcheck
22m 36s

Patch does not cause any errors with Hadoop 2.10.2 or 3.3.6 3.4.0.

+1 :green_heart:
spotless
0m 44s

patch has no errors when running spotless:check.

_ Other Tests _

+1 :green_heart:
asflicense
0m 54s

The patch does not generate ASF License warnings.

85m 23s

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless jshint shellcheck shelldocs

uname
Linux 11bd622fcf96 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
branch-2.6 / 59553ca50f5db3458909814650685b6e33bb5962

Default Java
Eclipse Adoptium-11.0.23+9

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

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

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

versions
git=2.34.1 maven=3.9.8 spotbugs=4.7.3 shellcheck=0.8.0

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m  9s

Docker mode activated.

-0 :warning:
yetus
0m  6s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.6 Compile Tests _

+0 :ok:
mvndep
0m 11s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
4m 21s

branch-2.6 passed

+1 :green_heart:
compile
2m 42s

branch-2.6 passed

+1 :green_heart:
javadoc
3m 46s

branch-2.6 passed

+1 :green_heart:
shadedjars
7m 56s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 17s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 35s

the patch passed

+1 :green_heart:
compile
2m 45s

the patch passed

+1 :green_heart:
javac
2m 45s

the patch passed

+1 :green_heart:
javadoc
3m 48s

the patch passed

+1 :green_heart:
shadedjars
7m 12s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
477m 39s
/patch-unit-root.txt
root in the patch failed.

522m 55s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux faadc1ccfd33 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
branch-2.6 / 59553ca50f5db3458909814650685b6e33bb5962

Default Java
Eclipse Adoptium-17.0.11+9

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

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

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

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

versions
git=2.34.1 maven=3.9.8

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 41s

Docker mode activated.

-0 :warning:
yetus
0m  5s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.6 Compile Tests _

+0 :ok:
mvndep
0m 12s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m  5s

branch-2.6 passed

+1 :green_heart:
compile
3m 29s

branch-2.6 passed

+1 :green_heart:
javadoc
4m  4s

branch-2.6 passed

+1 :green_heart:
shadedjars
6m 41s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
3m 31s

the patch passed

+1 :green_heart:
compile
2m 40s

the patch passed

+1 :green_heart:
javac
2m 40s

the patch passed

+1 :green_heart:
javadoc
3m 28s

the patch passed

+1 :green_heart:
shadedjars
6m 54s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
486m 52s
/patch-unit-root.txt
root in the patch failed.

532m  0s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux a29a527b125d 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
branch-2.6 / 59553ca50f5db3458909814650685b6e33bb5962

Default Java
Eclipse Adoptium-11.0.23+9

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

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

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

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

versions
git=2.34.1 maven=3.9.8

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

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 49s

Docker mode activated.

-0 :warning:
yetus
0m  6s

Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck

_ Prechecks _

_ branch-2.6 Compile Tests _

+0 :ok:
mvndep
0m 22s

Maven dependency ordering for branch

+1 :green_heart:
mvninstall
2m 38s

branch-2.6 passed

+1 :green_heart:
compile
2m 17s

branch-2.6 passed

+1 :green_heart:
javadoc
3m 16s

branch-2.6 passed

+1 :green_heart:
shadedjars
5m 33s

branch has no errors when building our shaded downstream artifacts.

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 12s

Maven dependency ordering for patch

+1 :green_heart:
mvninstall
2m 41s

the patch passed

+1 :green_heart:
compile
1m 52s

the patch passed

+1 :green_heart:
javac
1m 52s

the patch passed

+1 :green_heart:
javadoc
3m 12s

the patch passed

+1 :green_heart:
shadedjars
5m 27s

patch has no errors when building our shaded downstream artifacts.

_ Other Tests _

-1 :x:
unit
557m 23s
/patch-unit-root.txt
root in the patch failed.

592m 51s

Subsystem
Report/Notes

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

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

Optional Tests
javac javadoc unit compile shadedjars

uname
Linux c05f03a17d6b 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
branch-2.6 / 59553ca50f5db3458909814650685b6e33bb5962

Default Java
Temurin-1.8.0_412-b08

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

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

modules
C: hbase-resource-bundle hbase-http hbase-server hbase-thrift hbase-rest . U: .

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

versions
git=2.34.1 maven=3.9.8

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

This message was automatically generated.


Create index.md

[x ] I have read freeCodeCamp's contribution guidelines.
[ x] My pull request has a descriptive title (not a vague title like Update index.md)
[ x] My pull request targets the master branch of freeCodeCamp.
[ x] None of my changes are plagiarized from another source without proper attribution.
[x ] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

@loginaccount Well done, thank you!
Congrats on your first-time contribution!


Support partially-signed trasnactions

Save/export partially-signed transactions
Load and sign existing partially-signed transactions

For this to work, should be able to:

Import a partially-signed transaction buffer
Include existing signatures during the transaction send
Export data model to store signatures

Need to make sure our mappings are precise, otherwise the signature becomes invalid

This also makes the transaction read only... if it's changed the signature is no longer valid

An implication of that is that you don't need to accurately regenerate the serialised version - it must already exist

just thinking the partial-signed transaction will expire in 150 blocks (approximately 1 min after it is generated), should there be something to indicate the user the expiry time of the transaction? This is so the user is not surprised when transaction expires if they read the instructions too long.

Hmmm really good point. I guess this should really be for nonce
transactions. Damn.
On Tue, 25 Oct 2022 at 11:22, Joseph @.***> wrote:

just thinking the partial-signed transaction will expire in 150 blocks
(approximately 1 min after it is generated), should there be something to
indicate the user the expiry time of the transaction? This is so the user
is not surprised when transaction expires if they read the instructions too
long.
—
Reply to this email directly, view it on GitHub
https://github.com/labeleven-dev/bettercallsol/issues/92#issuecomment-1289810131,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACVTZ32ILJGQUSXUKRJOUDWE4R43ANCNFSM6AAAAAARNORAUE
.
You are receiving this because you commented.Message ID:
@.***>

--
Sent from Gmail Mobile


Update OS in windows CI to use 16 core variant.

Ohh sorry, I thought you requested my review. Github email notifications are very confusing


Duplicate variables in function

Input:
package riscv;
  function string func();
    automatic string str = "str";
    return "";
  endfunction
endpackage

Output:
\_package: riscv (riscv::), id:23 test.sv:1:1: , endln:6:11, parent:unnamed, parID:22
  |vpiName:riscv
  |vpiFullName:riscv::
  |vpiDefName:riscv
  |vpiTaskFunc:
  \_function: (riscv::func), id:24, line:2:3, endln:5:14, parent:riscv::, parID:23
    |vpiName:func
    |vpiFullName:riscv::func
    |vpiVariables:
    \_string_var: (riscv::func::str), id:25, line:3:22, endln:3:25, parent:riscv::func, parID:24
      |vpiName:str
      |vpiFullName:riscv::func::str
      |vpiAutomatic:1
    |vpiVisibility:1
    |vpiReturn:
    \_string_var: , id:14, line:2:12, endln:2:18
    |vpiStmt:
    \_begin: (riscv::func), id:26, parent:riscv::func, parID:24
      |vpiFullName:riscv::func
      |vpiVariables:
      \_string_var: (riscv::func::str), id:27, line:3:22, endln:3:25, parent:riscv::func, parID:26
        |vpiName:str
        |vpiFullName:riscv::func::str
        |vpiAutomatic:1
      |vpiStmt:
      \_assign_stmt: , id:28, line:3:22, endln:3:33, parent:riscv::func, parID:26
        |vpiRhs:
        \_constant: , id:19, line:3:28, endln:3:33, parID:18
          |vpiDecompile:str
          |vpiSize:3
          |STRING:str
          |vpiConstType:6
        |vpiLhs:
        \_string_var: (riscv::func::str), id:29, line:3:22, endln:3:25, parID:28
          |vpiName:str
          |vpiFullName:riscv::func::str
          |vpiAutomatic:1
      |vpiStmt:
      \_return_stmt: , id:30, line:4:5, endln:4:11, parent:riscv::func, parID:26
        |vpiCondition:
        \_constant: , id:21, line:4:12, endln:4:14, parID:20
          |STRING:
          |vpiConstType:6
    |vpiInstance:
    \_package: riscv (riscv::), id:23 test.sv:1:1: , endln:6:11, parent:unnamed, parID:22

Note the three instances of string_var variable str with ids 25, 27 and 29. Issue is not specific to string only.

@alaindargelas Any pointers on what needs to happen here. I can work on this if you can provide some pointers.

@hs-apotell, this is not a duplication. They are all attached to different part of the tree, they are not in the same tree branch (That would be a duplication).

While create all variables in a given context (ie: a function), there should be a local symbol table that merge to a singleton all the variables that are the same.

This is also a byproduct of the cloning and it is why we discussed the need for a comparison operator, if you need to know these objects represent the same thing.

BTW, this is not an issue for either Yosys or Verilator UHDM plugins. Both tools / their UHDM-readers have a symbol table that reconcile these.

While create all variables in a given context (ie: a function), there should be a local symbol table that merge to a singleton all the variables that are the same.

Is this something that needs to be happen in Surelog or are you proposing we do this on our end?

BTW, this is not an issue for either Yosys or Verilator UHDM plugins. Both tools / their UHDM-readers have a symbol table that reconcile these.

Shouldn't this reconciliation happen as part of Surelog? If this is already implemented in other Surelog clients, we would just be reinventing the wheel again. Making it part of Surelog has other advantages like less memory usage which can be significant for large designs.


Extreme min/max for gaze coordinates

Hi,
When I run the following minimal example, I get extreme values for the min and max gaze position (0.0 and 100000000.0, respectively) that are well outside the stated gaze coordinates (GAZE_COORDS 0.00 0.00 1919.00 1079.00). Do you know why this is? Thanks in advance for your help.
from pyedfread import edf

samples, events, messages = edf.pread('SUB001.EDF')

print('min gaze coordinates ', samples.gx_right.min(), samples.gy_right.min())
print('max gaze coordinates ', samples.gx_right.max(), samples.gy_right.max())

Hi @kmbond ,
It could be bad samples from outside of a recorded trial. Try bounding the samples by the start and end times of a trial and see if its still like that. It could also be loss of lock on the eye (e.g. blink, etc).

Hmm, okay. Should this be the case using the sample data provided with the package (SUB001.EDF)?
These extreme values don't appear to be in the raw EDF or the ASC files. So I think it would be worth considering whether there's an issue with the parsing of the raw data to a pd.DataFrame.

Hmm. I admit I never looked at the sample data. I haven't noticed a problem with my own data but it's worth checking out. Will see if I can get it going in the next few days.

Hi. I took a look at one of our recent trial data sets. I can confirm that I am seeing similar to you. Outside of a trial I do get 0.0 for the minimum but not inside, possibly due to a lack of blinks but I'm speculating. The max is the same regardless. I don't see these numbers in the .asc.
Maybe the source code will reveal why?

I think your issue might be due to blinks, as they distort the actual x and
y gaze positions. When the eyelids are passing over the pupil the
calibrated model might be interpreting this as upward or downward movement
leading to such extreme values.
On Fri 27. Sep 2019 at 17:54, Greg Schwimer<EMAIL_ADDRESS>wrote:

Hi. I took a look at one of our recent trial data sets. I can confirm that
I am seeing similar to you. Outside of a trial I do get 0.0 for the minimum
but not inside, possibly due to a lack of blinks but I'm speculating. The
max is the same regardless. I don't see these numbers in the .asc.
Maybe the source code will reveal why?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nwilming/pyedfread/issues/16?email_source=notifications&email_token=AA7F73OXJQXSCLLMLCA7TZLQLYUDTA5CNFSM4I27Y4WKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7ZKWWY#issuecomment-535997275,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA7F73OPCKY4XJRTSQBC5ZLQLYUDTANCNFSM4I27Y4WA
.

If the extreme gaze data were due to blinks, then those extreme values should also be present in the ASC file (but they aren't). @selimonat?


[BUG] Metrics plugin missing in shenyu admin console

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
Description:
Deployed apache shenyu using k8s deployment files and enabled "metrics" in the configmap of Shenyu admin. However, I don't see the metrics plugin available in the admin UI.
Steps to Reproduce:

As per this doc: https://shenyu.apache.org/docs/deployment/deployment-k8s, deployed shenyu-admin & shenyu-bootstrap pods
In the shenyu-admin configmap, enabled metrics and deployed the configmap

Issues:

Metrics plugin is not available under Plugins section. PFA
As per our requirement, we have to fetch the Response times of each API path/endpoint. Is there a metric available in shenyu to get the response times?

Expected Behavior
No response
Steps To Reproduce
No response
Environment
ShenYu version(s):2.5.1

Debug logs
No response
Anything else?

Metrics plugin not in shenyu admin，
you can config metrics in application.yaml
  metrics:
    enabled: true
    name : prometheus
    host: <IP_ADDRESS>
    port: 8090
    jmxConfig:
    props:
      jvm_enabled: true

@yu199195 got it, thanks.
One quick question, though - Can we get the Response Times of each API endpoint/Path?

@yu199195 Actually, I was looking for a metric which gives the response times of each API endpoint that passes through the shenyu gateway. I was able to get the Request times for api calls, however I couldn't find any metric to get the response times. Can you please share some docs or info related to this? Thanks in advance!

Can someone please help me in figuring this out? Thanks!


fix: imagePullSecrets field missing

Context
On SNCF organization, clusters doesn't have internet. We worked with private registry an authentication.
The authentication required imagePullSecret field (SA or PodSpec).
TODO
/!\ This PR doesn't fix the problem on ETCD Operator. That required changes on CRD : https://github.com/storageos/etcd-cluster-operator/blob/main/api/v1alpha1/etcdcluster_types.go#L36
This case was seen with @chris-milsted on Slack 👍🏼

No need :)


Function to run CalcM for non nothing F[_], E types

CalcM provides shortcut methods to evaluate itself for cases where E ~ Nothing type as well as for F ~ Nothing type. It would be nice to have a shortcut method to run it for both non-nothing E and F[_] types. That would be useful if one fancies using CalcM in place of ReaderT/ExceptT/StateT monad stack with IO playing role of an underlying effect.

Will push it, here the current workaround
  def tailrecEither[F[+_]: Monad, R, S1, S2, E, A](
      calc: CalcT[F, R, S1, S2, E, A]
  )(r: R, init: S1): F[(S2, Either[E, A])] =
    calc.step(r, init).tailRecM {
      case Ok(state, value)                    => Right((state, Right(value))).pure[F]
      case Error(state, err)                   => Right((state, Left(err))).pure[F]
      case wrap: Wrap[_, r, s, S2, x, E, m, A] =>
        wrap.inner.map(x => Left(wrap.cont.success(wrap.state, x).step(wrap.input, wrap.state)))
    }


Pre and post hooks for assemble/run/etc scripts

@thoraxe @GrahamDumpleton @thesteve0 @bparees,
To improve user experience, when users are trying to add only a pre/post actions to standard assemble and run scripts, I'm collecting use-cases of that. I would like to ask you to share real use-cases or your thoughts whether this feature would be useful or it wouldn't.
Thank you!
Related links:

https://github.com/openshift/source-to-image/issues/154
https://trello.com/c/WpdJNDz7/524-5-as-a-sti-user-i-d-like-to-extend-the-default-scripts-evg

The first use-case that @thoraxe describes in his blog post, is to do a post-processing of the templates with gulp inject. As far I understand, it even could cover all the actions with gulp, because our assemble script knows nothing about gulp and build-in assemble can be used only for installing gulp.

I kinda miss the old V2 hooks system.
It would be nice if we had the option to have .sti/bin/assemble-{pre,post} if you want to use the existing script and then just run things before/after. But being that you can simply reference the script itself (https://trello.com/c/WpdJNDz7/524-5-as-a-sti-user-i-d-like-to-extend-the-default-scripts-evg#comment-564482fecb0867efa9ac6129) which I did not realize in the original #154, I'm kinda thinking about just closing #154.

@thoraxe introduce pre-assemble/post-assemble is part of what we're discussing which is why we want use cases to understand if introducing those actually solves enough of the problem to be useful (as opposed to use cases where you need to modify something in the middle of the assemble script execution).
and then the other debate is, as you've noted/implied, whether it's worth introducing those minimal hook points given that users can already effectively accomplish the same thing.

The action hook types you need and why as are as follows.
In the assemble phase you need:

pre_build - Executed prior to building application artefacts. This is needed to handle the case where a user needs to install a library or other package from source code which is not part of system build but is required to install application dependencies which are built/installed automatically, such as from Python package index (PyPi). Because system directories are not writable, the user would need to install any library or package into an area the user has access to. Where this may be is potentially going to differ based on S2I builder used due to fact that S2I builders may not use a consistent directory layout.
build_env - This is not executed separately, but would be executed inline using source in the assemble script.  It would be run such that any variables set in the hook would be automatically exported and user doesn't need to use export themselves. This is needed to allow a user to set environment variables dynamically, which are required for the latter build steps to install application dependencies or build other application artefacts. This would be required where pre_build was used to install a library or package and environment variables had to be set so that when installing application dependencies, it knows where to find the header files/libraries or programs, installed by the pre_build script. It might also be used to set up additional environment variables dynamically based on static values from the Docker image. The static nature of .s2i/environment is too limiting and why this way of dynamically overriding environment variables for later build steps is needed.
build - This is executed after application dependencies or other application artefacts have been built. This is needed where a build action is dependent on having application dependencies installed first.

In the run phase you need:

deploy_env - This is not executed separately, but would be executed inline using source in the run script. It would be run such that any variables set in the hook would be automatically exported and user doesn't need to use export themselves. This is needed to allow a user to set environment variables dynamically, which are required for the latter deployment steps or when starting up the application. This would be required where the environment variables need to be set dynamically based on values derived from a package installed as part of the build. It might also be used to set up additional environment variables dynamically based on static values from the Docker image. The static nature of .s2i/environment is too limiting and why this way of dynamically overriding environment variables for later build deployment is needed.
deploy - This is executed just before the run script starts up the application. This would be required where last minute steps to prepare data for the application is required, or where it may be necessary to run additional tasks as background processes.

Because setting of environment variables is allowed dynamically, and those same environment variables from deploy_env could be required in any interactive shell environment created using oc rsh, or script executed using oc exec, then deploy_env would need to be run inline with any script used to enable SCL packages via ENV, BASH_ENV or PROMPT_COMMAND hack.
One final twist that might necessitate an additional deploy_cfg action hook is where an application config file required before starting the application, needs to incorporate values from environment variables, static or dynamic. Editing on the fly of such configuration files to incorporate values from environment variables could be done from deploy_env but if that were done, it would be on the user to use a marker file to ensure that they don't run the action more than once, given that deploy_env could technically be executed more than once in the life of the container. Thus deploy_cfg could be implemented as a separate concept, with the run script, plus SCL enable script, managing the marker files itself to ensure not run more than once, thus meaning user doesn't need to worry about it.

deploy_cfg - This is executed after deploy_env and before deploy. It is required where it is necessary to generate application configuration files which incorporate values from environment variables. This must only be run once. It needs to also be run, if not already run, as a side effect of scripts run using oc exec or when a shell is created using oc rsh. This is necessary for cases of where using lifecycle hooks and it is only a script that is run, and not the main run script.

You can see an example implementation based around an existing S2I builder for the above, with exception of deploy_cfg at:

https://gitlab.com/osevg/s2i-action-hooks

It doesn't implement the deploy_cfg hook at this point due to uncertainties around whether S2I builders follow a consistent directory structure and thus where one can safely write a marker file to track whether the hook has already been run.
You can see a separate example where a config hook is used in:

https://github.com/GrahamDumpleton/warpdrive/blob/master/warpdrive/etc/warpdrive-start#L27

This latter example doesn't currently have equivalent of build_env and deploy_env hooks as it was trying to do it with a single hook script for setting environment for both build and deploy, but that has been found to be less than ideal given that it would be run twice and user would need to work out whether build or deployment and set environment variables selectively. Thus two separate scripts seen as better. So you don't get confused, this latter example is a generic system that can operate with Docker alone and doesn't require S2I. It works with S2I through a small shim wrapper to many from S2I script names to the way the system does things.
Since availability of any changes to accomodate action hooks is likely to be many months away, and because I have had to explain how to do this sort of stuff to multiple people over the past few weeks, I was aiming to write a blog post about how to implement it using the s2i-action-hooks repository as sample.
Do be aware that since that the s2i-actions-hooks sample is having to wrap existing assemble script, it needs to accomodate for the fact that source code would not have been copied into place yet. As a result pre_build hook needs to use files out of /tmp/srcif necessary. Where integrated properly into existing assemble script of an S2I builder, then the location of where hook scripts run can be better located, such as pre_build being after source code moved into correct location. Exact placement may vary based on specific S2I builders and the language used. Some S2I builders might need additional hooks, but the above would be a minimal set which covers bulk of potential use cases.

@GrahamDumpleton I agree with your explanation and I think this cover most of the cases.
Also I think that extended builds (or if something in the future replaces this) could/should split the build/assemble and the run phases, so making this more clear whenever crafting the scripts would greatly help.

@GrahamDumpleton Thank you for sharing with us such comprehensive explanation!

pre_build - Executed prior to building application artefacts. This is needed to handle the case where a user needs to install a library or other package from source code which is not part of system build but is required to install application dependencies which are built/installed automatically, such as from Python package index (PyPi). Because system directories are not writable, the user would need to install any library or package into an area the user has access to. Where this may be is potentially going to differ based on S2I builder used due to fact that S2I builders may not use a consistent directory layout.

pre_build sounds logical and natural but because S2I script for building is called assemble then I would rather call the pre hook as pre_assemble

if to build an application user needs to install a library to the system directories then clean and right way will be to create a custom builder that will have these libraries already installed. If I have to use a gem that requires system libraries, I won't download/install GCC and library's sources, compile them and after that install my gem, right? Unlike application's sources we can use the same version of the system library for all of the builds. In other words, this is a non-standard task and we shouldn't solve such tasks on the level of the assemble script.

(And even if user tries to do so, he always has writable /tmp directory.)

build_env - This is not executed separately, but would be executed inline using source in the assemble script. It would be run such that any variables set in the hook would be automatically exported and user doesn't need to use export themselves. This is needed to allow a user to set environment variables dynamically, which are required for the latter build steps to install application dependencies or build other application artefacts. This would be required where pre_build was used to install a library or package and environment variables had to be set so that when installing application dependencies, it knows where to find the header files/libraries or programs, installed by the pre_build script.

It is the consequence of choosing the wrong way. Preparation of the system for building and preparation of the sources are on the different levels. I'm trying to focus on solving application level tasks but this one should be fixed on the lower level by creating a custom builder.

It might also be used to set up additional environment variables dynamically based on static values from the Docker image. The static nature of .s2i/environment is too limiting and why this way of dynamically overriding environment variables for later build steps is needed.

I can't imagine real use-case for that, could you give me an example?
BTW maybe we can use the Ansible-way: if .s2i/environment is executable then S2I will source it. This could solve the problem with static nature of .s2i/environment file.

build - This is executed after application dependencies or other application artefacts have been built. This is needed where a build action is dependent on having application dependencies installed first.

When this should be executed — also before the assemble script?

deploy_env - This is not executed separately, but would be executed inline using source in the run script. It would be run such that any variables set in the hook would be automatically exported and user doesn't need to use export themselves. This is needed to allow a user to set environment variables dynamically, which are required for the latter deployment steps or when starting up the application. This would be required where the environment variables need to be set dynamically based on values derived from a package installed as part of the build. It might also be used to set up additional environment variables dynamically based on static values from the Docker image. The static nature of .s2i/environment is too limiting and why this way of dynamically overriding environment variables for later build deployment is needed.

Why are you named it deploy when it relates to run script? Deploy could puzzle users.
I see here that we're trying to solve another issue: sometimes we want to have different environments in the builder and runtime containers. I think that this should be solved separately.
Also it can be hard to "execute inline using source in the run script" because it requires modification of the run script. S2I doesn't manage and modify this script, it just executes it.

deploy - This is executed just before the run script starts up the application. This would be required where last minute steps to prepare data for the application is required, or where it may be necessary to run additional tasks as background processes.

Because setting of environment variables is allowed dynamically, and those same environment variables from deploy_env could be required in any interactive shell environment created using oc rsh, or script executed using oc exec, then deploy_env would need to be run inline with any script used to enable SCL packages via ENV, BASH_ENV or PROMPT_COMMAND hack.

Sounds complicated and looks like it does the same as put this script into /etc/profile.d

One final twist that might necessitate an additional deploy_cfg action hook is where an application config file required before starting the application, needs to incorporate values from environment variables, static or dynamic. Editing on the fly of such configuration files to incorporate values from environment variables could be done from deploy_env but if that were done, it would be on the user to use a marker file to ensure that they don't run the action more than once, given that deploy_env could technically be executed more than once in the life of the container. Thus deploy_cfg could be implemented as a separate concept, with the run script, plus SCL enable script, managing the marker files itself to ensure not run more than once, thus meaning user doesn't need to worry about it.

This is the case when user have to provide his own run script or even write a wrapper around his application.

Do be aware that since that the s2i-actions-hooks sample is having to wrap existing assemble script, it needs to accomodate for the fact that source code would not have been copied into place yet. As a result pre_build hook needs to use files out of /tmp/src if necessary

This sounds like a bug or at least something that can be improved.
Thank you for your time again, your feedback gave us a lot of information to think of.

if to build an application user needs to install a library to the system directories then clean and right way will be to create a custom builder that will have these libraries already installed.

Trying to do that in a hook script is also likely to run into permission problems since the scripts will not be run as root, so that's another good reason to customize the image instead.

The naming of the hook scripts using 'build' and 'deploy' is based on OpenShift 2 because it had a good naming convention and many users will be used to that. It only confuses people by completely ignoring the past and creating a completely different way of doing things.
I am not talking just about installing additional packages into system directories. Not everyone wants to go off and create a new custom S2I builder to install as a library what could be an application specific code library that can't be handled using the language packaging mechanism, that only makes their workflow even more complicated as they can't do everything in the build and instead then need to worry about building a new base image all the time as well if the library is being changed.
Various builders already have a compiler as part of the base image. Just because some builders don't, and because you haven't yourself encountered situations where building a custom library is necessary, doesn't mean one should take a very narrow view of what functionality an action hooks mechanism should provide. Both the pre_build and then subsequent build_env can be important in some cases.
You can't use dynamic evaluation of .s2i/environment as s2i embeds those variables in the Docker image itself. They aren't dealt with by the assemble or run scripts. It is needed to more easily allow users to copy environment variables into differently named environment variables, or multiple environment variables as dictated by application code or dependent packages where changing that code is more trouble than its worth or not possible. Ability to set dynamically also allows defaults to more easily be set where they aren't set from outside.
The build phase would be executed after the specific language S2I builder had installed packages using its system, such as pip in Python. The separate example repo I linked shows the relationship. It has to be after as this is where users can run steps which need those language packages installed first.
If you think the ENV, BASH_ENV or PROMPT_COMMAND hack is complicated, ask the developers why it was done that way in the first place for some S2I builders. They must have had there reasons. Personally I don't like it either and prefer a helper script inside of the image which is executed and given as arguments the real command to run. That way the helper script can set up the environment without having to resort to those hacks. There is an entrypoint script in some images which sort of provides that, but it is not part of what you can officially use, is not in PATH and could even be in different locations based on which builder it is since no guarantees about it.
As to deploy_cfg, the user can't just provide their own run script which wraps the running of the application. This is because the S2I builders don't provide that capability. They would have to write their own S2I builder. This is why the action hooks mechanism is needed in the first place, to allow such overrides. Wrapping the startup of the application also doesn't help with situation where that same step of generating configuration from environment variables needs to be done when running management commands such as in a lifecycle hook. In that case the target application is never even run, so having a wrapper around it doesn't help. Having to wrap every single management command you might need to run separately in a container is just extra work where it could all be handled in one way.
And finally, needing to reference stuff out of /tmp/src is not a bug, it is part of how S2I works to get the source code into an image. One could avoid it by integrating pre_build into the assemble script at the point after code is moved into place based on how S2I builder works, but I have come to the conclusion that it is better before with some working off /tmp/src at that point as allows for application to better override certain things about how code is moved around.

The naming of the hook scripts using 'build' and 'deploy' is based on OpenShift 2 because it had a good naming convention and many users will be used to that. It only confuses people by completely ignoring the past and creating a completely different way of doing things.

When technology changes, names sometimes need to change to.  We don't call things "gears" and "cartridges" anymore either.  "run" most closely maps to what you are doing with the image because it corresponds to what happens when you "docker run" the image.  And we're not going to go back and rename s2i's assemble step to "build" so as @php-coder says, pre_assemble makes more sense for a set of users who are going to need to become accustomed to "assemble" as a terminology (and assemble makes more sense than build since it's assembling an image, not just building source code).

Various builders already have a compiler as part of the base image. Just because some builders don't, and because you haven't yourself encountered situations where building a custom library is necessary, doesn't mean one should take a very narrow view of what functionality an action hooks mechanism should provide. Both the pre_build and then subsequent build_env can be important in some cases.

this is why we reached out to you, so you can provide examples of these requirements and help us understand if it's a "90% of people will need this" or "10% of people will need this".  These aren't easy problems to solve, we're not going to boil the ocean for 10% of users who would be better served to just replace the assemble script entirely.  That said, i'm not seeing what about your scenario isn't handle by a pre_assemble hook in this case, so hopefully we can reach an agreement that such a feature is a) useful and b) sufficient.

You can't use dynamic evaluation of .s2i/environment as s2i embeds those variables in the Docker image itself.

@php-coder was suggesting that there be two different modes.  Yes today the contents of the "environment" file get processed before we launch the assemble container and they are part of the container and thus included in what is committed.  But there could be an alternate mode in which instead of doing that, we simply "source" the environment file before running assemble.  That would be done inside the shell of the container, it would not alter the container config itself, and thus would not be part of the committed image.  I don't actually like overloading the meaning of "environment", i'd prefer a separate file, but the general concept remains the same.

The build phase would be executed after the specific language S2I builder had installed packages using its system, such as pip in Python.

there's basically no chance we're going to break assemble up into discrete sub-steps at this point with the ability to call hooks in between those steps.  Doing so would require either:

s2i image authors write assemble scripts that explicitly call out to hooks if they exist (too hard for authors to implement correctly, not backwards compatible, makes writing an assemble script significantly more complicated)
s2i explicitly breaks assemble up into multiple scripts ("assemble_deps","assemble_compile","assemble_package", etc).  Again this has backwards compatibility problems (even if we continue to tolerate an "assemble" script, someone using an image that only supplies assemble, while trying to leverage a "pre_assemble_compile" hook is not going to get a valid result) and introduces a higher burden on s2i script authors to break their assemble script up in logic ways (and in ways that may not even make any sense for their particular framework).

So unless we can demonstrate that this level of granularity is something 90% of users will need on a regular basis (which was the point of starting this discussion), I think we have to continue to punt this into the "override the assemble script either in your source repo or by creating your own custom s2i builder image" category, for cases that can't be handled by a pre_assemble or post_assemble hook.
v2 had a model closer to what you're describing and while it was very flexible, it seemed like:

most people didn't use hooks for much (at most a pre_start hook here and there)
very few people wrote new cartridges because the burden was too high to get those details correct

If you think the ENV, BASH_ENV or PROMPT_COMMAND hack is complicated, ask the developers why it was done that way in the first place for some S2I builders. They must have had there reasons.

it was done to ensure that no matter how you run the image or exec into a running image, the scl packages are enabled for you.  Just running a helper script via the entrypoint doesn't solve that, and i'm pretty sure /etc/profile.d isn't consistently processed depending on how entered the container.

As to deploy_cfg, the user can't just provide their own run script which wraps the running of the application. This is because the S2I builders don't provide that capability.

What do you mean?  you can replace the run script, or you can write a run script that, as its last action, calls the existing image run script.

The ENV, BASH_ENV or PROMPT_COMMAND does not work to always enable SCL packages. It will only work if you are running a shell script which then does what you need. It will not do what is required for something like:
oc exec xxx python ...

It will pick up the system Python and not the SCL Python.
The use of a helper script and saying to users that they should always use it when executing stuff in the container is more predictable.
oc exec xxx warpdrive exec python ...

The warpdrive exec command in this case always ensures that SCL is enabled, plus any environment variables set by hook scripts would always be set.
Wrapping the whole run script doesn't help where needing to do stuff from life cycle hooks. Have to replicate it for that as well. So am talking about in context of having one way which works in both cases, that is what isn't supported.
Anyway, lets call time on this. Perhaps should just be closed as not fix as can't see any progress ever being made on this.

I'm not sure how you can complain about picking up system Python versus SCL Python when that is the behavior whether or not you are in a Docker container or even doing anything with OpenShift.
"oc exec" will execute a command in the remote container. It's just wrapping "docker exec". If you "docker run registry..../python -it bash" and then do "python foo", you're going to get the system python.
In this particular case (oc exec) you are asking for OpenShift to make an assumption about what the user wants to do with the remote container where it actually doesn't know anything about the remote container.
The only way that this particular thing could work, in my understanding, is if "oc exec" actually looked at metadata on the container image that it was being run against, and, depending on that metadata, "wrapped" whatever you were trying to exec inside of an "scl enable".
In other words, there would need to be Docker/container metadata that was something like "openshift.exec.wrapper" and, if present, would be used... or something.
I'm also still not understanding the need to build a library that isn't in the s2i but that isn't "built" as part of the native language dependency processing. Ruby gems, for example, will get built if they are required but not present. This may involve complication. This "just works" as it stands already. Is Python not capable of that?

To sum up: right now we didn't decide anything except to put this off for the future.

@php-coder I think we decided/established more than that:
We established that the only realistic thing we can do here is pre/post hooks and that the target users (in this case our evangelists) felt that those did not provide sufficient benefit over the existing ability to replace the entire script and/or write a new script that invokes the existing script, to justify investing in building the feature.
We also defined some additional use cases (setting env variables) which can be covered by the aforementioned capabilities (env variables defined in shell scripts won't be in the final image).
Lastly, we concluded it was important to document how to reference the existing scripts when writing new scripts (in lieu of providing the explicit pre_assemble/post_assemble hook points), and produced product documentation to that effect.
@sspeiche fyi, this was one of the 3.4 items, so you should be aware of the direction it took.

As this discussion is being pushed out to others who may not be aware of the bigger picture beyond this issue, I will fill in that bigger picture as to where I am coming from and why I see this issue as not meeting the requirements I at least have.
When you look at languages such as node.js and npm, or Java and tools like Maven, they have quite developed eco systems for handling the build and deployment of applications. They already include within those systems ways of hooking in custom actions as different points within the build and deployment process. For example for npm you have:

http://www.marcusoft.net/2015/08/pre-and-post-hooks-for-npm-scripting.html

In the Python world the build tools are not that sophisticated, handling package installation and nothing else. You cannot use the package installation system to readily trigger any custom actions you may need to do around or as part of the installation process. There are also so many different ways of deploying Python web applications and there is not one single dominant method used. There is therefore no commonly accepted way of having custom actions run by the deployment server either.
The lack of easy customisation points in the Python S2I builder is thus going to be felt much more acutely than builders for other languages.
In trying to get hook points introduced into the Python S2I builder there was push back to say that it must be done consistently across all builders and thus why this issue against source-to-image has become the focus point for discussion.
Unfortunately in trying to address it for all S2I builders you are trying to come up with a simplified one size fits all strategy which ignores that specific languages and the ecosystems around them may have different requirements. Some of the comments challenging why something would even be required show that there is lack of exposure to the extra challenges that exist in Python due to the short comings of the package installer for Python, plus the diversity of both Python web application servers and Python web frameworks or web toolkits.
The desire to keep things simple and avoid providing deeper integration with a specific S2I builder means that for Python at least, the solution you seem to want may not meet the requirements, or could be just as unwieldy as having nothing and telling people to work out a way of doing it themselves. It may even be better to recommend they use a different Python S2I builder developed by the community which can better address what the Python community feels they need.
So in that context of me trying to develop something that better meets the Python communities requirements, this back and forth discussion is not productive and I am better off working with the community to develop their own solution. There are also with the S2I builder more series issues which still aren't being addressed which this discussion just seems to be taking focus away from. So maybe if this issue is dropped the more serious issues will be fixed.

@GrahamDumpleton thanks, the distinction of "this functionality needs to be provided in a python specific way" vs "this problem should be solved in a generic way that works for all s2i builders" is a valuable one and definitely a key point that I was not picking up on until your most recent explanation.
I am definitely not averse to making the s2i-python builder image's assemble logic more sophisticated so as to handle the scenarios you have in mind, if indeed we are convinced that such logic is not generically applicable to s2i as an ecosystem.  (Or we are convinced that there is no suitable way to bring such generic logic to s2i(ie a way that doesn't make writing s2i builders significantly more painful or fragmented) and less need for it in other builders, which I think might be closer to the situation here).
When we started this issue, we were operating on the impression that significant numbers of users were finding it necessary to override the default scripts.  I'm still not sure we've actually gotten data to confirm that one way or another, or to answer the secondary question of whether pre/post hooks are sufficient to prevent users from having to replace the entire script when they do need to override behavior, but it sounds like at least in the case of python, the answer is "yes it's typical to need to override and no pre/post hooks aren't sufficient".
If anyone else on this thread has data about their experiences w/ other images, we'd still be interested in that, but for now we're proceeding with the documentation approach over implementing new capabilities.

Hi folks, I'm writing from Santander Group, we have been working with OpenShift from a long time. From our point of view, we think S2I should support hooks or extension points which allow users to run corporative process at any time (qa, security, etc). If S2I doesn't support this feature, we need use Jenkins and it no sense to use S2I for only for build task.

@dcortesf You might be interested in:

https://github.com/getwarped/action-hooks

It provides an example structure for doing it yourself within your source code repository.


🚀 Feature Request: It isn't clear that R2 buckets bound in wrangler dev are local

Describe the solution
I'm sure R2 isn't the only product with this issue, but:
Here's the output of wrangler dev with a bucket bound:
> wrangler dev ./src/index.ts

 ⛅ wrangler 3.78.4 (update available 3.78.8)
-------------------------------------------------------

Your worker has access to the following bindings:
- R2 Buckets:
  - BUCKET: asdfasdf
⎔ Starting local server...
[wrangler:inf] Ready on http://localhost:8787

When you have a bucket on R2 named asdfasdf, it's really confusing why your Worker is 404ing fetches from that bucket in wrangler dev.

Wonder if this should be a part of a bigger UX improvement?
Even a simple BINDING_NAME: <name> (local mode) would be much better than the current.


The library claims client state is RxBleClient.State.READY even when location service is off (Android 10 location changes)

Describe the bug
This is for applications targeting API 22.  This is due to the check in LocationServicesStatusApi23.isLocationProviderEnabledRequired() that assumes that location services is not required for apps targeting API 22 - on Android 10 (API 29), this is not the case. Location services is required regardless of which Android version the app targets.
To Reproduce
Steps to reproduce the behavior:

Create app targeting API 22
Have app observe RxBleClient.observeStateChanges()
After installing the app, grant location permission (either normal or 'only while app is in use')
Ensure Bluetooth is on and Location is off in Android settings
Launch the app
RxBleClient.State.READY is emitted by RxBleClient.observeStateChanges() which should not be the case

Specific application where the above situation occurs - https://github.com/sandy-8925/BLExplorer/blob/modernization_v2/android/src/main/java/org/ligi/blexplorer/BluetoothController.kt#L56
Expected behavior
RxBleClient.State.LOCATION_SERVICES_NOT_ENABLED should be emitted by RxBleClient.observeStateChanges() in this case
Smartphone (please complete the following information):

Device: OnePlus 5
OS: Android 10
Library version: 1.11.1

Logs from the application when bug occurs (this will greatly help in quick understanding the problem)
To turn on logs use:
RxBleClient.updateLogOptions(new LogOptions.Builder()
        .setLogLevel(LogConstants.DEBUG)
        .setMacAddressLogSetting(LogConstants.MAC_ADDRESS_FULL)
        .setUuidsLogSetting(LogConstants.UUIDS_FULL)
        .setShouldLogAttributeValues(true)
        .build()
);

// please paste the logs here

@sandy-8925 Ping?

Is the app in your case able to scan? Or Is there some kind of an error emitted? I see no logs.

It's not able to scan i.e no devices show up. Only after location services is turned on, and the app is restarted, is it able to scan and pick up devices.
I don't think any error was emitted, but I'll try reproducing it and see if there's anything relevant in the logs (like stacktrace or system error/warning).

I have just pushed a branch fix/location_check_api_28 which uses a new function in LocationManager to check if location is on. Could you try that branch/commit and report if it fixes the problem? I do not have access to such a device.
You can use JitPack for testing purposes.

@sandy-8925 Ping?

I tested, and unfortunately, the problem still remains. The problem is in this function - LocationServicesStatusApi23.isLocationProviderEnabledRequired() which checks return !isAndroidWear && targetSdk >= Build.VERSION_CODES.M
Since the target SDK of the app is API 22, this function returns false, thus resulting in the library thinking that location service is not required at all. The function you changed CheckerLocationProvider.isLocationProviderEnabled() never gets called because of this.

Correct me if I am wrong but you should not be able to upload such an application to Play Store now?
Anyway – could you get me information which Android OS stops respecting target SDK < 22 and checks for location permission anyway?

That limitation applies to the Play Store only, it doesn't apply to sideloaded Android apps. They library isn't limited to only being used in Play Store apps.
This app I used it in, is an open source app that I forked. It's distributed through FDroid.
The problem occurs on Android 10 and above, which seems to enforce location permission requirement for Bluetooth scanning, regardless of target level.

Do you know if the same does apply to android wear?

I am not aware of the behaviour on WearOS , but it should be the same.

Check the latest commit on that branch

Jitpack does not seem to generate a proper POM file and other dependencies are not correctly fetched. This should go away with a proper release

Ok, it looks like problem solved then. Thanks!

Fix available in 1.12.1


fix(TDI-39525): Missing properties for Wizard Backport to 651

What is the current behavior? (You can also link to an open issue here)
see https://github.com/Talend/components/pull/991
What is the new behavior?
Please check if the PR fulfills these requirements

[ ] The commit message follows Talend standard
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features) ?
[ ] The code coverage on new code >75%
[ ] The new code does not introduce new technical issues (sonar / eslint)

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build / CI related changes
[ ] Other... Please describe:

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information:

Pull request test result: success :star:
Sonar results


Add support for Bls12381G2 keys in kms-local

The kms-local implementation only supports a fixed set of key types. It is not possible to extend the current implementation as it is today to include a new key type like 'Bls12381G2'.
The asManagedKeyInfoInner method where the key types are checked is private. If you derive the base class to add new key types, you basically need to copy/clone that private method for supporting the existing key types (Ed25519, Secp256k1 and X25519) + new ones (Bls12381G2). Also that method expects 'RequireOnly<ManagedPrivateKey, 'privateKeyHex' | 'type'>)' as input. That assumes the public key can actually be derived from the private key all the time. I haven't found any implementation for Bls12381G2 keys that derive the public key from the private one, so I was expecting to also pass the public key as optional if it can not be derived.
This is for generating a new DID key for Bls12381G2 keys.
I've implemented something that works, but as I said, it is not ideal as I had to duplicate code from your implementation.
https://github.com/pcibraro/veramo/blob/next/packages/kms-bbs/src/key-management-system.ts

Perhaps we can use this to generate public keys from private: https://github.com/paulmillr/noble-bls12-381#getpublickeyprivatekey

ah, no, that library uses G1 for public keys and G2 for signatures

see my other comment about KMS too: https://github.com/uport-project/veramo/issues/895#issuecomment-1145937162

relates to #605


Classical RL

Refer #6

Is this issue for all classical Rl algos?

Yeah we dont really require separate issues for them, do we?

Which all have you started? I will do the others if you don't have any problem.

I'm done with bandits (UCB and Thompson Sampling), so SARSA is still left from that list

Cool i'll do that.

Bernoulli, Beta, Bayesian Bandits and Thompson Sampling. Will raise a separate PR for that. Still figuring out some details for that.


Santaleous questions

Maybe is interesting part about minion tap,and how him can use his ability more time per turn http://www.vekn.net/forum/rules-questions/58209-santaleous-questions?start=6

The part about minion tap is interesting indeed, I'd like to add a ruling, but I'll need a reference to a Rules Director post.

I'll add the part about Santaleous for now.

we dont know who be director this time,maybe someone of these guys. ankha become director later. maybe is good check somehow who be director in what years,by some topic i conclude how izzak be director one time

FYI this is the rules directors list, there are only 4 in the game history as far as I know:
2016-12-04 Vincent Ripoll (ANK)
2011-07-06  Pascal Bertrand (PIB)
1998-06-22 L. Scott Johnson (LSJ)
1994-12-15 Thomas R Wylie (TOM)
Shawn F. Carnes (SFC) has made some official rulings between 1995 and 1997. Maybe he filled in for a short period where TOM was not available, I don't know.

Anyhow, I added the Santaleous part @ https://github.com/lionel-panhaleux/krcg/commit/b0838c9b65c27db0b764b125eca177cc6b1922de . I'll try to find a link for minion tap and open a separate issue.


Remove semicolon from iteration example to avoid confusion.

This page: https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures-v8/learn-introductory-javascript-by-building-a-pyramid-generator/step-36
Has the example bees = bees + 3; This creates confusion and sometimes people add the semicolon at the end of the iteration statement in a for loop.
Solution: remove the semicolon.

Thanks for opening this issue.
This looks like something that can be fixed by "first-time" code contributors to this repository. Here are the files that you should be looking at to work on a fix:
List of files:

https://github.com/freeCodeCamp/freeCodeCamp/blob/ff7e0cf6826088bbc851d5102fa7c36ae4e4b12c/curriculum/challenges/english/15-javascript-algorithms-and-data-structures-22/learn-introductory-javascript-by-building-a-pyramid-generator/660f1b6e60bd9edf902c81fd.md
https://github.com/freeCodeCamp/freeCodeCamp/blob/ff7e0cf6826088bbc851d5102fa7c36ae4e4b12c/curriculum/challenges/english/15-javascript-algorithms-and-data-structures-22/learn-introductory-javascript-by-building-a-pyramid-generator/660f1b6e60bd9edf902c81fd.md#L12

Please make sure you read our guidelines for contributing, we prioritize contributors following the instructions in our guides. Join us in our chat room or our forum if you need help contributing; our moderators will guide you through this.
Sometimes we may get more than one pull request. We typically accept the most quality contribution followed by the one that is made first.
Happy contributing.


Splitting into several datasets depending on sample type

We could use the he fields “environmental_sample” and “host” fields to split the data. Users will probably want to know whether a bacteria comes from the water of a river or the guts of a fish.
We could have:

a dataset for eDNA: environmental_sample=True
a dataset for organism sequenced: environmental_sample=False & host=“”
a dataset with hosts? If so, we have to think about how to model this (these are probably questions for https://github.com/tdwg/dwc-qa if there aren't already guidelines for that):

should the host be an occurrence as well?
how do we map the relationship between host and sequence organism?
Should we use the fields associatedOccurrences or associatedOrganisms for example?

This makes good sense to me.

Can we please try and create the 3 datasets as described above and index them in UAT, in addition to the current one so we have something concrete to discuss. It is possible we'll then apply different deduplication processes on each type.

Can we please try and create the 3 datasets as described above and index them in UAT, in addition to the current one so we have something concrete to discuss. It is possible we'll then apply different deduplication processes on each type.

@ManonGros I'm going to create those on UAT. Do we have any title preference please?

@ManonGros I'm going to create those on UAT. Do we have any title preference please?

I don't have a particularly strong feeling about the titles but I suggest something like that:

INSDC sequences from environmental samples
INSDC sequences associated with hosting organisms
INSDC sequences - excluding environmental samples and sequences associated with host organisms

For the last one, we can only infer that they correspond to sequenced organism, it could also be that people just didn't bother to fill in the metadata. That's why I phrased it like that.

I don't have a particularly strong feeling about the titles but I suggest something like that:

INSDC sequences from environmental samples
INSDC sequences associated with hosting organisms
INSDC sequences - excluding environmental samples and sequences associated with host organisms

For the last one, we can only infer that they correspond to sequenced organism, it could also be that people just didn't bother to fill in the metadata. That's why I phrased it like that.

Thanks @mike-podolskiy90 !
Here are my comments:

For the INSDC sequences associated with hosting organisms dataset:

I think we have to show the host organism. As far as I understand, there is no standard way to do this at the moment.

I imagine that using a resourceRelationship extension would be the most Darwin Core proper thing to do.
I can also see that we could use the associatedTaxa term.
And there is always the dynamicProperties term.
-> I suggest to use both the associatedTaxa term and the  dynamicProperties term ({"hostingOrganism":"Lutra lutra"}. Would that make sense?

I don't think that it would be a good idea to keep human diseases. Could we consider excluding record where host="Homo sapiens"?
I also wonder whether we should include viruses. Perhaps if we exclude the human diseases we wouldn't need to exclude viruses.

For all three datasets, we still have the duplicate issue. See for example, the 3M pine tree records in the newest version on UAT. I suggest to check https://github.com/gbif/embl-adapter/issues/3 and consider the solutions discussed to remove duplicates.
For all three datasets, is there any way we could include some higher taxonomy? I can see that a lot of records have no match in our taxonomy. It would be really helpful to have at least a Kingdom for example. @thomasstjerne do you know if it would be possible?
For all three datasets, this is more a suggestion for the mapping (https://github.com/gbif/embl-adapter/blob/master/DATAMAPPING.md). For non preserved specimens, we could include the culture_collection and/or the bio_material as catalogueNumber or include them in the dynamicProperties. What do you think?

It would require a API call for each occurrence (I guess you could memoize the response for each taxonID) to add some higher classification and is only possible through their XML service:
https://www.ebi.ac.uk/ena/browser/api/xml/2697049

Nice to see the split view, I agree! A few comments to @ManonGros comments:

Old dream, if this would be easy, we would have so many other communities happy, too. If implemented, it would be a very nice GBIF improvement (requested by the modelling community). Note that one can simply display a host reported with the data, but TDWG IG on species interactions is working on revision of how to handle 2+ species occurrences, and interaction attribute: what I mean a quick display fix could be possible with available DwC fields, but with acceptance that we will likely need to revise / rebuild it, esp. if species interactions are part of next strategic plan. I am all in support of live experimenting.
Can we anyhow try the contig_set trick as recommended by Guy, and have sub-views with and without lumping applied. Or ask them to experiment with this? Ideally we would set the call with EMBL with these three displayed and with dedup solutions at hand.
Previsouly with UNITE we asked the publisher to add higher taxonomy. What comes to my mind, if we can assume coordinate systems and fuzzy matches, why cannot we "guess" higher taxonomy and show that this is a GBIF guess in the issues? Skip homonyms perhaps?
Culture and tissue collection often have own catalogueNumbers, not sure anything but local IDs should be there ? To me culture collection and bio_material is very important, and it belongs to improving basis of record story.
Yes, we also observed viruses with Mikhail when looking at the first, undivided version. +1 for exclusion by H. sapiens, but for the blanket removal of viruses (from all GBIF?), this is a major decision that would at least need SC blessing.

I think associatedTaxa is way better than dynamicProperties which is rather opaque.
What is the reasoning behind excluding human host records and diseases? Isn't this potentially valuable? If we could get all Corona tests recorded I guess we would have some serious bias in GBIF data. But are we not used to that already with birds? I don't have a strong opinion, just trying to understand the reasoning. Assuming we would be able to filter searches by the host then.

This is really great to have the higher taxonomy, thanks @mike-podolskiy90!
Some feedback concerning the newest version of the datasets published:

for records that have been deduplicated, for example: https://www.gbif-uat.org/occurrence/2889240632, it would be good to include all the corresponding accessions in the associatedSequences and the references fields. For example: https://www.ebi.ac.uk/ena/browser/view/KE161220 | https://www.ebi.ac.uk/ena/browser/view/KE161176 | https://www.ebi.ac.uk/ena/browser/view/KE161095 ... It will look messy because we can have up to 3M of these but I think this is the only way we can ensure transparency.
For the INSDC sequences associated with hosting organisms dataset, would it be possible to add the hosting organism (host) in the associatedTaxa field, something like "host":"Lutra lutra"?

It will look messy because we can have up to 3M of these but I think this is the only way we can ensure transparency.

Micro-encoding 3M values in a CSV cell will likely lead to issues including memory, timeouts on page loads etc. I'd suggest exploring an extension to capture that info with 3M rows.

@timrobertson100 I understand the issue but then we will need to decide:

will the "main" accession number (occurrenceID / associatedSequences / references) be chosen randomly? Or do we want to have some rule for that?
Which extension to use? @thomasstjerne any thought on this issue?


Adds faker.computed to generate computed values

Adds faker.computed to generate computed values
This update adds a new method to faker (faker.computed) that allows you to
create custom values based on combining faker methods with other things (like
strings, numbers, or other faker methods)
This update also refactors some of the functions used in Helix to their own
separate files, as well as adds the appropriate comment docs.
Example
const props = {
  fname: faker.name.firstName(),
  lname: faker.name.lastName()
}
const value = faker.computed(props)(values => {
  const { fname, lname } = values
  return `${fname} ${lname}`
})

console.log(value())
// Michelle Santos

Seeding
Computed values support seeding! The seed value is passed in when the computed value is instantiated. When generated with HelixSpec.generate, this is done automatically.
const props = {
  fname: faker.name.firstName(),
  lname: faker.name.lastName()
}
const value = faker.computed(props)(values => {
  const { fname, lname } = values
  return `${fname} ${lname}`
})

// Generate the computed value, with a seed value of 23
console.log(value(23))

Resolves: https://github.com/helpscout/helix/issues/2

Coverage remained the same at 100.0% when pulling 1f3b99178df0b848abcfa78d052503f380ba99d2 on computed-values into 7a3c30a59dee6ebd9ebea5093ac84a484120b83d on master.


Impossible to mock CreatedDate and LastUpdateDate

Hello,
When using @CreatedDate and @LastUpdateDate annotation with JPAAuditing, it is impossible to override the current time with our own value.
Test example :

Entity :

The entity saved in database

EnableAuditing, JpaTests and any classic test annotations can save the day.

Hello ! Can you share what this step does ?

Perhaps you meant * the current time is... ?

Hello, It was a test step written by me to define sys time to a mocked date. You can ignore that

If you're still using it, can you please provide its implementation so we better understand the issue and what can be done around it ?

No, I'm not still using it, in fact, I deleted it

Then, I close this ticket!


Is it possible to process different size by pre-trained model?

Hello, I want to process full-HD images by the model which trained with patches sized 256x256, is it possible? And how to do that? Thanks!

I just modified something in inference.py, and change placeholder shape in export_grphy.py to None. It can accept any size now.
export_grphy.py (on about line 30)
    input_image = tf.placeholder(tf.float32, shape=[None, None, 3], name='input_image')

inference.py (on about line 28)
input_image = tf.image.decode_jpeg(image_data, channels=3)
input_image = tf.image.resize_images(input_image, size=(FLAGS.height, FLAGS.width))
input_image = utils.convert2float(input_image)
input_image.set_shape([FLAGS.height, FLAGS.width, 3])


Shell Integration indicator always empty circle when PROMPT_COMMAND is two functions

Issue Type: Bug
I do not see the error or success icons for the gutter icon on my shell integration enabled terminals; instead it is always the empty circle.
The integration appears to otherwise be working (the Go to Recent Directory and Run Recent Command commands are working as expected).
I presume that somehow, the integration is not picking up the result of the operation being run. For reference, I am using https://github.com/magicmonty/bash-git-prompt but otherwise don't believe I have anything special in my Bash configuration that would affect this.
VS Code version: Code 1.68.0 (Universal) (4af164ea3a06f701fe3e89a2bcbb421d2026b68f, 2022-06-08T11:44:00.250Z)
OS version: Darwin x64 21.5.0
Restricted Mode: No

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz (12 x 2600)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmetal: disabled_offmultiple_raster_threads: enabled_onoop_rasterization: enabledopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
4, 4, 4

Memory (System)
16.00GB (0.02GB free)

Process Argv
--crash-reporter-id 5dc19a1b-275e-4628-a94c-a51e6ce0beb2

Screen Reader
no

VM
0%

Extensions (76)

Extension
Author (truncated)
Version

Bookmarks
ale
13.3.0

project-manager
ale
12.6.0

vscode-sqlite
ale
0.14.1

atlascode
atl
2.10.12

github-markdown-preview
bie
0.3.0

jsdoc-markdown-highlighting
bie
0.0.1

markdown-checkbox
bie
0.3.2

markdown-emoji
bie
0.2.1

markdown-footnotes
bie
0.0.7

markdown-mermaid
bie
1.14.0

markdown-preview-github-styles
bie
1.0.1

markdown-yaml-preamble
bie
0.1.0

gitignore
cod
0.7.0

vscode-markdownlint
Dav
0.47.0

vscode-eslint
dba
2.2.2

xml
Dot
2.5.1

gitlens
eam
12.0.7

EditorConfig
Edi
0.16.4

graphviz-preview
EFa
1.5.0

flow-for-vscode
flo
2.1.0

vscode-mysql
for
0.4.1

copilot
Git
1.28.6134

remotehub
Git
0.34.0

vscode-pull-request-github
Git
0.44.0

go
gol
0.33.1

todo-tree
Gru
0.0.215

triggertaskonsave
Gru
0.2.17

vscode-guid
hea
1.4.20

path-autocomplete
ion
1.19.1

tablegenerator
Jay
1.0.4

plantuml
jeb
2.17.2

svg
joc
1.4.18

docthis
joe
0.7.1

vscode-position
jtr
1.1.2

yarn-lock-syntax
mar
0.1.3

Kotlin
mat
1.7.1

vscode-language-babel
mgm
0.0.36

pull-request-quantifier
ms-
0.1.2

extension-manifest-editor
ms-
0.1.5

csharp
ms-
1.25.0

dotnet-interactive-vscode
ms-
1.0.3309020

network-edge-devtools
ms-
1.0.0

data-workspace-vscode
ms-
0.2.0

mssql
ms-
1.14.2

sql-bindings-vscode
ms-
0.1.0

sql-database-projects-vscode
ms-
0.16.2

vscode-postgresql
ms-
0.3.0

python
ms-
2022.8.0

vscode-pylance
ms-
2022.6.10

jupyter
ms-
2022.5.1001601848

jupyter-keymap
ms-
1.0.0

jupyter-renderers
ms-
1.0.8

hexeditor
ms-
1.9.6

powershell
ms-
2022.5.1

remote-repositories
ms-
0.12.0

vscode-js-profile-flame
ms-
1.0.2

vsliveshare
ms-
1.0.5615

vsliveshare-pack
ms-
0.4.0

resourcemonitor
mut
1.0.7

vscode-commons
red
0.0.6

vscode-yaml
red
1.8.0

sass-indented
rob
1.5.1

gitconfig
sid
2.0.1

mdx
sil
0.1.0

codevalet-vscode
Sop
1.5.0

vcl
tho
0.1.2

msbuild-project-tools
tin
0.4.3

jest-snapshot-language-support
tle
1.1.1

intellicode-api-usage-examples
Vis
0.1.1

vscodeintellicode
Vis
1.2.21

vscode-icons
vsc
11.12.0

quokka-vscode
Wal
1.0.478

wallaby-vscode
Wal
1.0.338

jinja
who
0.0.8

ReactSnippets
xab
2.4.0

vscode-proto3
zxh
0.5.5

(2 theme extensions excluded)

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vstes516:30244333
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonvspyt551cf:30345471
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30445986
pythondataviewer:30285071
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
vsc1dst:30438360
pythonvs932:30410667
wslgetstarted:30449410
vscscmwlcmt:30465135
cppdebug:30492333
vsclangdc:30486549

It's working fine for me (I have the icon customized):

This is with a fresh install of stable bash-git-prompt https://github.com/magicmonty/bash-git-prompt#installation
Version: 1.69.0-insider
Commit: ab6ba241145bb81c8bc0f323453bbec45fd66109
Date: 2022-06-10T05:16:48.648Z
Electron: 17.4.7
Chromium: 98.0.4758.141
Node.js: 16.13.0
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 21.5.0
Could you see if it happens on the insiders build?

I am installing the Insiders build now. I will let you know. 🤞🏻

Hmmm, doesn't seem to work.

How does it detect the exit code? Perhaps I have something installed that is interfering, either in my bash config or elsewhere?

Yeah it's meant to change depending on the exit code of the program. Some info that would help us investigate:

Set log level to debug via the command palette, then in Help > Developer Tools console it will show some shell integration related logs when you run a command
Do you set $PS1 or $PROMPT_COMMAND anywhere?
Do you use bash-preexec?

Set log level to debug via the command palette, then in Help > Developer Tools console it will show some shell integration related logs when you run a command

I'll get this going and let you know.

Do you set $PS1 or $PROMPT_COMMAND anywhere?

Ah yes, besides using bash-git-prompt, I have this in my bash config:
flush_history_and_reload() {
  # Read all history from the history file not already read and append to the
  # history list.
  history -n

  # Write the current history to the history file.
  history -w

  # Clear the history list.
  history -c

  # Read the history file into the history list.
  history -r
}

export HISTCONTROL=ignoreboth:erasedups
if [[ $PROMPT_COMMAND != *flush_history_and_reload* ]]; then
  PROMPT_COMMAND="$PROMPT_COMMAND;flush_history_and_reload"
fi

I'll try disabling that and see what happens. It would be a shame to lose it but perhaps there's a better way of implementing that so that it's compatible, if that turns out to be the issue.

Do you use bash-preexec?

Not that I am aware of, no.

OK, so I disabled my PROMPT_COMMAND change and tried a few things in a new terminal that weren't working before.
Now, when I use ls it is still an empty circle, but when I do echo, I get the green success lozenge!!
So I'm guessing that was the main issue; though I do wonder if I should be seeing that green circle for ls and such too (that said, this is the non-Insiders build - I'll try Insiders in a second). I'll add the log level and see what I get.

I can confirm that the Insiders build works as advertised now, so it was my history manipulation code that was getting in the way. 🤦🏻
Thank you for helping out. I'll close this issue as it appears to be an issue on my side, not yours. Thank you for helping troubleshoot.

Let's keep this open to track the issue so we handle it better.

@Tyriar would you like me to gather the logging info as requested, since this is staying open?

@somewhatabstract I think we understand the problem enough to reproduce it, it's just a case we need to detect and handle better.

This is happening because we actually depend on history to differentiate regular commands that succeeded or failed vs ones exited via ^C or running an empty line. Specifically this call:
https://github.com/microsoft/vscode/blob/4c60b2fd34c1c378418d497bbe8a653f262bccd3/src/vs/workbench/contrib/terminal/browser/media/shellIntegration-bash.sh#L79
I'll disable shell integration if HISTCONTROL includes erasedups as that specifically is the reason it was failing.

This bug has been fixed in the latest release of VS Code Insiders!
@somewhatabstract, you can help us out by commenting /verified if things are now working as expected.
If things still don't seem right, please ensure you're on version 0b3574dcef8f35fec4ee4f83dc958c1f16ef6fce of Insiders (today's or later - you can use Help: About in the command palette to check), and leave a comment letting us know what isn't working as expected.
Happy Coding!

/verified
I see that the integration is not enabled as the lozenges are missing.


Use case

I find this plugin interesting but I'm not sure what the use case is.
What is the purpose of opening things in modal windows? Can someone help me understand the benefit?
Thanks!

This plug-in itself is not aimed at any pain points. It only originates from personal preferences, but to some extent, it can also bring some convenience. For example, when editing certain documents, I like to quickly view certain web pages in the modal window, or quickly create an excalidraw image as an example diagram. Opening a new tab makes me feel like it is detached from the current document, and the modal window is like a part of the current document. Of course, there is no difference between superiority and inferiority. It is just a personal preference, and I also hope more people will share the use case.

Thank you for explaining. That's kind of what I suspected but now that I know its intention I will try it out :)


IB: credit limit by market

https://github.com/CreamFi/comptroller-upgrade/blob/ib_credit_limit_by_market/test/upgrade.js


[Feature request] YouTube music backend

Hey,
I really like the interface and usage of spot. Could it be possible to add an alternative YouTube Music backend?
In this case you don't need any registered account or premium membership.
There's already a gtk youtube music client over here https://github.com/misterhat/youtube-music-gtk
Best regards
Jonas

Seems like it falls out of scope for the project. And looks to be a severe undertaking.


Fix bridge initialization for IPv6 if IPv4-only docker0 exists

This fixes the daemon's failure to start when setting --ipv6=true for
the first time without deleting docker0 bridge from a prior use with
only IPv4 addressing.
The addition of the IPv6 bridge address is factored out into a separate
initialization routine which is called even if the bridge exists, but no
IPv6 addresses are found.
Docker-DCO-1.1-Signed-off-by: Phil Estes<EMAIL_ADDRESS>(github: estesp)

ping @jfrazelle: here is the IPv6 startup bug fix.  @icecrime I know 1.5.0 is close, but this would be a nice-to-have for those wanting to play with IPv6 for the first time and not hit an annoying bug right out of the gate.  Without it, we probably need a release note warning that you must delete your existing docker0 bridge before trying IPv6.

Thanks! I'm tentatively adding the milestone but I think it's gonna be hard.
Ping @LK4D4

@LK4D4 thanks for the quick look--I fixed the error logging to be more useful. PTAL

ping @maltej want to make sure we get his opinion on this, and I am testing now

So after discussion with @LK4D4, he told me something I didn't know, which is that missing around with daemon network flags already mandates that you delete the bridge in some cases. Obviously this is not ideal, but it does changes my understanding of the urgency of this PR.
I'm moving to milestone 1.5.1.

@icecrime as I mentioned in IRC, no problem.  But what @LK4D4 is talking about rarely causes daemon unable to start/immediate failure (I fixed the worst ones in prior PR for IPv4) :)

LGTM

LGTM

Alright you win :p

Thanks for this PR! This prevents lots of people from running into this problem.
LGTM

Alright you win, it's 1.5.0 ;-) Thanks for the reviews guys!