Mysql transaction deadlock when running CATs

Issue
We're running CATs with SCF+Eirini. Occasionally they fail due to some transaction deadlock in Mysql.
Context
We run CAPI release 1.81.  See more info about releases here
Steps to Reproduce

Deploy SCF with Eirini, according to instructions here
Run CATs with this config

Expected result

CATs should pass without any errors in cc logs

Current result
Sometimes they pass, sometimes they fail.
Here is the error:
{"timestamp":1560420022.9494345,"message":"Mysql2::Error: Deadlock found when trying to get lock; try restarting transaction: UPDATE `buildpack_lifecycle_data` SET `droplet_guid` = NULL WHERE ((`droplet_guid` = '5aac7308-c5f7-45ac-9c89-c9437471af5c') AN
D (`id` != 3335)) LIMIT 1","log_level":"error","source":"cc.db","data":{"request_guid":"c317e409-5754-471d-a937-eb97a02eac80"},"thread_id":47442393915700,"fiber_id":47442368878680,"process_id":1,"file":"/var/vcap/packages/.src/4f233290b34ea859bfacecc196
e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/logging.rb","lineno":82,"method":"public_send"}

Here is the relevant stacktrace:
exception not translated: Sequel::SerializationFailure - Mysql2::Error: Deadlock found when trying to get lock; try restarting transaction:
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/mysql2-0.4.10/lib/mysql2/client.rb:120:in `_query'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/mysql2-0.4.10/lib/mysql2/client.rb:120:in `block in query'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/mysql2-0.4.10/lib/mysql2/client.rb:119:in `handle_interrupt'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/mysql2-0.4.10/lib/mysql2/client.rb:119:in `query'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/adapters/mysql2.rb:137:in `block in _execute'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/logging.rb:43:in `log_connection_yield'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/adapters/mysql2.rb:132:in `_execute'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/adapters/utils/mysql_mysql2.rb:39:in `block in execute'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/connecting.rb:253:in `block in synchronize'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/connection_pool/threaded.rb:88:in `hold'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/connecting.rb:253:in `synchronize'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/adapters/utils/mysql_mysql2.rb:39:in `execute'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/adapters/mysql2.rb:68:in `execute_dui'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/dataset/actions.rb:1094:in `execute_dui'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/dataset/actions.rb:868:in `update'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/model/associations.rb:2212:in `block (2 levels) in def_one_to_many'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1905:in `block in checked_transaction'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/transactions.rb:216:in `block in transaction'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/connecting.rb:253:in `block in synchronize'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/connection_pool/threaded.rb:88:in `hold'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/connecting.rb:253:in `synchronize'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/transactions.rb:186:in `transaction'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/model/base.rb:1905:in `checked_transaction'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/model/associations.rb:2211:in `block in def_one_to_many'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/model/associations.rb:2616:in `_set_associated_object'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/model/associations.rb:2646:in `set_one_to_one_associated_object'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/model/associations.rb:2216:in `block in def_one_to_many'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/app/actions/droplet_create.rb:57:in `block in create_buildpack_droplet'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/transactions.rb:245:in `_transaction'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/transactions.rb:220:in `block in transaction'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/connecting.rb:253:in `block in synchronize'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/connection_pool/threaded.rb:92:in `hold'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/connecting.rb:253:in `synchronize'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sequel-5.16.0/lib/sequel/database/transactions.rb:186:in `transaction'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/app/actions/droplet_create.rb:55:in `create_buildpack_droplet'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/app/controllers/runtime/stagings_controller.rb:137:in `create_droplet_from_build'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/app/controllers/runtime/stagings_controller.rb:132:in `droplet_from_build'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/app/controllers/runtime/stagings_controller.rb:112:in `upload_droplet'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/app/controllers/runtime/stagings_controller.rb:63:in `upload_package_droplet_mtls'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/app/controllers/base/base_controller.rb:86:in `dispatch'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/lib/cloud_controller/rest_controller/routes.rb:16:in `block in define_route'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1634:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1634:in `block in compile!'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in `block (3 levels) in route!'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1011:in `route_eval'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:992:in`block (2 levels) in route!'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1040:in `block in process_route'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1038:in `catch'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1038:in `process_route'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:990:in `block in route!'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:989:in `each'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:989:in `route!'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1097:in `block in dispatch!'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `catch'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1094:in `dispatch!'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `block in call!'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `block in invoke'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `catch'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1076:in `invoke'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:924:in `call!'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:913:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-protection-2.0.5/lib/rack/protection/xss_header.rb:18:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-protection-2.0.5/lib/rack/protection/path_traversal.rb:16:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-protection-2.0.5/lib/rack/protection/json_csrf.rb:26:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-protection-2.0.5/lib/rack/protection/base.rb:50:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-protection-2.0.5/lib/rack/protection/frame_options.rb:31:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-2.0.7/lib/rack/null_logger.rb:9:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-2.0.7/lib/rack/head.rb:12:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:194:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/sinatra-2.0.5/lib/sinatra/base.rb:1957:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-2.0.7/lib/rack/urlmap.rb:68:in `block in call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-2.0.7/lib/rack/urlmap.rb:53:in `each'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-2.0.7/lib/rack/urlmap.rb:53:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/middleware/request_logs.rb:22:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/middleware/security_context_setter.rb:19:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/middleware/vcap_request_id.rb:15:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/middleware/cors.rb:49:in `call_app'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/middleware/cors.rb:14:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/cloud_controller_ng/middleware/request_metrics.rb:12:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/rack-2.0.7/lib/rack/builder.rb:153:in `call'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/thin-1.7.2/lib/thin/connection.rb:86:in `block in pre_process'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/thin-1.7.2/lib/thin/connection.rb:84:in `catch'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/thin-1.7.2/lib/thin/connection.rb:84:in `pre_process'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/thin-1.7.2/lib/thin/connection.rb:50:in `block in process'
/var/vcap/packages/.src/4f233290b34ea859bfacecc196e7c35541e4290e/gem_home/ruby/2.4.0/gems/eventmachine-<IP_ADDRESS>/lib/eventmachine.rb:1067:in `block in spawn_threadpool'

/cc @alex-slynko

Hi @akshaymankar and @alex-slynko,
We took a look at the logs for one of our long-running environments that runs cats frequently, and spotted the same error only a couple of times in the past few weeks. What we have found though is it originates from this endpoint POST /internal/v4/droplets/<droplet-guid>/upload?async=true after staging completes.
We don't have a SCF + Eirini environment easily available to us, so we were wondering if should could elaborate more on the differences between staging in Diego and Eirini to help us understand what might make this happen more often in this configuration. Like for example, does the Eirini stager retry these droplet uploads more frequently? Something else?

Hello,
We encountered the issue again with the latest CAPI version 1.93.0.
Best regards,
Georgi && @yulianedyalkova

k8s support was dropped, closing


Document or revert change in supported arg types

Describe the bug
As of v8.0, list is no longer supported as an argument type for @gf.cell functions. This presumably extends to all unhashable types (e.g. dict, np.ndarray, etc.) and is likely the root cause behind #2861.
To Reproduce
@gf.cell
def foo(x: list[int]) -> gf.Component:
    return gf.Component()

k = foo([1,2,3])
# In gdsfactory==7.27.0, this succeeds.
# In gdsfactory==8.0.0, this fails with "TypeError: unhashable type: 'list'
# Also tested at gdsfactory==8.5.4, which behaves like v8.0.0

Expected behavior
This isn't a bad change, since unhashable (or more specifically mutable) types have unsafe cache behavior. The issue is that it's not called out in the migration guide and the effects are wide-reaching; anyone who made heavy use of lists, dicts, or other unhashable types in their use of v7.* will require significant effort to convert to hashable arguments, and may not be aware which types are acceptable and which are not.
Suggested fix
I can think of a few options, in no particular order:

Convert these types in the migration script. This seems incredibly tricky to get right, but done correctly it would completely eliminate this issue.
Document the change in the migration guide. This is the easiest option, but may leave some users with a lot of work to do before they can upgrade to v8.*. This might be useful to do in addition to (1), as well.
Change @gf.cell to support unhashable types again. I can't really recommend this given the aforementioned dangers of caching mutable types, but if there's a good way to avoid those issues this option would require the least work from users.

This should be fixed in newer kfactory versions (something like 0.18+ if not earlier).
The way we get around unhashable types is by casting lists to tuples and dicts to frozensets on submission to the cache and back on retrieval.
If this is not the case in any tests, then it should be a bug of kfactory. I thought we have tests, but I couldn't find them. I'll investigate tomorrow.

I checked. Unfortunately this is not true for lists, that's right. The problem is that we can't do the magic trick of frozenset like we could with dicts. I have some ideas how we might be able to solve this, but I need to test first and see whether that works.

Hi Orion, we fixed this in Kfactory side
Feel free to reach out if there’s anything else I can assist with.

Thanks! Do you know which gdsfactory version picked up / will pick up the change? I think it's working for me at v8.17.0 but I haven't checked closely.

Quite some time ago, so 8.17 should definitely work


VS Code never updates

We have written the needed data into your clipboard because it was too large to send. Please paste.
Type: Bug
I have VS Code set to auto update, but it never updates.  There is also no "Check for updates" option on any of my menus.
VS Code version: Code 1.70.1 (6d9b74a70ca9c7733b29f0456fd8195364076dda, 2022-08-10T06:08:33.642Z)
OS version: Windows_NT x64 10.0.19045
Modes: Restricted

System Info

Item
Value

CPUs
11th Gen Intel(R) Core(TM) i7-11850H @ 2.50GHz (16 x 2496)

GPU Status
2d_canvas: enabledcanvas_oop_rasterization: disabled_offdirect_rendering_display_compositor: disabled_off_okgpu_compositing: enabledmultiple_raster_threads: enabled_onopengl: enabled_onrasterization: enabledraw_draw: disabled_off_okskia_renderer: enabled_onvideo_decode: enabledvideo_encode: enabledvulkan: disabled_offwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
31.20GB (3.76GB free)

Process Argv
--crash-reporter-id 040e1e18-72a9-4f7c-8947-9ac35c588627

Screen Reader
no

VM
0%

Extensions (9)

Extension
Author (truncated)
Version

soar
bde
0.1.0

python
ms-
2022.16.1

vscode-pylance
ms-
2023.1.10

jupyter
ms-
2022.7.1102252217

jupyter-keymap
ms-
1.0.0

java
red
1.14.0

tcl
sle
0.2.0

vscodeintellicode
Vis
1.2.30

vscode-maven
vsc
0.40.4

A/B Experiments
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492:30256859
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805cf:30301675
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdf:30486550
c4g48928:30535728
dsvsc012cf:30540253
azure-dev_surveyone:30548225
pyindex848:30662994
nodejswelcome1cf:30587006
282f8724:30602487
pyind779:30662992
89544117:30613380
pythonsymbol12cf:30657549
2i9eh265:30646982

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.75.1. Please try upgrading to the latest version and checking whether this issue remains.
Happy Coding!

Do you usually use "Run as administrator" to launch VS Code? If yes, this probably explains what you are seeing. I suggest you exit VS Code then run it without escalated privileges. Does the update option appear?

It appears the issue was that I had a "user" installation instead of a
"system" installation. Why that mattered and gave no indication that it
mattered is a mystery to me, but replacing with a "system" installation
appears to have solved the problem.
On 2/15/2023 4:04 PM, John Murray wrote:

Do you usually use "Run as administrator" to launch VS Code? If yes,
this probably explains what you are seeing. I suggest you exit VS Code
then run it without escalated privileges. Does the update option appear?
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/174489#issuecomment-1432029608,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN5R2OBAA2IDBWEY55J5GDWXVAEDANCNFSM6AAAAAAU5GS7JI.
You are receiving this because you authored the thread.Message ID:
@.***>


Bugfix - Fix syntax error in f-string in print_banner() function

Pull Request
Description
Bugfix - Fix syntax error in f-string in print_banner() function
Changes Made

Fix syntax error in f-string in print_banner() function

Related Issue

Fixes #1

Screenshots (if applicable)
[Include screenshots or other media to visually represent the changes, if relevant.]
Checklist

[x] All tests pass.
[x] Code follows the project's coding standards.
[x] Updated documentation (if applicable).
[x] Comments included for complex sections of code.

Reviewer(s)
Additional Notes
[Any additional information or context that might be helpful for the reviewer.]

Thank you for your contribution!


feature: Add Pub/Sub interface for qSM_Signal_t (qSM_t)

Currently signals can only be sent to particualar qSM_t HSMs. That forces some level of coupling.
HSM that sends signals has to know which HSM is interested in receiving it.
Adding Pub/Sub interafce would allow HSMs to declare which signals it wants to receive without mentioning
any other HSM. That would completly decouple HSMs.
Draft of such an interface can be find here: https://github.com/MichalRostekRostkowski/QuarkTS/pull/2

@ManuelPosada @thejbte ,  what you think about integrating this pattern to the FSM module?
I think the approach proposed by Michal will be simplier to tackle  tackled if is handled as a built-in feature of the qFSM.

Hello guys,
any thoughts on this?

taking a look...

https://github.com/kmilo17pet/QuarkTS/commit/79d9626efea46501e42db30bf29c0fe4fa1bbd13
Thanks @MichalRostekRostkowski


openui5_connect task not working with grunt-contrib-connect 0.11.*

Example:
In application https://github.com/SAP/openui5-sample-app I changed Gruntfile.js  and I have  error.
see attachment

Fixed with 0.8.0 which just got published.


feat: コウメ太夫構文ジェネレーターの追加

close #583

Type of Change:
以下の構文ジェネレーターを追加します。
!koume RSA鍵を登録した ed25519

RSA鍵を登録したと思ったら〜♪
ed25519 でした〜♪
チクショー！！
#毎日チクショー

Codecov Report

Merging #584 (c934fa1) into main (20d8f7d) will increase coverage by 0.00%.
The diff coverage is 76.47%.

:exclamation: Current head c934fa1 differs from pull request most recent head 7ca0d0c. Consider uploading reports for the commit 7ca0d0c to get more accurate results

@@           Coverage Diff           @@
##             main     #584   +/-   ##
=======================================
  Coverage   73.78%   73.79%
=======================================
  Files          62       63    +1
  Lines        4513     4529   +16
  Branches      399      400    +1
=======================================
+ Hits         3330     3342   +12
- Misses        785      788    +3
- Partials      398      399    +1

Flag
Coverage Δ

unittests
73.79% <76.47%> (+<0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/service/command/meme/koume.ts
71.42% <71.42%> (ø)

src/service/command/meme/index.ts
95.65% <100.00%> (+0.41%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


should persist docker auth token after login success

so that we don't have to login again after re-provision the VM.

by using this, we could symlink ./docker/config.json from host to home/.docker/config.json and now we could reuse the docker auth token from the host, this is very convenient.
$ cd teracy-dev
$ ln ~/.docker/config.json ./home/.docker/config.json


https://cn.vite.dev/ missing style  中文站点样式丢了

Documentation is

[X] Missing
[ ] Outdated
[X] Confusing
[ ] Not sure?

Explain in Detail
https://cn.vite.dev/
missing style 中文站点样式丢失了

Your Suggestion for Changes

Reproduction
No response
Steps to reproduce

Now it's normal.

It's strange that my mobile phone and computer are not working here, and there are no styles in Chinese websites.
---原始邮件---
发件人: @.>
发送时间: 2024年12月25日(周三) 上午8:10
收件人: @.>;
抄送<EMAIL_ADDRESS>主题: Re: [vitejs/vite] https://cn.vite.dev/ missing style  中文站点样式丢了 (Issue #19064)
Now it's normal.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

It could be a network problem and the style failed to load.

Many people have similar problems, and the iphone is can working without style.,but vuejs can access the Chinese website，Can you check whether there is a style file on the server?
If you can visit the vite Chinese website in style, it is estimated that there is something wrong with me here. What makes me doubt is that the networks around me are not working.
---原始邮件---
发件人: @.>
发送时间: 2024年12月25日(周三) 上午8:26
收件人: @.>;
抄送<EMAIL_ADDRESS>主题: Re: [vitejs/vite] https://cn.vite.dev/ missing style  中文站点样式丢了 (Issue #19064)
It could be a network problem and the style failed to load.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

I reproduced it and it seems to be the problem.

We can turn the question to https://github.com/vitejs/docs-cn

Everything is normal now, can you try again?

For one minute, it worked normally, and there was a style. When I forced a refresh, the style was gone
---原始邮件---
发件人: @.>
发送时间: 2024年12月25日(周三) 上午9:09
收件人: @.>;
抄送<EMAIL_ADDRESS>主题: Re: [vitejs/vite] https://cn.vite.dev/ missing style  中文站点样式丢了 (Issue #19064)
I reproduced it and it seems to be the problem.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Let's move this issue to https://github.com/vitejs/docs-cn/issues/1137

Update:
I've triggered a redeployment and it's looks normal now. Thanks for the feedback 🙏.
I'll look into the specific reasons when I have time.


Adafruit Motor/Stepper/Servo Shield for Arduino v2 Kit - v2.3

Support for "Adafruit Motor/Stepper/Servo Shield for Arduino v2 Kit - v2.3"
https://www.adafruit.com/product/1438
This kit uses i2c and can be coupled relatively easy to a raspberry pi. E.g. by soldering a 6 pin header in the breadboard section.
M1 and M2 have been tested on my basic robot.
Grtz,
Ruud Schramp

Thanks for the Pull Request, however this library is being deprecated. Please use the new replacement library here:
https://github.com/adafruit/Adafruit_CircuitPython_PCA9685
Setup instructions here:
https://learn.adafruit.com/16-channel-pwm-servo-driver/python-circuitpython
If there is still a need for the updates provided by this pull request, please resubmit based on new library:
https://github.com/adafruit/Adafruit_CircuitPython_PCA9685/pulls


Typo in smart-subscription.md

Correction to code example. The real method is "refresh", not "restart".

Thanks for your PR! :+1:


Custom Logo

Is there a way to put a custom logo or watermark on the video or even in the video controls like youtube does? I would want to add my own logo though for the embeds on my site...

Yep with CSS would be your best bet. Not something we'd want to bake into the player I don't think

I was able to add the logo perfectly. I like the customization-ability of the player.

@sparkktv How did you do?

@lepusmorris Custom CSS. The custom CSS has to be on the controls though and then move it into position. Anywhere else and the logo hides behind the player, likely due to z-index.

@sparkktv Can You send me The css To put Logo and Increase The size of the Button

.plyr__controls {
 background:url(/wp/wp-content/uploads/bank.jpg) 99% 70% no-repeat,linear-gradient(rgba(0,0,0,0),rgba(0,0,0,.5))!important;
 background-size:100px auto,auto!important
}

Got it to work

Hello,
Plyr is a great simple player and a watermark is a good feature to add. @vibhi19 solution is fine but the logo will gone when the control panel fades out. Also you can't add text watermark and you have some limits.
So, I find a better way to do this and it will work also on mobile phones and different screen sizes.
This JS/JQuery code will add a div that will be displayed over the video even in full screen mode:
setTimeout(function(){
var html = '
My Website Name
';
$('.plyr__controls').after(html);
},100);

Hi everyone, just throwing my two cents here...
Using just CSS I was able to have a custom logo, both always shown and hiding alongside the player controls:
Always shown
.plyr__video-wrapper::before {
  position: absolute;
  top: 5px;
  left: 5px;
  z-index: 10;
  content: url('https://test.png');
}

Using that, the image size cannot be changed, so please pick a small image.
Hiding with player controls
.plyr--video .plyr__controls {
  background: url(https://test.png) 99% 0px no-repeat, linear-gradient(rgba(0, 0, 0, 0), rgba(0, 0, 0, .5))!important;
}

Using that the image size can be changed by adding something like background-size: 70px auto, auto!important;
Hope it helps.

.plyr__video-wrapper::before {
position: absolute;
top: 5px;
left: 5px;
z-index: 10;
content: '';
display: block;
height: 30px;
width: 100px;
background: url('https://test.png') no-repeat;
background-size: 100px auto, auto;
}

.plyr__video-wrapper::before {
position: absolute;
top: 5px;
left: 5px;
z-index: 10;
content: '';
height: 30px;
width: 100px;
background: url('https://test.png') no-repeat;
background-size: 100px auto, auto;
}

WHere to keep this code inside index.html
or some where else

inside your css file

.plyr__video-wrapper::before {
position: absolute;
top: 5px;
left: 5px;
z-index: 10;
content: '';
height: 30px;
width: 100px;
background: url('https://test.png') no-repeat;
background-size: 100px auto, auto;
}

WHere to keep this code inside index.html
or some where else

inside your css file

I did it this way, because that way I have full control to position anywhere and set any attribute to be able to give more powers to the player.
const player_598436 = new Plyr('#dsp_video_598436');
var plyrWrapper = document.querySelector(".plyr__video-wrapper");
var plyrLogo = document.createElement("DIV");
plyrLogo.style = `
	background-repeat: no-repeat;
	background-image: url("url-my-logo.png");
	background-size: contain;
	background-position: center;
	position: absolute;
	bottom: 5%;
	right: 1%;
	width: 8%;
	height: auto;
	padding-bottom: 8%;
	z-index: auto;
`;
plyrWrapper.appendChild(plyrLogo);

Thank you! that worked for me!😄

.plyr__video-wrapper::before {
content: '';
position: absolute;
z-index: 10;
height: 10%;
width: 10%;
top: 5px;
left: 5px;
background: url(//logo.png);
background-size: 100% auto, auto;
background-repeat: no-repeat;
}


vendor/open-simulation-interface: Add full_package_mode

Set full_package_mode for Protobuf to consider the case that a consumer recipe might set Protobuf as a shared or static library.
How to reproduce issue:

Set the following options in your consumer: 'self.options['open-simulation-interface'].shared = True' and
'self.options['protobuf'].shared = True'
Then upload the packages to artifactory.
Now change self.options['protobuf'].shared = False in your consumer package.
Try to compile again. Assuming that your Conan configuration has as default `default_package_id_mode = semver_direct_mode' then the first version of OSI produced which links to a Protobuf as shared library is installed in your Conan cache.

That all said: Merging this PR isn't going to break anything so I'm not against it. You have to address the underlying issue too otherwise something will break again in the future.

That all said: Merging this PR isn't going to break anything so I'm not against it. You have to address the underlying issue too otherwise something will break again in the future.

I understand your point and I agree that changing this recipe is then not the permanent solution for our issue. I will proceed to merge this PR just to signal this issue for the future and that we eventually have something in the history that can help if it happens again but we will not depend on this solution.
I have temporarily fixed the issue without having to depend on the fixed recipe.


[Feature] support a template engine

I am working on my own project and I chose ninja for its simplicity. But I still think there can be something improved on top of it without interrupting its current design. As a result, I added a template engine to preprocess the ninja file.
Do you think this feature can be merged into ninja? https://github.com/wilsonwang371/ninja

Why don't you just make a pull request for it?


Resolving middleware breaks if resolver throws unexpected exception type

CallableResolver call is wrapped in a catch that expects RuntimeException
https://github.com/slimphp/Slim/blob/8294d20e016b01ba57eb2cdb8c0f59cde502d1ab/Slim/MiddlewareDispatcher.php#L214-L222
If a resolver throws exception that doesn't extend from RuntimeException this halts the execution and fallback code below is never reached.
Real example of the issue with third party resolver: https://github.com/PHP-DI/Slim-Bridge/issues/51
I am not sure what's the reasoning for specifically RuntimeException here, but broadening it to Exception might be a good idea for resilience?

I'm not sure it silencing all exceptions thrown by callable resolver is the best idea, personally.
Having a dedicated interface for this would be better, but it would also introduce a possible breaking change for callable resolver implementors.
something like this:
if ($this->callableResolver instanceof CallableResolverInterface) {
     try {
         $callable = $this->callableResolver->resolve($this->middleware);
     } catch (UnableToResolveCallableExceptionInterface $e) {
         // Do Nothing
     }
 }

A better interface name is needed.

@dakujem note that there is already AdvancedCallableResolverInterface, I am guessing CallableResolverInterface is retained for backwards compatibility so breaking changes to it are probably not an option.

@Rarst

I am guessing CallableResolverInterface is retained for backwards compatibility so breaking changes to it are probably not an option.

This is exactly why. Ultimate in Slim 5 we should get rid of AdvancedCallableResolver and unify the 2.

We need to specifically ensure that the exception thrown is because the callable could not be resolved

I follow the sentiment. The current implementation neither ensures that distinction or let fallback code be consistently reached.
My initial thought was to prioritize reaching fallback code since that would make more cases work.
Making more cases fail clearly does not look possible without introducing a new exception and having to rewrite existing interface implementers. At which point they could as well update to advanced interface.


Validate project configuration when requiresProject is true

Add a hook in SfpowerscriptsCommand that perform project-config validation whenever the requiresProject property is set to true

Codecov Report

Merging #455 (43fa029) into develop (492270d) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           develop     #455   +/-   ##
========================================
  Coverage    80.72%   80.72%
========================================
  Files           32       32
  Lines         1110     1110
  Branches       197      197
========================================
  Hits           896      896
  Misses         214      214

Impacted Files
Coverage Δ

...ages/core/src/artifacts/ArtifactFilePathFetcher.ts
30.18% <100.00%> (ø)

Continue to review full report at Codecov.

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


Allow TLS configuration for Postgres DBs in auto-setup.sh

This PR replaces #60.
What was changed
Arguments were added to auto-setup.sh which allow TLS terminated connections to Postres databases for schema setup.
Why?
Our database server requires TLS connections.

Closes #59

How was this tested:
This change only forwards arguments. I'm relying on the documentation of the command temporal-sql-tool. However, I have tested that command in an existing container to make sure the boolean flags work as expected and that arguments with empty strings as values are ignored.

Any docs updates needed?
It seems to me the code is the documentation. At least I found several links to the auto-steup.sh file in the docs.

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


Crash of initcontainer due to panic

When running appcontroller initcontainer I get:
panic: interface conversion: error is *url.Error, not *errors.StatusError

goroutine 1 [running]:
panic(0x1819800, 0xc4203f8080)
        /usr/local/go/src/runtime/panic.go:500 +0x1a1
github.com/Mirantis/k8s-AppController/cmd.createTPRIfNotExists(0xc42030d140, 0x12, 0xc42030d120, 0x12, 0xc42030d100, 0x1d, 0x0, 0x0, 0x0, 0x0, ...)
        /go/src/github.com/Mirantis/k8s-AppController/cmd/bootstrap.go:43 +0x1d7
github.com/Mirantis/k8s-AppController/cmd.bootstrap(0x23d8300, 0xc420432200, 0x1, 0x1)
        /go/src/github.com/Mirantis/k8s-AppController/cmd/bootstrap.go:83 +0x252
github.com/spf13/cobra.(*Command).execute(0x23d8300, 0xc4204321c0, 0x1, 0x1, 0x23d8300, 0xc4204321c0)
        /go/src/github.com/spf13/cobra/command.go:603 +0x439
github.com/spf13/cobra.(*Command).ExecuteC(0xc4203de6c0, 0x0, 0x0, 0x0)
        /go/src/github.com/spf13/cobra/command.go:689 +0x367
github.com/spf13/cobra.(*Command).Execute(0xc4203de6c0, 0x0, 0x0)
        /go/src/github.com/spf13/cobra/command.go:648 +0x2b
main.main()
        /go/src/github.com/Mirantis/k8s-AppController/main.go:26 +0x36

I see the reason of panic, I will correct this and find the underlying error.

Fixed by #86

The error that caused the panic happens (for unknown reasons yet) when using local-up-cluster. There are no reported problems with minikube.

@zefciu but is the panic fixed?

The panic is fixed. Now in this case you get correctly logged that it couldn't dial the kubernetes service. This is not a fault of appcontroller. I just mentioned it here for information.


[Grafana] Add tags to all grafana dashboards

Motivation
Currently, only the Prometheus dashboard contains an appropriate tag. The idea is to add tags to all dashboards, for visibility and fast filtering.

Modifications
Appropriate tags were added to all grafana dashboards shipped with Pulsar.

@tuteng @codelipenghui Would you also help review this?

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

/pulsarbot run-failure-checks

Looks we can skip the CI for Grafana dashboard changes.

@codelipenghui yes, the CI pipeline can be skipped for this change.

/pulsarbot run-failure-checks


!moreinfo

Feature request: Get more info about the current playing song, we can leverage the !np command and either use spotify or genius to get more info on the song, whatever API returns better info
Submitted by: Cash#8915
Server: mfDiscord

Added the following, rather than making a command that basically does the same thing, decided to re-work nowplaying to incorporate more info.


Add test that executes ipfs binary

for example: https://github.com/ipfs/npm-go-ipfs/blob/43d2964358beb142a5d9b97c399d8086c5f1295f/test/index.js

Now, npm-go-ipfs-dep is a dep of npm-go-ipfs, so that test gets executed for this one, not directly, but pretty close as they get released together :)


Disable x/blobstream in v2

Context
Blobstream is currently enabled for app version 2. See
https://github.com/celestiaorg/celestia-app/blob/1d73e334a48732ba2ef07caf064a7060175381f0/app/app.go#L516-L517
We reached rough alignment that we don't need to support the x/blobstream module in v2.
Proposal

Modify the ToVersion: 1 so that blobstream isn't enabled in app version 2.
Verify that the x/blobstream CLI commands are removed in celestia-app v2
Verify that the x/blobstream gRPC queries and txs are removed in celestia-app v2
Consider removing x/blobstream from the specs and/or only including them on the v1 specs and removing from v2 specs.
Add a migration that deletes state in the x/blobstream module

The OP proposal doesn't account for the staking keeper hooks that Blobstream added. We need a mechanism to remove those hooks from the staking module in v2. Currently hooks aren't version-aware.


Fix es.indices introduced version

https://github.com/justwatchcom/elasticsearch_exporter/releases/tag/v1.0.2

/assign @zwopir

thanks!

Thank you @zwopir!


'the Protocol Buffer runtime library' ERROR

Hi,
I got this error when I try the inversion process. The whole error message is shown below.
/home/yzeng/anaconda3/envs/ldm/lib/python3.8/site-packages/pytorch_lightning/core/datamodule.py:423: LightningDeprecationWarning: DataModule.setup has already been called, so it will not be called again. In v1.6 this behavior will change to always call DataModule.setup.
  rank_zero_deprecation(
LOCAL_RANK: 0 - CUDA_VISIBLE_DEVICES: [0]
2022-09-26 18:50:06.970489: I tensorflow/core/platform/cpu_feature_guard.cc:193] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX2 AVX512F AVX512_VNNI FMA
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
[libprotobuf FATAL google/protobuf/stubs/common.cc:83] This program was compiled against version 3.9.2 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.19.5).  Contact the program author for an update.  If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library.  (Version verification failed in "bazel-out/k8-opt/bin/tensorflow/core/framework/tensor_shape.pb.cc".)
terminate called after throwing an instance of 'google::protobuf::FatalException'
  what():  This program was compiled against version 3.9.2 of the Protocol Buffer runtime library, which is not compatible with the installed version (3.19.5).  Contact the program author for an update.  If you compiled the program yourself, make sure that your headers are from the same version of Protocol Buffers as your link-time library.  (Version verification failed in "bazel-out/k8-opt/bin/tensorflow/core/framework/tensor_shape.pb.cc".)
Aborted (core dumped)

Do you know how to fix this problem?
Thank you.

Looks like you've got a wrong version of one of the libraries (protobuf).
Are you using our env, or your own? Either way, try to install the version of protobuf it's asking for (3.9.2).

Looks like you've got a wrong version of one of the libraries (protobuf). Are you using our env, or your own? Either way, try to install the version of protobuf it's asking for (3.9.2).

The environment I used was provided by ldm. I reinstall all your libraries. Now it works. Thank you for your reply.

Happy to help. Closing now as it seems resolved.


Format plugin misconfiguration

With the fix provided in #11, do a build with mvn verify -Prelease:
[INFO] Checking licenses...

Ah, ok, that's the license plugin not the format plugin.

Mmmh, why do you have a war and gwt-unitcache folder in your gwt-core-gwt2-tests?

Whoops, may have stale output from an old commit, I'll retry from a clean checkout.


[Bug] Placeholder text live code and specs don't match

Block helper, inline helper, and placeholder text do not match Design System specs
Update: I have updated this issue after confirming that the helper text (block and inline) is displaying correctly. The remaining issue is the placeholder text on the texts input page. I have documented the possible fixes here.
Design System styling:
Specs:

  - Avenir Next Regular, 16 px, Gray (#5a5d61)

Live code example:

  - Avenir Next Regular, 14 px, Gray (#5a5d61) (for helper text)

  - Avenir Next Regular, 16 px, Black (#101820)(for placeholder text)
To Reproduce

Steps to reproduce the behavior:

Go to 'https://cfpb.github.io/design-system/components/helper-text#types-1'

Click on ‘show details - specs’ for each of the 3 types

View live code examples

Compare to specs

Expected behavior

I expect the code to reflect the documented style specs
These 3 types of text should match in terms of size and color

Resolution

Update block helper, inline helper and placeholder text to Avenir Next Regular, 16 px, Gray (#5a5d61)

@contolini @anselmbradford

I do not see any mismatch between the specs and the font-sizes / colors.
Block helper
font-size: 16px
font: Avenir Next
color: #5a5d61

Inline helper
font-size: 16px
font: Avenir Next
color: #5a5d61

Placeholder
font-size: 16px
font: Avenir Next
color: Can't verify the color

@anselmbradford - Do know what  is meant to do in the code for the block helper text and inline helper text?

@meissadia
If the inline helper, block helper, and placeholder are all set to 16px then that's good news. I inspected yesterday and got 14px but perhaps that was an error. If the only issue is the placeholder text being the wrong color then we can just handle the global update here: https://github.com/cfpb/design-system/issues/1702

On CF.gov I see the placeholder set to the expected grey, not sure why this setting isn't coming through on the Design System doc pages
cfpb-forms/src/atoms/text-input.less
::placeholder {
  color: #5a5d61;
}

This is the page where the placeholder text is showing up as Black (#101820) instead of Gray.
https://cfpb.github.io/design-system/components/text-inputs

Ok, I took another look and I think I see what’s happening. The text on the text inputs page labels the input text as "placeholder text." But what it is actually showing stylistically is text that has been entered  by a user (that's why it's showing up in black). So, if this is the intent, we should change the wording of the text in the fields to better reflect what the live code is intended to show.
Option 1. If the example is intending to show text that a user has typed in the field we can use "User input text" or "Input text." I can also update the specs to include specs for both the placeholder text and the input text (shown below).

Current
Updated

Option 2: If the example is intending to show placeholder text we can change the code to make it show that.
Option 3: Or we can leave the fields blank (this is what is done on USWDS).

Option 2: Placeholder text (Gray)
Option 3: Blank input fields

Regardless of what we decide for the live code examples I'll update the specs to show the text styling for both placeholder and input text.

@ans @meissadia
I just had a realization. The 14px helper text that I originally identified happens at mobile. Because the helper text is set to a value relative to the size of the parent element (the label) and the parent element drops down in size at mobile the helper text is dropping down as well. The helper text should be 16px at all screen widths.

I have now updated the specs content on the text input page to include the text styling for both placeholder and input text.
We include the following guidelines for placeholder text: "Placeholder text appears within a text input field, and disappears once a user begins typing in that field. Use it for formatting examples only."
The examples we include are very much that - formatting examples. The examples that were on the text input page (before I just published an edit) are not formatting examples. So, a question then is should we generally default to no placeholder text unless there is a clear need that is a formatting example? Are there accessibility reasons for or against populating the placeholder text attribute?

I have now updated the live code for the "Text input" page and it is displaying as described in Option 1 (above).
There is one more odd thing happening with the Date picker live code example where it shows placeholder text but is loading as Black.

I have moved the remaining tasks to their own issues:

Helper text (block and inline) are 14px at mobile. They should be 16px. - This task is now captured here: https://github.com/cfpb/design-system/issues/1712
Date picker live code placeholder example is showing up as black instead of gray - This task is now captured here: https://github.com/cfpb/design-system/issues/1713

Closing this issue because the remaining tasks have been completed.


[Store] Test case: <IP_ADDRESS>: To new application developer, it allows to input a password that does not consist of any special character

Description-:
Test case:
<IP_ADDRESS>- [N] No body should be allowed to input a password that does not consist any special characters during the signup
Result:
It allows to input a password without any special characters.

Password policy is configurable. The default password policy configured in 3.1.0 is ^[\S]{5,30}$. Hence, if user wants to force special characters they can modify it using following configuration in deployment.toml:
[user_store]
properties.PasswordJavaScriptRegEx = $password-regex
properties.PasswordJavaRegEx = $password-regex


feat: pass custom styles and scripts to login template

This pull request parses the scripts and styles arguments passed to the AdminBro constructor for display on the login page. This will allow basic style overrides using a custom stylesheet.
Would probably allow you to close the following issues:
https://github.com/SoftwareBrothers/admin-bro/issues/347
https://github.com/SoftwareBrothers/admin-bro/issues/531
To use custom styles on the login page:
new AdminBro({
  assets: {
    styles: ['/some-stylesheet.css'],
  }
});

Looks good, thanks for the PR!
I've changed the base branch to beta

Looks good, thanks for the PR!
I've changed the base branch to beta


Splash screen for iOS

Hi,
First, thanks to your package !
Did you considered to add splash screen meta for iOS ? https://medium.com/@applification/progressive-web-app-splash-screens-80340b45d210
Quite simple to implement and great benefits !

I've added my own splash-screen to the app... but it's still showing the default white screen with PWA icon... I've emptied cache and re-installed the app...


Add support for spread properties in stylesheets

Can you add a test to ensure this is covered?

Good to go!


check if async error has a stack

https://github.com/kblok/puppeteer/pull/19/commits/02b2451db5d8134bb860f7616e4b58185f15766b

Nothing to do here


x/pkgsite: for some repositories, the View Source works well for reading code but not figuring out where changes are made

What is the URL of the page with the issue?
https://pkg.go.dev/golang.org/x/website/internal/history#Releases
What did you do?
I shared the link https://pkg.go.dev/golang.org/x/website/internal/history#Releases that points to Releases, an exported package-scope variable in the golang.org/x/website/internal/history package, with the goal of making it clear what the identifier is, what package it's located in, and in turn what repository that package is located in.
In this situation, I wanted it to be possible for someone to find out where the source code lives, so they can send a change that modifies the Releases variable.
What did you expect to see?
I expected to see a documentation page with the Releases variable highlighted, and a way of finding out the underlying source code location for purposes of making changes (in addition to just reading).
In this case, the custom import path golang.org/x/website has a go-import meta tag that specifies that the root golang.org/x/website corresponds to a git repository at the URL https://go.googlesource.com/website:
$ curl -s https://golang.org/x/website | grep go-import
<meta name="go-import" content="golang.org/x/website git https://go.googlesource.com/website">

What did you see instead?
Under the "Repository" link, I saw a link to "cs.opensource.google/go/x/website":

On the right hand side of the identifier, I saw a "View Source" link:

Clicking that link takes one to https://cs.opensource.google/go/x/website/+/55fae94f:internal/history/release.go;l=16, which displays the source code and makes reading it convenient. There are many mentions of "x/website", but I have not been able to find the full URL of the underlying git repository.
Perhaps this is a bug/feature request for the https://cs.opensource.google website, although then it would still require pkg.go.dev users 2 hops to be able to get to this information.

/cc @julieqiu

Duplicate of #46243?

Yep, I think it's the same, thanks.


Revert "[Reland] Force automatic ndk download when building for Andro…

…id (#160260)"
This reverts commit 2948917a470470c1ee2a3b5897dc229417776829.

Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.
List which issues are fixed by this PR. You must list at least one issue. An issue is not required if the PR fixes something trivial like a typo.
If you had to change anything in the flutter/tests repo, include a link to the migration guide as per the breaking change policy.
Pre-launch Checklist

[ ] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[ ] I read the Tree Hygiene wiki page, which explains my responsibilities.
[ ] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[ ] I signed the CLA.
[ ] I listed at least one issue that this PR fixes in the description above.
[ ] I updated/added relevant documentation (doc comments with ///).
[ ] I added new tests to check the change I am making, or this PR is test-exempt.
[ ] I followed the breaking change policy and added Data Driven Fixes where supported.
[ ] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel on Discord.

Please update the PR template/description and explain why this is being reverted (links to a bug or discussion, or at minimum a short summary of the change)

Will do, made it for this discord conversation but then didn't update because I remembered tree is closed and rollers are off


not able scan individual ip of node

I have installed kube-hunter on gke cluster ,but when I hit command kube-hunter and selected option 1 ,in that I have put ip of node which getting from from kubectl get nodes -o wide ,then it gives error couldn't find cluster.  If create pod and checked logs of kube-hunter that method works fine .[when cluster implemented on on premise then all everything working fine.Only on cloud it give above error (GCP,AWS)]

yes the same issue i am also facing !!!!

Hi, @varshabhijeet
Can you provide more details about the machine you are running kube-hunter from? I see you use the internal IP of the node, can you access this IP? have you tried using the external IP?

Yes I have tried by both IP but  got same result

In case of AWS i have tried from ubuntu machine from which I have connected to  kubernetes cluster

@varshabhijeet can you try running kube-hunter as a job inside the cluster?

Also please run with --log debug, this will help us alot with solving this problem

@varshabhijeet can you try running kube-hunter as a job inside the cluster?
yes kube hunter pod working inside cluster but from remote machine access to cluster  not possible.

Also please run with --log debug, this will help us alot with solving this problem
Remotes (separated by a ','): <IP_ADDRESS>
2020-11-10 13:54:37,802 DEBUG kube_hunter.core.events.handler Event <class 'kube_hunter.core.events.types.HuntStarted'> got published with <kube_hunter.core.events.types.HuntStarted object at 0x7fd7104309b0>
2020-11-10 13:54:37,802 DEBUG kube_hunter.core.events.handler Event <class 'kube_hunter.core.events.types.HuntStarted'> got published with <kube_hunter.core.events.types.HuntStarted object at 0x7fd7104309b0>
2020-11-10 13:54:37,802 DEBUG kube_hunter.core.events.handler Event <class 'kube_hunter.modules.discovery.hosts.HostScanEvent'> got published with <kube_hunter.modules.discovery.hosts.HostScanEvent object at 0x7fd7104309e8>
2020-11-10 13:54:37,802 DEBUG kube_hunter.core.events.handler Executing <class 'kube_hunter.modules.report.collector.StartedInfo'> with {'previous': None, 'hunter': None}
2020-11-10 13:54:37,803 INFO kube_hunter.modules.report.collector Started hunting
2020-11-10 13:54:37,803 INFO kube_hunter.modules.report.collector Discovering Open Kubernetes Services
2020-11-10 13:54:37,802 DEBUG kube_hunter.core.events.handler Executing <class 'kube_hunter.modules.discovery.kubectl.KubectlClientDiscovery'> with {'previous': None, 'hunter': None}
2020-11-10 13:54:37,803 DEBUG kube_hunter.modules.discovery.kubectl Attempting to discover a local kubectl client
2020-11-10 13:54:37,803 DEBUG kube_hunter.core.events.handler Executing <class 'kube_hunter.modules.discovery.hosts.HostDiscovery'> with {'active': False, 'predefined_hosts': []}
2020-11-10 13:54:37,809 DEBUG kube_hunter.core.events.handler Event <class 'kube_hunter.core.events.types.NewHostEvent'> got published with <IP_ADDRESS>
2020-11-10 13:54:37,810 DEBUG kube_hunter.core.events.handler Executing <class 'kube_hunter.modules.discovery.ports.PortDiscovery'> with {'host': '<IP_ADDRESS>', 'cloud_type': None, 'event_id': 0, 'previous': <kube_hunter.modules.discovery.hosts.HostScanEvent object at 0x7fd7104309e8>, 'hunter': <class 'kube_hunter.modules.discovery.hosts.HostDiscovery'>}
2020-11-10 13:54:37,810 DEBUG kube_hunter.modules.discovery.ports host <IP_ADDRESS> try ports: [8001, 8080, 10250, 10255, 30000, 443, 6443, 2379]
2020-11-10 13:54:37,810 DEBUG kube_hunter.modules.discovery.ports Scanning <IP_ADDRESS>:8001
2020-11-10 13:54:37,815 DEBUG kube_hunter.modules.discovery.kubectl Could not find kubectl client
2020-11-10 13:54:39,312 DEBUG kube_hunter.modules.discovery.ports Scanning <IP_ADDRESS>:8080
2020-11-10 13:54:40,814 DEBUG kube_hunter.modules.discovery.ports Scanning <IP_ADDRESS>:10250
2020-11-10 13:54:42,316 DEBUG kube_hunter.modules.discovery.ports Scanning <IP_ADDRESS>:10255
2020-11-10 13:54:43,817 DEBUG kube_hunter.modules.discovery.ports Scanning <IP_ADDRESS>:30000
2020-11-10 13:54:45,319 DEBUG kube_hunter.modules.discovery.ports Scanning <IP_ADDRESS>:443
2020-11-10 13:54:45,481 DEBUG kube_hunter.modules.discovery.ports Scanning <IP_ADDRESS>:6443
2020-11-10 13:54:46,983 DEBUG kube_hunter.modules.discovery.ports Scanning <IP_ADDRESS>:2379
2020-11-10 13:54:48,485 DEBUG kube_hunter.core.events.handler Event <class 'kube_hunter.core.events.types.HuntFinished'> got published with <kube_hunter.core.events.types.HuntFinished object at 0x7fd710430a20>
2020-11-10 13:54:48,485 DEBUG kube_hunter.core.events.handler Executing <class 'kube_hunter.modules.report.collector.SendFullReport'> with {'previous': None, 'hunter': None}
2020-11-10 13:54:48,485 DEBUG kube_hunter.modules.report.dispatchers Dispatching report via stdout

Kube Hunter couldn't find any clusters
2020-11-10 13:54:48,485 DEBUG kube_hunter.main Cleaned Queue
this is output

@varshabhijeet looks like normal behavior.
This is not a problem in kube-hunter, this ip of the node is probably not accessible from where you are running kube-hunter.
I can further help you to figure out why this is happening but I would recommend just running kube-hunter as a pod inside your cluster.


Adding messageHash to ExecutingMessage

Description
This PR introduces a small change to the ExecutingMessage event in the CrossL2Inbox predeploy. Instead of emitting the entire message, it emits the hash of it as was suggested by @skeletor-spaceman.
Additional context
This change, although small, may affect other specs. I was not certain whether to include changes to multiple specs here or to have people more familiar with other specs push the respective changes (should this change be accepted) as well.
As an example, the sequencer.md file contains pseudocode showing how to check the existence of a log based on the Identifier. That code deserializes the log.data to get the entire message. After this change, it will only get the messageHash, and that code's further check should most likely compare the messageHash with the hash of encode(log[0])

This seems like a great improvement, going to want to double check with @ajsutton to make sure this doesn't impact him

The database always works on payload hash anyway so I don't see any issues with this.

We will need to update this section too: https://github.com/ethereum-optimism/specs/blob/main/specs/interop/sequencer.md#direct-dependency-confirmation
The abi.decode part will need to decode a hash instead of the message

Can we/should we use this PR to switch to outputting the Identifier as a struct rather than first serialising it to bytes? Because the field isn't indexed it should work fine and makes parsing the event much simpler and easier to test that its in sync with the contracts (see also https://github.com/ethereum-optimism/optimism/pull/11104)


md-input padding does not affect underline

Bug, feature request, or proposal:
bug
What is the expected behavior?
Underline should be affected
What is the current behavior?
setting padding for md-input doesn't affect underline
What are the steps to reproduce?
http://plnkr.co/edit/Jl20dtBLH8hILAahubzu?p=preview
Which versions of Angular, Material, OS, browsers are affected?
"@angular2-material/core": "^2.0.0-alpha.6",
"@angular/core": "2.0.0-rc.4",
Is there anything else we should know?
Fix:
change .md-input-underline position from absolute to relative

Hi @maciejsobala, it seems like you're trying to add spacing around the input itself. You should use margin instead of padding in this case. Changing padding inside the input is not supported.


[NTR]: medullary plasma cell

Note - please check that the term does not already exist (check OLS: https://www.ebi.ac.uk/ols/ontologies/cl)
Preferred term label:
medullary plasma cell
Synonyms
plasma cell of medullary sinus; medullary sinus plasma cell
Definition (free text, please give PubMed ID in format PMID:XXXXXX)
A plasma cell that is located in the medullary sinus of the lymph node.
Parent cell type term (check the hierarchy here https://www.ebi.ac.uk/ols/ontologies/cl):
plasma cell: http://purl.obolibrary.org/obo/CL_0000786
What is the anatomical structure that the cell is a part of? Please check Uberon: https://www.ebi.ac.uk/ols/ontologies/uberon
lymph node: http://purl.obolibrary.org/obo/CL_0000786
Your nano-attribution (ORCID)
0000-0003-4183-8865
Any additional notes or concerns
Part of anatomograms project with SCA - @paolaroncaglia. Sorry for the definition - i couldln't find a specific location-related role for these cells but we have them as a cell shape in the anatomogram. Maybe for EFO?

@ngeorgeebi and @sfexova
This request is for "A plasma cell that is located in the medullary sinus of the lymph node.", so the correct part_of parent would be Uberon 'lymph node medullary sinus', not the broader 'lymph node' as you suggested. 'lymph node medullary sinus'is part of 'medulla of lymph node' which is part of 'lymph node'. May I go ahead and create the term as part of 'lymph node medullary sinus', or is there an issue similar to https://github.com/obophenotype/cell-ontology/issues/989#issuecomment-874624066?
Thanks in advance for your feedback.
Paola

Also, re. new term label(s), we should keep in mind Alex's comment here.

Re. part_of parents: discussed at curators meeting today, Silvie confirmed that redundant part_of links are not needed for anatomograms.

@ngeorgeebi (cc @sfexova )
The new term is CL_0009059 (plasma cell of medullary sinus of lymph node).


Experiment with vaapi for the Preview-Encoders

This PR enables a new Config-Option vaapi in the [previews] which switches the preview-encoders to vaapi-accelerated hardware. This offloads the CPU quite a bit and quality vs. bandwidth is not an issue here either.
he UI has a rudimentary understanding of the different encoders and which decoders need to be used for them, although only none and h264 have been tested yet.

vaapih264enc existiert nicht auf encoder6, vaapiencode_h264 failt mit
   DEBUG AVPreviewOutput[cam1_preview]: Received Error-Signal on Output-Pipeline
   DEBUG AVPreviewOutput[cam1_preview]: Error-Details: #3: gstvideoencoder.c(1559): gst_video_encoder_change_state (): /GstPipeline:pipeline1/GstVaapiEncodeH264:vaapiencodeh264-0:
Failed to open encoder

weiteres research ist erforderlich

https://blogs.igalia.com/vjaquez/2016/04/06/gstreamer-vaapi-1-8-the-codec-split/

This explains the name-change: https://blogs.igalia.com/vjaquez/2016/04/06/gstreamer-vaapi-1-8-the-codec-split/ (our encoders only run gstreamer 1.6.3)

On our newer Skylake-Systems (esp. Encoder6) a backport-kernel (tested 4.6+74~bpo8+1) is required for the i915-Driver to recognize the intel graphics chipset and enable the vaapi-entrypoints.

The Test-Setup involved two Computers. One is very similar to encoder6 (Intel i7-6700) and ran the voctocore. The other was my notebook (Intel i5-2410M) running the GUI. The Load-Measurements are the 5-Minute-Averages after waiting for ~6 Minutes.
Using 1024x576@25 MJPEG-Previews (former and current default) the Testsystem (Core) had a load of 12.09 while the GUI had a load of 1.85
With the vaapi-h264-encoder the load was even a little higher (13.6) on the core and also on the client (2.24)
It's unclear if using the vaapi-code improves the situation on some computers (just not the ones in this test) or if it is completely useless ;)


Update Transition A rule to a to accept PointMass distribution in VMP

Hm why CI is not running on this PR??

Started manually here https://github.com/ReactiveBayes/ReactiveMP.jl/actions/runs/11435244607


Front end tests

User story

As a team member
I need the front end to be tested under various test cases
So that UI acts as desired

Acceptance criteria

[x]  All UI elements are working as desired.
[x] Code coverage of 70+%

Definition of done (DoD)

[ ]  Feature/Bug/Change has been implemented

[ ]  Application compiles successfully

[ ]  Code is documented

[ ]  Feature/Bug/Change is tested by at least one unit or e2e test

[ ]  Tests have been passed without warnings (except "deprecated" warnings)

[ ]  Changes have been reviewed

[ ]  PR has been merged to dev branch

[ ]  New dependencies have been added to bill of materials

[ ]  Software architecture diagram has been updated

[ ]  All acceptance criteria are fulfilled

[ ]  Screenshot is attached to issue

DoD general criteria

Feature has been fully implemented
Feature has been merged into the mainline
All acceptance criteria were met
Product owner approved features
All tests are passing
Developers agreed to release

Current test coverage:

When running cypress tests, the coverage report gets saved into coveragefolder, we could include this in the CI output.
I added more tests for frontend-only stuff like tooltips, but I'm really struggling with tests that involve signals from the backend. See file cypress/e2e/2-indicators/line-indicators.cy.js: I tried mocking the websocket connection to send a test sample array. And the message is received at the frontend. Problems are:

The message data is received as a string like 1, 0, 0, ... instead of an array buffer.
Despite turning on the oscillator by clicking the start button, $osciEnabled is still false and the onmessage handler doesn't get to updating the other components.


Using MAVSDK with only Iridium connection

Hi! I'm building a drone that would only have a SATCOM connection to it. And I want to be able to send commands to it using SATCOM. And while testing with MAVSDK I notice that it seems to require a connection to PX4 before being able to send MAVLink commands, is that correct?
So I was wondering if it is possible to put the MAVSDK_server into a mode that would only give back the MAVLink string (in hex) so I can then send it through the SATCOM website and communicate with my drone. I would also like reverse path also, so decoding a MAVLink string and return a human-readable string.
Thanks in advance!

it seems to require a connection to PX4 before being able to send MAVLink commands, is that correct?

When you start the connection with udp://:14540, it's equivalent to udp://<IP_ADDRESS>:14540, and it says "have MAVSDK listen (/bind to) on 14540". In that mode, the drone must send MAVLink messages to MAVSDK on port 14540.
When you start the connection with udp://<IP_ADDRESS>:14555, then it tells MAVSDK to start sending MAVLink heartbeats to the drone (here <IP_ADDRESS>) on port 14555. In that mode, the drone must listen (bind) to 14555.

Note that I invented the IPs and ports, you can use whatever you want. The point is just that udp://:<port> and udp://<IP_ADDRESS>:<port> run mavsdk in "server" mode, and udp://<some_ip>:<port> run mavsdk in "client" mode.
Does that help?

Hi @JonasVautherin! I'm familiar with the concept of using the UDP connection and port in general. But I'm more asking where the drone is only able to communicate with it through SATCOM, something like Iridium. So there's no real interface possible, either through UDP or Serial. Imagine that the drone is at 60 000ft (or 25 km) of altitude :sweat_smile: and we want to send and receive MAVLink messages. There's already the Iridium driver in PX4, but I need to add the part that decode and encode those messages.
In an ideal world, I'd like that the MAVSDK_server should just generate it's MAVLink message for the command I'm asking it for and would decode a MAVLink message that I've provided to it. We want to put that MAVSDK_server in our backend. Let me know if that's more clear :)!

Oh... sorry I read to quickly :sweat_smile:. I don't know if it would make sense to add support for Iridium in MAVSDK, but could you make a bridge, say like this?
[------ on the ground -----]                                                [--- on the drone ---]
MAVSDK <--- udp ---> bridge     <------------ Iridium --------------->       drone

So you write your UDP-to-Iridium proxy on the ground, and connect MAVSDK to it over UDP. For MAVSDK, it's just a UDP connection, and the drone just receives MAVLink messages.
Then the question would be whether or not MAVSDK generates too much traffic for your connection, I guess?

No worries, and I wasn't able to add a label to the issue, but it was more of a question towards MAVSDK if it was possible or not. So if it doesn't fit into the design that's alright, I'm more looking at a solution for what I want to do :).
As per your suggestion, that might be a good idea. In the Iridium driver in the PX4 documentation, they actually recommand something similar to what you're suggesting (http://docs.px4.io/main/en/advanced_features/satcom_roadblock.html#overview), here's the diagram:

But we really want to control what's going out of the MAVSDK_server, like on the PX4 we are only allowing some MAVLink streams  going out of the SATCOM since sending through SATCOM is costly : /.
I'd really like to use MAVSDK for this, but I'm unsure if it's a good fit, since I want something more like an encoder/decoder for MAVLink. Maybe I can just add a mode when starting the MAVSDK_server where it's kind of offline and behave differently?

Basically MAVSDK expects some heartbeats from the drone. Are you saying you would not have heartbeats? If so, we would have to make a config option that allows to have the timeout much bigger.
However, you sorta need to discover a system initially, otherwise you don't know what the target system ID and target component ID to send a command to.
MAVSDK also does a bit of initial back and forth to get some basic information. We would have to have some "low bandwidth" mode to avoid all that but it would require some work.

It feels quite specific, I'm not sure if it would fit in MAVSDK. It sounds like you really need to control what goes out of MAVSDK, so anyway I would personally do that with a proxy. Still it may be worth using MAVSDK instead of re-implementing the protocols (e.g. mission transfer, commands, etc).
You can already increase the timeout for commands in MAVSDK. Then for the heartbeat, one way would be to have your proxy "pretend to be the drone" and send regular heartbeats to MAVSDK (say your proxy sends a heartbeat every second, and receives the heartbeats from the drone at whatever rate you want). Same for others, like the parameters: you could maybe have a cache in your proxy, in order to save round-trips.

MAVSDK also does a bit of initial back and forth to get some basic information.

I also would like to know the minimal set of messages that MAVSDK needs to get started. It needs the heartbeats, and then at least a few params (I think). I may get to make a list in the next couple of weeks, so that could help. If you do before me, feel free to share it here :blush:

Hi @julianoes!

Basically MAVSDK expects some heartbeats from the drone. Are you saying you would not have heartbeats? If so, we would have to make a config option that allows to have the timeout much bigger.

We would mainly use a modified version of the HIGH_LATENCY2 for most of our communication with the GCS. So they would act as heartbeat for us.

However, you sorta need to discover a system initially, otherwise you don't know what the target system ID and target component ID to send a command to.
MAVSDK also does a bit of initial back and forth to get some basic information. We would have to have some "low bandwidth" mode to avoid all that but it would require some work.

Yeah, that was my understanding while using it with the PX4 SITL. And that was a motivation behind the questions I'm asking. I feel like MAVSDK is more supported for PX4 than the alternatives, but I wanted to know if it does what I want it to do :sweat_smile:.


help Evaluation of a model

Description
is there any standard method to evaluate a trained model?  I just replaced the test shards with new one and run t2t-train command with --schedule = evaluate and --eval_run_autoregressive.  is it a correct method of evaluating?
TensorFlow 1.6.0 and tensor2tensor 1.5.0

This is what I suggested you at Gitter because you were interested in the (Xentropy) loss and you had the model already trained and just wanted to test on new dataset. In this case, it is the only option. Note however that loss is an intrinsic and internal evaluation measure, hardly comparable across frameworks (or even different models within the same framework if they differ e.g. in vocabulary size). So be careful when comparing these numbers. (I guess most T2T users don't use the --eval_run_autoregressive flag, so their scores are not comparable to yours.)

Thank you. what just made me a bit unsure about this process is that, when I use the same  test set with --schedule = evaluate and --eval_run_autoregressive I got accuracy of 1 and  without these flag set I got accuracy of 90.

Do you mean accuracy 0.01 vs. 0.90? This is really strange. What is your --problem? (BTW: the issue template suggests to report the full command used for training/evaluation.)
If it is machine translation, then --schedule=evaluate should have no effect (relative to the last evaluation in continous_train_and_eval) and --eval_run_autoregressive should not have so huge effect. So please, inspect which of the two options causes the difference.
If it is language modelling, then don't use --eval_run_autoregressive (and I am sorry for confusion) - it would mean generating the whole sentence without any clue what is the sentence about, which is clearly nonsense.

Indeed by 1, I mean 100% accuracy. my problem is DNA translation which could be considered as a machine translation problem and I'm using transformer model.
for the evaluation phas Im using following t2t-train command
t2t-trainer \  --t2t_usr_dir=$USR_DIR  --schedule=evaluate  --eval_run_autoregressive   --eval_steps=1   --data_dir=$DATA_DIR  --problems=$PROBLEM   --model=$MODEL   --hparams_set=$HPARAMS   --worker_gpu=2   --output_dir=$TRAIN_DIR   --train_steps=0
for the training-evaulation phase Im using following t2t-train command
t2t-trainer   --t2t_usr_dir=$USR_DIR   --eval_steps=50   --data_dir=$DATA_DIR   --problems=$PROBLEM   --model=$MODEL   --hparams_set=$HPARAMS   --worker_gpu=2   --output_dir=$TRAIN_DIR   --train_steps=200000

--eval_steps=1 means that just the first batch (32 "sentences" by default) will be used for the evaluation. This is probably not what you want and may explain the 100% accuracy. (BTW: I understand "1" means 100%, but in that case I was confused by "accuracy of 90".) The default eval_steps is 100. To evaluate on the whole dev/test set, you can set eval_steps arbitrarily high, which will produce a warning after the data is exhausted, but you can ignore the warning.
If you are still unsure whether the accuracy is 90% or 100%, just use t2t-decoder and compare the output with the reference yourself.

the problem was --eval_steps. I don't know why just put it 1 :). it is fixed now. tnx


[v1.1][T11-B1] TuitionConnect

@ChoChihTun @raymond511 @a-shakra @yungyung04
Reasonable attempts for component enhancements can be found in our team repo.
User stories can be found in our team repo's Project tab, User Stories.
A draft project document can be found in our Google doc.

It is noticed that some of the builds (including the build of this PR) failed the Travis CI due to checkstyle issues. Please try to ensure that each PR passes Travis before merging into master branch. This will help you isolate future broken commits.
The main reason for Travis failures is checkstyle issues. Thus please ensure that proper coding standards are adhered to.  IntelliJ can check the coding standard for you to see if you violate checkstyle in any way, refer to the course website to see how you can configure that.

@ChoChihTun @raymond511 @a-shakra @yungyung04
Looks good. Nice work. You may want to fix the broken pictures in the About Us.


Deploy to Heroku Error

I used the "Deploy to Heroku" button to try out the wagtaildemo but received this error:
Run scripts & scale dynos
There was an issue while running the post deploy script:

@klummy you are right, deploying to Heroku doesn't work :(
@kaedroho this is because there's a bunch of required mongo settings in settings/heroku.py (to store files). This section probably needs to be optional (if a MONGODB_NAME env var exists only then setup mongo).

Oops, I was messing around with storing files in MongoDB last night. I must've accidentally pushed.
Sorry about that, will rollback/

I've rollbacked all the mongodb stuff now. Kept the Heroku PR merged since I think it's in a good enough state to start using now anyway.

It is working now. Thanks Kaedroho.

Quick question, how do I create a superuser?

@klummy a superuser is created by default with the credentials admin / changeme (https://github.com/torchbox/wagtaildemo#installation)

Ok, thanks spapas


Exercise: Module 3, class 1 prep / Searching Algorithms

The third question in the quiz gives answers but not to the first part of the question. Not sure if this was done on purpose.  Also the given array has an even amount of numbers, the examples in Doug's Playlist and the Short have used an odd set of numbers.

Question 3:

Given the following array:

{4, 7, 13, 18, 21, 42}

carry out the process of using binary search for the number ’21'.  For each iteration of binary search, show:

which elements of the array are between the “start” and “end” elements

which element is the “middle” element; highlight it by putting it between square brackets (i.e., put it between [])
next to the final iteration, write “final iteration"

For example, let's say we did this question with the following array:

{-6, 0, 1, 2, 3, 15, 20}

searching for the number '0'.

A correct answer would look like this:

{-6, 0, 1, [2], 3, 15, 20}

{-6, [0], 1} final iteration

I think it's ok.
The first part is basically just saying that the set of numbers should shrink.
The even / odd difference shouldn't matter


Intermittent errors on pecl install

I have received errors multiple times when installing gRPC on travis CI. It is intermittent, maybe once every 20 installs or so. When I restart the builds, the error goes away. Sometimes it's this error:
$ pecl install grpc
Package "grpc" Version "1.3.2" does not have REST dependency information available

It happened for this build, which is PHP 7, but the error is gone because I restarted it.
I've also received this error:
$ pecl install grpc
Package "grpc" does not have REST info xml available

That happened for this build, and I will kick off a new build instead of restarting it so that we can keep the logs.

This appears to be intermittent issue on PECL side. I only found very old articles/bugs about this.

Closing this as this is a PECL availability issue.


[PAN-3051] Preimage key value can now be null.

PR description
Preimage key value can now be null when running debug_storageRangeAt
Fixed Issue(s)
PAN-3051

Changes are for debug_storageRangeAt - with the retesteth support we needed a preimage cache for this API and it was added.  Meredith also needed it for a tool she wrote as well, so there are two use cases for it.

LGTM, but I'll let Madeline git the approval since she has questions about retesteth CLI docs.


⚠ Empornium has degraded performance

In 55e8d06, Empornium ($EMP) experienced degraded performance:

HTTP code: 200
Response time: 1554 ms

Resolved: Empornium performance has improved in c756b2d.


invalid byte sequence in US-ASCII when adding SBConstants in run scrip

Hi there,
so generating the constants from the terminal works fine. However trying to run the same command from a run script added to the build phases gives me this ruby error which seems cryptic to me as I don't know anything about the language. Do you have an idea?
/Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:79:in `[]': invalid byte sequence in US-ASCII (ArgumentError)
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:79:in `block (3 levels) in parse_storyboards'
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:78:in `each'
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:78:in `block (2 levels) in parse_storyboards'
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:77:in `each'
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:77:in `each_with_index'
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:77:in `block in parse_storyboards'
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:69:in `each'
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:69:in `each_with_index'
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:69:in `parse_storyboards'
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:18:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/lib/sbconstants/cli.rb:8:in `run'
	from /Library/Ruby/Gems/2.0.0/gems/sbconstants-1.1.2/bin/sbconstants:5:in `<top (required)>'
	from /usr/local/bin/sbconstants:23:in `load'
	from /usr/local/bin/sbconstants:23:in `<main>'
Command /bin/sh failed with exit code 1

Hi @Broich, have you tried to add UTF8 to your config before to run script in build phase?
export LANG=en_US.UTF-8
export LANGUAGE=en_US.UTF-8
export LC_ALL=en_US.UTF-8

Also should be good to have #encoding: utf-8 at the top of sbconstants, what do you thing @paulsamuels  / @orta?


Improve test code

This PR now allows for local database tests to be configurable. Check the new constants in phpunit.xml.dist. Just copy it to phpunit.xml and adjust values to your local test environment.

Also makes more use of TestHelpers class to facilitate entity testing.

@akalongman @MBoretto @jacklul
Have you looked at this at all yet? Would like to merge before carrying on with implementations, as there are a lot of code changes.

Hello, just scroll fast so far, in the weekend  I plan some time to review them, but if you want go ahead merge!

I'll wait till the weekend, then either you merge or I'll merge next week 😊
Thanks!

Great work!


Refactored the indexing (projections) module

The refactor includes the following changes:

removed dependency on Monix, the code is now generic on F[_] types
collapsed ResumableProjection and IndexFailuresLog into a single Projections type
added ordering to "indexing" failures
implemented a custom SessionProvider to use a single Cassandra session
moved classes under a single package *.projections
renamed module stream to projections to better describe the function
removed dependency on shapeless
renamed several classes in the attempt to standardise on the name projections
upgraded akka-persistence-cassandra to 0.93
bumped dependencies
replaced the use of *> with >>

Codecov Report

Merging #30 into master will decrease coverage by 0.32%.
The diff coverage is 90.08%.

@@            Coverage Diff             @@
##           master      #30      +/-   ##
==========================================
- Coverage   92.43%   92.11%   -0.33%
==========================================
  Files          22       17       -5
  Lines         529      545      +16
  Branches       19       15       -4
==========================================
+ Hits          489      502      +13
- Misses         40       43       +3

Impacted Files
Coverage Δ

...ch/epfl/bluebrain/nexus/sourcing/retry/Retry.scala
100% <ø> (ø)
:arrow_up:

.../nexus/sourcing/projections/StreamSupervisor.scala
90% <100%> (ø)

.../nexus/sourcing/projections/ProjectionConfig.scala
87.09% <100%> (ø)

...bluebrain/nexus/sourcing/akka/AggregateActor.scala
100% <100%> (ø)
:arrow_up:

...xus/sourcing/projections/SameSessionProvider.scala
100% <100%> (ø)

...rain/nexus/sourcing/retry/syntax/RetrySyntax.scala
100% <100%> (ø)
:arrow_up:

...ain/nexus/sourcing/projections/TagProjection.scala
66.66% <66.66%> (ø)

...exus/sourcing/projections/ProjectionProgress.scala
90% <90%> (ø)

...brain/nexus/sourcing/projections/Projections.scala
93.44% <93.44%> (ø)

... and 2 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 2548aca...230b54d. Read the comment docs.


add support for PerformanceLongTaskTiming

Which browsers are supporting PerformanceLongTaskTiming ?
It would be great to add this to the browser matrix.
https://w3c.github.io/longtasks/#sec-PerformanceLongTaskTiming
Cheers,
Nathan

+1

Available via MDN now: https://caniuse.com/?search=PerformanceLongTaskTiming


[Qwen]Fix performance issue with dynamic causal mask

What does this PR do?

Fixes Qwen performance issue with dynamic causal mask generation
Before submitting

[ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
[ ] Did you make sure to update the documentation with your changes?
[ ] Did you write any new necessary tests?

@echarlaix  could you please take a look?

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

To fix the code style test you can do the following :
pip install .[quality]
make style


:robot: Add codetrack.vm

Automated PR from https://github.com/mandiant/VM-Packages/issues/363 :rocket:

Making a new request as it's easier than fixing this.


I can't find the results

steps to Reproduce:
1.(here is my fbcookie),type the following:
export FACEBOOK_COOKIE="datr=MxeTYYDWGsmV9ARPWSunVXgF; sb=rkDNXTi8IihoyW-M_C3DshIB; c_user=100029018674116; xs=46%3AQy-iCXDGPQ%3A2%3A1644807957%3A-1%3A3373%3A%3AAcWENdtfu4uRHutJ7ZBGeDjRWrgAyNvIRA0rr8Ir4jI; fr=0iCFrRQLqE2cYd7yp.AWWeIEbaCqNSw.Bjnybs.a9.AAA.0.0.BjrrB7.AWVT1tbE8_A; wd=1440x298; dpr=2; presence=C%7B%%22utc3%22%3A16723%22v%22%3A1%7D"
2.type the following:
google-search -s "site:10degres.net" -c "$FACEBOOK_COOKIE"
I can't see any results! I don't know why!!!

Same for me, doesn't work anymore, maybe Google/Facebook fixed this.


Priority senders

PR description
This PR is build on top of #5966 so please check it first. Relative diff
This PR expand the concept of priority of txs and senders. Currently in Besu by default every tx sent using the RPC API is called local, and local is also a synonym for priority, that means that the tx does not need to satisfy the min price option and it is selected first when building a block, the txs received via p2p are called remote and haven't any priority.
It is possible to disable this default behavior passing the option --tx-pool-disable-locals, and all txs are treated the same.
This simple approach does not works well if Besu is used as a gateway to publish txs for multiple senders, when the node owner what to prioritize only a subset of them, to support this use case, this PR add the --tx-pool-priority-senders option, with it is possible to specify the list of senders, whom txs have priority, regardless their origin, both local or remote.
Since local is not always synonym of priority, the concepts have been separated, and so a PendingTransaction has both attributes as distinct fields, where local is now only used to identify the source and priority is used to apply or not the min price option and during the selection when building a block. To note that txs with priority will be dropped from the pool after the other ones.
To follow the new semantic of --tx-pool-disable-locals has been deprecated for removal in favor of --tx-pool-no-local-priority
To resume the possibility of mixing the priority options are:

Default (no option specified): All txs sent via RPC API are prioritized
--tx-pool-no-local-priority=true: No tx is prioritized
--tx-pool-priority-senders=sender1,sender2: All txs sent via RPC API are prioritized + all txs sent by sender1 and sender2
--tx-pool-no-local-priority=true --tx-pool-priority-senders=sender1,sender2: Only txs sent by sender1 and sender2 are prioritized

No functional or performance regressions found during the test.
Comparison with prev release (A this PR, B current stable release)
Block Value

Txs

Gas used

Fixed Issue(s)
Partially fixes #5829

@fab-10 Do you know which release the deprecated --tx-pool-disable-locals option will likely be removed in? I suspect some permissioned-chain users will be using that option.

@matthew1001 removal date is not yet set, but the feature is not removed, only the option is renamed to -tx-pool-no-local-priority` to better reflect that we are talking about priority tx does not always match with local tx


Null values shown in 'detailed' context for json columns

When a json column has a null value, it is being shown in detailed context like the following:

To avoid showing this, a markdown pattern can be written but that prevents ermrestJS from wrapping the contents in <pre> tags making the json object get "pretty printed".
This is related to another issue (#1893) about show_null behavior in record app

I spent some time looking into this, and the following is the summary of what I found out:
ermrest

While creating data, we can send JSONB null or database null (sending null or not sending anything).

We can distinguish the two through ermrest API (=null for JSONB null and ::null:: for database null).

Record/Recordset
The JSON response from ermrest doesn't tell us whether it's database null or JSONB null. The only way that we could figure this out is by sending a separate request. In read-only mode showing empty is cleaner, so we should treat it as database null.
Recordedit

While you can write "null" or leave it empty in the form for JSONB columns, we're not treating these differently. Both are treated as if the value is missing (database null)

Which means the "default" logic would be used for them.

Chaise won't complain when you use null for required columns, but then since null and undefined are treated the same in ermrestjs, we're adding the column as one of the "defaults" so ermrest will eventually complain.

Currently, we're setting empty fields as null in chaise. But if we were to use undefined instead, ermrestjs could distinguish between the two.

During update, chaise will only update the values that have been "touched"; as long as the column has not been touched, the database value stays the same.
The change detection uses !=, which needs to be changed when we do the "null" vs. "undefined" change for JSONB columns.

So, if it were database null or JSONB null, it would stay the same. And you cannot change it to be the other one.

We discussed this, and the following is the summary of it:

[ ] We should stop treating json/jsonb columns differently in read-only modes. So, a null value should be treated like a database null, and therefore, we should honor the show_null annotation for it (instead of forcefully showing the null in a code block).

[ ] Related to recordedit, if it doesn't require a lot of changes, we should distinguish between writing "null" and leaving the input empty in json/jsonb columns. Writing "null" should save a null, and leaving the input empty should not send any values for it (similar to other inputs). While chaise won't show different values for these cases in record/recordset, we should ensure we're doing the right thing in recordedit.

P.S. We don't need to worry about the change detection I mentioned above for this issue. We should tackle that as part of this issue, and we most probably should use dirty/changed flags for that instead of doing the check in ermrestjs.


[FEATURE] F-14AB should have a PILOT and RIO Module Name depending on which seat you are currently occupying

Apologies if this is actually already a thing but i've been unable to find such on the documentation
Currently you can set up your bindings for either the Pilot or RIO seat, but not both. Making binding for users who usually RIO in MP much harder
{TXT:vaicompro.playerdata.currentmodule.name} should have the options:
"F-14AB" to maintain legacy support, independent of your current seat selection
"F-14AB PILOT" for the front seat
"F-14AB RIO" for the back seat, RIO seat should use Radio 1 and 5 in VAICOM with easy comms off, with Radio 1 servicing whichever radio is currently selected by the RIO's radio select switch in the cockpit.
Only apparent alternative is to go in and change bindings manually depending on what you're flying that day, with no ability to select the radio being used in cockpit

It seems like this should work for both multicrew RIO and a pilot switching to the back seat temporarily.

It seems like this should work for both multicrew RIO and a pilot switching to the back seat temporarily.

ideally yes


Etcd s3 config secret support

K3s tracking issue for distro-side implementation of

https://github.com/rancher/rancher/issues/44256

https://github.com/k3s-io/k3s/issues/10487#issuecomment-2249090321
will close when rke2 is closed


Unable to fetch Channel data

Description
I am able to create the Chat Client successfully. After doing this, i am trying to get the channels.
But i am not getting the channels instantly.
Also if i do get the channels, i am not getting the channel attributes.
If i wait for 5-10 seconds, then this data comes successfully.
I have tried to implement a ProgressDialog, but am not able to because the ChatClientListener methods do not get called.
onClientSynchronization() method never gets called.
How do i handle this?
Reproduces how Often
95%
Chat Android SDK
4.2.6
Android API
28
Android Device
LG G7 ThinQ+

Hi Any update on this ??

Hi!

Please clarify what do you mean not getting the channels instantly? Getting channels first time after creating a client required network request which takes some reasonable time.
not getting the channel attributes on time is known issue. Current ETA to deliver a fix is one month.
Please provide debug log with your case when onClientSynchronization() method never gets called. (Call ChatClient.setLogLevel(LogLevel.VERBOSE) before creating a client to enable logging)


mcpitanlibarch isn't marked as a dependency in fabric.mod.json

In case someone forgets to download the required file, the following NoClassDefFoundError appears:
java.lang.NoClassDefFoundError: ml/pkom/mcpitanlibarch/api/util/TextUtil
	at ml.pkom.advancedreborn.items.ConfigWrench.method_7851(ConfigWrench.java:89)
	at net.minecraft.class_1799.method_7950(class_1799.java:699)
	at net.minecraft.class_310.method_1591(class_310.java:816)

I'd be nice if the fabric.mod.json included mcpitanlibarch as a dependency so that FabricLoader gives a more descriptive issue rather than this crash which is unreadable by some users.
Thanks!

It's true, I just checked. Thank you for your report.


De-incubate more APIs

This PR builds on top of  #15814 to avoid merge conflicts and de-incubates more execution team APIs.
Closes #15557
Closes #15558
Closes #15559

@bot-gradle test this

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

@bot-gradle test this

OK, I've already cancelled the old build and triggered a new ReadyForMerge build for you.

OK, I've already cancelled the old build and triggered a new ReadyForMerge build for you.

@bot-gradle test this

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test this

@bot-gradle test this

OK, I've already triggered ReadyForMerge build for you.

OK, I've already triggered ReadyForMerge build for you.