3-hour (!) delay before starting a step in a Windows environment

Description
On this public repo, a workflow has completed without issue on Ubuntu and macOS environments, but experiences a 3-hour delay on Windows for no apparent reason. This behaviour is evident across two separate runs of the workflow.
A three-hour delay for no reason appears to be a bug.
Virtual environments affected

[ ] Ubuntu 16.04
[ ] Ubuntu 18.04
[ ] Ubuntu 20.04
[ ] macOS 10.15
[ ] macOS 11
[ ] Windows Server 2016
[X] Windows Server 2019
[ ] Windows Server 2022

Image version and build link

Example 1
Example 2

The builds didn't fail, but they just took 3+ hours to complete for the Windows environments (well under 5 minutes for Ubuntu and macOS environments).
Is it regression?
No response
Expected behavior
Expected the Windows builds to complete within minutes, not hours.
Actual behavior
The 3-hour delay happens at the beginning of a particular step: Here's the debug log output from one of the examples.
Thu, 16 Sep 2021 13:59:18 GMT ##[debug]Evaluating condition for step: 'Test Kotlin/Java'
Thu, 16 Sep 2021 13:59:18 GMT ##[debug]Evaluating: success()
Thu, 16 Sep 2021 13:59:18 GMT ##[debug]Evaluating success:
Thu, 16 Sep 2021 13:59:18 GMT ##[debug]=> true
Thu, 16 Sep 2021 13:59:18 GMT ##[debug]Result: true
Thu, 16 Sep 2021 13:59:18 GMT ##[debug]Starting: Test Kotlin/Java
Thu, 16 Sep 2021 13:59:18 GMT ##[debug]Loading inputs
Thu, 16 Sep 2021 13:59:18 GMT ##[debug]Loading env
Thu, 16 Sep 2021 13:59:18 GMT Run python3 test_all.py jvm
Thu, 16 Sep 2021 13:59:18 GMT   python3 test_all.py jvm
Thu, 16 Sep 2021 13:59:18 GMT   shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"
Thu, 16 Sep 2021 13:59:18 GMT   env:
Thu, 16 Sep 2021 13:59:18 GMT     pythonLocation: C:\hostedtoolcache\windows\Python\3.9.7\x64
Thu, 16 Sep 2021 13:59:18 GMT     JAVA_HOME: C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64
Thu, 16 Sep 2021 13:59:18 GMT     DC: dmd
Thu, 16 Sep 2021 13:59:18 GMT     GOROOT: C:\hostedtoolcache\windows\go\1.17.1\x64
Thu, 16 Sep 2021 13:59:18 GMT     TMPDIR: D:\a\_temp
Thu, 16 Sep 2021 13:59:18 GMT     HOME: C:\Users\runneradmin
Thu, 16 Sep 2021 13:59:18 GMT     MSYS2_PATH_TYPE: inherit
Thu, 16 Sep 2021 13:59:18 GMT     MAKE: make.exe
Thu, 16 Sep 2021 13:59:18 GMT     Path: C:\Users\runneradmin\go\bin;C:\hostedtoolcache\windows\go\1.17.1\x64\bin;C:\hostedtoolcache\windows\dc\dmd-2.097.2\x64\dmd2\windows\lib64;C:\hostedtoolcache\windows\dc\dmd-2.097.2\x64\dmd2\windows\bin;C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64\bin;C:\Users\runneradmin\AppData\Roaming\Python\Python39\Scripts;C:\hostedtoolcache\windows\Python\3.9.7\x64\Scripts;C:\hostedtoolcache\windows\Python\3.9.7\x64;C:\Users\runneradmin\.dotnet\tools;C:\Program Files\MongoDB\Server\5.0\bin;C:\aliyun-cli;C:\vcpkg;C:\cf-cli;C:\Program Files (x86)\NSIS\;C:\tools\zstd;C:\Program Files\Mercurial\;C:\hostedtoolcache\windows\stack\2.7.3\x64;C:\tools\ghc-9.0.1\bin;C:\Program Files\dotnet;C:\mysql\bin;C:\Program Files\R\R-4.1.1\bin\x64;C:\SeleniumWebDrivers\GeckoDriver;C:\Program Files (x86)\sbt\bin;C:\Rust\.cargo\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\Program Files (x86)\pipx_bin;C:\hostedtoolcache\windows\go\1.15.15\x64\bin;C:\hostedtoolcache\windows\Python\3.7.9\x64\Scripts;C:\hostedtoolcache\windows\Python\3.7.9\x64;C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.302-8\x64\bin;C:\npm\prefix;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\ProgramData\kind;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\ProgramData\Chocolatey\bin;C:\Program Files\Docker;C:\Program Files\PowerShell\7\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn\;C:\Program Files\nodejs\;C:\Program Files\OpenSSL\bin;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\OpenJDK\jdk-17\bin;C:\Program Files\CMake\bin;C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.2\bin;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Program Files\GVFS;c:\tools\php;C:\Program Files (x86)\sbt\bin;C:\SeleniumWebDrivers\ChromeDriver\;C:\SeleniumWebDrivers\EdgeDriver\;C:\Program Files\Amazon\AWSCLIV2\;C:\Program Files\Amazon\SessionManagerPlugin\bin\;C:\Program Files\Amazon\AWSSAMCLI\bin\;C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin;C:\Program Files (x86)\Microsoft BizTalk Server\;C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps
Thu, 16 Sep 2021 13:59:18 GMT     DOTNET_ROOT: C:\Users\runneradmin\AppData\Local\Microsoft\dotnet
Thu, 16 Sep 2021 13:59:18 GMT     PY_DEBUG: 1
Thu, 16 Sep 2021 13:59:18 GMT ##[debug]C:\Program Files\PowerShell\7\pwsh.EXE -command ". 'D:\a\_temp\8238135e-2f28-442e-92f1-907b6c37a0e8.ps1'"
Thu, 16 Sep 2021 17:10:18 GMT Running on Python (3, 9): C:\msys64\mingw64\bin\python3.exe
Thu, 16 Sep 2021 17:10:18 GMT Testing for Kotlin/Java ...
Thu, 16 Sep 2021 17:10:18 GMT Running 'gradle.exe run'
Thu, 16 Sep 2021 17:10:18 GMT ##[debug]Finishing: Test Kotlin/Java

Note the lines where the delay occurs:
Thu, 16 Sep 2021 13:59:18 GMT ##[debug]C:\Program Files\PowerShell\7\pwsh.EXE -command ". 'D:\a\_temp\8238135e-2f28-442e-92f1-907b6c37a0e8.ps1'"
Thu, 16 Sep 2021 17:10:18 GMT Running on Python (3, 9): C:\msys64\mingw64\bin\python3.exe

So, between the logging that a Powershell script is about to be run and the first sign of execution of that script, there's a 3-hour+ gap!
Repro steps
Just review the logs on the workflow examples linked above, for the windows-latest runs.

Hi @vsajip!
Looks like the issue is with the path that was changed after setup-ruby action, which leads to python being used from mingw64 instead of hostedtoolcache. We will take a look at it.

Hi @vsajip.
First of all, you should swap setup-ruby and setup-python steps so python will be executed from hostedtoolcache instead of mingw64.
Also it looks like there's some problem with calling gradle inside test_jvm test.
I tried to debug this a little in a forked repo. I changed out = run_command('%s run' % get_exe('gradle'), wd) to  os.chdir(wd) out = os.system('gradle run'). Now gradle build being executed and not suspending step.
Here are some results: https://github.com/shilovmaksim/cfgclient/runs/3687567508

I've moved the Python setup to the end of the setup steps - I can see how using the wrong Python interpreter would mess things up, but do you know why it would complete successfully, but just with a 3-hour delay? Seems very odd and IMO worth getting to the bottom of it.
Moving the Python setup causes some other failure (on Windows only!), but that might be in my script so I'll attend to that.
However, regarding the test_jvm logic, be aware that run_command(..., wd) ensure that wd is switched to be the current directory in the subprocess before it runs gradle run - that's how the subprocess.check_output() call works. So I'm not sure if there's any change which should be required there.

Another point: the first thing the Python script test_all.py does is to print the Python version and executable's path, like this:
Running on Python (3, 9): C:\hostedtoolcache\windows\Python\3.9.7\x64\python3.exe

That's before it's even decided to run Gradle, or whatever, based on the command line arguments.
So there should be little or no delay between the ##[debug]C:\Program Files\PowerShell\7\pwsh.EXE -command ... line in the log and the "Running on Python ..." line which is the first effective output from the script.
The latest workflow run is here, looks like it's hit that delay ... it's now running the correct Python interpreter, as seen from the earlier steps which have completed.

@vsajip we are not java and gradle experts, but we have managed to found that gradle daemon is not started on windows (maybe it is expected) and then we tried the following cases:

Run gradle run inside jvm directory — the daemon starts and the test passes
Run python3 test_all.py test_jvm after that — it passes since the daemon is launched
Change the line to out = run_command('%s run --no-daemon' % get_exe('gradle'), wd) and run in the CI — it passes https://github.com/shilovmaksim/cfgclient/runs/3689246835?check_suite_focus=true

So it looks like the root cause is gradle daemon initialization but unfortunately, we don't have enough experience to debug it further.

So it looks like the root cause is gradle daemon initialization

How can that be the reason, when the 3-hour delay occurs between the debug line indicating that the Powershell script for the step is about to run, and the first output from the step? That first output - the
Running on Python (3, 9): C:\hostedtoolcache\windows\Python\3.9.7\x64\python3.exe

line - occurs before the script has even decided to run Gradle. It is normal for the Gradle daemon to not be running initially, and it is autostarted by Gradle on the first run to speed up later runs. This is what happens when you invoke a Gradle task on a freshly booted machine:
$ gradle test
Starting a Gradle Daemon, 1 incompatible and 1 stopped Daemons could not be reused, use --status for details

There can be a longish delay when Gradle starts, but never hours.
Are the debug logging timestamps unreliable or incorrect? Otherwise it's hard to infer how a delay in a Gradle daemon could play into the delay seen, given that it apparently happens even before the script decides to run Gradle ... you don't need to know Java or Gradle to see that, just see what the Python test_all.py script is doing. Here's the portion of the script I'm talking about, annotated with some comments:
def main():

    # First output from script occurs here.
    # Delay has already happened by now, if the log timestamps are reliable.

    print('Running on Python %s: %s' % (sys.version_info[:2], sys.executable))

    # Parsing of command line arguments happens here

    adhf = argparse.ArgumentDefaultsHelpFormatter
    ap = argparse.ArgumentParser(formatter_class=adhf)
    aa = ap.add_argument
    aa('langs', metavar='LANG', nargs='*', type=lang,
       help='Language to run test for')
    options = ap.parse_args()
    options.all = not bool(options.langs)
    basedir = os.getcwd()

    # other cases omitted for brevity, as not relevant ... they all look like

    if options.all or 'foo' in options.langs:
        test_foo(basedir)

    # Decision to call test_jvm occurs here

    if options.all or 'jvm' in options.langs:

        # Call to `gradle run` occurs inside here

        test_jvm(basedir)

That workflow I linked earlier is still running (1 hr 43 mins + later) - perhaps you can look at it and work out what processes are running on there at the moment?

@vsajip the delay happens after python3 test_all.py test_jvm, not somewhere in between so I would call it a hang, not a delay. We tested the behavior in the VM in Azure created from this repository and the result is pretty the same — the command is stuck when the gradle daemon is not running.
It's not possible to connect to the VM with your run so we can't check the processes there, but on our VM that I mentioned above the python process is stuck waiting for something.
Have you tried the script locally on any windows machine?

I've made one more change by invoking gradle run --no-daemon, and it seems to complete without the delay. That's great, but I think there is still an issue for you to look at, in that the log timestamps don't seem to tie up with the true state of when events are occurring - the long delay, if caused by daemon startup, should show up after the first statement from the script, not before it. Here's the log from the run that completed in reasonable time:
Thu, 23 Sep 2021 16:14:30 GMT ##[debug]Evaluating condition for step: 'Test Kotlin/Java'
Thu, 23 Sep 2021 16:14:30 GMT ##[debug]Evaluating: success()
Thu, 23 Sep 2021 16:14:30 GMT ##[debug]Evaluating success:
Thu, 23 Sep 2021 16:14:30 GMT ##[debug]=> true
Thu, 23 Sep 2021 16:14:30 GMT ##[debug]Result: true
Thu, 23 Sep 2021 16:14:30 GMT ##[debug]Starting: Test Kotlin/Java
Thu, 23 Sep 2021 16:14:30 GMT ##[debug]Loading inputs
Thu, 23 Sep 2021 16:14:30 GMT ##[debug]Loading env
Thu, 23 Sep 2021 16:14:30 GMT
Run python3 test_all.py jvm
Thu, 23 Sep 2021 16:14:30 GMT   python3 test_all.py jvm
Thu, 23 Sep 2021 16:14:30 GMT   shell: C:\Program Files\PowerShell\7\pwsh.EXE -command ". '{0}'"
Thu, 23 Sep 2021 16:14:30 GMT   env:
Thu, 23 Sep 2021 16:14:30 GMT     JAVA_HOME: C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64
Thu, 23 Sep 2021 16:14:30 GMT     DC: dmd
Thu, 23 Sep 2021 16:14:30 GMT     GOROOT: C:\hostedtoolcache\windows\go\1.17.1\x64
Thu, 23 Sep 2021 16:14:30 GMT     TMPDIR: D:\a\_temp
Thu, 23 Sep 2021 16:14:30 GMT     HOME: C:\Users\runneradmin
Thu, 23 Sep 2021 16:14:30 GMT     MSYS2_PATH_TYPE: inherit
Thu, 23 Sep 2021 16:14:30 GMT     MAKE: make.exe
Thu, 23 Sep 2021 16:14:30 GMT     Path: C:\Users\runneradmin\go\bin;C:\hostedtoolcache\windows\go\1.17.1\x64\bin;C:\hostedtoolcache\windows\dc\dmd-2.097.2\x64\dmd2\windows\lib64;C:\hostedtoolcache\windows\dc\dmd-2.097.2\x64\dmd2\windows\bin;C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64\bin;C:\Users\runneradmin\.dotnet\tools;C:\Program Files\MongoDB\Server\5.0\bin;C:\aliyun-cli;C:\vcpkg;C:\cf-cli;C:\Program Files (x86)\NSIS\;C:\tools\zstd;C:\Program Files\Mercurial\;C:\hostedtoolcache\windows\stack\2.7.3\x64;C:\tools\ghc-9.0.1\bin;C:\Program Files\dotnet;C:\mysql\bin;C:\Program Files\R\R-4.1.1\bin\x64;C:\SeleniumWebDrivers\GeckoDriver;C:\Program Files (x86)\sbt\bin;C:\Rust\.cargo\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\Program Files (x86)\pipx_bin;C:\hostedtoolcache\windows\go\1.15.15\x64\bin;C:\hostedtoolcache\windows\Python\3.7.9\x64\Scripts;C:\hostedtoolcache\windows\Python\3.7.9\x64;C:\tools\kotlinc\bin;C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.302-8\x64\bin;C:\npm\prefix;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\ProgramData\kind;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\ProgramData\Chocolatey\bin;C:\Program Files\Docker;C:\Program Files\PowerShell\7\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\dotnet\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files (x86)\Windows Kits\10\Windows Performance Toolkit\;C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\120\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\130\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\;C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn\;C:\Program Files\nodejs\;C:\Program Files\OpenSSL\bin;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\CMake\bin;C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.2\bin;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Program Files\GVFS;c:\tools\php;C:\Program Files (x86)\sbt\bin;C:\SeleniumWebDrivers\ChromeDriver\;C:\SeleniumWebDrivers\EdgeDriver\;C:\Program Files\Amazon\AWSCLIV2\;C:\Program Files\Amazon\SessionManagerPlugin\bin\;C:\Program Files\Amazon\AWSSAMCLI\bin\;C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin;C:\Program Files (x86)\Microsoft BizTalk Server\;C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps
Thu, 23 Sep 2021 16:14:30 GMT     DOTNET_ROOT: C:\Users\runneradmin\AppData\Local\Microsoft\dotnet
Thu, 23 Sep 2021 16:14:30 GMT     pythonLocation: C:\hostedtoolcache\windows\Python\3.9.7\x64
Thu, 23 Sep 2021 16:14:30 GMT     PY_DEBUG: 1
Thu, 23 Sep 2021 16:14:30 GMT ##[debug]C:\Program Files\PowerShell\7\pwsh.EXE -command ". 'D:\a\_temp\74cea43f-0b05-41d1-a8d4-14e79d5d5d81.ps1'"
Thu, 23 Sep 2021 16:17:55 GMT Running on Python (3, 9): C:\hostedtoolcache\windows\Python\3.9.7\x64\python3.exe
Thu, 23 Sep 2021 16:17:55 GMT Testing for Kotlin/Java ...
Thu, 23 Sep 2021 16:17:55 GMT Running 'gradle.exe run --no-daemon'
Thu, 23 Sep 2021 16:17:56 GMT ##[debug]Finishing: Test Kotlin/Java

The step as a whole took 3m 26s, but 3 minutes of that appears to have occurred before the first output of the script:
Thu, 23 Sep 2021 16:14:30 GMT ##[debug]C:\Program Files\PowerShell\7\pwsh.EXE -command ". 'D:\a\_temp\74cea43f-0b05-41d1-a8d4-14e79d5d5d81.ps1'"
Thu, 23 Sep 2021 16:17:55 GMT Running on Python (3, 9): C:\hostedtoolcache\windows\Python\3.9.7\x64\python3.exe

So the logged timestamps are actually only calculated after the step completes, and not in real time while it's running :disappointed:

Have you tried the script locally on any windows machine?

Of course, I verified that it runs locally - there's no long delay, even with a daemon. Based on the evidence I would agree that the daemon is likely to be the cause of the problem, though this means the timestamps are wrong.
For this specific workflow it doesn't matter, but for Java project CI in general, you would want to enable the Gradle daemon and not have it be the cause of long delays. Note that Ubuntu and macOS had no problems throughout, and they run Gradle daemons too, so there is probably a Windows runner environment issue somewhere to be unearthed.

There is no issue when you run gradle run from the jvm directory even when the daemon is not started so we suppose the issue is related to python and subprocesses not to the gradle itself.

Well, the jvm directory is the current directory when the gradle run is executed, and there is no problem in the Ubuntu and macOS environments, which run the same logic.

I've changed the script to output debug information from Gradle, and it seems to show that the 3-hour delay occurs at the end of the step, not the beginning. The log can be seen here - the relevant lines are shown below. You can ignore the GitHub Actions timestamps after the step starts, they are all off by about 3 hours because of the delay.
Thu, 23 Sep 2021 22:08:00 GMT ##[debug]C:\Program Files\PowerShell\7\pwsh.EXE -command ". 'D:\a\_temp\e619680b-6fc2-41c3-8472-a9b17d31c2ef.ps1'"

Above is the last line from the GitHub Actions debug log with an accurate timestamp. Next is the first line output by the Gradle script running in debug mode:
2021-09-23T22:08:08.283+0000 [INFO] [org.gradle.internal.nativeintegration.services.NativeServices] Initialized native services in: C:\Users\runneradmin\.gradle\native

It's around 8s after the earlier line, which is not unexpected for JVM/Gradle startup etc. Next are the two lines which indicate a successful run from the test_all.py script's point of view:
2021-09-23T22:11:38.891+0000 [QUIET] [system.out] Hello, Java world!
2021-09-23T22:11:38.892+0000 [QUIET] [system.out] Hello, Kotlin world!

So, these are output around 3 minutes after the script started running - also not unexpected. Next is the final line of debug information output by Gradle:
2021-09-23T22:11:39.052+0000 [LIFECYCLE] [org.gradle.launcher.cli.DebugLoggerWarningAction]

Still under 4 mins since the script started running at 22:08:00. And last, we have the GitHub Actions debug log line:
Fri, 24 Sep 2021 01:11:51 GMT ##[debug]Finishing: Test Kotlin/Java

So, between the last line output by Gradle and the above line, there's the huge delay. The test_all.py script gets control after the Gradle run and reports that
Run completed in 11025.80 secs

So starting at 22:08:00, that would suggest that the above line was printed at 01:11:46 today - which pretty much ties in with the subsequent log times shown in the GitHub Actions timestamps, which show post-delay times starting at that value:
Fri, 24 Sep 2021 01:11:46 GMT Running on Python (3, 9): C:\hostedtoolcache\windows\Python\3.9.7\x64\python3.exe

As an extra point, the lines of debug information relating to the Gradle daemon are
2021-09-23T22:11:39.032+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] The daemon has finished executing the build.
2021-09-23T22:11:39.032+0000 [DEBUG] [org.gradle.launcher.daemon.server.exec.ExecuteBuild] The daemon has finished executing the build.
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Received result Success[value=org.gradle.launcher.exec.BuildActionResult@17bffc17] from daemon DaemonInfo{pid=5016, address=[a4fd104a-5702-4553-a6ae-8fa00dce7f63 port:50115, addresses:[/<IP_ADDRESS>]], state=Busy, lastBusy=1632434896167, context=DefaultDaemonContext[uid=243ed05f-ad4e-412c-849c-e4b5fcfc5351,javaHome=C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64,daemonRegistryDir=C:\Users\runneradmin\.gradle\daemon,pid=5016,idleTimeout=10800000,priority=NORMAL,daemonOpts=-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=windows-1252,-Duser.country=US,-Duser.language=en,-Duser.variant]} (build should be done).
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Received result Success[value=org.gradle.launcher.exec.BuildActionResult@17bffc17] from daemon DaemonInfo{pid=5016, address=[a4fd104a-5702-4553-a6ae-8fa00dce7f63 port:50115, addresses:[/<IP_ADDRESS>]], state=Busy, lastBusy=1632434896167, context=DefaultDaemonContext[uid=243ed05f-ad4e-412c-849c-e4b5fcfc5351,javaHome=C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64,daemonRegistryDir=C:\Users\runneradmin\.gradle\daemon,pid=5016,idleTimeout=10800000,priority=NORMAL,daemonOpts=-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=windows-1252,-Duser.country=US,-Duser.language=en,-Duser.variant]} (build should be done).
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Received result Success[value=org.gradle.launcher.exec.BuildActionResult@17bffc17] from daemon DaemonInfo{pid=5016, address=[a4fd104a-5702-4553-a6ae-8fa00dce7f63 port:50115, addresses:[/<IP_ADDRESS>]], state=Busy, lastBusy=1632434896167, context=DefaultDaemonContext[uid=243ed05f-ad4e-412c-849c-e4b5fcfc5351,javaHome=C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64,daemonRegistryDir=C:\Users\runneradmin\.gradle\daemon,pid=5016,idleTimeout=10800000,priority=NORMAL,daemonOpts=-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=windows-1252,-Duser.country=US,-Duser.language=en,-Duser.variant]} (build should be done).
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Received result Success[value=org.gradle.launcher.exec.BuildActionResult@17bffc17] from daemon DaemonInfo{pid=5016, address=[a4fd104a-5702-4553-a6ae-8fa00dce7f63 port:50115, addresses:[/<IP_ADDRESS>]], state=Busy, lastBusy=1632434896167, context=DefaultDaemonContext[uid=243ed05f-ad4e-412c-849c-e4b5fcfc5351,javaHome=C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64,daemonRegistryDir=C:\Users\runneradmin\.gradle\daemon,pid=5016,idleTimeout=10800000,priority=NORMAL,daemonOpts=-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=windows-1252,-Duser.country=US,-Duser.language=en,-Duser.variant]} (build should be done).
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Received result Success[value=org.gradle.launcher.exec.BuildActionResult@17bffc17] from daemon DaemonInfo{pid=5016, address=[a4fd104a-5702-4553-a6ae-8fa00dce7f63 port:50115, addresses:[/<IP_ADDRESS>]], state=Busy, lastBusy=1632434896167, context=DefaultDaemonContext[uid=243ed05f-ad4e-412c-849c-e4b5fcfc5351,javaHome=C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64,daemonRegistryDir=C:\Users\runneradmin\.gradle\daemon,pid=5016,idleTimeout=10800000,priority=NORMAL,daemonOpts=-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=windows-1252,-Duser.country=US,-Duser.language=en,-Duser.variant]} (build should be done).
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Received result Success[value=org.gradle.launcher.exec.BuildActionResult@17bffc17] from daemon DaemonInfo{pid=5016, address=[a4fd104a-5702-4553-a6ae-8fa00dce7f63 port:50115, addresses:[/<IP_ADDRESS>]], state=Busy, lastBusy=1632434896167, context=DefaultDaemonContext[uid=243ed05f-ad4e-412c-849c-e4b5fcfc5351,javaHome=C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64,daemonRegistryDir=C:\Users\runneradmin\.gradle\daemon,pid=5016,idleTimeout=10800000,priority=NORMAL,daemonOpts=-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=windows-1252,-Duser.country=US,-Duser.language=en,-Duser.variant]} (build should be done).
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Received result Success[value=org.gradle.launcher.exec.BuildActionResult@17bffc17] from daemon DaemonInfo{pid=5016, address=[a4fd104a-5702-4553-a6ae-8fa00dce7f63 port:50115, addresses:[/<IP_ADDRESS>]], state=Busy, lastBusy=1632434896167, context=DefaultDaemonContext[uid=243ed05f-ad4e-412c-849c-e4b5fcfc5351,javaHome=C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64,daemonRegistryDir=C:\Users\runneradmin\.gradle\daemon,pid=5016,idleTimeout=10800000,priority=NORMAL,daemonOpts=-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=windows-1252,-Duser.country=US,-Duser.language=en,-Duser.variant]} (build should be done).
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Received result Success[value=org.gradle.launcher.exec.BuildActionResult@17bffc17] from daemon DaemonInfo{pid=5016, address=[a4fd104a-5702-4553-a6ae-8fa00dce7f63 port:50115, addresses:[/<IP_ADDRESS>]], state=Busy, lastBusy=1632434896167, context=DefaultDaemonContext[uid=243ed05f-ad4e-412c-849c-e4b5fcfc5351,javaHome=C:\hostedtoolcache\windows\Java_Adopt_jdk\8.0.302-8\x64,daemonRegistryDir=C:\Users\runneradmin\.gradle\daemon,pid=5016,idleTimeout=10800000,priority=NORMAL,daemonOpts=-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=windows-1252,-Duser.country=US,-Duser.language=en,-Duser.variant]} (build should be done).
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientConnection] thread 1: dispatching class org.gradle.launcher.daemon.protocol.Finished
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientConnection] thread 1: dispatching class org.gradle.launcher.daemon.protocol.Finished
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientConnection] thread 1: dispatching class org.gradle.launcher.daemon.protocol.Finished
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientConnection] thread 1: connection stop
2021-09-23T22:11:39.051+0000 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClientConnection] thread 1: connection stop

All within 4 minutes of start, which suggests that the daemon didn't contribute to any delay at startup, though the delay might be due to waiting for the daemon to die (which might not happen for 3 hours, depending on how the Gradle launcher is configured in the Windows VMs).
Please escalate as needed to a Gradle expert to give their input.

Of course, I verified that it runs locally - there's no long delay, even with a daemon.

Could you please try to run your script locally on a windows machine with all gradle daemons stopped and not running.

Sure. I used this batch file (runit.bat):
@echo off
gradle --status
time /t
python3 test_all.py jvm
time /t
gradle --status

Here's the run with daemons not disabled:
~\Projects\cfgclient> runit
No Gradle daemons are running.

Only Daemons for the current Gradle version are displayed. See https://docs.gradle.org/7.2/userguide/gradle_daemon.html#sec:status
08:26
Running on Python (3, 8): C:\Users\Vinay\AppData\Local\Programs\Python\Python38\python3.exe
Testing for Kotlin/Java ...
Running 'gradle.exe run'
08:26
   PID STATUS   INFO
  1880 IDLE     7.2

Only Daemons for the current Gradle version are displayed. See https://docs.gradle.org/7.2/userguide/gradle_daemon.html#sec:status

Here's the run with --no-daemon to disable daemons:
~\Projects\cfgclient [main]> runit
No Gradle daemons are running.

Only Daemons for the current Gradle version are displayed. See https://docs.gradle.org/7.2/userguide/gradle_daemon.html#sec:status
08:30
Running on Python (3, 8): C:\Users\Vinay\AppData\Local\Programs\Python\Python38\python3.exe
Testing for Kotlin/Java ...
Running 'gradle.exe run --no-daemon'
08:31
No Gradle daemons are running.

Only Daemons for the current Gradle version are displayed. See https://docs.gradle.org/7.2/userguide/gradle_daemon.html#sec:status

@vsajip, How is gradle installed on your local machine? I mean manually or via some package manager like chocolatey.

Manually, as per the instructions here, except onto drive F: and I also have a gradle.exe, because the manual installation just provides a gradle.bat, but in your VMs there's just gradle.exe AFAIK. My gradle.exe is just derived from a Python script that does exactly the same as gradle.bat, which is to run (as I have JDK1.8 on this Windows machine)
c:\jdk1.8\bin\java.exe -Xmx64m -Xms64m -Dorg.gradle.appname=gradle -classpath f:\gradle\gradle-7.2\lib\gradle-launcher-7.2.jar org.gradle.launcher.GradleMain <gradle.exe arguments>

I think the problem is the Gradle daemon die time. I can change this repo's workflow to use --no-daemon, but that won't solve the issue in the wider case, which might well be one of my other projects :wink: The real question is - why does the Windows VM hang around in the step for 3 hours (apparently waiting for the daemon to die), whereas the Ubuntu and macOS ones don't seem to? See this paragraph from the Gradle docs about the fact that the default setting for the Gradle daemon to die by itself is 3 hours.
Possibly a case could be made for configuring your Gradle launcher on Windows VMs to have a different configured timeout, say 15 minutes or 30 minutes. Happy to discuss with a Gradle expert if you feel one needs to get involved.

Gradle on a Windows VM installed via chocolatey.

provides a gradle.bat, but in your VMs there's just gradle.exe

Choco installing packages inside his installation folder and creating a shim leading to specific executable.
I've managed to repro the issue on my local machine with gradle installed with choco. And script works as expected with the same gradle switched to use gradle.bat bypassing shim.
The problem here imo lies in interaction between "run_command" function, gradle.exe shim and so on.
I think --no-daemon option is the best solution here for now.

The problem here imo lies in interaction between "run_command" function, gradle.exe shim and so on.

I don't agree, because the logs indicate otherwise - specifically the link and my analysis of the log as given in this message. In that analysis, it shows that the Gradle run proceeds normally, with a 3-hour delay after the run has completed. There is no point in hand-waving about interaction between "run_command" function, gradle.exe shim and so on, but feel free to poke holes in my analysis. One doesn't need Java or Gradle expertise for this, IMO; just reading timestamps on logs should be sufficient.
As I said, I have no problem switching to --no-daemon for this repo, but the problem remains in general for those cases where a daemon is needed - an unnecessary 3-hour delay at the end of the step on Windows only seems problematic to me.

@vsajip you can reproduce the issue on your local machine if you switch Gradle to the one from choco. The issue is most likely caused by the gradle shim and how it returns the status to your python script. Could you debug this combination (gradle from choco plus your script) locally because we can't do much from our end rather than get rid of choco, which we would rather avoid due to maintenance concerns?

I'll try installing Gradle with Chocolatey and see how that goes.

OK, I can reproduce the problem with the Chocolatey shim, thank goodness! Looks like it's a known issue with CI; AppVeyor had a similar issue, I've now found.

There's no specific place to log an issue for this, so I've contacted the Gradle package maintainers via a form on the Chocolatey site. Let's hope they respond.

@vsajip looks like it's a known issue, this one sounds very similar https://github.com/chocolatey/shimgen/issues/44
I'm going to close the issue since no action is required from our side at the moment. Feel free to contact us if you have any concerns or updates.
Thank you!


changing usage of bridges to connectors

hopefully this is complete and correct. It should also include file renames in a few instances - if I've done this correctly.

Thanks for doing this @timlawrence-bentley. Missed a couple spots - I'll fix them up.

@calebmshafer can you let us know what action is required to get @timlawrence-bentley's PR merged into imodeljs repo?

@timlawrence-bentley I queued the iModel.js Docs build here and there were a couple broken links.  here's the output
Invalid Link: "[overview](../learning/imodel-connectors.md)" in file "learning/writeaconnector"
Invalid Link: "[Transform](../learning/imodel-connectors.md#data-alignment)" in file "learning/writeaconnector"
Invalid Link: "[iModel Connectors]($docs/learning/imodel-connectors.md)" in file "learning/tutorials/create-test-imodel-itwin-sync"
Invalid Link: "[iModel Connectors](../../learning/imodel-connectors.md)" in file "bis/intro/federated-digital-twins"

Hi Caleb, The rename of imodel-bridges.md to imodel-connectors.md wasn’t made. Do I need to cancel this PR?  Tim From: Caleb Shafer<EMAIL_ADDRESS>Sent:

@timlawrence-bentley no need to re-open.  I'll kick off a new build now that you pushed the changes.

I'll kick off a new build now that you pushed the changes.

Is this something only @calebmshafer can do? We like to avoid pestering him when we can.

@pmconne it's a painful process right now given the way the association works between GH and ADOps. I manually queue the builds with the necessary variables set to make the association work.
I think I have a way to make it a bit easier that would let someone with write access leaving a comment. I'll kick it off this time and have a PR with the instructions on how members of iModel.js can do it going forward.


Remove xfix's matrix address from maintainers list

Description of changes

Planning to remove that Matrix account.
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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

[ ] 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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.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

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

please change the commit name to or something similar
maintainers: remove xfix matrix handle

Done.


Update grammatical mistake in Contributing.md Spanish translation

Fixed a grammatical mistake.

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

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

Thank you for opening this pull request.
This is a standard message notifying you that we’ve reviewed your pull request and have decided not to merge it. An older PR made this change obsolete. We would welcome future pull requests from you.
Thank you and happy coding.

Thank you for opening this pull request.
This is a standard message notifying you that we’ve reviewed your pull request and have decided not to merge it. An older PR made this change obsolete. We would welcome future pull requests from you.
Thank you and happy coding.


Cropped image return on the basis of cropProps

We have a original image and have cropprops which have topx topY bottomY bottomX how can we crop the image and get cropImage on the basis of topx topy bottomx bottomy
func cropProps(_ info: CropInfo) -> CropProps {
return CropProps(topX: Int(info.cropRegion.topLeft.x * info.originalPixels.width),
topY: Int(info.cropRegion.topLeft.y * info.originalPixels.height),
bottomX: Int(info.cropRegion.bottomRight.x * info.originalPixels.width),
bottomY: Int(info.cropRegion.bottomRight.y * info.originalPixels.height))
} can you provide in this library crop function cropped the image on the basis of cropInfo but can you get a function which takes cropProps as input and return cropImage on the basis of cropprops which is how can we do that please  @guoyingtao

@rahul6350
Mantis is an iOS Image cropping library, which mimics the Photo App. Users can crop images by the interactions with CropViewController. Perhaps you can find a dedicated image processing library that includes the cropping features you need.

There has been no reply to this ticket for a while, so I am closing it for now. You can reopen it anytime if needed.


luajit_2_0: 2.0.5-2020-08-09 -> 2.0.5-2020-09-27, luajit_2_1: 2.1.0-2020-08-27 -> 2.1.0-2020-09-30

Motivation for this change

various fixes
support for full-range 64 bit lightuserdata, this mean we can safely enable GC64 on all platforms! (luajit_2_1)

Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

The second commit message is wrong (and the title).  I was really happy for aarch64 yesterday when it happened.  I'm not sure how well the upstream code has been tested, but I expect the update will be OK for nixpkgs master.

Oops, fixed. Mike has good track record of pushing things which works and done right. I was also happy yesterday to see this finally solved.


WIP: psi4: 1.4.1 -> 1.5

Update to the latest upsteam release, unfortunately still with the original Libint2 hack as upstream (the build times are terrible).
https://github.com/psi4/psi4/releases/tag/v1.5

A flake update is required to get qcelemental 0.24.0, which is a dependency of Psi4 and has been merged recently into nixpkgs-unstable.


Baseline MAINTAINERS, CODEOWNERS, and external collaborator permissions

Follow https://github.com/opensearch-project/.github/issues/125 to baseline MAINTAINERS, CODEOWNERS, and external collaborator permissions.
Close this issue when:

MAINTAINERS.md has the correct list of project maintainers.
CODEOWNERS exists and has the correct list of aliases.
Repo permissions only contain individual aliases as collaborators with maintain rights, admin, and triage teams.
All other teams are removed from repo permissions.

If this repo's permissions was already baselined, please confirm the above when closing this issue.

Your permissions are incorrect. You have 19 people with admin access.

Please work with an admin to adjust permissions.

working with current admins to resolve this and baseline the permissions

Added the users listed in MAINTAINERS.md file as maintainers of this repo. @anirudha @derek-ho Please add CODEOWNERS file under .github directory with the maintainers list.

Verified, thx.


Test PR to Automate Docker Requirement Workflow

Related to https://github.com/Quansight/ragna/pull/459

Shoot, I was meant to be opened on fork. Sorry


Could not find reduxState global in main process, did you forget to call replayActionMain?

I'm want to build react-redux to native app.
Here is error when I try to use electron-redux, I not sure that I correctly use.

electron.js

import { forwardToRenderer, triggerAlias, replayActionMain } from 'electron-redux'
import { createStore, combineReducers, applyMiddleware } from 'redux'
import { browserHistory } from 'react-router'
import { routerMiddleware, routerReducer } from 'react-router-redux'
import thunkMiddleware from 'redux-thunk'
import logger from 'redux-logger'
import home from '../src/home/reducers'
const electron = require('electron');
const app = electron.app;
const BrowserWindow = electron.BrowserWindow;

const path = require('path');
const url = require('url');
const isDev = require('electron-is-dev');

let mainWindow;

function createWindow() {
  mainWindow = new BrowserWindow({width: 900, height: 680});
  mainWindow.loadURL(isDev ? 'http://localhost:3000' : `file://${path.join(__dirname, '../build/index.html')}`);
  mainWindow.webContents.openDevTools()
  mainWindow.on('closed', () => mainWindow = null);
}

app.on('ready', createWindow);

app.on('window-all-closed', () => {
  if (process.platform !== 'darwin') {
    app.quit();
  }
});

app.on('activate', () => {
  if (mainWindow === null) {
    createWindow();
  }
});

const rootReducers = (state, action) => {
  if (action.type === 'RESET_ALL_DATA') {
      state = undefined
  }
  return appReducers(state, action)
}

const appReducers = combineReducers({
  routing: routerReducer,
  home
})

const middleware = [
  thunkMiddleware,
  logger,
  routerMiddleware(browserHistory)
]

const store = createStore(
  rootReducers,
  {}, // optional
  applyMiddleware(
    triggerAlias, // optional, see below
    ...middleware,
    forwardToRenderer, // IMPORTANT! This goes last
  ),
);

replayActionMain(store);

renderer process (store.js in this case)

import { createStore, combineReducers, applyMiddleware } from 'redux'
import { browserHistory } from 'react-router'
import { routerMiddleware, routerReducer } from 'react-router-redux'
import thunkMiddleware from 'redux-thunk'
import logger from 'redux-logger'
import home from './home/reducers'

const { forwardToMain, replayActionRenderer, getInitialStateRenderer } = window.require('electron-redux')

const middleware = [
    thunkMiddleware,
    logger,
    routerMiddleware(browserHistory)
]

const rootReducers = (state, action) => {
    if (action.type === 'RESET_ALL_DATA') {
        state = undefined
    }
    return appReducers(state, action)
}

const appReducers = combineReducers({
    routing: routerReducer,
    home
})

const initialState = getInitialStateRenderer()

export const store = createStore(rootReducers, initialState, applyMiddleware(forwardToMain, ...middleware))
replayActionRenderer(store)

this is where I use store (index.js)

import React from 'react'
import ReactDOM from 'react-dom'
import './css/index.css'
import { store } from './store'
import { Router, Route, browserHistory, IndexRedirect } from 'react-router'
import { syncHistoryWithStore } from 'react-router-redux'
import { Provider } from 'react-redux'
import HomePage from './home/containers'

const history = syncHistoryWithStore(browserHistory, store)
const state = store.getState()

ReactDOM.render(
<Provider store={store}>
    <Router history={history}>
        <Route path='/'>
            <IndexRedirect to='/home'/>
            <Route path='home' component={HomePage}/>
        </Route>
    </Router>
</Provider>, document.getElementById('root'));

@nuugut Have you resolved this problem?

Has anyone else figured this out? I have the same setup, but my stores aren't syncing

Feel free to reopen if issue still persists in ~1.5.1


Add disabled component option argument with streamlit appropriate styling

Continuation of previous PR with styling issues fixed:
https://github.com/victoryhb/streamlit-option-menu/pull/49
Please review @victoryhb

I have updated the CSS to use an invert() filter so the colour will be visible (but faded) on various surroundings.

Is this the complete PR? I don't seem to find the newly added disabled option?

Hey thanks @victoryhb - I missed your reversion of the previous PR and was reconciling those changes back to this one - I missed a commit and the notes in the readme on my end here.
Should be all good now, but no rush if you want to leave open for review and testing for a few days.

Looking the same as original now. I have also improved documentation for the styling and added some extra class tags.

If you'd like to review and raise any thoughts before merging.

Seems alright, thanks!


fix(Translation): Objects in context caused error

Closes #2
Fixes the error when there is an object in the $context. Also checks for brackets before even bothering to run all those str_replace (which could be substantial if your context has a lot of vars in it.
Hope I did this ok? We were just starting to try this out and it was all working fine until I loaded a template with a few objects in it.
Not sure if master is the appropriate target, but since its the only branch...

Thank you for your contribution.


DCOS-9248: Remove overcapacity from bar

This PR does remove over capacity from the statusbar because the number was not clear to the user. There is now a text added next to the total task count if a service is over capacity.
Also the over capacity line is still in the tooltip.
over capacity:

within capacity:

/cc @leemunroe @silverem2

Test failed:
��� ServiceInfo ��� #render ��� it renders number of running tasks
  - Expected '2 Tasks (over capacity by NaN tasks)' to equal '2 Tasks'.

o.O Fixed the test.

@Poltergeist Making sure I understand what is going on here.

In the over capacity screenshot, nginx is Deploying
The ideal state of nginx is 3 tasks
There are currently 6 Tasks because there are 3 running healthy tasks and 3 tasks are deploying (therefore 3 over capacity)

Questions

Does it make sense to have (100%) beside each in the tooltip? This seems odd to me. I think I would expect 3 Healthy of 6 (50%) 3 Unknown of 6 (50%) 3 Over Capacity (100%)
The bar doesn't look like it is deploying (i.e. doesn't have the striped barbershop style) which is concerning. Is that because we don't know which tasks are deploying?

The labels are divided into multiple parts,

the percent was calculated using the instances setting not the tasksRunning. I use now what ever is higher either tasksRunning or instances. I used this because tasksStaging do not get added to the tasksRunning, alternative here would be to sum tasksStaging and tasksRunning.
However I do have a problem with is the 3 Over Capacity (100%) This would mean that this percentage is based on the instances defined and not the number of running tasks. I would rather think that 3 tasks are over capacity and those are 50% of all the tasks running then 100% over capacity.

About the bar, in this case I defined an application with a nginx container wit a healthcheck with an interval of 60 seconds, so the first 60 seconds the tasks is not healthy and the service is still deploying. So If I change the configuration to another nginx container like nginx:latest, a new task will be staged, which will be eventually be running, but first it will be unkown in health. After 60 seconds the health check will pass. At that moment the old running instances will be shutting down and after that the complete deployment will be completed and the service will be in the running state.
In the screenshot you do see a service which still is deploying but the new tasks are already running. We are adding the barbershop stripes only to staging instances, should we add the stripes to all states if a service is deploying? So also to the healthy, unhealthy, unknown  etc.

I think I would expect the deploying status to trump the health status i.e. if it is in a deploying state, always show the stripes, until the deployment has finished, then show the health. I think visually it is important to call this out to the user that it is deploying. Does that make sense?
Also sounds like something that needs a deeper look at in a future release, and whether we should separate out health/status and/or replace the bar with something else.

Okay I'll replace all the health informations with a deploying animation if a service is deploying. But this will mean that the user has no health information during a deployment even if this deployment will take longer. Do we also want to show something special for waiting services like a yellow barber stripe bar?

mesosphere-ci retest this please

LGTM! 🚢

Please reenable tooltip during deployment.

@orlandohohmeier @Poltergeist agreed, we should have the tooltip in there, then at least we have parity (I think) with how Marathon UI works today i.e. if a deployment is happening, the whole bar is striped, and the tool tip makes it clear what is going on.
What I would like to see, and should have clarified above, is if there are 3 running healthy tasks, and 3 deploying (therefore 3 over capacity), then half the bar is striped. It sounds like we can't do this right now because we don't know which tasks are deploying vs deployed, correct? I would suggest we chat to backend to see if there's a way to make this distinction /cc @gkleiman @aquamatthias

LGTM!

@leemunroe Could you please create a JIRA to track the adjustments needed to properly display overcapacity tasks?

LGTM 💯 ✨


Cannot find bin64, correct dir

Select directory button doesn't work.
Can't find my bin64 dir when I edit the game dir manually.
config.yaml has just part of the dir C:\games and no executable name.
When I edit config.yaml in a text editor and add the full path to game_path: then the next run of the Manager works and can find my game.
Unzipped clean and reproduced consistently.

Minor but figured I'd report it, thank you for your work!

config.zip

Have this been fixed yet or someone found a workaround?

@Altiahad Sorry for my silence recently, it looks like for now manually editing the game_path field of your config.yaml file should work according to @tb0n3zz ,  hopefully I'll get out a release with #59 integrated sometime soon so that'll fix this properly.


Create team from group

The MS-recommended way to create a team is to create a unified group first, then create a team from it. I think this is just because of the sync delay between AAD and Teams Service.
Currently this means we need to authenticate twice when creating the team: once to Exchange Online or Azure AD to find the Id of the group with the display name we intend to use; and once to Teams to create the new team.
If we use MFA, as strongly recommended, then we can't authenticate to Exchange Online with -Credential. We need to supply a UPN. But when we authenticate to Teams, we cannot supply the already supplied UPN. We have to type it again.
Is there a way to avoid having to type the username and password twice? Or maybe we should turn to Microsoft Graph?

@officedocsbot assign @yogkumgit

Hello @Air-Git
I know the team is constantly trying to improve the PowerShell module, and they listen to suggestions in Teams UserVoice, if you want to suggest that. As here we are limited to documentation changes, said that, can you kindly share the article that states this

The MS-recommended way to create a team is to create a unified group first, then create a team from it.

Maybe I can check if that is still the recommendation.
Thank you

It's the recommendation in the Graph documentation. Creating Teams. But I think this is simply a pointer to the fact that groups take time to be available, You need to set properties of the group e.g. to disable welcome notifications, so you need to use Exchange Online anyway, and may as well use it to create the group first.

@Air-Git I agree with you, Exchange Online Ps allows you to better customize a group, so probably you will start with it.
If you still want to suggest any idea to the Product Team, remember  you can use the UserVoice I referenced.

@get-itips  Thank you very much for the contribution and sharing this explanation. @Air-Git
Hope this comment is helpful for you. If you see a documentation update is required, please feel free to open an issue for the same. We proceed here to close it. Thanks for taking out some time to open the issue. Appreciate and encourage you to do the same in future also


OCM-5260: Add docs about default/worker machine pool

This is cherry-pick from main branch (from PR #463)

/lgtm
/approve

except small comment
/lgtm


Discussion: Extended Application Specification

We should consider extending the current ARC4 contract description with additional data.
The additional data might include:

State  keys/types
Data structures used
Hints or default parameters for methods.

One reason people often ask for the state schema to be exposed is so that callers can know

How much min balance is required to opt-in
Whether opt-ins are required at all

But just because there's a local state schema, that doesn't mean that accounts must be opted-in for every possible invocation of the contract.  There may be some calls that don't require the user to be opted in. Imagine, for example, an AMM that offers price information from a call that only examines global state. So this might fall under the "Hints" mentioned in the main description - does this method require opt-in?

Good point, having methods marked with an authorized: opted in and conveying that info to the caller would be a good addition

See also prior art here: https://github.com/algorandfoundation/ARCs/pull/75

I'm not sure this is the right place to discuss it but: I was considering that with the introductions of op-code budget utilities such as OpUp in PyTeal, a client should be able to discover the cost of an ABI call that eventually triggers Inner Transactions with the purpose of increasing the op-code budget. Maybe this could be just mentioned in the method's descriptions if we think that a specific ABI JSON field is too much.

I agree that info about cost is potentially useful, but I also worry that a) it might be dynamic, based on the input data, and b) even if static, it seems brittle to friend on it, if a contract you are calling is updateable. (That is, it might be reasonable to assume a contact won't change its method availability, but not changing its precise cost send like a big ask)
So we would need to figure out how to offer guidance without tripping on those issues.

Regarding contract update, I think metadata must be updated in that case.

I think it is definitely useful to include a structured standardisation of the state (global and local) in the ABI JSON. I saw there are some concerns about Boxes, which introduce a state that is not know in advance at compiling/creation time. I think we should treat the state “statically allocated” (in the original form) differently from the state “dynamically allocated” through Boxes. I’m in favour of having the “static” one structured and standardised in the JSON ABI and the “dynamic” one somehow appended as JSON appendix with the Box itself. In this way we gain already a very useful standardisation that covers all those apps that not make use of Boxes and have an escape valve for the state appended dynamically later on with Boxes.

I'm not sure the difference between status and dynamic is as straightforward as global/local vs boxes.
NFDs, for example, have user defined keys. A new "standard" among NFDs could emerge in which a particular key has a particular type, but that was not known at contract creation time.
Conversely, I expect some usage of boxes to be quite static. I was recently recommending to a project that they use one global box, maybe named "balances" or whatever, to hold a list of asset, balance pairs. They could statically declare the abi type of such a box.


feat(palette-mobile): all icons done

This PR is part of MOPLAT-610
Description

PR Checklist

[x] I have tested my changes on iOS and Android.
[x] I hid my changes behind a feature flag, or they don't need one.
[x] I have included screenshots or videos, or I have not changed the UI.
[x] I have added tests, or my changes don't require any.
[x] I added an app state migration, or my changes do not require one.
[x] I have documented any follow-up work that this PR will require, or it does not require any.
[x] I have added a changelog entry below, or my changes do not require one.

To the reviewers 👀

[ ] I would like at least one of the reviewers to run this PR on the simulator or device.

Changelog updates
Changelog updates

Cross-platform user-facing changes

iOS user-facing changes

Android user-facing changes

Dev changes

palette-mobile, all icons

Need help with something? Have a look at our docs, or get in touch with us.

yea. its a thing that id like to get to, but not on this PR. i have a branch pvinis/icons-dep that i tried to do that, but its kinda funky with the svgs, so i left it for later. in any case, it should be easy to do that on palette-mobile and get it here for free.


Add tini to allow termination signal handling

Description
Adds tini as the PID1 process in opensearch and opensearch-dashboards container to allow for termination signal handling.
Tini couldn't be found when using './tini' as the install path, so I reverted to using 'bin/tini'.
Issues Resolved
closes [BUG] OpenSearch container does not allow for graceful termination #3229
Test Plan and Results:

Build single/multi arch image and push image to dockerhub as described on opensearch-build/docker.
Run image

docker run -it -p 9200:9200 -p 9600:9600 -e "discovery.type=single-node" chawinphat/opensearch:1.3.9

Test signal handling with new image. See that container is closed after calling "SIGTERM"

# Check for Container
> docker ps
CONTAINER ID   IMAGE                         COMMAND                  CREATED          STATUS          PORTS                                                                NAMES
e7297b7fcbba   chawinphat/opensearch:1.3.9   "/bin/tini -- ./open…"   19 minutes ago   Up 19 minutes   <IP_ADDRESS>:9200->9200/tcp, 9300/tcp, <IP_ADDRESS>:9600->9600/tcp, 9650/tcp   vigorous_dewdney

# Send signal
> docker kill --signal="SIGTERM" e7297b7fcbba
e7297b7fcbba

# Check that container is gone
> docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

Opensearch container exits with the following logs

[2023-11-15T23:36:53,554][INFO ][o.o.n.Node               ] [e7297b7fcbba] stopped
[2023-11-15T23:36:53,555][INFO ][o.o.n.Node               ] [e7297b7fcbba] closing ...
[2023-11-15T23:36:53,561][INFO ][o.o.s.a.i.AuditLogImpl   ] [e7297b7fcbba] Closing AuditLogImpl
[2023-11-15T23:36:53,568][INFO ][o.o.n.Node               ] [e7297b7fcbba] closed

I was able to pass this test process on both single and multi arch builds.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Put it to pending now as it might be able to solve just by using exec to start process. See issue comments.
Thanks.


[Troubleshooting tip] Cannot start ZWESAUX

1. Slack conversation link (if any)
https://openmainframeproject.slack.com/archives/CC08782AG/p1593531399284800
2. Choose a title
Cannot start ZWESAUX
3. Symptom
when I try and start ZWESAUX task it falls over with the following...
ZWES0058E Communication area failure - master comm area parm not found.
4. Solution
You're not supposed to start up ZWESAUX, it's started up by ZWESIS on an as-needed basis

The user guide already says
You do not start or stop the ZWESASTC manually

In this case, I think less is better.  There is so much text on the screen using AUX, people are conflating it with the started task name which is ZWESASTC.

Hello,
Can you correct the documentation, User's Guide page 120 : a A is missing in the STC name

@F-LEMANER Thank you for raising this defect! It's fixed in this PR #1292 . Docs will be updated upon merge.


Add rule enforcing props are passed to super in constructor

Following the advice of the React Docs react-component#constructor it would be great if there was an eslint rule that would convert:
constructor(props) {
  super();
  // ....
}

to:
constructor(props) {
  super(props);
  // ....
}

So that we would catch cases where someone tries to use this.props before it is populated. Thank you!

Looks like a duplicate of #626

Has this rule been added?

@joetidee no, see #626.


[grpc] build failure | failed to cross compile gRPC on macOS arm64 host

Package: grpc[codegen,core]:x64-osx-custom -> 1.50.1
Host Environment

Host: arm64-osx
Compiler: AppleClang <IP_ADDRESS>00029
vcpkg-tool version: 2022-12-14-7ae0d8527fb488fde10a89c2813802dc9b03b6f9
vcpkg-scripts version: a0cd24633 2022-12-27 (29 hours ago)

To Reproduce
vcpkg install
Failure logs
-- Using cached grpc-grpc-v1.50.1.tar.gz.
-- Extracting source /<repo_root>/vcpkg_download/grpc-grpc-v1.50.1.tar.gz
-- Applying patch 00001-fix-uwp.patch
-- Applying patch 00002-static-linking-in-linux.patch
-- Applying patch 00003-undef-base64-macro.patch
-- Applying patch 00004-link-gdi32-on-windows.patch
-- Applying patch 00005-fix-uwp-error.patch
-- Applying patch 00009-use-system-upb.patch
-- Applying patch snprintf.patch
-- Applying patch 00012-fix-use-cxx17.patch
-- Applying patch 00014-pkgconfig-upbdefs.patch
-- Applying patch 00015-disable-download-archive.patch
-- Using source at /<repo_root>/vcpkg/buildtrees/grpc/src/v1.50.1-1b126aed1d.clean
-- Found external ninja('1.11.1').
-- Configuring x64-osx-custom
-- Building x64-osx-custom-dbg
CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:131 (message):
    Command failed: /<repo_root>/vcpkg_download/tools/cmake-3.25.0-osx/cmake-3.25.0-macos-universal/CMake.app/Contents/bin/cmake --build . --config Debug --target install -- -v -j11
    Working Directory: /<repo_root>/vcpkg/buildtrees/grpc/x64-osx-custom-dbg
    See logs for more information:
      /<repo_root>/vcpkg/buildtrees/grpc/install-x64-osx-custom-dbg-err.log

Call Stack (most recent call first):
  /<repo_root>/vcpkg_installed/x64-osx-custom/share/vcpkg-cmake/vcpkg_cmake_build.cmake:74 (vcpkg_execute_build_process)
  /<repo_root>/vcpkg_installed/x64-osx-custom/share/vcpkg-cmake/vcpkg_cmake_install.cmake:16 (vcpkg_cmake_build)
  buildtrees/versioning_/versions/grpc/13420572b45b2b5a5a3fb41eb383d0c62f1d7c51/portfile.cmake:69 (vcpkg_cmake_install)
  scripts/ports.cmake:147 (include)

//vcpkg/buildtrees/grpc/install-x64-osx-custom-dbg-err.log
ninja: error: '_gRPC_CPP_PLUGIN-NOTFOUND', needed by '/<repo_root>/vcpkg/buildtrees/grpc/x64-osx-custom-dbg/gens/src/proto/grpc/reflection/v1alpha/reflection.pb.cc', missing and no known rule to make it

Additional context
vcpkg.json
{
  "$schema": "https://raw.githubusercontent.com/microsoft/vcpkg/master/scripts/vcpkg.schema.json",
  "name": "proj",
  "version": "<IP_ADDRESS>",
  "builtin-baseline": "a0cd246334a33107cdef4f701b0b532a71514b19",
  "dependencies": [
    {
      "name": "grpc",
      "version>=": "1.50.1",
      "features": [
        "codegen"
      ]
    }
  ]
}

also documented here  https://github.com/microsoft/vcpkg/discussions/28594
I have the following triplets:
x64-osx-custom triplet:

set(VCPKG_TARGET_ARCHITECTURE x64)
set(VCPKG_OSX_ARCHITECTURES x86_64)
set(VCPKG_CMAKE_SYSTEM_NAME Darwin)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)

arm64-osx-custom triplet:

set(VCPKG_TARGET_ARCHITECTURE arm64)
set(VCPKG_OSX_ARCHITECTURES arm64)
set(VCPKG_CMAKE_SYSTEM_NAME Darwin)
set(VCPKG_CRT_LINKAGE dynamic)
set(VCPKG_LIBRARY_LINKAGE static)

in the main CMakeLists.txt before any call to project() I set:

set(VCPKG_TARGET_TRIPLET x64-osx-custom)
set(VCPKG_HOST_TRIPLET x64-osx-custom)

accourding to https://github.com/microsoft/vcpkg/issues/22476
and https://github.com/microsoft/vcpkg/issues/16504
and https://github.com/microsoft/vcpkg/issues/17436

When I set VCPKG_HOST_TRIPLET to arm64-osx-custom gRPC builds.

I do not understand what the issue is. You of course cannot compile with a host triplet that does not match your host system because gRPC has to execute just-compiled binaries during its build process. If those binaries are compiled for x86 while you are on arm64 then they won't work. Well, they might work because of emulation but vcpkg and CMake do not make that assumption.
Therefore, the expected use is:
set(VCPKG_TARGET_TRIPLET x64-osx-custom)
set(VCPKG_TARGET_TRIPLET arm64-osx-custom)
which should result in a compilation of gRPC tools (like protoc-gen-grpc) for arm64 and everything else for x86 (like gRPC static library). Is that not what is happening?

I do not understand what the issue is. You of course cannot compile with a host triplet that does not match your host system because gRPC has to execute just-compiled binaries during its build process. If those binaries are compiled for x86 while you are on arm64 then they won't work. Well, they might work because of emulation but vcpkg and CMake do not make that assumption. Therefore, the expected use is: set(VCPKG_TARGET_TRIPLET x64-osx-custom) set(VCPKG_TARGET_TRIPLET arm64-osx-custom) which should result in a compilation of gRPC tools (like protoc-gen-grpc) for arm64 and everything else for x86 (like gRPC static library). Is that not what is happening?

Thanks for clarifying. If I am not mistaken, I think you have a typo in one of the variable names.

Indeed, I mean to write
set(VCPKG_HOST_TRIPLET arm64-osx-custom)
set(VCPKG_TARGET_TRIPLET x64-osx-custom)

related to https://github.com/microsoft/vcpkg/discussions/29386


Chore: fix vulnerabilities via npm audit fix

This PR fixes vulnerabilities via npm audit fix:

json5

Watch those dev-next failures here:

`No access token was returned during the UMA exchange flow. Refer to your network requests for details.`


Reason for v0.2 ?

Hi,
Cool project. Can I ask what was wrong with v0.1 other than more expensive parts (LMP7721) ? This part seems missing in the project history. It seems to match what I'm doing in a board and I'm interested in your experience with these circuits.
Thanks!
Wilco

The primary reason for the design change from v0.1 to v0.2 was to reduce manufacturing costs.  It wasn't due to any issue with the v0.1 design.  The design was modified to only use components which are stocked by the PCB manufacturer/assembler.  Doing this enables us to get the boards made very quickly and at lower cost.   Moving to the lower cost op amp (from the LMP7721) helped as well, but it was more of a side a effect.

Thank you for your reply!


Implement radio ingestion

This PR implements Audio Streaming Integration by integrating the SpeechToText-WebSockets-Java with our Spark platform.
The integration works as follows:

We create a transcriber object via the speech-to-text library.
We open a standard URL connection to the radio stream and connect it to the transcriber.
The transcriber takes care of reading the audio stream, converting it to text, etc.
Whenever a transcription is complete, the transcriber calls our callback. In this callback, we store the transcribed audio in our Spark receiver which triggers the downstream Spark Streaming pipeline.

Pipeline in action:

Note that the speech-to-text library is still fairly brittle and will need some improvements to be fully production-ready. I recommend to start playing with the integration, collecting some issues and then fixing them in bulk.
The feature service seems to be broken/changed recently, so to test the core of this PR, I also needed to make our feature service client more robust to failures. These changes are also included in this PR: we now ignore bad responses from the feature service and we also ignore when we're unable to connect to the feature service. Even if the feature service is down, the rest of the pipeline can still work (just the locations-from-text inference piece won't work) so I assert that it's good to make our pipeline robust to feature service outages.

Addressed all actionable comments from Kevin, now waiting for sign off from @erikschlegel.

Closing this off. Let's revisit the questions around multiple copies of the same stream configured with different parameters as a separate thread.


 Each node maintains its own metric data, but the current implementation only retrieves metrics from the node where the test pod is running.
https://github.com/longhorn/longhorn-tests/blob/master/manager/integration/tests/test_metric.py#L134-L135
Proposed Fix
Ensures the metric is retrieved from the correct node, or check for all nodes instead.

Proposed Fix

Ensures the metric is retrieved from the correct node,
Or, consider checking metrics across all nodes.

After the fix, testing on my cluster passed. However, the pipeline test is still failing.
Debug
Manually accessing the pipeline nodes, it seems the metric does not exist on any nodes.
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  496k    0  496k    0     0  26.3M      0 --:--:-- --:--:-- --:--:-- 26.9M
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  491k    0  491k    0     0  25.4M      0 --:--:-- --:--:-- --:--:-- 26.6M
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  551k    0  551k    0     0  22.6M      0 --:--:-- --:--:-- --:--:-- 23.4M

So I manually executed the following:
instance-manager-2abe201ad9e8e1e94824389c37247020:/ # mount -o remount,ro /host/var/lib/kubelet/plugins/kubernetes.io/csi/driver.longhorn.io/0a07fdb6570cac5e0a1b0a2248a72e093b867d2dc7692ee34f5e981bef28b59d/globalmount/

And this result the expected metrics output:
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  496k    0  496k    0     0  31.7M      0 --:--:-- --:--:-- --:--:-- 32.2M
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  491k    0  491k    0     0  32.9M      0 --:--:-- --:--:-- --:--:-- 34.2M
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0# HELP longhorn_volume_file_system_read_only Volume whose mount point is in read-only mode
# TYPE longhorn_volume_file_system_read_only gauge
longhorn_volume_file_system_read_only{node="ip-10-0-2-130",pvc="pvc-longhorn-testvol-28m2os",pvc_namespace="default",volume="longhorn-testvol-28m2os"} 1
100  552k    0  552k    0     0  45.3M      0 --:--:-- --:--:-- --:--:-- 49.0M

This is an indication that the feature works as expected and there are other areas in the test case that need to be fixed.

Verified pass on longhorn master(https://github.com/longhorn/longhorn-tests/commit/9f65a9df347929a8517708b714e99380f92eeb26)
Perform five times of test case test_metric_longhorn_volume_file_system_read_only result all passed


Duplicate Output

Describe the bug
If logging is used, ORC outputs to multiple streams, which causes the number of ODRVs reported to be doubled.
info: ORC complete.
info:   537 ODRVs reported

becomes:
info: ORC complete.
info:   1074 ODRVs reported

Expected behavior
The problem is straightforward:
++globals::instance()._odrv_count; in std::ostream& operator<<(std::ostream& s, const odrv_report& report) is called twice when there is logging.
But the actual issue IMO is that we have filter logic and side effects in operator<<. operator<< should:

have no side effects
only output - not filter

Fixing this will take some moderate refactoring.

Fixed by: https://github.com/adobe/orc/pull/54


Install make, nano, sqlite into ~/.swc/opt instead of ~/.swc/lib

Seems somewhat more appropriate.  I don't know if there was any specific reason to choose lib/

On Mon, Jun 13, 2016 at 11:30:24AM -0700, Erik Bray wrote:

Seems somewhat more appropriate.  I don't know if there was any
specific reason to choose lib/

I didn't record a reason behind ‘lib’ in 806fedff.  It's hard to pick
a good name when the executable and shared libraries are all unpacked
into the same directory, but I didn't care enough to split them apart
;).
‘lib’ → ‘opt’ works for me, but can you make a new PR for that against
the ‘python’ branch?  This one is against ‘master’.

Sure.  I think /opt is best for questions of "this software is not installed in a unix-like manner!"

Although I have seen lib/ used for that before too.  But it gives me a bad feeling.

I'm going to go ahead and merge this into master since I don't see why it shouldn't be consistent.  But I will hand-merge into the python branch as well.


Can you guide how can I enter into the Lobby with this code? I have the token generated by my own API? How can I pass that token here and start the video ? Not clear with this code.Please help it's urgent ASAP

Hi @abhishekthanvi8, thanks for checking out the app!
This is where the app actually fetches the Twilio access token so that the app can connect to a room.
For the community build accessTokenStore is set to an instance of CommunityTwilioAccessTokenStore. It might be easiest to replace the internals of this with something that makes a request to your API. You can also look at InternalTwilioAccessTokenStore which we use for internal testing.
You may want to make some UI changes to replace the sign in screens at launch with whatever you use for auth.
Let me know if that helps!

Hi @abhishekthanvi8, thanks for checking out the app!
This is where the app actually fetches the Twilio access token so that the app can connect to a room.
For the community build accessTokenStore is set to an instance of CommunityTwilioAccessTokenStore. It might be easiest to replace the internals of this with something that makes a request to your API. You can also look at InternalTwilioAccessTokenStore which we use for internal testing.
You may want to make some UI changes to replace the sign in screens at launch with whatever you use for auth.
Let me know if that helps!

actually I already have the token from my rest api I just want to now which particular particular method is that which I need to call and how to just enter the room I want to skip the Auth part here...so please guide which method to call. may be can you explain in some more detail I will be really grateful to you..

actually I already have the token from my rest api I just want to now which particular particular method is that which I need to call and how to just enter the room I want to skip the Auth part here...so please guide which method to call. may be can you explain in some more detail I will be really grateful to you..

You could modify this line to always use the lobbySeque to skip auth. This should get you to the lobby screen.
To set the access token you can modify this line. Or you can provide your own implementation of the access token store as described above.

You could modify this line to always use the lobbySeque to skip auth. This should get you to the lobby screen.
To set the access token you can modify this line. Or you can provide your own implementation of the access token store as described above.

I have integrated this code in my app..and I have token an room type available with me what is the straight forward method where I can pass this token and room type and I am ready to go....
Also I am facing a crash on this below code when I call the launchFlow
var appInfo: AppInfo {
        AppInfo(
            appCenterAppSecret: bundle.object(forInfoDictionaryKey: "AppCenterAppSecret") as! String,
            version: bundle.object(forInfoDictionaryKey: "CFBundleShortVersionString") as! String,
            build: bundle.object(forInfoDictionaryKey: "CFBundleVersion") as! String,
            target: AppInfo.Target(rawValue: bundle.object(forInfoDictionaryKey: "TargetName") as! String)!
        )
    }

I have integrated this code in my app..and I have token an room type available with me what is the straight forward method where I can pass this token and room type and I am ready to go....
Also I am facing a crash on this below code when I call the launchFlow
var appInfo: AppInfo {
        AppInfo(
            appCenterAppSecret: bundle.object(forInfoDictionaryKey: "AppCenterAppSecret") as! String,
            version: bundle.object(forInfoDictionaryKey: "CFBundleShortVersionString") as! String,
            build: bundle.object(forInfoDictionaryKey: "CFBundleVersion") as! String,
            target: AppInfo.Target(rawValue: bundle.object(forInfoDictionaryKey: "TargetName") as! String)!
        )
    }

@timrozum  Can you please help me with this..It's a urgent for me

@timrozum  Can you please help me with this..It's a urgent for me

Hi @abhishekthanvi8,
The crash may be caused by the AppCenterAppSecret key not being defined in your app's info.plist. You could either add the key as an empty string to info.plist or edit this code to just remove the appCenterAppSecret parameter.
Room type is handled by the backend and not the app. See this doc for how to configure room type with your API or the Twilio Console.
Regarding the Twilio access token, this is where it is set when we connect to a room. It sounds like you will need to modify this area of code to meet the needs of your app. Replacing the internals of CommunityTwilioAccessTokenStore may work well.
I hope this helps.

Hi @abhishekthanvi8,
The crash may be caused by the AppCenterAppSecret key not being defined in your app's info.plist. You could either add the key as an empty string to info.plist or edit this code to just remove the appCenterAppSecret parameter.
Room type is handled by the backend and not the app. See this doc for how to configure room type with your API or the Twilio Console.
Regarding the Twilio access token, this is where it is set when we connect to a room. It sounds like you will need to modify this area of code to meet the needs of your app. Replacing the internals of CommunityTwilioAccessTokenStore may work well.
I hope this helps.

but where should i call this function
  let options = self.connectOptionsFactory.makeConnectOptions(
                accessToken: accessToken,
                roomName: roomName,
                audioTracks: [self.localParticipant.micTrack].compactMap { $0 },
                videoTracks: [self.localParticipant.localCameraTrack].compactMap { $0 }
            )
            self.room = self.twilioVideoSDKType.connect(options: options, delegate: self)

but where should i call this function
  let options = self.connectOptionsFactory.makeConnectOptions(
                accessToken: accessToken,
                roomName: roomName,
                audioTracks: [self.localParticipant.micTrack].compactMap { $0 },
                videoTracks: [self.localParticipant.localCameraTrack].compactMap { $0 }
            )
            self.room = self.twilioVideoSDKType.connect(options: options, delegate: self)

I removed appCenterAppSecret from paramters now it is not crashing
Now when i run below code nothing happens LobbyViewController is not opened with below code. Please help
 var launchFlow: LaunchFlow?
            var launchFlowFactory: LaunchFlowFactory = LaunchFlowFactoryImpl()
            var launchStoresFactory: LaunchStoresFactory = LaunchStoresFactoryImpl()
            var urlOpenerFactory: URLOpenerFactory = URLOpenerFactoryImpl()
            var userActivityStoreFactory: UserActivityStoreFactory = UserActivityStoreFactoryImpl()
            var window: UIWindow?

        window = UIWindow(frame: UIScreen.main.bounds)
                   launchFlow = launchFlowFactory.makeLaunchFlow(window: window!)
                   launchFlow?.start()

I removed appCenterAppSecret from paramters now it is not crashing
Now when i run below code nothing happens LobbyViewController is not opened with below code. Please help
 var launchFlow: LaunchFlow?
            var launchFlowFactory: LaunchFlowFactory = LaunchFlowFactoryImpl()
            var launchStoresFactory: LaunchStoresFactory = LaunchStoresFactoryImpl()
            var urlOpenerFactory: URLOpenerFactory = URLOpenerFactoryImpl()
            var userActivityStoreFactory: UserActivityStoreFactory = UserActivityStoreFactoryImpl()
            var window: UIWindow?

        window = UIWindow(frame: UIScreen.main.bounds)
                   launchFlow = launchFlowFactory.makeLaunchFlow(window: window!)
                   launchFlow?.start()

It's difficult for me to determine how this modified code is executed. Did you remove SceneDelegate support completely (the code further below in AppDelegate and
Application Scene Manifest in info.plist)? Either way there might be an an easier way about this.
The launch sequence in this app may be more complicated than you need for a variety of reasons. This app has to support both public and internal build variants and also has some special paths to exercise specific video SDK features.
It might be easiest to start with the default AppDelegate that Xcode provides and just insert and rework the code below directly inside of AppDelegate. It should only require a little rework like skipping the sign in screen. In fact you could probably also just change what screen is the root view controller on the storyboard to avoid having to perform any segue at all.
        let storyboard = UIStoryboard(name: "Main", bundle: nil)
        window.rootViewController = storyboard.instantiateInitialViewController()
        window.makeKeyAndVisible()

        let navigationController = window.rootViewController as! UINavigationController
        navigationController.barHideOnSwipeGestureRecognizer.isEnabled = false
        navigationController.hidesBarsOnSwipe = false

        let segueIdentifier = authStore.isSignedIn ? "lobbySegue" : signInSegueIdentifierFactory.makeSignInSegueIdentifier()
        navigationController.topViewController?.performSegue(withIdentifier: segueIdentifier, sender: self)

Sorry there is not a cleaner interface between the somewhat complex launch sequence of this app and the display of the lobby screen. That is something we can consider improving.
However, I'm hoping the above idea may help you make progress.

It's difficult for me to determine how this modified code is executed. Did you remove SceneDelegate support completely (the code further below in AppDelegate and
Application Scene Manifest in info.plist)? Either way there might be an an easier way about this.
The launch sequence in this app may be more complicated than you need for a variety of reasons. This app has to support both public and internal build variants and also has some special paths to exercise specific video SDK features.
It might be easiest to start with the default AppDelegate that Xcode provides and just insert and rework the code below directly inside of AppDelegate. It should only require a little rework like skipping the sign in screen. In fact you could probably also just change what screen is the root view controller on the storyboard to avoid having to perform any segue at all.
        let storyboard = UIStoryboard(name: "Main", bundle: nil)
        window.rootViewController = storyboard.instantiateInitialViewController()
        window.makeKeyAndVisible()

        let navigationController = window.rootViewController as! UINavigationController
        navigationController.barHideOnSwipeGestureRecognizer.isEnabled = false
        navigationController.hidesBarsOnSwipe = false

        let segueIdentifier = authStore.isSignedIn ? "lobbySegue" : signInSegueIdentifierFactory.makeSignInSegueIdentifier()
        navigationController.topViewController?.performSegue(withIdentifier: segueIdentifier, sender: self)

Sorry there is not a cleaner interface between the somewhat complex launch sequence of this app and the display of the lobby screen. That is something we can consider improving.
However, I'm hoping the above idea may help you make progress.

Thanks @timrozum  I was able to integrate it successfully by myself..but thanks for your precious time. :)

Thanks @timrozum  I was able to integrate it successfully by myself..but thanks for your precious time. :)

That is great to hear and you're welcome!

That is great to hear and you're welcome!


Adding Getting Started section.

Minor improvement to the README.

This could be further improved with updated screenshots with the new UI from #29, using the preferences from #32, and a step-by-step guide to getting a schema.

One last recommendation here: can you explain a situation where you'd actually need the .zip file to run the code? Is it just a byproduct of the release?

The two source code archives are part of the release process for Github.


fix(checkbox): support native tabindex attribute

Currently the checkbox only allows changing the tabIndex using the tabIndex binding. Using the native tabindex attribute doesn't have any affect. With this change the native tabindex property will be respected.
References #6465

@tinayuangao PTAL


gNMI-1.4: Added deviation for fanOperStatusUnsupported

Added deviation for fanOperStatusUnsupported cases where device does not support oper-status leaf for some of the fan components

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 55.741%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1170

Relevant Lines:
2099

💛  - Coveralls

/gcbrun

/gcbrun

/gcbrun

/gcbrun

/gcbrun


[Question] Better development setup instruction

Operating System: Windows 10 64 bit
I was trying to setup a dev environment on windows and there is a problem when following the instruction from the readme.
Running npm run bootstrap gives unknown error (no vcbuild.exe in verbose mode), and the final solution (taken from here) is to run
npm install -g --production windows-build-tools

Is it obvious to someone who does electron development?
If so, close this issue ;) If not, please include it in the readme

Great suggestion! Just added it to the README


Open source licence

This is great! Could you please add an open source licence to the repo so we know that we can use it without worrying about software licensing? Thanks :pray:

Have done, will close issue 🙂


Original code design, extended using the same structures, to add use of BME280 sensor

Here are the files discussed, arriving as you suggested, by my pushing them to my fork, then issuing a pull request to your repository - indeed, I was presented with a choice of branch and so am directing this to your new BME280 branch.

Thanks for the contribution @425629 !


BuildTestCommand should not use shell=True

Currently, buildtest.tools.system.BuildTestCommand issues a command to the host with shell=True
        self.ret = subprocess.Popen(
            cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.PIPE
        )

From what I've read, this should be avoided - we can likely compensate for expanding envars / other features of having the shell through other measures.

Yea i know shell=True is a security vulnerability and yes if there is an alternative to running shell commands i would be for it. The code would need to be refactored as i recall BuildTestCommand is used in several places.

Note: we will also need to update the command in spider.py to use this. Comment here https://github.com/HPC-buildtest/buildtest-framework/pull/181#pullrequestreview-364382563

I'd like to work on this after the class refactor for the types, which is a larger chunk of work.

Sounds good with me.

This is fixed in #219


⚠ Bofrost.at has degraded performance

In f0ac074, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2139 ms

Resolved: Bofrost.at performance has improved in c3a026d.


fix(pilota-build): use prefixed field_id to support field_id as field identifier

Motivation
The use of field_id as variable in the field decode codgen causes a conflict with Parquet's Thrift file (it has a struct with a field named field_id).
Solution
This PR modifies the codegen to use a prefixed variable to support fields with field_id as identifier.

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

Thank you very much for your contribution! Could you please sign the CLA, and after that we can merge this?


'Window': Request cannot be constructed

main-b988c55a89aca51c.js:1 Uncaught (in promise) TypeError: Failed to execute 'fetch' on 'Window': Request cannot be constructed from a URL that includes credentials: /_next/data/eo0pNmiwooIdaYWXKre6v/output.json
at K (main-b988c55a89aca51c.js:1:56759)
at d (main-b988c55a89aca51c.js:1:57382)
at J (main-b988c55a89aca51c.js:1:58253)
at main-b988c55a89aca51c.js:1:70134
at main-b988c55a89aca51c.js:1:116138
at Object.next (main-b988c55a89aca51c.js:1:116243)
at r (main-b988c55a89aca51c.js:1:882)
at u (main-b988c55a89aca51c.js:1:1087)
at main-b988c55a89aca51c.js:1:1146
at new Promise ()

output of command
node -v


the search icon isn't aligned

I find the search icon isn't aligned.
My device:13-inch MacBook Pro, macOS Monterey

I also find the problem, how can we fix that?

I've just shipped an update to the Paper Theme, that fixes this issue.
@Ben9706 @huanhuan129