Batch Edit: Setting embargo and lease does not work

When I got to my works listing
And I choose Multiple works
and I click Edit Selected
And I click on the collaborators tab
And I choose embargo
And I choose a date in the future
And I click Save Changes
Then the form should not hang forever (It should set the works to embargo)
Same scenario for embargo

Verified that this was an issue in production by running an edit on stage.

Here is the stack trace from the server
Rendering 500 page due to exception: #<ArgumentError: Invalid visibility: "embargo"> - ["/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/hydra-access-controls-10.5.0/app/models/concerns/hydra/access_controls/visibility.rb:16:in `visibility='", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/hydra-access-controls-10.5.0/app/models/concerns/hydra/access_controls/embargoable.rb:66:in `visibility='", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/active-fedora-11.1.6/lib/active_fedora/attribute_assignment.rb:51:in `public_send'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/active-fedora-11.1.6/lib/active_fedora/attribute_assignment.rb:51:in `_assign_attribute'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/active-fedora-11.1.6/lib/active_fedora/attribute_assignment.rb:45:in `block in _assign_attributes'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_controller/metal/strong_parameters.rb:185:in `each_pair'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_controller/metal/strong_parameters.rb:185:in `each_pair'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/active-fedora-11.1.6/lib/active_fedora/attribute_assignment.rb:44:in `_assign_attributes'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/active-fedora-11.1.6/lib/active_fedora/attribute_assignment.rb:38:in `assign_attributes'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/active-fedora-11.1.6/lib/active_fedora/attribute_assignment.rb:9:in `attributes='", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/active-fedora-11.1.6/lib/active_fedora/attributes/serializers.rb:24:in `attributes='", "/opt/heracles/deploy/scholarsphere/releases/20171115235014/app/controllers/batch_edits_controller.rb:29:in `update_document'", "/opt/heracles/deploy/scholarsphere/releases/20171115235014/app/controllers/batch_edits_controller.rb:17:in `block in update'", "/opt/heracles/deploy/scholarsphere/releases/20171115235014/app/controllers/batch_edits_controller.rb:17:in `map'", "/opt/heracles/deploy/scholarsphere/releases/20171115235014/app/controllers/batch_edits_controller.rb:17:in `update'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_controller/metal/implicit_render.rb:4:in `send_action'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/abstract_controller/base.rb:198:in `process_action'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_controller/metal/rendering.rb:10:in `process_action'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/abstract_controller/callbacks.rb:20:in `block in process_action'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:117:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:555:in `block (2 levels) in compile'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:505:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:92:in `__run_callbacks__'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:778:in `_run_process_action_callbacks'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:81:in `run_callbacks'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/abstract_controller/callbacks.rb:19:in `process_action'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_controller/metal/rescue.rb:29:in `process_action'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_controller/metal/instrumentation.rb:32:in `block in process_action'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/notifications.rb:164:in `block in instrument'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/notifications/instrumenter.rb:20:in `instrument'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/notifications.rb:164:in `instrument'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_controller/metal/instrumentation.rb:30:in `process_action'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_controller/metal/params_wrapper.rb:250:in `process_action'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/railties/controller_runtime.rb:18:in `process_action'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/abstract_controller/base.rb:137:in `process'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionview-<IP_ADDRESS>/lib/action_view/rendering.rb:30:in `process'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_controller/metal.rb:196:in `dispatch'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_controller/metal/rack_delegation.rb:13:in `dispatch'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_controller/metal.rb:237:in `block in action'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/routing/route_set.rb:74:in `dispatch'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/routing/route_set.rb:43:in `serve'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/journey/router.rb:43:in `block in serve'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/journey/router.rb:30:in `each'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/journey/router.rb:30:in `serve'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/routing/route_set.rb:817:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/rack/agent_hooks.rb:30:in `traced_call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/rack/browser_monitoring.rb:32:in `traced_call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/rack-maintenance-2.0.1/lib/rack/maintenance.rb:19:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/warden-1.2.6/lib/warden/manager.rb:35:in `block in call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/warden-1.2.6/lib/warden/manager.rb:34:in `catch'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/warden-1.2.6/lib/warden/manager.rb:34:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/rack-1.6.8/lib/rack/etag.rb:24:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/rack-1.6.8/lib/rack/conditionalget.rb:38:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/rack-1.6.8/lib/rack/head.rb:13:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/params_parser.rb:27:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/flash.rb:260:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/rack-1.6.8/lib/rack/session/abstract/id.rb:225:in `context'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/rack-1.6.8/lib/rack/session/abstract/id.rb:220:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/cookies.rb:560:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/query_cache.rb:36:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activerecord-<IP_ADDRESS>/lib/active_record/connection_adapters/abstract/connection_pool.rb:653:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/active-fedora-11.1.6/lib/active_fedora/ldp_cache.rb:26:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/flipflop-2.3.1/lib/flipflop/feature_cache.rb:12:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/callbacks.rb:29:in `block in call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:88:in `__run_callbacks__'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:778:in `_run_call_callbacks'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/callbacks.rb:81:in `run_callbacks'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/callbacks.rb:27:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/remote_ip.rb:78:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/debug_exceptions.rb:17:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/show_exceptions.rb:30:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/railties-<IP_ADDRESS>/lib/rails/rack/logger.rb:38:in `call_app'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/railties-<IP_ADDRESS>/lib/rails/rack/logger.rb:20:in `block in call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/tagged_logging.rb:68:in `block in tagged'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/tagged_logging.rb:26:in `tagged'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/tagged_logging.rb:68:in `tagged'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/railties-<IP_ADDRESS>/lib/rails/rack/logger.rb:20:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/request_id.rb:21:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/rack-1.6.8/lib/rack/methodoverride.rb:22:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/rack-1.6.8/lib/rack/runtime.rb:18:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/activesupport-<IP_ADDRESS>/lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/rack-1.6.8/lib/rack/sendfile.rb:113:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/actionpack-<IP_ADDRESS>/lib/action_dispatch/middleware/ssl.rb:24:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/railties-<IP_ADDRESS>/lib/rails/engine.rb:518:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/railties-<IP_ADDRESS>/lib/rails/application.rb:165:in `call'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/railties-<IP_ADDRESS>/lib/rails/railtie.rb:194:in `public_send'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/railties-<IP_ADDRESS>/lib/rails/railtie.rb:194:in `method_missing'", "/opt/heracles/deploy/scholarsphere/shared/bundle/ruby/2.3.0/gems/newrelic_rpm-<IP_ADDRESS>6/lib/new_relic/agent/instrumentation/middleware_tracing.rb:96:in `call'", "/usr/share/ruby/vendor_ruby/phusion_passenger/rack/thread_handler_extension.rb:81:in `block in process_request'", "/usr/share/ruby/vendor_ruby/phusion_passenger/rack/thread_handler_extension.rb:367:in `maybe_tag_logger'", "/usr/share/ruby/vendor_ruby/phusion_passenger/rack/thread_handler_extension.rb:81:in `process_request'", "/usr/share/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:145:in `accept_and_process_next_request'", "/usr/share/ruby/vendor_ruby/phusion_passenger/request_handler/thread_handler.rb:98:in `main_loop'", "/usr/share/ruby/vendor_ruby/phusion_passenger/request_handler.rb:440:in `block (3 levels) in start_threads'", "/usr/share/ruby/vendor_ruby/phusion_passenger/utils.rb:97:in `block in create_thread_and_abort_on_exception'"]


add no_checks for sub dataset in lvwerra/stack-exchange-paired since …

…it does not contain test split
What does this PR do?

Fixes # (issue)
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?

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.

load dataset error if datasets >= 2.19.0.
error is like

occurred after https://github.com/huggingface/datasets/pull/6714 is merged.

@sywangyi Could you try with the latest release of Datasets (v2.19.2) please? It should solve this issue.

yes. works in 2.19.2

yes. works in 2.19.2

Great! Could you remove verification_mode="no_checks" from the examples (dpo.py too) and set the requirements datasets==2.19.2 in requirements.txt please?

ok, I will do it


Demo8 extremes update

Reduced number of lines (in cell [3])
Clean up notebook
Result from latest rerun

@acordonez Thank you for resolving the issues for the extreme PR. I was able to make Demo8 notebook run it through.
I opened this PR for a few edits in the Demo8 notebook and also for some questions.

Compared to the original notebook, I see the numbers in JSON are slightly different, and the plot colorbar range is different (in the original 0 to 20, while in my notebook, 0 to 30). Do you consider they are close enough?

There are a lot of warning messages, curious if there is a way to reduce or mute them if they are not critical.

@acordonez Thank you for resolving the issues for the extreme PR. I was able to make Demo8 notebook run it through.
I opened this PR for a few edits in the Demo8 notebook and also for some questions.
1. Compared to the [original notebook](https://github.com/PCMDI/pcmdi_metrics/blob/534_ao_extremes/doc/jupyter/Demo/Demo_8_extremes.ipynb), I see the numbers in JSON are slightly different, and the plot colorbar range is different (in the original 0 to 20, while in my notebook, 0 to 30). Do you consider they are close enough?

2. There are a lot of warning messages, curious if there is a way to reduce or mute them if they are not critical.

Regarding 1., the figure looks pretty similar to me once you account for the change in the colorbar. Unfortunately I don't think the various fits and solvers used to get the return values are guaranteed to produce stable results, but I'll look into this some more.

@acordonez Thank you for resolving the issues for the extreme PR. I was able to make Demo8 notebook run it through.
I opened this PR for a few edits in the Demo8 notebook and also for some questions.
1. Compared to the [original notebook](https://github.com/PCMDI/pcmdi_metrics/blob/534_ao_extremes/doc/jupyter/Demo/Demo_8_extremes.ipynb), I see the numbers in JSON are slightly different, and the plot colorbar range is different (in the original 0 to 20, while in my notebook, 0 to 30). Do you consider they are close enough?

2. There are a lot of warning messages, curious if there is a way to reduce or mute them if they are not critical.

Regarding 2., I've tried a couple of ways to suppress warnings in the Jupyter notebook but have not been successful. I've tried the warnings module and the %%capture cell magic, but in both cases I still see all the warnings.
Warnings:

%%capture:

I'm reluctant to turn off all the warnings within the driver itself, as they are flagging real instances where the GEV fit is failing for one reason or another. Do you have any other suggestions?

Regarding Q2, I've also tried redirecting output to a text file, but still get the warnings live:

Here's the return value results I got for the first test run in the Demo, and I'm getting slightly different results from you and from my original run - not much matches after the decimal point. It wasn't unusual for me to get different results when I was testing the code on single timeseries, so I'm not surprised.
{
  "GISS-E2-H": {
    "r6i1p1": {
      "Rx1day": {
        "land": {
          "mean": {
            "ANN": 13.624667116247734,
            "DJF": 9.135238348527835,
            "JJA": 9.695412307925825,
            "MAM": 9.4947603968054,
            "SON": 10.085489430018676
          },
          "std_xy": {
            "ANN": 5.84894894720064,
            "DJF": 6.01362496906134,
            "JJA": 5.727293357791019,
            "MAM": 5.823173294700789,
            "SON": 4.879856373306809
          }
        }
      },
      "Rx5day": {
        "land": {
          "mean": {
            "ANN": 8.612030197868712,
            "DJF": 5.639787497943132,
            "JJA": 6.327905351825952,
            "MAM": 5.881106639945075,
            "SON": 6.422801996975585
          },
          "std_xy": {
            "ANN": 4.350543642971108,
            "DJF": 4.133318652361083,
            "JJA": 4.293765096254575,
            "MAM": 3.970500853809765,
            "SON": 3.6944120761563717
          }
        }
      }
    }
  }
}

@acordonez thank you for the comments. I think we can be confident merging this if differences are only at decimal point level.


how to add newline in message

Produce Steps
1.add this to yml
    - name: notify message while success
      uses: louis70109/line-notify-action@master
      if : steps.buildAction.outcome == 'success'
      with:
        token: ${{ secrets.LINE_NOTIFY_TOKEN }}
        message: '\n WorkSpaceName:${{ val1 }} \n Version:${{val2 }} \n Message:Github build success'

2.The Result :

Except Result :
'\n' cant create newline in line app ?
[BotName]
WorkSpaceName:SCHOOL.Works
Version:513.0.0
Message:
Github get an error while building stage

@ChangYinShung could you try following?
- name: send message with image url
  uses: louis70109/line-notify-action@master
  with:
    token: ${{ secrets.LINE_NOTIFY_TOKEN }}
    message: |
      Hello World....
      This is new line for Notify.

@louis70109
It works,thanks.
sorry for later response.


Fix for IOS applications that available in specific country

Fixes # .
If an IOS app is available only in specific country,  IsLatestVersion function throw an exception, and there are no ability specify an IOS app country's alpha 2 code for correct work of that function.
Changes proposed in this pull request:

Addressed in #32 - Added as a property to ILatestVersion instead of the CrossLatestVersion class.


Package_Indexing -[Sys.Root]

@martin-gir great job!
signing_off
rizwan-r-r

Sorry, I currentlly don't understand the purpose of your contribution. How do I test that?
Thanks a lot and cheers!


Parse5 'endTagInBody' causes stack overflow when loading certain documents

Possible to upgrade to a later version of Parse5? I see this is using an older version.

Hi @wchaering,
Can you provide markup that causes the error?

Thanks for replying so quickly @inikulin ! Absolutely--here is the document I am loading: https://www.thoughtco.com/supercomputers-tech-weather-forecasting-tools-4120844
My configuration object, in case it's helpful:
{
  url: 'https://www.thoughtco.com/supercomputers-tech-weather-forecasting-tools-4120844',
  scripts: ["https://code.jquery.com/jquery-3.1.1.slim.min.js"],
  headers: {
    Accept: 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8',
  }
}

Also the error:
RangeError: Maximum call stack size exceeded
    at genericEndTagInBody (/Users/wchaering/Code/scraping-test/node_modules/parse5/lib/tree_construction/parser.js:1887:29)
at Object.endTagInBody [as END_TAG_TOKEN] (/Users/wchaering/Code/scraping-test/node_modules/parse5/lib/tree_construction/parser.js:2002:17)
    at Parser._processToken (/Users/wchaering/Code/scraping-test/node_modules/parse5/lib/tree_construction/parser.js:619:38)
at parser._processToken (/Users/wchaering/Code/scraping-test/node_modules/parse5/lib/tree_construction/location_info_mixin.js:89:35)
    at Parser._processFakeEndTag (/Users/wchaering/Code/scraping-test/node_modules/parse5/lib/tree_construction/parser.js:663:10)
    at buttonStartTagInBody (/Users/wchaering/Code/scraping-test/node_modules/parse5/lib/tree_construction/parser.js:1351:11)
...
^ 'at buttonStartTagInBody' line repeats

I confirm that it was a long time ago in parse5 via https://github.com/inikulin/parse5/commit/15e0321f3533c3dfac3eeae3b9c4e21cfef1c6a9


Unable to send email feedback

From itc:

app works flawlessly when you don't receive any feedback amrite


SCRIPT ERROR: @illenium-appearance/server/database/playerskins.lua:12: illenium-appearance was unable to execute a query!

hi i had a problem after a database was removed due to error since then we have had bug after bug to fix now we have this issue and people are loading in as random peds after making there charecter

also tryed to join the discord first but the captcha has a error

the error only comes up after trying to change cloths

same as when u try to  use admin menu in any way to save ped

Read the docs again. You have not followed them correctly. Reapply SQL as mentioned in the docs


Added the Hawkeye Gyro Fan Rotor code

Please put all commits into a single branch and PR that branch


Design Idea: Collapsible Model Parameter Forms

Some of the models have a LOT of parameters, including some of the default models (eg. Tinker for the HMF). This makes the vertical spacing quite long, and makes it easy to miss some of the inputs. One way around this might be to have the model parameter sections, that appear on the right of the model choices, as collapsible. Not sure if this is easy or hard. If easy, I'd say it's worth it.
At the moment, at the very least, the mass range and mass resolution are very easy to miss (being after all the Tinker parameters), and should be fixed. One way would be just to bring them to the top of the HMF section (so, above the choice for Tinker). Another would be to bring all the "resolution" kinds of parameters -- so lnk-range, mass-range, resolution, scale range, etc., into one section called "Ranges", which should be towards the top.

@steven-murray was this still wanted? Please see this deploy for a possible implementation. It can be reverted though.

Hmmmm. I almost like it. It has a few things that are not ideal -- like when there are no parameters, it still shows the grey horizontal separator. I feel like it should maybe only collapse if there are more than say 3 parameters? Not sure if this is possible. Also, I think I like having the parameters show to the right of the main dropdown for each model (then again, not sure this'd work with the collapsing). The reason for this is that in the future I'd like to stick a Latex equation below each model, which would fit neatly to the left of the parameter list (if there is one).
Thoughts?

@steven-murray alright! Those ideas were implemented. Check out the deploy here, or the screenshots below:

Truly spectacular!


Minimal working example

I'm looking into tuf/rust-tuf for some update procedures.
For now I'm failing to create a minimal working example and I'm not sure if it's just me or if there is a bug in the documentation that needs fixing. rust-tuf's src/lib.rs contains an example with a function get_original_root() that simply is unimplemented!(). I'm trying to fill the gap here.
First, I have followed the TUF documentation to generate a directory structure to be served according to the documentation in https://github.com/theupdateframework/tuf/blob/develop/tuf/README.md. In a nutshell, the steps are:

Generate RSA keys (root, targets, snapshot, timestamp);
Create repository metadata;
Create the actual repository.

Step 1. is trivial, simply calling tuf.repository_tool.generate_and_write_rsa_keypair() for each key. Step 2. uses create_new_repository() and adds the keys to the repo. Step 3. walks the repository directory and signs files using add_targets().
The problem I am facing comes from the call to rust-tuf's tuf::interchange::JsonDataInterchange::from_reader(). Since the get_original_root() function in unimplemented!(), I had to adapt it. It's returning a File, so I let it return File::open("repository/metadata/root.json").unwrap() where the json file was created by step 3 above.  The from_reader() call fails though with a deserialization error:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Encoding("JSON: ErrorImpl { code: Message(\"missing field `key_id`\"), line: 7, column: 3 }")', src/libcore/result.rs:859

I checked the files generated by tuf.repository_tool, and none contains the string key_id. The rust-tuf struct Signature seems to have one such field and is Deserialize so maybe this is where the error comes from?
I might be loading the improper file in tuf::interchange::JsonDataInterchange::from_reader(), but then there is no file that contains the key_id field in tuf's generated files. Am I following the proper guide to initialize a repository (https://github.com/theupdateframework/tuf/blob/develop/tuf/README.md)?
Note that I'm using rust-tuf c3321bf1295be66df46dcfb0440df491f2cf583f (branch develop) and tuf 904fa9b8df8ab8c632a210a2b05fd741e366788a (branch develop).
Thanks!

Hi hi @nbigaouette-eai.
The first problem with that minimal working example is that rust-tuf can't properly sign things yet. :)
Once that's done, I can clean up the lib.rs documentation to be a bit more clear. There's really two halves of this: making a root if you're doing the server side, and fetching a root if you're doing the client. This was meant to show the basic client update flow.
I'd also not use this against Python example. If you dig through the issues regarding the development of the spec, you'll see that the spec is overly restrictive on field names, formats, and other things not directly related to the security model. This will be changing to specify more the what than the how.
E.g., https://github.com/theupdateframework/tuf/issues/457
Also, Uptane, a TUF extension, only defines suggested ASN.1 modules for the metadata with the assumption that you'd implemented it how you want.
So as a result, I have taken some liberties with the data format like renaming the field _type to type because that extra underscore is an artifact of it being a common function in Python (or I suppose that's why they chose that name). Also, I used snake case eveywhere for consistency, so key_id replaces Python's keyid.
I will keep this issue open until I can get the docs more up to date with a full cycle of creating metadata, storing it, fetching, verifying, downloading, yada yada.

I have slightly updated the docs to use the library as it's intended in e8da3ea. This still only addresses the client side.

Great thanks for the hints. I'll continue my investigation.
Note that the example unfortunately does not run, probably due to
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Opaque("Hyper: Io(Error { repr: Custom(Custom { kind: InvalidInput, error: StringError(\"Invalid scheme for Http\") }) })")', src/libcore/result.rs:859

I had to add a TLS implementation (hyper-native-tls = "0.2") and using this:
extern crate hyper_native_tls;
...
    let ssl = hyper_native_tls::NativeTlsClient::new().unwrap();
    let connector = hyper::net::HttpsConnector::new(ssl);

    let mut remote = HttpRepository::new(
        Url::parse("https://static.rust-lang.org/").unwrap(),
        HttpClient::with_connector(connector),
        Some("rustup/1.4.0".into()));
...

I still get a panic, but at least it's further down the road:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NotFound', src/libcore/result.rs:859

Ah, well that would be because there is no https://static.rust-lang.org/root.json yet. I guess I should have put in something like example.com. Ha! You'll have to self host for a bit. Getting that up on to static.rust-lang.org is probably a couple of months out. I'm only doing the rust/rustup/tuf stuff in my spare time.

Also the line Some("rustup/1.4.0".into()) is a prefix for the HTTP User-Agent header. You should put something like Someformat!("my_app/{}", env!("CARGO_PACKAGE_VERSION"))). This generates a User-Agent string like my_app/1.2.3 (rust-tuf/0.2.0).

About the root.json: makes sense that it's not implemented yet for the official repo ;) I do plan to self host; it is meant for an internal tool.
Thanks about the info about the header, I'll adapt it for my use case.
When you say that rust-tuf can't sign yet, do you mean that it cannot be used to create the metadata for a repository or that it cannot be used to validate some downloads? I don't mind using the Python reference implementation to manage the repository for now, but I would like to deploy an updater in Rust... Having a full blown Rust implementation would obviously be a total win ;)
Regarding the field names, I still cannot Deserialize the root.json created by the (Python) tuf (v0.10.0-660-g904fa9b on branch develop). As you mentioned, some fields have a different name than what is present in the rust structs. I guess upstream is still not decided on the exact format, am I right? As such, could rust-tuf tell serde to rename the fields? That way the json can at least be attempted to be deserialized...
Here's a simple patch doing so:
diff --git a/src/crypto.rs b/src/crypto.rs
index 5ac145d..f2132c3 100644
--- a/src/crypto.rs
+++ b/src/crypto.rs
@@ -463,8 +463,11 @@ pub enum KeyFormat {
 /// A structure that contains a `Signature` and associated data for verifying it.
 #[derive(Debug, Serialize, Deserialize)]
 pub struct Signature {
+    #[serde(rename="keyid")]
     key_id: KeyId,
+    #[serde(rename="method")]
     scheme: SignatureScheme,
+    #[serde(rename="sig")]
     signature: SignatureValue,
 }

diff --git a/src/metadata.rs b/src/metadata.rs
index ffc1c62..3cbd384 100644
--- a/src/metadata.rs
+++ b/src/metadata.rs
@@ -236,8 +236,11 @@ where
 {
     signatures: Vec<Signature>,
     signed: D::RawData,
+    #[serde(skip_deserializing)]
     _interchage: PhantomData<D>,
+    #[serde(skip_deserializing)]
     _metadata: PhantomData<M>,
+    #[serde(skip_deserializing)]
     _verification: PhantomData<V>,
 }

Note that this also skip deserialization for the phantom data which should not appear in the (compiled) struct and/or the json file (it's some phantom data after all! ;) ).
Also, is there a reason why SignatureSheme uses FromStr trait instead of Deserialize from serde? I had to tell its from_str() method to accept the value found in root.json:
diff --git a/src/crypto.rs b/src/crypto.rs
index 5ac145d..b1fc4e6 100644
--- a/src/crypto.rs
+++ b/src/crypto.rs
@@ -128,6 +128,7 @@ impl FromStr for SignatureScheme {
     fn from_str(s: &str) -> ::std::result::Result<Self, Self::Err> {
         match s {
             "ed25519" => Ok(SignatureScheme::Ed25519),
+            "RSASSA-PSS" => Ok(SignatureScheme::RsaSsaPssSha512),
             "rsassa-pss-sha256" => Ok(SignatureScheme::RsaSsaPssSha256),
             "rsassa-pss-sha512" => Ok(SignatureScheme::RsaSsaPssSha512),
             typ => Err(Error::Encoding(typ.into())),

I'm definitely not sure this is valid, but at least the execution can continue ;)
After those modifications, the example continues, but still fail at the line:
let tuf = Tuf::<JsonDataInterchange>::from_root_pinned(root, &key_ids).unwrap();

with the error:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Encoding("JSON: ErrorImpl { code: Message(\"missing field `type`\"), line: 0, column: 0 }")', src/libcore/result.rs:859

When you say that rust-tuf can't sign yet

There's a Signer struct, but some of the ser/de operations on public keys is borked at the moment. DER problems, I think.

I guess upstream is still not decided on the exact format, am I right?

Not quite. Because as the spec says, TUF is not a universal update. There isn't any assumption that two TUF implementation need to be able to talk coherently with each other, especially since they are removing the restriction that the data interchange format is JSON.

Note that this also skip deserialization for the phantom data which should not appear in the (compiled) struct and/or the json file (it's some phantom data after all! ;) ).

I haven't written tests for the ser/de functions either, but I think some of that was covered in shims.rs. If it wasn't, can you open another ticket for that issue specifically so I don't forget?

Also, is there a reason why SignatureSheme uses FromStr trait instead of Deserialize from serde?

SignatureScheme implements both Serialize and Deserialize, and it uses ToString and FromString to perform them.

       "RSASSA-PSS" => Ok(SignatureScheme::RsaSsaPssSha512),

I'm pretty sure the Python implementation does RSASSA-PSS over SHA256, not SHA512.

Message("missing field type")

This is because you need to do a #[serde(rename = "_type")] on the fields typ in the signed portion of the metadata. That also might be keytype too, which I just called type because it's obviously a key.

There's another problem too. The Python implementation calculates key IDs as sha256(canonical_json(json_string)) and I do sha256(spki_convert(der_bytes)), so you'd have to disable the checks on key ID too.
With the amount of drift you'd have to do to get rust-tuf to work with the Python reference implementation, it'd probably be better for you to write some test cases that address the issues you've found and maybe even try to fix some of the bugs.

@nbigaouette-eai just letting you know that signing and verifying seems to be working on my small number of test cases. If you find any issues while playing around with this, please file issues. :)

There's a Signer...
I couldn't find it... at least in the develop branch.

[...] TUF is not a universal updater,
Not sure what you meant, so had to dig it up a bit. Here's the link
to section
1.4. Non-goals
of the specs. I believe this means that TUF is not meant to be the "updater" of
the system but rather just a way to validate the software, which I think if
just fine. I can write my own updater but I want to use TUF to validate the
trust chain.

[...] there isn't any assumption that two TUF implementation need to be able to talk coherently with each other, especially since they are removing the restriction that the data interchange format is JSON.
Wait... what?! That's sad! I would have though the specs would define the file
formats properly so that implementations could talk to each other... So while
the reference implementation is in Python, I can use a great Rust
implementation in my project! ;) After having listened to Justin Cappos's
interview on PODCAST.INIT  I though it was great that their was already multiple implementations...

So if they can't all talk to each other, I guess the same lib should be used
for both the repository signing and the download validation by the client,
right?

[...] but I think some of that was covered in shims.rs.
That file
doesn't contain any test...

[...] can you open another ticket for that issue specifically so I don't forget?
I can open an issue for missing tests on Serialize/Deserialize traits if you
want... Let me know if that is not what you meant before I start opening useless
issues ;)

SignatureScheme implements both Serialize and Deserialize, and it uses ToString and FromString to perform them.

I've opened #102 regarding this.
I'll see what could be done about the serde rename attributes. I have a couple
here that might be required. But before submitting them, I want to have basic
functionality so I know what I'm doing is not total crap!
Because the Python reference implementation's documentation is kind of hard to
follow, I've tried the go one. Its
simple example is a lot simpler
than the Python one.
With go-tuf, the root.json looks like this:
{"signed":{"_type":"Root","consistent_snapshot":true,"expires":"2018-07-05T20:24:43Z","keys":{"6551df4f3837b9312e88c459b1e77d40398509ba7d214253f92a4e17eb947c27":{"keytype":"ed25519","keyval":{"public":"c0cfa553f2bf974496c73deab2a5a5ad428c52c4b3534b915c8a336a4b3f4bfc"}},"72558c26bbbd89610b8a3dc15a3aee10f10b370df723bc7752b9760ec8d8e90c":{"keytype":"ed25519","keyval":{"public":"257245370ba831440eeabb7db253d2afa440e8cacb2a251ca304b5e601fd9d7d"}},"96fd5e97b0a2f912b4b8b78c3da45c98af5e2458d92db1429af6b697a745648e":{"keytype":"ed25519","keyval":{"public":"97a0f2df25914cba22d5ff70ff4cfc27ef934121f3c1ce8ca153f2cd6c4aa225"}},"c3b9005a53967778fc6a4a24bac23f87333799ab07b7a9e75f8008fd5fda7f15":{"keytype":"ed25519","keyval":{"public":"14dce612e576edc41e50d4db99f52c4b2b843c1daf797d602b6b65c1e41906e0"}}},"roles":{"root":{"keyids":["6551df4f3837b9312e88c459b1e77d40398509ba7d214253f92a4e17eb947c27"],"threshold":1},"snapshot":{"keyids":["96fd5e97b0a2f912b4b8b78c3da45c98af5e2458d92db1429af6b697a745648e"],"threshold":1},"targets":{"keyids":["72558c26bbbd89610b8a3dc15a3aee10f10b370df723bc7752b9760ec8d8e90c"],"threshold":1},"timestamp":{"keyids":["c3b9005a53967778fc6a4a24bac23f87333799ab07b7a9e75f8008fd5fda7f15"],"threshold":1}},"version":4},"signatures":[{"keyid":"6551df4f3837b9312e88c459b1e77d40398509ba7d214253f92a4e17eb947c27","method":"ed25519","sig":"64873aad168bcb63047487ec1e58130a70cd56c05b478695f72f421491d83ca8bd2f50060b43c19b0c475c9bd22569ddc6580d816ee5318a668be28368f63805"}]}

I still get an error with rust-tuf:
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Encoding("JSON: ErrorImpl { code: Message(\"invalid type: map, expected a string\"), line: 0, column: 0 }")', src/libcore/result.rs:859

when calling this line:
let tuf = Tuf::<JsonDataInterchange>::from_root_pinned(root, &key_ids).unwrap();

I wish I could have a minimal working rust code to boostrap the process... :S

signing and verifying seems to be working on my small number of test cases.
That's great! So does that mean that at some point the repository files could
be signed using rust-tuf to create all the metadata and that a rust client
updater could be used to download the updates and validate them using rust-tuf?

I couldn't find it... at least in the develop branch.

Yeah, totally forgot I pulled that out in the rebase. Rushed post. Look at metadata::SignedMetadata::new and crypto::PrivateKey.

Wait... what?! That's sad!

Yes and no. At my work we're trying to switch this to DER because embedded devices can't handle the JSON as easily. Every byte counts, and DER ends up being smaller. This is also a framework which means it can be used flexibly. Even with something much more tightly spec'd, a modern webserver can't talk to an old phone, etc.
I you dislike this, you could open an upstream issue.

So if they can't all talk to each other, I guess the same lib should be used for both the repository signing and the download validation by the client, right?

Yes. That was the intention with this. Both halves would use this lib.

That file doesn't contain any test...

I mean covered as is implemented. Ser/de tests are coming with ticket #100.

I still get an error with rust-tuf:

I think that might be the public key. Python (and presumably Go) store keys like:
{
   "keytype": "ed25519 | rsa",
   "keyval": {
    "public": "hex public point | PEM encoded DER key (PKCS#1 or SPKI)"
  }
}

I store it something like this (but it's not finalized yet):
{
  "type": "ed25519 | rsa",
  "value": "PEM encded DER SPKI"
}

The only reason i include the type field (which is redundant with the DER OID) and not just using a s JSON string only is to support this future addition to TUF: https://github.com/theupdateframework/taps/issues/38

I wish I could have a minimal working rust code to boostrap the process... :S

Yeah, yeah. I'm working on it. :)

So does that mean that at some point the repository files could be signed using rust-tuf to create all the metadata and that a rust client updater could be used to download the updates and validate them using rust-tuf?

Yes. That is exactly the idea.

I couldn't find it... at least in the develop branch.

Yeah, totally forgot I pulled that out in the rebase. Rushed post. Look at metadata::SignedMetadata::new and crypto::PrivateKey.

Wait... what?! That's sad!

Yes and no. At my work we're trying to switch this to DER because embedded devices can't handle the JSON as easily. Every byte counts, and DER ends up being smaller. This is also a framework which means it can be used flexibly. Even with something much more tightly spec'd, a modern webserver can't talk to an old phone, etc.
I you dislike this, you could open an upstream issue.

So if they can't all talk to each other, I guess the same lib should be used for both the repository signing and the download validation by the client, right?

Yes. That was the intention with this. Both halves would use this lib.

That file doesn't contain any test...

I mean covered as is implemented. Ser/de tests are coming with ticket #100.

I still get an error with rust-tuf:

I think that might be the public key. Python (and presumably Go) store keys like:
{
   "keytype": "ed25519 | rsa",
   "keyval": {
    "public": "hex public point | PEM encoded DER key (PKCS#1 or SPKI)"
  }
}

I store it something like this (but it's not finalized yet):
{
  "type": "ed25519 | rsa",
  "value": "PEM encded DER SPKI"
}

The only reason i include the type field (which is redundant with the DER OID) and not just using a s JSON string only is to support this future addition to TUF: https://github.com/theupdateframework/taps/issues/38

I wish I could have a minimal working rust code to boostrap the process... :S

Yeah, yeah. I'm working on it. :)

So does that mean that at some point the repository files could be signed using rust-tuf to create all the metadata and that a rust client updater could be used to download the updates and validate them using rust-tuf?

Yes. That is exactly the idea.


QASYMM_SIGNED support for NEDeconvolutionlayer in 20.02.1

Hi,
we are trying to support the quantized deconv layer for inference . Version 20.02.1 seems does not support qasymm8_signed for deconv. Could you confirm on this.
The same is supported in 20.05.Hence wanted to confirm if  this was added as part of 20.05.
Thanks in advance,
Praveen.

Hi @uu-praveeng ,
Yes, QASYMM8_SIGNED in NEDeconvolutionLayer is supported since v20.05.
Thanks,
Michele

Thanks @mdigiorgio


title.collides is not needed for physics collision

line 1924:
                    if (tile && tile.collides)
should be:
                   if (tile)
Recent versions of tiled and recent version of Phaser doesn't add a collides true property to the title, unless you call setCollisionBetween or setCollisionByExclusion beforehand.
And for this plugin, you only need to do:
var map = game.add.tiledmap('tilemap-key');

game.physics.p2.convertTiledmap(map, 'tilelayer-name');

So it won't work then because collides doesn't get set to tile. I did the above and was wondering why p2 physics bodies were not being created and I removed the && tile.collides and it works fine now, so if anyone is having p2 physics collision issues you're welcome

obrigado, estava preciso muito disso!

Hmm, not sure I understand what you mean. The collides property is a property of the Tile object in this module:
https://github.com/englercj/phaser-tiled/blob/fd7fa2ac8dfaeea5808aa9710b98146c92e1ebe9/src/tiled/Tile.js#L353-L364

Aww. I kept thinking I had to use enable the p2 physics to have collision.

No problem.


Story title

Need to decide:

Whether all stories have a mandatory title?
When is this title decided? (beginning? end?)

And then implement.

We decided:

Yes, all stories have a mandatory title (needed to display them e.g. list of stories etc.)
The title is decided at the beginning.
A) By the end of the game, players are too tired.
B) Starting with a title might add needed structure to the storyline.

Done


Add all parameter for --clean option

Now cleaning could be used as spamostack --clean all
instead of enumeration every component.

Coverage remained the same at 0.0% when pulling 593b0e3d45108a4a748b3426918f1062eae2f83f on FromZeus:master into 45e43184ae603b624322ceb5b2994e30fdaabf34 on seecloud:master.


Missing to_normalized_address example in README

Hi!
Looks like the to_normalized_address in README is merely copy of to_checksum_address.
It will be great to include the correct explanation and sample of it

fixed via 148cb34442840f272c240c6b658845db2139b98b
Thanks for catching this.


Update day3_1000_Packagedemo_paper3.yaml

Add github link for "tidy genomic..." workshop

Thanks, Mike, just got to it, at ISMB. Will reply on Slack momentarily


Mount resource failing to execute after first run.

Description
When using action :mount on mount resource is failing future runs because previous runs have already mounted the drive.
Chef Version
17.10.3
Platform Version
rhel8
Replication Case

Using something like this:
mount '/my/mount' do
device '/dev/my_mount'
device_type :device
fstype 'xfs'
options %w(defaults)
dump 1
pass 1
enabled true
action [ :mount, :enable ]
end
Client Output

================================================================================
    Error executing action `mount` on resource 'mount[/var/lib/containers]'
    ================================================================================

    Mixlib::ShellOut::ShellCommandFailed
    ------------------------------------
    Expected process to exit with [0], but received '32'
    ---- Begin output of ["mount", "-t", "xfs", "-o", "defaults", "/dev/my_mount", "/var/lib/containers"] ----
    STDOUT:
    STDERR: mount: /var/lib/containers: /dev/mapper/my_mount already mounted on /var/lib/containers.
    ---- End output of ["mount", "-t", "xfs", "-o", "defaults", "/dev/my_mount", "/var/lib/containers"] ----
    Ran ["mount", "-t", "xfs", "-o", "defaults", "/dev/my_mount", "/var/lib/containers"] returned 32

    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/podman/recipes/default.rb

     11: mount <obfuscated>[:mount_point] do
     12:   device <obfuscated>[:device]
     13:   device_type <obfuscated>[:device_type]
     14:   fstype <obfuscated>[:fstype]
     15:   options <obfuscated>[:options]
     16:   dump <obfuscated>[:dump]
     17:   pass <obfuscated>[:pass]
     18:   enabled <obfuscated>[:enabled]
     19:   action [ :mount, :enable ]
     20:   only_if { <obfuscated>[:enabled] == true }
     21: end
     22:

    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/podman/recipes/default.rb:11:in `from_file'

    mount("/var/lib/containers") do
      action [:mount, :enable]
      default_guard_interpreter :default
      declared_type :mount
      cookbook_name "podman"
      recipe_name "default"
      device "/dev/my_mount"
      device_type :device
      fstype "xfs"
      options ["defaults"]
      dump 1
      pass 1
      enabled true
      mount_point "/var/lib/containers"
      supports {:remount=>false}
      fsck_device "-"
      only_if { #code block }
    end

    System Info:
    ------------
    chef_version=17.10.3
    platform=redhat
    platform_version=8.8
    ruby=ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [x86_64-linux]
    program_name=/usr/bin/chef-client
    executable=/opt/chef/bin/chef-client

Stacktrace

See above

Running in trace I also see that Chef reconizes that its already mounted during some evaulation.
[2023-10-25T11:56:05-04:00] TRACE: Found mount /dev/mapper/my_mount to /var/lib/containers in /etc/fstab


Tidier Types module

Omit synthetic StrictDouble when not used
Align enum declarations

This is not even close to correct 🙃


MediaFoundationResampler is not found in Nuget UWP

Unfortunately, UWP is quite a sandboxed environment, and doesn't allow us to call the APIs we need to access for MediaFoundationResampler


Resp section parsing with navy cjcs

Add in a responsibility section parser that utilizes the section parsing logic for Navy/CJCS section parsing (https://github.com/dod-advana/gamechanger-data/tree/section-parse-navy-cjcs-eo-title) and generates an xlsx spreadsheet containing the input for the Responsibility explorer model.
To Run/Test:

A CLI tool has been added  in gamechanger-data/common/document_parser/lib/responsibility_parse/cli/responsibility_parser_cli.py and can be used to parse a directory of JSONs (that have been parsed via the section parsing code) via:

python3 common/document_parser/lib/responsibility_parse/cli/responsibility_parser_cli.py -i "/path/to/gc_jsons" -s "/directory/to/save/responsibility_results.xlsx"
NOTE: Multiple json paths can be parsed at the same time by semi-colon delimiting the input paths, similar to python3 common/document_parser/lib/responsibility_parse/cli/responsibility_parser_cli.py -i "/path/to/gc_jsons1;/path/to/gc_jsons2" -s "/directory/to/save/responsibility_results.xlsx"
These results can also be ingested up into postgres as well via the cli tool. E.g.: python3 common/document_parser/lib/responsibility_parse/cli/responsibility_parser_cli.py -i "/Users/austinmishoe/bah/advana_data/gc_jsons_dod" -e "/Users/austinmishoe/bah/advana_data/responsibility_results.xlsx" -s -u postgres -p password -d game_changer -t responsibilites_new3 -n <IP_ADDRESS>

Unit tests can be found/run via gamechanger-data/common/document_parser/lib/responsibility_parse/tests/unit/test_parse_responsibilities.py

Tests in test_responsibility_parser.py. :) I did get a resource warning fyi

I ran the CLI with the command: python3 gamechanger-data/common/document_parser/lib/responsibility_parse/cli/responsibility_parser_cli.py -i /Users/oliviakroop/Desktop/test/output -s /Users/oliviakroop/Desktop/test/resp_output  and it attempted to save to RDS without supplying the --save-to-rds flag. Is this intentional?

You'll want to use the -e (or --excel-save-filepath) param for saving the results to a file (and not to postgress)
e.g.
python3 common/document_parser/lib/responsibility_parse/cli/responsibility_parser_cli.py -i "/Users/austinmishoe/bah/advana_data/gc_jsons" -e "/Users/austinmishoe/bah/advana_data/responsibility_results.xlsx"

Just added a README with more explicit instructions https://github.com/dod-advana/gamechanger-data/pull/254/commits/fe840d2a9a018a06c10488df7baadece4c511acd 👍 @kroop-olivia-bah


Cloud - Google Integration not Working in 0.95.X

Home Assistant release with the issue:

0.95.1
Last working Home Assistant release (if known):
0.94.4
Operating environment (Hass.io/Docker/Windows/etc.):

Debian 9 with Docker
Component/platform:

https://www.home-assistant.io/components/cloud/
Description of problem:
Since upgrading to 0.95.x, I can no longer sync devices to Google via the Cloud component, but existing devices do get controlled properly.  I was initially trying to expose a new light and noticed it would never sync up.
Everything has worked flawlessly up to this point. Now, when I try to sync from either Home Assistant or via “sync my devices” on Google Assistant on my phone, I get errors and new devices do not sync.
My log shows this error each time:
2019-06-28 07:28:43 ERROR (MainThread) [homeassistant.components.google_assistant.smart_home] Unexpected error Traceback (most recent call last):   File "/usr/src/app/homeassistant/components/google_assistant/smart_home.py", line 55, in _process     result = await handler(hass, data, inputs[0].get('payload'))   File "/usr/src/app/homeassistant/components/google_assistant/smart_home.py", line 86, in async_devices_sync     async_get_entities(hass, data.config)   File "/usr/src/app/homeassistant/components/google_assistant/helpers.py", line 119, in sync_serialize     entity_config = self.config.entity_config.get(state.entity_id, {}) AttributeError: 'NoneType' object has no attribute 'get' 2019-06-28 07:28:43 ERROR (MainThread) [homeassistant.components.google_assistant.smart_home] Error handling message {'inputs': [{'intent': 'action.devices.SYNC'}], 'requestId': '1967247859201571938'}: {'errorCode': 'unknownError'}
My phone (Google Assistant) just says there was an error syncing to hass.io.
I have attempted numerous restarts and even went as far as unlinking hass.io, but now it wont re-link. When I try to re-link it, it just says “Couldn’t update the setting, please check your connection.” There are no connection issues. I tried multiple times including ensuring it was unlinked, restarting Hass, and waiting 30 minutes to let everything sync up. Same error.
This morning, I tried to wipe out my cloud settings altogether (removed cloud file from .storage) and restarting Home Assistant. Then I signed back into Nabu Casa, selected my entities for Google, then tried linking hass.io on my phone. Same error.
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
cloud: in my configuration.yaml. I had the same issue with all cloud settings wiped out (default).

Traceback (if applicable):
2019-06-28 07:28:43 ERROR (MainThread) [homeassistant.components.google_assistant.smart_home] Unexpected error
Traceback (most recent call last):
  File "/usr/src/app/homeassistant/components/google_assistant/smart_home.py", line 55, in _process
    result = await handler(hass, data, inputs[0].get('payload'))
  File "/usr/src/app/homeassistant/components/google_assistant/smart_home.py", line 86, in async_devices_sync
    async_get_entities(hass, data.config)
  File "/usr/src/app/homeassistant/components/google_assistant/helpers.py", line 119, in sync_serialize
    entity_config = self.config.entity_config.get(state.entity_id, {})
AttributeError: 'NoneType' object has no attribute 'get'
2019-06-28 07:28:43 ERROR (MainThread) [homeassistant.components.google_assistant.smart_home] Error handling message {'inputs': [{'intent': 'action.devices.SYNC'}], 'requestId': '1967247859201571938'}: {'errorCode': 'unknownError'}

Additional information:
I downgraded to 0.94.4 and hass.io synced the first try.

I thought it was an issue with google and based on the current posts about issues between hass and google home, I tried unlinking then linking hass.io. This results in a "Couldn't update the setting. Check your connection" toast message in the google home app.
Another possible symptom is that the google api endpoint on the hassio instance is 404.

I tried upgrading to 0.95.2 since there was a fix for Google Assistant, but I still couldn't get it to sync.

Another note. This happens with or without the cloud: yaml filled in.

I have a hunch that it's because the http_api file async_setup(hass) function does not return anything. I'll continue to investigate

Same problem here.  Thought it was going to be fixed with 0.95.2 as a fix was pushed for the issue, but the problem still exists.

Oh snap, looks like I fixed it at the wrong place. Are all of you using Home Assistant Cloud with a custom filters defined in YAML?
Going to look for a fix now and will be in 95.3

I had filters, but then tried with no cloud config at all (deleted cloud file) with the same results.

Oh snap, looks like I fixed it at the wrong place. Are all of you using Home Assistant Cloud with a custom filters defined in YAML?
Going to look for a fix now and will be in 95.3

Hi Balloob, i tried it with custom filters in YAML and also using the built in UI methods, both failed

95.3 has been released with the fix.

Confirmed fixed in 95.4

I'm running 0.95.4 - all my thermostats don't work now via Google Assistant.
'Sync my devices' returns "An erro occured while syncing my test app."
Using the "Home" app, checking my thermostats etc show "Not responding".

I'm running 0.95.4 - all my thermostats don't work now via Google Assistant.
'Sync my devices' returns "An erro occured while syncing my test app."
Using the "Home" app, checking my thermostats etc show "Not responding".
None of the lights that previously worked are available either.
EDIT: Looks like this might be the issue:
[homeassistant.config] Invalid config for [google_assistant]: The 'allow_unlock' option (with value 'False') is deprecated, please remove it from your config
uration. This option will become invalid in version 0.95 for dictionary value @ data['google_assistant'].

prior to 0.95 incorrect configs gave a warning, after 0.95 its a error and needs to be resolved for it to work


Add AudioFrame to Variant

Based of this addition I have (almost ready) an audio effect that can be used to read and generate audio samples from scripts.

With the mentioned audio effect procedural audio will be able to be generated (requested at #18135).

No, this is overkill.. and you can use a Vector2 if you want, which is pretty much the same.
I think the best way to approach this would be to create an AudioStream that you can simply feed via PoolFloatArray or PoolVector2Array (and improve gdscript performance to access it). Still it's really inefficient, better GDNative bindings are imo the best alternative.

On a side note, if the script API gets a way to generate audio, then GDNative and also C# will get it for free as well, with no need to design a new specific interface that would only work in GDNative.

I also think it's too much to add a whole new Variant for this. Variant is one of the most intimate parts of the engine, additions to it need to have a very strong use case to justify them. I haven't looked at this in detail but if Vector2 can be used to the same effect, then adding a new audio-specific tuple seems overkill indeed.

That said, I think you could probably add a constructor and operator for AudioFrame that takes and returns a Vector2. This way you can use it in your C++ APIs and it will work for variant.


Update MAINTAINERS.md

Retire Gari, remove old chat reference
Signed-off-by: Ry Jones<EMAIL_ADDRESS>

@ mastersingh24


Google Address Validator hits exception on some addresses.  Issue #2461

Critical Changes
Changes
Issues Closed
FIxed #2461

@njjc this fix is ready for review.  turns out if you were using google address verification, and you had Reject Ambiguous Addresses checked on, we would hit a null ptr exception because where were expecting a boolean partial_match in the response, but google actually returns true or null (rather than false).  so treating the null as a boolean caused a null ptr exception.  kinda feels like a platform issue, but anyways, changing the logic to explicitly test the boolean works.

@njjc I added a trivial fix to opp naming due to an error someone reported in the hub.

@jlantz this is an error I haven't seen before, thought you might like to investigate.

@davidhabib Any idea when this will be pushed to production?  I'd like to know when these error messages will end :)

@ckoppelman This will push to production as part of NPSP 3.90 tonight. Thanks for your patience.


Resolve duplicate local string key related to PR comments

A regression in #31924 caused there to be two issues.review.comment keys in the English language locale file, leading to a problem when reading PR review histories that contain comments.
This snapshot addresses this by making the newer key unique.

Before:

After:


Troubleshooting and resolution steps needed

Troubleshooting and resolution steps should be added.

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

ID: de955911-dfbf-33b3-778a-767a5a578a0d
Version Independent ID: 23fb5cbd-5f7d-f7ca-1622-5885020966c2
Content: Bug Check 0x1A MEMORY_MANAGEMENT
Content Source: windows-driver-docs-pr/debugger/bug-check-0x1a--memory-management.md
Product: windows-hardware
GitHub Login: @DOMARS
Microsoft Alias: domars

Thanks, @LuigiBruno
@DOMARS please add this for consideration.

@LuigiBruno - This topic now describes the helpful !analyze utility and the Windows Memory diagnostics. There is more that could be done, but those tools and the specific error guidance for the sub type of memory error along with the general guidance that we provide on stop codes, is a reasonable start. We will use data to determine if there is more that we should document on this stop code in the future, beyond the newer memory code items that is tracked in other git issues.

@LuigiBruno - This topic now describes the helpful !analyze utility and the Windows Memory diagnostics. There is more that could be done, but those tools and the specific error guidance for the sub type of memory error along with the general guidance that we provide on stop codes, is a reasonable start. We will use data to determine if there is more that we should document on this stop code in the future, beyond the newer memory code items that is tracked in other git issues.

OK @DOMARS. Thank you.


http: making downstream scheme vs unreliable-:scheme clear

See comments in header_utility.h for details on the difference between
:scheme (which is functionally a hop by hop header, transitioning from optional downstream scheme to reflecting upstream encryption) and
x-forwarded-proto (which represents the actual downstream scheme)
I set up this PR to address #14587 since folks have been using :scheme when (I believe) they intend to use X-Forwarded-Proto.
I removed the Scheme header key, so Envoy filters would fail to compile until they switched to getDownstreamScheme or getLegacyScheme, docced up the difference, and planned on migrating all the Envoy uses to getDownstreamScheme.
I was tempted to send this out for actual review, when it occurred to me that maybe
isModifiableHeader should apply to X-Forwarded-Proto since it affects a fundamental component of the request.  And lua filters and wasm filters and ext_foo filters are probably all going to have the same problem, which is that people think :scheme represents the scheme of the request (rather than functionally being hop by hop).
So then I thought, why not fix it differently.  On header ingress, move :scheme to :scheme-of-last-hop and set the value which currently was in x-forwarded-proto to the :scheme header.  The HTTP/1 codec ignores both headers, and the HTTP/2 codec could do the swap back, addressing my concerns about consistency between regular and upstream filters, and people get what they expect when they reference :scheme.
Unless they're actually familiar with the spec, at which point we'd of course be doing the wrong thing.
Polling wasm/security/http experts for thoughts on which group of people we should confuse :-/
Commit Message:
Additional Description:
Risk Level:
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]

But :scheme is not a hop-by-hop header, it describes the target URI and the same value should be retained end-to-end (e.g. clients can send a request with :scheme: http over existing HTTP/2+TLS connection), at least that's the way I understand it.

But :scheme is not a hop-by-hop header, it describes the target URI and the same value should be retained end-to-end (e.g. clients can send a request with :scheme: http over existing HTTP/2+TLS connection), at least that's the way I understand it.

I can't find anything specific on whether :scheme should be end to end. The spec has this A proxy or gateway can translate requests for non-HTTP schemes, enabling the use of HTTP to interact with non-HTTP services. which I interpret that a proxy can translate between different schemes.

I can't find anything specific on whether :scheme should be end to end. The spec has this A proxy or gateway can translate requests for non-HTTP schemes, enabling the use of HTTP to interact with non-HTTP services. which I interpret that a proxy can translate between different schemes.

I can't find anything specific on whether :scheme should be end to end. The spec has this A proxy or gateway can translate requests for non-HTTP schemes, enabling the use of HTTP to interact with non-HTTP services. which I interpret that a proxy can translate between different schemes.

Indeed, :scheme definitely isn't very well specified, but it's supposed to represent the scheme portion of the target URI, and I don't believe that we're changing the target URI.
I cannot easily test that, since Chrome dropped support for chrome://net-internals, but I believe that browsers might send :scheme: http over existing HTTP/2 TLS connection, which suggests that it doesn't represent the security properties of the underlying transport.
Also, there are bugfixes in other proxies (e.g. https://github.com/haproxy/haproxy/commit/3b44c54129a4f8334834dda6344c512e76e883fa) to forward :scheme received from the client.

I can't find anything specific on whether :scheme should be end to end. The spec has this A proxy or gateway can translate requests for non-HTTP schemes, enabling the use of HTTP to interact with non-HTTP services. which I interpret that a proxy can translate between different schemes.

Indeed, :scheme definitely isn't very well specified, but it's supposed to represent the scheme portion of the target URI, and I don't believe that we're changing the target URI.
I cannot easily test that, since Chrome dropped support for chrome://net-internals, but I believe that browsers might send :scheme: http over existing HTTP/2 TLS connection, which suggests that it doesn't represent the security properties of the underlying transport.
Also, there are bugfixes in other proxies (e.g. https://github.com/haproxy/haproxy/commit/3b44c54129a4f8334834dda6344c512e76e883fa) to forward :scheme received from the client.

yeah, the more I look at it and read the spec, I think Envoy has the two inverted.  It's going to take some thought about how to reverse them safely.
I'm going to close this off in favor of digging back through the code and discussion on slack

yeah, the more I look at it and read the spec, I think Envoy has the two inverted.  It's going to take some thought about how to reverse them safely.
I'm going to close this off in favor of digging back through the code and discussion on slack


Embed MathJax?

One goal I had was for everything to be usable offline. But because MathJax is so big, we load it from a remote CDN. This won't work if you're offline, and I wonder if there are even security concerns.

This might be useful https://github.com/mathjax/MathJax-grunt-cleaner; most use cases need only about ~1.5MB of MathJax's components.


Segmentation fault

[x] I have read the FAQ.
[x] I have searched in existing issues.

Environment

OS: Ubuntu 20.04
scrcpy version: 1.17
installation method: manual build
device model: motorola moto g(6)
Android version: 9

Describe the bug
When I run the command  scrcpy or ./run x, a segfault occurs.
INFO: scrcpy 1.17 <https://github.com/Genymobile/scrcpy>
x/server/scrcpy-server: 1 file pushed, 0 skipped. 172.5 MB/s (34974 bytes in 0.000s)
[server] INFO: Device: motorola moto g(6) (Android 9)
INFO: Renderer: opengl
INFO: OpenGL version: 4.6 (Compatibility Profile) Mesa 20.2.6
INFO: Trilinear filtering enabled
INFO: Initial texture: 1080x2160
./run, linha 23: 51766 Falha de segmentação  (imagem do núcleo gravada) SCRCPY_SERVER_PATH="$BUILDDIR/server/scrcpy-server" "$BUILDDIR/app/scrcpy" "$@"

Worth noticing that I tried with snap and it did work, but different adb versions conflicted so didn't work for me (setting the envvar ADB did not work for me).

Please enable ASAN, recompile and rerun to get a stack trace:
meson configure x -Db_sanitize=address
ninja -Cx
./run x

Please enable ASAN, recompile and rerun to get a stack trace:
meson configure x -Db_sanitize=address
ninja -Cx
./run x

This is what I got now:
INFO: scrcpy 1.17 <https://github.com/Genymobile/scrcpy>
x/server/scrcpy-server: 1 file pushed, 0 skipped. 52.8 MB/s (34974 bytes in 0.001s)
[server] INFO: Device: motorola moto g(6) (Android 9)
INFO: Renderer: opengl
INFO: OpenGL version: 4.6 (Compatibility Profile) Mesa 20.2.6
INFO: Trilinear filtering enabled
INFO: Initial texture: 1080x2160
AddressSanitizer:DEADLYSIGNAL
=================================================================
ERROR: Failed to mmap

This is what I got now:
INFO: scrcpy 1.17 <https://github.com/Genymobile/scrcpy>
x/server/scrcpy-server: 1 file pushed, 0 skipped. 52.8 MB/s (34974 bytes in 0.001s)
[server] INFO: Device: motorola moto g(6) (Android 9)
INFO: Renderer: opengl
INFO: OpenGL version: 4.6 (Compatibility Profile) Mesa 20.2.6
INFO: Trilinear filtering enabled
INFO: Initial texture: 1080x2160
AddressSanitizer:DEADLYSIGNAL
=================================================================
ERROR: Failed to mmap

Hmm… weird. And you don't get a full stacktrace?

 Which filesystem?

Hmm… weird. And you don't get a full stacktrace?

 Which filesystem?

No, it's actually xubuntu. The filesystem is ext4.
Yes, this was all I got :/

No, it's actually xubuntu. The filesystem is ext4.
Yes, this was all I got :/

strace -e trace=mmap ./run x

strace -e trace=mmap ./run x

mmap(NULL, 101563, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f35a79ef000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f35a79ed000
mmap(NULL, 2036952, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f35a77fb000
mmap(0x7f35a7820000, 1540096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f35a7820000
mmap(0x7f35a7998000, 303104, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19d000) = 0x7f35a7998000
mmap(0x7f35a79e3000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7f35a79e3000
mmap(0x7f35a79e9000, 13528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f35a79e9000
mmap(NULL, 5707984, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f35a7289000
mmap(NULL, 101563, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f56ce633000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f56ce631000
mmap(NULL, 194944, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f56ce601000
mmap(0x7f56ce60f000, 61440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0x7f56ce60f000
mmap(0x7f56ce61e000, 57344, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d000) = 0x7f56ce61e000
mmap(0x7f56ce62c000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2a000) = 0x7f56ce62c000
mmap(NULL, 20752, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f56ce5fb000
mmap(0x7f56ce5fc000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f56ce5fc000
mmap(0x7f56ce5fe000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f56ce5fe000
mmap(0x7f56ce5ff000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f56ce5ff000
mmap(NULL, 2036952, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f56ce409000
mmap(0x7f56ce42e000, 1540096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f56ce42e000
mmap(0x7f56ce5a6000, 303104, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19d000) = 0x7f56ce5a6000
mmap(0x7f56ce5f1000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7f56ce5f1000
mmap(0x7f56ce5f7000, 13528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f56ce5f7000
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f56ce406000
mmap(NULL, 5707984, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f56cde94000
mmap(NULL, 27002, PROT_READ, MAP_SHARED, 3, 0) = 0x7f56ce645000
INFO: scrcpy 1.17 <https://github.com/Genymobile/scrcpy>
x/server/scrcpy-server: 1 file pushed, 0 skipped. 111.2 MB/s (34974 bytes in 0.000s)
[server] INFO: Device: motorola moto g(6) (Android 9)
INFO: Renderer: opengl
INFO: OpenGL version: 4.6 (Compatibility Profile) Mesa 20.2.6
INFO: Trilinear filtering enabled
INFO: Initial texture: 1080x2160
AddressSanitizer:DEADLYSIGNAL
=================================================================
ERROR: Failed to mmap
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=85473, si_uid=1000, si_status=1, si_utime=479, si_stime=295} ---
+++ exited with 1 +++

mmap(NULL, 101563, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f35a79ef000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f35a79ed000
mmap(NULL, 2036952, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f35a77fb000
mmap(0x7f35a7820000, 1540096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f35a7820000
mmap(0x7f35a7998000, 303104, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19d000) = 0x7f35a7998000
mmap(0x7f35a79e3000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7f35a79e3000
mmap(0x7f35a79e9000, 13528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f35a79e9000
mmap(NULL, 5707984, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f35a7289000
mmap(NULL, 101563, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f56ce633000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f56ce631000
mmap(NULL, 194944, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f56ce601000
mmap(0x7f56ce60f000, 61440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xe000) = 0x7f56ce60f000
mmap(0x7f56ce61e000, 57344, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d000) = 0x7f56ce61e000
mmap(0x7f56ce62c000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2a000) = 0x7f56ce62c000
mmap(NULL, 20752, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f56ce5fb000
mmap(0x7f56ce5fc000, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f56ce5fc000
mmap(0x7f56ce5fe000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f56ce5fe000
mmap(0x7f56ce5ff000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f56ce5ff000
mmap(NULL, 2036952, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f56ce409000
mmap(0x7f56ce42e000, 1540096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x25000) = 0x7f56ce42e000
mmap(0x7f56ce5a6000, 303104, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19d000) = 0x7f56ce5a6000
mmap(0x7f56ce5f1000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7f56ce5f1000
mmap(0x7f56ce5f7000, 13528, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f56ce5f7000
mmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f56ce406000
mmap(NULL, 5707984, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f56cde94000
mmap(NULL, 27002, PROT_READ, MAP_SHARED, 3, 0) = 0x7f56ce645000
INFO: scrcpy 1.17 <https://github.com/Genymobile/scrcpy>
x/server/scrcpy-server: 1 file pushed, 0 skipped. 111.2 MB/s (34974 bytes in 0.000s)
[server] INFO: Device: motorola moto g(6) (Android 9)
INFO: Renderer: opengl
INFO: OpenGL version: 4.6 (Compatibility Profile) Mesa 20.2.6
INFO: Trilinear filtering enabled
INFO: Initial texture: 1080x2160
AddressSanitizer:DEADLYSIGNAL
=================================================================
ERROR: Failed to mmap
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=85473, si_uid=1000, si_status=1, si_utime=479, si_stime=295} ---
+++ exited with 1 +++

You're not running on an emulator, right?
All references to Failed to mmap I can find are related to emulators.

You're not running on an emulator, right?
All references to Failed to mmap I can find are related to emulators.

Hmm, I run an emulator usually. But this was when I got my phone plugged in and it seems to detect it. Maybe it's some problem with adb running an emulator previously?

Hmm, I run an emulator usually. But this was when I got my phone plugged in and it seems to detect it. Maybe it's some problem with adb running an emulator previously?

By emulator, I'm not talking about an Android emulator, but VirtualBox or Qemu: is Xubuntu your "host" operating system, or is it running inside a VM?
If it's not inside a VM, I don't know it "failed to mmap()".
https://www.google.com/search?q="failed+to+mmap"

By emulator, I'm not talking about an Android emulator, but VirtualBox or Qemu: is Xubuntu your "host" operating system, or is it running inside a VM?
If it's not inside a VM, I don't know it "failed to mmap()".
https://www.google.com/search?q="failed+to+mmap"

Oh, sorry. No, I'm not doing that, Xubuntu is my host OS.

Oh, sorry. No, I'm not doing that, Xubuntu is my host OS.

It turns out it was a driver problem.
If I understand it correctly, as of Ubuntu 20.04 the default Intel graphics driver used was not compatible with my GPU. I noticed it should be something similar because mpv was also crashing.
See this bug for reference.
The solution is to set this environment variable
export MESA_LOADER_DRIVER_OVERRIDE=i965

Sorry for the trouble, hope this helps someone.


RA confused by proc macro with same name as internal module

Repro repo: https://github.com/nox/proc-macro-glob-import
RA fails to resolve the use settings::Settings import in src/lib.rs, as long as there is mod settings {} in macros/src/lib.rs.

Repro:
//- /lib.rs crate:lib deps:settings,macros
use macros::settings;
use settings::Settings;
//- /settings.rs crate:settings
pub struct Settings;
//- /macros.rs crate:macros
mod settings {}
pub const settings: () = ();

It's weird that we're apparently ignoring the visibility of the settings module here


Support for thumbs up and thumps down as feedback  for messages

Hi All
My requirement is when user clicks on thumps up and thumps down, i need to capture those details as a feedback to the bot. PFA the screenshot.I tried subscribing for all messages in webhooks but still no message is coming from facebook when this is clicked.

I will investigate if it is possible to handle this kind of action / event

Unfortunately there is no possibility so far to process this kind of action.
You could file a feature request directly on facebook.
I close this issue. Feel free to reopen if facebook messenger supports that feature.


Fixed issue #303: added support for NOT

Just added a case for ExpressionType.Not in CompileExpr

Great!


Github Slack Integration

Hi,
Can the owner install Github Slack integration, please?
This way people can receive any updates being made in here over slack.
Install GitHub App integration link
PROBLEM

@alancapc Sure, but which slack channel are you using ?

@alancapc the reason I asked is because I tried to click on the link but got An unexpected error occured

@alancapc ok.... what do we do now ?

@alancapc @veggiemonk Maybe it would be good to understand the use case a bit better. It could be possible we handle this another way.

@vegasbrianc Sure, what do you propose ?

Sorry for the late reply, maybe if I create a quick .gif of the use case it would help understanding the use
case?
Steps to reproduce desired result:

On Slack, add/install "Github" app.

On Slack, go to "Github" app to (can do this from anywhere, but doing so here for the sake of keeping one scope):

From Github app, subscribe to a project (One that can be used for comparison is docker/compose).

Output: Any updates on docker/compose project hosted on Github will be reflected as notifications on Slack:

Clean up: If you don't want to follow docker/compose (I do as it doesn't seem ready for production on windows just yet) just unsubscribe from it:
Unsubscribe to notifications for a repository:
/github unsubscribe owner/repository

To understand the scenario going through these steps will give you a fairly good idea of how I planned on receiving veggiemonk/awesome-docker notifications on slack.
I will think of why it cannot be done from veggiemonk/awesome-docker just yet and how this can be changed, as soon as I do so will get back.
Thanks !

@alancapc @vegasbrianc Does one need to install the slack app on github or the github app on slack. I'm confused....

Reopen the issue if still relevant


Web App Notification

Describe the Feature
I hope Bluesky can add a "push notification toggle" in the web version's notification settings to request the browser's push notification permissions, allowing users to have the same real-time notification capabilities on the desktop as they do on mobile devices.
Twitter already has this feature, and you can take it as a reference.
Thank you very much for the efforts of your development team. Best wishes!
Attachments
No response
Describe Alternatives
No response
Additional Context
No response

Somewhat related, see also #1194 and #1584 which suggest making the website a Progressive Web App (PWA).


check-code-quality fails to run: can't import mkdocstrings itself

$ poetry install

$ poetry run duty check-code-quality
✗ Checking code quality (1)
  > flakehell lint src/mkdocstrings tests duties.py
  src/mkdocstrings/plugin.py:36:1: E0401 Unable to import 'mkdocstrings.extension' [pylint]
  src/mkdocstrings/plugin.py:37:1: E0401 Unable to import 'mkdocstrings.handlers.base' [pylint]
  src/mkdocstrings/plugin.py:38:1: E0401 Unable to import 'mkdocstrings.loggers' [pylint]
  src/mkdocstrings/plugin.py:39:1: E0401 Unable to import 'mkdocstrings.references' [pylint]
  src/mkdocstrings/loggers.py:11:1: WPS301 Found dotted raw import: mkdocstrings.handlers.base [wemake-python-styleguide]
  tests/test_references.py:4:1: E0401 Unable to import 'mkdocstrings.references' [pylint]
  tests/test_extension.py:5:1: E0401 Unable to import 'mkdocstrings.extension' [pylint]

"It works on my machine."
More seriously, this is weird.  I'd like to avoid these kind of issues for contributors indeed. Could you share any other details about your setup? I'm not sure what would be relevant though :confused:

Also works fine on a fresh Ubuntu, apparently. (docker run -it ubuntu:latest)
apt update
apt install git python3 curl python3-distutils
curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python3
. ~/.profile
git clone https://github.com/pawamoy/mkdocstrings
cd mkdocstrings
poetry install
poetry run duty check-code-quality

I'm just on Arch Linux; the only thing that seems relevant is that I have a really messy ~/.local/lib/python3.8/site-packages/ directory, which includes mkdocstrings and weird symlinks.

Oh, it even works locally for me now. Nevermind O_o
But I'm sure that just now was the first time I was able to run it successfully.


Keep spring cloud client library up to date with new Spring Boot releases

Closing in favor of #21770.


Highlight the correct navigation link on content pages

When we go to pages in /content, we should highlight the navigation link
Tags so we know where we are in the application. This commit makes sure that
happens.
The naming is still not coherent between the URLs and the navigation links. There are tasks in trello to fix that, so I will do that in a separate PR.
Trello: https://trello.com/c/RrWiwHb4/81-content-tagger-when-we-navigate-to-a-content-page-the-nav-link-tab-isn-t-highlighted

👍


Return a Koalas series instead of pandas' in stats APIs at Koalas DataFrame

Currently, Koalas' statics functions such as count, sum, min, max, etc. returns a pandas Series.
Resolves #1332

Codecov Report

Merging #1333 into master will increase coverage by 1.15%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1333      +/-   ##
==========================================
+ Coverage   94.05%   95.21%   +1.15%
==========================================
  Files          34       34
  Lines        7405     7439      +34
==========================================
+ Hits         6965     7083     +118
+ Misses        440      356      -84

Impacted Files
Coverage Δ

databricks/koalas/generic.py
96.99% <ø> (ø)
:arrow_up:

databricks/koalas/frame.py
96.73% <100%> (ø)
:arrow_up:

databricks/koalas/__init__.py
85.1% <0%> (-8.52%)
:arrow_down:

databricks/koalas/missing/frame.py
100% <0%> (ø)
:arrow_up:

databricks/koalas/usage_logging/usage_logger.py
100% <0%> (+50%)
:arrow_up:

databricks/koalas/usage_logging/__init__.py
95.49% <0%> (+69.36%)
:arrow_up:

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 fa824d8...8965916. Read the comment docs.

I discussed offline with @ueshin. I am going to merge this.


Avoid synchronous IO for rendering Mermaid diagrams

Hi! Thanks a lot for this incredible project. I am absolutely amazed by the new telegramify function.
Recently Mermaid rendering was added, and I noticed that it does synchronous IO with requests, which is very bad for users who develop asynchronous bots with aiogram for example.
To fix this, I have a few suggestions:

Allow disabling Mermaid rendering,  render_mermaid=False. I think this one is necessary.
Instead of downloading the image, pass https url to telegram, as it will download the image itself.
Add support for asynchronous http with aiohttp. Maybe under specific extra: pip install telegramify-markdown[async]. I don't think this is needed, if the second suggestion will be implemented.

We will configure a dedicated configuration class for telegramify.
Regarding the asynchronous issue, I actually intend to fully implement it as asynchronous. However, this might lead to compatibility problems, so perhaps I should write a telegramify_async method.
import asyncio

async def telegramify_async(message):
    """Asynchronous method"""
    await asyncio.sleep(0.1)
    return f"Telegram [Async]: {message}"

def sync_adapter(coroutine):
    """
    Synchronous adapter: Executes a coroutine and explicitly starts an event loop
    in a synchronous context.
    """
    try:
        loop = asyncio.get_event_loop()
    except RuntimeError:  # If no event loop is running, create a new one
        loop = asyncio.new_event_loop()
        asyncio.set_event_loop(loop)

    if not loop.is_running():
        return loop.run_until_complete(coroutine)  # Run the coroutine until it completes
    else:
        raise RuntimeError("Attempting to call an asynchronous function synchronously inside an active event loop")

def telegramify(message):
    """
    Provides support for synchronous calls (adapts asynchronous methods through the adapter)
    """
    return sync_adapter(telegramify_async(message))

what you think?

It seems that the synchronous methods of telegramify can be completely removed and converted to asynchronous methods. . .
I will complete this conversion in a while

To ensure compatibility, I will add a period of time to determine whether the synchronous method is compatible within the asynchronous loop and display a warning.

I have released a new version to fix this issue.


Adding the label does not trigger autorebase

I installed the app, and gave permission to our private repo. But when I add the label autorebase, it doesn't trigger the bot. I am able to see the bot autorebase in the author list. Should we do something additional like adding the webhook manually?
Another thing is that our target branch is staging, not master. Does this cause the problem?

Hi Emin,
Installing the app and enabling it on a repo is all you need to do. However, PRs labeled with autorebase won't be rebased if they have failing status checks as explained in the README. Where you expecting another behavior? If yes, which one?

Hi @tibdex ,
I read the readme and like you said, it's green but still it does not work. Is there a specific order about when to add the label? Please check the screenshot I took. I have to mention again that it's a private repo. I can't think of a proper reason why it shouldn't work. :/ I would really love to use this app.

The app is working fine for me and other projects are using it without issues. I don't have access to the logs of last week. Could you try again and tell me about it so that I can look into the GitHub webhooks sent and the logs on Zeit's Now?

Hey. I have just seen your message, and applied the label immediately right now. I would be happy if you could check the logs. Thank you!

I checked and GitHub indeed sent a webhook following your label addition. So this means the app is correctly installed on your repo.
However, I tried to do a dry-run of Autorebase on your PR but it's now closed/merged. Can you please open a dummy PR on the same repo, put it in a green/mergeable state, add the autorebase label, tell me when it's done, and keep it open. I'll then do another dry-run and try to gather more information. My suspicion is that GitHub would see your PR's mergeableStateStatus as different from clean/behind.

I believe the issue comes from the branch protection settings. When I remove the protection on the branch, autorebase worked successfully.

Do we have to reconfigure the settings or do you have any suggestion to give permission to autorebase app?

Hi Emin,
Autorebase will need push permission on the head branch of the PR to be able to rebase it and on its base branch to be able to merge it. I don’t know if you can add Autorebase to the list of “people and teams with puss access” visible in your screenshot.
I usually never use this “restrict who can push to matching branches” setting and prefer to require pull requests to be approved by a “code owner” reviewer instead. Maybe you could try that too.

Did you manage to make it work?


app title snipped baddly

[x] I am on the latest Hyper.app version
[x] I have searched the issues of this repo and believe that this is not a duplicate

**Ubuntu 17.10
Hyper.app version:2.0
Link of a Gist with the contents of your .hyper.js:
Relevant information from devtools (CMD+ALT+I on macOS, CTRL+SHIFT+I elsewhere):
The issue is reproducible in vanilla Hyper.app:

Issue

App title shouldn't be snipped when it's short.

Duplicate of #2641. Thanks for the confirming.


fix rds dashboard

Datasource was hardcoded, this way if we change datasource ID stuff will keep working
Signed-off-by: Riccardo piccoli<EMAIL_ADDRESS>

/cc @osherdp


[docs] missing source code of tauri_runtime_wry::Window and tauri_runtime_wry::WindowId

Where is the tauri_runtime_wry::Window and tauri_runtime_wry::WindowId's source code? did I miss something?

I need the WindowId, but could not find a way to get it from tauri::Window, which was on_window_event provided. And then I tried to see the source code, but couldn't find any

Basically, I want to try to solving the #2549 by sending redraw event after resize, don't know if it will work

tauri_runtime_wry::Window and tauri_runtime_wry::WindowId are re-exports of wry::application::Window and wry::application::WindowId which are re-exports of tao::window::Window and tao::window::WindowId


implement the start lang item

this let us use the normal main function in applications instead of the
tock_main! macro.
the blink example has been updated and produces the exact same disassembly as
the old version when compiled in release mode

@alevy This is looking very neat. Just a xargo build and you get a Tock application. Great work 👍

A+! this is much better.
One question... the entry point in Tock behaves differently than you might expect main to work in that it's totally fine (expected in many cases) to return from it. For example, here is the blink app written asynchronously:
#![no_std]

extern crate tock;

use tock::{led, timer};

extern fn timer_event(_: usize, _: usize, _: usize, _: usize) {
    led::toggle(0);
}

fn main() {
    timer::subscribe(timer_event, 0);
    timer::start_repeating(500);
}

The "blocking" versions of calls are really wrappers around this API (hence the loop { yieldk() } in the _start function).
Do you think naming it main is too misleading? On the upside, it seems as though Rust totally does the right thing eliminating excess code in the infinite-loop case, so maybe this totally fine.

If you ask me, I think it's fine. We do something similar in cortex-m-rt. Documentation helps though :-)