worker: 3.8.5 -> 3.15.0

Semi-automatic update. These checks were performed:

built on NixOS
ran /nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/bin/worker -h got 0 exit code
ran /nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/bin/worker --help got 0 exit code
ran /nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/bin/worker help got 0 exit code
ran /nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/bin/worker -V and found version 3.15.0
ran /nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/bin/worker -v and found version 3.15.0
ran /nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/bin/worker --version and found version 3.15.0
ran /nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/bin/worker -h and found version 3.15.0
ran /nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/bin/worker --help and found version 3.15.0
found 3.15.0 with grep in /nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0
found 3.15.0 in filename of file in /nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0

cc "@ndowens"

Success on x86_64-darwin (full log)
Partial log (click to expand)
/nix/store/zvic89775sm97f2wf227m2i1yi1ifg86-worker-3.15.0/share/worker/scripts/aa.pattern_rename.sh: interpreter directive changed from "/bin/bash" to "/nix/store/pkjmwq7sqrvjg7cjiph6hq0khsmfl6p8-bash-4.4-p12/bin/bash"
/nix/store/zvic89775sm97f2wf227m2i1yi1ifg86-worker-3.15.0/share/worker/scripts/cd2flac.sh: interpreter directive changed from " /bin/bash" to "/nix/store/pkjmwq7sqrvjg7cjiph6hq0khsmfl6p8-bash-4.4-p12/bin/bash"
/nix/store/zvic89775sm97f2wf227m2i1yi1ifg86-worker-3.15.0/share/worker/scripts/cd2mp3.sh: interpreter directive changed from " /bin/bash" to "/nix/store/pkjmwq7sqrvjg7cjiph6hq0khsmfl6p8-bash-4.4-p12/bin/bash"
/nix/store/zvic89775sm97f2wf227m2i1yi1ifg86-worker-3.15.0/share/worker/scripts/cd2ogg.sh: interpreter directive changed from " /bin/bash" to "/nix/store/pkjmwq7sqrvjg7cjiph6hq0khsmfl6p8-bash-4.4-p12/bin/bash"
/nix/store/zvic89775sm97f2wf227m2i1yi1ifg86-worker-3.15.0/share/worker/scripts/cd2wav.sh: interpreter directive changed from " /bin/bash" to "/nix/store/pkjmwq7sqrvjg7cjiph6hq0khsmfl6p8-bash-4.4-p12/bin/bash"
/nix/store/zvic89775sm97f2wf227m2i1yi1ifg86-worker-3.15.0/share/worker/scripts/displaywrapper_worker: interpreter directive changed from " /bin/sh" to "/nix/store/pkjmwq7sqrvjg7cjiph6hq0khsmfl6p8-bash-4.4-p12/bin/sh"
/nix/store/zvic89775sm97f2wf227m2i1yi1ifg86-worker-3.15.0/share/worker/scripts/git_modified_files.sh: interpreter directive changed from " /bin/sh" to "/nix/store/pkjmwq7sqrvjg7cjiph6hq0khsmfl6p8-bash-4.4-p12/bin/sh"
/nix/store/zvic89775sm97f2wf227m2i1yi1ifg86-worker-3.15.0/share/worker/scripts/xeditor: interpreter directive changed from " /bin/bash" to "/nix/store/pkjmwq7sqrvjg7cjiph6hq0khsmfl6p8-bash-4.4-p12/bin/bash"
/nix/store/zvic89775sm97f2wf227m2i1yi1ifg86-worker-3.15.0/share/worker/scripts/xliwrapper_worker: interpreter directive changed from " /bin/sh" to "/nix/store/pkjmwq7sqrvjg7cjiph6hq0khsmfl6p8-bash-4.4-p12/bin/sh"
/nix/store/zvic89775sm97f2wf227m2i1yi1ifg86-worker-3.15.0

Success on x86_64-linux (full log)
Partial log (click to expand)
/nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/share/worker/scripts/aa.pattern_rename.sh: interpreter directive changed from "/bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/share/worker/scripts/cd2mp3.sh: interpreter directive changed from " /bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/share/worker/scripts/displaywrapper_worker: interpreter directive changed from " /bin/sh" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/sh"
/nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/share/worker/scripts/xeditor: interpreter directive changed from " /bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/share/worker/scripts/xliwrapper_worker: interpreter directive changed from " /bin/sh" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/sh"
/nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/share/worker/scripts/cd2wav.sh: interpreter directive changed from " /bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/share/worker/scripts/cd2ogg.sh: interpreter directive changed from " /bin/bash" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/bash"
/nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0/share/worker/scripts/git_modified_files.sh: interpreter directive changed from " /bin/sh" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/sh"
checking for references to /tmp/nix-build-worker-3.15.0.drv-0 in /nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0...
/nix/store/r4nbmymh7w5xqig9szbc6rmw2ld2gc91-worker-3.15.0

Failure on aarch64-linux (full log)
Partial log (click to expand)
g++ -DHAVE_CONFIG_H -I. -I../src/aguix   -pthread  -g -O2 -std=c++11 -Wall -c -o exprfilter_parser.o exprfilter_parser.cc
g++ -DHAVE_CONFIG_H -I. -I../src/aguix   -pthread  -g -O2 -std=c++11 -Wall -c -o exprfilter_scanner.o exprfilter_scanner.cc
g++ -DHAVE_CONFIG_H -I. -I../src/aguix   -pthread  -g -O2 -std=c++11 -Wall -c -o externalvdirop.o externalvdirop.cc
g++ -DHAVE_CONFIG_H -I. -I../src/aguix   -pthread  -g -O2 -std=c++11 -Wall -c -o fileentry.o fileentry.cc
g++ -DHAVE_CONFIG_H -I. -I../src/aguix   -pthread  -g -O2 -std=c++11 -Wall -c -o fileentry_color.o fileentry_color.cc
g++ -DHAVE_CONFIG_H -I. -I../src/aguix   -pthread  -g -O2 -std=c++11 -Wall -c -o fileentry_customcolor.o fileentry_customcolor.cc
g++ -DHAVE_CONFIG_H -I. -I../src/aguix   -pthread  -g -O2 -std=c++11 -Wall -c -o fileentry_typecheck.o fileentry_typecheck.cc
g++ -DHAVE_CONFIG_H -I. -I../src/aguix   -pthread  -g -O2 -std=c++11 -Wall -c -o filelock.o filelock.cc
building of '/nix/store/4m25aipc0803kqdiah4w95lc2h14avrn-worker-3.15.0.drv' timed out after 3200 seconds
error: build of '/nix/store/4m25aipc0803kqdiah4w95lc2h14avrn-worker-3.15.0.drv' failed


Fixes #568: MockFile.Copy does not honor AccessFileShare on MockFileData

add CheckFileAccess on MockFile.Copy, so IOException is correctly thrown if Read access is not granted.
added missing coverage on MockFile.Move related to AccessFileShare

Great, thank you also for this!


Null Exception Processing Map With Mapref to SubjectScheme Map

When building output from a map that references a subjectScheme map, the subjectScheme map is not available for processing at the debug-filter stage, generating a null exception.
Tested with DITA-OT 2.2.4, 2.2.5, 2.3, html5 transtype. Tested when the base map is a standard map and a classification map. Same results with all tests.
Attached are sample build files with the log file and temp directory.
admin-build-new.zip

If I manually copy the taxonomy ditamap to the (incorrect) path expected in the build log, the build completes without the error. I do not possess the Java-Fu, but I think the problem is that either parentRoot or childRoot is incorrectly defined in src/main/java/org/dita/dost/module/DebugAndFilterModule.java, leading the module to look for the taxonomy map in the wrong path.

Verified this problem still exists in 3.0 and uncovered another effect: because of this, you effectively can't use schemeref (or topicref, mapref, etc.) to extend a referenced classification map, as you'd need to copy all the referenced artifacts to the incorrect location along with the subjectScheme map.


[184446952] Using S3 broker version with new security changes

What
Starting in April 2023 Amazon S3 will change the default security configuration for all new S3 buckets. For new buckets created after this date, S3 Block Public Access will be enabled, and S3 access control lists (ACLs) will be disabled.
This PR uses the S3-Broker version supporting this is functionality.
How to review
Check the paas-s3-broker-boshrelease release in the build CI version to match the version with the paas-s3-broker feature version.

🚨⚠ Please do not merge this pull request via the GitHub UI ⚠🚨

Things match 👍
Not sure why there's a white space change?

There was a continuation in line 56 with a white space at the end of the line which is not visible. Putting spaces on at the end of the formatted text is producing formatting errors upon change. The humans editing the file will find out about them while adding the change to a commit. As this is a yaml free text block it is preferable for the space between sentences to be identifiable from humans. That is why it prepends the sentence. Not big of a deal. If you want that reverted I can happily make it happen.


Fix littlevgl link error issues

The littlevgl library had changed its name and domain to LVGL.
See https://blog.lvgl.io/2020-06-01/announcement
We change some names and links accordingly.
Also remove the cloning for tlsf library as it isn't used now.

https://github.com/bytecodealliance/wasm-micro-runtime/blob/main/ATTRIBUTIONS.md


[ TTS ] Vocoder(Pwgan): covert onnx model to TRT ERROR

In TTS,  I cover Vocoder(Pwgan) paddle model to onnx model with your code,  it is OK, and the onnx model is OK;
Then I cover that onnx model to TensorRT model, It is error.  And the error is like that:
Loading ONNX file from path ../data/paddle_onnx/onnx_model/pwgan_aishell3.onnx...
Beginning ONNX file parsing
[04/27/2022-21:39:16] [TRT] [W] onnx2trt_utils.cpp:366: Your ONNX model has been generated with INT64 weights, while TensorRT does not natively support INT64. Attempting to cast down to INT32.
Completed parsing of ONNX file
Building an engine from file ../data/paddle_onnx/onnx_model/pwgan_aishell3.onnx; this may take a while...
[04/27/2022-21:39:16] [TRT] [E] 4: [network.cpp::validate::2633] Error Code 4: Internal Error (Network must have at least one output)
Completed creating Engine
Traceback (most recent call last):
  File "onnx2trt_paddle.py", line 95, in <module>
    engine = ONNX_build_engine(onnx_file_path, trt_output, write_engine)
  File "onnx2trt_paddle.py", line 44, in ONNX_build_engine
    f.write(engine.serialize())
AttributeError: 'NoneType' object has no attribute 'serialize'

The code I use to cober TRT is just like this:

I covert vocoder from pytorch --> onnx --> TRT is OK
So, Does paddle --> onnx model spport onnx --> TRT model ?
** Environment (please complete the following information):**

OS:  Ubuntu
Python Version:  3.7
GPU/DRIVER Informationo : GeForce RTX 3090
CUDA/CUDNN Version : cuda-11.2
TensorRT Version :  <IP_ADDRESS>

I have no knowledge about onnx -> trt, sorry, please make sure your onnx model can use trt first, as far as I am concerned, fastspeech2 can't not use trt, because the duration is predicted during inference, so the trt doesn't known the size of some layers

I have no knowledge about onnx -> trt, sorry, please make sure your onnx model can use trt first, as far as I am concerned, fastspeech2 can't not use trt, because the duration is predicted during inference, so the trt doesn't known the size of some layers

Thank you very much. But vocoder model from onnx covert to TRT is also error. I guess something is wrong with onnx model.


add test for concurrent subscriptions & update qlobber

This is a test for https://github.com/mcollina/aedes-cached-persistence/issues/12

would you also attempt a fix?

fix will be inside https://github.com/mcollina/aedes-cached-persistence

I should depend on this when merged to test

This should now pass @mcollina
I will provide another PR in a few minutes to fix https://github.com/mcollina/aedes-cached-persistence/issues/12


issue #8 : add crossScalaVersions to build to support 2.11.7 and 2.10.5

Modify build to add crossScalaVersions := Seq("2.10.5", "2.11.7") and set the scalaVersion := "2.11.7".

spark 2 support now builds for scala 2.11


[decancer] Set stuff

Cleans up the setting command and adds custom checks to prevent auto from showing when disabled globally. Also enforces modlog when turning on auto and speeds auto up a bit by using get_member.

thanks for another PR!


ensure we check for whether logged-in user has data storage

Bug fix for https://trello.com/c/16dIWMWm
Something I started (and just finished updating the tests for) when I couldn't sleep last Sat...

LGTM - will merge ready for build


feat(presets): update angular preset's commit types

based on: https://github.com/commitizen/conventional-commit-types/blob/01a66a9c4946f51c3018eef4c26cef79ed82205e/index.json
closes #54

Awesome, thank you!


Bug: Error while loading configuration value: CHROME_VERSION UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd5 in position 0: invalid continuation byte

My environment was Win10, Python 3.10, Node 18.17.1, archivebox-0.6.2, Google Chrome 117.0.5938.149 (正式版本) （64 位） (cohort: M117 Rollout) (as I'm in China)
1, create and activate a virtual environment
2, pip3 install archivebox
So far so good, but when I ran
archivebox add 'https://example.com'

or
archivebox init --setup

or
archivebox version

my Chrome 117.0.5938.149 was launched, then I got an error:
[X] Error while loading configuration value: CHROME_VERSION
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd5 in position 0: invalid continuation byte
Check your config for mistakes and try again (your archive data is unaffected).
PS:
I also downloaded chromium and set CHROME_BINARY env variable, but then I got:
archivebox version
[X] Error while loading configuration value: DEPENDENCIES
PermissionError: [Errno 13] Permission denied: 'F:\ArchiveBox\chrome-win'
and I also encountered PermissionError when trying to use Archivebox with docker run or docker-compose under WSL2
PPS:
PermissonError disappeared after I move CHROME_BINARY to 'F:\chrome-win
But when I run archivebox init --setup, I got
[+] Installing enabled ArchiveBox dependencies automatically...
[X] Failed to install chromium using playwright: AttributeError module 'os' has no attribute 'getpgid'
It seems that archievebox was not quite native to windows after all?

ArchiveBox does not support Windows officially other than in Docker. Some people  have gotten it working but I cant provide official Windows support because I don't own a windows machine and don't really know anything about Windows.
Docker-compose should work but dont set a custom chrome version, as it definitely cannot use the Windows version of chrome inside a linux container.


Added feature to create a connection per slack user

I found a single connection from a bot, with the username in the message text to be cumbersome and bad for the readability of the message origin.
This PR adds the ability to create a new connection for every slack user, by using the slack username appended with [s] to indicate the slack integration. The behavior is now more like the behavior on slack, but restrictions from the IRC might apply (maximum connections per host).
A todo is of course tests, but first I would like to know if you would consider merging this feature, or if I should simply keep it in my own fork.

Coverage decreased (-13.2%) to 86.325% when pulling b1540e8c2b8714a0fa31d45dc3b9f5855ed6fecf on bobvandevijver:connection-per-user into e5cb8c6e83a18b706bd69cef96c5af067a31604a on ekmartin:master.

Coverage decreased (-13.2%) to 86.325% when pulling b1540e8c2b8714a0fa31d45dc3b9f5855ed6fecf on bobvandevijver:connection-per-user into e5cb8c6e83a18b706bd69cef96c5af067a31604a on ekmartin:master.


CB-11177 SplashScreen gets shifted on Windows devices with soft navbar

Platforms affected
Windows
What does this PR do?
Fixes splash jump bug (affected mostly Windows 10 Mobile devices, especially with soft navigation bar)
What testing has been done on this change?
Manual testing
Checklist

[x] Reported an issue in the JIRA database
[x] Commit message follows the format: "CB-3232: (android) Fix bug with resolving file paths", where CB-xxxx is the JIRA ID & "android" is the platform affected.
[ ] Added automated test coverage as appropriate for this change.

Current coverage is 76.13% (diff: 100%)

Merging #216 into master will not change coverage

@@             master       #216   diff @@
==========================================
  Files            16         16
  Lines          2204       2204
  Methods         413        413
  Messages          0          0
  Branches        430        430
==========================================
  Hits           1678       1678
  Misses          526        526
  Partials          0          0

Powered by Codecov. Last update 707bf96...94b0c27

@vladimir-kotikov, is this good to go?

Yep 👍

Merged, thanks for review!


Fix type of return value of fused function

Fix #227.

How about adding option to ElementwiseKernel?

The type of the return values can't be determined statically.

Sorry, I accidentally closed it.

Jenkins CI test (for commit
c52a59481f059900a94faa6242afc254c27f3d63) succeeded without errors!

Jenkins CI test (for commit 49c54e91abe4bad4a1374febad4021a82e010b04) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

LGTM!


Remove "Usage" section of design.login.gov

This pull request transitions "Usage" of the design system from living on design.login.gov as a .md file to being part of the README. As the user is primarily internal team members, it makes sense to keep this installation and usage information in one place (instead of two).

@aduth updates made. Re-requested review before 🚀 please 😄


Restore onAfterScreenshot from the original API of cy.screenshot

It generally is useful in many scenarios and this plugin is hiding it likely due to a oversight

Hey @ eugenet8k, we made some changes to the plugin and this PR #228  will fix your issue.
If that's not the case,  please feel free to open a new one.
Thanks

@area73 I am looking at the changes and it doesn't seem to address the issue I faced. Which is that this lib callback onAfterScreenshot replaces a possible callback value in the screenshotOptions. Where a more universal approach would be to "add it on" or chain it.
Now the code https://github.com/cypress-visual-regression/cypress-visual-regression/blob/38c10a63444fd3415034ecea412f42fd752b9b1e/src/command.ts#L182-L200
the line 193 tells us that if screenshotOptions has onAfterScreenshot value it will be ignored. And my proposed fix was to add another line into onAfterScreenshot
        onAfterScreenshot(_el, props) {
           ScreenshotDetails = props
           screenshotOptions?.onAfterScreenshot?.(_el, props)
        }

I will rebase my PR to head of master.

I created another PR https://github.com/cypress-visual-regression/cypress-visual-regression/pull/235


Help in generating Jenkins DSL for this plugin

Hey, can anyone help us in enabling this plugin as well as adding keyword via Jenkins DSL/XML declarative format?
We tried it, however, it was overwriting the git branch and git credentials block for some reason.
Would appreciate some help regarding this.
Thanks

Closing because I'm archiving this repository feel free to fork it/otherwise update it to work for you


#1643 try with resource

GitHub issue resolved: #
Briefly describe the changes proposed in this PR:

fixed various unclosed resources
moved to try-with-resource

need to run compliance tests on this branch

I've gone a bit overboard with this one:
[INFO] Running org.eclipse.rdf4j.sail.memory.PersistentMemoryStoreIsolationLevelTest
[MemoryStore snapshot cleanup] WARN org.eclipse.rdf4j.common.concurrent.locks.LockManager - Read lock abandoned; lock was acquired in Thread-65
java.lang.Throwable: Read lock 3662 acquired in Thread-65
        at org.eclipse.rdf4j.common.concurrent.locks.LockManager.createLock(LockManager.java:173)
        at org.eclipse.rdf4j.common.concurrent.locks.AbstractReadWriteLockManager.createReadLock(AbstractReadWriteLockManager.java:99)
        at org.eclipse.rdf4j.common.concurrent.locks.ReadPrefReadWriteLockManager.getReadLock(ReadPrefReadWriteLockManager.java:78)
        at org.eclipse.rdf4j.sail.memory.MemorySailStore.openStatementsReadLock(MemorySailStore.java:142)
        at org.eclipse.rdf4j.sail.memory.MemorySailStore.access$100(MemorySailStore.java:56)
        at org.eclipse.rdf4j.sail.memory.MemorySailStore$MemorySailDataset.<init>(MemorySailStore.java:590)
        at org.eclipse.rdf4j.sail.memory.MemorySailStore$MemorySailSource.dataset(MemorySailStore.java:347)
        at org.eclipse.rdf4j.sail.memory.MemorySailStore$MemorySailSource.dataset(MemorySailStore.java:331)
        at org.eclipse.rdf4j.sail.base.SailSourceBranch.derivedFromSnapshot(SailSourceBranch.java:390)
        at org.eclipse.rdf4j.sail.base.SailSourceBranch.derivedFromSerializable(SailSourceBranch.java:365)
        at org.eclipse.rdf4j.sail.base.SailSourceBranch.dataset(SailSourceBranch.java:206)
        at org.eclipse.rdf4j.sail.base.DelegatingSailSource.dataset(DelegatingSailSource.java:72)
        at org.eclipse.rdf4j.sail.base.SailSourceConnection.addStatement(SailSourceConnection.java:453)
        at org.eclipse.rdf4j.sail.helpers.AbstractSailConnection.addStatement(AbstractSailConnection.java:442)
        at org.eclipse.rdf4j.sail.SailIsolationLevelTest$1.run(SailIsolationLevelTest.java:217)
        at java.lang.Thread.run(Thread.java:748)

@rdf4j-bot run tests

Unfortunately this patch is also making the SpinSail faster in some scenarios. Up to 50% faster. Just by cleaning up some code and closing some resources.
Before:

After:

Compliance tests passed


Fix: jagged slicing for ListArray

This PR fixes #1405: a v2-only bug in jagged slicing

Is this addressing both #1405 and #1406? If so, adding them to the Development thing on the right-bar would be a good idea, to ensure that we don't forget to close the issues when this PR fixes them.
It is entirely plausible that a kernel is missing the starts[0] != 0 case, since starts[0] == 0 is so common. If that's what it is, it can also be relatively easy to diagnose. Once you've narrowed it down to a particular kernel (it looks like you have), print out the data going into and coming out of that kernel and manually increase all of the starts and stops by 1, 2, 3, etc.
I usually debug such things with a command-line one-liner, like this:
python -c 'import awkward as ak, numpy as np; a = ak._v2.Array([[1, 2, 3], [], [4, 5]]); a.layout.content._data = np.tile(a.layout.content._data, 2); a.layout.offsets._data += 1; print(a.layout)'

with print(a.layout) replaced by the call that triggers the kernel, and the handle on 1, 2, 3, etc. is on the right-hand side of the +=. Then up-arrow, modify, up-arrow, modify.
This is hacking, pure and simple, using private accessors to modify things in place and print-outs in the source code, but it narrows down on the issue a lot faster than a debugging library. (Which is why it's great that Python discourages hacking without disallowing it. It would take much longer to understand what's wrong if this were in Java...)
What you should expect to see is values going into or coming from the kernel not moving up and down as you vary the offset (or maybe going up and down when they shouldn't be).

Right now, this is really just a staging ground for looking at the issue in #1405 / #1406. I think that there are several bugs going on here, some that are v2 specific, and some that are v1-v2. My plan would be to separate these into different PRs. So, this PR is really more about centralising a proof-of-bug ahead of actually fixing anything :)
The issue as I see it is not actually the kernel. I have no reason to believe that the kernel isn't doing what it is supposed to be. In #1406 I explored my early findings that it seems we are just doing the wrong thing, namely that we're taking the carry of one array and applying it to another. Certain implementation details / invariants mean that we don't see the bug that often, but I think fundamentally we need to extend it.
Often in these kernel bugfixing journeys I find one can go down a rabbit hole, but I am fairly confident we've narrowed down at least one problem-site.

@jpivarski OK, I've added a first set of tests that isolate one jagged slicing bug -> inner contents might not be mapped onto by the outer list/index types, but we currently raise an Exception in the ListArray _getitem_next_jagged if the list has a different length to the index.

OK, next set of tests look at a separate (though likely not independent) bug on the ListArray::_getitem_next_jagged(slicecontent=IndexedOptionArray(ListOffsetArray codepath:
https://github.com/scikit-hep/awkward-1.0/blob/edfce3800ccd1f8b90734cf9594c3b5c117441ff/src/awkward/_v2/contents/listarray.py#L472-L476
As explained in my above comment (#1406), we're just taking the indices that map into the slicecontent and applying them to the IndexedOptionArray content. I believe this is wrong - in my debugging we end up with a ListArray with starts/stops equal to the offsets 0, 2, 2, rather than 2, 2, 3. This means that when Awkward tries to pull the 0th item of the second sublist, it fails as it has length 0.

This commit (d652c81) fixes #1406 by first computing the carry that would be required to convert the ListArray into a ListOffsetArray starting at 0. We definitely have a kernel for this, but it was easy just to write a nplike to do this for a proof of concept.

It is an explicit goal to replace kernels with nplike calls if there are no correctness or performance issues in doing so. That would make the v2 code different from the v1 code (which does still rely on kernels), but if you can reduce dependence on kernels in v2, more of them will be removed when we remove v1 support. That will be less code to maintain, test, and port to CUDA.
The "performance" exception cited above is if the nplike calls require more passes over the data. If one kernel is replaced by multiple nplike function applications, it might not be a good replacement. (It's likely that some algorithms implemented entirely in nplike will be going the other way, if they can be fewer passes/faster in a single kernel call.)

I have noticed the odd kernel to which this applies, so I will keep that in mind! Here I'm not familiar enough with the slicing code to understand whether this is a symptom of a larger problem or not, hence the "HACK" commit message. I'm putting this down for now, as I think I've identified some of the bugs / solutions and I've run out of time!

Added small fix to convert the index to the appropriate array type. At present, the typetracer code does not support the magic methods for addition/subtraction, so this doesn't work. I haven't looked at the existing typetracer usage enough to know whether I need to handle this with a special case, or whether we should add support for these operations to typetracer.

I'm getting this out of context, but the TypeTracer is usually used wrapped in a high-level ak._v2.Array, which has those magic methods and passes them on to the underlying layout (containing TypeTracerArrays in this case), which eventually goes to the TypeTracer nplike's ufuncs. Maybe the latter are not implemented—it would be easy to add that, since it would only need to pass on whatever shape it gets and predict a dtype—but no new methods like __add__ and __sub__ should be implemented.

@jpivarski in this context, I'm referring to the TypeTracerArray that we see as the data associated with a layout, e.g. the starts of a ListArray.
In this trial PR, I've followed the convention of taking stops (an Index) and extracting the underlying array with nplike.asarray.  There is precedence for assuming that this result is ndarray-like, e.g.,  ak_where where we anticipate that the array has __eq__
https://cs.github.com/scikit-hep/awkward-1.0/blob/6ff41fb299167333d2715cae7c0904d8cd5dba7e/src/awkward/_v2/operations/structure/ak_where.py?q=asarray#L116
Here, if one tries to compute nplike.asarray(stops) - nplike.asarray(starts) for a TypeTracerArray, they will see an error as we do not implement TypeTracerArray.__sub__.
I think the reason that this is at all apparent is that there is a much softer boundary between what should be done by a kernel, and what should be done with the nplike interface. Practically speaking, the nplike + ndarray interface is a well-tested, well known subset of useful kernels.
I think we currently have an assumed "narrow" interface for nplike which is a subset of useful functions (in particular, searchsorted and friends) + the basic NDArrayOperatorsMixin interface on the array object. The question that I raised earlier is, I suppose:

how much like an ndarray should the TypeTracerArray behave, and in defining this, how should we define this interface so that Awkward code does not accidentally use unsupported methods?

The latter sentence is not a huge problem - we should pick this up in our tests, but in general I like to have the semantics / API well defined.

That's true! I stand corrected—the TypeTracerArray will need to have __add__ and __sub__ methods, as well as a few others that might be needed by the codebase, like array.any(). We managed to eliminate all explicit uses of NumPy in favor of nplike, which channels the code path through the nplike functions that we control, but the codebase does still include method calls on the array objects, including those like __add__. Fortunately, for a completely artificial type like TypeTracerArray (as opposed to pre-existing libraries like CuPy), we can control that code path as well.
But you're right that TypeTracerArray.__add__ and TypeTracerArray.__sub__ will need to be written. (That's already the case for UnknownScalar, in the same library. The good news is that these are simple: __add__ and __sub__ are probably not even going to be different from each other.)
Channeling everything through nplike was an attempt to define an API—the complete set of functions used in our codebase on the arrays backing Index and NumpyArray are or should be in the list in nplike.py. Unfortunately, methods, and especially operators, are not as well controlled. To make the list of functions in nplike.py, I could do a text-based search (with the assumption that we never import X from numpy). To find all of the methods and operators used, in an automated way, we'd need a type-checker like mypy, as well as all the annotations (and no typing.Any!). We don't have that.
However, just adding the methods whenever we hit them in testing does work. All it misses is the certainty of knowing that we got them all

The good news is that these are simple: add and sub are probably not even going to be different from each other.

Absolutely, these functions will all be identical apart from __truediv__ (and maybe any others I've forgotten?)

[nplike] was an attempt to define an API
...
However, just adding the methods whenever we hit them in testing does work. All it misses is the certainty of knowing that we got them all

Yes, I don't think this is a pressing concern yet. Once we add type hints, we can implement a protocol for the ndarray interface that we expect.

I modernized this PR because it's addressing a bug in the Prioritized Issues list.
As it is, the only tests that fail are
tests/v2/test_1405-slicing-untested-cases.py::test_index_unmapped
tests/v2/test_1502-getitem-jagged-issue1406.py::test_success_nonempty_list

which are directly intended to test #1405 and #1406, so at least this PR does no harm. (It can't be merged because it doesn't fix the issue it's intended to, but not breaking other things is a big plus.)

OK, so the reason that v2 doesn't agree with v1 for this test case is that we don't use the same kernel in ListArray to traverse a jagged slice. ListArray.cpp uses ListArray_getitem_jagged_apply_64 whilst listarray.py uses awkward_ListArray_getitem_jagged_descend
Explicitly, jagged slicing is failing when we try to slice the entire inner ListOffsetArray:
ak._v2.contents.ListOffsetArray(
        ak._v2.index.Index64(np.array([0, 1, 2, 3], dtype=np.int64)),
        ak._v2.contents.NumpyArray(np.array([2, 2, 2], dtype=np.int64)),
)```
Rather than the projected one, i.e.
ak._v2.contents.ListOffsetArray(
        ak._v2.index.Index64(np.array([0, 1, 2], dtype=np.int64)),
        ak._v2.contents.NumpyArray(np.array([2, 2, 2], dtype=np.int64)),
)```
We have code that ensures that the content length matches the length of the slice, which fails without this projection.

My "fix" (ugly though it is) for `listarray.py` in d7a1d53 handled this for the option-type slicing, by `carry`ing only the mapped items. @ioanaif do you know why we changed the kernel here? I'm trying to get up to speed. It seems as though do need to carry, but it might be better to do it with a proper kernel rather than lots of `nplike` code.

@jpivarski I just remembered that Ioanna is working on CLAD this week, so perhaps I'm better pinging you to ask about the kernel change in my above comment?

I think there's no reason that v1 and v2 should ever differ on what kernels they use. In some cases, v2 replaces trivial kernels with the corresponding nplike call, but I don't think it should ever replace one kernel for another. The "I don't think" is based on the fact that we didn't rethink any of the getitem logic from v1 to v2; it was ported.
However, in this case, you're looking at the wrong function. C++ can dispatch by argument type but Python can't, so there was some subtlety in the porting. The getitem_next_jagged function that you point to:
https://github.com/scikit-hep/awkward/blob/352b0dead74846ad2a56d385be4694ec87072a08/src/libawkward/array/ListArray.cpp#L1827-L1832
is actually the specialization of that function in which the third argument is SliceArray64 (would be Index64 in v2).
There's also one in which the third argument is SliceMissing64 (would be IndexedOptionArray in v2):
https://github.com/scikit-hep/awkward/blob/352b0dead74846ad2a56d385be4694ec87072a08/src/libawkward/array/ListArray.cpp#L1887-L1892
and one in which the third argument is SliceJagged64 (would be ListOffsetArray in v2):
https://github.com/scikit-hep/awkward/blob/352b0dead74846ad2a56d385be4694ec87072a08/src/libawkward/array/ListArray.cpp#L1975-L1980
The equivalent in Python is to do the dispatching manually within the function, in if statements. The implementation you pointed to is
https://github.com/scikit-hep/awkward/blob/352b0dead74846ad2a56d385be4694ec87072a08/src/awkward/_v2/contents/listarray.py#L322
but there's also
https://github.com/scikit-hep/awkward/blob/352b0dead74846ad2a56d385be4694ec87072a08/src/awkward/_v2/contents/listarray.py#L365
(huh? not Index64?) and
https://github.com/scikit-hep/awkward/blob/352b0dead74846ad2a56d385be4694ec87072a08/src/awkward/_v2/contents/listarray.py#L434-L436
and
https://github.com/scikit-hep/awkward/blob/352b0dead74846ad2a56d385be4694ec87072a08/src/awkward/_v2/contents/listarray.py#L556
(huh? slices can't be EmptyArray, thanks to the normalization described in https://github.com/scikit-hep/awkward/pull/1597#issuecomment-1227754769).
Both v1 and v2 use awkward_ListArray_getitem_jagged_descend on the SliceJagged64/ListOffsetArray case. But if you were debugging, following the wrong code path, that could have something to do with an error that you see, and maybe this code checking for the wrong slice types accounts for it. It certainly looks suspicious.

I'm going to try to collect a complete list of getitem calls and what slice types they're assuming. Any line numbers correspond to main right now, which is commit dd2a3f400e29fc9ea908fc7d8267f592091457bb.

Content (content.py)

_getitem_next_field(self, head, tail, advanced)
_getitem_next_fields(self, head, tail, advanced)
_getitem_next_newaxis(self, tail, advanced)
_getitem_next_ellipsis(self, tail, advanced)

tail may contain Index64

_getitem_next_regular_missing(self, head, tail, advanced, raw, length)

head is Index64

_getitem_next_missing_jagged(self, head, tail, advanced, that)

head has content (is IndexedOptionArray)

_getitem_next_missing(self, head, tail, advanced)

head asserted to be IndexedOptionArray

_getitem(self, where)

where dispatched based on type (wide open to any user input)

BitMaskedArray

_getitem_nothing(self)
_getitem_at(self, where)

where assumed to be int

_getitem_range(self, where)

passed to ByteMaskedArray

_getitem_field(self, where, only_fields=())

passed to content

_getitem_fields(self, where, only_fields=())

passed to content

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

passed to ByteMaskedArray

_getitem_next(self, head, tail, advanced)

head dispatched by (), int, Index64, ListOffsetArray, str, list (of str), newaxis, Ellipsis, IndexedOptionArray

ByteMaskedArray

_getitem_nothing(self)
_getitem_at(self, where)

where assumed to be int

_getitem_range(self, where)

where assumed to be slice

_getitem_field(self, where, only_fields=())

passed to content

_getitem_fields(self, where, only_fields=())

passed to content

_getitem_next_jagged_generic(self, slicestarts, slicestops, slicecontent, tail)

no assumptions made about slicecontent (used as duck-typing)

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

passed to self._getitem_next_jagged_generic (following v1 C++ constraints)

_getitem_next(self, head, tail, advanced)

head dispatched by (), int, Index64, ListOffsetArray, str, list (of str), newaxis, Ellipsis, IndexedOptionArray

EmptyArray

_getitem_nothing(self)
_getitem_at(self, where)
_getitem_range(self, where)
_getitem_field(self, where, only_fields=())
_getitem_fields(self, where, only_fields=())

where assumed to be a list

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

no assumptions (errors out)

_getitem_next(self, head, tail, advanced)

head dispatched by (), int, slice, str, list (of str), newaxis, Ellipsis, Index64, ListOffsetArray, IndexedOptionArray

IndexedArray

_getitem_nothing(self)
_getitem_at(self, where)

where assumed to be int

_getitem_range(self, where)

where assumed to be slice

_getitem_field(self, where, only_fields=())

passed to content

_getitem_fields(self, where, only_fields=())

passed to content

_getitem_next_jagged_generic(self, slicestarts, slicestops, slicecontent, tail)

no assumptions made on slicecontent (duck typed)

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

passed to self._getitem_next_jagged_generic

_getitem_next(self, head, tail, advanced)

head dispatched by (), int, Index64, ListOffsetArray, str, list (of str), newaxis, Ellipsis, IndexedOptionArray

IndexedOptionArray

_getitem_nothing(self)
_getitem_at(self, where)

where assumed to be int

_getitem_range(self, where)

where assumed to be slice

_getitem_field(self, where, only_fields=())

passed to content

_getitem_fields(self, where, only_fields=())

passed to content

_getitem_next_jagged_generic(self, slicestarts, slicestops, slicecontent, tail)

no assumptions made on slicecontent (duck typed)

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

passed to self._getitem_next_jagged_generic

_getitem_next(self, head, tail, advanced)

head dispatched as (), int, slice, Index64, ListOffsetArray, str, list (of str), newaxis, Ellipsis, IndexedOptionArray

ListArray

_getitem_nothing(self)
_getitem_at(self, where)

where assumed to be int

_getitem_range(self, where)

where assumed to be slice

_getitem_field(self, where, only_fields=())

passed to content

_getitem_fields(self, where, only_fields=())

passed to content

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

slicecontent dispatched by ListOffsetArray, NumpyArray (!?!), IndexedOptionArray, EmptyArray (!?!)

_getitem_next(self, head, tail, advanced)

head dispatched by (), int, slice, str, list (of str), newaxis, Ellipsis, Index64, ListOffsetArray, IndexedOptionArray

ListOffsetArray

_getitem_nothing(self)
_getitem_at(self, where)

where assumed to be int

_getitem_range(self, where)

where assumed to be slice

_getitem_field(self, where, only_fields=())

passed to content

_getitem_fields(self, where, only_fields=())

passed to content

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

passed to ListArray._getitem_next_jagged

_getitem_next(self, head, tail, advanced)

head dispatched as (), int, slice, str, list (of str), newaxis, Ellipsis, Index64, ListOffsetArray, IndexedOptionArray

NumpyArray

_getitem_nothing(self)
_getitem_at(self, where)

where assumed to be int

_getitem_range(self, where)

where assumed to be slice

_getitem_field(self, where, only_fields=())

errors out

_getitem_fields(self, where, only_fields=())

errors out

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

may pass slicecontent to RegularArray._getitem_next_jagged

_getitem_next(self, head, tail, advanced)

head dispatched as (), int, slice, newaxis, Ellipsis, str, list (of str), Index64, ListOffsetArray, IndexedOptionArray

RecordArray

_getitem_nothing(self)
_getitem_at(self, where)

where assumed to be int

_getitem_range(self, where)

where assumed to be slice

_getitem_field(self, where, only_fields=())

where assumed to be str

_getitem_fields(self, where, only_fields=())

where assumed to be list (of str)

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

passed to each item of contents

_getitem_next(self, head, tail, advanced)

head dispatched as (), str, list (of str), IndexedOptionArray, or passed to the _getitem_next of each item of contents

RegularArray

_getitem_nothing(self)
_getitem_at(self, where)

where assumed to be int

_getitem_range(self, where)

where assumed to be slice

_getitem_field(self, where, only_fields=())

passed to content

_getitem_fields(self, where, only_fields=())

passed to content

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

passed to ListOffsetArray._getitem_next_jagged

_getitem_next(self, head, tail, advanced)

head dispatched as (), int, slice, str, list (of str), newaxis, Ellipsis, Index64, ListOffsetArray, IndexedOptionArray

UnionArray

_getitem_nothing(self)
_getitem_at(self, where)

where assumed to be int

_getitem_range(self, where)

where assumed to be slice

_getitem_field(self, where, only_fields=())

passed to each item of contents

_getitem_fields(self, where, only_fields=())

passed to each item of contents

_getitem_next_jagged_generic(self, slicestarts, slicestops, slicecontent, tail)

raises error if can't be simplified, otherwise passed to simplified._getitem_next_jagged

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

passed to _getitem_next_jagged_generic

_getitem_next(self, head, tail, advanced)

head dispatched to (), int, slice, Index64, ListOffsetArray, str, list (of str), newaxis, Ellipsis, IndexedOptionArray

UnmaskedArray

_getitem_nothing(self)
_getitem_at(self, where)

passed to content

_getitem_range(self, where)

where assumed to be slice

_getitem_field(self, where, only_fields=())

passed to content

_getitem_fields(self, where, only_fields=())

passed to content

_getitem_next_jagged(self, slicestarts, slicestops, slicecontent, tail)

passed to content

_getitem_next(self, head, tail, advanced)

head dispatched as (), int, slice, Index64, ListOffsetArray, str, list (of str), newaxis, Ellipsis, IndexedOptionArray

The only red flags (labeled by "!?!") are the ones you found in ListArray. The rest all look correct.
You can use this, by the way, as a step into typing all the getitem methods. These are all of them (they all have "getitem" in their names, and that's what I searched for to make this).

@jpivarski thank you for such a thorough investigation. I did a visual trace-through by eye, and clearly mistook the execution pathway. I like using the CLion debugger, but it's less convenient to run both CLion and PyCharm from the same location. Once I reconfigured my editors, it was clear that indeed I was looking at the wrong method. Additionally, I must have included the kernel prefix that is missing in C++, so I really did lead us on a wild goose chase!
I've found the cause of the difference between v1 and v2 - https://github.com/scikit-hep/awkward/blob/352b0dead74846ad2a56d385be4694ec87072a08/src/awkward/_v2/contents/listarray.py#L190-L205 is a new pathway that ultimately produces a ListOffsetArray with a length that exceeds the offsets. Allowing un-trimmed layouts is a common feature in the codebase, so I'm assuming that the best way to handle this is to explicitly trim the content ourselves.

This isn't ready for review just yet. I've fixed a slicing issue in ListArray._getitem_next_jagged, and corrected an older test that is asserting the wrong output. In addition, I've copied this older v2 test into v1 to show that the bug exists in both versions. We'll need to skip that until it's fixed in turn.
There is also an ugly hack in ListArray._getitem_next_jagged that I added at the start of this PR. I'll need to rethink that, hence moving to draft status.

OK, that was surprisingly easy. It's the same fix in two places.


twister: Fix test-only tests with hardware map fixtures

In test-only mode with a hardware map, all tests with fixtures were skipped, even when the hardware map has appropriate fixtures defined. This change fixes it.
E.g. with this call:
west twister --device-testing --test-only -T tests/foo --hardware-map hardware-map.yml

For "DRY" reasons, moved the check for fixtures in the hardware map to the check_runnable test in TestInstance.


Picker should migrate to Select-Only Combobox Example from WAI-ARIA Authoring Practices Guide

🐛 Bug Report
Picker implements the (Deprecated) Collapsible Dropdown Listbox Example from an outdated version of the WAI-ARIA 1.2 Authoring Practices Guide. We should update Picker to follow the latest recommendation, Select-Only Combobox Example.
🤔 Expected Behavior
Picker should be announced as a combo box and with its text content as its value, which should reduce the need to specify aria-labelledby for both the label and the value content.
😯 Current Behavior
Picker announces as a dropdown menu button.
💁 Possible Solution

🔦 Context

💻 Code Sample

🌍 Your Environment

Software
Version(s)

react-spectrum
<EMAIL_ADDRESS>

Browser
Chrome Version 110.0.5481.100 (Official Build) (arm64)

Operating System
macOS Ventura 13.2.1 (22D68)

🧢 Your Company/Team
Adobe/Accessibility
🕷 Tracking Issue (optional)
A11Y-5854

What's the advantage of doing this? I tested the select-only combobox example, and VoiceOver on macOS doesn't announce the options at all when navigating with the arrow keys.

What's the advantage of doing this? I tested the select-only combobox example, and VoiceOver on macOS doesn't announce the options at all when navigating with the arrow keys.

I'm not sure we would have the same issue with VoiceOver and Safari on macOS, which is an open issue against WebKit (https://bugs.webkit.org/show_bug.cgi?id=231724), because with Picker, we focus items in the listbox directly rather than use aria-activedescendant. With Chrome on macOS, aria-activedescendant is working correctly.
Advantages:

We would be following the latest WAI-ARIA APG recommendation. To find (Deprecated) Collapsible Dropdown Listbox Example, I had to dig back through old versions of the APG.
Simplifies labelling, because we would no longer need to concatenate the IDREFs for the label and the value.
Screen reader announcement of value and label would be more consistent with platform and AT conventions, adding commas where appropriate, etc.

Yeah I'm just concerned that it is a pretty big change for not much benefit overall given we already have a working implementation and there aren't really any major problems with it that this would solve. We would need to invest a lot of time into testing and working around screen reader/browser issues again, which we already did for the last implementation. We also had a ton of problems with announcements in ComboBox (which can be seen in the APG example itself) so it would be unfortunate to need to solve all of that again.


Updated Mac/Linux ANDROID_HOME path to include ${HOME}

Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
Using ~ in the .bashrc or .zshrc fails inside of double quotes.  By changing this to $HOME the path is exported correctly in all instances.
Explain the motivation for making this change. What existing problem does the pull request solve?
It corrects the path to the Android home location if SDK is installed via Android Studio. Using ~ for the home path is failing.  By added $HOME you are guaranteed the correct path.
Prefer small pull requests. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
Test plan (required)
Install Android Studio & SDK.
Set environment variable in .bashrc or .zshrc with ${HOME}/Library/Android/sdk instead of ~/Library/Android/sdk
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
Code formatting
Look around. Match the style of the rest of the codebase. See also the simple style guide.
For more info, see the "Pull Requests" section of our "Contributing" guidelines.

I  have completed the CLA with @daynewright 👍

Nice change. Thanks!


Object detection Touchdesigner bounding boxes not aligned

I noticed while using the object detection portion of the TOX that the bounding boxes that Touchdesginer is drawing do not align with bounding boxes that Mediapipe is drawing. They are offset and don't accurately map back onto the video.
Thanks for putting this resource together, it is a really great tool and addition to touchdesigner!

Hi @mikebru thanks for letting us know - we'll take a look at the code and see what's going on.

I also observe the same thing here. It doesn't look like a translation or scaling problem in instance space. It seems that the objects are in other positions randomly.
I am great to see the possibility of using mediapipe in TD. Thanks for this project.

I noticed the same using the current last release (v0.3.2)

I spent a few hours this week fixing up all the bounding boxes for the object tracking and added them for the face tracking too.
The changes are all checked in, so will be there next time we do a release build.

This fix got released in v0.3.3 so closing this issue :)


Allow custom axis scales through common component

Many clippy errors also. Don't forget cargo clippy is your friend. :-)


Test failure with Python 3.13:  TestUpdateAbstractMethods.test_remain_abstract[False] does not raise the expected TypeError

attrs: 23.2.0 built in Fedora Linux 40 with Python 3.13.0a3 cause this test failure:
____________ TestUpdateAbstractMethods.test_remain_abstract[False] _____________

self = <tests.test_abc.TestUpdateAbstractMethods object at 0x7f8f99690860>
slots = False

    def test_remain_abstract(self, slots):
        """
        If an attrs class inherits from an abstract class but doesn't implement
        abstract methods, it remains abstract.
        """

        class A(abc.ABC):
            @abc.abstractmethod
            def foo(self):
                pass

        @attrs.define(slots=slots)
        class StillAbstract(A):
            pass

        assert inspect.isabstract(StillAbstract)
        expected_exception_message = (
            "^Can't instantiate abstract class StillAbstract without an "
            "implementation for abstract method 'foo'$"
            if PY_3_12_PLUS
            else "class StillAbstract with abstract method foo"
        )
>       with pytest.raises(TypeError, match=expected_exception_message):
E       Failed: DID NOT RAISE <class 'TypeError'>

tests/test_abc.py:59: Failed

@befeleme What does it raise instead? Do you have a more complete excerpt? What happens if you drop with pytest.raises() and just run what's inside?

I'm running python -m pytest -k "test_remain_abstract" -vvv in a venv with Python 3.13.0a3 and the project configured according to the contributors guide.
It gets weirder, now slots = False passes, but slots = True fails:
________________________________ TestUpdateAbstractMethods.test_remain_abstract[True] _________________________________

self = <tests.test_abc.TestUpdateAbstractMethods object at 0x7f32a2d892b0>, slots = True

    def test_remain_abstract(self, slots):
        """
        If an attrs class inherits from an abstract class but doesn't implement
        abstract methods, it remains abstract.
        """

        class A(abc.ABC):
            @abc.abstractmethod
            def foo(self):
                pass

        @attrs.define(slots=slots)
        class StillAbstract(A):
            pass

        assert inspect.isabstract(StillAbstract)
        expected_exception_message = (
            "^Can't instantiate abstract class StillAbstract without an "
            "implementation for abstract method 'foo'$"
            if PY_3_12_PLUS
            else "class StillAbstract with abstract method foo"
        )
        # with pytest.raises(TypeError, match=expected_exception_message):
>       StillAbstract()
E       TypeError: Can't instantiate abstract class StillAbstract without an implementation for abstract method 'foo'

tests/test_abc.py:60: TypeError

In an interactive Python 3.13.0a3 console in both cases TypeError is raised. I'm really confused.

This is reproducible with 3.13.0a3 and is not Fedora-specific (I'm using pyenv under Gentoo Linux).
Here's another observation: running each of the parameterized tests separately succeeds and running both in the same test session makes one fail. There must be a shared state or caching somewhere.
$ tox -qq -e py-tests -- tests/test_abc.py::TestUpdateAbstractMethods::test_remain_abstract[False]
===================================================================== test session starts =====================================================================
platform linux -- Python 3.13.0a3, pytest-8.0.0, pluggy-1.4.0
cachedir: .tox/py-tests/.pytest_cache
rootdir: ~/src/github/python-attrs/attrs
configfile: pyproject.toml
plugins: hypothesis-6.97.2, xdist-3.5.0, mypy-plugins-3.0.0
collected 1 item

tests/test_abc.py .                                                                                [100%]

====================================================================== 1 passed in 0.02s ======================================================================

$ tox -qq -e py-tests -- tests/test_abc.py::TestUpdateAbstractMethods::test_remain_abstract[True]
===================================================================== test session starts =====================================================================
platform linux -- Python 3.13.0a3, pytest-8.0.0, pluggy-1.4.0
cachedir: .tox/py-tests/.pytest_cache
rootdir: ~/src/github/python-attrs/attrs
configfile: pyproject.toml
plugins: hypothesis-6.97.2, xdist-3.5.0, mypy-plugins-3.0.0
collected 1 item

tests/test_abc.py .                                                                                [100%]

====================================================================== 1 passed in 0.02s ======================================================================

$ tox -qq -e py-tests -- tests/test_abc.py::TestUpdateAbstractMethods::test_remain_abstract
===================================================================== test session starts =====================================================================
platform linux -- Python 3.13.0a3, pytest-8.0.0, pluggy-1.4.0
cachedir: .tox/py-tests/.pytest_cache
rootdir: ~/src/github/python-attrs/attrs
configfile: pyproject.toml
plugins: hypothesis-6.97.2, xdist-3.5.0, mypy-plugins-3.0.0
collected 2 items

tests/test_abc.py .F                                                                                [100%]

========================================================================== FAILURES ===========================================================================
____________________________________________________ TestUpdateAbstractMethods.test_remain_abstract[True] _____________________________________________________

self = <tests.test_abc.TestUpdateAbstractMethods object at 0x7f1901a874d0>, slots = True

    def test_remain_abstract(self, slots):
        """
        If an attrs class inherits from an abstract class but doesn't implement
        abstract methods, it remains abstract.
        """

        class A(abc.ABC):
            @abc.abstractmethod
            def foo(self):
                pass

        @attrs.define(slots=slots)
        class StillAbstract(A):
            pass

        assert inspect.isabstract(StillAbstract)
        expected_exception_message = (
            "^Can't instantiate abstract class StillAbstract without an "
            "implementation for abstract method 'foo'$"
            if PY_3_12_PLUS
            else "class StillAbstract with abstract method foo"
        )
>       with pytest.raises(TypeError, match=expected_exception_message):
E       Failed: DID NOT RAISE <class 'TypeError'>

tests/test_abc.py:59: Failed
=================================================================== short test summary info ===================================================================
FAILED tests/test_abc.py::TestUpdateAbstractMethods::test_remain_abstract[True] - Failed: DID NOT RAISE <class 'TypeError'>
================================================================= 1 failed, 1 passed in 0.04s =================================================================

Action items: bisect when this started happening. Is 3.13.0a2 working? What's the last release where testing succeeds? Is it CPython that needs fixing or pytest, maybe? I'd look into the slots changes in CPython, I suppose.

I see you run pytest 8 – could this be actually related to #1233? Would you mind re-testing with the pin I've added the other day?

@hynek I tested with older pytest versions too, just forgot to mention those. Perhaps it's time to plug py313 into the CI as experimental.

I'm not sure what happened and where but during my work on a different issue with Python 3.13 I've realized that I'm no longer able to reproduce this one. Using Python 3.13.0a4 and pytest 8.0.2.
Could please anybody verify it?

I can confirm that all of test_abc is passing now! 🎉
I'm opening #1256 to see if we can add it to CI.


use electron builder to optimize release process

Describe the solution you'd like
Release desktop installer for Mac, linux and windows in one script npm run release

done by 38510a4872ebde551d61fb26a3648cb061b4e29b


Date types and durations

right now, code like this doesn't work:
df = DataFrame(d1 = [Date(2016,3,31), Date(2015,3,31)], d2 = [Date(2016,3,30), Date(2015,3,30)]) df[:delta] = df[:d1] - df[:d2]
Here is the error I get from the second line of this expression:

ERROR: MethodError: convert has no method matching convert(::Type{Date}, ::Base.Dates.Day)
This may have arisen from a call to the constructor Date(...),
since type constructors fall back to convert methods.
Closest candidates are:
Date(::Base.Dates.Period...)
Date(::Any)
Date(::Any, ::Any)
...

My hunch is that its not working because DataFrames expects that the output of the differencing operator should have the same type as one (or both) of the inputs to the differencing operator.  With a Date, this isn't true, as the difference is a "Day" as opposed to a "Date"
My current workaround to this is to convert each DataArray to an array, do the math on the two arrays, and then assign that to a new column in df:
df[:delta] = convert(Array, df[:d1]) - convert(Array, df[:d2])
Is there a more natural way to do this?

The problem is actually in DataArrays, you don't need a data frame to reproduce it:
da = DataArray([Date(2016,3,31), Date(2015,3,31)])
da - da

The definition for arithmetic operations uses promote_type(eltype(a), eltype(b)) as the element type of the result. Looks like it should use Base.promote_op(Base.SubFun(), eltype(a), eltype(b)).
Note that NullableArrays.jl uses promote_op, and still suffers from the same bug, so there might be something else to do.

This now works because DataFrames doesn't require DataArrays as underlying storage
julia> df = DataFrame(d1 = [Date(2016,3,31), Date(2015,3,31)], d2 = [Date(2016,3,30), Date(2015,3,30)])
2×2 DataFrames.DataFrame
│ Row │ d1         │ d2         │
├─────┼────────────┼────────────┤
│ 1   │ 2016-03-31 │ 2016-03-30 │
│ 2   │ 2015-03-31 │ 2015-03-30 │

julia> df[:delta] = df[:d1] - df[:d2]
2-element Array{Base.Dates.Day,1}:
 1 day
 1 day


build: resolve failure on nodejs 12.x / 16.x

merging this into the feature branch because adding the missing test case (for coverage) is not enough
because production code change is needed to fix a bug as well.


feat(linter): add missing test cases to no-unnecessary-type-constraint

Based on this https://github.com/oxc-project/oxc/issues/2934 I added missing test cases

Reviewing it I saw that test cases are the same

I'm sorry, I thought people may not consider it.


[proposal] Fixture for acceptance tests

I was trying to build an integration test for the Events API (see test integration from webapi to websocket in  #1349) but I soon noticed that it was quite a different test from the ones we have in our code base, and that's the reason why I'm creating a PR for that.
The idea was to test the new Events API using BigchainDB as a blackbox:

connect to the web socket endpoint
create a transaction
push the transaction to the API
check if the transaction pops up in the web socket

This kind of testing can be defined in many ways:

Acceptance testing
Black box testing
Integration testing
Validation testing

This kind of testing also doesn't increment code coverage, but it might be useful to describe and test the behavior of BigchainDB.
Thoughts?
Update: works on my machine™ but Travis-ci is complaining.

I understand what you are trying to do and I agree that it would be useful to have a fixture that would start the bigchaindb process for some tests. But the test itself does not represent the usefulness of such a fixture since its basically only testing the driver which should be done on the driver project itself. From the backend we already test the views.

All jobs are timing out. Either the bigchaindb process is not starting correctly or the is not being shutdown correctly.

I understand what you are trying to do and I agree that it would be useful to have a fixture that would start the bigchaindb process for some tests. But the test itself does not represent the usefulness of such a

I understand what you are trying to do and I agree that it would be useful to have a fixture that would start the bigchaindb process for some tests. But the test itself does not represent the usefulness of such a fixture since its basically only testing the driver which should be done on the driver project itself. From the backend we already test the views.

The test can be described as: in normal circumstances if you push a transaction through the Web API, you should see it validated at one point. It was the simplest integration test that came up to my mind while creating the fixture. The real test scenario I'm trying to tackle is test integration from webapi to websocket, but since #1349 is not merged yet, I don't have the code to test :smiley:.

All jobs are timing out. Either the bigchaindb process is not starting correctly or is not being shutdown correctly.

Yep, I noticed it, and I still don't know why this is happening since it works on my machine™. I'll spend some time on it later.

ping

ping

Pong! I've set a reminder to review this at the end of next week.


For project member if member is deleted externally, set name as externalId if name is missing

When the github team is removed on github, the projects where the team is added as a member, that environment can no longer be edited on the UI.
The reason is actually UI hitting a NPE since for github team, it tries to use the member.name property which may be null.
We are adding a fix on the backend to ensure that if the name of the member is null, we set the name to be externalID in such case where the backend entity is removed.

https://github.com/rancher/rancher/issues/16850


Merge ceviche repo 🎉

This PR merges the code from ceviche back into the public repo. ceviche is our codename for Preact X. An alpha release on npm will follow shortly on March 4th.
Todos:

[x] Resolve Merge-Conflicts
[x] Preserve git history of both projects
[x] Verify changes with git diff ceviche..ceviche/master
[x] Remove 8.x code that's been unaffected by the merge
[x] Verify TS types, children type-checking seems to be broken.
[x] Fix missing Text-Nodes in Children tests.
[x] Fix missing code coverage in compat.

Note: The commit view here on GitHub doesn't show all commits. The most recent ones are missing for me in the web ui. They're all there when viewed locally via git.

Coverage decreased (-3.1%) to 96.854% when pulling 32ba027a344f4c0d279a5ab058f35445016bfa22 on ceviche into 3aaa578270c0c6cd1fb7f5cf992737eec2934433 on master.

Just went over the changes and pushed 2 minor corrections to our TS types.
We seemed to have missed to enable code coverage for compat in our ceviche repo, which is why coveralls is failing. I just pushed a few commits adding a lot of tests for compat. Something seems to be going on with Children.map/forEach. It seems to swallow text nodes. It's unlikely that they are causing it themselves, it's probably something else in compat.
I'm quite busy today. Maybe I can take an hour off to check this evening.
Apart from that I think we're good to go. All other open PRs that we have in the other repo can be done here and be based on master once this PR lands.

Phew, finally managed to add tests for every missing line that wasn't covered with a test :tada: Everything is green now :+1:

@marvinhagemeister going above and beyond as always 😁

@developit No need for it, already found and fixed it :tada: https://github.com/developit/preact/pull/1302/commits/9ab2ea770285cd477315eb5a51d5fa16b1010280

Minor change 1 is going to prove hot on the wheels of browsers, at least in comparison to the current implementation, and when hooks land; considering inline-functions will become more common in that space. Is there any reason the previous route was ditched – 1 listener mount + a map of callbacks that are updated?

@thysultan The changelog isn't really up to date. Event listeners in ceviche work the same way as they do in current preact. That section was written before we implemented them there.
To avoid any further confusion I'll remove it.

So exciting!

Merge time, and let the community celebrate? :shipit: :dancers: :tada:

Why is not included "compat/*" in package.files?

@mochiya98 Good catch! Added it :+1:

aaaaand we're a go

@developit dont forget the npm release :wink:

Great job! Waiting for updated docs and release notes 😊

@marvinhagemeister 🎉


Can’t Run a Coral EdgeTPU classification model with TFLite API

I am trying to apply the tutorial of coral USB accelerator with MacOS 10.15. The tutorial link : Get started with the USB Accelerator
Everything is successfully done until the last step "Run the image classifier with the bird photo (shown in figure 1)"
I copied the code to my terminal:
python3 classify_image.py \ --model models/mobilenet_v2_1.0_224_inat_bird_quant_edgetpu.tflite \ --labels models/inat_bird_labels.txt \ --input images/parrot.jpg
My terminal returns this error information:
Traceback (most recent call last):   File "classify_image.py", line 122, in <module>     main()   File "classify_image.py", line 99, in main     interpreter = make_interpreter(args.model)   File "classify_image.py", line 73, in make_interpreter     {'device': device[0]} if device else {})   File "/Users/xxx/anaconda3/lib/python3.6/site-packages/tflite_runtime/interpreter.py", line 204, in __init__     model_path, self._custom_op_registerers)) SystemError: <built-in function InterpreterWrapper_CreateWrapperCPPFromFile> returned a result with an error set
How should I fix it?

Can you share the outputs of these commands?
python3 -c 'print(__import__("tflite_runtime").__git_version__)'
python3 -c "from ctypes import *; cdll.LoadLibrary('libedgetpu.so.1.0'); print('success')"

``python3 -c 'print(import("tflite_runtime").git_version)'

'0.6.0-76902-gd855adfc5a' python3 -c "from ctypes import *; cdll.LoadLibrary('libedgetpu.so.1.0'); print('success')"
OSError: dlopen(libedgetpu.so.1.0, 6): image not found md5sum /usr/local/lib/libedgetpu.1.0.dylib
a8a47d9dc537bd56c77cc5c7cb4e6aa6  /usr/local/lib/libedgetpu.1.0.dylib``

Although I still don't know the reason, today when I run the command again on the same computer, it worked well as the webpage described. So please close this Issue thread.

@ssghost Ahh, I was trying to check if the correct version of /usr/local/lib/libedgetpu.1.0.dylib was installed on our system.
But from your outputs, everything looks good :)


Spurious syntax error with dependent pairs (only occuring with FSharp build)

The follwing code
(* Adding this line fixes the issue *)
//type bar (i:int) = int

val foo : (i:int & int)
let foo = (| 0, 0 |)

causes a syntax Error when using the FSharp build.
When using the ocaml binary the file verifies correctly.
Strangely, adding the commented type declaration fixes the issue.

See also #356 for another example of divergence between the OCaml and F# binaries.

This also reminds me #252, which also disappeared if adding a type declaration.

#252 happens with both the OCaml and the .NET binary though.

I can confirm that this parsing issue still appears with --universes and the FSharp build.
[hritcu@detained bug-reports]$ fstar.exe --universes bug404.fst
/home/hritcu/Projects/fstar/pub/examples/bug-reports/bug404.fst(6,22-6,23) : Error
Syntax error

Is this really Priority 1? I'd be delighted if someone fixed the F# lexer ... but I'm not going to get around to it anytime soon myself.

fixed with the menhir parser


scootapi,workerapi/client - client and dialer refactoring

Refactor the api clients somewhat to support use of a dialer interface to manage thrift connection. Separate client from cli in workerapi, scootapi too commingled for now. This is primarily to support custom dialer implementations in closed source and to decouple client/cli/connection logic.

separate workerapi client and cli client
move dialer to common and use with both clients
distinguish package, var, struct field names

Current coverage is 63.99% (diff: 100%)

Merging #148 into master will increase coverage by 0.07%

@@             master       #148   diff @@
==========================================
  Files            61         61
  Lines          2633       2633
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits           1683       1685     +2
+ Misses          832        830     -2
  Partials        118        118

Powered by Codecov. Last update 616d1ef...e04e195


Google Maps API and Google Earth

Hello,
maybe this's a bit out of the scope of your project but when you have a XCSoar task file (or any other PNA), it will be nice to be able to draw this task on a map with much more details.
A webpage using Google Maps API could be an interesting idea.
Maybe Aerofiles should be able to output such a HTML page (or a link to webpage).
pygmaps or pygmaps-extended might help https://code.google.com/p/pygmaps/ https://github.com/thearn/pygmaps-extended
Having this task displayed in Google Earth will be also interesting as we can have 3D view.
pyKML could help http://googlegeodevelopers.blogspot.fr/2012/01/introducing-pykml-python-library-for.html
Kind regards

@scls19fr  you are right, this is out of scope, but we are planning to allow something like this in https://github.com/skylines-project/skylines

Thanks for the link. This is a very interesting project.


Adds Sqlite3.release/2 for prepared statements

This should in theory fix #154

Well that was weird, compilation segfaulted

I wonder if the segfault is from enif_release_resource(). When I run mix test on my local machine I do not get the segfault. I'll check if I can reproduce in a Docker container.

For anyone following along, I haven't forgotten about this. Just been busy and haven't been able to get back to this.


Handle backlog of "single trades" more efficiently

At the moment the majority of our solvers will settle trades one by one. Since we wait 30 seconds between batches and mining the solution tx takes some time, we can effectively handle about 0.5-1 individual trades per minute.
This has become noticable in today's testing challenge (worsened by the fact that we were stuck 5 minutes without a solution submission) when multiple people tried to trade non-overlapping tokens at the same time, some trades got very delayed.
This might be important to address, before we get real traffic which might be spiky (e.g. around tweets, etc).
A simple approach would be to make the solver trade return a list of solutions, which we could batch up into a single settlement (or multiple parallel txs). However, this bears the risk of one solution effecting e.g. the uniswap state of another solution and might therefore be invalid by the time the first is mined (maybe we can base all our queries on the pending block which could already have the first solution applied).
We should at least skip the 30s pause when there has been a solution submission in the current run loop.

We discussed this in the team on Monday. We already reduced the time between runloops as long as there are orders in the system that had been created more than 30s ago. Yet in our last test we could easily encounter user wait times of up to 10 minutes.
A next immediate step to address this issue is to change the solver trait to allow returning a Vec<Settlements> (e.g. the baseline solver would return one settlement per limit order).
For now, the driver would merge Settlements into a larger "multi trade" settlement and submit it with the current tx logic. A concern about having many independent trades in the same settlement is that failing to settle a single trade, would cause a failure to all involved trades. Since this compounds with number of trades per settlement, we might "upper bound" the merging logic to include no more than n trades per settlement.
Mid-term it probably makes sense to refactor the tx submission logic to allow tracking multiple transactions in parallel (so that any subset of them could be mined/reverted independently without blocking others). This also works nicely with the fact that the MIP solver already returns independent sequences.
The question of how to update the state of e.g. the AMM pools for the trade n+1 assuming that trade n gets mined first can be an implementation detail of each solver. We might want to refactor the SettlementHandling trait to take a &mut self so that liquidity can update itself based on information on how it is used in an earlier sequence of the settlement.
For now we consider this less urgent as material changes to the underlying reserves (in a way that effect prices significantly) require large trade sizes.


Update Terraform lexer to support data blocks

(Original issue 1402 created by None on 2017-12-12T21:55:38.916603+00:00)
Terraform supports data configurations, but the pygments lexer fails to understand it.
Sample RST Markup
.. code-block:: terraform
data "aws_iam_policy_document" "binaryalert" {
  statement {
    effect = "Allow"

    actions = [
      "cloudwatch:DeleteAlarms",
      "cloudwatch:DeleteDashboards",
      "cloudwatch:DescribeAlarms",
      "cloudwatch:PutMetricAlarm",
    ]

    resources = ["*"]
  }
}

Sphinx-Build
ERROR: Could not lex literal_block as "terraform"

Can you please have a look at #1756? Feedback is welcome. Thanks!


add zoxide

zoxide on github

I have no experience with zoxide, as I've created a custom skim alt-c command to quickly change directories based on zsh's cdr command.
That's the beauty of profiles though. Feel free to add it to core, or to your own own developer profile.

Some things that might be of interest to you @blaggacao :

fzf provides an alt-c keybinding to fuzzy find a folder and cd to it
broot is a more interactive and feature-full fzf to navigate directories (and more)

I think this can be closed for the time being, thank you for the tips!

I think this can be closed for the time being, thank you for the tips!


chore(goreleaser): don't use version in tarball name

Description
Removes version from the trallbar name, in order to allow downloads like this:
wget https://github.com/ojo-network/price-feeder/releases/latest/download/price-feeder-linux-amd64.tar.gz

This way we will be able to easily download latest version for e2e tests.

I'm not a big fan of this change tbh. @rbajollari is this necessary for e2e?

closing due to staleness

Was there any argument against this change? if no, then let's reconsider. It will help us with integrations we are planning, as described above.


"Attach Node Script" dialog box spawns slightly off-center

Operating system or device, Godot version
Linux Mint 18.3 Sylvia x64, Godot 3.0 f3ad142
Issue description:
The dialog box always seems to appear too far down and to the right:

This happens for me only the first time the dialog is open. The next time I open the dialog is in the center.

@vnen Good observation.

I called popup_centered() twice in a row instead of just once and it started to align to center. I'm trying to trace the reason why the second call centers the dialog.

See #16069, which is a later duplicate but has some more debugging details, so closing this one in favour of #16069.

This behaviour still occurs as of dd2cd06.

However, it only happens when adding a script from the Scene dock; creating a script from within the Script editor (File > New Script...) has the dialog centered correctly the first time. I narrowed it down to this line:
https://github.com/godotengine/godot/blob/dd2cd06165670bb0d78bf4aa397935be15716e76/editor/plugins/script_editor_plugin.cpp#L971
The Scene dock's dialog is popped up without any size information:
https://github.com/godotengine/godot/blob/dd2cd06165670bb0d78bf4aa397935be15716e76/editor/scene_tree_dock.cpp#L394
Adding it fixes the problem. I have no idea why, though. Is it worth making a PR for this, or is a proper fix desired?


Develop derived tables po_lines_mat_type_*

Starting table in FROM is
po_lines
separate derived tables for JSON arrays extracted:
-electronic resources
-material type
-physical resources
Other tables joined
material types
*Material type on the PO has not been developed in the Orders application yet.

2 new derived tables were just submitted for this issue:
po_lines_phys_mat_type
po_lines_er_mat_type

PR #136

What tables remain to be developed for this issue, other than the two that have been submitted?

I think we only need the 2 tables, so I that should wrap up this issue


NFT (natural feature tracking) on AR.js

⚠ All PRs have to be done versus 'dev' branch, so be aware of that, or we'll close your issue ⚠
What kind of change does this PR introduce?
this PR want to test the new jsartoolkit5 from https://github.com/kalwalt/jsartoolkit5/pull/1 with the new changes especially the NFT part.
🖼 This will eventually make AR.js capable of detect and track 2D images.
https://twitter.com/nicolocarp/status/1204841439160684549

Could be raise some bugs and incompatibilties between the code. It is more a test...
Can it be referenced to an Issue? If so what is the issue # ?
From jsartoolkit5 repo:  PR  https://github.com/kalwalt/jsartoolkit5/pull/1
From AR.js issues:

https://github.com/jeromeetienne/AR.js/issues/544
https://github.com/jeromeetienne/AR.js/issues/149
https://github.com/jeromeetienne/AR.js/issues/503
https://github.com/jeromeetienne/AR.js/issues/420
https://github.com/jeromeetienne/AR.js/issues/227
https://github.com/jeromeetienne/AR.js/issues/190
https://github.com/jeromeetienne/AR.js/issues/185

also, a repo cleaning will help for: https://github.com/jeromeetienne/AR.js/issues/433
How can we test it?
Just test the examples and tell us what happens...

Summary

Does this PR introduce a breaking change?
It could be... but it will add NFT feature.
Please TEST your PR before proposing it. Specify here what device you have used for tests, version of OS and version of Browser
Other information
I uploaded the new jsartookit5 libs and build the AR.js libs with makefile.
Progress

[x] Clean repo before starting the porting
[x] Import new jsartoolkit5 version, coming with NFT
[ ] Adapt the code (threejs side) to support NFT (emulate what's already done for fiducial markers)
[ ] Adapt the code (aframe side) to support NFT (emulate what's already done for fiducial markers)
[ ] Create at least one example for threejs + NFT
[ ] Create at least one example for aframe + NFT
[ ] Change documentation (principal Readme + Readmes inside threejs + aframe folders)
[ ] release version 3 of AR.js

The simplest examples don't works i receive an error like:
artoolkit.api.js:1235 Uncaught TypeError: artoolkit.setup is not a function
    at ARController._initialize (artoolkit.api.js:1235)
    at new ARController (artoolkit.api.js:128)
    at ARCameraParam.onload (threex-artoolkitcontext.js:197)
    at ARCameraParam.<anonymous> (artoolkit.api.js:1673)
    at writeCallback (artoolkit.api.js:1892)
    at writeByteArrayToFS (artoolkit.api.js:1919)
    at XMLHttpRequest.oReq.onload (artoolkit.api.js:1936)
ARController._initialize @ artoolkit.api.js:1235
ARController @ artoolkit.api.js:128
(anonymous) @ threex-artoolkitcontext.js:197
(anonymous) @ artoolkit.api.js:1673
writeCallback @ artoolkit.api.js:1892
writeByteArrayToFS @ artoolkit.api.js:1919
oReq.onload @ artoolkit.api.js:1936
load (async)
ajax @ artoolkit.api.js:1931
loadCamera @ artoolkit.api.js:1900
ARCameraParam.load @ artoolkit.api.js:1670
ARCameraParam @ artoolkit.api.js:1649
ARjs.Context._initArtoolkit @ threex-artoolkitcontext.js:195
ARjs.Context.init @ threex-artoolkitcontext.js:106
(anonymous) @ dev.html:114

you can try different examples ( basic, default, dev..) but same result. we have to change the code but i have not a clear idea if jsartoolkit5 or AR.js or both...

with the latest commit small example to test, i receive this error:
THREE.WebGLRenderer 103
test-new.html:86 Live reload enabled.
773test-new.html:53 Uncaught ReferenceError: arToolkitContext is not defined
    at onResize (test-new.html:53)
    at onReady (test-new.html:43)
    at onSourceReady (ar.js:6275)
    at ar.js:6420
onResize @ test-new.html:53
onReady @ test-new.html:43
onSourceReady @ ar.js:6275
(anonymous) @ ar.js:6420
setInterval (async)
success @ ar.js:6418
Promise.then (async)
(anonymous) @ ar.js:6404
Promise.then (async)
ARjs.Source._initSourceWebcam @ ar.js:6379
ARjs.Source.init @ ar.js:6251
(anonymous) @ test-new.html:42

It's enough for today! i will continue another time...

i changed the test-new example a bit and i'm testing a simple example with NFT. Basically like the video_threejs_worker.html example in the nft_improved_worker folder using directly the artoolkit functions... but i get an error with the camera initailization, see the log:
Live reload enabled.
three.js:22661 THREE.WebGLRenderer 103
three.js:47439 THREE.MeshNormalMaterial: .shading has been removed.

Ok now The NFT example works but without modifications to THREEX or other part of the code in AR.js, this is another problem to solve. First we need to integrate the new artoolkit (with NFT) into AR.js.

We have to see how AR.js integrates with artoolkit event handling. When marker are detected, for example (but also other stuff) callbacks are called or events are handled, from artoolkit to AR.js.
We have to replicate exactly what is done for fiducial markers, this time for NFT.
Technically it is not difficult, theorically speaking. But there will be a lot of problem solving :)

We have to see how AR.js integrates with artoolkit markers handling. When marker are detected, for example (but also other stuff) callbacks are called or events are handled, from artoolkit to AR.js.
We have to replicate exactly what is done for fiducial markers, this time for NFT.

Yes, i understand this. it needs to understand step by step. I will do a summary and some considerations above the jsartoolkit5 changes, i think this will help us.

Technically it is not difficult, theorically speaking. But there will be a lot of problem solving :)

Yes probably for you is easier! :smiley: but for me require a lot...

Thank you @nicolocarpignoli for the latest push and merge!

running the threejs/examples/basic.html example i get:
Uncaught ReferenceError: importScripts is not defined
    at ar.js:2000
(anonymous) @ ar.js:2000

because artoolkit.worker.js i suppose.

We removed the lean version of the lib because has not sense, there is not a lean version anymore.

importScripts issue solved thanks to this article https://stackoverflow.com/questions/14500091/uncaught-referenceerror-importscripts-is-not-defined

In my opinion we should first reach a stable point on jsartoolkit5 repository with the NFT version and all demos working. Use web assembly as default maybe, if gives better performances and its supported the same as the version only with workers.
After that we should restart work on this pr to integrate it on arjs and also think of a way to integrate the NFT generator on this repository or maybe on an arjs org

I tested the latest, yes something is showing very instable at the moment, but for sure could be improved! Bravo Nicolò!

i think the flashing of the model happens because we should add the getNFTmarker event listeners to get data from the NFT marker.

We could create in jsartoolkit5 (artoolkit.api.js) a NFT_MARKER=2 in the exported api, and add marker type into the NFT dispatch event. This should be help us to retieve the type data.

We could create in jsartoolkit5 (artoolkit.api.js) a NFT_MARKER=2 in the exported api, and add marker type into the NFT dispatch event. This should be help us to retieve the type of data.

yes I saw that was missing! next step is to add that on jsartoolkit5 side in my opinion

Now it works! :smile:

@nicolocarpignoli I will do that changes inside jsartoolkit5, if i can this night...

i did the changes to artoolkit.api.js in this commit https://github.com/kalwalt/jsartoolkit5/pull/1/commits/9066705237c4ef4e699c1dfc86abf458aa7280ef if you updates the jsartoolkit lib make a ref to this commit.

With https://github.com/jeromeetienne/AR.js/pull/674/commits/7672bf3aaf1aec1cf8a3bf3e84e98c03ec42d67e the ar.js libs can be minifyed with uglifyjs using the 'use strict' directive at the beggining of the jsartoolkit5 lib (artoolkit.min.js)


Have coredns restart automatically. Sometimes coredns starts so fast it

mistakenly detects port 53 in use from the previous running coredns.

cc @radez


[Runtime Bug]: Vampire: The Masquerade - Crash when taking capture

Describe the bug
When playing Vampire: The Masquerade with the Unofficial patch installed an latest remix versions, I'm experiencing a crash when trying to take a capture. This is consistent anywhere in the beginning of the game, about 20 minutes in.
Using Remix version,
dxvk-remix-53b0bdc-599-debugoptimized
bridge-remix-07778f9-85-debugoptimized
How do you reproduce the bug?
Launch Vampire: The Masquerade with the Unofficial Patch, try to capture, and see crash.
What is the expected behavior?
The runtime should capture all assets as expected.
Version
dxvk-remix-53b0bdc-599-debugoptimized
Logs
d3d9.log
Vampire_d3d9.log
NvRemixBridge.log
Crash dumps
NvRemixBridge.exe_20240727_190213.dmp
Media

REMIX-3405 for tracking


Stuck processing repos, unable to edit profile sections

I clicked "Update" -> "Update GitHub repos", and Sourcerer seems to be stuck on one of my repos.

The repo in question seems to be "disabled", not sure if that's related to the problem. (I've blacked out the owner's name since it's someone else's repo I was added to.)

After it was stuck for a while, I tried running the repo update again, and it completed correctly, but the previous process (Process 11) seems to still be hanging.

I still get the banner at the top of the page, and loading indicators where the section edit buttons would be.

Let me know if you need any more info.

Looks like it finally hit a timeout and I can edit my profile again.

I'll close this issue. Feel free to reach out if you want any more info. All of the failed repos are private, once Sourcerer got to the public ones after that it started processing again.


cgo: zero cost cgo calling

sorry for asking but is there a possibility for zero cost cgo calling in future?
140ns per call is too much.
rustlang has zero cost calling c / c++ now.
just wondering if that'll be the way in future.

If it was easy to have zero cost cgo calls, it would've been done by now. It wasn't one of Go design goals to have effortless and performance C integration, and it's not easy for a language with a runtime like Go's. Anyway, this is #9704 and #19574, closing here as a dup.


ast_to_dag support for opaque gates

This PR is going towards recovering our QASM input in Qiskit, now that composite gates are working. (see #1566)
For fully supporting gate mygate(theta) q {...} I need to extend DAG with a binding mechanism for parameters. That might take longer, so I prefer to push this PR with support for opaque, that is easier.

This looks good. I think for a defined custom gate, we need to create a circuit that contains its definition, then append it using circuit.append(subcircuit.to_instruction).
Not sure what you mean by "extend DAG with a binding mechanism for parameters"?

Not sure what you mean by "extend DAG with a binding mechanism for parameters"?

gate mygate(theta) q {...} creates the instruction and mygate(3,q[2]) needs to bind theta. Right?


Move Zeek docs to Integrations area

I've spotted some material changes I'd like to make to our docs about how Zed works with Zeek. These have been in living in a separate spot away from the other Zed docs, which I believe was motivated by an instinct to create some separation from tooling's prior Zeek-centric focus. However, we now have an Integrations area in the Zed docs where it feels like these could safely live such that they'd benefit from the better rendering in Docusaurus and they'd also be easier for readers to find but still be clearly separate from the core Zed mission. This PR just takes care of moving them to the new location and updating the formatting/links. Once this merges I'll put up a follow-on PR with actual material changes to the content.
If you want to see how it looks rendered, I've put a copy of on a personal staging site at https://spiffy-gnome-8f2834.netlify.app/docs/next/integrations/zeek.

zio/zeekio/ is all about Zeek TSV I/O, so it doesn't feel like the right place for shaper.zed and its test. How about embedding them in shaping-zeek-ndjson.md as a fenced code block (for the shaper) and mdtest?

@nwt: Ok, I've followed your recommendation and moved the shaper.zed into the markdown and created an mdtest to replicate what was formerly in the ztest. As we discussed offline, that iteration of the shaper.zed is particularly huge but I have plans to shorten it significantly in the changes I have coming up along with a wider overhaul of that doc about shaping Zeek, so try not to get too caught up in its present contents.


Feature request: hide PINGs

For servers which preemptively ping clients, the log rapidly gets filled with PING & PONG requests and replies.
It might be helpful to have a flag to hide them. Probably should be visible by default, though. Perhaps some sort of configurable hiding with lists, like --hide PING,PONG.

Yeah I could definitely see something like this, thanks for the request

Implemented by abf16cb7fc6762f76dd2dcf64d0d65f93b8aef23, will be in the next release. Thanks again for the suggestion!

Which is the v0.2.0 release right here! Feel free to let me know if it doesn't act as expected :)


Not able to self host, Not working as intended.

// Listen on a specific host via the HOST environment variable
var host = process.env.HOST || '<IP_ADDRESS>';
// Listen on a specific port via the PORT environment variable
var port = process.env.PORT || 8080;

var cors_proxy = require('cors-anywhere');
cors_proxy.createServer({
    originWhitelist: [], // Allow all origins
    requireHeader: ['origin', 'x-requested-with'],
    removeHeaders: ['cookie', 'cookie2']
}).listen(port, host, function() {
    console.log('Running CORS Anywhere on ' + host + ':' + port);
});

base code from example and export PORT=8080 and export CORSANYWHERE_WHITELIST=https://my.domain.com/
Endpoints return
This API enables cross-origin requests to anywhere.

Usage:

/               Shows help
/iscorsneeded   This is the only resource on this host which is served without CORS headers.
/<url>          Create a request to <url>, and includes CORS headers in the response.

If the protocol is omitted, it defaults to http (https if port 443 is specified).

Cookies are disabled and stripped from requests.

Redirects are automatically followed. For debugging purposes, each followed redirect results
in the addition of a X-CORS-Redirect-n header, where n starts at 1. These headers are not
accessible by the XMLHttpRequest API.
After 5 redirects, redirects are not followed any more. The redirect response is sent back
to the browser, which can choose to follow the redirect (handled automatically by the browser).

The requested URL is available in the X-Request-URL response header.
The final URL, after following all redirects, is available in the X-Final-URL response header.

To prevent the use of the proxy for casual browsing, the API requires either the Origin
or the X-Requested-With header to be set. To avoid unnecessary preflight (OPTIONS) requests,
it's recommended to not manually set these headers in your code.

Demo          :   https://robwu.nl/cors-anywhere.html
Source code   :   https://github.com/Rob--W/cors-anywhere/
Documentation :   https://github.com/Rob--W/cors-anywhere/#documentation

You've shown the server part only. Where is the client-side code?
And note that the environment variable only works if you use the default server.js from CORS Anywhere. The code snippet at the top uses cors-anywhere as a library, with an empty originWhitelist. If you want to restrict requests to a specific origin, use originWhitelist: ["https://my.domain.com"],instead (note:/is not at the end because an origin isport+://` + host (hostname + optional port separator & port).

	async function fetchInfo() {
		const res = await fetch(`${CORS}${URL}`).then(async data => {
			let d = await data.json();
			...
		})
		setTimeout(fetchInfo, 15000)
	}
 fetchInfo()

Something like this on the client side

If I use the http://IP:8080  of the instance it seems to work, I have configured vhosts for the port 8080 and works on https://my.domain.com and it is behind a cloudflare.
Also If I use the server.js after cloning it again works with http://IP:8080 and not https://my.domain.com

So CORS Anywhere and your application are at the same origin?
If so, you need to set the X-Requested-With request header, so that CORS Anywhere allows the request to go through.
CORS Anywhere requires either the Origin header or X-Requested-With to prevent direct requests (when visiting in the browser), because that's would be a huge security issue for your website. See my comments at https://github.com/Rob--W/cors-anywhere/issues/39 for more info.

No, they do not have same origin. Application is at (https://application.domain.com) and wants to use the cors server https://cors.domain.com/
The request structure from the client side will be https://cors.domain.com/https://api-resource.com/endpoint and client is expecting a JSON response. BTW https://cors-anywhere.herokuapp.com/ seems to work fine.

Could it be that your server (in front of Node.js) normalizes URLs, such that /http://example.com/ becomes /http:/example.com/? That is a common mistake, see e.g. https://github.com/Rob--W/cors-anywhere/issues/143 (nginx) and https://github.com/Rob--W/cors-anywhere/issues/201 (Apache).

No, doesn't look like it the client points to the right URL.
this is the config
<VirtualHost *:80>
     ServerName my.domain.com
     ServerAlias my.domain.com
     ServerAdmin webmaster@localhost
     ProxyPreserveHost Off

    ProxyPass / http://<IP_ADDRESS>:8080/
    ProxyPassReverse / http://<IP_ADDRESS>:8080/
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

I don't understand what you're trying to say in your last comment.
In any case, have you tried putting a different Node.js application behind it, to see if the request.url is as expected?
require("http").createServer((req, res) => {
 res.end(req.url);
}).listen(8080);

and then send the request and check whether the returned URL matches the input URL.