Initialize error

WHAT
If I take my currently functioning ~/.config/afx/* under the new environment, put the latest release of the afx binary in the path, and run afx install, I get an error that ~/.afx/state.json does not exist.

Thank you for using this tool and reporting the trouble.
I'm also using ~/.config/afx as config directory but I didn't face this kinda situation in my env. So please let me know more detail log? This page is helpful to show debug log.

I9-1% AFX_LOG=debug afx install
2022/03/21 11:59:38 [INFO] afx version: 0.1.18
2022/03/21 11:59:38 [INFO] Go runtime version: go1.16.1
2022/03/21 11:59:38 [INFO] Build tag/SHA: v0.1.18/adb5a3e
2022/03/21 11:59:38 [INFO] CLI args: []string{"afx", "install"}
2022/03/21 11:59:38 [DEBUG] (goroutine): checking new updates...
2022/03/21 11:59:38 [INFO] Reading config /home/nakai/.config/afx/github.yaml...
2022/03/21 11:59:38 [DEBUG] call GitHub Release API to get release info
2022/03/21 11:59:38 [INFO] Parsing config...
2022/03/21 11:59:38 [INFO] Reading config /home/nakai/.config/afx/main.yaml...
2022/03/21 11:59:38 [INFO] Parsing config...
2022/03/21 11:59:38 [INFO] Reading config /home/nakai/.config/afx/release.yaml...
2022/03/21 11:59:38 [INFO] Parsing config...
2022/03/21 11:59:38 [DEBUG] dependency graph is here:
* sindresorhus/pure -> mafredri/zsh-async
2022/03/21 11:59:38 [DEBUG] mkdir /home/nakai/.afx
2022/03/21 11:59:38 [DEBUG] mkdir /home/nakai/.afx/bin
[ERROR]: failed to initialize afx: faield to open state file: open /home/nakai/.afx/state.json: no such file or directory

Thank you. This has been solved at new version v0.1.19


Destinations in relations with type=destination_sign get impoper changes

URL
No response
How to reproduce the issue?

Create a destination sign relation
Type anything in the destination field with at least one capitalized letter and at least one space and press enter

Screenshot(s) or anything else?
The text gets converted to lowercase and spaces are replaced with underscores.

Which iD Editor versions do you see the issue on?
Released version at openstreetmap.org/edit
Which browsers are you seeing this problem on?
Firefox

Fixed by https://github.com/openstreetmap/id-tagging-schema/pull/515


Move Screen to use NPM module for keyboard avoiding.

[x] Issue does not already exist
Identify exactly what aspect your issue is about

[x] ignite base application
[ ] ignite the cli
[x] ignite generated code

remove keyboard avoiding template code from screen generated template, and now use https://github.com/Andr3wHur5t/react-native-keyboard-spacer  which keeps code simpler.

Nope, don't use keyboard spacer, coming soon keyboard avoiding view -  https://github.com/facebook/react-native/commit/8b78846a9501ef9c5ce9d1e18ee104bfae76af2e


Added blender rule

@pgaskin Could you please merge this PR if it's OK? I don't have permission to do that.


RC test: Graphing Lines 1.3.0-rc.1

@KatieWoe , @ariel-phet , @amanda-phet graphing-lines/1.3.0-rc.1 is ready for RC testing. This is a brand=phet release only (no PhET-iO, no a11y).
Document issues in https://github.com/phetsims/graphing-lines/issues and link to this issue.
NOTE: For efficiency, this should be tested at the same time as Graphing Slope-Intercept 1.1.0, see #278.
Assigning to @ariel-phet for prioritization.

General RC Test

What to Test

Click every single button.
Test all possible forms of input.

Test all mouse/trackpad inputs.
Test all touchscreen inputs.

If there is sound, make sure it works.
Make sure you can't lose anything.
Play with the sim normally.
Try to break the sim.
Test all query parameters on all platforms. (See QA Book for a list of query parameters.)
Download HTML on Chrome and iOS.
Make sure the iFrame version of the simulation is working as intended on all platforms.
Make sure the XHTML version of the simulation is working as intended on all platforms.
Complete the test matrix.
Don't forget to make sure the sim works with Legends of Learning.
Check this LoL spreadsheet and notify AR if it not there.
If this is rc.1 please do a memory test.

Issues to Verify

[x] disable showAnswers in production versions
[x] prioritize active line when color-coding point tool
[x] use icons for "Hide lines" and "Hide grid"
[x] do not disable UI components when graph contents are hidden
[x] use standard font for math symbols
[x] equations are not simplified in Point-Slope scree
[x] Eliminate GamePhaseProperty

These issues should have the "status:fixed-pending-testing" label. Check these issues off and close them if they are fixed. Otherwise, post a comment in the issue saying that it wasn't fixed.

Link(s)

Simulation
iFrame
XHTML
Test Matrix
Legends of Learning Harness

FAQs for QA Members

There are multiple tests in this issue... Which test should I do first?
Test in order! Test the first thing first, the second thing second, and so on.

How should I format my issue?

We typically assign the developer who opened the issue in the QA repository.

My question isn't in here... What should I do?
You should:

Consult the QA Book.
Google it.
Ask Katie.
Ask a developer.
Google it again.
Cry.

Memory Test Results:
Start: 47.9
1 min: 60.4
2 min: 63.7
3 min: 64.6
4 min: 63.0
5 min: 64.0
6 min: 67.4
7 min: 64.1
8 min: 69.9
9 min: 66.3
10 min: 70.1

QA is done

Thanks QA team! We'll need another RC, and I'll keep this issue open until I've created the corresponding issue.

1.3.0-rc.2 has been published, see https://github.com/phetsims/QA/issues/283.


added checkServerIdentity override

This allows for the user to define a custom checkServerIdentity function to override the default certificate hostname verification function (tls. checkServerIdentity)

Couldn't you use the env variable NODE_TLS_REJECT_UNAUTHORIZED ?

That's an on/off switch - it doesn't allow you to define your own custom logic to validate certificates.

Gotcha!
Will ping as soon as it is published.

Thanks!

Published in v0.2.3


Quoted org.gradle.jvmargs argument is incorrectly handled, resulting in Daemon startup failure

Our build is failing when specyfiying org.gradle.jvmargs / java heap size:
      - name: Setup and execute Gradle
        uses<EMAIL_ADDRESS>        with:
          arguments: |
            assembleCurrentStageDebug
            -Dorg.gradle.parallel=true
            -Dorg.gradle.caching=true
            -Dorg.gradle.jvmargs="-Xmx3g -XX:+HeapDumpOnOutOfMemoryError -XX:MaxMetaspaceSize=256m"
            -Dkotlin.daemon.jvm.options="-Xmx1g"
            -Dorg.gradle.vfs.watch=false
            -Pandroid.builder.sdkDownload=false
            --scan

with output:
Run<EMAIL_ADDRESS>Restore Gradle state from cache
/home/runner/work/app-android/app-android/gradlew assembleCurrentStageDebug -Dorg.gradle.parallel=true -Dorg.gradle.caching=true -Dorg.gradle.jvmargs="-Xmx3g -XX:+HeapDumpOnOutOfMemoryError -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8" -Dkotlin.daemon.jvm.options="-Xmx1g" -Dorg.gradle.vfs.watch=false -Pandroid.builder.sdkDownload=false --scan
To honour the JVM settings for this build a single-use Daemon process will be forked. See https://docs.gradle.org/7.4.1/userguide/gradle_daemon.html#sec:disabling_the_daemon.
Could not write standard input to Gradle build daemon.
java.io.IOException: Stream closed
	at java.base/java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:442)
	at java.base/java.io.OutputStream.write(OutputStream.java:157)
	at java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
	at java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
	at org.gradle.process.internal.streams.ExecOutputHandleRunner.forwardContent(ExecOutputHandleRunner.java:[68](https://github.com/globalid/app-android/runs/5832608936?check_suite_focus=true#step:6:68))
	at org.gradle.process.internal.streams.ExecOutputHandleRunner.run(ExecOutputHandleRunner.java:53)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)

FAILURE: Build failed with an exception.

* What went wrong:
Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the User Manual chapter on the daemon at https://docs.gradle.org/7.4.1/userguide/gradle_daemon.html
Process command line: /usr/lib/jvm/temurin-11-jdk-amd64/bin/java --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.util.concurrent.atomic=ALL-UNNAMED -Xmx3g -XX:+HeapDumpOnOutOfMemoryError -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8 -Dfile.encoding=UTF-8 -Duser.country -Duser.language=en -Duser.variant -cp /home/runner/.gradle/wrapper/dists/gradle-7.4.1-bin/58kw26xllvsiedyf3nujyarhn/gradle-7.4.1/lib/gradle-launcher-7.4.1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 7.4.1
Please read the following process output to find out more:
-----------------------
Invalid maximum heap size: -Xmx3g -XX:+HeapDumpOnOutOfMemoryError -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org/
Error: Gradle build failed: process exited with status 1

But it works when we set it to the gradlew wrapper when running it manually:
    - name: Run Gradle task
      shell: bash
      run: >-
        ./gradlew assembleCurrentStageDebug
        -Dorg.gradle.parallel=true
        -Dorg.gradle.caching=true
        -Dorg.gradle.jvmargs="-Xmx3g -XX:+HeapDumpOnOutOfMemoryError -XX:MaxMetaspaceSize=256m"
        -Dkotlin.daemon.jvm.options="-Xmx1g"
        -Dorg.gradle.vfs.watch=false
        -Pandroid.builder.sdkDownload=false
        --scan

This is using the ubuntu-latest runner, which we know has 7gb of RAM, but we tested it extensively with the specified settings and never had OOM problems with them. It's a large project, so maximizing the available heap is very important for build preformance (on a local machine with 12g heap size it uses roughly 9g).
Without these jvm settings (just deleted the -Dorg.gradle.jvmargs line), we're getting failed build in the configuration stage already:
> Configure project :libs:logout
Warning: The 'kotlin-android-extensions' Gradle plugin is deprecated. Please use this migration guide (https://goo.gle/kotlin-android-extensions-deprecation) to start working with View Binding (https://developer.android.com/topic/libraries/view-binding) and the 'kotlin-parcelize' plugin.

Expiring Daemon because JVM heap space is exhausted

> Configure project :libs:markdown
Warning: The 'kotlin-android-extensions' Gradle plugin is deprecated. Please use this migration guide (https://goo.gle/kotlin-android-extensions-deprecation) to start working with View Binding (https://developer.android.com/topic/libraries/view-binding) and the 'kotlin-parcelize' plugin.

Expiring Daemon because JVM heap space is exhausted
Expiring Daemon because JVM heap space is exhausted
Expiring Daemon because JVM heap space is exhausted

> Configure project :libs:mentions
Warning: The 'kotlin-android-extensions' Gradle plugin is deprecated. Please use this migration guide (https://goo.gle/kotlin-android-extensions-deprecation) to start working with View Binding (https://developer.android.com/topic/libraries/view-binding) and the 'kotlin-parcelize' plugin.

FAILURE: Build failed with an exception.

* What went wrong:
Java heap space

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org/
Error: Gradle build failed: process exited with status 1

Thanks for the report. Is the project public so I can inspect the output/logs directly?
The only thing I can think would be different is that the gradle-build-action currently sets org.gradle.daemon=false. To check if this could be the underlying reason, can you please try separating the "Setup Gradle" and "Execute Gradle" steps? Something like:
    - name: Setup and execute Gradle
      uses<EMAIL_ADDRESS>    - name: Run Gradle task
      shell: bash
      run: >-
        ./gradlew assembleCurrentStageDebug
        -Dorg.gradle.parallel=true
        -Dorg.gradle.caching=true
        -Dorg.gradle.jvmargs="-Xmx3g -XX:+HeapDumpOnOutOfMemoryError -XX:MaxMetaspaceSize=256m"
        -Dkotlin.daemon.jvm.options="-Xmx1g"
        -Dorg.gradle.vfs.watch=false
        -Pandroid.builder.sdkDownload=false
        --scan

This provides all of the caching/integration benefits of the gradle-build-action but separates the actual invocation of Gradle.

I can reproduce this issue: it appears that the entire content of org.gradle.jvmargs is being treated as a single argument when started the daemon. So while the command line looks OK, the build treats this as though "-Xmx3g -Xms512m" is quoted on the command line.
Note that if the order of jvm args is reversed, the failure is "Invalid initial heap" instead of "Invalid maximum heap".
Unfortunately I don't currently have an idea on how to fix this, but I think that separating the "Setup Gradle" from "Execute Gradle" steps is a valid workaround.

Hi Daz, thank you for the speedy reply.
Separating the gradle setup from the build invocation does indeed fix the issue. 👍
Just out of curiosity, why do you disable the daemon, since it is stated in gradle docs that leaving the daemon enabled is recommended for both user and CI machines?

Separating the gradle setup from the build invocation does indeed fix the issue.
Thanks for confirming.

Just out of curiosity, why do you disable the daemon

This was done to avoid locks being held by the daemon, which prevent the Gradle User Home from being cached. But this was meant to be a temporary solution, pending a proper fix: see #113

In issue https://github.com/gradle/gradle-build-action/issues/113 you wrote that if we were to use --daemon flag in the arguments we'd need to take care of stopping the daemon by ourselves afterwards. Would that be any different than when running the ./gradlew manually (without explicitly calling ./gradlew --stop?
Also, another thing I noticed is that subsequent builds aren't fully using/reusing the configuration cache, even on the same commit, but I can see it should be restored and saved empty in post, which I understand as no changes. Are you by any chance disabling that somewhere as well?
Restore:
Cache restored successfully
  Restored configuration-cache with key configuration-cache-0ecb672fc3ffd7eb541007597a07a9fc9148f51a5639ccf1bb20c36b56cadae5 to /home/runner/work/app-android/app-android/.gradle/configuration-cache

Save (post):
Entry: /home/runner/work/app-android/app-android/.gradle/configuration-cache
      Requested Key : configuration-cache-0ecb672fc3ffd7eb[54](https://github.com/globalid/app-android/runs/5852277133?check_suite_focus=true#step:62:54)1007597a07a9fc9148f51a[56](https://github.com/globalid/app-android/runs/5852277133?check_suite_focus=true#step:62:56)39ccf1bb20c36b56cadae5
      Restored  Key : configuration-cache-0ecb672fc3ffd7eb541007597a07a9fc9148f51a5639ccf1bb20c36b56cadae5
                Size: 4 MB (3785008 B)
      Saved     Key :
                Size:

Build scan/Performance/Configuration:

Total configuration time
1m 56.639s

Script compilation
0.000s

Building included plugins
0.000s

Model configuration
59.919s

Task graph calculation
39.541s

Other
17.179s

Locally, Total configuration time is 0.182s

In issue #113 you wrote that if we were to use --daemon flag in the arguments we'd need to take care of stopping the daemon by ourselves afterwards. Would that be any different than when running the ./gradlew manually (without explicitly calling ./gradlew --stop?

No, it wouldn't be any different. But the failure would show up when trying to save the Gradle User Home, and thus would be attributed to the gradle-build-action. I really want this action to work out-of-the-box in 99% of cases, which is why we disable the daemon when it is used.
One option would be for a user to explicitly opt-in to the daemon via this action. But since there's a clear path to handling this automatically (track all started Gradle daemons and stop them before saving Gradle Home), I'd rather invest the effort in that. This will work whether you run the build with arguments or split it out into a separate run step.

Also, another thing I noticed is that subsequent builds aren't fully using/reusing the configuration cache, even on the same commit, but I can see it should be restored and saved empty in post, which I understand as no changes. Are you by any chance disabling that somewhere as well?

No, the action doesn't do anything to disable configuration caching. It should work.
Do you see any messages about configuration-cache in the Gradle output?

No, the action doesn't do anything to disable configuration caching. It should work.
Do you see any messages about configuration-cache in the Gradle output?

Yes, I see this line, but when running with --debug argument, I don't really see what has changed... or at least I can't decipher it from the logs.
Calculating task graph as configuration cache cannot be reused because the set of Gradle properties has changed.

 Working directory: /home/runner/.gradle/daemon/7.4.1 Command: /usr/lib/jvm/temurin-11-jdk-amd64/bin/java -XX:+HeapDumpOnOutOfMemoryError -XX:MaxMetaspaceSize=1g --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.invoke=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.prefs/java.util.prefs=ALL-UNNAMED --add-opens java.base/java.nio.charset=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.util.concurrent.atomic=ALL-UNNAMED -Xmx3584m -Dfile.encoding=UTF-8 -Duser.country -Duser.language=en -Duser.variant -cp /home/runner/.gradle/wrapper/dists/gradle-7.4.1-bin/58kw26xllvsiedyf3nujyarhn/gradle-7.4.1/lib/gradle-launcher-7.4.1.jar org.gradle.launcher.daemon.bootstrap.GradleDaemon 7.4.1
2022-04-08T10:34:02.2529377Z 2022-04-08T10:34:02.215+0000 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTING
2022-04-08T10:34:02.2531984Z 2022-04-08T10:34:02.218+0000 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Waiting until process started: Gradle build daemon.
2022-04-08T10:34:02.2534375Z 2022-04-08T10:34:02.221+0000 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTED
2022-04-08T10:34:02.2536915Z 2022-04-08T10:34:02.227+0000 [INFO] [org.gradle.process.internal.DefaultExecHandle] Successfully started process 'Gradle build daemon'
2022-04-08T10:34:02.2542599Z 2022-04-08T10:34:02.227+0000 [DEBUG] [org.gradle.launcher.daemon.client.DefaultDaemonStarter] Gradle daemon process is starting. Waiting for the daemon to detach...
2022-04-08T10:34:02.2543609Z 2022-04-08T10:34:02.228+0000 [DEBUG] [org.gradle.process.internal.ExecHandleRunner] waiting until streams are handled...
2022-04-08T10:34:02.2544766Z 2022-04-08T10:34:02.230+0000 [DEBUG] [org.gradle.launcher.daemon.bootstrap.DaemonOutputConsumer] Starting consuming the daemon process output.
2022-04-08T10:34:03.4347077Z 2022-04-08T10:34:03.345+0000 [DEBUG] [org.gradle.launcher.daemon.bootstrap.DaemonOutputConsumer] daemon out: Daemon started. About to close the streams. Daemon details:<PHONE_NUMBER>3633002432653838343863322d623962642d343936362d393134632d376334626264323864316262b99f4e74c21543f79bdf36565c4ae2d10000940b00000001000000047f00000100352f686f6d652f72756e6e65722f2e677261646c652f6461656d6f6e2f372e342e312f6461656d6f6e2d313736332e6f75742e6c6f67
2022-04-08T10:34:03.4348463Z 2022-04-08T10:34:03.346+0000 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: DETACHED
2022-04-08T10:34:03.4349326Z 2022-04-08T10:34:03.346+0000 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Process 'Gradle build daemon' finished with exit value 0 (state: DETACHED)
2022-04-08T10:34:03.4350192Z 2022-04-08T10:34:03.346+0000 [DEBUG] [org.gradle.launcher.daemon.client.DefaultDaemonStarter] Gradle daemon process is now detached.
2022-04-08T10:34:03.4351230Z 2022-04-08T10:34:03.350+0000 [INFO] [org.gradle.launcher.daemon.client.DefaultDaemonStarter] An attempt to start the daemon took 1.153 secs.
2022-04-08T10:34:03.4352545Z 2022-04-08T10:34:03.350+0000 [DEBUG] [org.gradle.launcher.daemon.client.DefaultDaemonConnector] Started Gradle daemon DaemonStartupInfo{pid=1763, uid=2e8848c2-b9bd-4966-914c-7c4bbd28d1bb, address=[b99f4e74-c215-43f7-9bdf-36565c4ae2d1 port:37899, addresses:[/<IP_ADDRESS>]], diagnostics={pid=1763, daemonLog=/home/runner/.gradle/daemon/7.4.1/daemon-1763.out.log}}
2022-04-08T10:34:03.4353910Z 2022-04-08T10:34:03.351+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
2022-04-08T10:34:03.4368623Z 2022-04-08T10:34:03.351+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on daemon addresses registry.
2022-04-08T10:34:03.4369534Z 2022-04-08T10:34:03.351+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
2022-04-08T10:34:03.4370528Z 2022-04-08T10:34:03.352+0000 [DEBUG] [org.gradle.internal.remote.internal.inet.TcpOutgoingConnector] Attempting to connect to [b99f4e74-c215-43f7-9bdf-36565c4ae2d1 port:37899, addresses:[/<IP_ADDRESS>]].
2022-04-08T10:34:03.4371473Z 2022-04-08T10:34:03.352+0000 [DEBUG] [org.gradle.internal.remote.internal.inet.TcpOutgoingConnector] Trying to connect to address /<IP_ADDRESS>.
2022-04-08T10:34:03.4372509Z 2022-04-08T10:34:03.356+0000 [DEBUG] [org.gradle.internal.remote.internal.inet.TcpOutgoingConnector] Connected to address /<IP_ADDRESS>:37899.
2022-04-08T10:34:03.4375756Z 2022-04-08T10:34:03.388+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Connected to daemon DaemonInfo{pid=1763, address=[b99f4e74-c215-43f7-9bdf-36565c4ae2d1 port:37899, addresses:[/<IP_ADDRESS>]], state=Busy, lastBusy=1649414043339, context=DefaultDaemonContext[uid=2e8848c2-b9bd-4966-914c-7c4bbd28d1bb,javaHome=/usr/lib/jvm/temurin-11-jdk-amd64,daemonRegistryDir=/home/runner/.gradle/daemon,pid=1763,idleTimeout=10800000,priority=NORMAL,daemonOpts=-XX:+HeapDumpOnOutOfMemoryError,-XX:MaxMetaspaceSize=1g,--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.base/java.lang=ALL-UNNAMED,--add-opens,java.base/java.lang.invoke=ALL-UNNAMED,--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.base/java.nio.charset=ALL-UNNAMED,--add-opens,java.base/java.net=ALL-UNNAMED,--add-opens,java.base/java.util.concurrent.atomic=ALL-UNNAMED,-Xmx3584m,-Dfile.encoding=UTF-8,-Duser.country,-Duser.language=en,-Duser.variant]}. Dispatching request Build{id=25a2313c-1998-4b97-868b-af713aa6b6f7, currentDir=/home/runner/work/app-android/app-android}.
2022-04-08T10:34:03.4378580Z 2022-04-08T10:34:03.388+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientConnection] thread 1: dispatching class org.gradle.launcher.daemon.protocol.Build
2022-04-08T10:34:03.4381956Z 2022-04-08T10:34:03.424+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Received result org.gradle.launcher.daemon.protocol.BuildStarted@1a69561c from daemon DaemonInfo{pid=1763, address=[b99f4e74-c215-43f7-9bdf-36565c4ae2d1 port:37899, addresses:[/<IP_ADDRESS>]], state=Busy, lastBusy=1649414043339, context=DefaultDaemonContext[uid=2e8848c2-b9bd-4966-914c-7c4bbd28d1bb,javaHome=/usr/lib/jvm/temurin-11-jdk-amd64,daemonRegistryDir=/home/runner/.gradle/daemon,pid=1763,idleTimeout=10800000,priority=NORMAL,daemonOpts=-XX:+HeapDumpOnOutOfMemoryError,-XX:MaxMetaspaceSize=1g,--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.base/java.lang=ALL-UNNAMED,--add-opens,java.base/java.lang.invoke=ALL-UNNAMED,--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.base/java.nio.charset=ALL-UNNAMED,--add-opens,java.base/java.net=ALL-UNNAMED,--add-opens,java.base/java.util.concurrent.atomic=ALL-UNNAMED,-Xmx3584m,-Dfile.encoding=UTF-8,-Duser.country,-Duser.language=en,-Duser.variant]} (build should be starting).
2022-04-08T10:34:03.5332813Z 2022-04-08T10:34:03.433+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientInputForwarder] Dispatching close input message: org.gradle.launcher.daemon.protocol.CloseInput@10f86071
2022-04-08T10:34:03.5407253Z 2022-04-08T10:34:03.434+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientConnection] thread 18: dispatching class org.gradle.launcher.daemon.protocol.CloseInput
2022-04-08T10:34:03.5408583Z 2022-04-08T10:34:03.435+0000 [INFO] [org.gradle.launcher.daemon.server.exec.LogToClient] The client will now receive all logging from the daemon (pid: 1763). The daemon log file: /home/runner/.gradle/daemon/7.4.1/daemon-1763.out.log
2022-04-08T10:34:03.5410074Z 2022-04-08T10:34:03.435+0000 [DEBUG] [org.gradle.launcher.daemon.server.SynchronizedDispatchConnection] thread 17: received class org.gradle.launcher.daemon.protocol.CloseInput
2022-04-08T10:34:03.5411260Z 2022-04-08T10:34:03.435+0000 [DEBUG] [org.gradle.launcher.daemon.server.DefaultDaemonConnection] thread 17: Received IO message from client: org.gradle.launcher.daemon.protocol.CloseInput@55d50465
2022-04-08T10:34:03.5412497Z 2022-04-08T10:34:03.446+0000 [INFO] [org.gradle.launcher.daemon.server.exec.LogAndCheckHealth] Starting build in new daemon [memory: 3.5 GiB]
2022-04-08T10:34:03.5413449Z 2022-04-08T10:34:03.449+0000 [INFO] [org.gradle.launcher.daemon.server.exec.ForwardClientInput] Closing daemon's stdin at end of input.
2022-04-08T10:34:03.5414796Z 2022-04-08T10:34:03.460+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] The daemon has started executing the build.
2022-04-08T10:34:03.5417604Z 2022-04-08T10:34:03.465+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] Executing build with daemon context: DefaultDaemonContext[uid=2e8848c2-b9bd-4966-914c-7c4bbd28d1bb,javaHome=/usr/lib/jvm/temurin-11-jdk-amd64,daemonRegistryDir=/home/runner/.gradle/daemon,pid=1763,idleTimeout=10800000,priority=NORMAL,daemonOpts=-XX:+HeapDumpOnOutOfMemoryError,-XX:MaxMetaspaceSize=1g,--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.base/java.lang=ALL-UNNAMED,--add-opens,java.base/java.lang.invoke=ALL-UNNAMED,--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,--add-opens,java.base/java.nio.charset=ALL-UNNAMED,--add-opens,java.base/java.net=ALL-UNNAMED,--add-opens,java.base/java.util.concurrent.atomic=ALL-UNNAMED,-Xmx3584m,-Dfile.encoding=UTF-8,-Duser.country,-Duser.language=en,-Duser.variant]
2022-04-08T10:34:03.5420075Z 2022-04-08T10:34:03.464+0000 [INFO] [org.gradle.launcher.daemon.server.exec.ForwardClientInput] The daemon will no longer process any standard input.
2022-04-08T10:34:03.6337362Z 2022-04-08T10:34:03.584+0000 [INFO] [org.gradle.internal.work.DefaultWorkerLeaseService] Using 2 worker leases.
2022-04-08T10:34:03.7395346Z 2022-04-08T10:34:03.651+0000 [DEBUG] [org.gradle.internal.work.DefaultWorkerLeaseService] Worker lease root.1 started (1 worker(s) in use).
2022-04-08T10:34:03.7399584Z 2022-04-08T10:34:03.651+0000 [DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Daemon worker: acquired lock on root.1
2022-04-08T10:34:03.7400808Z 2022-04-08T10:34:03.654+0000 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationRunner] Build operation 'Run build' started
2022-04-08T10:34:03.7401847Z 2022-04-08T10:34:03.664+0000 [WARN] [org.gradle.internal.featurelifecycle.LoggingIncubatingFeatureHandler] Configuration cache is an incubating feature.
2022-04-08T10:34:03.7403260Z 2022-04-08T10:34:03.704+0000 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Creating new cache for file-access, path /home/runner/.gradle/caches/journal-1/file-access.bin, access org.gradle.cache.internal.DefaultCacheAccess@21973bf9
2022-04-08T10:34:03.7404643Z 2022-04-08T10:34:03.712+0000 [DEBUG] [org.gradle.cache.internal.DefaultInMemoryCacheDecoratorFactory] Creating in-memory store for cache /home/runner/.gradle/caches/journal-1/file-access.bin (max size: 45100)
2022-04-08T10:34:03.7405986Z 2022-04-08T10:34:03.714+0000 [DEBUG] [org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess] Acquiring file lock for journal cache (/home/runner/.gradle/caches/journal-1)
2022-04-08T10:34:03.7407035Z 2022-04-08T10:34:03.715+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on journal cache (/home/runner/.gradle/caches/journal-1).
2022-04-08T10:34:03.7408472Z 2022-04-08T10:34:03.715+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on journal cache (/home/runner/.gradle/caches/journal-1).
2022-04-08T10:34:03.7409491Z 2022-04-08T10:34:03.726+0000 [DEBUG] [org.gradle.cache.internal.locklistener.DefaultFileLockContentionHandler] Starting file lock listener thread.
2022-04-08T10:34:03.8331709Z 2022-04-08T10:34:03.757+0000 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Creating new cache for fileHashes, path /home/runner/.gradle/caches/7.4.1/fileHashes/fileHashes.bin, access org.gradle.cache.internal.DefaultCacheAccess@6017e561
2022-04-08T10:34:03.8333175Z 2022-04-08T10:34:03.757+0000 [DEBUG] [org.gradle.cache.internal.DefaultInMemoryCacheDecoratorFactory] Creating in-memory store for cache /home/runner/.gradle/caches/7.4.1/fileHashes/fileHashes.bin (max size: 1807300)
2022-04-08T10:34:03.8334614Z 2022-04-08T10:34:03.758+0000 [DEBUG] [org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess] Acquiring file lock for file hash cache (/home/runner/.gradle/caches/7.4.1/fileHashes)
2022-04-08T10:34:03.8335917Z 2022-04-08T10:34:03.758+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on file hash cache (/home/runner/.gradle/caches/7.4.1/fileHashes).
2022-04-08T10:34:03.8337127Z 2022-04-08T10:34:03.758+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on file hash cache (/home/runner/.gradle/caches/7.4.1/fileHashes).
2022-04-08T10:34:03.8338409Z 2022-04-08T10:34:03.818+0000 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Creating new cache for resourceHashesCache, path /home/runner/.gradle/caches/7.4.1/fileHashes/resourceHashesCache.bin, access org.gradle.cache.internal.DefaultCacheAccess@6017e561
2022-04-08T10:34:03.8339939Z 2022-04-08T10:34:03.819+0000 [DEBUG] [org.gradle.cache.internal.DefaultInMemoryCacheDecoratorFactory] Creating in-memory store for cache /home/runner/.gradle/caches/7.4.1/fileHashes/resourceHashesCache.bin (max size: 1807300)
2022-04-08T10:34:04.2331602Z 2022-04-08T10:34:04.134+0000 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Creating new cache for fileHashes, path /home/runner/work/app-android/app-android/.gradle/7.4.1/fileHashes/fileHashes.bin, access org.gradle.cache.internal.DefaultCacheAccess@10afd1f2
2022-04-08T10:34:04.2333297Z 2022-04-08T10:34:04.134+0000 [DEBUG] [org.gradle.cache.internal.DefaultInMemoryCacheDecoratorFactory] Creating in-memory store for cache /home/runner/work/app-android/app-android/.gradle/7.4.1/fileHashes/fileHashes.bin (max size: 1807300)
2022-04-08T10:34:04.2336759Z 2022-04-08T10:34:04.134+0000 [DEBUG] [org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess] Acquiring file lock for file hash cache (/home/runner/work/app-android/app-android/.gradle/7.4.1/fileHashes)
2022-04-08T10:34:04.2337989Z 2022-04-08T10:34:04.135+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on file hash cache (/home/runner/work/app-android/app-android/.gradle/7.4.1/fileHashes).
2022-04-08T10:34:04.2339318Z 2022-04-08T10:34:04.135+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on file hash cache (/home/runner/work/app-android/app-android/.gradle/7.4.1/fileHashes).
2022-04-08T10:34:04.2340940Z 2022-04-08T10:34:04.136+0000 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Creating new cache for resourceHashesCache, path /home/runner/work/app-android/app-android/.gradle/7.4.1/fileHashes/resourceHashesCache.bin, access org.gradle.cache.internal.DefaultCacheAccess@10afd1f2
2022-04-08T10:34:04.2342574Z 2022-04-08T10:34:04.136+0000 [DEBUG] [org.gradle.cache.internal.DefaultInMemoryCacheDecoratorFactory] Creating in-memory store for cache /home/runner/work/app-android/app-android/.gradle/7.4.1/fileHashes/resourceHashesCache.bin (max size: 3614700)
2022-04-08T10:34:04.4330922Z 2022-04-08T10:34:04.337+0000 [DEBUG] [org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess] Acquiring file lock for Configuration Cache (/home/runner/work/app-android/app-android/.gradle/configuration-cache)
2022-04-08T10:34:04.4335577Z 2022-04-08T10:34:04.338+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on Configuration Cache (/home/runner/work/app-android/app-android/.gradle/configuration-cache).
2022-04-08T10:34:04.4337333Z 2022-04-08T10:34:04.338+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on Configuration Cache (/home/runner/work/app-android/app-android/.gradle/configuration-cache).
2022-04-08T10:34:04.4338669Z 2022-04-08T10:34:04.390+0000 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Creating new cache for md5-checksums, path /home/runner/work/app-android/app-android/.gradle/7.4.1/checksums/md5-checksums.bin, access org.gradle.cache.internal.DefaultCacheAccess@32db939b
2022-04-08T10:34:04.4340196Z 2022-04-08T10:34:04.391+0000 [DEBUG] [org.gradle.cache.internal.DefaultInMemoryCacheDecoratorFactory] Creating in-memory store for cache /home/runner/work/app-android/app-android/.gradle/7.4.1/checksums/md5-checksums.bin (max size: 4500)
2022-04-08T10:34:04.4341600Z 2022-04-08T10:34:04.391+0000 [DEBUG] [org.gradle.cache.internal.LockOnDemandCrossProcessCacheAccess] Acquiring file lock for checksums cache (/home/runner/work/app-android/app-android/.gradle/7.4.1/checksums)
2022-04-08T10:34:04.4342974Z 2022-04-08T10:34:04.391+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire exclusive lock on checksums cache (/home/runner/work/app-android/app-android/.gradle/7.4.1/checksums).
2022-04-08T10:34:04.4344358Z 2022-04-08T10:34:04.391+0000 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired on checksums cache (/home/runner/work/app-android/app-android/.gradle/7.4.1/checksums).
2022-04-08T10:34:04.4346003Z 2022-04-08T10:34:04.391+0000 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Creating new cache for sha1-checksums, path /home/runner/work/app-android/app-android/.gradle/7.4.1/checksums/sha1-checksums.bin, access org.gradle.cache.internal.DefaultCacheAccess@32db939b
2022-04-08T10:34:04.4347390Z 2022-04-08T10:34:04.391+0000 [DEBUG] [org.gradle.cache.internal.DefaultInMemoryCacheDecoratorFactory] Creating in-memory store for cache /home/runner/work/app-android/app-android/.gradle/7.4.1/checksums/sha1-checksums.bin (max size: 4500)
2022-04-08T10:34:04.4348959Z 2022-04-08T10:34:04.392+0000 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Creating new cache for sha256-checksums, path /home/runner/work/app-android/app-android/.gradle/7.4.1/checksums/sha256-checksums.bin, access org.gradle.cache.internal.DefaultCacheAccess@32db939b
2022-04-08T10:34:04.4350316Z 2022-04-08T10:34:04.392+0000 [DEBUG] [org.gradle.cache.internal.DefaultInMemoryCacheDecoratorFactory] Creating in-memory store for cache /home/runner/work/app-android/app-android/.gradle/7.4.1/checksums/sha256-checksums.bin (max size: 4500)
2022-04-08T10:34:04.4352408Z 2022-04-08T10:34:04.392+0000 [DEBUG] [org.gradle.cache.internal.DefaultCacheAccess] Creating new cache for sha512-checksums, path /home/runner/work/app-android/app-android/.gradle/7.4.1/checksums/sha512-checksums.bin, access org.gradle.cache.internal.DefaultCacheAccess@32db939b
2022-04-08T10:34:04.4353976Z 2022-04-08T10:34:04.392+0000 [DEBUG] [org.gradle.cache.internal.DefaultInMemoryCacheDecoratorFactory] Creating in-memory store for cache /home/runner/work/app-android/app-android/.gradle/7.4.1/checksums/sha512-checksums.bin (max size: 4500)
2022-04-08T10:34:04.6331892Z 2022-04-08T10:34:04.538+0000 [DEBUG] [org.gradle.cache.internal.btree.BTreePersistentIndexedCache] Opening cache file-access.bin (/home/runner/.gradle/caches/journal-1/file-access.bin)
2022-04-08T10:34:04.6333397Z 2022-04-08T10:34:04.559+0000 [DEBUG] [org.gradle.initialization.DefaultGradlePropertiesLoader] Found env project properties: []
2022-04-08T10:34:04.6334534Z 2022-04-08T10:34:04.559+0000 [DEBUG] [org.gradle.initialization.DefaultGradlePropertiesLoader] Found system project properties: []
2022-04-08T10:34:04.6335671Z 2022-04-08T10:34:04.595+0000 [DEBUG] [org.gradle.cache.internal.btree.BTreePersistentIndexedCache] Opening cache fileHashes.bin (/home/runner/work/app-android/app-android/.gradle/7.4.1/fileHashes/fileHashes.bin)
2022-04-08T10:34:04.6336844Z 2022-04-08T10:34:04.612+0000 [LIFECYCLE] [org.gradle.configurationcache.DefaultConfigurationCache] Calculating task graph as configuration cache cannot be reused because the set of Gradle properties has changed.

@ribafish To determine the property at fault, your best bet would be to add a call to the properties task (or some other mechanism to print all Gradle properties )and compare what's changing between invocations.
This looks to be a workflow configuration issue, and not a problem with save/restore of Gradle User Home. I'm going to close this issue but please open a new issue:

Here if you find the gradle-build-action is adding a property that changes on each invocation
In https://github.com/gradle/gradle/issues if you think Gradle isn't handling things correctly.

Oops. Of course this issue needs to stay open, since it's a legitimate problem when using arguments that include org.gradle.jvmargs=....

I'm going to close this issue. There is a simple workaround: use a separate gradle-build-action step to "Setup Gradle" and then use a shell action to execute Gradle. This is the recommended configuration: https://github.com/gradle/gradle-build-action#use-the-action-to-setup-gradle.


Migrate to Swift 4.2 ?

Will do! Sorry I've been slow to do this, completely forgot 😅

no worries !
Huge thanks for making this skeleton animation 👍  !

On it! 🏃

Resolved! 0.3.0 ✨


Fix resumption token used in REST APIs

#1735
Checklist

[x] the [contributor license agreement][] is signed
[x] commit message follows [commit guidelines][]
[ ] tests are included
[x] screenshots are included showing significant UI changes
[ ] documentation is changed or added

Description of change
Fixed the resumption token used in some REST APIs.
The testing environment for below screenshots has 5 items totally.
First request with initial resumption token being 0:2. The length specified in params is ignored.

Second request with the token returned from last request

Third request with the token returned from last request. No more token is returned.

Another request with an initial token which can retrieve all items so no token returned.

Another request with an invalid token. So use the length from query params instead.

Considering the last commit has just one minor change and builds for  previous commit were all green, so merge this PR without waiting for green builds.


Communication issues with microcontroller - Loko Air

Hi,
Having assembled a couple of Air's, I was now messing with trying to see if I could get the microcontroller to respond to some AT commands, but I'm having little success. The serial port is identified without issues, but that is all I'm getting. No response to AT.
I know this may be a little scarse information, but I'm not seeing from which end I should start troubleshooting more in depth.
Would you be able to help?
Thanks in advance.

@tyagodani
after firmware installation,  connect to PC via USB , ( Note: USB C connector is not mirrored,  it means USB C connector will work only in one position).   Then use Putty to connect to serial , and on successful connection Loko will print data to terminal

Hi Tomi,
I had already noticed the USB connector not being mirrored, as it was only recognized in one orientation. That is sorted.
I have tried with Putty and also Arduino IDE. I'm not getting a response from the microcontroller. I took some measurements to see if there was any issue with power being fed to it and discovered I needed to have the battery already connected, as with USB only, only about 1,74V were being delivered to the controller. Now it's right at 3V.
I've also verified the serial drivers and everything looks OK.
This is the only thing Putty displays when attempting to connect:

@tyagodani  if the firmware successfully uploaded ,( re-read the microcontroller to see if it is written )  . then  look for IC1 , it is serial- USB converter, check its soldering .

@tomipiriyev I figured out that you write the firmaware with STM32CubeProgrammer. However, I'm still facing the same issue where I can see the serial converter from my computer, but it can't communicate with the microcontroller. I've checked the soldering and it looks fine (it came soldered from JLCPCB). All 3 units I have assembled are showing the exact same behaviour.
Any furrther ideas of what might be the issue?

These are the configs I'm using:

@tyagodani  yes , please use Cube programmer,   Why 9600 ?  change it to 11500.  STM32 comes in protected, need to first delete inside, and then you will be able to read stm32 memory, and then upload the firmware.  Also can you try to use P1 connector to connect to st-link .
Also sorry for my late reply , I am a little sick in these days .

@tomipiriyev no problem and thank you for your availability and patience. have a speedy recovery.
I've chnaged the baud rate to 115200 (guessing the 11500 you typed was a mistake), but I'm getting the same. This is the list of available baud rates:

Connection logs:
12:44:01 : UR connection mode is defined with the HWrst reset mode   12:44:01 : RTS low   12:44:01 : DTR low   12:44:01 : Serial Port COM4 is successfully opened.   12:44:01 : Port configuration: parity = none, baudrate = 115200, data-bit = 8,                     stop-bit = 1.0, flow-control = off   12:44:03 : Timeout error occured while waiting for acknowledgement.   12:44:03 : Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again...

I am now sure that this is a hardware issue. I've tried this on 2 different Air's, one with and one without the battery, and the issue is the exact same.
Scenario 1: USB disconnected
VBAT = 2.84V
LoRa_Supply = 0.0V
Voc (bat_protection) to GND = -2.24V
Voc (bat_protection) to GND_BAT = 0.0V
Scenario 2: USB connected
VBAT = 2.84V
LoRa_Supply = 1.73V
Voc (U5) to GND = -2.24V
Voc (U5) to GND_BAT = 0.0V
Vod (U5) to GND = 1.73V
Vod (U5) to GND_BAT = 2.81V
I've double and tripple checked the component orientation, soldering and continuity between the USB connector, U5, Q7, U8 and U1.
Do you have any idea on what else I should check to try to find the underlying issue?
Thank you a lot for your time.

@tyagodani  battery below 3v battery protection will disconnect the battery, it is empty.
voltage is low on Lora_Supply ,  can you show picture of your connection to ST-link please

@tomipiriyev I will attempt to charge the battery externally. But shouldn't the microcontroller be receiving the correct voltage when USB is connected?
I don't have an ST-Link programmer. Isn't it possible to program over USB?

@tyagodani STM32 microcontroller pins are not set as default to use for USB , so in first time, it needs to be programmed with st-link programmer.
When the button is pressed MCU Should be powered with 3v ,

@tomipiriyev
"When the button is pressed MCU Should be powered with 3v"
This even without programming the MCU, correct?

@tyagodani  "When the button is pressed MCU Should be powered with 3v" this is not correct, my mistake .
you should have 3v when it is powered from usb +battery .     but battery should be over 3v , please first charge the battery and then test .

@tomipiriyev tested now with a charged battery and the results seem to be better!
The MCU is now receiving the propper voltage and the battery is charging via the Loko.
Over serial, I am getting the following (baud rate at 115200):
UART-BL v1.0.0
CCCCCCCCCCCCCCC

@tomipiriyev got the ST-Link and managed to connect to the MCU. however, I'm getting data read failed error.
Already verified all pins are connected corrrectly to P1, including the NRST. I'm unable to erase the chip, but can see its details:

Error:
01:16:45 : STM32CubeProgrammer API v2.13.0 | Windows-64Bits    01:16:54 : UR connection mode is defined with the HWrst reset mode   01:16:54 : ST-LINK SN  :<PHONE_NUMBER>00004E4B52524E   01:16:54 : ST-LINK FW  : V2J43S7   01:16:54 : Board       : --   01:16:54 : Voltage     : 3.29V   01:16:54 : SWD freq    : 4000 KHz   01:16:54 : Connect mode: Normal   01:16:54 : Reset mode  : Hardware reset   01:16:54 : Device ID   : 0x497   01:16:54 : Revision ID : Rev Y   01:16:55 : UPLOADING OPTION BYTES DATA ...   01:16:55 :   Bank          : 0x00   01:16:55 :   Address       : 0x58004020   01:16:55 :   Size          : 96 Bytes   01:16:55 :   Bank          : 0x01   01:16:55 :   Address       : 0x58004080   01:16:55 :   Size          : 8 Bytes   01:16:55 : UPLOADING ...   01:16:55 :   Size          : 1024 Bytes   01:16:55 :   Address       : 0x8000000   01:16:55 : Read progress:   01:16:55 : Error: Data read failed

@tyagodani  can you please share more photo from  stmprogrammer screen shout, and hardware connection

@tomipiriyev it may be a little hard to see on the photos, but:
yellow: 3.3V
green: GND
white: RST
orange: SWDIO
blue: SWCLK

@tyagodani  if you supply the voltage from the st-link programmer , remove the battery .  then try . it should work.  I do the same setup as you, only I use different type st-link programmer. never tried with the one that you use.

@tomipiriyev I have tried both with and without the battery installed.
May I ask what version of the ST programmer software you are using?
Cheers

@tyagodani  day after tomorrow I will set up the exact same configuration with yours , so we can go over it .  I use STM32CubeProgrammer v2.10.0  on Mac  ( the st-link programmer you use might be the issue, not sure, in internet I can see that some other people having similar issue )

@tomipiriyev so, at long last, I've managed to resolve the data reading error. It wasn't the programmer, but rather one of the Read Out Protection parameters on the software.
For anyone reading this in the future and facing a similar issue, this is what I did to resolve the issue (props to this post on the Seeed Studio forums: https://forum.seeedstudio.com/t/how-to-program-a-lora-e5/257491):
Initially connect using the following configuration:

The "data read failed" pop-up will show. Dismiss it. The software should remain connected to the MCU. Check on the bottom right corner for the "Target information" fields to be populated like this:

On the hamburger menu on the left, select "Option bytes":

Under "Read Out Protection", change the "RDP" parameter value from "BB" to "AA" and hit "Apply":

After a few seconds, a bunch of errors like these will appear, but fear not:

Now just simply unplug the programmer from the computer, plug it back in and you can connect in Normal Mode successfully.

@tyagodani  you have mentioned that you ordered assembled units from JLC,  if it is not secret. how much it cost to order full assembled board from JLC?

@tyagodani you have mentioned that you ordered assembled units from JLC, if it is not secret. how much it cost to order full assembled board from JLC?

@tomipiriyev I did not get all components assembled by JLC, as they did not have them all available. The GPS sensor, diodes Q1 and Q2, the MCU and USB connector I had to source from different places and soldered them myself.
Nonetheless, the total for 5 boards was ~115€ + Shipping + Tax + the other components I mentioned were missing. Higher quantity orders will equate to a much better per unit price. For example, 20 boards only cost ~198€ at the time (9,90€ vs 23,00€ per board).

@tomipiriyev regarding the configuration tool, I'm assuming you only uploaded the MacOS version, correct?


text files

Where can i find the text files ?

I moved the text resources from the binaries directory.
You can now find the text resources here.


Reduce spammy logging for object store failed opens

Do not log all failed attempts. Instead, set the exception message.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-PR-Builder/10958/
Test PASSed.

@madanadit Can you please take a look?

alluxio-bot, merge this please.

alluxio-bot, cherry-pick this to branch-2.3 please.


Bundlephobia error

https://bundlephobia.com/result?p=defi
Some deps are missing.
Would be nice to get rid of babel runtime too?

@dy weird, these files are there, I've double checked (I even made some dummy releases). It looks like a bug at bundlephobia or something else I don't understand. Do you have any ideas?

Would be nice to get rid of babel runtime too?

Defi.js is uses features provided by Babel and they require the runtime as a JS library which needs to be included for any CJS environment.

@dy OK, I see the issue, fixing.

Fixed, my bad.

Thanks @finom!


Test with coverage

Run the tests on Travis with coverage
Submit coverage report to coveralls
Add coveralls coverage % badge to README.

I think this will be useful for evaluating tests for new features and improving the test suite overall.
@codelucas you can enable the coveralls builds here: https://coveralls.io/repos/new
The badge will look like this:
There's also an option to leave coveralls out and show a text version of the coverage report in travis.

:+1:

I'll enable them, this looks good to me!

@codelucas great, just need to enable coveralls for the badge to work.


Develop

Engineers Checklist
What this PR does?

List of updates for features, enhancements, or bugfixes

How can it be tested?

Please provide step-by-step guide on how to test
If web or mobile, screenshots will be very helpful in addition

Where is it documented?

List JIRA tickets

Backend Updates

[ ] Updated Postman Documentation

[ ] Requests
[ ] Examples
[ ] Tests

[ ] Updated Tasks on JIRA
[ ] Tested API updates in dev environment
[ ] CI Checks Passed

Implemented changes to the media query.


bigint: Failed to load bindings

After scaffolding a new app, initializing and starting the server, I notice this notification in my server logs:
bigint: Failed to load bindings, pure JS will be used (try npm run rebuild?)
This isn't the first time I've encountered this. I see it in all my projects that use the wallet-adapter.
It's not breaking anything. I assume it has some effect on performance.
I'm just curious what it is, where it's coming from, and if it needs to be addressed?

It's a pretty harmless warning, it indicates that the bigint operations are less performant as they use the pure JS implementation instead of the native bindings.
As you already mentioned, it's related to one of our dependencies so not something we can fix here.
Btw, a better place to ask these questions is the Solana StackExchange. That way we keep this repo for issues with the create-solana-dapp cli.


tests: convert neutron to use gremlin builder

verify that neutron tests still pass

moved to tests-all-gremlin PR


I wonder if the code is different from the algorithm in origin paper？？ thanks

In paper ,
while not converged do

Update weights w by descending GRADw(w; alpha)
Update architecture alpha by descending GRADalpha(updated w; alpha)
Which means: when update weights ,the alpha is fixed. However in code below, when use momentum to update the weights,  all parameters model.parameters() including arch_parameters are updated, waiting to be confirmed ，thanks....

optimizer = torch.optim.SGD(
model.parameters(),
args.learning_rate,
momentum=args.momentum,
weight_decay=args.weight_decay)

From my understanding, arch_parameters are updated in architect.step() (line 206 of train_search.py in rnn).
The part that u wrote above does not affect arch_parameters.
Model.arch_parameters is defined at line 67 of model_search.py in rnn. It is not the same as the usual model.parameters in pytorch.

To add on,  you can get arch_parameters by model.weights (line 62 of model_search.py in rnn). It is defined with Variable. Variable is not registered to model.parameters().
Only nn.Module and nn.Parameter are registered to model.parameters(), which is then passed to the optimizer. That's why arch_parameters are not updated in the part u mentioned.

To add on, you can get arch_parameters by model.weights (line 62 of model_search.py in rnn). It is defined with Variable. Variable is not registered to model.parameters().
Only nn.Module and nn.Parameter are registered to model.parameters(), which is then passed to the optimizer. That's why arch_parameters are not updated in the part u mentioned.

Hello,
Are you sure that nn.Parameter are registered to model.parameters()?
I tried the following code:
import torch
import torch.nn as nn

class Hello(nn.Module):
  def __init__(self):
    super(Hello, self).__init__()
    self.layer = nn.Conv2d(3, 4, 1)
    self.alpha = nn.Parameter(1e-3*torch.randn(5))

model = Hello()
print(model.parameters)

the print information only includes conv2d, no alpha.
I'm not sure if there something I'm wrong.

@ShoufaChen
It should be "model.parameters()" not "model.parameters". However, I'm wondering what "model.parameters" are, since I can't find it in the official document and it only exists "model._parameters".
I've also tried to make a list of "nn.Parameter", and the list containing several "nn.Parameter" will not appear in "model.parameters()" either.

I'm wrong. the nn.Parameter are registered to model.parameters().
should print
model.parameters()

rather than 'model.parameter`


Optimot symbols layout

Following the AZERTY-fr and QWERTZ-de symbol layouts, Optimot support could be nice to have.
It’s unclear whether Optimot’s non-free license allows it or not, but we could use a random name (e.g. “Optimist”) to dodge the question.

fixed by #25


Trap for Docker images with encoded characters in their names.

We have found there to be a few Docker images in our registry with encoded characters in their names, like '/' encoded as "%2F".
This is causing issues when trying to do the API curls resulting in 404 errors.
It would be good if there was an option to skip these images without failing the migration.

Does the option for ERROR_ACTION=skip achieve what you're looking for?  That should skip over the image when pushing or pulling or retagging.


Reference Issues

When I bring this up, the test project does not seem to recognize the source generator.

Nevermind. I got it working.


Test Cases

To begin with

Liquidation: No shortfall

Insert our assertions in this test test vault liquidation @alexanderem49

Liquidation: Collateral sold debt not covered

Base test for this scenario shortfall @anilhelvaci

Liquidation: Unsold collateral

Base test for this one reinstate vault

Generic assertions

Check that no child node with auction start time's name created before the liquidation
Check that {timestamp}.vaults.preAuction values are correct before auction is completed
Check that {timestamp}.vaults.postAuction values are correct after auction is completed
Check that {timestamp}.auctionResult values are correct after auction is completed
Create snapshot of the storage node => documentStorageSchema

At this test 'refund to one of two loans' of ...

Edge Cases

Test coverage (unit test)
Done:

liquidation flow 1
liquidation flow 2a
liquidation flow 2b

ToDo:

no vaults are liquidated
force a promise rejection in:

E(auctionPF).getSchedules()
helper.makeLiquidationRecorderKits(timestamp)

force an error while distributing proceeds
assert that vaultId being recorded under liquidations correspond to the correct vaultId under vaults
test flow with more than one vaultManager

same collateral
different collateral

Side Tasks:

update tests names with something more descriptive.
the same for comments describing the tests

cc: @alexanderem49

ToDo:

Assure that all tests follow the same logic in its assertions

See flow 1 vs flow 2a and 2b

Unit test: multiple vaultManagers
The changes made in commit cc2651a5dbc0358fe310d6857bf9a8cba9b40504 of branch alex/develop provide the 2 vaultManagers for 2 different assets for the test test-jorge-
The assertions for the Vstorage behaviour is still WiP.
IMPORTANT: the changes made to the setupServices function was following the logic of make it work and not make it good.
So I advise to refactor the code so it does not break the other tests cases or generate conflicts when merging to other branch
cc: @alexanderem49


disabled docker container timeout

Docker container timeout is not compatible with the older Docker API. Removed it from the code

Coverage increased (+0.05%) to 46.278% when pulling a0602217d127669d55a0541ce96ec9fa49ccc10b on docker-fix into 8533aecc8ca2c573e00b272a525f9ac8bd8c9e56 on master.


fix: add $ to mangle regex and init improvements

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Update Service Bus service level readme

The page https://github.com/MicrosoftDocs/azure-docs-sdk-node/blob/c67e75cb905ec431387183157a82ca96fbedfa80/docs-ref-services/latest/service-bus.md powers the content in https://docs.microsoft.com/en-us/javascript/api/overview/azure/service-bus?view=azure-node-latest
This PR updates it to match with what is in the azure-sdk-for-js repo for Service Bus i.e. https://github.com/azure/azure-sdk-for-js/blob/master/sdk/servicebus/README.md

Docs Build status updates of commit 92f971f:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/latest/service-bus.md
:warning:Warning
View (azure-node-latest)
Details

docs-ref-services/latest/service-bus.md

Line 2, Column 1: [Warning-ms-prod-and-service] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 10, Column 16: [Warning-ms-prod-technology-invalid] Invalid value for 'ms.technology': 'azure' is not valid with 'ms.prod' value 'azure'.
Line 12, Column 13: [Warning-ms-service-subservice-invalid] Invalid value for 'ms.service': 'Service Bus'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit cae3550:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/latest/service-bus.md
:warning:Warning
View (azure-node-latest)
Details

docs-ref-services/latest/service-bus.md

Line 2, Column 1: [Warning-ms-prod-and-service] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 10, Column 16: [Warning-ms-prod-technology-invalid] Invalid value for 'ms.technology': 'azure' is not valid with 'ms.prod' value 'azure'.
Line 12, Column 13: [Warning-ms-service-subservice-invalid] Invalid value for 'ms.service': 'Service Bus'.
Line 45, Column 1: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/javascript/api/@azure/service-bus/?view=azure-node-legacy' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 53, Column 1: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/javascript/api/azure-sb/?view=azure-node-legacy' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 45, Column 1: [Suggestion-preserve-view-not-set] Did you mean to link to a specific version? If so, add &preserve-view=true to the URL: https://docs.microsoft.com/en-us/javascript/api/@azure/service-bus/?view=azure-node-legacy
Line 53, Column 1: [Suggestion-preserve-view-not-set] Did you mean to link to a specific version? If so, add &preserve-view=true to the URL: https://docs.microsoft.com/en-us/javascript/api/azure-sb/?view=azure-node-legacy

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit cae3550:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-services/latest/service-bus.md
:warning:Warning
View (azure-node-latest)
Details

docs-ref-services/latest/service-bus.md

Line 2, Column 1: [Warning-ms-prod-and-service] Only one of the following attributes can exist: 'ms.prod', 'ms.service'. Use ms.prod for on-premise products, or ms.service for cloud services.
Line 10, Column 16: [Warning-ms-prod-technology-invalid] Invalid value for 'ms.technology': 'azure' is not valid with 'ms.prod' value 'azure'.
Line 12, Column 13: [Warning-ms-service-subservice-invalid] Invalid value for 'ms.service': 'Service Bus'.
Line 45, Column 1: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/javascript/api/@azure/service-bus/?view=azure-node-legacy' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 53, Column 1: [Warning-hard-coded-locale] Link 'https://docs.microsoft.com/en-us/javascript/api/azure-sb/?view=azure-node-legacy' contains locale code 'en-us'. For localizability, remove 'en-us' from links to most Microsoft sites.
Line 45, Column 1: [Suggestion-preserve-view-not-set] Did you mean to link to a specific version? If so, add &preserve-view=true to the URL: https://docs.microsoft.com/en-us/javascript/api/@azure/service-bus/?view=azure-node-legacy
Line 53, Column 1: [Suggestion-preserve-view-not-set] Did you mean to link to a specific version? If so, add &preserve-view=true to the URL: https://docs.microsoft.com/en-us/javascript/api/azure-sb/?view=azure-node-legacy

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Fix overflow text of the "How to apply to job" input field when a job is previewed

In the process of posting a job, in the "How to apply field" when the content exceeds a certain limit of characters, there is an overflow that happens when the job is previewed. See image below.
How ever, when the btn is hovered the overflow dies not happen are

I fixed this at 300 characters on the PR => https://github.com/osscameroon/jobsika/pull/442


Create layout for classifier model editor

Description
The basic layout of the classifier model editor has been added. Additionally, the <ModelEditor /> component is extensible as it renders the type of editor based on the URL params.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

How Has This Been Tested?
Clicked on the Create New Model button which opened up the model editor.
Test Configuration:
Layout of the model editor:

Checklist:

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

Hi @laksh22,
Can you please update some more designs on how this component is going to turn out after all the changes?

@ivantha Sure, I have added the new mockups to issue #425. You can find it under the See UI mockups section

@ivantha Are the UI mockups alright?

@ivantha Are the UI mockups alright?

Yes they are. I am sorry about the delay in reviewing this 🙂


 Will need to dig into it later.
Analyzing contract: contracts/contracts/crytic/PropertiesOUSDTransferable.sol:PropertiesOUSDTransferable
crytic_approve_overwrites: passed! 🎉
crytic_self_transferFrom_to_other_ERC20PropertiesTransferable: failed!💥
Call sequence:
initialize("&\214&4#\216)?P1\170\141\254\162.\227\142\153BiZ\209\DC3\vqC9)\NAK\ETX\212$","\251\f\b\251\139x\n]$!\249\207_______\205\194\239\128p\SYN\255",0xf17f52151ebef6c7334fad080c5704d77216b732) from: 0x627306090abab3a6e1400e9345bc60c78a8bef57
mint(0xf17f52151ebef6c7334fad080c5704d77216b732,6) from: 0xf17f52151ebef6c7334fad080c5704d77216b732 Time delay: 363058 seconds Block delay: 6382
changeSupply(599290589) from: 0xf17f52151ebef6c7334fad080c5704d77216b732 Time delay: 40014 seconds Block delay: 39046
crytic_zero_always_empty_ERC20Properties: passed! 🎉
crytic_self_transfer_ERC20PropertiesTransferable: passed! 🎉
crytic_self_transferFrom_ERC20PropertiesTransferable: passed! 🎉
crytic_revert_transferFrom_to_zero_ERC20PropertiesTransferable: passed! 🎉
crytic_revert_transfer_to_user_ERC20PropertiesTransferable: passed! 🎉
crytic_revert_transfer_to_zero_ERC20PropertiesTransferable: passed! 🎉
crytic_transfer_to_other_ERC20PropertiesTransferable: failed!💥
Call sequence:
initialize("&\214&4#\216)?P1\170\141\254\162.\227\142\153BiZ\209\DC3\vqC9)\NAK\ETX\212$","\251\f\b\251\139x\n]$!\249\207_______\205\194\239\128p\SYN\255",0xf17f52151ebef6c7334fad080c5704d77216b732) from: 0x627306090abab3a6e1400e9345bc60c78a8bef57 Time delay: 411308 seconds Block delay: 14451
mint(0xf17f52151ebef6c7334fad080c5704d77216b732,6) from: 0xf17f52151ebef6c7334fad080c5704d77216b732 Time delay: 363058 seconds Block delay: 6382
changeSupply(599290589) from: 0xf17f52151ebef6c7334fad080c5704d77216b732
crytic_less_than_total_ERC20Properties: passed! 🎉
Unique instructions: 5450
Unique codehashes: 1
Seed:<PHONE_NUMBER>353822340

Here's my initial decoding of this. (I like to imagine Echidna as being a little dramatic at times.)

Start with three users, each having $113,427,455,640,312,821,154 OUSD.
Mint raw 6 coins to one user
BACKING STABLE COINGS ARE ALMOST GONE! ONLY BACKED NOW BY ONE BILLIONTH OF A CENT.
One user transfers one raw coin, aka one billionth billionth of a cent, to another.
One of the following properties does not hold:

balanceOf(sender) == starting_balance - 1)
balanceOf(receiver) >= 1)
the transfer succeeded

Now this makes all the sense in the world that this would fail, given that our rebase ratio has just been hammered flat by the backing coins going from $113,427,455,640,312,821,154 to something near zero in human scales.
The question I'm left with after reading the code is why this isn't happening every time echidna runs a couple hundred thousand tests. It may just be that it rarely ends up setting the supply to something truly low, since random uint256s cover a big range? Feels like I must be not understanding something somewhere.
The other side of this is that using such high initial balances for echidna may mask any problems going the opposite way, a normal supply massively increasing over the years.

Here's my initial decoding of this. (I like to imagine Echidna as being a little dramatic at times.)

Start with three users, each having $113,427,455,640,312,821,154 OUSD.
Mint raw 6 coins to one user
BACKING STABLE COINGS ARE ALMOST GONE! ONLY BACKED NOW BY ONE BILLIONTH OF A CENT.
One user transfers one raw coin, aka one billionth billionth of a cent, to another.
One of the following properties does not hold:

balanceOf(sender) == starting_balance - 1)
balanceOf(receiver) >= 1)
the transfer succeeded

Now this makes all the sense in the world that this would fail, given that our rebase ratio has just been hammered flat by the backing coins going from $113,427,455,640,312,821,154 to something near zero in human scales.
The question I'm left with after reading the code is why this isn't happening every time echidna runs a couple hundred thousand tests. It may just be that it rarely ends up setting the supply to something truly low, since random uint256s cover a big range? Feels like I must be not understanding something somewhere.
The other side of this is that using such high initial balances for echidna may mask any problems going the opposite way, a normal supply massively increasing over the years.

Switched too running tests giving everyone a starting balance of "10" for the joy of it. Got another failure in a different test.
crytic_self_transferFrom_to_other_ERC20PropertiesTransferable: failed!💥
Call sequence:
initialize("\NUL\202\195gZ'\248\197}\165\144\163\150\161\247\224\136\SI","{{(4\165\176<\244\161U",0x627306090abab3a6e1400e9345bc60c78a8bef57)
mint(0xf17f52151ebef6c7334fad080c5704d77216b732,2)
changeSupply(3)
OUSD doesn't seem to work well when the supply changes down to billionths of billionths of a cent.

Switched too running tests giving everyone a starting balance of "10" for the joy of it. Got another failure in a different test.
crytic_self_transferFrom_to_other_ERC20PropertiesTransferable: failed!💥
Call sequence:
initialize("\NUL\202\195gZ'\248\197}\165\144\163\150\161\247\224\136\SI","{{(4\165\176<\244\161U",0x627306090abab3a6e1400e9345bc60c78a8bef57)
mint(0xf17f52151ebef6c7334fad080c5704d77216b732,2)
changeSupply(3)
OUSD doesn't seem to work well when the supply changes down to billionths of billionths of a cent.

From a triage point of view, I don't think these results are an indication of a security vulnerability.
We may want to discuss:

if this is really not an issue
if we should alter our tests to avoid triggering this as a false positive

if we should alter our contract behavior in some way for exceptionally massive changes in supply.

From a triage point of view, I don't think these results are an indication of a security vulnerability.
We may want to discuss:

if this is really not an issue
if we should alter our tests to avoid triggering this as a false positive

if we should alter our contract behavior in some way for exceptionally massive changes in supply.

Here is another reproduction:
crytic_transfer_to_other_ERC20PropertiesTransferable: FAILED!

Call sequence, shrinking (2664/5000):
1.initialize("Governor::propose: proposal function information arity mismatch","\164:\v\173\173\173\173\173\173\173\1
2.mint(0xf17f52151ebef6c7334fad080c5704d77216b732,1524785992) from: 0xc5fdf4076b8f3a5357c5e395ab970b5b54098fef Time d
3.changeSupply(18) from: 0xc5fdf4076b8f3a5357c5e395ab970b5b54098fef Time delay: 496638 seconds Block delay: 19465

Here is another reproduction:
crytic_transfer_to_other_ERC20PropertiesTransferable: FAILED!

Call sequence, shrinking (2664/5000):
1.initialize("Governor::propose: proposal function information arity mismatch","\164:\v\173\173\173\173\173\173\173\1
2.mint(0xf17f52151ebef6c7334fad080c5704d77216b732,1524785992) from: 0xc5fdf4076b8f3a5357c5e395ab970b5b54098fef Time d
3.changeSupply(18) from: 0xc5fdf4076b8f3a5357c5e395ab970b5b54098fef Time delay: 496638 seconds Block delay: 19465

Another repro:

Another repro:


Describe how the admin password can be changed

I couldn't find it documented how to change the admin password via the CLI, I think it would be great to have this documented! :-)
Especially since the initial admin password is very trivial but there's already a change for that.

A snippet was added that appears in several places: https://openziti.github.io/search/?q=change+password


Alpine 3.3 reached EoL

Alpine 3.3 reached EoL a few months ago - https://en.wikipedia.org/wiki/Alpine_Linux#Version_history
nginx & rtmp module have had patches and ffmpeg has had a minor bump.
I don't expect any action this is purely for note/heads up. Thanks for the great docker repo, out of the handful I've dug into this one is top dollar. 👍

Ah, thanks for the heads up and the kind words! I'll look into updating this soon!

So I tried updating to the latest Alpine 3.7, but FFmpeg doesn't seem to build with the --enable-openssl flag. It's probably due to Alpine switching to libressl. It's similar to the issue reported here:
https://trac.ffmpeg.org/ticket/6580
So I can update Alpine to 3.4 (which still seems to be supported for a bit longer with openssl) and update to Alpine 3.7 once FFmpeg supports building with the --enable-libtls option.
Another option is to remove the --enable-openssl build flag. I'm not too sure on the scope on how this is used along with nginx-rtmp though.
Anyway, I'm updating this image to Alpine 3.4 soon, along with the version bumps from ffmpeg and nginx-vod-module. I'll add another ticket for Alpine 3.7.


Chat feature not available

VS Code Version:
Version: 1.78.2 (Universal)
Commit: b3e4e68a0bc097f0ae7907b217c1119af9e03435
Date: 2023-05-10T14:44:45.204Z (6 days ago)
Electron: 22.5.2
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 22.2.0
Sandboxed: No
OS Version:
Venture 13.1
Logs:

Steps to Reproduce:
Hello, I'm very excited to try Copilot Chat! However, I'm having trouble using it. I'm using VSc Code Insiders, and I've installed the Github Copilot Nightly Extension, but I don't see the chat icon in the activity panel. I confirmed that Copilot is connected by checking that autocomplete functionality works. I've tried restarting VS Code and my computer and that didn't work.
The screenshot below should show that 1. chat icon is missing 2. I have Github Copilot Nightly Installed and 3. Copilot is working (by completing my code).
Thanks for your help!

Can you switch to version 1.79.0 and give it a try?

Thanks for the quick response! Where can I find v1.79? Here it looks like it hasn't been released yet: https://code.visualstudio.com/updates/v1_79

Maybe if you look in the mailbox, there should be an address in the invitation email to download it.😁

I did follow the link :) It brought me here: https://code.visualstudio.com/insiders/ and I downloaded the most recent version. At the top of the page, I see a banner that says "Version 1.78 is now available! Read about the new features and fixes from April." That makes me think that 1.79 isn't publicly available yet.

Oh, I guess that misled you. But when I clicked Download, it was version 1.79.0.

I tried downloading it again and it worked! Not sure how I got the wrong version the first time, but it's working now, thanks so much for your help! :)

nice
------------------ 原始邮件 ------------------
发件人:                                                                                "microsoft/vscode-copilot-release"                                                                                @.>;
发送时间: 2023年5月17日(星期三) 中午1:44
@.>;
<EMAIL_ADDRESS>主题: Re: [microsoft/vscode-copilot-release] Chat feature not available (Issue #8)
I tried downloading it again and it worked! Not sure how I got the wrong version the first time, but it's working now, thanks so much for your help! :)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***>

I tried downloading it again and it worked! Not sure how I got the wrong version the first time, but it's working now, thanks so much for your help! :)

I second this, they somehow deployed the wrong build, and just re-downloading insiders worked


Dynamo decorder decodes value "TRUE" of type string to :true atom

Currently, the dynamo decoder is setup to decode string data types with a value of "TRUE" to the atom true upon deserialization.
That absolutely makes sense when the dynamo type is boolean but I'm not so sure if it makes sense when the dynamo data type is string. In the case of a string data type, it seems like more of a bandaid for those that are not using the proper types when the better solution would be to simply fix their types.
I'm dealing with stock market and "TRUE" is a valid ticker symbol.
The leads to strange behavior since, I cannot do this...
# Retrieve metadata
{:ok, %{"Item" => item}} = ExAws.Dynamo.get_item(table(), %{"symbol" => symbol})
metadata = ExAws.Dynamo.Decoder.decode(item, as: Metadata)

# Update metadata and save it back
new_metadata = update_metadata(metadata, new_data)
ExAws.Dynamo.put_item table(), new_metadata

Because the decode transforms the "TRUE" string into an atom, the put_item blows up with a validation exception since I'm now trying to save a boolean value into a key field which is a string field:
{:error, {"ValidationException", "One or more parameter values were invalid: Type mismatch for key symbol expected: S actual: BOOL"}}

It seems like it makes sense to remove these two cases from the decode function:
  def decode(%{"S" => "TRUE"}),     do: true
  def decode(%{"S" => "FALSE"}),    do: false

What do you think?

@stocks29 Just an FYI, @benwilson512 went and got himself married, so he'll be out for ~week on his honeymoon. I think your suggestion seems reasonable, but as this is his project, I'm going to leave the call to him -- so there will be a slight delay in this getting handled.

You're absolutely right, this is a left over thing from before Dynamo had a Boolean type. If I get bored at the airport or something I'll see if I can push a fix.

I should add that in the mean time that doing a custom implementation of the decoder and encoder protocols for your struct ought to allow you to override this behavior. I believe an example exists in the Dynamo tests.

Oh, nice! Congrats Ben! Enjoy your honeymoon!  :)

v0.3.0 Fixes this.


FastForward doesn't work with ckk.ai

Domain
ckk.ai
Link
https://ckk.ai/SH37wF
Version
0.0.0
What browsers are you seeing the problem on?
Chrome
What OS are you seeing the problem on?
Windows
Anything else?
The extension does nothing when entering this page. I have a special interest in bypassing this domain because I haven't found any way to get to the destination link manually (I get trapped in a maze of unavoidable ads).
Good luck fixing this, and thank you for making this extension!

yep same broken  on my side both tested from kiwi(mobile) and edge

same for me. I get redirected to Magybu.net.
Not sure if anyone else has this same problem

I guess crowdbypass is also down for this site

Still broken

Still broken.

Keeping this open because I have a MV3 bypass for this site, so I can just translate that to the mv2 version.

Damn, I didn't even notice that this site has been broken since at least August.

Any luck?

i believe crowd-bypass fixes this

i saw that too, just after i sent this. im not sure why thats happening, ill ask the other devs. we will go back to a local bypass in the mv3 build which is coming in a few weeks.

You can try out the (experimental) mv3 version here: https://nightly.link/FastForwardTeam/FastForward/workflows/main/manifest-v3

same for tii.la domain

Are we still waiting on the fabled mv3 1.0 release before FastForward actually starts working again? I was using it just fine like 6 months ago, but now my reason for installing this isn't functioning (crowd bypasses).

can we still use the mv2 version ?

Yes you can.


Unable to build Nuxt 3/Vite project

Describe the bug
I've been able to get a Nuxt 3/Vite project to build with @solana/web3.js and @solana/wallet-adapter-vue, but I'm unable to import a wallet from @solana/wallet-adapter-wallets.
I'm using import { getPhantomWallet } from '@solana/wallet-adapter-wallets' in my project, and the repro.
Originally this was breaking on the Ledger wallet, which I eventually got working, now I'm stuck on the Torus wallet.
With @toruslabs/eccrypto in optimizeDeps I get ReferenceError: Buffer is not defined, and without it in optimizeDeps (which I believe is necessary for Buffer to be shimmed) I get Uncaught SyntaxError: The requested module '/_nuxt/node_modules/@toruslabs/eccrypto/browser.js?v=31b23600' does not provide an export named 'decrypt'.
Is there a way I can import a single wallet without needing to deal with the CJS/ESM & Node built-in issues across every wallet?
To Reproduce
Minimal repro on CodeSandbox
Expected behavior
Ability to import wallets.
Desktop
OS X 10.15.7 / Chrome

Thanks for reporting this. I think it might be the same issue seen here: https://github.com/solana-labs/wallet-adapter/issues/153#issuecomment-968352050
I'm not familiar with Nuxt, but do you think it's related to server side rendering? Is there a way to specify which modules should be external / ignored?

I came across that issue at some stage but don't think it's related – SSR is disabled in my project and the repo, on line 78 of nuxt.config.js.

Got it working. For anyone following along at home, here are my settings. Fair warning: some of this may be unnecessary.
nuxt.config.js:
import { defineNuxtConfig } from 'nuxt3'

// https://v3.nuxtjs.org/docs/directory-structure/nuxt.config

import { Buffer } from 'buffer'
import inject from '@rollup/plugin-inject'
import Inspect from 'vite-plugin-inspect'

// https://github.com/vitejs/vite/discussions/2785

export default defineNuxtConfig({
  meta: {
    meta: [
      { name: 'viewport', content: 'width=device-width, initial-scale=1' }
    ],
  },
  buildModules: [
    'nuxt-windicss',
  ],
  vite: {
    resolve: {
      alias: { '@ledgerhq/devices/lib': '@ledgerhq/devices/lib-es' },
      dedupe: ["secp256k1", "bn.js"]
    },
    define: {
      "global": {},
      "process.env.NODE_DEBUG": JSON.stringify("")
    },
    plugins: [
      inject({
        Buffer: ['buffer', 'Buffer']
      }),
      Inspect(),
    ],
    optimizeDeps: {
      include: [
<EMAIL_ADDRESS><EMAIL_ADDRESS>> bn.js',
<EMAIL_ADDRESS>> borsh',
<EMAIL_ADDRESS>> buffer',
        'js-sha3',
        'secp256k1',
        'jayson',
        'rpc-websockets',
        '@solana/buffer-layout',
        'borsh',
        'tweetnacl',
        'buffer',
        'eventemitter3',
        '@blocto/sdk',
        'bs58',
        'events',
        'semver',
        'base64url',
        'keccak',
        'randombytes',
        'readable-stream',
        'end-of-stream',
        'once',
        'pump',
        'fast-safe-stringify',
        'lodash.merge',
        '@toruslabs/eccrypto',
        '@toruslabs/http-helpers',
        '@toruslabs/tweetnacl-js',
        '@solana/wallet-adapter-vue',
        'util'
      ],
    },
  },
  build: {
    transpile: [
      '@blocto/sdk',
      '@project-serum/sol-wallet-adapter',
      '@solana/wallet-adapter-base',
      '@solana/wallet-adapter-bitkeep',
      '@solana/wallet-adapter-bitpie',
      '@solana/wallet-adapter-blocto',
      '@solana/wallet-adapter-clover',
      '@solana/wallet-adapter-coin98',
      '@solana/wallet-adapter-coinhub',
      '@solana/wallet-adapter-ledger',
      '@solana/wallet-adapter-mathwallet',
      '@solana/wallet-adapter-phantom',
      '@solana/wallet-adapter-safepal',
      '@solana/wallet-adapter-slope',
      '@solana/wallet-adapter-solflare',
      '@solana/wallet-adapter-sollet',
      '@solana/wallet-adapter-solong',
      '@solana/wallet-adapter-torus',
      '@solana/wallet-adapter-vue',
      '@solana/wallet-adapter-vue-ui',
      '@solana/wallet-adapter-walletconnect',
      '@solana/wallet-adapter-wallets',
<EMAIL_ADDRESS>    ],
  },
  ssr: false
})

tsconfig.json:
{
  // https://v3.nuxtjs.org/concepts/typescript
  "extends": "./.nuxt/tsconfig.json",
  "compilerOptions": {
    "isolatedModules": true,
    "esModuleInterop": true
  }
}

@timhanlon 's settings worked in my Vue but non-nuxt project. I stripped it down, and this is the bare minimum I needed to get things to work:
vite.config.js
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import inject from '@rollup/plugin-inject'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    vue(),
    inject({
      Buffer: ['buffer', 'Buffer']
    }),
  ],
  define: {
    "global": {},
    "process.env.NODE_DEBUG": JSON.stringify("")
  },
  optimizeDeps: {
    include: [
      'buffer',
    ]
  },
})

@0xzachvai Awesome – what version of Vite are you using?

@timhanlon vite --version outputs: vite/2.4.2 linux-x64 node-v16.7.0


GH-1587: Don't Correct TX Offsets After Seek(s)

Resolves https://github.com/spring-projects/spring-kafka/issues/1587
We should not advance the consumer partition if Seek operations have been
performed; skip fixing the offsets if that condition is detected.
Capture the positions after the poll and check during the fix operation.
This is difficult to write a unit test for; tested with a Boot application,
observing the correct behavior via DEBUG logs.
cherry-pick to 2.5.x

... and cherry-picked to 2.5.x


Names vocabulary shouldn't overwrite existing data

Is your feature request related to a problem? Please describe.
In our use case, we're automatically populating metadata from CrossRef and then enhancing metadata in the deposit form. Currently existing metadata in the creators field, like a name, that is replaced when you use the "Search for persons" functionality. This is problematic when you want to retain the published name form for an article, but enhance the name with additional metadata from the vocabulary such as identifiers or affiliations.
Describe the solution you'd like
The "Search for persons" box should only add new metadata, not replace existing metadata in the modal.

After discussion, 2 possible options:

harmonize the behaviour of the widget to always fill in the missing info when selecting from a vocabulary, and don't overwrite existing input
or, if not a viable solution for everyone, make this behaviour configurable, via config/props


k_is_in_isr() returns false inside "direct" interrupts on several arches

This affects at least x86, Nios II, Xtensa, and Riscv32.
These arches detect whether we are in interrupt context by checking kernel.nested which gets incremented/decremented in the common IRQ entry/exit code. However direct interrupts bypass all the common IRQ code and hence this always returns false.

After discussing with @andyross we think this might be an acceptable caveat for direct interrupts.
I am considering altering the default fatal error policy to hang the system for any unhandled exception in supervisor mode.

Closing based on offline discussion.


Sentence does not make sense possible missing words

Repro steps:

Navigate to this page:
https://docs.microsoft.com/en-us/sharepoint/dev/general-development/build-sites-for-sharepoint
See the "The content-creation workflow is revised so that you can create content using any —and author great content." sentence

GH topic:
https://github.com/SharePoint/sp-dev-docs/blob/live/docs/general-development/build-sites-for-sharepoint.md
Actual results:
The sentence seems to be missing words therefore it does not make sense.
Expected results:
Missing words should be added so the sentence makes sense.

The text has been updated - https://github.com/SharePoint/sp-dev-docs/commit/872ae8761968cdab13bb872f5459221716923c33


Update handler name to match startAndXYZ convention

Additional minor cleanup, fix tests not shutting down correctly.

Maybe startServerAndCreateLambdaHandler? Otherwise it seems like start applies to lambda handler... Or something else?


Updated readme with steps to run locally

Thanks, Antall! I appreciate your help updating our documentation.


Remote Update (interactions): donovandmc/interactions-locale

@ErisPRUpdateBot erge

@ErisPRUpdateBot merge

Error Merging:

HttpError: Pull Request is not mergeable
at /app/node_modules/@octokit/request/dist-src/fetch-wrapper.js:68:27
at runMicrotasks ()
at processTicksAndRejections (node:internal/process/task_queues:96:5)
at /src/sites/yiff.rest/routes/eris-pr-merge.ts:26:3
at async Promise.all (index 0)
at middleware (/app/node_modules/@octokit/webhooks/dist-src/middleware/node/middleware.js:51:9)

oh wait


Rename seq to str; updates docs and paper

This updates the code to use str instead of seq.
Updates the doc strings in the code and in the paper to use string and language instead of sequence and set of sequences. Apologies for typos.
Line 21 of the paper still talks about sequence because I couldn't decide what to change it to. Can you help Walter?

This is such a tedious, but BIG step in the right direction. Thank you so much.

Thanks - I'll merge this then. I'll have a think about the paper drafting.