error compiling clap

I'm having trouble building collapse. Could I please ask for help figuring this out?
cargo --version
cargo 1.28.0 (96a2c7d16 2018-07-13)

rustc --version
rustc 1.28.0 (9634041f0 2018-07-30)

cargo build --release

   Compiling clap v2.32.0
error[E0583]: file not found for module `option`
  --> /Users/slowikow/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.32.0/src/args/arg_builder/mod.rs:10:5
   |
10 | mod option;
   |     ^^^^^^
   |
   = help: name the file either option.rs or option/mod.rs inside the directory "/Users/slowikow/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.32.0/src/args/arg_builder"

error: aborting due to previous error

For more information about this error, try `rustc --explain E0583`.
error: Could not compile `clap`.
warning: build failed, waiting for other jobs to finish...
error: build failed

rustc --explain E0583

A file wasn't found for an out-of-line module.

Erroneous code example:

```
mod file_that_doesnt_exist; // error: file not found for module

fn main() {}
```

Please be sure that a file corresponding to the module exists. If you
want to use a module named `file_that_doesnt_exist`, you need to have a file
named `file_that_doesnt_exist.rs` or `file_that_doesnt_exist/mod.rs` in the
same directory.

$ cargo build --release
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating git repository `https://github.com/sdleffler/vosealias-rs`
 Downloading ndarray v0.6.10
 Downloading image v0.20.1
 Downloading bitflags v0.7.0
 Downloading bit-set v0.4.0
 Downloading bit-vec v0.4.4
 Downloading log v0.3.9
 Downloading pbr v0.3.1
 Downloading regex v0.1.80
 Downloading itertools v0.5.10
 Downloading num-traits v0.1.43
 Downloading matrixmultiply v0.1.15
 Downloading num-complex v0.1.43
 Downloading num-traits v0.2.6
 Downloading rawpointer v0.1.0
 Downloading tiff v0.2.1
 Downloading num-rational v0.2.1
 Downloading png v0.12.0
 Downloading lzw v0.10.0
 Downloading gif v0.10.1
 Downloading scoped_threadpool v0.1.9
 Downloading jpeg-decoder v0.1.15
 Downloading byteorder v1.2.7
 Downloading num-iter v0.1.37
 Downloading num-derive v0.2.3
 Downloading proc-macro2 v0.4.23
 Downloading quote v0.6.10
 Downloading syn v0.15.20
 Downloading inflate v0.4.3
 Downloading deflate v0.7.19
 Downloading adler32 v1.0.3
 Downloading color_quant v1.0.1
 Downloading rayon v1.0.3
 Downloading cfg-if v0.1.6
 Downloading lazy_static v1.2.0
 Downloading nodrop v0.1.13
 Downloading log v0.4.6
 Downloading winapi v0.2.8
 Downloading kernel32-sys v0.2.2
 Downloading winapi-build v0.1.1
 Downloading thread_local v0.2.7
 Downloading regex-syntax v0.3.9
 Downloading aho-corasick v0.5.3
 Downloading memchr v0.1.11
 Downloading utf8-ranges v0.1.3
 Downloading thread-id v2.0.0
   Compiling proc-macro2 v0.4.23
   Compiling cfg-if v0.1.6
   Compiling nodrop v0.1.13
   Compiling scopeguard v0.3.3
   Compiling unicode-xid v0.1.0
   Compiling memoffset v0.2.1
   Compiling lazy_static v1.2.0
   Compiling num-traits v0.2.6
   Compiling winapi-build v0.1.1
   Compiling libc v0.2.43
   Compiling rayon-core v1.4.1
   Compiling num-integer v0.1.39
   Compiling num-derive v0.2.3
   Compiling rayon v1.0.3
   Compiling num-iter v0.1.37
   Compiling winapi v0.2.8
   Compiling adler32 v1.0.3
   Compiling either v1.5.0
   Compiling byteorder v1.2.7
   Compiling num-rational v0.2.1
   Compiling matrixmultiply v0.1.15
   Compiling lzw v0.10.0
   Compiling rawpointer v0.1.0
   Compiling unicode-width v0.1.5
   Compiling ndarray v0.6.10
   Compiling bitflags v1.0.4
   Compiling color_quant v1.0.1
   Compiling vec_map v0.8.1
   Compiling strsim v0.7.0
   Compiling regex-syntax v0.3.9
   Compiling bit-vec v0.4.4
   Compiling ansi_term v0.11.0
   Compiling utf8-ranges v0.1.3
   Compiling scoped_threadpool v0.1.9
   Compiling bitflags v0.7.0
   Compiling lazy_static v0.2.11
   Compiling crossbeam-utils v0.2.2
   Compiling log v0.4.6
   Compiling arrayvec v0.4.7
   Compiling kernel32-sys v0.2.2
   Compiling num_cpus v1.8.0
   Compiling rand v0.4.3
   Compiling memchr v0.1.11
   Compiling time v0.1.40
   Compiling atty v0.2.11
   Compiling inflate v0.4.3
   Compiling itertools v0.5.10
   Compiling textwrap v0.10.0
   Compiling deflate v0.7.19
   Compiling bit-set v0.4.0
   Compiling gif v0.10.1
   Compiling log v0.3.9
   Compiling crossbeam-epoch v0.3.1
   Compiling aho-corasick v0.5.3
   Compiling clap v2.32.0
error[E0583]: file not found for module `option`
  --> /Users/slowikow/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.32.0/src/args/arg_builder/mod.rs:10:5
   |
10 | mod option;
   |     ^^^^^^
   |
   = help: name the file either option.rs or option/mod.rs inside the directory "/Users/slowikow/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.32.0/src/args/arg_builder"
error: aborting due to previous error
For more information about this error, try rustc --explain E0583.
error: Could not compile clap.
warning: build failed, waiting for other jobs to finish...
error: build failed

Hi! This looks like a build error within clap, which is not part of collapse, but a dependency that I don't have control over. 2.32.0 seems to be the newest version of clap, which I use for CLI parsing. Not sure what's going on. I'll try to reproduce it myself and report back.

I've pushed a new commit which fixes builds for me on Rust 1.29. The clap dependency here is set to use the newest clap published as long as it doesn't go over major version 2, so it may be that clap 2.32 does not want to compile on stable Rust 1.28 as the newest stable Rust version is actually 1.30.1. In any case it now compiles for me on 1.29 with the updates I just made. I'm going to update to 1.30.1 and see how it does.

Thanks for the comments! I appreciate your help.
I did rustup update to update my rust to version 1.30.0
Then I did cargo build --release and got the same error as before:
   Compiling clap v2.32.0
   Compiling rand v0.3.22
error[E0583]: file not found for module `option`
  --> /Users/slowikow/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.32.0/src/args/arg_builder/mod.rs:10:5
   |
10 | mod option;
   |     ^^^^^^
   |
   = help: name the file either option.rs or option/mod.rs inside the directory "/Users/slowikow/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.32.0/src/args/arg_builder"

error: aborting due to previous error

For more information about this error, try `rustc --explain E0583`.
error: Could not compile `clap`.
warning: build failed, waiting for other jobs to finish...
error: build failed

$ rustc --version
rustc 1.30.1 (1433507eb 2018-11-07)

$ cargo --version
cargo 1.30.0 (a1a4ad372 2018-11-02)

Next, I tried removing clap and trying again. Now I get a new error, similar to the one you mentioned!
First, get rid of clap:
$ rm -rf /Users/slowikow/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.32.0

Now try building again:
$ cargo build --release
   Compiling clap v2.32.0
   Compiling quote v0.6.10
   Compiling crossbeam-deque v0.2.0
   Compiling num-integer v0.1.39
   Compiling num-complex v0.1.43
   Compiling num-traits v0.1.43
   Compiling thread-id v2.0.0
   Compiling pbr v0.3.1
   Compiling thread_local v0.2.7
   Compiling vosealias v0.2.0 (https://github.com/sdleffler/vosealias-rs#73db72c8)
   Compiling rayon-core v1.4.1
error[E0283]: type annotations required: cannot resolve `std::string::String: std::convert::AsRef<_>`
   --> /Users/slowikow/.cargo/registry/src/github.com-1ecc6299db9ec823/pbr-0.3.1/src/pb.rs:348:64
    |
348 |                         base = base + repeat!(self.bar_current.as_ref(), curr_count - 1) +
    |                                                                ^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0283`.
error: Could not compile `pbr`.
warning: build failed, waiting for other jobs to finish...
error: build failed

@slowkow that looks like whatever is failing the build wants to be using Edition 2018. Can you try again using Rust nightly? If you're using rustup you can do rustup override set nightly to tell rustup to use nightly for a single project.

Er, the clap error looks that way. I can't speak for the second error.


The Menubar is not visible in mobile devices

Describe the bug

The Menubar is not visible in mobile devices.
Expected behavior
It needs some adjustments in CSS.Apart from this the tagline in the hero section is also not readable in mobile devices. I want to make these changes and make the UI perfect in mobile devices.
Screenshots (Mandatory)

Additional context (Mandatory )
Kindly assign me this issue.
Are you contributing under any open-source program ?

Yes under GSSOC.

@Abhishek-465 assigned

@apu i have made the PR but it was closed by someone i don't know at all. Is he a project maintainer?

@apu i have made the PR but it was closed by someone i don't know at all. Is he a project maintainer?

Yes. he is project Maintainer .but Don't worry . I have reopened the PR .I will review this . Don't worry

Okay @apu52
thank you so much.


Having sidebar-left to also be toggleable

In previous version it was toggleable deafult="inactive"but this doen't work now in 1.0.3.
How to achieve to have left sidebar also closed and toggled by ui-toggle?

You only need to add

at least in 1.2.0-beta11

That didn't help :-(
sidebar-right has that behavior by default but just can't make sidebar-left to work that way.

Can't understand, in the demo (master branch) both sidebars have the same behaviour, which one are you referring to?

Please see this screen
http://prntscr.com/5xssnt

Oh, in desktop mode.
Well, it sounds quite like an hack because the sidebar behavior is hardcoded in the styles, so you have to mangle it with a bit of LESS:
@media (min-width: @screen-desktop) {
    .has-sidebar-left .app {
        margin-left: 0;
    }
    .sidebar-left-in .app {
        margin-left: @sidebar-left-width-lg;
    }
}

or compiled to CSS:
@media (min-width: 992px) {
    .has-sidebar-left .app {
        margin-left: 0;
    }
    .sidebar-left-in .app {
        margin-left: 300px;
    }
}

Your mileage may vary.
@mcasimir styles seems sometimes very hardcoded, I had to place some workarounds too working with MAUI, wondering if they can be further modularized or customizable, particularly in behaviors like these...

That's it. Thanks a lot.


Unified release script

Reuse https://github.com/Unleash/.github/blob/v1.1.0/.github/workflows/npm-release.yml

@Tymek Should we reopen and merge this?

If you'd like to use the same release automation as in other JS SDKs, yes.


unable to generate top level generation1-convenience-client

In this internal pull request, I'm attempting to upgrade to "Microsoft.Azure.AutoRest.CSharp" Version="3.0.0-beta.20220822.2". The configuration used to be azure-arm: true, but now I'm producing almost the same thing with:
generation1-convenience-client: true
public-clients: true

The top level AvsManagementClient.cs is gone and I don't know why. How do I get it to generate the top level convenience client? Or why was it removed?

I tried switching to the version from https://github.com/Azure/azure-sdk-for-net/blob/main/eng/Directory.Build.Common.props#L8 , but it did not help.
<PackageReference Include="Microsoft.Azure.AutoRest.CSharp" Version="3.0.0-beta.20210504.1" PrivateAssets="All" />

For my info, https://github.com/Azure/azure-sdk-for-net/pull/30583 now has a track2 client for AVS from 5 days ago.

Hi @cataggar , why have you removed azure-arm: true?

@AlexanderSher,
If I add it back, I get:

Exception: Enabling both 'generation1-convenience-client' and 'azure-arm' at the same time is not supported.
at AutoRest.CSharp.AutoRest.Plugins.CSharpGen.ValidateConfiguration() in D:\a_work\1\s\autorest.csharp\src\AutoRest.CSharp\Common\AutoRest\Plugins\CSha
rpGen.cs:line 72
at AutoRest.CSharp.AutoRest.Plugins.CSharpGen.ExecuteAsync(Task`1 codeModelTask) in D:\a_work\1\s\autorest.csharp\src\AutoRest.CSharp\Common\AutoRest\P
lugins\CSharpGen.cs:line 24
at AutoRest.CSharp.AutoRest.Plugins.CSharpGen.Execute(IPluginCommunication autoRest) in D:\a_work\1\s\autorest.csharp\src\AutoRest.CSharp\Common\AutoRe
st\Plugins\CSharpGen.cs:line 97
fatal   | Process() cancelled due to failure

If I remove generation1-convenience-client, I get:

fatal   | Internal error in AutoRest.CSharp
Please file an issue at https://github.com/Azure/autorest.csharp/issues/new.
Attach the written 'Configuration.json' and 'CodeModel.yaml' or the original swagger so we can reproduce your error.

Exception: The blobDuration property of LogSpecification ends with "Duration" but does not use the duration format to be generated as TimeSpan type. Add "format": "duration" with directive in autorest.md for the property if it's ISO 8601 format like P1DT2H59M59S. Add "x-ms-format": "duration-constant" if it's the constant format like 1.2:59:59.5000000. If the property does not conform to a TimeSpan format, please use "x-ms-client-name" to rename the property for the client.

Exception: The blobDuration property of LogSpecification ends with "Duration" but does not use the duration format to be generated as TimeSpan type. Add "format": "duration" with directive in autorest.md for the property if it's ISO 8601 format like P1DT2H59M59S. Add "x-ms-format": "duration-constant" if it's the constant format like 1.2:59:59.5000000. If the property does not conform to a TimeSpan format, please use "x-ms-client-name" to rename the property for the client.

This is the issue you need to address in your input. Here is the property in question: https://github.com/Azure/azure-rest-api-specs-pr/blob/AVS/2022-05/specification/vmware/resource-manager/Microsoft.AVS/stable/2022-05-01/vmware.json#L5365

Even with that removed, azure-arm is creating completely different code than before. I'd like to stay focused on generation1-convience-client for this issue. Any idea why a top level client is no longer generated?

You have swagger input for resource manager, so correct setting is azure-arm: true
@m-nash , @Yao725 , @ArcturusZhang  - can you please take a look?

Hi @cataggar, you should not use the flag generation1-convenience-client, this is for data plane generation. If you want to have the top-level client, you should use this script to generate the track 1 code management plane library. Azure.ResourceManager.Avs belongs to the track 2 management plane library and it will only have one client named ArmClient, which is defined in our core library Azure.ResourceManager.


Fix for getting and setting chunks from wrong region.

This normally cancels itself out when using both get and set chunk.

I have fixed the issues

Thanks. I'd like to test this before merging - can you give me the steps to reproduce the problem that this pull request fixes?


Block web crawlers on v0.7-branch

Google keeps surfacing links from very old versions of the Kubeflow docs website, which is confusing to users.
This PR adds the <meta name="robots" content="noindex"> meta tag to tell Google to stop indexing the pages from the v0.7-branch branch.
It will take probably a few months (or longer) for Google to re-index these pages, I have left nofollow off, so that google will re-index the whole site quicker by following links.

It also backports the changes from https://github.com/kubeflow/website/pull/3863 so the version selector is consistent across each archive version.

The build is actually succeeding on this one, it's just that there is a random other Netlify build which is failing.
The only one that matters is the main one, so this can be merged.

/lgtm
/approve

/lgtm


update sqltoolsversion to 3.0.0-release.41

This PR fixes #
updates sqltoolsversion to 3.0.0-release.41

In the future please include in the title that this is for Kusto specifically 😄

Pull Request Test Coverage Report for Build 298153634

0 of 0   changed or added relevant lines in 0 files are covered.
4 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.01%) to 39.893%

Files with Coverage Reduction
New Missed Lines
%

extensions/notebook/src/jupyter/serverInstance.ts
4
74.52%

Totals

Change from base Build 298096262:
-0.01%

Covered Lines:
20093

Relevant Lines:
46189

💛  - Coveralls


Fix refinement list numerical facets

Came here to say that I had this exact issue on 2.1.0, and I am so relieved to see it fixed! What a great timing! Thanks a lot, seriously!

😀


How to reduce the number of layers of yolo small model

I want to make a light version of yolo-nas less than yolo small model . In YoloV8 we can change the depth, width parameter in yolov8.yaml file , similarly could i adjust hidden_channels and width_mult in this file to achieve it.
Also another question is this file base for only Yolov1 to Yolov8 only or else is it base for yolo-nas also

Hello, please refer to 3 files here: yolo_nas_{s,m,l}_arch_params.yaml.
There are many parameters there, together with depth_mult, and width_mult.


⚠ RPC server - Harmony Test has degraded performance

In e25d320, RPC server - Harmony Test ($HARMONY_TEST_RPC_URL) experienced degraded performance:

HTTP code: 0
Response time: 0 ms

Resolved: RPC server - Harmony Test performance has improved in b1470cc.


[WIP] Bugfix/remove custom selector schema settings from modules

Checklist

[ ] I tested the changes and all related features on the test server https://artemistest.ase.in.tum.de.
[x] ~I documented my source code using the JavaDoc / JSDoc style.~
[x] ~I added integration test cases for the server (Spring) related to the features~
[x] ~I added integration test cases for the client (Jest) related to the features~
[x] ~I added screenshots/screencast of my UI changes~
[x] ~I translated all the newly inserted strings~

Motivation and Context

In many module definitions we use the following setting:
@ngModule({
...
schemas: [CUSTOM_ELEMENTS_SCHEMA]
...
)}

(https://angular.io/api/core/CUSTOM_ELEMENTS_SCHEMA)
:information_source: This setting has harmful effects as we might not detect bugs in the template (see examples below and screenshot).
Description

The setting mentioned above allows e.g. the following html without code-error being a valid selector for an angular component:
<code-error>some random text</code-error>

This setting causes a couple of issues:

When a component from another module is not imported, no error is raised by angular, but an empty html tag is rendered (see screenshot below for an example)
No wrong inputs/outputs are recognized (e.g. if the component does not have an input)

Steps for Testing

When allowing custom schemas (current state):

Check out the current version of develop
Comment out the ArtemisResultsModule import in code-editor.module.ts
Load the code-editor in the client => the result will not be shown as angular rendered an empty html tag for the jhi-updating-result

When NOT allowing custom schemas (new state):

Check out this branch
Comment out the ArtemisResultsModule import in code-editor.module.ts
When trying to access the client, an error will be shown: Uncaught Error: Template parse errors: Can't bind to 'exerciseType' since it isn't a known property of 'jhi-updating-result' (This is the expected result from angular)

Screenshots

Current state of develop when a component import is missing:

CUSTOM_ELEMENTS_SCHEMA comes from the jhipster template. I don't know why they actually use it and what it is good for.
From my side, we can remove CUSTOM_ELEMENTS_SCHEMA if it improves our compile and build process and if we can detect more errors.
We might even report this to the jhipster developers and discuss why they use it.

@thilo-behnke Did you remove CUSTOM_ELEMENTS_SCHEMA from all modules in this PR?

@thilo-behnke Did you remove CUSTOM_ELEMENTS_SCHEMA from all modules in this PR?

Yes, I removed it from all modules.

I had to make a small css fix, this shouldn't break the build - ready for review.


useCurrent:false does not affects viewMode:'months','years'

With useCurrent set to false it is expected to have nothing pre-selected/highlighted in any mode.
But this is not the case in 4.7.14.
jsfiddle: http://jsfiddle.net/0Ltv25o8/511/

Please check the development branch.

Seems done in dev. Thanks.


fix brew edit

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[ ] Have you added an explanation of what your changes do and why you'd like us to include them?
[ ] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?
[ ] Have you successfully run brew man locally and committed any changes?

Closes https://github.com/Homebrew/brew/issues/8876

This feels like it should also have the brew create messaging you mentioned before.

Thanks again @hyuraku, you rock!


Iron out issues with Release Please

Release Please doesn't seem to work consistently. It also defaulted to releasing 1.0.0.

It seems like others have this issue too:
https://github.com/googleapis/release-please/issues/2028
Might have to migrate.

Replaced it with release-it and added a workflow that can be dispatched for stable and rc releases.


Retina sprite mixin loads an incorrect variable

Within the _sprite.scss the @mixin retina-sprite mixin adds the wrong variable within the retina mixin, it adds
@media (-webkit-min-device-pixel-ratio: 2),
(min-resolution: 192dpi) {
@include sprite-image($retina-sprite);
@include sprite-background-size($normal-sprite);
}
rather it should be
@media (-webkit-min-device-pixel-ratio: 2),
(min-resolution: 192dpi) {
@include sprite-image($retina-sprite);
@include sprite-background-size($retina-sprite);
}
I've also attached an image of the full mixin

Nope, we want the retina spritesheet to be the same pixel size as the normal spritesheet. To clear up the confusion, I will re-iterate how retina spritesheets work.
 However, when we go to a retina laptop, there are more pixels in the monitor (i.e. higher pixel density). As a result, images with a low pixel density need to spread out across the same distance but don't have the same pixel values defined for the more refined values (e.g. there is a x=1px value and a x=2px value but no x=1.5px value). This is the reason for granularity in non-retina images on retina displays.
To solve this, we create a 2x larger spritesheet (e.g. we would define x=2px, x=4px and x=3px). Then, we condense it down to the same size as the 1x spritesheet -- effectively halving all the values. This winds up defining that 1.5px value.
The way we perform this in CSS is to use background-size to adjust the size of the entire spritesheet.


/show command hides keyboard, /hide command opens it

After /show command nothing happens if the keyboard is closed.

After /hide command keyboard opens

Thank you for the detailed description.
1.After /hide it is expected to open the keyboard for entering commands. I think it is more convenient for the user to use reply buttons. I added the option to hide reply buttons to be able to control the bot only with commands.
2.After entering a command /show or /hide there is no check if the keyboard is hidden or open.
Do you think it is necessary to add such a check?

@mkangoo Hm, can we consider removing these commands entirely?

Their current behaviour is really strange - I didn't even expect the /hide command to open something
Native tg buttons (menu bar on the left, inline keyboard button on the right) look like more native way to do what /show and /hide commands do + the user needs even more clicks to invoke this commands than get the desired result using native buttons.

@Ilanaya I agree with you.  I think it needs to be fixed


Add COVID19-Databode

Novel Covd tracker for all countries with simple maps and choroplet

Add COVID19-Databode

Very cool, you could try using the flags of each country instead of using the same globe icon in the list!


Sample exposure when holdings value is zero

Description

When the holdings value is zero, exposure was not being updated and as a result, the chart does showed invalid exposure values.

Related Issue

Closes #6524
Motivation and Context

Requires Documentation Change

How Has This Been Tested?

Unit tests, manual algorithm runs.
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] Refactor (non-breaking change which improves implementation)
[ ] Performance (non-breaking change which improves performance. Please add associated performance test and results)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Non-functional change (xml comments/documentation/etc)

Checklist:

[x] My code follows the code style of this project.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.
[x] My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>

Please make the exposure plot match the actual exposure. If sampling exposure on a minute timeframe, what would it look like? IMHO - Square wave, not triangle.
Potentially something like:

if longHoldings == 0:
SampleExposureHelper(PositionSide.Long, time**.Add(-1 tick),** previousPortfolioValue, previousLongHoldings);
SampleExposureHelper(PositionSide.Long, time, currentPortfolioValue, longHoldings);
if shortHoldings == 0:
SampleExposureHelper(PositionSide.Long, time**.Add(-1 tick),** previousPortfolioValue, previousShortHoldings);
SampleExposureHelper(PositionSide.Short, time, currentPortfolioValue, shortHoldings);

Moved to a new issue as the proposal was not ideal. Better to refactor for online, event-based exposure calculations
https://github.com/QuantConnect/Lean/issues/7034


samples: subsys: usb: mass: sample.usb_device_next.mass_flash_fatfs fails

Describe the bug
The samples/subsys/usb/mass/sample.usb_device_next.mass_flash_fatfs fails
Observed for:

nrf52840dk_nrf52840
nrf5340dk_nrf5340_cpuapp

To Reproduce
Steps to reproduce the behavior:

have nrf52840dk_nrf52840 connected
go to your zephyr dir
call ./scripts/twister -T samples/subsys/usb/mass -p nrf52840dk_nrf52840 --device-testing --device-serial /dev/ttyACM0 -v --inline-logs
See console output with error

Expected behavior
Valid console output
Impact
Not clear
Logs and console output
[2023-02-27T01:21:38.236Z] ERROR   - *** Booting Zephyr OS build zephyr-v3.3.0-472-gb2512d2f534e ***
[2023-02-27T01:21:38.236Z] Area 0 at 0x0 on mx25r6435f@0 for 131072 bytes
[2023-02-27T01:21:38.236Z] [00:00:00.380,676] <err> os: ***** MPU FAULT *****
[2023-02-27T01:21:38.236Z] [00:00:00.380,706] <err> os:   Data Access Violation
[2023-02-27T01:21:38.236Z] [00:00:00.380,706] <err> os:   MMFAR Address: 0x200044bc
[2023-02-27T01:21:38.236Z] [00:00:00.380,737] <err> os: r0/a1:  0x20004550  r1/a2:  0x0000000e  r2/a3:  0x00000000
[2023-02-27T01:21:38.236Z] [00:00:00.380,737] <err> os: r3/a4:  0x2000450c r12/ip:  0x00000800 r14/lr:  0x00001cf9
[2023-02-27T01:21:38.236Z] [00:00:00.380,767] <err> os:  xpsr:  0x61000000
[2023-02-27T01:21:38.236Z] [00:00:00.380,767] <err> os: Faulting instruction address (r15/pc): 0x00000a10
[2023-02-27T01:21:38.236Z] [00:00:00.380,798] <err> os: >>> ZEPHYR FATAL ERROR 19: Unknown error on CPU 0
[2023-02-27T01:21:38.236Z] [00:00:00.380,828] <err> os: Current thread: 0x20000bd0 (unknown)
[2023-02-27T01:21:38.236Z] [00:00:01.585,632] <err> os: Halting system

Environment (please complete the following information):

OS: Ubuntu 20.04.1 LTS
Toolchain Zephyr SDK 0.15.2
Commit SHA or Version used:  zephyr-v3.3.0-472-gb2512d2f534e

This seems to be related to main stack size. Increasing MAIN_STACK_SIZE to 1137 or more (zephyr commit 865ee855d11f76c764356a6fe9643abae58b8f20) results in sample working fine. I have to check if it is a stack overflow issue or something happens to be writing out of bounds.

When I increased stack and enabled stack initialization, the last stack write seems to be at 1144 bytes from top. Therefore 1024 bytes long stack is definitely too small. Peak stack usage is in cbprintf functions called from logger functions.


Issues-619 Bump asciidoctor-emoji version to 0.5.0

Closes/Fixes/Resolves #619

Description:
Bumping the asciidoctor-emoji version to 0.5.0 fixes the loading emoji issue.

@barboras7 Please take a look.


More graphics-related tweaks

I assume it should be able to activate some special tweaks directed to specific version type you choose like:

Clouds height should be at Y:128 on some of versions
Fog start/end position related to render distance (take attention on fog mechanics up to release 1.6.4, it's just like on Minecraft Legacy Console Edition)
Old villages type
Old tallgrass shader type (more dark-colored)
Old lighting mechanics at all and specifically at leaves (it should be somewhere darker, somewhere lighter)

Well, this mod is mostly focused on world generation and stuff like resource packs and Nostalgic Tweaks can already do most of this stuff. As for old villages, someone already made a datapack for that and it has been updated for 1.21: https://www.planetminecraft.com/data-pack/classic-villages/


Updating broker/Interoperator docker image versions:0.13.0

Updating broker/Interoperator docker image versions:0.13.0

Pull Request Test Coverage Report for Build 5208

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.007%) to 89.153%

Files with Coverage Reduction
New Missed Lines
%

broker/data-access-layer/cf/src/TokenIssuer.js
1
98.55%

Totals

Change from base Build 5206:
-0.007%

Covered Lines:
9446

Relevant Lines:
10224

💛  - Coveralls

Closing since base docker images are updated since


[dif/edn] Allow seed_material to be NULL for dif_edn_instantiate()

The documentation of dif_edn_instantiate() specifies that the
seed_material argument can be NULL, in which case CSRNG will use a
zero vector instead.  Prior to this commit, dif_edn_instantiate()
would return kDifBadArg in this case, however.
This commit fixes that by passing the NULL pointer for seed_material
on to csrng_send_app_cmd(), which in this case will correctly program
the CSRNG with a seed of length zero.

Thanks @engdoreis, I have implemented your feedback


chore(build): document dynamic dependencies

Add PLATFORM.moduleName() around aurelia-framework.
Also reviewed the loading path so that no promise goes unobserved. Previously starting would resolve too early because several calls were not properly chained in 3 or 4 places.
Although the priority for that refactoring was clarity and correctness, the resulting minified commonjs distribution is 6% smaller.
See aurelia/pal#21

@niieani I added the changes you needed for the starting Promise on top of my previous PR.

TODO: One more thing we should add is expose the startingPromise under  PLATFORM.global  so that plugins can hook it without having access to the loader/module interface.

I'm not sure I understand.
Plugins configure() run during startup. Your use case would be a plugin that wants to do something after its application has completly started?
They can already use Aurelia.start() for that.
Note that this method has a bug as well: the promise returned when called a second time (e.g. from your plugin) resolves too early. I plan to submit a PR for that as well.
starting is also easy to consume globally anyway: import { starting } from "aurelia-bootstrapper". (except if you're the first to do that you launch the startup process...)
PLATFORM.global doesn't seem a good location to put anything. It's window, i.e. global namespace pollution and can be overwritten by anything.

Sorry, I meant external "plugins", like the ones for testing (e.g. protractor), not Aurelia plugins. Yes, I'm aware global is the same as window. The idea is that an external module has to be able to access that Promise. If it's not aware of the module loader (and we do not want it to be), the Promise has to be exposed somewhere where it would be accessible globally. Therefore it is not possible to consume it with import { starting } from "aurelia-bootstrapper" outside of the bundler context (e.g. from the debugger console in the browser).

I might remember wrong but I think theres an event fired when it should be composed?

@stoffeastrom

I might remember wrong but I think theres an event fired when it should be composed?

There is one, although I don't think it indicates which app has loaded, so is a bit harder to use in a general context if you want to support more than one Aurelia app starting up in the same window.
More than one app is not a common scenario, though.
@niieani I still don't feel good about polluting the global scope. You could hold the same argument for everything: "I would like to have access to the Aurelia app/the loader/the DI".
If you need to debug from the browser console, you can use webpack.NamedModulesPlugin and all modules will have friendly names, which should enable you to easily request "aurelia-bootstrapper" from the console.

@jods4 it's not about debugging. It's about having programmatic information that the app has bootstrapped. I don't think it's the same as having access to app/loader/DI in the global context, because you only use those from within the app. This is a different case. We want to be able to know that Aurelia is ready, without having to fallback to any hacks.

you can use webpack.NamedModulesPlugin (...)

No, that would make this a webpack-specific solution, possible only with a specific set of plugins. Not portable, not good, IMO.
I wouldn't feel comfortable with running different code for e2e tests, as e2e tests are supposed to run on the same code as is being run in production. If we don't want to expose anything globally, another solution might be to emit a custom event on window, signalling that the Aurelia app has bootstrapped. Ultimately, the end-goal is the same, and the use similar (global event vs global variable).
@EisenbergEffect thoughts on the best solution?

@niieani  like aurelia-started?
https://github.com/aurelia/framework/blob/master/src/aurelia.js#L89

@jods4 sure, I was pretty sure we had something like this. I wonder why we don't use it in the protractor plugin (I'm not the original author, I've only moved the files from aurelia-tools where it was located previously). Is that event used anywhere, or is it more like public API for external tool use?

It was originally used in the protractor plugin, I think.

Good job everyone! I think this version is much cleaner than the previous.

@jods4 the problem with the event is that it happens once, and if we happen to start listening for the event too late, we have no way of knowing whether Aurelia has started or not. This is my working theory on why protractor-plugin has stopped working without a reason, i.e. the new stack is so fast, that the plugin starts listening to the event too late, when Aurelia is already composed, and hence no e2e tests ever get run. A global would make it possible to know if Aurelia is ready, without external tooling having to race Aurelia with its loading time, just to be able to catch one of those aurelia-started or aurelia-composed events.
An alternative to a global would be an attribute on the body/component that is being managed by Aurelia, like <body aurelia-started aurelia-composed>. We could then simply check if any elements contain [aurelia-composed] attribute, and run the rest of the code synchronously or asynchronously after waiting for the callback from the event.
Unless there's a better way, I'm all ears.

@niieani Talk to me in the chat, because I'm not familiar with how the protractor plugin works.

https://github.com/aurelia/protractor-plugin/pull/4 seems to have fixed the race condition, however I still feel some other indication of a successful start/composition would be a good improvement.

@niieani That fix seems very hacky. Why don't you do the same thing as for the router?
https://github.com/aurelia/protractor-plugin/blob/2802216a0e82e8f0b873f1a9e2114b57ea875ca9/index.js#L39
If [aurelia-app] has an aurelia property you can do .aurelia.start(...).
If it doesn't then it has not loaded yet and you can wait for the event.

@jods4 Indeed, it could. I'll try that idea. In fact, this is not my code, I just separated it into it's own repo, so I haven't gone deep enough.


[DOC] More detail for slices parameter of reindex API

What do you want to do?

[ ] Request a change to existing documentation
[ ] Add new documentation
[ ] Report a technical problem with the documentation
[x] Other

Tell us about your request.
Add more detail about slices parameter of reindex API
Setting slices to auto will let OpenSearch choose the number of slices to use. This setting will use one slice per shard, up to a certain limit(which is 20). If there are multiple sources, it will choose the number of slices based on the index or backing index with the smallest number of shards.
https://opensearch.org/docs/latest/api-reference/document-apis/reindex/#request-body
What other resources are available? Provide links to related issues, POCs, steps for testing, etc.

Reassigning to Aria, since she has taken over a lot of the index management doc.


HIP 95: Self-Onboard Hotspots After Maker Exit

HIP 95: Self-Onboard Hotspots After Maker Exit

Author(s): @shawaj, @Sophi, @ke6jjj, @ChewingGlass
Start Date: 2023-07-15
Category: Economic, Technical
Original HIP PR: #744
Tracking Issue: #775
Vote Requirements: veHNT holders

Summary
There are three types of hotspots available when manufacturers leave the network (regardless of whether updates and support are taken over by another business):

Onboarded hotspots that have had location asserted.
Onboarded hotspots that have not had their locations asserted.
Un-onboarded hotspots in customer or reseller possession.

The onboarding fee is collected as a part of the hotspot price by the manufacturer, but the onboarding and assert fees are not collected from the maker-wallet when the hotspot is shipped, but are delayed and collected when the hotspot is onboarded by the user. This allows for the manufacturer to sell a hotspot and not have DC available to pay for the onboarding.
This HIP proposes a mechanism to improve the onboarding experience for hotspot users whose makers have left the network either through bankruptcy, business closure, failure for compliance, involuntary loss of staking key, the former business being taken over by a new business owner or any other reason. Currently, if a maker leaves the network and they have run out of onboarding DC credits, users are left with only cumbersome or risky ways to onboard their devices to the network. This proposal seeks to change this in a way that lets users onboard their devices in a self-service manner if their hotspot maker has left the ecosystem.
This proposal excludes data-only hotspots as their owners can already onboard using their own wallet.
Rendered View
https://github.com/helium/HIP/blob/main/0095-self-onboard-hotspots-after-maker-exit.md

@shawaj @Sophi @ke6jjj Now that users can self onboard and select for the Maker or their own wallet to pay for the onboard is there any need for this HIP to go forward?
Other than maybe something for the processes for the MCC or Foundation to follow to move a maker between the status of Good/Suspend Onboarding/Flagging as Defunct/Maker wallet closed.


Example not complie

Got error
no matching function for call to 'ArduinoJson::JsonObject::printTo(char [200])'

did you install arduio json library?

Upgrade ArduinoJson and it works thank you,


chore(store-sync): add benchmarks to store-sync

Uses Vitest benchmarks to find bottlenecks in the sync stack and compare the different storage adapter implementations. Inspired by how Viem benchmarks itself against Ethers.
Currently it compares the time taken to sync logs between the RECS, SQLite, Zustand storage adapter.

If I remove the logs (console. and debug), Zustand is ~9x faster than RECS:

Compared to the regular codebase where the RECS is timed as 3x faster than Zustand

It seems logging has a big impact on the benchmarks. If I remove console. and debug, Zustand is ~9x faster than

Can you tell if it's specifically debug or console.log adding to the processing time? or are they both doing it equally?
I've been looking to swap debug for something else as it's a bit heavy and we only use it for a handful of its features, of which it has some trade-offs that I don't love. Curious if this is a good excuse to swap it for something else.

Can you tell if it's specifically debug or console.log adding to the processing time? or are they both doing it equally?

It seems like a specific console.log that prints unknown tables:
https://github.com/latticexyz/mud/blob/main/packages/store-sync/src/zustand/createStorageAdapter.ts#L33
I'm not even sure why that would be running in these benchmarks 🤔

It seems like a specific console.log that prints unknown tables: https://github.com/latticexyz/mud/blob/main/packages/store-sync/src/zustand/createStorageAdapter.ts#L33
I'm not even sure why that would be running in these benchmarks 🤔

Oh interesting! I think that log line may have slipped in accidentally. So feel free to just delete it (maybe in a separate PR?)

@holic interesting results! require more in-depth benchmarks though


CoreData throws exception when withdrawing and trying to log in again

Describe the bug
When withdrawing from the study and attempting to log in again, Core Data throws an exception and the app crashes.
CoreData: error: Illegal attempt to save to a file that was never opened. "This NSPersistentStoreCoordinator has no persistent stores (unknown)
To Reproduce
Steps to reproduce the behavior:

Log in to CardinalKit
Choose "Withdraw from Study" on the "Profile" tab and confirm your withdrawal on the following screen.
Once returns to the login screen, choose "Login Existing User" and log in.

Expected behavior
The app should not crash.
Screenshots
N/A
Smartphone (please complete the following information):

Device: Simulator
OS: iOS 15.5

Additional context
This does not occur if the app is deleted and reinstalled after withdrawing.

This issue appears to be originating from CKCareKitManager.shared.wipe() which is called upon opting to withdraw.


Using react-hook-form Controller with file type input

Great job with this awesome library! Unfortunately, I haven't been able to get it to work with a FileInput. I'm using Controller from react-hook-form and useRemixForm to handle the rest. The problem I'm facing is that whenever I submit the form, the value of the "avatar" field is always an empty object. Interestingly, on the client side, I've set up a watcher for the "avatar" field, and it is not empty. Do you have any ideas on what might be causing this issue?
Relevant code:
<Controller
    control={control}
    name="avatar"
    render={({ field: { onChange } }) => (
      <FileInput
        w="100%"
        size="md"
        icon={<IconPhotoUp />}
        label="Your Photo"
        placeholder="Upload your profile photo"
        onChange={onChange}
        accept="image/png,image/jpeg,image/jpg,image/webp"
      />
    )}
  />

This is my squema
const schema = zod.object({
  avatar: zod.any() as zod.ZodType<File>,
  firstName: zod.string().optional(),
  lastName: zod.string().optional(),
  email: zod.string().email({ message: "Invalid email address" }),
  role: zod.string().optional(),
  country: zod.string().optional(),
  timezone: zod.string().optional(),
  username: zod.string().optional()
});
type FormData = zod.infer<typeof schema>;
const resolver = zodResolver(schema);

//on action

const { errors: formErrors, data: formData, receivedValues } = await getValidatedFormData<FormData>(
    request,
    resolver
);

Hello! Thank you so much for the support, I think the issue you are facing is with the fact how Remix handles file uploads, check this part of the documentation:
https://remix.run/docs/en/1.17.1/utils/parse-multipart-form-data
The package tries to get all the data from the passed formData but it natively doesn't handle file uploads and I am waiting for the API to become stable to actually add it to the package, what you can do is try getting the data by hand and then passing it into validateFormData, I will in any case investigate this and add a readme update to help clear this up

  // You get the parsed file here
  const formData = await unstable_parseMultipartFormData(request);
  // Then you validate
  const { errors, data } =
    await validateFormData<FormData>(formData, resolver);
  if (errors) {
    return json(errors);
  }
  // Do something with the data
};

Do let me know if this works. Currently sick but I am planning to look into this further when I am feeling a bit better

  // You get the parsed file here
  const formData = await unstable_parseMultipartFormData(request);
  // Then you validate
  const { errors, data } =
    await validateFormData<FormData>(formData, resolver);
  if (errors) {
    return json(errors);
  }
  // Do something with the data
};

Do let me know if this works. Currently sick but I am planning to look into this further when I am feeling a bit better

The code you provided is still missing the uploadHandler. Remix provides two utilities to handle this: unstable_createFileUploadHandler and unstable_createMemoryUploadHandler. It is our responsibility to decide which one fits the use case better. However, we can always build our custom uploadHandler, which is what I ended up doing in my case since I'm using Supabase buckets for storage.
Here's an example of a custom uploadHandler implementation:
`
const uploadHandler = async (part: UploadHandlerPart): Promise =>
new Promise(async (resolve, reject) => {
try {
// Handle the file here
} catch (error) {
reject(error);
}
});
const formData = await unstable_parseMultipartFormData(request, uploadHandler);
`

@eovandodev yes that is right, you need that as well, I have a project where I upload to supabase buckets as well and what I do is use the uploadHandler to upload it and return a url as the form value and then validate it as a string on the BE but what you're doing is right

will be closing this issue for now, file upload handling will be tacked as soon as the API in remix is stabilized

will be closing this issue for now, file upload handling will be tacked as soon as the API in remix is stabilized

@AlemTuzlak  Thanks for the assistance!

Hi
Thanks for your amazing work on this very useful library!
I've been trying to upload files too using the solution described above. I met an issue because I'm using the onValid handler which is supposed to submit the form at the end:
const submit = useSubmit();

const form = useRemixForm<Output<typeof schema>>({
  submitHandlers: {
    onValid: (data) => {
      // ...

      const formData = createFormData(data);

      submit(formData, { method: "post", encType: "multipart/form-data" });
    },
  },
}

The problem I met is that the createFormData function returns a FormData object that contains a formData, that contains a JSON-stringified version of the data. Then unstable_parseMultipartFormData is not able to handle the data sent properly.
To fixed I had to turn the handler into this:
onValid: (data) => {
  // ...
  const formData = new FormData();
  for (const key in data) {
    formData.append(key, data[key]);
  }

  submit(formData, { method: "post", encType: "multipart/form-data" });
},

Does it make sense to you?

@oltodo @eovandodev the package now supports file uploads

Thanks @AlemTuzlak!
Could you provide an example on how to handle multipart forms with the v3 please?

The following code worked for me:
const formData = await unstable_parseMultipartFormData(
  request.clone(),
  unstable_createFileUploadHandler({
    directory: "/Users/nicolas/Code/AdventPrayers/public/assets/uploads",
  }),
);

const {
  errors,
  data,
  receivedValues: defaultValues,
} = await getValidatedFormData<Output<typeof schema>>(
  request,
  resolver(schema),
);

if (errors) {
  return json({ errors, defaultValues });
}

const picture = formData.get("picture") as NodeOnDiskFile | null;

const user = await createUser({
  ...data,
  picture: picture?.name || null,
});

@oltodo yes you have to use unstable_... Because of way how Remix works with files, but yes this is one of the ways you can do it, I'd recommend directly uploading it to a bucket if you're using one then returning the url from the handler


Add 10.13 to list of supported operating systems in the readme.

Yup - ran the script with no issues.


Improve IpAddr/SocketAddr serialization by avoiding Display

I'm opening a draft PR because I'd appreciate feedback, but this is definitely not done.
In some profiling, I've found that serializing Ipv4Addr to JSON is disproportionately slow. This (currently crude) patch is ~4x faster. I'm no expert on integer formatting, ~but I think I can improve the implementation by running cargo expand on itoa then pasting in the chunks I need. As far as I can tell, going through itoa's public interface is not faster than this code because LLVM keeps the itoa::Buffer in memory.~ Done. The algorithm is faster.
Is there any concern with not using std::fmt::Display? As far as I can tell from experimenting, there's basically no opportunity to make the standard library formatting code faster because it uses so much dynamic dispatch.

:facepalm: Yes
use std::net::Ipv4Addr;
fn main() {
    let mut buf = [0u8; 15];
    for _ in 0..10_000_000 {
        ser_ip(&mut buf, &Ipv4Addr::new(127, 10, 0, 1));
    }
}

#[inline(never)]
fn ser_ip(buf: &mut [u8], thing: &Ipv4Addr) {
    serde_json::to_writer(buf, thing).unwrap();
}

$ cargo build --release
$ perf stat -r10 ./target/release/scratch

I'm aware this is not a typical way to do benchmarking in the Rust community, but I find it is much more stable than using cargo bench or criterion, probably because it averages over a few process startups.

Would it be worth comparing against an unsafe version that removes the zero initialization of the whole buffer and the utf8 validation? My expectation from benchmarking itoa in the past is that those unnecessary things account for 30-40% of this code still. We can also consider removing all those bounds checks in format_u8 but that tends not to be measurable in a microbenchmark, since they're 100% correctly predicted, and the performance implication is only in polluting the branch predictor.

Would it be worth comparing against an unsafe version that removes the zero initialization of the whole buffer and the utf8 validation? My expectation from benchmarking itoa in the past is that those unnecessary things account for 30-40% of this code still.

In this case, it appears the utf8 validation is ~30% of the benchmark's runtime. Adding #[inline] to the function in the standard library causes it to be inlined but not cleaned up very much, but even so this takes off half the overhead. Still seems like a silly thing to be spending cycles and code size on.
As far as I can tell, leaving the buffer uninitialized doesn't help at all. But initializing it with b'.' instead of 0u8 and skipping over writing each b'.' knocks a few percent off the runtime. The annotated assembly from perf  suggests the initialization instructions are ~0.10% of total runtime. Maybe things look different in a real program but they can't be that much different. Maybe this will matter more for Ipv6 addresses.

We can also consider removing all those bounds checks in format_u8

As far as I can tell, there are no bounds checks emitted. It looks like LLVM correctly figures out that the buffer is large enough.
After these improvements, the big hog in the benchmark is calling serialize_str which is ~57% of runtime, and the time is spent in the JSON escaping loop and the memset calls that LLVM emits to write the string delimiters (which I've reported here. It would be nifty to skip over the escaping, but it's unclear to me if that's possible.

Thanks -- LGTM once tests pass.

I've made the tests pass; do we want to give the same treatment to SocketAddrV4 or the IpV6 types?


fix: canary pipeline greater than syntax

Details
This fixes a syntax mistake introduced by #1093
Motivation
Feature work
Pull request checklist

[n/a] Addresses an existing issue: Fixes #0000
[n/a] Added relevant unit test for your changes. (yarn test)
[n/a] Verified code coverage for the changes made. Check coverage report at: <rootDir>/test-results/unit/coverage
[x] Ran precheckin (yarn precheckin)
[ ] (after PR created) The Accessibility Checks (pull_request) check should fail. All other checks should pass.

Codecov Report

Merging #1097 (c99cdae) into main (6a10911) will not change coverage.
The diff coverage is n/a.

:exclamation: Current head c99cdae differs from pull request most recent head 78a809d. Consider uploading reports for the commit 78a809d to get more accurate results

@@           Coverage Diff           @@
##             main    #1097   +/-   ##
=======================================
  Coverage   89.65%   89.65%
=======================================
  Files          54       54
  Lines        1286     1286
  Branches      151      151
=======================================
  Hits         1153     1153
  Misses        133      133

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 6a10911...78a809d. Read the comment docs.


Fingerprint cannot be used

iPhone 6sp was downgraded to 13.6 and fingerprint cannot be used. Downgraded to 14.2, fingerprint can be used. Which version of IOS 13 can use fingerprint? Thanks!

Touch ID doesn't work on iOS 13 sadly


how to avoid sending user-agent header?

In unirest, when I don't specify user-agent header, it's just not sent. However superagent sends node-superagent/5.0.2.
.set('user-agent', undefined) fails with TypeError [ERR_HTTP_INVALID_HEADER_VALUE]: Invalid value "undefined" for header "user-agent"
.set('user-agent', '') sends { 'user-agent': '' }
.set('user-agent', null) sends { 'user-agent': 'null' }

@niftylettuce Not familiar with codebase much, but after digging a bit, it seems like user-agent is set here and here(for redirects). Do you suggest we remove those calls to resolve this issue?

Yes, I am completely OK with removing the user-agent added altogether.
Please submit a PR

.unset('User-Agent') would have worked

This should be in the docs so users know they must explicitly set a User Agent as some CDNs block requests without it


Remove unused parameter

Description

While working on https://github.com/youtube/vitess/pull/3078, I noticed that dbaParams was never used.  Should we remove it?

LGTM
The history on this is probably this: the connection must have used the dba privileges to kill queries. Now, it gets that from the dba pool.


Withdraw results in non-mandatory-script-verify-flag (Witness program hash mismatch). Unsent tx discarded

A user is reporting several failed attempts to withdraw funds after a force close. The failure always results in the error:
Error calling method Withdraw: RpcError{ code: Some(-1), message: \"Error broadcasting transaction: error-code: -26\\\\nerror message: \\\\nnon-mandatory-script-verify-flag (Witness program hash mismatch). Unsent tx discarded ...
after which the utxo's are marked reserved for a day or so. Once the utxo's are available again, the user repeats resulting in the same error. Node id for reference is: 02810d14934b1b41b52af4b6c118878a00e857cc4922442ea59e18b31906b09c67
A similar issue is also raised in https://github.com/Blockstream/green_android/issues/185 relating to the same circumstances and error.
I have requested the user provides a trace log the next time they attempt a withdraw and will attach them to this issue.

Here are the logs, the process starts at 2024-01-10T07:39:33.750Z and ends at 2024-01-10T07:39:36.591Z
com.satimoto-latest.txt

Here is a decode of the tx w/ the `Witness program hash mismatch:
bitcoin-cli decoderawtransaction<PHONE_NUMBER>01013db0eb77d3275977ab5e33adbb35361c40eb8971db957491a73c53727ab2b5e3030000000001000000023e3704000000000016001487e09361881dcb6897e3161ee602f62290ba8d812202000000000000225120c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b02483045022100eba3c7db03e7be73a932d39816f10be376a79fb3ac2b960617a3331c5212ef0802201aaee301beac012ccd413a3ea6dbcd8edbf1ae3c26ccfc2ab979e70c352fc19b0121020d0f6142c6ad7c190875838f7a57bcfdcceb6e7bcc253849d038a8e6d847f33313970c00
{
  "txid": "c61a315065ffb927e5464515e632c24c617f126a556afccae3cf890aaa338e53",
  "hash": "e36191ca8f6f2313f50325e1e3a554fd6432f2a2e0dbcb941fe9b4ad283d3100",
  "version": 2,
  "size": 235,
  "vsize": 153,
  "weight": 610,
  "locktime": 825107,
  "vin": [
    {
      "txid": "e3b5b27a72533ca7917495db7189eb401c3635bbad335eab775927d377ebb03d",
      "vout": 3,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "3045022100eba3c7db03e7be73a932d39816f10be376a79fb3ac2b960617a3331c5212ef0802201aaee301beac012ccd413a3ea6dbcd8edbf1ae3c26ccfc2ab979e70c352fc19b01",
        "020d0f6142c6ad7c190875838f7a57bcfdcceb6e7bcc253849d038a8e6d847f333"
      ],
      "sequence": 1
    }
  ],
  "vout": [
    {
      "value": 0.00276286,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 87e09361881dcb6897e3161ee602f62290ba8d81",
        "desc": "addr(bc1qslsfxcvgrh9k39lrzc0wvqhky2gt4rvpwxmeap)#5kjmxkdg",
        "hex": "001487e09361881dcb6897e3161ee602f62290ba8d81",
        "address": "bc1qslsfxcvgrh9k39lrzc0wvqhky2gt4rvpwxmeap",
        "type": "witness_v0_keyhash"
      }
    },
    {
      "value": 0.00000546,
      "n": 1,
      "scriptPubKey": {
        "asm": "1 c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b",
        "desc": "rawtr(c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b)#nj32wcvg",
        "hex": "5120c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b",
        "address": "bc1pc7fu67whtzcy5068rvvztdw5rh3wkcfgn6tv65kx7xs7wumwy6ds35es75",
        "type": "witness_v1_taproot"
      }
    }
  ]
}

@ksedgwic I'm not quite up to speed on the error that is being reported here. Could this somehow be related to our use of VLS, or is this related to the data we feed into VLS?

Log Excerpt and Analysis

The SignWithdrawal Logging
2024-01-10T07:39:35.930Z [DEBUG]  BreezSDK: [DEBUG] SignWithdrawal(SignWithdrawal { utxos: Array([Utxo { txid: e3b5b27a72533ca7917495db7189eb401c3635bbad335eab775927d377ebb03d, outnum: 3, amount: 282008, keyindex: 0, is_p2sh: false, script: 00200549ae6098a014f9a0ed7ada3f1f1341aa3bd73e41470530cfafee0cea401685, close_info: Some(CloseInfo { channel_id: 2, peer_id:<PHONE_NUMBER>8398d8cb31e67921ffd4d4cfb10b42dc72529a45dba6f105adfb83d4, commitment_point: None, is_anchors: true, csv: 1 }), is_in_coinbase: false }]), psbt: WithSize(StreamedPSBT { psbt: PartiallySignedTransaction { unsigned_tx: Transaction { version: 2, lock_time: PackedLockTime(825107), input: [TxIn { previous_output: OutPoint { txid: e3b5b27a72533ca7917495db7189eb401c3635bbad335eab775927d377ebb03d, vout: 3 }, script_sig: Script(), sequence: Sequence(1), witness: Witness { content: [], witness_elements: 0, last: 0, second_to_last: 0 } }], output: [TxOut { value: 276286, script_pubkey: Script(OP_0 OP_PUSHBYTES_20 87e09361881dcb6897e3161ee602f62290ba8d81) }, TxOut { value: 546, script_pubkey: Script(OP_PUSHNUM_1 OP_PUSHBYTES_32 c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b) }] }, version: 0, xpub: {}, proprietary: {}, unknown: {}, inputs: [Input { non_witness_utxo: None, witness_utxo: Some(TxOut { value: 282008, script_pubkey: Script(OP_0 OP_PUSHBYTES_32 0549ae6098a014f9a0ed7ada3f1f1341aa3bd73e41470530cfafee0cea401685) }), partial_sigs: {}, sighash_type: None, redeem_script: None, witness_script: None, bip32_derivation: {}, final_script_sig: None, final_script_witness: None, ripemd160_preimages: {}, sha256_preimages: {}, hash160_preimages: {}, hash256_preimages: {}, tap_key_sig: None, tap_script_sigs: {}, tap_scripts: {}, tap_key_origins: {}, tap_internal_key: None, tap_merkle_root: None, proprietary: {}, unknown: {} }], outputs: [Output { redeem_script: None, witness_script: None, bip32_derivation: {}, tap_internal_key: None, tap_tree: None, tap_key_origins: {}, proprietary: {ProprietaryKey { prefix: [108, 105, 103, 104, 116, 110, 105, 110, 103], subtype: 4, key: [] }: [0, 1]}, unknown: {} }, Output { redeem_script: None, witness_script: None, bip32_derivation: {}, tap_internal_key: None, tap_tree: None, tap_key_origins: {XOnlyPublicKey(d4b2368a126fd976c4ef9bc3800f62b10c47ec0bdb8f62ce97f3581be49af0f33c47e38e007440674c149fcfdd0fc3e91460b05c2319fbdf4f8507337bc1ce3c): ([], (5506e7e7, m/5))}, proprietary: {}, unknown: {} }] }, segwit_flags: [true] }) })
2024-01-10T07:39:35.930Z [DEBUG]  BreezSDK: [TRACE] poll_complete
2024-01-10T07:39:35.931Z [DEBUG]  BreezSDK: [DEBUG] SignWithdrawal psbt StreamedPSBT {
    psbt: PartiallySignedTransaction {
        unsigned_tx: Transaction {
            version: 2,
            lock_time: PackedLockTime(
                825107,
            ),
            input: [
                TxIn {
                    previous_output: OutPoint {
                        txid: e3b5b27a72533ca7917495db7189eb401c3635bbad335eab775927d377ebb03d,
                        vout: 3,
                    },
                    script_sig: Script(),
                    sequence: Sequence(
                        1,
                    ),
                    witness: Witness {
                        content: [],
                        witness_elements: 0,
                        last: 0,
                        second_to_last: 0,
                    },
                },
            ],
            output: [
                TxOut {
                    value: 276286,
                    script_pubkey: Script(OP_0 OP_PUSHBYTES_20 87e09361881dcb6897e3161ee602f62290ba8d81),
                },
                TxOut {
                    value: 546,
                    script_pubkey: Script(OP_PUSHNUM_1 OP_PUSHBYTES_32 c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b),
                },
            ],
        },
        version: 0,
        xpub: {},
        proprietary: {},
        unknown: {},
        inputs: [
            Input {
                non_witness_utxo: None,
                witness_utxo: Some(
                    TxOut {
                        value: 282008,
                        script_pubkey: Script(OP_0 OP_PUSHBYTES_32 0549ae6098a014f9a0ed7ada3f1f1341aa3bd73e41470530cfafee0cea401685),
                    },
                ),
                partial_sigs: {},
                sighash_type: None,
                redeem_script: None,
                witness_script: None,
                bip32_derivation: {},
                final_script_sig: None,
                final_script_witness: None,
                ripemd160_preimages: {},
                sha256_preimages: {},
                hash160_preimages: {},
                hash256_preimages: {},
                tap_key_sig: None,
                tap_script_sigs: {},
                tap_scripts: {},
                tap_key_origins: {},
                tap_internal_key: None,
                tap_merkle_root: None,
                proprietary: {},
                unknown: {},
            },
        ],
        outputs: [
            Output {
                redeem_script: None,
                witness_script: None,
                bip32_derivation: {},
                tap_internal_key: None,
                tap_tree: None,
                tap_key_origins: {},
                proprietary: {
                    ProprietaryKey {
                        prefix: [
                            108,
                            105,
                            103,
                            104,
                            116,
                            110,
                            105,
                            110,
                            103,
                        ],
                        subtype: 4,
                        key: [],
                    }: [
                        0,
                        1,
                    ],
                },
                unknown: {},
            },
            Output {
                redeem_script: None,
                witness_script: None,
                bip32_derivation: {},
                tap_internal_key: None,
                tap_tree: None,
                tap_key_origins: {
                    XOnlyPublicKey(
                        d4b2368a126fd976c4ef9bc3800f62b10c47ec0bdb8f62ce97f3581be49af0f33c47e38e007440674c149fcfdd0fc3e91460b05c2319fbdf4f8507337bc1ce3c,
                    ): (
                        [],
                        (
                            5506e7e7,
                            m/5,
                        ),
                    ),
                },
                proprietary: {},
                unknown: {},
            },
        ],
    },
    segwit_flags: [
        true,
    ],
}
2024-01-10T07:39:35.931Z [DEBUG]  BreezSDK: [TRACE] schedule_pending_open
2024-01-10T07:39:35.931Z [DEBUG]  BreezSDK: [TRACE] pop_frame;
2024-01-10T07:39:35.931Z [DEBUG]  BreezSDK: [DEBUG] "ipaths": [
    [
        0,
    ],
]
2024-01-10T07:39:35.931Z [DEBUG]  BreezSDK: [TRACE] -> pop_frame;
2024-01-10T07:39:35.931Z [DEBUG]  BreezSDK: [DEBUG] "opaths": [
    [],
    [
        5,
    ],
]
2024-01-10T07:39:35.931Z [DEBUG]  BreezSDK: [TRACE] <- pop_frame;
2024-01-10T07:39:35.931Z [DEBUG]  BreezSDK: [DEBUG] "tx.txid()": c61a315065ffb927e5464515e632c24c617f126a556afccae3cf890aaa338e53
2024-01-10T07:39:35.931Z [DEBUG]  BreezSDK: [TRACE] -- pop_frame;
2024-01-10T07:39:35.932Z [DEBUG]  BreezSDK: [TRACE] FramedWrite::flush;
2024-01-10T07:39:35.932Z [DEBUG]  BreezSDK: [DEBUG] "tx": Transaction {
    version: 2,
    lock_time: PackedLockTime(
        825107,
    ),
    input: [
        TxIn {
            previous_output: OutPoint {
                txid: e3b5b27a72533ca7917495db7189eb401c3635bbad335eab775927d377ebb03d,
                vout: 3,
            },
            script_sig: Script(),
            sequence: Sequence(
                1,
            ),
            witness: Witness {
                content: [],
                witness_elements: 0,
                last: 0,
                second_to_last: 0,
            },
        },
    ],
    output: [
        TxOut {
            value: 276286,
            script_pubkey: Script(OP_0 OP_PUSHBYTES_20 87e09361881dcb6897e3161ee602f62290ba8d81),
        },
        TxOut {
            value: 546,
            script_pubkey: Script(OP_PUSHNUM_1 OP_PUSHBYTES_32 c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b),
        },
    ],
}
2024-01-10T07:39:35.932Z [DEBUG]  BreezSDK: [TRACE] -> FramedWrite::flush;
2024-01-10T07:39:35.932Z [DEBUG]  BreezSDK: [DEBUG] "streamed.segwit_flags": [
    true,
]
2024-01-10T07:39:35.932Z [DEBUG]  BreezSDK: [TRACE] flushing buffer
2024-01-10T07:39:35.932Z [DEBUG]  BreezSDK: [TRACE] <- FramedWrite::flush;
2024-01-10T07:39:35.932Z [DEBUG]  BreezSDK: [DEBUG] "uniclosekeys": [
    Some(
        (
            SecretKey(
                #020d039934d80918,
            ),
            [
                [
                    2,
                    13,
                    15,
                    97,
                    66,
                    198,
                    173,
                    124,
                    25,
                    8,
                    117,
                    131,
                    143,
                    122,
                    87,
                    188,
                    253,
                    204,
                    235,
                    110,
                    123,
                    204,
                    37,
                    56,
                    73,
                    208,
                    56,
                    168,
                    230,
                    216,
                    71,
                    243,
                    51,
                ],
            ],
        ),
    ),
]
2024-01-10T07:39:35.932Z [DEBUG]  BreezSDK: [TRACE] -- FramedWrite::flush;
2024-01-10T07:39:35.933Z [DEBUG]  BreezSDK: [TRACE] try_reclaim_frame;
2024-01-10T07:39:35.933Z [DEBUG]  BreezSDK: [TRACE] -> try_reclaim_frame;
2024-01-10T07:39:35.933Z [DEBUG]  BreezSDK: [DEBUG] check_onchain_tx: txid: c61a315065ffb927e5464515e632c24c617f126a556afccae3cf890aaa338e53
2024-01-10T07:39:35.933Z [DEBUG]  BreezSDK: [TRACE] <- try_reclaim_frame;
2024-01-10T07:39:35.933Z [DEBUG]  BreezSDK: [DEBUG] weight_lower_bound: 611
2024-01-10T07:39:35.933Z [DEBUG]  BreezSDK: [TRACE] -- try_reclaim_frame;
2024-01-10T07:39:35.933Z [DEBUG]  BreezSDK: [TRACE] <- poll;
2024-01-10T07:39:35.933Z [DEBUG]  BreezSDK: [DEBUG] output 0 (276286) is unknown
2024-01-10T07:39:35.933Z [DEBUG]  BreezSDK: [TRACE] -- poll;
2024-01-10T07:39:35.934Z [DEBUG]  BreezSDK: [TRACE] <- Connection;
2024-01-10T07:39:35.934Z [DEBUG]  BreezSDK: [TRACE] -- Connection;
2024-01-10T07:39:35.934Z [DEBUG]  BreezSDK: [TRACE] release_capacity; size=101
2024-01-10T07:39:35.934Z [DEBUG]  BreezSDK: [DEBUG] output 1 (546) is to our wallet
2024-01-10T07:39:35.934Z [DEBUG]  BreezSDK: [TRACE] release_connection_capacity; size=101, connection in_flight_data=324
2024-01-10T07:39:35.934Z [DEBUG]  BreezSDK: [DEBUG] node-logs: DEBUG   plugin-gl-plugin-internal: Sending signer requests with 1 requests and 6 state entries
2024-01-10T07:39:35.934Z [DEBUG]  BreezSDK: [TRACE] release_capacity; size=123
2024-01-10T07:39:35.934Z [DEBUG]  BreezSDK: [TRACE] release_connection_capacity; size=123, connection in_flight_data=223
2024-01-10T07:39:35.934Z [DEBUG]  BreezSDK: [DEBUG] node-logs: DEBUG   plugin-gl-plugin-internal: Received event Ok(RpcCall(\"/greenlight.Node/RespondHsmRequest\")) from gl_plugin
2024-01-10T07:39:35.935Z [DEBUG]  BreezSDK: [TRACE] release_capacity; size=100
2024-01-10T07:39:35.935Z [DEBUG]  BreezSDK: [TRACE] release_connection_capacity; size=100, connection in_flight_data=100
2024-01-10T07:39:35.935Z [DEBUG]  BreezSDK: [DEBUG] node-logs: DEBUG   plugin-gl-plugin-internal: Response for request_id=1024, outstanding requests count=0
2024-01-10T07:39:35.937Z [DEBUG]  BreezSDK: [DEBUG] validate_onchain_tx failed:
2024-01-10T07:39:35.937Z [DEBUG]  BreezSDK: [DEBUG] "tx": Transaction {
    version: 2,
    lock_time: PackedLockTime(
        825107,
    ),
    input: [
        TxIn {
            previous_output: OutPoint {
                txid: e3b5b27a72533ca7917495db7189eb401c3635bbad335eab775927d377ebb03d,
                vout: 3,
            },
            script_sig: Script(),
            sequence: Sequence(
                1,
            ),
            witness: Witness {
                content: [],
                witness_elements: 0,
                last: 0,
                second_to_last: 0,
            },
        },
    ],
    output: [
        TxOut {
            value: 276286,
            script_pubkey: Script(OP_0 OP_PUSHBYTES_20 87e09361881dcb6897e3161ee602f62290ba8d81),
        },
        TxOut {
            value: 546,
            script_pubkey: Script(OP_PUSHNUM_1 OP_PUSHBYTES_32 c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b),
        },
    ],
}
2024-01-10T07:39:35.938Z [DEBUG]  BreezSDK: [DEBUG] "values_sat": [
    282008,
]
2024-01-10T07:39:35.938Z [DEBUG]  BreezSDK: [DEBUG] "opaths": [
    [],
    [
        5,
    ],
]
2024-01-10T07:39:35.938Z [DEBUG]  BreezSDK: [WARN] unapproved onchain Transaction { version: 2, lock_time: PackedLockTime(825107), input: [TxIn { previous_output: OutPoint { txid: e3b5b27a72533ca7917495db7189eb401c3635bbad335eab775927d377ebb03d, vout: 3 }, script_sig: Script(), sequence: Sequence(1), witness: Witness { content: [], witness_elements: 0, last: 0, second_to_last: 0 } }], output: [TxOut { value: 276286, script_pubkey: Script(OP_0 OP_PUSHBYTES_20 87e09361881dcb6897e3161ee602f62290ba8d81) }, TxOut { value: 546, script_pubkey: Script(OP_PUSHNUM_1 OP_PUSHBYTES_32 c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b) }] } [TxOut { value: 282008, script_pubkey: Script(OP_0 OP_PUSHBYTES_32 0549ae6098a014f9a0ed7ada3f1f1341aa3bd73e41470530cfafee0cea401685) }] [0]
2024-01-10T07:39:35.938Z [DEBUG]  BreezSDK: [INFO] approved onchain tx with unknown outputs
2024-01-10T07:39:35.939Z [DEBUG]  BreezSDK: [DEBUG] unchecked_sign_onchain_tx: txid: c61a315065ffb927e5464515e632c24c617f126a556afccae3cf890aaa338e53
2024-01-10T07:39:35.939Z [DEBUG]  BreezSDK: [DEBUG] SignWithdrawalReply { psbt: WithSize(PartiallySignedTransaction { unsigned_tx: Transaction { version: 2, lock_time: PackedLockTime(825107), input: [TxIn { previous_output: OutPoint { txid: e3b5b27a72533ca7917495db7189eb401c3635bbad335eab775927d377ebb03d, vout: 3 }, script_sig: Script(), sequence: Sequence(1), witness: Witness { content: [], witness_elements: 0, last: 0, second_to_last: 0 } }], output: [TxOut { value: 276286, script_pubkey: Script(OP_0 OP_PUSHBYTES_20 87e09361881dcb6897e3161ee602f62290ba8d81) }, TxOut { value: 546, script_pubkey: Script(OP_PUSHNUM_1 OP_PUSHBYTES_32 c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b) }] }, version: 0, xpub: {}, proprietary: {}, unknown: {}, inputs: [Input { non_witness_utxo: None, witness_utxo: Some(TxOut { value: 282008, script_pubkey: Script(OP_0 OP_PUSHBYTES_32 0549ae6098a014f9a0ed7ada3f1f1341aa3bd73e41470530cfafee0cea401685) }), partial_sigs: {}, sighash_type: None, redeem_script: None, witness_script: None, bip32_derivation: {}, final_script_sig: None, final_script_witness: Some(Witness { content: [72, 48, 69, 2, 33, 0, 235, 163, 199, 219, 3, 231, 190, 115, 169, 50, 211, 152, 22, 241, 11, 227, 118, 167, 159, 179, 172, 43, 150, 6, 23, 163, 51, 28, 82, 18, 239, 8, 2, 32, 26, 174, 227, 1, 190, 172, 1, 44, 205, 65, 58, 62, 166, 219, 205, 142, 219, 241, 174, 60, 38, 204, 252, 42, 185, 121, 231, 12, 53, 47, 193, 155, 1, 33, 2, 13, 15, 97, 66, 198, 173, 124, 25, 8, 117, 131, 143, 122, 87, 188, 253, 204, 235, 110, 123, 204, 37, 56, 73, 208, 56, 168, 230, 216, 71, 243, 51], witness_elements: 2, last: 73, second_to_last: 0 }), ripemd160_preimages: {}, sha256_preimages: {}, hash160_preimages: {}, hash256_preimages: {}, tap_key_sig: None, tap_script_sigs: {}, tap_scripts: {}, tap_key_origins: {}, tap_internal_key: None, tap_merkle_root: None, proprietary: {}, unknown: {} }], outputs: [Output { redeem_script: None, witness_script: None, bip32_derivation: {}, tap_internal_key: None, tap_tree: None, tap_key_origins: {}, proprietary: {ProprietaryKey { prefix: [108, 105, 103, 104, 116, 110, 105, 110, 103], subtype: 4, key: [] }: [0, 1]}, unknown: {} }, Output { redeem_script: None, witness_script: None, bip32_derivation: {}, tap_internal_key: None, tap_tree: None, tap_key_origins: {XOnlyPublicKey(d4b2368a126fd976c4ef9bc3800f62b10c47ec0bdb8f62ce97f3581be49af0f33c47e38e007440674c149fcfdd0fc3e91460b05c2319fbdf4f8507337bc1ce3c): ([], (5506e7e7, m/5))}, proprietary: {}, unknown: {} }] }) }
2024-01-10T07:39:35.940Z [DEBUG]  BreezSDK: [DEBUG] Serializing state changes to report to node
2024-01-10T07:39:35.941Z [DEBUG]  BreezSDK: [TRACE] Sending response 006b0000016270736274ff01007d02000000013db0eb77d3275977ab5e33adbb35361c40eb8971db957491a73c53727ab2b5e3030000000001000000023e3704000000000016001487e09361881dcb6897e3161ee602f62290ba8d812202000000000000225120c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b13970c000001012b984d0400000000002200200549ae6098a014f9a0ed7ada3f1f1341aa3bd73e41470530cfafee0cea40168501086c02483045022100eba3c7db03e7be73a932d39816f10be376a79fb3ac2b960617a3331c5212ef0802201aaee301beac012ccd413a3ea6dbcd8edbf1ae3c26ccfc2ab979e70c352fc19b0121020d0f6142c6ad7c190875838f7a57bcfdcceb6e7bcc253849d038a8e6d847f333000cfc096c696768746e696e6704020001002107f3f09ae41b58f397ce628fdb0bec470cb1620f80c39befc476d96f128a36b2d409005506e7e70500000000

The sendrawtx error:
2024-01-10T07:39:36.591Z [DEBUG]  BreezSDK: [DEBUG] node-logs: DEBUG   plugin-bcli: sendrawtx exit 26 (bitcoin-cli -rpcconnect=<IP_ADDRESS> -rpcport=8332 -rpcuser=... -stdinrpcpass sendrawtransaction<PHONE_NUMBER>01013db0eb77d3275977ab5e33adbb35361c40eb8971db957491a73c53727ab2b5e3030000000001000000023e3704000000000016001487e09361881dcb6897e3161ee602f62290ba8d812202000000000000225120c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b02483045022100eba3c7db03e7be73a932d39816f10be376a79fb3ac2b960617a3331c5212ef0802201aaee301beac012ccd413a3ea6dbcd8edbf1ae3c26ccfc2ab979e70c352fc19b0121020d0f6142c6ad7c190875838f7a57bcfdcceb6e7bcc253849d038a8e6d847f33313970c00) error code: -26\nerror message:\nnon-mandatory-script-verify-flag (Witness program hash mismatch)

Parent tx in block explorer:
https://mempool.space/tx/e3b5b27a72533ca7917495db7189eb401c3635bbad335eab775927d377ebb03d
The transaction decoded:
bitcoin@home5:~$ bitcoin-cli decoderawtransaction<PHONE_NUMBER>01013db0eb77d3275977ab5e33adbb35361c40eb8971db957491a73c53727ab2b5e3030000000001000000023e3704000000000016001487e09361881dcb6897e3161ee602f62290ba8d812202000000000000225120c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b02483045022100eba3c7db03e7be73a932d39816f10be376a79fb3ac2b960617a3331c5212ef0802201aaee301beac012ccd413a3ea6dbcd8edbf1ae3c26ccfc2ab979e70c352fc19b0121020d0f6142c6ad7c190875838f7a57bcfdcceb6e7bcc253849d038a8e6d847f33313970c00
{
  "txid": "c61a315065ffb927e5464515e632c24c617f126a556afccae3cf890aaa338e53",
  "hash": "e36191ca8f6f2313f50325e1e3a554fd6432f2a2e0dbcb941fe9b4ad283d3100",
  "version": 2,
  "size": 235,
  "vsize": 153,
  "weight": 610,
  "locktime": 825107,
  "vin": [
    {
      "txid": "e3b5b27a72533ca7917495db7189eb401c3635bbad335eab775927d377ebb03d",
      "vout": 3,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "3045022100eba3c7db03e7be73a932d39816f10be376a79fb3ac2b960617a3331c5212ef0802201aaee301beac012ccd413a3ea6dbcd8edbf1ae3c26ccfc2ab979e70c352fc19b01",
        "020d0f6142c6ad7c190875838f7a57bcfdcceb6e7bcc253849d038a8e6d847f333"
      ],
      "sequence": 1
    }
  ],
  "vout": [
    {
      "value": 0.00276286,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 87e09361881dcb6897e3161ee602f62290ba8d81",
        "desc": "addr(bc1qslsfxcvgrh9k39lrzc0wvqhky2gt4rvpwxmeap)#5kjmxkdg",
        "hex": "001487e09361881dcb6897e3161ee602f62290ba8d81",
        "address": "bc1qslsfxcvgrh9k39lrzc0wvqhky2gt4rvpwxmeap",
        "type": "witness_v0_keyhash"
      }
    },
    {
      "value": 0.00000546,
      "n": 1,
      "scriptPubKey": {
        "asm": "1 c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b",
        "desc": "rawtr(c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b)#nj32wcvg",
        "hex": "5120c793cd79d758b04a3f471b1825b5d41de2eb61289e96cd52c6f1a1e7736e269b",
        "address": "bc1pc7fu67whtzcy5068rvvztdw5rh3wkcfgn6tv65kx7xs7wumwy6ds35es75",
        "type": "witness_v1_taproot"
      }
    }
  ]
}

The witness script decoded:
bitcoin@home5:~$ bitcoin-cli decodescript 020d0f6142c6ad7c190875838f7a57bcfdcceb6e7bcc253849d038a8e6d847f333
{
  "asm": "3853 OP_NOP [error]",
  "desc": "raw(020d0f6142c6ad7c190875838f7a57bcfdcceb6e7bcc253849d038a8e6d847f333)#j7hk5lw4",
  "type": "nonstandard"
}

Analysis:

the parent looks like a commitment tx
the input in question looks like a to_remote output from the commitment:

the first two outputs  (vout 0 and 1)look like anchors
vout 2 looks like a to_local based on the redeem script used on it
the (failed) spend attempt has seq = 1 for vout 3

Based on https://github.com/lightning/bolts/blob/master/03-transactions.md#to_remote-output
the witness should be single element <remote_sig>, not a two element witness

Comparing two similar commitments
Comparing failed operation above (F) to similar successful instance (A):

A: https://mempool.space/tx/4f907fca9c7d670a1f6a38a99e4adc80dfc04bed26bfc0f34b23dacb65a3eea5
F: https://mempool.space/tx/e3b5b27a72533ca7917495db7189eb401c3635bbad335eab775927d377ebb03d

Observations:

both seem to be channel closes w/ anchors
why does mempool.space know that A was a "Channel close: ..."
while F was only "Multisig 2 of 2"?  maybe difference in
announcements?

The good channel's outputs are spent by:

A vout 2 is the to_remote:
<remotepubkey> OP_CHECKSIGVERIFY 1 OP_CHECKSEQUENCEVERIFY
https://mempool.space/tx/b357bc5f8f087211786be62c9b1d7bdf9e9b2cf33b74181c40a0bad7f08f5452#vin=5
A vout 3 is the to_local:
OP_IF <revocationpubkey> OP_ELSE to_self_delay OP_CHECKSEQUENCEVERIFY OP_DROP <local_delayedpubkey> OP_ENDIF OP_CHECKSIG
https://mempool.space/tx/8492511e2c73337acede42c1480d25fcc0c0269a3a7d07cda6e84615abe14fdb#vin=0

The troubled commitment's main outputs are:

F vout 2 is the to_local:
OP_IF <revocationpubkey> OP_ELSE to_self_delay OP_CHECKSEQUENCEVERIFY OP_DROP <local_delayedpubkey> OP_ENDIF OP_CHECKSIG
https://mempool.space/tx/315b9223ccbf8090331d0c2eac5eaf43d0cf73ab137707812efd5bffbeebf823#vin=0
-F vout 3 must be the to_remote (this is the troubled output)

The witness for A's to_remote is:
3045022100f5bad7155179820b4c74107a5c878a94dfdd61bd5561710546b5b4f5663ace8202203493a886ead7c11d2c04f31434e02338f68a31e6c9dcb18f15fbe50f99e0b13e01
2103e20728952d387266bbec58a0b608952124baa9dd58e6c339e52ec7115bb54501ad51b2

The script decodes as:
bitcoin@home5:~$ bitcoin-cli decodescript 2103e20728952d387266bbec58a0b608952124baa9dd58e6c339e52ec7115bb54501ad51b2
{
  "asm": "03e20728952d387266bbec58a0b608952124baa9dd58e6c339e52ec7115bb54501 OP_CHECKSIGVERIFY 1 OP_CHECKSEQUENCEVERIFY",
  "desc": "raw(2103e20728952d387266bbec58a0b608952124baa9dd58e6c339e52ec7115bb54501ad51b2)#7kdpwq3z",
  "type": "nonstandard",
  "p2sh": "3MmR7DiFemknUa1vQoE3ycri2ahU7hTR9b",
  "segwit": {
    "asm": "0 b61d3aec9892251b2aaeb5ce5600d4477090a9ef7e59ea11156edd1b4dcde2d9",
    "desc": "wsh(and_v(v:pk(03e20728952d387266bbec58a0b608952124baa9dd58e6c339e52ec7115bb54501),older(1)))#9pt2xcnl",
    "hex": "0020b61d3aec9892251b2aaeb5ce5600d4477090a9ef7e59ea11156edd1b4dcde2d9",
    "address": "bc1qkcwn4mycjgj3k24wkh89vqx5gacfp2000ev75yg4dmw3knwdutvsa5fh5j",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "32gXVyAjbrDhKb8iyAKh7xiYiZKeuekto3"
  }
}

The witness for F's to_remote is:
3045022100eba3c7db03e7be73a932d39816f10be376a79fb3ac2b960617a3331c5212ef0802201aaee301beac012ccd413a3ea6dbcd8edbf1ae3c26ccfc2ab979e70c352fc19b01
020d0f6142c6ad7c190875838f7a57bcfdcceb6e7bcc253849d038a8e6d847f333

The script is wrong

Running out of time, thinking out loud ... "How does / should SignWithdrawal know that this is a commitment to_remote output?
Does this output need to be swept with a different HSMD interface?

I think the issue is related to the uniclosekeys argument to SignWithdrawal.  The output is question is being spent and it is being identified as the output of a priot unilateral close.  I suspect we need to deal with the anchors case explicitly ...

created https://gitlab.com/lightning-signer/validating-lightning-signer/-/issues/444

I analyzed the problem in the issue linked above.  The issue is that we are missing the redeemscript in the witness stack for the anchors case.
I'm surprised that this case is not covered by the CLN system tests.

The script is wrong

That witness element would have been correct if this was non-anchors (p2wpkh), but it's indeed wrong for the anchors case (p2wsh).

I improved the VLS debugging of Unilateral Close Info and slightly modified a CLN integration test to expose this issue in integration testing:
https://gitlab.com/lightning-signer/vls-hsmd/-/merge_requests/136

https://github.com/lightning-signer/c-lightning/compare/798ace6e1e17de8b2f46b6c006919422874a5a49...b06db5636911cccc4bb3f5572a39b292acb13066

fixed in https://gitlab.com/lightning-signer/validating-lightning-signer/-/merge_requests/585

https://gitlab.com/lightning-signer/validating-lightning-signer/-/merge_requests/585 merged


Ensure we build properly on OSX and Windows

This will probably fail.

Should try to disable compiling cargo-travis on windows to win some 20 minutes or so.

This now builds. The last step is to ensure the windows build works even in the absence of MSYS.


Latest Python Common Layer causes cffi backend error in validator

After a lot of troubleshooting between my dev and test orgs for a client (built days apart) ive found that there looks to be a version release done to the common python layer (38 vs 39) that seems to cause the validator to spit out an error
No module named '_cffi_backend'

Ive manually uploaded a zip of the previous version of the python common layer as a workaround which fixed the issue

@dcarbonetti do you know where we can find a zip of the previous version of the python common layer?

@dcarbonetti Disregard, we pulled an old version from dev.  Thank you very much for supplying the workaround!

awsscv_common_python-068ce42a-b848-48da-8927-097cbbb23d3b.zip
We've had the same problem with our latest installation and uploading this file as a new version of the awsscv_common_python fixed it.

Reviewing this fix. WIll update today.

@corentinbernier Can you explain how to upload the file as a new version.  When i try uploading the zip it doesn't work

@dcarbonetti Can you please provide where that old version is, I cannot seem to find it.  Really appreciate the help
Thanks,

@dcarbonetti Can you please provide where that old version is, I cannot seem to find it. Really appreciate the help
Thanks,

Here's a step by step:

Download the Zip file provided by @corentinbernier ( https://github.com/amazon-connect/amazon-connect-salesforce-scv/files/7127220/awsscv_common_python-068ce42a-b848-48da-8927-097cbbb23d3b.zip)
log into AWS console
navigate to Lambda
select "Layers" on the left hand side menu
click on the "awsscv_common_python" (or equivalent)
click on the "create version" button on the top right
upload the zip file you previously downloaded
click create

after that you will need to just doublecheck that all of the other python based lambdas are pointing to the correct version

Thank you so much!

This has been fixed in the latest build


localized off-canvas-position rather than globally declared and tied to breakpoints.

What should happen?
Hi guys, Using offcanvas components i had implemented an element which in medium and above devices would cover half the screen and in small devices cover entire screen. Now after updating to latest version of <IP_ADDRESS> i am not able to set this option locally on class by class basis, Is there an option to set this locally for a class.
.offcanvas-half-screen_right {
  @include off-canvas-base($background: white, $transition: 0.3s ease-in-out);
  @include breakpoint(small) {
     @include off-canvas-position($position: right, $size: 100%);
  }
  @include breakpoint(medium) {
     @include off-canvas-position($position: right, $size: 50%);
     transform: translateX(100%);
  }
}
.offcanvas_normal_left {
   @include off-canvas-position($position: left, $size: 250px);
}

What happens instead?
I tried setting in settings file, this works but it applies globally,  for both left and right side offcanvas elemets.
$offcanvas-sizes: (
  small: 100%,
  medium: 50%,
  large:  50%,
);

Context
Design was for the same breakpoint, left offcanvas should render with 250px(standard default size)
and right offcanvas should render 50% or 100% based on the breakpoint. It was originally implemented in 6.3.1 and it was working perfectly but ofter updating to <IP_ADDRESS> it's broken.
Your Environment

Foundation version(s) used: <IP_ADDRESS>
Browser(s) name and version(s): chrome@latest
Operating System and version (desktop or mobile): MacOS

Checklist (all required):

[x] I have read and follow the CONTRIBUTING.md document.
[x] There are no other issues similar to this one.
[x] The issue title is descriptive.
[x] The template is correctly filled.

@vikksr $size is deprecated – you have to use $sizes instead
(you didn't get a deprecation warning bcz you're not using the global $offcanvas-sizes)
@include off-canvas-position($position: right, $sizes: (small: 100%));


[dialogues] NPC head animations

NPC head animations do not work on both 377 and 317. When using the dialogue plugin, only a static image of the NPC head is shown.
Should this be fixed plugin-wise or in core?

Can you provide the code you are using?

I've not written any dialogue code, I've just used the built in tutorial island plugin together with the dialogue plugin to test tutorial island. The npc head of the runescape guide wasn't moving in the  dialogue.

there is a packet which apollo does not have for interface animations

@WizardJesse1 So... perhaps we should implement the packet?
What's the opcode?

200 - Animate component (not sure)
interfaceId - Short
animationId - Short

Shouldn't be hard to implement. Would you accept pull requests to implement this @Major- ?

im sure he wouldn't object to a pull req

Apollo does have this frame @WizardJesse1 @Tim-W, it's called SetWidgetModelAnimation.
The actual issue is that the emote is never set in any of the dialogues, and that the frame is not sent when the dialogue is. The dialogue code is all cobbled together and needs rewriting in an actual OO manner at some point, so this probably isn't the only issue with them.

I implemented this today, care for a PR?
http://recordit.co/bsMIFshRme


Attention weight score

Hi, I was reading your work and was wondering, how do you obtain the highest attention weight for the feature maps in figure 5? Do you just sum up the tensor along the channel dimension and sort that or do you use some other method?
Thanks!

We use exactly the same method used by CAIN but plot only the highest activation feature.
https://www.dropbox.com/s/b62wnroqdd5lhfc/AAAI-ChoiM.4773.pdf?dl=0

Hi, I have taken a look at the CAIN paper and also the repository, however, there is no explanation as to how they get the attention score. How would you obtain the attention score in the first place?

During training, we compute a separate attention score for each channel dimension in each layer. To visualize, we pick a layer and compute the attention weights for all the channels, and plot channel maps having largest attention values as RGB images.

Can you elaborate on how would you compute this attention score?
Also, if you compute an attention value for each channel (say for example with a layer with 64 channels), would you basically take the 3 channels with the largest activations and concatenate them to obtain the RGB images or would you use one channel and create two empty channels of 1s?


Add Ascend NPU as a backend

Description
:rocket:Ascend is a full-stack AI computing infrastructure for industry applications and services based on Huawei Ascend processors and software. For more information about Ascend, see Ascend Community.
CANN (Compute Architecture of Neural Networks), developped by Huawei, is a heterogeneous computing architecture for AI.
Pytorch has officially announced support for Ascend NPU (through key PrivateUse1), please see the PrivateUse1 tutorial here.

Motivation
With the growing number of developers leveraging Ascend NPUs for AI training and inference, I would like to propose adding support for the Ascend NPU backend to this project.

Hi @noemotiovon thanks for creating the issue. If I understand correctly one gap is to import torch_npu to access the NPU backend, is that correct? Looking at the Ascend/pytorch repo I only see up to version 2.3 supported on main (ref), while we only support the latest stable version of PyTorch (2.4 and soon to be 2.5). Do you know if these more recent versions are currently support in Ascend?

@ebsmothers Thank you very much for taking the time to review my issue :smile: !
Currently, torch-npu 2.4.0rc1 has been released, and we can use it for testing.(ref)
You’re correct, we just need to import torch_npu based on the device. And will you accept a PR that use this version(2.4.0rc1) of torch_npu for testing and verification? :smiley:

@noemotiovon yep if you open a PR I am happy to review it!

fyi looks like this has been requested in the past, but never followed up on: https://github.com/pytorch/torchtune/issues/1006

Closed by #1826


kernel: sched: z_unpend_all_rc

This function is used to unpend all tasks from a wait queue and have the pend_curr(..) function return a specific return code. This is useful when a task is waiting for a resource and the resource is no longer available. By calling z_unpend_all_rc(..) the caller can convey the reason for the cancelation to the waiting tasks.

Also the very early intent of this API wasn't as a generic feature, it was to exploit the implementation of swap() as a C ABI function to stuff the value into the spot where the context save code put the return value of the function, thus making it "zero cost" (to the thread calling swap() anyway).  AFAICT it only ever worked like that on i386, not even Cortex M got it.
And a quick check shows that of all the architectures added since, only Nios (?!!) ever bothered to duplicate the trick.  That sort of shows you how seriously people take the feature.  Personally I'd kinda like it to die.

Let's let the feature die, I'll sort the intended use case in another way instead :+1:


Moved CV conventions into ops.py docstrings

Context:
We currently have information about the CV operations split among multiple pages:

Conventions/Operators (information about creation/annhilation, quad operator conventions)
Conventions/Gates (CV gate set definitions)
Conventions/States (CV initial state definitions)
Conventions/Decompositions (common CV decompositions)
Conventions/Measurements (CV measurements)
Conventions/Other (loss channels)
ops.py docstrings (operator arguments)

This is confusing to navigate, and can cause users to end up on the wrong page. Furthermore, the ops.py docstrings currently have very little information in them.
Description of the Change:
Merges the conventions rst files with the ops.py docstrings, under a Details and Conventions section (collapsed by default). For example,

In particular:

Conventions/Operators is left as-is, as it is more technical/doesn't have any direct code correspondence.

Everything in Conventions/Gates is moved to the corresponding Gate docstrings in ops.py

Everything in Conventions/States, except the introduction on Gaussian states, is moved to the corresponding Preparation docstrings in ops.py

Everything in Conventions/Decompositions, except the intro on Gaussian unitaries, is moved to the corresponding Decomposition docstrings in ops.py

Everything in Conventions/Measurements is moved to the corresponding Measurement docstrings in ops.py

Everything in Conventions/Other, except a very brief section on commutation relations, is moved to the corresponding Channels docstrings in ops.py.

Benefits:

Now that each Python object has it's own page, it makes sense to collate all information regarding that object (including conventions) in the same place.

Easier to find and navigate

Still to do:
What should be done with the remaining conventions pages? All that remains is:

Annhilation/creation operators
Quadrature operators
Commutation relations
Gaussian unitaries
Gaussian states

These likely make up two new pages, one on operator conventions, and one on the Gaussian representation.
Possible Drawbacks: n/a
Related GitHub Issues: n/a

Maybe one could include the discussion on creation and annihilation operators, quadrature operators, commutation relations and Gaussian states and operations as a preface of ops.py. This will be helpful for people reading this files read things like "the Dgate is Gaussian"? Is that reasonable?

What's the plan to fix the CodeFactor errors?

What's the plan to fix the CodeFactor errors?

Two of the errors can be fixed by removing unneeded imports. The others were existing pylint warnings that have been picked up again, so I think it's safe to continue to ignore for now (out of scope to fix in this PR)

@trbromley, I've fixed the transition error occurring with module-level variables.


UseInMemoryDatabase extension method is no longer in the Microsoft.EntityFrameworkCore.SqlServer package

Hi!
I've found an issue in the documentation under the "Add database context" section. The issue is in that the UseInMemoryDatabase cannot be found in the NuGet package Microsoft.EntityFrameworkCore.SqlServer it can actually be found in the Microsoft.EntityFrameworkCore.InMemory NuGet package. Installing this package through the UI actually makes this code snippet work:
            services.AddDbContext<TodoContext>(opt =>                                                opt.UseInMemoryDatabase("TodoList"));
Also, adding the NuGet package with VSCode is also missing. My suggestion would be to provide CLI commands to add the mentioned package.

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

ID: 583ae3e7-5915-f22b-e54c-6c100cf2a7da
Version Independent ID: 95f2549e-29f9-e31a-b4d0-432b971643ff
Content: Tutorial: Create a web API with ASP.NET Core
Content Source: aspnetcore/tutorials/first-web-api.md
Product: aspnet-core
Technology: aspnetcore-tutorials
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

Hello @hoborm ... It's in the topic ... see the last bullet of ...
https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio#add-nuget-packages

Hello @hoborm ... It's in the topic ... see the last bullet of ...
https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio#add-nuget-packages

Oh right, well the VSCode problem still persist.

Oh right, well the VSCode problem still persist.

That's in a different section earlier in the topic ...
https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio-code#create-a-web-project

That's in a different section earlier in the topic ...
https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio-code#create-a-web-project

... and the macOS way is a little further down ...
https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio-mac#to-access-a-command-terminal-from-finder

... and the macOS way is a little further down ...
https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-5.0&tabs=visual-studio-mac#to-access-a-command-terminal-from-finder

You are right @guardrex excuse my lack of thoroughness.

You are right @guardrex excuse my lack of thoroughness.


Document deletion of dynamic shovels

We have to answer this from time to time, e.g. in this thread.

Done.