New non-volatile storage system

Introduction
In recent years, advances to process nodes in embedded hardware have made it necessary to support non-volatile technologies different from the classical on-chip NOR flash, which is written in words but erased in pages. These new technologies do not require a separate erase operation at all, and data can be overwritten directly at any time.
On top of that, complexity of firware has not stopped growing, making it necessary to ensure that a solid, scalable storage mechanism is available for all applications. This storage needs to support millions of entries with solid CRC protection and multiple advanced features.
Problem description
In Zephyr, there are currently a few alternatives for non-volatile memory storage:

NVS: Basic ID-based storage, but optimized for devices with page erase
LittleFS: Full file system, optimized for devices with page erase
FCB: Very little use, extremely bare-bones storage

None of them are optimal for the current new wave of solid-state non-volatile memory technologies, including resistive (RRAM) and magnetic (MRAM) random-access, non-volatile memory, because they rely on the "page erase" abstraction whereas these devices do not require an erase operation at all, and data can be overwritten directly.
Additionally, none of the storage systems above is a good match for the widely used settings subsystem, given that they were never designed to operate as a backend for it.
The closest one is NVS, and an analysis of why it is not suitable can be found in the Alternatives section of this issue.
Proposed change
Create a new storage mechanism that fulfills the following requirements:

Simple Key-Value Storage (i.e. no file/folder abstractions)
32-bit IDs
Support for entries in multiple formats
CRC-24 for entries that require it
No limits in value length
Metadata entries can also store small (1 to 4 bytes) data entries
Optimized for bigger (e.g. 16-byte) write block sizes
Support for no-erase-required flash drivers (i.e. RRAM, MRAM, etc)
Designed from the start to be efficient when used as a backend for the settings susbystem
Designed from the start to be able to serve as a backend of the Secure Storage subsystem (link)

Potential names

ZMS: Zephyr Memory Storage
NVMS: Non-Volatile Memory Storage
IDVS: ID Value Storage
ZKVS: Zephyr Key-Value Storage

Detailed RFC
Proposed change (Detailed)
General behavior:
ZMS divides the memory space into sectors (minimum 2), and each sector is filled with key/value pair until it is full , we close it then the storage system will move forward to the next sector until it reaches the end and then it starts again from the first sector after garbage collecting it and erasing its content.
Mounting the FS:
Mounting the filesystem will start by getting the flash parameters, checking that the file system properties are correct (sector_size, sector_count ...) Then initializes the file system.
Initialization of ZMS:
As the ZMS has a fast-forward write mechanism, we must find the last sector and the last pointer of the entry where it stopped the last time.
It must look for a closed sector followed by an open one, then within the open sector, it finds (recover) the last written ATE (Allocation Table Entry).
After that it checks that the sector after this one is empty, or it will erase it.
Composition of a sector.
A sector is organized in this form :

Sector N

data0

data1

...

...

ate1

ate0

gc_done

empty_ate

close_ate

Close ATE is used to close a sector if a sector is full
Empty ATE is used to erase a sector
ATEn are entries that describe where the data is stored, its size and its crc32
Data is the written value
ZMS Key/value write :
To avoid rewriting the same data with the same ID again, it must look in all the sectors if the same ID exist then compares its data, if the data is identical no write is performed.
If we must perform a write, then an ATE and Data (if not a delete) are written in a sector
If the sector is full (cannot hold the current data + ATE) we have to move to the next sector, garbage collect the sector after the newly opened one then erase it.
Data size that is smaller or equal to 4 bytes are written within the ATE
ZMS read (with history):
By default it looks for the last data with the same ID and retrieves its data.
If history count is provided that is different than 0, older data with same ID is retrieved.
ZMS how does the cycle counter works ?
Each sector has a lead cycle counter which is a uin8_t that is used to validate all the other ATEs.
The lead cycle counter is stored in the empty ATE.
To become valid, an ATE must have the same cycle counter as the one stored in the empty ATE.
Each time an ATE is moved from a sector to another it must get the cycle counter of the destination sector.
To erase a sector, the cycle counter of the empty ATE is incremented. All the ATEs in that sector become invalid
ZMS how to close a sector ?
To close a sector a close ATE is added at the end of the sector and it must have the same cycle counter as the empty ATE
When closing a sector, all the remaining space that has not been used is filled with garbage data to avoid having old ATEs with a valid cycle counter.
ZMS structure of ATE (Allocation Table Entries)
An entry has 16 bytes divided between these variables :
struct zms_ate {
	uint32_t id;     /* data id */
	uint32_t offset; /* data offset within sector */
	uint16_t len;    /* data len within sector */
	union {
		uint32_t crc_data; /* crc for data */
		uint32_t data;     /* used to store small size data */
	};
	uint8_t cycle_cnt; /* cycle counter for non erasable devices */
	uint8_t crc8;      /* crc8 check of the entry */
} __packed;

id has 32 bits
sector size is now 32 bits, that's why offset is also 32 bits => That allows to define large sectors of needed.
length of data is 16 bits (could be changed to 32 bits in the future) which can store data up to 64K
crc_data/data is a field that can store small size data (<= 4 bytes) or the crc32 for bigger data
cycle_cnt is used to validate an ATE within a sector
crc8 is the crc of the ATE (could be changed to crc24 in the future)

Dependencies
Only on flash drivers.
Concerns and Unresolved Questions
The first draft of this new storage system will not include all the features listed in the proposed change section.
This is intended to minimize the effort of reviewing this new storage system for developers that are familiar to NVS filesystem.
More changes will come in future patch lists
Alternatives
The one alternative we have considered would be to expand the existing NVS codebase in order to remove its described shortcomings. This is in fact how this new proposal was born, once expanding NVS was identified as suboptimal.
Among other issues, we identified the following:

NVS was never designed for devices that do not have an erase operation available
NVS limits the max value length to be the size of a sector (32KB)
NVS was designed to be simple and compact, so extending it is not necessarily a good option
NVS performs poorly when the storage mechanism gets close to being full
Slow Garbage Collector that can go through all sectors for a single write operation
Switching to the next sector is a time consuming operation
NVS was not designed to be used as a backend for the settings subsystem, causing latency (up to minutes) and other issues

More info in these Pull Requests:

https://github.com/zephyrproject-rtos/zephyr/pull/69384
https://github.com/zephyrproject-rtos/zephyr/pull/74432

Zephyr platforms have a maximum write size of up to 512 bytes.
Will ZMS support it?

Zephyr platforms have a maximum write size of up to 512 bytes. Will ZMS support it?

@butok I saw this RFC https://github.com/zephyrproject-rtos/zephyr/issues/77576
Although this storage system is still (could change in the future) not optimized for larger block write size, we could add a hidden config for that with a warning for users that want to increase the default maximum write block size.
So I won't block this

Architecture WG:

Presentation by @rghaddab of the new system, including some basic technical details
@bjarki-andreasen asks whether the API is similar to NVS, Riadh answers that it is
A question on whether this new system should coexist with NVS is raised, @henrikbrixandersen and @carlescufi suggest that there's no reason why the two systems could coexist. There's a large base of NVS installations in the wild, and the two systems differ in scope and maturity.

I was thinking about one thing even when learning about how NVS works - is separating data ATE From actual data worth it?
We maybe make the data more dense by storing ATE - data pairs from the start of the sector.

Sector start

ATE 1

DATA 1

ATE 2

DATA 2a

DATA 2b

ATE 3

DATA 3

.....

gc_done

emty_ate

close_ate

The advantages would be that the ATE and DATA could be placed right next to each other - so we waste less space in case of larger write block size. On the other end the disadvantage is that we would need to do some address calculation to find every other data ATE except of the first one. But I think it would not be a reason for a noticeable slowdown - just calculate ATE start address + ATE size + data length and align it to the next start of the write block.

I was thinking about one thing even when learning about how NVS works - is separating data ATE From actual data worth it?

Yes it is. It is easier to recover if something happens, otherwise you may just write something that looks like ATE to data and glitch device into attempting to read storage as your data mandates or loop. Also if you write in the loop you may basically loop the ATE/DATA storage without a way to figure out where it really ends. It is much easier to keep things working if you keep users out of area where metadata of your storage is stored.
Same happens with any block-device oriented FS, where metadata is separated from data streams.
Of course there is also a way to do that, for example introducing different alphabets for metadata and data, but this means that you end up in some  8 to N encodings (N > 8), and have to make sure that user data will not get encoded to look like metadata.

I was thinking about one thing even when learning about how NVS works - is separating data ATE From actual data worth it?

Yes it is. It is easier to recover if something happens, otherwise you may just write something that looks like ATE to data and glitch device into attempting to read storage as your data mandates or loop. Also if you write in the loop you may basically loop the ATE/DATA storage without a way to figure out where it really ends. It is much easier to keep things working if you keep users out of area where metadata of your storage is stored.
Same happens with any block-device oriented FS, where metadata is separated from data streams.
Of course there is also a way to do that, for example introducing different alphabets for metadata and data, but this means that you end up in some 8 to N encodings (N > 8), and have to make sure that user data will not get encoded to look like metadata.

OK I understand the reason now.
For the purpose of saving space I really like the small data inside an ATE feature.
For data that is a little larger than 4 bytes - would it be acceptable to write that right after ATE if the block is large enough? So maybe there could be another rule that if there is enough space in a block right after the ATE for the data than it would be stored there.
Technically this is also mixing ATE and data but we would search for ATEs only on the start of the blocks anyway.
What do you think about such feature?

For data that is a little larger than 4 bytes - would it be acceptable to write that right after ATE if the block is large enough?

This could be done once the multiple format entries feature is added. Which means that you can have a different format which is larger and that holds N bytes of data

For the purpose of saving space I really like the small data inside an ATE feature.
For data that is a little larger than 4 bytes - would it be acceptable to write that right after ATE if the block is large enough? So maybe there could be another rule that if there is enough space in a block right after the ATE for the data than it would be stored there.
Technically this is also mixing ATE and data but we would search for ATEs only on the start of the blocks anyway.
What do you think about such feature?

The original design of NVS and the ZMS here intends to work with devices with relatively small write block sizes, wbs, that can be appended without altering other data (unless area is overwritten); this allows placing metadata in small chunks of constant size and data at variable size, with no mandated boundaries (except write block size) between data.
Because ATE have same sizes, if wbs becomes large, it should be possible to start placing some data in it, for example if you have 32byte long wbs and 16 bytes of ATE, then any data of size <= 16 bytes can go into ATE, and it would not be a problem as wbs and size of ATE set boundaries, which means that the ATE and data in ATE wbs are still separated.
Eventually you may have to erase some part of storage, but that happens because device requires it, for example flash, before it can be written. Using a magnetic tape analogy: erase head has to erase data before r/w head can write in are previously used.
I understand that what you are trying to solve in your case @andrisk-dev , is a problem of relatively big write block size of your device that equals to erase block size - so you basically have a block device. You can see a difference here, where you can not really append data, directly on storage, you have to basically replace entire block contents, unless you are willing to append data at wbs of sector size.
In your case, the scheme you have presented in comment https://github.com/zephyrproject-rtos/zephyr/issues/77929#issuecomment-2326925453 could work, if you decide to divide your sector into ATE and data part assuming that you always write both as a single sector, for every sector, even if it carries continuation of data from previous sector, has that ATE part reserved and not available for users. Still, you will probably have some unused space wasted.
Amiga on OFS has been doing that to datablocks, where each sector had reserved 24 bytes for OFS header, which means that user data could only take 488 bytes out of 512 byte sector (https://en.wikipedia.org/wiki/Amiga_Old_File_System, https://wiki.osdev.org/FFS_(Amiga))
What I understand is you are trying to provide your users with small reliable storage for basic data or settings, but I do not think that this PR will effectively solve your problem, at least not without significant complexity being introduced, as it is basically based on ability to freely append data at small granularity of  xRAM and small wbs Flash devices, something your device does not provide. We can try to bend it your way, but I would rather focus first on making it solid solution for the devices it has been originally designed for.

Thanks for your replies @rghaddab  @de-nordic ,
I understand that the first version is to be as simple as possible. I think one solution that would enable us at NXP to make most of the 512 bytes write block size is to have ATE in different format, maybe we can call it long ATE here, which could store information about multiple data records in one place. The format would include information about a number of data items stored in that ATE and a list of metadata about all of them would follow. That way, even if the data stored individually would be still sparse in flash, when reallocating the data from erased sector to a new one we could pack the data much more densely.
As this is more of a future release thing, I think the main question for now is how would the filesystem distinguish between normal entry fromat and an entry in different format. I think that should be decided now to make sure the "Support for entries in multiple formats" is possible in the future.

As this is more of a future release thing, I think the main question for now is how would the filesystem distinguish between normal entry fromat and an entry in different format.

This change is planned as following :
The first byte of an ATE will be a format-type field that defines what is the ATE format that should be considered.
For example : 0 => default format, 1 => format for big data 2=> ...
All the write/read/ATE validation functions will have different behavior depending on the format that is read from the first byte. This is of course should be done in the initialization phase and we must verify that the ATEs are valid if we choose a custom format.
At a certain point there will be different files containing each the corresponding function for each format. The main file will only have pointer to these functions depending on the format

Zephyr platforms have a maximum write size of up to 512 bytes. Will ZMS support it?

@butok I saw this RFC #77576 Although this storage system is still (could change in the future) not optimized for larger block write size, we could add a hidden config for that with a warning for users that want to increase the default maximum write block size.

This needs to be a requirement on ZMS to not artificially limit the size. Optimize later if needed. Add warnings to make sure the users are aware of the impacts.

@rghaddab, This needs to be a requirement on ZMS to not artificially limit the size. Optimize later if needed. Add warnings to make sure the users are aware of the impacts.

@dleach02  I included this on the last revision of the PR


No module named 'openselfsup'

After I run the command below:
bash tools/dist_train.sh configs/selfsup/odc/r50_v1.py 4
It get the error below:
Traceback (most recent call last):   File "tools/train.py", line 13, in <module>     from openselfsup import __version__ ModuleNotFoundError: No module named 'openselfsup' Traceback (most recent call last):   File "tools/train.py", line 13, in <module>     from openselfsup import __version__ ModuleNotFoundError: No module named 'openselfsup'
How to solve it?
Thanks.

Did you correctly install openselfsup following: https://github.com/open-mmlab/OpenSelfSup/blob/master/docs/INSTALL.md

I have run the command below:
conda install faiss-gpu
pip install -v -e .

It seems like other package I have already installed through the version is different(I run the code in docker whose images is Ubuntu20.04, and my Python version is 3.8).
When I use python command interaction interface.
It can Import openselfsup, but in bash, it can't.
>>> import openselfsup
>>>

Please correctly reinstall openselfsup following: https://github.com/open-mmlab/OpenSelfSup/blob/master/docs/INSTALL.md


Uncaught ValueError in style.py line 76

Aider version: 0.58.0
Python version: 3.10.0rc2
Platform: Windows-10-10.0.26100-SP0
Python implementation: CPython
Virtual environment: No
OS: Windows 10 (64bit)
Git version: git version 2.46.0.windows.1
An uncaught exception occurred:
Traceback (most recent call last):
  File "runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "__main__.py", line 7, in <module>
    sys.exit(main())
  File "main.py", line 501, in main
    git_root = setup_git(git_root, io)
  File "main.py", line 78, in setup_git
    elif io.confirm_ask("No git repo found, create one to track aider's changes (recommended)?"):
  File "io.py", line 526, in confirm_ask
    style = self._get_style()
  File "io.py", line 290, in _get_style
    return Style.from_dict(style_dict)
  File "style.py", line 266, in from_dict
    return cls(list(style_dict.items()))
  File "style.py", line 239, in __init__
    attrs = _parse_style_str(style_str)
  File "style.py", line 172, in _parse_style_str
    attrs = attrs._replace(color=parse_color(part))
  File "style.py", line 76, in parse_color
    raise ValueError(f"Wrong color format {text!r}")
ValueError: Wrong color format 'sonnet'

Thank you for filing this issue.
Looks like something got messed up in you configuration and you try to set sonnet as a color format somehow.

I'm closing this issue for now.
If any new related concerns arise, please feel free to comment, and I'll reopen the issue.


Problems converting A4 format brews to Letter brews

Having a real problem with converting brews formatted as A4 to Letter size. There's a simple click to put the A4 snippet in your brew, but once done, how do you convert back?
I have tried deleteing the snippet, but the pdf still comes out in A4 format. If I set the printing to Letter format, it still prints in A4 format.
Please help.

My guess is you have multiple copies of the A4 snippet hidden away in your
document somewhere, because deleting it is all you need to do. It also
always helps if you put your "share" link here so someone can actually look
at it. I don't know why nobody seems to read the instructions when filling
out these bug reports.
On Sat, Jul 8, 2017, 2:13 PM staticdrifter<EMAIL_ADDRESS>wrote:

Having a real problem with converting brews formatted as A4 to Letter
size. There's a simple click to put the A4 snippet in your brew, but once
done, how do you convert back?
I have tried deleteing the snippet, but the pdf still comes out in A4
format. If I set the printing to Letter format, it still prints in A4
format.
Please help.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/stolksdorf/homebrewery/issues/439, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFmzBi6AJYWJPdjvyJFeZcgt9CyUaljjks5sL8bTgaJpZM4OR008
.

Closing since there hasn't been a reply from the user for a while and it is assumed the problem was solved.
If you are still experiencing this issue, feel free to reopen and provide information, @staticdrifter


Question - how to skip route/url from validation?

Hello,
Is there some simple way to skip the route from validation.

Core: Symfony 5.x
File: security.yaml

    firewalls:
        login:
            provider: app_user_provider
            pattern: ^/login
            stateless: true
            json_login:
                check_path: /login
                success_handler: lexik_jwt_authentication.handler.authentication_success
                failure_handler: lexik_jwt_authentication.handler.authentication_failure

        main:
            stateless: true
            jwt: ~

It's about the main firewall. I would like to put a routes which should be skipped from validation. Any idea how to handle it?
Anything like:
        main:
            stateless: true
            jwt: ~
         exclude: ['url1', 'url2']

?

Hi, you can achieve that using access_control in security.yaml.
https://symfony.com/doc/current/security.html#security-authorization-access-control

No. That's not the solution.
Problem is that the bundle checks every route for jwt token. Now I got routes for which I do not provide jwt token.
Anyway got working solution so closing.


iOS Build Fails node_modules/react-native-bluetooth-escpos-printer/ios/RNBluetoothTscPrinter.m normal x86_64 objective-c com.apple.compilers.llvm.clang.1_0.compiler

@reactnative12414  Have you solved this issue?

same issue

never met this issue


Fixes render loop push/pop order

This takes care of #167

Yeah, this isn't going to work for now.


#2315, #2316, #2324

RTools Options page not working #2324
Need separate installer for RHost for remote #2316
Remote services installer - can't load rtvs package #2315
Bundle build in RTVS-Pr coming next

Also couple of fixes: caught null ref on await and we need to check against local connections only.


Handle language server shutdown gracefully

Closes #491

Codecov Report

Merging #507 into master will decrease coverage by 0.29%.
The diff coverage is 0.00%.

@@            Coverage Diff             @@
##           master     #507      +/-   ##
==========================================
- Coverage   93.70%   93.41%   -0.30%
==========================================
  Files         214      214
  Lines        7388     7390       +2
==========================================
- Hits         6923     6903      -20
- Misses        465      487      +22

Flag
Coverage Δ

#dotnet
93.41% <0.00%> (-0.30%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/Bicep.LangServer/Program.cs
0.00% <0.00%> (ø)

src/Bicep.Cli.UnitTests/PathHelperTests.cs
100.00% <0.00%> (ø)


Error in the location check

After v1.9, when I try to start the Client, it says the file directory is wrong and that it should be in the C Drive, even though I have the game installed on my D Drive. I'd prefer it if works wherever it was installed instead of having to move the game to C Drive.

i know to how to fix

i can help ?

It does not need to be in the C drive, it is just an example path. v1.9 ensures the files are in the correct location. The exe / dlls being directly under the game folder is incorrect. They need to be under the YgoMaster folder. This is stated in the README, the v1.9 release notes and the error popup.
https://github.com/pixeltris/YgoMaster#usage
"Copy the YgoMaster folder (the folder, not the contents of the folder) into the game folder."
https://github.com/pixeltris/YgoMaster/releases
"The Build folder has been renamed to YgoMaster and now checks that it's in the correct location (i.e. as a sub folder of the game install)."


Print reason why is not possible to start the coserver

because I have problem with build inside Debian infra:
https://buildd.debian.org/status/fetch.php?pkg=python-molotov&arch=all&ver=1.6-1&stamp=1534416935&raw=0

Coverage remained the same at 98.569% when pulling ae4182a8b03ae5c935b930548a4c22cdd5581bef on onovy:master into 371b87ff5e77fb803baacfe00018bb05867e55fb on loads:master.

Thanks


crunchy-cli: 3.0.0-dev.10 -> 3.2.2

Description of changes
closes https://github.com/NixOS/nixpkgs/issues/279867
crunchy-cli: 3.0.0-dev.10 -> 3.2.2
repo: https://github.com/crunchy-labs/crunchy-cli
change log: https://github.com/crunchy-labs/crunchy-cli/releases/tag/v3.2.2
Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

build error:
$ nix build .#crunchy-cli
note: keeping build directory '/private/tmp/nix-build-crunchy-cli-3.2.2.drv-7'
error: builder for '/nix/store/3y79ivapjvmw4an27kq2dm5hzhp3678h-crunchy-cli-3.2.2.drv' failed with exit code 101;
       last 10 log lines:
       >    |     |
       >    |     `async` because of this
       >    |
       >    = note: `async` trait functions are not currently supported
       >    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
       >    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information
       >
       > For more information about this error, try `rustc --explain E0706`.
       > error: could not compile `crunchy-cli-core` (lib) due to 30 previous errors
       > warning: build failed, waiting for other jobs to finish...
       For full logs, run 'nix log /nix/store/3y79ivapjvmw4an27kq2dm5hzhp3678h-crunchy-cli-3.2.2.drv'.

'nix log /nix/store/3y79ivapjvmw4an27kq2dm5hzhp3678h-crunchy-cli-3.2.2.drv'

$ nix log /nix/store/3y79ivapjvmw4an27kq2dm5hzhp3678h-crunchy-cli-3.2.2.drv
warning: The interpretation of store paths arguments ending in `.drv` recently changed. If this command is now failing try again with '/nix/store/3y79ivapjvmw4an27kq2dm5hzhp3678h-crunchy-cli-3.2.2.drv^*'
@nix { "action": "setPhase", "phase": "unpackPhase" }
Running phase: unpackPhase
unpacking source archive /nix/store/q4815d36dmfq29wzbrwjd6611d3l3dvg-source
source root is source
Executing cargoSetupPostUnpackHook
Finished cargoSetupPostUnpackHook
@nix { "action": "setPhase", "phase": "patchPhase" }
Running phase: patchPhase
Executing cargoSetupPostPatchHook
Validating consistency between /private/tmp/nix-build-crunchy-cli-3.2.2.drv-7/source/Cargo.lock and /private/tmp/nix-build-crunchy-cli-3.2.2.drv-7/cargo-vendor-dir/Cargo.lock
Finished cargoSetupPostPatchHook
@nix { "action": "setPhase", "phase": "updateAutotoolsGnuConfigScriptsPhase" }
Running phase: updateAutotoolsGnuConfigScriptsPhase
@nix { "action": "setPhase", "phase": "configurePhase" }
Running phase: configurePhase
@nix { "action": "setPhase", "phase": "buildPhase" }
Running phase: buildPhase
Executing cargoBuildHook
++ env CC_AARCH64_APPLE_DARWIN=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/cc CXX_AARCH64_APPLE_DARWIN=/nix/store/vwh2qqal1q101wv4jy40giavp73q0msd-clang-wrapper-16.0.6/bin/c++ CARGO_TARGET_AARCH64_APPLE_DARWIN_LINKER=/nix/>
   Compiling libc v0.2.152
   Compiling proc-macro2 v1.0.76
   Compiling unicode-ident v1.0.12
   Compiling autocfg v1.1.0
   Compiling serde v1.0.195
   Compiling version_check v0.9.4
   Compiling rustix v0.38.28
   Compiling typenum v1.17.0
   Compiling fnv v1.0.7
   Compiling core-foundation-sys v0.8.6
   Compiling strsim v0.10.0
   Compiling cfg-if v1.0.0
   Compiling memchr v2.7.1
   Compiling pin-project-lite v0.2.13
   Compiling itoa v1.0.10
   Compiling thiserror v1.0.56
   Compiling httparse v1.8.0
   Compiling bytes v1.5.0
   Compiling generic-array v0.14.7
   Compiling slab v0.4.9
   Compiling num-traits v0.2.17
   Compiling native-tls v0.2.11 (https://github.com/crunchy-labs/rust-not-so-native-tls.git?rev=fdba246#fdba246a)
   Compiling ident_case v1.0.1
   Compiling rustls v0.21.10
   Compiling time-core v0.1.2
   Compiling cookie v0.16.2
   Compiling tinyvec_macros v0.1.1
   Compiling serde_json v1.0.111
   Compiling system-configuration-sys v0.5.0
   Compiling futures-core v0.3.30
   Compiling time-macros v0.2.16
   Compiling bitflags v2.4.1
   Compiling tinyvec v1.6.0
   Compiling once_cell v1.19.0
   Compiling fs-err v2.11.0
   Compiling tracing-core v0.1.32
   Compiling futures-io v0.3.30
   Compiling unicode-bidi v0.3.14
   Compiling quote v1.0.35
   Compiling syn v2.0.48
   Compiling unicode-normalization v0.1.22
   Compiling iana-time-zone v0.1.59
   Compiling futures-task v0.3.30
   Compiling percent-encoding v2.3.1
   Compiling cc v1.0.83
   Compiling socket2 v0.5.5
   Compiling mio v0.8.10
   Compiling num_cpus v1.16.0
   Compiling errno v0.3.8
   Compiling getrandom v0.2.12
   Compiling untrusted v0.9.0
   Compiling pin-utils v0.1.0
   Compiling spin v0.9.8
   Compiling core-foundation v0.9.4
   Compiling http v0.2.11
   Compiling bitflags v1.3.2
   Compiling equivalent v1.0.1
   Compiling futures-sink v0.3.30
   Compiling hashbrown v0.14.3
   Compiling portable-atomic v1.6.0
   Compiling ring v0.17.7
   Compiling form_urlencoded v1.2.1
   Compiling security-framework-sys v2.9.1
   Compiling indexmap v2.1.0
   Compiling fastrand v2.0.1
   Compiling heck v0.4.1
   Compiling try-lock v0.2.5
   Compiling base64 v0.21.6
   Compiling utf8parse v0.2.1
   Compiling log v0.4.20
   Compiling powerfmt v0.2.0
   Compiling anstyle-parse v0.2.3
   Compiling want v0.3.1
   Compiling tempfile v3.9.0
   Compiling deranged v0.3.11
   Compiling security-framework v2.9.2
   Compiling http-body v0.4.6
   Compiling block-padding v0.3.3
   Compiling idna v0.5.0
   Compiling futures-channel v0.3.30
   Compiling darling_core v0.20.3
   Compiling lazy_static v1.4.0
   Compiling anstyle-query v1.0.2
   Compiling colorchoice v1.0.0
   Compiling async-trait v0.1.77
   Compiling ryu v1.0.16
   Compiling tower-service v0.3.2
   Compiling anyhow v1.0.79
   Compiling anstyle v1.0.4
   Compiling minimal-lexical v0.2.1
   Compiling httpdate v1.0.3
   Compiling anstream v0.6.5
   Compiling nom v7.1.3
   Compiling time v0.3.31
   Compiling url v2.5.0
   Compiling inout v0.1.3
   Compiling crypto-common v0.1.6
   Compiling idna v0.3.0
   Compiling aho-corasick v1.1.2
   Compiling regex-syntax v0.8.2
   Compiling matches v0.1.10
   Compiling psl-types v2.0.11
   Compiling clap_lex v0.6.0
   Compiling publicsuffix v2.2.3
   Compiling clap_builder v4.4.14
   Compiling serde_derive v1.0.195
   Compiling tokio-macros v2.2.0
   Compiling tracing-attributes v0.1.27
   Compiling futures-macro v0.3.30
   Compiling thiserror-impl v1.0.56
   Compiling darling_macro v0.20.3
   Compiling clap_derive v4.4.7
   Compiling tokio v1.35.1
   Compiling darling v0.20.3
   Compiling futures-util v0.3.30
   Compiling tracing v0.1.40
   Compiling serde_with_macros v3.4.0
   Compiling crunchyroll-rs-internal v0.8.2
   Compiling regex-automata v0.4.3
   Compiling sct v0.7.1
   Compiling rustls-webpki v0.101.7
   Compiling smart-default v0.7.1
   Compiling idna v0.2.3
   Compiling cipher v0.4.4
   Compiling unicode-width v0.1.11
   Compiling tokio-util v0.7.10
   Compiling tokio-native-tls v0.3.1
   Compiling h2 v0.3.22
   Compiling either v1.9.0
   Compiling tokio-socks v0.5.1
   Compiling tokio-rustls v0.24.1
   Compiling chrono v0.4.31
   Compiling base64-serde v0.7.0
   Compiling serde_urlencoded v0.7.1
   Compiling quick-xml v0.31.0
   Compiling serde_path_to_error v0.1.15
   Compiling serde_with v3.4.0
   Compiling console v0.15.7
   Compiling cookie_store v0.16.2
   Compiling regex v1.10.2
   Compiling hyper v0.14.28
   Compiling crunchy-cli-core v3.2.2 (/private/tmp/nix-build-crunchy-cli-3.2.2.drv-7/source/crunchy-cli-core)
   Compiling system-configuration v0.5.1
   Compiling clap v4.4.14
   Compiling iso8601 v0.6.1
   Compiling rustls-pemfile v1.0.4
   Compiling xattr v1.2.0
   Compiling cpufeatures v0.2.12
   Compiling encoding_rs v0.8.33
   Compiling rustls-pki-types v1.1.0
   Compiling option-ext v0.2.0
   Compiling ipnet v2.9.0
   Compiling mime v0.3.17
   Compiling webpki-roots v0.25.3
   Compiling webpki-roots v0.26.0
   Compiling dirs-sys v0.4.1
   Compiling dash-mpd v0.14.7
   Compiling aes v0.8.3
   Compiling hyper-tls v0.5.0
   Compiling hyper-rustls v0.24.2
   Compiling reqwest v0.11.23
   Compiling m3u8-rs v5.0.5
   Compiling cbc v0.1.2
   Compiling derive_setters v0.1.6
   Compiling nix v0.27.1
   Compiling number_prefix v0.4.0
   Compiling shell-words v1.1.0
   Compiling futures-timer v3.0.2
   Compiling indicatif v0.17.7
   Compiling dialoguer v0.11.0
   Compiling async-speed-limit v0.4.1
   Compiling crunchyroll-rs v0.8.2
   Compiling ctrlc v3.4.2
   Compiling dirs v5.0.1
   Compiling serde_plain v1.0.2
   Compiling fs2 v0.4.3
   Compiling sys-locale v0.3.1
   Compiling roff v0.2.1
   Compiling shlex v1.2.0
   Compiling clap_mangen v0.2.16
   Compiling clap_complete v4.4.6
error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/archive/command.rs:178:5
    |
178 |     async fn execute(self, ctx: Context) -> Result<()> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/archive/filter.rs:52:5
   |
52 |     async fn visit_series(&mut self, series: Series) -> Result<Vec<Season>> {
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/archive/filter.rs:123:5
    |
123 |     async fn visit_season(&mut self, mut season: Season) -> Result<Vec<Episode>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/archive/filter.rs:245:5
    |
245 |     async fn visit_episode(&mut self, mut episode: Episode) -> Result<Option<Self::T>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/archive/filter.rs:368:5
    |
368 |     async fn visit_movie_listing(&mut self, movie_listing: MovieListing) -> Result<Vec<Movie>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/archive/filter.rs:372:5
    |
372 |     async fn visit_movie(&mut self, movie: Movie) -> Result<Option<Self::T>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/archive/filter.rs:376:5
    |
376 |     async fn visit_music_video(&mut self, music_video: MusicVideo) -> Result<Option<Self::T>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/archive/filter.rs:380:5
    |
380 |     async fn visit_concert(&mut self, concert: Concert) -> Result<Option<Self::T>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/archive/filter.rs:384:5
    |
384 |     async fn finish(self, input: Vec<Self::T>) -> Result<Self::Output> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/download/command.rs:171:5
    |
171 |     async fn execute(self, ctx: Context) -> Result<()> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/download/filter.rs:44:5
   |
44 |     async fn visit_series(&mut self, series: Series) -> Result<Vec<Season>> {
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/download/filter.rs:110:5
    |
110 |     async fn visit_season(&mut self, season: Season) -> Result<Vec<Episode>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/download/filter.rs:132:5
    |
132 |     async fn visit_episode(&mut self, mut episode: Episode) -> Result<Option<Self::T>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/download/filter.rs:258:5
    |
258 |     async fn visit_movie_listing(&mut self, movie_listing: MovieListing) -> Result<Vec<Movie>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/download/filter.rs:262:5
    |
262 |     async fn visit_movie(&mut self, movie: Movie) -> Result<Option<Self::T>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/download/filter.rs:266:5
    |
266 |     async fn visit_music_video(&mut self, music_video: MusicVideo) -> Result<Option<Self::T>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/download/filter.rs:270:5
    |
270 |     async fn visit_concert(&mut self, concert: Concert) -> Result<Option<Self::T>> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/download/filter.rs:274:5
    |
274 |     async fn finish(self, input: Vec<Self::T>) -> Result<Self::Output> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/login/command.rs:20:5
   |
20 |     async fn execute(self, ctx: Context) -> Result<()> {
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
   --> crunchy-cli-core/src/search/command.rs:104:5
    |
104 |     async fn execute(self, ctx: Context) -> Result<()> {
    |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |     |
    |     `async` because of this
    |
    = note: `async` trait functions are not currently supported
    = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
    = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/utils/filter.rs:10:5
   |
10 |     async fn visit_series(&mut self, series: Series) -> Result<Vec<Season>>;
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/utils/filter.rs:11:5
   |
11 |     async fn visit_season(&mut self, season: Season) -> Result<Vec<Episode>>;
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/utils/filter.rs:12:5
   |
12 |     async fn visit_episode(&mut self, episode: Episode) -> Result<Option<Self::T>>;
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/utils/filter.rs:13:5
   |
13 |     async fn visit_movie_listing(&mut self, movie_listing: MovieListing) -> Result<Vec<Movie>>;
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/utils/filter.rs:14:5
   |
14 |     async fn visit_movie(&mut self, movie: Movie) -> Result<Option<Self::T>>;
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/utils/filter.rs:15:5
   |
15 |     async fn visit_music_video(&mut self, music_video: MusicVideo) -> Result<Option<Self::T>>;
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/utils/filter.rs:16:5
   |
16 |     async fn visit_concert(&mut self, concert: Concert) -> Result<Option<Self::T>>;
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/utils/filter.rs:18:5
   |
18 |       async fn visit(mut self, media_collection: MediaCollection) -> Result<Self::Output>
   |       ^----
   |       |
   |  _____`async` because of this
   | |
19 | |     where
20 | |         Self: Send + Sized,
   | |___________________________^
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/utils/filter.rs:80:5
   |
80 |     async fn finish(self, input: Vec<Self::T>) -> Result<Self::Output>;
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

error[E0706]: functions in traits cannot be declared `async`
  --> crunchy-cli-core/src/lib.rs:31:5
   |
31 |     async fn execute(self, ctx: Context) -> Result<()>;
   |     -----^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `async` because of this
   |
   = note: `async` trait functions are not currently supported
   = note: consider using the `async-trait` crate: https://crates.io/crates/async-trait
   = note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information

For more information about this error, try `rustc --explain E0706`.
error: could not compile `crunchy-cli-core` (lib) due to 30 previous errors
warning: build failed, waiting for other jobs to finish...


when i pull down too quick, that's error report

════════ Exception caught by rendering library ═════════════════════════════════════════════════════
The following assertion was thrown during performLayout():
Build scheduled during frame.
While the widget tree was being built, laid out, and painted, a new frame was scheduled to rebuild the widget tree.
This might be because setState() was called from a layout or paint callback. If a change is needed to the widget tree, it should be applied as the tree is being built. Scheduling a change for the subsequent frame instead results in an interface that lags behind by one frame. If this was done to make your build dependent on a size measured at layout time, consider using a LayoutBuilder, CustomSingleChildLayout, or CustomMultiChildLayout. If, on the other hand, the one frame delay is the desired effect, for example because this is an animation, consider scheduling the frame in a post-frame callback using SchedulerBinding.addPostFrameCallback or using an AnimationController to trigger the animation.
The relevant error-causing widget was:
GlowingOverscrollIndicator file:///Users/haifeng/AndroidStudioProjects/xiyou/lib/blocks/pulltore_fresh.dart:672:14
When the exception was thrown, this was the stack:
#0      WidgetsBinding._handleBuildScheduled. (package:flutter/src/widgets/binding.dart:743:9)
#1      WidgetsBinding._handleBuildScheduled (package:flutter/src/widgets/binding.dart:766:6)
#2      BuildOwner.scheduleBuildFor (package:flutter/src/widgets/framework.dart:2551:24)
#3      Element.markNeedsBuild (package:flutter/src/widgets/framework.dart:4157:12)
#4      State.setState (package:flutter/src/widgets/framework.dart:1287:15)
...
GlowingOverscrollIndicator file:///Users/haifeng/AndroidStudioProjects/xiyou/lib/blocks/pulltore_fresh.dart:672:14
if (!isShowLeadingGlow || !isShowTrailingGlow) {
return new GlowingOverscrollIndicator(
showLeading: isShowLeadingGlow,
showTrailing: isShowTrailingGlow,
child: child,
axisDirection: axisDirection,
color: _kDefaultGlowColor,
);
} else {
return super.buildViewportChrome(context, child, axisDirection);
}

Hi @haifeng94
Can you please provide your flutter doctor -v, your flutter run --verbose and a minimal complete reproducible code sample?
Thank you

Hi @haifeng94
Can you please provide your flutter doctor -v, your flutter run --verbose and a minimal complete reproducible code sample?
Thank you

[✓] Flutter (Channel stable, 2.0.2, on Mac OS X 10.15.4 19E287 darwin-x64,
locale zh-Hans-CN)
• Flutter version 2.0.2 at /Users/haifeng/development/flutter/flutter
• Framework revision 8962f6dc68 (7 days ago), 2021-03-11 13:22:20 -0800
• Engine revision 5d8bf811b3
• Dart version 2.12.1
• Pub download mirror https://pub.flutter-io.cn
• Flutter download mirror https://storage.flutter-io.cn
[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
• Android SDK at /Users/haifeng/Library/Android/sdk
• Platform android-29, build-tools 29.0.3
• Java binary at: /Applications/Android
Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build
1.8.0_212-release-1586-b4-5784211)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 12.4, Build version 12D4e
• CocoaPods version 1.10.1
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 3.6)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin version 45.1.1
• Dart plugin version 192.7761
• Java version OpenJDK Runtime Environment (build
1.8.0_212-release-1586-b4-5784211)
• No issues found!

Hi @haifeng94
Can you please provide your flutter doctor -v, your flutter run --verbose and a minimal complete reproducible code sample?
Thank you

PullAndPush(
    defaultRefreshBoxTextColor: Color(0xff666666),
    defaultRefreshBoxBackgroundColor:
        Theme.of(context).scaffoldBackgroundColor,

    triggerPullController: triggerPullController,

    listView: ListView.builder(
      itemCount: widgetList.length,
      controller: controller,
      physics: scrollPhysics,
      itemBuilder: (BuildContext context, int index) {
        return widgetList[index];
      },
    ),

    loadData: (isPullDown) async {
      await _loadData(isPullDown);
    },
    scrollPhysicsChanged: (ScrollPhysics physics) {
      setState(() {
        scrollPhysics = physics;
      });
    },
  ),

Hi @haifeng94
Can you please provide your flutter doctor -v, your flutter run --verbose and a minimal complete reproducible code sample?
Thank you

Widget buildViewportChrome(
BuildContext context, Widget child, AxisDirection axisDirection) {
if (!isShowLeadingGlow || !isShowTrailingGlow) {
return new GlowingOverscrollIndicator(
showLeading: isShowLeadingGlow,
showTrailing: isShowTrailingGlow,
child: child,
axisDirection: axisDirection,
color: _kDefaultGlowColor,
);
} else {
return super.buildViewportChrome(context, child, axisDirection);
}
}

this error happened just when i pull down too long in ios.

Hi @haifeng94
Can you please provide a minimal complete reproducible code sample that I can copy/paste and run it? Refer to https://stackoverflow.com/help/minimal-reproducible-example to learn how to create a minimal code sample.
Thank you

hi
See the attachment for details
------------------ 原始邮件 ------------------
发件人:                                                                                "flutter/flutter"                                                                                @.>;
发送时间: 2021年3月19日(星期五) 晚上8:10
@.>;
<EMAIL_ADDRESS>主题: Re: [flutter/flutter] when i pull down too quick, that's error report (#78599)
Hi @haifeng94
Can you please provide a minimal complete reproducible code sample that I can copy/paste and run it? Refer to https://stackoverflow.com/help/minimal-reproducible-example to learn how to create a minimal code sample.
Thank you
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Can you received the dart files from email?

Sorry, I'm not sure about that.

i upload my dart file example to my github, just see https://github.com/haifeng94/flutter_example
------------------ 原始邮件 ------------------
发件人:                                                                                "flutter/flutter"                                                                                @.>;
发送时间: 2021年3月19日(星期五) 晚上10:21
@.>;
<EMAIL_ADDRESS>主题: Re: [flutter/flutter] when i pull down too quick, that's error report (#78599)
Can you received the dart files from email?
Sorry, I'm not sure about that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

after this error happen, can not pull down again, this is to say, pull down scroll disappear

i upload my dart file example to my github, just see https://github.com/haifeng94/flutter_example
…

Your code has more than 700 lines of code so it does not seems to be a minimal reproducible code sample.
It seems you are asking for assistance on personal code. Please see https://flutter.dev/community for resources and asking questions like this,
you may also get some help if you post it on Stack Overflow and if you need help with your code, please see https://www.reddit.com/r/flutterhelp/
Closing, as this doesn't seems to be an issue with Flutter itself. If you disagree, please provide a valid minimal reproducible code sample.
Thank you


Not maintained anymore ?

Hi, this looks very use-full for daily life. Is this not maintained anymore ? @mkokho

Hi, unfortunately, it is. No more Go development at my current company.


Invalid credentials after cli update

!    Invalid credentials provided.

Try this https://github.com/heroku/heroku-accounts/issues/20#issuecomment-476369422


Trouble with variables

I'm following the "Young person's guide to Programming in Minecraft". I followed the instructions to execute the command:
/js echo( self, location )
while 'location' was 'Mahon Point'.
But instead of displaying  Mahon Point  in the chat, it returned
CraftPlayer{name=Acetas}  (Acetas is my Minecraft username, in case you wonder)
After that, I tested around for a bit with commands like  "/js echo ( self, self.name )" . I also tried the "greet.js" thing mentioned in the "Your first Minecraft Mod" section. I'm sure I did everything correct, but still, when I executed  "/js greet(self)"  it also just displayed  "CraftPlayer{name=Acetas}" .
Long story short, whenever I execute a command that contains a variable like "self" or "player", it returns "CraftPlayer{name=Acetas}" no matter what the actual command is.

Which version of Java are you using?  java -version
Which OS are you using?
Which Modding lib are you using - SpigotMC or CanaryMod?

I'm actually running Scriptcraft on a SERVER, with SpigotMC, Linux and Java 8.

I've tried to reproduce this with Spigot 1.9, Linux and Java 8. I cannot reproduce this issue.

/js greet(self)
does not work for me either:
[15:02:19 WARN]: Caused by: sun.org.mozilla.javascript.JavaScriptException: JavaException: javax.script.ScriptException: sun.org.mozilla.javascript.EcmaError: TypeError: Cannot read property "name" from undefined (#2) in  at line number 2 (#638)

I cannot reproduce the error either
/js greet('Mahon Point',self)
works fine with Spigot 1.9


Update readme file

Change readme file to be more descriptive  and contain more information. In particular, change the readme to include usage information, inputs and outputs required.

PR addressing this ticket has been created here.


Clarify the "FileShare" role for multi-machine GEneral Purpose ArcGIS Setup

Hi there! We are trying to install a two-server ArcGIS GEneral purpose (and federate that with an existing Portal). We are confused by a few things:

On the example file "GISServer-GeneralPurpose-MultiMachine.json", the "roles" for the first machine includes a role called "FileShare"? What is this for? We have a file share on a nas, separete from the two ArcGIS Machines. Also, the Wiki doesn't list that as a valid option for the roles

Can you clarify what the "FileShareLocalPath" and "FileShareName" exactly are? It would be helpful to have examples on the Wiki page, as it's not clear exactly how those are used.

Right now, this is what I'm going to try:
"FileShareLocalPath":  "\\nas\arcgisdata",
"FileShareName":  "arcgisdata",
(\nas\arcgisdata is where we plan to put ArcGIS server's shared data)
Thanks!

@amarilatitude FileShare role is when you want the DSC script to provision an smb file share for you on the machine which you have specified the role on. "FileShareLocalPath" and "FileShareName" are required only when you FileShare Role on one of your machines.
We do support external file shares. Just give the relative paths for server and portal parameters in Config Data Block. Example - Replace \\\\[Fileshare Machine Name 1]\\[Fileshare Name]\\  with \\nas\arcgisdata

Thanks for the clarification! Would be very useful if the wiki can be updated to include this information.

@amarilatitude Wiki will be updated in a coming release.


Develop a process to load and register plugins

Develop a process to load and register plugins using the Marathon Plugin mechanism as documented in mesosphere/marathon#2827.

Please see mesosphere/marathon#3106 for Marathon implementation details.


Any way to set custom SYSLOG TAG for posix.syslog?

Hello.
For instance,
os.execute("logger -p local0.info -t url-filter-subsystem -u /run/systemd/journal/dev-log" .. logstring )
will allow to change the TAG of syslog record to "url-filter-subsystem". For instance, in syslog an example of TAG is snmpd[29384] in this record:
Nov 27 01:49:12 fw01 snmpd[29384]: error on subcontainer 'ia_addr' insert (-1)
So it's just a name of process/PID what executed the script.
In case of posix.syslog, it always LUA or LUA pid, but I want to customize it.
Are there any ways to do this wit posix.syslog?
I wasn't able to find any additional ways to pas parameters to
posix.syslog(posix.LOG_LOCAL1, 'test lua log string one two three')
in order to customize the tag.

Actually posix.syslog is not a module I have used in my own code, but it is little more than a very thin wrapper around the POSIX C API documented fully here:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/syslog.html
Looking very superficially at your request, it seems like you would need to write a slightly higher level wrapper API to manage the arguments and splice them into the actual message string argument for syslog - I don’t know whether the logger command you cite is built with the posix syslog call, but if so you could port its implementation to Lua.
HTH,
Gary

Actually posix.syslog is not a module I have used in my own code, but it is little more than a very thin wrapper around the POSIX C API documented fully here:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/syslog.html
Looking very superficially at your request, it seems like you would need to write a slightly higher level wrapper API to manage the arguments and splice them into the actual message string argument for syslog - I don’t know whether the logger command you cite is built with the posix syslog call, but if so you could port its implementation to Lua.
HTH,
Gary

Thank you for the comment, I'll dig into the logger command code.

UPD I found solution using the https://github.com/ntd/luasyslog module.
Just customize the syslog(name) name string.
local syslog = require 'logging.syslog'

local logger = syslog('luasyslog1')
logger:debug('Debug message new')

Nov 27 16:55:18 fw01 luasyslog1[40922]: Debug message new

looking at the C code for that module, I think you can do the same thing with luaposix:
local syslog = require ‘posix.syslog’
syslog.openlog(‘luasyslog1’, syslog.LOG_PID)
syslog.syslog(syslog.LOG_DEBUG, ‘New debug log message’)
syslog.closelog()


[heroku] Adding logs

Hi! I'm new to Raycast. It's great!
I would like to suggest a little feature to add to the "Heroku" plugin, I would like to quickly check the logs for my apps. Is this possible? Thanks a lot :)

Hey! Since it doesn't related to the API, I'll close the issue. Can I please ask you to open a new one but with the right template?
To avoid filling the data about the extension it could be easier to create templates through the feedback actions that you can find in a root search or in the store for the extension 😉


More WIN32 install fixes

CI Vulkan-ExtensionLayer build queued with queue ID 57269.

CI Vulkan-ExtensionLayer build queued with queue ID 57269.

CI Vulkan-ExtensionLayer build # 346 running.

CI Vulkan-ExtensionLayer build # 346 failed.

CI Vulkan-ExtensionLayer build queued with queue ID 57278.

CI Vulkan-ExtensionLayer build queued with queue ID 57278.

CI Vulkan-ExtensionLayer build # 347 running.

CI Vulkan-ExtensionLayer build # 347 passed.

Now PDBs are being installed properly:
-- Installing: D:/a/Vulkan-ExtensionLayer/Vulkan-ExtensionLayer/build/./install/bin/VkLayer_khronos_synchronization2.json
-- Installing: D:/a/Vulkan-ExtensionLayer/Vulkan-ExtensionLayer/build/./install/bin/VkLayer_khronos_synchronization2.pdb
-- Installing: D:/a/Vulkan-ExtensionLayer/Vulkan-ExtensionLayer/build/./install/bin/VkLayer_khronos_synchronization2.dll
-- Installing: D:/a/Vulkan-ExtensionLayer/Vulkan-ExtensionLayer/build/./install/bin/VkLayer_khronos_shader_object.json
-- Installing: D:/a/Vulkan-ExtensionLayer/Vulkan-ExtensionLayer/build/./install/bin/VkLayer_khronos_shader_object.pdb
-- Installing: D:/a/Vulkan-ExtensionLayer/Vulkan-ExtensionLayer/build/./install/bin/VkLayer_khronos_shader_object.dll


Fix NullPointerException when response is empty

Fixes the issue reported here: https://github.com/dmfs/oauth2-essentials/issues/78

Sorry for the delayed response. I've thought about this for quite some time and I've come to the conclusion that this is not the right fix for the original issue. This fix only defers the original crash you reported to a later point in the instruction flow. It doesn't fix it. So merging this change would still leave you with a crash, just with a different stack trace.
The original issue is that a null refresh token was passed to the OAuth2 refresh grant flow and null is never a valid refresh token. A better response would be to introduce an explicit null check and throw an IllegalArgumentException instead. I'm not a big fan of that either, though. If someone likes to use null as valid return types they should be prepared for the possibility of NullPointerExceptions. Also in cases like this it doesn't really make much of a difference.
I've talked to Sebastian and I believe he talked to you. I've submitted a PR which avoids passing null and fixes this crash.  The real challenge is to find out where the null originated. In the original code there are two potential sources. One of them would be my responsibility and I'll double check whether there could be the reason.
If you doubt this decision I invite you to have a chat with me over this (for instance on Teams, Sebastian can tell you how to reach me via mail).


[BUG] SMTP setup

Describe the bug
Unable to create SMTP mailer in settings:
To Reproduce
Steps to reproduce the behavior:

Deploy from docker compose
Attempt to set up email in settings
Potentially caused by pasting 587 into the smtp port field, but same issue occurs on max attachment size without touching it so probably unrelated to pasting.

Expected behavior
A clear and concise description of what you expected to happen.
Accept a typed value as entered.
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: [e.g. macOS, Windows, Linux, iOS, watchOS, Android]

Server running from docker compose on ubuntu, accessing from Edge on Windows 10
Additional context
Add any other context about the problem here.

Hey 👋
This looks to just be a client-side validation issue, so the fix should hopefully be quick. I'll try to give it a look before the weekend ends, but I have a couple other items in the queue first. I'll post an update when I put up a fix, thanks for making the report!

OK scratch that - I had some time while my dinner is in the oven 🥘
I think I've fixed the issue locally, I'll make sure the fix goes to nightly sometime tomorrow. I'm taking this as an opportunity to start adding proper testing on the frontend application so little issues like this are less likely to surface as the app continues to get bigger and bigger.
I also noticed the delete functionality was never mapped to the delete button? lol so I quickly added that too

Demo
https://github.com/user-attachments/assets/47cd5911-6c46-4da2-9bb5-c2c4a3a67d2f

This should be resolved now, and will be available in nightly first (once the build gets pushed).
I will try to release 0.0.6 sometime towards the end of this week, which would include the fix


required labels red stars are misplaced when the form is placed inside a scrollable container

See this fiddle for example (i forked it from somewhere else and just adapted the max-height and overflow style attribute of the div container of the form):
https://jsfiddle.net/3fg4o9dv/1/
This is due to the fact that the :after that renders the star is positioned absolute

Well, it seems like removing the position: absolute; line from the formGenerator.css fixes this:
&.required {
  > label:after {
    content: "*";
    font-weight: normal;
    color: Red;
    /* position: absolute; */
    padding-left: 0.2em;
    font-size: 1em;
  }
}

@icebob:
However, I can't figure out how to test this locally? I make the change - and webpack dev will recompile - but the dev examples don't seem to include vfg.css - which doesn't get compiled by npm run dev anyway?
When I add this css file to the index.html<EMAIL_ADDRESS>it loads it, but I think this change: https://github.com/icebob/vue-form-generator/commit/b5d58ac broke the css; this is a separate issue, but it looks like formGenerator line 359 needs to change from this:
  fieldset.vue-form-generator {

to this:
  .vue-form-generator {

@dflock
You can test css in dev mode because in this case the css is not extracted, it is in the bundle. So no need to add css file to html.
The "Grouping" feature breaks the CSS selector fieldset.vue-form-generator because the layout changed (wrapped with a div) and now the div has vue-form-generator class. I removed the absolute style and remove the fieldset from CSS selector. These are fixed this issue, but I don't like that we wrapped the layout with a new field. :(

@gregorius90 https://jsfiddle.net/3fg4o9dv/3/

Thanks - makes sense now. The fact that I couldn't see the vfg.css file - combined with the fieldset.vue-form-generator selector coincidentally being broken, meant that I couldn't see the styles being applied from the bundle either - which is what confused me, sorry!

Don't say sorry, I'm happy that you help me :+1:


Not updated with latest manifest schema 1.7

[Enter feedback here]
Not updated with latest manifest schema 1.7 - please help

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

ID: b449c9ba-a94c-4012-4721-cee5f87eeb8a
Version Independent ID: b2536bbc-eb27-547d-d7f5-bab3ded3bedf
Content: Developer Preview Manifest schema reference - Teams
Content Source: msteams-platform/resources/schema/manifest-schema-dev-preview.md
Product: msteams
GitHub Login: @laujan
Microsoft Alias: lajanuar

This has been updated to v1.7.


Add message to failure tags in junit

This is useful for both RP and Polarion to have correct failure messages.
The matching is not great but it works for beakerlib fine, other issues should be matched as well and if nothing is found whole output is dumped there.

@kkaarreell Now the primary matching is done for whole block BEGIN-FAIL, hope that's what you needed

@KwisatzHaderach Hi, I am sorry, maybe you misunderstood, but BEGIN - FAILED block is just for rlRun command. Other failures won't have begin block bug still we may need to see the preceding output. I was pointing you to a code that we are using today so please either use that one or do not implement it at all. And still I believe that it would be better to populate results.yaml with the failure and do the parsing per configured framework.

Hi @KwisatzHaderach, would you have an example of a junit xml log processed by the updated script? For a beakerlib related log you can e.g. use a log produced by the following testing farm test log
https://artifacts.dev.testing-farm.io/a8a7af19-477d-478f-bc15-4dd1c48079c3/

I extracted the function to have an easy way to execute without Result instance and everything, but this is what would be inside the text field http://pastebin.test.redhat.com/1077466 of the first failed test


Write a C++ program to print pattern 1

Description
Write a C++ program to print pattern 1
Input  : 5

Output :
1
1 2
1 2 3
1 2 3 4
1 2 3 4 5

Contributed by - @PraaneshSelvaraj

How to contribute

Save the solution in program/PrintPattern1.cpp file
Add PrintPattern1.cpp file in print-pattern-1 folder

!assign

@harshraj8843  Please review fed1828d9cdc3c186eaaf600b82e15af679439d9


twinClient.getTwin(device) throws java.lang.RuntimeException: java.nio.charset.IllegalCharsetNameException: java.nio.charset.CharsetICU[UTF-8] on Android

OS and version used:
Android 6.0.1
Java runtime used:
Java 8
SDK version used:
IOT service client 1.17.1
(implementation group: 'com.microsoft.azure.sdk.iot', name: 'iot-service-client', version: '1.17.1')
twinClient.getTwin(device) throws the following exception
java.lang.RuntimeException: java.nio.charset.IllegalCharsetNameException: java.nio.charset.CharsetICU[UTF-8]
    at com.microsoft.azure.sdk.iot.service.auth.IotHubServiceSasToken.buildToken(IotHubServiceSasToken.java:107)
    at com.microsoft.azure.sdk.iot.service.auth.IotHubServiceSasToken.<init>(IotHubServiceSasToken.java:66)
    at com.microsoft.azure.sdk.iot.service.devicetwin.DeviceOperations.request(DeviceOperations.java:90)
    at com.microsoft.azure.sdk.iot.service.devicetwin.DeviceTwin.getTwinOperation(DeviceTwin.java:107)
    at com.microsoft.azure.sdk.iot.service.devicetwin.DeviceTwin.getTwin(DeviceTwin.java:88)

The crash occurs only for Java 8.
The exception is caused at line number 80 in the class IotHubServiceSasToken.java due to the following statement:
String.valueOf(StandardCharsets.UTF_8));
Using StandardCharsets.UTF_8.displayName() would prevent the exception.
However since I need to use Java 8, is there a work around to get this working?

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

ID: 4a916075-fc2a-629b-7dfe-20400ec2dcc1
Version Independent ID: d4ecda58-12b7-9b47-4da5-b16a1356e790
Content: Get started with Azure IoT Hub device twins (Java)
Content Source: articles/iot-hub/iot-hub-java-java-twin-getstarted.md
Service: iot-hub
GitHub Login: @wesmc7777
Microsoft Alias: wesmc

@DeveloperBeginner Thanks for taking the time for bringing this to our attention. Would you please open an issue on the SDK? https://github.com/Azure/azure-iot-sdk-java
If you are interested you could potentially create a pull request with the fix.

Hi @DeveloperBeginner did you see my previous comment?

Is there no way to get it working currently?

If your proposed fix works:

Open an issue so the SDK team acknowledges the bug and also you can express that you want to create a Pull Request with the fix (if you want to)
You can create a fork of the repo and fix that line of code
(If interested in contributing) Create a Pull Request against the SDK repo  referencing the issue number you opened

I guess in the meantime while your Pull Request gets reviewed you could use your forked copy with the fix.

Hi @DeveloperBeginner I hope  my previous response was useful

Yes I am using a forked copy as of now. Thanks for the response. I shall raise a pull request.

@DeveloperBeginner That's awesome! We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Added an attribute to enable setting the point on ee to apply force on

So we could set this parameter in the yaml file instead of hard coding it.

@thomascent Hey Tom I cannot merge this PR, as I am not an authorized user. Could you please merge it? Thanks a lot!


atx: register with multiple poet servers

Description

for stability, it's best for node to register with multiple poet servers.
currently it build ATX eagerly whenever a poet proof is received. to use multiple poet services, we should wait till the last minute to build ATX, and pick the poet proofs with the highest tick.

Pending design proposal by @noamnelke.

Pending design proposal by @noamnelke.

The design was proposed in https://community.spacemesh.io/t/redundant-poet-registration/310/1

@countvonzero, the current idea was to use PM as a placeholder for research work. So PM would have both "epics" and meta containers for Research work.

@countvonzero, the current idea was to use PM as a placeholder for research work. So PM would have both "epics" and meta containers for Research work.

so the expected workflow for a given topic T is
A. create research meta on T in PM repo
B. create research forum thread on T for discussion
C. once B conclude, create epic on T in PM repo
D. create go-spacemesh issues based on epic T
do i understand correctly?


skip promo popup when logging in

Added a get request which effectively skips the promotion page.
I couldn't seem to make login work by opening a browser and logging in before using this splitter. Instead I've tweaked the login process such that it will skip the promotion page for the user automatically.

Thanks for making this project possible!!! Made my life much easier should have found this years ago when I started splitting my ATT plan haha.
Will do the formatting once I get home. Btw, I’m not familiar with the python setup script, how would you compile and test?

I'm glad you find this useful. I'm curious how you find about it?

I always wanted to write a script similar to this one but procrastinated :/
Then I decided to lookup if there's any luck on GitHub and I found you made this project!! Really appreciate your effort.

LGTM. I'll merge it in and upload to pypi.


Widget not diplaying properly in forms.

Hey, I am quite new to Django and was trying to implement the sortedm2m widget in my forms. The code I used is

class TrackForm(forms.ModelForm):
title = forms.CharField(max_length=128, help_text="Please enter the track title.")
views = forms.IntegerField(widget=forms.HiddenInput(), initial=0)
genres = SortedMultipleChoiceField(queryset=Genre.objects.all())

but I got this. It is plain list of labels without the scroller, also multiple objects cannot be added only one of the selected object is added to the Trackform data. I am thinking, it may be due failing widget.

Hi, sorry for not responding to this properly. Did you manage to fix the problem for you?
I'm closing this issue for now as it is quite old. Feel free to reopen it if you still have a problem getting it to work.


ENH: Change ivar name in itk::IntermodesThresholdImageFilter

Change the m_MaxSmoothingIterations ivar name in
itk::IntermodesThresholdImageFilter
to m_MaximumSmoothingIterations
so that the Set/Get methods match the ones previous to the change in
6dc4948017858006200d57491459c49b3cbc5765.
PR Checklist

[X] No API changes were made (or the changes have been approved)
[X] No major design changes were made (or the changes have been approved)
[ ] Added test (or behavior not changed)
[ ] Updated API documentation (or API not changed)
[ ] Added license to new files (if any)
[ ] Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
[ ] Added ITK examples for all new major features (if any)

The API change was inadvertent and recent (1-2 days ago), so legacy support is not needed.

@thewtex as Dženan said, the change was introduced in a commit that was merged yesterday, and I just realized about this today. So this is quick move to avoid the API break that commit introduced and that I failed to spot.

Thanks for the fix. Looks like there is a big need for better testing here.


build: update integration project to one with firestore

Can you point me to an example of how to do that?

https://github.com/googleapis/java-bigtable/blob/master/synth.py#L57

Thanks, added the exclude to synth.py


Dead link: winnower

This link is dead
https://winnower-production.s3.amazonaws.com/papers/5577/v1/pdf/5577-a-step-by-step-guide-for-organizing-open-collaborative-brainhack-events.pdf
Seems all winnower content moved here:
https://www.authorea.com/inst/26392
But I cannot find this publication there.
Supposed to be this one.
The Neuro Bureau (2016). A step by step guide for organizing open collaborative “Brainhack” events. the Winnower

fixed by #301


Write v2 documentation about template functions

The template functions are currently undocumented. We should document them before releasing v2. https://github.com/cloudspannerecosystem/yo/pull/114 may be enough, but we need to reexamine it.

Resolved by https://github.com/cloudspannerecosystem/yo/pull/114