It would be nice to have Harbor registry supported

Hello,
I am not aware if someone here uses Harbor as a private registry but I assume that it would be a nice feature to add that one also into the list described here - https://argocd-image-updater.readthedocs.io/en/latest/configuration/registries/#configuring-a-custom-container-registry
I currently trying to test ArgoCD with my private Harbor registry and wasn't able to pull images/charts from it.
If there is some other way to include Harbor to be used at the custom registry, so Argo can point to it, please advise me.
Thanks for review this ticket!
Sincerely,
Igor

Hey @Igor992, have you tried configuring your Harbor registry in the registries.conf? If yes, what did not work?

Hey @jannfis, this was my mistake with configuration a fresh new k8s cluster, somehow I forgot to add my private registry into the service account. Gladly ArgoCD provides good logs output and I was able to see what is missing there.
Thanks for the reply tho, keep doing a great job with Argo.
Sincerely,
Igor

Hey @Igor992, I know its been a long time since this issue was closed but can you please help with the registries.conf for harbor. We have the configmap but failing with the below error :
registries.conf: |
    registries:
    - name: Harbor registry
      api_url: https://harbor.example.net
      credentials: pullsecret:argocd/regcred
      ping: no

and the logs says :
time="2021-11-30T10:14:39Z" level=error msg="Could not get registry endpoint from configuration: no registry with prefix 'harbor.example.net' configured" alias= application=backend-example-dev image_name=backend-example/development image_tag=latest registry=harbor.example.net

Hello @vishnuhd, I can't tell what is the problem here is from this "short" stderr output, but maybe you can use this trick to debug it further on the container itself.
https://github.com/argoproj-labs/argocd-image-updater/issues/204#:~:text=%24 ./dist/argocd-image-updater test public.ecr.aws/nginx/nginx --registries-conf registries.conf
There should be some FATA[0001] output code for problems that you have.
I hope this helps with your needs.
Sincerely,
Igor

@vishnuhd You will need to set the appropriate prefix in your registries.conf, i.e.
registries.conf: |
    registries:
    - name: Harbor registry
      prefix: harbor.example.net
      api_url: https://harbor.example.net
      credentials: pullsecret:argocd/regcred
      ping: no


Add drop to angular events

Hi, i am using an handler for the native drop event in my application, and i wrote a directive for that.
Looking at the problem later, i realised that a good directive would probably have the same appearance of the "standard" angular directives handling events, and thus i think that drop should be added to the list of auto-generated event handling directives.
This looks like a quick win, but i am having some troubles running the test suite, so i write the issue in order to have feedback from others before investing more time

Will be fixed by https://github.com/angular/angular.js/pull/16614


ci: merge staging to master

This is an automatic PR generated by the pipeline CI/CD. This will be automatically fast-forward merged if successful.

Pipeline Attempt on 945506984 for 612c7a3b705b3d971a07edd6ff461e786ccba154
https://gitlab.com/MatrixAI/open-source/js-mdns/-/pipelines/945506984

Pipeline Succeeded on 945506984 for 612c7a3b705b3d971a07edd6ff461e786ccba154
https://gitlab.com/MatrixAI/open-source/js-mdns/-/pipelines/945506984


Update documentation to reflect that it can now be cancelled

Now $.stillAlive returns a pointer to the returned value from setInterval, so you can say
var thing = $.stillAlive(update);
/* ... some stuff happens */
clearInterval(thing);

to stop the recurrence of update.

No...


proychains but not for some addons

Hello!
I was wondering if there are ways to obtain better control over how addon are launched and their environement.
I am using a transparent proxy + proxychains setup but I would like for some of my addons to access the network without going trough proxychains. I only want the outgoing mitmproxy request to go trough proxychains.
Would it be possible to launch only the mitmproxy component that makes the final request inside the "proxychains scope" and the rest outside of it? Is there a way to configure mitmproxy that would allow for that?
Thanks for the amazing software, cheers!

TL;DR: No.
That sounds like a proxychains question and not so much of a mitmproxy question? I guess you could maybe flip your setup and have proxychains first and then mitmproxy in upstream mode? Mitmproxy addons are just launched within the mitmproxy Python process. I don't think there's anything you could do to escape a proxychains setup.

That sounds like a proxychains question and not so much of a mitmproxy question?

I just wanted to make sure that I wasn't unaware of a mitmproxy feature allowing for this.

guess you could maybe flip your setup and have proxychains first and then mitmproxy in upstream mode

Yeah, I setup something similar to this.
Thanks for the response, I'll close this!


Fixed a deadlock issue that could occur when RialtoServer died while RialtoServerManager was waiting for a reply from it

Summary: Fixed a deadlock issue that could occur when RialtoServer died while RialtoServerManager was waiting for a reply from it
Type: Fix
Test Plan: Unittests, YT conformance tests, Manual Tests
Jira: RIALTO-520

https://jenkins.code.rdkcentral.com/job/build-component/89467/ started.

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/github-triggered/14978/ started

Job for AI/job/AI_BUILDS/job/AI-Trigger-PullRequests started: https://pv-jen015.uk2.scp.bskyb.com/job/AI/job/AI_BUILDS/job/AI-Trigger-PullRequests/268/

Sanity tests for ['RPI4 Mediaclient'] added.
https://jenkinsrdkm.cmf.code.rdkcentral.com/job/test-components-flow/41686/

Sanity tests for ['BCM Reference Refapp2'] added.
https://jenkinsrdkm.cmf.code.rdkcentral.com/job/test-components-flow/41688/

Job for AI/job/AI_BUILDS/job/AI-Trigger-PullRequests started: https://pv-jen015.uk2.scp.bskyb.com/job/AI/job/AI_BUILDS/job/AI-Trigger-PullRequests/270/

https://jenkins.code.rdkcentral.com/job/github-triggered/50206/ started

https://jenkins.code.rdkcentral.com/job/build-component/89523/ started.

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/build-component-platform/21813/ started.

Job for AI/job/AI_BUILDS/job/AI-Trigger-PullRequests started: https://pv-jen015.uk2.scp.bskyb.com/job/AI/job/AI_BUILDS/job/AI-Trigger-PullRequests/271/

https://jenkinsrdkm.cmf.code.rdkcentral.com/job/github-triggered/15050/ started

https://jenkins.code.rdkcentral.com/job/github-triggered/50208/ started

https://jenkins.code.rdkcentral.com/job/build-component/89524/ started.

Sanity tests for ['BCM Reference Refapp2'] added.
https://jenkinsrdkm.cmf.code.rdkcentral.com/job/test-components-flow/41824/


Add Codepen Examples for JS Frameworks

Angular and Vue

Closing this; soon we will be adding StackBlitz examples (based on https://github.com/foursquare/unfolded-sdk-examples/pull/57#issuecomment-1485430806, and recently we decided internally to use StackBlitz over alternatives (CodePen or CodeSandbox).


User interaction notebook demo

Description
Notebook selects watershed from Ipyleaflet WFS plugin accessing GeoServer layer, selects weather data set
from THREDDS server using JupyterLab extension, runs RAVEN using an input form and displays the results
as interactive plotly graphic.
Environment

Raven version used, if any:
Python version, if any:
Operating System:

Steps to Reproduce
Paste the command(s) you ran and the output.

Additional Information
Links to other issues or sources.

@huard Should we ask CRIM to work on this? Especially the leaflet and input form objects?

The first part is done and integrated into birdy (show watersheds for WFS plugin).
There are issues already opened for the climate data catalog.
We could work on creating a form to launch Raven.

@huard we now have a Full_process_example notebook that uses the ipyleaflet to select a basin and essentially builds and runs raven on some provided data, and analyzes it... Not sure how forms work, but we'd be ready to just pop some forms in there and this would be done.

@huard is this something that can now be done with the solving of previous issues? Is it even necessary?

Current setup is OK


Fixed bug for dark theme in nav bar

Description 📝
Fixed the bug of hover effect in Nav bar in dark mode

Fixes/Closes: #199
Checklist ✅

[x] Reviewed the code changes thoroughly.
[x] Tested the changes locally and ensured they work as expected.
[x] Updated relevant documentation.
[x] Added appropriate test cases, if applicable.
[x] Considered potential security or performance implications.
[x] Code adheres to the project's style guidelines.
[x] Addressed all reviewer comments and concerns, if any.

Screenshots (if applicable)
https://github.com/PiyushKalyanpy/GyanaGuru/assets/115401171/c1ee9e02-7759-4c96-ad53-e5d1db7dac14
I am a GSSoC contributor so please add labels and level in this PR

@PiyushKalyanpy done ! could you add required Gssoc labels/ level and assignee


[urllib3.connectionpool] Connection pool is full

Hi,
once I install this addon (latest version) and configure my FB 6490 via the Integrations, I get continuously the following warning msg. in HA logs (approx. every 30 seconds).
I did research already a bit over the web but related issues did not really help me further.
Thanks!

Did you try rebooting the host machine? Looks like a strange issue

Hi,
unfortunately, does not solve the issue. Uninstalled your addon completely thru HACS, restarted HA and then rebooted my Host.
Afterwards I installed the addon again, restarted HA and added the related integration for my FB. Once done, logs get full again.
I am running HA 116.4 from @fredrike inside Docker 18.09 on a Synology DS (latest DSM).
Your addon used to work just fine but since yesterday and suddenly I face this warning and it comes along really often. No clue why.
Logger: urllib3.connectionpool Source: /usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py:303 First occurred: 8:19:53 AM (22 occurrences) Last logged: 8:30:53 AM Connection pool is full, discarding connection: <IP_ADDRESS>
Any chance to increase the value? I am referring to: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#customizing-pool-behavior
Thanks.

I don't think that we're directly using urrlib3, but rather fritzbox connection and/or HA. :smirk:

I don't think that we're directly using urrlib3, but rather fritzbox connection and/or HA. 😏

I've seen similar issues with the Daikin integration in HA. Have a look at how it is handled from the integration side in HA.
The problem is that you are using too many integrations @iHaveAstream, but it is fixable by building the integrations a bit smarter.

Thanks for the hint, @fredrike! I'm gonna take a look into my integrations.
Indeed it could be and for some reason I believe it's somehow related to the AdGuard integration that I added just recently.
Because before that, I did not have issues with the FritzBox Tools addon/integrations...
However, ideally I can operate both in some way.

@iHaveAstream you could try disabling the features of the integration that you're not using (eg. Profile switches) to reduce the number of outgoing requests.

@iHaveAstream you could try disabling the features of the integration that you're not using (eg. Profile switches) to reduce the number of outgoing requests.

Did already try that out but did not really help. I'm gonna try further. Thanks for the support so far, much appreciated!

No... no matther what I do with regards to other integrations, the log warnings appear immediately once the FritzBox Tools integration is enabled (connected to my FB).

OK, I could get things sorted...
My issue is in fact related to the portforwarding entities which the integration supports.
In ttl. I've eight portforwarding rules set in my FB, whereof four are currently active. When I disable two of them as entities, doesn't matter which ones, the warnings are immediately stopped. When I disable just one, the warnings still appear, not every 30s, but every 60s.
No clue if you'd like to look further into this @mammuth ... in case not, I can close this one here as I can "live" with this "limitation".
Thanks!

My issue is in fact related to the portforwarding entities which the integration supports.
In ttl. I've eight portforwarding rules set in my FB, whereof four are currently active. When I disable two of them as entities, doesn't matter which ones, the warnings are immediately stopped. When I disable just one, the warnings still appear, not every 30s, but every 60s.

Confirmed, with 2 entities enabled all is fine, with 4 I have the same issue.
I disabled them from HA not from FB.
Simone

i also have this kind of error, i have only one port forward and i use adguard
Logger: urllib3.connectionpool
Source: /usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py:304
First occurred: 17 dicembre 2020, 22:29:26 (3192 occurrences)
Last logged: 21:19:31
Connection pool is full, discarding connection: <IP_ADDRESS>

Same error message. Started also since I added an aditional port forward.

Same error message. Started also since I added an aditional port forward.

Should be solved in the new core integration.
Just wait for 2021.7.0 :-)
Simone

Hello Simone. I just upgraded to  2021.7.0 and unfortunately I started to see these warnings in pairs every 30s. Similar to @iHaveAstream i also have a set of port forwards active in my FB.
I don't see any stack, just the warning lines with the IP of my Fritz!Box:
2021-07-08 17:17:02 WARNING (SyncWorker_2) [urllib3.connectionpool] Connection pool is full, discarding connection: <IP_ADDRESS>
2021-07-08 17:17:02 WARNING (SyncWorker_0) [urllib3.connectionpool] Connection pool is full, discarding connection: <IP_ADDRESS>
2021-07-08 17:17:32 WARNING (SyncWorker_8) [urllib3.connectionpool] Connection pool is full, discarding connection: <IP_ADDRESS>
2021-07-08 17:17:32 WARNING (SyncWorker_1) [urllib3.connectionpool] Connection pool is full, discarding connection: <IP_ADDRESS>
2021-07-08 17:18:02 WARNING (SyncWorker_9) [urllib3.connectionpool] Connection pool is full, discarding connection: <IP_ADDRESS>
2021-07-08 17:18:02 WARNING (SyncWorker_9) [urllib3.connectionpool] Connection pool is full, discarding connection: <IP_ADDRESS>

This custom integration is now deprecated because is fully merged into HomeAssistant core.
I would suggest you configure the new integration and retest your issue.
After reading the documentation, if still present then open a issue on HomeAssistant Core repository.
Simone

Thanks for you quick feedback. Looks like a little chicken-and-egg issue, as this 2day old comment directed me to this issue now getting directed back


Options

Here we go!

????? :) What's this about?

@zaydek Shhhh! 😎

sanko it's live: https://about.robinhood.com/options/#waitlist

I have the endpoints. I was told it would be late January so I haven't documented it yet. Busy week for us. AMA on Reddit later today, tv interviews, the whole nine yards.

Wait so do you work at Robinhood now or what? @sanko

@sanko do you know when the options endpoints will be documented?  I'd be happy to help.

Yes, I do and no thanks.

For anyone interested in the options api ... https://github.com/mstrum/robinhood-python/blob/master/robinhood/RobinhoodClient.py#L2219


Disable Search Box if CDN is down (#14, #9)

Should help fixing #9 and be a potentially help for #14.

Turns out I think this PR is more related to #9, since #14 is still happening.

since #14 is still happening.

What's the error / stack trace you're seeing in the console after these changes have been made?

What's the error / stack trace you're seeing in the console after these changes have been made?

The same from before:

Ah, I see. I thought before that you were getting an error about docsearch being undefined but I see that was actually reported by another person.

Turning the Cookie button "On" works for me, (which is bizarre since #14 is related to enabling it).
I'm not sure if it helps, but we it's good to consider that Cookie Whitelist is Legacy add-on:

I'm changing the PR name to point to #9.


Macro: The system allows you to paste on canvas while modifying nucleotides in the RNA builder

Steps to Reproduce

Switch to Macro mode -> Sequence mode
Add any RNA/DNA letters
Select two and copy by CTRL+C
Select any, right-click and select 'Modify in RNA Builder'
Press CTRL+V

Actual behavior
The system allows you to paste on canvas while modifying nucleotides in the RNA builder
Expected behavior
The system should not allow you to paste on canvas while modifying nucleotides in the RNA builder
Screenshots/Videos
https://github.com/epam/ketcher/assets/62464241/1d0b0c1b-5676-4daa-9581-4f5c03fbb123
Desktop (please complete the following information):

OS: Windows 11
Browser Chrome
Version 123.0.6312.106 (Official Build) (64-bit)

Ketcher version
[Version 2.21.0-rc.1]
Bug registered after testing: https://github.com/epam/ketcher/issues/3824

The issue has been moved from 2.21.0-rc.2 to 2.22.0-rc.1 after discussion with management and in accordance with the testing flow process.

The system also allows users to launch the Text-editing mode by pressing the Enter key, where new sequences can be added

Verified.
Windows 10
Chrome Version 125.0.6422.142 (Official Build) (64-bit)
Ketcher Version 2.21.0-rc.2 Build at 2024-06-03; 05:33:52
Indigo Toolkit Version 1.21.0-dev.5.4-gb45d44aa-wasm32-wasm-clang-12.0.0


BUG: sparse: load_npz is failing with numpy master

See the Travis test from an unrelated PR: https://travis-ci.org/scipy/scipy/builds/233577623
All of the scipy.sparse.load_npz tests are failing, with the following error:
======================================================================
ERROR: test_matrix_io.test_save_and_load_random
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.5.2/lib/python3.5/site-packages/scipy/sparse/_matrix_io.py", line 121, in load_npz
    cls = getattr(scipy.sparse, '{}_matrix'.format(matrix_format))
AttributeError: module 'scipy.sparse' has no attribute ''csc'_matrix'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.5.2/lib/python3.5/site-packages/nose/case.py", line 198, in runTest
    self.test(*self.arg)
  File "/home/travis/virtualenv/python3.5.2/lib/python3.5/site-packages/scipy/sparse/tests/test_matrix_io.py", line 34, in test_save_and_load_random
    _check_save_and_load(dense_matrix)
  File "/home/travis/virtualenv/python3.5.2/lib/python3.5/site-packages/scipy/sparse/tests/test_matrix_io.py", line 23, in _check_save_and_load
    loaded_matrix = _save_and_load(matrix)
  File "/home/travis/virtualenv/python3.5.2/lib/python3.5/site-packages/scipy/sparse/tests/test_matrix_io.py", line 15, in _save_and_load
    loaded_matrix = load_npz(tmpfile)
  File "/home/travis/virtualenv/python3.5.2/lib/python3.5/site-packages/scipy/sparse/_matrix_io.py", line 123, in load_npz
    raise ValueError('Unknown matrix format "{}"'.format(matrix_format))
ValueError: Unknown matrix format "'csc'"

The matrix_format variable is read directly from an .npz file, so something must have changed in either np.savez or np.load to produce extra quote characters.

Numpy bug? Doesn't sound intentional change.
.
Also, the call to np.load in load_npz certainly should use
allow_pickle=False (needs to check if the numpy version is new enough).

Seems to be https://github.com/numpy/numpy/pull/8983, although why is another question...

This change seems relevant:
With numpy 1.12.1:
In [134]: np.__version__
Out[134]: '1.12.1'

In [135]: print(np.array('foo'))
foo

With numpy master branch:
In [5]: np.__version__
Out[5]: '1.14.0.dev0+1ec9ad6'

In [6]: print(np.array('foo'))
'foo'

There are now single quotes in the output.

Should be fixed by gh-7419 I think. The reliance on how numpy formats bytes scalars to unicode strings is a bit shady and best removed.


Airbrake error fallback

Fallback to msg in airbrake hook if:

no error was provided (or it wasn't an error type)
msg is an error type

For convenience since often msg will just contain the anyways.
Also fixes a panic if error was not an error.

I'll close this since it's been here forever.


Could any help me to have a look why tide http server is slow than NodeJS http server, plz :)

I wrote 2 performance testing minimal HTTP servers, one for tide (1.6) and one for Node.JS, what I expect is that the tide one should faster than the Node.JS one. But the result is the opposite..., anyone has a try on this?:)
Testing environment:
macOS 10.14.6
Intel(R) Core(TM) i5-8500 CPU @ 3.00GHz [ 6 cores ]
rustc 1.50.0 (cb75ad5db 2021-02-10)

Here are the source code for both versions:

benchmark_server.js
benchmark_server.rs

Both HTTP server have the same routes and responses below:

HTML response (Benchmark testing) for the default route /:

JSON response for the /json-benchmark route:
{
    "name":"Wison Ye",
    "role":"Administrator",
    "settings":{
        "prefer_language":"English",
        "reload_when_changed":true
    }
}

Here is my ulimit -a output:
Maximum size of core files created                           (kB, -c) 0
Maximum size of a processճ data segment                     (kB, -d) unlimited
Maximum size of files created by the shell                   (kB, -f) unlimited
Maximum size that may be locked into memory                  (kB, -l) unlimited
Maximum resident set size                                    (kB, -m) unlimited
Maximum number of open file descriptors                          (-n) 1000000
Maximum stack size                                           (kB, -s) 8192
Maximum amount of cpu time in seconds                   (seconds, -t) unlimited
Maximum number of processes available to a single user           (-u) 3546
Maximum amount of virtual memory available to the shell      (kB, -v) unlimited

Here is the test result:

NodeJS version:
recreate node project:
npm init -y
// copy the `benchmark_server.js` to current folder
npm install restify restify-errors

node --version
# v14.16.0

Node spwan 6 cluster workers to serve:
node benchmark_server.js

# setupMaster Cluster worker amount: 6
# setupMaster Cluster worker "1" (PID: 10719) is online.
# setupMaster Cluster worker "3" (PID: 10721) is online.
# setupMaster Cluster worker "2" (PID: 10720) is online.
# setupMaster Cluster worker "4" (PID: 10722) is online.
# setupMaster Cluster worker "5" (PID: 10723) is online.
# setupMaster Cluster worker "6" (PID: 10724) is online.
# run Worker Process 3 (PID: 10721) |  "Benchmark Http Server" is running at http://<IP_ADDRESS>:8080
# setupMaster Cluster worker "3" (PID: 10721) is listening on <IP_ADDRESS>:8080.
# run Worker Process 2 (PID: 10720) |  "Benchmark Http Server" is running at http://<IP_ADDRESS>:8080
# setupMaster Cluster worker "2" (PID: 10720) is listening on <IP_ADDRESS>:8080.
# run Worker Process 6 (PID: 10724) |  "Benchmark Http Server" is running at http://<IP_ADDRESS>:8080
# setupMaster Cluster worker "6" (PID: 10724) is listening on <IP_ADDRESS>:8080.
# run Worker Process 1 (PID: 10719) |  "Benchmark Http Server" is running at http://<IP_ADDRESS>:8080
# setupMaster Cluster worker "1" (PID: 10719) is listening on <IP_ADDRESS>:8080.
# run Worker Process 4 (PID: 10722) |  "Benchmark Http Server" is running at http://<IP_ADDRESS>:8080
# setupMaster Cluster worker "4" (PID: 10722) is listening on <IP_ADDRESS>:8080.
# run Worker Process 5 (PID: 10723) |  "Benchmark Http Server" is running at http://<IP_ADDRESS>:8080
# setupMaster Cluster worker "5" (PID: 10723) is listening on <IP_ADDRESS>:8080.

# `/` default route
wrk --thread 8 --connections 5000 --duration 10s --latency http://<IP_ADDRESS>:8080/

Running 10s test @ http://<IP_ADDRESS>:8080/
  8 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     7.21ms    7.06ms 165.76ms   90.33%
    Req/Sec    10.55k     5.94k   40.11k    80.46%
  Latency Distribution
     50%    5.57ms
     75%    9.21ms
     90%   14.07ms
     99%   31.48ms
  769416 requests in 10.06s, 151.16MB read
  Socket errors: connect 0, read 1251, write 0, timeout 0
Requests/sec:  76466.35
Transfer/sec:     15.02MB

# `/json-benchmark` route
wrk --thread 8 --connections 5000 --duration 10s --latency http://<IP_ADDRESS>:8080/json-benchmark

Running 10s test @ http://<IP_ADDRESS>:8080/json-benchmark
  8 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     8.45ms    8.56ms 327.08ms   92.21%
    Req/Sec     9.94k     4.52k   28.71k    73.51%
  Latency Distribution
     50%    6.66ms
     75%    9.82ms
     90%   15.27ms
     99%   34.71ms
  729305 requests in 10.06s, 206.57MB read
  Socket errors: connect 0, read 1488, write 3, timeout 0
Requests/sec:  72481.25
Transfer/sec:     20.53MB

Rust version:
recreate node project:
cargo new benchmark

# Add the dependencies to `Cargo.toml`:
tide = "~0.15"
async-std = { version = "1.8.0", features = ["attributes"] }
async-trait = "^0.1.41"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0

# Build release version
cargo build --bin benchmark_server --release

./target/release/benchmark_server
[ Benchmark Server Demo ]

Benchmark Server is listening on: <IP_ADDRESS>:8080

# `/` default route
wrk --thread 8 --connections 5000 --duration 10s --latency http://<IP_ADDRESS>:8080/

Running 10s test @ http://<IP_ADDRESS>:8080/
  8 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    10.16ms    6.56ms 228.77ms   69.81%
    Req/Sec     8.15k     5.77k   42.38k    88.54%
  Latency Distribution
     50%    9.14ms
     75%   14.20ms
     90%   17.50ms
     99%   23.26ms
  577136 requests in 10.08s, 73.82MB read
  Socket errors: connect 0, read 1493, write 3, timeout 0
Requests/sec:  57266.86
Transfer/sec:      7.32MB

# `/json-benchmark` route
wrk --thread 8 --connections 5000 --duration 10s --latency http://<IP_ADDRESS>:8080/json-benchmark

Running 10s test @ http://<IP_ADDRESS>:8080/json-benchmark
  8 threads and 5000 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    11.39ms    5.93ms 216.63ms   66.60%
    Req/Sec     7.73k     3.47k   24.06k    67.97%
  Latency Distribution
     50%   10.51ms
     75%   15.89ms
     90%   18.91ms
     99%   22.02ms
  573039 requests in 10.08s, 119.74MB read
  Socket errors: connect 0, read 1120, write 0, timeout 0
Requests/sec:  56862.43
Transfer/sec:     11.88MB

Maybe same to this issue #781

Maybe same to this issue #781

So it means I need to wait for the next fix? as your PR didn't merge yet.
Or any workaround I can use at this moment? plz :)

try this. Use this patch to your  Cargo.toml.
[patch.crates-io]
tide = { git = 'https://github.com/fiag/tide.git', branch='tcp-nodelay' }

try this. Use this patch to your Cargo.toml.
[patch.crates-io]
tide = { git = 'https://github.com/fiag/tide.git', branch='tcp-nodelay' }

Hi flag, thanks for the patch, and actually .... the result is quite funny...:)
After adding your patch to Cargo.tom, I run:
# Actually I also delete the `Cargo.Lock` file
cargo update
cargo clean && cargo build --bin benchmark_server --release

So I run the release version and test it again:

After that, test the node version again:

And here is the result, I took a screenshot and then align them together which easier to compare:

As you can see above, the Rust  SHOULD fast than the node version, as the latency is low and balabala... which highlighted in the green colour. But somehow the node version can handle a lot of connections than the Rust one. That's why the Final result shows the node version got more throughput... (And btw, I use my iMac to run the above test, that's why the result is different from the very beginning when I created this issue which runs on my MacBookPro).
I've already considered that the Node version spawns a few child processes (even the ps command shows it got the same Thread amount with the rust binary), but tide use async-std which means it still spawns the same number of threads (with my CPU core amount), as the ASYNC_STD_THREAD_COUNT does that by default. Also, async-std uses the Rust Async model which should be efficient than the normal IPC which the node's cluster module use. ..... I just don't get that why the final result looks like that, could anyone try to have a try on this, plz :)

Also, I got another same situation and comparison result in my production service. I built a Binary Protocol Parser for encoding/decoding the hardware network data which transfers via TCP.
I made a performance test for both Typescripts (run in Node) and Rust version (release binary). The test very simple: Just run the decode function in a for loop to parse the same lines of binary protocol data (basically, just a brunch of byte[] / [u8]).
But the result is pretty funny which is the TypeScript one got more throughput than the Rust one. I consider that:
Maybe in every for loop scope, the Rust version always re-allocate and de-allocate all the local var memories (should be almost a few million operations during the test), as I saw the rust binary memory footprint can keep around 428KB and it's very stable.
But the node version, it uses around 32MB to run through the test (for getting that high throughput result). So I guess, the V8 never run the GC (to free the memory)? :)
Is that the same potential reason for the tide test result above?

@wisonye might be out of scope, but I'd be curious to see how other web frameworks written in rust perform here, and if they produce similar results. Might be out of scope, but it made me curious

Yup, it's not out of scope:) And I also want to see how other frameworks perform as well. If you have time then add a minimal demo here and what happen:)

I found tide slower than spring😂

@wisonye might be out of scope, but I'd be curious to see how other web frameworks written in rust perform here, and if they produce similar results. Might be out of scope, but it made me curious

warp are much more faster

Sorry, I'm too busy using Tide in prod to dig into this. I can tell you from production experience: it is orders of magnitude faster than Node.js for common workloads.9

autocannon against your node.js example:
autocannon <IP_ADDRESS>:8080 -c 16 -W -w 8 -d 20
Running 20s warmup @ http://<IP_ADDRESS>:8080
16 connections
8 workers

Running 20s test @ http://<IP_ADDRESS>:8080
16 connections
8 workers

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 1 ms │ 1 ms  │ 1 ms │ 0.61 ms │ 1.46 ms │ 155 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴────────┘
┌───────────┬─────────┬─────────┬────────┬─────────┬─────────┬────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%    │ 97.5%   │ Avg     │ Stdev  │ Min     │
├───────────┼─────────┼─────────┼────────┼─────────┼─────────┼────────┼─────────┤
│ Req/Sec   │ 15199   │ 15199   │ 15535  │ 17679   │ 15782.4 │ 644.56 │ 15198   │
├───────────┼─────────┼─────────┼────────┼─────────┼─────────┼────────┼─────────┤
│ Bytes/Sec │ 3.13 MB │ 3.13 MB │ 3.2 MB │ 3.64 MB │ 3.25 MB │ 133 kB │ 3.13 MB │
└───────────┴─────────┴─────────┴────────┴─────────┴─────────┴────────┴─────────┘

Req/Bytes counts sampled once per second.

316k requests in 20.05s, 65 MB read

Autocannon against Tide (--release):
autocannon <IP_ADDRESS>:8080 -c 16 -W -w 8 -d 20
Running 20s warmup @ http://<IP_ADDRESS>:8080
16 connections
8 workers

Running 20s test @ http://<IP_ADDRESS>:8080
16 connections
8 workers

┌─────────┬──────┬──────┬───────┬──────┬─────────┬────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev  │ Max    │
├─────────┼──────┼──────┼───────┼──────┼─────────┼────────┼────────┤
│ Latency │ 0 ms │ 1 ms │ 2 ms  │ 2 ms │ 1.16 ms │ 0.9 ms │ 110 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴────────┴────────┘
┌───────────┬────────┬────────┬─────────┬─────────┬─────────┬────────┬────────┐
│ Stat      │ 1%     │ 2.5%   │ 50%     │ 97.5%   │ Avg     │ Stdev  │ Min    │
├───────────┼────────┼────────┼─────────┼─────────┼─────────┼────────┼────────┤
│ Req/Sec   │ 8967   │ 8967   │ 9167    │ 11063   │ 9449.6  │ 530.04 │ 8966   │
├───────────┼────────┼────────┼─────────┼─────────┼─────────┼────────┼────────┤
│ Bytes/Sec │ 1.2 MB │ 1.2 MB │ 1.23 MB │ 1.48 MB │ 1.27 MB │ 71 kB  │ 1.2 MB │
└───────────┴────────┴────────┴─────────┴─────────┴─────────┴────────┴────────┘

Req/Bytes counts sampled once per second.

189k requests in 20.04s, 25.3 MB read

That's kinda odd. It's definitely not what we observe but we also don't stress our Rust processes much (because they are plenty fast to carry our load).

Linux perf counter stats seem to indicate this is artificial (possibly TCP no_delay related):
 Performance counter stats for 'node benchmark_server.js':

        117,093.95 msec task-clock                #    2.461 CPUs utilized
           469,264      context-switches          #    0.004 M/sec
            86,414      cpu-migrations            #    0.738 K/sec
           102,170      page-faults               #    0.873 K/sec
   272,687,722,707      cycles                    #    2.329 GHz
   122,404,642,364      instructions              #    0.45  insn per cycle
    25,706,131,492      branches                  #  219.534 M/sec
     1,663,729,936      branch-misses             #    6.47% of all branches
     ```

Performance counter stats for 'cargo run --release':
     49,355.48 msec task-clock                #    0.430 CPUs utilized
       863,669      context-switches          #    0.017 M/sec
        23,368      cpu-migrations            #    0.473 K/sec
         7,929      page-faults               #    0.161 K/sec
85,474,611,529      cycles                    #    1.732 GHz
43,426,351,109      instructions              #    0.51  insn per cycle
 8,534,130,491      branches                  #  172.912 M/sec
   529,585,015      branch-misses             #    6.21% of all branches
   ```

Of note there, Tide does a bunch more context switching, but it's not too bad, I think.
Tide however uses less than a third of the cpu cycles.

With tcp no_delay enabled via @jbr's draft PR I get:
Running 20s warmup @ http://<IP_ADDRESS>:8080
16 connections
8 workers

Running 20s test @ http://<IP_ADDRESS>:8080
16 connections
8 workers

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 0 ms │ 1 ms  │ 2 ms │ 0.53 ms │ 0.98 ms │ 130 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg     │ Stdev   │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Req/Sec   │ 12887   │ 12887   │ 14711   │ 19167   │ 15810.6 │ 2260.19 │ 12885   │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 1.73 MB │ 1.73 MB │ 1.97 MB │ 2.57 MB │ 2.12 MB │ 303 kB  │ 1.73 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

Req/Bytes counts sampled once per second.

316k requests in 20.03s, 42.4 MB read

Which is about on-par. I think my laptop is now the limiting factor. I'll try to run the benchmark in reverse.

Also, for that last example, we're still using only about half the cpu cycles for the same number of requests as Node.
 Performance counter stats for 'cargo run --release':

         55,935.65 msec task-clock                #    0.565 CPUs utilized
         1,361,880      context-switches          #    0.024 M/sec
            22,762      cpu-migrations            #    0.407 K/sec
             7,881      page-faults               #    0.141 K/sec
   126,799,597,556      cycles                    #    2.267 GHz
    71,088,504,957      instructions              #    0.56  insn per cycle
    13,899,982,207      branches                  #  248.500 M/sec
       583,560,089      branch-misses             #    4.20% of all branches

I am going to caution that no_delay may be ideal for this benchmarking workload but may not be ideal in the real world.

I run tfb with TCP_NODELAY, it has a big improvement in Req/Sec, but the Latency increased a lot.
**TCP_NODELAY**
8 threads and 8 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   644.08ms    1.07s    3.67s    81.67%
    Req/Sec    12.16k     4.52k   14.46k    87.83%

Comparing with..
**tide = "0.16.0"**
  8 threads and 8 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    15.47ms   16.24ms  45.97ms   80.29%
    Req/Sec    93.20     32.76   272.00     68.75%

The result looks really strange. I'm not familiar with this topic, but I think the following link will help.
https://stackoverflow.com/questions/3761276/when-should-i-use-tcp-nodelay-and-when-tcp-cork

@Fishrock123 @wisonye @slhmy Are there any tools to inspect where time is spent when the server is running, might offer some clues as to what you were seeing @wisonye

@Fishrock123 @wisonye @slhmy Are there any tools to inspect where time is spent when the server is running, might offer some clues as to what you were seeing @wisonye

Don't know if flamegraph(https://github.com/flamegraph-rs/flamegraph) will help... I'm kind of busy nowadays.

I want to take bottom-up perf stacks but don't know how to offhand with rust (and I am super busy).

autocannon to benchmark_server.js
❯ autocannon <IP_ADDRESS>:8080 -c 16 -W -w 8 -d 20                                                            (base)
Running 20s warmup @ http://<IP_ADDRESS>:8080
16 connections
8 workers

Running 20s test @ http://<IP_ADDRESS>:8080
16 connections
8 workers

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 0 ms │ 0 ms  │ 1 ms │ 0.34 ms │ 7.63 ms │ 376 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg     │ Stdev   │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Req/Sec   │ 16879   │ 16879   │ 32895   │ 39871   │ 31267.6 │ 5363.64 │ 16871   │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 3.09 MB │ 3.09 MB │ 6.02 MB │ 7.29 MB │ 5.72 MB │ 981 kB  │ 3.09 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

Req/Bytes counts sampled once per second.

625k requests in 20.21s, 114 MB read

autocanon tide --release, with TCP_NODELAY
❯ autocannon <IP_ADDRESS>:8080 -c 16 -W -w 8 -d 20                                                            (base)
Running 20s warmup @ http://<IP_ADDRESS>:8080
16 connections
8 workers

Running 20s test @ http://<IP_ADDRESS>:8080
16 connections
8 workers

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 0 ms │ 0 ms  │ 1 ms │ 0.07 ms │ 1.68 ms │ 255 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg     │ Stdev   │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Req/Sec   │ 20015   │ 20015   │ 45023   │ 47871   │ 43102.4 │ 6650.74 │ 20001   │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 2.68 MB │ 2.68 MB │ 6.03 MB │ 6.41 MB │ 5.78 MB │ 891 kB  │ 2.68 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

Req/Bytes counts sampled once per second.

862k requests in 20.01s, 116 MB read

And make a flamegraph.
flamegraph.svg.zip

autocannon to benchmark_server.js
❯ autocannon <IP_ADDRESS>:8080 -c 16 -W -w 8 -d 20                                                            (base)
Running 20s warmup @ http://<IP_ADDRESS>:8080
16 connections
8 workers

Running 20s test @ http://<IP_ADDRESS>:8080
16 connections
8 workers

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 0 ms │ 0 ms  │ 1 ms │ 0.34 ms │ 7.63 ms │ 376 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg     │ Stdev   │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Req/Sec   │ 16879   │ 16879   │ 32895   │ 39871   │ 31267.6 │ 5363.64 │ 16871   │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 3.09 MB │ 3.09 MB │ 6.02 MB │ 7.29 MB │ 5.72 MB │ 981 kB  │ 3.09 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

Req/Bytes counts sampled once per second.

625k requests in 20.21s, 114 MB read

autocanon tide --release, with TCP_NODELAY
❯ autocannon <IP_ADDRESS>:8080 -c 16 -W -w 8 -d 20                                                            (base)
Running 20s warmup @ http://<IP_ADDRESS>:8080
16 connections
8 workers

Running 20s test @ http://<IP_ADDRESS>:8080
16 connections
8 workers

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 0 ms │ 0 ms  │ 1 ms │ 0.07 ms │ 1.68 ms │ 255 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg     │ Stdev   │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Req/Sec   │ 20015   │ 20015   │ 45023   │ 47871   │ 43102.4 │ 6650.74 │ 20001   │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 2.68 MB │ 2.68 MB │ 6.03 MB │ 6.41 MB │ 5.78 MB │ 891 kB  │ 2.68 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

Req/Bytes counts sampled once per second.

862k requests in 20.01s, 116 MB read

And make a flamegraph.
flamegraph.svg.zip

I am going to caution that no_delay may be ideal for this benchmarking workload but may not be ideal in the real world.

I run tfb with TCP_NODELAY, it has a big improvement in Req/Sec, but the Latency increased a lot.
**TCP_NODELAY**
8 threads and 8 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   644.08ms    1.07s    3.67s    81.67%
    Req/Sec    12.16k     4.52k   14.46k    87.83%

Comparing with..
**tide = "0.16.0"**
  8 threads and 8 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    15.47ms   16.24ms  45.97ms   80.29%
    Req/Sec    93.20     32.76   272.00     68.75%

The result looks really strange. I'm not familiar with this topic, but I think the following link will help.
https://stackoverflow.com/questions/3761276/when-should-i-use-tcp-nodelay-and-when-tcp-cork

@wisonye might be out of scope, but I'd be curious to see how other web frameworks written in rust perform here, and if they produce similar results. Might be out of scope, but it made me curious

Also currently warp has a more satisfying result on my computer.
**warp**
  8 threads and 8 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   497.54us  550.14us  18.32ms   97.70%
    Req/Sec     2.02k   309.63     2.96k    78.77%

It's understandably microbenchmark doesn't reflect the whole real word. But the result can't persuade me that tide is good enough like other web app framework.

@slhmy
Hey, sorry for late, so busy nowadays. And YES, you're right I think. Actually, I think the choice belongs to between async-std and tokio, as that's a bigger difference under the hood:) It very depends :)

autocannon to benchmark_server.js
❯ autocannon <IP_ADDRESS>:8080 -c 16 -W -w 8 -d 20                                                            (base)
Running 20s warmup @ http://<IP_ADDRESS>:8080
16 connections
8 workers

Running 20s test @ http://<IP_ADDRESS>:8080
16 connections
8 workers

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 0 ms │ 0 ms  │ 1 ms │ 0.34 ms │ 7.63 ms │ 376 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg     │ Stdev   │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Req/Sec   │ 16879   │ 16879   │ 32895   │ 39871   │ 31267.6 │ 5363.64 │ 16871   │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 3.09 MB │ 3.09 MB │ 6.02 MB │ 7.29 MB │ 5.72 MB │ 981 kB  │ 3.09 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

Req/Bytes counts sampled once per second.

625k requests in 20.21s, 114 MB read

autocanon tide --release, with TCP_NODELAY
❯ autocannon <IP_ADDRESS>:8080 -c 16 -W -w 8 -d 20                                                            (base)
Running 20s warmup @ http://<IP_ADDRESS>:8080
16 connections
8 workers

Running 20s test @ http://<IP_ADDRESS>:8080
16 connections
8 workers

┌─────────┬──────┬──────┬───────┬──────┬─────────┬─────────┬────────┐
│ Stat    │ 2.5% │ 50%  │ 97.5% │ 99%  │ Avg     │ Stdev   │ Max    │
├─────────┼──────┼──────┼───────┼──────┼─────────┼─────────┼────────┤
│ Latency │ 0 ms │ 0 ms │ 0 ms  │ 1 ms │ 0.07 ms │ 1.68 ms │ 255 ms │
└─────────┴──────┴──────┴───────┴──────┴─────────┴─────────┴────────┘
┌───────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬─────────┐
│ Stat      │ 1%      │ 2.5%    │ 50%     │ 97.5%   │ Avg     │ Stdev   │ Min     │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Req/Sec   │ 20015   │ 20015   │ 45023   │ 47871   │ 43102.4 │ 6650.74 │ 20001   │
├───────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┼─────────┤
│ Bytes/Sec │ 2.68 MB │ 2.68 MB │ 6.03 MB │ 6.41 MB │ 5.78 MB │ 891 kB  │ 2.68 MB │
└───────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴─────────┘

Req/Bytes counts sampled once per second.

862k requests in 20.01s, 116 MB read

And make a flamegraph.
flamegraph.svg.zip

@fiag .....That's funny:) But I remember that I did give it a try based on your patch branch for the TCP_NO_DELAY settings, and the result I got looks no much different. How it comes it looks like a very big difference when you use it? :)

@slhmy
Hey, sorry for late, so busy nowadays. And YES, you're right I think. Actually, I think the choice belongs to between and , as that's a bigger difference under the hood:) It very depends :)async-std``tokio

🦀 Maybe more comparisons need to be made.
I currently made actix-web work with sqlx (sqlx runs a tokio runtime which is compatible with actix-web 4.0-beta) and there is also some performance issue...(Check this issue It temporary solved by making querying in one connection)
I also found there is a huge performance loss if I put a async-sever into a docker machine.
Combining to the above relate, I guess maybe async-std consumes a lot of time to switch between threads, but I can't make flamegraph for computer reason...So, it's only my guess. 😂

@slhmy Thanks for that:) Also, here is my personal opinion:

(Check this issue. It is temporary solved by making querying in one connection)
I did check that issue and I think jplatte answer is good. As usual, the Pool just responsible for **getting an exists and free connection back to you when you ask for; If not one exists, then create a new connection instance and cache it (in the hashmap usually). What you were trying to do is ask the pool to give you the new one and use it immediately (before it releases which more like none of free connection instance in the pool). I think that's why that "bug" shows up, just guess :)

I also found there is a huge performance loss if I put a async-sever into a docker machine.
I did use async-std in production and that high-performance TCP server is running inside docker swarm  as well which I didn't see any slow issue. So what's your case actually?:)

I guess maybe async-std consumes a lot of time to switch between threads
I think you can go to async-std discord channel to ask them, as by default just spawn a few threads which based on how much CPU core you have, should not be a very big problem for switching between the threads (I think), and I should works like asking for a free OS/Native thread from the internal thread pool:)

@wisonye

I also found there is a huge performance loss if I put a async-sever into a docker machine.
I did use  in production and that high-performance TCP server is running inside docker swarm  as well which I didn't see any slow issue. So what's your case actually?:)async-std

Thanks a lot for your help, actually  it''s related the issue I have post.

I run the service in a docker container, and actix+sqlx will cost more than 20s to request 500 rows in the database.
However others like tide+sqlx will not(only cost around 300ms).
The 20s problem only appears in docker machine build by tfb debug mode (tfb debug mode will automatically , when the server is not in docker it won't cost so much time.
Any way I also think your opinion is correct, so I will do more try and exclude all my personal issue if I could, then the guess may come into a result.


Subscribe button not working on Android in v16.2.96

The Material Design press action is visible, but it never subscribes me. Happening on Android app trying to subscribe to the core/sprint channel for Python.zulipchat.com .

Thanks for the report @brettcannon
We did fix this bug a week or so ago.
Expect the next release to include the fix!

Following up: 17.1.98 went out to all users early this week, and had the fix for this bug. Thanks again @brettcannon for the report!
(See also #2889 , which was a previous report of this bug.)


Update hover color for lounge access icon

Details

Update hover color for lounge access icon
Fixed Issues

$ https://github.com/Expensify/App/issues/22766
PROPOSAL: https://github.com/Expensify/App/issues/22766#issuecomment-1633483867
Tests

Click on the settings (profile icon)
Hover over various buttons, observe color change of the icon.
Click Profile.
Hover over personal details, observe color change of the icon.
Hover over or long pressing Lounge Access.
Verify that LoungeAccess icon turn into white when hovering.

[x] Verify that no errors appear in the JS console

Offline tests

Same as Tests.
QA Steps

Click on the settings (profile icon)
Hover over various buttons, observe color change of the icon.
Click Profile.
Hover over personal details, observe color change of the icon.
Hover over or long pressing Lounge Access.
Verify that LoungeAccess icon turn into white when hovering.

[x] Verify that no errors appear in the JS console

PR Author Checklist

[x] I linked the correct issue in the ### Fixed Issues section above
[x] I wrote clear testing steps that cover the changes made in this PR

[x] I added steps for local testing in the Tests section
[x] I added steps for the expected offline behavior in the Offline steps section
[x] I added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[x] I included screenshots or videos for tests on all platforms
[x] I ran the tests on all platforms & verified they passed on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[x] I followed proper code patterns (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[x] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I followed the guidelines as stated in the Review Guidelines
[x] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] I verified that if a function's arguments changed that all usages have also been updated correctly
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] If we are not using the full Onyx data that we loaded, I've added the proper selector in order to ensure the component only re-renders when the data it is using changes
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

https://github.com/Expensify/App/assets/16502320/0f01673c-8f3a-42a7-a4eb-f37798d3f3a4

Mobile Web - Chrome
https://github.com/Expensify/App/assets/16502320/6e192a48-0536-413e-8914-65b5f69918e5

Mobile Web - Safari

https://github.com/Expensify/App/assets/16502320/1e9d1610-0a04-41c1-8ece-9577930e0869

Desktop

https://github.com/Expensify/App/assets/16502320/0f01673c-8f3a-42a7-a4eb-f37798d3f3a4

iOS

https://github.com/Expensify/App/assets/16502320/5ef77ac2-e949-422a-9d3b-b3061f70975c

Android

https://github.com/Expensify/App/assets/16502320/777f9747-db3e-4915-a518-6db33afa8ff2

@hungvu193 star not changing to white on hover. can you investigate?

Reviewer Checklist

[x] I have verified the author checklist is complete (all boxes are checked off).
[x] I verified the correct issue is linked in the ### Fixed Issues section above
[x] I verified testing steps are clear and they cover the changes made in this PR

[x] I verified the steps for local testing are in the Tests section
[x] I verified the steps for Staging and/or Production testing are in the QA steps section
[x] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[x] I checked that screenshots or videos are included for tests on all platforms
[x] I included screenshots or videos for tests on all platforms
[x] I verified tests pass on all platforms & I tested again on:

[x] Android / native
[x] Android / Chrome
[x] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[x] MacOS / Desktop

[x] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[x] I verified proper code patterns were followed (see Reviewing the code)

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[x] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[x] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

[x] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[x] I verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[x] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[x] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[x] If a new component is created I verified that:

[x] A similar component doesn't exist in the codebase
[x] All props are defined accurately and each prop has a /** comment above it */
[x] The file is named correctly
[x] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[x] The only data being stored in the state is data necessary for rendering and nothing else
[x] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[x] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[x] All JSX used for rendering exists in the render method
[x] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[x] If any new file was added I verified that:

[x] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[x] If a new CSS style is added I verified that:

[x] A similar style doesn't already exist
[x] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[x] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
[x] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web
https://github.com/Expensify/App/assets/108292595/2f21cde0-7525-4778-967a-cd8c13109ab4

Mobile Web - Chrome
https://github.com/Expensify/App/assets/108292595/a524105c-64a5-4eed-bd7c-f971ba61cf14

Mobile Web - Safari
https://github.com/Expensify/App/assets/108292595/6fcd4749-9434-4833-a0a8-dfb66b6e9532

Desktop
https://github.com/Expensify/App/assets/108292595/e0960836-9942-4efd-9ea5-91ff079d97d0

iOS
https://github.com/Expensify/App/assets/108292595/b0cb03fd-e02e-4318-aa1d-710144a5ae49

Android
https://github.com/Expensify/App/assets/108292595/bf4e8756-a938-4fda-b513-641a968be930

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/aldo-expensify in version: 1.3.55-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to staging by https://github.com/aldo-expensify in version: 1.3.56-0 🚀

platform
result

🤖 android 🤖
failure ❌

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/roryabraham in version: 1.3.56-24 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
failure ❌

🕸 web 🕸
success ✅


Added a little demo to UIImage+Additions

Perfect!!! I will create a new pod version with the changes.


Add TaggedTable trait and codegen attribute

Today we don't know which types relate to which tag(s) in codegen. Add an attribute, e.g.
#[type_for_tag("cmap")]
table Cmap {

(name of attribute up for bikeshed)

This should also have a corresponding trait in read-fonts. The trait would look like,
pub trait TaggedTable {
    const TAG: Tag;
}

Which is what we would implement if we saw this attribute on a table.
We can bikeshed this name. TopLevelTable? RootTable? FontTable? Nothing really jumps out at me.
In any case, this will let us further simplify the common case in TableProvider:
pub trait TableProvider<'a> {
    fn expect_table<T: FontRead<'a> + TaggedTable>(&self) -> Result<T, ReadError> {
        self.expect_data_for_tag(T::TAG).and_then(FontRead::read)
    }

    /// now our individual table getters generally just look like:
    fn head(&self) -> Result<tables::head::Head<'a>, ReadError> {
        self.expect_table()
    }
}

Also we should make sure this new attribute supports mapping multiple tags to the same table structure (see, hmtx/vmtx and hhea/vhea in #104)

This actually raises an interesting question: we can't have two impls of this trait for the same table, so as designed it doesn't work with VHmtx etc. I'm not sure what the best approach here is. A possible approach I can see is having a newtype wrapper for each concrete table that just implements this method + deref/derefmut? this doesn't feel wonderful either. I'll let this stew and see if another good solution presents itself.

Added in #164


Make harvesting function work when only 860 is loaded

I didn't really design the ETL process to work w/ only 860, but it will be useful in the future. Especially for folks using CEMS + 860.
The harvesting process is sequential (plants are loaded before utilities for a reason) and boilers are last. There are only a few boiler entity columns and the harvesting process is failing on the last column:
KeyError: "['prime_mover_code'] not in index"
I'm pretty sure the prime_mover_code comes just from 923, which is why this is breaking.
Note: this was happening when running init_pudl with only 2017 for 860.

Prime mover is also reported in the 860 generator file.

The prime move for the generator entity is properly being pulled from 860. But there is a boiler table in 923 that has boiler prime mover, which to my knowledge does not exist in 860.

Ok, got it. My bad! :)

@cmgosnell Do you think this is still something we should do, given that we're mostly envisioning ourselves running a pretty complete ETL, and publishing the processed data for folks to use?

Not gonna do it.


OCM-3473 | fix: create operator-roles for shared VPC

Operator roles' policies are associated with the installer role prefix. In case the operator role policy already has sts:AssumeRole action with shared VPC role ARN, and the user provides a different shared VPC role ARN, error out, and guide the user to use a different account role ARN.
Note: Currently the command overrides the shared VPC role ARN value with the value provided by the user.
Examples:

User create operator roles outside of the shared VPC scope:

User overrides the policy created in [1], while creating operator roles with shared VPC role ARN:
(A new policy version is created with a sts:AssumeRole permission)

The user tries to create operator roles with the same installer role from [2] with a different shared-vpc-role-arn and is prompted to use a different installer role:

The user is using a different role ARN, and creates successfully the operator roles:

/lgtm

aside from small NP, looking good to me~

/lgtm


_socket is not defined

When I assign a hotkey and press it I get a Javascript error:
Uncaught Exception: ReferenceError: _socket is not defined     at Function.<anonymous> (C:\GoXLR Interface\main.js:83:13)
I am able to get around the issue by commenting out all lines with "_socket" in them. After that when I press the hotkeys I get the correct sound, however in the node console I get a "hotkey registration failed for CTRL+2" message and the routing table doesn't change.

Hi @PaoloTK,
I just checked this issue and may have an idea what is going on. First of I pushed a new version with a bit more checking of the settings that should prevent a few error messages and exceptions. Could it be that you did not specify your GoXLR plugin path correctly? The _socket variable was only initialized in case the GoXLR plugin established a connection to the GoXLR interface. In this case GoXLR is not able to change any settings in your GoXLR App.
The latest version will give an error instead of thorwing an excpetion. Could you please check out this new version and also check the path to your GoXRL Plugin executable? Also make sure to to let GoXLR interface restart your GoXLR app before using a hotkey (or do it by hand!).

I'm thinking that maybe the issue was caused by the fact that I extracted the executable alone from the plugin without the other files, but I now realize that there's some js stuff in there (at first I thought it was only icons). The reason I didn't extract everything in the first place was that 7zip gave me errors - it thinks there are files named like the folders and so extracting everything fails.
I have now updated to the latest version and I don't get the error anymore, but instead, I'm getting a "Can't execute action, GoXLR plugin not connected!" error. I've restarted the GoXLR app multiple times, restarted GoXLR Interface, reset the settings for it (deleted the folder in Roaming) and restarted my PC.

As far as I know, it should be sufficient to just extract the *.exe. The error you get indicates that for for some reason to GoXRL App is not connected to GoXLR Interface. Have you double checked that you have selected the correct executables for "GoXLR plugin executable" and "GoXLR executable" in GoXLR interface? Do you see the error "Plugin executable not found!"?
Another question? Do you run the Streamdeck software?

Yes, the path for both the plugin and program Exe is correct.
I don't see the error you mentioned but in the terminal I see this:
"(node:9344) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)"
I do run the Streamdeck Software but I've also tried closing it and restarting everything - no luck.

Hmm, is there any additional information where the exception is thrown? I am not sure what impact the Streamdeck applicaiton can have on everything. Have you checked in that really nothing from elgato was still running? (maybe there is some background process?). I fear it will most likely not be possible to run GoXLR-Interface together with the streamdeck software...

Hmm, is there any additional information where the exception is thrown? I am not sure what impact the Streamdeck applicaiton can have on everything. Have you checked in that really nothing from elgato was still running? (maybe there is some background process?).
Not as far as I can tell.

I was also not encountering this problem before the last update no matter if the Stream Deck app was running or not. I could trigger hotkeys and hear the sound GoXLR Interface is supposed to play when toggling the routing options.

But actually changeing the routing table never worked right? And you do NOT see the message "GoXLR Plugin connected", correct?
That you could hear the sounds only means that the mapping of the hotkey worked, but before the last update GoXLR did not actually check if the plugin is connected or not. This is now done, so you should no longer hear the sounds.
What you could try: run GoXLR interface and then start the GoXLR plugin by hand via the command line. Naviagate to the folder an run:
[exename] -port 3001 -pluginUUID com.tchelicon.goxlr.routingtable -registerEvent registerEvent -info {}
Port 3001 is only the default port, if this port is already used, it may use another port. To figure out which port is actually used you can add a debug print at the beginning of the function startWebsocket() in line 32:
console.log("Startin websocket on port "+port);
Check if there is any error when starting the plugin by hand and if you see the message "GoXLR Plugin connected".

I was able to get rid of that error I got earlier. To delete the settings when I was testing I deleted the folder in Appdata/Roaming, and after that when I launched GoXLR Interface "OBS Websocket address" and "OBS Websocket Port" defaulted to "undefined". This caused some issues and the webserver wasn't starting at all: I couldn't even see the message you made me add to the log. Replacing the address and port with <IP_ADDRESS> and 4444 respectively got rid of the errors and it looks like the plugin websocket started correctly.
Everything seems to be working fine now!

That is good news! I will try to make the App more resiliant to these types of input errors with the next version. What would be very interesting to me: is it working for you if the Streamdeck software is running? And if so: do both Apps work or only one of them?

There seems to be some issues with the Stream Deck software and GoXLR Interface running at the same time. I was able to keep GoXLR Interface working after closing the Stream Deck app, manually starting the plugin with the command you gave me earlier and then opening the Stream Deck app again. However the GoXLR integration wasn't working on the Stream Deck. For me that's not a big issue since I don't plan to use the GoXLR integration on the Stream Deck and would rather have a quick way to mute myself with a mouse button rather than having to press a button on the GoXLR device.


layers: Change to including vk_safe_struct code.

Cmake on windows cannot handle multiple projects using generated library code.
This happens with vk_safe_struct.cpp between core_validation and unique_objects.
Having both layers list it in add_vk_layer and the resulting add_library operation causes
their vcxproj files to create vk_safe_struct.cpp for build and remove vk_safe_struct.cpp for rebuild.
That breaks parallel builds when the creation collides.
It breaks rebuild when the recently created file is removed by another project.
Changing to using #include of the cpp file avoids that bad build behavior.

Thanks Mike.  The changes look good, but let me test it out on my VS 2015 machine tomorrow to make sure it works.  I believe it should.

It works for me!  Thanks again Mike

Cherry-picked to master


feat: add blockchain migration feature

This is work in progress - feedback is welcome
This pull request introduces the blockchain migration feature, which is highly dependent on how the consortium management is implemented. The approveMigration method will allow a stakeholder to agree on the migration, via the consortium maangement plugin.
Regarding the test, currently, it initializes a Besu blockchain migrator plugin. The idea is to submit transactions through Besu, capture the data they generate, and issue transactions against a target ledger (e.g., Quorum or Fabric). Finally, it should assert if the data migrated can be found at the target ledger.
How to test this feature (similar instructions to PR #123):
-checkout this branch
-cd to the project root
-npm run configure -
-run the test at packages/cactus-plugin-blockchain-migrator-besu/src/test/typescript/integration/plugin-ledger-blockchain-migrator-besu/data-migration/migrate-data-to-quorum.ts

@RafaelAPB set it as a 'draft' PR in line with it being WIP still. If you open a non-draft PR that should in general mean that it's ready for the maintainers to invest the time to review it from top to bottom. Not a big issue at all, just wanted to clarify. :-)

@RafaelAPB Tried to give this a spin, but it won't build, see errors below:
@hyperledger/cactus-plugin-blockchain-migrator-besu: packages/cactus-plugin-blockchain-migrator-besu/src/main/typescript/plugin-ledger-blockchain-migrator-besu.ts:92:39
@hyperledger/cactus-plugin-blockchain-migrator-besu: ERROR: 92:39  no-shadowed-variable  Shadowed name: 'migrationDepth'
@hyperledger/cactus-plugin-blockchain-migrator-besu: ERROR: 93:39  no-shadowed-variable  Shadowed name: 'migrationType'

This should only work natively and without resigning transactions for blockchains which have the same transaction arquitecture.
(Quorum, Besu, Geth, OpenEthereum, Nethermint and other open implementations based on the EVM)
That said, the networks may have to be configured in a specific way.
The chainID should be the same in all the configured networks which is not usually done.
This could potentially open users to replay attacks across different networks.
There might be a better approach migrating the contract and manually pushing a checkpoint data
Or asking all the agents to resign all their transactions

@kikoncuo thank you for the suggestions. That's an interesting path :) We can discuss further on the meetings

Is this PR linked to an issue? if so, can you ping it on the main comment so we can track it better? (IE: Resolves #issueNumber)

@kikoncuo No, I don't think there's an issue on this.

@petermetz yes - sorry for the infinite delay, but still working on the paper/feature :)

@RafaelAPB No worries, I'm just taking a pass on all the PRs to make sure we don't have dead ones hanging around. If you are still working on it it's cool to keep it open IMO.


This plugin doesn't work with Elasticsearch 2.x

Hi,
I'm upgrading ES from 1.7.3 to 2.1.1 and had plugins like elasticsearch-cloud-aws installed on my ES estate. However this plugin no longer works with ES 2.1.1.
Do you have a version of this plugin that can work with ES 2.1.1 ?
Thanks

As stated in the README, read https://www.elastic.co/guide/en/elasticsearch/plugins/current/cloud-aws.html


Define rule: For a Timing from an anchor (with type "fixed reference), relativeToFrom is either "start to start" or "end to start"

CHK0029: A timing relative to an anchor should have a value of relative to from either "start to start" to "end to start".  I.e., the "leg" of a timing that links to an anchor has to link to the start of an anchor.  This assumes that the anchor is at the "from" end of the relationship, and that an anchor has only a start (or that start and end are the same)
Also assumes (an assumption that needs to be checked) that in a to-from relationship

from is the established instance (e.g., the anchor)
to is the instance being added to the timeline

From Berber's document "USDM Check categories v2" : -	In case relativeToFrom=“fixed reference” the timing.type should be “Start to Start” (to be checked with Dave, based on his example)
So this define rule can't be advanced until after consultation with Dave I-H.

I agree that it would be best to check with Dave about this. The important thing is to be able to identify whether it's the start or the end of the "from" activity that defines the anchor (e.g., does the clock start ticking when dosing starts or when it ends?). At the moment, the codelist for relativeToFrom only contains two-part codes:

Concept C-code
Preferred Term
CDISC Definition

C201352
End to End
A timing relationship defined as the end of one event to the end of another event.

C201353
End to Start
A timing relationship defined as the end of one event to the start of another event.

C201354
Start to End
A timing relationship defined as the start of one event to the end of another event.

C201355
Start to Start
A timing relationship defined as the start of one event to the start of another event.

(Note: given that all codes are defined as "from" something "to" something, it might be better to rename the attribute as relativeFromTo)
Given that it's only the first part of the (de)code (the "from" part) that's relevant, there seem to be two options (if we want to ensure that relativeToFrom is specified consistently for anchors):

Choose which of the two available codes should be used to indicate "Start" vs "End" (I'd prefer using "Start to Start" and "End to End" because you get the intended value if you look at either the first or second part of the decode).
Add two new codes for just "Start" and "End" to the codelist for relativeToFrom to be used specifically for anchors.

In either case, the rule would then check that only appropriate codes are used for anchors. If the second option were chosen, the rule would also check that the new anchor-specific codes are not used for non-anchors.

Removed "end to start" from rule.

Rule ID was changed from DDF99977 to DDF00036.

Review complete as part of review of #155


Separate database and .env file per module

Hello, i need to create specific modules with their separate databases and .env file to hold app specific environment variables. Is this feature currently available?

Hi, no sorry modules have no awareness of env files.


B-toasts dont appear

Toasts seems to dont work, even on the examples pages.

Please give more context or the issue will be marked closed.

I imported the toast plugin they dont apper, i checked the website with examples they dont work there too.

Examples dont work due to SSR and Vuepress build. Browser does not matter.

Closed due to inactivity and insufficient information.


MoodEdit fragment

Focus
Create a fragment that handles the view and logic of editing the details of a mood event. This fragment will be used for both adding a new mood event or editing and existing. When editing an existing the fragment will populate the editable fields. When adding a new mood event the field will be empty.
This class in conjunction with the MoodEvent satisfies #1, #20, and #4.

Mostly complete as of PR #98. Need to create buttons for social situation to restrict input. Text fields currently causes a crash if many digits entered.
Also need to implement location API.
Will close this issue and reopen as enhancement.

The above is actually a US requirement and is found in #8


Prevent crash if variable gives a 403

App was crashing if NEXT_PUBLIC_SCIENTIFIC_EVIDENCE_STATS_API_URL didnt gave back a 200

Started again here: https://github.com/Orcasa-Platform/orcasa/pull/232


v3: Cordova CLI not found on your PATH

Short description of the problem:
In trying to update an existing project that has been working fine from v2 to v3 using, I get the above error when I try to do npm install --save-dev --save-exact @ionic/cli-plugin-cordova@latest.
I have also noticed that Cordova is not listed in my global packages under ionic info even though sudo cordova -v works just fine outputting 7.0.1
What behavior are you expecting?
Packages should install normally
Post the output of ionic info below please
global packages:

    @ionic/cli-utils : 1.0.0
    Ionic CLI        : 3.0.0

local packages:

    @ionic/app-scripts              : 1.3.7
    @ionic/cli-plugin-ionic-angular : 1.0.0
    Ionic Framework                 : ionic-angular 3.2.1

System:

    Node       : v7.10.0
    OS         : macOS Sierra
    Xcode      : Xcode 8.3.2 Build version 8E2002
    ios-deploy : not installed
    ios-sim    : not installed

same problem !!

So I just reinstalled v2.2.3 and this is my ionic info
Your system information:

Cordova CLI: 7.0.1
Ionic Framework Version: 3.2.1
Ionic CLI Version: 2.2.3
Ionic App Lib Version: 2.2.1
Ionic App Scripts Version: 1.3.7
ios-deploy version: Not installed
ios-sim version: 5.0.13
OS: macOS Sierra
Node Version: v7.10.0
Xcode version: Xcode 8.3.2 Build version 8E2002

as you can see, my cordova is listed properly showing the issue is with ionic cli v3

Duplicate issue. See https://github.com/driftyco/ionic-cli/issues/2214


ERROR: Unable to extract uploader id

Checklist

[x] I'm reporting a broken site support issue
[x] I've verified that I'm running youtube-dl version 2021.12.17
[x] I've checked that all provided URLs are alive and playable in a browser
[x] I've checked that all URLs and arguments with special characters are properly quoted or escaped
[x] I've searched the bugtracker for similar bug reports including closed ones
[x] I've read bugs section in FAQ

Verbose log

evilsupahfly on Black-Beast at Sat 13 May 2023 17:02:31 EDT
[~/Videos] youtube-dl --verbose -f 'bestvideo+bestaudio' "https://www.youtube.com/watch?v=IFwFDZDQWAA"
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['--verbose', '-f', 'bestvideo+bestaudio', 'https://www.youtube.com/watch?v=IFwFDZDQWAA']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, pref UTF-8
[debug] youtube-dl version 2021.12.17
[debug] Python version 3.10.6 (CPython) - Linux-6.2.7-060207-generic-x86_64-with-glibc2.35
[debug] exe versions: ffmpeg 4.4.2, ffprobe 4.4.2
[debug] Proxy map: {}
[youtube] IFwFDZDQWAA: Downloading webpage
ERROR: Unable to extract uploader id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/dist-packages/youtube_dl-2021.12.17-py3.10.egg/youtube_dl/YoutubeDL.py", line 815, in wrapper
    return func(self, *args, **kwargs)
  File "/usr/local/lib/python3.10/dist-packages/youtube_dl-2021.12.17-py3.10.egg/youtube_dl/YoutubeDL.py", line 836, in __extract_info
    ie_result = ie.extract(url)
  File "/usr/local/lib/python3.10/dist-packages/youtube_dl-2021.12.17-py3.10.egg/youtube_dl/extractor/common.py", line 534, in extract
    ie_result = self._real_extract(url)
  File "/usr/local/lib/python3.10/dist-packages/youtube_dl-2021.12.17-py3.10.egg/youtube_dl/extractor/youtube.py", line 1794, in _real_extract
    'uploader_id': self._search_regex(r'/(?:channel|user)/([^/?&#]+)', owner_profile_url, 'uploader id') if owner_profile_url else None,
  File "/usr/local/lib/python3.10/dist-packages/youtube_dl-2021.12.17-py3.10.egg/youtube_dl/extractor/common.py", line 1012, in _search_regex
    raise RegexNotFoundError('Unable to extract %s' % _name)
youtube_dl.utils.RegexNotFoundError: Unable to extract uploader id; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.

Description

Well, the problem started yesterday when I started getting a strange error:
WARNING: [youtube] Unable to decode n-parameter: download likely to be throttled (Unhandled exception in decode; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output. Traceback (most recent call last):
  File "/usr/local/lib/python3.10/dist-packages/youtube_dl/extractor/youtube.py", line 1673, in _n_descramble
    raise ExtractorError('Unhandled exception in decode')
youtube_dl.utils.ExtractorError: Unhandled exception in decode; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output.
)
[download] Destination: Chalk Warfare-G1LEFtWk-08.mp4
[download] 100% of 10.35MiB in 12:38

Despite the initial error, it still downloaded the videos, albeit more slowly than previously. So, I forced pip to update it, even though it reported no update was required (Requirement already satisfied: youtube-dl in /usr/local/lib/python3.10/dist-packages/youtube_dl-2021.12.17-py3.10.egg (2021.12.17)),  and THEN it wouldn't download at all.
So I completely removed it, and rebuilt it from the same source I used last time (the MASTER branch here on GIT), tried again, but I still got ERROR: Unable to extract uploader id and the download fails.
After poking around, I found a Windows user who was getting a similar error but resolved it with a nightly build. I figured if it worked for him, it would work for me, so now I've gone and picked up the latest (at time of writing) Nightly Build from https://github.com/ytdl-patched/youtube-dl/releases/tag/2<IP_ADDRESS>9.
The good news is that the nightly build works, but if I remove it and go back to Official Build 2021.12.17 everything falls apart again. Did YouTube change something on their end, or did I screw something up?
EDIT:
I'll also note that with the nightly build, the original error is also gone, and the speed has dramatically improved:
evilsupahfly on Black-Beast at Sat 13 May 2023 18:17:13 EDT
[~/Videos] youtube-dl -f 'bestvideo+bestaudio' --verbose "https://www.youtube.com/watch?v=6zCH13oxlPc"
[debug] System config: []
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: ['-f', 'best', '-f', 'bestvideo+bestaudio', '--verbose', 'https://www.youtube.com/watch?v=6zCH13oxlPc']
[debug] Encodings: locale UTF-8, fs utf-8, out utf-8, pref UTF-8
[debug] youtube-dl version 2021.12.17
** This build is unofficial daily builds, provided for ease of use.
** Please do not ask for any support.
[debug] Python 3.10.6 (CPython 64bit) - Linux-6.2.7-060207-generic-x86_64-with-glibc2.35 (OpenSSL 3.0.2 15 Mar 2022, glibc 2.35)
[debug] exe versions: ffmpeg 4.4.2, ffprobe 4.4.2
[debug] Proxy map: {}
[youtube] 6zCH13oxlPc: Downloading webpage
[debug] [youtube] Decrypted nsig QU6kUEO_TvHHxnkGA3 => RRfg9NqGm93q9g
[debug] [youtube] Decrypted nsig ALk2QxIDZF3RuEuowp => jJl1MJ4E8owYNg
WARNING: Requested formats are incompatible for merge and will be merged into mkv.
[debug] Invoking downloader on 'https://rr2---sn-nu5gu-tt1e.googlevideo.com/videoplayback?expire=1684037989&ei=BQ1gZJWDNIONjQT05q6gCA&ip=<IP_ADDRESS>&id=o-AJ0cFUuFUEfFYroovYFoj_mgH83OUCAIr0_n0E9GwQ-C&itag=299&aitags=133%2C134%2C135%2C136%2C160%2C242%2C243%2C244%2C247%2C278%2C298%2C299%2C302%2C303%2C394%2C395%2C396%2C397%2C398%2C399&source=youtube&requiressl=yes&mh=Cn&mm=31%2C29&mn=sn-nu5gu-tt1e%2Csn-tt1e7nls&ms=au%2Crdu&mv=m&mvi=2&pcm2cms=yes&pl=23&initcwndbps=1765000&vprv=1&svpuc=1&mime=video%2Fmp4&ns=rB3fQ5CyFqWQ89J5unLE910N&gir=yes&clen=374527444&dur=728.149&lmt=1682477059043846&mt=1684015997&fvip=2&keepalive=yes&fexp=24007246%2C24362688&c=WEB&txp=5535434&n=RRfg9NqGm93q9g&sparams=expire%2Cei%2Cip%2Cid%2Caitags%2Csource%2Crequiressl%2Cvprv%2Csvpuc%2Cmime%2Cns%2Cgir%2Cclen%2Cdur%2Clmt&sig=AOq0QJ8wRAIgI5N7qLw6MBxmQgq4WvDw6aowbN-xw6vlRG1f4z3sU0sCIFJEynETfG_KUDBUOOHUnOwidAQTeyOL2Rv3YOxGk3x3&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpcm2cms%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRQIgGZRS_D5pHxBsjZxotXYR4VUjRcN_BBqUExlEdXWUq7ECIQCeY6KCJejruVjIbbQ_ALaqi_IXv453WFpFJMISW1yC2w%3D%3D'
[dashsegments] Total fragments: 36
[download] Destination: Antimatter Weapons - Threat or Ridiculous Pipe Dream-6zCH13oxlPc.f299.mp4
[download] 100% of 357.18MiB in 00:37
[debug] Invoking downloader on 'https://rr2---sn-nu5gu-tt1e.googlevideo.com/videoplayback?expire=1684037989&ei=BQ1gZJWDNIONjQT05q6gCA&ip=<IP_ADDRESS>&id=o-AJ0cFUuFUEfFYroovYFoj_mgH83OUCAIr0_n0E9GwQ-C&itag=251&source=youtube&requiressl=yes&mh=Cn&mm=31%2C29&mn=sn-nu5gu-tt1e%2Csn-tt1e7nls&ms=au%2Crdu&mv=m&mvi=2&pcm2cms=yes&pl=23&initcwndbps=1765000&vprv=1&svpuc=1&mime=audio%2Fwebm&ns=rB3fQ5CyFqWQ89J5unLE910N&gir=yes&clen=12455510&dur=728.181&lmt=1682472910417233&mt=1684015997&fvip=2&keepalive=yes&fexp=24007246%2C24362688&c=WEB&txp=5532434&n=RRfg9NqGm93q9g&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cvprv%2Csvpuc%2Cmime%2Cns%2Cgir%2Cclen%2Cdur%2Clmt&sig=AOq0QJ8wRgIhAMZ-aq8zVvNW2qCR5Pmv1E2EVuydEVpjWctgaO1A6CA8AiEAikAPN6yfnGcD0hD_MSrvHzLt20W1Z8-WvTJerKcCHwU%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpcm2cms%2Cpl%2Cinitcwndbps&lsig=AG3C_xAwRQIgGZRS_D5pHxBsjZxotXYR4VUjRcN_BBqUExlEdXWUq7ECIQCeY6KCJejruVjIbbQ_ALaqi_IXv453WFpFJMISW1yC2w%3D%3D'
[dashsegments] Total fragments: 2
[download] Destination: Antimatter Weapons - Threat or Ridiculous Pipe Dream-6zCH13oxlPc.f251.webm
[download] 100% of 11.88MiB in 00:01
[ffmpeg] Merging formats into "Antimatter Weapons - Threat or Ridiculous Pipe Dream-6zCH13oxlPc.mkv"
[debug] ffmpeg command line: ffmpeg -y -loglevel repeat+info -i 'file:Antimatter Weapons - Threat or Ridiculous Pipe Dream-6zCH13oxlPc.f299.mp4' -i 'file:Antimatter Weapons - Threat or Ridiculous Pipe Dream-6zCH13oxlPc.f251.webm' -c copy -map 0:v:0 -map 1:a:0 'file:Antimatter Weapons - Threat or Ridiculous Pipe Dream-6zCH13oxlPc.temp.mkv'
Deleting original file Antimatter Weapons - Threat or Ridiculous Pipe Dream-6zCH13oxlPc.f299.mp4 (pass -k to keep)
Deleting original file Antimatter Weapons - Threat or Ridiculous Pipe Dream-6zCH13oxlPc.f251.webm (pass -k to keep)

If you did something to fix #31530 before (which would also have fixed the download speed), do the same again to fix the return of #32066 (that's your "strange error"). If not, you can't have been using yt-dl for YouTube since February, but you can read #31530 to learn about the problem.
Or just stick with the unofficial nightly build, which has the same effect.

Yesterday was the first time since December that I used YTDL, and since the nightly build seems to fix the issue, I'm just going to stick with the nightly build for now, rather than messing around with it anymore, because I don't want to break everything again.

In that case, your issue is a slightly complicated duplicate of #31530, and you've found one of the suggested solutions. For now keep using and updating, if necessary, the unofficial nightly build, but do report issues here rather than in the repo from which you downloaded it.