text:
Apply T! macro where posible

apply T! macro implemented in #1248

Hm, OTOH, T!['{'] is inline with how various parser generators handle things.
Let's just merge this, we can always revert to L_CURLY later :D
bors r+

I've got the feeling that this increases compile time a lot. Is this known?

Hm, no, I haven't check it, will run some benchmarks, thanks for the report.
If you have already measured the impact of this change on compile time, I'd be interested in seeing the results!
We might also look at the travis build times I guess.

Hm, I've checked locally, and compile time seems the same.
Specififivally, I've check f7112371ee646d8ecc68861e9fe832af9729878e
and 64ab5ab10d32e7e8ec085af818d3d94211aea39b by
repeateadly running
$ find ./target/debug -type f -maxdepth 1 -delete && rm -fr ./target/debug/{deps,.fingerprint}/{*ra_*,*test*,*tools*,*gen_lsp*,*thread_worker*}
$ cargo check

and
$ find ./target/debug -type f -maxdepth 1 -delete && rm -fr ./target/debug/{deps,.fingerprint}/{*ra_*,*test*,*tools*,*gen_lsp*,*thread_worker*}
$ cargo test --no-run

in both cases compile itme was more or less the same for both commits
@jens1o could you give a little more details about where you are observing longer compile times?

I digged a little bit further. At some point yesterday, I just quit compiling. I now let it run for some while, only to notice that ra_ide_api results into overflow evaluating the requirement (something with salsa). Might be like https://github.com/rust-lang/rust/issues/47032? I do not know how to get rid of it, though. :/ When it really overflows, then this might be the reason why it takes sooo long.

Hm, whihc version of rustc are you using?

I think this is the same as https://github.com/rust-analyzer/rust-analyzer/issues/1283: on the latest nightly I also get a very long compile time + overflow at the end.

Ah, yes it is! Thank you very much and pardon me!

Thanks for the report! Tacking that overflowing error is important: it has been my main gripe with rustc since all hands :D

authors: jens1o matklad pasa


text:
Account for data pushing opcodes in is_standard_op_return

While I believe the original commit used 80 bytes for the entire script as the limit, Bitcoin Core as of this commit will relay OP_RETURN outputs as long as the data itself is not above 80 bytes, meaning a script of maximum size 83 bytes should be standard.

I like that core defines this as a constant MAX_OP_RETURN_RELAY = 83;.

Updated. I am impartial where this constant goes, but I've put it with borrowed for now.

Perhaps we should put it in bitcoin/src/policy.rs

Should I define as 32 bit and assume as usize is a safe cast or just opt for usize as the const type?

The core const you linked to is of type int (32 bits) so why not just keep the same size here?  No need for more than 32 bits to store the number 83.

Oh if its not going to be public then perhaps policy is the wrong place. Sorry to send you on a wild goosechase.

I like policy because it corresponds well policy.h, but I can also see the case for including it in the file it is used. I will leave it this way for now unless advised otherwise

Why not make the constant a usize? It represents a length and is only ever used as a usize.

Why not make the constant a usize? It represents a length and is only ever used as a usize.

This is probably my fault for steering this toward a u32 like the other consts in policy and like the core int type which is ostensibly u32.  I guess if it's usize the cast can be avoided, although there's no reason this needs to be a usize since the value can always be contained in a u32.  If it's not being publicly exported though I think it doesn't matter much either way.

If we go that direction it can just be a byte. I am unable to work on this for the week if you would like to take it over @yancyribbens. Otherwise I will update it next week

if you would like to take it over @yancyribbens. Otherwise I will update it next week

I could but there is no rush I think

If we go that direction it can just be a byte

We should go in the direction of "constant lengths should be represented as usizes". We only need to copy Core's types in cases where we are consensus decoding/encoding them.

Had some time to update. Now using usize

source: gharchive/pull-request

authors: apoelstra rustaceanrob tcharding yancyribbens

repo: rust-bitcoin/rust-bitcoin

license_type: permissive

license_source: github-api


text:
Consider using code generation to produce Rust code from structured RPC information exported from Bitcoin Core

I've been considering an alternative approach to writing a Bitcoin Core JSON RPC client, namely, exporting the structured API information available within Bitcoin Core as JSON, and using that to auto-generate the API.
I created a branch of Core here which implements a new JSON RPC command, api, which dumps structured API information as JSON.
You can see the output here. It contains types and documentation for all RPC commands.
These could be used to automatically generate Rust code, instead of writing them manually and keeping them up to date between versions of Core. Types are not ideal, for example, addresses have type "string". However, you could write a complementary JSON "patch" file which described what the user facing types should be.
For example, getaddressinfo takes a single argument which is of type string. The patch file could contain instructions for the code generator to expose this as a bitcoin::Address:
{
  "getaddressinfo": {
    "arguments": {
      "address": {
        "type": "address",
      }
    }
  }
}

The code generator would then load the JSON file dumped by bitcoin-cli api, as well as the patch file, and use them to generate user-facing Rust code which exposed the appropriate types, and performed the appropriate conversions when calling Bitcoin Core.
There are a bunch of advantages to this approach. You would be guaranteed to be up-to-date with Core, and could automatically expose documentation from Core as Rust doc comments, without needing to copy them manually. Since everything is auto-generated, you would likely only need a minimum of tests to be confident that things were working.
Some types would require special considerations, like addresses, fee rates, and amounts (which are exposed by the Core RPC with different units in different places). So, it might be wise to consider the patchfile to be a kind of whitelist, and require entries in the patch file for all commands before allowing to code generator to expose them, to ensure that a human had manually confirmed that no types require special handling.
I don't know if I'm going to keep working on this myself. Since rust-bitcoincore-rpc has been deprecated, I went down a bit of a rabbit hole thinking about how the whole RPC situation could be improved, and this is what I came up with. However, in reality, we'll probably keep using rust-bitcoincore-rpc for the time being, and just hack around the limitations until they become intolerable.
If this approach is fruitful, it would be nice to get the branch which adds the api command merged into Core, so it doesn't require continual rebasing. I've been away from Core development for a while, and have been spoiled rotten by Rust, so I might not be the right person to do that.

Thanks for the write up man, I didn't totally grok it but I had an immediate question, will your idea achieve what I want to achieve with less work now and less work to maintain it? If so I'm in favour of it. To assist you in possibly answering this perhaps I can outline what it is this repo is trying to achieve and why I think it should be low maintenance going forward. FTR if I never have to look at JSON RPC code again I will be a happy camper, I am working on this crate because I think it needs to exist not because I find it interesting in any way.
Wants and don't wants

I want to write integration test code and have it run against some specific subset of released Core versions
I don't want to spend much time maintaining this repo
I don't want it to break every time we release a new version of rust-bitcoin, and when it does break I want to be able to patch it quickly/easily
I want it to be easy enough to upgrade when new Core versions come out (an hour or twos work)
I don't want it to keep getting more and more complicated as Core's RPC API changes over time

This project is pretty new so I don't know if it will achieve these aims but in regards to each one:

Yep, it definitely does this.
We will have to see how this pans out
I'm concerned with this one, there is a shit ton of rust-bitcoin type conversion code that will be annoying to update but it should be brain dead simple at least.
Core 28 upgrade was done recently by an external contributor so it can't be toooo hard, once one knows the repo it should achieve this easily
All the complexity should be isolated to the json::model module

It is bleedingly obvious while working on this repo that a trained monkey could do it because it is so repetative. It is also boring, hence why it is taking me so long.

I'm actually a little bit unclear about how this crate does 1. Looking at the client code, it looks like each version has a different module containing the types for that version. How does the client code run against different core versions? Does it have to enumerate those versions, like doing v1::method(), v2::method(), or does it somehow select the right method and models to use dynamically based on what version of Core it's connected to?

I think codegen potentially helps with this. Each time a new version of core comes out, you rebase the C++ code which dumps the API to JSON onto the new version. Then you run a Rust codegen script to auto-generate the Rust code which contains Rust structs for all the request and response types for that version.

I think codegen helps with this. You have the type conversion code, for example between a JSON string and a Rust address in one place, so if that changes, for example because of a change to rust-bitcoin, you only have to change it in one place, and the codegen script will replicate it wherever that type is used in a request or response.

This depends on whether or not the code in Core changes enough to make rebasing hard. In the best case, it gets integrated into Core, so you don't need to rebase. In the medium case you have to rebase manually but it's easy, in the worst case there's crazy code churn in the new version of Core, so you have to modify it to rebase it.

I think codegen probably helps, or at least makes that complexity easy to deal with.

A big problem with the codegen approach is that I wrote the code for Bitcoin Core 28. I don't know how much change there's been in the RPC API code, but if there's been a lot, rebasing the the code onto earlier and earlier versions, back to v17, might be very hard. I do wonder if it's worth supporting versions of core which are that old. Is there demand for it? If not, then you could just decided to support v28 going forward, and anyone who wants support for an older version should use the deprecated library.

I posted the API description PR to Twitter, and someone mentioned it in an issue in Core, so linking here for posterity.

Edit: If there is a single software project out there, which currently correctly and fully implements the RPC API in a type-safe manner, it would be interesting to see how they approached it. But I doubt there is one?

Gawd damn, if I knew that before I started this repo I might not have started.

😭

Mad, that inspires me. Thanks.

The names are a mess now, below I'm going to use the new names because they are shorter but for anyone not following the rename I  list them here

bitcoind-json-rpc-regtest -> corepc-node (directory is bitcoind because the crate was originally called that)
bitcoind-json-rpc-client -> corepc-client
bitcoind-json-rpc-types -> corepc-types

I'm actually a little bit unclear about how this crate does 1. Looking at the client code, it looks like each version has a different module containing the types for that version. How does the client code run against different core versions? Does it have to enumerate those versions, like doing v1::method(), v2::method(), or does it somehow select the right method and models to use dynamically based on what version of Core it's connected to?

So we test using features on the integration_test crate that enable features in corepc-node.
corepcp-node spins up a Bitcoin Core node of the correct version and passes back the handle in BitcoinD.
corepc-node has features that configure which Client is exposed from corepc-client in the handle i.e., the Client field of BitcoinD is version specific. When one calls bitcoind.client.foo() they are calling client::client_sync::v17::foo (assuming corepc-nod was built with feature 0_17_1).

I think codegen potentially helps with this. Each time a new version of core comes out, you rebase the C++ code which dumps the API to JSON onto the new version. Then you run a Rust codegen script to auto-generate the Rust code which contains Rust structs for all the request and response types for that version.

I think you are right, as long as we don't manually go in and touch the generated code. All "fixes" would have to go into the code generator.

I think codegen helps with this. You have the type conversion code, for example between a JSON string and a Rust address in one place, so if that changes, for example because of a change to rust-bitcoin, you only have to change it in one place, and the codegen script will replicate it wherever that type is used in a request or response.

This one I'm more confident you are correct.

This depends on whether or not the code in Core changes enough to make rebasing hard. In the best case, it gets integrated into Core, so you don't need to rebase. In the medium case you have to rebase manually but it's easy, in the worst case there's crazy code churn in the new version of Core, so you have to modify it to rebase it.

I'm hopeful that you are correct here, I don't know exactly how hard it is to go from a fully fleshed out version to the next in this crate yet because v17 is not fully fleshed out. All other versions are just minimal (basically just what was needed by miniscript).

I think codegen probably helps, or at least makes that complexity easy to deal with.

One idea would be to only codegen Rust std types and leave the model stuff done manually. It would be nice to code gen the whole thing of course.

A big problem with the codegen approach is that I wrote the code for Bitcoin Core 28. I don't know how much change there's been in the RPC API code, but if there's been a lot, rebasing the the code onto earlier and earlier versions, back to v17, might be very hard. I do wonder if it's worth supporting versions of core which are that old. Is there demand for it? If not, then you could just decided to support v28 going forward, and anyone who wants support for an older version should use the deprecated library.

Yeah I asked myself this question also, I started at v17 because that is where bitcoincore-rpc started and I wanted to replace it without loss of test coverage.

I started working on a new branch which exports a description of the RPC API as JSON Schema. I don't have a lot of experience with JSON Schema, but it seems pretty widely adopted, and there is at least some amount of tooling for it. At the very worst, it doesn't seem a whole lot more difficult to work with than an ad-hoc JSON description of the API

branch
diff
generated JSON schema

For each command, there is an arguments key which holds a JSON Schema describing the arguments to the command. I haven't started on return types yet, since they're much more complicated.

corepc-node has features that configure which Client is exposed from corepc-client in the handle i.e., the Client field of BitcoinD is version specific. When one calls bitcoind.client.foo() they are calling client::client_sync::v17::foo (assuming corepc-node was built with feature 0_17_1).

Does that mean that client code has to statically select which version of bitcoind it wants to talk to with a feature?

I don't quite understand the question. By 'client code' you mean code in the corepc-client crate or code that uses the Clent (by way of eg bitcoind.client)?

Ah yeah, sorry it's confusing. Yeah, I mean a user of corepc-client::Client.

I'll try to clarify.
The Client (and corepc-client) is specifically, and explicitly, only for integration testing. I envisage only two users of Client:

The integration_test crate in this repo (solely exits to verify that the types crate is correct).
Other projects that wish to do integration testing using bitcoind (for an example see rust-miniscript/bitcoind-tests).

A user uses Client by way of corepc-node and the BitcoinD type (which I'd like to rename to Node). corepc-node controls, by way of features, which version of Core the Client is for.
A user of Client should be able to write arbitrary code e.g., client.foo(). The return type of client.foo() is version specific eg if it returns Foo then the corepc-node guarantees that Foo is correct for that version of Core. This is tested because when the integration tests in this repo run they run against each version of Core.
If other projects (miniscript or anyone else) want to extend the Client I plan of having a low bar for merging new methods on Client.
Now, my opinion, and background on design assumptions:
For production code, people should write their own client and only use the corepc-types crate from this repo. They will be able to have confidence that what ever version of Core they hit the types contained types will be valid and correct but they are version specific. Such crates will have to work out for themselves how they handle hitting different versions of Core. I maintain the position that this decision is application specific eg

app explicitly only supports latest Core version (easy)
app explicitly only supports latest 3 versions (if dynamic, may need branching logic in the code switching on version)
app supports any version but must be statically built for that version (can use features)

And all of these depend on what subset of RPC methods the app calls. Hence my view that its app specific and not right to have a single production client library that everyone can use.
The final piece of the puzzle is the types::model module. This has types that are:

General over all versions of Core
Have rust-bitcoin types (Amount instead of u64)

One can convert from an types::vXY::Foo  to a model::Foo by calling bitcoind.client.foo().into_model().
I have a good reason for the split between vXY::Foo and model::Foo but I've already written enough text for now.

source: gharchive/issue

authors: casey tcharding

repo: rust-bitcoin/rust-bitcoind-json-rpc


text:
Rustup to the latest nightly

Caused by rust-lang/rust#70164.
r? @ibabushkin

r? @Manishearth

CI still fails on windows, but I'm landing this anyway.

authors: JohnTitor Manishearth

repo: rust-dev-tools/rust-semverver


text:
Book is not reachable

http://book.rust-embedded.org/ says 404 and http://rust-embedded.github.io/book forwards to the first url.

https://docs.rust-embedded.org/book/ is the official link now

authors: Phaiax japaric

repo: rust-embedded/book

license_source: bigquery


text:
Change missing_docs from deny to warn.

It is annoying to get hard errors while developing, it prevents testing things out
without documenting them because it fails the build.
This changes it to warn, which has the same effect in CI (because it already has RUSTFLAGS: '--deny warnings'),
but still allows buildilng.

r? @eldruin
(rust-highfive has picked a reviewer for you, use r? to override)

authors: Dirbaio rust-highfive

repo: rust-embedded/embedded-hal


text:
WIP: Compat blog post

I'm going to continue writing this tomorrow if I find the time. In the meantime, here's what I have so far 🙂

Alright. Now it's done. Plz review
Note: I turn various code snippets into links once we've released the docs for alpha.4. The docs for alpha.3 don't include the compatibility layer (an oversight ^^').

@carllerche This blog post talks about compatibility between 0.1 and 0.3 futures in general, but also about Tokio compatibility. Now, that tokio-async-await is released, I think we should update this post before we release it so that it only presents a single solution on that topic.
I think it'd be best to place the general 0.1 <-> 0.3 compatibility layer in futures-util and to keep all Tokio related compatibility layer functionality in tokio-async-await (and remove it form futures-util). Also, I think it'd be nice if tokio-async-await used the compatibility layer from the futures crate internally. We should improve the compatibility layer if it lacks required functionality.
I'd love to hear your take on this. Would you be open for collaboration?

I don't really have many thoughts as to what collaboration would look like. I have not dug into the compat layer in the futures lib.
General thoughts:
tokio-async-await doesn't bother trying to bridge the two task systems. It assumes that leaf futures are 0.1 and users are on Tokio. Given this, it just passes a Waker that panics if used.
Also, tokio-async-await does not bother trying to set the spawn handle with the context. I presonally think it is an incorrect API. I provided more details to @cramertj and will be pushing back against it once there is a forum to do so. Given this, I would rather not burden Tokio users with having to worry about it.
Last, keeping what I need in tokio-async-await to make things work allows me to make progress and publish on my schedule, which is more convenient at this point.

authors: MajorBreakfast carllerche

repo: rust-lang-nursery/futures-rs


text:
Elaborated documentation around log levels.

Two changes:

fixed the mistake in the example: release_max_level_warn disables trace, debug, and info, not trace, info, and warn.

The explanation of log levels was a bit misleading because it was said that error! represents the highest-priority log level. However, the log level that shows only error is the lowest. I removed the word level there, and added additional explanation about log levels as the level of verbosity.

Nice, it captures the intention while being simpler and more concise! I'll update the PR in a sec.

repo: rust-lang-nursery/log


text:
Line numbers in --check mode are based on the formatted file

rustfmt --check produces a diff output which uses the line numbers from the temporary formatted file rather than the source file.
This makes it difficult to use --check in a CI context, where you might want to look at the error in the build log and know where to look in your file.
Example:
For the source file main.rs
 1 fn my_shorter_function(
 2     _a: String,
 3     _b: String,
 4     _c: String,
 5 ) {
 6     unimplemented!()
 7 }
 8
 9 fn my_function_with_a_very_long_name(a: &str, b: &str, c: &str, d: &str, e: &str, f: &str) {
10     println!("A: {} | B: {} | C: {} | D: {} | E: {} | F: {}", a, b, c, d, e, f);
11 }
12
13 fn main() {
14     my_function_with_a_very_long_name("a", "b", "c", "d", "e", "f");

» rustfmt --check src/main.rs
Diff in /home/bradfier/src/bugs/rustfmt-linecount/src/main.rs at line 1:
-fn my_shorter_function(
-    _a: String,
-    _b: String,
-    _c: String,
-) {
+fn my_shorter_function(_a: String, _b: String, _c: String) {
     unimplemented!()
 }
Diff in /home/bradfier/src/bugs/rustfmt-linecount/src/main.rs at line 5:
 fn my_function_with_a_very_long_name(a: &str, b: &str, c: &str, d: &str, e: &str, f: &str) {
-    println!("A: {} | B: {} | C: {} | D: {} | E: {} | F: {}", a, b, c, d, e, f);
+    println!(
+        "A: {} | B: {} | C: {} | D: {} | E: {} | F: {}",
+        a, b, c, d, e, f
+    );
 }
 fn main() {

The diff at line 5 actually appears at line 9 in the source file.
A minimal (and probably unnecessary) example can be found here.

I was going to jump on this as my first issue, but I think it was already fixed here: https://github.com/rust-lang-nursery/rustfmt/pull/2998

Sorry, my bad. @wez470 Thanks!

authors: bradfier topecongiro wez470

repo: rust-lang-nursery/rustfmt


text:
Use correct name for undefined linked toolchain invocation

Closes #927.

Thanks @topecongiro!
Can you add a test to cli-exact.rs that captures the output of of cargo +bogus test after this?

@brson I will try and rebase. Thank you!

@bors r+ Thanks @topecongiro !

:pushpin: Commit ded5ee2 has been approved by brson

:hourglass: Testing commit ded5ee2 with merge 3b8ad1e...

:broken_heart: Test failed - status-appveyor

Interesting failure here @topecongiro on windows. It looks to me like it's failing because on windows rustup is emitting a "info: found 0 remaining processes" .... which is bizarre. I think you should just delete that info! line from job.rs to make all platforms agree.

@brson Thank you for pointing out! Rebased.

@bors r+

:pushpin: Commit 645f2d9 has been approved by brson

:hourglass: Testing commit 645f2d9 with merge 3b0337c...

:broken_heart: Test failed - status-appveyor

:bulb: This pull request was already approved, no need to approve it again.

This pull request previously failed. You should add more commits to fix the bug, or use retry to trigger a build again.

@bors r+

:pushpin: Commit 645f2d9 has been approved by brson

@bors r+

:bulb: This pull request was already approved, no need to approve it again.

This pull request previously failed. You should add more commits to fix the bug, or use retry to trigger a build again.
There's another pull request that is currently being tested, blocking this pull request: #1015

:pushpin: Commit 645f2d9 has been approved by brson

authors: bors brson topecongiro


text:
Remove empty directories after component uninstall

Re #596. I've placed the test in tests/cli-v2.rs, remove_target; there's an almost identical one, with the same name, in tests/cli-rustup.rs, which I haven't modified.
Edit: the code does the removal pass unconditionally, as opposed to the suggestion in the issue; however, I don't see how the situation where rustup is allowed to remove the component's files, but not directories, could arise. What am I overlooking?

@inejge thank you! Unfortunately it's the end of the day here and I'm tired. I'll try to review over the weekend.
The situation where the directory can't be removed is theoretical. The installation code is intended to be used not just in rustup but for Rust packages anywhere (e.g. the installers on the main website today are the same installation format and they install to the system). I don't feel too strongly about it.

Ah, OK. The code should then be usable as is. I've pushed another commit with fixes for a couple of nits I've noticed in the meantime.

Thanks @inejge!

authors: brson inejge


text:
"This app can't run on your PC" when targeting release

Problem
My problem is that when compiling for debug, everything works fine but when I want to target release or publish the package, the output binary won't run and will just show the Windows message "This app can't run on your PC".
Steps

Clone my repo: https://github.com/bennett-sh/wemod-pro-unlocker
Go into the cli folder
Run cargo build
|-> Executable should run normally
Run cargo build --release
|-> Executable won't run

Possible Solution(s)
No response
Notes
No response
Version
cargo 1.61.0 (a028ae42f 2022-04-29)
release: 1.61.0
commit-hash: a028ae42fc1376571de836be702e840ca8e060c2
commit-date: 2022-04-29
host: x86_64-pc-windows-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:Schannel)
os: Windows 10.0.22623 (Windows 10 Pro) [64-bit]

I found out that this is not an issue with cargo, but with a specific dependency.

repo: rust-lang/cargo


text:
cargo test shows the error by twice

That builds your crate once normally for the integration tests, and once as the unit test library. So two compiles with the same code base: two errors.
It would better if were showed only one error; so, one option could be if there are any error at integration tests, then do not compile unit test library.

Thanks for the report! What's actually happening here is that the library is being compiled twice (once with --test and once for doc tests later on), and this is a dupe of https://github.com/rust-lang/cargo/issues/1534 and https://github.com/rust-lang/cargo/issues/851 (now tracked at https://github.com/rust-lang/cargo/issues/1198). This is intended behavior though, and you can use various flags like --test, --lib, or -j to not run rustc in parallel, so I'm going to close this.

authors: alexcrichton kless


text:
chore(ci): Ensure intradoc links are valid

The plan is to move the architecture documents over to rustdoc so they can more easily stay up-to-date.  To do so, we'll need to enforce that the intradoc links stay valid.
As part of this, the PR run for cargo doc was updated to the command in #11019

Did a run without the fixes to ensure CI will report the failure: https://github.com/rust-lang/cargo/runs/8209088968?check_suite_focus=true

Thanks!
@bors r+

:pushpin: Commit 4b2837a4ccce923bc51e9b577460d257d16f9293 has been approved by ehuss
It is now in the queue for this repository.

:hourglass: Testing commit 4b2837a4ccce923bc51e9b577460d257d16f9293 with merge 9467f81fbf340b70f7ab7e3290146350133f3ea3...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 9467f81fbf340b70f7ab7e3290146350133f3ea3 to master...

authors: bors ehuss epage


text:
fix(help): Remove redundant information from new/init

Auditing all of the --help in prep for #12578 and noticed that we list the VCS information twice, once on our end and once by clap.

Can we do rollup in Cargo 😆?
@bors r+ rollup=always

:pushpin: Commit ad0a11349e0c9b52664c842d40a0960a08de5cb1 has been approved by weihanglo
It is now in the queue for this repository.

Can we do rollup in Cargo 😆?

Yeah, chose to do multiple PRs for this because so its easier to deal with it if there is push back against any of these ideas

Actually I mean the rollup in bors. I think we are able to do that in rust-lang/cargo. Just never saw anyone doing it.

:hourglass: Testing commit ad0a11349e0c9b52664c842d40a0960a08de5cb1 with merge a873df5c39eac8d316eaa695e69bcb4b2f5af9a7...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing a873df5c39eac8d316eaa695e69bcb4b2f5af9a7 to master...

authors: bors epage weihanglo


text:
Update suggestion message on bad project name error

closes #9876
Error message suggest adding [bin] to Cargo.toml which should be [[bin]] instead.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.
Please see the contribution instructions for more information.

:pushpin: Commit cb2932e47b1c9768fd115499e77bb8a66a0a23cd has been approved by ehuss

:hourglass: Testing commit cb2932e47b1c9768fd115499e77bb8a66a0a23cd with merge 38b4c6ed955c89d5738a63e38834e4f1c5f46464...

@bors r+

:bulb: This pull request was already approved, no need to approve it again.

This pull request is currently being tested. If there's no response from the continuous integration service, you may use retry to trigger a build again.

:pushpin: Commit cb2932e47b1c9768fd115499e77bb8a66a0a23cd has been approved by ehuss

:hourglass: Testing commit cb2932e47b1c9768fd115499e77bb8a66a0a23cd with merge 941b12368962056731c7b033fd786f5415aa7d7b...

:sunny: Test successful - checks-actions
Approved by: ehuss
Pushing 941b12368962056731c7b033fd786f5415aa7d7b to master...

authors: bors dswij ehuss rust-highfive


text:
windows-sys crate build failure

Crate name
windows-sys
Build failure link
https://docs.rs/crate/windows-sys/0.36.0/builds/548347
Additional details
Memory usage is peaking locally around 3.5GB. So short term, I think we could use a boost to perhaps 5GB. Would like to also brainstorm options with the team on how we move forward with windows and windows-sys. (I'll jump on Discord.)

@riverar I just increased the memory limit for the windows-sys crate to 5 GB.
Also I triggered a rebuild for the failed version, see https://docs.rs/releases/queue . It's lowest priority but will be handled when the other recent releases are finished.
There was some discussion about reducing memory usage in https://github.com/rust-lang/docs.rs/issues/1633, related to other issues about azure library builds

@syphar Great, thanks!
I reviewed the discussion and sadly nothing there applies. windows and windows-sys are just edge case extremely large crates (the Windows API surface is huge). We're going to have to huddle up across rustdoc, docs.rs, and windows teams and figure out a way forward.

authors: riverar syphar

license: MIT


text:
Remove unnecessary redirect

Once https://github.com/rust-lang/docs.rs/pull/534 gets merged, the 'Platform' dropdown will link to the default build /:crate/:version/:platform, which will immediately redirect to /:crate/:version. It would be nice to link to /:crate/:version directly for the default platform.

Here's some half-working code (goes in src/web/rustdoc.rs):
    let target_links = {
        use std::collections::HashMap;
        let mut map = HashMap::new();
        for target in &crate_details.doc_targets {
            match target {
                Json::String(target) => {
                    if target == &crate_details.metadata.default_target {
                        map.insert(target, "".to_owned());
                    } else {
                        let path = format!("/{}", target);
                        map.insert(target, path);
                    }
                }
                _ => log::warn!("unknown JSON type for doc_target: {}", target),
            }
        }
        map
    };

To implement this:

Add a target_links field to CrateDetails
Fill out that field using the code above.
Use those links in the template instead of always using the {{this}} variable.

I'll take a look at this, thanks for all the work outlining what needs to be done.

Is double clicking on the platform drop down supposed to automatically redirect you?

I wouldn't expect it too ... you're suggesting it should take you to the default platform? I'd be ok with that.

@jyn514 I think I assumed a bit too much when glancing over the issue :). I don't have a preference either way, but I'll add it as part of this PR and we can get opinions from the larger team.

@pietroalbini do you think this is still worth fixing? I kind of like that it's consistent with all the other redirects, it makes it easier to reason about reading the code.


text:
Match unified NDK headers

Before Android NDK r14b, each android api version has their own libc headers set which were not totally correct.
Since Android NDK r14b, Google unified the headers so that they apply to all api version (using #ifdef when needed to differentiate between mismatching versions). These new headers are directly taken from the bionic source which was not apparently the case before.
Unfortunately, this crate was based on these not unified headers and contain some incompatibilities with the new correct headers.
For now, we manage to update the NDK used to r15b by skipping the tests of the functions and structs that have changed. But ideally, we should update these functions to match the new headers for the next major version of libc.
So, for new symbols, please do not look into $NDK_PATH/platforms/android-xx/arch-arm/usr/include for reference but into $NDK_PATH/sysroot/usr/include as this path contains the new headers.
Here is a list of the changes written in C that we need to cover for the next major release:

int getpriotity(int, int) --> int getpriority(int, id_t) (id_t is uin32_t and is already defined as libc::id_t)

int setpriority(int, int, int) --> int setpriority(int, id_t, int)

int personality (unsigned long) --> personality(unsigned int)

stat struct is probably a bit harder to fix:
These fields:
long st_atime;
unsigned long st_atime_nsec;
long st_mtime;
unsigned long st_mtime_nsec;
long st_ctime;
unsigned long st_ctime_nsec;

became:
struct timespec st_atim;
struct timespec st_mtim;
struct timespec st_ctim;

where timespec is defined as:
struct timespec {
  time_t tv_sec;
  long tv_nsec;
};

and some #define allow to still have fields like st_mtime_nsec:
#define st_atime st_atim.tv_sec
#define st_mtime st_mtim.tv_sec
#define st_ctime st_ctim.tv_sec

#define st_atime_nsec st_atim.tv_nsec
#define st_mtime_nsec st_mtim.tv_nsec
#define st_ctime_nsec st_ctim.tv_nsec

#define st_atimensec st_atim.tv_nsec
#define st_mtimensec st_mtim.tv_nsec
#define st_ctimensec st_ctim.tv_nsec

It means we could just keep the stat struct as is and just change the types of *_mtime and *_nsec to match the nex types and drop the new fields st_atim (without final e) and st_atimensec an alike (without the underscore before nsec) or find a way to present the field with different names.

int strerror_r(int, char*, size_t) --> char* strerror_r(int, char*, size_t)
The old function is still present and accessible through the symbol strerror_r, the new one is accessible through _gnu_strerror_r. The solution is more probably simply just to ignore the new function and let strerror_r as is.

int madvise(const void*, size_t, int) --> int madvise(void*, size_t, int)

int msync(const void*, size_t, int) --> int msync(void*, size_t, int)

int mprotect(const void*, size_t, int) --> int mprotect(void*, size_t, int)

ssize_t recvfrom(int, void*, size_t, int, const struct sockaddr*, socklen_t*) --> ssize_t recvfrom(int, void*, size_t, int, struct sockaddr*, socklen_t*)

int bind(int, const struct sockaddr*, int) --> int bind(int, const struct sockaddr*, socklen_t) (only applies to android 64 bits, do not know why we bounded it correctly in 32 bits)

int writev(int, const struct iovec *, int) --> ssize_t writev(int, const struct iovec*, int) (same remark, only applies to android 64 bits)

int readv(int, const struct iovec *, int) --> ssize_t readv(int, const struct iovec*, int) (same remark)

int sendmsg(int, const struct msghdr*, int) --> ssize_t sendmsg(int, const struct msghdr*, int) (same remark)

int recvmsg(int, struct msghdr*, int) --> ssize_t recvmsg(int, struct msghdr*, int) (same remark)

Thanks for opening this @ndusart!

This is fixed (or should be) fixed on master.

authors: alexcrichton gnzlbg ndusart

repo: rust-lang/libc


text:
Fix linux ioctl BLKSSZGET and BLKPBSZGET constants types.

The BLKSSZGET and BLKPBSZGET constants weren't arch dependent as they should have.

r? @Amanieu
(rust-highfive has picked a reviewer for you, use r? to override)

@bors r+

:pushpin: Commit 426dfabea877cf195f0fd238a45af5e8c8ef3be4 has been approved by Amanieu

:sunny: Test successful - checks-actions, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, checks-cirrus-freebsd-13
Approved by: Amanieu
Pushing 7f1da49dd4207d5a0bb28a5838fa21ff7befc4f7 to master...

authors: Amanieu Mek101 bors rust-highfive


text:
cargo-miri has problems with spaces in sysroot

I've installed miri via rustup add component miri
rustc 1.36.0-nightly (8aaae4294 2019-04-19)
binary: rustc
commit-hash: 8aaae4294b16b8070a52b858364f440873bfc95c
commit-date: 2019-04-19
host: x86_64-pc-windows-msvc
release: 1.36.0-nightly
LLVM version: 8.0

When trying to run a hello world crate via miri, I get the following output:
$ cargo miri
It seems you do not have a recent enough xargo installed. I will run `cargo install xargo -f`. Proceed? [Y/n] Y
    Updating crates.io index
  Downloaded xargo v0.3.13
  Downloaded 1 crates (186.6 KB) in 0.77s
  Installing xargo v0.3.13
  Downloaded rustc_version v0.1.7
  Downloaded rand v0.4.6
  Downloaded semver v0.1.20
  Downloaded serde_json v0.8.6
  Downloaded error-chain v0.7.2
  Downloaded itoa v0.1.1
  Downloaded dtoa v0.2.2
   Compiling winapi-build v0.1.1
   Compiling winapi v0.3.7
   Compiling autocfg v0.1.2
   Compiling num-traits v0.2.6
   Compiling winapi v0.2.8
   Compiling rustc-demangle v0.1.14
   Compiling cfg-if v0.1.7
   Compiling libc v0.2.51
   Compiling xargo v0.3.13
   Compiling itoa v0.1.1
   Compiling rustc-serialize v0.3.24
   Compiling dtoa v0.2.2
   Compiling semver v0.1.20
   Compiling serde v0.8.23
   Compiling kernel32-sys v0.2.2
   Compiling backtrace v0.3.15
   Compiling rustc_version v0.1.7
   Compiling num-traits v0.1.43
   Compiling serde_json v0.8.6
   Compiling toml v0.2.1
   Compiling rand v0.4.6
   Compiling remove_dir_all v0.5.1
   Compiling fs2 v0.4.3
   Compiling dirs v1.0.5
   Compiling error-chain v0.7.2
   Compiling tempdir v0.3.7
   Compiling same-file v0.1.3
   Compiling walkdir v1.0.7
    Finished release [optimized] target(s) in 47.60s
  Installing C:\Users\Felix Schütt\.cargo\bin\xargo.exe
   Installed package `xargo v0.3.13` (executable `xargo.exe`)
It seems you do not have the rust-src component installed. I will run `rustup component add rust-src`. Proceed? [Y/n] Y
info: downloading component 'rust-src'
info: installing component 'rust-src'
    Updating crates.io index
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names -Zalways-encode-mir -Zmir-emit-retag -Zmir-opt-level=0 --cfg=miri --sysroot 'C:\Users\Felix' 'Schütt\AppData\Local\miri\miri\cache\HOST' -Z force-unstable-if-unmarked --target x86_64-pc-windows-msvc --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 1)
--- stderr
error: multiple input filenames provided (first two filenames are `-` and `Schütt\AppData\Local\miri\miri\cache\HOST`)

error: `"cargo" "build" "--release" "--manifest-path" "C:\\Users\\FELIXS~1\\AppData\\Local\\Temp\\xargo.NZRWjaHsFAad\\Cargo.toml" "--target" "x86_64-pc-windows-msvc" "-p" "std"` failed with exit code: Some(101)
note: run with `RUST_BACKTRACE=1` for a backtrace
fatal error: Failed to run xargo

$ RUST_BACKTRACE=1 cargo miri
    Updating crates.io index
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names -Zalways-encode-mir -Zmir-emit-retag -Zmir-opt-level=0 --cfg=miri --sysroot 'C:\Users\Felix' 'Schütt\AppData\Local\miri\miri\cache\HOST' -Z force-unstable-if-unmarked --target x86_64-pc-windows-msvc --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 1)
--- stderr
error: multiple input filenames provided (first two filenames are `-` and `Schütt\AppData\Local\miri\miri\cache\HOST`)

error: `"cargo" "build" "--release" "--manifest-path" "C:\\Users\\FELIXS~1\\AppData\\Local\\Temp\\xargo.c7N5WMu814CD\\Cargo.toml" "--target" "x86_64-pc-windows-msvc" "-p" "std"` failed with exit code: Some(101)
stack backtrace:
   0: <no info> (0x7ff668d2af52)
   1: <no info> (0x7ff668d2aff3)
   2: <no info> (0x7ff668cf78b7)
   3: <no info> (0x7ff668cec354)
   4: <no info> (0x7ff668cf1e5f)
   5: <no info> (0x7ff668cdc1fa)
   6: <no info> (0x7ff668cf8746)
   7: <no info> (0x7ff668d47b77)
   8: <no info> (0x7ff668d532b2)
   9: <no info> (0x7ff668d48422)
  10: <no info> (0x7ff668cdd2a7)
  11: <no info> (0x7ff668d62678)
  12: BaseThreadInitThunk (0x7fffb15413d2)
fatal error: Failed to run xargo

It seems that either xargo or miri is handling the sysroot wrong and splits the sysroot by spaces, so it doesn't find the sysroot if the path contains spaces:
--sysroot 'C:\Users\Felix' 'Schütt\AppData\Local\miri\miri\cache\HOST'

should be a single argument:
--sysroot 'C:\Users\Felix Schütt\AppData\Local\miri\miri\cache\HOST'

Interesting. I can reproduce this locally without Miri being involved -- the issue is in xargo or further upstream:
$ XARGO_HOME=~/.cache/"mi ri" XARGO_RUST_SRC=~/"src/rust/rustc/src" xargo build -v
+ "rustc" "--print" "sysroot"
+ RUSTFLAGS="--sysroot /home/r/.cache/mi ri/HOST -Z force-unstable-if-unmarked"
+ "cargo" "build" "--release" "--manifest-path" "/tmp/xargo.BGZjgFbURhmN/Cargo.toml" "--target" "x86_64-unknown-linux-gnu" "-v" "-p" "std"
    Updating crates.io index
error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `rustc - --crate-name ___ --print=file-names --sysroot /home/r/.cache/mi ri/HOST -Z force-unstable-if-unmarked --target x86_64-unknown-linux-gnu --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (exit code: 1)
--- stderr
error: multiple input filenames provided (first two filenames are `-` and `ri/HOST`)

Actually, it's a cargo issue: https://github.com/rust-lang/cargo/issues/6139

Also see this xargo issue: https://github.com/japaric/xargo/issues/206

The xargo issue got fixed by https://github.com/japaric/xargo/pull/336.
Could someone who was affected by this problem try installing the most recent xargo (cargo install --git https://github.com/japaric/xargo) and see if that fixes Miri?

authors: RalfJung fschutt

repo: rust-lang/miri


text:
Support zone id when parsing / formatting SocketAddrV6

SocketAddrV6 contains a field scope_id (AKA zone id in RFCs).
In RFC4007, a textual representation for an IPv6 address with a zone id is specified, where the zone id is appended to the ipv6 address with % as a separator.
I think it would be very useful and quite easy to add parsing of a numeric zone id to read_socket_addr_v6.
For improved usability, adding support for interface names would be nice, but those would need to be converted to interface indices using OS specific interfaces (like libc::if_nametoindex on linux).
When formatting a SocketAddrV6, the zone id could be printed if it's not 0. (But that could be seen as an incompatible change.)

A related problem is around parsing a Ipv6Addr address with a zone index. This panics in Rust now but should be parseable.
cc https://github.com/rust-lang/rust/issues/32904

Yes, this is not just related, it's exactly the same issue. Thanks for pointing it out, I didn't know that ticket.
However, I think this should be handled in SocketAddrV6, not Ipv6Addr, for these reasons:

SocketAddrV6 already contains the field scope_id, so the fix would only affect parsing / formatting code, not the data structures.
Most everyday usages of IPv6 addresses don't need a scope id, so making Ipv6Addr more complicated may do more harm than good.
There are many cases where a scope id can't easily be communicated in a meaningful way, e.g. in URLs. This is because scope ids are host-specific, and only minimally specified. RFC6874 lists some of the shortcomings. Chrome and Mozilla chose not to implement them in URLs. So applications may or may not want to support scope ids when parsing IPv6 addresses.
A SocketAddrV6 is a more technical thing, less likely to be presented to end users and more likely to be used in situations where a scope id is neccessary. (Well - I can't give a citation for this claim. It's just my experience.)

authors: achanda jannic

repo: rust-lang/rfcs


text:
Mini-RFC: Make .. a pattern syntactically

Make .. a pattern rather than a syntactic fragment of some other patterns.
Follow up to https://github.com/rust-lang/rfcs/pull/2359.
Edit: Rendered

@rfcbot merge
See https://github.com/rust-lang/rfcs/pull/2359#issuecomment-500030549 for rationale.

N.B. I have checked Aaron's box as they are on leave.

🎉 Huzzah! This RFC has been merged! 🎉
Tracking issue: https://github.com/rust-lang/rust/issues/62254

authors: Centril petrochenkov


text:
Clif ir and vcode/asm inspector

This inspector allow you to pick a single function and then present the clif ir (before and after optimization) and compiled vcode/asm of said function. It should also show the mapping between clif ir and vcode instructions in a way similar to godbolt's compiler explorer. As a bonus it could also show the original rust source and the mir of the compiled function. Preferably the inspector would be usable for other Cranelift users too if they dump all necessary info in the right format.

This would be a great feature.
Short of a nice GUI, is there a way to dump the intermediate CLIF code right now for inspection? Forgive me if I've missed something in the documentation, it's not come up in my searching so far. Thanks.

Ah, makes sense! Thank you!


text:
DBSCAN does not count border points

The DBSCAN implementation in linfa-clustering only includes core points with minPts neighbours. Border points (points with less than minPts neighbours) connected to core points are counted as noise, which is different behaviour from how DBSCAN is typically described. Is this behaviour intentional or a bug?

Hi, nice find, I don't believe that they should be counted as noise. In theory, border points could belong to more than one cluster but, since we can only return a single cluster membership value for each point, I believe that we should arbitrarily choose a single cluster for each border point like the approximate dbscan implementation does. Would you like to open a PR fixing this? This should be fixable with like three lines of code I think 👍🏻

Might also be an issue with appx_dbscan as well, since those tests are failing after my fix.

resolved in #100

authors: Sauro98 YuhanLiin bytesnake

repo: rust-ml/linfa


text:
Carry only single word in multiplication

The carry from a multiply or a multiply-accumulate is a single word,
so update the functions to clarify that. Use a temporary double word for the
computation. And rename "acc" to "carry" to distinguish from the accumulator.
Also use multiply instead of multiply-accumulate for string conversions.
And remove an unnecessary mask in get_lo().

Have you run benchmarks for this change? It has been pretty sensitive in the past, whether this ultimately coaxes good behavior out of LLVM.

Closing for inactivity; please feel free to reopen when ready.

authors: calebsander cuviper

repo: rust-num/num-bigint


text:
Make more functions const.

Other than just adding const a few times, this:

Replaces the array_init dependency by the const_in_array_repeat_expressions feature.

Implements VirtAddr::new_unchecked using a multiply and divide instead of set_bits in an if. (Bonus: Resulting assembly is much much shorter.)

Thanks!

Released together with #115 as version 0.8.3

authors: m-ou-se phil-opp


text:
Implement query parameter extraction

Description
Add serde_qs based query string extraction (QueryParams) next to the existing UrlQuery (-> QueryString), which extracts the entire query string and parses using FromStr.
Motivation and Context
See #147.
How Has This Been Tested?
~So far only type based plumbing.~ Documentation test.
Types of changes

~Bug fix (non-breaking change which fixes an issue)~
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Needs to be rewritten after #156.

repo: rustasync/tide


text:
Fix build with human-panic 1.0.2

Fixes #818

Closing since human-panic 1.0.2 is yanked

repo: rustwasm/wasm-pack


text:
IndexError: list index out of range when calling jittable()

🐛 Bug
Hi, I want to use the torch.jit feature on my graph model.
I install pytorch and PyG from source on a docker machine, it runs pretty well, but when I call jittable() on the module, an index error will appear.
To Reproduce
Steps to reproduce the behavior:
>>>import torch
>>>import torch_geometric as geo
>>>m = geo.nn.ChebConv(4, 8, 2).jittable()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/dist-packages/torch_geometric/nn/conv/message_passing.py", line 340, in jittable
    ['message', 'aggregate', 'update'])
  File "/usr/local/lib/python3.6/dist-packages/torch_geometric/nn/conv/utils/inspector.py", line 42, in types
    arg_types = parse_types(func)[0][0]
  File "/usr/local/lib/python3.6/dist-packages/torch_geometric/nn/conv/utils/typing.py", line 95, in parse_types
    arg_types = OrderedDict((k, param_type_repr(v)) for k, v in ps.items())
  File "/usr/local/lib/python3.6/dist-packages/torch_geometric/nn/conv/utils/typing.py", line 95, in <genexpr>
    arg_types = OrderedDict((k, param_type_repr(v)) for k, v in ps.items())
  File "/usr/local/lib/python3.6/dist-packages/torch_geometric/nn/conv/utils/typing.py", line 57, in param_type_repr
    return sanitize(re.split(r': | =', str(param))[1])
IndexError: list index out of range

This error not only when using ChebConv, but also appear on other types of GNN layers.
When using MessagePassing a different error will appear
>>>m = geo.nn.MessagePassing().jittable()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/dist-packages/torch_geometric/nn/conv/message_passing.py", line 336, in jittable
    prop_types = dict([re.split(r'\s*:\s*', t) for t in prop_types])
ValueError: dictionary update sequence element #2 has length 1; 2 is required

Expected behavior

Environment

OS: Ubuntu 18.04.3 LTS
Python version: 3.6.9
PyTorch version: 1.6
CUDA/cuDNN version: 10.1/7.6.5
GCC version: 7.5
Any other relevant information:
pytorch_geometric version: 1.6
Docker version: 19.03.12
Image: ufoym/deepo:latest

Additional context

This might be related to Python 3.6. I need to look into it :)

Doesn't seem to be related to Python 3.6, as all tests pass with it (see here).

@rusty1s After upgrading to 1.6.1 this error disappeared.


text:
Converting a Data object back into a Networkx Graph?

Is there a simple way to convert a pytorch Data Object of a graph into a Networkx graph and vice-versa? The obvious way is to rebuild the graph by iterating through all the edges and nodes but is there a pre-built method that already does that (I wasn't able to find one with a quick search)?

Yeah, our documentation search seems to be broken at the moment, but the utils subpackage provides from_networkx and to_networkx functions :)

Thanks, will definitely look at it!


text:
Emit socket error events

Totally up to you whether you want to accept this, but I needed to make some of these changes so I figured I would see if you wanted them.
Reasons for the changes:

Net socket errors were never emitted, so if the initial connection failed, an error would be asynchronously thrown with no good way to catch it.
The isConnected state variable and the 'connect' event were being triggered regardless of it a connection was actually established. I left the 'connect' event that way just in case it's supposed to mean it's starting to connect
Deleted isReady since it didn't appear to be used anywhere

Deleted isReady since it didn't appear to be used anywhere

isReady is used by Johnny-Five as part of the required IO-Plugin semantics.

authors: gsbucks rwaldron

repo: rwaldron/particle-io

license: mit


text:
[enhancement] Aggregation to non-calendar periods

Currently, the aggregation for PfLine and PfState instances is done with .asfreq(freq), with the parameter freq being "MS", "QS", or "'AS'", to aggregate to monthly, quarterly, or yearly values.
What is not yet possible, is to aggregate to e.g. business years (let's say starting at April 1), or to time periods of e.g. 15 months.
The following proposal (up for discussion):

Allow not only "AS", but also e.g. "AS-APR" as value for freq. This would aggregate the values between April 1 0:00 (incl) and April 1 0:00 (excl) the next year. Compare:

>>> pd.date_range('2022', freq="AS-APR", periods=10)
DatetimeIndex(['2022-04-01', '2023-04-01', '2024-04-01', '2025-04-01',
               '2026-04-01', '2027-04-01', '2028-04-01', '2029-04-01',
               '2030-04-01', '2031-04-01'],
              dtype='datetime64[ns]', freq='AS-APR')

For more exotic aggregations, allow "all" as value for freq. This would aggregate over all time periods in the PfLine or PfState. Here, the implications are a bit more difficult, as this is not supported out of the box by pandas.

See attached xlsx for more elaborate explanation
explainer.xlsx

repo: rwijtvliet/portfolyo


text:
Missing license

In absence of a license, it's difficult for anyone to decide if they can contribute, or even read the code.

MIT License added. Thank you!

authors: gurjeet rwv


text:
bonzai does not work when pyenv in $PATH

Hi, thanks for your work and streams. Bonzai is an excellent idea and I am planning to move my scritps as well to it after I understand how to use it.
I have pyenv on my environment, running any bonzai command that calls a help command fails with pyenv: no such command "tmp/hlpe-XXXXX"
If I remove pyenv from my $PATH bonzai help command works. Why would the pyenv executable be called ? I never encountered this issue.
Is there a way to traceback command exection ? I am willing to fix it if I can the debug the call. strace was not  helpfulp.
It should be easy to reproduce by just installing pyenv. The bug happen under any shell (bash, zsh, fish ...)
Thanks.

There is nothing directly related to pyenv anywhere. The pager will look for a pager in the environment, perhaps that is affecting it. If you could provide the OS you are using and perhaps a recreation of code that produces the error I can help get into it.

Just an update that the problem seems resolved for me now. I have no idea what was the issue. If the problem happens again I will investigate.
Thanks a lot for this project.

repo: rwxrob/bonzai


text:
Argument required: Plugin

I was trying to install Plugins via vundle, although it successfully installed plugins, when type vim it throw out following errors:

Error detected while processing /home/haoliu/.vimrc:
line  248:
E471: Argument required: Plugin
line  249:
E471: Argument required: Plugin
line  250:
E471: Argument required: Plugin
line  251:
E471: Argument required: Plugin
line  252:
E471: Argument required: Plugin
line  253:
E471: Argument required: Plugin
line  254:
E471: Argument required: Plugin
line  255:
E471: Argument required: Plugin
line  256:
E471: Argument required: Plugin
line  257:
E471: Argument required: Plugin
line  258:
E471: Argument required: Plugin
line  259:
E471: Argument required: Plugin
line  260:
E471: Argument required: Plugin
line  261:
E471: Argument required: Plugin
line  262:
E471: Argument required: Plugin
line  263:
E471: Argument required: Plugin
Press ENTER or type command to continue

Here is what my ~/.vimrc file looks like(in fact, I only modified bundle plugins parts):

" based on http://github.com/jferris/config_files/blob/master/vimrc
" Use Vim settings, rather then Vi settings (much better!).
" This must be first, because it changes other options as a side effect.
set nocompatible
" allow backspacing over everything in insert mode
set backspace=indent,eol,start
set nobackup
set nowritebackup
set history=50		" keep 50 lines of command line history
set ruler		" show the cursor position all the time
set showcmd		" display incomplete commands
set incsearch		" do incremental searching
" Don't use Ex mode, use Q for formatting
map Q gq
" This is an alternative that also works in block mode, but the deleted
" text is lost and it only works for putting the current register.
"vnoremap p "_dp
" Switch syntax highlighting on, when the terminal has colors
" Also switch on highlighting the last used search pattern.
if (&t_Co > 2 || has("gui_running")) && !exists("syntax_on")
syntax on
set hlsearch
endif
" Switch wrap off for everything
set nowrap
" Only do this part when compiled with support for autocommands.
if has("autocmd")
" Enable file type detection.
" Use the default filetype settings, so that mail gets 'tw' set to 72,
" 'cindent' is on in C files, etc.
" Also load indent files, to automatically do language-dependent indenting.
filetype plugin indent on
" Set File type to 'text' for files ending in .txt
autocmd BufNewFile,BufRead *.txt setfiletype text
" Enable soft-wrapping for text files
autocmd FileType text,markdown,html,xhtml,eruby setlocal wrap linebreak nolist
" Put these in an autocmd group, so that we can delete them easily.
augroup vimrcEx
au!
" For all text files set 'textwidth' to 78 characters.
" autocmd FileType text setlocal textwidth=78
" When editing a file, always jump to the last known cursor position.
" Don't do it when the position is invalid or when inside an event handler
" (happens when dropping a file on gvim).
autocmd BufReadPost *
\ if line("'"") > 0 && line("'"") <= line("$") |
\   exe "normal g`"" |
\ endif
" Automatically load .vimrc source when saved
autocmd BufWritePost .vimrc source $MYVIMRC
augroup END
else
set autoindent		" always set autoindenting on
endif " has("autocmd")
" if has("folding")
" set foldenable
" set foldmethod=syntax
" set foldlevel=1
" set foldnestmax=2
" set foldtext=strpart(getline(v:foldstart),0,50).'\ ...\ '.substitute(getline(v:foldend),'^[\ #]*','','g').'\ '
" endif
" Softtabs, 2 spaces
set tabstop=2
set shiftwidth=2
set expandtab
" Always display the status line
set laststatus=2
" \ is the leader character
let mapleader = ","
" Edit the README_FOR_APP (makes :R commands work)
map R :e doc/README_FOR_APP
" Leader shortcuts for Rails commands
map m :Rmodel
map c :Rcontroller
map v :Rview
map u :Runittest
map f :Rfunctionaltest
map tm :RTmodel
map tc :RTcontroller
map tv :RTview
map tu :RTunittest
map tf :RTfunctionaltest
map sm :RSmodel
map sc :RScontroller
map sv :RSview
map su :RSunittest
map sf :RSfunctionaltest
" Hide search highlighting
map h :set invhls
" Opens an edit command with the path of the currently edited file filled in
" Normal mode: e
map e :e =expand("%:p:h") . "/"
" Opens a tab edit command with the path of the currently edited file filled in
" Normal mode: t
map te :tabe =expand("%:p:h") . "/"
" Inserts the path of the currently edited file into a command
" Command mode: Ctrl+P
cmap  =expand("%:p:h") . "/"
" Duplicate a selection
" Visual mode: D
vmap D y'>p
" Press Shift+P while in visual mode to replace the selection without
" overwriting the default register
vmap P p :call setreg('"', getreg('0'))
" For Haml
au! BufRead,BufNewFile *.haml         setfiletype haml
" No Help, please
nmap
" Press ^F from insert mode to insert the current file name
imap  =expand("%")
" Maps autocomplete to tab
imap
imap  =>
" Display extra whitespace
" set list listchars=tab:»·,trail:·
" Edit routes
command! Rroutes :e config/routes.rb
command! Rschema :e db/schema.rb
" Local config
if filereadable(".vimrc.local")
source .vimrc.local
endif
" Use Ack instead of Grep when available
if executable("ack")
set grepprg=ack\ -H\ --nogroup\ --nocolor\ --ignore-dir=tmp\ --ignore-dir=coverage
endif
" Color scheme
" colorscheme vividchalk
" highlight NonText guibg=#060606
" highlight Folded  guibg=#0A0A0A guifg=#9090D0
" Numbers
set number
set numberwidth=5
" Snippets are activated by Shift+Tab
let g:snippetsEmu_key = ""
" Tab completion options
" (only complete to the longest unambiguous match, and show a menu)
set completeopt=longest,menu
set wildmode=list:longest,list:full
set complete=.,t
" case only matters with mixed case expressions
set ignorecase
set smartcase
" Tags
let g:Tlist_Ctags_Cmd="ctags --exclude='*.js'"
set tags=./tags;
let g:fuf_splitPathMatching=1
" Open URL
command -bar -nargs=1 OpenURL :!open
function! OpenURL()
let s:uri = matchstr(getline("."), '[a-z]://[^ >,;:]')
echo s:uri
if s:uri != ""
exec "!open "" . s:uri . """
else
echo "No URI found in line."
endif
endfunction
map w :call OpenURL()
"disable arrow key movement"
noremap
noremap
noremap
noremap
set nocompatible              " be iMproved, required
filetype off                  " required
" set the runtime path to include Vundle and initialize
set rtp+=~/.vim/bundle/Vundle.vim
call vundle#begin()
" alternatively, pass a path where Vundle should install plugins
"call vundle#begin('~/some/path/here')
" let Vundle manage Vundle, required
Plugin 'VundleVim/Vundle.vim'
" Define Plugins via Github repos
Plugin 'christoomey/vim-run-interactive'
"Plugin 'Valloric/YouCompleteMe'"
Plugin 'croaky/vim-colors-github'
Plugin 'danro/rename.vim'
Plugin 'majutsushi/tagbar'
Plugin 'kchmck/vim-coffee-script'
Plugin 'kien/ctrlp.vim'
Plugin 'pbrisbin/vim-mkdir'
Plugin 'scrooloose/syntastic'
Plugin 'slim-template/vim-slim'
Plugin 'thoughtbot/vim-rspec'
Plugin 'tpope/vim-endwise'
Plugin 'tpope/vim-fugitive'
Plugin 'tpope/vim-rails'
Plugin 'tpope/vim-surround'
Plugin 'vim-ruby/vim-ruby'
Plugin 'vim-scripts/ctags.vim'
Plugin 'vim-scripts/matchit.zip'
Plugin 'vim-scripts/tComment'
Plugin "mattn/emmet-vim"
Plugin "scrooloose/nerdtree"
Plugin "Lokaltog/vim-powerline"
Plugin "godlygeek/tabular"
Plugin "msanders/snipmate.vim"
Plugin "jelera/vim-javascript-syntax"
Plugin "altercation/vim-colors-solarized"
Plugin "othree/html5.vim"
Plugin "xsbeats/vim-blade"
Plugin "Raimondi/delimitMate"
Plugin "groenewege/vim-less"
Plugin "evanmiller/nginx-vim-syntax"
Plugin "Lokaltog/vim-easymotion"
Plugin "tomasr/molokai"
Plugin "klen/python-mode"
Plugin "easymotion/vim-easymotion"
" The following are examples of different formats supported.
" Keep Plugin commands between vundle#begin/end.
" plugin on GitHub repo
"Plugin 'tpope/vim-fugitive'"
" plugin from http://vim-scripts.org/vim/scripts.html
" Plugin 'L9'
" Git plugin not hosted on GitHub
Plugin 'git://git.wincent.com/command-t.git'
" git repos on your local machine (i.e. when working on your own plugin)
"Plugin 'file:///home/gmarik/path/to/plugin'"
" The sparkup vim script is in a subdirectory of this repo called vim.
" Pass the path to set the runtimepath properly.
Plugin 'rstacruz/sparkup', {'rtp': 'vim/'}
" Install L9 and avoid a Naming conflict if you've already installed a
" different version somewhere else.
" Plugin 'ascenator/L9', {'name': 'newL9'}
" All of your Plugins must be added before the following line
call vundle#end()            " required
filetype plugin indent on    " required
" To ignore plugin indent changes, instead use:
"filetype plugin on
"
" Brief help
" :PluginList       - lists configured plugins
" :PluginInstall    - installs plugins; append ! to update or just :PluginUpdate
" :PluginSearch foo - searches for foo; append ! to refresh local cache
" :PluginClean      - confirms removal of unused plugins; append ! to auto-approve removal
"
" see :h vundle for more details or wiki for FAQ
" Put your non-Plugin stuff after this line

I don't know what happened, even after google search, could you please tell me why?

It is due to using double quotes instead of single quote in some lines.

repo: ryanb/dotfiles


text:
Android 5 ExoPlayer crash

Hi, the recent update 0.1.4 broke my app on old Android devices, but was later fixed by 0.1.5 so now it is all good.
To investigate the issue I set up an Android 5 emulator (didn't have it before so would not know wether it used to work on versions lower than 0.1.4 or not), and it turns out that (after the initial issues were fixed, upgrading to 0.1.5), the plugin crashes upon trying to play some audio.
...
I/OMXClient(20748): Using client-side OMX mux.
E/AudioTrack(20748): AudioFlinger could not create track, status: -12
E/AudioTrack-JNI(20748): Error -12 initializing AudioTrack
E/android.media.AudioTrack(20748): Error code -20 when initializing AudioTrack.
E/ExoPlayerImplInternal(20748): Playback error
E/ExoPlayerImplInternal(20748):   com.google.android.exoplayer2.ExoPlaybackException: MediaCodecAudioRenderer error, index=1, format=Format(null, null, null, audio/raw, null, -1, null, [-1, -1, -1.0], [2, 44100]), format_supported=YES
E/ExoPlayerImplInternal(20748):       at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:554)
E/ExoPlayerImplInternal(20748):       at android.os.Handler.dispatchMessage(Handler.java:98)
E/ExoPlayerImplInternal(20748):       at android.os.Looper.loop(Looper.java:135)
E/ExoPlayerImplInternal(20748):       at android.os.HandlerThread.run(HandlerThread.java:61)
E/ExoPlayerImplInternal(20748):   Caused by: com.google.android.exoplayer2.audio.AudioSink$InitializationException: AudioTrack init failed 0 Config(44100, 12, 44100)
E/ExoPlayerImplInternal(20748):       at com.google.android.exoplayer2.audio.DefaultAudioSink$Configuration.buildAudioTrack(DefaultAudioSink.java:1999)
E/ExoPlayerImplInternal(20748):       at com.google.android.exoplayer2.audio.DefaultAudioSink.buildAudioTrack(DefaultAudioSink.java:821)
E/ExoPlayerImplInternal(20748):       at com.google.android.exoplayer2.audio.DefaultAudioSink.initializeAudioTrack(DefaultAudioSink.java:626)
E/ExoPlayerImplInternal(20748):       at com.google.android.exoplayer2.audio.DefaultAudioSink.handleBuffer(DefaultAudioSink.java:699)
E/ExoPlayerImplInternal(20748):       at com.google.android.exoplayer2.audio.MediaCodecAudioRenderer.processOutputBuffer(MediaCodecAudioRenderer.java:630)
E/ExoPlayerImplInternal(20748):       at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.drainOutputBuffer(MediaCodecRenderer.java:1854)
E/ExoPlayerImplInternal(20748):       at com.google.android.exoplayer2.mediacodec.MediaCodecRenderer.render(MediaCodecRenderer.java:824)
E/ExoPlayerImplInternal(20748):       at com.google.android.exoplayer2.ExoPlayerImplInternal.doSomeWork(ExoPlayerImplInternal.java:947)
E/ExoPlayerImplInternal(20748):       at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:477)
E/ExoPlayerImplInternal(20748):       ... 3 more
E/AudioPlayer(20748): TYPE_RENDERER: AudioTrack init failed 0 Config(44100, 12, 44100)
...

I see this message repeated multiple times (3?) every time my app tries to play some audio (simple .mp3 files).
Is there anything that can be done about this?

This error seems to be for just_audio rather than audio_session. It's the following helpful?
https://exoplayer.dev/supported-devices.html

@ryanheise thank you very much for the prompt response!
The paragraph on emulators answered my question:
Emulators - Some Android emulators do not properly implement components of Android’s media stack, and as a result do not support ExoPlayer. This is an issue with the emulator, not with ExoPlayer. Android’s official emulator (“Virtual Devices” in Android Studio) supports ExoPlayer provided the system image has an API level of at least 23. System images with earlier API levels do not support ExoPlayer. The level of support provided by third party emulators varies. Issues running ExoPlayer on third party emulators should be reported to the developer of the emulator rather than to the ExoPlayer team. Where possible, we recommend testing media applications on physical devices rather than emulators.
In hindsight, I should have checked myself with the ExoPlayer website.
Thanks a lot! Please keep up the good work.


text:
🛑 Backend is down

In 96ddb1c, Backend ($SECRET_BACKEND_SITE) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Backend is back up in 92bb772.

repo: ryanlid/upptime


text:
Default arguments

We should add some disclaimer in the "default arguments" section, since the example will work only if the argument passed is undefined, if the argument is null, it won't work in the second example, but it will work in the first one.

Hey there! There's a PR for this, and I think I'll probably add a small disclaimer to keep short-circuiting if you expect falsey values other than undefined. https://github.com/ryanmcdermott/clean-code-javascript/pull/106

authors: rubenmoya ryanmcdermott

repo: ryanmcdermott/clean-code-javascript


text:
JavaScript

#JavaScript
User Story
As a bootcamp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
Acceptance Criteria
GIVEN a Prework Study Guide website
WHEN I view the study guide
Then I can see the four topics I learned listed along with a suggestion on what I should study first

Well done

repo: ryanpauldutton/prework-study-guide


text:
Added alias for andOtherCallsShouldBeIgnored

Goal here is to improve readability
f.shouldBeCalled().withOtherCallsIgnored().when(...

vs.
f.shouldBeCalled().andOtherCallsShouldBeIgnored().when(...

@h2oboi89


text:
force setState doesn't trigger update inside keyed For

Reproducible demo: https://codesandbox.io/s/solid-force-list-3hvt3
Try edit the inputs with initial value 'hello' and click the button. The input inside keyed For doesn't update as expected.

Thanks for reporting. Super weird as Solid's For is always keyed and the keyed property is unnecessary(doesn't do anything). Something about it is screwing things up though. Probably a bug in force. I will investigate.

Thanks for instant reply. In the doc about Suspense there is an example using key. I'm curious about the reason why Solid doesn't need key to persist component state (input state, focus, etc.)?
function ProfileTimeline() {
  // Try to read posts, although they might not have loaded yet
  return (

      <For each={resource.value.posts}>{post => (

{post.text}

      )}</For>

  );
}

Bad Copy and Paste from a React Example. Solid is based on mutation internally. It only renders once so I can use DOM node references as "keys". Sorting a list of DOM nodes is really just sorting a list of DOM nodes.
I figured out the problem. But it's not great. In a recent version, to reduce overhead of making too many fine-grained bindings I group them by template now. To improve performance I added simple diffing. So even if the change gets propagated there it is blocked.  However single binding templates don't have it.  Which produces an inconsistency. force only really has value for inputs so if this doesn't work its kind of worthless. However not diffing is a small overhead for all. I need to think on this.

I've thought of a couple ways of addressing this but I actually don't think I actually like them.

Wrap each input value in its own binding. This will work in this scenario as you want but it sort of ties my hands on how I approach DOM updates. It basically re-enforces the inconsistency. This is the only place in the DOM we aren't doing a strict test and it doesn't come up often. I'd rather make this never work than try to make this the solution. What if you are using custom Web Components this way etc, the compiler would never know. I think it is perfectly valid for the library to take the stance that DOM updates should only be responsible for the state its aware of (like VDOM libraries like React). And too specific solution here will have long term potential downstream repercussions.

Deprecating force to reduce confusion. I added force thinking it could help in this scenario although its use extends beyond this. Especially if the intention is to use state like signals. But I could argue, just use a signal then. The scenario I'm talking about is like time series, and RX type stuff where you are viewing each subsequent value as a sequence so the fact that the previous value is the same is irrelevant. Signals are basically made for this scenario of wiring stuff together. For example as a way of dispatching actions to a Store. It's perfectly fine to dispatch the same action multiple times in a row. That beings said force as an escape hatch has value. It just shouldn't be used for uncontrolled forms.

Which is unfortunate as this is the only scenario where this happens in the wild and I'd rather not change how bindings work (performance considerations), nor necessarily remove force, escape hatch scenarios for non-DOM updates. Although I'd definitely lean towards the latter. A similar discussion has come around removing index (2nd argument) from For since it will never update. I have solutions for that but it requires more complexity. There is a certain argument for just removing all potential footguns.
The challenge of course is there are solutions for these sort of problems but they will require a lot of documentation. In this case I can direct you to: https://reactjs.org/docs/uncontrolled-components.html. If we the intention is not to listen to input changes to update state (preferred approach) then use refs. Solid's refs are a bit different than Reacts. In this case either direct assignment with ref or forwardRef which calls a function with the ref could work. The challenge of course is if the list can be sorted your can't use index as the key to your refs array with the basic For component. In that case both the controlled/non-controlled forms sort of work similar in which you are mapping to a data structure for lookup.
This isn't a particular easy problem for React either in an uncontrolled way since if you bind to value every state re-render would reset all the inputs. This mixed form is really awkward for them. People are still trying to figure ways around it(https://github.com/reactjs/reactjs.org/issues/918). We don't have that problem, but you still have to do the same book keeping ultimately.
Thoughts? Is that reasonable?
===================
There is a 3rd option people might think of which is forceRender like React's forceUpdate but that will not work with Solid. Re-evaluating everything would not be Component scoped (there are no real Components) and it would cause a bunch of work possibly re-rendering parts of the DOM.

force is a little confusing, since diffing happens in some scenarios. State is just a snapshot of data, we should not use setState to represent a signal. I prefer deprecating force option and add some documents about unconntrolled forms.

authors: ajihyf ryansolid

repo: ryansolid/solid


text:
Convenient handling of Proxy type?

When using Typescript, I cannot find a nice way to work with the implicit Proxy type. The type inferred from createState wraps objects and arrays into Proxy<T>. Now if I want to pass that field into another component the compiler complains, for instance:
function MyComponent(props: {data: number[]}) {
  return <div>...</div>
}

function App() {
  const [state, setState] = createState({
    data: [1, 2, 3]
  })
  return <MyComponent data={(state.data)}/>
}

Error:
src/typed.tsx:36:23 - error TS2740: Type 'Proxy<number[]>' is missing the following properties from type 'number[]': length, pop, push, concat, and 25 more.

36   return <MyComponent data={(state.data)}/>

The inferred type of state.data is Proxy<number[]> which is obviously correct, but since Proxy is a private type, I cannot pass state.data around or do anything with it without a cast.
As a work-around I can double cast state.someProp as any as TheUnderlyingType everywhere, but that makes working with state quite tedious (for example (state.data as any as number[])[i] instead of just state.data[i]).
I'm wondering

Can we somehow convince Typescript that a Proxy<T> really behaves like a T (if that's the case)?
Should the type system rather hide the wrapping for convenience?
Exporting Proxy would at least allow clients to explicitly use Proxy<T> in type signatures. This may reduce the number of casts required, but eventually a cast is still necessary when actually doing something with T.

These are great questions. I honestly do not know. Exporting Proxy seems straight forward enough but as you said I think the fact it's a proxy is not that important for the consumer so hiding it sounds intriguing. I have no idea whether we wouldn't just hit another oddity. That seems be an everyday thing with TypeScript.

Maybe it is possible to define the proxy type interface like that?
type Proxy<T extends any> = T & {
  get(): any,
  set(): boolean
};

This seems to allow treating a Proxy<T> as if it was T. The following compiles:
const x: Proxy<number[]> = {} as Proxy<number[]>
const l = x.length
x[0] = 0

Ok, I mean if that does the trick then I'm pretty stoked. The last thing I want is to deal with unnecessary typings. If there are no objections I will change it and export the type from the project.  I have no idea the best way to solve these things, but if that is a reasonable approach I'm all for it.

I only had a quick look at state.ts so I'm not fully sure what it is doing. After reading up what a Proxy is, I'm a bit surprised that it is defined as
type Proxy<T> = {
  get(): any,
  set(): boolean
}

According to the docs I would say a Proxy is best described as either type Proxy<T> = T or Wrapped<T>. The get and set methods only exist on the handler passed into the Proxy constructor, right? I verified that by actually calling state.data.get() and state.data.set() which should exist according to the type definitions, but both give runtime errors (TypeError: state.data.set is not a function).
I'm also confused by the wrap function, where the actual Proxy constructor is returned as a Wrapped<T>:
function wrap<T extends StateNode>(value: T): Wrapped<T> { return value[SPROXY] || (value[SPROXY] = new Proxy(value, proxyTraps)); }

How would you describe in natural language what a Proxy<T> and Wrapped<T> is? Is the wrapping on root level different from the nested wrapping or are they the same?

Got the Proxy from an example in a section in this doc https://www.typescriptlang.org/docs/handbook/advanced-types.html.
This was how they applied the Proxy to properly forward Types from T.  Wrapped is the outputted Type which represented the Proxy wrapped state, it forwards all the keys from T, and shows that nested Objects are too wrapped, whereas simple primitives return their value. So I'd say Wrapped is more representative of the state object after it has been wrapped in a Proxy. There is no difference in whether they are top level or not. Looking at the code again I would expect you to be using Wrapped not Proxy. And Wrapped is the one that is exported.

Yes, the difference between the proxy defined in the examples
type Proxy<T> = {
    get(): T;
    set(value: T): void;
}

and the native proxy is that the example hides access behind explicit get/set wrappers, whereas native proxies still behave like T itself, but with access traps.
As far as I can see, we could simply remove the proxy type and define Wrapped as:
export type Wrapped<T> = {
  [P in keyof T]: T[P] extends object ? Wrapped<T[P]> : T[P];
} & { _state: T }

Yeah probably my misunderstanding of the example since you define proxies by accessors. If you can confirm this works seems like a simple change.

Yes, I've been experimenting with this change a bit, and so far it seems to work fine.

I did actually run into the same issue shortly after I proposed the initial change to the Wrapped type, however I was so busy at work the last two weeks, I did not investigate it further. Can confirm that @bluenote10 changes seem to work fine so far.

Fixed in Solid v0.7.6.


text:
Add raw join

I use your library at my work.
I need to use raw join sql, so it would be helpful if you would approve this commit.

Looks good, thanks!


text:
vim: avoid using alias of vim-sensible

I am doing some work on the nixpkgs vim infra that broke vim aliases for me, which made me spot this.

Thanks! Merged 🙂

authors: rycee teto

repo: rycee/home-manager


text:
Added some examples roms to the solution

As the title states!
Though, we should probably remove these after the workshop 😯

Oops, wrong repo 😂

repo: rylev/rust-wasm-workshop


text:
@NonNull should be allowed on abstract methods

Lombok throws an error when using @NonNull on abstract method (in abstract class or interface): @NonNull is meaningless on a parameter of an abstract method.
@NonNull not meaningless in this situation.
It is actually very useful for documentation purposes.
Also, to keep things easy to understand, probably Lombok should require @NonNull for implementations of these methods (even for abstract overrides - e.g. add a throws declaration in a subclass).

Already fixed in issue #807 and available in the edge release

authors: cristian-mocanu-mob rspilker

repo: rzwitserloot/lombok


text:
Unable to resolve linked dependencies using SPFx 1.19 & pnpm workspaces

I have monorepo set up with single spfx web part and two spfx libraries.
MyWebpart -> depends on MyLibrary -> depends on MyOtherLibrary
I am installing the packages using pnpm and the link-workspace-packages to link the dependecies together.
When running the fast-serve task, everything builds fine but the web part fails to load in the browser.
It works fine using the regular gulp serve command
spfx libraries: 1.19.0
spfx-fast-serve-helpers:1.19.2
pnpm: 9.7.1
node: 18.19.1
I have reproduced the problem at this repository.
Thanks

Hello, is there an update regarding this issue as I'm also facing the same issue. Thanks in advance.

No luck. I tried with version 1.19.3 also but still not working with pnpm for me. I have been using the SPFx gulp serve.

I didn't have a chance to have a deep look at the issue yet. This weekend I have some time and will try to fix this one and some other issues added recently. Sorry for the inconvenience.

I found where the problem is, it could be fixed, but require some time, will wok on it this week.

That's great. Thanks for your help

I published the 1.19.4 version, where I believe the issue is fixed.
I don't know which commands do you use for updating dependencies inside pnpm workspaces, I used below commands to install the latest version (based on the sample repo you provided, should be executed in the root workspace directory):
pnpm i spfx-fast-serve-helpers@1.19.4 --filter @spfxtesting/my-webpart -DE
pnpm i spfx-fast-serve-helpers@1.19.4 --filter @spfxtesting/my-other-library -DE
pnpm i spfx-fast-serve-helpers@1.19.4 --filter @spfxtesting/my-library -DE

then you should consequently execute npm run serve starting from the library without dependencies (my-other-library), then npm run serve inside my-library (because it depends on my-other-library) and finally for my-library. You should wait until it's fully compiled at each step, and only after that execute next npm run serve.
Please try it and tell if it fixes the issue.
PS. In your sample repository you use old format of fast-serve config, which will work, because it's backward compatible, but moving forward it's better to use a newer one.
The one you have:
{
  "$schema": "https://raw.githubusercontent.com/s-KaiNet/spfx-fast-serve/master/schema/config.1.1.schema.json",
  "cli": {
    "isLibraryComponent": true,
    "port": 4322
  }
}

should be changed to:
{
  "$schema": "https://raw.githubusercontent.com/s-KaiNet/spfx-fast-serve/master/schema/config.v2.schema.json",
  "serve": {
    "port": 4322,
    "isLibraryComponent": true
  }
}

Thank you for this. Everything is working fine again within the yarn monorepo

authors: MatthewSammut jacksonv1lle s-KaiNet

repo: s-KaiNet/spfx-fast-serve


text:
Should we tag Transactions, Addresses, or both?

Should we tag Transactions ("ChainEvent"), Addresses, or both?
In some use cases, it seems more efficient and user-friendly to tag addresses rather than transactions. For example, we may want to declare an "ON-RAMP" address. Or is it sufficient to declare ("tag") as "ON-RAMP" all transactions from that address?

The primary purpose of this library is for income tax accounting. In that case, do addresses have intrinsic properties we may want to tag, or are the meaningful properties primarily attached to transactions?
Are there cases where the same address may or may not have a property ("tag") depending on the transaction? For example, can an address sometimes be for on-ramping and other times for off-ramping?

While writing this, my intuition is tagging only at transaction-level should be sufficient, even if it may be more inefficient sometimes (we may trade O(1×n) to O(m×n) in the naive implementation).
I remain open to comments.

I solicited ChatGPT about that. Here is a summary of our discussion:
Question
I am designing an accounting application written in TypeScript for my personal use. The main goal is to collect the transactions from or to given addresses in order to detect fiat-to-crypto and crypto-to-fiat events and evaluate the global portfolio value on those dates to report to income tax services.
At this stage, I can collect the required transaction data from GnosisScan and keep them ordered by timestamp in a Ledger. The Ledger also stores a catalog of all the addresses discovered when extracting the transactions. I can also leverage the CoinGecko API to gather past token prices for portfolio evaluation purposes.
I suppose I will need a Portfolio object that will walk through the transactions in the Ledger and evaluate and store the total portfolio value for each event. It should also track whether fiat money was on-ramped or off-ramped in each transaction.
This requires additional user-supplied data to correctly classify each event. So, I need to enrich the data stored in the Ledger with things like:

Transactions to this address are crypto-to-fiat events.
Transactions from that address are fiat-to-crypto events.
A particular transaction is a rent yield.
Another transaction is an airdrop.
And so on...

I imagine a tag system to enrich the data stored in the Ledger so the Portfolio can handle the different events properly.
Question:
Should I tag only transactions, only addresses, or both?
What are the pros and cons of each approach?

Discussion Summary
Option 1: Tag Only Transactions
Pros:

Provides granular control for each transaction.
Simplifies Portfolio analysis by making event types explicit.
Allows handling edge cases where a single address serves multiple purposes.
Transparent for debugging and auditing.

Cons:

Requires tagging every relevant transaction, which could be labor-intensive.
May result in redundant tags if many transactions share the same behavior due to the involved address.
Complex queries might be needed to group transactions by address.

Option 2: Tag Only Addresses
Pros:

Efficient tagging: apply a tag once per address, reducing duplication.
Automatically applies to all transactions involving the tagged address.
Simplifies logic when the behavior of an address is static.

Cons:

Lacks granularity when the same address serves multiple roles (e.g., crypto-to-fiat and fiat-to-crypto events).
Assumes all transactions involving a tagged address share the same behavior, which can lead to incorrect classifications.
Struggles to handle exceptions or edge cases without additional mechanisms.

Option 3: Tag Both Transactions and Addresses
Pros:

Combines the efficiency of address tags with the granularity of transaction tags.
Allows default behaviors based on address tags while handling exceptions via transaction tags.
Enhanced analytics and flexibility for handling overlapping use cases.
Suitable for complex scenarios where transactions and addresses require distinct classifications.

Cons:

Increases complexity due to the need for reconciliation logic.
Requires maintaining two tagging systems, which could add overhead.
Potential for confusion if the precedence of address and transaction tags is not well-documented.

Recommendation

Start with transaction-level tagging if short on time, as it provides the granularity needed to handle ambiguous cases and edge scenarios.
Implement contextual inference for cases where explicit tags are missing (e.g., using transaction direction, amount, or token type).
Allow manual tagging or overrides for ambiguous transactions to ensure correctness.
Expand to include address-level tagging later to simplify common patterns while maintaining the flexibility of transaction tags.

Decision Tree for Tagging

Does the transaction have an explicit tag?

Yes: Use it.
No: Continue.

Does the address have a default tag?

Yes: Use it.
No: Continue.

Can the event be inferred from context (e.g., direction, amount, token)?

Yes: Infer it.
No: Continue.

Is the transaction ambiguous?

Yes: Prompt the user to classify it.
No: Leave it unclassified (or tag it as unknown).

Edge Case: Multi-Purpose Addresses

Problem: An address is used for both crypto-to-fiat and fiat-to-crypto events.
Solution:

Infer the event based on transaction direction (to or from), amount, or token.
Use transaction-level tags to override address-level defaults when necessary.
Allow manual classification for ambiguous transactions.

Conclusion
Using transaction-level tagging combined with contextual inference offers the flexibility to handle most scenarios, including multi-purpose addresses and ambiguous events. Expanding to include address-level tagging later can simplify tagging for common patterns, providing a robust system for classifying and analyzing transactions effectively.

repo: s-leroux/wallet-valuator


text:
Use static id for Topic ARN instead of timestamp

Fixes issue #38

Codecov Report

Merging #39 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master      #39   +/-   ##
=======================================
  Coverage   36.36%   36.36%
=======================================
  Files          21       21
  Lines         341      341
  Branches        8        9    +1
=======================================
  Hits          124      124
  Misses        217      217

Impacted Files
Coverage Δ

.../main/scala/me/snov/sns/actor/SubscribeActor.scala
0% <0%> (ø)
: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 87d38f4...50e128c. Read the comment docs.

authors: akhilpanchal codecov-io


text:
Added task model and related functions. Created task-types file.

Created the model schema for task and also wrote out functions specific to the model.
Created a task-types file to act as enum-ish.

 Create model and functions for task 3


text:
ddp pretraining

Thank you for opening such good codes.
Could I use ddp to pretrain a model?

Hey!
Sorry that the pretraining part not yet support DDP I think. The current implementation is in DP only. I am not sure whether there is a plan for upgrading to DDP. @andi611 is in charge of the pretraining part, and might give you more information :)

You can use data parallel by using the argument --multi_gpu, see here.
However, we currently don't support DDP at the moment, but surely we can add it in the future.


text:
[SMT] - Bug in Grafana when showing project count history

When  showing project count history, Grafana sometimes incorrectly stacks projects, resulting in a strange behaviour that can show a gap between 2 days even if no new jobs are apps have been created

Trello card: [#120] [SMT] - Bug in Grafana when showing project count history

authors: saagie-service tquiviger

repo: saagie/technologies-community


text:
Problème

Désolé,
le sujet n'est pas clair

ptdr

vois ca avec avec lui

authors: GuillaumeHERMOSO LucasColas


text:
Added brakeout game

Title and Issue number
Title : Brakeout Game
Issue No. : #206
Code Stack : Html, CSS, JavaScript
Checklist:

[x] I have mentioned the issue number in my Pull Request.
[] I have commented my code, particularly in hard-to-understand areas
[] I have created a helpful and easy to understand README.md
[] I have updated the Index.html file for my contribution

is it created by you @bilalmirza74

please share the video link

Building from YouTube or references is good. But the code just looks like a copy-paste from another place.
Ex: https://github.com/Inzahanyang/50days/tree/03d17163f2e7599527e8f2f4f4b0fbdb9abd1938/src/contents/breakout-game

The challenge is letter to letter exactly the same.
The repo encourages to build. As of now, we will not accept this. Thank you

repo: sadanandpai/frontend-mini-challenges


text:
Fix/added loader to all pages

Fixes
Use common loader across all the pages of the application
Reference - #1494
Solution
For the pages that lacked a loading state, the loading state was created, and a 'Loader' was added to display the loading.
Additionally, the pages that were already in a loading state were changed to use the proper 'Loader' style.
import Loader from "common/Loader/index"

<div className="flex h-full w-full items-center justify-center">
      <Loader />
</div>

Hey @prasanthchaduvula I have raised the PR for the issue #1494
Can you please review it and let me know if I should make any changes?

@akhilgkrishnan , I have updated the changes.
Can you please take a look at it?

@apoorv1316 Could you please test this PR?

@apoorv1316 Have you tested this PR ?

@prasanthchaduvula We have an empty state for reports and a few other pages that appear while the page is loaded and in this PR we are using the 'Miru Loader' on almost all pages. It's not consistent. Let's try to make it more consistent across the app.

@prasanthchaduvula We have an empty state for reports and a few other pages that appear while the page is loaded and in this PR we are using the 'Miru Loader' on almost all pages. It's not consistent. Let's try to make it more consistent across the app.

If possible can you list all the pages?

@apoorv1316 @akhilgkrishnan , Hey guys any updates?

@apoorv1316 @akhilgkrishnan , Hey guys any updates?

@apoorv1316 We can create a separate ticket adding the loader for missing pages. Could you please check the current implementation, if everything looks good we can merge.

repo: saeloun/miru-web


text:
Merge pull request #1 from sahava/master

Updates

Delete this pull request, I didn't realize that I did it backwards. Apologies for that

repo: sahava/spam-filter-tool


text:
[BUG] prevent using recv() without send()

Hello,
just find that if I wrongly run recv() without send(), then the program will goes into like an infinite loop.
It would very easily to occur in jupyter or interactive console or program bug.
Would it be better to add a timeout function inside recv() function?
Best regards.

I don't think it's possible because, from EnvPool's perspective, it cannot predict the single env step elapsed time. It's hard to tell the difference between user's wrong calling pattern and env's slow execution speed.

repo: sail-sg/envpool


text:
Create nuget package

I use COM to automate deployment of software which needs to create lnk. I use nuget to fetch all dependencies for F# scripts which do this. I'd like to avoid any COM access and use you api instead.

Since Stuxnet LNK vulnerability, Microsoft changed the way of creating .lnk files and Shellify is -at this time- only able to alter files.

I see. And there is another new patch for previous patch https://threatpost.com/patched-windows-machines-exposed-to-stuxnet-lnk-flaw-all-along/111558 ))

authors: asd-and-Rizzo sailro

repo: sailro/Shellify


text:
SAK-47688 Direct request failure: IllegalArgumentException:Invalid event id (:ID:), the id must be a number

https://sakaiproject.atlassian.net/browse/SAK-47688

Thanks for the good work @jesusmmp !

authors: jesusmmp mpellicer

repo: sakaiproject/sakai