Is it possible to remove a package ?

Hi,  I registered VTKView.jl , which will have several serious binary dependencies which will take some time to become stable. So I continue to develop the package complex in my own registry. The idea is to transfer things here at a certain point of time. In order to avoid confusion I think it would be better to remove it here. Would this be possible ?

We generally do not allow you to delete packages from the general registry.

It is perfectly fine to work on the package in your own registry, and then, whenever you are ready, start making releases again in the General registry.
There's no need to delete the package.

Ok then that's what I'll do.


Different banner text depending on the language of the site

Hello. How to display different banner text depending on the language of the site

Slated for sometime in v4 we are looking to add language support: #570
Stay tuned for that release, I will link the PR here when it happens.


Feature/session storage

The cookie previously contained sensitive user information which poses
a security risk.

Hi,
I see the potential problem, but in this way the semantic of getCurrentUser() is totally different. It no longer returns the current user with all their attribute but the session token.
getCurrentUser() should ask to the server the actual data instead of rely on cookies/local storage, and a new getSessionToken() should be implemented.
WDYT?


zPositionIfMatched Removed

Shared transition of views were working perfectly fine while push and pop from one viewController to another using zPositionIfMatched. Please add this functionality again.. Now this type of animation can only be added while using presentViewController.

zPosition is now a animatable property. If you want it set the zPosition. Hero will now read the layer's zPosition instead.

Also with the introduction of coordinate space. you might need the 'useGlobalCoordinateSpace' modifier to make some animation functions. Check out the usage guide on coordinate space.

you can use the new .beginWithIfMatch modifiers in your case.
Here is how:
.beginWithIfMatched(modifiers:.zPosition(5))

This should behave the same way as .zPositionIfMatched(5) in the previous versions.


PopupMenu: add_submenu() documentation does not tell that submenu should already exist

Godot version
3.3.2 stable AND v4.0.dev.custom_build [a0d800e96]
System information
Arch Linux (kernel 5.12.15-arch1-1, X11)
Issue description
PopupMenu's add_submenu_item() description reads:
Adds an item that will act as a submenu of the parent PopupMenu node when clicked. The submenu argument is the name of the child PopupMenu node that will be shown when the item is clicked.

An id can optionally be provided. If no id is provided, one will be created from the index.

First times i read this, i thought that this method will actually create the PopupMenu subnode, and the name here is so that i can access the child node like this (wow, github actually has a dedicated gdscript highlighting):
extends MenuButton

func _ready():
	get_popup().add_submenu_item("submenu label","submenu")
	get_popup().get_node("submenu").add_item("submenu item")

On 4.0 this throws a misleading (and buggy) error of previously freed instance (https://github.com/godotengine/godot/issues/48891), which makes things even worse, since now i think that my submenu WAS created but some incredibly evil bugforce insta-erased it.
It took me a trip to the godot sources to find an example of how godot editor itself does this (editor_node.cpp).
vcs_actions_menu = VersionControlEditorPlugin::get_singleton()->get_version_control_actions_panel();
vcs_actions_menu->set_name("Version Control");
vcs_actions_menu->connect("index_pressed", callable_mp(this, &EditorNode::_version_control_menu_option));
p->add_separator();
p->add_child(vcs_actions_menu);
p->add_submenu_item(TTR("Version Control"), "Version Control");
vcs_actions_menu->add_item(TTR("Set Up Version Control"), RUN_VCS_SETTINGS);
vcs_actions_menu->add_item(TTR("Shut Down Version Control"), RUN_VCS_SHUT_DOWN);

So, the right way to do this is :
extends MenuButton

func _ready():
	var submenu = PopupMenu.new()
	submenu.set_name("submenu")
	submenu.add_item("submenu item")
	get_popup().add_child(submenu)
	get_popup().add_submenu_item("submenu label","submenu")

The documentation (or, ideally, function's name) should reflect the fact that it is the reader's job to get a correctly named submenu there. Example code like above (but above is written from the MenuButton point of view) would also be nice.
Steps to reproduce

Try to forget all you know as a Godot dev.
Look at the documentation of add_submenu_item().

Minimal reproduction project
No response

on the improvement side of things, comparing my expectations and how it actually works, it is hard not to notice that something like this would be a much easier way:
submenu = add_submenu_item("submenu label")
submenu.add_item("submenu item")

Maybe this is how it should actually work?

Yeah having to reference by the nodes name feels pretty yuck.

Easily misunderstood and difficult to use.it took me two hours to test.

When deal with another bug, I found the doc is easily misunderstood for me too.


MultiMiner no hash rate on nicehash

Im trying to mine bitcoins with my 2 BFL Jalapeno ASIC miners on the NiceHash pool, It says a worker is connected but its not showing any hashrate. The hashrate in MultiMiner is working fine and as far as i can tell everything is configured correctly.

Hi
how did you configure it?

is this what you mean?

still not working...

neither in minegarte

Try using the Process Log screen to launch the Backend Miner directly (stop mining in MultiMiner first). If the issue persists, contact the author of the Backend Miner in question.

https://github.com/nwoolls/MultiMiner/wiki/Process-Log
https://github.com/nwoolls/MultiMiner/wiki/Backend-Miners

For mining on NiceHash or other "multi" pools, make sure you are using their guide for configuring BFGMiner. Check the MultiMiner help for passing additional args to the Backend Miner:

https://www.nicehash.com/asic-mining

Specifically - ensure you are using #xnsub in the pool URL or click the Features button in MultiMiner and click Extra-nonce Subscribe.


Help with updating plugin library dependencies properly in Node 22+

We have reached a point where our project dependencies will no longer load properly with a standard npm i. In order to get the modules to load with their dependencies, we have to enter npm i --legacy-peer-deps. This is obviously a band-aid and needs to be fixed. This is outside of my node/coding level expertise. @nmn or anyone else listed here, can you help upgrade the codebase?

I'll take a look later this week

Thanks @aaronpoweruser
FWIW, I am personally using node v22, which should be active for the next year. I think it would be fine to make that the base

Result of npm outdated
(node:21902) ExperimentalWarning: CommonJS module /opt/homebrew/lib/node_modules/npm/node_modules/debug/src/node.js is loading ES Module /opt/homebrew/lib/node_modules/npm/node_modules/supports-color/index.js using require().
Support for loading ES Module in require() is an experimental feature and might change at any time
(Use node --trace-warnings ... to show where the warning was created)
Package                              Current   Wanted   Latest  Location                                          Depended by
@babel/cli                            7.21.0   7.25.9   7.25.9  node_modules/@babel/cli                           plugins
@babel/core                           7.21.0   7.26.0   7.26.0  node_modules/@babel/core                          plugins
@babel/eslint-parser                  7.19.1   7.25.9   7.25.9  node_modules/@babel/eslint-parser                 plugins
@babel/generator                      7.21.1   7.26.2   7.26.2  node_modules/@babel/generator                     plugins
@babel/parser                         7.21.2   7.26.2   7.26.2  node_modules/@babel/parser                        plugins
@babel/preset-env                     7.20.2   7.26.0   7.26.0  node_modules/@babel/preset-env                    plugins
@babel/preset-flow                    7.18.6   7.25.9   7.25.9  node_modules/@babel/preset-flow                   plugins
@babel/preset-react                   7.18.6   7.25.9   7.25.9  node_modules/@babel/preset-react                  plugins
@codedungeon/gunner                   0.77.0   0.77.0   0.80.1  node_modules/@codedungeon/gunner                  plugins
@rollup/plugin-alias                   4.0.3    4.0.4    5.1.1  node_modules/@rollup/plugin-alias                 plugins
@rollup/plugin-babel                   5.3.1    5.3.1    6.0.4  node_modules/@rollup/plugin-babel                 plugins
@rollup/plugin-commonjs               19.0.2   19.0.2   28.0.1  node_modules/@rollup/plugin-commonjs              plugins
@rollup/plugin-json                    4.1.0    4.1.0    6.1.0  node_modules/@rollup/plugin-json                  plugins
@rollup/plugin-node-resolve           13.0.4   13.0.4   15.3.0  node_modules/@rollup/plugin-node-resolve          plugins
babel                                 6.23.0   6.23.0   5.8.38  node_modules/babel                                plugins
bcrypt                                 5.0.1    5.0.1    5.1.1  node_modules/bcrypt                               plugins
browserify                            17.0.0   17.0.1   17.0.1  node_modules/browserify                           plugins
chroma-js                              2.4.2    2.6.0    3.1.2  node_modules/chroma-js                            plugins
chrono-node                            2.6.3    2.7.7    2.7.7  node_modules/chrono-node                          plugins
clipboardy                             3.0.0    3.0.0    4.0.0  node_modules/clipboardy                           plugins
commander                              8.3.0    8.3.0   12.1.0  node_modules/commander                            plugins
concurrently                           6.5.1    6.5.1    9.1.0  node_modules/concurrently                         plugins
contentful-html-rich-text-converter    1.0.9    1.0.9   1.0.11  node_modules/contentful-html-rich-text-converter  plugins
date-fns                              2.29.3   2.30.0    4.1.0  node_modules/date-fns                             plugins
dayjs                                 1.10.6   1.10.6  1.11.13  node_modules/dayjs                                plugins
documentation                         13.2.5   13.2.5   14.0.3  node_modules/documentation                        plugins
enquirer                               2.3.6    2.4.1    2.4.1  node_modules/enquirer                             plugins
eslint                                7.32.0   7.32.0   9.16.0  node_modules/eslint                               plugins
eslint-config-prettier                 8.6.0   8.10.0    9.1.0  node_modules/eslint-config-prettier               plugins
eslint-plugin-flowtype                5.10.0   5.10.0    8.0.3  node_modules/eslint-plugin-flowtype               plugins
eslint-plugin-import                  2.27.5   2.31.0   2.31.0  node_modules/eslint-plugin-import                 plugins
eslint-plugin-no-floating-promise      1.0.2    1.0.2    2.0.0  node_modules/eslint-plugin-no-floating-promise    plugins
eslint-plugin-react                   7.32.2   7.37.2   7.37.2  node_modules/eslint-plugin-react                  plugins
eslint-plugin-unused-imports           1.1.5    1.1.5    4.1.4  node_modules/eslint-plugin-unused-imports         plugins
fast-glob                             3.2.12    3.3.2    3.3.2  node_modules/fast-glob                            plugins
findup-sync                            4.0.0    4.0.0    5.0.0  node_modules/findup-sync                          plugins
flow-bin                             0.210.2  0.245.2  0.255.0  node_modules/flow-bin                             plugins
fsevents                               2.3.2    2.3.3    2.3.3  node_modules/fsevents                             plugins
fuse.js                                6.6.2    6.6.2    7.0.0  node_modules/fuse.js                              plugins
inquirer                               8.2.5    8.2.6   12.1.0  node_modules/inquirer                             plugins
jest                                  27.5.1   27.5.1   29.7.0  node_modules/jest                                 plugins
jest-silent-reporter                   0.5.0    0.5.0    0.6.0  node_modules/jest-silent-reporter                 plugins
jest-spec-reporter                    1.0.17   1.0.17   1.0.19  node_modules/jest-spec-reporter                   plugins
mathjs                                11.6.0  11.12.0   14.0.0  node_modules/mathjs                               plugins
mermaid                               10.1.0   10.9.3   11.4.1  node_modules/mermaid                              plugins
mkdirp                                 1.0.4    1.0.4    3.0.1  node_modules/mkdirp                               plugins
moment                                2.29.1   2.29.1   2.30.1  node_modules/moment                               plugins
node-gyp                               9.3.1    9.4.1   10.2.0  node_modules/node-gyp                             plugins
node-notifier                         10.0.0   10.0.0   10.0.1  node_modules/node-notifier                        plugins
plotly.js-dist-min                    2.32.0   2.35.2   2.35.2  node_modules/plotly.js-dist-min                   plugins
prettier                               2.8.4    2.8.8    3.4.1  node_modules/prettier                             plugins
react                                 18.2.0   18.3.1   18.3.1  node_modules/react                                plugins
react-circular-progressbar           MISSING    2.1.0    2.1.0  -                                                 plugins
react-data-table-component             7.5.3    7.6.2    7.6.2  node_modules/react-data-table-component           plugins
react-day-picker                      8.10.1   8.10.1    9.4.1  node_modules/react-day-picker                     plugins
react-dom                             18.2.0   18.3.1   18.3.1  node_modules/react-dom                            plugins
react-error-boundary                  4.0.13    4.1.2    4.1.2  node_modules/react-error-boundary                 plugins
react-loader-spinner                   5.3.4    5.4.5    6.1.6  node_modules/react-loader-spinner                 plugins
react-select                           5.7.0    5.8.3    5.8.3  node_modules/react-select                         plugins
rollup                                2.79.1   2.79.2   4.28.0  node_modules/rollup                               plugins
rollup-plugin-visualizer               5.9.0   5.12.0   5.12.0  node_modules/rollup-plugin-visualizer             plugins
rxjs                                   6.6.7    6.6.7    7.8.1  node_modules/rxjs                                 plugins
showdown                               1.9.1    1.9.1    2.1.0  node_modules/showdown                             plugins
sprintf-js                             1.0.3    1.0.3    1.1.3  node_modules/sprintf-js                           plugins
strftime                              0.10.0   0.10.0   0.10.3  node_modules/strftime                             plugins

I can do this fairly quickly so I'll put up a PR. My question is if people would prefer switching to a different package manager for the repo?
Both pnpm and bun are significantly faster and generally more reliable. I recommend switching to bun for this repo instead of Node. Bun is essentially a drop-in replacement for Node but it uses the JavasrciptCore JS engine instead of V8. This is the same engine that Noteplan uses internally and so should work more reliably.
The counter-point is that Bun on Windows is somewhat new and it's another new thing for people to install.

#606 created

@nmn I think we're open to your advice on the package manager. We can adapt
to anything, and there are not that many of us. Nobody on Windows so that
is not a limitation.
ᐧ
On Wed, Dec 4, 2024 at 1:55 PM Naman Goel @.***> wrote:

I can do this fairly quickly so I'll put up a PR. My question is if people
would prefer switching to a different package manager for the repo?
Both pnpm and bun are significantly faster and generally more reliable. I
recommend switching to bun for this repo instead of Node. Bun is
essentially a drop-in replacement for Node but it uses the JavasrciptCore
JS engine instead of V8. This is the same engine that Noteplan uses
internally and so should work more reliably.
The counter-point is that Bun on Windows is somewhat new and it's another
new thing for people to install.
—
Reply to this email directly, view it on GitHub
https://github.com/NotePlan/plugins/issues/604#issuecomment-2518639685,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACEI6VDUT7KGN4OQI2UWGSL2D5237AVCNFSM6AAAAABS36QZZKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJYGYZTSNRYGU
.
You are receiving this because you authored the thread.Message ID:
@.***>

@dwertheimer I will try to do a big improvement to the setup sometime soon then. There should be fewer dependencies and everything should compile faster.
I also think it would be useful to switch from Flow to Typescript just because that is the industry standard now.
Anyway, if it's too much work, I'll bail!

@nmn Thanks so much. This all looks good. The plugins all build and the tests all pass. Of course we don't have near 100% coverage, but it all seems good to merge when you are ready.
Fingers crossed on all of this!

I've switched to node 22 and then npm i.
npc has stopped working, with this error:
Error: Cannot find module 'rollup-plugin-terser'
Require stack:
- /Users/jonathan/GitHub/NP-plugins/scripts/rollup.js
...

I've had a go at fixing this, but its saying its a deprecated package, and I'm beyond my limited understanding.
Anyway, I'd appreciate someone looking at this (@nmn ?) soonest, and certainly before the much bigger change I see brewing ...  Thanks.

@jgclark Go to /Users/jonathan/GitHub/NP-plugins/scripts/rollup.js and remove rollup-plugin-terser from the list of plugins being applied.
This dependency was removed because terser is a minifier but we never use it to actually minify the output.

Thanks, @nmn. I'd not wanted to do that as I could see that the terser was being used in rollup.js. Anyway, with your encouragement I've commented that out, and it now builds and runs again. Thanks.


Fix the job server service hangs on when set a no privileged path

What changes are proposed in this pull request?
Fix the job server service hangs on when  set alluxio.master.journal.folder a no privileged path.
Why are the changes needed?
Fix the job server service hangs on when  set alluxio.master.journal.folder a no privileged path.
Because of ratis's bug. See this pr https://github.com/apache/ratis/pull/477.
Does this PR introduce any user facing changes?
No

Codecov Report

Merging #13906 (746109c) into master (4ec7832) will decrease coverage by 20.99%.
The diff coverage is 0.00%.

@@              Coverage Diff              @@
##             master   #13906       +/-   ##
=============================================
- Coverage     43.58%   22.59%   -21.00%
+ Complexity     9151     4227     -4924
=============================================
  Files          1395     1395
  Lines         81161    81164        +3
  Branches       9873     9875        +2
=============================================
- Hits          35371    18335    -17036
- Misses        42848    61607    +18759
+ Partials       2942     1222     -1720

Impacted Files
Coverage Δ

...alluxio/master/journal/raft/RaftJournalSystem.java
59.25% <0.00%> (-0.58%)
:arrow_down:

...n/java/alluxio/master/AlluxioJobMasterProcess.java
0.00% <0.00%> (ø)

...common/src/main/java/alluxio/grpc/GrpcService.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...common/src/main/java/alluxio/time/TimeContext.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...mmon/src/main/java/alluxio/metrics/MetricInfo.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...mmon/src/main/java/alluxio/time/ThreadSleeper.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...mon/src/main/java/alluxio/concurrent/LockMode.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...mon/src/main/java/alluxio/shell/CommandReturn.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...mon/src/main/java/alluxio/util/ExceptionUtils.java
0.00% <0.00%> (-100.00%)
:arrow_down:

...mon/src/main/java/alluxio/util/WaitForOptions.java
0.00% <0.00%> (-100.00%)
:arrow_down:

... and 592 more

Continue to review full report at Codecov.

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

@ggezer since this is journal related, I will leave to you to review.

ping @ggezer

alluxio-bot, merge this please


using "is" with gdscript class on both sides fail

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Ubuntu 17.04, godot master da144fed4c49133a93b3b83cfc665352c0af351a
Issue description:
Checking if an instance that inherits a gdscript class is an instance of a gdscript class fails with Internal Script Error - opcode #31 (report please)
Pretty sure this was introduced in https://github.com/godotengine/godot/pull/11518 just like https://github.com/godotengine/godot/issues/11595
Steps to reproduce:
class ClassA:
	var x

func _ready():
	ClassA.new() is Node # works
	Node.new() is ClassA # works
	ClassA.new() is ClassA # Internal Script Error - opcode #31

It also fails on checking for classes via files.
	if (!ring_taken && (body is preload ("res://Scripts/player.gd"))): - fails with the same error as above.

@Sslaxx checking with preloaded class is supposed to work, that's how I discovered this bug in my project.
AFAIK the difference between load and preload is that preload loads at parse time, so preload call wont block when called the first time like load would.
And yea it looks like #11596 has transformed to be a duplicate of this issue, or maybe this issue is the duplicate now..

This is fixed in 6c15c23889772ce4986765e801be3f216ed50a11


Compatibility fix mapping drivers is not working.

include_once(Doctrine/Persistence/Mapping/Driver/AnnotationDriver.php): Failed to open stream: No such file or directory
..vendor/doctrine/mongodb-odm/lib/Doctrine/ODM/MongoDB/Mapping/Driver/CompatibilityAnnotationDriver.php:12

use Doctrine\Persistence\Mapping\Driver\AnnotationDriver as PersistenceAnnotationDriver;
use Doctrine\Persistence\Mapping\Driver\MappingDriver;

use function class_exists;

if (class_exists(PersistenceAnnotationDriver::class)) {  // line 12

adding into composer.json
"doctrine/orm": "2.11.*",
fixes it temporary but not sure why that compatibility fix is needed if it is not working.
So now I can not use correct MappingDriver.
Can we have version without compatibility fix?

Sounds more like you are using a buggy autoloader. You use Composer, right? If yes, what version?

Closing due to lack of response.


chore: codegen acir opcodes after renaming arithmetic to assertzero

Please provide a paragraph or two giving a summary of the change, including relevant motivation and context.
Arithmetic ACIR opcode has been renamed to AssetZero, but it was not 'codegened' in BB. This PR takes care of this.
Checklist:
Remove the checklist to signal you've completed it. Enable auto-merge if the PR is ready to merge.

[ ] If the pull request requires a cryptography review (e.g. cryptographic algorithm implementations) I have added the 'crypto' tag.
[ ] I have reviewed my diff in github, line by line and removed unexpected formatting changes, testing logs, or commented-out code.
[ ] Every change is related to the PR description.
[ ] I have linked this pull request to relevant issues (if any exist).

Benchmark results
Metrics with a significant change:

note_successful_decrypting_time_in_ms (8): 360 (-25%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit a2b267bf and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
128 txs

l1_rollup_calldata_size_in_bytes
45,444
179,588
716,132

l1_rollup_calldata_gas
222,828
867,920
3,448,208

l1_rollup_execution_gas
866,937
3,745,973
23,304,973

l2_block_processing_time_in_ms
1,329 (-2%)
5,091
20,943

note_successful_decrypting_time_in_ms
:warning: 360 (-25%)
1,120 (+1%)
4,109 (+1%)

note_trial_decrypting_time_in_ms
72.3 (-19%)
36.2 (-8%)
142 (-1%)

l2_block_building_time_in_ms
14,898
59,309
237,920

l2_block_rollup_simulation_time_in_ms
10,584
42,242
169,784

l2_block_public_tx_process_time_in_ms
4,282
16,980 (-1%)
67,809

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
15,386 (+2%)
29,246 (+1%)

note_history_successful_decrypting_time_in_ms
2,943 (+10%)
5,348 (-3%)

note_history_trial_decrypting_time_in_ms
135 (+23%)
171 (+16%)

node_database_size_in_bytes
3,617,128
3,726,441

pxe_database_size_in_bytes
29,923
59,478

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
211
44,709
25,561

private-kernel-ordering
137
30,953
14,809

base-rollup
1,079
128,374
881

root-rollup
82.6 (-2%)
4,088
889

private-kernel-inner
287
71,236
25,561

public-kernel-private-input
203
31,891
25,561

public-kernel-non-first-iteration
200
31,933
25,561

merge-rollup
9.72
2,608
881

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
2 leaves
8 leaves
16 leaves
32 leaves
64 leaves
128 leaves
512 leaves
1024 leaves
2048 leaves
8192 leaves

batch_insert_into_append_only_tree_ms
11.1
88.5
13.7 (-2%)
17.8 (-1%)
23.7 (+1%)
50.0
89.0 (+1%)
241 (-2%)
470
909
3,562

batch_insert_into_indexed_tree_ms
N/A
N/A
N/A
64.6
N/A
59.7 (+1%)
110 (-1%)
361 (-1%)
736
1,402
5,547

Miscellaneous
Transaction sizes based on how many contracts are deployed in the tx.

Metric
0 deployed contracts
1 deployed contracts

tx_size_in_bytes
15,487
31,877

Transaction processing duration by data writes.

Metric
0 new commitments
1 new commitments

tx_pxe_processing_time_ms
372 (+8%)
970

Metric
1 public data writes

tx_sequencer_processing_time_ms
529


add flake.nix

This allow to build the project executables with nix.
nix build . # builds teosd and teos-cli

nix build .#plugin # builds watchtower-client

UPDATE: worth mentioning experimental features nix-command and flake are required, either enabled via the command or globally

Thanks!
Could this tolerate being in a sub/nested directory (e.g. dist).
There are probably other package managers could build/use teos in a certain way. I imagine lots of these files in the projects root directory gonna be messy in the future.

Putting it in a sub-directory would prevent most of the usefulness. From the docs:

A flake refers to a file-system tree whose root directory contains the Nix file specification called flake.nix.

The standard position allows to run the executable also with this syntax:
nix run github:talaia-labs/rust-teos # this is for master, it's possible to use a specific branch or commit hash

@seberm you may be interested in this, given https://github.com/fort-nix/nix-bitcoin/pull/543
Would you mind giving it a try if so?

Works for me, but I don't know if this flake.nix is idiomatic.

Is this fixable by running it though nixfmt?

I made a few changes and got this working, see my fork here here
@RCasatta let me know if you want to fix up your PR or I can open a new one.

Works for me, but I don't know if this flake.nix is idiomatic.

Is this fixable by running it though nixfmt?

I added nixfmt as well.

Please go ahead with a new one, thanks!


Documentation error

the link on how to upgrade to Devise 2.0 points to an empty page,
How To: Upgrade to Devise 2.0  => https://github.com/plataformatec/devise/wiki/How-To:-Upgrade-to-Devise-2.0

Fixed. Thanks


Uncaught TypeError: Cannot set property 'azblob' of undefined

Hi,
Not sure what I did wrong, I am trying to use the v10 azure-storage.blob.js into my solution but when I import it, it keep throwing me error of 'azblob' underfined, did i do wrong from import part to my vue solution?

Also if I referring the Azure Storage from npm package and i get another error, this maybe driving me a little bit crazy...

@alpha128 Try uploadBrowserDataToBlockBlob. uploadFileToBlockBlob is only in Node.js runtime according to the API reference.

Okay... how about downloading it? now I successful to uploadblob but download doesnt prompt my browser anything with the code provided from the readme

@alpha128 Do you want to download blob data into memory? Or pop up a browser download window?
For previous, I believe your code has already downloaded the data into your blob or text variable.
For 2nd, you can display the download link blobURL.url, and let browser viewers click the link for download.
You can also generate a download link according to your blob variable. See this sample.
https://jsfiddle.net/koldev/cW7W5/

Close since answer. Please reopen is there is any question.


Sync with master changes

What does this PR do?
git cherry-pick bf5fa3517dd7f3641b5c164a59c16d8ea5517ce2..8bc78a6596538a14bd04d246d45668b625f638b1

It is very strange, that the previous PR ran test-on-tpus (fabric) (correctly), but this one somehow wants to go back to test-on-tpus (lite)which got renamed. cc @Borda


feat(hub): adding snapshot download method

Description
We can now create a snapshotDownload method similator to the snapshot_download of the PY lib^1, clone to the cache (only cache supported for now) a repository (either model, space or dataset)
Related issues/PR
With the amazing help of @coyotte508 we were able to merge the following changes

https://github.com/huggingface/huggingface.js/pull/1034
https://github.com/huggingface/huggingface.js/pull/1031
https://github.com/huggingface/huggingface.js/pull/999

Which allow this PR to provide a python compliant clone of a hugging face repository to the cache directory.
Testing

[x] unit tests are covering the new feature

Manually
await snapshotDownload({
	repo: {
		name: 'OuteAI/OuteTTS-0.1-350M',
		type: 'model',
	},
});

assert using the huggingface-cli tool (python)
$: huggingface-cli scan-cache
REPO ID                             REPO TYPE SIZE ON DISK NB FILES LAST_ACCESSED     LAST_MODIFIED     REFS LOCAL PATH
----------------------------------- --------- ------------ -------- ----------------- ----------------- ---- ----------------------------------------------------------------------------------
OuteAI/OuteTTS-0.1-350M             model           731.6M       14 5 minutes ago     5 minutes ago     main /home/axel7083/.cache/huggingface/hub/models--OuteAI--OuteTTS-0.1-350M

And can you add a small section in packages/hub/README.md regarding cache management? 🙏

Yes np!

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

I just reviewed them and logic is good. I'm a bit worried though about the lack of locks when downloading an individual file. In huggingface_hub, we use filelock which guarantees that a single file is never downloaded twice concurrently. In the js implementation, since the (...).incomplete filename is deterministic, it can happen that 2 processes are downloading bytes to the same file concurrently (and in this case I expect one process to crash?). Is there an equivalent that could be used in JS to avoid concurrency issues?

This is a very complicated problem actually, I've just spent an hour investigating.
The python library filelock use a very complex mechanism to lock the file in a way, that other processes cannot delete the file.
The problem is that the python library apply a real lock on windows it uses msvcrt which provide advanced File Operations and on unix system fcntl
There are using platform dependent mechanism to provide a real lock.
JS packages
There is currently two well known packages:

https://github.com/npm/lockfile seems to only create the file, and check for existence.
https://www.npmjs.com/package/proper-lockfile uses the mkdir method to lock a file.

If we open a file in write mode, no two processes can open it, so it suffices as a lock?
In any case, let's not add additional deps

If we open a file in write mode, no two processes can open it at the same time, so it suffices as a lock?

No this is not the case in Node sadly, you can check it by deleting the  file through the windows explorer.
const file = await open(path, 'w');

setTimeout(async () => {
    await file.close();
}, 60_000);

no two processes can open it at the same time

What happens if we try to do so? An error is triggered? If that's the case, we could catch the error, wait while the file is been downloaded by the other process and then continue without downloaded once the first process has completed.
I'm raising the question mainly because concurrency issues caused quite some trouble at some point on the Python side. When using multiple GPUs with 1 GPU == 1 process, each process tries to download the weight file at the same time - hence causing the concurrency issue. I guess this is much less likely to happen in JS but still want to raise the question.

What happens if we try to do so? An error is triggered?

No error are triggered sadly, we may check for file existence, but the python implementation is complex and change the file descriptor using C code to interact with os level structure.
We could from the JS detect if the file is locked, so the JS would avoid downloading the file if the python is doing it, but we cannot prevent the python to do it if the JS is downloading it :/

Note that we can open a file in Node.JS with mode "wx", so it fails if the file already exists.

Note that we can open a file in Node.JS with mode "wx", so it fails if the file already exists.

Yes, but we can stat to check if it exists, that not the issue, the problem is telling the python that we lock the file, which we cannot :(

well @Wauplin is the maintainer of the python lib :)

Ah, I wasn't thinking of a lock shared between JS and Python (that seems much less likely to happen). I think handling the concurrency issue between JS processes is already good enough

Ah, I wasn't thinking of a lock shared between JS and Python (that seems much less likely to happen). I think handling the concurrency issue between JS processes is already good enough

Oh yeah, if that's the only thing we can definitely use https://github.com/npm/lockfile

We can copy the mechanism internally (or just use wx write mode when downloading files) - but let's not add dependencies


#23976 : Resolve ImportError: cannot import name cloud on s390x

As per comments in #23976, adding check for s390x

checked logs for failing CI builds. Could see error  AttributeError: class Tokenizer has no attribute '__mro__'
Not sure if its related to the code patch introduced in this PR

@Nayana-ibm  @gunan  Please address the test failures.

@gunan @meteorcloudy Checked logs of failing CI builds - GPU Python3, MacOS Contrib etc.  Tests are failing with - error code 134 or ImportError: No module named keras_preprocessing
Doesn't look like its related to the code patch introduced in this PR. Could you please guide me on this? Merging is blocked due to these failures.


Initialization of the ClarityModule in jasmine tests should not consume more than a fraction of the jasmine default timeout duration.

[ x ] enhancement

Expected behavior
Initialization of the ClarityModule in jasmine tests should not consume more than a fraction of the jasmine default timeout duration.
Actual behavior
We've observed initialization times of Clarity ranging from 1.2 seconds to 4 seconds in Firefox, using the below attached unit test. The jasmine default timeout is 5 seconds - in a perfect world, we'd expect that initialization should take less than a second in all browsers.
Reproduction of behavior
// Output from this test, run in Firefox
//   Bootstrap Test
//    with ClarityModule
//      ✓ should create a component (2452ms)
//    with FormsModule
//      ✓ should create a component (130ms)
//    with no modules
//      ✓ should create a component (45ms)

import {TestBed} from '@angular/core/testing';
import {Component} from '@angular/core';
import {ClarityModule} from 'clarity-angular';
import {FormsModule} from '@angular/forms';

@Component({
  template: '
Hello world
'
})
class TestComponent {
}

fdescribe('Bootstrap Test', function () {

  describe('with ClarityModule', function () {
    beforeEach(() => {
      TestBed.configureTestingModule({
        imports: [ClarityModule],
        declarations: [TestComponent]
      }).compileComponents();
    });

    it('should create a component', () => {
      TestBed.createComponent(TestComponent);
      expect(true).toBeTruthy();
    });
  });

  describe('with FormsModule', function () {
    beforeEach(() => {
      TestBed.configureTestingModule({
        imports: [FormsModule],
        declarations: [TestComponent]
      }).compileComponents();
    });

    it('should create a component', () => {
      TestBed.createComponent(TestComponent);
      expect(true).toBeTruthy();
    });
  });

  describe('with no modules', function () {
    beforeEach(() => {
      TestBed.configureTestingModule({
        imports: [],
        declarations: [TestComponent]
      }).compileComponents();
    });

    it('should create a component', () => {
      TestBed.createComponent(TestComponent);
      expect(true).toBeTruthy();
    });
  });
});

Environment details

Angular version: 2.4.5

Clarity version: 0.8.5

OS and version: OSX Sierra

Browser: [all]

There was some discussion about this here: https://github.com/angular/angular/issues/12409
People had the same issue importing MaterialModule.forRoot(). It's actually the same issue for any components library. If the Angular team does not provide a way to import a module but only compile the actually used components, we'll need to export submodules that people can import for their unit tests: AlertsModule, DatagridModule, ...

Closed by #880. You can now just import the module you need for the test.


[BUG] BS2UMP transform always sets group to 0 (for a MIDI 1.0 client)

Describe the bug
group always set to zero
Expected behavior
Group needs to match the group index for that midi 1.0 port
Installer Name or Version
DP6

Does this case occur on a USB MIDI 1.0 device running with the USB MIDI 1.0 driver (USBAUDIO.sys)?

Does this case occur on a USB MIDI 1.0 device running with the USB MIDI 1.0 driver (USBAUDIO.sys)?

Yes. This applies to MIDI 1.0 devices using a vendor or MIDI 1.0 class driver. It also applies to the older MIDI 1.0 APIs in Windows (but you cannot test that part yet)
This does not apply to anything using the UMP class driver.

Probably, I don't understand this well, but I would like to share my test result.

Load attached UUT_ZOA_104.zip to the ProtoZOA.
This firmware works as a USB MIDI 1.0 device with four input and output ports, and all received messages are echo back to the host.
Attach the device to PC and make sure the device is running with the OS in-box USB MIDI 1.0 driver (USBAUDIO.sys).
Open a console and monitor the attached device.
Open another console and send GrpIndexTest.txt  which contains MT2 message with group index of 0-7.

Messages which have group index of 0-3 were sent to the device and other messages were dropped.

Then all received messages were displayed on the monitor.

So, it seems everything works as expected...

Thanks @m-komo
I just realized that this won't apply to the devices themselves, but only to the older MIDI 1.0 APIs. The devices have the incoming translation happening in the KSA abstraction for this very reason. But when a MIDI 1.0 client connects, it does not have the group # context, so neither does the translation code.
Keeping this open until others are able to test integration with the older winmm and WinRT MIDI 1.0 APIs.

Closing this one. #418 correctly captures the current state.


Create package.json

Good stuff, thanks.

No problem, BTW, would you like to add cdn info in readme?
We have Meny on cdnjs here https://cdnjs.com/libraries/meny

Sure – added a note about it in 1d05ffbf2e36f3106e800ac98dda7fdd2c1655e1

:+1:


Download file content

Is it possible to download file content using the API? If so, how can it be done?
Thanks

Yup that would be awesome, if there is a way to do this...


Develop

Codecov Report

Merging #2 (f5ee420) into main (bb33b91) will increase coverage by 1.91%.
The diff coverage is 92.72%.

@@            Coverage Diff             @@
##             main       #2      +/-   ##
==========================================
+ Coverage   93.15%   95.06%   +1.91%
==========================================
  Files           3        3
  Lines         146      223      +77
==========================================
+ Hits          136      212      +76
- Misses          7        8       +1
  Partials        3        3

Impacted Files
Coverage Δ

segments.go
90.00% <87.09%> (-10.00%)
:arrow_down:

options.go
100.00% <100.00%> (ø)

pathmatch.go
97.41% <100.00%> (+8.90%)
:arrow_up:

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 bb33b91...f5ee420. Read the comment docs.

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


bazel: allow coverage to be customized by consumer projects

@htuch this provides enough customization to do coverage in our private tree correctly. LMK if you have any preferences on how it's factored.


I would recommend connecting 'brain encoded' to 'brain-encoded' as good practice.

Thanks @da5nsy for your close eye! Would it be possible to compile all typos and related low-level problems for each day into a single issue, to keep the issue feed manageable? Thank you!

Noted! :)

Would it be possible to compile all typos and related low-level problems for each day into a single issue, to keep the issue feed manageable? Thank you!

I have edited this issue to fold in https://github.com/NeuromatchAcademy/course-content/issues/408.


Handle missing org / private scoped errors.

By default, when publishing scoped packages npm will attempt to create the package as private. However, if the scope does not have access to a paid npm account (and therefore has no private packages available) the npm publish command fails.
We should detect this failure (much the same as how we detect otp missing failures), and prompt to confirm the user would like to publish the package as public. If yes, set the --access flag to npm publish; if no, skip and continue publishing other packages.

Fixed by #16 and #17


pyzfs version 0.2: support for extended API

This is a replacement for PR #2.

@exarkun could you please make subsequent review comments in this PR?
I will answer the previous ones in PR #2.
Thank you!

Thanks Andriy!
I've gone through and made a bunch of comments. Don't be disheartened by the number of them, many are just trivial changes for PEP8 coding standards.
Other than that, the major areas for comments are:

extract common logic out of the various lzc_list functions
suggestions for improving the _uncommitted decorator

My comments about is_supported and _uncommitted might not be internally consistent, since I was figuring it out as I went along.
I've done very little C / Python interaction in the past, so I might have suggested things that are impossible or inadvisable.
Please feel free to ask me questions on Zulip, or to talk through options around refactoring.
PS. I did this review with reviewable at https://reviewable.io/reviews/ClusterHQ/pyzfs/6#- — if it's an option for you, I encourage you to use it for replies.

Reviewed 5 of 9 files at r1, 2 of 4 files at r2, 2 of 2 files at r3.
Review status: all files reviewed at latest revision, 61 unresolved discussions, all commit checks successful.

docs/source/conf.py, line 304 [r3] (raw file):
I don't think this is a good idea. Although it works now, it's likely to mask mistakes is future patches.
http://sphinx-doc.org/ext/autodoc.html suggests:
"""
It’s possible to override the signature for explicitly documented callable objects (functions, methods, classes) with the regular syntax that will override the signature gained from introspection:
.. autoclass:: Noodle(type)
.. automethod:: eat(persona)
This is useful if the signature from the method is hidden by a decorator.
"""

libzfs_core/_error_translation.py, line 403 [r3] (raw file):
It's very uncommon for Python code to use abbreviations like xlate. Could you please change here and elsewhere to use translate?

libzfs_core/_error_translation.py, line 409 [r3] (raw file):
Please rename to MAX_NAME_LENGTH.

libzfs_core/_error_translation.py, line 491 [r3] (raw file):
This chunk of code is repeated a lot.
I'd suggest creating a helper function like this:
def _validate_name(name):
  if not _is_valid_fs_name(name):
    raise lzc_exc.NameInvalid(name)
  if len(name) > MAXNAMELEN:
    raise lzc_exc.NameTooLong(name)

And then updating this call site and others to say:
if ret == errno.EINVAL:
    _validate_name(name)

libzfs_core/_error_translation.py, line 501 [r3] (raw file):
Raising StopIteration here and relying on it in the various callers is going to confuse the heck out of most Python programmers.
It would be better to not check this here, and then in each of the places where we loop over lzc_list results to check explicitly for ESRCH there and then break (or whatever control flow action is appropriate).

libzfs_core/_error_translation.py, line 514 [r3] (raw file):
See earlier StopIteration comment.

libzfs_core/_error_translation.py, line 527 [r3] (raw file):
See earlier StopIteration comment.

libzfs_core/_libzfs_core.py, line 677 [r3] (raw file):
Typo: s/funciton/function/

libzfs_core/_libzfs_core.py, line 680 [r3] (raw file):
This paragraph should go before :param:

libzfs_core/_libzfs_core.py, line 684 [r3] (raw file):
Did this condition come up during development?  I don't think checking for this is necessary.
Just fname = func.__name__ will do. No need to document that the function can raise an AttributeError, as the documentation already says that it expects a function.

libzfs_core/_libzfs_core.py, line 690 [r3] (raw file):
I'm genuinely unsure that these checks are worth it. One the one hand, yay defensive programming. On the other, if you don't have these checks, then all that will happen is you return False for non-functions: that seems like OK behaviour?
Up to you.

libzfs_core/_libzfs_core.py, line 697 [r3] (raw file):
No spaces around = in argument lists.

libzfs_core/_libzfs_core.py, line 700 [r3] (raw file):
s/may be unavailable/might not be available/
The former is correct, but the latter is (at least to this English speaker) more clear.

libzfs_core/_libzfs_core.py, line 703 [r3] (raw file):
For a while I didn't understand the purpose of this, but when I saw the use cases below it became clear. From a caller's point of view, this isn't so much a function to check as a declaration of a dependency.
At the least, I think the documentation should say add "For example, if the decorated function uses another uncommitted function", or similar.
Maybe the name of the parameter should be updated to depends_on. Not sure.

libzfs_core/_libzfs_core.py, line 708 [r3] (raw file):
Please wrap this at 80 cols.

libzfs_core/_libzfs_core.py, line 714 [r3] (raw file):
s/implemeted/implemented/

libzfs_core/_libzfs_core.py, line 716 [r3] (raw file):
No spaces around = in parameter lists.

libzfs_core/_libzfs_core.py, line 716 [r3] (raw file):
Not necessary, but more common Python style is to spell words out. e.g. function, check_function.

libzfs_core/_libzfs_core.py, line 724 [r3] (raw file):
We could make this simpler by making the following changes:

Make check_func a variable argument parameter, e.g. *dependencies
Change _f to say:for function in dependencies + (_f,):
    if not is_supported(function):
        raise NotImplementedError(func.__name__)

Drop explicit separate check_func conditional
Remove all knowledge of check_func from is_supported

This adds a small amount of runtime overhead.

libzfs_core/_libzfs_core.py, line 725 [r3] (raw file):
Thinking about it further still, do we really need a dependency/check_func mechanism at all?
The decorator doesn't update the docstring, the error is going to happen at runtime anyway, and the two existing use cases call lzc_list pretty much as the first thing they do, so there's no danger that the check is protecting us from.
What are your thoughts?

libzfs_core/_libzfs_core.py, line 782 [r3] (raw file):
What's the purpose of this alias? Could you please at least add a comment?

libzfs_core/_libzfs_core.py, line 812 [r3] (raw file):
What's the purpose of this alias? Could you please at least add a comment?

libzfs_core/_libzfs_core.py, line 841 [r3] (raw file):
No whitespace around braces. So, {prop: val}.

libzfs_core/_libzfs_core.py, line 847 [r3] (raw file):
What's the purpose of this alias? Could you please add  comment?

libzfs_core/_libzfs_core.py, line 868 [r3] (raw file):
I think a nicer Python API would be to make these explicit parameters and then build the options dict inside the function. e.g.
def lzc_list(name, options, recurse=None, types=None):
    # ...
    options = {
        'fd': int32_t(wfd),
        'recurse': recurse,
        'types': types,
    }

libzfs_core/_libzfs_core.py, line 876 [r3] (raw file):
Invocations below use type not types. Which is it?

libzfs_core/_libzfs_core.py, line 878 [r3] (raw file):
What happens if types is not specified? Please update the docstring.

libzfs_core/_libzfs_core.py, line 915 [r3] (raw file):
Please move the return and rtype clauses below the raises clauses.

libzfs_core/_libzfs_core.py, line 932 [r3] (raw file):
If you make the options change I describe above, this would become lzc_list(name, recurse=1)

libzfs_core/_libzfs_core.py, line 955 [r3] (raw file):
other_fd doesn't get used in the loop. Is there any reason it can't be closed immediately after the call to lzc_list?

libzfs_core/_libzfs_core.py, line 956 [r3] (raw file):
If you extracted the call to lzc_list and this loop into its own internal function (say, _find_dataset), then the logic of the loop could become simpler. Rather than resetting entry each time, you could rely on an early return of result.
Actually, I notice that there's logic very similar to this loop in the functions below. You should actually go further still.

Make an _iter_children(name, types=None) that has this logic, but yields all full result objects that derive from a call to lzc_list(name, recurse=1, types=types)
Update this function, lzc_list_children, and lzc_list_snaps to use that.

libzfs_core/test/test_libzfs_core.py, line 1867 [r3] (raw file):
I'd suggest changing this to unittest.expectedFailure unless it's potentially destructive.
At the least, should have a comment that links to the bug for patching libzfs_core

libzfs_core/test/test_libzfs_core.py, line 2659 [r3] (raw file):
Probably best to define a helper function:
def needs_support(function):
    return unittest.skipUnless(lzc.is_supported(function), '{} not available'.format(function.__name__))

And then decorate tests with:
@needs_support(lzc.lzc_promote)

libzfs_core/test/test_libzfs_core.py, line 2687 [r3] (raw file):
So that means we can't land this patch yet? Could you please add a link for the OpenZFS bug.
Perhaps this should be marked as @unittest.expectedFailure (see https://docs.python.org/2/library/unittest.html#unittest.expectedFailure)

libzfs_core/test/test_libzfs_core.py, line 3180 [r3] (raw file):
flocker coding conventions require docstrings for all tests that describe the expected test behaviour.
I see that this module doesn't follow that convention. I encourage you to add docstrings for all of the tests here, but won't insist on it as a reviewer. I will specifically flag a few tests that I think do need a docstring.
https://jml.io/test-docstrings/ has a brief guide on how to do so.

libzfs_core/test/test_libzfs_core.py, line 3201 [r3] (raw file):
assertEqual(children, []) will probably get you a better error message when the test fails.

libzfs_core/test/test_libzfs_core.py, line 3210 [r3] (raw file):
Likewise, assertEqual here.

libzfs_core/test/test_libzfs_core.py, line 3235 [r3] (raw file):
assertEqual please

libzfs_core/test/test_libzfs_core.py, line 3244 [r3] (raw file):
assertEqual please.

libzfs_core/test/test_libzfs_core.py, line 3250 [r3] (raw file):
No spaces after { or before }.

libzfs_core/test/test_libzfs_core.py, line 3260 [r3] (raw file):
No spaces after [ or before ].

libzfs_core/test/test_libzfs_core.py, line 3261 [r3] (raw file):
No spaces after { or before }.

libzfs_core/test/test_libzfs_core.py, line 3273 [r3] (raw file):
Don't assign to the return value here.

libzfs_core/test/test_libzfs_core.py, line 3277 [r3] (raw file):
Please add a docstring describing the behaviour this test is checking for.

libzfs_core/test/test_libzfs_core.py, line 3280 [r3] (raw file):
No spaces after { or before }.

libzfs_core/test/test_libzfs_core.py, line 3292 [r3] (raw file):
Please add a docstring for this test.

libzfs_core/test/test_libzfs_core.py, line 3295 [r3] (raw file):
No spaces after { or before }.

libzfs_core/test/test_libzfs_core.py, line 3310 [r3] (raw file):
No spaces after { or before }.

libzfs_core/test/test_libzfs_core.py, line 3312 [r3] (raw file):
No spaces around = in argument lists.

libzfs_core/test/test_libzfs_core.py, line 3318 [r3] (raw file):
The code would be a bit more self-documenting if it said child_props here, and asserted that props (rather than the literal expansion) was in child_props.

libzfs_core/test/test_libzfs_core.py, line 3334 [r3] (raw file):
not need for instance check, unless being a list is super important for some reason. (If it is important, then please add a comment explaining why).

libzfs_core/test/test_libzfs_core.py, line 3385 [r3] (raw file):
:question: Consider making helper methods for assertExists and assertNotExists.
If this test fails, you'll be told True == False and nothing more. With a helper method, you could get a much more informative error message.

libzfs_core/test/test_libzfs_core.py, line 3402 [r3] (raw file):
No spaces after { or before }.

libzfs_core/test/test_libzfs_core.py, line 3416 [r3] (raw file):
No spaces after { or before }.

libzfs_core/test/test_libzfs_core.py, line 3422 [r3] (raw file):
assertNotIn will give you a much better error message when this fails.

libzfs_core/test/test_libzfs_core.py, line 3451 [r3] (raw file):
This would make a pretty good docstring. You could perhaps expand it to:
"""
Inheriting a non-existent property from the parent is a no-op.
"""

libzfs_core/test/test_libzfs_core.py, line 3529 [r3] (raw file):
assertNotIn

libzfs_core/test/test_libzfs_core.py, line 3541 [r3] (raw file):
assertNotIn

libzfs_core/test/test_libzfs_core.py, line 3553 [r3] (raw file):
assertNotIn

Comments from the review on Reviewable.io

I think that I've addressed most of your comments. It seems that there were only a handful of issues where I disagreed or had a question. It could also be that some of your comments I "acknowledged" by mistake while in the reality I should have said "Done".
Also, I cleaned up most but of not all of the things that flake8 (and frosted) complained about. Some things still remain, for example, many lines longer than 80 symbols. By the way, my personal preference for the line length is 120, not sure why though.

Review status: all files reviewed at latest revision, 48 unresolved discussions, all commit checks successful.

docs/source/conf.py, line 304 [r3] (raw file):
I am aware of this ugliness and JP also promised to think about how to fix it.
Originally I wanted to avoid writing the explicit documentation. You probably noticed that right now all of it is generated from the docstrings.
So, I'd like to postpone fixing this quirk until later.
I'll open a github issue for that.

libzfs_core/_error_translation.py, line 409 [r3] (raw file):
This variable mirrors a C constant of the same name.
I think that keeping the name would be less confusing for those familiar with the C ZFS API, but I could be wrong...

libzfs_core/_error_translation.py, line 491 [r3] (raw file):
Done. This change also helped to uncover a bug where in some cases an exception was not raised. And believed that that was because there was no C error.  So the better code also helped to fix the bug and to clear my confusion about behavior of some API functions.

libzfs_core/_error_translation.py, line 501 [r3] (raw file):
The idea was that the C error codes should be contained to _error_translation as much as possible. But I agree that it's better to handle the case without abusing StopIteration.

libzfs_core/_libzfs_core.py, line 697 [r3] (raw file):
Done.

libzfs_core/_libzfs_core.py, line 700 [r3] (raw file):
Done.

libzfs_core/_libzfs_core.py, line 703 [r3] (raw file):
I've added the clarifying statement. Also, there is more explanation for the parameter further in the docstring.

libzfs_core/_libzfs_core.py, line 708 [r3] (raw file):
Done.

libzfs_core/_libzfs_core.py, line 716 [r3] (raw file):
Done.

libzfs_core/_libzfs_core.py, line 724 [r3] (raw file):
I think that I can not remove check_func knowledge from is_supported, because then the decorator and is_supported would fall out of sync.  Please note that is_supported was designed as a public API and its return value should be consistent with whether the decorated function would throw NotImplemented or not.
Maybe we could leave this messy code out of the current review?

libzfs_core/_libzfs_core.py, line 725 [r3] (raw file):
For me the main convenience behind is_supported was to use it with test cases.
So, for example, if I test lzc_list_children then I can check is_supported(lzc_list_children) and skip the test if necessary.
Of course, a different mechanism could be implemented for ignoring uncommitted functions...

libzfs_core/_libzfs_core.py, line 782 [r3] (raw file):
Done. Comment added.

libzfs_core/_libzfs_core.py, line 812 [r3] (raw file):
Done. Comment added.

libzfs_core/_libzfs_core.py, line 841 [r3] (raw file):
Done.

libzfs_core/_libzfs_core.py, line 847 [r3] (raw file):
Done. Comment added.

libzfs_core/_libzfs_core.py, line 868 [r3] (raw file):
Done. I've actually kept lzc_list as is, but the newly added wrapper _list ia taking the parameters the way you suggested.

libzfs_core/_libzfs_core.py, line 876 [r3] (raw file):
A typo, it's type.

libzfs_core/_libzfs_core.py, line 878 [r3] (raw file):
Done.

libzfs_core/_libzfs_core.py, line 915 [r3] (raw file):
Done.

libzfs_core/_libzfs_core.py, line 955 [r3] (raw file):
Yes, it's passed to the kernel and it is being written to by the kernel.

libzfs_core/_libzfs_core.py, line 956 [r3] (raw file):
Done. I've added the wrapper (which I called just _list()) and switched lzc_list_children, lzc_list_snaps and lzc_get_props to it.

libzfs_core/_libzfs_core.py, line 1028 [r2] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 1867 [r3] (raw file):
Well, wouldn't expectedFailure result in an error on patched systems where the test is successful?

libzfs_core/test/test_libzfs_core.py, line 2659 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 2687 [r3] (raw file):
Thanks for catching this. The bug has already been fixed, so the comment gets removed.

libzfs_core/test/test_libzfs_core.py, line 3201 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3210 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3235 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3244 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3250 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3260 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3261 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3273 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3277 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3280 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3292 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3295 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3310 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3312 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3318 [r3] (raw file):
Done 50%. I am taking the advice about child_props, but the expected value in child_props is a little bit different from props.  The newly added docstring explains the difference.

libzfs_core/test/test_libzfs_core.py, line 3334 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3385 [r3] (raw file):
Done. I like the suggestion.

libzfs_core/test/test_libzfs_core.py, line 3402 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3416 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3422 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3451 [r3] (raw file):
Overcome by other changes.

libzfs_core/test/test_libzfs_core.py, line 3529 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3541 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 3553 [r3] (raw file):
Done.

Comments from the review on Reviewable.io

For better or worse, we follow PEP 8, which is 80 cols. (I have my own preferences, which I keep as a closely guarded secret).
I've only suggested adding a couple of comments and one small, optional change. I still think the decorator stuff around supported APIs is should be cleaned up, but I'm OK with doing that in a later pass.
Thanks for your patience.

Reviewed 9 of 9 files at r4.
Review status: all files reviewed at latest revision, 9 unresolved discussions, all commit checks successful.

libzfs_core/_error_translation.py, line 409 [r3] (raw file):
That's fair enough.

libzfs_core/_error_translation.py, line 491 [r3] (raw file):
Yay!

libzfs_core/_libzfs_core.py, line 724 [r3] (raw file):
Yeah, maybe. I think I'm OK with proceeding as-is and clearing it up later.

libzfs_core/_libzfs_core.py, line 955 [r3] (raw file):
That's a good reason :smile:
Could you please add a comment?

libzfs_core/_libzfs_core.py, line 956 [r3] (raw file):
Great, thanks. Much clearer.

libzfs_core/_libzfs_core.py, line 965 [r4] (raw file):
Optional:
You could write this as an iterator. Instead of appending to entries, you could do yield result. Instead of return iter([]) you can just do return.
Advantages:

When you're doing filtering or linear searching, you don't need to process the whole input before getting the result
No need to buffer the whole result in memory before using it

Disadvantages:

Slightly more runtime overhead per iteration
Another change :wink:

libzfs_core/test/test_libzfs_core.py, line 212 [r4] (raw file):
I didn't notice this in the earlier review.
setUpClass and tearDownClass can be dangerous, because they create state that is shared between all tests, and it makes it very easy to write tests that depend on each other.
AFAICT, it's probably OK here, because you reset state in tearDown.

libzfs_core/test/test_libzfs_core.py, line 1867 [r3] (raw file):
With trial, it would return "unexpected success", which (I think) gets interpreted as a success. It's probably OK to leave it as skip. There should still be a comment with a link to the patch though.

Comments from the review on Reviewable.io

To clarify, no need for a follow-up review.

Review status: all files reviewed at latest revision, 9 unresolved discussions, all commit checks successful.

Comments from the review on Reviewable.io

libzfs_core/_libzfs_core.py, line 965 [r4] (raw file):
Actually I originally had code that followed the pattern that you suggested, but @exarkun warned me that that was dangerous with respect to the resource clean up.
On the other hand, if we have the full control of the generator (as opposed to returning it to a random caller), then probably we should be safe.

Comments from the review on Reviewable.io

Review status: 11 of 13 files reviewed at latest revision, 4 unresolved discussions, all commit checks successful.

libzfs_core/_libzfs_core.py, line 1000 [r3] (raw file):
Done.

libzfs_core/test/test_libzfs_core.py, line 1770 [r3] (raw file):
Done.

Comments from the review on Reviewable.io


Add mutual TLS for EspHttpClient

Description
Add client_cert_pem and client_key_pem attributes to EspHttpClient for mutual TLS, as defined in https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_http_client.html#_CPPv424esp_http_client_config_t
This is currently a PoC. The feature still has a bug to resolve, described below.
Example
You can include certificates with the include_str!() macro
const client_cert: &str = include_str!("certs/client_cert.pem");
const client_key: &str = include_str!("certs/client_key.pem");

and specify them in EspHttpClientConfiguration
let mut client = EspHttpClient::new(&EspHttpClientConfiguration {
        crt_bundle_attach: Some(esp_idf_sys::esp_crt_bundle_attach),
        client_cert_pem: Some(client_cert),
        client_key_pem: Some(client_key),
        ..Default::default()
    })?;

Issue (Fixed)
There's currently an issue with the underlying implementation,
https://github.com/esp-rs/esp-idf-svc/blob/73b3e53e1f7fd87b4abcab68089509afbb5c7166/src/http/client.rs#L114-L131
We specify the pointers to the certificates and pass them to native_config, but the value referenced by the pointers is dropped at the end of the scope. Similar as the problem detailed here:
https://github.com/esp-rs/esp-idf-svc/blob/554cad178e079b75e837885dffcf71a833f53107/src/http/server.rs#L198-L208
Contrary of the Https Server, the values referenced by the pointers need to be valid when doing a request, even after the initialization has ended.

Each mutual TLS requests seem to take a couple of seconds, I believe this is because we don't take advantage of the TLS sessions feature.
https://github.com/espressif/esp-idf/issues/8852

@AnthonyGrondin Sorry for the huge delay here, but as you've probably noticed, I was overly busy with finishing the next branch and merging it into master. Now that this is done, we can follow up on all the outstanding merge requests. I'm absolutely for merging this now, but can you rebase it on top of latest master and fix the merge conflicts?

@AnthonyGrondin The PR is unmergeable due to conflicts. Can you resolve these?

@AnthonyGrondin The PR is unmergeable due to conflicts. Can you resolve these?

^^^ Disregard.


How to train on the arctic dataset?

If I'm understanding correctly, if we want to use train1 on the arctic dataset, we just need to do
python train1.py datasets/arctic/ right? It's stuck on the first epoch, and it's hard to tell if this is in the wrong format because it doesn't give a 'no such file or directory' error.

Ok, looking through hparams.py, I now understand that I should be training on the TIMIT dataset, but I'm still encountering the same problem where it hangs on the first epoch. I put the TIMIT dataset in the 'datasets' folder, so according to line 49 in hparams.py, it should be pointing to the correct place. Is there anything I need to change in hparams.py or anywhere else?

Ah, so it seems that it was looking for anything ending in .wav, but all of my audio files ended in .WAV. I just wrote a quick script to change all of the files from .WAV to .wav and all is well.

this is the problem I faced.....can you tell me why?...

Try running it through the terminal with the command python train1.py timit
And just to be sure, you have the whole TIMIT dataset, right?

Thank you for answering me !! You are very patient.
I found that I haven't put my TIMIT dataset in it.

Try running it through the terminal with the command python train1.py timit
And just to be sure, you have the whole TIMIT dataset, right?
Edit: Also be sure that the directory in data_path found in class Test1 in hparams.py matches the directory of your dataset. I had to move some folders around to get mine working.

I still cannot train

where did u get TIMIT dataset? It is not for free so far as I know.

@LukeJacob You can download TIMIT from http://academictorrents.com/details/34e2b78745138186976cbc27939b1b34d18bd5b3


Fix structure overflow

Closes #65

/preview

/preview

/preview

/preview

/preview

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


Library breaks with rocket 0.5.0-rc.2

After updating rocket to 0.5.0-rc.2 i am getting this error for every function using either the User, Users or Auth Requestguards
  --> src/routes/index.rs:30:5
   |
30 | pub async fn some_method(user: User) -> SomeReturnType {
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^------
   |     |                                                          |
   |     |                                                          consider giving ´___responder´ a type
   |     cannot infer type

I am not 100% sure if this is an error in the library, in rocket or in my own code
(This issue is more to report this than to require any fix of this problem)

i wrongly identified this. has nothing to do with the library


Re-use challengeString cookie if it is already set

The cause of the login issues appears to be Chrome specifically re-generating the challenge string when it visits /oauth, causing it to not match the hash we sent to BaaS.

Suddenly stopped being able to repro this even without the fix, but it won't do any harm to handle this case