[sw, rv_core_ibex] Is all memory containing executable code initialised with valid ECC?

This is related to https://github.com/lowRISC/opentitan/issues/11035. In that issue I was seeing a potential problem due to Ibex's speculative iside fetches. Such a fetch could fetch from unmapped memory, getting an error response. If that response didn't have correct integrity we triggered an alert. That's a problem as entirely correct code executing close to some memory region boundary could trigger an alert.
We'll see very similar behaviour when we're executing code inside a memory but some parts of that memory don't have correct integrity because they haven't been written yet. In particular this effects flash and SRAM.
Is it the case that SRAM will be initialized and flash will have valid integrity written at all words? If not we either need to give some guarantees about Ibex's prefetching behaviour for fetches (so we know what extra words around instructions need to be initialized with valid integrity) or stop checking integrity on incoming fetches. The latter would require icache alterations as right now ECC is calculated inside icache as it writes to the data RAMs. We'd need to switch that to instead carry it through from the bus (or corrupt instruction words would just silently get given correct integrity by the ICache).
@msfschaffner @tjaychen @cdgori @arunthomas @alphan @cfrantz

hmmm... that's a good question.
For sram, there is an initialization function we can call that goes through and populates the memory with valid, random data. This bit is handled by ROM./  For the injection case however, I don't think ROM has done this part yet, so we might need the external host to trigger it to get around this issue.

@GregAC just to double check, have you seen a failure so far where pre-fetches to uninitialized flash has caused an alert generation as you described?
The way the flash logic is "supposed" to behave is that we always generate the integrity based on the data read.  We may attach sideband errors to it based on local checks, but you should not technically get incorrect transmission integrity.
@jdonjdon have you seen anything misbehave here so far?

@GregAC just to double check, have you seen a failure so far where pre-fetches to uninitialized flash has caused an alert generation as you described?
The way the flash logic is "supposed" to behave is that we always generate the integrity based on the data read. We may attach sideband errors to it based on local checks, but you should not technically get incorrect transmission integrity.
@jdonjdon have you seen anything misbehave here so far?

As long as input data is not 'x', I don't see any misbehavior.
And I assume all uninitialized flash have random '0' or '1' in real life.

@GregAC just to double check, have you seen a failure so far where pre-fetches to uninitialized flash has caused an alert generation as you described?

Nope, this is based on issues we've seen in the Ibex testbench. We've got tests that cause fetches to uninitialized memory leading to alerts.

@GregAC just to confirm though.. if you prefetch into an area that is marked non-excutable, what happens then? Because in some sense I think we can equate these cases.  I would assume the pmp would actually error that prefetch, and there is some trickle down behavior.  So then as long as we don't enable execution to uninitialized regions, wouldn't we be okay also?

if you prefetch into an area that is marked non-excutable, what happens then?

Nothing, the PMP check occurs between the Fetch and Decode/Execute stages of the pipeline. So we can prefetch on the iside into non-executable space.

ah i see... so then the error conditions associated with that fetch, does it automatically jump into an exception? I'm guess it does not.
However, knowing this then..

for sram_ctrl, we can avoid it by calling the init function, which populates every sram location with valid integrity.
for flash, we "should" be okay assuming the design does what it does and has at least a non-x value on which to operate.

@alphan @dmcardle can you double check that the SRAM inject test cases do not run into this issue? If they do, we can solve this by calling the init function as @tjaychen mentioned above.

@alphan @dmcardle can you double check that the SRAM inject test cases do not run into this issue? If they do, we can solve this by calling the init function as @tjaychen mentioned above.

I didn't run into this during my trials. If needed, this should be trivial to handle in gdb, right @dmcardle? Also, .text is followed by .bss, so we can potentially handle this in the binary itself, right? I recommend keeping this in mind but not changing anything in the sram injection part unless we are sure that we need this in order not to introduce a dependency on the SRAM init function, which probably depends on other pieces of HW.
@dmcardle @tjaychen @msfschaffner PLMK if you agree.

@alphan @dmcardle can you double check that the SRAM inject test cases do not run into this issue? If they do, we can solve this by calling the init function as @tjaychen mentioned above.

I didn't run into this during my trials. If needed, this should be trivial to handle in gdb, right @dmcardle? Also, .text is followed by .bss, so we can potentially handle this in the binary itself, right? I recommend keeping this in mind but not changing anything in the sram injection part unless we are sure that we need this in order not to introduce a dependency on the SRAM init function, which probably depends on other pieces of HW.
@dmcardle @tjaychen @msfschaffner PLMK if you agree.

To my knowledge, I have not run into integrity alerts while mucking with SRAM in the GDB test (sram_program_fpga_cw310_test), but I have to admit I'm not sure how I would know. I'm assuming the alert would be fatal, so my SRAM program would fail >0% of the time, right? I'm not seeing any flakiness in the test.
It would be trivial to call an init function directly out of the ROM if that's acceptable. Otherwise, and if we can't use the SRAM safely without first calling the init function, we have a kind of bootstrapping problem. I'm sure we could figure something out if necessary, but it might require extending OpenOCD (we could write tiny, arbitrary programs in the program buffer).

Thanks @dmcardle!

It would be trivial to call an init function directly out of the ROM if that's acceptable.

Just to be clear, @tjaychen, you are referring to the LFSR-based memory initialization feature, right?

Sorry, some questions.
@GregAC you said:

could fetch from unmapped memory
What does unmapped mean in this context?  The rest of this discussion seems to be regarding either non-execute or non-initialized regions.  But I think this is referring to literally an unpopulated part of the address space?

For the non-execute part, I believe I understood this comment

Nothing, the PMP check occurs between the Fetch and Decode/Execute stages of the pipeline. So we can prefetch on the iside into non-executable space.
from @GregAC to mean that the PMP check will prevent the speculatively fetched data from being decoded.  That's very important to prevent any abuse of a speculative fetch mechanism if the executable region borders a data/non-execute region.

For non-initialized memory, I didn't quite follow @tjaychen - is the sram_ctrl init function a piece of software?  (My main concern is not about the simulation, but rather the actual hardware and what would happen if that init was bypassed somehow in the boot process.)  Or is that some hardware function that software triggers to initialize the memory?  (Again, same question about what happens if that's bypassed during boot.)
Flash sounds like it is OK, the transmission integrity is generated on what is read.  (Side question @tjaychen - do you expect we will do full bank erases post-manufacturing testing such that all the contents of flash would read all-zero or all-one, except where we have actually stored data?)
Obviously, there are potential simulation concerns to resolve as well, but you all are better situated to find the best path there than me.

@cdgori the initialization is the latter. Ie hardware function triggered by software. If some unfortunate soul were to skip this, the memory likely will be a mismatch of data and integrity.  Meaning if anyone tried to read from it, the integrity errors would likely trigger. This was the original case we were worried about for debug access.
re. flash yes i do. One of the first things we do, before we boot strap an image, is a bank level erase across the flash. So everything will be wiped.  Since boot strap is the only way we can get an image in, we actually have no choice "but" to wipe.

Thanks, those are both reassuring results.  I can't see how to exploit the SRAM by skipping the init, and the flash, that matches my expectations and seems safe.
If someone caused the bootstrap to skip erasing one of the banks, when we read from the skipped bank later, those reads would presumably have bad integrity (with extremely high probability), right?

yeah, especially if they're jammed with random data.
But I want to say the wafer test people will probably do an erase of their own though..so maybe it'll look very erased?
But if it's not, i think the second layer of protection is that flash program and eventual verification are both going to fail.  So the image would for all practical purposes be bad.

Mostly I'm trying to come up with "what bad thing could an adversary do with a raw wafer that didn't go though wafer testing/erase" - I'm not getting anywhere though (which is good!)

@GregAC are you satisfied with the answers given here? Can we close this issue?

The only thing left for me was my clarifying question regarding what @GregAC meant by "unmapped" in his first comment above.
I guess also to double/triple-check that the PMP check prevents decode of data-fetched-beyond-the-boundary since that would be a serious problem.  (It's ~OK to fetch/pre-fetch into non-execute regions, but manipulating/decoding the data is the problem.)

Yeah let's wait for @GregAC to clarify.
RE prefetching from non-execute: yes, unless the region is not idempotent (e.g. a FIFO). we should probably make sure executable regions are placed far away from non-executable regions in the system memory map.

i think longer term we're going to want a PMA... right now the ibex can't tell these things apart, so as a result the memory access latency I think suffers since we technically need a response before issuing another. If we could actually tell apart IO/memory space, we could probably reap some benefits from it.  The PMA will also let us know to not fetch into IO space if they are close together.

The only thing left for me was my clarifying question regarding what @GregAC meant by "unmapped" in his first comment above.

By unmapped I mean addresses not physically present in the address map

I guess also to double/triple-check that the PMP check prevents decode of data-fetched-beyond-the-boundary since that would be a serious problem. (It's ~OK to fetch/pre-fetch into non-execute regions, but manipulating/decoding the data is the problem.)

The instruction bits will enter the IF stage, which has a compressed instruction decoder (uncompressing instructions into 32-bit instructions). The actual decoder lives in the ID/EX stage and the PMP won't let the prefetched instructions from the IF stage enter the ID/EX stage.

we should probably make sure executable regions are placed far away from non-executable regions in the system memory map.

Yes definitely

i think longer term we're going to want a PMA... right now the ibex can't tell these things apart, so as a result the memory access latency I think suffers since we technically need a response before issuing another. If we could actually tell apart IO/memory space, we could probably reap some benefits from it. The PMA will also let us know to not fetch into IO space if they are close together.

Yeah I'd definitely like to look into PMA. We were looking at implementing it a year or so back but I think other things took priority and it's fallen by the wayside. Definitely something to consider for future work.

I am closing this issue now since it seems like all questions have been answered. Please reopen if you think otherwise.


remove unnecessary artificial delay in catalog example

Description
When I read catalog example, I found unnecessary artificial delay Now.
It is because https://github.com/flutter/flutter/pull/12896 Merged.
So, I remove the line.
# local test command
cd examples/catalog
dart bin/sample_page.dart commit
flutter driver -t test_driver/screenshot.dart

Related Issues

https://github.com/flutter/flutter/pull/12896 delay taking screenshot to allow GPU thread to render the frame

Tests
no addition
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
[x] No, this is not a breaking change.

@Hixie Would you review this ?

Do we have any code anywhere that tests that this code works when generated?

@Hixie
yes, the code is https://github.com/flutter/flutter/blob/master/dev/devicelab/lib/tasks/sample_catalog_generator.dart#L30-L37

Great.


Change label colors

Change label colors so they are more diverse and easily recognizable as different.

There should be 25 different colors.

Done.


Support query parameters

This could be done with an augmented URLSearchParams (like we do for JSON) and a hardcoded query template string. It will also be needed for apis which use required query string parameters.
This is needed for example in the tMDB API for search.

#19 is enabled by default now. Still need to figure out how to properly augment the URLSearchParams type globally with the generic parameter.


Update readme regarding AuthController guest middleware assignment

First thanks very much for this great piece of middleware :-)
I suggest to add to the description, that one obviously has to except the trait methods from the "guest" middleware in the AuthController constructor, otherwise it wont work:
    public function __construct()
    {
        $this->middleware('guest', ['except' => ['getLogout', 'postReauthenticate', 'getReauthenticate']]);
    }

Andreas

Thank you, done :)


Add new fields to integration test and distribution build publish libraries

Description

Add new component_repo and component_repo_url fields for both the distribution and integration test publish libs. With these fields all the distribution and integration test documents can be filtered by component_repo (or component_repo_url).
Since the OSD integration tests has multiple CI groups, filtering by component_repo should give the all the CI groups test failures.
The new fields test_stdout and test_stderr for both with-security and without-security should give users direct downloads links for the stderr and stdout errors. Thanks to @peterzhuamazon coming from https://github.com/opensearch-project/opensearch-build/pull/5001.

Issues Resolved
Part of https://github.com/opensearch-project/opensearch-metrics/issues/72 and https://github.com/opensearch-project/opensearch-metrics/issues/51
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Testing, following is the generate sample JSON documents which has all the added new fields
Integration test results
{
  "_index": "opensearch-integration-test-results-09-2024",
  "_id": "k4rD-5EBKO-WGAnwaj9C",
  "_version": 1,
  "_score": null,
  "_source": {
    "component": "skills",
    "component_repo": "skills",
    "component_repo_url": "https://github.com/opensearch-project/skills.git",
    "version": "2.17.0",
    "integ_test_build_number": 87,
    "integ_test_build_url": "https://ci-staging.opensearch.org/job/pgodithi/job/integ-test-publish/87/display/redirect",
    "distribution_build_number": "10292",
    "distribution_build_url": "https://build.ci.opensearch.org/blue/organizations/jenkins/distribution-build-opensearch/detail/distribution-build-opensearch/10154/pipeline",
    "build_start_time":<PHONE_NUMBER>200,
    "rc": true,
    "rc_number": 6,
    "platform": "linux",
    "architecture": "arm64",
    "distribution": "tar",
    "component_category": "OpenSearch",
    "component_build_result": "passed",
    "test_report_manifest_yml": "https://ci.opensearch.org/ci/dbc/pgodithi/integ-test-publish/2.17.0/10292/linux/arm64/tar/test-results/87/integ-test/test-report.yml",
    "with_security": "pass",
    "with_security_build_yml": "https://ci.opensearch.org/ci/dbc/integ-test/2.17.0/10292/linux/arm64/tar/test-results/8688/integ-test/skills/with-security/skills.yml",
    "with_security_cluster_stdout": [
      "https://ci.opensearch.org/ci/dbc/integ-test/2.17.0/10292/linux/arm64/tar/test-results/8688/integ-test/skills/with-security/local-cluster-logs/id-0/stdout.txt"
    ],
    "with_security_cluster_stderr": [
      "https://ci.opensearch.org/ci/dbc/integ-test/2.17.0/10292/linux/arm64/tar/test-results/8688/integ-test/skills/with-security/local-cluster-logs/id-0/stderr.txt"
    ],
    "with_security_test_stdout": "https://ci.opensearch.org/ci/dbc/integ-test/2.17.0/10292/linux/arm64/tar/test-results/8688/integ-test/skills/with-security/stdout.txt",
    "with_security_test_stderr": "https://ci.opensearch.org/ci/dbc/integ-test/2.17.0/10292/linux/arm64/tar/test-results/8688/integ-test/skills/with-security/stderr.txt",
    "without_security": "pass",
    "without_security_build_yml": "https://ci.opensearch.org/ci/dbc/integ-test/2.17.0/10292/linux/arm64/tar/test-results/8688/integ-test/skills/without-security/skills.yml",
    "without_security_cluster_stdout": [
      "https://ci.opensearch.org/ci/dbc/integ-test/2.17.0/10292/linux/arm64/tar/test-results/8688/integ-test/skills/without-security/local-cluster-logs/id-1/stdout.txt"
    ],
    "without_security_cluster_stderr": [
      "https://ci.opensearch.org/ci/dbc/integ-test/2.17.0/10292/linux/arm64/tar/test-results/8688/integ-test/skills/without-security/local-cluster-logs/id-1/stderr.txt"
    ],
    "without_security_test_stdout": "https://ci.opensearch.org/ci/dbc/integ-test/2.17.0/10292/linux/arm64/tar/test-results/8688/integ-test/skills/without-security/stdout.txt",
    "without_security_test_stderr": "https://ci.opensearch.org/ci/dbc/integ-test/2.17.0/10292/linux/arm64/tar/test-results/8688/integ-test/skills/without-security/stderr.txt"
  },
  "fields": {
    "build_start_time": [
      "2024-09-16T16:50:50.200Z"
    ]
  },
  "sort": [
<PHONE_NUMBER>200
  ]
}

Distribution build results
{
  "_index": "opensearch-distribution-build-results-09-2024",
  "_id": "Pq3N-5EBDMw2GPZSOcoY",
  "_version": 1,
  "_score": null,
  "_source": {
    "component": "OpenSearch",
    "component_repo": "OpenSearch",
    "component_repo_url": "https://github.com/opensearch-project/OpenSearch.git",
    "component_ref": "tags/2.16.0",
    "version": "2.16.0",
    "distribution_build_number": 6530,
    "distribution_build_url": "https://ci-staging.opensearch.org/job/pgodithi/job/distribution-build-opensearch/6530/display/redirect",
    "build_start_time":<PHONE_NUMBER>993,
    "rc": false,
    "rc_number": 0,
    "component_category": "OpenSearch",
    "component_build_result": "passed"
  },
  "fields": {
    "build_start_time": [
      "2024-09-16T16:52:38.993Z"
    ]
  },
  "sort": [
<PHONE_NUMBER>993
  ]
}

I can see the following after the latest commit, please check
Integration test publish:
    "component": "skills",
    "component_repo": "skills",
    "component_repo_url": "github.com/opensearch-project/skills",

Distribution build publish:
    "component": "OpenSearch",
    "component_repo": "OpenSearch",
    "component_repo_url": "github.com/opensearch-project/OpenSearch",
    "component_ref": "tags/2.16.0",

This PR will share the same version:
https://github.com/opensearch-project/opensearch-build-libraries/pull/497
Thanks.


Release 6.0.0

New release request, replaces #1199

@d1nuc0m sorry for the noise, can you do a final rebase and changelog regenerate? then we should be good to go.

No problem - done


build 1.5.1

maturin 1.5.1
Destination channel: defaults
Links

PKG-4410
Upstream repository
Upstream changelog/diff

Explanation of changes:

upstream requires rust 1.70 but we only have 1.71.0 as closest match

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_8f_d6t96ri/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:42: host_section_needs_exact_pinnings: output "maturin": Linked libraries host should have exact version pinnings.
clone/recipe/meta.yaml:71: host_section_needs_exact_pinnings: output "maturin-gnu": Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 2 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_94kwwjd13d/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:63: host_section_needs_exact_pinnings: output "maturin-gnu": Linked libraries host should have exact version pinnings.
clone/recipe/meta.yaml:34: host_section_needs_exact_pinnings: output "maturin": Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 2 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_eeugch_gcd/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:34: host_section_needs_exact_pinnings: output "maturin": Linked libraries host should have exact version pinnings.
clone/recipe/meta.yaml:63: host_section_needs_exact_pinnings: output "maturin-gnu": Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 2 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_edelm2ucj7/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:63: host_section_needs_exact_pinnings: output "maturin-gnu": Linked libraries host should have exact version pinnings.
clone/recipe/meta.yaml:34: host_section_needs_exact_pinnings: output "maturin": Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 2 Warnings were found

upstream requires rust 1.70 but we only have 1.71.1 as closest match

The rust-version field in the Cargo.toml file defines the minimum rust version supported. See https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field.

upstream requires py<311

No, this just says that tomli>=1.1.0 is required for python_version<'3.11'.

upstream requires rust 1.70 but we only have 1.71.1 as closest match

The rust-version field in the Cargo.toml file defines the minimum rust version supported. See https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field.

upstream requires py<311

No, this just says that tomli>=1.1.0 is required for python_version<'3.11'.

I removed those lines from the description, the recipe was already fixed.

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_98bq5za_uj/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:34: host_section_needs_exact_pinnings: output "maturin": Linked libraries host should have exact version pinnings.
clone/recipe/meta.yaml:63: host_section_needs_exact_pinnings: output "maturin-gnu": Linked libraries host should have exact version pinnings.
===== Final Report: =====
0 Errors and 2 Warnings were found


feat(bsc): changes for bsc.

gas for unlock on bsc.
gas for mint on bsc.

Codecov Report

Merging #348 (2676efc) into feature-nervos-to-ethereum (6ef064e) will decrease coverage by 3.76%.
The diff coverage is n/a.

@@                      Coverage Diff                       @@
##           feature-nervos-to-ethereum     #348      +/-   ##
==============================================================
- Coverage                       42.72%   38.96%   -3.77%
==============================================================
  Files                              24       16       -8
  Lines                            1959     1699     -260
  Branches                           58        0      -58
==============================================================
- Hits                              837      662     -175
+ Misses                           1122     1037      -85

Impacted Files
Coverage Δ

...th-contracts/contracts/libraries/MultisigUtils.sol

...ules/eth-contracts/contracts/libraries/Address.sol

...in-modules/eth-contracts/contracts/ForceBridge.sol

...n-modules/eth-contracts/contracts/AssetManager.sol

...ain-modules/eth-contracts/contracts/test/ERC20.sol

...les/eth-contracts/contracts/libraries/SafeMath.sol

...ules/eth-contracts/contracts/NervosMirrorToken.sol

...es/eth-contracts/contracts/libraries/SafeERC20.sol

Continue to review full report at Codecov.

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


Accept AsRef instead of &Path in Registry::expand

Fixes #64. Not a breaking change right?

Looks good to me. r+ when #63 lands and fixes the build on nightly.


[FEAT]: Landing Page

Design and create a landing page for the project
If not at least include a better layout for this:

This one was made for testing purposes, I will spin up a decent landing page for a practice project 👍 Thanks for your suggestions!


set-output command is deprecated

Describe the bug
GitHub Actions Deprecate Message
Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

Workflow configuration (please complete the following information):

Action version: swift-actions/setup-swift@v1
Platform: ubuntu-latest
Swift version: 5.7

@actions/core's version is required v1.10.0, but setup-swift's @action/core is v1.10.0.
Maybe GitHub Deprecate Message is incorrect.

Hi @zunda-pixel! 👋🏻
Thanks for reporting, the updated @actions/core only existed in master, created a new release now 🎉


Develop branch does not have styling

The pages on the develop branch load with no css applied.
The following error is being thrown when it is built:
]
  message: 'source string:143: error: invalid top-level expression\n',
  showStack: false,
  showProperties: true,
  plugin: 'gulp-sass',
  __safety: { toString: [Function] } }```

<!---
@huboard:{"order":133.875,"milestone_order":138,"custom_state":""}
-->

All Browsers
Ran through a smoke test of the application all outstanding issues found have been captured in separate tickets.


bug: breaks with complex schema

{
  $schema: 'http://json-schema.org/draft-04/schema#',
  $id: 'https://example.com/employee.schema.json',
  title: 'Input',
  description: 'Soooooooo meee',
  type: 'object',
  properties: {
    id: {
      description: 'A unique identifier for an employee',
      type: 'number',
    },
    name: {
      description: 'Full name of the employee',
      type: 'string',
    },
    age: {
      description: 'Age of the employee',
      placeholder: 'Age of the employee',
      type: 'number',
    },
    maggies: {
      description: 'maggies of the employee',
      type: 'object',
      properties: {
        name: {
          description: 'Full name of the employee',
          type: 'string',
        },
        age: {
          description: 'Age of the employee',
          placeholder: 'Age of the employee',
          type: 'number',
        },
      },
    },
    dependent_details: {
      items: {
        properties: {
          birthdate: {
            description: 'Enter your child’s date of birth',
            format: 'date',
            'x-jsf-presentation': {
              inputType: 'date',
            },
            title: 'Child Birthdate',
            type: 'string',
            maxLength: 255,
          },
          full_name: {
            description: 'Enter your child’s full name',
            'x-jsf-presentation': {
              inputType: 'text',
            },
            title: 'Child Full Name',
            type: 'string',
            maxLength: 255,
          },
          sex: {
            description:
              'We know sex is non-binary but for insurance and payroll purposes, we need to collect this information.',
            enum: ['female', 'male'],
            'x-jsf-presentation': {
              inputType: 'radio',
              options: [
                {
                  label: 'Male',
                  value: 'male',
                },
                {
                  label: 'Female',
                  value: 'female',
                },
              ],
            },
            title: 'Child Sex',
          },
        },
        'x-jsf-order': ['full_name', 'birthdate', 'sex'],
        required: ['full_name', 'birthdate', 'sex'],
        type: 'object',
      },
      'x-jsf-presentation': {
        inputType: 'group-array',
        addFieldText: 'Add new field',
      },
      title: 'Child details',
      description: 'Add the dependents you claim below',
      type: 'array',
    },
    optional_dependent_details: {
      items: {
        properties: {
          birthdate: {
            description: 'Enter your child’s date of birth',
            format: 'date',
            'x-jsf-presentation': {
              inputType: 'date',
            },
            title: 'Child Birthdate',
            type: 'string',
            maxLength: 255,
          },
          full_name: {
            description: 'Enter your child’s full name',
            'x-jsf-presentation': {
              inputType: 'text',
            },
            title: 'Child Full Name',
            type: 'string',
            maxLength: 255,
          },
          sex: {
            description:
              'We know sex is non-binary but for insurance and payroll purposes, we need to collect this information.',
            enum: ['female', 'male'],
            'x-jsf-presentation': {
              inputType: 'radio',
              options: [
                {
                  label: 'Male',
                  value: 'male',
                },
                {
                  label: 'Female',
                  value: 'female',
                },
              ],
            },
            title: 'Child Sex',
          },
        },
        'x-jsf-order': ['full_name', 'birthdate', 'sex'],
        required: ['full_name', 'birthdate', 'sex'],
        type: 'object',
      },
      'x-jsf-presentation': {
        inputType: 'group-array',
        addFieldText: 'Add new field',
      },
      title: 'Child details (optional)',
      description:
        'This is an optional group-array. For a better UX, this Component asks a Yes/No question before allowing to add new field entries.',
      type: 'array',
    },
    hobbies: {
      description: 'Hobbies of the employee',
      type: 'object',
      properties: {
        indoor: {
          type: 'array',
          items: {
            'x-jsf-presentation': {
              inputType: 'text',
            },
            description: 'List of indoor hobbies',
            type: 'string',
          },
        },
        outdoor: {
          type: 'array',
          title: 'Child details',
          description: 'List of outdoor hobbies',
          items: {
            description: 'List of outdoor hobbies',
            type: 'object',
            properties: {
              indoor: {
                type: 'array',
                items: {
                  description: 'List of indoor hobbies',
                  type: 'string',
                },
              },
              outdoor: {
                type: 'array',
                items: {
                  description: 'List of outdoor hobbies',
                  type: 'string',
                },
              },
            },
          },
        },
        maggies: {
          description: 'Hobbies of the employee',
          type: 'object',
          properties: {
            indoor: {
              type: 'array',
              items: {
                description: 'List of indoor hobbies',
                type: 'string',
              },
            },
            outdoor: {
              type: 'array',
              items: {
                description: 'List of outdoor hobbies',
                type: 'string',
              },
            },
          },
        },
      },
    },
  },
  required: ['id'],
}

The above schema breaks the form due to this part here
outdoor: {
          type: 'array',
          title: 'Child details',
          description: 'List of outdoor hobbies',
          items: {
            description: 'List of outdoor hobbies',
            type: 'object',
            properties: {
              indoor: {
                type: 'array',
                items: {
                  description: 'List of indoor hobbies',
                  type: 'string',
                },
              },
              outdoor: {
                type: 'array',
                items: {
                  description: 'List of outdoor hobbies',
                  type: 'string',
                },
              },
            },
          },
        },

Would have loved to make a fix, but I'm encumbered

Hi @juicycleff !
Indeed, JSF does have two limitations around group-array fields ("type": "array").
First, currently, the group-array field only accepts a list of objects. (like in this demo, where each item is {full_name, birthdate, sex}.
So, even a simpler JSON Schema like the following — an array of strings — would break in the JSF:
{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "hobbies": {
      "items": {
        "title": "Hobby name",
        "type": "string"
      },
      "x-jsf-presentation": {
        "inputType": "group-array",
        "addFieldText": "Add new hoddy"
      },
      "title": "Hobbies",
      "type": "array"
    }
  },
  "required": ["hobbies"]
}

A workaround could be changing the structure to:
{
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "hobbies": {
      "items": {
        "properties": {
          "name": {
            "title": "Hobby name",
            "type": "string"
          }
        }
      },
      "x-jsf-presentation": {
        "inputType": "group-array",
        "addFieldText": "Add new hoddy"
      },
      "title": "Hobbies",
      "type": "array"
    }
  },
  "required": [
    "hobbies"
  ]
}

I'm not saying this is the fix, I'm just saying this is a workaround, which I understand might not be ideal for you because the JSON structure would change
// Before (not supported)
{ "hoobies": ["read", "video games"]}`
// Now (workaround)
- { "hoobies": [ {name: "read"}, {name: "video games"} ] }

The other JSF limitation is that currently group-array do not work inside fieldsets (which is in your example with hobbies.indoor[]. Let's look at the shortest JSON Schema snippet:
{
  "title": "My Form",
  "type": "object",
  "properties": {
    "hobbies": {
      "title": "Hobbies of employee",
      "type": "object",
      "properties": {
        "indoor": {
          "type": "array",
          "items": {
            "properties": {
              "name": {
                "title": "Hobby name",
                "type": "string"
              }
            }
          }
        }
      }
    }
  }
}

This breaks to render in the Playground, because as the error says Objects are not valid as a React child (found: TypeError: innerFields.forEach is not a function). If you meant to render a collection of children, use an array instead. — The error is not intuitive, but basically it fails to loop innerFields (group arrays) inside fieldsets. :/
The good news is that this bug is on our internal backlog too. I don't have a timeline for you though. Hopefully by the end of the year.
I'm sorry for not giving the answer you are looking for. This was just a dump of analyses/explanations around this bug.

@jguddas what do you mean? Can you give an example? For example, the example above, you can see the error and trace-it in the dev tools.

An AJV style error might look something like this:
- JSON Schema invalid TypeError: innerFields.forEach is not a function
+ JSON Schema invalid: data/properties/hobbies/items/type must be object

I believe we are talking about different things: this is not an error with JSON Schema (it's valid!). It's a run-time error with the json-schema-form internals that doesn't support (yet) the given JSON Schema structure.
We could leave a DX error, yes, saying that for now, it must be an object, but that's a different issue. I've created an issue dedicated to it: https://github.com/remoteoss/json-schema-form/issues/29
Regarding timelines, we don't know yet as the team is currently busy with other projects. Probably still this year.


SL, Cortex, Streamlit Blog

What are you changing in this pull request and why?

Checklist

[ ] Review the Content style guide so my content adheres to these guidelines.
[ ] For docs versioning, review how to version a whole page and version a block of content.
[ ] Add a checklist item for anything that needs to happen before this PR is merged, such as "needs technical review" or "change base branch."

Adding or removing pages (delete if not applicable):

[ ] Add/remove page in website/sidebars.js
[ ] Provide a unique filename for new pages
[ ] Add an entry for deleted pages in website/vercel.json
[ ] Run link testing locally with npm run build to update the links that point to deleted pages

@amychen1776 I have one final todo to create a loom walking through the application, but the rest is ready for review.

Also, I have this diagram that I put together real quick and can throw it in somewhere if you think it's helpful/additive.


Version 0.3 complaining about missing .mtl file

This does not sound correct to me - since there is no color support yet, the mtl should not be needed right?

I just wrote myself a simple mtl file containing this
newmtl MaterialName
Ns 100.0
Ka 1.0 1.0 1.0
Kd 1.0 1.0 1.0
Ks 1.0 1.0 1.0
Ke 0.0 0.0 0.0
Ni 1.0
d 1.0
illum 2

and added these lines to my obj
mtllib wf_sky_repaired.mtl

usemtl MaterialName

Now the file loads, but i am greeted with a blank program and voxelise throws yet another error

it looks kind of like the material is being loaded, but not set correctly?

Okay Photoshop CC 2019 to the rescue, it was missing texture mapping vertices. File now loads just fine

Closing since 0.4 released


Pydata Work Prioritization

This is a meta issue to prioritize our work for Pydata Seattle 2023.
High-level tasks for the presentation:

[x] #141

High-level tasks for new features/maintenance ahead of Pydata Seattle 2023. These are divided into "must", "should" and "nice-to-have":
Must:

[x] sktime and skbase initial integration is completed. Targeting mid-April release of sktime v0.18.0
[x] Create "example" repository that includes a stylized package that uses skbase (will also be useful for additional testing of our lookup, testing and validation functionality too)
[x] Local (class) configuration interface
[x]  #106

Should

[x] #150
[ ] Add persistance (re-work of sktime persistance approach to make sure it works more generally)
[ ] Upgrade documentation, with emphasis on landing page
[ ] Redo governance section of documentation
[ ] Create functionality roadmap (borrow from HackMD and design document and add other ideas)
[ ]  Improve documentation of the skbase.testing module

Nice-to-have

[ ] #149
[ ] Example showing how to use skbase to create scikit-learn compliant class (need to investigate if this is possible. If their checks are "duck-typed" then it should be)

seems like you dropped from the call?
My thoughts on priorities:

"cook show" style tutorial creation, as described here: https://github.com/sktime/skbase/issues/141
consists of two parts: (1a) jupyter notebooks for demo; (1b) multiple stages of "package being built" for the cook show

sktime/skbase integration. It is realistic to publish an skbase based sktime version 0.18.0 by mid Apr - test framework refactor fails for mysterious reasons, but it is not actually needed for a rebasing of the core module, as the existing sktime tests are robust enough.

optional bonus feature: persistence. This has been implemented in sktime by myself and @achieveordie, and is likely a nice feature we could deliver until then, in skbase (lateral transfer)

optional proof-of-concept: sklearn with skbase. Small version: extension template based on skbase that passes sklearn interface contract tests. Big version: PR to sklearn fork that replaces the base class and refactors the tag system to use skbase's, etc.

from call with Ryan - which features would be great to create that we can showcase?
These are "should", "must" is the actual material based on status quo.

config (local) - PR exist
global config - may need some thought
pretty printing (html and text) - seems easy

@fkiraly I've updated my initial issue comment based on the notes you recorded above in our call today. I'm open to adjusting the checklists as needed (let me know if something ended up somewhere you didn't expect).

Looks reasonable - the presentation itself is obvious the absolute highest priority, but I do not see it in the list. I guess it is understood, but may be useful to list it there.

I was using that first check-box to the other issue for the presentation. I figured it would have enough stuff to stay on top of that we'd keep it separate in that issue.

@fkiraly for the example repository. We had talked about skbase moving to its own GH organization. I've got https://github.com/scikit-base setup to eventually be that (skbase was taken). Do you want me to add the example repository there or do we want to put it under sktime to start and move it over later?

pydata presentation has now happened.


Update chip theme

PR Checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[x] Docs have been added / updated (for bug fixes / features)

PR Type
What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[x] Other... Please describe: Theme update

Does this PR introduce a breaking change?
[x] Yes
[ ] No

This updates ChipTheme. Existing applications that overwrite or extend ChipTheme will have to update to match the new shape
Other information
Dark mode
https://github.com/reaviz/reablocks/assets/40581813/1875ceec-dfc6-4349-8f57-9599195d41dc
Light mode
https://github.com/reaviz/reablocks/assets/40581813/f6f51b15-aca9-45d9-a8eb-4e63e8602565
Note: The border of the selected default outlined tag in light mode is the same color as the storybook background so you can't see it

You have a conflict now 😝


Firefox applications vs browser_specific_settings manifest keys

Can we use just one ? If so, which ?
Added "applications" because @wext/shipit cli publisher for FF add-ons seems to require it somewhere.

Can't actually find any documentation for "applications"

[x] Why does wext/shipit require it then?

[x] Check the shipit source (it uses web-ext)
[x] what version of web-ext does shipit depend on ? 3.2.0

  // version 3.2.0
  export function getManifestId(manifestData: ExtensionManifest): string | void {
    return manifestData.applications ?
      manifestData.applications.gecko.id : undefined;
  }

  // version 6.8.0
  export function getManifestId(manifestData: ExtensionManifest): string | void {
    const manifestApps = [
      manifestData.browser_specific_settings,
      manifestData.applications,
    ];
    for (const apps of manifestApps) {
      // If both bss and applicants contains a defined gecko property,
      // we prefer bss even if the id property isn't available.
      // This match what Firefox does in this particular scenario, see
      // https://searchfox.org/mozilla-central/rev/828f2319c0195d7f561ed35533aef6fe183e68e3/toolkit/mozapps/extensions/internal/XPIInstall.jsm#470-474,488
      if (apps?.gecko) {
        return apps.gecko.id;
      }
    }

    return undefined;
  }

So it seems it's not the add-on store that requires the `applications` key in the manifest, it's just the shipt cli  which is using an old version of web-ext.


Frontend: second draft

Improve UI
Change faceting/filtering behaviour to be and rather than or
Change URL based on search params
Add mapping widget

Anything else @jnothman ?

Somewhere along the line I need to get the main searchbox to work properly; currently it seems to be useless. The text boxes for each of the filters seem to work very well, so it is strange how this one doesn't seem to work.
On the topic of searchboxes, it also seems that we have to generate a list of items to show up as suggestions when users type into the search bar.

it also seems that we have to generate a list of items to show up as suggestions when users type into the search bar.

I'd assume that ES provides some way to get a list of (common) indexed terms for each field, as it's very similar to the aggregates shown in faceted search.

Somewhere along the line I need to get the main searchbox to work properly; currently it seems to be useless.

What do you intend its purpose to be? Which fields will it search? If unneeded, should we remove it?

I was originally thinking a general search box across all data fields (or at least the big ones) might be useful


Debug: Icon issues in call stack view

The disconnect icon is missing:

Vertical alignment is broken:

Icon visibility is broken in a selected yet not focused row (click row and press Down):

Icon visibility for disabled actions isn't great for selected and focused rows:

Weird mouse hover behavior:

@joaomoreno nice catches. I have pushed a fix which tackles everything except the "Disabled action visibility is not great for selected items". That one I leave up to @misolori if he would like to tackle.
Also note that the vertical alignment I got with the vertical-align: text-top. I am open for suggestions on a nicer solution, though this seems to work fine.
Let me know how it behaves now.

I think that it should still look disabled in the active/selected state, I'll take that one.
Also concerned that the stop icon looks like this:

Will look into this as well.

Actually, the disabled opacity is set to 40% across all disabled items in the product, which I don't think we should change:
https://github.com/microsoft/vscode/blob/8e1ce7174b77f58699d98b932c2605dc9efb82c7/src/vs/base/browser/ui/actionbar/actionbar.css#L53-L56

@misolori if you are refering to the centering regardign the stop icon: I should have fixed that.

@isidorn no, I meant how the stop icon is filled and not an outline. It should be like this (I already fixed this):

Yes, that makes senst. Thanks!


Port some of autests to OS X

changed netstat usage to lsof
added OS X specific sysctl usage for getting port range
changed less portable SOL_TCP to IPPROTO_TCP

[approve ci autest]

I have some fixes coming in to help deal with double, txn failures.
are the tests you tweaked failing because the system does not have lsof on it?

Here is more info about the changes in case this is what you were asking about:

tweaked few tests to use lsof as a more portable way to get the listening tcp ports instead of netstat (on OS X netstat is different and lacks the options used in the tests)
changed the sysctl state variable names for determining ephemeral ports range on OS X since whatever was used is not available on OS X
changed the less portable SOL_TCP to IPPROTO_TCP (which fails the building of some of the plugins generated during the AuTest bench test run)

If you were asking about why the Jenkins AuTest job failed then I was not able to figure it out just by looking at the job console output (at the time this PR was created I had them succeed locally on both OS X and CentOS 6)
I wonder if it would be a good idea to have the ability to trigger by hand a second job run with --debug or something of that sort after the initial AuTest job fails.

That might be a good idea to add a secondary --debug --verbose run if we have failures... at least with the one that failed. I thing @zwoop is already complaining the time for the 60 or so test we have is taking to long ( ie ~10 minutes). I welcome the changes, as I am myself been making fixes to address testing issues on a larger test set of OS in our internal CI at work. I try to check this out tomorrow and rebase with the latest test fixes today and see what happens for me. I would love to fix the issue on the make, but honestly before this PR i never heard of lsof ( I did see the issue with netstat... ie why we get a message on the Mac about netstat not being used)

@dragon512, I was thinking more in terms of triggering the --debug --verbose AuTest job by hand (sometimes it would not be necessary) with [approve ci autest] or something of the sort.
netstat dates long back in time and on different "Unix-like" systems its parameters may differ a lot (one could compare the FreeBSD and Linux man pages to get a sense).
lsof leverages an old "treats everything as a file" philosophy but appeared fairly recently (still more than 17+ years ago, I think) and seems to be more portable (ported to a big number of "Unix-like" systems and having generally the same parameters and functionality)

[approve ci autest]
[approve ci CentOS]
[approve ci Ubuntu]

@gtenev I am adding your mac fix for port selection. in a different PR. I have a different fix for the netstat issue that I am adding to the core Autest code, and a different PR to address the change of netstat in the tests

@gtenev Where are we with this? Is this still WIP? Seems it has merge conflicts now :-).

[approve ci debian]

Going to close this for now. @gtenev Please (re)open once you have something we can land please.


Use PhantomJS from Master branch

TL;DR links aren't clickable at the moment, it's scheduled for the 2.1 release but I need this immediately. It's been merged into master, see: https://github.com/ariya/phantomjs/issues/10196

Not sure if this is a side effect but npm installing is really slow...

Hi @haydenbleasel,
thanks for this information.
However I will not use an unreleased and eventually unstable version of phantomJS in this lib.
You can use your fork of this repo as dependency, if you need it. (git://github.com//haydenbleasel/phantom-html2pdf.git)
Otherwise you need to wait for the next phantomJS release. This lib is using the latest version, so it will update without any changes.
Cheers
Dustin


linter: implement from_configuration for jsx-a11y autocomplete-valid

This closes #2362
While fixing this issue I've found that the test data differed so I've regenerated it.
There seems to be no easy way to do this (Maybe create a test regen command in just?)
This way if there are new tests added, a CI hook or something could regenerate them on new plugin releases(changes in tests might mean changes that need to be addressed in the logic as well)
I've also added the tests that pass in the plugin rule, but seem to fail here. Since I was not able to find if the test values are really correct, I've left them commented out

Thank you!

There seems to be no easy way to do this (Maybe create a test regen command in just?)

Yeah ... syncing the tests is difficult at the moment.


Add wind pressure calculation to MCMC, and modify the calculation methods for relative wind speed and direction.

Modification of the Calculation Method for Relative Wind Direction and Speed
Updated the approach to calculate relative wind direction and speed for improved accuracy.

Update to the MMG3DOF Model Considering Wind Conditions
Enhanced the MMG3DOF model to incorporate wind conditions, ensuring more realistic simulations.

Extension to MCMC Considering Wind Conditions
Expanded the MCMC framework to account for wind effects, providing better modeling capabilities.

Type Adjustments Due to the Above Changes
Adjusted type definitions to align with the modifications in wind calculation methods and model enhancements.

Addition of Libraries Required for the Above Changes
Introduced new libraries necessary to support the updated calculations and model expansions.

#47


Add units parameter to get_data for Raw

Reference issue
Partially addresses #8473.

[x] add units to Raw.get_data
[ ] add units to Epochs.get_data

What does this implement/fix?
Adds a units parameter to the get_data() function of base.py.
With units being either None, str or dict.
Additional information
Continuation of #8476.

I would do it in a new mne/io/tests/test_raw.py:test_get_data_units function.

I think that's ready for review @sappelhoff @larsoner. It does not completely close #8473 because it's only implemented for Raw and not Epochs, but I won't have much time to continue working on it unfortunately.
Doc: https://26384-1301584-gh.circle-artifacts.com/0/dev/generated/mne.io.Raw.html#mne.io.Raw.get_data

Hello, what's the status of this? 😊

Hello, what's the status of this? 😊

Hi @hoechenberger, I didn't have much time this week but will get back on it this weekend :)

Hi @hoechenberger, I didn't have much time this week but will get back on it this weekend :)

Perfect! Do not hesitate to ask for help if you get stuck!

no but it should be tested as it's advertised as supported :)

no but it should be tested as it's advertised as supported :)

Heh. Neat :) 😁

Does it make sense to refactor mne/tests/test_defaults.py:test_si_units to make use of the new conversion code? I suspect there are some redundancies now

(also our CIs are failing on all PRs due to a matplotlib issue so feel free to ignore the raw plotting errors)

Does it make sense to refactor mne/tests/test_defaults.py:test_si_units to make use of the new conversion code? I suspect there are some redundancies now

@larsoner, I deleted a good chuck of it as most of the tests were already done in _get_scaling

LGTM +1 for merge assuming CIs are happy (aside from matplotlib failures)!

Should I merge main again once the CI is fixed?

In theory you shouldn't need to, if we just restart the CIs at that point they should get the fix because they build a merged-with-main version of the PR. But you could also merge with main in your branch and it would work without needing to manually restart

Thank you, @HanBnrd!!


cmake: Add default openocd path to flash command

This piece of info is missing to flash stm32 boards using
STLink-V2 and openocd
Signed-off-by: Erwan Gouriou<EMAIL_ADDRESS>

Hi, I took your patch and continued with it in https://github.com/zephyrproject-rtos/zephyr/pull/4866

@SebastianBoe : ok. Thanks. Closed


Is it possible to set an upscale resolution?

When running mpv with a 480p anime on my lower resolution display (1920*1080), upscaling is performed well. However, moving the mpv window over to my higher resolution display (2560*1440), the video constantly stutters and is unwatchable. I assume this is because upscaling from 480p to 1440p is too demanding (although I'm still unsure if this is the cause). Is there a way to limit the upscale to 1080p?

Most of the aiupscalers only make 2x once a time.


feat: allow use of full url for pwa manifest and icons

What kind of change does this PR introduce? (check at least one)

[ ] Bugfix
[x] Feature
[ ] Code style update
[ ] Refactor
[ ] Docs
[ ] Underlying tools
[ ] Other, please describe:

Does this PR introduce a breaking change? (check one)

[ ] Yes
[x] No

Other information:
This PR allows use of pwa.manifestPath: 'https://other-domain.com/manifest.json' and makes more sense when using pwa.manifestCrossorigin: true.
I added support of full url for icons too, because it's the same way of building links.

Could you provide a practical use case for this feature, please?
I thought it makes more sense to provide a full URL for publicPath in this case.

Could you provide a practical use case for this feature, please?
I thought it makes more sense to provide a full URL for publicPath in this case.

If you do that, then all of your ressources must come from this same publicPath.
In my case, I want icons to be relative to the publicPath "/", but I want my manifest to come from a REST API with a full URL:
pwa: {
  name: 'My App',
  themeColor: '#FF6622',
  msTileColor: '#FF6622',
  favicon32: 'img/icons/favicon-32x32.png',
  manifestPath: 'https://my-api/getManifest',
  appleMobileWebAppCapable: 'yes',
  workboxOptions: {
    skipWaiting: true,
    clientsClaim: true,
    exclude: [/\.htaccess/],
  },
},

If I do that right now, I will get that in my index.html:
<link rel=manifest href=/https://my-api/getManifest>

And of course, the link is not valid.

Yeah that makes sense.


Unique symbols per precision

The libraries trans_sp and trans_dp have duplicated symbols.
This PR uses some kind of preprocessing of original files to generate files with a precision suffix like _sp and _dp, avoiding the same symbol names, so that in the future a library could link to both trans_sp and trans_dp.
The work in this PR is inherited from PR #55 by @piotrows, and tidied up a bit, but does not yet go so far to introduce wrappers that make a unified interface.
Note, commit 5329c07203270b972e75e14f9d0c5aece9687641 in this PR changes the API of setup_trans and setup_trans0 to use arguments with KIND=JPRD only.  This could be reverted and/or added in a follow-up PR if desired.
When this PR is merged and a new release is to be used in the IFS, an extra commit in ifs-source is required, which I have prepared and would be ready for review. I will update this Issue with ifs-source status.
ifs-source was using some ectrans internal modules or subroutines without including the interface.
So even without API change in setup_trans, the ifs-source commit would be required.

Note, preprocessing is based on sed. On macOS 13 this works but on the CI it does not work yet.
Either a workaround will be needed before merging, or we update the macOS runner. Further investigation needed.

First read over completed. Here is my summary:

Where possible, PARKIND1 replaced with EC_PARKIND
PWEIGHT and PSTRET arguments to SETUP_TRANS and corresponding module variables in TPM_DISTR, TPM_GEOMETRY made double precision always
PRAD argument to SETUP_TRANS0 made double precision always
SPECNORM PNORM argument made mandatory - Why is this necessary?
ectrans_common library created based on subset of JPRB-agnostic modules
ectrans_{sp/dp} "backend libraries" created with JPRB-dependent modules

I'd like some more time to read the new CMake functionality for generating the ectrans_${prec} libraries, but feel free to respond to the above comments in the mean time.

Where possible, PARKIND1 replaced with EC_PARKIND

I only applied this to some routines, but we could push this through everywhere JPRB is not needed.

PWEIGHT and PSTRET arguments to SETUP_TRANS and corresponding module variables in TPM_DISTR, TPM_GEOMETRY made double precision always

Correct. These are arguments that are only needed to set up the grid point domain decomposition.

PRAD argument to SETUP_TRANS0 made double precision always

Yes, this makes TPM_CONSTANTS module independent of JPRB.

SPECNORM PNORM argument made mandatory - Why is this necessary?

It is in fact not necessary for this PR, but disambiguates overload on this argument's KIND of this routine in the future. All optional arguments cannot be disambiguated. In practice this argument is always required. Otherwise what's the point. Trying this change in ifs-source proved that this argument is never omitted. This change could be removed from this PR and introduced later, but it's pretty harmless.

ectrans_common library created based on subset of JPRB-agnostic modules

It is also enlightening to see which routines and modules are not used for the actual transforms.

ectrans_{sp/dp} "backend libraries" created with JPRB-dependent modules

I'd like some more time to read the new CMake functionality for generating the ectrans_${prec} libraries, but feel free to respond to the above comments in the mean time.

Noteworthy is that neither backend libraries ectrans_sp and ectrans_dp link with parkind_sp or parkind_dp because the preprocessor step replaces parkind1 with ec_parkind and JPRB with JPRD or JPRM.

Rebased on recently merged CY49R1 sync branch

I added commit f77550c to develop branch which updates the macOS runner to macos-13. Having rebased this branch on develop now fixes the 'sed' issues previously present.

JPIB is better.
JPIA has become too ambiguous.
----- Météo-France -----
EL KHATIB Ryad
DESR/CNRM/GMAP/ALGO
@.***
Fixe : +33 561078466

De: "Sam Hatfield" @.>
À: "ecmwf-ifs/ectrans" @.>
Cc: "ryad el khatib" @.>, "Mention"
@.>
Envoyé: Mercredi 14 Février 2024 16:36:16
Objet: Re: [ecmwf-ifs/ectrans] Unique symbols per precision (PR #61)

@samhatfield commented on this pull request.

In [ https://github.com/ecmwf-ifs/ectrans/pull/61#discussion_r1489678436 |
src/trans/internal/trgtol_mod.F90 ] :

@@ -472,7 +472,7 @@ SUBROUTINE
TRGTOL_COMM(PGLAT,KF_FS,KF_GP,KF_SCALARS_G,KVSET,&
INTEGER(KIND=JPIM) :: ISEND, ITAG, JBLK, JFLD, JK, JL, IFLD, II, IFLDS, INS, INR
INTEGER(KIND=JPIM) :: JJ,JI,IFLDT, J

-INTEGER(KIND=JPIA) :: JFLD64
+INTEGER(KIND=JPIB) :: JFLD64

This variable was introduced in my CY49R1 [
https://github.com/ecmwf-ifs/ectrans/commit/635f9bb1c36c40945077e8f7e1ca68649ad794e6#diff-d50752e10eeb0069e066a6ac0bd9fea3ed72921d7b40aa07cfb5edca47d6efd2R475
| sync commit ] . I think [ https://github.com/RyadElKhatibMF | @RyadElKhatibMF
] picked JPIA for a reason but not sure why. Can we keep it?

—
Reply to this email directly, [
https://github.com/ecmwf-ifs/ectrans/pull/61#pullrequestreview-1880625399 |
view it on GitHub ] , or [
https://github.com/notifications/unsubscribe-auth/AYEAC4OUHKJ6MARY4CEFUZLYTTKXBAVCNFSM6AAAAABDARCI6WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTQOBQGYZDKMZZHE
| unsubscribe ] .
You are receiving this because you were mentioned. Message ID:
@.***>

I finally read through the CMake changes and that looks good to me! I think I'm starting to like CMake.
Can internal/sutrle_mod.F90 be added to the common library?
Also external/setup_trans.F90?

I finally read through the CMake changes and that looks good to me! I think I'm starting to like CMake.
Can internal/sutrle_mod.F90 be added to the common library?
Also external/setup_trans.F90?

Hi @samhatfield these files unfortunately cannot be added to the common library because they USE modules that have themselves JPRB. e.g. TPM_FIELDS

Good to merge for me.

Merged in develop now! Thanks everyone, especially @piotrows for the majority of all work included in this PR. 🙏


MINOR: Doc of 'retries' config should mention about max.in.flight.requests.per.connection to avoid confusion

When I first read the doc of producer config retries, it was quite confusing because it sounds like there's no way to guarantee in-order message producing with keep it durable for broker failure.
If my understanding is correct, I felt it is much kind if the doc of retries mention about max.in.flight.requests.per.connection.

@ijuma would you mind reviewing this?

Thanks for the PR. Left a couple of minor comments. Also, can you please edit the PR description to simply describe the change (or simply leave it blank if the PR title is enough)? The PR title and PR description are combined to form the commit message in the merged commit.

The PR title and PR description are combined to form the commit message in the merged commit.

Oh yeah I knew this. It's bit tricky but let me try leaving a description of PR as the first comment from the next time.

@ijuma Thanks for the review. Updated.

LGTM

Thanks for the PR, merged to trunk and 0.10.0 branches.


Fix benign "bug"

In the Encode_Non_Initial_G_Front_Vowel method inside  Metaphone3.java. The negation is redundant since if m_current equaled 3 and it was indeed prefixed with "MAC" the first condition would fail, and we'd land where we need to anyway.
if(
  ! ((m_current == 2) && StringAt(0, 2, "MC", ""))
  || ((m_current == 3) && StringAt(0, 3, "MAC", ""))
)

Thanks! I am unclear on if the change causes any visible difference for users in the end - it seems like it does not, right?
I had a cursory look at this class and there seems to be quite a few other places where some conditions cannot be reached because of the surrounding context. I don't think this is really worth cleaning up to be honest. As @tfmorris said, it's not tested, and I think it's also not worth investing too much effort into getting a decent coverage (see #6400).
I'd be interested to know what brought you to submitting this change in the first place. How did you notice this "bug"? What was your motivation to work on it?

Closing per the above, feel free to reopen @aminnaggar if you feel like we have misunderstood your motivation here.

That's super fair, I'd do the same. I wasn't aware of the poor test coverage here, and it's not the kind of thing worth investing a bunch of time on.
re: how I found it: I was porting it to typescript and my linter started yelling at me lol.
Nice meeting both of you, apologies for the distraction.


Adding sine, cosine, logn, abs, square, squareroot, inverse square root

Adding sine, cosine, logn, abs, square, squareroot, inverse square root

merged these changes manually


Change PUT/Replace on objects so it does not do delete/insert.

Change PUT/Replace on objects so it does not do delete/insert. Also add test cases to check observation is still notified when resources are updated by an object replace.
Signed-off-by: delme-imgtec<EMAIL_ADDRESS>

retest this please


Generated CAN ID exceeds 11 bits on Classic Mode

I tried running the library on Arduino Uno by following the instructions on the README.md.
My initialization routine is as follows:
CanardInstance* libcanard_init(void)
{
    static CanardInstance ins = canardInit(&memAllocate, &memFree);

    ins.mtu_bytes = CANARD_MTU_CAN_CLASSIC;  // Defaults to 64 (CAN FD); here we select Classic CAN.
    ins.node_id   = 42;                      // Defaults to anonymous; can be set up later at any point.

    return &ins;
}

I first verified how the payload is separated into frames by creating two tasks - one that periodically pushes the message to canard and one that pops the transfer frame. To see the packetized CAN frames I printed them out first on a serial monitor.
void task_publishlibcanard(void)
{
/**Publish a message */
    static uint8_t my_message_transfer_id;  // Must be static or heap-allocated to retain state between calls.
    const CanardTransfer transfer = {
        .timestamp_usec = micros() + 10000,      // Zero if transmission deadline is not limited.
        .priority       = CanardPriorityNominal,
        .transfer_kind  = CanardTransferKindMessage,
        .port_id        = 1234,                       // This is the subject-ID.
        .remote_node_id = CANARD_NODE_ID_UNSET,       // Messages cannot be unicast, so use UNSET.
        .transfer_id    = my_message_transfer_id,
        .payload_size   = 47,
        .payload        = "\x2D\x00" "Sancho, it strikes me thou art in great fear.",
    };
    ++my_message_transfer_id;  // The transfer-ID shall be incremented after every transmission on this subject.
    int32_t result = canardTxPush(myCanardIns, &transfer);
    if (result < 0)
    {
        // An error has occurred: either an argument is invalid or we've ran out of memory.
        // It is possible to statically prove that an out-of-memory will never occur for a given application if the
        // heap is sized correctly; for background, refer to the Robson's Proof and the documentation for O1Heap.
        abort();
    }
}

Here's two consecutive set of periodic CAN frames I got on my serial monitor:
tx [2D 00 53 61 6E 63 68 BC ] ID: d22a
tx [6F 2C 20 69 74 20 73 1C ] ID: d22a
tx [74 72 69 6B 65 73 20 3C ] ID: d22a
tx [6D 65 20 74 68 6F 75 1C ] ID: d22a
tx [20 61 72 74 20 69 6E 3C ] ID: d22a
tx [20 67 72 65 61 74 20 1C ] ID: d22a
tx [66 65 61 72 2E 62 BB 7C ] ID: d22a

tx [2D 00 53 61 6E 63 68 BD ] ID: d22a
tx [6F 2C 20 69 74 20 73 1D ] ID: d22a
tx [74 72 69 6B 65 73 20 3D ] ID: d22a
tx [6D 65 20 74 68 6F 75 1D ] ID: d22a
tx [20 61 72 74 20 69 6E 3D ] ID: d22a
tx [20 67 72 65 61 74 20 1D ] ID: d22a
tx [66 65 61 72 2E 62 BB 7D ] ID: d22a
...

So far so good. But the value of txf->extended_can_id is 0xd22a, which clearly exceeds 0x7ff, the maximum ID for a CAN classical frame.
For added information, my media layer mock looks like this:

bool pleaseTransmit(const CanardFrame *txf)
{
  uint8_t *payload = (uint8_t*)(txf->payload);
  printf("tx [");
  for( size_t i = 0; i < txf->payload_size; ++i )
  {
    printf("%02X ", payload[i]);
  }
  printf("] ");
  printf("ID: %x\r\n", txf->extended_can_id);
}

Is this a known issue or am I missing something on the initialization?

Sorry, I mixed up the concepts of Classic/FD CAN and 11-bit/Extended IDs. Ignore this issue!


Compatible nosec clause

Description
Compatible nosec clause
Type of change

Refactor (refactoring code, removing useless files)

Testing steps
Done on CI
Checklist

[ ] make before_commit passes
[ ] updated documentation wherever necessary
[ ] added or modified tests if necessary
[ ] updated schemas and validators in insights-data-schemas in case of input/output change

Codecov Report

Merging #222 (b7dade1) into master (9c93f21) will not change coverage.
The diff coverage is 0.00%.

@@           Coverage Diff           @@
##           master     #222   +/-   ##
=======================================
  Coverage   92.54%   92.54%
=======================================
  Files          33       33
  Lines        1087     1087
=======================================
  Hits         1006     1006
  Misses         66       66
  Partials       15       15

Impacted Files
Coverage Δ

http/openapi.go
46.34% <0.00%> (ø)

Continue to review full report at Codecov.

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


Command fields not cleared after autocompletion

My application, jsoar, includes a REPL, and all the commands are implemented using picocli (I love picocli!). As part of this, we use picocli to recommend command completions as users type. It appears that sometimes a command's fields are not cleared between executions, so that if the same command is executed twice with different arguments, the wrong thing happens (e.g., it may execute as if the command were given the first set of arguments instead of the second). This appears to have something to do with autocompletion, because if I remove the call to picocli.AutoComplete.complete then the commands execte as expected (although then the completion doesn't work of course).
I have created a junit test in my project that reproduces the issue:
https://github.com/soartech/jsoar/blob/picocli-field-not-reset/jsoar-core/src/test/java/org/jsoar/kernel/commands/QMemoryCommandTest.java
Note this is on the picocli-field-not-reset branch of the repo. There are comments in the test explaining what is expected to happen.
I ran the test with -Dpicocli.trace=DEBUG. I believe the relevant output is below (does not include all of the initial command registration, which is a LOT of output as there are many commands).
[picocli DEBUG] Creating CommandSpec for org.jsoar.kernel.commands.QMemoryCommand$QMemoryC@7f485fda with factory picocli.CommandLine$DefaultFactory
[picocli DEBUG] Creating CommandSpec for class picocli.CommandLine$HelpCommand with factory picocli.CommandLine$DefaultFactory
[picocli DEBUG] Adding subcommand 'help' to 'qmemory'
[picocli DEBUG] Creating CommandSpec for org.jsoar.kernel.commands.QMemoryCommand$QMemoryC@7f485fda with factory picocli.CommandLine$DefaultFactory
[picocli DEBUG] Creating CommandSpec for class picocli.CommandLine$HelpCommand with factory picocli.CommandLine$DefaultFactory
[picocli DEBUG] Adding subcommand 'help' to 'qmemory'
[picocli DEBUG] extractCommandSpec returning existing CommandSpec instance command 'qmemory' (user object: org.jsoar.kernel.commands.QMemoryCommand$QMemoryC@7f485fda)
[picocli INFO] Picocli version: 4.6.3, JVM: 1.8.0_261 (Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.261-b12), OS: Windows 10 10.0 amd64
[picocli INFO] Parsing 4 command line args [qmemory, --set, a, foo]
[picocli DEBUG] Parser configuration: optionsCaseInsensitive=false, subcommandsCaseInsensitive=false, abbreviatedOptionsAllowed=false, abbreviatedSubcommandsAllowed=false, aritySatisfiedByAttachedOptionParam=false, atFileCommentChar=#, caseInsensitiveEnumValuesAllowed=false, collectErrors=true, endOfOptionsDelimiter=--, expandAtFiles=true, limitSplit=false, overwrittenOptionsAllowed=false, posixClusteredShortOptionsAllowed=true, separator=null, splitQuotedStrings=false, stopAtPositional=false, stopAtUnmatched=false, toggleBooleanFlags=false, trimQuotes=false, unmatchedArgumentsAllowed=false, unmatchedOptionsAllowedAsOptionParameters=true, unmatchedOptionsArePositionalParams=false, useSimplifiedAtFiles=false
[picocli DEBUG] (ANSI is disabled by default: systemproperty[picocli.ansi]=null, isatty=false, TERM=null, OSTYPE=null, isWindows=true, JansiConsoleInstalled=false, ANSICON=null, ConEmuANSI=null, NO_COLOR=null, CLICOLOR=null, CLICOLOR_FORCE=null)
[picocli DEBUG] Initializing command 'qmemory' (user object: org.jsoar.kernel.commands.QMemoryCommand$QMemoryC@7f485fda): 4 options, 0 positional parameters, 0 required, 0 groups, 1 subcommands.
[picocli DEBUG] Set initial value for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.getPath of type class java.lang.String to null.
[picocli DEBUG] Set initial value for field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue of type class [Ljava.lang.String; to null.
[picocli DEBUG] Set initial value for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.removePath of type class java.lang.String to null.
[picocli DEBUG] Set initial value for field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear of type boolean to false.
[picocli DEBUG] [0] Processing argument 'qmemory'. Remainder=[--set, a, foo]
[picocli DEBUG] 'qmemory' cannot be separated into <option>=<option-parameter>
[picocli DEBUG] Could not find option 'qmemory', deciding whether to treat as unmatched option or positional parameter...
[picocli DEBUG] No option named 'qmemory' found. Processing as positional parameter
[picocli DEBUG] 'qmemory' doesn't resemble an option: 0 matching prefix chars out of 8 option names
[picocli DEBUG] [0] Processing next arg as a positional parameter. Command-local position=0. Remainder=[qmemory, --set, a, foo]
[picocli DEBUG] Consumed 0 arguments and 0 interactive values, moving command-local position to index 0.
[picocli DEBUG] [1] Processing argument '--set'. Remainder=[a, foo]
[picocli DEBUG] '--set' cannot be separated into <option>=<option-parameter>
[picocli DEBUG] Found option named '--set': field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue, arity=2
[picocli DEBUG] Single-character arguments that don't match known options are considered positional parameters
[picocli INFO] Adding [a] to field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue for option --set on QMemoryC@7f485fda
[picocli DEBUG] 'foo' doesn't resemble an option: 0 matching prefix chars out of 8 option names
[picocli INFO] Adding [foo] to field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue for option --set on QMemoryC@7f485fda
[picocli DEBUG] Applying default values for command 'qmemory'
[picocli DEBUG] defaultValue not defined for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.getPath
[picocli DEBUG] defaultValue not defined for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.removePath
[picocli DEBUG] Applying defaultValue (false) to field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear on QMemoryC@7f485fda
[picocli DEBUG] 'false' doesn't resemble an option: 0 matching prefix chars out of 8 option names
[picocli INFO] Setting field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear to 'false' (was 'false') for field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear on QMemoryC@7f485fda
[picocli INFO] Unmatched arguments: [qmemory]
[picocli INFO] Picocli version: 4.6.3, JVM: 1.8.0_261 (Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.261-b12), OS: Windows 10 10.0 amd64
[picocli INFO] Parsing 3 command line args [--set, a, foo]
[picocli DEBUG] Parser configuration: optionsCaseInsensitive=false, subcommandsCaseInsensitive=false, abbreviatedOptionsAllowed=false, abbreviatedSubcommandsAllowed=false, aritySatisfiedByAttachedOptionParam=false, atFileCommentChar=#, caseInsensitiveEnumValuesAllowed=false, collectErrors=false, endOfOptionsDelimiter=--, expandAtFiles=true, limitSplit=false, overwrittenOptionsAllowed=false, posixClusteredShortOptionsAllowed=true, separator=null, splitQuotedStrings=false, stopAtPositional=false, stopAtUnmatched=false, toggleBooleanFlags=false, trimQuotes=false, unmatchedArgumentsAllowed=false, unmatchedOptionsAllowedAsOptionParameters=true, unmatchedOptionsArePositionalParams=true, useSimplifiedAtFiles=false
[picocli DEBUG] (ANSI is disabled by default: systemproperty[picocli.ansi]=null, isatty=false, TERM=null, OSTYPE=null, isWindows=true, JansiConsoleInstalled=false, ANSICON=null, ConEmuANSI=null, NO_COLOR=null, CLICOLOR=null, CLICOLOR_FORCE=null)
[picocli DEBUG] Initializing command 'qmemory' (user object: org.jsoar.kernel.commands.QMemoryCommand$QMemoryC@7f485fda): 4 options, 0 positional parameters, 0 required, 0 groups, 1 subcommands.
[picocli DEBUG] Set initial value for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.getPath of type class java.lang.String to null.
[picocli DEBUG] Set initial value for field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue of type class [Ljava.lang.String; to [Ljava.lang.String;@a37aefe.
[picocli DEBUG] Set initial value for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.removePath of type class java.lang.String to null.
[picocli DEBUG] Set initial value for field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear of type boolean to false.
[picocli DEBUG] [0] Processing argument '--set'. Remainder=[a, foo]
[picocli DEBUG] '--set' cannot be separated into <option>=<option-parameter>
[picocli DEBUG] Found option named '--set': field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue, arity=2
[picocli DEBUG] Single-character arguments that don't match known options are considered positional parameters
[picocli INFO] Adding [a] to field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue for option --set on QMemoryC@7f485fda
[picocli DEBUG] 'foo' doesn't resemble an option: 0 matching prefix chars out of 8 option names
[picocli INFO] Adding [foo] to field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue for option --set on QMemoryC@7f485fda
[picocli DEBUG] Applying default values for command 'qmemory'
[picocli DEBUG] defaultValue not defined for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.getPath
[picocli DEBUG] defaultValue not defined for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.removePath
[picocli DEBUG] Applying defaultValue (false) to field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear on QMemoryC@7f485fda
[picocli DEBUG] 'false' doesn't resemble an option: 0 matching prefix chars out of 8 option names
[picocli INFO] Setting field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear to 'false' (was 'false') for field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear on QMemoryC@7f485fda
[picocli DEBUG] Creating CommandSpec for org.jsoar.kernel.commands.QMemoryCommand$QMemoryC@7f485fda with factory picocli.CommandLine$DefaultFactory
[picocli DEBUG] Creating CommandSpec for class picocli.CommandLine$HelpCommand with factory picocli.CommandLine$DefaultFactory
[picocli DEBUG] Adding subcommand 'help' to 'qmemory'
[picocli DEBUG] Creating CommandSpec for org.jsoar.kernel.commands.QMemoryCommand$QMemoryC@7f485fda with factory picocli.CommandLine$DefaultFactory
[picocli DEBUG] Creating CommandSpec for class picocli.CommandLine$HelpCommand with factory picocli.CommandLine$DefaultFactory
[picocli DEBUG] Adding subcommand 'help' to 'qmemory'
[picocli DEBUG] extractCommandSpec returning existing CommandSpec instance command 'qmemory' (user object: org.jsoar.kernel.commands.QMemoryCommand$QMemoryC@7f485fda)
[picocli INFO] Picocli version: 4.6.3, JVM: 1.8.0_261 (Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.261-b12), OS: Windows 10 10.0 amd64
[picocli INFO] Parsing 2 command line args [qmemory, --clear]
[picocli DEBUG] Parser configuration: optionsCaseInsensitive=false, subcommandsCaseInsensitive=false, abbreviatedOptionsAllowed=false, abbreviatedSubcommandsAllowed=false, aritySatisfiedByAttachedOptionParam=false, atFileCommentChar=#, caseInsensitiveEnumValuesAllowed=false, collectErrors=true, endOfOptionsDelimiter=--, expandAtFiles=true, limitSplit=false, overwrittenOptionsAllowed=false, posixClusteredShortOptionsAllowed=true, separator=null, splitQuotedStrings=false, stopAtPositional=false, stopAtUnmatched=false, toggleBooleanFlags=false, trimQuotes=false, unmatchedArgumentsAllowed=false, unmatchedOptionsAllowedAsOptionParameters=true, unmatchedOptionsArePositionalParams=false, useSimplifiedAtFiles=false
[picocli DEBUG] (ANSI is disabled by default: systemproperty[picocli.ansi]=null, isatty=false, TERM=null, OSTYPE=null, isWindows=true, JansiConsoleInstalled=false, ANSICON=null, ConEmuANSI=null, NO_COLOR=null, CLICOLOR=null, CLICOLOR_FORCE=null)
[picocli DEBUG] Initializing command 'qmemory' (user object: org.jsoar.kernel.commands.QMemoryCommand$QMemoryC@7f485fda): 4 options, 0 positional parameters, 0 required, 0 groups, 1 subcommands.
[picocli DEBUG] Set initial value for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.getPath of type class java.lang.String to null.
[picocli DEBUG] Set initial value for field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue of type class [Ljava.lang.String; to [Ljava.lang.String;@6b6776cb.
[picocli DEBUG] Set initial value for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.removePath of type class java.lang.String to null.
[picocli DEBUG] Set initial value for field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear of type boolean to false.
[picocli DEBUG] [0] Processing argument 'qmemory'. Remainder=[--clear]
[picocli DEBUG] 'qmemory' cannot be separated into <option>=<option-parameter>
[picocli DEBUG] Could not find option 'qmemory', deciding whether to treat as unmatched option or positional parameter...
[picocli DEBUG] No option named 'qmemory' found. Processing as positional parameter
[picocli DEBUG] 'qmemory' doesn't resemble an option: 0 matching prefix chars out of 8 option names
[picocli DEBUG] [0] Processing next arg as a positional parameter. Command-local position=0. Remainder=[qmemory, --clear]
[picocli DEBUG] Consumed 0 arguments and 0 interactive values, moving command-local position to index 0.
[picocli DEBUG] [1] Processing argument '--clear'. Remainder=[]
[picocli DEBUG] '--clear' cannot be separated into <option>=<option-parameter>
[picocli DEBUG] Found option named '--clear': field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear, arity=0
[picocli INFO] Setting field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear to 'true' (was 'false') for option --clear on QMemoryC@7f485fda
[picocli DEBUG] Applying default values for command 'qmemory'
[picocli DEBUG] defaultValue not defined for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.getPath
[picocli DEBUG] defaultValue not defined for field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue
[picocli DEBUG] defaultValue not defined for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.removePath
[picocli INFO] Unmatched arguments: [qmemory]
[picocli INFO] Picocli version: 4.6.3, JVM: 1.8.0_261 (Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 25.261-b12), OS: Windows 10 10.0 amd64
[picocli INFO] Parsing 1 command line args [--clear]
[picocli DEBUG] Parser configuration: optionsCaseInsensitive=false, subcommandsCaseInsensitive=false, abbreviatedOptionsAllowed=false, abbreviatedSubcommandsAllowed=false, aritySatisfiedByAttachedOptionParam=false, atFileCommentChar=#, caseInsensitiveEnumValuesAllowed=false, collectErrors=false, endOfOptionsDelimiter=--, expandAtFiles=true, limitSplit=false, overwrittenOptionsAllowed=false, posixClusteredShortOptionsAllowed=true, separator=null, splitQuotedStrings=false, stopAtPositional=false, stopAtUnmatched=false, toggleBooleanFlags=false, trimQuotes=false, unmatchedArgumentsAllowed=false, unmatchedOptionsAllowedAsOptionParameters=true, unmatchedOptionsArePositionalParams=true, useSimplifiedAtFiles=false
[picocli DEBUG] (ANSI is disabled by default: systemproperty[picocli.ansi]=null, isatty=false, TERM=null, OSTYPE=null, isWindows=true, JansiConsoleInstalled=false, ANSICON=null, ConEmuANSI=null, NO_COLOR=null, CLICOLOR=null, CLICOLOR_FORCE=null)
[picocli DEBUG] Initializing command 'qmemory' (user object: org.jsoar.kernel.commands.QMemoryCommand$QMemoryC@7f485fda): 4 options, 0 positional parameters, 0 required, 0 groups, 1 subcommands.
[picocli DEBUG] Set initial value for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.getPath of type class java.lang.String to null.
[picocli DEBUG] Set initial value for field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue of type class [Ljava.lang.String; to [Ljava.lang.String;@a37aefe.
[picocli DEBUG] Set initial value for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.removePath of type class java.lang.String to null.
[picocli DEBUG] Set initial value for field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear of type boolean to false.
[picocli DEBUG] [0] Processing argument '--clear'. Remainder=[]
[picocli DEBUG] '--clear' cannot be separated into <option>=<option-parameter>
[picocli DEBUG] Found option named '--clear': field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear, arity=0
[picocli INFO] Setting field boolean org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.clear to 'true' (was 'false') for option --clear on QMemoryC@7f485fda
[picocli DEBUG] Applying default values for command 'qmemory'
[picocli DEBUG] defaultValue not defined for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.getPath
[picocli DEBUG] defaultValue not defined for field String[] org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.setPathAndValue
[picocli DEBUG] defaultValue not defined for field String org.jsoar.kernel.commands.QMemoryCommand$QMemoryC.removePath

One idea is to construct and return a new CommandLine instance from getCommand instead of caching the CommandLine instance.
Another idea is to define the array option such that it has a default, but you'd have to try to see if that helps:
//QMemoryCommand.QMemoryC
        @Option(names={"-s", "--set"}, arity="2", description="Path and item to set in qmemory (2 parameters required)")
        String[] setPathAndValue = new String[];

Sorry, my time is extremely limited at the moment...
If you find the cause, and can provide a PR with a test that demonstrates the issue and a fix, I can review and merge it.

Unfortunately, constructing a new CommandLine won't work for me because of performance (see our discussion from several years ago here: https://stackoverflow.com/questions/59415247/how-to-improve-command-performance-at-runtime).
I tried setting a default value for all the fields, but this did not fix the problem.
I haven't yet figured out the actual problem, but I was able to update the test to further narrow the possibilities -- it is only necessary to do the second autocomplete to cause the problem. In stepping through picocli.AutoComplete.complete() it appears that during the process of clearing the fields, the initial value for the setPathAndValue field gets set to the previous call's arguments. The callstack at that point looks like this:
CommandLine$Model$OptionSpec(CommandLine$Model$ArgSpec).initialValue() line: 8878
CommandLine$Model$OptionSpec(CommandLine$Model$ArgSpec).applyInitialValue(CommandLine$Tracer) line: 8668
CommandLine$Interpreter.clear(CommandLine$Model$ArgSpec) line: 13129
CommandLine$Interpreter.clear() line: 13116
CommandLine$Interpreter.parse(List<CommandLine>, Stack<String>, String[], List<Object>, Collection<ArgSpec>, Set<ArgSpec>) line: 13156
CommandLine$Interpreter.parse(List<CommandLine>, Stack<String>, String[], List<Object>, Collection<ArgSpec>) line: 13146
CommandLine$Interpreter.parse(String...) line: 13047
CommandLine.parseArgs(String...) line: 1478
AutoComplete.complete(CommandSpec, String[], int, int, int, List<CharSequence>) line: 849

The line annotatedElement.getter().get() is returning the value from the previous call to this command instead of the actual initial value. I'm not sure where annotatedElement is coming from or how its value got changed.
Unfortunately I'm also very busy, so this is as far as I can get for this weekend. Perhaps this gives you an idea I can look into next weekend?

Thanks for looking into this!
I’ll try to take a closer look when I’m back from traveling.

On Nov 5, 2022, at 16:45, marinier @.***> wrote:

I updated to picocli 4.7.0. The issue did not magically go away, but it changed a little (now the problem occurs when
I understand part of the issue a bit better. Internally, I have my classes that are annotated with @Command, and these are cached (there is only ever one instance of each command, and they get reused).
The problem appears to be that the CommandLine$Model$OptionSpec objects used by AutoComplete for each option are different than the one that is used when executing the commands, but both wrap the same underlying @Command object for a given command. AutoComplete correctly caches the initialValue for an option (in CommandLine$Model$OptionSpec.initialValue()), and then the underlying command object is modified based on the options that were passed in. But this CommandLine$Model$OptionSpec is lost and we end up with a new one when the execution happens, so the initial value gets cached again in the new instance of CommandLine$Model$OptionSpec, which does not have a cached value yet. So during initialValue() it gets the current value of the field, seemingly assuming that the underlying command object is "fresh" -- but it's the same object that was modified during autocompletion, so the value it gets is the values from the options that were passed in as part of autocomplete, and that gets cached as the initial value. And that CommandLine$Model$OptionSpec is reused for all future executions of this command, and thus everything has the wrong initial value for the fields that were modified during the autocomplete.
I was able to seemingly fix this on my end by doing two things:
For command executions I'm already caching the CommandLine object so it gets reused, but for autocompletion I was creating a new CommandLine object each time. Now I use the cached one instead (that is, I get the CommandSpec from the cached CommandLine, which is what AutoComplete.complete needs -- it creates a new CommandLine from that internally).
As part of autocompletion I was creating a fresh CommandSpec each time via:
// we need to get a "fresh" command spec each time to avoid accidentally reusing one that may already be in use
CommandSpec commandSpec = CommandSpec.forAnnotatedObject(commandLine.getCommandSpec().userObject());
I removed that, and combined with reusing the CommandLine object, it appears to work now. The comment above implies that the person who wrote that thought it was needed for what sounds like a threading issue, but since that was originally written I fixed a bunch of threading issues and I'm pretty sure this is no longer needed.
So I was able to make it work in my application. It's still not clear to me if this means there's no problem in AutoComplete or if there is in fact a problem and I'm just working around it. At the very least, it was possible to get things into a bad state without it being obvious why.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.


Freeze the screen AFTER the capture call to eliminate the occasional…

I added the change proposed by @bfichter  in #83
This should fix #83

It turned out that the described change did not fix the issue #83.


State change feedback to alexa app

I am looking for any function which can update state in alexa app if device is turn on using button on Esp board.

It worked with setVal function.

Hey! Do you have an example? I'm doing the same here, but i don't know how to implement...
Thanks.


JARs import proposal

When I import freshly downloaded gdx projects from the repository, they all are "red" because of missing jars:

I know the documentation says that I have to download the missing jars from the gdx-nightly server and manually re-import them (which btw is not very handy).
I would like to propose (I believe) a better solution that I already successfully use for the JAR's import.
The idea is that:

You create a new repository and call it gdx-nightly.
There you upload an eclipse project that contains all the jars. Here is an example: https://github.com/JFixby/libgdx-nightly
Then you import that project into eclipse workspace and link the jars.

That would be a solution for the Eclipse.
Now when you import freshly downloaded gdx projects from the repository, they will all immediately resolve the missing jars right when you import the gdx-nightly into your workspace.
Pros:

no manual resolution, just import the gdx-nightly
you can deduce related paragraph in the doc to simple "just import the gdx-nightly"
bonus: you can use git to switch libraries between versions to test you code against older jars

I don't understand what it is you are trying to accomplish here.
Is it simply that you don't want to have to run the fetch script when cloning the libgdx repo? Dropping binaries into a git repo is generally a bad idea, and is the reason there is a fetch script in the first place.

Please use ant -f fetch.xml and close this issue.
On Mar 7, 2016 6:32 PM, "Justin Shapcott"<EMAIL_ADDRESS>wrote:

I don't understand what it is you are trying to accomplish here.
Is it simply that you don't want to have to run the fetch script when
cloning the libgdx repo? Dropping binaries into a git repo is generally a
bad idea, and is the reason there is a fetch script in the first place.
—
Reply to this email directly or view it on GitHub
https://github.com/libgdx/libgdx/issues/3905#issuecomment-193361837.

Sorry for my ignorance about the Ant.

How to call the ant -f fetch.xml in Windows?

Install ant, and use ant -f fetch.xml. Or use the gradle wrapper, and run ./gradlew fetchNatives

I thought it is some feature of the Eclipse.
Ok, I downloaded ant http://ant.apache.org/bindownload.cgi
and called <%AntLocation%>\bin\ant -f fetch.xml from the lingdx directory. Seems to be working.

Yet gdx-controllers-desktop is red due to the missing gdx-controllers-desktop-natives.jar


build: add some internal advanced variables for Python detection

The FindPython* modules are more clever and try really hard to find
the interpreter themselves.  Add additional internal variables to force
them to select the version we would like.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@swift-ci please smoke test

@swift-ci please clean test

Build failed
Swift Test Linux Platform
Git Sha - aaf508bb78a24edd2c939be7e66f9157e0b1b8e4

Build failed
Swift Test OS X Platform
Git Sha - aaf508bb78a24edd2c939be7e66f9157e0b1b8e4


MGDCTRS-584 Make apicurio.auth.service.url and apicurio.auth.realm configurable via ConfigMap

https://issues.redhat.com/browse/MGDCTRS-584

LGTM. Let @lburgazzoli take a final look when he is back from PTO.

Looks very good now! Thx a lot @ani-sha. Applied


Idea: Allow  at any depth

It would be handy to support <Animatable> elements at any depth under a <AnimationGroup> or <AnimationSequence>.  I.e.
<AnimationGroup ...>
  <Animatable ...>

      ohai
      <Animatable ...>

ohai2u

      </Animatable>

  </Animatable>

I'm unsure what all the implications would be though. Would crawling the element tree on render going to be too much of a perf burden?  Similarly, someone might be tempted to nesting <Animatable>s inside other <Animatable> - though, that should be ok, I think :P

@nevir this is a great idea, I haven't gotten around to tackling it however. That was the main idea around the `Animatable

Yeah, no worries - and thanks for building this project out; it's already been tremendously helpful :)

+1 for this feature.