Memory consumption keeps increasing over time.

We have multiple instances of Skupper v1.4.2 and, although the setup of the instances is very similar (if not the same), one of these has the skupper-router container v2.4.2-2 with a memory consumption that keeps increasing over time and reaches multiple GBs (approx 22 GiB in less than 24h). And the number of edges (5 for the bad environment) doesn't justify this high memory consumption.

Any idea what the problem could be?
Could it be an edge that is misconfigured?
Below the report of the skstat -m of the "bad instance" and another normal instance.
2023-11-03 18:05:47.021967 UTC skupper-router-75bb6bff76-6g65s

Memory Pools
  type                        size    batch  thread-max  total   in-threads  rebal-in   rebal-out
  =================================================================================================
  endpoint_ref_t              56      64     128         64      64          0          0
  qd_adaptor_buffer_t         16,408  16     32          144     112         2,608      2,610
  qd_adaptor_config_t         72      64     128         64      64          0          0
  qd_adaptor_listener_t       160     64     128         64      64          0          0
  qd_bitmask_t                24      64     128         576     448         3,235      3,237
  qd_buffer_t                 4,096   16     32          512     112         124,635    124,660
  qd_composed_field_t         48      64     128         448     448         0          0
  qd_composite_t              112     64     128         448     448         0          0
  qd_connection_t             2,504   16     32          6,592   6,592       0          0
  qd_delivery_state_t         48      64     128         512     384         3,219      3,221
  qd_hash_handle_t            16      64     128         256     256         0          0
  qd_hash_item_t              40      64     128         256     256         0          0
  qd_iterator_t               128     64     128         640     512         1,351      1,353
  qd_link_ref_t               24      64     128         384     256         23         25
  qd_link_t                   136     64     128         6,976   6,976       0          0
  qd_listener_t               360     64     128         64      64          0          0
  qd_log_entry_t              2,112   16     32          1,056   1,056       0          0
  qd_management_context_t     56      64     128         192     192         0          0
  qd_message_content_t        1,088   64     128         640     576         1,075      1,076
  qd_message_stream_data_t    120     64     128         384     256         83         85
  qd_message_t                96      64     128         12,032  512         625,192    625,372
  qd_node_t                   56      64     128         64      64          0          0
  qd_parse_node_t             104     64     128         128     128         0          0
  qd_parse_tree_t             32      64     128         64      64          0          0
  qd_parsed_field_t           136     64     128         448     384         330        331
  qd_session_t                48      64     128         6,720   6,720       0          0
  qd_tcp_adaptor_config_t     16      64     128         64      64          0          0
  qd_tcp_connector_t          72      64     128         64      64          0          0
  qd_tcp_listener_t           72      64     128         64      64          0          0
  qd_timer_t                  112     64     128         64      64          0          0
  qdr_action_t                136     64     128         5,056   320         1,462,796  1,462,870
  qdr_addr_endpoint_state_t   48      64     128         64      64          0          0
  qdr_address_config_t        72      64     128         64      64          0          0
  qdr_address_t               392     64     128         256     256         0          0
  qdr_address_watch_t         72      64     128         64      64          0          0
  qdr_connection_info_t       144     64     128         6,912   6,912       5          5
  qdr_connection_ref_t        24      64     128         64      64          0          0
  qdr_connection_t            584     64     128         6,912   6,912       5          5
  qdr_connection_work_t       56      64     128         512     384         114        116
  qdr_core_timer_t            40      64     128         64      64          0          0
  qdr_delivery_cleanup_t      32      64     128         9,216   384         629,836    629,974
  qdr_delivery_ref_t          24      64     128         512     512         20,876     20,876
  qdr_delivery_t              344     64     128         9,792   256         585,990    586,139
  qdr_field_t                 32      64     128         448     192         1,736      1,740
  qdr_forward_deliver_info_t  32      64     128         2,240   64          594,481    594,515
  qdr_general_work_t          160     64     128         3,328   448         112,730    112,775
  qdr_link_ref_t              24      64     128         18,496  14,208      678,911    678,978
  qdr_link_t                  512     64     128         7,232   7,232       13         13
  qdr_link_work_t             48      64     128         4,800   384         628,871    628,940
  qdr_query_t                 344     64     128         256     256         0          0
  qdr_tcp_connection_t        2,472   16     32          96      80          25         26
  qdr_tcp_stats_t             72      64     128         64      64          0          0
  qdr_terminus_t              64      64     128         512     448         3          4
  qdrc_endpoint_t             24      64     128         64      64          0          0
  vflow_attribute_data_t      32      64     128         256     256         0          0
  vflow_rate_t                112     64     128         64      64          0          0
  vflow_record_t              160     64     128         384     256         3          5
  vflow_work_t                56      64     128         448     256         45,157     45,160

Memory Summary
  VmSize    Pooled
  ====================
  6.49 GiB  39.8 MiB

2023-11-03 18:08:32.242316 UTC skupper-router-5545fd9f94-87pgx

Memory Pools
  type                        size    batch  thread-max  total  in-threads  rebal-in   rebal-out
  ================================================================================================
  endpoint_ref_t              56      64     128         64     64          0          0
  qd_adaptor_buffer_t         16,408  16     32          288    192         29,308     29,314
  qd_adaptor_config_t         72      64     128         192    192         0          0
  qd_adaptor_listener_t       160     64     128         192    192         0          0
  qd_bitmask_t                24      64     128         448    320         22,098     22,100
  qd_buffer_t                 4,096   16     32          672    176         2,349,831  2,349,862
  qd_composed_field_t         48      64     128         448    448         0          0
  qd_composite_t              112     64     128         448    448         0          0
  qd_connection_t             2,504   16     32          96     96          1          1
  qd_deferred_call_t          32      64     128         64     64          0          0
  qd_delivery_state_t         48      64     128         512    320         54,823     54,826
  qd_hash_handle_t            16      64     128         128    128         0          0
  qd_hash_item_t              40      64     128         128    128         0          0
  qd_iterator_t               128     64     128         640    512         16,186     16,188
  qd_link_ref_t               24      64     128         448    320         123        125
  qd_link_t                   136     64     128         320    256         0          1
  qd_listener_t               360     64     128         64     64          0          0
  qd_log_entry_t              2,112   16     32          1,056  1,056       0          0
  qd_management_context_t     56      64     128         256    256         0          0
  qd_message_content_t        1,088   64     128         704    512         12,979     12,982
  qd_message_stream_data_t    120     64     128         384    320         480        481
  qd_message_t                96      64     128         1,344  448         69,199     69,213
  qd_node_t                   56      64     128         64     64          0          0
  qd_parse_node_t             104     64     128         128    128         0          0
  qd_parse_tree_t             32      64     128         64     64          0          0
  qd_parsed_field_t           136     64     128         704    320         7,853      7,859
  qd_pn_free_link_session_t   32      64     128         256    256         0          0
  qd_session_t                48      64     128         256    256         0          0
  qd_tcp_adaptor_config_t     16      64     128         192    192         0          0
  qd_tcp_connector_t          72      64     128         64     64          0          0
  qd_tcp_listener_t           72      64     128         192    192         0          0
  qd_timer_t                  112     64     128         64     64          0          0
  qdr_action_t                136     64     128         576    384         1,040,214  1,040,217
  qdr_addr_endpoint_state_t   48      64     128         64     64          0          0
  qdr_address_config_t        72      64     128         64     64          0          0
  qdr_address_t               392     64     128         128    128         0          0
  qdr_address_watch_t         72      64     128         64     64          0          0
  qdr_connection_info_t       144     64     128         448    384         250        251
  qdr_connection_ref_t        24      64     128         64     64          0          0
  qdr_connection_t            584     64     128         448    384         250        251
  qdr_connection_work_t       56      64     128         512    448         499        500
  qdr_core_timer_t            40      64     128         64     64          0          0
  qdr_delivery_cleanup_t      32      64     128         896    384         102,438    102,446
  qdr_delivery_ref_t          24      64     128         576    320         225,802    225,806
  qdr_delivery_t              344     64     128         1,152  320         28,852     28,865
  qdr_field_t                 32      64     128         448    256         18,733     18,736
  qdr_forward_deliver_info_t  32      64     128         64     64          0          0
  qdr_general_work_t          160     64     128         512    320         68,560     68,563
  qdr_link_ref_t              24      64     128         832    640         621,344    621,347
  qdr_link_t                  512     64     128         512    448         502        503
  qdr_link_work_t             48      64     128         576    384         88,023     88,026
  qdr_query_t                 344     64     128         320    320         0          0
  qdr_tcp_connection_t        2,472   16     32          112    80          993        995
  qdr_tcp_stats_t             72      64     128         192    192         0          0
  qdr_terminus_t              64      64     128         384    384         2          2
  qdrc_endpoint_t             24      64     128         64     64          0          0
  vflow_attribute_data_t      32      64     128         448    320         26         28
  vflow_rate_t                112     64     128         64     64          0          0
  vflow_record_t              160     64     128         384    320         247        248
  vflow_work_t                56      64     128         512    256         533,874    533,878

Memory Summary
  VmSize   Pooled
  ===================
  563 MiB  12.7 MiB

"bad":
Router Statistics
  attr                             value
  =======================================================================================
  Version                          2.4.2
  Mode                             interior
  Router Id                        skupper-router-75bb6bff76-6g65s
  Worker Threads                   4
  Uptime                           000:22:01:07
  VmSize                           22.7 GiB
  Area                             0
  Auto Links                       0
  Links                            24284
  Nodes                            0
  Addresses                        149
  Connections                      23958
  Presettled Count                 871776
  Dropped Presettled Count         2
  Accepted Count                   120988
  Rejected Count                   0
  Released Count                   0
  Modified Count                   0
  Deliveries Delayed > 1sec        89
  Deliveries Delayed > 10sec       147
  Deliveries Stuck > 10sec         13
  Links Blocked                    38
  Ingress Count                    992785
  Egress Count                     505754339
  Transit Count                    0
  Deliveries from Route Container  0
  Deliveries to Route Container    0

normal:
Router Statistics
  attr                             value
  =======================================================================================

  Version                          2.4.2
  Mode                             interior
  Router Id                        skupper-router-5545fd9f94-87pgx
  Worker Threads                   4
  Uptime                           003:19:48:10
  VmSize                           563 MiB
  Area                             0
  Auto Links                       0
  Links                            143
  Nodes                            0
  Addresses                        40
  Connections                      44
  Presettled Count                 1609937
  Dropped Presettled Count         3132
  Accepted Count                   621386
  Rejected Count                   0
  Released Count                   0
  Modified Count                   23
  Deliveries Delayed > 1sec        1250
  Deliveries Delayed > 10sec       20707
  Deliveries Stuck > 10sec         0
  Links Blocked                    0
  Ingress Count                    2231392
  Egress Count                     5444193
  Transit Count                    0
  Deliveries from Route Container  0
  Deliveries to Route Container    0

It's clear that we have too many connection opens but the number of edges (5 for the bad environment) doesn't justify it
$ kubectl --kubeconfig k exec -it skupper-router-75bb6bff76-6g65s -n bad -- skstat --connections | wc -l
Defaulted container "router" out of: router, config-sync
Unable to use a TTY - input is not a terminal or the right kind of file
24285

$ kubectl --kubeconfig k exec -it skupper-router-5545fd9f94-87pgx -n good-- skstat --connections | wc -l
Defaulted container "router" out of: router, config-sync
Unable to use a TTY - input is not a terminal or the right kind of file
50

Kept digging a bit, and with log level set to info we see a set of 3 connection opened every 10 seconds. Apparently these are the connections that stay open; hence the memory consumption.
2023-11-04 14:03:52.421565 +0000 SERVER (info) [C74] Accepted connection to :5671 from <IP_ADDRESS>:54016
2023-11-04 14:03:52.447510 +0000 ROUTER_CORE (info) [C74] Connection Opened: dir=in host=<IP_ADDRESS>:54016 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=eKfLLvQChbDn_Xg1judMer01t8KpHzS8lI5X8ULIqNSJOw7KsWYehg props=
2023-11-04 14:03:52.448530 +0000 ROUTER_CORE (info) [C74][L332] Link attached: dir=out source={mc/sfe.5k5vq:0 expire:sess} target={<none> expire:sess}
2023-11-04 14:03:52.477837 +0000 SERVER (info) [C73] Accepted connection to :5671 from <IP_ADDRESS>:54008
2023-11-04 14:03:52.480861 +0000 SERVER (info) [C75] Accepted connection to :5671 from <IP_ADDRESS>:54028
2023-11-04 14:03:52.493783 +0000 ROUTER_CORE (info) [C73] Connection Opened: dir=in host=<IP_ADDRESS>:54008 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=opo6spKrgHVYObYnaRdWQCNuSToOCev4FIL1nlxuynIjqU40f11_VA props=
2023-11-04 14:03:52.495941 +0000 ROUTER_CORE (info) [C73][L333] Link attached: dir=out source={mc/sfe.5k5vq:0.flows expire:sess} target={<none> expire:sess}
2023-11-04 14:03:52.498905 +0000 ROUTER_CORE (info) [C75] Connection Opened: dir=in host=<IP_ADDRESS>:54028 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=MK2Fr0KGh6NDSK_6CseRKqOmcjSZ-DMn7F_UjkOmnZxFQWHuUb2X9A props=
2023-11-04 14:03:52.499577 +0000 ROUTER_CORE (info) [C75][L334] Link attached: dir=in source={<none> expire:sess} target={sfe.5k5vq:0 expire:sess}

2023-11-04 14:04:02.445625 +0000 SERVER (info) [C77] Accepted connection to :5671 from <IP_ADDRESS>:49188
2023-11-04 14:04:02.456607 +0000 ROUTER_CORE (info) [C77] Connection Opened: dir=in host=<IP_ADDRESS>:49188 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=nOp39uX_kaiyBYqHJT-UWB1SCfW8k2ZAUZxiIVeY2UDapRBW-cmvFA props=
2023-11-04 14:04:02.456874 +0000 SERVER (info) [C76] Accepted connection to :5671 from <IP_ADDRESS>:49180
2023-11-04 14:04:02.457993 +0000 ROUTER_CORE (info) [C77][L335] Link attached: dir=out source={mc/sfe.5k5vq:0 expire:sess} target={<none> expire:sess}
2023-11-04 14:04:02.464047 +0000 SERVER (info) [C78] Accepted connection to :5671 from <IP_ADDRESS>:49194
2023-11-04 14:04:02.465785 +0000 ROUTER_CORE (info) [C76] Connection Opened: dir=in host=<IP_ADDRESS>:49180 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=1KyToNmJ7XEgh0gJRw2CI4Mssfbla5Z5Re8ek0fc-eBrdFk2aYO1mQ props=
2023-11-04 14:04:02.466459 +0000 ROUTER_CORE (info) [C76][L336] Link attached: dir=out source={mc/sfe.5k5vq:0.flows expire:sess} target={<none> expire:sess}
2023-11-04 14:04:02.470814 +0000 ROUTER_CORE (info) [C78] Connection Opened: dir=in host=<IP_ADDRESS>:49194 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=TYhuzBUENuZ8HkfGFRZa_COagLMoPsmaoZ8OJvZqqC8GeYqLzS6BqA props=
2023-11-04 14:04:02.471996 +0000 ROUTER_CORE (info) [C78][L337] Link attached: dir=in source={<none> expire:sess} target={sfe.5k5vq:0 expire:sess}

On Sat, Nov 4, 2023 at 10:09 AM Nicola Cadenelli @.***>
wrote:

Kept digging a bit, and with log level set to info we see a set of 3
connection opened every 10 seconds. Apparently these are the connections
that stay open; hence the memory consumption.

Were you seeing the same memory growth issue in the previous versions ?
What is the last version of the router where this kind memory growth did
not happen?
Also, what is the traffic pattern your test is generating ?
There seems to be 3 connections opened every 10 seconds, do the connections
disconnect at any point or do you simply keep adding more and more
connections in your test ?
Thanks.

2023-11-04 14:03:52.421565 +0000 SERVER (info) [C74] Accepted connection to :5671 from <IP_ADDRESS>:54016
2023-11-04 14:03:52.447510 +0000 ROUTER_CORE (info) [C74] Connection Opened: dir=in host=<IP_ADDRESS>:54016 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=eKfLLvQChbDn_Xg1judMer01t8KpHzS8lI5X8ULIqNSJOw7KsWYehg props=
2023-11-04 14:03:52.448530 +0000 ROUTER_CORE (info) [C74][L332] Link attached: dir=out source={mc/sfe.5k5vq:0 expire:sess} target={ expire:sess}
2023-11-04 14:03:52.477837 +0000 SERVER (info) [C73] Accepted connection to :5671 from <IP_ADDRESS>:54008
2023-11-04 14:03:52.480861 +0000 SERVER (info) [C75] Accepted connection to :5671 from <IP_ADDRESS>:54028
2023-11-04 14:03:52.493783 +0000 ROUTER_CORE (info) [C73] Connection Opened: dir=in host=<IP_ADDRESS>:54008 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=opo6spKrgHVYObYnaRdWQCNuSToOCev4FIL1nlxuynIjqU40f11_VA props=
2023-11-04 14:03:52.495941 +0000 ROUTER_CORE (info) [C73][L333] Link attached: dir=out source={mc/sfe.5k5vq:0.flows expire:sess} target={ expire:sess}
2023-11-04 14:03:52.498905 +0000 ROUTER_CORE (info) [C75] Connection Opened: dir=in host=<IP_ADDRESS>:54028 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=MK2Fr0KGh6NDSK_6CseRKqOmcjSZ-DMn7F_UjkOmnZxFQWHuUb2X9A props=
2023-11-04 14:03:52.499577 +0000 ROUTER_CORE (info) [C75][L334] Link attached: dir=in source={ expire:sess} target={sfe.5k5vq:0 expire:sess}
2023-11-04 14:04:02.445625 +0000 SERVER (info) [C77] Accepted connection to :5671 from <IP_ADDRESS>:49188
2023-11-04 14:04:02.456607 +0000 ROUTER_CORE (info) [C77] Connection Opened: dir=in host=<IP_ADDRESS>:49188 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=nOp39uX_kaiyBYqHJT-UWB1SCfW8k2ZAUZxiIVeY2UDapRBW-cmvFA props=
2023-11-04 14:04:02.456874 +0000 SERVER (info) [C76] Accepted connection to :5671 from <IP_ADDRESS>:49180
2023-11-04 14:04:02.457993 +0000 ROUTER_CORE (info) [C77][L335] Link attached: dir=out source={mc/sfe.5k5vq:0 expire:sess} target={ expire:sess}
2023-11-04 14:04:02.464047 +0000 SERVER (info) [C78] Accepted connection to :5671 from <IP_ADDRESS>:49194
2023-11-04 14:04:02.465785 +0000 ROUTER_CORE (info) [C76] Connection Opened: dir=in host=<IP_ADDRESS>:49180 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=1KyToNmJ7XEgh0gJRw2CI4Mssfbla5Z5Re8ek0fc-eBrdFk2aYO1mQ props=
2023-11-04 14:04:02.466459 +0000 ROUTER_CORE (info) [C76][L336] Link attached: dir=out source={mc/sfe.5k5vq:0.flows expire:sess} target={ expire:sess}
2023-11-04 14:04:02.470814 +0000 ROUTER_CORE (info) [C78] Connection Opened: dir=in host=<IP_ADDRESS>:49194 encrypted=TLSv1.3 auth=EXTERNAL user=CN=skupper-router-local container_id=TYhuzBUENuZ8HkfGFRZa_COagLMoPsmaoZ8OJvZqqC8GeYqLzS6BqA props=
2023-11-04 14:04:02.471996 +0000 ROUTER_CORE (info) [C78][L337] Link attached: dir=in source={ expire:sess} target={sfe.5k5vq:0 expire:sess}
—
Reply to this email directly, view it on GitHub
https://github.com/skupperproject/skupper-router/issues/1291#issuecomment-1793453622,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AASKJ6TJ2RDHUPTC4C57LELYCZEA3AVCNFSM6AAAAAA642SU22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOJTGQ2TGNRSGI
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

Were you seeing the same memory growth issue in the previous versions ?
No, we didn't see this issue before. Or at least it wasn't so problematic.

What is the last version of the router where this kind memory growth did
not happen?
We moved from 1.4.1 to 1.4.2 on September the 5th. When we did this we also set serviceSync: "true", before we were not setting it and we did see this issue.

Also, what is the traffic pattern your test is generating ?
There seems to be 3 connections opened every 10 seconds, do the connections
disconnect at any point or do you simply keep adding more and more
connections in your test ?
We are not testing any traffic pattern per se. And I've tried to pin point these 3 connections but not sure where they come from. We have different services using Skupper to reach each others.

We moved from 1.4.1 to 1.4.2 on September the 5th. When we did this we also set serviceSync: "true", before we were not setting it and we did see this issue.

It is not really clear to me what you are saying. Are you able to run the same reproducer against two versions of the router and able to say that in one version you are seeing the memory growth and not seeing memory growth in the other. That would give us a good starting point to analyze this issue.

Hi @nicolacdnll - thanks for the detailed output dumps.
From the look of it, the skupper controller seems to be opening an absurd number of connections and leaving them up.  If you look at the log output you'll see references to "sfe.XXX"
I'm going to ask our resident skupper controller expert to take a look at this.

Hi @nicolacdnll the log reference to "sfe.XXX" indicates you are running the flow collector in your deployment. In the 1.4.2 release, there was an issue where the connection to a purged event source was not closed. This will be resolved in the 1.5.0 release which should be available next week. Disabling the collector should inhibit the memory growth you are seeing in 1.4.2.
That said, it would be worth understanding why the collector is losing connectivity with the router indicated by "sfe.5k5vq:0". Can you provide a snippet of the log from the flow collector container that is running as a sidecar to the service-controller pod? Where have you placed your collector in relation to that router?

Yes, we were using the flow collector and release 1.4.2. The router and flow-collector are in different pods that belong to the same namespace. But the pods are those created by the site-controller.
The snippets I have are from the past days (in the meantime we had already moved to 1.4.3 and did many redeploy):
2023/11/09 07:11:39 COLLECTOR: Error receiving message  dial tcp <IP_ADDRESS>:5671: connect: cannot assign requested address
2023/11/09 07:11:39 COLLECTOR: Error sending out updates dial tcp <IP_ADDRESS>:5671: connect: cannot assign requested address
2023/11/09 07:11:39 COLLECTOR: Error sending out updates dial tcp <IP_ADDRESS>:5671: connect: cannot assign requested address
2023/11/09 07:11:39 COLLECTOR: Error sending out updates dial tcp <IP_ADDRESS>:5671: connect: cannot assign requested address
2023/11/09 07:11:39 COLLECTOR: Error receiving message  dial tcp <IP_ADDRESS>:5671: connect: cannot assign requested address
2023/11/09 07:11:39 COLLECTOR: Error receiving message  dial tcp <IP_ADDRESS>:5671: connect: cannot assign requested address
2023/11/09 07:11:39 COLLECTOR: Error receiving message  dial tcp <IP_ADDRESS>:5671: connect: cannot assign requested address
2023/11/09 07:11:39 COLLECTOR: Error sending out updates dial tcp <IP_ADDRESS>:5671: connect: cannot assign requested address
2023/11/09 07:11:39 COLLECTOR: Error sending out updates dial tcp <IP_ADDRESS>:5671: connect: cannot assign requested address
2023/11/09 07:11:39 COLLECTOR: Error sending out updates dial tcp <IP_ADDRESS>:5671: connect: cannot assign requested address
[...]
2023/11/09 07:11:39 COLLECTOR: Error sending out updates dial tcp <IP_ADDRESS>:5671: connect: cannot assign requested address
2023/11/09 07:11:39 COLLECTOR: Error sending out updates dial tcp <IP_ADDRESS>:5671: connect: connection refused

Here also an older screenshot:

Also, here some snippet from the other "good" deployment always using 1.4.2 where the issue doesn't manifest:
2023/11/10 14:15:08 FLOW_LOG: {"recType":"FLOW","identity":"tqnvs:92950","parent":"tqnvs:88741","startTime":1699624806818516,"endTime":1699624806951094,"sourceHost":"<IP_ADDRESS>","sourcePort":"33154","counterFlow":"87pgx:55573","latency":44076,"octets":378,"octetsUnacked":47,"windowSize":1459620,"process":"15820deb-c100-4dd7-8a17-d38933a688ae","processName":"site-clients-166ae776","protocol":"tcp","place":1}
2023/11/10 14:15:08 FLOW_LOG: {"recType":"FLOWPAIR","identity":"fp-tqnvs:92950","startTime":1699624806818516,"endTime":1699624806951094,"protocol":"tcp","sourceSiteId":"166ae776-c886-4b3d-807f-b011922efc35","sourceSiteName":"k8s-f8f6d4a1-220e-4189-9ce4-488b83a1a221","destinationSiteId":"1c06804c-7eba-4b51-addd-ef54ef5af335","destinationSiteName":"foobar-controller","flowTrace":"foobar-controller-skupper-router-5545fd9f94-87pgx@foobar-controller","forwardFlow":{"recType":"FLOW","identity":"tqnvs:92950","parent":"tqnvs:88741","startTime":1699624806818516,"endTime":1699624806951094,"sourceHost":"<IP_ADDRESS>","sourcePort":"33154","counterFlow":"87pgx:55573","latency":44076,"octets":378,"octetsUnacked":47,"windowSize":1459620,"process":"15820deb-c100-4dd7-8a17-d38933a688ae","processName":"site-clients-166ae776","protocol":"tcp","place":1},"counterFlow":{"recType":"FLOW","identity":"87pgx:55573","parent":"87pgx:51347","startTime":1699624806836753,"endTime":1699624806931718,"sourceHost":"<IP_ADDRESS>","sourcePort":"50806","counterFlow":"tqnvs:92950","trace":"Local","latency":5721,"octets":464,"octetsUnacked":17,"windowSize":1459620,"process":"3fdbcff8-6a16-4014-aa5a-158f2398da67","processName":"site-servers-1c06804c","protocol":"tcp","place":2},"siteAggregateId":"166ae776-c886-4b3d-807f-b011922efc35-to-1c06804c-7eba-4b51-addd-ef54ef5af335","processGroupAggregateId":"43ddd417-f34d-4887-8204-bf985d52fb07-to-8641b4db-e472-449c-8e90-2c81beae98b5","processAggregateId":"15820deb-c100-4dd7-8a17-d38933a688ae-to-3fdbcff8-6a16-4014-aa5a-158f2398da67"}
2023/11/10 14:15:08 FLOW_LOG: {"recType":"FLOW","identity":"87pgx:55573","parent":"87pgx:51347","startTime":1699624806836753,"endTime":1699624806931718,"sourceHost":"<IP_ADDRESS>","sourcePort":"50806","counterFlow":"tqnvs:92950","trace":"Local","latency":5721,"octets":464,"octetsUnacked":17,"windowSize":1459620,"process":"3fdbcff8-6a16-4014-aa5a-158f2398da67","processName":"site-servers-1c06804c","protocol":"tcp","place":2}
2023/11/10 14:15:10 FLOW_LOG: {"recType":"FLOW","identity":"87pgx:55553","parent":"87pgx:38905","startTime":1699624465304429,"endTime":1699624810532010,"sourceHost":"<IP_ADDRESS>","sourcePort":"49528","counterFlow":"tqnvs:92930","trace":"Local","latency":827,"octets":41495,"octetsUnacked":410,"windowSize":1459620,"process":"43894bff-2e1c-4c05-9ded-388b0df6fea4","processName":"foobar-alerta-api-d4b5d4fb9-gq6dj","protocol":"tcp","place":2}
2023/11/10 14:15:10 FLOW_LOG: {"recType":"FLOW","identity":"tqnvs:92930","parent":"tqnvs:56325","startTime":1699624465248219,"endTime":1699624810512919,"sourceHost":"<IP_ADDRESS>","sourcePort":"47260","counterFlow":"87pgx:55553","latency":77397,"octets":338229,"octetsUnacked":5626,"windowSize":1459620,"process":"15820deb-c100-4dd7-8a17-d38933a688ae","processName":"site-clients-166ae776","protocol":"tcp","place":1}
2023/11/10 14:15:10 FLOW_LOG: {"recType":"FLOWPAIR","identity":"fp-tqnvs:92930","startTime":1699624465248219,"endTime":1699624810512919,"protocol":"tcp","sourceSiteId":"166ae776-c886-4b3d-807f-b011922efc35","sourceSiteName":"k8s-f8f6d4a1-220e-4189-9ce4-488b83a1a221","destinationSiteId":"1c06804c-7eba-4b51-addd-ef54ef5af335","destinationSiteName":"foobar-controller","flowTrace":"foobar-controller-skupper-router-5545fd9f94-87pgx@foobar-controller","forwardFlow":{"recType":"FLOW","identity":"tqnvs:92930","parent":"tqnvs:56325","startTime":1699624465248219,"endTime":1699624810512919,"sourceHost":"<IP_ADDRESS>","sourcePort":"47260","counterFlow":"87pgx:55553","latency":77397,"octets":338229,"octetsUnacked":5626,"windowSize":1459620,"process":"15820deb-c100-4dd7-8a17-d38933a688ae","processName":"site-clients-166ae776","protocol":"tcp","place":1},"counterFlow":{"recType":"FLOW","identity":"87pgx:55553","parent":"87pgx:38905","startTime":1699624465304429,"endTime":1699624810532010,"sourceHost":"<IP_ADDRESS>","sourcePort":"49528","counterFlow":"tqnvs:92930","trace":"Local","latency":827,"octets":41495,"octetsUnacked":410,"windowSize":1459620,"process":"43894bff-2e1c-4c05-9ded-388b0df6fea4","processName":"foobar-alerta-api-d4b5d4fb9-gq6dj","protocol":"tcp","place":2},"siteAggregateId":"166ae776-c886-4b3d-807f-b011922efc35-to-1c06804c-7eba-4b51-addd-ef54ef5af335","processGroupAggregateId":"43ddd417-f34d-4887-8204-bf985d52fb07-to-0c700ee5-0417-4273-9623-7e75bcc4224a","processAggregateId":"15820deb-c100-4dd7-8a17-d38933a688ae-to-43894bff-2e1c-4c05-9ded-388b0df6fea4"}
2023/11/10 14:15:54 FLOW_LOG: {"recType":"FLOW","identity":"tqnvs:92953","parent":"tqnvs:11","startTime":1699624853297947,"endTime":1699624853383894,"sourceHost":"<IP_ADDRESS>","sourcePort":"48096","counterFlow":"87pgx:55576","trace":"0/foobar-controller-skupper-router-5545fd9f94-87pgx","latency":2331,"octets":2049,"octetsUnacked":24,"windowSize":1459620,"process":"aa4c5019-e726-421f-8378-34ac46d7488c","processName":"site-servers-166ae776","protocol":"tcp","place":2}
2023/11/10 14:15:54 FLOW_LOG: {"recType":"FLOW","identity":"87pgx:55576","parent":"87pgx:6","startTime":1699624853276648,"endTime":1699624853402588,"sourceHost":"<IP_ADDRESS>","sourcePort":"52696","counterFlow":"tqnvs:92953","latency":41180,"octets":590,"octetsUnacked":24,"windowSize":1459620,"process":"10acc232-a858-4e68-9335-9156fbdeef44","processName":"site-clients-1c06804c","protocol":"tcp","place":1}
2023/11/10 14:15:54 FLOW_LOG: {"recType":"FLOWPAIR","identity":"fp-87pgx:55576","startTime":1699624853276648,"endTime":1699624853402588,"protocol":"tcp","sourceSiteId":"1c06804c-7eba-4b51-addd-ef54ef5af335","sourceSiteName":"foobar-controller","destinationSiteId":"166ae776-c886-4b3d-807f-b011922efc35","destinationSiteName":"k8s-f8f6d4a1-220e-4189-9ce4-488b83a1a221","flowTrace":"foobar-controller-skupper-router-5545fd9f94-87pgx@foobar-controller|k8s-f8f6d4a1-220e-4189-9ce4-488b83a1a221-skupper-router-67c77f688d-tqnvs@k8s-f8f6d4a1-220e-4189-9ce4-488b83a1a221","forwardFlow":{"recType":"FLOW","identity":"87pgx:55576","parent":"87pgx:6","startTime":1699624853276648,"endTime":1699624853402588,"sourceHost":"<IP_ADDRESS>","sourcePort":"52696","counterFlow":"tqnvs:92953","latency":41180,"octets":590,"octetsUnacked":24,"windowSize":1459620,"process":"10acc232-a858-4e68-9335-9156fbdeef44","processName":"site-clients-1c06804c","protocol":"tcp","place":1},"counterFlow":{"recType":"FLOW","identity":"tqnvs:92953","parent":"tqnvs:11","startTime":1699624853297947,"endTime":1699624853383894,"sourceHost":"<IP_ADDRESS>","sourcePort":"48096","counterFlow":"87pgx:55576","trace":"0/foobar-controller-skupper-router-5545fd9f94-87pgx","latency":2331,"octets":2049,"octetsUnacked":24,"windowSize":1459620,"process":"aa4c5019-e726-421f-8378-34ac46d7488c","processName":"site-servers-166ae776","protocol":"tcp","place":2},"siteAggregateId":"1c06804c-7eba-4b51-addd-ef54ef5af335-to-166ae776-c886-4b3d-807f-b011922efc35","processGroupAggregateId":"43ddd417-f34d-4887-8204-bf985d52fb07-to-8641b4db-e472-449c-8e90-2c81beae98b5","processAggregateId":"10acc232-a858-4e68-9335-9156fbdeef44-to-aa4c5019-e726-421f-8378-34ac46d7488c"}
2023/11/10 14:15:56 FLOW_LOG: {"recType":"FLOW","identity":"87pgx:55628","parent":"87pgx:6","startTime":1699625756381013,"endTime":0,"sourceHost":"<IP_ADDRESS>","sourcePort":"52528","latency":43831,"octets":590,"octetsUnacked":24,"windowSize":1459620,"protocol":"tcp","place":1}
2023/11/10 14:15:56 FLOW_LOG: {"recType":"FLOW","identity":"tqnvs:93005","parent":"tqnvs:11","startTime":1699625756401773,"endTime":1699625756486466,"sourceHost":"<IP_ADDRESS>","sourcePort":"56132","counterFlow":"87pgx:55628","trace":"0/foobar-controller-skupper-router-5545fd9f94-87pgx","latency":2027,"octets":2049,"octetsUnacked":24,"windowSize":1459620,"protocol":"tcp","place":2}
2023/11/10 14:15:56 COLLECTOR: Associating flow 87pgx:55628 to external process site-clients-1c06804c
2023/11/10 14:16:22 FLOW_LOG: {"recType":"FLOW","identity":"87pgx:55562","parent":"87pgx:38905","startTime":1699624625409327,"endTime":1699624881739727,"sourceHost":"<IP_ADDRESS>","sourcePort":"55448","counterFlow":"tqnvs:92939","trace":"Local","latency":1315,"octets":41495,"octetsUnacked":410,"windowSize":1459620,"process":"43894bff-2e1c-4c05-9ded-388b0df6fea4","processName":"foobar-alerta-api-d4b5d4fb9-gq6dj","protocol":"tcp","place":2}
2023/11/10 14:16:22 FLOW_LOG: {"recType":"FLOW","identity":"tqnvs:92939","parent":"tqnvs:56325","startTime":1699624625312022,"endTime":1699624881716392,"sourceHost":"<IP_ADDRESS>","sourcePort":"38032","counterFlow":"87pgx:55562","latency":120770,"octets":314362,"octetsUnacked":2401,"windowSize":1459620,"process":"15820deb-c100-4dd7-8a17-d38933a688ae","processName":"site-clients-166ae776","protocol":"tcp","place":1}
2023/11/10 14:16:22 FLOW_LOG: {"recType":"FLOWPAIR","identity":"fp-tqnvs:92939","startTime":1699624625312022,"endTime":1699624881716392,"protocol":"tcp","sourceSiteId":"166ae776-c886-4b3d-807f-b011922efc35","sourceSiteName":"k8s-f8f6d4a1-220e-4189-9ce4-488b83a1a221","destinationSiteId":"1c06804c-7eba-4b51-addd-ef54ef5af335","destinationSiteName":"foobar-controller","flowTrace":"foobar-controller-skupper-router-5545fd9f94-87pgx@foobar-controller","forwardFlow":{"recType":"FLOW","identity":"tqnvs:92939","parent":"tqnvs:56325","startTime":1699624625312022,"endTime":1699624881716392,"sourceHost":"<IP_ADDRESS>","sourcePort":"38032","counterFlow":"87pgx:55562","latency":120770,"octets":314362,"octetsUnacked":2401,"windowSize":1459620,"process":"15820deb-c100-4dd7-8a17-d38933a688ae","processName":"site-clients-166ae776","protocol":"tcp","place":1},"counterFlow":{"recType":"FLOW","identity":"87pgx:55562","parent":"87pgx:38905","startTime":1699624625409327,"endTime":1699624881739727,"sourceHost":"<IP_ADDRESS>","sourcePort":"55448","counterFlow":"tqnvs:92939","trace":"Local","latency":1315,"octets":41495,"octetsUnacked":410,"windowSize":1459620,"process":"43894bff-2e1c-4c05-9ded-388b0df6fea4","processName":"foobar-alerta-api-d4b5d4fb9-gq6dj","protocol":"tcp","place":2},"siteAggregateId":"166ae776-c886-4b3d-807f-b011922efc35-to-1c06804c-7eba-4b51-addd-ef54ef5af335","processGroupAggregateId":"43ddd417-f34d-4887-8204-bf985d52fb07-to-0c700ee5-0417-4273-9623-7e75bcc4224a","processAggregateId":"15820deb-c100-4dd7-8a17-d38933a688ae-to-43894bff-2e1c-4c05-9ded-388b0df6fea4"}
2023/11/10 14:16:25 FLOW_LOG: {"recType":"FLOW","identity":"87pgx:55629","parent":"87pgx:38905","startTime":1699625785903999,"endTime":0,"sourceHost":"<IP_ADDRESS>","sourcePort":"43688","counterFlow":"tqnvs:93006","trace":"Local","latency":1182,"octets":415,"octetsUnacked":415,"windowSize":1459620,"protocol":"tcp","place":2}
2023/11/10 14:16:26 FLOW_LOG: {"recType":"FLOW","identity":"tqnvs:93006","parent":"tqnvs:56325","startTime":1699625785882511,"endTime":0,"sourceHost":"<IP_ADDRESS>","sourcePort":"45194","latency":42732,"octets":2162,"octetsUnacked":2162,"windowSize":1459620,"protocol":"tcp","place":1}
2023/11/10 14:16:26 COLLECTOR: Associating flow tqnvs:93006 to external process site-clients-166ae776


Detect sub-shells without shell integration enabled and add a status to the tab directing the user to manual installation

Sub-shells don't support shell integration, example user confusion: https://github.com/microsoft/vscode/issues/154547
What if the shell integration addon detected when there is a sub-shell active for a certain amount of time by checking child process tracking for pwsh/bash/zsh/ssh, a preexec fired but not a precmd and enter was pressed x times? If all these conditions are met an informational status could be added to the terminal to help them install it.

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


GEODE-3415: Add apache-geode dependency to integration-test2

With the new SslException class, cryptoimpl now depends on apache-geode.dll. This commit adds the copy to the post build step of cli's integration-test2.

Wait, isn't this a circular dependency?  I thought when @pivotal-jbarrett asked for a more specific exception class, we'd be adding code for one to cryptoimpl, not importing one from the native client.  This seems bad to me at first blush, but I'll wait for others to comment....

@echobravopapa This is the first use a an NC exception in cryptoimpl, which makes cryptoimpl dependent on apache-geode.dll.  Which we have concluded is probably bad.

Agreed. I was discussing in our slack channel.
I think we should just rollback to throw std::exception as in the initial
commit. Alternatively, we could still use an SslException class that
inherits std::exception instead of apache.geode.excpetion.
On Fri, May 3, 2019 at 12:29 PM Blake Bender<EMAIL_ADDRESS>wrote:

@echobravopapa https://github.com/echobravopapa This is the first use a
an NC exception in cryptoimpl, which makes cryptoimpl dependent on
apache-geode.dll. Which we have concluded is probably bad.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/apache/geode-native/pull/483#issuecomment-489213037,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AD7KGX4QTQV74UPOA6KR7ALPTSG77ANCNFSM4HKVUPNQ
.

The circular dependency has always been there but it looks the the VC++ linker noticed that no symbols were imported and left the dll out of the implicit load set. While I prefer to solve the circular linker problem for this plugin so it can use meaningful exceptions, I am fine with just throwing a std::exception like std::invalid_argument. This exception should be caught inside the library and translated into a library Exception, probably SslException still makes sense in this case.
It also turns out that the pre-existing circular dependency is artificial. The real dependency was removed when we replaced SharedPtr with std::shared_ptr. Remove the unused header include in DHImpl.cpp, #include <geode/internal/geode_globals.hpp>. Then you can remove the dependency from the CMakeLists.txt, apache-geode.

Okay I’ll ask the vicious question here:  why do we have any exception classes implemented in a .cpp file at all?  They should be trivial classes, the implementation should all be in a header, and using them shouldn’t create a library dependency at all.  Is there a story there?

Because we had this silly idea that exceptions should capture a stack trace. Booo!
The stack trace code needs to be in the cpp to hide the fact it uses boost from the public api. It used to use all sorts of nasties in the past. If we got rid of stack tracing then yes it could be header only.


Add Yandex Translate service

You can add yandex translate in addition to google?

+++++

+++++

Done. You'll need an API key though


Re-enable optional coverage map loading in input tester

We removed this from input_tester::Tester when simplifying things. Now that we have a module cache, too, find the best way to do this, including building up total coverage across runs.

Closed by #699.


Add a suffix to the window title when running from a debug build

Since projects exported in debug mode run slower than those exported in release mode, this should be clearly presented to the user.
Thanks @bruvzg for suggesting a fix for the initial window title :slightly_smiling_face:
This partially addresses #20219.
Preview

I would add it only to main but leave the set_window_title binding alone, so that users can still override this if they want to.
It might also be worth showing it also on TOOLS enabled builds (but not the editor or project manager) for consistency. Especially if we eventually add an option to run the game from the editor with a release template.

I would add it only to main but leave the set_window_title binding alone, so that users can still override this if they want to.

I made it always visible so that users can notice it even if they override the window title in _ready() or a timer (which some kinds of games may be doing, such as idle games). It may look a bit jarring, but that's kind of the point; we want to make sure people don't accidentally distribute debug builds to end users :slightly_smiling_face:

It might also be worth showing it also on TOOLS enabled builds (but not the editor or project manager) for consistency. Especially if we eventually add an option to run the game from the editor with a release template.

I don't know if this can be done. If the project is running with a release template, it's not running from a tools-enabled build then :slightly_smiling_face:
That said, we could enable it for editor builds when not running the project from the editor (e.g. when you start the editor from a terminal in the project folder).

I made it always visible, so that users can notice it even if they override the window title in _ready() or a timer (some kinds of games may be doing this, such as idle games). It may look a bit jarring, but that's kind of the point; we want to make sure developers don't accidentally distribute debug builds to end users.

Sure, but I think some users will actually want to ship debug builds on purpose at some point, and if they need to fork the engine to remove this "(DEBUG)" print, it might be a hurdle. Think about jam games where they might have crashes in release builds and no time to investigate. There are even published console games that were shipped as debug builds back in the days for similar reasons (which is great now to reverse engineer them :P).
Still, I guess we can keep as is and see if anyone complains.

I don't know if this can be done. If the project is running with a release template, it's not running from a tools-enabled build then

What I meant is that it should show on the debug build you get when you press Run in the editor. If we had a feature to test run with the release template, then it would of course not be on the title of the release build, which lets you know at a glance whether you're testing a release or debug build from the editor.

I still think that overriding what set_window_title() does when called from scripts is wrong.
IMO the changes in main.cpp are sufficient: "DEBUG" will be added to the default window title, and users can choose to override it.

@akien-mga That makes sense. I'll change it after I get to resolve the current merge conflicts.

Thanks!

Cherry-picked for 3.2.2.


koji_import: adjust exit_sendmail and exit_koji_tag_build

make them aware of koji_import and prefer to use it over
koji_promote.
Signed-off-by: Mark Langsdorf<EMAIL_ADDRESS>

Updated release notes.


Updates for version 9.0.0 (csstype, reduce bundle, reorg)

Reference: https://github.com/typestyle/typestyle/pull/245
Reference: https://github.com/typestyle/csx/issues/37
Reference: https://github.com/typestyle/csx/issues/35
This PR contains the following changes

Heavy code refactoring of colors to create less objects and to reduce the overall bundle size
Switch to use csstype type definitions instead of typestyle type definitions
Switch to jest because of tooling
Switch to rollup for UMD build so the output resembles the src files

Breaking changes

named colors have been removed.  The named colors accounted for the majority of the bundle size and could not be optimized away because of how they were defined
some type definitions have been renamed (due to moving to csstype)
internal modules have been moved to top level to encourage direct imports.  This will break code that was incorrectly importing from 'csx/lib/internal/'.  Most modules can now be imported from 'csx/'

We should wait to move forward until csstips is updated to use csstype

This has been published to npm as version 9.0.0


doc: Added secret management documentation

What type of PR is this?
/kind documentation
What does this PR do / why we need it:
GITOPS-3394
Have you updated the necessary documentation?

[x] Documentation update is required by this PR.
[x] Documentation has been updated.

Which issue(s) this PR fixes:
Fixes #?
GITOPS-3394

This will work only on OCP versions 4.14+ as Secrets Store CSI operator is not available on lower versions
cc: @svghadi

This will work only on OCP versions 4.14+ as Secrets Store CSI operator is not available on lower versions cc: @svghadi

Should we add a note in doc about this? @ciiay

/lgtm

/lgtm

@iam-veeramalla Could you please confirm if we can merge this PR?

/lgtm
/approve


Merge remote-tracking branch 'origin/CB-2.54.0' into  'origin/CB-2.55.0'

See detailed description in the commit message.

seems like that is merged already


No such file or directory

I can't run train_embedding.pr or model.py.
It throws me error - No such file or directory: 'modelresnewnew3.ckpt'

i have same error , No such file or directory: 'modelresnewnew3.ckpt'
how produce this file
please any one help me

@kashyap32  did you solve the error

@kashyap32 that is the path to the pretrained. Just comment the line where model weights are being loaded and it should work!


SSL Handshake Error when deplying API Gateway

Hello,
Sorry to come with another issue, luckily I am just working on a small test project so switching from python 3.4 to python 2.7.6 was easy enough since I am not doing much that is impacted by switching versions (just testing mostly) though now when I run the deploy, it bundles the files up nicely, creates the lambda app, then create the API Gateway part which seems to complete without issue, but now when Deploying the API Gateway it errors with this: https://gist.github.com/tcross911/369d204d983919a1bbb236831206ef56

This actually bit somebody else the other day, https://github.com/Miserlou/Zappa/issues/69
Can you try:
pip install requests[security]

?

That definitely fixed the issue, had a few other issues after that, but those were issues with my code (forgot urllib.parse doesn't exist in 2.7 and it is urlparse for example).  Thanks so much for the help.

Great! Thanks for reporting, and thanks for using Zappa!


Expose coalesce module

The figment::coalesce::Coalescible trait seems very helpful when writing providers, any chance to make that pub?

Which things would be helpful?

Right now, I'm just copying the whole Coalescible implementation, so it would be helpful if I could import that instead of copying it. I'm using it  in a Provider to build a nested Dict from a mapping of key, value pairs where the keys are dot- or underscore-separated paths:
for (k, v) in self.data.iter().map(|(k, v)| {
    let key = k.to_ascii_lowercase().replace('_', ".");
    (key, v.to_owned())
}) {
    let nested_dict: std::collections::BTreeMap<String, figment::value::Value> =
        nest(k.as_str(), v.parse().expect("infallible"))
            .into_dict()
            .expect("key is non-empty: must have dict");

    dict = dict.merge(nested_dict);
}

let profile = Profile::default();
Ok(profile.collect(dict))

I do eventually want to expose the implementations underling the module in some form, but I'm not sure exposing it directly is the right way. I'll give this some more thought and post an update later day.


[go client] cannot use size (type _Ctype_int) as type _Ctype_ulong

Describe the bug
# github.com/apache/pulsar/pulsar-client-go/pulsar
../../pulsar/c_message.go:91:213: cannot use size (type _Ctype_int) as type _Ctype_ulong in argument to func literal

To Reproduce
Steps to reproduce the behavior:
1. git clone git@github.com:apache/pulsar.git
2. cd apache/pulsar/pulsar-client-cpp
3. cmake .
4. make
5. make install
6. cd ../pulsar-client-go
7. go build -o main producer.go

Expected behavior
build success
Desktop (please complete the following information):

OS: MAC OS
go: go 1.11.4

At first, I think it is a problem that go is inconsistent with the version of cpp client. so, exec go clean -modcache , go mod tidy again. Unfortunately, I still encountered the same problem.

I upgraded to the corresponding version, now its working


Automate EPP ingestion

Description:
As an eLife Production team member I want reviews to automatically be published to save manual effort
Acceptance Criteria

[ ] Get the MECA archive from BioRxiv bucket
[ ] Extract & ingest the XML
[ ] Extract & ingest the images
[ ] Extract & ingest the supplementary files

@BlueReZZ is the plan still have Sciety message us when an eLife article is produced?

No, but that could be an option. An available option is to poll the DocMaps index, filtered by eLife as the group, and the last known published review date, and new ones will appear automatically.


Gesture in SwiftUI does not execute the onEnded callback in some cases, causing the button state and callout to not return the state.

When there is a built-in input box on the keyboard, if you click the input box and then quickly click the button, the button and callout will not restore their status. I have found the reason, it is because gesture in SwiftUI does not execute the onEnded callback when processing system gestures. The following is a bug recurrence:
https://github.com/KeyboardKit/KeyboardKit/assets/25328214/87ae19d7-2c39-4c32-a25c-695b5f630ed7
code：

Hi @zhanggenlove
Great find! Any idea on how to best fix it? :)

Hi @zhanggenlove
Great find, thank you! And thanks for the slimmed down example that clearly shows the proble.
Do you have any idea on how to best fix it? :)

Waiting for the Apple team to fix this issue is not a good idea. Rewriting UIKit's UIGestureRecognizer and combining it with UIViewRepresentable should be able to handle this problem. But I haven't practiced it yet

I looked around a bit, and it seems like many are having this problem.
Here's one link with good information:
https://github.com/feedback-assistant/reports/issues/463
I'll tag this as an Apple bug, and hope I can think of a way to work around this bug.

@zhanggenlove Do you have any more findings regarding this?

@zhanggenlove After not being able to reproduce this bug, I have investigated it more and can now reliably reproduce it.
I have added an automatic cancel event that will trigger if a single drag value has been recorded after 3 seconds. This will let keys that are stuck automatically fix themselves.
I describe this in more detail in #759 and have pushed a fix to the master branch that you can try, to see if it fixes the bug in a satisfying way.
If so, I will release this as a 8.8.2


Xcode9 Compatible

Fixed for XCODE 9 with reference to this article.
https://forums.developer.apple.com/thread/84607
In my project file it is working fine for now.
thanks and regards.

This is needed in order to work in XCode 9, please merge this!

I think this is a bit old now, but would be helpful if this PR could be merged. For projects still targeting iOS 9/10 but using XCode 9, this would help fix some build errors.


An implementation of CC-POMCP

This pull request implements the cost-constrained POMCP (CC-POMCP) algorithm and its dependencies. The algorithm is in algorithms/ccpomcp.p*, while the dependencies are in the framework/generalization.p* and utils/cvec.p* files. This pull request also proposes a generic model, called a ResponseModel, and a corresponding output, called a Response. The name "response" comes from the notion of independent and dependent variables, where a response (reward, cost, etc.) depends on the interaction with the real or simulated environment. Thus, a response model is a wrapper for more specific models, such as reward and cost models (and any others that will follow in the future). By extension, a response is a wrapper for the reward, cost, etc.
The framework/generalization.p* files contain
The pull request has the following:

Implementation of the CCPOMCP and its dependencies,
Some updates to pre-existing algorithms to reduce copied-and-pasted code,
Some updates to the code for rocksample,
Implementation of the rocksample from the CC-POMCP paper,
Test script for Vector operations (in test_util_vector_ops.py), and
Passes for the test_all.py script.

I merged the changes from main into ccpomcp. Let me know if I need to update anything.

Great. Looks like CIs passed except for pre-commit. I will review the code soon.


3-stage add-mul-or doesn't work on Xilinx DSP, but add-mul-and does

https://github.com/uwsampl/lakeroad/blob/3ceb22b22df72c8ed45a4a7e3688da9acd6c62c0/integration_tests/lakeroad/addmulor_3_stage_unsigneds_9_bit.v
This test doesn't work on Xilinx DSPs, but if we change the | to &, it does. I can't tell if this is (1) a Lakeroad bug, (2) a bug with the Xilinx DSP model, or (3) an accurate reflection of how the Xilinx DSP actually works!

Continued work in #345


grpc-gateway Demo

This PR ships a new demo showing how to deploy http gateway services that are able to call RPC services deployed with grpc.
It's based on https://github.com/grpc-ecosystem/grpc-gateway . Hence, it uses some go lang to set up the reverse proxy service.

On the other side, since now we have two rpc services, package organization has been changed.

Codecov Report

Merging #7 into master will not change coverage.
The diff coverage is 0%.

@@         Coverage Diff          @@
##           master    #7   +/-   ##
====================================
  Coverage       0%    0%
====================================
  Files           6    11    +5
  Lines         102   121   +19
  Branches        3     4    +1
====================================
- Misses        102   121   +19

Impacted Files
Coverage Δ

...mo/src/main/scala/greeting/GreetingClientApp.scala
0% <ø> (ø)

...mo/src/main/scala/greeting/GreetingServerApp.scala
0% <ø> (ø)

demo/src/main/scala/package.scala
0% <ø> (ø)
:arrow_up:

demo/src/main/scala/greeting/GreetingClient.scala
0% <ø> (ø)

demo/src/main/scala/user/UserClient.scala
0% <0%> (ø)

demo/src/main/scala/user/UserClientApp.scala
0% <0%> (ø)

demo/src/main/scala/user/UserServerApp.scala
0% <0%> (ø)

demo/src/main/scala/user/UserService.scala
0% <0%> (ø)

demo/src/main/scala/greeting/GreetingService.scala
0% <0%> (ø)

demo/src/main/scala/user/package.scala
0% <0%> (ø)

... and 5 more

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 3af56ce...c357e7c. Read the comment docs.


node1 unlock may overwrite node2's lock's info in MongoLockProvider?

In mongoProvider, if node1 running a task gets a lock at 9:00, lockuntil's value is 9:30, but the task is blocked until 9:40.
At 9:30, another node2 running the shcedule task can get the lock by the following code and set lockuntil is 10:00:
 @Override         public boolean updateRecord(LockConfiguration lockConfiguration) {             Date now = now();             Bson update = combine(                 set(LOCK_UNTIL, Date.from(lockConfiguration.getLockAtMostUntil())),                 set(LOCKED_AT, now),                 set(LOCKED_BY, hostname)             );             Document result = getCollection().findOneAndUpdate(                 and(eq(ID, lockConfiguration.getName()), lte(LOCK_UNTIL, now)),                 update             );             return result != null;         }
When the times comes to 9:40, node1 unlocks lock and update LOCK_UNTIL to now(9:40)
@Override         public void unlock(LockConfiguration lockConfiguration) {             // Set lockUtil to now or lockAtLeastUntil whichever is later             getCollection().findOneAndUpdate(                 eq(ID, lockConfiguration.getName()),                 combine(set(LOCK_UNTIL, Date.from(lockConfiguration.getUnlockTime())))             );         }
public Instant getUnlockTime() {         Instant now = Instant.now();         return lockAtLeastUntil.isAfter(now) ? lockAtLeastUntil : now;     }
the node1 changes node2's lock info through unlock ? should add "lockedBy" check in unlock operation?

if the task duration is 5 minutes, the lockAtMostFor =30min is ok. but in some exceptions or other conditions, the task run 40 minutes unfortunately, the unlock operation will overwrite node2's LOCK_UNTIL.
Should add "lockedBy" check in unlock operation? Using this check to ensure that only unlock oneself lock.

"lockedBy" check would defeat the reason for lockAtMostFor existence so you just can set lockAtMostFor to some large value and you are done. Imagine that you execute the task in Kubernetes or some similar environment and the node running the task crashes. New one with different hostname is created which means that "lockedBy" check would always fail and the the lock would have been kept indefinitely.


fix players window layout

Doesen't this affect alpha as well ?

Shouldn't affect, the layoutRow was changed to positive margins at the uiElements refactoring.


Removing external crypto dependency

Removing external dependency on the crypto module which had been deprecated. Ensuring Node.js >= 10 is required as it ships with crypto.

Please remove this topic from todo-list in readme.md also and mention it in changelog for 0.7.0


⚠ ClamAV has degraded performance

In 3d4266b, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 68 ms

Resolved: ClamAV performance has improved in e1fc162 after 541 days, 35 minutes.


Genomescope failed to converge with -C option in Jellyfish

Hi, I'm using Jellyfish+Genomescope on pair-end NGS data. It seems like that Genomescope complains about failing to converge and the result seems not correct. I have tried changing kmer from 21 to 19, but it didn't work. I'm pretty sure the sequencing data is enough. When I turned off the -C option in Jellyfish, Genomescope seems to work good. I wonder what the reason is. So can anyone help me? The histo file is attached here. thanks!
Here are the commands I used:
jellyfish count -C -m 19 -t 16 -s 16G <(zcat CL100122025_L01_read_1.fq.gz) <(zcat CL100122025_L01_read_2.fq.gz) -o reads.jf
jellyfish histo -t 16 reads.jf > reads.histo
Rscript genomescope.R reads.histo 19 150 result
reads.histo.txt

What is your expected genome size and how much coverage do you think you have roughly? I wonder if there is too much coverage.

Can you also provide the histo file produced when not using -C.

I want to ask if the predicted genome size is normal after you turn off the -C option, and the predicted genome size after I turn off the -C option is twice the actual assembly size.But I can't draw a picture with the -C option on.

It is important to use the -C flag or you will reduce the coverage in half
since kmers from the forward and reverse strands will be counted
separately. If it is not working with the -C flag, you might need to adjust
some of the other settings. Can you share the genomescope link (or the
histo file)
Good luck
Mike
On Tue, Sep 24, 2024 at 10:38 PM luo9595 @.***> wrote:

I want to ask if the predicted genome size is normal after you turn off
the -C option, and the predicted genome size after I turn off the -C option
is twice the actual assembly size.But I can't draw a picture with the -C
option on.
—
Reply to this email directly, view it on GitHub
https://github.com/schatzlab/genomescope/issues/20#issuecomment-2372771950,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABP3426SJYQTKNCNLDOA2TZYIO4BAVCNFSM6AAAAABOZQWZ7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZSG43TCOJVGA
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@mschatz
Here is my histo file
19_kmer.histo.txt
I used the Next-generation sequencing quality control data to evaluate the genome size, and the selected kmer was 19. The genome size is about 2.6M, and the estimated genome size is 5.2M, which is the parameter I used.

If the genome is expected to be only 2.6Mbp in size, Im guessing this is a
bacteria. Im very surprised by the kmer distribution (in blue) that has two
peaks at ~150x and ~300x. This is usually the signature for a heterozygous
sample - perhaps this is not a clonal population? The variations in the
population will increase the genome size estimate. Have you tried to run
the assembler? I would normally recommend spades for a short read
bacterial genome assembly.
I would also comment that you probably have too much coverage for the
assembler. I would recommend a random downsampling to keep only 33% of the
reads - after this your peak at 150x will shift to 50x and 300x will shift
to 100x. This will often really improve the assembly
Here is the link to the profile with default parameters:
http://genomescope.org/genomescope2/analysis.php?code=ubcE9uhKsJjDwDLeHN25
Good luck
Mike
On Thu, Sep 26, 2024 at 2:38 AM luo9595 @.***> wrote:

@mschatz https://github.com/mschatz
Here is my histo file
19_kmer.histo.txt
https://github.com/user-attachments/files/17143946/19_kmer.histo.txt
I used the Next-generation sequencing quality control data to evaluate the
genome size, and the selected kmer was 19. The genome size is about 2.6M,
and the estimated genome size is 5.2M, which is the parameter I used.
image.png (view on web)
https://github.com/user-attachments/assets/0896a6bb-7567-45ac-91f5-f07674e4eaba
—
Reply to this email directly, view it on GitHub
https://github.com/schatzlab/genomescope/issues/20#issuecomment-2376058059,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABP347SWA5LZNGEHYJCKDLZYOTVNAVCNFSM6AAAAABOZQWZ7WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZWGA2TQMBVHE
.
You are receiving this because you were mentioned.Message ID:
@.***>


Error: No valid nx workspace found

Just installed and tried to run nx-lib-bundle all returns:

Error: No valid nx workspace found

Packages
"@nrwl/node": "^10.2.0",
"@nrwl/workspace": "10.2.0",
"@novotea/nx-lib-bundle": "^1.1.0",

Can you provide a link with a reproducible case ?

I just started to setup a sample repo when I stumbled over this:

Look for nx.json, workspace.json and package.json

So if the nx workspace was setup with angular and you have an angular.json instead of a workspace.json  file - this will not work right?


MatchExpressions Component

When dealing with affinity/scheduling rules in workloads, they all boil down to matchExpressions, so we should make a component to be used throughout the scheduling rules sections.
There are 2 options for what the dropdown options are for the operator, so we should be able to set if it's needed for node scheduling or pod scheduling.
MatchExpressions component

Header/Label Name
k8s yaml
Input Field/Component
Example Input/Default

Key
key
String input textbox

Operator
operator
Dropdown Options for Node Scheduling:  * = (In)  * ≠ (NotIn)  *  exists (Exists)  * does not exist (DoesNotExist)  * > (Gt)  * < (Lt)  Dropdown Options for Pod Scheduling:  * = (In)  * ≠ (NotIn)  * exists (Exists)  * does not exist (DoesNotExist)
Default Value: =

Value
values
String input textbox
When exists or does not exist is selected as an operator, the textbox is hidden and shown as a n/a label.

** Note:** In and Out are able to take string arrays. From a design perspective, we'll take a comma separated list as 1 string and parse it out as string array.

In view only mode of this component, show the headers, but show text of There are no rows to show. as it matches the other components like KeyValue when it has no data.

Workload - Edit Page

[ ] Need space between Add Node Selector button and component

[ ] There should be space between multiple node selectors (not sure if this is in the component or in the workload-edit page.

[ ] When coming to the page, do not have any node selectors added. Have it look like this where you need to add node selectors:

Currently, it's already adding a node selector, which is unnecessary:

[ ] When adding a node selector have it already add space for 1 rule as you need 1 rule in each node selector.

Currently, it's allowing you to create a node selector without a rule, which is invalid. Each node selector needs a rule.

[ ] Trying to save the node affinity with 2 rules for require all didn't work so I wasn't able to review the detail page when it has content.

Workload - Detail Page

[ ] Remove ability to add Node Selectors under Require all of.

Component

[ ] In edit/create mode of the component, align headers to the left side of the input box. This is how KeyValue component is set up.

[ ] In view mode of the component, there should be a line to separate the header and the rest of the content. This was recently added to the KeyValue Component so the tables are consistent with a line between header and content.

When trying to use this in workloads, it refuses to recognize the operator.
I keep getting:
spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[0].operator: Invalid value: \"\": not a valid selector operator", "status": 422 }

LGTM based on 6/8 master


Cloudformation Support for Resource-Based Policies

Based off this page (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/protect-stack-resources.html): Cloudformation does support stack policies.
On this page (https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html#management_svcs), the chart shows CloudFormation not supporting resource-based policies.
I know Cloudformation does support stack policies, are these not considered "true" resource-based policies or should this chart be updated?
Thanks!

Thanks! I'll check with the Cloudformation team and verify whether the IAM page needs updating.

Hi, can we get an update on this?

update

L

Closing this issue or pull request in advance of archiving this repo. For more information about the decision to archive this repo (and others in the 'awsdocs' org), see the announcement on the AWS News Blog.


Dark mode OS setting not respected

The Bible seems to start in light mode and I can't find a way to change it to dark mode either.
OS: Linux Mint 21 Cinnamon (set to dark mode)

What I think the problem could be is that the theme is not installed on the flatpak system or the theme is not GTK4 comparable. Either way in GTK4 there is now a dark mode/light mode setting that can be toggled and in my rather limited testing the dark mode/light mode is respected on Gnome 42 and it toggles between dark and light Adwaita. Do you know if the theme you are using supports GTK4?

This is a Cinnamon issue, as they don't properly support the dark style preference.


feat(prettier): format WithStatement

Current dependencies on/for this PR:

main

PR #1332   👈

This stack of pull requests is managed by Graphite.


Suggested fixes by iCR, OpenRefactory, Inc.

This issue was detected in branch master of httpie project on the version with commit hash 810bb1. This is an instance of a weak cryptography issue.
Fixes for weak cryptography issues:
In file: update_warnings.py, method: _fetch_updates, there is code that turns off certificate validation while establishing an SSL/TLS connection. According to CWE 295, if a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by interfering in the communication path between the host and client. iCR suggested that the certificate validation option should not be turned off.
This issue was detected by OpenRefactory's Intelligent Code Repair (iCR). We are running iCR on libraries in the PyPI repository to identify issues and fix them. More info at: pypi.openrefactory.com

Codecov Report
Base: 97.28% // Head: 94.59% // Decreases project coverage by -2.69% :warning:

Coverage data is based on head (a7d8c14) compared to base (4d7d6b6).
Patch coverage: 90.94% of modified lines in pull request are covered.

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1434      +/-   ##
==========================================
- Coverage   97.28%   94.59%   -2.70%
==========================================
  Files          67      109      +42
  Lines        4235     7656    +3421
==========================================
+ Hits         4120     7242    +3122
- Misses        115      414     +299

Impacted Files
Coverage Δ

httpie/output/ui/man_pages.py
0.00% <0.00%> (ø)

httpie/output/ui/rich_utils.py
0.00% <0.00%> (ø)

tests/test_binary.py
100.00% <ø> (ø)

tests/test_sessions.py
99.70% <ø> (-0.30%)
:arrow_down:

tests/test_ssl.py
92.59% <ø> (-2.35%)
:arrow_down:

tests/test_stream.py
100.00% <ø> (ø)

tests/test_tokens.py
100.00% <ø> (ø)

tests/test_update_warnings.py
99.14% <ø> (ø)

tests/test_uploads.py
96.70% <ø> (-3.30%)
:arrow_down:

tests/test_xml.py
97.56% <ø> (-0.06%)
:arrow_down:

... and 102 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Support Windows

gostackparse has a bug causing error messages like this on windows: invalid file:line ref on line 3: \"\\tC:/Users/felixge/pprof.go:693 +0x9f\"
Should be relatively easy to fix in the upstream package.
Thanks to @lkarlslund for reporting on twitter.

Can confirm that this works great. Thanks!


Include error filter creation into InitializeOnStartup.

is this still relevant? we have a TODO referencing this issue in our code base, but I'm not really sure why 😅

Closing this issue.


feat: Create only one sink per source at a time

Jira: https://keboola.atlassian.net/browse/PSGO-636
Slack:https://keboolaglobal.slack.com/archives/C055WKPHYSD/p1721992621885959?thread_ts=1721739978.643919&cid=C055WKPHYSD
Changes:

Added distributed lock to create sink API call.

(removed FIXME commit)


Changing splitting strategy to clean up Cross Validation API

Changing splitting strategy to clean up Cross Validation API (#4049)

generate_subset_indices() and generate_subset_inverse() are renamed,
respectively, to validation() and train();
The methods are now const and return const vectors;
build_subsets() won't be explicitly called, but rather internally
in the constructor of the derived classes;
Examples, unit tests and notebooks were changed accordingly.

Hi @karlnapf @vigsterkr !
Thanks for the review. I've changed the constness strategy and now build_subsets() is called in the constructors of the derived classes.
After these changes, CrossValidationMMD unit tests started to fail. That was due to the use of randomness in the creation of the subsets. Given that now build_subsets() is in the constructor, I've adapted the test in order to fix this.

Added a few comments, the build seems to be fine. So tests passing.
Once we have cleaned up I think we can merge this.
Did you check all ipython notebooks and meta examples for the new API?

Any updates here?

Hi @karlnapf ! Sorry for my late reply.
I'm sending a new patch set changing build_subsets() in TimeSeriesSplitting according to your last comments. I've adapted the unit tests and notebook accordingly.
As far as I've checked, all python notebooks and meta examples for the new API were changed.

This is almost ready.
Just my comment on the naming. What are your thoughts here?

I like "train" and "test"! I'll make the changes and submit another patch set.
Thanks!

Hi @karlnapf !
Any other comments in this PR? Can I squash the commits to clean it up?

Thanks for the udpate and ping! :)
Looks good! No need to squash as github can do that these days
One thing I want to make sure.Did you run all unit and integration tests?


[1pt] Create website header with empty nav - Setup (group task)

Download the free image for the app logo.
Create empty navigation (this will be filled in in separate tasks).

We (@skyv26 and @iambenkis ) have successfully complete this task.


About the dimension projection

The linear projection after the self attention:
bs = self_attention.size(0)
self_attention = self_attention.view(bs, -1)
linear_proj = F.relu(self.linear_projection(self_attention))
From the paper, they said "We project the self-attended neighbor encodings to a LARGER 4x2d dimensional space", so if you flatten out the last two dimensions of "self_attention" before the projection, how can you make sure neighbor < 4?
In my opinion, we should not flatten the last two dimensions before projection, we do projection on the last dimension whose size is 2d, and 2d < 4x2d, so we are projecting it to a larger space.
Please point it out if I understand this wrong at some place, or you do this on purpose for some reason.

@shaonanqinghuaizongshishi I think you are mistaking 4 to be the number of neighbors here. 4 is an arbitrary number chosen by the authors without much explanation on it. So the linear projections are designed such that, no matter what sizes you use for neighbors and embedding size, the shapes will be taken care of.


Refactor/move translated text to own package

@nicole-eb make sure to migrate to this in your mein-b.. PR when this is merged.

@Vin-RM I think we already talked about extracting this b/c it will be used in different places.


Mod to BST that bolds first editor for Book item type

Finally found a fix so that first/only editor of "Book" item in BIB file is bolded, like the first/only author of an article. The mod does not affect "InBook" or "Misc" items that include the editor field.

Thanks!


[Footer] Page is not updated after clicking twice same link on the footer of the page

Environment: macOS High Sierra 10.13, Google Chrome 81.0.4044.129 (64-bit)
Reproducable: always
Build found: commit a101c84
Preconditions:

Open GreenCity website https://ita-social-projects.github.io/GreenCityClient/#/welcome
Sign in with valid credentials

Steps to reproduce

Scroll to the footer of the page;
Click 'Eco news' link in the footer.
Scroll to the footer of the page
Click 'Eco news' link in the footer again.
Repeat step 1-4 with links in the footer: 'Places', 'About us', 'My habits' and the name "Greencity" or logo

Actual result:
Page is not updated
Expected result:
Page is updated
User story: #384

It was not a requirement from BA and Designers, should be discussed

Agreed with designers on the meeting


Error while saving results to folder

I tried to save result by running eval.py with argument --plot-dir and got this error
fts_path: ./data/nuscenes/maskclip_features_projections/CAM_FRONT/n008-2018-08-01-16-03-27-0400__CAM_FRONT__1533153857912404.pth.npy
Traceback (most recent call last):
  File "/home/sherlock/workspace/POP3D/eval.py", line 788, in <module>
    torch.multiprocessing.spawn(main, args=(args,), nprocs=args.gpus)
  File "/home/sherlock/anaconda3/envs/maskclip/lib/python3.9/site-packages/torch/multiprocessing/spawn.py", line 230, in spawn
    return start_processes(fn, args, nprocs, join, daemon, start_method='spawn')
  File "/home/sherlock/anaconda3/envs/maskclip/lib/python3.9/site-packages/torch/multiprocessing/spawn.py", line 188, in start_processes
    while not context.join():
  File "/home/sherlock/anaconda3/envs/maskclip/lib/python3.9/site-packages/torch/multiprocessing/spawn.py", line 150, in join
    raise ProcessRaisedException(msg, error_index, failed_process.pid)
torch.multiprocessing.spawn.ProcessRaisedException:

-- Process 0 terminated with the following error:
Traceback (most recent call last):
  File "/home/sherlock/anaconda3/envs/maskclip/lib/python3.9/site-packages/torch/multiprocessing/spawn.py", line 59, in _wrap
    fn(i, *args)
  File "/home/sherlock/anaconda3/envs/maskclip/lib/python3.9/site-packages/torch/autograd/grad_mode.py", line 28, in decorate_context
    return func(*args, **kwargs)
  File "/home/sherlock/workspace/POP3D/eval.py", line 510, in main
    plt.savefig(save_path, bbox_inches='tight')
  File "/home/sherlock/anaconda3/envs/maskclip/lib/python3.9/site-packages/matplotlib/pyplot.py", line 977, in savefig
    res = fig.savefig(*args, **kwargs)
  File "/home/sherlock/anaconda3/envs/maskclip/lib/python3.9/site-packages/matplotlib/figure.py", line 3058, in savefig
    self.canvas.print_figure(fname, **kwargs)
  File "/home/sherlock/anaconda3/envs/maskclip/lib/python3.9/site-packages/matplotlib/backend_bases.py", line 2299, in print_figure
    bbox_inches = self.figure.get_tightbbox(
  File "/home/sherlock/anaconda3/envs/maskclip/lib/python3.9/site-packages/matplotlib/figure.py", line 1684, in get_tightbbox
    bbox = a.get_tightbbox(renderer)
  File "/home/sherlock/anaconda3/envs/maskclip/lib/python3.9/site-packages/mpl_toolkits/mplot3d/axes3d.py", line 3369, in get_tightbbox
    if axis_bb:
UnboundLocalError: local variable 'axis_bb' referenced before assignment

What seems to be the problem here?

By the way, Could you show me how to visualize your result as shown in Figure 3 in your paper?

Hi, I don't know what is the problem with the plotting. It seems to be matplotlib-related. I also encounter the problem on my side. I will investigate it and let you know as soon as I fix it.
I think that you mean Figure 5 in the main paper, right? For that, I exported the results in a text format, where every line has the following format: [x,y,z,R,G,B], where x,y,z are 3D point coordinates and R,G,B are red, green and blue values. Then, I visualize the results with Cloud Compare.

Should it still be a problem, please feel free to re-open this issue.


 : screen reader not narrating 'expanded/collapsed' when opened and closed (Accessibility Issue)

Issue Description
Screen reader (NVDA) is not narrating 'expanded/collapsed' when they are opened and closed in Material angular version 8.2.3
Reproduction
Steps to reproduce:

Install any Screen reader.
open and close the mat-select while screen reader is 'ON'

Expected Behavior
The screen reader should narrate as 'Expanded/Collapsed' when the select is opened/closed
Actual Behavior
The screen reader not narrating as 'Expanded/Collapsed' when the select is opened/closed
Environment

Angular: 8.2.14
CDK/Material: 8.2.3
Browser(s): Edge Chromium, Google Chrome
Operating System (e.g. Windows, macOS, Ubuntu): Windows, MacOs, Ubuntu

mat-select had a lot of accessibility issues, apart from the one mentioned here. In 10.2.0 we released a new version with a reworked accessibility pattern.


Low-res recon bug

Jordan, I was working on trying to do a preliminary multi-grid implementation, and I think I found a bug. I set up a separate branch for the bug-fix. The branch is called "low_res_bug_fix". If your run the script demo/demo_multires.py, it will crash. But if you change the parameter

delta_pixel = 4.0
to
delta_pixel = 2.0

Then it works fine. There seems to be a problem when delta_pixel is greater than 4.

@cabouman I don't get the error on my linux machine but I do on my mac with clang.
What OS and compiler are you using?

I'm using clang, so I guess it must be a compiler specific bug. Not good.

This doesn't excuse the malloc error, but in the demo when you increase the pixel size, you also want to reduce the image size in the recon arguments like,
num_rows=int(num_rows/delta_pixel)
num_cols=int(num_cols/delta_pixel)

It doesn't crash if I make that change.
Aside: Here's another place we need to check the input values. Something like adjusting the image size if
delta_pixel*max(num_rows+2,num_cols+2)*sqrt(2) > delta_channel*(num_channels+2*channel_offset)

For debugging purposes, I left the script that generates the malloc error in "demo_multires.py" in the branch named "low_res_bug_fix".

I believe the malloc errors were due to memory running out on our macs rather than a clang issue.
The conditions that caused this were the large image extent relative to the detectors, so it goes away with limiting image size or by reducing the roi_recon to the scan FOV.
I'll need to block out some time to analyze this. The memory is spiking in the piecewise transformation of the A matrix.

This should be fixed now.  There's been changes to the A matrix encoding, so when installing the recent change to the master branch

Clear out any old cached system matrix files, typically in $HOME/.cache/svmbir/parbeam/sysmatrix
If pulling the update to an existing local repository, run "git submodule update" before recompiling/ installing


Error: "go server 启动失败，服务器将不可用" after npm run dev-all

Describe the bug (must be provided)
"go server 启动失败，服务器将不可用"

And even I couldn't connect my centos 7 server after the command for several times. It recovered after I rebooted it.

Additional context
><EMAIL_ADDRESS>dev-all /www/wwwroot/nebula-studio-3.4.0
> node ./config/server.js

(node:3369) ExperimentalWarning: The fs.promises API is experimental
<i> [webpack-dev-server] [HPM] Proxy created: /api-nebula/**  -> http://<IP_ADDRESS>:9000
<i> [webpack-dev-server] [HPM] Proxy created: /api/**  -> http://<IP_ADDRESS>:9000
Listening at localhost: 7001
Opening your system browser...
server::go build -ldflags '' -o bin/studio studio.go

go server 启动失败，服务器将不可用，请切换到 server 目录调试异常

<e> [webpack-dev-middleware] HookWebpackError: Not supported
<e>     at makeWebpackError (/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack/lib/HookWebpackError.js:48:9)
<e>     at hooks.processAssets.callAsync.err (/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack/lib/Compilation.js:3060:12)
<e>     at eval (eval at create (/www/wwwroot/nebula-studio-3.4.0/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:52:1)
<e>     at err (/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack/lib/Compilation.js:510:26)
<e>     at compilation.hooks.processAssets.tapAsync (/www/wwwroot/nebula-studio-3.4.0/node_modules/copy-webpack-plugin/dist/index.js:710:13)
<e>     at process._tickCallback (internal/process/next_tick.js:68:7)
<e> -- inner error --
<e> Error: Not supported
<e>     at compilation.hooks.processAssets.tapAsync (/www/wwwroot/nebula-studio-3.4.0/node_modules/copy-webpack-plugin/dist/index.js:706:13)
<e>     at fn (/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack/lib/Compilation.js:509:9)
<e>     at Hook.eval [as callAsync] (eval at create (/www/wwwroot/nebula-studio-3.4.0/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:50:1)
<e>     at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/www/wwwroot/nebula-studio-3.4.0/node_modules/tapable/lib/Hook.js:18:14)
<e>     at cont (/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack/lib/Compilation.js:3057:34)
<e>     at createChunkAssets.err (/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack/lib/Compilation.js:3105:10)
<e>     at symbolIterator (/www/wwwroot/nebula-studio-3.4.0/node_modules/neo-async/async.js:3485:9)
<e>     at timesSync (/www/wwwroot/nebula-studio-3.4.0/node_modules/neo-async/async.js:2297:7)
<e>     at Object.eachLimit (/www/wwwroot/nebula-studio-3.4.0/node_modules/neo-async/async.js:3463:5)
<e>     at Compilation.createChunkAssets (/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack/lib/Compilation.js:4522:12)
<e> caused by plugins in Compilation.hooks.processAssets
<e> Error: Not supported
<e>     at compilation.hooks.processAssets.tapAsync (/www/wwwroot/nebula-studio-3.4.0/node_modules/copy-webpack-plugin/dist/index.js:706:13)
<e>     at fn (/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack/lib/Compilation.js:509:9)
<e>     at Hook.eval [as callAsync] (eval at create (/www/wwwroot/nebula-studio-3.4.0/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:50:1)
<e>     at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (/www/wwwroot/nebula-studio-3.4.0/node_modules/tapable/lib/Hook.js:18:14)
<e>     at cont (/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack/lib/Compilation.js:3057:34)
<e>     at createChunkAssets.err (/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack/lib/Compilation.js:3105:10)
<e>     at symbolIterator (/www/wwwroot/nebula-studio-3.4.0/node_modules/neo-async/async.js:3485:9)
<e>     at timesSync (/www/wwwroot/nebula-studio-3.4.0/node_modules/neo-async/async.js:2297:7)
<e>     at Object.eachLimit (/www/wwwroot/nebula-studio-3.4.0/node_modules/neo-async/async.js:3463:5)
<e>     at Compilation.createChunkAssets (/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack/lib/Compilation.js:4522:12)

could you use go run server/api/studio/studio.go to  specific server error information. it need golang environment.
Btw, i suggestion use rpm on CentOs directly. refer to doc

go run server/api/studio/studio.go

thx, I'll try

@hetao92  it still show me the same error

go run server/api/studio/studio.go

[root@izbp110l2aupfn0cocrcmgz nebula-studio-3.4.0]# go run server/api/studio/studio.go
server/api/studio/studio.go:9:2: no required module provides package github.com/vesoft-inc/go-pkg/middleware: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:10:2: no required module provides package github.com/vesoft-inc/nebula-http-gateway/ccore/nebula/gateway/pool: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:11:2: no required module provides package github.com/vesoft-inc/nebula-studio/server-v2/api/studio/internal/config: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:12:2: no required module provides package github.com/vesoft-inc/nebula-studio/server-v2/api/studio/internal/handler: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:13:2: no required module provides package github.com/vesoft-inc/nebula-studio/server-v2/api/studio/internal/service/importer: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:14:2: no required module provides package github.com/vesoft-inc/nebula-studio/server-v2/api/studio/internal/svc: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:15:2: no required module provides package github.com/vesoft-inc/nebula-studio/server-v2/api/studio/pkg/auth: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:16:2: no required module provides package github.com/vesoft-inc/nebula-studio/server-v2/api/studio/pkg/logging: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:17:2: no required module provides package github.com/vesoft-inc/nebula-studio/server-v2/api/studio/pkg/utils: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:18:2: no required module provides package github.com/zeromicro/go-zero/core/conf: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:19:2: no required module provides package github.com/zeromicro/go-zero/core/proc: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:20:2: no required module provides package github.com/zeromicro/go-zero/rest: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:21:2: no required module provides package github.com/zeromicro/go-zero/rest/httpx: go.mod file not found in current directory or any parent directory; see 'go help modules'
server/api/studio/studio.go:22:2: no required module provides package go.uber.org/zap: go.mod file not found in current directory or any parent directory; see 'go help modules'
[root@izbp110l2aupfn0cocrcmgz nebula-studio-3.4.0]#
[root@izbp110l2aupfn0cocrcmgz nebula-studio-3.4.0]# npm run dev-all

><EMAIL_ADDRESS>dev-all /www/wwwroot/nebula-studio-3.4.0
> node ./config/server.js

(node:21246) ExperimentalWarning: The fs.promises API is experimental
<i> [webpack-dev-server] [HPM] Proxy created: /api-nebula/**  -> http://<IP_ADDRESS>:9000
<i> [webpack-dev-server] [HPM] Proxy created: /api/**  -> http://<IP_ADDRESS>:9000
process exits with code: 1
/www/wwwroot/nebula-studio-3.4.0/node_modules/webpack-dev-server/lib/Server.js:2432
        throw error;
        ^

Error: listen EADDRINUSE <IP_ADDRESS>:7001
    at Server.setupListenHandle [as _listen2] (net.js:1334:14)
    at listenInCluster (net.js:1382:12)
    at GetAddrInfoReqWrap.doListen [as callback] (net.js:1508:7)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:62:10)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR<EMAIL_ADDRESS>dev-all: `node ./config/server.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>dev-all script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR!
I guess go based backend should be built before starting everything up :-D.

@TommyLemon Can you try go 1.17?
cd server/api/studio
make run

You don't need to execute npm run dev-all now. This is used to quickly start the front and back services at the same time, but it seems that your server can't start. There is a problem with golang on your virtual machine and the server fails to start. Could you use our rpm package to deploy studio directly? If you want to deploy source code, you may need to modify the configuration of golang like go env -w GO111MODULE=auto

Thank you all.
I changed my server to a Ubuntu 20.04, while it still showed me the same error above.
Then I switched to a former version 3.2.3, it stepped forward a lot together with [nebula-graph 3.0.0](wget https://oss-cdn.nebula-graph.com.cn/package/3.0.0/nebula-graph-3.0.0.ubuntu2204.amd64.deb).
But there is another error:
Error from chokidar (/home/tommy.zhou/nebula-studio-3.2.3/node_modules/lodash-es): Error: ENOSPC: System limit for number of file watchers reached, watch '/home/tommy.zhou/nebula-studio-3.2.3/node_modules/lodash-es/util.default.js'

~Have you run backend build with:~
cd server/api/studio
go build -o server

~before "dev-all" ?~
~I guess go based backend should be built before starting everything up :-D.~
update: dev-all will build the go server, too, you are doing right :-p But still, it's worth trying for a go server build:
$ cd ./server/api/studio
$ make run

[root@izbp110l2aupfn0cocrcmgz nebula-studio-3.4.0]# go run server/api/studio/studio.go
...
server/api/studio/studio.go:22:2: no required module provides package go.uber.org/zap: go.mod file not found in current directory or any parent directory; see 'go help modules'

@wey-gu  @veezhang   No such file or directory in nebula-studio-3.2.3
^Croot@tommy:/home/tommy/nebula-studio-3.2.3# cd ./server/api/studio
bash: cd: ./server/api/studio: No such file or directory
root@tommy:/home/tommy/nebula-studio-3.2.3# cd server/api/studio
bash: cd: server/api/studio: No such file or directory
root@tommy:/home/tommy/nebula-studio-3.2.3#

in 3.2.3, the go server side isn't embedded in NebulaStudio, instead, it relied on the http gateway, thus there is no such folder yet.

Due to no progress for a month, this issue is closed first, if you have a new update, you can open the issue again.


Add support for new attribute syntax using @

Now WGSL uses @ for attributes instead of double brackets. cf. https://github.com/gpuweb/gpuweb/pull/2517
So I added support for that, and update test.wgsl to use new syntax.

@PolyMeilex Could you please release this update to the marketplace?
Thanks for the nice extension!

@PolyMeilex Could you please release this update to the marketplace? Thanks for the nice extension!

Done