Mongoid 7 support

Here's an error I'm getting on Mongoid 7:
undefined method `macro' for #<Mongoid::Association::Referenced::BelongsTo:0x00007efea4728220>

rails_admin (1.3.0) lib/rails_admin/adapters/mongoid/association.rb:105:in `macro'
rails_admin (1.3.0) lib/rails_admin/adapters/mongoid/association.rb:48:in `foreign_key'
rails_admin (1.3.0) lib/rails_admin/config/fields/factories/association.rb:6:in `block (2 levels) in <main>'
rails_admin (1.3.0) lib/rails_admin/config/fields/factories/association.rb:6:in `each'
rails_admin (1.3.0) lib/rails_admin/config/fields/factories/association.rb:6:in `detect'
rails_admin (1.3.0) lib/rails_admin/config/fields/factories/association.rb:6:in `block in <main>'
rails_admin (1.3.0) lib/rails_admin/config/fields.rb:54:in `block (2 levels) in factory'
rails_admin (1.3.0) lib/rails_admin/config/fields.rb:54:in `each'
rails_admin (1.3.0) lib/rails_admin/config/fields.rb:54:in `detect'
rails_admin (1.3.0) lib/rails_admin/config/fields.rb:54:in `block in factory'
rails_admin (1.3.0) lib/rails_admin/config/fields.rb:50:in `each'
rails_admin (1.3.0) lib/rails_admin/config/fields.rb:50:in `factory'
rails_admin (1.3.0) lib/rails_admin/config/has_fields.rb:130:in `_fields'
rails_admin (1.3.0) lib/rails_admin/config/has_fields.rb:133:in `_fields'
rails_admin (1.3.0) lib/rails_admin/config/has_fields.rb:108:in `all_fields'
rails_admin (1.3.0) lib/rails_admin/config/has_fields.rb:83:in `fields'
rails_admin (1.3.0) app/controllers/rails_admin/main_controller.rb:123:in `get_collection'
rails_admin (1.3.0) app/controllers/rails_admin/main_controller.rb:37:in `list_entries'
rails_admin (1.3.0) lib/rails_admin/config/actions/index.rb:30:in `block (2 levels) in <class:Index>'
rails_admin (1.3.0) app/controllers/rails_admin/main_controller.rb:22:in `instance_eval'
rails_admin (1.3.0) app/controllers/rails_admin/main_controller.rb:22:in `index'
actionpack (5.2.0) lib/action_controller/metal/basic_implicit_render.rb:6:in `send_action'
actionpack (5.2.0) lib/abstract_controller/base.rb:194:in `process_action'
actionpack (5.2.0) lib/action_controller/metal/rendering.rb:30:in `process_action'
actionpack (5.2.0) lib/abstract_controller/callbacks.rb:42:in `block in process_action'
activesupport (5.2.0) lib/active_support/callbacks.rb:132:in `run_callbacks'
actionpack (5.2.0) lib/abstract_controller/callbacks.rb:41:in `process_action'
actionpack (5.2.0) lib/action_controller/metal/rescue.rb:22:in `process_action'
actionpack (5.2.0) lib/action_controller/metal/instrumentation.rb:34:in `block in process_action'
activesupport (5.2.0) lib/active_support/notifications.rb:168:in `block in instrument'
activesupport (5.2.0) lib/active_support/notifications/instrumenter.rb:23:in `instrument'
activesupport (5.2.0) lib/active_support/notifications.rb:168:in `instrument'
actionpack (5.2.0) lib/action_controller/metal/instrumentation.rb:32:in `process_action'
actionpack (5.2.0) lib/action_controller/metal/params_wrapper.rb:256:in `process_action'
actionpack (5.2.0) lib/abstract_controller/base.rb:134:in `process'
actionview (5.2.0) lib/action_view/rendering.rb:32:in `process'
actionpack (5.2.0) lib/action_controller/metal.rb:191:in `dispatch'
actionpack (5.2.0) lib/action_controller/metal.rb:252:in `dispatch'
actionpack (5.2.0) lib/action_dispatch/routing/route_set.rb:52:in `dispatch'
actionpack (5.2.0) lib/action_dispatch/routing/route_set.rb:34:in `serve'
actionpack (5.2.0) lib/action_dispatch/journey/router.rb:52:in `block in serve'
actionpack (5.2.0) lib/action_dispatch/journey/router.rb:35:in `each'
actionpack (5.2.0) lib/action_dispatch/journey/router.rb:35:in `serve'
actionpack (5.2.0) lib/action_dispatch/routing/route_set.rb:840:in `call'
railties (5.2.0) lib/rails/engine.rb:524:in `call'
railties (5.2.0) lib/rails/railtie.rb:190:in `public_send'
railties (5.2.0) lib/rails/railtie.rb:190:in `method_missing'
actionpack (5.2.0) lib/action_dispatch/routing/mapper.rb:19:in `block in <class:Constraints>'
actionpack (5.2.0) lib/action_dispatch/routing/mapper.rb:48:in `serve'
actionpack (5.2.0) lib/action_dispatch/journey/router.rb:52:in `block in serve'
actionpack (5.2.0) lib/action_dispatch/journey/router.rb:35:in `each'
actionpack (5.2.0) lib/action_dispatch/journey/router.rb:35:in `serve'
actionpack (5.2.0) lib/action_dispatch/routing/route_set.rb:840:in `call'
rack-pjax (1.0.0) lib/rack/pjax.rb:12:in `call'
rack (2.0.4) lib/rack/method_override.rb:22:in `call'
rack (2.0.4) lib/rack/session/abstract/id.rb:232:in `context'
rack (2.0.4) lib/rack/session/abstract/id.rb:226:in `call'
actionpack (5.2.0) lib/action_dispatch/middleware/cookies.rb:670:in `call'
remotipart (1.3.1) lib/remotipart/middleware.rb:32:in `call'
rack (2.0.4) lib/rack/etag.rb:25:in `call'
rack (2.0.4) lib/rack/conditional_get.rb:25:in `call'
rack (2.0.4) lib/rack/head.rb:12:in `call'
actionpack (5.2.0) lib/action_dispatch/middleware/callbacks.rb:28:in `block in call'
activesupport (5.2.0) lib/active_support/callbacks.rb:98:in `run_callbacks'
actionpack (5.2.0) lib/action_dispatch/middleware/callbacks.rb:26:in `call'
actionpack (5.2.0) lib/action_dispatch/middleware/executor.rb:14:in `call'
rollbar (2.15.5) lib/rollbar/middleware/rails/rollbar.rb:24:in `block in call'
rollbar (2.15.5) lib/rollbar.rb:145:in `scoped'
rollbar (2.15.5) lib/rollbar/middleware/rails/rollbar.rb:22:in `call'
actionpack (5.2.0) lib/action_dispatch/middleware/debug_exceptions.rb:61:in `call'
rollbar (2.15.5) lib/rollbar/middleware/rails/show_exceptions.rb:22:in `call_with_rollbar'
actionpack (5.2.0) lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
railties (5.2.0) lib/rails/rack/logger.rb:38:in `call_app'
railties (5.2.0) lib/rails/rack/logger.rb:28:in `call'
actionpack (5.2.0) lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
actionpack (5.2.0) lib/action_dispatch/middleware/request_id.rb:27:in `call'
rack (2.0.4) lib/rack/runtime.rb:22:in `call'
activesupport (5.2.0) lib/active_support/cache/strategy/local_cache_middleware.rb:29:in `call'
actionpack (5.2.0) lib/action_dispatch/middleware/executor.rb:14:in `call'
actionpack (5.2.0) lib/action_dispatch/middleware/static.rb:127:in `call'
rack (2.0.4) lib/rack/sendfile.rb:111:in `call'
railties (5.2.0) lib/rails/engine.rb:524:in `call'
puma (3.11.3) lib/puma/configuration.rb:225:in `call'
puma (3.11.3) lib/puma/server.rb:624:in `handle_request'
puma (3.11.3) lib/puma/server.rb:438:in `process_client'
puma (3.11.3) lib/puma/server.rb:302:in `block in run'
puma (3.11.3) lib/puma/thread_pool.rb:120:in `block in spawn_thread'

Facing the same problem on 2.5.1, Rails 5.2, Mongoid 7.0.1, RailsAdmin 1.3.

Hello, I have the same problem with Mongoid 7.1.0, RailsAdmin 1.3.0 and Rails 5.2.0.


照片人物完全没法分割出来呀，难道是我用的方法不对？

挺帅

No, you are right. I have never seen a good case in real use of this model.


Invalid format in buttons

Provide the exact quote of the error or issue
The following are missing and need to be added in buttons:
Invalid format
Title should be Example Title instead of ExampleTitle

Invalid format for PrimaryButton in contents/forms/buttons/primary-button/metadata.json

Does the feature already exist? Please link to it.
No response
Are you willing to participate in fixing this issue and create a pull request with the fix?
None

fixed in pull request #327


reworks SQLite and puTxMeta

Description
adds all putTxMeta
Linked issue
Type of change

[ ] 🐞 Bug fix (non-breaking change which fixes an issue)
[x] 🛠 New feature (non-breaking change which adds functionality)
[ ] ⚠ Breaking change (fix or feature that would cause existing functionality to change)
[ ] 🏭 Refactoring that does not change existing functionality but does improve things like code readability, structure etc
[ ] 🔨 New or improved tests for existing code
[ ] ⛑ git-flow chore (backport, hotfix, etc)

Developer checklist

[ ] I have read the style guide document, and my code follows the code style of this project.
[ ] If my code deals with exceptions, it follows the guidelines.
[ ] I have updated any documentation accordingly, if needed. Documentation changes can be reflected in opening a PR on cardanodocs.com, amending the inline Haddock comments, any relevant README file or one of the document listed in the docs directory.
[ ] CHANGELOG entry has been added and is linked to the correct PR on GitHub.

Testing checklist

[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

QA Steps

Screenshots (if available)

Obsoleted by https://github.com/input-output-hk/cardano-sl/pull/3407 .


[1.12] Items shows up in every Creative Tab

The Items from Garden Stuff show up in every Creative Tab (even Vanilla Tabs), not only in the Garden Stuff Tab.
EDIT: Not all Items are affected as I've seen it now. Affected are: Iron Nugget, Iron/Gold Link, Wrought Iron Nugget/Ingot/Link, Candelilla and Wax. And these are always the same one.
Using:
forge-<IP_ADDRESS>2
GardenStuff1.12-2.0.0

Oh yeah.  I even knew about this but forgot to fix it before release :E

This should be fixed under Chameleon 4.1.3.


Fix windows compiler error in kmac_prov.c

Error is seen here: https://ci.appveyor.com/project/openssl/openssl/builds/38653748

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

Attempted to add --strict-warnings to the minimal windows build - but it failed badly..
https://github.com/openssl/openssl/pull/14852

Marked as 'urgent' since this breaks all appveyor builds.. (Which are queued for a long time)

Agreed, urgent enough.  Merged to master.


Can't tail container logs when docker is using an API version prior to 1.25

Describe what happened:
Can't tail container logs when docker has a API version prior to 1.25
Describe what you expected:
Be able to tail container logs on any version latter to1.18
Steps to reproduce the issue:
Install docker 1.12

Fixed with #1301, closing


Remove v1.6 from docs

What are you changing in this pull request and why?
Removes v1.6 from the dropdown.
Removes content where v1.6 was "lastversion"
Cleans up "firstversion="1.7" blocks
Removes appropriate page version blocks
Checklist

[ ] I have reviewed the Content style guide so my content adheres to these guidelines.
[ ] The topic I'm writing about is for specific dbt version(s) and I have versioned it according to the version a whole page and/or version a block of content guidelines.
[ ] I have added checklist item(s) to this list for anything anything that needs to happen before this PR is merged, such as "needs technical review" or "change base branch."
[ ] The content in this PR requires a dbt release note, so I added one to the release notes page.

🚀 Deployment available! Here are the direct links to the updated files:

https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/docs/build/metricflow-time-spine
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/docs/build/packages
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/docs/build/saved-queries
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/docs/build/semantic-models
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/docs/core/connect-data-platform/about-core-connections
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/docs/core/connect-data-platform/glue-setup
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/docs/core/connect-data-platform/spark-setup
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/docs/core/connect-data-platform/teradata-setup
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/faqs/Core/install-pip-os-prereqs
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/faqs/Core/install-python-compatibility
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/artifacts/run-results-json
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/commands/cmd-docs
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/commands/deps
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/commands/init
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/dbt_project.yml
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/global-configs/resource-type
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/node-selection/methods
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-configs/access
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-configs/bigquery-configs
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-configs/contract
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-configs/databricks-configs
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-configs/enabled
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-configs/group
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-configs/meta
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-configs/postgres-configs
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-configs/redshift-configs
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-configs/snowflake-configs
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-properties/config
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/reference/resource-properties/freshness

I saw a few 1.6 references that might be worth removing:

https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/docs/collaborate/govern/model-versions#why-version-a-model Paragraph beginning with "dbt Core 1.6 introduced"
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/best-practices/clone-incremental-models
https://docs-getdbt-com-git-eol-dbt-labs.vercel.app/docs/collaborate/govern/project-dependencies#prerequisites (maybe just supported version of dbt" is good enough here)

Otherwise it looks good!

Thanks @runleonarun Anywhere it's indicating a prerequisite, I left it in. I did update some of the language to be consistent elsewhere.
I left it in the Model Version doc because it tells a story about when we created it and why we used the feature.


♻ Tiny Improvements

This PR adds the following (mostly chore-related) changes:

Adds a CI pipeline that checks the format for md, yml, yaml, and rs files, ensures no typos, and validates all links;
Adds the AGPL License if you're fine with it;
Improves the docs;

This is sweet! For the license, let's do an MIT license instead?

Sure, will push tomorrow!

This is sweet! For the license, let's do an MIT license instead?

Fixed via f74e4cfeadce5e9257b61c3b6d507aad00aa23ff and 18b01c64c4d6ed6127644312fc9a36bc21835738.


fix: ignore all @strapi/* updates

Strapi cannot be updated one by one package and should be checked for migrations

:tada: This PR is included in version 1.3.12 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[Node.js] $lt with limit not working

db.find({
    selector: { ts: { $lt: endts } },
    limit: 5,
    sort: [{ ts: 'desc' }]
  })

Code is like this. I have a collection indexed by ts. Every time I fetch more, it gives me 4 records instead 5.
Versions:
"pouchdb": "^6.0.6",
"pouchdb-find": "^0.10.3",
Server:
<EMAIL_ADDRESS>

I am experiencing a perhaps related issue.
Here is my selector:
{
    "selector": {
        "_id": {
            "$gt": "surgery_case.",
            "$lt": "surgery_case."
        }
    }
}

I have a database with hundreds of records. 32 of these have an _id that starts with the "surgery_case." prefix. If I do not set a limit, the above query only returns 25 of these records.
If I do set a limit of, say, 35 the above query will return all 32 records.
NOTE: The special character at the end of the $lt clause is the character with code 0xffff.

CouchDB Mango defaults to only returning 25 docs. This is a configuration
option. I think in future releases you can configure it in the config.ini.
On 6 February 2017 at 23:55, John David Eriksen<EMAIL_ADDRESS>wrote:

I am experiencing a perhaps related issue.
Here is my selector:
{
"selector": {
"_id": {
"$gt": "surgery_case.",
"$lt": "surgery_case.�"
}
}
}
I have a database with hundreds of records. 32 of these have an _id that
starts with the "surgery_case." prefix. If I do not set a limit, the
above query only returns 25 of these records.
If I do set a limit of, say, 35 the above query will return all 32
records.
NOTE: The special character at the end of the $lt clause is the character
with code 0xffff.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nolanlawson/pouchdb-find/issues/215#issuecomment-277826610,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAK9AlVk7hO6Iv7B7VEPPZRylSPpv9_Aks5rZ5bMgaJpZM4KQe9S
.

This issue was moved to pouchdb/pouchdb#6263


morty: init -> 0.1.0

Motivation for this change
This tool complements searx (from the same author), and provides a proxy service that can be used for visiting search results from the search engine.
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[x] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

@GrahamcOfBorg eval

I removed the fixed uid/gid mapping, under the assumption that a proxy has little worthwhile state.

@GrahamcOfBorg test morty

Failure on x86_64-linux (full log)
Partial log (click to expand)
while evaluating ‘dischargeProperties’ at /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:386:25, called from /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:324:62:
while evaluating the attribute ‘condition’ at /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:467:14:
while evaluating the attribute ‘condition’ at /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:467:14:
while evaluating the attribute ‘condition’ at /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:467:14:
while evaluating the attribute ‘services.nixosManual’ at /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/attrsets.nix:199:44:
while evaluating anonymous function at /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:75:45, called from /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/attrsets.nix:199:52:
while evaluating ‘yieldConfig’ at /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:74:29, called from /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:77:16:
while evaluating anonymous function at /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:80:24, called from /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:80:11:
while evaluating anonymous function at /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:81:26, called from /var/lib/gc-of-borg/.nix-test-rs/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/ogden/lib/modules.nix:81:13:
The option `services.morty' defined in `<unknown-file>' does not exist.

Failure on aarch64-linux (full log)
Partial log (click to expand)
while evaluating 'dischargeProperties' at /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:386:25, called from /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:324:62:
while evaluating the attribute 'condition' at /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:467:14:
while evaluating the attribute 'condition' at /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:467:14:
while evaluating the attribute 'condition' at /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:467:14:
while evaluating the attribute 'services.nixosManual' at /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/attrsets.nix:199:44:
while evaluating anonymous function at /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:75:45, called from /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/attrsets.nix:199:52:
while evaluating 'yieldConfig' at /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:74:29, called from /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:77:16:
while evaluating anonymous function at /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:80:24, called from /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:80:11:
while evaluating anonymous function at /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:81:26, called from /var/lib/gc-of-borg/nix-test-rs-1/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-1/lib/modules.nix:81:13:
The option `services.morty' defined in `<unknown-file>' does not exist.

@GrahamcOfBorg test morty

No attempt on aarch64-linux (full log)
The following builds were skipped because they don't evaluate on aarch64-linux: tests.morty
Partial log (click to expand)
while evaluating the attribute 'values' at /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/lib/modules.nix:434:7:
while evaluating 'concatMap' at /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/lib/lists.nix:104:18, called from /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/lib/modules.nix:434:16:
while evaluating 'concatMap' at /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/lib/lists.nix:104:18, called from /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/lib/modules.nix:324:17:
while evaluating anonymous function at /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/lib/modules.nix:324:28, called from undefined position:
while evaluating 'dischargeProperties' at /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/lib/modules.nix:392:25, called from /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/lib/modules.nix:325:62:
while evaluating the attribute 'value' at /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/lib/modules.nix:216:48:
while evaluating the attribute 'config.uid' at /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/nixos/modules/services/networking/morty.nix:76:9:
while evaluating the attribute 'ids.uids.morty' at /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/lib/attrsets.nix:199:44:
attribute 'morty' missing, at /var/lib/gc-of-borg/nix-test-rs-12/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/grahamc-aarch64-community-12/nixos/modules/services/networking/morty.nix:76:15

No attempt on x86_64-linux (full log)
The following builds were skipped because they don't evaluate on x86_64-linux: tests.morty
Partial log (click to expand)
while evaluating the attribute 'values' at /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/lib/modules.nix:434:7:
while evaluating 'concatMap' at /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/lib/lists.nix:104:18, called from /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/lib/modules.nix:434:16:
while evaluating 'concatMap' at /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/lib/lists.nix:104:18, called from /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/lib/modules.nix:324:17:
while evaluating anonymous function at /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/lib/modules.nix:324:28, called from undefined position:
while evaluating 'dischargeProperties' at /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/lib/modules.nix:392:25, called from /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/lib/modules.nix:325:62:
while evaluating the attribute 'value' at /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/lib/modules.nix:216:48:
while evaluating the attribute 'config.uid' at /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/nixos/modules/services/networking/morty.nix:76:9:
while evaluating the attribute 'ids.uids.morty' at /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/lib/attrsets.nix:199:44:
attribute 'morty' missing, at /home/ofborg/ofborg3/repo/38dca4e3aa6bca43ea96d2fcc04e8229/builder/builder-7c6f434c3/nixos/modules/services/networking/morty.nix:76:15

Success on aarch64-linux (full log)
Attempted: tests.morty
Partial log (click to expand)
mortyProxyWithKey: running command: sync
mortyProxyWithKey# [   17.568988] dhcpcd[765]: eth0: Router Advertisement from fe80::2
mortyProxyWithKey# [   17.577832] dhcpcd[765]: eth0: adding address fec0::5054:ff:fe12:3456/64
mortyProxyWithKey: exit status 0
test script finished in 18.50s
cleaning up
killing mortyProxyWithKey (pid 627)
vde_switch: EOF on stdin, cleaning up and exiting
vde_switch: Could not remove ctl dir '/build/vde1.ctl': Directory not empty
/nix/store/3lchhnjr9zyimaj62j3g9whz0shqbzx7-vm-test-run-morty

LGTM, though to be strictly conforming to the guidelines this should ideally be one commit for the package and one for the service, with appropriate commit subjects.

@joachifm: split into one commit for the package and one for the service.


Generate lookup tables

there is some current script that does it for sections of the sepctrums
find a bragg and then finds the maximum, for 10-15 Bragg angles
IDGAP lookup table

@callumforrester  where to best cache values like lookup tables that change a couple of times during a run. or for a different experiment. ideally during comissioning automatically. 15 different hfiles for different harmonics here

for each energy there happens an optimization of the undulator gap SR. then it is move the Bragg angle given a crystal cut. crystal spacing is what we need - Ge Si for this. then move to the Bragg angle, scan the gap
then we measure at one of the diods, maby eD7 - BL18I-DI-PHDGN-07 - instant rbv
w eget a curve, with a peak and then the peak
columns: energy of monochromator, gap fot he undulator
then we make a quadratic curve. we need to cache a python callable.

I believe MX have been using redis for this @dperl-dls may know more...

We'd like to be using redis for things like this, currently we're just using it for feature flag lookup live. This kind of thing is definitely on the roadmap though.
@aragaod does use redis to cache some expensive parameters, but that's his personal deployment for one beamline, hasn't had any input from us. It's enough to say that it works well for this use case but we'll want something properly supported if we're going to be relying on it seriously, or at least have very good fallback options

I have some python code that does lookup tables for me.
Basically
Changes energy, waits for feedback to recover, gather valuee, stores in redis.
Then at the end a piece of python3 outside GDA gathers the data from redis and in one case uses jinja2 template to generate the text file GDA formatted lookup style file and in other case calculate the coefs for a polinomial based on the redis data. Then pushes does coefs to the respective holder epics PVs.
Because I could not install redis in jython I wrote a urllib based jython implementation and have a http to redis api jython talks too. All working for 5 years. Our redis server runs on i04-control has in 5 years has never failed us.
We also use redis for a variety of other purposes from caching to temporary storage of data in JSON format for later use outside gda. Most redis keys are setup with an expiry so we see redis as volatile data not long term.
Would be great to have a redis server side by side with every beamline and consider it part of the infrastructure. It is incredibly useful.

there is a separate issue to explore this already, so it looks like we're on the right track
https://github.com/DiamondLightSource/blueapi/issues/537

@aragaod could you link me the code please?

dodal DCM

#Bragg angle against roll( absolute number)
#reloadLookupTables()

last update 2023/01/19 NP
Units Deg mrad
26.4095 -0.2799
6.3075  -0.2799
it's in dodal/devices/unit_tests/test_daq_configuratino/lookup/BeamLineEnergy_DCM_Roll_converter.txt

$ helm install my-redis bitnami/redis --version 19.6.3
Error: INSTALLATION FAILED: 2 errors occurred:
        * admission webhook "validate.kyverno.svc-fail" denied the request:

policy StatefulSet/i18-beamline/my-redis-replicas for resource violations:

custom-drop-capabilities:
  autogen-validate-capabilities-hostNetwork-not-set: 'validation failure: The list
    spec.securityContext.drop must include NET_RAW'
  autogen-validate-capabilities-hostNetwork-true: preconditions not met
kp-validate-custom-validate-user-and-group-ids:
  autogen-validate fsgroup ids: preconditions not met
  autogen-validate group id: preconditions not met
  autogen-validate supplemental group ids: preconditions not met
  autogen-validate user id: preconditions not met
kp-validate-hostpath-restrictions-custom:
  autogen-enforce absolute paths: preconditions not met
  autogen-restrict directories: preconditions not met

        * admission webhook "validate.kyverno.svc-fail" denied the request:

policy StatefulSet/i18-beamline/my-redis-master for resource violations:

custom-drop-capabilities:
  autogen-validate-capabilities-hostNetwork-not-set: 'validation failure: The list
    spec.securityContext.drop must include NET_RAW'
  autogen-validate-capabilities-hostNetwork-true: preconditions not met
kp-validate-custom-validate-user-and-group-ids:
  autogen-validate fsgroup ids: preconditions not met
  autogen-validate group id: preconditions not met
  autogen-validate supplemental group ids: preconditions not met
  autogen-validate user id: preconditions not met
kp-validate-hostpath-restrictions-custom:
  autogen-enforce absolute paths: preconditions not met
  autogen-restrict directories: preconditions not met

I see that Sci-Comp resolved the issue for i18 cluster (which had previously been seen on another beamline cluster, but the fix not applied to other clusters), but it begs the question (or I beg the question with the issue as justification): central redis or per-beamline redis?

tested-on-beamline redis is the first step in both paths anyway
redis is a fast cache and per-beamline would be the fastest. We might try some experimentation with plan calling either the central or the local one and measuring the response time. or just the delay in pinging either server as a low-effort version?

redis deployment notes:
$ helm install blue-redis oci://registry-1.docker.io/bitnamicharts/
redis
Pulled: registry-1.docker.io/bitnamicharts/redis:19.6.4
Digest: sha256:42bd28a5365ce7da88e2fafec59cd4eb41827db26b2e42050dc6e6607baaaa51
NAME: blue-redis
LAST DEPLOYED: Mon Jul 29 16:51:04 2024
NAMESPACE: i18-beamline
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
CHART NAME: redis
CHART VERSION: 19.6.4
APP VERSION: 7.2.5

** Please be patient while the chart is being deployed **

Redis® can be accessed on the following DNS names from within your cluster:

    blue-redis-master.i18-beamline.svc.cluster.local for read/write operations (port 6379)
    blue-redis-replicas.i18-beamline.svc.cluster.local for read-only operations (port 6379)

To get your password run:

    export REDIS_PASSWORD=$(kubectl get secret --namespace i18-beamline blue-redis -o jsonpath="{.data.redis-password}" | base64 -d)

To connect to your Redis® server:

1. Run a Redis® pod that you can use as a client:

   kubectl run --namespace i18-beamline redis-client --restart='Never'  --env REDIS_PASSWORD=$REDIS_PASSWORD  --image docker.io/bitnami/redis:7.2.5-debian-12-r4 --command -- sleep infinity

   Use the following command to attach to the pod:

   kubectl exec --tty -i redis-client \
   --namespace i18-beamline -- bash

2. Connect using the Redis® CLI:
   REDISCLI_AUTH="$REDIS_PASSWORD" redis-cli -h blue-redis-master
   REDISCLI_AUTH="$REDIS_PASSWORD" redis-cli -h blue-redis-replicas

To connect to your database from outside the cluster execute the following commands:

    kubectl port-forward --namespace i18-beamline svc/blue-redis-master 6379:6379 &
    REDISCLI_AUTH="$REDIS_PASSWORD" redis-cli -h <IP_ADDRESS> -p 6379

WARNING: There are "resources" sections in the chart not set. Using "resourcesPreset" is not recommended for production. For production installations, please set the following values according to your workload needs:
  - replica.resources
  - master.resources
+info https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

should make an ophyd-async device fwiw

should make an ophyd-async device fwiw

For communicating with Redis? Disagree, it should be a plan stub.

@callumforrester said otherwise

after conversation, this could be implemented in the following ways:

ophyd-async device - where we this is similar to GDA scannable, but should work for now
stub - but this would block the runengine IO
a call back - but it's less handy for the optimization loop

for now we'll do an ophyd-async device

@callumforrester said otherwise, that RunEngine should never do IO on its own

This is not quite true, I said plans should never do I/O on their own, so you shouldn't have a plan that says
def my_plan():
    yield from mv(motor, 1)
    redis.put({"foo": "bar"})  # Does I/O!
    yield from mv(motor 2)

The plan should be runnable offline, so you should have a yield from and get the RunEngine to either do I/O directly by defining a custom verb or via a device, as @DominicOram et al. have been doing.

custom_verb - that's the first time when this has been mentioned, it might have the shape of the thing @DiamondJoseph was postulating, so as plan stubs.
still it's a more coupled solution, against the modular approach.

I think I would do this using a callback but given it's a commissioning script I think it needs to be:

As simple as possible - callbacks spread logic so are not easy to reason about
Doesn't need to be perfect code quality - it will usually be ran supervised and infrequently

So I wouldn't actually be too against the plan just doing the io itself

@callumforrester  mentioned quite strongly that plans running io themselves causes lack of determinism in the RunEngine.

I agree that a callback is the best solution for writing to the lookup table, I assume we're also figuring out how best to read from the lookup table?

There is already code to do the reading inside the ophyd device, which seems sensible to me

ok I have this and will work with this
https://github.com/DiamondLightSource/i18-bluesky/pull/14/files#diff-d9cd4b6e154a4ea75e73b8f832da87eb57d4d22bba935048f521c0e0df488075

IDGAP - is the only alignment kind one that uses the lookup
pinhole scan - to get the beam back through it
gold wire scan - without  lookup table - to check the size of the focal spot - ran if change to KB mirrors

after the meeting with @DominicOram  decision to put the logic in the event callbacks so that we do no calculations in the plan itself. the plan would use a composite undulator and dcm device

accomplished today locally with @iain-hall


External Data

Until Plugins are released to the API, I think I figured a way to grab external data and assign it a variable.
Initially sending date, top5 headlines, weather and SPY.
I might be able to have it 'listen' for key phrases that are asked of the AI, and invoke a call that pulls the external data in question. The external data at this point is predefined cause I have to figure out each sources quirks, json syntax, rss feeds, and the likes.

Oh yeah!
Now it only loads the data if the right keywords are asked. for example, asking "how is the weather" where weather is a trigger word to load the weather data. Currently being aggregated via the bash script.
Now I just need news sources to add, and the logic to get there.  Template to add bolts on in place now.


Why the extra impl for ZipSlices?

I was looking at the ZipSlices impl and noticed that you have the signatures  impl<'a, 'b, A, B> ZipSlices<&'a [A], &'b [B]> and impl<T, U> ZipSlices<T, U> where T: Slice, U: Slice. The latter seems a lot more general, and I was wondering why the former is still in the library? Are there some non-trivial reasons for this?

Yes, the reason is that the non-general one will force coercions, so it will actually work with arguments like '&Vec`, so it's actually easier to use. Only problem is I've basically inverted the names for the two methods..

If type parameter defaults change the story for coercions, we can talk about removing it, until then it's useful.

Type param defaults: rust-lang/rust/issues/27336


Seeded Estimator Occasionally Breaks

The seeded estimator will break and not allow any new launches of the node if Gazebo Classic breaks and somehow reports 0 as the lat/long/alt/pressure it throws an invalid type error where the string is cast to an int instead of a double. I think this is low priority, because either a fresh build or reverting the parameter changes will fix it, and because we will be decoupling the sensors from the sim relativity soon. That being said a type error like this should not be possible.
--EDIT-- This is actually a pretty big issue, it happens every time Gazebo implodes while rosplane is running

Okay so it is actually only during a specific gazebo crash, just the most common one. An easy way to avoid this is to launch rosplane only when Gazebo has been confirmed to have successfully launched.


fix brower fetch responese body has an error occurred with  using  after interception

fix brower fetch responese body has an error occurred with  using  after interception
may be fix #113 #138
This appears to be a duplicate of #150 #151.
but add more test cases than above.
BTW: preparation of test case writing

yarn run build (test case depends on the build artifact lib)
page-with knowledge.  (playwright awesome)

Thank you for preparing this, @SCWR! Also impressed by your preparation and the tests you've written down.
I will get to reviewing this in the nearest future so we can have this bug fix merged and propagated in the next release.

Meanwhile, please note that your first commit isn't associated with your GitHub user. Please rebase the pull request and edit the author for that commit. You can do so via:
git commit --amend --author="Author Name<EMAIL_ADDRESS>

Meanwhile, please note that your first commit isn't associated with your GitHub user. Please rebase the pull request and edit the author for that commit. You can do so via:
git commit --amend --author="Author Name<EMAIL_ADDRESS>
Make sure to use the same email as you have on GitHub.

I have modified and push.

Hey, @SCWR. I've reviewed the code and reworked the test suite a little to be minimalistic and still capture the issue. There's no need to test each method, as there's no method-specific logic on the library's side.

Hey, @SCWR. I've reviewed the code and reworked the test suite a little to be minimalistic and still capture the issue. There's no need to test each method, as there's no method-specific logic on the library's side.

The test cases are concise,  learned


Question: How to pass ssh client options?

Hi,
how do I pass ssh/sftp client options using the jmeter GUI:
-o option
Can be used to give options in the format used in the
configuration file.  This is useful for specifying options for
which there is no separate command-line flag.  For full details
of the options listed below, and their possible values, see
ssh_config(5).
               AddKeysToAgent
               AddressFamily
               BatchMode
               BindAddress
               CanonicalDomains
               CanonicalizeFallbackLocal
               CanonicalizeHostname
               CanonicalizeMaxDots
               CanonicalizePermittedCNAMEs
               CertificateFile
               ChallengeResponseAuthentication
               CheckHostIP
               Cipher
               Ciphers
               ClearAllForwardings
               Compression
               CompressionLevel
               ConnectionAttempts
               ConnectTimeout
               ControlMaster
               ControlPath
               ControlPersist
               DynamicForward
               EscapeChar
               ExitOnForwardFailure
               FingerprintHash
               ForwardAgent
               ForwardX11
               ForwardX11Timeout
               ForwardX11Trusted
               GatewayPorts
               GlobalKnownHostsFile
               GSSAPIAuthentication
               GSSAPIDelegateCredentials
               HashKnownHosts
               Host
               HostbasedAuthentication
               HostbasedKeyTypes
               HostKeyAlgorithms
               HostKeyAlias
               HostName
               IdentityFile
               IdentitiesOnly
               IPQoS
               KbdInteractiveAuthentication
               KbdInteractiveDevices
               KexAlgorithms
               LocalCommand
               LocalForward
               LogLevel
               MACs
               Match
               NoHostAuthenticationForLocalhost
               NumberOfPasswordPrompts
               PasswordAuthentication
               PermitLocalCommand
               PKCS11Provider
               Port
               PreferredAuthentications
               Protocol
               ProxyCommand
               ProxyUseFdpass
               PubkeyAcceptedKeyTypes
               PubkeyAuthentication
               RekeyLimit
               RemoteForward
               RequestTTY
               RhostsRSAAuthentication
               RSAAuthentication
               SendEnv
               ServerAliveInterval
               ServerAliveCountMax
               StreamLocalBindMask
               StreamLocalBindUnlink
               StrictHostKeyChecking
               TCPKeepAlive
               Tunnel
               TunnelDevice
               UpdateHostKeys
               UsePrivilegedPort
               User
               UserKnownHostsFile
               VerifyHostKeyDNS
               VersionAddendum
               VisualHostKey
               XAuthLocation

Sorry man I don't remember I have been notified about these messages, I know it is too late but I will answer in case of some other user needs to know the answer.
This plugin uses JSch to handle SSH protocol, it does not implement all these options but it does implement this: http://epaul.github.io/jsch-documentation/simple.javadoc/com/jcraft/jsch/JSch.html#setConfig-java.lang.String-java.lang.String-
We could implement these options by adding a component or by using a variable prefix, if anyone interested, we could set a PR up on this purpose.

@yciabaud These options should be quite easy to use from this plugin. On the cmd line it is used like this for example:
for port option: sftp -oPort=22333 user@host
for cipher option: sftp -oCiphers=aes128-ctr user@host
All that is needed is for a place in the plugin UI to enter options and then it should be added to the sftp/ssh cmd by the plugin logic. No parsing is even necessary in the logic really. The client does do some checking itself and will fail the connection if the options are incorrect.


add a driver option for injection of CodecRegistry

Yeah that makes sense, right now we allow injection of individual codecs, but for the whole registry there's no easy way apart from extending the driver context.
I wonder if we need a factory though. Another option would be to add SessionBuilder.withCodecRegistry(), and then inject it via ProgrammaticArguments the way it's already done for nodeStateListener, etc.
The rationale for config-based initialization is that some components need a reference to the context to fetch internal dependencies at construction time. For the codec registry I don't think this will be a common need, in general you know ahead of time which codecs you'll need.
Can you share more about your use case? Does your custom implementation need the context, or could it be created before the session?

Yeah that makes sense, right now we allow injection of individual codecs, but for the whole registry there's no easy way apart from extending the driver context.
I wonder if we need a factory though. Another option would be to add SessionBuilder.withCodecRegistry(), and then inject it via ProgrammaticArguments the way it's already done for nodeStateListener, etc.
The rationale for config-based initialization is that some components need a reference to the context to fetch internal dependencies at construction time. For the codec registry I don't think this will be a common need, in general you know ahead of time which codecs you'll need.
Can you share more about your use case? Does your custom implementation need the context, or could it be created before the session?

Hi, thanks for reviewing!
Initially I implemented this as SessionBuilder.withCodecRegistryBuilder(), the factory pattern is there so the creation method can still receive the session name and codecs like in buildCodecRegistry(this.sessionName, codecs). Do you think it's better to keep this on SessionBuilder rather than config?
Cheerio,
Tim

Let's just do the builder method for now. And I don't think we need a builder, just taking a registry instance should suffice:
withCodecRegistry(CodecRegistry)

We can always add a config option later if the need arises.

I've updated the patch to create a withCodecRegistry(CodecRegistry) method on SessionBuilder rather than the previous implementation which used driver options.

Merged, thanks for your contribution!


custom-resource.py overrides DefaultAction

if you change the WAF default action in the cloudformation the WAF is initially created with that default action but it is then overrridden when custom-resource.py runs.
            response = waf.update_web_acl(
                WebACLId=web_acl_id,
                ChangeToken=waf.get_change_token()['ChangeToken'],
                Updates=updates,
                DefaultAction={'Type': 'ALLOW'}
            )

Can the line be removed so this confusion is removed and the cloudformation value is honored?

This default action should apply for Web ACL’s default action. I mean, if any rule got trigged when a request is process, then the default action takes place.
The rules configured by custom resource are set to be added as block ... what if we add an extra input parameter in this template to ask what should be the rules’ action?

Hello,
I have a custom scenario where I want the default action to be "BLOCK".  I updated the cloudformation
"WAFWebACL": {
"Type": "AWS::WAF::WebACL",
"Condition": "CreateWebACL",
"DependsOn": [
"WAFWhitelistRule"
],
"Properties": {
"Name": {
"Ref": "AWS::StackName"
},
"DefaultAction": {
"Type": "BLOCK"
},
"MetricName": "SecurityAutomationsMaliciousRequesters",
"Rules": [
{
"Action": {
"Type": "ALLOW"
},
"Priority": 10,
"RuleId": {
"Ref": "WAFWhitelistRule"
}
}
]
}
},
but once custom-resource.py runs it changes it to "ALLOW".
I don't see a need for this line in the python script
DefaultAction={'Type': 'ALLOW'}
why not simply honor the cloudformation value?

I got your point!
We can't remove this parameter from update_web_acl as it seems to be required but I'll add an extra step to retrieve the current action instead assuming the it should be ALLOW.

@hvital
how I read the documentation is that if "DefaultAction" is passed then "Type" is required but I don't believe that "DefaultAction" is required

I miss understood the Type (string) -- [REQUIRED] boto doc. Lets just remove this parameter then :)
Just added a note to include this for the next update. Thanks for pointing this out!!

thanks!


capture location

other apps that may ask for access to captured media files are only given access to media folders such as DCIM. The camera app does not store its captured files in that location.
Use case: I installed a photo backup apk from my NAS vendor on grapheneos. Its file and media permissions are set to Allow access to media only. In the app, i can customize the backup source but can only see DCIM, DCIM -> OpenCamera, and Pictures. I cannot select Android/media/app.grapheneos.camera/Camera

I tried using this app, but it requires me to have some login credentials. But before we discuss more into that, I wanted to clarify something...

Other apps that may ask for access to captured media files are only given access to media folders such as DCIM. The camera app does not store its captured files in that location.

We have made the required changes to ensure that the app only uses the DCIM storage (along with some other supporting changes). Does this resolve your issue?

other apps that may ask for access to captured media files are only given access to media folders such as DCIM. The camera app does not store its captured files in that location.

The app now uses the device's default storage with the concept of scoped storage. That change has indirectly resolved this issue. Please do let us know if we misunderstood this issue by any chance.
Thanks a lot for reporting this issue!

I just downloaded and installed the alpha build that hit the repo a couple of hours ago. Storage location is accessible with media access privilege, confirmed this update has resolved the issue. Aside from that non-visible change, the visible updates to the app and its control panel look very nice.

I have release<PHONE_NUMBER> tag SP1A.210812.015.2021102300 installed on a pixel 4a. Photos taken by the camera are stored in /Pictures instead of /DCIM/Camera. This change in behavior started a week or two ago, I'm not certain which OTA release broke it.

Release SP1A.210812.015.2021102300 uses AOSP Camera, not this app.

AOSP Camera changed location for photos in AOSP 12. Nothing to do with this. It also wasn't a change made by GrapheneOS.

Thanks for the clarity, thestinger.
DCIM has been used for photos on phones for as long as I remember.
Is it just a coincidence that both the new GrapheneOS Camera app and the old AOSP 12 Camera app have just decided to store photos in a new, non-standard place? Or has some android spec changed, and the path is obtained by a system call, and that has changed. If so, all media, backup, and other apps that access photos have to be updated to accommodate user photos existing in two places now.

That's not true. Read what was written. Stop posting off-topic stuff here.


fix comment in ./miri

pointed out in https://github.com/rust-lang/miri/pull/2288#discussion_r915445912

@bors r+

:hourglass: Testing commit 52abae6826277f350723823968ce468d061c3a1d with merge 622963a2df22bdb91f3db076e3a7aa399d2dca0f...

:sunny: Test successful - checks-actions
Approved by: RalfJung
Pushing 622963a2df22bdb91f3db076e3a7aa399d2dca0f to master...


Dependency conflict on ecto with phoenix 0.14

Since phoenix 0.14 uses ecto 0.13.1, and here we are trying to use 0.12.1 we get a dependency conflict. Could you update timex_ecto to use ecto 0.13.1?
Alternatively, is there a way to bypass this conflict?
Thanks. 😊

@vsmart Sure I can do that, just so you know though, you can always override the dependency at the top level with:
def deps do
  [{:ecto, "~> x.x.x", override: true}, ...]
end

This forces your application to use the version of ecto you specified. Hope that helps :)

Thank you! :+1: :tada:

Just FYI, I pushed a new release 0.3.0 which is updated to use the latest ecto version :)

Thanks again. :cake:


about the average indicator value

Great job. I have a small question. I used the checkpoint you gave and calculated the indicators in inference. I found that the average value of psnr was 30.32, ssim was 0.93, and nmse was 0.034. They are different from the values in the paper. What is wrong with me?

Maybe you only use the inference.py to eval metric.  It‘s just a reference.  This file "our_paper_metric.py" will help you.


added ceph osd create

Like @leseb said, if you create an OSD, you need to capture the created id and use it.    Either the OSD_ID must be set or the directory must be appropriately named.  So far as I know, you cannot tell ceph osd create which id to create, which makes it unusable in this container, as is.
That said, I do think it is torturous to have to know the id in advance, and I do want to design a more automated approach.  Unfortunately, this PR alone will not do that, and it doors not work at all, except in very special circumstances (strict, linear additions of OSDs with no skips in the lineup).  Moreover, it has the potential to create a huge number of unused OSDs, without bound.

Just a disclaimer, I'm a complete newbie with ceph and was just trying a bunch of random things to get the various Docker Ceph containers to work.
I was finally able to get ceph/mon, osd, and mds to work and was able to mount cephfs on a client.
And I was not able to get it to work with this line in the script.
Please feel free to delete this PR if it's not the right solution.
But please also update the documentation on how to get the stack to work properly.

Thanks for your understanding.
The OSD doc says:
To create your OSDs simply run the following command:
docker exec <mon-container-id> ceph osd create.
This is the way to setup it.

@mingfang Sorry if I was overly harsh-sounding.  I have a tendency toward succinctness, particularly when mobile.
We do appreciate the feedback, input, and help, and I don't want to dissuade you from providing it.
I can certainly understand the confusion, and I definitely do want to modify the container such that it will work a bit more intuitively.

no worries.
thanks for your help.


Add devspace to common installers (brew, npm, chocolate etc.)

devspace is available in brew and npm at this point so I think it is safe to close this out, so... closing! 🥳


Avoid counting lines of code in parallel with running queries

This can lead to OOME in larger repositories. Unfortunately, running
the LoC serially will cause the action to take longer, but I don't think
there is any other way around this.
Fixes https://github.com/github/codeql/issues/5873
I am running an analysis in a forked version the repository mentioned in that issue.
This run https://github.com/aeisenberg/Mudlet/runs/2557912173?check_suite_focus=true is using the current version of the action (ie- counting in parallel). I will do another run with the count happening after the queries are completed.
Merge / deployment checklist

[x] Confirm this change is backwards compatible with existing workflows.
[x] Confirm the readme has been updated if necessary.

This change is no longer necessary.


Reduce performance hit of recursive mutex

The recursive mutex code seemed to negatively effect some time critical code, so the code was reworked slightly
for the regular mutex methods, but additional explciit mutex_funx_r() and mutex_func_nr() vairants were added for
recursive mutexes and non recursive mutexes respectively.
It might have been nice to swtich to different mutex types for recursive/non recursive (which i had considered
when adding recursive mutexes), but that is a bit too fraught with backwards compatibility issues.
I imagine not that many people care about the performance of this so critically that they much care (which is why the _r and _nr names are a bit oblique - the naming was a bit confusing as they will silently fail in release mode for the wrong type of mutex)

This is probably a silly suggestion, but could it be worth adding mutex_init_nr as an alias of mutex_init and mutex_init_r as an alias of recursive_mutex_init ?

auto_init_recursive_mutex still references .recursion_state ? And once that's "fixed" (if it is indeed a bug) I think you can/could also then get rid of MAX_RECURSION_STATE?

Just for future reference, it might be worth adding a note to the commit-comment that the spelling of mutex_is_initialized has been "fixed" too? (or is that function internal-use-only?)

mutex_try_enter_r_guts still checks  && mtx->recursive which I think isn't necessary?
Should there also be mutex_enter_block_until_nr and mutex_enter_block_until_r specialisations, or is that function inherently less timing-critical?

i've decided that this is a case of trying to correct a wrong with another wrong. I am going to make a backwards compatible change to split mutex back to being non recursive and use a separate rmutex for recursive. I will attempt to add a #define to allow 1.2.0 code using recursive mutex to work


RFC: Component stores

Since v1, a lot has been improved in the library regarding state management. Most notably:

#487
#744
#745

I'm still not completely satisfied with that, though. There are still a few issues remaining, and I believe component stores will solve them all while keeping the progress we've made so far.
The problems
Currently, this is how state hooks look like:
function App() {
  const dialog = useDialogState({ defaultOpen: true }); // state hook
  const mounted = dialog.mounted; // state value
  const show = dialog.show; // state method
  return (
    <>
      <button onClick={show}>Show modal</button>
      {mounted && <Dialog state={dialog}>Content</Dialog>}
    </>
  );
}

We can't reuse the state logic outside of React
As we work to make the library framework-agnostic, it's important that we reuse as much code as possible to avoid having to maintain huge libraries with similar logic but different sources for each framework.
The way state hooks are implemented today, using React's built-in hooks like useState, prevents us from reusing them in other frameworks. This was done like that so that the state would be compatible with the concurrent features in React.
Host components render on every state update
Consider the following example:
function Host() {
  const select = useSelectState();
  const value = select.value;
  return (
    <>
      <Select state={select}>{select.value}</Select>
      <SelectPopover state={select}>
        <SelectItem value="Apple" />
        <SelectItem value="Orange" />
        <SelectItem value="Watermelon" />
      </SelectPopover>
    </>
  );
}

Although we're only reading the value state, the Host component will render on every change in the select state. For example, when the user presses arrow keys to move through select items, the select.activeId state will update, triggering a render in our Host component, even though it doesn't depend on the active id value.
That's generally not a problem unless the Host component becomes too complex with expensive unmemoized computations. Even in these cases, simply abstracting the components and colocating the state like we do in the MenuBar example is the solution. However, this solution may not always be obvious, especially when you combine different components (e.g. Select with Combobox). In real-world apps, I've seen more and more of these complex components.
Methods as deps in useEffect, useCallback, etc.
Sometimes, we need to use a state method inside a useEffect or useCallback function:
const select = useSelectState();

useEffect(() => {
  select.setValue("");
}, []); // warning

That works because select.setValue is referentially stable, but the React Hooks ESLint plugin will show the following warning:

React Hook useEffect has a missing dependency: 'select'. Either include it or remove the dependency array. (react-hooks/exhaustive-deps)

If the user follows the proposed solution and adds select to the deps array, now the effect will run on every change in the select state, as the select object itself changes whenever the state is updated.
The solution is to ignore the warning, which I think most people would be wary of doing, or to destructure the methods before passing them to the deps, which is also not obvious:
const select = useSelectState();
const { setValue } = select;

useEffect(() => {
  setValue("");
}, [setValue]); // no warning

Component stores
This is how component stores would look like:
function App() {
  const dialog = useDialogStore({ defaultOpen: true }); // store hook
  const mounted = dialog.useState("mounted"); // state value
  const show = dialog.show; // store method
  return (
    <>
      <button onClick={show}>Show modal</button>
      {mounted && <Dialog store={dialog}>Content</Dialog>}
    </>
  );
}

Differences from the current state hook API:

State Hooks
Component Stores

useDialogState()
useDialogStore()

dialog.mounted
dialog.useState("mounted")

state={dialog}
store={dialog}

We can reuse the state logic outside of React
The store would be implemented with vanilla JS so we can reuse it in other frameworks. The React hook would use the useSyncExternalStore hook internally, so we can keep it compatible with concurrent rendering.
Host components re-render only when state is used
In the example below, Host will re-render only when the value state changes:
function Host() {
  const select = useSelectStore();
  const value = select.useState("value");
  return (
    <>
      <Select store={select}>{select.value}</Select>
      <SelectPopover store={select}>
        <SelectItem value="Apple" />
        <SelectItem value="Orange" />
        <SelectItem value="Watermelon" />
      </SelectPopover>
    </>
  );
}

Methods as deps in useEffect, useCallback, etc.
The object returned by the store hook is always referentially stable so it can be safely included in the deps array of useEffect, useCallback, etc.:
const select = useSelectStore();

useEffect(() => {
  select.setValue("");
}, [select]); // no warning, equivalent to []

Extra
Besides solving the aforementioned problems and maintaining the improvements introduced by state hooks (discussed in the previous RFCs), component stores also unlock some new possibilities.
Accessing state inside event handlers without re-rendering
If a state value is used only inside event handlers, there's no need to useState. We can access the state directly without triggering a new render when the state changes:
const dialog = useDialogStore();

const onClick = () => {
  // Accessing the state directly in an event handler doesn't trigger renders
  const { mounted } = dialog.getState();
  if (mounted) {
    // ...
  }
}

Computed selectors
Consider the SelectItem component. While the user navigates through the items, this component will set the aria-selected attribute to true or false based on the select's activeId state.
However, if we do select.useState("activeId"), all the SelectItem elements will re-render on every activeId change, even when the change is not related to that specific SelectItem.
Internally, we already optimize this so our SelectItem component only re-renders when it's the current/previous active item. But we don't expose this feature.
With component stores, this can be easily achieved in userland:
const id = useId();
// Re-renders only when isActiveItem changes from true to false and vice-versa
const isActiveItem = select.useState((state) => state.activeId === id);

Passing store around as a prop/context
Since the store object is always referentially stable, it can be safely passed as a prop to memoized components and as a context value without impacting performance. Features like field-level validation with memoized input components will be much easier to implement.

@diegohaz did you have a store backend in mind? I'm having a difficult time imagining how this would bridge over to other component libraries without understanding how the implementation would work for this proposal.
Is the useSelectStore function described here returning a state object as returned by useSyncExternalStore?

@sarayourfriend I have a POC here: https://codesandbox.io/s/ariakit-component-stores-forked-248do5?file=/src/dom/disclosure-store.ts
useSelectStore returns a stable store object with updater functions and nested hooks. store.useState() returns a state using useSyncExternalStore.

I see! This makes a lot more sense.
I think it could be easily adapted to Vue. I'll sketch up a version of react/store.ts but for Vue later today :slightly_smiling_face:

Very interesting. I followed a similar pattern with useSyncExternalStore in one of my recent projects. This appears to be a more generic and granular implementation which only notifies subscribers of updates for the property keys they specify.
It would indeed enable you to re-use some state logic in a way that isn't tied to a particular framework. In my case, I use the same class for my game's state in both the React frontend and on the server. With this class implementation, all of my state properties and methods live together and be run entirely on their own. The properties are easily serializable, so I can send it back and forth between client and server and each can manipulate the state using those class methods. The methods themselves notify subscribers when properties change. The trick is that it all relies on referential inequality checks, so immutable datatypes for the properties are a must for them to be subscribed to.
What I particularly like about your approach is selectively subscribing to only the property updates you care about, which does indeed reduce renders.
I can see this working out, but my only reservation is with the store.useState() method and how verbose that could end up being (forces the creation of listeners for each property you want to subscribe to, rather than just being able to destructure, for ex). Sufficiently complex components could suffer from this. So, the thing I like has its own tradeoffs, which I'm not sure if there is a way to make more ergonomic for the end user.
Might come back to this later with more thoughts. Would be happy to jump on a call sometime and jam on the idea though.

I can see this working out, but my only reservation is with the store.useState() method and how verbose that could end up being (forces the creation of listeners for each property you want to subscribe to, rather than just being able to destructure, for ex). Sufficiently complex components could suffer from this. So, the thing I like has its own tradeoffs, which I'm not sure if there is a way to make more ergonomic for the end user.

We thought about some APIs to make that less verbose.
For example, with multiple arguments:
const { mounted, animating } = store.useState("mounted", "animating");

But we can't support computed selectors with that API. So there's the object API:
const { mounted, animating, isActiveItem } = store.useState({
  mounted: true,
  animating: true,
  isActiveItem: (state) => state.activeId === id,
});

But I think this makes the API more complicated and harder to teach. And, to be honest, it doesn't seem much less verbose than this:
const mounted = store.useState("mounted");
const animating = store.useState("animating");
const isActiveItem = store.useState((state) => state.activeId === id);

And I doubt people would need to access more than 1-2 state values in the render phase in 99% of use cases. At least we don't have such a use case in our current examples.

Here is a shot at a Vue implementation: https://codesandbox.io/s/ariakit-component-stores-forked-i9z47h?file=/src/vue/store.ts
It's almost laughably simple, to the point where I doubt that it behaves as expected? But I can't see why it wouldn't. The vue implementation of the component would rely on the state property as the reactive source of truth, the actions as the ways for modifying state. In Vue we can just use a regular computed to subscribe to a particular state update in the component:
const isDisclosureOpen = computed(() => disclosureStore.state.open)

Vue's composition API really shines in this regard, it doesn't look like we'd need really any special APIs to make this work. The useStore composable is still useful to remove the boilerplate at least.
The store property should theoretically be seldom, if ever, used. Reading from a reactive and calling functions that update the reactive is a great way to handle local component state in Vue.

I also believe framework-agnostic components state primitives are the future.
zagjs is also designed for building  ui components across frameworks.

but zagjs uses state machine, causing extra complexity

I hope ariakit store can take the good features from zagjs.

https://github.com/chakra-ui/zag

// 👇🏻 import resuable component state primitive, how will ariakit store work
import * as toggle from "@zag-js/toggle"

import { normalizeProps, useMachine } from "@zag-js/react"

function ZagExample() {
  // if you need access to `state` or `send` from machine
  const [state, send] = useMachine(toggle.machine({ id: "2" }))

  // convert machine details into `DOM` props
  const api = toggle.connect(state, send, normalizeProps)

  // consume into components
  return <button {...api.buttonProps}>Toggle me</button>
}


Script-aware fallback

Clearly one of the trickier aspects to integrating with a text layout system is script aware fallback. Issue #28 is one way, provide metadata. The problem is, it's not really supported by platform text libraries.
What is supported, and used by most web browsers, is an API for choosing a fallback font based on a Unicode code point and other data, generally locale preferences. In CoreText, that's the not-well-documented CTFontCopyDefaultCascadeListForLanguages. In DirectWrite, it's IDWriteFontFallback with IDWriteTextAnalysisSource. In discussions with @pcwalton and further thought, I think the best thing to do is to implement an abstraction for those API's in font-kit.
This will change and increase the API surface of font-kit quite a bit. In particular, we need to adopt a locale representation, and have code to plumb that to platform API calls. I suggest we use fluent-locale-rs, as this has promise to be a standard across the Rust ecosystem.
Discussion is welcome, as is an offer to implement the functionality. However, I'm also quite willing to do it myself, especially as I expect this to interact with the design of the rest of skribo, including its API.

What about for Fontconfig? We're facing this exact issue right now and throwing around various extensions to @font-face rules that might help us on systems that don't have a platform font stack.

It's a good question. One of the issues I found in my research is that some systems (like my stock Debian) have thin config files that don't do CJK properly, and there are various blog posts on how to configure that. The Firefox approach, of having a configurable "pref" that defaults to hardcoding known fonts, should work expediently for users, but is another configuration point and will degrade as fonts change (and there's lots of activity with quality free CJK fonts, so I expect this to be an issue). I did address it on the skribo side, but since the work is planned for this repo, it's worth capturing.

We have separate fonts.css for Linux, MacOS, and Windows, but yes that requires ongoing maintenance work to keep it up to date. Also CSS is not really the right format for this as @font-face rules only have one simple sorting mechanism so you can't easily express language/script-based preferences in conjunction with that, ah well. Not that users always use appropriate language tags in the first place! :laughing:

Agree with above. This is slightly beyond the scope of my work, but maybe with awareness of the script-specific issues (I might blog about it) we might push Linux distros to ship a more precise fontconfig.
And yeah, CSS is not quite adequate. When I make "font collection" objects in skribo, I have to think about how much of that functionality to export in builders, or to treat it pretty much like CSS, and relegate the script-aware stuff to the system fallback fonts. That also gets into how much of the "font collection" and "font family" concepts spill over from being skribo to font-kit data types. The next couple weeks are going to be fun, I predict.

I discussed this with @pcwalton and I think we've come up with an API that represents the intersection of the Windows and Mac based approaches. This API takes:

A string.
The base font (used for style matching).
Additional explicit style parameters (weight, width, italic).
A single locale.

It returns:

An ordered list of fonts. Each font also has style synthesis (and maybe scale) metadata.
A substring length, saying that the fallback is valid for that substring.

This interface is quite a bit like IDWriteFontFallback::MapCharacters but with a couple important differences, to accommodate other platforms. Notably, it returns a list of fonts rather than a single font, and takes a single locale. On Windows, the implementation of this method is a very thin wrapper around MapCharacters.
On macOS, it can ignore the string and just return the result of CTFontCopyDefaultCascadeListForLanguages (but see below).
The guarantee is essentially this: the composition of the returned list of fonts will render the string up to the returned substring length. Further, the order of fonts returned will respect the requested locale (primarily used for Han unification).
The returned fonts should match in unique ID (see #40) so that existing loaded resources can be reused.
Rationale for taking a single locale
For correct handling of multi-locale fallback, it is the caller's responsibility to determine the most relevant locale for the string. In an extreme case, for "ल骨" and a locale list of "en-US, zh-CN, mr-IN", there should be two different queries, the first using "mr-IN" and the second "zh-CN", to get the Marathi-specific allographs and Han unification correct.
We could take multiple locales, which might increase accuracy in some cases, but would also increase the risk of differences in behavior across platforms. For example, the above string might render correctly on Windows, which can handle the locale list, but then apply neither the Marathi or Simplified Chinese rules. (Note: allographs are usually applied with the 'locl' feature of in Devanagari OpenType fonts, as opposed to font selection, but the principle stands).
Using script hints for filtering
A typical macOS device will have more than 30 fonts in the cascade list. To improve efficiency (as there is a cost to considering each font in the list), the implementation may well filter the list. I think a good approach is to use script to rule out fonts - for example, if the source text contains no glyphs in the range U+0900 to U+097F, then any Devanagari fonts may be excluded. That might be determined from well-known font names, analysis of cmap coverage, or other sources.
Alternatively, the caller might do this filtering; we'll need to see which is cleaner and more efficient. In any case, the API should allow it.
Android
It should be possible to basically just list the contents of fonts.xml, using the locale to prioritize script matches; this would be quite similar to macOS.
The number of fonts is large, however, so it might be even more important to do script-based filtering as above.
Note also that the fonts.xml file has a dire warning that this mechanism is going away soon. We should try to get input from the Android team what NDK-friendly mechanism will replace it. @nona-google can you comment?
Linux/FontConfig
I think the API sketched above can work using FontConfig, but I haven't dug into the details. I'd love to have help with this also.

Yes, fonts.xml is dying.
We are now proposing new API for Java and NDK, named SystemFonts.
https://developer.android.com/reference/android/graphics/fonts/SystemFonts
The equivalent APIs will be in NDK too but there is no public documentation yet.
(Please note that we are still refining API surface. This draft APIs may be different from the final released version).

@nona-google Thanks, this is very helpful! In particular, it looks like the getLocaleList method might be useful for doing the script-based filtering as mentioned above.

It is not clear to me how you implement the script-based filter, but please note that the returning locale does not completely reflect the font's cmap coverage. For example, NotoSansCJK covers Latin characters or some symbols but we don't put Latn script or Zsym script to that font. This is because we only give extra score with the locale info.
Android filters out the coverage first, then give extra score based on locale preference, as you know well :)
So, if you filter out the font only by script returned by getLocaleList(), that sounds too aggressive to me.
BTW, if you are looking for font matching logic, we will also provide font matching API in NDK (not for Java, sorry). This is actually exposing minikin::FontCollection::itemize function.
I want to point the API documentation but not yet in public :/
You can see this API in system_fonts.h in NDK r19 beta. Please check it if you are interested in.

Sorry, even ndk-r19, the relevant information is not included.
I'll notify you once the NDK API documents are public.

I agree, for Latn and Zsym in particular (also Zyyy) it's very difficult to use script coverage to choose fonts. This is why I'm suggesting we use script metadata to rule certain fonts out, very especially the long tail of seldom-used scripts. Likely you'd never rule out the CJK fonts, because the question of script coverage for them is so complex. But Sharada and SoraSompeng I think you can exclude safely unless there are U+111xx or U+110xx code points, respectively. I think we will need to do further experimentation, but I also think it's likely we can get the list of fonts down from many dozens.
Having the itemize function available might also be a good approach - as you can see this is close to what we plan for Windows. We can't use it for everything (among other things, I don't see how to make it support unicode-range for Web fonts), but when we get to the fallback chain having it choose the font for a given string might well be practical and efficient. I look forward to seeing the NDK.

Presumably you could also pass in a locale and the empty string and get a suitable list of fonts back?

@mikeday I like the idea but don't know how to implement that on Windows. Related, I'm not sure how best to implement this on old Windows - the IDWriteFontFallback API is 8.1+.

@raphlinus Yikes, the Windows 8.1 dependence will be a problem for Servo eventually. We don't have to fix this now, but we will need to come up with a solution for Windows 7 at some point.

I should do more research on Windows 7, but at the absolute worst, hard-coding a list of system fonts along with metadata (so it knows to put Meiryo at the front for ja-JP locale) should work at least ok. The biggest question is whether the API proposed above is valid. My sense is that it is, but if we're uncertain about 7 and want more confidence, lemme know and I'll dig in.

Research on Windows 7 below (it was bothering me, obviously).
Qt has a hardcoded list of fonts and includes the Han unification logic in there (there's a separate font list for each of the CJK locales). It doesn't have any script awareness beyond CJK. I haven't researched how it deals with the non-CJK fonts.
Blink calls into Uniscribe for this, using quite a bit of trickery - it creates a metafile DC so it can intercept the font request, then uses ScriptStringOut It calls this when the request for the IDWriteFactory2 fails. Based on a quick read of the code, I think the approach is workable - like the MapCharacters approach, it will yield a single font. I'm not 100% sure how to wire up the locale, but at the very least it should be sensitive to system settings, which might be Good Enough for many cases.

Looking more closely at DirectWrite, I think another possibility for Win7+ is to create a TextLayout object, then call pass a custom TextRenderer to the Draw method, gathering the font references in the callback. I haven't found anything that does this, but I think it should work. Perhaps the main reason I don't see it being done is that it requires DirectWrite, while the Uniscribe approach above goes back at least to XP.

I see Gecko doing this, but for a reason I can't determine, it doesn't write up its aRunScript argument to set the locale. Maybe @jfkthame can shed more light on why?

I don't have any particular insight into why. This was implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=705594, and I can only assume that it seemed to work adequately with just passing the hardcoded en-US locale; but it may not have been tested in sufficient depth that locale-dependent differences would show up.
I'd guess the likeliest place for a dependency on the locale argument to show up would be with Han-unified characters, selecting between fonts preferred for ja/zh-Hans/zh-Hant. But within Firefox, this is likely to be handled by the prefs-based font fallback setup, and so this "last-ditch" fallback won't apply. Which could explain why the lack of locale support here hasn't been an issue in practice, even though it does in theory look like a shortcoming.

@jfkthame This seems likely to me, yes. The CJK stuff would have already been covered by pref, so this seems most effective in the long tail fonts like Ebrima.
I think this (custom renderer) should be the plan of record for Windows 7, and we can have a separate issue for it.


any change to make the fw_log.volt filter colors custom ?

@fichtner
it has "0" priority but I wanted to ask if we could make the colors custom?
I think this is not quite suitable and it would not hurt to be able to customize this for the respective theme.

@opnsenseuser can you try to overwrite fw_pass and fw_block in your theme's? https://github.com/opnsense/core/commit/fe21186e05f5e33167cc109ce7fef09e3dc947b7 should fix the defaults.

@opnsenseuser by the way, tickets for core changes should be opened in the core repo, no need to reopen, but good to know for the next one :)

@opnsenseuser by the way, tickets for core changes should be opened in the core repo, no need to reopen, but good to know for the next one :)

of course - sorry was my fault!

no problem :)

@AdSchellevis but problem still exists. no more logs are shown!

@AdSchellevis same problem on org. opnsense theme

any script errors? does it still show api calls in the network view? (and how do the responses look)
At my end it still works (using the new classes) an empty list kind of suggest other type of issues.

strange. even the original opnsense theme does not show anything. i try a restart of the vm.

Away for a long weekend, you'll need to remind me when I get back.
null

Ok

Not a big Deal.
Add these two classes „fw_pass“ and „fw_block“ to your Template for the Firewall log as shown above. Give them background-Colors as you like and if you want change the content Main Color is i did.
2nd more important is the sidebar modifications as the Font-size of the Symbols, Text and the div widths for the submenu have changed a little. There where also Some things that arent relevant anymore. So you can delete them. Just compare my old and the new sidebar Main.css to See the difference.
If you need more help Message me
Regards rene

All changes accept the border-line between the main Menu items are also already in the Main.css of opnsense theme.

One more thing. For the Firewall log you do not need to modify anything if you still like the original colors. The org colors are hardcoded in the .volt file


misaligned address in windows 10

demo_render.py works fine
but in demo_deform.py I get this error (windows 10 python 3.7 cuda 10)
set CUDA_VISIBLE_DEVICES=0 & python examples/demo_deform.py
Loss: 0.8354:   0%|                                                                                | 0/20000 [00:00<?, ?it/s]THCudaCheck FAIL file=C:/w/1/s/windows/pytorch/aten/src\THC/THCReduceAll.cuh line=327 error=74 : misaligned address
Traceback (most recent call last):
File "examples/demo_deform.py", line 111, in
main()
File "examples/demo_deform.py", line 100, in main
loss.backward()
File "D:\apps\python3\lib\site-packages\torch\tensor.py", line 107, in backward
torch.autograd.backward(self, gradient, retain_graph, create_graph)
File "D:\apps\python3\lib\site-packages\torch\autograd_init_.py", line 93, in backward
allow_unreachable=True)  # allow_unreachable flag
RuntimeError: cuda runtime error (74) : misaligned address at C:/w/1/s/windows/pytorch/aten/src\THC/THCReduceAll.cuh:327

I have not tried it on windows. My environment is on Ubuntu 16/18. It seems that some CUDA code doesn't work on windows. Can you try it on Ubuntu? I will try to figure out where the problem is.

Works on Ubuntu.
Thanks.


Update Crystal install instructions

I took an attempt at cleaning up the language in the installation instructions.
Also tried to package it with brew a bit at https://github.com/lutostag/homebrew-brews/blob/main/Formula/justprep.rb -- if you want to have them at your namespace rather than mine, feel free to fork it into your own github repo!
I'm not super attached to the words specifically, so up to you what you want to say for sure.
Thanks for the chat as well, appreciate it @MadBomber!

I had an issue with the brew formula where it wasn't open to the public. It should work now though if you want to try it out.
Appreciate your time @MadBomber -- no rush to see if this is a smoother install process.

Your brew formula does not show up on a brew search justprep BUT it does
install using the instructions in the README.  The TOC is out of date.  I
forgot which tool I used to create that TOC.  I tried to use the ruby gem
"tocer" but it does not work.  Might have to do the update by hand.
Dewayne
o-*
On Sun, Mar 27, 2022 at 8:22 AM Greg Lutostanski @.***>
wrote:

I had an issue with the brew formula where it wasn't open to the public.
It should work now though if you want to try it out.
Appreciate your time @MadBomber https://github.com/MadBomber -- no rush
to see if this is a smoother install process.
—
Reply to this email directly, view it on GitHub
https://github.com/MadBomber/justprep/pull/10#issuecomment-1079930991,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAFE3IMOIE3VP2UDCIJLETVCBOITANCNFSM5RGQUE7Q
.
You are receiving this because you were mentioned.Message ID:
@.***>


[stable/grafana] New existingClaim configuration parameter

Added server.persistentVolume.existingClaim to README.
Honour the value in deployment.yaml.
Don't define PersistentVolumeClaim if existingClaim is set.
Default value in values.yaml is set to "".

@k8s-bot ok to test

Needs chart version bump then LGTM

Version bumped. @lachie83 can you squash? I can't.

Sure. We'll squash on merge


TODO - Comment attachment

Need to improve the way Cherow collect comments today, and also add a new feature allowing comments to be attached to the node without need for Escodegen or similar libraries.

[x] Add a new Attach option for attaching comments

[x] Attach the comments on the node at correct locations

[ ] Optimize the code

[ ] Add loads of tests to get things right!

[ ] Push to GH and NPM

**Example output after parsing with Cherow: **

// Inner comment parsing
cherow.parseScript(`function x() {
            // Inner comment
        }`, { attach: true })

// Output

{
                  "body": [
                    {
                      "async": false,
                      "body": {
                        "body": [],
                        "end": 61,
                        "innerComments": [
                         {
                            "end": 47,
                            "start": 31,
                            "type": "Line",
                            "value": " Inner comment"
                          },
                        ],
                        "leadingComments": null,
                        "start": 13,
                        "type": "BlockStatement"
                      },
                      "end": 61,
                      "expression": false,
                      "generator": false,
                      "id": {
                        "end": 10,
                        "name": "x",
                        "start": 9,
                        "type": "Identifier"
                      },
                      "params": [],
                      "start": 0,
                      "type": "FunctionDeclaration"
                    },
                  ],
                  "sourceType": "script",
                  "type": "Program"
                }

Closing. The code is live on NPM. Still several things to fix before pushing to GH:

Does this actually exist? I couldn't find it in the code npm code.

It did exist in previous version but because you never know exactly where to put a comment - it was removed. And it was also a perf killer.
I can reconsider adding it back for 2.0 if I can gigure out a good algorithm for it.
What's your use case?

I'm writing a documentation metadata generator, ultimately producing static JSON representations of the different elements of a library. Comments are used to override specific details and add context to the metadata.
For example, there is an EventEmitter class. The library's build process ultimately packages this class into a namespace called NGN, so users of the library would reference NGN.EventEmitter instead of just EventEmitter. There's no way Cherow would be able to know this, which is where the comments come into play. Comments also offer a fair amount of inline documentation, relevant to the specific node.
The important part for my use case is associating comments with specific nodes. Comments are written above the node, in either single or multi-line syntax, like these comments. The "gotcha" I've come across in similar past efforts is the comment isn't always the immediately preceding line... sometimes a dev will leave a line break between the comment and the code.
My current approach is kludgy. I parse the code twice; once with Cherow and once with a comment parsing module. Associations are created by comparing line numbers between the output of each parser. While Cherow performs very nicely as a component of this solution, the overall solution is complex to maintain/communicate.
Personally, I'd be thrilled if there were a way to associate comments with specific nodes. I liked the idea of having this as an option, or even a separate add-on module. I understand why this wouldn't be ideal as the default, but having the option to knowingly take a performance hit in exchange for this functionality would be a big benefit in my use case.

Have you tried to collect the comments and used a 3rd party code to attach them? Similiar to what Acorn suggest?
I'm out of town ATM, but back in a few days and will try to think about this once more. The main issue is that you can't always know wich AST node you should attach the comment to.
Recast solved this in a good way and attach comments after done parsing. Maybe you could look at that algorithm?
If  done inline - as I tried before -  you would need two sets of arrays and modify finishNode to insert the node for each AST node if you use a algorithm ala babylon / Esprima 2.x. i found this not performant.
Third option is to rely on heavy use of member access or mutual parser flags and that way keep track on where to insert the comment. I never tried it, and I'm afraid it would be very complex...
And I also doubt it's possible to get this 100% correct because there will allways exist a comment that belong to nothing.
Anyway. I can add this to my v. 2.0 TODO list and look into it once more.
And also feel free to contact me on gitter if you want to discuss this further.

I'll ping you on gitter for further conversation (will wait until you get back), but for completeness/anyone who lands here from a Google search, I'll post one last reply here.
Yes, the Acorn approach is essentially the one I took. It works, it's just tough for other developers to make changes. That may just be the nature of the beast though. I haven't looked at Recast, so I'll check that out.
I would agree it's unlikely to get this 100% correct for all use cases. Though unusual, nothing is stopping a developer from writing comments below a node or even in a specific line.
One thought that occurred is to identify possible nodes a comment could be associated to, like the node immediately preceding/succeeding a comment. This doesn't completely solve my personal use case, but it would significantly reduce the complexity of what needs to be done after the initial parse. It may not make sense to embed that logic directly in the core Cherow lib, but perhaps some sort of hook system would allow Cherow to be extended? In my use case, and potentially any other custom use case, this would make the code significantly more readable/easier to understand.
For illustration purposes:
commentHandler: function (commentNode, nextNode, priorNode) {
  // Handle the comment using custom logic
  if (nextNode.type === 'ClassDeclaration') {
    nextNode.comments = commentNode
  }
}

The advantage of this approach is developers can handle the comment processing logic, so Cherow wouldn't necessarily need an algorithm to automate the association. It also leaves any major performance impact decisions to the developer, so the core Cherow lib doesn't needlessly take a performance hit, nor does it appear to pollute the scope of Cherow.

I just realized that what I suggested is something Acorn is already doing... precedence?

@coreybutler FYI! I'm back.

@coreybutler I'm finally back on track and started to work on 2.0. I have now added option for a comment handler - onComment. What's your other ideas?

I wound up with a more complex solution than I'd hoped, but it works.
Remember, my use case is generating documentation of OOP-style code (metadata-generator). I used a build process to extract comments separately from the AST, then combine the output. The effect: it generates metadata based on the AST, allowing inline comments to override/customize as necessary.
I use my own extendable build lib (productionline), which has a generic text file processor. I extended this to support comment extraction. It also identifies which line(s) of code a comment is related to. This is mostly generic, but I wouldn't call the code 100% unopinionated.
So, that's the core of the doc generator. I'd love to see a more elegant solution, but the nature of auto-documentation (as opposed to AST parsing) is complex and nuanced. It's mostly opinion, aside from identifying comment-->LOC relativity. I didn't implement a specific algorithm... pretty much just some simple looping.


Removing RTX for h264 from SDP as Chrome does not work correctly with…

… it. Removes problems with freezing remote video (sent from Chrome Canary using h264) on owr.

Is this debugged already and reported to Chrome? Or to GStreamer if it's a problem with the RTX handling there?

I've filed a Chrome bug: https://bugs.chromium.org/p/webrtc/issues/detail?id=5810
I've not dug deep into it as h264 with RTX works fine between FF and owr.

@sdroege @superdump @stefanalund I think someone should merge this as it creates problems with h264 interop with Chrome. We can in parallel investigate the reasons.

Sure, I just wanted to be sure that the real problem is tracked somewhere and not just forgotten :)


Implement GDPR requirements with Google Analytics using Consent API and Javascript.

User Story: As a website owner, I want to make sure that my website is complian with GDPR regulations, so that I can avoid legal fines and protect my customers' privacy.
Description: The GDPR scanner would need to analyze the website for specific issues such as cookie usage, data collection and processing, and privacy policy compliance

We did initial scans with 2gdpr scanner. Results: https://2gdpr.com/939664630
May use a different scanner and see if we get the same passing scores once more before submitting.


ISPN-5544 Deprecate eager near cache mode

https://issues.jboss.org/browse/ISPN-5544

Deprecate eager near caching.
Rename LAZY near cache mode to INVALIDATED.

I wonder if we should just remove this for 8.0 and deprecate only in 7.2?

7.2 final is out already so don't think we should deprecate things in a point release. WDYT @tristantarrant ?

@galderz  I agree

Pushed, thanks


Getting Started guide doesn't mention that you need to extract from the .zip

Can this be closed now etcher exists and can AFAIK extract from zip (does it for me on xenial)?

@Lewiscowles1986 while that is true, the reason this was raise was because for resinOS one is directed to using rdt flash and rdt configure while rdt flash will most likely etcher does work with zip files currently, there is no way (yet) to configure zip files before flashing, so one has to extract the image first.


feat: cast --concat-hex

Motivation
I'd like to use cast in scripts that involve directly computing storage slots of solidity contracts. To do so,
it requires concatenating hex values and then hashing them. Doing so in bash results in a bunch of
boilerplate and adding a simple command to cast makes this much easier.
Solution
This adds a new flag to cast for concatenating hex strings.
cast --concat-hex accepts any number of arguments.
Any intermediate 0x prefixes will be removed and the returned
string will be prefixed with 0x. This is useful for computing
storage slots.
The following script will print off the same value for the calls to balance and storage:
slot=$(cast keccak $(
    cast --concat-hex \
        $(cast abi-encode 'f(address)' 0x4200000000000000000000000000000000000011) \
        $(cast --to-uint256 0)
))

export ETH_RPC_URL=https://mainnet.optimism.io
cast balance 0x4200000000000000000000000000000000000011
cast storage 0xDeadDeAddeAddEAddeadDEaDDEAdDeaDDeAD0000 $slot | cast --to-dec

I like this, definitely useful. But mainly commenting in case you don't know about cast index (based on seth index) to help with computing storage slots for mappings 🙂