"linking with rust-lld failed" when compiling BIOS

I got the following error trying to build bios. I have successfully built some other examples (ferris, fs, hello_world and monkey).
error: linking with `rust-lld` failed: exit code: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "C:\\Users\\renhe\\AppData\\Local\\Temp\\rustci0ZOiV\\symbols.o" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\deps\\bios-dd9b20a8139ede00.bios.59bee40b-cgu.0.rcgu.o" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\deps\\bios-dd9b20a8139ede00.5dfc63nowul9hpyw.rcgu.o" "--as-needed" "-L" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\deps" "-L" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\release\\deps" "-L" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\build\\psx-4fa2646774207910\\out" "-L" "C:\\Users\\renhe\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\mipsel-sony-psx\\lib" "-Bstatic" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\deps\\libbytemuck-e3e6e7a5223e4a8f.rlib" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\deps\\libpsx-cc211b81ab3b3833.rlib" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\deps\\liblinked_list_allocator-5b0b3e84bbae530b.rlib" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\deps\\liballoc-16042111529a6aac.rlib" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\deps\\librustc_std_workspace_core-9b88d97047bd756f.rlib" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\deps\\libcore-67000f1dbeeb79dc.rlib" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\deps\\libcompiler_builtins-3b687ead3f7c55ff.rlib" "-Bdynamic" "--eh-frame-hdr" "-znoexecstack" "-L" "C:\\Users\\renhe\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\mipsel-sony-psx\\lib" "-o" "C:\\Users\\renhe\\Documents\\GitHub\\psx-sdk-rs\\examples\\target\\mipsel-sony-psx\\release\\deps\\bios-dd9b20a8139ede00.exe" "--gc-sections" "-O1" "-Tpsexe.ld" "--oformat=binary"
  = note: rust-lld: error: undefined symbol: main
          >>> referenced by psx.6664e7ff-cgu.0
          >>>               psx-cc211b81ab3b3833.psx.6664e7ff-cgu.0.rcgu.o:(__start) in archive C:\Users\renhe\Documents\GitHub\psx-sdk-rs\examples\target\mipsel-sony-psx\release\deps\libpsx-cc211b81ab3b3833.rlib

error: could not compile `bios` due to previous error

Are you building the bios with cargo psx build --link bios.ld like in its README?
undefined symbol: main leads me to think that it's using the default psexe.ld instead of bios.ld since the former pulls in the __start function in psx/src/runtime.rs which calls an unmangled main function.
Also lld isn't supported for building the bios yet since it doesn't set the load address from the ld script correctly. cargo should use mipsel-linux-gnu-ld because it's set in examples/bios/.cargo/config.toml but if that's not getting picked you can set the CARGO_TARGET_MIPSEL_SONY_PSX_LINKER environment variable to mipsel-linux-gnu-ld or mipsel-unknown-elf-ld and cargo build psx --link bios.ld should just work.


[PREVIEW] SSCS-3946 Evidence received

Send COR specific notifications when we set an evidence received event.

QA verified


[Bug] surface_vehicles.md workspace wget command not working

Environment

Ubuntu 22.04:
Source (gz-sim8, 2ca64d032)

per@per ~ $ mkdir ~/gazebo_maritime_ws
wget https://raw.githubusercontent.com/gazebosim/gz-sim/gz-sim8/tutorials/files/surface_vehicles/gazebo_maritime_ws -o ~/gazebo_maritime_ws -r
wget: /home/per/gazebo_maritime_ws: Is a directory

Description

Expected behavior: The command from the surface_vehicles.md page to work.
Actual behavior: The error above, under the details section.

Steps to reproduce

Run this command:
mkdir ~/gazebo_maritime_ws
wget https://raw.githubusercontent.com/gazebosim/gz-sim/gz-sim8/tutorials/files/surface_vehicles/gazebo_maritime_ws -o ~/gazebo_maritime_ws -r
Output
wget: /home/per/gazebo_maritime_ws: Is a directory
Thanks!

Thanks for reporting it, see #2330 .

Nice, thanks for the fast response!

I got around the wget issues, but now when trying to run the sydney_regatta, I get the following error:
[Err] [SystemLoader.cc:119] Failed to load system plugin: (Reason: Could not find shared library)

Requested plugin name: [maritime::PublisherPlugin]
Requested library name: [libPublisherPlugin.so]
Library search paths:

/home/per/.gz/sim/plugins/
/usr/lib/x86_64-linux-gnu/gz-sim-7/plugins/
/home/per/.ignition/gazebo/plugins/
[Err] [SystemLoader.cc:119] Failed to load system plugin: (Reason: Could not find shared library)

Requested plugin name: [maritime::WaveVisual]
Requested library name: [libWaveVisual.so]
Library search paths:

/home/per/.gz/sim/plugins/
/usr/lib/x86_64-linux-gnu/gz-sim-7/plugins/
/home/per/.ignition/gazebo/plugins/

I tried exporting the gazebo plugin paths to the binaries, but it still did not work.
export GAZEBO_PLUGIN_PATH=/home/per/gz-sim/tutorials/files/surface_vehicles/gazebo_maritime_ws/install/lib:${GAZEBO_PLUGIN_PATH}


HDFS-15557. Log the reason why a storage log file can't be deleted

https://issues.apache.org/jira/browse/HDFS-15557
NOTICE
Please create an issue in ASF JIRA before opening a pull request,
and you need to set the title of the pull request which starts with
the corresponding JIRA issue number. (e.g. HADOOP-XXXXX. Fix a typo in YYY.)
For more details, please see https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

-1 :x:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
29m 28s
trunk passed

+1 :green_heart:
compile
1m 17s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
compile
1m 10s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
checkstyle
0m 48s
trunk passed

+1 :green_heart:
mvnsite
1m 20s
trunk passed

+1 :green_heart:
shadedclient
16m 16s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 53s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 26s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+0 :ok:
spotbugs
3m  0s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
2m 57s
trunk passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m  7s
the patch passed

+1 :green_heart:
compile
1m  8s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

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

+1 :green_heart:
compile
1m  2s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

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

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

+1 :green_heart:
mvnsite
1m  9s
the patch passed

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

+1 :green_heart:
shadedclient
13m 53s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 46s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 24s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
findbugs
3m  4s
the patch passed

_ Other Tests _

-1 :x:
unit
94m 29s
hadoop-hdfs in the patch passed.

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

177m 27s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.balancer.TestBalancer

hadoop.hdfs.server.blockmanagement.TestBlockStatsMXBean

hadoop.hdfs.TestFileChecksum

hadoop.hdfs.server.blockmanagement.TestUnderReplicatedBlocks

hadoop.hdfs.server.namenode.TestNameNodeRetryCacheMetrics

hadoop.hdfs.TestFileChecksumCompositeCrc

hadoop.hdfs.TestDFSInotifyEventInputStreamKerberized

hadoop.hdfs.server.sps.TestExternalStoragePolicySatisfier

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux a5a6b91bbc09 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 139a43e98e2

Default Java
Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/1/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

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

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

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

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

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

Powered by
Apache Yetus 0.13.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

-1 :x:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
28m 13s
trunk passed

+1 :green_heart:
compile
1m 17s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
compile
1m 11s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
checkstyle
0m 49s
trunk passed

+1 :green_heart:
mvnsite
1m 18s
trunk passed

+1 :green_heart:
shadedclient
16m 15s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 51s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 22s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+0 :ok:
spotbugs
2m 58s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
2m 56s
trunk passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 11s
the patch passed

+1 :green_heart:
compile
1m  8s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

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

+1 :green_heart:
compile
1m  4s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

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

-0 :warning:
checkstyle
0m 40s
hadoop-hdfs-project/hadoop-hdfs: The patch generated 2 new + 3 unchanged - 0 fixed = 5 total (was 3)

+1 :green_heart:
mvnsite
1m 12s
the patch passed

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

+1 :green_heart:
shadedclient
13m 51s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 51s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 25s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
findbugs
3m  7s
the patch passed

_ Other Tests _

-1 :x:
unit
97m 52s
hadoop-hdfs in the patch passed.

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

207m 42s

Reason
Tests

Failed junit tests
hadoop.hdfs.TestFileChecksumCompositeCrc

hadoop.hdfs.TestMultipleNNPortQOP

hadoop.hdfs.TestFileAppend4

hadoop.hdfs.TestErasureCodingExerciseAPIs

hadoop.hdfs.TestFileChecksum

hadoop.hdfs.server.sps.TestExternalStoragePolicySatisfier

hadoop.hdfs.TestDFSStripedOutputStream

hadoop.hdfs.TestDFSStripedOutputStreamWithFailure

hadoop.hdfs.server.balancer.TestBalancerWithMultipleNameNodes

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux c407a908478b 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 139a43e98e2

Default Java
Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/2/artifact/out/diff-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/2/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

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

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

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

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

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

Powered by
Apache Yetus 0.13.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

-1 :x:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
28m  6s
trunk passed

+1 :green_heart:
compile
1m 16s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
compile
1m 12s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
checkstyle
0m 48s
trunk passed

+1 :green_heart:
mvnsite
1m 20s
trunk passed

+1 :green_heart:
shadedclient
16m 25s
branch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 52s
trunk passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 27s
trunk passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+0 :ok:
spotbugs
3m  0s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
2m 58s
trunk passed

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
1m 10s
the patch passed

+1 :green_heart:
compile
1m 10s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

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

+1 :green_heart:
compile
1m  3s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

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

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

+1 :green_heart:
mvnsite
1m  8s
the patch passed

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

+1 :green_heart:
shadedclient
13m 54s
patch has no errors when building and testing our client artifacts.

+1 :green_heart:
javadoc
0m 45s
the patch passed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1

+1 :green_heart:
javadoc
1m 19s
the patch passed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

+1 :green_heart:
findbugs
3m  4s
the patch passed

_ Other Tests _

-1 :x:
unit
94m 42s
hadoop-hdfs in the patch passed.

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

176m 26s

Reason
Tests

Failed junit tests
hadoop.hdfs.server.namenode.TestNameNodeRetryCacheMetrics

hadoop.hdfs.server.sps.TestExternalStoragePolicySatisfier

hadoop.hdfs.TestReconstructStripedFile

hadoop.hdfs.TestFileChecksumCompositeCrc

hadoop.hdfs.server.blockmanagement.TestBlockTokenWithDFSStriped

hadoop.hdfs.TestFileChecksum

hadoop.hdfs.TestGetFileChecksum

Subsystem
Report/Notes

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

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

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

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 139a43e98e2

Default Java
Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/3/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

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

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

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

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

versions
git=2.17.1 maven=3.6.0 findbugs=4.0.6

Powered by
Apache Yetus 0.13.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

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

_ Prechecks _

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

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

-1 :x:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ trunk Compile Tests _

-1 :x:
mvninstall
16m 16s
root in trunk failed.

-1 :x:
compile
0m 17s
hadoop-hdfs in trunk failed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.

-1 :x:
compile
0m 26s
hadoop-hdfs in trunk failed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01.

+1 :green_heart:
checkstyle
0m 51s
trunk passed

-1 :x:
mvnsite
0m 25s
hadoop-hdfs in trunk failed.

+1 :green_heart:
shadedclient
1m 49s
branch has no errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 26s
hadoop-hdfs in trunk failed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.

-1 :x:
javadoc
0m 26s
hadoop-hdfs in trunk failed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01.

+0 :ok:
spotbugs
3m  8s
Used deprecated FindBugs config; considering switching to SpotBugs.

-1 :x:
findbugs
0m 25s
hadoop-hdfs in trunk failed.

_ Patch Compile Tests _

-1 :x:
mvninstall
0m 22s
hadoop-hdfs in the patch failed.

-1 :x:
compile
0m 22s
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.

-1 :x:
javac
0m 22s
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.

-1 :x:
compile
0m 21s
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01.

-1 :x:
javac
0m 21s
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01.

-0 :warning:
checkstyle
0m 20s
The patch fails to run checkstyle in hadoop-hdfs

-1 :x:
mvnsite
0m 23s
hadoop-hdfs in the patch failed.

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

+1 :green_heart:
shadedclient
0m 21s
patch has no errors when building and testing our client artifacts.

-1 :x:
javadoc
0m 23s
hadoop-hdfs in the patch failed with JDK Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.

-1 :x:
javadoc
0m 23s
hadoop-hdfs in the patch failed with JDK Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01.

-1 :x:
findbugs
0m 22s
hadoop-hdfs in the patch failed.

_ Other Tests _

-1 :x:
unit
0m 21s
hadoop-hdfs in the patch failed.

+0 :ok:
asflicense
0m 22s
ASF License check generated no output?

59m  1s

Subsystem
Report/Notes

Docker
ClientAPI=1.40 ServerAPI=1.40 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/Dockerfile

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

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 62e70170050b 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 7a6265ac425

Default Java
Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01

mvninstall
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/branch-mvninstall-root.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/branch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/branch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01.txt

mvnsite
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/branch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/branch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01.txt

findbugs
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/branch-findbugs-hadoop-hdfs-project_hadoop-hdfs.txt

mvninstall
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/patch-mvninstall-hadoop-hdfs-project_hadoop-hdfs.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.txt

javac
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.txt

compile
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01.txt

javac
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/patch-compile-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01.txt

checkstyle
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/buildtool-patch-checkstyle-hadoop-hdfs-project_hadoop-hdfs.txt

mvnsite
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/patch-mvnsite-hadoop-hdfs-project_hadoop-hdfs.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkUbuntu-11.0.8+10-post-Ubuntu-0ubuntu118.04.1.txt

javadoc
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/patch-javadoc-hadoop-hdfs-project_hadoop-hdfs-jdkPrivateBuild-1.8.0_265-8u265-b01-0ubuntu2~18.04-b01.txt

findbugs
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/patch-findbugs-hadoop-hdfs-project_hadoop-hdfs.txt

unit
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/testReport/

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

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-2274/4/console

versions
git=2.17.1 maven=3.6.0

Powered by
Apache Yetus 0.13.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

Not sure why the build came out so badly... let's see if we can retrigger.

@liuml07 any further comments?

+1
Not sure why the QA is not coming back cleanly here...not related to the change.


Support ExtraTuple type

Initial Checks

[X] I have searched Google & GitHub for similar requests and couldn't find anything
[X] I have read and followed the docs and still think this feature is missing

Description
Currently, there's no tuple that can generate a TuplePositionalSchema with the extra_schema field being set. In other words, there's no way to do it with either tuple or typing.Tuple, since Tuple[str, int, ...] is not supported in Python (as ... needs to be the second argument).
The idea here would be to create an ExtraTuple, that could be used like ExtraTuple[int, str, ...]. On this case, the str would be the extra_schema, and int would be the prefixItems.
Affected Components

[ ] Compatibility between releases
[X] Data validation/parsing
[ ] Data serialization - .model_dump() and .model_dump_json()
[X] JSON Schema
[ ] Dataclasses
[ ] Model Config
[X] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[ ] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

I think this would be cool, especially as we already support it in pydantic-core.

The implementation in pydantic-core is quite complex. Although it’s already there I think there’s something to be said for waiting for user requests. Unless there’s already an existing one we can link here,


Rear left calf motor does not receive command

Hi!
We are doing a research with the Unitree A1 robot. So we made our own locomotion controller and run it on an Intel NUC placed on top of the robot. We connect the NUC via LAN cable to the LAN port on the Jetson NX of the robot.
Everything works fine for most conditions, including stairs and rough terrain. However, we have a strange issue. Everytime the robot climbs a relatively steep slope (maybe around 18 degree), the rear left calf suddenly crippled.
When we log the data of the motor, we noticed that for that leg only, the control mode became 0x00 (or 8), which according to the A1 Dev. guide indicates 'electronic braking mode' due to disconnection protection. However, I couldn't find further details about it.
We checked the LowState and got this data at the time the leg crippled
Temperature, mode, reserve, torque, position, velocity
48.000000 10.000000 0.000000 24.382812 -1.543421 0.541724
48.000000 10.000000 0.000000 24.347656 -1.542578 0.028331
49.000000 10.000000 0.000000 24.347656 -1.540724 0.637019
48.000000 10.000000 0.000000 24.562500 -1.537394 1.049966
48.000000 10.000000 0.000000 17.593750 -1.530820 0.804430
48.000000 10.000000 0.000000 16.777344 -1.530778 -0.183723
48.000000 10.000000 0.000000 16.847656 -1.530736 0.254121
48.000000 10.000000 0.000000 17.308594 -1.528418 0.723729
48.000000 8.000000 4.000000 3.234375 -1.523024 1.309238
49.000000 8.000000 4.000000 5.367188 -1.531073 -2.379808
48.000000 8.000000 4.000000 3.339844 -1.539923 -1.243990
49.000000 8.000000 4.000000 1.847656 -1.544179 -0.746909
48.000000 8.000000 4.000000 1.101562 -1.547508 -0.522837
49.000000 8.000000 4.000000 0.531250 -1.549616 -0.291896
49.000000 8.000000 4.000000 -0.035156 -1.550248 0.097012
48.000000 8.000000 4.000000 0.000000 -1.549953 -0.117617
48.000000 8.000000 4.000000 -0.035156 -1.549742 0.084135
It looks like everything did not surpass the motor limits. So I have no idea why this problem happens. And what does reserve=4 mean?
Notes:

The NUC is powered using an external battery and regulator
Realsense camera is connected directly to the NUC

Thanks in advance for your help!

As shown in mode and reserve, this motor is under temperature protection, and turn off it's own power.
Did this motor temperature high?

Hi! Thanks for your quick reply.
As the log that I attached above, the temperature of the motor is 48. And when i touched the motor, i can feel that the other motor (front legs) feel even warmer compared to this motor.
So that means, it is certainly not about the disconnection problem?

Maybe the temperature sensor fails.
Please contact our sales for more help.


fixing typo in toolkit workspace - close #1002

Description

Fixes the runtime error when viewing the webscraper toolkit with no API key configured

Related Issues

#1002
Solution and Design

Test Plan

tested manually
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Docs update

Checklist

[x] My pull request is atomic and focuses on a single change.
[x] I have read the contributing guide and my code conforms to the guidelines.
[x] I have documented my changes clearly and comprehensively.
[x] I have added the required tests.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Should color-adjust be prefixed?

The behavior of this CSS property is described in color-adjust. This property could potentially be prefixed with -webkit-print-color-adjust. Would it make sense to support it here?

Is this a standard property? I see it being supported in FireFox without any prefixes, but I'm not sure how to interpret linked spec. I'm not too familiar with CSS standardization process and thus I'm not sure what's the current status of this one.

According to MDN color-adjust is implemented in chromium with the -webkit prefix: https://developer.mozilla.org/en-US/docs/Web/CSS/color-adjust#Browser_compatibility

Right, I'm interested if this is a standard feature that needs prefixing to work in some browsers, or is it a non-standard property that comes prefixed and non-prefixed in some browsers. As far as I can tell we currently support prefixing only of standard properties.

The link to the spec was already linked as well as MDN explaining how -webkit-print-color-adjust is non-standard while color-adjust is. Do you meant that you don't prefix editor drafts? What is the minimum stage you start prefixing properties?

Do you meant that you don't prefix editor drafts?

I'm not 100% sure, but I think there are no editor draft properties prefixed right now. From what I understand editor draft is the very beginning of the standardization process - so I'm not sure if we want to support this. Keep in mind that every added property adds to the bundle size.

What is the minimum stage you start prefixing properties?

I'm not against adding this per se, but there is currently no rule of thumb which properties we should strive to support and which we shouldn't. So this issue is definitely a good time to decide about this one and probably add a note about it to the docs. @thysultan what's your opinion on this matter?


What's wrong with the cocoaPods .

pod search keeplayout
-> KeepLayout (1.2.2)
Making Auto Layout easier to code.
pod 'KeepLayout', '~> 1.2.2'

Homepage: https://github.com/iMartinKiss/KeepLayout
Source:   https://github.com/iMartinKiss/KeepLayout.git
Versions: 1.2.2, 1.2.1, 1.1.1, 1.0.2, 1.0.1, 0.3.1, 0.3.0 [master repo]

I’m no longer updating CocoaPods central repo.
pod 'KeepLayout', :git => 'https://github.com/iMartinKiss/KeepLayout.git'

Tks


for #1403, fix bug for prepared statement set parameters by master-slave mode

Fixes #1403 .
Changes proposed in this pull request:

add parameters for SQLUnit in master-slave mode

Pull Request Test Coverage Report for Build 5478

0 of 1 (0.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 67.069%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

sharding-proxy/src/main/java/io/shardingsphere/shardingproxy/backend/jdbc/wrapper/PreparedStatementExecutorWrapper.java
0
1
0.0%

Totals

Change from base Build 5477:
0.0%

Covered Lines:
7566

Relevant Lines:
11281

💛  - Coveralls

Sorry, I don't understand your reply for #1403 . Why is Linked #1403 ?


Sugar for common GitHub Actions (and other CI/CD workflows)

(This is written about GitHub so we have a specific example, but applies to all future CI/CD providers!)
Right now, you need to deal with a menagerie of flags to verify GitHub actions workflows (cosign verify-blob):
      --certificate-github-workflow-name string                                                  contains the workflow claim from the GitHub OIDC Identity token that contains the name of the executed workflow.
      --certificate-github-workflow-ref string                                                   contains the ref claim from the GitHub OIDC Identity token that contains the git ref that the workflow run was based upon.
      --certificate-github-workflow-repository string                                            contains the repository claim from the GitHub OIDC Identity token that contains the repository that the workflow run was based upon
      --certificate-github-workflow-sha string                                                   contains the sha claim from the GitHub OIDC Identity token that contains the commit SHA that the workflow run was based upon.
      --certificate-github-workflow-trigger string                                               contains the event_name claim from the GitHub OIDC Identity token that contains the name of the event that triggered the workflow run

We've talked about simplifying this (CC @haydentherapper) by splitting into specific verify-github subcommands. This helps a bit, but still requires values for many (all?) of these fields. That's required for full power for sure.
But @sudo-bmitch points out that there's a really common query we can optimize for: did this signature come from a workflow in "its" GitHub repository? This would boil down to something like just --certificate-github-workflow-repository.
Need to be careful here but I think if we're clear about what it's checking, we can make this common use case really nice! Let's think through this if we're building a verify-github command.

In https://github.com/sigstore/cosign/issues/2805 @philpennock makes some good, related points: namely, we may want to do this for other code forges. Please check out that issue for a proposed syntax as well.
How will we get from here to there (you can ignore if you're not interested in implementation details)?
First, the way that we check predicates like those from the --certificate-* flags is starting to get a little hairy. I'm somewhat nervous to add much more complexity there. Instead, what I'd really like to see is a unified interface to Verify that takes in a "policy" or "predicate". This will prevent the construction of shoot-yourself-in-the-foot predicates (e.g., failing to specify the OIDC issuer—like https://github.com/sigstore/cosign/issues/1947 but enforced deeper in the stack) but also allow more-complicated assertions (like requested in https://github.com/sigstore/cosign/issues/2630) and even support new Fulcio features without needing a new Cosign release (https://github.com/sigstore/cosign/issues/2719), possibly by passing in a Rego or CUE policy. This also plays really nicely with the goals of https://github.com/sigstore/cosign/issues/2804 and will make error messages better.
Then, once that's tamed, the existing flags can "compile" to a predicate. This compilation process will make it really easy to add "sugar" that prevents common antipatterns, support testability and debuggability, and allows consistency across verification commands.
CC @ivanayov as this issue is similar to those you've been working on; it might be a fun one to take a look at—if you're interested, happy to dig into it with you.
CC @asraa and @haydentherapper who have been interested in related issues in the past

Love this idea! As Phil said, what you want is to know that what you're verifying came from some repository - You shouldn't need to know the exact structure of the subject and issuer.
cc @laurentsimon you might be interested in this too for slsa-verifier

I really like the idea of moving towards a policy-based approach because of  the flexibility it adds. Sigstore could even provide a set of canned policies (or policy templates) for different use cases.
One of the things to consider here is how the certificate data will be available as an input to the policy. Currently, verify-attestation passes the base64 decoded payload of the envelope. This enables a rego policy like this:
package signature

default allow := false

allow {
	input.predicateType == "https://slsa.dev/provenance/v0.2"
}

In other words, input is the attestation statement (https://in-toto.io/Statement/v0.1).
If we want policies to evaluate the certificate, we need to pass that to the policy. There are different approaches that come to mind:

Stuff the certificate information under data, leaving input as is. This certainly seems unusual. The certificate information is, after all, an input.
Change input to be a list of documents. One item is the attestation statement, the others are certificates. This is how conftest handles this limitation.
Change input to be an umbrella document. For example, input.statement refers to the statement, and
input.certificates is a list of the certificates.
Change cosign to take an additional policy to be applied just for the certificates. Then, change cosign to call opa multiple times, one for the statement, and one for each certificate, using the corresponding policy. This may be tricky when there are multiple certificates and the user only cares about one of them. Not sure how realistic this scenario is though.

I like option 3, or a variation of it, because it allows us to add attributes in the future without breaking the format.
On the Enterprise Contract side, we chose a variation of 3. But in our case, we combine verify and verify-attestation into a single command. input contains the certificates for the image signature, the statements, and the certificates for each statement. Something like this:
input:
  image:
    signatures:
      - {... cert ...}
  attestations:
    - predicateType: ...
      signatures:
        - {... cert ...}

It would be really great if we could come up with an approach where a certain policy could work with cosign, Enterprise Contract, sigstore/policy-controller, etc...
The benefit for cosign is that the same policy could be used in the verify and the verify-attestation commands.


feat(ark-contracts): execute orders

To check:

DIRI abigen missing files
Add missing executed for orders


Enhancement Request - mass upload to queue

Hi,
using TumblThree to fill the queue (and ost directly) of a configured blog, would be a very welcome addition.
https://www.tumblr.com/docs/en/api/v2#photo-posts
https://www.tumblr.com/docs/en/api/v2#blog-queue
The idea is as following:

Allow to define a local source for upload (a folder)
Allow to define a target blog to upload to the queue (in case you have more than one blog)
Allow to set the number of images per post created (As in single photo posts vs. multi image posts)
Allow to for TumblThree to move queued images to a different local location (Uploaded folger for example)

Well, I don't know.
TumblThree doesn't use the API v2. I've actually ported the code using that api in the beginning, but you need to ask Tumblr that they unlock your key, otherwise it's rate limited to only a few dozen requests per hour. Application-wide, under all users. They didn't unlock it. No big surprise here, given that TumblThree mass downloads their content.
Thus, if someone would implement that, every user has to register the application with his own key, and even then it's still rate limited.
Personally, I most likely will not add this, but if someone else cares, sure..

Ah Gotcha, I hear you. Well it would be neat if if someone feels like it. But looking at where Tumblr is going with being owned by Verizon, I would assume that is not going to go into a better direction. Thanks for commenting and letting me know, Johannes.

I know that this is somewhat inconvenient to many users, but I think using the current Tumblr API with OAuth authentication is a reasonable choice. True, you have to provide your own API key and - secret (i.e. for each user) to make access possible, but at least it works. There are still API limitations in place, that is correct, but afaik they are something like 1000 requests per hour and 5000 requests per day, not too unreasonable, and it works..

Well, then add it. It's open source, and my intention never was to upload anything with TumblThree, but to download content. Thus I'm not even sure why this request is here. Is there really no usable uploading/posting application for tumblr at all?
And that api limit limits the scans per key to around 10 000 posts per hour and 50 000 posts per day. Thus, it's not usable for a downloader. And like you've said, I've answered to issues here where people didn't understand real basics, and they sure as hell will not get through the application registration progress.

There is no option to mass upload images in any shape or form. No web service, no app. There are some apps you buy from very dubious sources used for spamming etc but that does not seem the way to do it and I have no idea how they got around doing it like this. Uploading images to tumblr, as it is, is rather tedious but that ist just the way it is.

Just for the record, I did not mean to express a "+1" to that specific feature request, although I agree with the point about automation of uploading/queuing. And yes, there is no 3rd-party app for this that seems legit and trustworthy, as far as I am aware.
I don't know if this helps, but maybe you haven't tried this one yet @Kvothe1970, just log on to your Tumblr account, go to settings, then "Labs" and activate this new "Queue 2.0" experiment. I have no idea what it does, but it might be worth a try.
My initial intention was simply to mention that you can actually use the Tumblr API (v2), to let you know that this possibility exists, including downloading content, which is also my primary use case. This is something what has been done on another project, very recently actually, and I'm currently using this, with my own API credentials.

Hi @Hrxn I have turned that on. It gives you options in regards to being more flexible when posting. But not to easier uploads. Tumblr considers dragging and dropping n images into one post a mass upload :)

Just FYI, because I've earlier mentioned some other project, which sounds rather ominous.
This is open source as well.. (Yay!)
It's also on GitHub as well... (Yay!!)
https://github.com/mikf/gallery-dl
Issue regarding Tumblr & OAuth: https://github.com/mikf/gallery-dl/issues/65

Btw I have now found a way to mass upload single images to queue.
IFTTT is the solution here:
https://ifttt.com/applets/75037044d-batch-upload-to-tumblr-queue
you will need a free dropbox account and give IFTTT access to a folder in your dropbox and access to your tumblr. It is pretty straightforward and does not use the API, hence the limit. But, it works.


Add hashtags.

Rendered word as a hashtag.

Solved with https://github.com/PiotrJustyna/fontbot/commit/0deba00aedf6295f05c05ed2bfbd37f19396aebd.


Berkeley DB v6 compatibility fix

Fixes building error looking like this:
CXX      wallet/libbitcoin_wallet_a-db.o
wallet/db.cpp: In member function ‘void CDBEnv::EnvShutdown()’:
wallet/db.cpp:46:16: error: call of overloaded ‘DbEnv(int)’ is ambiguous
DbEnv(0).remove(strPath.c_str(), 0);
^
wallet/db.cpp:46:16: note: candidates are:
In file included from wallet/db.h:21:0,
from wallet/db.cpp:6:
/usr/include/db_cxx.h:916:2: note: DbEnv::DbEnv(const DbEnv&)
DbEnv(const DbEnv &);
^
/usr/include/db_cxx.h:518:2: note: DbEnv::DbEnv(DB_ENV*)
DbEnv(DB_ENV *dbenv);
^
/usr/include/db_cxx.h:516:2: note: DbEnv::DbEnv(u_int32_t)
DbEnv(u_int32_t flags);
^
Makefile:5780: recipe for target 'wallet/libbitcoin_wallet_a-db.o' failed
make[2]: *** [wallet/libbitcoin_wallet_a-db.o] Error 1

Closing, as discussed by @JeremyRand on the pull request against the namecoin repo.


Normalise ansible scripts

Use colons to separate commands and values. Variables have spaces between the name and double braces. Value which contain a parameter need to be wrapped in quotes to run,

@cagiti I'm just running it locally to make sure I didn't misconfigure something

Worked on my machine 😉


Culture Information for JSON serialization of Numeric Data

To investigate: will we run into issues with commas vs. periods as users in different regions serialize the JSON?

Per the spec (i.e., large picture) on json.org and numerous online comments to the same effect, use of commas in numbers are not permitted in json.  The decimal separator in valid json is "." and thousands separators are not used.
@strhea @aferreyra  FYI


Editor GPU: Support adding and removing content from lines

This works some of the time currently.

If the user adds content to the middle of it, everything to the right should shift 1 to the right (to minimize manipulating memory too much)
If the user removes content from the middle of it, everything to the right should shift 1 to the left
Deleting multiple lines should work
Adding multiple lines should work

If the shifting of a large amount of data becomes a bottleneck, we can consider using a map of buffer line indexes to actual line data:

Let's not complicate things unless necessary though.

The indirection above is not yet used, but it's mostly tracked in https://github.com/microsoft/vscode/issues/233949
Closing this as done


[FEAT] Upgrade modules-service-plan to 6.3.0

Community Note

Please vote on this issue by adding a :thumbsup: reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description
Hi,
The module of service plan used needs to be updated to version v6.3.0
New or Affected Resource(s)/Data Source(s)
module "service_plan"
Potential Terraform Configuration
# Service Plan
module "service_plan" {
  source  = "claranet/app-service-plan/azurerm"
  version = "~> 6.3.0"

....
}

References
No response

With version 6.2.0 when sku_name is setup to P0v3, I'm getting the bellow error
│ The `sku_name` value must be valid. Possible values include B1, B2, B3, D1, F1, FREE, I1, I2, I3, I1v2, I2v2, I3v2, P1v2, P2v2, P3v2, P1v3, P2v3, P3v3, S1, S2, S3, SHARED, Y1, EP1, EP2, EP3, WS1, WS2, and WS3.
│
│ This was checked by the validation rule at .terraform/modules/app_service_web_eafront.service_plan/variables.tf:45,3-13.

@BzSpi it is possible for a new release to be published with this change ?


Generation test Error: Signal not found.

Guys, I followed the README code and wrote this
import { RLN, Registry, Cache, genExternalNullifier } from 'rlnjs';
import * as path from 'path';
import * as fs from 'fs';

// This assumes you have built the circom circuits and placed them into the folder ./zkeyFiles
const zkeyFilesPath = './zkeyFiles';
const vkeyPath = path.join(zkeyFilesPath, 'verification_key.json');
const vKey = JSON.parse(fs.readFileSync(vkeyPath, 'utf-8'));
const wasmFilePath = path.join(zkeyFilesPath, 'rln.wasm');
const finalZkeyPath = path.join(zkeyFilesPath, 'rln_final.zkey');

// Instantiate RLN
const rlnInstance = new RLN(wasmFilePath, finalZkeyPath, vKey);

// Example of accessing the generated identity commitment
const identity = rlnInstance.identity;
const identityCommitment = rlnInstance.commitment;

console.log('Identity: ', identity);
console.log('Identity commitment: ', identityCommitment);

// generate RLN registry that contains slashed registry
const registry = new Registry(); // using the default tree depth
registry.addMember(identityCommitment);

const cache = new Cache(rlnInstance.rlnIdentifier);

// Example of generating a proof
const epoch = genExternalNullifier('test-epoch');
const signal = 'This is a test signal';

const merkleProof = registry.generateMerkleProof(identityCommitment);

const proof = await rlnInstance.generateProof(signal, merkleProof, epoch);

console.log('DONE!');

but when i try to generate a proof i get this error
ERROR:  1
file{path}/node_modules/circom_runtime/js/witness_calculator.js:433
                    throw new Error(err);
                          ^

Error: Error: Signal not found.
    at file:{path}/node_modules/circom_runtime/js/witness_calculator.js:433:27
    at Array.forEach (<anonymous>)
    at WitnessCalculatorCircom2._doCalculateWitness (file:{path}/node_modules/circom_runtime/js/witness_calculator.js:418:14)
    at WitnessCalculatorCircom2.calculateWTNSBin (file:{path}/node_modules/circom_runtime/js/witness_calculator.js:463:20)
    at wtnsCalculate (file:{path}/node_modules/snarkjs/src/wtns_calculate.js:45:28)
    at async Module.groth16FullProve (file:{path}/poc/node_modules/snarkjs/src/groth16_fullprove.js:31:5)

do you have any ideas?

The error indicates RLNjs is interacting with the wrong circuit. Specifically, README.md suggested the wrong package to install. Please remove rlnjs and do this instead
npm install rlnjs

Sorry for the inconvenience and the issue will be fixed soon

thank you very much for your quick reply, I followed your command and installed
"dependencies": {
  "rlnjs": "^2.0.5"
}

unfortunately I still have the error, do I have to do something else besides the installation?

No problem. Since rln-circuits is also upgraded, but 86cbf5a is the commit that is compatible with RLNjs. Can you try building the rln-circuits at commit 86cbf5a, rebuild the circuit, and update the zkeys?
# 1. Go to the rln-circuit directory
cd rln-circuits
# 2. Build the circuit of at the commit 86cbf5a
git checkout 86cbf5a && npm i && npm run build
# 3. Copy zkey files

you are great, problem solved, initially it gave another problem:
ERROR:  6
Error: Input signal array access exceeds the size.

but I was making a mistake, with the checkout the depth of the tree in rln-circuits is 15 and so they were incompatible, again thank you very much it all works now


Archiving failed

When I try to deploy my app I get this error:
macpro:do Tim$ DEBUG=* mup-test deploy
  mup:module:default exec => mup deploy +0ms
  mup:module:meteor exec => mup meteor deploy +0ms
  mup:module:meteor exec => mup meteor push +12ms
Bulding App Bundle Locally
=> Archiving failed: ENOENT, stat '/tmp/ee280d18-a4fc-4820-b11f-4d2289d81ae6/bundle/programs/server/npm/react-runtime-prod/node_modules/react/node_modules/envify/node_modules/jstransform/node_modules/esprima-fb/.#README.md'
Error: ENOENT, stat '/tmp/ee280d18-a4fc-4820-b11f-4d2289d81ae6/bundle/programs/server/npm/react-runtime-prod/node_modules/react/node_modules/envify/node_modules/jstransform/node_modules/esprima-fb/.#README.md

Unfortunately there's absolutely no indication as to what could be going wrong :(

I remember this error message. Are you using a newer React version (0.14.4?).

Yes, I am.
I've also just tried to use mupx instead, and it's failing with the same error.

OK, I've just downgraded React and that's worked. Nevertheless I'll leave this bug report open since there's no reason it should be failing. Note that I can push to Galaxy without any issues too.

Yes, this was an issue in current mup, definitely should be open :) It's a bug with mup when using React 0.14.4.

I think it's a file lock error or most likely permissions?

This is pretty hard to solve for whatever the reason and we don't anything fancy here. Just build it using Meteor's command.
So, my suggestion is not to use 0.14.4.
With Meteor 1.3, you don't need this package.
See: Getting Started with Meteor 1.3 and React

Well, this time it's failed with React. Next time the same issue could
affect another package, no?
Also, moving away from the React package can only be done once it's
no longer required by any 3rd party packages that we're using.
What is the actual issue? Why doesn't meteor deploy suffer from it?
On Saturday, 23 January 2016, Arunoda Susiripala<EMAIL_ADDRESS>wrote:

This is pretty hard to solve for whatever the reason and we don't anything
fancy here. Just build it using Meteor's command.
So, my suggestion is not to use 0.14.4.
With Meteor 1.3, you don't need this package.
See: Getting Started with Meteor 1.3 and React
https://voice.kadira.io/getting-started-with-meteor-1-3-and-react-15e071e41cd1
—
Reply to this email directly or view it on GitHub
https://github.com/kadirahq/meteor-up/issues/35#issuecomment-174095455.

I also fail to understand why 0.14.4 is not working with this, as everything is standard. There is something that is mup-specific causing this to fail, and this may lead to other packages not loading as well. I really think this should be solved as 0.14.4 is starting to become the standard version of React install at this point in time.

Here's the build related code. There is nothing mup specific.
See: https://github.com/kadirahq/meteor-up/blob/master/lib/modules/meteor/build.js#L26
I'm open to any reason why it's failed and happy to fix it's an issue on mup.

I would add that it may not be limited to 0.14.4. I am running 0.14.3 and had the exact same error.
NOTE: However I was using mupx, not this mup. I'm trying to sort out all of the different mups. It's my first time using mup, so I'm just getting starteding.

running React 0.14.7 gives the same issue. By how much should I downgrade React?
Also what do you mean by with Meteor 1.3 you don't need this package ? In your post you do npm i --save react react-dom right?
Thanks!

I solved this by removing .meteor/local and node_modules, and re-installed npm modules using meteor npm install, I guess having multiple versions of npm on my machine caused this issue and using meteor npm makes meteor use the correct version that works with node 0.12 which meteor ships with at the moment.


Code Block > Scroll Long Lines setting scrolls for each individual line in Live Preview

Is the bug present when using the default Obsidian theme?
No
Is the bug present when snippets and plugins are disabled?
Yes
Minimal theme version
6.1.17
Describe the bug
In Style Settings > Code Block > Scroll Long Lines is turned on, it works as expected in Reading mode:

But when you switch to Live Preview, it scrolls for each individual line instead:

Here's the behaviour reproduced on an empty vault + Minimal + Minimal Theme Settings + Style Settings

Debug info
SYSTEM INFO:
Obsidian version: v1.1.8
Installer version: v1.1.8
Operating system: Windows 10 Pro 10.0.22621
Login status: logged in
Catalyst license: none
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: Minimal v6.1.17
Snippets enabled: 0
Restricted mode: off
Plugins installed: 2
Plugins enabled: 2
1: Style Settings v0.4.12
2: Minimal Theme Settings v6.1.1
RECOMMENDATIONS:
Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.

Unfortunately there is no way to avoid that that I know of.

that's unfortunate :(


FileNotFoundException

Does anybody knows why is this happening?
FileNotFoundException in MimeTypeGuesser.php line 123:
The file "" does not exist
I'm trying to upload an image with this:

.
.
.
//in PHP function
            //create new image
            if (!empty($data['image'])) {
                //var_dump($data);
                $imageUpload = Imageupload::upload($data['image'], null, 'uploads/images/');
                $data['image'] = $imageUpload['filename'];
            }
.
.
.

can you share the full code and describe the steps?

I apologize for this. Actually the problem was with my server the maximum file upload was set on 20 MB and I was trying to upload a file of 21 MB.

Nice to hear that.


error while using --partial

[root@emin home]# autoxtrabackup --partial
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type Database name: lkgfd
Type Table name: sdfnl
Sorry, There is no such Database or Table in backup directory
Or maybe table storage engine is not InnoDB
Traceback (most recent call last):
  File "/usr/local/bin/autoxtrabackup", line 9, in <module>
load_entry_point('mysql-autoxtrabackup==1.0', 'console_scripts', 'autoxtrabackup')()
  File "/usr/local/lib/python3.3/site-packages/click-4.0-py3.3.egg/click/core.py", line 664, in __call__
return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.3/site-packages/click-4.0-py3.3.egg/click/core.py", line 644, in main
rv = self.invoke(ctx)
  File "/usr/local/lib/python3.3/site-packages/click-4.0-py3.3.egg/click/core.py", line 837, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.3/site-packages/click-4.0-py3.3.egg/click/core.py", line 464, in invoke
return callback(*args, **kwargs)
  File "/usr/local/lib/python3.3/site-packages/mysql_autoxtrabackup-1.0-py3.3.egg/autoxtrabackup.py", line 39, in all_procedure
  File "/usr/local/lib/python3.3/site-packages/mysql_autoxtrabackup-1.0-py3.3.egg/partial_recovery/partial.py", line 323, in final_actions
TypeError: 'bool' object is not subscriptable

Thank you for report.
Yes, this exception comes up, when there is no existing database or table in backup directory.

Fixed as described:
Added check for file path of .frm file.
Thank you for report.


Doc comments are different in 4.02.3

There's a CI issue, with doc comments appearing double in 4.02.3.
Doc-comments get filtered out of the comments, because they appear as attributes in the
parsetree. And are formatted starting from the attribute in the printer, not as comment.
I tracked it down to:
https://github.com/facebook/reason/blob/master/src/reason_toolchain.ml#L348
On 4.02.3 Hashtbl.add seen (text, loc) (); properly filters out comments.
While for example on 4.04.2 we need Hashtbl.add seen ("*" ^ text, loc) (); to properly filter out comments.
@let-def is there a reason why the behaviour on 4.02.3 is different?

It is a bug in 4.02.3

There is no way but hacking around it (or if you use a custom distribution of 4.02.3, e.g bucklescript, maybe fixing it directly in the source).


backport: fixing issue with xtrabackup and long gtids (#16304)

Description
backport upstream https://github.com/vitessio/vitess/pull/16304

Related Issue(s)

Checklist

[ ] "Backport to:" labels have been added if this change should be back-ported
[ ] Tests were added or are not required
[ ] Did the new or modified tests pass consistently locally and on the CI
[ ] Documentation was added or is not required

Deployment Notes

@tanjinx can we backport this to slack-19.0 as well?

@tanjinx the failing CI can be fixed by:
goimports -local vitess.io/vitess -l -w ./go/vt/mysqlctl/xtrabackupengine_test.go

And committing the fixed file

goimports -local vitess.io/vitess -l -w ./go/vt/mysqlctl/xtrabackupengine_test.go

ah, til, thanks!


[color] Color Palette Architecture

As a developer, I would like consistency in color ramps so I do not have to do more work based on which color I pick.
First identified in #553
AC
Design:
Create color ramps that are consistent with contrast ratios. ie. 50 to 60 is always the same change of white to black text on color.
Dev:
Warning and Success button colors are not currently AA compliant, fix.
Update theme variable
Simplify theme logic

Remove "color-text-on-primary"

Other considerations:
Re-think structure of color theme variables (see #376)

Please check the updated version of the color palette.
https://ca.invisionapp.com/d/main#/console/11070131/250301076/preview

Please check the updated version of the color palette.
https://ca.invisionapp.com/d/main#/console/11070131/250301076/preview

Follow-up identified:

[ ]  Audit reality vs. readableColor vs. palette spec
[ ]  TextInput & TextArea (others?) border colors
[ ]  Other variant related gotchas?


Build action

Please add a build action so we can download your extensoin from github.

@tombueng Thank you for your contribution first of all. Unexpected :)
That said: The build is using jdk 21. This opens up a question: The reason why I did not add a build action in the first place (apart from me being lazy) is, that you have to build it yourself with the java version matching your applications' java version. So, when you run a JDK 11 java app, but build the extension with jdk 21, it won't work - see my notes in the README. So i think if we want to add a build/release step here, we should have at least a matrix build for, say, last three JDK LTE versions + current one, right? So it's not that simple. I'm happy to hear your thoughts about this, not at all against adding it, but if we add it, it should be right not just for one use case, but in general.

SureAm 30.10.2024 13:34 schrieb Dominik Guhr @.***>:
@DGuhr commented on this pull request.
In .github/workflows/maven-publish.yml:

release:

types: [created]

+jobs:

build:

runs-on: ubuntu-latest
permissions:

 contents: read

 packages: write

defaults:

 run:

   working-directory: otel-javaagent-spring-extension

steps:

uses: @.***

name: Set up JDK 11

Shuoldn't this be called 21?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

Not sure, but compiling with 21 for 11 should work. Will elaborate next days.Am 30.10.2024 13:38 schrieb Dominik Guhr @.***>:
@tombueng Thank you for your contribution first of all. Unexpected :)
That said: The build is using jdk 21. This opens up a question: The reason why I did not add a build action in the first place (apart from me being lazy) is, that you have to build it yourself with the java version matching your applications' java version. So, when you run a JDK 11 java app, but build the extension with jdk 21, it won't work - see my notes in the README. So i think if we want to add a build/release step here, we should have at least a matrix build for, say, last three JDK LTE versions + current one, right? So it's not that simple. I'm happy to hear your thoughts about this, not at all against adding it, but if we add it, it should be right not just for one use case, but in general.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>


Generate ARC check in implementation files

Although j2objc generates ARC or non-ARC source depending on its mutually-exclusive -use-arc flag or -use-reference-counting flags, compiling them with the wrong option (-fobjc-arc for ARC) may still succeed but not manage memory as expected.
To avoid this, implementation files should have a test near their beginning that verifies that they are compiled as their flags specified.
Default or -use-reference-counting:
#if __has_feature(objc_arc)
#error "<filename> should not be compiled with ARC (-fobjc-arc)"
#endif

use-arc:
#if !__has_feature(objc_arc)
#error "<filename> must be compiled with ARC (-fobjc-arc)"
#endif

Should we close this? It was merged in 95783b5c87608a0aabc406075e7136d2b7f8a4ff

Thanks for reminding me.


Replace "dill @ git+https://github.com/som-shahlab/dill@enums" in pyproject.toml with "dill = 0.3.7" when patch for

Describe the bug
When this issue is resolved: https://github.com/uqfoundation/dill/issues/332
Replace our forked version of dill (with the abstract method patch) with the official dill version.
Specifically, we are waiting on this pull request to be released: https://github.com/uqfoundation/dill/pull/450

Dill is now removed.


SVD-T2V weights

Hello, I noticed that you only open sourced the weights of I2V. When can we get the weights of the T2V model?

+1

1

+1

Any update?

+1

+1

Any update?


Update deps

Done

Update deps

Ignore this PR, there's going to be a new one for the updates.

Should we delete the branch?

Should we delete the branch?

Yes please


[1.12] DO NOT MERGE- daprd mTLS fix proof

This PR cherry-picks the integration tests added in https://github.com/dapr/dapr/pull/6951 and serves as proof that the implementation changes make these tests go from failing to passing.

Implementation PR merged https://github.com/dapr/dapr/pull/6951


add ImageComponent that creates and draws ImGui images

Add a compile() function to RenderImGui that compiles child resources like ImageComponent.
This is similar to the code I wrote for vsgCs. I'm not entirely happy that compilable resources in components need to be added directly to the RenderImGui object. It would be better if RenderImGui traversed its components during compile(), but at the moment the components are subclasses of a VSG class that has a compile() member function. Changing that would require more of an incompatible change than I'm willing to make without some discussion.

Crazy idea: RenderImGui becomes a subclass of vsg::Commands, the components are required to be subclasses of vsg::Command, all the ImGui stuff is done in record() member functions...

Crazy idea: RenderImGui becomes a subclass of vsg::Commands, the components are required to be subclasses of vsg::Command, all the ImGui stuff is done in record() member functions...

I've done a quick review of the PR so am still digesting it.  Your crazy idea has me curious about the how well it could work + consequences.  If you want to create a branch to experiment with this then I'd be up for considering it.
I do need to properly get my head around ImGui/vsgImGui, I keep do a bit of work on, leaving it for a month or two, then returning without ever using vsgImgGui directly in my own/client work.  I feel it's with real-world usage you really get insight into how well functionality can work.
Another off the cuff suggestion. could we just have integrate the components more generally with the scene graph so one could use vsg::Switch etc. to toggle on/off subgraphs using switches/masks etc.

W.r.t crazy ideas, perhaps tt's better to review/merge this PR independent of any future refactoring of vsgImGui components to make more flexible.  Thoughts @timoore?

If vsgImGui::RenderImGui was subclassed from vsg::Group and override the accept(RecordTraversal&) it could do the necessary ImGui API calls do in  RenderImGui::recordComponents() and the fallow up calls in the RenderImGui::record() calls.
I don't know if there is a way of checking whether the ImDrawData is empty or not, but there is then we could possible get rid of the bool visibleComponents - we need this as we don't want an overhead when there is nothing to render.
Finally we'd need a way of conveniently providing the call to set up the calls to ImGui in place of the Component = std::function<bool()>. Having class like ImageComponent subclass from vsg::Command could be extended so that a Component subclasses from vsg::Command and "has a" std::function<bool()>.
Another element I have wondering about, more generally for the VSG, but usable here is how we put callbacks/event handlers into the scene graph. I haven't put general callbacks into the VSG so far as they add a memory and comparison during traversal on all nodes and most don't ever have callbacks so it;s mostly a performance drain.   This is why we assign event handlers to the viewer to give us that event handling capability, but it's viewer level not scene graph level.
One approach I've considered is having callback nodes in the scene graph or extend the CompileTraversal so that it can not only do compilation of shaders, creation of vulkan objects and transfer data to GPU, but also be a way of class logging that it has a callback/event handler that needs to be called.  The CompileTraversal could then be checked for event handlers etc. that should be called on each frame,  There is a CompileResult container that is already used for dynamic data and other results so perhaps this could be the place to put these items.
This approach would allow us to more loosely couple the ImGui scene graph from the application setup, as the SendImGuiEvents could be automatically logged with the viewer..

W.r.t crazy ideas, perhaps tt's better to review/merge this PR independent of any future refactoring of vsgImGui components to make more flexible. Thoughts @timoore?

If you think that the functionality is useful as at stands and don't mind that ImageComponent stores a ref to the Window, then I think it's fine to merge. I suppose that it's not to late to make breaking changes to RenderImGui in another pull request :metal:

I think the right thing to do is to merge this PR as a branch then cherry pick from it, or just use it as a reference.
Then create another branch of vsgImGui to trial refactoring it enable vsgImGui::Image/Component to subclassed from vsg::Command and have it handle it's own compile and have the record do the ImGui calls.  I don't know whether to keep the Component as is for backwards compatibility or to have an adapter class this takes the std::function() as a member.  Perhaps starting off with backwards compatibility is the thing to do.
Making RenderImGui subclass from vsg::Group opens the door to users subclassing from vsg::Command and doing their own ImGui class that way.
With the refactor I suspect the ImageComponent class could be simplified, so I think it makes sense to wait till a refactor before merging otherwise we'd just have a move the goal posts for users attempting to adopt it.
I'll merge as a branch now then experiment with a RenderImGui refactor this morning.
On the topic of UpdateOperators, a remove() method looks to be a a simple solution.

@timoore I've checked in a UpdateOperation::remove(ref_ptr opeator) method to VSG master.
https://github.com/vsg-dev/VulkanSceneGraph/commit/6b6790add08fb770dc6a2a91c6790d7549e54cca

I have merged as a branch:
https://github.com/vsg-dev/vsgImGui/tree/timoore-timoore/image-component

I've been investigating elements of a vsgImGui refactor and the draw_data->CmdListsCount value goes to 0 when nothing is going to be rendered so we can dispense with the bool returned from the RenderImGui::Component std::function and potentially just use standard vsg::Commands or other node subclasses.
We needn't subclass from vsg::Command in all cases as mostly there won't be any Vulkan objects to set up or dispatch directly, just special cases like setting up the DescriptorImage to get the TextureID.
I also want to remove the Window from ImageComponent, even right now it just need a Device so that's all you'd need to pass into the constructor, but preferable it wouldn't have this at all.  All need do is record the deviceID that the texture was compiled for, so we can probably just cache that.

I think we can safely cache the deviceID in ImageComponent::compile(..) method as we can prevent it from being used with other devices with the following addition to RenderImGui:
void RenderImGui::record(vsg::CommandBuffer& commandBuffer) const
{
if (commandBuffer.deviceID != _device->deviceID) return;
This will also generalize to when RenderImGui is subclassed from vsg::Group.
The one area it would fail would be if the use added a ImageComponent to a different subgraph as well and this was compiled for another device.  This is trying hard to find a way to break though...

In theory ImGui can be used in multiple windows / devices. Unless it's
simple to pass the context into components, I'd do whatever to get it
working.
On Wed, Feb 1, 2023 at 1:25 PM Robert Osfield @.***>
wrote:

I think we can safely cache the deviceID in ImageComponent::compile(..)
method as we can prevent it from being used with other devices with the
following addition to RenderImGui:
void RenderImGui::record(vsg::CommandBuffer& commandBuffer) const
{
if (commandBuffer.deviceID != _device->deviceID) return;
This will also generalize to when RenderImGui is subclassed from
vsg::Group.
The one area it would fail would be if the use added a ImageComponent to a
different subgraph as well and this was compiled for another device. This
is trying hard to find a way to break though...
—
Reply to this email directly, view it on GitHub
https://github.com/vsg-dev/vsgImGui/pull/45#issuecomment-1411977058, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AABAQAJ4YQYYPT4S2YPPTFTWVJI5PANCNFSM6AAAAAAUMLSNQ4
.
You are receiving this because you were mentioned.Message ID:
@.***>

I have now checked in the first step at refactoring vsgImGui::RenderImGui, with a new RenderImGui_Refactor branch:
https://github.com/vsg-dev/vsgImGui/tree/RenderImGui_Refactor
The key change is RenderImGui now subclasses from vsg::Group rather than vsg::Command allowing users to do an addChild() to add their own nodes, so can subclass from vsg::Node for straight forward ImGui calls, or vsg::Command if they need to override the compile() method such as with ImageComponent.
I have left the old RenderImGui::Component API in place for backwards compatibility.

I don't know how easy it would be to get ImGui working with multiple Vulkan devices.  For now using a separate RenderImGui for each device would be the way to tackle it.
Vulkan allows you to use multiple Windows with a single logical Device, you only need to create multiple Devices when the Windows on separate GPUs.
For now I'm happy to just focus on the single Window/Device case.  Generalizing to multiple Window and one Device would be the next nature step.  However, I have enough other work to get with chasing ImGui functionality is something I need to avoid getting to deeply drawn into.

@timoore could you let know what you want to do now w.r.t the ImageComponent branch.  The RenderImGui_Refactor branch should now be ready to handle the addition of ImageComponent.
Perhaps a first step would simply be to merge the RenderImGui_Refactor branch with master and then merge this into the image component one, or simply create a new branch and copy in the ImageComponent class over to it.
Thoughts?

I'm merged with PR #46.
I'll leave this PR and the one on vsgExamples up, when you are ready and submit new ones I'll delete the older ones.

A have checked another experiment - using a ImGuiNode subclass from vsg::Node to adapt the Component function to a conventional node so can be added as child like any other node.

Some further evolution of the ImGuiNode with commit : 0236047d01d54908590fc1050704a6da55020f08
The key change is that the ImGuiNode has two lists of callback functions that can be either the legacy signature for backwads compatibility or a new RecordFunction one that the RecordTraversal is passed in:
/// std::function signature with RecordTraverasl used vsgImGui
using RecordFunction = std::function<void(vsg::RecordTraversal& rt)>;

/// std::function signature used for older vsgImGui versions
using LegacyFunction = std::function<bool()>;

I have changed the vsgimgui example to use the new std::function<void(vsg::RecordTraversal& rt)  with a new vsgExamples ImGuiNode branch:
You can get the DeviceID from the RecordTraversal, though it's a bit long winded right now:
auto deviceID =  rt.getState()._commandBuffer->deviceID;
I think it might be useful to cache the deviceID on RecordTraversal class to make it easier to access.
Another alternative it pass the RenderImGui node as a parameter to the RecordFunction.
https://github.com/vsg-dev/vsgExamples/tree/ImGuiNode

To make it easier to get the deviceID I've added:
    /// get the current CommandBuffer for current subgraph being traversed
    CommandBuffer* getCommandBuffer();

    /// get the current DeviceID for current subgraph being traversed
    uint32_t deviceID() const;

to vsg::RecordTraversal with commit : https://github.com/vsg-dev/VulkanSceneGraph/commit/a9410151c054ac28f0b7184436750a8e473b1e74
These changes should pave the way for get the TextureID a bit more conveniently.
With this I think I'm done for now refactoring for now so will get on with other work.  Items I'm not happy about yet is the naming of RenderImGui and ImGuiNode, they work fine, but I'm wondering if there might be better naming lurking out there.  Perhaps once we get the texture functionality integrated and used it'll all become clearer.

@timoore I have picked up the my work refactoring vsgImGui and integrating ImageComponent into the ImGuiNode branch, this is now far enough along I think it should be good enough to merge vsgImGui and vsgExamples master soon.
First integrated ImageComponent pretty cose to verbatim but have now started refactoring it a bit to make it more general purpose - such as removing the Window dependency.  This changes usage a bit so I've updated the changes to vsgimgui_example:
https://github.com/vsg-dev/vsgImGui/commit/ed0e2f4ae859b20b052dc58297f3c348d5cd8af2
https://github.com/vsg-dev/vsgExamples/commit/319891698d41f3c5ca0a10438d6cf5aa7d0f44b6
I want to spend a bit more time with the code to see if there are further opportunities to make them more general purpose.

@timoore  I have been thinking about the coupling between ImageComponent and an implementation of the ImGui function in the vsgimgui_example and it feels pretty clunky.  Ideally we'd have things self contained so a class/function that handles the GUI also has responsibility for any textures than it wants to use.
I may mean that whole std::function approach won't cope this as we'll need to entry points - the RecordTraversal and the CompileTraversal.  Unless we add support for doing compile in the RecordTraversal as well, which is a possibility.
I don't know where we'll end with this.  What we have now is cludgy but workable, it might be that's an OK interim solution.

I have just completed my final refactoring of the ImGuiNode branch with the renaming of vsgImGui::ImageComponent to vsgImGui::Texture to keep it inline with ImGui terminology better.  This refactor work is now ready to merge with master so I've updated the vsgImGui version to 0.1.0 and created a PR for it: #47 so will close this PR as all the functionality is part of 47.

That's a relief, I was hoping that things would just work for you.
W.r.t use of vsg::Command, perhaps another base class vsg::Compilable may be useful base c;lass to have for objects that need to be compiled by never have any Command associated with them.  The VSG has to small CPU overhead when encountering Command during the ReocrdTraversal - the vsg::State has to be made current before the command::record(..) is called and this will happen even when a Command implementation is a non op.

On Wed, 22 Mar 2023 at 18:09, Tim Moore @.***> wrote:

That change would be a little less convenient for vsgCs because I use the
viewer's CompileManager to compile the Texture, which IIUC would invoke
the compile() virtual function as part of a traversal.

If you subclass from vsg::Command and override compile() like I've done
with the vsgimgui_example it should be invoked in the CompileTraversal, if
you just assigned the vsgImGui::Texture as it's own object in the scene
graph or call compile on it directly then it'll need to remain subclassed
from vsg::Command, or a new vsg:::Compileable base class.
Have you checked in your changes to vsgCs to use the new vsgImGui::Texture
support?  Tomorrow I could have a look at the usage case and reflect on
what changes might make things cleaner.

Message ID: @.***>

On Wed, 22 Mar 2023 at 18:09, Tim Moore @.***> wrote: That change would be a little less convenient for vsgCs because I use the viewer's CompileManager to compile the Texture, which IIUC would invoke the compile() virtual function as part of a traversal.
If you subclass from vsg::Command and override compile() like I've done with the vsgimgui_example it should be invoked in the CompileTraversal, if you just assigned the vsgImGui::Texture as it's own object in the scene graph or call compile on it directly then it'll need to remain subclassed from vsg::Command, or a new vsg:::Compileable base class. Have you checked in your changes to vsgCs to use the new vsgImGui::Texture support? Tomorrow I could have a look at the usage case and reflect on what changes might make things cleaner.

Just to be clear, the way Texture is defined now is fine for me. Whether a compilable thing is a subclass of Command or something called Compilable is really just a detail that can be resolved much later IMHO.
In my usage of ImGui / Texture, I can't just compile it when the "component" is compiled, because I don't have the image yet; it's loaded later via http when the Cesium credits system detects that ion needs to be credited.
My use of vsgImGui::Texture in vsgCs is all checked in.


[mandatory-inlining] Fixup reference counts before we inline now that we can know if inlining will succeed before actually inlining.

[mandatory-inlining] Fixup reference counts before we inline now that we can know if inlining will succeed before actually inlining.
rdar://31521023

@swift-ci smoke test and merge

So what happened here is by my moving inserting the fixups and removing the block break, I eliminated a bug where if a transparent function was the first instruction in a function, we would set II to that value and then call ++II, skipping it.
Really all of the handling around iterators in Mandatory inlining is confusing and hard to reason about. I am going to do some cleanups tonight and then jump back.

I fixed this in a different PR. Closing!


check if process is still alive when executing weaver single/multi status command

when I manually killed components' processes and then used command weaver single/multi status, I found the killed pids are still presented in column REPLICA PIDS. The corresponding codes are in file internal/status/status.go:
// formatDeployments pretty-prints the set of components.
func formatComponents(w io.Writer, statuses []*Status) {
         ...
	for _, status := range statuses {
		...
		for _, component := range status.Components {
			prefix, _ := formatId(status.DeploymentId)
			c := logging.ShortenComponent(component.Name)
			sort.Slice(component.Pids, func(i, j int) bool {
				return component.Pids[i] < component.Pids[j]
			})
			pids := make([]string, len(component.Pids))
			for i, pid := range component.Pids {
				pids[i] = fmt.Sprint(pid)
			}
			t.Row(status.App, prefix, c, strings.Join(pids, ", "))
		}
	}
}

Maybe check for process liveness is needed before assembling pids info. Glad to help if you think this optimization is needed.

I think if a process dies when deployed via weaver multi deploy, the entire deployment should be killed. This makes it easier to see when and why things are failing.

Op, my mistake. This behavior is actually already implemented.


[tflite][micro] [patch] Incorrect arguments to ComputePaddingHeightWidth, causing wrong offsets in maxpool implementation

With a 1x4 kernel on a one dimensional tensor the max pool result was always minimum (0 in my case), because no input data was selected.
See padding.h: TfLitePaddingValues ComputePaddingHeightWidth(int stride_height, int stride_width, int dilation_rate_height, int dilation_rate_width, int in_height, int in_width, int filter_height, int filter_width, TfLitePadding padding, int* out_height, int* out_width)
---
 tensorflow/lite/experimental/micro/kernels/pooling.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tensorflow/lite/experimental/micro/kernels/pooling.cc b/tensorflow/lite/experimental/micro/kernels/pooling.cc
index 385143050f..4acda7ef68 100644
--- a/tensorflow/lite/experimental/micro/kernels/pooling.cc
+++ b/tensorflow/lite/experimental/micro/kernels/pooling.cc
@@ -44,9 +44,9 @@ TfLiteStatus CalculateOpData(const TfLiteContext* context,
   int out_height, out_width;

   data->padding = ComputePaddingHeightWidth(
-      params->stride_height, params->stride_width, /* dilation_rate= */ 1,
+      params->stride_height, params->stride_width, /* dilation_rate= */ 1,1,
       height, width, params->filter_height, params->filter_width,
-      params->padding, params->padding, &out_height, &out_width);
+      params->padding, &out_height, &out_width);

   return kTfLiteOk;
 }
--

It looks like this is fixed in https://github.com/tensorflow/tensorflow/commit/7645ab725f5b8ce92031e761a6fe0bbcf596b2ce.

I agree that it was solved by that commit.


Switch win32 implementation to new design

In other words, it no longer uses gen_api_transition!.

In addition to this, it should be possible to rework Window::set_cursor_state to use the new execute_in_thread function, but I preferred not to change any behavior.

While I'm not very familiar with X11/OSX, I am very confident in this Win32 implementation and I guess this can be merged. Chances are that nobody else is going to review it anyway.


Fixed minimum size of AABB in ImmediateMesh to draw only one vertex

Fixed #52627.
At least it needs a very small AABB in any case same as ArrayMesh calling RenderingServer::_surface_set_data() does, for the behavior when there is only one vertex.
Ref: https://github.com/godotengine/godot/blob/52b7d5fa347fb88aa016e1e30414abd01e800381/servers/rendering_server.cpp#L373-L391

@akien-mga Make SMALL_VEC2 and SMALL_VEC3 to use CMP_EPSILON  and fixed some comment format in ImmediateMesh and RenderingServer.

Changed SMALL_VEC2 and SMALL_VEC3 to class const small_vec2 and small_vec3.

Thanks!


[Torch] Support logsumexp, clean up unnecessary infer_shape usage

Add logsumexp support per https://github.com/microsoft/hummingbird/issues/232#issuecomment-684998759
I also fixed how we handle a list of integers during conversion. For some reason (probably a debt from the beginning) for each int list we are creating a Relay Var:
https://github.com/apache/incubator-tvm/blob/f56bb71df9c93ba8830c5ab632352b3b2569bec9/python/tvm/relay/frontend/pytorch.py#L2700-L2701
And inside each op converter we are using infer_shape to recover the int list. This doesn't make any sense, so I removed Relay Var creation and that allowed me to remove many _infer_shape usage in our frontend.
please review @siju-samuel @t-vi
Also thanks to @siju-samuel for adding logsumexp to Relay!

I should clarify that, with this change, prim::ListConstruct converts to either

List ADT (dynamic case, e.g. when the list is appended a new item at runtime)
List of integer or tensors (static case, preserve Python list during conversion)

Yeah, the thing that makes it ad hoc in my eyes is that

we don't have a view as which ops all lead to dynamic lists (e.g. append),
very likely we should have some criterion for recursion (e.g. handling slicing, which might be not that uncommon when you think of some "manual broadcasting"-style things).

But again, I see the PR as a good improvement over the status quo and so I think its good to have. Thank you!

Thanks @masahi @t-vi . This PR is merged.


Make sure directory is correct

We actually fixed this for Develop in PR #991, but did not cherry pick it to Release.

Although the Travis check for push failed due to Travis dependency issues, the other check passed and building results were copied to S3. So it's safe to merge.


unit test cases to test methods containing EntryFrameworkCore Attach method

I have an update method which updates an entity. As my controller already fetched the item from DB, I was attaching my entity with DBContext
 public async Task UpdateUser(User user, string name)
        {
            using (var context = _dbProvider())
            {
                context.Attach(user);
                user.Username = name;
                await context.SaveChangesAsync();
            }
        }
[SampleAttachProblem.zip](https://github.com/aspnet/EntityFrameworkCore/files/2896573/SampleAttachProblem.zip)

This works fine with the Sqlserver provider.
In my unit test cases, I tried to test this using InMemory Provider.

First my InMemoryDBContext fetches entity
Then sends an update for that entity.

But I get error
The instance of entity type 'Message' cannot be tracked because another instance with the same key value for {'Id'} is already being tracked. When attaching existing entities, ensure that only one entity instance with a given key value is attached. Consider using 'DbContextOptionsBuilder.EnableSensitiveDataLogging' to see the conflicting key values.
Steps to reproduce

First my InMemoryDBContext fetches entity
Then sends an update for that entity.

Partial code listings, or multiple fragments of code, will slow down our response or cause us to push the issue back to you to provide code to reproduce the issue.
Further technical details
EF Core version: <IP_ADDRESS>
Microsoft.EntityFrameworkCore.InMemory: <IP_ADDRESS>
Attached are files. My earlier issue got closed and couldnt find a way to open that.

SampleAttachProblem.zip
Files attached

Problem being faced while writing unittest case was with methods containing Attach method

Case 1: when we use same DBContext then error says

`      Error : The instance of entity type 'Message' cannot be tracked because another instance with the same key value for {'Id'} is already being tracked. When attaching existing entities, ensure that only one entity instance with a given key value is attached. Consider using 'DbContextOptionsBuilder.EnableSensitiveDataLogging' to see the conflicting key values.
Even if we detached DBContext with original one

Case 2: in case we do not use same context and remove all item error says

Error: Attempted to update or delete an entity that does not exist in the store.

@NidhiNagarro Both GetDBContext and GetDBContextDetached generate a new name for the in-memory database each time they run. If you want the same database to be used in both cases (so you can insert with one context instance and update with another) then you'll need to use the same database name for both. Also, deleting the data EnsureDeleted doesn't seem appropriate if you're trying to get data out of it.


Only show model names on hover

Model names, however short we make them, will always end up cluttering the scatter plots.
This PR removes model name annotations and rather only shows them on hover.

Closes #11.

Jae-Won, the code is hard to understand. If you deploy the work via a test-url and point me to that, I can see the effect of your change and comment.

This is where I saw the anomaly before:
https://ml.energy/leaderboard/?__theme=light

Turns out there was a recent bug introduced in the CI pipeline that prevented stuff from getting deployed to https://ml.energy/leaderboard. Now you will be able to see the result of the PR deployed there.

You can add a space after energy= and the same for the next line. Otherwise, LGTM.


Select Component rendering is broken

Hi Support Team,
This is like first I tried  the select component and below error is on browser console when click on the component.
choices.js?d6ea:2541 Uncaught TypeError: Cannot create property 'keyCode' on boolean 'false'     at Choices._handleChoiceAction (choices.js?d6ea:2541)     at Choices._onMouseDown (choices.js?d6ea:3121)
This Error is on the console while the UI is totally broken for the select component. I am using the react-formio lib.

Please help here?

It is probably related to the choices upgrade and could be that you need to update your CSS from the choices.js library. Can you verify the CSS is the latest from them?

@wag110894 choices.js is already at the latest version in formiojs bundle. plus for rendering, I am not sure for rendering choices.js is responsible. it throws an error after clicking on drop down.

You need to include the formio.min.css file in your application. This includes the choices.js css.

Fixed by including choices.min.css


[HS] youtube-dl for android

Hello,
i wonder if there is any possibility to make youtube-dl for android
if it's already done can you reference me please
Best regards,

Duplicate of #967.

ok i guess there is no pure android application !

is there any way to use youtube-dl on android app. There is 2 possible way first; add executable youtube-dl file to android project and run it with command codes second way add scripts to android project and run it. i succeed second way as running scripts on ios project. and also i cant use youtube-dl executable file on android project. i am searching a native example project that can run python codes


How to use AbortController with the client?

Firstly, thank you for this great lib.
I want to cancel a mutation, I used Abortcontroller wtih axios and fetch before but I can't find how to use it with Genql?
I see that you can pass signal to the createClient function but I'm wondering how a top level controller could be used?

You could create a new client every time you want to use an Abortcontroller, createClient is a cheap operation
Or you could use your own fetch function and generate the query and variables with generateQueryOp: https://genql.dev/docs/usage/integrate-with-other-graphql-clients