immugw as auditor - error - unknown method CurrentRoot

What happened
I don't know if this problem is a bug but, please, I need guidance to overcome the issue.
I am using immudb (v.1.3.2) and immugw (latest) as docker containers.
Immugw container is set to run as auditor (IMMUGW_AUDIT=true). Actually the environment variables are:
    environment:
      - IMMUGW_ADDRESS=<IP_ADDRESS>
      - IMMUGW_PORT=3323
      - IMMUGW_IMMUDB_ADDRESS=immudb
      - IMMUGW_IMMUDB_PORT=3322
      - IMMUGW_AUDIT=true
      - IMMUGW_AUDIT_INTERVAL=1m
      - IMMUGW_AUDIT_USERNAME=immudb
      - IMMUGW_AUDIT_PASSWORD=immudb

Unfortunately, inside immugw log I have noticed an error :
error getting current root: rpc error: code = Unimplemented desc = unknown method CurrentRoot for service immudb.schema.ImmuService

I don't understand what I am doing wrong. Should I perform additional configuration ?
What you expected to happen
immugw to run in audit mode without errors
How to reproduce it (as minimally and precisely as possible)
Environment
Additional info (any other context about the problem)

What happened I don't know if this problem is a bug but, please, I need guidance to overcome the issue.
I am using immudb (v.1.3.2) and immugw (latest) as docker containers. Immugw container is set to run as auditor (IMMUGW_AUDIT=true). Actually the environment variables are:
    environment:
      - IMMUGW_ADDRESS=<IP_ADDRESS>
      - IMMUGW_PORT=3323
      - IMMUGW_IMMUDB_ADDRESS=immudb
      - IMMUGW_IMMUDB_PORT=3322
      - IMMUGW_AUDIT=true
      - IMMUGW_AUDIT_INTERVAL=1m
      - IMMUGW_AUDIT_USERNAME=immudb
      - IMMUGW_AUDIT_PASSWORD=immudb

Unfortunately, inside immugw log I have noticed an error :
error getting current root: rpc error: code = Unimplemented desc = unknown method CurrentRoot for service immudb.schema.ImmuService

I don't understand what I am doing wrong. Should I perform additional configuration ?
What you expected to happen immugw to run in audit mode without errors
How to reproduce it (as minimally and precisely as possible)
Environment
Additional info (any other context about the problem)

Hi @cezar-radan, thanks for reaching out. We're about to release a new version of immugw that will be compatible with 1.3.2+. Meanwhile, it should be possible to build from current master, see section Build the container images yourself in the readme (or just the binary with make)

@jeroiraz
Thank you for your fast answer and for guidance.


Add graphiql command to CLI application

It would be nice if the user can launch GraphiQL using the decafcli application, something like:
decafcli graphiql \
  --file-profiles ~/.decaf/profiles.yaml \
  --profile testinvest \
  --api [microlot|module-pdms] \
  [--port 3333]

We can:

Implement a tiny Web server that serves GraphiQL using CDN assets (See example), or
Launch graphqurl as a separate process.

The advantage of the first method is that it does not have a dependency requirement for the end-user. The latter will require graphqurl to be installed OR will install it automatically for the enduser.

We can use blaze for generating the html:
https://hackage.haskell.org/package/blaze-html


Add support for We mobile provider in Egypt

Resolves: https://github.com/floere/phony/issues/441

Coverage increased (+0.04%) to 98.596% when pulling 13e420448041c74a3e9dccd78af998927cec58bd on zurb:master into 47b69b8b25625afdbaf67fa0e0755540b21af5b0 on floere:master.

@mrsweaters Thank you! 🎉 Released in 2.18.4 🚀


Click on Dropdown button does not close it

Hi, first I wanna say that I really love all the work! It's amazing!
I wanna make a suggestion, quand using a Dropdown, a click on the button (or associated label, whatever) will open the Dropdown component but if we click again it will not close. So to close it we have to click outside. Can we add a class or something so it can also close when the user click on the button again? I think most user will have the reflex to click on the button again.

Duplicate of #157


Build CircleCI artifacts with cameronkerrnz/logstash-plugin-dev

Using the wonderful https://github.com/cameronkerrnz/logstash-plugin-dev by Cameron Kerr.

Sorry about that


Deprecated Supported Features

Logger: homeassistant.components.light
Source: components/light/init.py:1319
integration: Light (documentation, issues)
First occurred: 12:07:53 AM (19 occurrences)
Last logged: 12:07:53 AM
Entity None (<class 'custom_components.legrand_rflc.light._Dimmer'>) is using deprecated supported features values which will be removed in HA Core 2025.1. Instead it should use <LightEntityFeature.TRANSITION: 32> and color modes, please report it to the author of the 'legrand_rflc' custom integration and reference https://developers.home-assistant.io/blog/2023/12/28/support-feature-magic-numbers-deprecation

Thanks for letting me know. I'll take a look this week.

Thank you. I ran it through gpt 4o and it updated my local code to the new
standard. We're living in the future.
Really appreciate your hard work, despite our new robot overlords.
On Wed, Jun 19, 2024 at 8:55 AM Alexander Hudek @.***>
wrote:

Thanks for letting me know. I'll take a look this week.
—
Reply to this email directly, view it on GitHub
https://github.com/akhudek/legrand_rflc/issues/5#issuecomment-2179033411,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEL4SX5AFHIZWQ7BHS4YPR3ZIGSX7AVCNFSM6AAAAABJRPMFACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZZGAZTGNBRGE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Ok, this is fixed!


Gradle 6.0 seems to ignore project-local Maven repository

After an upgrade to Gradle 6.0 builds with project-local Maven repositories specified with
repositories {
    //...
    maven { url uri('lib') }
}

do not work anymore. The last know-good version of Gradle is 5.6.2.
The lib directory resides in the project and contains a Maven file system structure. That contains the required dependencies.
Expected Behavior
Gradle should use libraries from the project-locale Maven repository.
Current Behavior
The build fails.
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not find com.acme:seclib:1.0.0.
     Searched in the following locations:
       - https://jcenter.bintray.com/com/acme/seclib/1.0.0/maven-metadata.xml
       - https://jcenter.bintray.com/com/acme/seclib/1.0.0/seclib-1.0.0.pom
       - file:/gateway/lib/com/acme/seclib/1.0.0/maven-metadata.xml
       - file:/gateway/lib/com/acme/seclib/1.0.0/seclib-1.0.0.pom
     Required by:
         project :

This bug may be related to https://github.com/gradle/gradle/issues/11321

If your repo does not contain pom metadata, you now have to add artifact() metadata source to your repository. See migration guide section: https://docs.gradle.org/current/userguide/upgrading_version_5.html#maven_or_ivy_repositories_are_no_longer_queried_for_artifacts_without_metadata_by_default
repositories {
    maven {
        url uri('lib')
        metadataSources {
            artifact()
        }
    }
}


Improve user-facing alert "identifier"

Idea by @peterdesmet extracted from #77:

Alerts are currently numbered over the whole application (e.g. my first alert is #10), but that doesn't make a lot of sense to the user. I would keep the internal identifier (also used in the URL), but choose a different title for the end user.

What kind of title would you suggest, @peterdesmet?

Another numeric identifier, but scoped so it's number 1, then 2 then 3 for any given user?
A descriptive string such as "alert for species X, Y and Z in area ...." (I'm worried this could be long in some cases)

IMHO I think we should give the user the possibility to define a SHORT name for the alert (define a max n of characters)

Giving the user the option to name an alert is a good idea:

The default name could remain the alert identifier then, maybe written as Custom alert #11
I would not necessarily restrict the name length too much (300 char)

Great suggestions, thanks for the team effort!

Nice work @niconoe.
Yes, I tested it on dev and it seems working. Here my new alert with a nice name 😄

That's now deployed in production


Update HuaweiCloud provider default region and allocate EIP for head node

"ap-southeast-3" region is in Singapore, we can use more stable
and speed networking access to some resources.
Update server flavor and image to match the region.
Allocate and attach EIP to head node
Add workspace security group egress rule
Add workspace subnet DNS option
Add configurable workspace bandwidth option for EIP and NAT

Related-with: #1011

rebase on main branch


Remove path arg from add_image and add_labels

Description
As proposed in https://github.com/napari/napari/pull/1111#issuecomment-612955351 and discussed in meeting, this removes the path arg from add_image(path='path') (and add_labels) in favor of open_path('path', layer_type='image').  The ability to pass a plugin to open_path requires some of the work in #1104, so we'll either need to extract that into a different PR, or wait to merge this.
UPDATE: everything I need to keep working on this is now in #1153
Type of change

[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)

References

How has this been tested?

[ ] example: the test suite for my feature covers cases x, y, and z
[ ] example: all tests pass with my change

Final checklist:

[ ] My PR is the minimum possible work for the desired functionality
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added tests that prove my fix is effective or that my feature works

I think it’s ready.  The one thing I wondered is how we feel about having view_path but viewer.open (no path).   Do we want to stick with that?

The one thing I wondered is how we feel about having view_path but viewer.open (no path). Do we want to stick with that?

I like viewer.open, I agree view_path is not ideal, but I can live with it. I could also live with open_path, I could also live with dropping view_path entirely.

I could also live with dropping view_path entirely.

Me too.

I could also live with dropping view_path entirely.

Me too.

really??
so to just open tiff with napari is always going to require a multistep process of first creating a viewer?

so to just open tiff with napari is always going to require a multistep process of first creating a viewer?

Hmm this part of the API has long been an issue for us. Not sure if we want to try and fix it now for 0.3.0 maybe we just live with view_path for now and then fix all of this with 0.4.0 if we move to viewer.layers.add_image (though that has it's own complexity).
Do you have a recommendation @tlambert03 on how to proceed?

Other than considering different names for napari.view_path, I don't have any suggestions... but I don't think we should remove it entirely.  I think it's pretty important to be able to open a file with one command.  (it forms the basis of our own CLI after all... so you can imagine others might want something like that).

We can wait on dropping/ renaming view_path - will merge once tests pass


Add method to ApiUsers to save a bank account

Add method to ApiUsers to save a users bank account. This allows a bank account to be deactivated (active = false)
This will solve issue #113

Thanks so so much @mtdenyer :-)


Examples build fails on M1 Mac

On
ambient run

I keep getting
[2023-03-18T16:31:34Z INFO  ambient] Building Tic Tac Toe
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: no compiler-artifact', /Users/andrewhariri/.cargo/git/checkouts/ambient-e153138232031f82/5e30ad8/crates/build/src/lib.rs:38:55
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Is there anything I can do to fix this? I just wanted to see what the examples looked like but they don't seem to build for me

Are you using the examples from the repository with Ambient 0.1.1? The main branch is used for development, so they're out of sync. If you'd like to check them out, you can either explicitly check out the 0.1.1 tag or download the examples from the release: https://github.com/AmbientRun/Ambient/releases/tag/v0.1.1

Ah i see, it might be helpful to clarify this in the README

Each example in the examples directory can be run with Ambient as both client and server:

Could be better phrased as

Examples can be run from the v0.1.1 source code or examples assets in the releases. Choose an example and run ambient run to build and launch the example.

On a separate note, it seems like I'm still having issues running the tictactoe example (minigolf works, it seems like the examples with servers are the ones that aren't working for me). The error is the same as https://github.com/AmbientRun/Ambient/issues/198

Hm, good point about clarifying what people see from the README. I'll see what I can do.

On a separate note, it seems like I'm still having issues running the tictactoe example (minigolf works, it seems like the examples with servers are the ones that aren't working for me). The error is the same as https://github.com/AmbientRun/Ambient/issues/198

Odd - so this is with a completely clean 0.1.1 runtime and examples? Can you show the commands you ran?

I also encountered similar issue on M1 Mac when I tried to ambient run on the physics example at the latest version (v0.2 dev)
Neither ambient run (0.1.1) nor the latest one (v0.2 dev) can work with the latest example(v0.2 dev) Tic Tac Toe or physics .
They have different errors
ambient run (0.1.1)
cargo install --git https://github.com/AmbientRun/Ambient.git --tag v0.1.1

Errors:
ambient run                                                                         ✔  took 3m 49s  at 04:11:49 PM
[2023-03-19T15:21:07Z INFO  ambient] Building Physics
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: no compiler-artifact

Stack backtrace:
   0: std::backtrace_rs::backtrace::libunwind::trace
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1: std::backtrace_rs::backtrace::trace_unsynchronized
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2: std::backtrace::Backtrace::create
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/backtrace.rs:332:13
   3: ambient_rustc::Rust::build
   4: ambient_build::build::{{closure}}
   5: tokio::runtime::park::CachedParkThread::block_on
   6: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
   7: tokio::runtime::runtime::Runtime::block_on
   8: ambient::main
   9: std::sys_common::backtrace::__rust_begin_short_backtrace
  10: std::rt::lang_start::{{closure}}
  11: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/core/src/ops/function.rs:287:13
  12: std::panicking::try::do_call
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/panicking.rs:487:40
  13: std::panicking::try
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/panicking.rs:451:19
  14: std::panic::catch_unwind
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/panic.rs:140:14
  15: std::rt::lang_start_internal::{{closure}}
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/rt.rs:148:48
  16: std::panicking::try::do_call
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/panicking.rs:487:40
  17: std::panicking::try
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/panicking.rs:451:19
  18: std::panic::catch_unwind
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/panic.rs:140:14
  19: std::rt::lang_start_internal
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/rt.rs:148:20
  20: _main', /Users/chaosprint/.cargo/git/checkouts/ambient-e153138232031f82/5e30ad8/crates/build/src/lib.rs:38:55
stack backtrace:
   0: rust_begin_unwind
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/panicking.rs:579:5
   1: core::panicking::panic_fmt
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/core/src/panicking.rs:64:14
   2: core::result::unwrap_failed
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/core/src/result.rs:1750:5
   3: ambient_build::build::{{closure}}
   4: tokio::runtime::park::CachedParkThread::block_on
   5: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
   6: tokio::runtime::runtime::Runtime::block_on
   7: ambient::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

ambient run (0.2)
cargo install --git https://github.com/AmbientRun/Ambient.git ambient

Errors:
ambient run                                                                          ✔  at 04:04:52 PM
[2023-03-19T15:04:53Z INFO  ambient] Building Tic Tac Toe
[2023-03-19T15:04:54Z INFO  ambient] Done building Tic Tac Toe
[2023-03-19T15:04:54Z INFO  ambient::server] Creating server
[2023-03-19T15:04:54Z INFO  ambient::server] Created server, running at <IP_ADDRESS>:9000
[2023-03-19T15:04:54Z INFO  ambient::server] Starting server
thread 'main' panicked at '', /Users/chaosprint/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-hal-0.14.1/src/metal/adapter.rs:485:13
stack backtrace:
   0: rust_begin_unwind
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/std/src/panicking.rs:579:5
   1: core::panicking::panic_fmt
             at /rustc/4a04d086cac54a41517d5657b59d5fe2caca2d71/library/core/src/panicking.rs:64:14
   2: core::panicking::panic_display
   3: wgpu_hal::metal::AdapterShared::new
   4: <wgpu_hal::metal::Instance as wgpu_hal::Instance<wgpu_hal::metal::Api>>::enumerate_adapters::{{closure}}
   5: alloc::vec::in_place_collect::<impl alloc::vec::spec_from_iter::SpecFromIter<T,I> for alloc::vec::Vec<T>>::from_iter
   6: <wgpu_hal::metal::Instance as wgpu_hal::Instance<wgpu_hal::metal::Api>>::enumerate_adapters
   7: wgpu_core::instance::<impl wgpu_core::hub::Global<G>>::request_adapter::gather
   8: wgpu_core::instance::<impl wgpu_core::hub::Global<G>>::request_adapter
   9: wgpu::Instance::request_adapter
  10: ambient_gpu::gpu::Gpu::with_config::{{closure}}::{{closure}}
  11: ambient_app::AppBuilder::build::{{closure}}
  12: tokio::runtime::park::CachedParkThread::block_on
  13: tokio::runtime::scheduler::multi_thread::MultiThread::block_on
  14: tokio::runtime::runtime::Runtime::block_on
  15: ambient::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
ambient(58375,0x10850c580) malloc: *** error for object 0x1: pointer being freed was not allocated
ambient(58375,0x10850c580) malloc: *** set a breakpoint in malloc_error_break to debug
zsh: abort      ambient run

Yep i ran the same commands as @chaosprint

Yep i ran the same commands as @chaosprint, interestingly though I did not have issues with the physics example

Aha, I think the latest version of ambient run at v0.2.0-dev should work fine on M1 Mac. At least I got it working on both the Tic Tac Toe and the Physics examples.
Try to install it again with:
cargo install --git https://github.com/AmbientRun/Ambient.git ambient

Then in your project, run:
cargo clean

Then it should work:
ambient run


docs: update webhook related instructions

Description of change

Update webhook related posts to use new API endpoint
Issues resolved by this PR

[x] DVN-11551

More info

Deployed pipeline for PR #769 (docs: update webhook related instructions): Devopness application thlmenezes-site.devopness.com deployment in-progress on action https://thlmenezes-site.devopness.com

Deployed pipeline for PR #769 (docs: update webhook related instructions): Devopness application thlmenezes-site.devopness.com deployment completed on action https://thlmenezes-site.devopness.com

Deployed pipeline for PR #769 (docs: update webhook related instructions): Devopness application thlmenezes-site.devopness.com deployment in-progress on action https://thlmenezes-site.devopness.com

Deployed pipeline for PR #769 (docs: update webhook related instructions): Devopness application thlmenezes-site.devopness.com deployment completed on action https://thlmenezes-site.devopness.com

Deployed pipeline for PR #769 (docs: update webhook related instructions): Devopness application thlmenezes-site.devopness.com deployment in-progress on action https://thlmenezes-site.devopness.com

Deployed pipeline for PR #769 (docs: update webhook related instructions): Devopness application thlmenezes-site.devopness.com deployment completed on action https://thlmenezes-site.devopness.com

Deployed pipeline for PR #769 (docs: update webhook related instructions): Devopness application thlmenezes-site.devopness.com deployment in-progress on action https://thlmenezes-site.devopness.com

Deployed pipeline for PR #769 (docs: update webhook related instructions): Devopness application thlmenezes-site.devopness.com deployment completed on action https://thlmenezes-site.devopness.com

Deployed pipeline for PR #769 (docs: update webhook related instructions): Devopness application thlmenezes-site.devopness.com deployment in-progress on action https://thlmenezes-site.devopness.com


Fix license issue #134

Changes
Rename license file and add license info to package file.
Checklist

[x] have tested my change
[x] updated relevant documentation
[x] Remove any/all console.logs I added
[x] eslint is not complaining
[x] have added myself to the contributors' list in the README
[x] for feature PRs: PR only includes one feature enhancement.

Hi Liam.
I reckoned I could make the change myself instead of having you do all the work...
Btw, I spent some time figuring out why other lines in the package.json file was changed when saved - it is the ESLint extension which does this. Let me know if you want that change removed.

These changes look good. Thank you @chrjorgensen!


Detect most denied / warned lints ?

To see which lints are most popular.

Someone could do it, but I am not interested in doing that as part of this project.

https://github.com/lengyijun/noisy-clippy/blob/warn/deny.md
https://github.com/lengyijun/noisy-clippy/blob/warn/warn.md


[feature request] need CMD "pouch rm [-f]"

Issue Description
Need to add CMD: pouch rm [-f]
Describe what happened:
Describe what you expected to happen:
How to reproduce it (as minimally and precisely as possible):
1.
2.
3.
Anything else we need to know?:
Environment:

pouch version (use pouch version):
OS (e.g. from /etc/os-release):
Kernel (e.g. uname -a):
Install tools:
Others:

Set this as P0, since lots of people are waiting for this, like https://github.com/alibaba/pouch/pull/203

This has been fixed in https://github.com/alibaba/pouch/pull/214
Closing this.


Acyclic Tx labels sent twice on each trigger

Describe the bug
Acyclic messages are sent on a trigger rather than continuously at a specified rate. Given that acyclic messages are sent on a trigger, users expect that the acyclic labels are only sent once per trigger event.
To Reproduce
Steps to reproduce the behavior:

Open a new default project in VeriStand.
Add a Ballard ARINC 429 custom device to the project.
Specify the attached configuration files.
Enable logging in the custom device.
Deploy.
Trigger each loopback Tx label.
Disconnect and inspect the generated log file.
Note that each triggered acyclic label was received and logged twice.

time stamp,channel,label,sdi,data word
23.226483,3,7,0,3758147591
23.326562,3,7,0,3758147591
24.226202,3,8,0,1610664968
24.326282,3,8,0,1610664968
25.625882,3,23,0,1610666007
25.726322,3,23,0,1610666007
27.225722,3,24,0,3758150680
27.326162,3,24,0,3758150680

Expected behavior
One trigger = one transmit.
Configuration Files.zip
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: Linux RT
Version: base image = 21.0

Additional context
Add any other context about the problem here.

trigger once, receive two was also observed when AIM hardware was used for Rx.


feat: DA for terraform-ibm-watsonx assistant

Description
The PR is to create DA(Deployable Architecture) for watsonx Assistant. Refer Issue - 11381
Release required?

[ ] No release
[ ] Patch release (x.x.X)
[x] Minor release (x.X.x)
[ ] Major release (X.x.x)

Release notes content

DA (Deployable Architectures) for terraform-ibm-watsonx-assistant

Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
/run pipeline

Checklist for reviewers

[x] If relevant, a test for the change is included or updated with this PR.
[x] If relevant, documentation for the change is included or updated with this PR.

For mergers

Use a conventional commit message to set the release level. Follow the guidelines.
Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
Use the Squash and merge option.

/run pipeline

/run pipeline

/run pipeline

/run pipeline

In reference-architecture diagram, service label should watsonx Assistant instead of IBM Cloud... and font size of the label can be increased a bit.

/run pipeline

/run pipeline

/run pipeline

:tada: This PR is included in version 1.1.0 :tada:
The release is available on:

GitHub release
v1.1.0

Your semantic-release bot :package::rocket:


Multi-level underlay

Add support for autonomous systems and model 2-level network IDs: e.g. 10.20, 1.22, etc. First should represent the stub/trans number and the second should represent node number.

Internetwork overlays work, but still we can't support more than 10k nodes.

Internetwork overlays work, but still we can't support more than 10k nodes.


[Bug]: After Install cyberpanel , coolify can't run on port 3000!!

Is there an existing issue for this?

[X] I have searched the existing issues

Description
when I'm install cyberpanel , coolify currently installed before cyberpanel can't access on port 3000!!
please test it & you see my problem in action
I'm also bypass redis install on cyberpanel install structure but also the same error .
cyber panel usage ports is :
TCP: 8090 for CyberPanel
TCP: 80, TCP: 443 and UDP: 443 for webserver
TCP: 21 and TCP: 40110-40210 for FTP
TCP: 25, TCP: 587, TCP: 465, TCP: 110, TCP: 143 and TCP: 993 for mail service
TCP: 53 and UDP: 53 for DNS service
please help me why cyberpanel & coolify have conflict .
waiting for your response
finest regards
Steps To Reproduce
idk
Version
latest

Hey, Coolify uses port 3000 by default, but Coolify proxy uses 80 & 443. Ifcthe proxy cannot be started, you can only reach Coolify over IP address with port, not with the domain.


Difficulty port mapping for apps

Hey!  Thank you for making this repo, it's exactly what I need!
I am having one issue, so if you download the Bitcoin Node app it requires localhost:2100 ; however, if I port map 2100:2100 in docker-compose the app can't boot with this error

umbrel           | Error response from daemon: driver failed programming external connectivity on endpoint bitcoin_app_proxy_1 (20b64ffe404142b9ca8a6471d7fafb3bdba53a377d154a2939feef3280b33be8): Bind for <IP_ADDRESS>:2100 failed: port is already allocated

If I do 2101:2100 the app will boot, but I cannot access it through the host network at localhost:2101
i.e.
umbrel:
        image: dockurr/umbrel
        container_name: umbrel
        ports:
            - 81:80
            - 2100:2100
            - 12596:12596
        volumes:
            - "sail-umbrel:/data"
            - "/var/run/docker.sock:/var/run/docker.sock"
        stop_grace_period: 1m

So I wasn't able to reach it via localhost:2100 from the get go and after a bit of testing, it appears to be the volume part in my config that caused this issue.
  - "sail-umbrel:/data"
Which I did have set up in the volumes section correctly
    sail-umbrel:
        driver: local

I don't know why yet though, but was able to fix using       - "/home/example:/data"


math: TBalpha 10.0a4+ 64bit Windows

Info for posterity...
Issue is present

alpha only (not release) - since 10.0a4

e.g. the 9.5.4 stable release (68.12.0esr) is good, but 10.0a4 (68.11.0esr) is not
we will wait and see what happens in the first stable release based on ESR78
update: it does not happen on TB 10.0 release

only in 64bit builds
only on Windows (AFAIK)
only with TB

i.e FF builds with mingw do not produce the issue

update: just to add to the confusion, I could not reproduce on my Win10 vm

Tested

FF same release built with and without mingw-64, it does not have the problem

STR

bookmark 1: https://arkenfox.github.io/TZP/tests/math.html
bookmark 2: https://arkenfox.github.io/tzp/tzp.html#math
start a whole new TB
go to site1

note your hash, for me on windows I can just remember [F3]

close tab

go to site2

note your 1st Edition hash, you should get a letter, D or G for Linux, for me I can remember [B]

close tab

revisit site1

check the hash or code: it's changed

close tab

revisit site2

check the hash or letter: it's changed

close tab

Diffs (from 107 176 items tested)

The first six items are used on the current TZP test, all items are used in the current math research test
Note that the last item, cbrt is a polyfill

Left: expected. Right: when it changes

we will wait and see what happens in the first stable release based on ESR78

It does not happen on TB10.0 - so it seems it is definitely an alpha only issue, and my best guess is it has something to do with build system changes
something is/was different in alpha esr78 builds. It will be interesting to see if what happens with the next alpha now release has caught up
here's changes for TB10.0
 * Build System
   * Windows + OS X + Linux
     * Bump Go to 1.14.7
     * Bug 31845: Bump GCC version to 9.3.0
     * Bug 34011: Bump clang to 9.0.1
     * Bug 34014: Enable sqlite3 support in Python
     * Bug 34390: Don't copy DBM libraries anymore
     * Bug 34391: Remove unused --enable-signmar option
     * Bug 40004: Adapt Rust project for Firefox 78 ESR [tor-browser-build]
     * Bug 40005: Adapt Node project for Firefox 78 ESR [tor-browser-build]
     * Bug 40006: Adapt cbindgen for Firefox 78 ESR [tor-browser-build]
     * Bug 40037: Move projects over to clang-source [tor-browser-build]
     * Bug 40026: Fix full .mar creation for esr78 [tor-browser-build]
     * Bug 40027: Fix incremental .mar creation for esr78 [tor-browser-build]
     * Bug 40028: Do not reference unset env variables [tor-browser-build]
     * Bug 40031: Add licenses for kcp-go and smux. [tor-browser-build]
     * Bug 40045: Fix complete .mar file creation for dmg2mar [tor-browser-build]
     * Bug 40065: Bump debootstrap-image ubuntu_version to 20.04.1 [tor-browser-build]
     * Bug 40087: Deterministically add HTTPS Everywhere into omni.ja [tor-browser-build]
   * Windows
     * Bug 34230: Update Windows toolchain for Firefox 78 ESR
     * Bug 40015: Use only 64bit fxc2 [tor-browser-build]
     * Bug 40017: Enable stripping again on Windows [tor-browser-build]
     * Bug 40052: Bump NSIS to 3.06.1 [tor-browser-build]
     * Bug 40061: Omit the Windows default browser agent from the build [tor-browser]
     * Bug 40071: Be explicit about no SEH with mingw-w64 on 32bit systems [tor-browser-build]
     * Bug 40077: Don't pass --no-insert-timestamp when building Firefox [tor-browser-build]
     * Bug 40090: NSIS 3.06.1 based builds are not reproducible anymore [tor-browser-build]
   * OS X
     * Bug 34229: Update macOS toolchain for Firefox 78 ESR
     * Bug 40003: Update cctools version for Firefox 78 ESR [tor-browser-build]
     * Bug 40018: Add libtapi project for cctools [tor-browser-build]
     * Bug 40019: Ship our own runtime library for macOS [tor-browser-build]
   * Linux
     * Bug 34359: Adapt abicheck.cc to deal with newer GCC version
     * Bug 34386: Fix up clang compilation on Linux
     * Bug 40053: Also create the langpacks tarball for non-release builds [tor-browser-build]

these are the only diffs in 64 TB 10 (no issue) vs 10.0a7 (issue)

resource://gre/chrome/toolkit/content/global/buildconfig.html

Maybe it's the library versions. IDK. Maybe the next alpha will self-correct. IDK

It will be interesting to see if what happens with the next alpha now release has caught up

Maybe the next alpha will self-correct. IDK

...aaaaaaand in TB 10.5a1 the issue seems to be resolved

...aaaaaaand in TB 10.5a1 the issue seems to be resolved

and I spoke too soon. NOT RESOLVED

I've tried a few times, but not that much, and haven't replicated this for some time. At one stage I thought the problem had gone away, but then it happened again. Seems intermittent.
Maybe with the move to ESR91.1 together with RFP's math protection this is now resolved. Will leave open for a while, and I promise to test more often - haven't had much time for TB lately, sorry, not sorry :)

can't replicate anymore (and haven't seen a red NEW since .. IDK 2020 or early 2021)


Fix internalDataReader to return data without waiting for the array t…

Until the array data is filled, the function Read will not return data.

also encountered this problem


missing MongoDB Authentication

Can you please add descriptions to these issues?

I assume this is similar to this? https://github.com/mrvautin/adminMongo/issues/10

Ok. Authentication is out of scope right now (possibly forever) as per the linked issue.


WithRedisCommander and WithMongoExpress configContainer callbacks.

Add container configuration callbacks to both WithMongoExpress and WithRedisCommander. Also add corresponding UseHostPort methods to simplify overriding the host port.
Microsoft Reviewers: Open in CodeFlow

We need to fix cosmos and storage emulators, and pgadmin in a follow up.

I think Cosmos and Storage are in a slightly different category. For Storage there are three different ports, so WithHostPort becomes WithBlobPort, WithQueuePort etc. I guess we could collapse them into one but if you are just using blob storage that seems odd.
In the case of Cosmos I am hopeful that at some point the future we can avoid having to use the Gateway port as the sigular port we use to connect on. At which point we'll have multiple methods to set the gateway and the partition port ranges (I think its ports == partitions .. a good question for the Cosmos team).

I mean the With vs Use prefix is all.


Cannot load a pre trained Keras h5 model inside Python functions

Inferencing from a Keras model seems impossible with this issue:
Keras has an api called load_model which loads a pre-trained model from disk. It does not support loading this from a blob or file storage. It can load this from a mounted disk.
Azure functions on Python must provide a facility to be able to load model files from mounted storage.
Ideally ML libraries must support loading models from cloud like blob storage/file share etc. But they seem to be supporting disk paths.
Observed this with gensim, NLTK and now Keras.
If there is a way to access a specific disk from Python functions - load it from runtime or support SMB, it will bridge this gap to some extent. Here are some GitHub issues raised on the libraries themselves.
https://github.com/nltk/nltk/issues/2127
https://github.com/RaRe-Technologies/gensim/issues/2184
Workaround: Pickle the model while training it. Load the pickled model back. scikit supports this but Keras warns against pickling models, and suggests to go with their API.
The major concern with this workaround is for data scientists to be able to consciously store models in pickle format, which they will reject with passion - and its also wrong for them to persist this way. AWS lambda solves this by allowing disk access.

Works when I did this:
model = load_model(os.path.join(os.getcwd(),"FUNC_APP_NAME","keras-gear.h5"))
But the model is now part of the function app and is uploaded along with function app.
As an alternative, tried the "Bring your own storage" option:
https://blogs.msdn.microsoft.com/appserviceteam/2018/09/24/announcing-bring-your-own-storage-to-app-service/
Did not work after mounting "models" folder from blob storage to /home/site/wwwroot/ folder.
Asking to support "Bring your own storage" pattern with functionapp - this is the key to using functions with ML for inference.

Works when I did this:
model = load_model(os.path.join(os.getcwd(),"FUNC_APP_NAME","keras-gear.h5"))

Good to know that this worked.

Asking to support "Bring your own storage" pattern with functionapp - this is the key to using functions with ML for inference.

I don't think we have the ability to mount an external storage to the container today. Keeping the issue open, to gauge traction. /cc @davidebbo @ahmelsayed

Serverless Python is mostly seen as an inferencing compute target for ML scenarios among the ML python community. This means it should load models that are stored in blob storage. Currently using Docker/Kubernetes, the model is explicitly downloaded from Blob storage into local disk path and ML libraries load models from local disk path.
While ML Libraries need to catch up and load models from Azure blob storage (which might take a while) it is important to stop this gap by getting to load models from local paths. And hence mounting the paths from a custom storage becomes very important.
The "bring your own storage" facility for webapp seems very valuable in this context. While operationalizing models, this can be used readily from a CI/CD pipeline for inference purposes from a function.  I strongly suggest to get this for functionapp if we need functions to do ML inferencing.

@asavaritayal  - the “Bring Your Own Storage” feature in that blog announcement from the team mentions it's for "App Service on Linux and Web App for Containers". Wouldn't it work for Functions in App Service Plans for now? I suspect Consumption plan would be a different story to implement...

      Serverless Python is mostly seen as an inferencing compute target for ML scenarios among the ML python community. This means it should load models that are stored in blob storage. Currently using Docker/Kubernetes, the model is explicitly downloaded from Blob storage into local disk path and ML libraries load models from local disk path.

While ML Libraries need to catch up and load models from Azure blob storage (which might take a while) it is important to stop this gap by getting to load models from local paths. And hence mounting the paths from a custom storage becomes very important.
The "bring your own storage" facility for webapp seems very valuable in this context. While operationalizing models, this can be used readily from a CI/CD pipeline for inference purposes from a function.  I strongly suggest to get this for functionapp if we need functions to do ML inferencing.

I had Keras TF models working in functions in August but only in a container/locally as the 200MB model proved a challenge for the service. I recently got sklearn models working loading them from blob. Originally I wanted to have routes mapped to model versions but as per this issue: https://github.com/Azure/azure-functions-python-worker/issues/230
The inputStream object is missing the BytesIO method .seek.
I worked around the issue for now by loading the models directly from blob from the REST API where I could perform the .seek(0) required for Pickle. joblib implements .seek(0) in the backend while loading.
Here's my getBlob function and associated helper functions:
def getDate():
    date = datetime.utcnow()
    return date.strftime("%a, %d %b %Y %H:%M:%S GMT")

def generateAuth(storageaccount, stringtosign, key):
    encodedstring = bytes(stringtosign, 'utf-8')
    signature = hmac.new(key, msg=encodedstring, digestmod=hashlib.sha256).digest()
    signature = base64.b64encode(signature).decode()
    return "SharedKeyLite "+storageaccount+":"+signature

def getBlob(key, modelVer, storageaccount, modelname):
    url = "https://"+storageaccount+".blob.core.windows.net/"+modelname+"/"+modelVer
    date = getDate()
    stringtosign = "GET\n\n\n\nx-ms-date:"+date+"\nx-ms-version:2018-03-28\n/" \
    +storageaccount+"/"+modelname+"/"+modelVer
    auth = generateAuth(storageaccount, stringtosign, key)
    header = {"Authorization": auth, "x-ms-date": date, "x-ms-version": "2018-03-28"}
    res = requests.get(url, headers=header)
    return BytesIO(res.content)

The object returned by getBlob I'm loading with joblib like this: lemon_model = joblib.load(model)
These aren't large models so the function runs quite quickly even loading models from blob. I am going to test the 200MB Keras TF model with this pattern and see how it performs.

@jmo808 : What is joblib? Are you able to use keras API's themselves to load a model directly from a byte stream? I know Keras API's don't support reading from a blob.


Allow specification of output dataset name (vs automatic) in predict and model

Models no longer part of easydata


Fluent getters and setters

Please add support for fluent accessors in addition to bean-like accessors. Or, alternatively, add support for private fields, which is how JSON parsers handle it.
class MyClass {
    private int something;
    int something();
    MyClass something(int value);
    // or void something(int value);
}

Many thanks for your input.  I'm not sure where you are missing them.

I am using lombok to generate fluent accessors via @Getter/@Setter annotation. I configured lombok globally to generate fluent accessors everywhere, i.e. without get/set prefix and with setters returning this.
@Getter @Setter class MyCsvRow {
	private String field1;
	private String field2;
}

I then tried to use CsvBeanWriter and CsvBeanReader with my data class, but they won't recognize the fluent accessors.
My current workaround is to set @Accessors(fluent = false, chain = true) on the data class, which locally disables fluent accessors.
@Accessors(fluent = false, chain = true) @Getter @Setter class MyCsvRow {
	private String field1;
	private String field2;
}

Aside from being more verbose, this leads to oddly looking code with some accessors fluent and some not.

Hi Robert
So that tool generate get/set methods with a different signature than what we harvest. Perhaps the harvester needs to be more configurable?
How used is this loom tool?

Lombok actually generates bean-like accessors by default. Verb-less (without get/set) and chaining (returning this) accessors are an option. Some Java developers, including myself, use fluent style for handwritten accessors, because it results in neat APIs for dumb data classes.
Since super-csv is essentially a serialization library, the objective here should be to match API of more commonly used serialization libraries, specifically JSON serializers. Both Gson and Jackson will use fields directly, including private fields. Gson will do so automatically while Jackson needs a one-line configuration to use private fields. This solution bypasses accessors entirely.

Hi, @kbilsted
For the problem of get/set, we can try to use the field direct mapping throught java reflection instead of the set/get method mapping. What do you think?

Hi, @robertvazan
Is super CSV suitable for fluent programming? Can you come up with a specific scenario code (if super CSV supports fluent programming)

@dota17 It's not that SuperCSV API itself needs to be fluent. All that's needed is to support fluent POJOs in addition to JavaBeans. The reasons for support are convenience and consistency (with the rest of the app code and with JSON parsers).

Hi, @robertvazan  @kbilsted
Do you think such PR #180  can solve your problem? What do you think?

@dota17 It essentially fixes this issue. I didn't test it though. It would be even better to automatically configure name mapping and default processors, but that's something CsvBeanReader and CsvBeanWriter would benefit from too.

Hi, @robertvazan
automatically configure name mapping and default processors is the issue #158 ? . I understand these are two different questions, right? PR #180 is mainly used to solve this problem. Direct Field reflection can support  fluent POJOs in addition to JavaBeans.

@dota17 Yes, you are right. This PR is already a big help.


Meg datacheck

Created a pull request for this project because it's easier to keep track in the To-do sheet. I'll leave to the assignees and reviewers to continue the discussion below!

Let's prioritize this pull request in the next month, please :)

hey everyone, wanted to check if there are any updates on this?


Use shared babel-preset file for transform

This uses our shared babel preset for tests so we don't need to duplicate a list of presets.
Fixes #68

!merge


Roll engine afed5c54765b..5ab48b447641 (1 commits)

https://github.com/flutter/engine/compare/afed5c54765b...5ab48b447641
git log afed5c54765b3097f4ba58a76b3d450b7631a910..5ab48b4476413203b7735736429e0431407c8f0f --no-merges --oneline
5ab48b447 Roll src/third_party/skia 53ae936b8447..9e1e8caff331 (1 commits) (flutter/engine#9245)
The AutoRoll server is located here: https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md
If the roll is causing failures, please contact the current sheriff (bmparr@google.com), and stop
the roller if necessary.

Auto-roller completed checks. About to merge.


Add a 7th or 8th order ODE Solver

Resources are available on internet. Also, they can be shared later on this thread.

Can i try it with a scipy , with using function DOP853 ..a eightth order runge-kunta ode solver ?

I guess you should try out #360 first, then dive into deeper, not so good first issues. If you wanna go for it, be my guest :)
Regards,
Ritwik

On 02-Feb-2020, at 4:35 PM, sagnik-chatterjee<EMAIL_ADDRESS>wrote:

Can i try it with a scipy , with using function DOP853 ..a eightth order runge-kunta ode solver ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Truly, I agree with @ritzvik .
If you feel you know things about ODEs. You are welcome to take this up. Otherwise it's not a good first issue

@shreyasbapat This seems interesting to me
Shall I try this one

Sure, let's first discuss the whole problem somewhere. And then you can proceed!

Some related literature:

https://arxiv.org/pdf/2010.02237.pdf
https://www.unige.ch/~hairer/poly_geoint/week2.pdf

Some related literature:

https://arxiv.org/pdf/2010.02237.pdf
https://www.unige.ch/~hairer/poly_geoint/week2.pdf


Textbook content: sec. 6.2 S-gates confusing sentence

Section 6.2 of the (old and new) textbook contains the following sentence:

It is important to note that unlike every gate introduced in this chapter so far, the S-gate is not its own inverse!

Since the R_phi gate is introduced before, which is generally not its own inverse (obvious from the fact that S is a special case of it) this sentence might be better reformulated, maybe by explicitly naming

It is important to note that unlike the Pauli and Hadamard gates introduced in this chapter so far, the S-gate is not its own inverse!

Can I work on this issue. I am new to open source and this looks like a good one to start with.

Can't find it on Qiskit/platypus. Opened a PR in LaBEQ-main/qiskit

@soumya-s3 the notebook is here: https://github.com/Qiskit/platypus/pull/797. I think the confusion is that '6.2' refers to the section within the notebook, but the original poster didn't specify which notebook contained the error. Please open a PR here as that repo isn't associated with this one.


Crash Report

I'm installing PhantomJS 2.0.0 via
sudo add-apt-repository ppa:tanguy-patte/phantomjs -y
sudo apt-get update
sudo apt-get install phantomjs

I get these .dmp files when running my tests on Travis's Ubuntu Trusty VMs (one per run):

0a65bce6-ee6a-5e8e-60309df0-1d89c59f.dmp
7826990a-aa02-b405-3ba80548-4cb56310.dmp

And this one using the built-in PhantomJS 2.0.0 installation:

29c8ccf4-e283-042e-0f9cdba9-22742991.dmp

I couldn't find symbol files for 2.0.0, so I can't expand the .dmp files.

I believe 2.1.1 makes this crash go away, but without the stack trace, I'm not sure why.


Need help to run mkall.sh (delve\vendor\golang.org\x\sys\unix\mkall.sh)

What version of Go are you using (go version)?

$ go version
go version go1.12.4 linux/arm64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="arm64"
GOBIN="/home/bin"
GOCACHE="/root/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_arm64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build141065257=/tmp/go-build -gno-record-gcc-switches"

What did you do?
Hi, i am interested in regenerating files for my native environment (arm64 with linux), located at :

src/vendor/golang.org/x/sys/unix/

I looked at the file mkall.sh that generates files for Architecture/OS combination .

src/vendor/golang.org/x/sys/unix/mkall.sh

line 51 in file mkall.sh, requires a dockerfile present at ${GOOS}/Dockerfile but i can't locate it anywhere in the source .
line 51:  $cmd docker build --tag generate:$GOOS $GOOS
please suggest how can i get this dockerfile .
error in running the script is as follows:
unable to prepare context: path "linux" not found
Unable to find image 'generate:linux' locally

What did you expect to see?
I expected to find a dockerfile present in   $GOOS or atleast anywhere in the repository .
What did you see instead?
unable to prepare context: path "linux" not found
Unable to find image 'generate:linux' locally

See the big README at https://github.com/golang/sys/tree/master/unix#building-sysunix
It's likely it won't work in some project's vendor directory.
The Dockerfile is in https://github.com/golang/sys/tree/master/unix/linux but that's an implementation detail if you follow the instructions above and run it from the upstream location.
But we already regenerate files for arm64 regularly, so you should back up and describe your actual problem (http://xyproblem.info/).
/cc @tklauser


Adding new file to lazy-engine while server is running doesn't get added to engine build

Description
If I run ember serve and then add a file to my lazy-engine's addon/controllers folder (or anywhere), the file is not included in the resulting engine.js folder.
It looks like the area that causes this is at the buildEngineJSTreeWithoutRoutes function. In the broccoli-dependency-funnel it's running fs-tree-diff patch calculations, but it's not correctly issuing a 'create' patch, it's issuing a 'change' patch which is a no-op for symlinked files (in the tmp folder).
This looks to be because on the creation of DependencyFunnel in that engine-addon function is only saving that FSTree at a the point of creation, and then continuing to compare against that. I'm not sure if this is a bug with FS-Tree-Diff / Broccoli Dependency Funnel, or with the use of the DependencyFunnel inside the buildEngineJSTreeWithoutRoutes function.
Repro Steps:
Setup ember-engines repo
git clone https://github.com/ember-engines/ember-engines; cd ember-engines; npm install

Serve the app

ember serve

Navigate to http://localhost:4200/routable-engine-demo/ember-blog/new

Move template file out

mv tests/dummy/lib/ember-blog/addon/templates/new.hbs tmp

Wait for rebuild and then move file back in

mv tmp/new.hbs tests/dummy/lib/ember-blog/addon/templates

Notice the template isn't loaded/shown in the served application
This could be rebuilt with the new.hbs starting outside the project, and then added in (moving step 3 to step 1) and the same effect would happen.
A couple of notes:

I am running an out of repo engine
I am symlinking my engine into the node_modules of the parent application

Thanks for sharing the reproduction!


Suggest to make a flag that would write (1) (2) (3) and so on at the end of files with the same name

DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

[X] I understand that I will be blocked if I intentionally remove or skip any mandatory* field

Checklist

[X] I'm requesting a feature unrelated to a specific site
[X] I've looked through the README
[X] I've verified that I have updated yt-dlp to nightly or master (update instructions)
[X] I've searched known issues and the bugtracker for similar issues including closed ones. DO NOT post duplicates
[X] I've read the guidelines for opening an issue

Provide a description that is worded well enough to be understood
In this program, there is a problem. If at the end point of saving video or audio, there is a file with the same name, the program just writes an error and does not download. I suggest to make a flag that would write (1) (2) (3) and so on at the end of files with the same name. It's just that I very often download streams from Twitch, and many streamers name the streams the same, and I leave downloading several streams at once for the night
Provide verbose output that clearly demonstrates the problem

[ ] Run your yt-dlp command with -vU flag added (yt-dlp -vU <your command line>)
[ ] If using API, add 'verbose': True to YoutubeDL params instead
[ ] Copy the WHOLE output (starting with [debug] Command-line config) and insert it below

Complete Verbose Output
No response

Duplicate of #5485


Unreceived Packets in IBC Token Transfers

Summary of Bug

Hi,
We've successfully set up an IBC relayer path. However, we're encountering issues with token transfers. Specifically, withdrawals via Osmosis Zone and IBC transfers through Keplr are getting stuck and showing as unreceived packets when we check with hermes tx packet-recv
While transferring token via Hermes using hermes tx ft-transfer went well.
It's important to note that our server is constantly running hermes start
We're reaching out to investigate the potential causes of this problem. Any insights you can offer would be greatly appreciated.
For reference, this issue is related to the one discussed in this GitHub pull request: https://github.com/osmosis-labs/assetlists/pull/1417
Thank you for your support.
Version

Hermes v1.8.2
Steps to Reproduce

Testing on Osmosis Zone

Go to https://app.osmosis.zone/?to=CIF&from=USDC or https://app.osmosis.zone/?to=CIF&from=OSMO and swap for some CIF
Go to https://app.osmosis.zone/assets?show_preview_assets=true
Withdraw CIF, it will show as "pending" in transaction history

Testing on Keplr wallet

Add chain "Cifer" on Keplr extension
Try IBC transfer CIF IBC from Osmosis to Cifer via Keplr (wallet address prefix = cife), add new IBC channel: select Cifer as destination chain, with channel-39205
It will show as "Transaction success" but no CIF token received in wallet.

Acceptance Criteria

Please provide any insights which can be the cause of this problem.

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

Hi,
Do you mean that your running instance, hermes start, is not relaying the packets but if you run the manual relaying hermes tx packet-recv it succeeds?
If it is the case, can you share the configuration used by the running Hermes instance as well as logs at debug level of the instance running 10 minutes before and after the transfer?

I have a same problem.
This is working from our chain to Osmosis but Osmosis to our chain did not work.
If I execute packet clear command line, they transfer token.
hermes clear packets --chain osmosis-1 --port transfer --channel channel-xxxx

@soring323 Could you share the logs with the error when trying to clear packets?

there is no errors, if I clear packet, it's working. Packet is relayed and token is transferred.

no errors.  If I clear packet,  packets are relayed to target chain.

when I execute clear packet command line.
2024-11-13T13:24:30.880088Z  INFO ThreadId(01) running Hermes v1.10.3+e26d356
2024-11-13T13:24:34.228891Z  INFO ThreadId(01) relay_recv_packet_and_timeout_messages{src_chain=osmosis-1 src_port=transfer src_channel=channel-86496 dst_chain=kima_mainnet}: 1 unreceived packets found: [ 10 ]
2024-11-13T13:24:34.769034Z  INFO ThreadId(01) relay_recv_packet_and_timeout_messages{src_chain=osmosis-1 src_port=transfer src_channel=channel-86496 dst_chain=kima_mainnet}: pulled packet data for 1 out of 1 events: 10..=10 events.total=1 events.left=0```

relayer side
```Nov 13 13:25:07 kima-prod-relay hermes[1037446]: 2024-11-13T13:25:07.742262Z  INFO ThreadId(08) spawn:chain{chain=kima_mainnet}:client{client=07-tendermint-27}:connection{connection=connection-17}:channel{channel=channel-4}:worker.client.misbehaviour{client=07-tendermint-27 src_chain=osmosis-1 dst_chain=kima_mainnet}:foreign_client.detect_misbehaviour_and_submit_evidence{client=osmosis-1->kima_mainnet:07-tendermint-27}:foreign_client.detect_misbehaviour{client=osmosis-1->kima_mainnet:07-tendermint-27}: No evidence of misbehavior detected for chain osmosis-1
Nov 13 13:25:07 kima-prod-relay hermes[1037446]: 2024-11-13T13:25:07.742318Z DEBUG ThreadId(08) spawn:chain{chain=kima_mainnet}:client{client=07-tendermint-27}:connection{connection=connection-17}:channel{channel=channel-4}:worker.client.misbehaviour{client=07-tendermint-27 src_chain=osmosis-1 dst_chain=kima_mainnet}:foreign_client.detect_misbehaviour_and_submit_evidence{client=osmosis-1->kima_mainnet:07-tendermint-27}:foreign_client.detect_misbehaviour{client=osmosis-1->kima_mainnet:07-tendermint-27}: no misbehavior detected
Nov 13 13:25:07 kima-prod-relay hermes[1037446]: 2024-11-13T13:25:07.842523Z  INFO ThreadId(154) spawn:chain{chain=kima_mainnet}:client{client=07-tendermint-27}:connection{connection=connection-17}:channel{channel=channel-4}:worker.client.misbehaviour{client=07-tendermint-27 src_chain=osmosis-1 dst_chain=kima_mainnet}:foreign_client.detect_misbehaviour_and_submit_evidence{client=osmosis-1->kima_mainnet:07-tendermint-27}: client is valid
Nov 13 13:25:07 kima-prod-relay hermes[1037446]: 2024-11-13T13:25:07.842564Z DEBUG ThreadId(154) spawn:chain{chain=kima_mainnet}:client{client=07-tendermint-27}:connection{connection=connection-17}:channel{channel=channel-4}:worker.client.misbehaviour{client=07-tendermint-27 src_chain=osmosis-1 dst_chain=kima_mainnet}: client is valid
Nov 13 13:28:02 kima-prod-relay hermes[1037446]: 2024-11-13T13:28:02.284023Z  WARN ThreadId(28) spawn:chain{chain=osmosis-1}:wallet{chain=osmosis-1}: task encountered ignorable error: failed to query balance for the account: gRPC call `query_balance` failed with status: status: Internal, message: "protocol error: received message with invalid compression flag: 60 (valid flags are 0 and 1) while receiving response with status: 503 Service Unavailable", details: [], metadata: MetadataMap { headers: {"server": "nginx", "date": "Wed, 13 Nov 2024 13:28:02 GMT", "content-type": "text/html; charset=utf-8", "content-length": "190"} }```

hermes clear packets --chain osmosis-1 --port transfer --channel channel-xxxx
``2024-11-13T13:24:30.879697Z  INFO ThreadId(01) using default configuration from '/root/.hermes/config.toml'
2024-11-13T13:24:30.880088Z  INFO ThreadId(01) running Hermes v1.10.3+e26d356
2024-11-13T13:24:34.228891Z  INFO ThreadId(01) relay_recv_packet_and_timeout_messages{src_chain=osmosis-1 src_port=transfer src_channel=channel-86496 dst_chain=kima_mainnet}: 1 unreceived packets found: [ 10 ]
2024-11-13T13:24:34.769034Z  INFO ThreadId(01) relay_recv_packet_and_timeout_messages{src_chain=osmosis-1 src_port=transfer src_channel=channel-86496 dst_chain=kima_mainnet}: pulled packet data for 1 out of 1 events: 10..=10 events.total=1 events.left=0
2024-11-13T13:24:35.242432Z DEBUG ThreadId(01) relay_recv_packet_and_timeout_messages{src_chain=osmosis-1 src_port=transfer src_channel=channel-86496 dst_chain=kima_mainnet}:schedule{odata=packet-recv ->Destination @1-23925095; len=1}: connection delay need not be taken into account: client update message will be prepended later
2024-11-13T13:24:35.242467Z DEBUG ThreadId(01) relay_recv_packet_and_timeout_messages{src_chain=osmosis-1 src_port=transfer src_channel=channel-86496 dst_chain=kima_mainnet}:relay{odata=packet-recv ->Destination @1-23925095; len=1}: retrying retry.current=1 retry.max=5```
Nov 13 13:24:55 kima-prod-relay hermes[1037446]: 2024-11-13T13:24:55.592015Z ERROR ThreadId(08) worker.batch{chain=kima_mainnet}:supervisor.handle_batch{chain=kima_mainnet}:supervisor.process_batch{chain=kima_mainnet}:worker.packet.cmd{src_chain=kima_mainnet src_port=transfer src_channel=channel-4 dst_chain=osmosis-1}:relay{odata=0a7a76f9 ->Destination @0-1131275; len=1}:send_messages_and_wait_check_tx{chain=osmosis-1 tracking_id=0a7a76f9}:send_tx_with_account_sequence_retry{chain=osmosis-1 account.sequence=491}:estimate_gas: failed to simulate tx. propagating error to caller: gRPC call `send_tx_simulate` failed with status: status: Unknown, message: "account sequence mismatch, expected 492, got 491: incorrect account sequence [cosmos/cosmos-sdk@v0.50.9/x/auth/ante/sigverify.go:290] with gas used: '79430'", details: [], metadata: MetadataMap { headers: {"server": "nginx", "date": "Wed, 13 Nov 2024 13:24:55 GMT", "content-type": "application/grpc", "x-cosmos-block-height": "23925109"} }
Nov 13 13:24:55 kima-prod-relay hermes[1037446]: 2024-11-13T13:24:55.592095Z ERROR ThreadId(608) worker.batch{chain=kima_mainnet}:supervisor.handle_batch{chain=kima_mainnet}:supervisor.process_batch{chain=kima_mainnet}:worker.packet.cmd{src_chain=kima_mainnet src_port=transfer src_channel=channel-4 dst_chain=osmosis-1}: will retry: schedule execution encountered error: link failed with underlying error: gRPC call `send_tx_simulate` failed with status: status: Unknown, message: "account sequence mismatch, expected 492, got 491: incorrect account sequence [cosmos/cosmos-sdk@v0.50.9/x/auth/ante/sigverify.go:290] with gas used: '79430'", details: [], metadata: MetadataMap { headers: {"server": "nginx", "date": "Wed, 13 Nov 2024 13:24:55 GMT", "content-type": "application/grpc", "x-cosmos-block-height": "23925109"} }
Nov 13 13:24:55 kima-prod-relay hermes[1037446]: 2024-11-13T13:24:55.592120Z  WARN ThreadId(608) worker.batch{chain=kima_mainnet}:supervisor.handle_batch{chain=kima_mainnet}:supervisor.process_batch{chain=kima_mainnet}:worker.packet.cmd{src_chain=kima_mainnet src_port=transfer src_channel=channel-4 dst_chain=osmosis-1}: task encountered ignorable error: link error: link failed with underlying error: gRPC call `send_tx_simulate` failed with status: status: Unknown, message: "account sequence mismatch, expected 492, got 491: incorrect account sequence [cosmos/cosmos-sdk@v0.50.9/x/auth/ante/sigverify.go:290] with gas used: '79430'", details: [], metadata: MetadataMap { headers: {"server": "nginx", "date": "Wed, 13 Nov 2024 13:24:55 GMT", "content-type": "application/grpc", "x-cosmos-block-height": "23925109"} }
Nov 13 13:25:03 kima-prod-relay hermes[1037446]: 2024-11-13T13:25:03.873995Z DEBUG ThreadId(154) spawn:chain{chain=kima_mainnet}:client{client=07-tendermint-27}:connection{connection=connection-17}:channel{channel=channel-4}:worker.client.misbehaviour{client=07-tendermint-27 src_chain=osmosis-1 dst_chain=kima_mainnet}: checking misbehavior for updated client
Nov 13 13:25:07 kima-prod-relay hermes[1037446]: 2024-11-13T13:25:07.742262Z  INFO ThreadId(08) spawn:chain{chain=kima_mainnet}:client{client=07-tendermint-27}:connection{connection=connection-17}:channel{channel=channel-4}:worker.client.misbehaviour{client=07-tendermint-27 src_chain=osmosis-1 dst_chain=kima_mainnet}:foreign_client.detect_misbehaviour_and_submit_evidence{client=osmosis-1->kima_mainnet:07-tendermint-27}:foreign_client.detect_misbehaviour{client=osmosis-1->kima_mainnet:07-tendermint-27}: No evidence of misbehavior detected for chain osmosis-1
Nov 13 13:25:07 kima-prod-relay hermes[1037446]: 2024-11-13T13:25:07.742318Z DEBUG ThreadId(08) spawn:chain{chain=kima_mainnet}:client{client=07-tendermint-27}:connection{connection=connection-17}:channel{channel=channel-4}:worker.client.misbehaviour{client=07-tendermint-27 src_chain=osmosis-1 dst_chain=kima_mainnet}:foreign_client.detect_misbehaviour_and_submit_evidence{client=osmosis-1->kima_mainnet:07-tendermint-27}:foreign_client.detect_misbehaviour{client=osmosis-1->kima_mainnet:07-tendermint-27}: no misbehavior detected
Nov 13 13:25:07 kima-prod-relay hermes[1037446]: 2024-11-13T13:25:07.842523Z  INFO ThreadId(154) spawn:chain{chain=kima_mainnet}:client{client=07-tendermint-27}:connection{connection=connection-17}:channel{channel=channel-4}:worker.client.misbehaviour{client=07-tendermint-27 src_chain=osmosis-1 dst_chain=kima_mainnet}:foreign_client.detect_misbehaviour_and_submit_evidence{client=osmosis-1->kima_mainnet:07-tendermint-27}: client is valid
Nov 13 13:25:07 kima-prod-relay hermes[1037446]: 2024-11-13T13:25:07.842564Z DEBUG ThreadId(154) spawn:chain{chain=kima_mainnet}:client{client=07-tendermint-27}:connection{connection=connection-17}:channel{channel=channel-4}:worker.client.misbehaviour{client=07-tendermint-27 src_chain=osmosis-1 dst_chain=kima_mainnet}: client is valid
Nov 13 13:28:02 kima-prod-relay hermes[1037446]: 2024-11-13T13:28:02.284023Z  WARN ThreadId(28) spawn:chain{chain=osmosis-1}:wallet{chain=osmosis-1}: task encountered ignorable error: failed to query balance for the account: gRPC call `query_balance` failed with status: status: Internal, message: "protocol error: received message with invalid compression flag: 60 (valid flags are 0 and 1) while receiving response with status: 503 Service Unavailable", details: [], metadata: MetadataMap { headers: {"server": "nginx", "date": "Wed, 13 Nov 2024 13:28:02 GMT", "content-type": "text/html; charset=utf-8", "content-length": "190"} }
Nov 13 13:29:22 kima-prod-relay hermes[1037446]: 2024-11-13T13:29:22.506295Z  WARN ThreadId(28) spawn:chain{chain=osmosis-1}:wallet{chain=osmosis-1}: task encountered ignorable error: failed to query balance for the account: gRPC call `query_balance` failed with status: status: Internal, message: "protocol error: received message with invalid compression flag: 60 (valid flags are 0 and 1) while receiving response with status: 503 Service Unavailable", details: [], metadata: MetadataMap { headers: {"server": "nginx", "date": "Wed, 13 Nov 2024 13:29:22 GMT", "content-type": "text/html; charset=utf-8", "content-length": "190"} }```

So the error you are seeing is the account sequence mismatch, correct?


Add functions to split a robot model into submodel objects

cc @GiulioRomualdi @S-Dafarra

Hi @S-Dafarra I addressed all the comments besides https://github.com/ami-iit/bipedal-locomotion-framework/pull/604#discussion_r1104144580 and https://github.com/ami-iit/bipedal-locomotion-framework/pull/604#discussion_r1104158771. I will wait for @GiulioRomualdi's answers. Thanks for the review.

As a more general comment, I have seen that you removed the RobotDynamicsEstimator namespace. Now all the SubModel related functions are in the "general" namespace Estimators.
It is not a big deal, but I would expect the symbols in the general Estimators namespace to be related to an estimator, while in this case are functions related to the use of a sub-model.
One possibility would be to move those functions within the struct SubModel.
Another, trickier, possibility is to have a more class-oriented approach. I have noticed that many of those methods require a submodel as input (all the attach functions). This can be avoided if the function is a class method. The functions that instead create a SubModel can be a static method. In other words, we could have
class SubModel {
    //These below are all private. If we need to expose them, we could use appropriate getters/setters
    iDynTree::Model model; /**< iDynTree Model object describing the submodel */
    std::vector<int> jointListMapping; /**< Each element contains an index describing the joint position in the full model*/
    std::vector<FT> ftList; /**< List of force/torque sensors in the submodel */
    std::vector<Sensor> accelerometerList; /**< List of accelerometers in the submodel */
    std::vector<Sensor> gyroscopeList; /**< List of gyroscopes in the submodel */
    std::vector<std::string> externalContactList; /**< List of the additional external contacts */
public:
    static bool getSubModels(iDynTree::ModelLoader & mdlLdr,
                  iDynTree::KinDynComputations & kinDyn,
                  const std::vector<BipedalLocomotion::Estimators::Sensor> & ftSensorList,
                  const std::vector<BipedalLocomotion::Estimators::Sensor> & accList,
                  const std::vector<BipedalLocomotion::Estimators::Sensor> & gyroList,
                  const std::vector<std::string> & externalContacts,
                  std::vector<BipedalLocomotion::Estimators::SubModel> & subModelList);
    /* ...... */
    std::vector<std::string> attachExternalContactsToSubModel(const std::vector<std::string> & contactsFromConfig); //note that I am not passing a submodel here
};

Anyhow, these are just possible suggestions. Feel free to ignore them :wink:

@S-Dafarra @GiulioRomualdi I completely changed the file structure. I created two classes, one for splitting the model into sub-models and one that represents the sub-model object (what before was a struct). All members are private and are only accessible via get methods. I have also added back the RobotDynamicsEstimator namespace.

@S-Dafarra thanks again. I modified the code following your suggestions.

Anyhow, none of the remaining comments is blocking for me.

Great! Thanks again, you gave me really useful tips :)

@GiulioRomualdi the PR is again ready for review.

Thank you @isorrentino I will squash and merge the PR :)


Can't interrupt running cell after continuing debug session

Applies To

[X] Notebooks (.ipynb files)
[ ] Interactive Window and/or Cell Scripts (.py files with #%% markers)

What happened?
It is impossible to interrupt the kernel after debugging a cell, hitting a breakpoint, and then continuing. Instead, you have to wait for the cell to finishing executing before you can run it again or restart the kernel. This can be problematic when debugging long-running calculations
Steps to reproduce

Install this repository: https://github.com/caleb531/automata
Create a new Python notebook
Create a new cell and enter the following code:

from automata.tm.dtm import DTM

dtm = DTM(
    states={'S','a','b','c','d','e','f','H'},
    input_symbols={'1'},
    tape_symbols={'0','1'},
    transitions={
        'S': {
            '0': ('a', '0', 'N'),
            '1': ('a', '0', 'N')
        },
        'a': {
            '0': ('b', '1', 'R'),
            '1': ('d', '0', 'L')
        },
        'b': {
            '0': ('c', '1', 'R'),
            '1': ('f', '0', 'R')
        },
        'c': {
            '0': ('c', '1', 'L'),
            '1': ('a', '1', 'L')
        },
        'd': {
            '0': ('e', '0', 'L'),
            '1': ('H', '1', 'R')
        },
        'e': {
            '0': ('f', '1', 'L'),
            '1': ('b', '0', 'R')
        },
        'f': {
            '0': ('c', '0', 'R'),
            '1': ('e', '0', 'R')
        }
    },
    initial_state='a',
    blank_symbol='0',
    final_states={'H'}
)

dtm.read_input('1')

Add a breakpoint on the last line
Select 'Debug cell' from the little drop down next to the arrowhead by the top left corner of the cell
Wait for the breakpoint to be hit
Hit the blue continue button that looks like a right-pointing arrowhead with a line next to it
Hit the square interrupt button by the top left corner of the cell

Expected behaviour
Cell execution is interrupted
Actual behaviour
Cell execution continues (in this specific case, for a very long time)
Additional info
See attached video for a demonstration of the behaviour. Despite pressing the interrupt button twice and attempting to restart the kernel, the cell still appears to be running.
https://user-images.githubusercontent.com/19190699/223289351-7d8d0b49-1ebd-45e0-9e4b-1f9695b6f575.mp4
Disconnecting from the debug session (with the red disconnected plug icon) allows interrupting, but it is not possible to disconnect from the debug session after continuing as far as I can tell.
Appears to be specific to pre-release version v2022.10.1103011060 as downgrading to the current release v2022.9.1303220346 fixes it. However, that is not an acceptable workaround as v2022.10.1103011060 introduced the jupyter.debugJustMyCode config option, which I make frequent use of.
I tried searching for this specific issue on Google and in the GitHub issues, but couldn't find any other reports of this exact issue. Apologies if I've overlooked something.
VS Code Version
Version: 1.72.2 Commit: d045a5eda657f4d7b676dedbfa7aab8207f8a075 Date: 2022-10-12T22:16:26.920Z Electron: 19.0.17 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: <IP_ADDRESS>-electron.0 OS: Linux x64 5.15.0-48-generic Sandboxed: No
Jupyter Extension Version
v2022.10.1103011060
Jupyter logs
No response
Coding Language and Runtime Version
Python 3.9.0
Language Extension Version (if applicable)
Python v2022.16.1
Anaconda Version (if applicable)
conda 4.12.0
Running Jupyter locally or remotely?
Local

This is supposed to do an interrupt, seems like that's not happening

I can no longer rpro this issue, if you still run into this, please do ping here and I'll reopen this issue or feel free to create a new issue.


Fix #536 mpv crash in AppImage on Manjaro (code by zocker-160)

See #536

Testing the changes on my Debian Sid, this doesn't affect AppImage running fine, but it breaks running Syncplay natively.
Originally the environment was set for sake of screenshots appearing in correct folder. Maybe the solution is to just set the $PWD rather than overriding entire env.


Linked to first tutorial

Added first tutorial
Updated operations
Updated
Updated resource content
Add links to resources files
Update links to resources files.
Added the required note
Added prep-checks resource references
Added content to house-exchanges resources; updated users resource
Added link to users resource reference topic
Minor tweak to reference topic for users
Added users resource reference topic
Added a link to Get STarted
Added overview content

Couldn't resolve conflicts


JWKS URL does not change based on the configuration in the deployment.toml

Description:
In APIM v4, we have the following configuration and using that we can change the JWKS endpoint. Basically we can provide a private url to the gateways for calling the JWKS endpoint.
[apim.key_manager]
service_url = "https://wso2apim:9443/services/"
Looks like in APIM v4.1.0, we can't change that anymore due to a recent fix. This is an issue in a container deployments as it cannot route to the external facing endpoint(Lb endpoint/Ingress). All the QSGs related to container deployment will fail and we have to ask the user to manually change the JWKS endpoint. I guess this is not a good approach for QSGs.
Had a chat with Tharindu and possible option is to introduce a config which basically gives the permission to override the wellknown urls or not.
Steps to reproduce:
Affected Product Version:

Environment details (with versions):

OS:
Client:
Env (Docker/K8s):

Optional Fields
Related Issues:

Suggested Labels:

Suggested Assignees:

I don't understand the fix properly. If giving permission to override the well known URLs is ok, instead of making that the default behaviour why are we introducing a config?

It seems this fix has been introduced as part of the token exchange grant. So if we override these endpoints, then the token exchange grant won't work. If we have a config, then we can control this. @tharindu1st Comments?

@nuwand  currently we read issuer and JWKS endpoint through Well-known endpoint.
When that we doing we get the public hostname of IDP to read the JWKS.
since authorization servers are behind a load balancer and they are in the same zone they directly read from CP through the internal hostname.
The fix is required to override the behavior that came from OpenID connect endpoint and keep only having generated urls to jwks endpoint.

As discussed we could set the K8s service name to the ingress host as well. But encountered an issue where external port is 443 and internal port is 9443. But at the K8s service level we could expose another port as 443 and route to the 9443 port of the apim container. With that we could solve this issue. Plan is to apply these changes to K8s related artifacts.

As discussed we could set the K8s service name to the ingress host as well. But encountered an issue where external port is 443 and internal port is 9443. But at the K8s service level we could expose another port as 443 and route to the 9443 port of the apim container. With that we could solve this issue. Plan is to apply these changes to K8s related artifacts.


reel_board: remove the hw_reset which blocks flashing

The hw reset type is blocking the flash of reel_board.
It seems removing it can fix the issue.
Signed-off-by: Ming Shao<EMAIL_ADDRESS>(Disclaimer: I am not sure if this fix is appropriate. But it does work when I try to flash reel board)
The error I saw is:

Traceback (most recent call last):
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/main.py", line 161, in run
status = cmd.invoke()
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/subcommands/load_cmd.py", line 125, in invoke
programmer.program(filename,
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/file_programmer.py", line 170, in program
self._loader.commit()
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/loader.py", line 289, in commit
perf = builder.program(chip_erase=chipErase,
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/builder.py", line 490, in program
sector_erase_count, page_program_time = self._compute_sector_erase_pages_and_weight(fast_verify)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/builder.py", line 666, in _compute_sector_erase_pages_and_weight
self._analyze_pages_with_crc32(fast_verify)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/builder.py", line 645, in _analyze_pages_with_crc32
self._enable_read_access()
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/builder.py", line 259, in _enable_read_access
self.flash.init(self.flash.Operation.VERIFY)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/flash.py", line 252, in init
result = self._call_function_and_wait(self.flash_algo['pc_init'],
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/flash.py", line 653, in _call_function_and_wait
self._call_function(pc, r0, r1, r2, r3, init)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/flash.py", line 555, in _call_function
self.target.write_core_registers_raw(reg_list, data_list)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/core/soc_target.py", line 235, in write_core_registers_raw
self.selected_core_or_raise.write_core_registers_raw(reg_list, data_list)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/coresight/cortex_m.py", line 1175, in write_core_registers_raw
self._base_write_core_registers_raw(reg_list, data_list)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/coresight/cortex_m.py", line 1189, in _base_write_core_registers_raw
raise exceptions.CoreRegisterAccessError(
pyocd.core.exceptions.CoreRegisterAccessError: cannot write registers pc, r0, r1, r2, r9, sp, lr because core #0 is not halted
FATAL ERROR: command exited with status 1: pyocd flash --config /home/ming/sources/zephyrproject/zephyr/boards/arm/reel_board/support/pyocd.yaml -e sector -t nrf52840 -f 4000000 /home/ming/sources/zephyrproject/zephyr/bld_reel/zephyr/zephyr.hex
FAILED: zephyr/cmake/flash/CMakeFiles/flash /home/ming/sources/zephyrproject/zephyr/bld_reel/zephyr/cmake/flash/CMakeFiles/flash

I cannot confirm any issues flashing reel board, tested on latest main and Python 3.10.6.

Could you try below steps:
I have two reel boards plugged on my host (but I think the number doesn't matter).
I got hardware map like below:

connected: true
id: OSHW000032254e45000d8003ab98002484d1000097969900
platform: reel_board
product: DAPLink CMSIS-DAP
runner: pyocd
serial: /dev/ttyACM0
connected: true
id: OSHW000041114e45002e3006bcf000330571000097969900
platform: reel_board
product: DAPLink CMSIS-DAP
runner: pyocd
serial: /dev/ttyACM1

Then I did this:
cmake -B bld_reel -GNinja -DBOARD=reel_board -S samples/hello_world/
cd bld_reel/
ninja flash
Then pyocd prompts me with this:
[0/1] Flashing reel_board
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner pyocd
-- runners.pyocd: Flashing file: /home/ming/sources/zephyrproject/zephyr/bld_reel/zephyr/zephyr.hex
  #   Probe/Board             Unique ID                                          Target
-----------------------------------------------------------------------------------------
  0   ARM DAPLink CMSIS-DAP   OSHW000032254e45000d8003ab98002484d1000097969900   n/a

  1   ARM DAPLink CMSIS-DAP   OSHW000041114e45002e3006bcf000330571000097969900   n/a

Enter the number of the debug probe or 'q' to quit>

Then I select 0 or 1.
Then I got the error:

0059759 W Board ID OSHW is not recognized [mbed_board]
0059996 I Loading /home/ming/sources/zephyrproject/zephyr/bld_reel/zephyr/zephyr.hex [load_cmd]
0060789 C cannot write registers pc, r0, r1, r2, r9, sp, lr because core #0 is not halted [main]
Traceback (most recent call last):
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/main.py", line 161, in run
status = cmd.invoke()
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/subcommands/load_cmd.py", line 125, in invoke
programmer.program(filename,
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/file_programmer.py", line 170, in program
self._loader.commit()
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/loader.py", line 289, in commit
perf = builder.program(chip_erase=chipErase,
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/builder.py", line 490, in program
sector_erase_count, page_program_time = self._compute_sector_erase_pages_and_weight(fast_verify)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/builder.py", line 666, in _compute_sector_erase_pages_and_weight
self._analyze_pages_with_crc32(fast_verify)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/builder.py", line 645, in _analyze_pages_with_crc32
self._enable_read_access()
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/builder.py", line 259, in _enable_read_access
self.flash.init(self.flash.Operation.VERIFY)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/flash.py", line 252, in init
result = self._call_function_and_wait(self.flash_algo['pc_init'],
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/flash.py", line 653, in _call_function_and_wait
self._call_function(pc, r0, r1, r2, r3, init)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/flash/flash.py", line 555, in _call_function
self.target.write_core_registers_raw(reg_list, data_list)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/core/soc_target.py", line 235, in write_core_registers_raw
self.selected_core_or_raise.write_core_registers_raw(reg_list, data_list)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/coresight/cortex_m.py", line 1175, in write_core_registers_raw
self._base_write_core_registers_raw(reg_list, data_list)
File "/home/ming/.local/lib/python3.10/site-packages/pyocd/coresight/cortex_m.py", line 1189, in _base_write_core_registers_raw
raise exceptions.CoreRegisterAccessError(
pyocd.core.exceptions.CoreRegisterAccessError: cannot write registers pc, r0, r1, r2, r9, sp, lr because core #0 is not halted
FATAL ERROR: command exited with status 1: pyocd flash --config /home/ming/sources/zephyrproject/zephyr/boards/arm/reel_board/support/pyocd.yaml -e sector -t nrf52840 -f 4000000 /home/ming/sources/zephyrproject/zephyr/bld_reel/zephyr/zephyr.hex
FAILED: zephyr/cmake/flash/CMakeFiles/flash /home/ming/sources/zephyrproject/zephyr/bld_reel/zephyr/cmake/flash/CMakeFiles/flash
cd /home/ming/sources/zephyrproject/zephyr/bld_reel && /usr/bin/cmake -DTARGET=flash -DDEPENDENCIES="" -P /home/ming/sources/zephyrproject/zephyr/cmake/flash/check_runner_dependencies.cmake && /usr/bin/cmake -E env /usr/bin/python3.10 -m west flash
ninja: build stopped: subcommand failed.

Codecov Report

Merging #50128 (2829de7) into main (4da8975) will increase coverage by 0.24%.
The diff coverage is 72.22%.

:exclamation: Current head 2829de7 differs from pull request most recent head dc68f00. Consider uploading reports for the commit dc68f00 to get more accurate results

@@            Coverage Diff             @@
##             main   #50128      +/-   ##
==========================================
+ Coverage   47.77%   48.02%   +0.24%
==========================================
  Files         517      521       +4
  Lines       74085    74501     +416
  Branches    17794    17870      +76
==========================================
+ Hits        35393    35777     +384
+ Misses      32611    32573      -38
- Partials     6081     6151      +70

Impacted Files
Coverage Δ

drivers/gpio/gpio_emul.c
69.25% <ø> (ø)

drivers/i2c/i2c_common.c
62.50% <0.00%> (ø)

drivers/can/can_shell.c
49.01% <41.66%> (-0.46%)
:arrow_down:

drivers/can/can_loopback.c
85.51% <100.00%> (+3.46%)
:arrow_up:

arch/posix/core/cpuhalt.c
69.23% <0.00%> (-30.77%)
:arrow_down:

subsys/net/lib/lwm2m/lwm2m_registry.c
21.08% <0.00%> (-0.20%)
:arrow_down:

subsys/net/lib/websocket/websocket.c
25.52% <0.00%> (-0.12%)
:arrow_down:

subsys/net/lib/lwm2m/lwm2m_engine.c
8.98% <0.00%> (-0.11%)
:arrow_down:

subsys/net/lib/coap/coap.c
6.94% <0.00%> (-0.09%)
:arrow_down:

subsys/net/lib/lwm2m/lwm2m_message_handling.c
9.38% <0.00%> (-0.02%)
:arrow_down:

... and 25 more

Continue to review full report at Codecov.

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

Then I did this:
cmake -B bld_reel -GNinja -DBOARD=reel_board -S samples/hello_world/ cd bld_reel/ ninja flash

[0/1] Flashing reel_board
-- west flash: rebuilding
[2/171] Generating include/generated/version.h
-- Zephyr version: 3.2.0-rc2 (/home/john/zephyr-project/zephyr), build: v3.2.0-rc2-68-g7c231e3e271a
[161/171] Linking C executable zephyr/zephyr_pre0.elf

[165/171] Linking C executable zephyr/zephyr_pre1.elf

[171/171] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:       22508 B         1 MB      2.15%
            SRAM:        4264 B       256 KB      1.63%
        IDT_LIST:          0 GB         2 KB      0.00%
-- west flash: using runner pyocd
-- runners.pyocd: Flashing file: /home/john/zephyr-project/zephyr/build/zephyr/zephyr.hex
  #   Probe                   Unique ID
--------------------------------------------------------------------------------
  0   ARM DAPLink CMSIS-DAP   OSHW000032254e4500138003ab98002184d1000097969900
  1   ARM DAPLink CMSIS-DAP   OSHW000047784e45001d9002d996002b9081000097969900

Enter the number of the debug probe or 'q' to quit> 0
0003791 I Loading /home/john/zephyr-project/zephyr/build/zephyr/zephyr.hex [load_cmd]
[==================================================] 100%
0006252 I Erased 24576 bytes (6 sectors), programmed 24576 bytes (6 pages), skipped 0 bytes (0 pages) at 9.82 kB/s [loader]

Works fine for me. What is your pyocd --version?

Works fine for me. What is your pyocd --version?

pyocd 0.34.1
@jfischer-no

Works fine for me. What is your pyocd --version?

pyocd 0.34.1
@jfischer-no

I cannot reproduce it using pyocd-0.33.1 but pyocd 0.34.1


CRL HELPER

This package automatically downloads CRLs and uploads them to OneView. The users have to provide aliasname of certificates and their associated CRL Distribution points .

@SushruthHPE please sign your commit. You should be able to do this by going to your fork and doing 'git commit -s --amend' and a push. This should update the pull request.

@bobfraser1 I have signed my commit . Also the images were missing in README.md. I have fixed them.


"go get" fails in GOPATH mode

Running GO111MODULE=off go get github.com/mholt/archiver (or, more generally, running go get github.com/mholt/archiver in GOPATH mode) fails with the following output:
package github.com/pierrec/lz4/v3: cannot find package "github.com/pierrec/lz4/v3" in any of:
	/usr/local/go/src/github.com/pierrec/lz4/v3 (from $GOROOT)
	/go/src/github.com/pierrec/lz4/v3 (from $GOPATH)

This is due to an interaction between Go module semantic version imports and GOPATH mode not working well together in certain cases -- filed https://github.com/golang/go/issues/35630 to track the underlying issue on the Golang side.
Even though it's not best practice, some clients appear to depend on "go get" to populate their GOPATH for development, and the current conflation of circumstances are such that there is no easy work-around for this.
The easiest short-term fix would probably be to revert https://github.com/mholt/archiver/pull/192 -- if the import path is restored to "github.com/pierrec/lz4", then this will continue to work (and the only downside of this is that module imports are not quite as nice).

Is there any way do go get it right now?

Revert change #192 on master immediately, only development branches should refer to other development branches!!!  That's not only a best practice, it's common sense.
  The modules thing is not even the issue, and doesn't really solve the dependency management aspect of the problem here at all.

@awgh the change you referenced doesn't reference a development branch -- it adds a dependency for version 3.0.1, which is a release version of the referenced project: https://github.com/pierrec/lz4/tree/v3.0.1
The github.com/pierrec/lz4 project has taken an unconventional (but valid) approach to modules, where it seems that they only add the go.mod file on releases but don't maintain it on the development branch. This makes the "go get" operation fail due to interactions with GOPATH mode.
For module consumers (which should be the vast majority of consumers going forward), this change is strictly correct, as it properly declares the module dependency of an imported package. However, it does have the unfortunate side effect of negative impact for GOPATH mode due to the unconventional approach of the lz4 repo.
The comment on https://github.com/golang/go/issues/35630#issuecomment-555091261 did provide a workaround for GOPATH mode -- I'll update this issue with the specific instructions.
There certainly is a trade-off here between module correctness and maintaining smoothness for GOPATH/go get consumers. @mholt is in a better position to evaluate the trade-off for this package and decide what he's comfortable with -- for example, this package itself could adopt the "major version subdirectory" mode of development and create a "v3" or "v4" subdirectory for the new module-based version (which would maintain GOPATH compatibility for the previous version), but that would be a major change to the repo structure.

Although not pretty, in GOPATH mode with a clean GOPATH, running the following command will allow "go get" or "go install" to succeed:
go get github.com/pierrec/lz4 && cd $GOPATH/src/github.com/pierrec/lz4 && git fetch && git checkout v3.0.1

Basically, if the copy of github.com/pierrec/lz4 in the local GOPATH includes the go.mod definition that declares the major version of the module, then the "go get" or "go install" of this package will succeed due to the minimal module compatibility code.

Even though it's not best practice, some clients appear to depend on "go get" to populate their GOPATH for development

Unfortunately, Go modules broke the behavior of go get for this, I also opened an issue about it: https://github.com/golang/go/issues/31529
I think if a user wants to maintain a deprecated Go convention from earlier versions of Go while using a newer version of Go, that is their responsibility -- and the lack of a go.mod in the lz4 lib isn't a bug in this project.
I think it's important that we strictly maintain Go module compatibility going forward. I'm not really interested in maintaining old versions. Just the most recent version is enough work. 😅

Although not pretty, in GOPATH mode with a clean GOPATH, running the following command will allow "go get" or "go install" to succeed:

Thanks! This helped me out :)


Optimization: Remove 'accept-encoding: gzip' from default

We are running into an issue where some heavy duty tests that spawn multiple isolates are failing to run coverage fast enough in Travis-CI (hits the 50 minute maximum).
Looking at CPU profiler, the coverage tool spends about 15% of runtime decompressing gzipped data (or at least in a method that is only triggered when decompressing data). Since the VM service is most often used intra-machine (?), it might be valuable to turn off gzip by default.
(It doesn't appear that the dart:io Websocket implementation allows this behavior yet.)

Hi @joeconwaystk, is the coverage tool using this library? This repo is for dart and java libraries to speak the service protocol.
You probably want to file this issue on the dart sdk repo against the vm and debugger implementation?

👍 Got confused on my repos. Will move it there, thanks.


Liveliness Detection Documentation

Documentation Improvement in liveness detection
Fixes: #985
Proposed Changes

Added an Introduction of the project
application of the project
flowchart of the training pipeline
Also created a new folder for storing images to separate the dataset images and others

let me know if further changes are required


DLL load failed (python=3.10.8)

ImportError                               Traceback (most recent call last)
Cell In[1], line 1
----> 1 import gradio as gr
2 import os
3 from langchain.chat_models import ChatOpenAI
File [c:\ProgramData\anaconda3\envs\wenan3\lib\site-packages\gradio_init_.py:3](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/init.py:3)
[1](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/init.py:1) import json
----> [3](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/init.py:3) import gradio._simple_templates
[4](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/init.py:4) import gradio.image_utils
[5](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/init.py:5) import gradio.processing_utils
File [c:\ProgramData\anaconda3\envs\wenan3\lib\site-packages\gradio_simple_templates_init_.py:1](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/_simple_templates/init.py:1)
----> [1](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/_simple_templates/init.py:1) from .simpledropdown import SimpleDropdown
[2](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/_simple_templates/init.py:2) from .simpleimage import SimpleImage
[3](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/_simple_templates/init.py:3) from .simpletextbox import SimpleTextbox
File [c:\ProgramData\anaconda3\envs\wenan3\lib\site-packages\gradio_simple_templates\simpledropdown.py:6](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/_simple_templates/simpledropdown.py:6)
[3](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/_simple_templates/simpledropdown.py:3) import warnings
[4](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/_simple_templates/simpledropdown.py:4) from typing import Any, Callable
----> [6](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/_simple_templates/simpledropdown.py:6) from gradio.components.base import FormComponent
[7](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/_simple_templates/simpledropdown.py:7) from gradio.events import Events
[10](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/gradio/_simple_templates/simpledropdown.py:10) class SimpleDropdown(FormComponent):
...
----> [1](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/rpds/init.py:1) from .rpds import *
[3](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/rpds/init.py:3) doc = rpds.doc
[4](file:///C:/ProgramData/anaconda3/envs/wenan3/lib/site-packages/rpds/init.py:4) if hasattr(rpds, "all"):
ImportError: DLL load failed while importing rpds: 拒绝访问。

I have tested on two computer with python=3.10.8. Both of them have this issue。 The specific manifestation is: everything works normally the first time it is run, but after closing and running it a second time, the aforementioned "ImportError: DLL load failed while importing rpds" error appears.
I later tried different Python versions on the same computer with python=3.11.7 there is no problem, but with python=3.10.8 the error always occurs.
However, for some reason, I wish for it to run normally under Python 3.10.8. Is there a way to resolve this issue?

I have no idea what gradio is.
If you do have the right repo, please provide a way to reproduce whatever behavior you're reporting without any dependencies.

What Gradio is doesn't matter; it's just that when I was using it, it utilized rpds, and there was an error with rpds. The line of code that needs attention is: 'from .rpds import *'. In a Python 3.10.8 environment, I encountered the error 'ImportError: DLL load failed while importing rpds: Access is denied'.    But id didn't occur in python=3.11.7

Well, again then, provide a minimal example with no dependencies that produces the behavior you're reporting.

just run import rpds  on python=3.10.8

CI, which obviously runs that line, passes fine, so you'll have to be more specific.
Your screenshot also shows a traceback with lines that do not exist in this package.
Closing, please provide an actual reproducer and then I'm happy to look.

Thsnks a lot! Here is the step:

I use Anaconda to create a new env, with python=3.10.8

runnning pip install rpds-py

open vscode, run import rpds, the fist time I run this code it will be fine
close vscode, open vscode and run import rpds again, the error occur