RaceDay Scoring showing old result after edit

This was during testing for #44
I'm testing RDS time machine interface using a file. I simulated the case where the entry at the time machine was incorrect for one runner. For this simulation the bib number 1691 should have been 1694. The file was edited with 1694, and in RDS the raw read for 1691 was deleted, then the time machine stream was replayed. The incorrect 1691 result persists in the overall report and at RunSignUp's results for this race. Is there another operation I missed to delete the 1691 result?

Clearing raw read did take care of removing the errant result in RDS as when I cleared the raw reads the leaderboard did indeed get cleared and 1691 is not in RDS overall results report now. Unfortunately I still see 1691 in the runsignup results. I've refreshed https://runsignup.com/Race/Results/116536#resultSetId-431179;perpage:100 for several minutes and his result persists. I know I can manually delete the result on RSU, but I'm not sure why it doesn't get cleaned up when syncing with RDS.

Also I want to know if there's a less heavy-handed way to clear the results associated with a particular raw read.
I'm considering the case where we will be using Time Machine as backup for a chip system. The scenario I'm worried about is a mistyped bib number on the Time Machine causing a result for a runner who hasn't finished yet. When we discover this we want to be able to fix the results. In this case, we would prefer not to edit the time machine file. Would ignoring the errant raw read in RDS take care of it, and sync the results properly with RSU?

per Kevin at RSU:
_It looks like when you delete a raw read, you will need to select the recalc button in order for results to be updated in RDS. I did just do a quick test and it does look like when read is deleted and you recalc (so results are updated in RDS) the autosave for some reason is not getting updated as well. I'll need to create an issue for our development team to look into this. I do also think the recalc should be happening automatically as well so I'll create an issue for them on that as well. _ [emphasis added]
This does not help get RSU results squared away as mentioned. Subsquently went to Scored Events and did Save, which corrected the RSU results.

Workaround for fully updating a confirmed entry:

for any bib number which was removed, delete associated raw reads at Raw Reads view
under RAW READS on dashboard, click RECALC, then RECALCULATE
under Scored Events view, click Save

RSU claims this is fixed in RDS 4.0.23: https://info.runsignup.com/2024/01/04/new-read-filtering-options-announcer-features-and-more-in-raceday-scoring-v4-0-23/

It doesn't look like RDS 4.0.23 fully solved this issue.
I did the following test:

added bib 1700 to the file
updated file by editing 1700 to 1701
deleted raw read 1700
replay stream

The report in RaceDay Scoring is correct

however the results on RunSign show the errant 1700

I still need to go to the Scored Events view and click Save in order for the results to be saved to RSU correctly. Below is after that operation.

From Matt Avery (2/15/24):
We have corrected the issue where participants would remain in progress after clearing their reads in the latest update. [v4.0.33]

I don't see that this is fixed.
I had some issues on setup. These times are approximate. This isn't my complaint, but is the background
2024-03-11 17:01 edit 1701 to be 1700 in csv file
2024-03-11 17:12 RDS start read connector
2024-03-11 17:13 delete 1701 raw read
2024-03-11 17:13 RDS start autosaves
2024-03-11 17:13 noticed no results on RSU
2024-03-11 17:17 delete all raw results, replay stream
2024-03-11 17:17 still no results on RSU
2024-03-11 17:19 edit overall report, save
2024-03-11 17:19 results now on RSU

I was more careful on the times below.
2024-03-11 17:24 edit 1700 to be 1701 in csv file
2024-03-11 17:25 delete 1700 raw read
2024-03-11 17:26 1700 still on RSU results
2024-03-11 17:26 RDS replay stream
2024-03-11 17:27 1700 still on RSU results. screenshot https://i.imgur.com/s49mQbm.png
2024-03-11 17:30 RDS scored events > save
2024-03-11 17:30 1701 is now on RSU results. screenshot https://i.imgur.com/D5Bm1XR.png
2024-03-11 17:32 RDS get help log sent

This was resolved with RDS v4.0.34
I reproduced the problem with v4.0.33, and verified the fix with v4.0.34. Thanks!
2024-03-14 05:14 RDS v4.0.33
2024-03-14 05:14 edit 1700 to 1701 in csv file
2024-03-14 05:15 RDS replay stream
2024-03-14 05:15 RDS delete raw read 1700
2024-03-14 05:16 (wait > 30 sec)
2024-03-14 05:17 RSU 1700 remains in result set, but 1701 is seen [see previous screenshots]
2024-03-14 05:17 RDS scored events save
2024-03-14 05:18 RSU 1700 not seen in result set

2024-03-14 05:18 install RDS [v4.0.34]
2024-03-14 05:20 RDS start read connector
2024-03-14 05:20 RDS start autosaves
2024-03-14 05:21 edit 1701 to 1700 in csv file
2024-03-14 05:21 RDS replay stream
2024-03-14 05:22 RDS delete raw read 1701
2024-03-14 05:22 (wait > 30 sec)
2024-03-14 05:23 RSU shows 1700 and not 1701 (i.e., fixed). https://i.imgur.com/Yuqt657.png


doc: feedback and clarifications

Highlights:

[infra] Added a BUILD file to check that the types and methods in the README file match the ICRC-2.did file.
[spec] Removed the "Signer" terminology as I couldn't find its past usage (e.g., it does not appear in the IC spec or the ICP Ledger spec).
[spec] Extended the "Motivation" section to list new types of applications that the standard makes possible.
[spec] Added a missing from_subaccount field in ApproveArgs.
[spec] Refined the Error types returned from the approve and transfer_from methods. The ApproveError variant doesn't have the BadBurn case, and TransferFromError has an extra InsufficientAllowance case.
[spec] Added explicit preconditions and postconditions for each method.
[spec] Clarified that the approver pays all the fees.
[spec] Clarified that approve overrides the previous allowance.
[spec] Renamed AllowanceArgs.owner to AllowanceArgs.account to be more consistent ("owner" is usually a principal).

Looks great! Thanks for the feedback. One thing That comes to mind is how memo/created_at_time will actually work, but we can pick up the conversation further in the main PR


Add Star Trek: TOS colored Space Suits Pack for TextureReplacer from KerbalStuff

Added Dependency and Installation details to KerbalStuffBot's #1287

I don't say this often but I think this identifier could use some shortening down.
Lines 5 and 21 are not needed, the comma on line 20 should be removed when line 21 is removed. spec_verison 1.4 is probably not needed, 1.2 should be good enough from what I see.

Is there a page somewhere that lists the capabilities of the different spec versions?

https://github.com/KSP-CKAN/CKAN/blob/master/Spec.md

Are you sure about that license line? I can't see why it's failing now.

You're right, re-add license line. I forgot how to NetKAN for a second I think :-1:

The spec claims that the KerbalStuff $kref should scrape the license.


Kured notify url is deprecated

time="2022-01-06T01:04:53Z" level=warning msg="Deprecated flag(s). Please use --notify-url flag instead."                                                                 time="2022-01-06T01:04:53Z" level=warning msg="slack-hook-url is not properly formatted...no notification will be sent: <nil>\n"

https://containrrr.dev/shoutrrr/v0.5/services/discord/

Use notify-url instead. Fixed.


Implementing tabs component

Thanks a lot for working on this, I just added a few inline comments, but this is almost ready to be merged already :D

Just started reviewing :) :octocat: Sent from GH.

The code is almost perfect now, just a few more things that I've commented inline :D
Besides the code changes there's just one more thing that's needed before we merge this. We always try to have 100% test coverage on metal modules. Of course that doesn't really mean that all cases are covered, but it helps to know that all code lines are runnable and usually covers the main use cases, so we like doing that. This sometimes even reveals unnecessary code that can be removed.
You can easily check your code's coverage percentage by running gulp test:coverage on your machine. Also, if you want you can check exactly which lines are missing tests, by running gulp test:coverage:open, which will open a report in your browser. Let me know if you have any trouble with that :)

Just started reviewing :) :octocat: Sent from GH.

Just started reviewing :) :octocat: Sent from GH.


Add CRC generator

This PR adds a CRC generator to the stdlib. It supports the full set of Williams/Rocksoft model parameters, which in practice means it should be able to generate and validate pretty much every commonly used CRC directly, and significantly that includes all the ones in the reveng catalogue and crcmod predefined list.
It's configurable for arbitrary input word widths with a constant single-cycle latency, so can be used to generate a classic bit-at-a-time shift-register CRC, or update wider words in parallel. It doesn't support masking the input words, which might limit its use in very wide masked data paths, though I expect that could be added later in a backwards-compatible way if necessary. I haven't thought about how masking might be implemented.
The generated logic is a product/XOR equation for each bit of the new state which includes bits of the previous state and current input. As far as I'm aware this is essentially the best way to generate an arbitrary parallel CRC in hardware.
Currently it uses a reset and valid input signal, rather than e.g. relying on users to add EnableInserter and ResetInserter as appropriate. I don't know what the preferred way to deal with that is in stdlib items. Since reset will pretty much always be required it seems easier to have it as an input than requiring ResetInserter; I guess some applications may never need to change valid if they always have valid new data after resetting.
The test suite uses a variety of standard CRCs to provide coverage of the various input parameters, and tests each at input word widths of 1, 2, 4, 8, 16, 32, and 64 bits.
I originally wrote this code for my work, where we've used it in a variety of applications, but I have permission to release it under the BSD two-clause licence for inclusion in Amaranth.

Currently it uses a reset and valid input signal, rather than e.g. relying on users to add EnableInserter and ResetInserter as appropriate.

This could be affected/related to https://github.com/amaranth-lang/rfcs/pull/12

#12 is a major rework that will not be relevant in short term (if ever).

I've updated to rename the reset signal to rst.

This PR has been updated to address the latest review comments in https://github.com/amaranth-lang/rfcs/pull/6#issuecomment-1567391041. I've squashed the commits to a single one suitable for merging as I don't think there's any benefit to preserving the commit history.

Do you think you could reach 100% code coverage in this PR? This is something I strive for in the core language and the standard library, although it is not currently the case everywhere.

We also need a changelog line for the RFC and this PR -- could you add them?

Perfect, thanks!

Rebased and added tests for 100% coverage of the new files.

Thanks for checking! I thought I had added a changelog entry here, should I do something else too?
I'll rebase now to fix the merge conflict.

Thanks for checking! I thought I had added a changelog entry here, should I do something else too?

Oh sorry, I completely missed that somehow!

Could you squash the commits, please?

Sorry, I missed your comment last week. I've pushed a single squashed commit that's rebased on current main.


Update gradle-wrapper.properties

@vivekkiran
Before making a PR you should create an issue.
Wait for the mentors approval (If its an enhancement)
Then make a PR.

@free4murad I just created an issue #1289


change SPDX identifier as the "license" field in "package.json"

Module has a wrong SPDX identifier as the "license" field in "package.json".
According to spdx list "BSD" is not a valid spdx identifier.

https://github.com/ericf/css-mediaquery/pull/23 has been merged, but not yet released to https://www.npmjs.com/package/css-mediaquery


Simplify api of using the package

What
Embed the .wasm file into the .js file, and load it automatically.
Why
Make the rust wasm compiled to js package a better experience to use, so that it looks like any other js package.
Eliminates the need to navigate loading the .wasm file.
Makes the API of the package like the API of any other package, where it just has the functions to call.
The idea has been floated on wasm-pack as a type of new target, "inline," but it hasn't eventuated into an implementation yet:

https://github.com/rustwasm/wasm-pack/issues/1334
https://github.com/rustwasm/wasm-pack/issues/699
https://github.com/rustwasm/wasm-pack/issues/831
https://github.com/rustwasm/wasm-pack/issues/1074

But we can do the same thing with a little file manipulation.
Why Not
Could break in the future when we update wasm-pack versions.
There could be situations where an application wants to defer loading the wasm until it'll be used. This solution definitely impacts on any ability to do that.

Going to abandon this because of the size change to the dependency as a whole.


Method name

Hi there, great work!
I had been working on a similar idea, but it seems you've already implemented and tested it more comprehensively. So, I thought I'd bring your attention to an alternative name that is a real word for a tasty fruit and actually fits quite naturally:
LoQuaT: Low... Quantized Training.
Of course, feel free to use it or not. Cheers!

Hi Jonathan,
Thanks for checking out our work! We appreciate your suggestion and we’ll definitely keep it in mind. Cheers!


Summary statistics dataset

This PR should include toolset to work with summary statistics dataset:

[x] Summary statistics schema in json format.
[x] Summary statistics dataset class.
[x] Reading from parquet
[x] Create from harmonized summary statistics from the GWAS Catalog
[x] Apply p-value filter.
[ ] Distance based top loci identification.
[x] Test for creating summary statistics
[x] Test for p-value filtering.

As a side effect there are a bit of re-shuffling of functions that were moved from a dataset to the shared module.

Codecov Report

Merging #68 (2faefb4) into do_hydra (2db11ab) will decrease coverage by 0.06%.
The diff coverage is 75.00%.

@@             Coverage Diff              @@
##           do_hydra      #68      +/-   ##
============================================
- Coverage     75.07%   75.02%   -0.06%
============================================
  Files            38       39       +1
  Lines          1007     1049      +42
============================================
+ Hits            756      787      +31
- Misses          251      262      +11

Impacted Files
Coverage Δ

src/otg/dataset/study_locus.py
79.58% <0.00%> (-0.83%)
:arrow_down:

src/otg/dataset/summary_statistics.py
66.66% <66.66%> (ø)

src/otg/common/spark_helpers.py
100.00% <100.00%> (ø)

src/otg/common/utils.py
100.00% <100.00%> (ø)

How the ingest step works:
poetry run otg step=gwas_catalog_sumstats_preprocess \
    step.raw_sumstats_path=$(pwd)/tests/data_samples/gwas_summary_stats_sample.tsv.gz \
    step.out_sumstats_path=$(pwd)/test_sumstats \
    step.study_id=test_study_id

This command works (after work around the validation part) and generates this:
+-------------+------------+----------+--------+--------------+--------------+------------+-------------+-------------------------------+
|      studyId|   variantId|chromosome|position|pValueMantissa|pValueExponent|        beta|standardError|effectAlleleFrequencyFromSource|
+-------------+------------+----------+--------+--------------+--------------+------------+-------------+-------------------------------+
|test_study_id|10_14554_A_G|        10|   14554|         9.803|            -1|-0.001107265| 4.481483e-02|                         0.0028|
|test_study_id|10_14575_T_C|        10|   14575|         6.629|            -1|  0.03958083| 9.078693e-02|                         0.9993|
|test_study_id|10_14583_T_G|        10|   14583|          4.65|            -1|  0.08531199| 1.167557e-01|                         8.0E-4|
|test_study_id|10_14744_A_C|        10|   14744|         8.094|            -1|  0.00284793| 1.180797e-02|                          0.028|
|test_study_id|10_14829_T_C|        10|   14829|         1.065|            -1|  -0.2438626| 1.510821e-01|                         2.0E-4|
+-------------+------------+----------+--------+--------------+--------------+------------+-------------+-------------------------------+


vscode-extensions.rust-lang.rust: init at 0.7.8

Motivation for this change
Add a VSCode extension, Rust (rust-lang.rust).
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[x] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

I was about to say, isn't there some native tooling need to make this work?

What's the status of this PR, is it still relevant?

Closing this issue since I get no feedback from the author and the extension is now deprecated.
https://marketplace.visualstudio.com/items?itemName=rust-lang.rust


Tests fail with error "java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libjscexecutor.so"

What happened?
After upgrading react-native to version 0.68.2 from 0.63.4, the tests fail. The built application works.
The error that is thrown by the tests is:
DetoxRuntimeError: Failed to run application on the device

    HINT: Most likely, your tests have timed out and called detox.cleanup() while it was waiting for "ready" message (over WebSocket) from the instrumentation process.

      3 | describe('Example', () => {
      4 |   beforeAll(async () => {
    > 5 |     await device.launchApp()
        |                  ^
      6 |   })
      7 |

      at onboarding.e2e.ts:5:18
      at onboarding.e2e.ts:8:71
      at Object.<anonymous>.__awaiter (onboarding.e2e.ts:4:12)
      at Object.<anonymous> (onboarding.e2e.ts:4:24)

By reading the more detailed logs, we find that the following command causes an error:
13:13:09.324 detox[105379] DEBUG: [SPAWN_CMD, #27, cpid=105524] /home/user/Library/Android/sdk/platform-tools/adb -s emulator-14004 shell am instrument -w -r -e detoxServer ws://localhost:39081 -e detoxSessionId d6ae8bef-12df-0b4e-4336-c96d21b681d9 -e debug false com.revelator.originalworks.test/androidx.test.runner.AndroidJUnitRunner
13:13:10.443 detox[105379] DEBUG: [SPAWN_END, #27, cpid=105524] /home/user/Library/Android/sdk/platform-tools/adb -s emulator-14004 shell am instrument -w -r -e detoxServer ws://localhost:39081 -e detoxSessionId d6ae8bef-12df-0b4e-4336-c96d21b681d9 -e debug false com.revelator.originalworks.test/androidx.test.runner.AndroidJUnitRunner exited with code #0

adb shell output:
 detoxSessionId d6ae8bef-12df-0b4e-4336-c96d21b681d9 -e debug false com.revelator.originalworks.test/androidx.test.runner.AndroidJUnitRunner                                                                     <
INSTRUMENTATION_RESULT: shortMsg=Process crashed.
INSTRUMENTATION_CODE: 0

These are logs from adb logcat. This is the error part.
logs:
07-14 15:31:24.634 19982 19982 E SoLoader: couldn't find DSO to load: libhermes.so
07-14 15:31:24.634 19982 19982 E SoLoader: 	SoSource 0: com.facebook.soloader.DirectorySoSource[root = /data/app/~~uSoN9VPkk1WOrWDuOLHKBA==/com.revelator.originalworks-JByrEhVwC7zOOGW0bGmoXg==/lib/x86_64 flags = 0]
07-14 15:31:24.634 19982 19982 E SoLoader: 	SoSource 1: com.facebook.soloader.DirectApkSoSource[root = /data/app/~~_40r519kmaU-M2cpDflLfQ==/com.revelator.originalworks.test-iZJ33nB4_UiufyC2njdQTg==/base.apk!/lib/x86_64]
07-14 15:31:24.634 19982 19982 E SoLoader: 	SoSource 2: com.facebook.soloader.DirectorySoSource[root = /system/lib64 flags = 2]
07-14 15:31:24.634 19982 19982 E SoLoader: 	SoSource 3: com.facebook.soloader.DirectorySoSource[root = /vendor/lib64 flags = 2]
07-14 15:31:24.634 19982 19982 E SoLoader: 	Native lib dir: /data/app/~~uSoN9VPkk1WOrWDuOLHKBA==/com.revelator.originalworks-JByrEhVwC7zOOGW0bGmoXg==/lib/x86_64
07-14 15:31:24.634 19982 19982 E SoLoader:  result: 0
07-14 15:31:24.635 19982 19982 W System.err: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so
07-14 15:31:24.635 19982 19982 W System.err: 	SoSource 0: com.facebook.soloader.DirectorySoSource[root = /data/app/~~uSoN9VPkk1WOrWDuOLHKBA==/com.revelator.originalworks-JByrEhVwC7zOOGW0bGmoXg==/lib/x86_64 flags = 0]
07-14 15:31:24.635 19982 19982 W System.err: 	SoSource 1: com.facebook.soloader.DirectApkSoSource[root = /data/app/~~_40r519kmaU-M2cpDflLfQ==/com.revelator.originalworks.test-iZJ33nB4_UiufyC2njdQTg==/base.apk!/lib/x86_64]
07-14 15:31:24.635 19982 19982 W System.err: 	SoSource 2: com.facebook.soloader.DirectorySoSource[root = /system/lib64 flags = 2]
07-14 15:31:24.635 19982 19982 W System.err: 	SoSource 3: com.facebook.soloader.DirectorySoSource[root = /vendor/lib64 flags = 2]
07-14 15:31:24.635 19982 19982 W System.err: 	Native lib dir: /data/app/~~uSoN9VPkk1WOrWDuOLHKBA==/com.revelator.originalworks-JByrEhVwC7zOOGW0bGmoXg==/lib/x86_64
07-14 15:31:24.635 19982 19982 W System.err:  result: 0
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:1098)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:914)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:826)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:773)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:743)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.hermes.reactexecutor.HermesExecutor.loadLibrary(HermesExecutor.java:25)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.hermes.reactexecutor.HermesExecutor.<clinit>(HermesExecutor.java:19)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.hermes.reactexecutor.HermesExecutor.loadLibrary(HermesExecutor.java:23)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:369)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:318)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:95)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:42)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.revelator.originalworks.MainApplication.onCreate(MainApplication.java:55)
07-14 15:31:24.635 19982 19982 W System.err: 	at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1192)
07-14 15:31:24.635 19982 19982 W System.err: 	at androidx.test.runner.MonitoringInstrumentation.callApplicationOnCreate(MonitoringInstrumentation.java:442)
07-14 15:31:24.635 19982 19982 W System.err: 	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6712)
07-14 15:31:24.635 19982 19982 W System.err: 	at android.app.ActivityThread.access$1300(ActivityThread.java:237)
07-14 15:31:24.635 19982 19982 W System.err: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1913)
07-14 15:31:24.635 19982 19982 W System.err: 	at android.os.Handler.dispatchMessage(Handler.java:106)
07-14 15:31:24.635 19982 19982 W System.err: 	at android.os.Looper.loop(Looper.java:223)
07-14 15:31:24.635 19982 19982 W System.err: 	at android.app.ActivityThread.main(ActivityThread.java:7656)
07-14 15:31:24.635 19982 19982 W System.err: 	at java.lang.reflect.Method.invoke(Native Method)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
07-14 15:31:24.635 19982 19982 W System.err: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
07-14 15:31:24.635 19982 19982 D AndroidRuntime: Shutting down VM
07-14 15:31:24.636 19982 19982 E AndroidRuntime: FATAL EXCEPTION: main
07-14 15:31:24.636 19982 19982 E AndroidRuntime: Process: com.revelator.originalworks, PID: 19982
07-14 15:31:24.636 19982 19982 E AndroidRuntime: java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libjscexecutor.so
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	SoSource 0: com.facebook.soloader.DirectorySoSource[root = /data/app/~~uSoN9VPkk1WOrWDuOLHKBA==/com.revelator.originalworks-JByrEhVwC7zOOGW0bGmoXg==/lib/x86_64 flags = 0]
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	SoSource 1: com.facebook.soloader.DirectApkSoSource[root = /data/app/~~_40r519kmaU-M2cpDflLfQ==/com.revelator.originalworks.test-iZJ33nB4_UiufyC2njdQTg==/base.apk!/lib/x86_64]
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	SoSource 2: com.facebook.soloader.DirectorySoSource[root = /system/lib64 flags = 2]
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	SoSource 3: com.facebook.soloader.DirectorySoSource[root = /vendor/lib64 flags = 2]
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	Native lib dir: /data/app/~~uSoN9VPkk1WOrWDuOLHKBA==/com.revelator.originalworks-JByrEhVwC7zOOGW0bGmoXg==/lib/x86_64
07-14 15:31:24.636 19982 19982 E AndroidRuntime:  result: 0
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:1098)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:914)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:826)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:773)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:743)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.react.jscexecutor.JSCExecutor.loadLibrary(JSCExecutor.java:24)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.react.jscexecutor.JSCExecutor.<clinit>(JSCExecutor.java:20)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.react.jscexecutor.JSCExecutor.loadLibrary(Unknown Source:0)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:351)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:318)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:95)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:42)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.revelator.originalworks.MainApplication.onCreate(MainApplication.java:55)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1192)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at androidx.test.runner.MonitoringInstrumentation.callApplicationOnCreate(MonitoringInstrumentation.java:442)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6712)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at android.app.ActivityThread.access$1300(ActivityThread.java:237)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1913)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at android.os.Handler.dispatchMessage(Handler.java:106)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at android.os.Looper.loop(Looper.java:223)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at android.app.ActivityThread.main(ActivityThread.java:7656)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at java.lang.reflect.Method.invoke(Native Method)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
07-14 15:31:24.636 19982 19982 E AndroidRuntime: 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
07-14 15:31:24.636 19982 19982 E AndroidJUnitRunner: An unhandled exception was thrown by the app.
07-14 15:31:24.638 19982 19982 E InstrumentationResultPrinter: Failed to mark test No Tests as finished after process crash
07-14 15:31:24.638 19982 19982 I AndroidJUnitRunner: Bringing down the entire Instrumentation process.

Setup
./android/build.gradle:
https://pastebin.com/raw/kFP9SvkV
./android/app/build.gradle:
https://pastebin.com/raw/AdYvm1tC
DetoxTest.java:
https://pastebin.com/raw/V8vZMt6E
What was the expected behaviour?
No response
Was it tested on latest Detox?

[X] I have tested this issue on the latest Detox release and it still reproduces.

Did your test throw out a timeout?

[X] I have followed the instructions under Identifying which synchronization mechanism causes us to wait too much.

Help us reproduce this issue!
No response
In what environment did this happen?
Detox version: 19.6.9
React Native version: 0.68.2
Node version: 12.21
Device model: Nexus_5X_API_R
Android version: 11
Test-runner (select one): jest+jasmine
Detox logs
https://pastebin.com/raw/2Z6s7bYj
Device logs
https://pastebin.com/raw/PHwrUEMY
More data, please!
No response

I am facing a similar issue. I upgraded my app to 0.68.2 RN and got the same error.

oh, I'm so glad we're not the only ones!

Also glad to have company!
We have the same java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libjscexecutor.so error on multiple machines.
I have found that the issue with libjscexecutor.so only causes an error and a crash when Detox is trying to open the app on the AVD (i.e. (device.launchApp()):

When I open the compiled version of the app that Detox was choking on myself, in the same AVD, it runs fine.
When I run the usual yarn react-native run-android (i.e. a standard Debug build, not with Detox), I also see the same libjscexecutor.so message in adb logcat, but it does not show as an error and does not cause the app to crash.
Our tests run fine on our CI. This might be because we run those on a Release build, not a Debug build.

I unfortunately don't have any suggestions for a fix, but happy to try anything that the Detox team might recommend and report back. It would definitely be nice to get our tests running locally again!
To replicate
The Detox crash:

Run detox build --configuration android.emu.debug && detox test --configuration android.emu.debug
Detox successfully builds the app.
Detox loads the app onto the AVD, but then immediately reports that the test has failed. I never see the app attempting to open in the GUI - there was no "flash" as the app is launched. It seems to crash before the splash screen even appears.
adb logcat output shows the java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libjscexecutor.so error that @michalgrzegor reported. See my adb logcat - detox.txt

And then:

Either run detox test --configuration android.emu.debug again, and cancel the script after it loads the .apk onto the AVD, or manually drop the .apk into the AVD.
Tap to open the app.
The app launches. When I adb logcat for this manual launch, I can see that the same libjscexecutor.so not found message is shown, but it doesn't seem to cause a crash. See adb logcat - manual.txt and:

07-16 17:16:55.753  7442  7442 D SoLoader: libjscexecutor.so not found on /data/app/~~R_UhU_1E1n0LFIT1zQeYTQ==/com.helloworld.redactedappname.debug-5imjrLF19cwQO_5Hhif2dA==/lib/x86_64
07-16 17:16:55.753  7442  7442 D SoLoader: libjscexecutor.so not found on /data/app/~~R_UhU_1E1n0LFIT1zQeYTQ==/com.helloworld.redactedappname.debug-5imjrLF19cwQO_5Hhif2dA==/base.apk!/lib/x86_64
07-16 17:16:55.753  7442  7442 D SoLoader: libjscexecutor.so not found on /system/lib64
07-16 17:16:55.753  7442  7442 D SoLoader: libjscexecutor.so not found on /vendor/lib64
07-16 17:16:55.755  7442  7442 E SoLoader: couldn't find DSO to load: libjscexecutor.so
07-16 17:16:55.755  7442  7442 E SoLoader: 	SoSource 0: com.facebook.soloader.DirectorySoSource[root = /data/app/~~R_UhU_1E1n0LFIT1zQeYTQ==/com.helloworld.redactedappname.debug-5imjrLF19cwQO_5Hhif2dA==/lib/x86_64 flags = 0]
07-16 17:16:55.755  7442  7442 E SoLoader: 	SoSource 1: com.facebook.soloader.DirectApkSoSource[root = /data/app/~~R_UhU_1E1n0LFIT1zQeYTQ==/com.helloworld.redactedappname.debug-5imjrLF19cwQO_5Hhif2dA==/base.apk!/lib/x86_64]
07-16 17:16:55.755  7442  7442 E SoLoader: 	SoSource 2: com.facebook.soloader.DirectorySoSource[root = /system/lib64 flags = 2]
07-16 17:16:55.755  7442  7442 E SoLoader: 	SoSource 3: com.facebook.soloader.DirectorySoSource[root = /vendor/lib64 flags = 2]
07-16 17:16:55.755  7442  7442 E SoLoader: 	Native lib dir: /data/app/~~R_UhU_1E1n0LFIT1zQeYTQ==/com.helloworld.redactedappname.debug-5imjrLF19cwQO_5Hhif2dA==/lib/x86_64
07-16 17:16:55.755  7442  7442 E SoLoader:  result: 0

Environment
I've tried this in a bunch of different environments and versions of RN. While it's possible that I might have gotten a stale cache at some point, with all of these permutations, I definitely see the libjscexecutor.so crash issue on both RN 0.67.4 and 0.69.1.

Detox / RN version:

RN 0.69.1 + Detox 19.4.0, 19.7.0, 19.7.1
RN 0.67.4 + Detox 19.7.0, 19.7.1

Node version: 16.15.1
Android Device / Version: Pixel 3 and Pixel 5 AVDs, with both:

system-images;android-30;default;x86_64
system-images;android-29;default;x86

Test-runner: jest

Downgrading soloader to 0.10.1 fixed this for me. However I have an entirely separate set of problems which is that Detox android is far too slow to accomplish a test #3486

Downgrading soloader to 0.10.1 fixed this for me. However I have an entirely separate set of problems which is that Detox android is far too slow to accomplish a test #3486

This didn't do a trick for me, I still have the same error. What I've done:

Add

 apply from: "../../node_modules/react-native/react.gradle"
@@ -207,6 +208,8 @@ android {
 dependencies {
     implementation fileTree(dir: "libs", include: ["*.jar"])
     //noinspection GradleDynamicVersion
+
+    implementation 'com.facebook.soloader:soloader:0.10.1'

Run ./gradlew clean
Rebuild and run tests

I still have exact same error.
@shamilovtim have you done anything additional to what I listed above?

How strange. One of the first things I had tried last week was forcing Soloader to 0.10.3, but it didn't seem to fix the issue.
However, forcing it to 0.10.4 solves the problem for me (see releases):
In my android/app/build.gradle:
dependencies {
    ...
    implementation 'com.facebook.soloader:soloader:0.10.4+'
    ....
}

There seem to be several complaints in the Soloader project, regarding this error appearing in 64-bit environments. I'm guessing all of us are using "system-images;android-30;default;x86_64" or similar for our AVDs?

@hanno-jonlay I thought that too for a minute. But already tried in several images.

android-30;default;x86_64
android-30;google_apis;x86_64
android-30;google_apis;x86

All of them log the same error:
 java.lang.UnsatisfiedLinkError: dlopen failed: library "/data/app/~~wWw63Xw3XuHckpe9HIzkGw==/com.myapp.test-eHV-I7_1b6vVx-wOOBZiRA==/base.apk!/lib/x86/libhermes.so" not found
I'm curious about the com.myapp.test ".test" information. That gives me an impression that the problem is coming from the test build used by detox.

How strange. One of the first things I had tried last week was forcing Soloader to 0.10.3, but it didn't seem to fix the issue.
However, forcing it to 0.10.4 solves the problem for me (see releases):
In my android/app/build.gradle:
dependencies {
    ...
    implementation 'com.facebook.soloader:soloader:0.10.4+'
    ....
}

There seem to be several complaints in the Soloader project, regarding this error appearing in 64-bit environments. I'm guessing all of us are using "system-images;android-30;default;x86_64" or similar for our AVDs?

Tried the soloader 0.10.4, and that changed the logcat a little. Now I can see a new error:

But I honestly don't know if this error is relevant or just a consequence of changing the soloader version.

I'm guessing all of us are using "system-images;android-30;default;x86_64" or similar for our AVDs?

That's exactly what we're using.

That gives me an impression that the problem is coming from the test build used by detox.

I also think it's caused by detox somehow. As Michał mentioned in description, the apk built with assembleRelease works fine. It's only the apk built with assembleAndroidTest -DtestBuildType=debug that fails.

I'm in the same boat as you - same problem

Same, can't run detox against an android release build with hermes enabled.

Unfortunately I don't think I can share much more on our end, as we now have this working in both RN 0.69.1 and 0.67.4 with the Soloader version pinning.
However, @kowalski - the link you've just posted reminds me of something I also stumbled across in earlier debugging  here.
Specifically https://github.com/facebook/react-native/issues/25537#issuecomment-1104619909, which suggests setting the enableVmCleanup: false property in the android/app/build.gradle:
project.ext.react = [
    enableHermes: true,
    enableVmCleanup: false,
]

This was one of the first things I tried in our environment, but it didn't seem to have much effect at the time, so I ended up reverting it.
Perhaps you'll have more luck? It may be a better option than trying to patch node_modules directly.

One last addition from me.
We're upgrading a couple of RN projects at the moment and have stumbled across a lot of discussion about Soloader 0.10.3 causing issues in Android instrumented tests:

https://github.com/reactwg/react-native-releases/discussions/26#discussioncomment-3166381
https://github.com/facebook/SoLoader/issues/94#issuecomment-1187800843

Good luck to all of you!

Thanks @hanno-jonlay. None of the pointers resolved the issue for me, but I appreciate the effort.
I will wait for Expo 46 and hope that RN69 (with bundled Hermes) fixes the issue.

we now have this working in both RN 0.69.1 and 0.67.4 with the Soloader version pinning.

@hanno-jonlay do I understand correctly that it works fine for you on 0.69.1? What exact version of Soloader have you pinned to?

...

Tried the soloader 0.10.4, and that changed the logcat a little. Now I can see a new error:
But I honestly don't know if this error is relevant or just a consequence of changing the soloader version.

Firstly i tried just to use specific version of soloader (0.10.4+)

, and that alone didn't work for detox test build, because it was causing another error. Which, later, I solved by doing the following guide:
https://wix.github.io/Detox/docs/introduction/android/#setting-detox-up-as-a-compiling-dependency
Thank you all

we now have this working in both RN 0.69.1 and 0.67.4 with the Soloader version pinning.

@hanno-jonlay do I understand correctly that it works fine for you on 0.69.1? What exact version of Soloader have you pinned to?

Yes - I'm pinned to 0.10.4 in both RN versions, and it appears to be working.

fixing to implementation 'com.facebook.soloader:soloader:0.10.4+' fixed this for me

this issue symptoms was release version that didn't work in release move while working in debug , for traceability reasons

upgrading to 0.10.4 didn;t work

Same issue for me (using the soloader:0.10.4+ fix, with Detox 19.12.1 and RN 0.68.2). The weird thing is the tests don't run for me on an Intel chip (building the app in x86_64) but it works for my colleagues on an M1 chip with arm64-v8a


YAML snippet for NuGetCommand@2 does not line up with what the task actually requires

Parameters are from here: https://github.com/Microsoft/azure-pipelines-tasks/blob/master/Tasks/NuGetCommandV2/task.json
Some of the discrepancies I see.
YAML = feedsToUse, Task = selectOrConfig
YAML = restoreSolution, Task = solution
YAML = vstsFeed, Task = feedRestore

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

ID: 0fa37a3f-6551-16ad-e164-a4ac522cdaab
Version Independent ID: a3fd6935-2b99-92ef-4eb3-3249fca01f8a
Content: NuGet restore, pack, and publish task - Azure Pipelines & TFS
Content Source: docs/pipelines/tasks/package/nuget.md
Product: devops
GitHub Login: @elbatk
Microsoft Alias: elbatk

Hi @CoolDadTx ! I took a look at the task reference, and it looks like everything is okay here. So the Task has the names that you've mentioned above, but the YAML is showing the "alias" for those input parameters. So the "alias" values are what we show and prefer people use, and they work exactly as the actual value. You will find that if you use the YAML values you refer to, they work just fine :)


Invalid target element for this operation in IE9

How about "Invalid target element for this operation" in IE9， angular 1.4.1，
the error happend in code like this

search with google get some info

innerHTML is read only in tbody so the error happend

http://stackoverflow.com/questions/4729644/cant-set-innerhtml-on-tbody-in-ie

http://stackoverflow.com/questions/28316096/invalid-target-element-for-this-operation-ngtable

https://github.com/esvit/ng-table/issues/667

say there is no resolution.
what should i do, thanks for your help.

There's not much that can be said without a demo of the problem. The only thing I can say is that manipulating
  elements and their contents is difficult, because the browser HTML parser is very strict with regards to them.

demo: http://dev.cmcm.us/,
error Invalid target element for this operation   "
" in ie 9

I have read the stackoverflow and the github issue for ngTable. If the problem is with jqlite, you could open a PR that changes the implementation to match that of jquery.

Without a small isolated test case it's hard to work on an issue. Taking that into account as well as age of this ticket, the closeness of the maintenance mode of jqLite and the fact it only affects IE 9 I'm going to close this.


Update build system to work when built by k

I mean those are both variables set by CMAKE implicitly.


Successful login with wrong password

Hello, I noticed that when I try to connect an incorrect password, the connected event is triggered as usual, but the error event is not.

PS: Of course it really can't connect but arcon.js considers it connected

on closer inspection, I have the impression that the buffer doesn't return the same value as in the condition
client.ts

Result

Fixed in 6.0.7.
Thanks for the issue!

thank u


Long when clauses not readable

Testing #23287

Of course, you can hover to see the whole clause, but that wont work for people not using the mouse

Duplicates #23378


Glibc 2.34 from alma 9

Builds on #79 and predecessors, so review those first.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

License exception is not an SPDX exception.

Documentation on acceptable licenses can be found here.

This is the output of the update.py,
(builder) E:\conda-forge\linux-sysroot-feedstock\recipe>python update.py
WARNING:root:Could not download rpm for glibc-headers from https://repo.almalinux.org/vault/9.3/AppStream/aarch64/os/Packages/glibc-headers-2.34-83.el9_3.12.aarch64.rpm!
WARNING:root:Could not download rpm for glibc-headers from https://repo.almalinux.org/vault/9.3/AppStream/ppc64le/os/Packages/glibc-headers-2.34-83.el9_3.12.ppc64le.rpm!

i.e. exactly two packages aren't available in the expected location w.r.t. x86_64. I've checked the other subfolders on the vault, and indeed the glibc-headers seem to be missing completely for 9.3 on aarch/ppc, and this also matches the info on pkgs.org. No idea why that's the case. Interestingly it's fine for s390x.

Did you move the current main to an alma8 branch?

It'll be easy to create a new v2.28 branch off the latest commit on main (https://github.com/conda-forge/linux-sysroot-feedstock/commit/4bead3616bda93c7bebab2175431552e148f8ce9), irrespective of whether that's before/after merging this. I can do it if you'd like, but Isuru doesn't like non-maintainers doing branch ops, so I'm holding off.

I went ahead and made a v2.28 branch. I will sync it with main if any other PRs get made there before this is merged.

What happened to libnss_nis.so?

See the commit message for https://github.com/conda-forge/linux-sysroot-feedstock/pull/80/commits/6d8749da1b6ec1d0d470fa7d81c7ada3e729c3f3. I couldn't find anything related to that anymore (see also here).

Also I see aarch64-conda-linux-gnu/sysroot/usr/lib64/libnss_hesiod.so is a symlink with no target

Looks like we need nss_hesiod instead...

OK, the "symlink with no target" warnings are all gone now. While I don't know what determines the separation between lib64 and usr/lib64, libnss_hesiod.so is now next to the other nss libraries:
                                              [...]
?rwxrwxr-x 0/0<PHONE_NUMBER>-10-24 22:45:50 x86_64-conda-linux-gnu/sysroot/lib64/libm.so.6
?rwxrwxr-x 0/0<PHONE_NUMBER>-10-24 22:45:50 x86_64-conda-linux-gnu/sysroot/lib64/libmvec.so.1
?rwxrwxr-x 0/0      45552 2024-10-24 22:45:50 x86_64-conda-linux-gnu/sysroot/lib64/libnss_compat.so.2
?rwxrwxr-x 0/0      40872 2024-10-24 22:45:51 x86_64-conda-linux-gnu/sysroot/lib64/libnss_db.so.2
?rwxrwxr-x 0/0      15344 2024-10-24 22:45:50 x86_64-conda-linux-gnu/sysroot/lib64/libnss_dns.so.2
?rwxrwxr-x 0/0      15336 2024-10-24 22:45:50 x86_64-conda-linux-gnu/sysroot/lib64/libnss_files.so.2
?rwxrwxr-x 0/0      28448 2024-10-24 22:45:51 x86_64-conda-linux-gnu/sysroot/lib64/libnss_hesiod.so.2
?rwxrwxr-x 0/0      15480 2024-10-24 22:45:50 x86_64-conda-linux-gnu/sysroot/lib64/libpthread.so.0
                                              [...]

Shall we remove nss components from 2.28 and 2.34 both and deal with it when there's a use-case?

That seems fine. I don't even know why we had them in the first place. Is there someone to ask about that?

It appears from #32 that some of the nss stuff was added due to a bug in building the ROS distro packages from work by @wolfv. Maybe he recalls what happened there?

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found some lint.
Here's what I've got...
For recipe/meta.yaml:

license_file entry is missing, but is required.

For recipe/meta.yaml:

License exception is not an SPDX exception.

Documentation on acceptable licenses can be found here.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.
I do have some suggestions for making it better though...
For recipe/meta.yaml:

License exception is not an SPDX exception.

Documentation on acceptable licenses can be found here.

Shall we remove nss components from 2.28 and 2.34 both and deal with it when there's a use-case?

Fixed in this PR; opened #83 that backports relevant commits to v2.28

Thanks


support/historyarchive: Allow adding timeout to http.Client in HttpArchiveBackend

Currently it's not possible to add Timeout to http.Client in HttpArchiveBackend. historyarchive.Connect does not allow passing http.Client or timeout value.
Without timeout it's possible that connection to history archive file will wait indefinitely blocking other components using this package.

Closing for now: https://github.com/stellar/go/pull/1829#issuecomment-542418676.


design: anti-L1-spoofing messaging system

Feature Request
The current Messaging System takes the l1_sender address as the caller of the L2 contract invoked.
This can be an issue if, for example, a L2 contract expects to be invoked in specific conditions by another L2 contract, but ends up being called in other conditions by an L1 contract that would match these conditions.
We need to design a system that prevents this from happening:

Arbitrum has an offset on all L1 addresses executing messages on L2
Optimism routes all messages from the XDomainMessenger Contract

this requires address collision first right? to be able to have on L1 a contract that has exactly the same address as another on L2

It seems optimism is also using address aliasing for deposits tx (used by the CrossDomainMessenger
Deposit tx aliasing here
see https://specs.optimism.io/protocol/deposits.html#address-aliasing


High memory usage with metric agent caused by Istio metrics not expiring

On cluster some kyma installations we observed that the metric agent instance consumes ~450MB of memory with low traffic. After investigation, we find out some istio proxy metrics can't be scraped because of hitting configured sample_limit
{"level":"warn","ts":1712933373.5290124,"caller":"internal/transaction.go:123","msg":"Failed to scrape Prometheus endpoint","kind":"receiver","name":"prometheus/istio","data_type":"metrics","scrape_timestamp":1712933363527,"target_labels":"{__name__=\"up\", instance=\"<IP_ADDRESS>:15090\", job=\"istio-proxy\"}"}
{"level":"warn","ts":1712933382.5105486,"caller":"internal/transaction.go:123","msg":"Failed to scrape Prometheus endpoint","kind":"receiver","name":"prometheus/istio","data_type":"metrics","scrape_timestamp":1712933372508,"target_labels":"{__name__=\"up\", instance=\"<IP_ADDRESS>:15090\", job=\"istio-proxy\"}"}
{"level":"warn","ts":1712933382.8925762,"caller":"internal/transaction.go:123","msg":"Failed to scrape Prometheus endpoint","kind":"receiver","name":"prometheus/istio","data_type":"metrics","scrape_timestamp":1712933372891,"target_labels":"{__name__=\"up\", instance=\"<IP_ADDRESS>:15090\", job=\"istio-proxy\"}"}
{"level":"warn","ts":1712933383.103386,"caller":"internal/transaction.go:123","msg":"Failed to scrape Prometheus endpoint","kind":"receiver","name":"prometheus/istio","data_type":"metrics","scrape_timestamp":1712933373102,"target_labels":"{__name__=\"up\", instance=\"<IP_ADDRESS>:15090\", job=\"istio-proxy\"}"}
{"level":"warn","ts":1712933386.1228697,"caller":"internal/transaction.go:123","msg":"Failed to scrape Prometheus endpoint","kind":"receiver","name":"prometheus/istio","data_type":"metrics","scrape_timestamp":1712933376122,"target_labels":"{__name__=\"up\", instance=\"<IP_ADDRESS>:15090\", job=\"istio-proxy\"}"}

We observed payload of istio proxy metric endpoints returns some times huge amount of data, the payload contains big histograms mostly metrics istio_request_* or istio_response_*.
On the cluster a lot of kubernetes services are generated and it looks like communication to that service happens only initially. However, metrics about not active communication is present when scraping the envoy after some time
With Istio 1.18 a metric expiry feature was introduced which might be the solution to the problem.
We have to test the metric rotation of istio pilot, we should check the workloads involved to a communication, after 5 min. should be disappear from the metrics when workload not more exist or not in any communication involved.
Criteria

Metrics in envoy of old communication will not be reported anymore after a well-defined amount of time
The two new istio settings are well understood and the value derived from experiments
PR is created on istio module and aligned with the maintainers

Will be part of 1.7.0 release of Istio module


Add API for external Buffer component iteration

Motivation:
Accessing the internal ByteBuffer instances, or the native addresses, with the Buffer.forEachReadable/Writable methods have turned out to be rather troublesome.
The trouble specifically comes from the API being designed around internal iteration.
While internal iteration is excellent at masking whether a buffer is composite or not, the loss of local mutable context (because of the use of lambdas) makes it rather combersome to use.
Modification:
This adds an API based on external iteration of the components.
There are a number of requirements pulling on this API and causing it to look the way it does.
First, we really want to ensure that the parent Buffer instance is strongly referenced and live throughout the entire iteration.
With internal iteration, we can place a reachabilityFence after the iteration.
With external iteration, we instead rely on the ComponentIterator being AutoCloseable and place a reachability fence in the close method.
Second, we wish to prevent the components from leaking beyond the iteration.
This isn't entirely possible to prevent, for either internal or external iteration.
The use of intersection types discourages assigning the iterator or the components to fields, though they don't prevent it.
It does, however, prevent correctly typed local variables from existing beyond their intended scope.
Result:
We have a API for external buffer component iteration.

@chrisvest I like the abstraction... Let's do it

@normanmaurer Comments addressed. Please take a look.

@normanmaurer Comments addressed and rebased


Expose Clipboard#read/write with data transfer

Can you provide HTML clipboard access which is available in Electron? i.e. expose that in extHostClipboard.ts

We have no plans of exposing any of the "custom" electron API but our plan is to explore the JS standard APIs: https://developer.mozilla.org/en-US/docs/Web/API/Clipboard. Once read/write is ready, and supported in Electron, we will expose them in the API.

Thanks for the answer, sad but makes sense.

I keeping this open so that we can tackle this once the underlying API is ready

But I saw https://developer.mozilla.org/en-US/docs/Web/API/Clipboard/read, mozilla standard supports read() method, which can be used to get image from the clipboard.

@mmdjiji
Everyone here is already aware of the Clipboard API, and waits patiently. You don't need to ping or bump.
The specification is managed by W3C, not Mozilla.
The APIs still have a long way to go before becoming production-ready, and receive very limited support now.

Okay, thank you! I am sorry about my ping or bump, and I will wait for it.

We closed this issue because we don't plan to address it in the foreseeable future. If you disagree and feel that this issue is crucial: we are happy to listen and to reconsider.
If you wonder what we are up to, please see our roadmap and issue reporting guidelines.
Thanks for your understanding, and happy coding!

There is still no good support across browsers for this: https://developer.mozilla.org/en-US/docs/Web/API/Clipboard#browser_compatibility

There is still no good support across browsers for this: https://developer.mozilla.org/en-US/docs/Web/API/Clipboard#browser_compatibility

Some time has passed and this seems pretty well supported by now :partying_face: I'd be interested in this API should it become available, so I'm just posting a gentle bump here.


Replace log file path when run install script

          I'm not sure if actionable, but could we further automate these 2 steps?

Like we could create a new install.bat/install.ps with the following pseudo-code:
$currentPath=Get-Current-Absolute-Path
Replace-Text-In-File AgentService.xml '{LOG_FILE_LOCATION}' "$currentPath\service-log"
.\AgentService.exe install

So that all the user need to do is to run the install.bat with admin permission.
Feel free to do this in another PR.
Originally posted by @hydraxman in https://github.com/microsoft/HydraLab/pull/227#discussion_r1071642675

One Line Installer is avalable to replace log path


ssr problem tag  with filter

this problem only on Safari mobile [Vue warn]: The client-side rendered virtual DOM tree is not matching server-rendered content. This is likely caused by incorrect HTML markup, for example nesting block-level elements inside
, or missing
. Bailing hydration and performing full client-side render.
see code
html: <time v-if="item.dates && item.dates.created" style="    margin-left: 5px;" class="date post-date" 											:datetime="item.dates.created|timeList">{{item.dates.created|timeList}}</time>
filter: ```Vue.filter('timeList', function (time) {
console.log(time)
var toRet = '--:-- --/--/--';
try {
var timeArr = time.split('T');
var left = timeArr[0].split('-');
var right = timeArr[1].split('.')[0].split(':');
var toRet = ''+ right[0] + ':' + right[1] + ' ' + left[2] + '/' + left[1] + '/' +left[0];
} catch (e) {
		}
		return toRet;
	});```

warn: Parent
<time datetime="08:36 25/01/2017" class="date post-date" style="margin-left:5px;">08:36 25/01/201736 25/01/2017</time>
what?? Carl!!! a href="tel:"?????
Anybody takes same issue?

UPDATE:
<meta name="format-detection" content="telephone=no">
this trick worked, but it no-good(

Hi!
Please make sure to follow the Issue Reporting Guidelines before opening an issue.
If you have a question or need help debugging your code, we encourage you to ask on the forum or StackOverflow first.
If you're reporting a bug, make sure to provide a minimal reproduction in a jsfiddle or github repo.
Thanks!


Implement Lagrange polynomial interpolation

This PR adds Lagrange polynomial calculation functions into the MathUtils namespace.
Polynomial interpolations are useful for example for giving the user the ability to specify curves using simple arrays of double values. A typical use-case is for example the "Curves" tool in photo editing software which uses polynomial interpolations to interpolate between the points a user gave.
I'm hoping this could be useful inside osu for example in mapping for being able to provide customizable curve functions for animatable values like for example ppy/osu#3953. It's not quite as customizable as being able to provide custom math functions anywhere, but it's a lot more space-efficient just storing a few coordinate pairs to describe a close approximation to any "curvy" function.
The advantage of this over bezier curves is that it is a mathematical function, so any one input has exactly one output.

Hey there, nice addition! My main gripe with polynomial interpolation is the diverging behavior as the number of points becomes large (wikipedia has a nice illustration of this; also known as Runge's phenomenon).
It would be awesome if you could add an additional function with restricted interface that enforces the x-coordinates to follow Chebyshev nodes, minimizing this divergence phenomenon.

I think Chebyshev nodes are a little bit out of scope of this PR as the polynomial interpolation is intended to be used for users to make curves (who will adjust the curve if they see that it becomes really weird, just like in Photoshop for example), rather than interpolating measured data points for now. I think instead of using Lagrange polynomials for such automatic data interpolation, other algorithms like using splines should be preferred.

I added barycentric lagrange interpolation now which makes calculation O(n) when repeatedly calculating over the same lagrange polynomial. I also added a PathApproximator implementation with it and a visual test case to see the PathApproximators in action for some 5-point path. (though the arc only takes the first 3)
Chebyshev nodes should be implementable more easily with the PathApproximator imlpementation too (it currently just generates 51 equally spaced points)

I'm fine with getting this in in its current state and building upon it with Chebyshev nodes afterwards, if you'd like. Seems pretty solid for now.


Unable to add multiple IPsec PSK on 23.1

When reconfiguring IPsec site-to-site tunnels after upgraded to the 23.1_6 release, the web interface does not allow to save more than one pre-shared key, complaining that another local identifier already exists (we are using local and remote IP addresses to authenticate):

But we have two tunnels between our public IP address and two different remote gateways, thus the tuple "local identifier / remote identifier" are not the same... it looks like to me as a bug in the checking logic of the web interface, isn't it?

@andrewhotlab https://github.com/opnsense/core/commit/c0a6d22e58d4f16ace73a893b594900f61f39b8c should fix the constraint issue.

Wonderful: now it works as expected.
Thank you so much @AdSchellevis !  If you solve a low-priority bug in 24 minutes, I'm curious to know how much time it takes you to solve a high priority one! :D
Needless to say that I will never thank enough anyone involved in OPNsense development... you are great!

@andrewhotlab you're welcome, thanks for reporting!


Watcher doesn't trigger for globally declared object refs exported via composable

Vue version
3.3.4
Link to minimal reproduction
https://play.vuejs.org/#eNqNVVtv2jAU/iuWNQmqorCpPCGItlXVtGnapsG0lzw0BBPSOnbkC0VC+e89viRxoAVAKPhcv+NzzpcD/lJV0U4TPMUzmYmiUkgSpas4YUVZcaHQAWlJ7jkcZLqiBNVoI3iJBtG4J4+UHAQ+L6nKtiMkyKZ1gCxgkbCMM2lMcspXKV2oVJER0tUanv6Qcc0UEeA57ycf3nQBvNF/k4iIpSjynAiyXhYlkeAHmYcfwdwZB7muc6A8u9L+1MMrDwlDTrokUk0R05QmrLYuG80yVXDm6/7Z+g5vUOf3fv5ol1JNbm/7pk4atTkByOOCl8SZIKtFHw5Xxa4fAauBajs59Lc9QgBwHjuM5zrQAXQFuyi9lgeRLrXnOJr5zsZuXmFS4aBIWVFwhxNCs+2n2NZv3abo0Bu2SBlVXc/GYGbMncskvvdjZ7HCUzUYkDIgbJyzU2djTjyESfzN5kTSzsS5oBensw1sQ6+0UjA6nzNaZM/zBAe7k+D4nz25rLOxs208oWA7asheQXc7wQh1wxPckKnGOV4u5tLmXFNLtw9dQW6GT8syk9B2H4+wkrCPmyKPniRnQGt2wBKcAYkUlIjfldk7mWAAazRGl1LKX35YmRKajBo5oM+e35A/yb2RJfiPIJKIHaBsdSoVOVFO/bD4Rfbwv1WWfK0pWJ9R/iWSU20wOrOvmq0BdmBn0X63RFuwfCkf9oow2RRlgBrL2tonGFjX8Od7pXdw76I76wc7Brd4zO1wkS23n5C6gC74X4+bO5ZsNcGotzQJSgPGzKRnSZDAovuQZG/zdpTZfyNALT7AEal2fOr15uORtYQSqEKKcERqt6Th0IY9exGAJXvBGTTP7FA+HNixhQYhtfXbOBid5rBVGt+6KdccBLyCBesjD7kzlIdvzjcq7cWvcf0Kgn3Lqw==
Steps to reproduce

Create composable function
Declare object ref in higher scope
Export it via composable function
Try to 'watch' the value

What is expected?
I expect my watcher to trigger every time when ref changes
What is actually happening?
Watcher doesn't trigger despite the ref changing
System Info
No response
Any additional comments?
I need to share reactive state in a composable to use it between components. I know that this might sound stupid and most of you would recommend using Pinia, which would easily solve my problem, but I can't because I am working on a library and I would like to avoid extra dependencies (also adding Pinia as a dependency to a package is a pain in butt). I think my approach would solve my problem fine, but it looks like a bug with watch(). You can see in the repro that it works fine with primitive type declared globally, but not with the object. However, local object watcher works fine also.
Also, if this would work, I would question the purpose of Pinia at all because it looks like a native alternative without any packages.

Crap, the solution was simple:

=>

But it seems it depends the way I declare my watcher depends on the way I update the ref.
function updateState() {
    globalState.value = { test: `Some value ${counter.value}` } // assigning to the whole ref
}

watch(globalState, () => { // will trigger
  globalStateWatcherTriggeredTimes.value++
})

watch(globalState.value, () => { // will NOT trigger
  globalStateWatcherTriggeredTimes.value++
})

function updateState() {
    globalState.value.test = `Some value ${counter.value}` // assigning to the property
}

watch(globalState, () => { // will NOT trigger
  globalStateWatcherTriggeredTimes.value++
})

watch(globalState.value, () => { // WILL trigger
  globalStateWatcherTriggeredTimes.value++
})

Maybe it's just my misunderstanding of how watch() works.

Also, locally my problem was that I've tried to put in that global ref the return value of window.getSelection() and ironically it returns the same object every time (window.getSelection() === window.getSelection()), which I didn't consider initially.


How do i solve this problem?  tool idf-python-wheels has no installed versions (IDFGH-5504)

Setting IDF_PATH: C:\Desktop\esp-idf
Adding ESP-IDF tools to PATH...
Not using an unsupported version of tool cmake found in PATH: 3.19.8.
WARNING: tool idf-python-wheels found in path, but returned non-zero exit code (1) with error message:
ϵͳҲָ·
WARNING: tool idf-python-wheels version idf4.3_py3.9_2021-01-07 is installed, but returned non-zero exit code (1) with error message:
ϵͳҲָ·
ERROR: tool idf-python-wheels has no installed versions. Please run 'C:\Desktop\esp-idf\install.bat' to install it.
When I install Esp-idf on my win10 , this problem arises.

Installation on Windows should be performed by Windows Installer. It contains several additional checks for integrity of environemnt.
Please use Windows Installer to update your environment https://dl.espressif.com/dl/esp-idf/
idf-python-wheels are no longer necessary in tools/tools.json and was removed, because on Windows wheels installation is handled by Windows Installer. Possible solutions:

update git repo to release/v4.3
run Windows Installer and let it update the installation
manually edit tools/tools.json and remove the package

Closing the issue, because solution exists. Feel free to reopen the issue in case of futher problems discovered.


Update spanish.py

added a couple of words, defined few and removed one which is not a bad word "per se".

Thanks!


update to use sys.executable for test in main

#451

Windows wheels behavior is strange. But, tests pass.


Natural Language Configuration Modifications: Set up /config command with OpenAI prompt

Probably should also fs.readFileSync to pass in the AJV information.
This will need to use the new config schema we recently implemented at https://github.com/pavlovcik/ubiquibot/pull/45#issuecomment-1815335346
Base off of a commit anytime after that one.

/start

@pavlovcik would it be a good idea to have a /config help or /config --help and we'll have GPT explain the config structure or list what can be set?

Help should be in the help menu. Don't make a sub help menu.
The commit I'm referring to is when we refactored all of the configuration hierarchy on my fork.

generateConfiguration(context: ProbotContext)

Seems like a sensible start.


Normalize TabBarTheme

This PR is to make preparations to make TabBarTheme conform to Flutter's conventions for component themes:

Added a TabBarThemeData class which defines overrides for the defaults for TabBar properties.
Added 2 TabBarTheme constructor parameters: TabBarThemeData? data and Widget? child. This is now the preferred way to configure a TabBarTheme:

TabBarTheme(
  data: TabBarThemeData(labelColor: xxx, indicatorColor: xxx, ...),
  child: TabBar(...)
)

These two properties are made nullable to not break existing apps which has customized ThemeData.tabBarTheme.

Changed the type of component theme defaults from TabBarTheme to TabBarThemeData.

TODO:

Fix internal failures.
Change the type of ThemeData.tabBarTheme from TabBarTheme to TabBarThemeData. This may cause breaking changes, a migration guide will be created.

Addresses the "theme normalization" sub project within https://github.com/flutter/flutter/issues/91772
Pre-launch Checklist

[x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
[x] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
[x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
[x] I signed the [CLA].
[x] I listed at least one issue that this PR fixes in the description above.
[x] I updated/added relevant documentation (doc comments with ///).
[x] I added new tests to check the change I am making, or this PR is [test-exempt].
[x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported.
[x] All existing and new tests are passing.

Reason for revert: The newly added tests are failing in postsubmit. See https://ci.chromium.org/ui/p/flutter/builders/prod/Windows framework_tests_libraries/19062/overview

@QuncCccccc I mentioned this on discord but I know it's easy to get lost so I'll repeat it here:

the way we handled this is to avoid asserting .toString behavior.  here's an example:

--- a/dev/tracing_tests/test/timeline_test.dart
+++ b/dev/tracing_tests/test/timeline_test.dart
@@ -108,7 +108,7 @@ void main() {
       <String>['BUILD', 'Placeholder', 'CustomPaint', 'LAYOUT', 'UPDATING COMPOSITING BITS', 'PAINT', 'COMPOSITING', 'FINALIZE TREE'],
     );
     args = (events.where((TimelineEvent event) => event.json!['name'] == '$Placeholder').single.json!['args'] as Map<String, Object?>).cast<String, String>();
-    expect(args['color'], 'Color(0xffffffff)');
+    expect(args['color'], '${const Color(0xffffffff)}');
     debugProfileBuildsEnabled = false;
     debugEnhanceBuildTimelineArguments = false;


Add ignore keys functionality to the Consul storage

Coverage increased (+0.1%) to 85.57% when pulling d3ef23ba70a9b4510524a8d0657af0202238221a on ignore into 4c686d38b0eadb6439c8cec49600f1e0445e4df5 on master.

Coverage increased (+0.1%) to 85.57% when pulling c67bce792b68db86c77ae68f3723c82a4ab8774f on ignore into 4c686d38b0eadb6439c8cec49600f1e0445e4df5 on master.

Coverage increased (+0.1%) to 85.57% when pulling a848ac16bcd705eebce97804116890e543f783b7 on ignore into 4c686d38b0eadb6439c8cec49600f1e0445e4df5 on master.

Coverage increased (+0.1%) to 85.57% when pulling 70bdc500d7b556184a0105e231446edbcef64d10 on ignore into 4c686d38b0eadb6439c8cec49600f1e0445e4df5 on master.


EXTRA_MODEL_FIELDS cant refer to self in ForeignKey

i was trying to add a parent category reference to blogcategory, but each time got and error such as
blog.blogcategory: 'parent_category' has a relation with model self, which has either not been installed or is abstract.
i had to modify boot/__init__.py as mention at the link below, to get it to work
https://groups.google.com/forum/#!topic/mezzanine-users/CBqb6srpmqU
Is this a bug? or is there some other way to implement without modifying 'boot/__init__.py' directly?

Sounds like you have some working code, please create a PR.

ok np, i submtting it as pr #1396


build sole mesh failed, use a 4800x4800 obj file.

obj file content:
g default
v 0 0 0
v 0 0 -4800
v 4800 0 -4800
v 4800 0 0

vn 0 -1 0
vn 0 -1 0
vn 0 -1 0
vn 0 -1 0

vt 0 0
vt 0 0
vt 0 0
vt 0 0

usemtl None
usemap None

f 3/3/3 2/2/2 1/1/1
f 1/1/1 4/4/4 3/3/3

For a plane this large, it's best to split up generation into chunks with the tile mesh generator and pay close attention to the build parameters used, as they can have a massive impact on performance.


WaitForCompletion would throw a Null pointer exception

for acquisitions that did not have a savingExecutor (which is a valid way to run the acquisition engine).

Not sure if the change in tag names interferes with other uses of AcqEngJ.  Alternatively, we can catch these alternative spellings in the Micro-Manager PropertyMaps (or so I believe).

Not sure if the change in tag names interferes with other uses of AcqEngJ. Alternatively, we can catch these alternative spellings in the Micro-Manager PropertyMaps (or so I believe).

Yes, I think that would be a better way to go as this would seem to change metadata names for other applications as you say

I think it is best to not try match all these tags to the ones in mmstudio. Theses are authoritative for MMStudio, but acqengJ sits at a lower level of abstraction and do not make all the assumptions about the microscope that mmstudio does (and this will be true even more so as it is increasingly generalized). Creating the tags that mmstudio needs should thus be done on its own side in the adapter code

The wait for completion part looks good and can be merged on its own

Since Micro-Manager looks at that tag to report the Z position.  If we leave this out, upstream has no idea any more about Z  position.  I guess this can also be done upstream (i.e. in the AcqEngJAdapter code).  Will look at that.

Removed the commit changing metadata (and handle that in the AcqEngJ adapter).