text:
Update warning about linker-plugin-lto not working with -Os/-Oz

Just noticed this while reading through the docs... The bug was fixed by @jonas-schievink in Rust 1.49 already, fortunately.  But as the MSRV is still 1.38 we cannot drop the warning entirely yet.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thalesfragoso (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

authors: Rahix rust-highfive

repo: rust-embedded/cortex-m


text:
Thoughts on Flash API?

Do you mind taking a quick look at https://github.com/idubrov/stm32-hal/blob/master/src/flash.rs to see if Flash trait I created is a good candidate to be included into this embedded-hal crate?
It appears to me that the trait itself could go into embedded-hal and implementation (line #97 and below) would go into device-specific crate (which in my case is stm32f103xx, but there is not stm32f103xx-hal yet, as far as I can see).
I also have an EEPROM emulation crate (https://github.com/idubrov/eeprom) which uses Flash trait, but, I guess, it should stay as a separate "driver" crate, which will depend on embedded-hal, right?

I'm resurrecting this, as I'll be adding flash support to the stm32l0x1-hal crate today or tomorrow, and so am looking for traits to use. @idubrov, I think I'll probably adapt your proposal into its own flash-only traits crate with an eye toward adding its contents to an embedded-hal PR soon-ish.

I'm currently experimenting with these traits. I've impl'd them for stm32l0x1-hal, and will be doing lpc177x_8x-hal soon.

Neat! i think it'd be good to have a page write as well, and maybe it could be generic over word size?
I don't know if it's the right approach / maybe there's something simpler, but maybe write_word(&mut self, word: W) with default impls for write_u8/write_u16/write_u32 where W is u8, u16 and u32 would work?

Sounds good @thenewwazoo! I wrote this EEPROM 24x driver and what I would miss in your traits would mostly be reading an array of words and writing a page (array of words) (see docs). These devices also support reading sequentially (read current address + advance address pointer) but this is probably not implemented in all devices.
I think I would only implement Read and WriteRead and would have no need for Latency or Locking.
The erase_page would not make sense for these devices but I guess I could overwrite the whole page with 0s and that would be fine.
The flash traits presented at the beginning of this thread do not seem to fit  the EEPROM 24x devices very well.
Is the Latency used for devices that support communicating at different rates? If so, would it make sense to have a getter method for latency for generic drivers that read the latency from the device?
About the wording, I am not very sure about program_word, I think I would name it write_word but maybe I associate the word program with programming (as in writing code) too much.
There is one thing that I would not know how to model, though: In these devices, after you write a word or page, the device enters an internally-timed write cycle and it does not respond to I2C for a short while (device-dependent).
However, this is not available in the form of some BUSY bit or IO pin. Do you have any idea on how to implement an is_busy()?

I haven’t had a chance to do any coding in a few days but I did just have an idea about the is_busy question: you could take a non-Periodic hal::timer::Timer in the constructor, and start it when you write; is_busy then becomes a thin shim over Timer::wait

I haven’t had a chance to do any coding in a few days but I did just have an idea about the is_busy question: you could take a non-Periodic hal::timer::Timer in the constructor, and start it when you write; is_busy then becomes a thin shim over Timer::wait

Interesting solution! I think that could be done. However, it seems to me like the whole API will have to use nb::Result if I do not want to forcefully block on is_busy() in the rest of methods, but I think it could be worth it.
Ok I have to apologize I forgot about this: The devices support "Acknowledge polling". I will try to implement the is_busy() just using normal I2C and mapping the errors although that could mask other errors. If that does not work, I will try with the timer.
Thanks @thenewwazoo!

I've started to iterate on these Flash traits: https://github.com/nickray/stm32l4xx-hal/blob/wip/src/extra_traits/flash.rs
One tricky issue is the fact that in a general Flash trait, the size/alignment rules for reads, writes and erases are chip dependent. I'm currently using the generic-array approach, an alternative would be the "config crate" approach demo'd in https://github.com/jamesmunns/mcf-config-demo
Question: are there any (many?) chips where e.g. read/write/erase sizes and alignment requirements are different? Because then there would be at least 6 instead of 3 constants to configure.

Many chips I'm aware of (specifically the STM32 line) do have different alignment and size requirements for all three. Reads are usually allowed pretty freely -- down to byte resolution, and aligned to the size of the read. Writes must be aligned to 4-byte words, and usually only clear bits (never set them). Erases usually are page-aligned -- 1024 bytes is a common size for a page.
I'd encourage you to double check this on some device datasheets, since I'm going from memory here and this is just for one family of MCUs.

I'm aware of that, e.g. the STM32L432 I'm using has read/write/erase sizes of 8/8/2048 bytes. My question is whether something like like read size 2 but read alignment 1 occurs (i.e., not "Reads are usually allowed (...) aligned to the size of the read"), or write size != write alignment, or erase size != erase alignment.

has anyone considered opening this up to all forms of NVS?
while not as popular as it used to be some chips are still shipping with eeprom which is really useful when available.

Ah, I misunderstood -- apologies. Unfortunately I can't provide as clear-cut an answer there -- I've never seen such an MCU, but my experience is far from comprehensive.
It does seem to me that for a given operation alignment can never be greater than size -- otherwise, there'd be inaccessible holes in your address space. So if you assume that size == alignment, and encounter an architecture where size > alignment, all you're missing is a potential optimization (and probably a minor one at that), rather than a fundamental incompatibility.
With that said, my assumption should probably be challenged before anyone relies on it.

has anyone considered opening this up to all forms of NVS?
while not as popular as it used to be some chips are still shipping with eeprom which is really useful when available.

I think this could be extremely useful. However, I'd propose a generic byte-oriented nonvolatile storage trait rather than trying to make a flash trait encompass all necessary functionality. Such a trait could be built on top of a flash implementer, or directly on top of a hardware EEPROM, or on top of an I2C trait accessing an off-SoC part.

One of my goals is to have traits that easily implement the Storage trait used in the LittleFS wrapper: https://docs.rs/littlefs/0.2.0/littlefs/trait.Storage.html

The traits as implemented seem to be very specific to on-die flash. Would it make sense to have a more generic Storage or Memory trait, and then a Flash trait can get more specific from there?

I'd really like to see a flash trait, probably most non-volatile storage though needs to be treated as pages of memory of some size. Ideally you could represent that in a type like
struct Page<PageSize> {
    buf: [u8; Size]
}

with a trait like
trait PagedStorage<PageAddr, PageSize> {
   fn read(&self, page_addr: Page<PageSize>) -> nb::Result<Page<PageSize>>;
   fn write(&self, page_addr: PageAddr, page: Page<PageSize>) -> nb::Result<()>;
   fn erase(&self, page_addr: PageAddr) -> nb::Result<()>;
}

This seems doable now with const generics happening in Rust

@MathiasKoch has created embedded-storage and it would be great to move the discussion around this there for a more focused forum. Once we achieve a good API, we could merge it to embedded-hal but we can discuss this separately.
For this reason, I will close this issue now. If you think otherwise, feel free to ask for reopening.

source: gharchive/issue

authors: IGBC austinglaser bfrog eldruin idubrov nickray ryankurte thenewwazoo twitchyliquid64

repo: rust-embedded/embedded-hal

license_type: permissive

license_source: github-api


text:
Fix run-fuzzer.sh

Pass in --target in run-fuzzer.sh to avoid sanitizing build scripts.
Closes #70.

Awesome, thanks for the quick update!

So I think this works, but I don't have a Mac to test it out on 😞.

Just tested it on my macbook, works find. I'll merge when Travis agrees :)

bors r+

@frewsxcv your new bot doesn't like me :(

woops, just fixed that! you should have permissions now
bors r=killercup

source: gharchive/pull-request

authors: alanhdu frewsxcv killercup

repo: rust-fuzz/targets


text:
N44: add screen ball and battle city games

Part of #1317
Thanks.

Ah, I used to play BC a lot on Dandy back in the middle of the nineties :D
Thanks for the PR!

Cool, thanks. Feel free to tweak the content.

authors: lewiszlw ozkriff


text:
translate Calling Unsafe Functions

I found that part of https://doc.rust-jp.rs/rust-by-example-ja/unsafe.html#calling-unsafe-functions is not translated.
Therefore I translated this.

Thank you for your contribution.

authors: baseballyama dalance

repo: rust-lang-ja/rust-by-example-ja


text:
Simplify helpers::blob

Thanks @fitzgen for the detailed instructions.
Fixes #928.

@bors-servo r+

:pushpin: Commit 93d9642 has been approved by fitzgen

:hourglass: Testing commit 93d96428ce7ec51c198866703cd3efc25800be11 with merge d22e6364509977e35ec356f74bad6522455d2ff0...

:sunny: Test successful - status-travis
Approved by: fitzgen
Pushing d22e6364509977e35ec356f74bad6522455d2ff0 to master...

authors: MaloJaffre bors-servo fitzgen

repo: rust-lang-nursery/rust-bindgen


text:
Confused between serialize and rustc-serialize

What is the relationship between serialize::json and rustc-serialize::json?
The doc pages look very similar to me...
http://doc.rust-lang.org/serialize/json/
http://doc.rust-lang.org/rustc-serialize/rustc-serialize/json/index.html

rustc-serialize used to be included in the standard Rust distribution with the name serialize. It has since moved to its own package on crates.io. I think I can say that you should always be using rustc-serialize.
The reason why this move occurred, AFAIK, is that the serialization infrastructure probably isn't going to be stabilized before Rust 1.0. But, it's extremely useful. The Rust 1.0 stable channel will disallow all uses of unstable things, so the only way to permit continued use of rustc-serialize is to split it out of Rust proper and into its own separate package.

Thanks for the explanation :) Should we then remove the docs from http://doc.rust-lang.org/serialize/json/ ?

+1 to downing these docs !
I just lost 30 minutes to figure out how to deserialize json ! Reason was that I of course found the 'serialize' documentation first, which caused all sorts of problems as both crates got mixed up in my code.
It really adds to my frustration as everything I attempt quickly ends up being much more difficult than anticipated. Sure, it's alpha, but there is no need to unnecessarily confuse anyone :).

I'm going to close this now that this crate is deprecated in favor of serde. We're discontinuing feature development in rustc-serialize but will still continue to merge bug fixes if they arise.

authors: BurntSushi Byron alexcrichton winding-lines

repo: rust-lang-nursery/rustc-serialize

license_source: bigquery


text:
choice of TARGET_CC or HOST_CC does not seem consistent

Hello! So I do a lot of cross compiling. In one case, on Linux x86_64, I need to cross compile for Linux x86_64 (no typo), as I need to 1) use a very specific compiler and 2) have a sysroot I need to use as it has a very specific (and old) version of glibc (from CentOS 6). Notably, I am striving for reproducible builds, something I was having no problems with until I started linking against a rust library :(. (In specific, the library I'm using depends on ring, which has some native code.)
So, the way I'd expect HOST_CC and TARGET_CC to work is that there are essentially two levels of build: there's stuff being built to be used by the build, and then there's stuff being built to be deployed after the build; everything in the former category should use HOST_CC, and everything in the latter category should use TARGET_CC. This is, for example, how other build systems--such as autotools--handles choosing compilers (at worst they print an awkward warning).
Now, with Cargo, when I compile on a macOS machine, I use TARGET_CC to specify my very specific Linux x86_64 compiler, and this works "as expected": any code that is supposed to be run on macOS uses HOST_CC and any code that is supposed to be deployed is built using TARGET_CC. However, when I compile on a Linux x86_64 system, this doesn't happen: instead, as far as I can tell, everything uses HOST_CC always, even stuff that is going to be deployed :(.
I figure the logic here is "I'm on a Linux x86_64 system, and I just need any compiler, right? so why can't I just use the HOST_CC here?", but again: the issue is that I might have some very "good" reason for having different compilers that goes beyond "does it run?" and moves into the world of "does it provide bit-for-bit identical results with some other machine that is also building this code because I want to reproduce that build" or "I have weird glibc requirements".
(This might be related in some way to #3349, btw; but, while I am not entirely sure what build-script-build is, it sounds like that bug is more from long enough ago that TARGET_CC might simply not have existed, and so the issue was more that there was no way to specify this at all, as opposed to that it was being selected in weird ways? FWIW, I don't feel a need for anything lower-level than TARGET_CC: I just want TARGET_CC to always be used as the target cc ;P.)
(FWIW, in this case, I feel like I'm going to be able to come up with a messy workaround for this wherein I detect cases where I think the wrong variable will be used and pass HOST_CC instead, but that isn't viable in the general case: as an example, maybe I want to compile to target some newer platform version than the one I'm currently running on using some version variant switch, in which case the TARGET_CC might generate object files that are invalid on my host system.)
Maybe put most simply: my assertion is that the choice of HOST_CC or TARGET_CC should be based on what I'm intending to do with the thing being compiled, as opposed to what amounts to an unpredictable decision based upon whether the host and target happen to share a triple (which is by no means a guarantee of full compatibility, whether practically or conceptually); the host and target are semantically different from each other in ways unrelated to their platform.
(Note: it is totally possible that this is some issue specific to ring, but I couldn't find any mention of TARGET_CC in their code so I got the impression that they were just asking Cargo to build stuff Cargo was taking care of it; but I also don't know how Cargo packages are formatted and so haven't dug into ring to determine exactly how this is all specified either. So, if this isn't even an issue in Cargo and this is actually an issue with ring, I'm super sorry for wasting your time.)

Cargo doesn't execute C compilers. It looks like ring uses the cc package to handle building C code.

This is sort of arguably a Cargo bug though because build scripts have no way of distinguishing cargo build and cargo build --target $host. The problem is likely on this line which checks for host == target to select which compiler to use.

Or rather not so much as a Cargo bug but rather a Cargo feature request.

In case it is useful to anyone else, my latest workaround for this issue is to run rustc --version --verbose | sed -e '/^host: /!d;s///' (a feature that I am not sure existed a year ago, though I'm not sure I would have thought to look at the time anyway) and compare it with my --target, so I know which environment variables--either TARGET_* or HOST_*--to set (which is definitely much cleaner than the haphazard heuristics I used to have, but I will note still is not a comprehensive solution as it assumes that the target compiler and flags are always going to be able to generate binaries that can run on my current machine, which certainly isn't guaranteed for a number of reasons, including-but-not-limited-to those mentioned in #6375, which is a problem with a similar concept that occurs at a very different location in the standard Rust build stack).

In case it is useful to anyone else, my latest workaround for this issue is to run rustc --version --verbose | sed -e '/^host: /!d;s///' (a feature that I am not sure existed a year ago, though I'm not sure I would have thought to look at the time anyway) and compare it with my --target, so I know which environment variables--either TARGET_* or HOST_*--to set (which is definitely much cleaner than the haphazard heuristics I used to have, but I will note still is not a comprehensive solution as it assumes that the target compiler and flags are always going to be able to generate binaries that can run on my current machine, which certainly isn't guaranteed for a number of reasons, including-but-not-limited-to those mentioned in #6375, which is a problem with a similar concept that occurs at a very different location in the standard Rust build stack).

authors: alexcrichton ehuss saurik

repo: rust-lang/cargo


text:
test: Migrate network tests to snapbox

Part of #14039.

@bors r+

:pushpin: Commit 47253e4da1f1115d2fa854297277d910b04bb42b has been approved by epage
It is now in the queue for this repository.

:hourglass: Testing commit 47253e4da1f1115d2fa854297277d910b04bb42b with merge 3a76b8c790cedd234fe9933161eacddb855e59d5...

:sunny: Test successful - checks-actions
Approved by: epage
Pushing 3a76b8c790cedd234fe9933161eacddb855e59d5 to master...

authors: bors dieterplex epage


text:
Check minimal version of Rust that compiles

Specify a minimum version of the Rust compiler that successfully builds the crate. This allows us to be aware if the minimal version increases and to avoid issues such as https://github.com/rust-lang/flate2-rs/issues/370
The minimum version is a best-effort measured value and is different to the MSRV which is a support guarantee. The minimum version can be incremented by a PR in order to pass tests, as long as the MSRV holds. When the minimum version increases, the next release should be a minor version, to allow any affected users to pin to a previous minor version.

The minimum version for the updated miniz_oxide is higher than I expected. Since the rust-version in Cargo.toml can prevent Cargo from selecting the crate, it needs to be the minimum version supported by a common feature-set. We do not want to prevent someone using Rust 1.56.1 from downloading the crate if they are planning to use zlib-* feature.
My current thinking is to remove the rust-version directive from Cargo.toml but keep the test, and use it to document behavior. (e.g. if using Rust < 1.60 a different backend must be selected).

Ah it's ppv-lite86 which is a transitive dependency in the dev-dependencies. v0.2.17 in my lock file has no dependencies, but the latest v0.2.20 used in GitHub Actions adds zerocopy which requires 1.60.
[dev-dependencies]
├── quickcheck v1.0.3
│   └── rand v0.8.5
│       ├── libc v0.2.153
│       ├── rand_chacha v0.3.1
│       │   ├── ppv-lite86 v0.2.17

Changed the CI workflow to only test that code builds, without running the tests.

Oh wow, CI should complain more noisily if that happens!


text:
Provide a secure_getenv() equivalent

Glibc provides a non-standard function secure_getenv() (manpage, glibc manual). It is the same as getenv(), except that it returns NULL if "secure execution" is required. See the manpage for the exact definition but in short, if the executable is setuid or similar.
I think Rust should expose a similar function in the standard library. Here's an example scenario (I haven't tried it out, so I might have it wrong):

A setuid binary.
The binary depends on a crate. The binary calls a function from the crate before dropping privileges.
The function in the crate needs to write a temporary file, so to be nice it tries to use the conventional TMPDIR environment variable to pick the directory first.
Evil user does TMPDIR=/root/.ssh/ ./binary.

If the library uses getenv, then the user managed to trick the binary into writing stuff into /root/.ssh which is a security hazard. If the library uses secure_getenv, then at least this case is prevented.

@bluetech any developments here?

authors: Centril bluetech

repo: rust-lang/rfcs


text:
Issues are not feature requests

Currently issues get often used as feature requests, where they basically get ignored because nobody is watching the issues.
I'd like to propose we stop allowing issues as feature requests and severely restrict the issues on this repo to tracking issues
and general housekeeping.
We instead encourage feature requests to become discussions on the internals forum.

@rfcbot fcp merge
I believe we're ready to go on this and that the current text represents the consensus of the core team (though we are not happy with the state, and expect more work in this area in the future).

authors: Manishearth Mark-Simulacrum


text:
Syntax highlighting and indentation incorrect with lifetimes

The code whose syntax I want highlighting is as follows:
enum Thunk<'a, T> {
    Unevaluated(&'a FnOnce()),
}

However, emacs, in Rust mode, highlights it according to the following image:

Are you running an old version of the rust-mode package? I have version 20160505.2130 and can't reproduce this. To get the version number, you can run M-x describe-package<RET>rust-mode<RET>

That says I'm using version 0.1.0, which I guess is an old version. Updating fixes this.
Thanks very much for your help :)

authors: Taneb tomjakubowski

repo: rust-lang/rust-mode


text:
New Website Logo: Clever Cloud

Organization name: Clever Cloud
Homepage url: https://www.clever-cloud.com/
Logo url: http://dev.unhandledexpression.com/clever-svg.svg
How you are using Rust: we host Rust web apps (currently in beta), and a part of our infrastructure (around git and app management) is developed in Rust
Url describing Rust usage: https://www.clever-cloud.com/doc/rust/rust/
Organization contact: Geoffroy Couprie geoffroy.couprie@clever-cloud.com

Sorry about taking so long with the PR! I was out of town.

I was out of town too ;)

authors: Geal steveklabnik

repo: rust-lang/rust-www


text:
'Run' new code fails (due to cross-domain issue?)

The 'run' button on the rust front page doesn't work for me (Firefox 34.0.5, OSX).  The status goes to 'running' and it just sits there.  If I open a javascript console, it says that:
Cross-Origin Request Blocked:
    The Same Origin Policy disallows reading the remote resource at http://play.rust-lang.org/evaluate.json.
    This can be fixed by moving the resource to the same domain or enabling CORS.
        evaluate.json

TypeError:
    message is null
        www.rust-lang.org:382

Same here, Firefox 35 on Fedora Linux (same with Epiphany). Leaves a bad impression currently, as if Rust was taking forever to run the program.

I think this is fixed now, thanks for the report!

authors: alexcrichton danthedeckie robinst


text:
Add Windows -msvc links to the Downloads page.

It is very hard to find the native -msvc tools.
I didn't add links for stable 1.3 because my understanding is that 1.4 is the first version where -msvc will be recommended.

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

r? @brson (we just had a convo today about this)

Thanks! I've made my own tweaks and included it in the PR for tomorrow's release.

authors: briansmith brson rust-highfive steveklabnik


text:
writing an I/O-related library that doesn't care about whether it's used in a sync or async context

Character: Barbara (almost)
Brief summary: Barbara tries to write a library that parses a particular kind of format in a streaming fashion that works with any implementation of std::io::Read or std::io::Write, and wants it to work in an async context with minimal fuss.
Key points or morals (if known):

Library author may not know much (or anything) about Async Rust.
There is nothing inherently "sync" or "async" about the actual details of the format. By virtue of working on things like the Read/Write traits, it works on streams. (Where "stream" is used colloquially here.)
Depending on specific async runtimes with specific async versions of the Read/Write traits seems inelegant and doesn't seem to scale with respect to maintenance effort.
Async Runtimes may have adapters for working with Read/Write impls, but it may come with additional costs that one might not want to pay.
Making such code work regardless of if it's used in a sync or async context should not require major effort or significant code duplication.

One example here is the flate2 crate. To solve this problem, they have an optional dependency on a specific async runtime, tokio, and have impls for AsyncRead and AsyncWrite that are specific to async runtime.
Another example is the csv crate. The problem has come up a few times:

https://github.com/BurntSushi/rust-csv/issues/141
https://github.com/BurntSushi/rust-csv/issues/171
https://github.com/BurntSushi/rust-csv/pull/199

Its author (me) has not wanted to wade into these waters because of the aforementioned problems. As a result, folks are maintaining a csv-async fork to make it work in an async context. This doesn't seem ideal.
This is somewhat related to #45. For example, AsyncRead/AsyncWrite traits that are shared across all async runtimes might do a lot to fix this problem. But I'm not sure. Fundamentally, this, to me, is about writing I/O adapters that don't care about whether they're used in a sync or async context with minimal fuss, rather than just about trying to abstract over all async runtimes.
Apologies in advance if I've filled out this issue incorrectly. I tried to follow the others, but maybe I got a bit too specific! Happy to update it as appropriate. Overall, I think this is a really wonderful approach to gather feedback. I'm completely blown away by this!
Also, above, I said this was "almost" Barabara, because this story doesn't actually require the programmer to write or even care about async code at all.

Hmm, so this is mostly(?) a question of "sync-async" bridging, I think? I was going to open a similar-ish (only vaguely) issue based on some conversations I had with @Mark-Simulacrum, though in that case the gist is more like "I want to write a client that uses libraries that are implemented in async with minimal fuss, and right now it's painful".

I opened https://github.com/rust-lang/wg-async-foundations/issues/54 to cover my conversation with @Mark-Simulacrum

@nikomatsakis Yeah, I think "sync-async" bridging is a very general way to put it, although there may be many specific cases of it with this being one of them. (Not quite sure how to categorize everything, I leave that difficult task to y'all. :-))

Some elements of this blog post feel related:
https://kevinhoffman.medium.com/rust-async-and-the-terrible-horrible-no-good-very-bad-day-348ebc836274

Lesson II — It is possible for a single dependency of your crate to be so tightly coupled to a future polling runtime that it effectively makes that runtime mandatory for all consumers.

Here’s an approach to this from Python’s ecosystem: https://sans-io.readthedocs.io/

@matklad In my example above, that's what csv-core is. The problem comes when you want to build some nice abstractions that do I/O. e.g., csv::Reader.

I have recently implemented an async version of parquet here using only futures:: (i.e. run-time agnostic) and my understanding is that ultimately, implementations have to offer two APIs
pub fn read_*<R: Read + Seek> -> Result<Foo>;
pub async fn read_*_async<R: AsyncRead + AsyncSeek + Send + Unpin> -> Result<Foo>;

and that this changes propagates to any code that performs I/O (it does not propagate to code that performs CPU-intensive tasks such as de-serialization) by basically adding async and .await.
They represent two different compilation paths: one that calls .read_()? and the other that calls .read_*().await?.
It all boils down to the fact that we never know what the next byte will cause to the state machine. In the case of CSV, the key item is the un-escaped end of line, that causes a whole panoply of events. The reader must read byte by byte in a state machine until the state is "new row". An equivalent way of framing this problem is that it is not possible to tell how many bytes we should read for the state machine to move to its "clean" state (finished reading a whole line).
This problem emerges in reading protobuf, flatbuffers, thrift, because certain nested types are stored in things like <number of bytes in i32 little endian><bytes> and that are read as let bytes = reader.read_i32() and reader.read_bytes(bytes). It is not possible to know how much to read prior to calling .read_i32(), which means that we need to offer the ability to .await the reading of <bytes>. This requires the whole thing to be async because even with buffering, there is a chance that the buffer is not large enough to cover <number of bytes in i32 little endian><bytes>, in which case the buffer itself needs to call .read_*(remaining bytes).await to cover <bytes>.
The alternative to this is to offer a sync API and re-use it via spawn_blocking. The problem with this is that it forces the library to use a concrete runtime engine, which falls into the Lesson II of the blog post.
I see two potential ways improve the situation:

design a mechanism to be able to reuse sync code in async code by generating the corresponding async code whenever certain traits are used. E.g. some macro that automagically converts Read <> AsyncRead -> all calls on the trait become .await and the function is automatically converted to async (including every usage of the trait in dependent functions).
design a mechanism to "spawn blocking" without a concrete runtime engine. E.g. A trait describing the runtime state that is passed to a function together with a generic spawn_blocking<T: RuntimeState> that can be called from that function, or something like that (I do not know the details of what spawn_blocking needs to be generic)

I know we don't need a list of examples, but serde seems worth a special mention here.  It's a complex, popular, amazing library that at the bottom just writes/reads from a stream.  Currently, we have to fork a separate version of entire serde ecosystem with all the functions in a different colour just so we can deserialise from an async source.  (ie: it's not just the io-related library - it's everything that calls that io-related library, and sometimes this involves crates from multiple third-party authors.)

@anguslees that's a very good point. We should also keep in mind that serde has been unmaintained for almost 2 years now.

authors: BurntSushi anguslees jorgecarleitao matklad nikomatsakis zeenix

repo: rust-lang/wg-async-foundations


text:
Outline of tsap idea and prototype

In the last half year I used hydra extensively for machine learning at my university job. It provides a configuration tool for complex applications, remote capability (e.g. executing on SLURM cluster) and multiruns (e.g. doing hyperparameter search).
This issue proposes a similar crate for Rust and linfa to build and configure machine learning applications. Similar to structopt and clap it consists of two elements, a macro system to derive structs and a argument parser to override default hierarchies. Compared to established argument parsers, we don't follow Unix argument patterns and combine a default from file with override by arguments step. The crate is therefore geared towards ML instead of command line applications.
To keep dependencies low we make most of the API surface optional. In minimal setting the parameter macro generates only a builder pattern; allowing programmatical control of the algorithm. This is geared for consumer crates, which uses simple parameter sets and don't have to make configuration accessible. In more complex settings we also want to take files and command line arguments into account and extend our API surface to that of Hydra.
Because most of the infrastructure already exist, we use serde for serialization, TOML as configuration format and add a small template engine to rewrite TOML's configuration tree. Extending configuration from other files is a typical usecase for a resolver. In total tsap exists to give a unified macro for generating highly configurable parameter sets for algorithms we have at Linfa.
Motivation
We will start with a simple example to illustrate a usecase:
use tsap::param;

#[param]
struct RandomForest {
    ntrees: usize,
}

#[param]
struct SVClassifier {
    regul_term: f32,
}

#[param]
enum Model {
    RandomForest(RandomForest),
    SVClassifier(SVClassifier),
}

#[param]
struct Main {
    seed: usize,
    #[check]
    model: Model,
}

fn main() {
     // load default configuration from entry file
     let conf: Main = Main::from_file("config/main.toml")
        .amend_args()
        .seed(40)
        .try_into()?;

     // start experiment, do other stuff...
     conf.run_experiment();
}

The following binary calls are then valid:

just plainly with default params: cargo run
override default model: cargo run model=svclassifier
do multirun with multiple seeds: cargo run -m model=randomforest seed=10,20,30,40

Default values are defined with a hierarchy of TOML files, typical parametrizations can be shaped by using using default values. For example the upper example could have one for the main entry and one for the model:
seed = 42

[model]
from_file = { base_path="models/", default="randomforest" }

variant = "randomforest"
ntrees = 128

The keys variant and from_file are reserved keys and indicate enum variant and where to look for the configuration. When overloading the model with a different configuration, the application will automatically look in that folder for a TOML file with the same name.
Guide-level explanation
WIP
Alternatives

use YAML instead of TOML (or make backend agnostic over configuration file)

complex hierarchy of YAML files, when your application can't be fitted into a simple structure, then you should refactor it
configuration backend agnostic seems sensible, but more work required

support traits instead of enums for variants of keys
add inline templates supporting system more similar to omegaconf (e.g. "cmd:data" with expansion to current date)

Unresolved Questions

is the current prototype possible in a static typed language?
should we add a builder pattern generator to help simplify linfa's parameter structs?
should we implement Try when building for nightly, this would support ? for building

talked with @nils-werner recently and he mentioned that one of the key features of Hydra is dependency injection. To give an example: for clustering algorithms you want to be generic over your distance function and allow extending them in retro (which would not be possible with enums).

Why do you want to extend them in retro (I understand that as without re-compiling)? Why not instead require the config files to list all available functions and parameters (and generate Enums from them), and only allow the CLI to override the values, but not add new ones?
In my experience in 95% of cases I don't randomly change a function or class to a completely unseen one, I mostly pick from an existing list, or change their parameters. In the remaining 5% of cases I could accept a re-compile, if I get Rusts Enum-goodness and safety in return.

Why do you want to extend them in retro (I understand that as without re-compiling)? Why not instead require the config files to list all available functions and parameters (and generate Enums from them), and only allow the CLI to override the values, but not add new ones?

using Rust enums has two disadvantages: (1) you loose performance if you use them in your critical path (like as a distance function) because you are adding indirection by branching (2) you can't implement functionality from a downstream crate easily.
So what you have to do in the example is writing your algorithm generic over the distance, but over a closed enum to the user of what you expect them to use. After compilation you can't change those variants anymore.

In my experience in 95% of cases I don't randomly change a function or class to a completely unseen one, I mostly pick from an existing list, or change their parameters. In the remaining 5% of cases I could accept a re-compile, if I get Rusts Enum-goodness and safety in return.

If Rust supported JIT compilation and extensible ADT (https://www.andres-loeh.de/OpenDatatypes.pdf) then it would be possible to extend it from configuration but also quite a different language

P.S. sorry for the necrobump, I'm only just slowly starting to dig deeper into Rust which made me think of this issue again.

learned a new word will steal it from now on :zombie:

Oh I see, if I write an algorithm and you want to replace the distance function afterwards, you can't. Unless I'd make the distance function parameterizable via its trait, which in turn forces me to use a Box. Got it...
OK, I didn't think of composing components from different crates.

you can also implement the trait for your enum, but in practice I have not used boxed trait object yet

authors: bytesnake nils-werner

repo: rust-ml/tsap

license: MIT


text:
Implement 128-bit Gaussian integers

The build script detects support for u128 and i128 (Rust 1.26+) and
enables their Complex implementations.  We only have to directly
implement the operators with scalar LHS, and the rest comes from
enabling num-traits' 128-bit Num.

bors r+

repo: rust-num/num-complex


text:
Features request: Sailfish cli tool

Features:
I need a sailfish-cli tool to transform a nested folder a to folder b, will transform all files with ext.stpl to b same folder structure with files without .stpl. I have looked into sailfish and compiler, it mostly support macro for now which is a bit hard to navigate around.
The dictionaries data to do the translation can be environment variable or config file through --config, -c
If there is any hint to get it done? Thanks

Check out rust build macros. That's what I use to copy things over for my builds, along with running the tailwindCSS executable to minify my CSS.
https://doc.rust-lang.org/cargo/reference/build-scripts.html
If you need a starter, I can give you some of my build script code.

Here's my build.rs anyway: (Just ignore some of the bits about windows, I'm still trying to get it cross platform, but haven't gotten far enough yet.)
use std::env;
//use std::fs::create_dir;
use std::io::ErrorKind;
use std::path::PathBuf;
use std::process::Command;

//use std::thread::current;
//use regex::Regex;

fn main() {
    //let out_dir = env::var("OUT_DIR").unwrap();
    //Get the current directory
    let current_dir = String::from(format!(
        "{}",
        env::current_dir().expect("current_dir failed!").display()
    ));

    //use regex::Regex;
    //let re = Regex::new(r"[A-Za-z]").unwrap();
    //let result = re.replace_all("Hello World!", "x");
    //println!("{}", result); // => "xxxxx xxxxx!"

    // let icon_str = Regex::new(r##"fill=["'].*['"]"##).unwrap().replace_all(
    //     include_str!(concat!(env!("CARGO_MANIFEST_DIR"), "/src/img/heroicons/src/24/solid/chevron-right.svg")),
    //     "fill='white'"
    // ).into_owned();

    if cfg!(windows) {
        println!("cargo:warning=windows-specific-directory");
        //cd C:\
        //mkdir dev
        //cd dev
        //mkdir vcpkg
        //cd vcpkg
        //git clone https://github.com/microsoft/vcpkg
        //.\vcpkg\bootstrap-vcpkg.bat
        //cd C:\dev\vcpkg\vcpkg
        //.\vcpkg install openssl:x64-windows-static
        //mkdir "C:\Program Files\OpenSSL-Win64\certs"
        //winget install curl
        //C:\Program` Files\Git\mingw64\bin\curl --remote-name "C:\Program` Files\OpenSSL-Win64\certs\cacert.pem" -o "C:\Program` Files\OpenSSL-Win64\certs\cacert.pem" https://curl.se/ca/cacert.pem
        //set OPENSSL_NO_VENDOR=1
        //set RUSTFLAGS=-Ctarget-feature=+crt-static
        //set SSL_CERT_FILE=C:\OpenSSL-Win64\certs\cacert.pem
        /*

I just had this issue and none of them worked, but here is what worked for me on Windows 11.

    Install OpenSSL from http://slproweb.com/products/Win32OpenSSL.html into C:\Program Files\OpenSSL-Win64

    Set all your env variables, for me I set OPENSSL_CONF to C:\Program Files\OpenSSL-Win64\bin\openssl.cfg and added C:\Program Files\OpenSSL-Win64\bin to my path.

    Download the cert, assuming you have wget installed, wget https://curl.se/ca/cacert.pem -o cacert.pem into C:\Program Files\OpenSSL-Win64\certs

    Next step is to set up your environment for building openssl run in powershell:

 $env:OPENSSL_NO_VENDOR=1
 $env:RUSTFLAGS='-Ctarget-feature=+crt-static'
 $env:SSL_CERT = 'C:\OpenSSL-Win64\certs\cacert.pem'
 $env:OPENSSL_DIR = 'C:\Program Files\OpenSSL-Win64'

and run cargo build

         */
    } else {
        println!("cargo:warning=unix-directory");
    };

    if cfg!(target_os = "windows") {
        println!("Windows detected!");
        Command::new("cmd")
            .args(["/C", "echo hello"])
            .output()
            .expect("failed to execute process");
        return;
    } else {
        Command::new("sh")
            .arg("-c")
            .arg("echo hello")
            .output()
            .expect("failed to execute process");
    }
    //let src_dir : PathBuf = [ &current_dir, "src" ].iter().collect();
    //Setup the assets output directory
    let assets_dir: PathBuf = [&current_dir, "assets"].iter().collect();

    //copy the css files
    let css_dir: PathBuf = [&current_dir, "src", "css"].iter().collect();
    copy_dir(&css_dir, &assets_dir).expect("cargo:warning=Failed to copy_dir!");
    //Minify the CSS with the tailwindcss tool, thus overwriting the site.css file
    if cfg!(target_os = "linux") {
        let tailwindcss_status = Command::new("./tailwindcss-linux-x64_v3.2.4")
            .arg("-i")
            .arg("src/css/site.css")
            .arg("-o")
            .arg("assets/css/site.css")
            .arg("--minify")
            .spawn()
            .expect("Tailwind command failed to start!");

        println!("cargo:warning=tailwindcss-linux-x64 ran with status: '{tailwindcss_status:?}'");
    }

    //copy the favicon over
    let favicon_from_path : PathBuf = [&current_dir, "src", "favicon.ico"].iter().collect();
    let favicon_to_path : PathBuf = [&current_dir, "assets", "favicon.ico"].iter().collect();
    std::fs::copy(favicon_from_path, favicon_to_path).expect("cargo:warning=Failed to copy favicon.ico!");

    //copy the images over
    let img_dir: PathBuf = [&current_dir, "src", "img"].iter().collect();
    copy_dir(&img_dir, &assets_dir).expect("cargo:warning=Failed to copy_dir!");
    //copy the template pages over
    //let pages_dir: PathBuf = [&current_dir, "src", "pages"].iter().collect();
    //copy_dir(&pages_dir, &assets_dir).expect("cargo:warning=Failed to copy_dir!");

    //copy the js files over
    let js_dir: PathBuf = [&current_dir, "src", "js"].iter().collect();
    copy_dir(&js_dir, &assets_dir).expect("cargo:warning=Failed to copy_dir!");

    //copy the component js files over
    std::fs::create_dir_all(PathBuf::from_iter([&current_dir, "assets", "js", "components"].iter()))
                            .expect("failed to create director(y/ies)!");
    let components_dir: PathBuf = [&current_dir, "src", "pages", "components"].iter().collect();
    copy_files_with_extension(&components_dir,
                              &PathBuf::from_iter([&current_dir, "assets", "js", "components"].iter()),
                              ".js")
                              .expect("cargo:warning=Failed to copy_dir!");

    //let dest_path = Path::new(&out_dir).join("hello.rs");
    //let mut f = File::create(&dest_path).unwrap();

    // f.write_all(b"
    //     pub fn message() -> &'static str {
    //         \"Hello, World!\"
    //     }
    // ").unwrap();
}

/// don't call this except when in copy_dir, or recursive_copy_dir.
fn recursive_copy_dir(from: &PathBuf, to: &PathBuf) -> Result<(), std::io::Error> {
    // println!("cargo:warning=recursive_copy_dir entered! from: {:?}",from.clone().display());
    // println!("cargo:warning=recursive_copy_dir entered! to  : {:?}",to.clone().display());

    for entry in std::fs::read_dir(from)? {
        let path = entry.expect("failed to read entry").path();

        // let metadata = std::fs::metadata(&path)?;
        // let last_modified = metadata
        //     .modified()?
        //     .elapsed()
        //     .expect("std::io::Error")
        //     .as_secs();

        // if last_modified < 24 * 3600 && metadata.is_file() {
        //     println!(
        //         "cargo:warning=Last modified: {:?} seconds, is read only: {:?}, size: {:?} bytes, filename: {:?}",
        //         last_modified,
        //         metadata.permissions().readonly(),
        //         metadata.len(),
        //         path.file_name().ok_or("No filename").expect("No filename!")
        //     );
        // }

        if path.is_file() {
            let from_filename = path.file_name().expect("filename not found!");
            let to_filepath = [to, &PathBuf::from(from_filename)].iter().collect::<PathBuf>();
            // println!("cargo:warning=path.is_file()");
            // println!("cargo:warning=from{:?} to filepath{:?}",&path,&filepath);
            let from_attr = std::fs::metadata(&path)?;
            //Check if the file already exists
            match std::fs::metadata(&to_filepath) {
                Ok(to_attr) => {
                    //File exists in the target location
                    match from_attr.modified() {
                        Ok(from_modified) => {
                            match to_attr.modified() {
                                Ok(to_modified) => {
                                    //Only copy files over where the modification date is different
                                    if from_modified != to_modified {
                                        std::fs::copy(path, &to_filepath)?;
                                    }
                                },
                                Err(err) => {
                                    println!("cargo:warning=Unable to determine to's modified value: {:?}. Cannot continue. Error: {:?}",&to_attr,&err);
                                }
                            }
                        },
                        Err(err) => {
                            println!("cargo:warning=Unable to determine from's modified value: {:?}. Cannot continue. Error: {:?}",&from_attr,&err);
                        },
                    }
                },
                Err(err)=> {
                    //File does not exist or there is an error reading the to location path
                    if err.kind() == ErrorKind::NotFound {
                        std::fs::copy(path, &to_filepath)?;
                    } else {
                        println!("cargo:warning=Unable to determine to_filepath's modified value: {:?}. Cannot continue. Error: {:?}",&from_attr,&err);
                    }
                }
            }

            //std::fs::copy(path, &filepath)?;
        } else if path.is_dir() {
            //If the current item we are copying is a directory, we need to create it
            //println!("cargo:warning=path.is_dir()");
            let dirname = path.file_name().expect("filename not found!");
            match  dirname.to_str() {
                Some(dirname_str) => {
                    //Don't copy over .hidden directories
                    if dirname_str.starts_with(".") == false {
                        let directory_path_to_create = [to, &PathBuf::from(dirname)].iter().collect();
                        //println!("cargo:warning=from {:?} to directory_path_to_create {:?}",&path,&directory_path_to_create);
                        std::fs::create_dir_all(&directory_path_to_create)
                            .expect("failed to create director(y/ies)!");
                        recursive_copy_dir(&path, &directory_path_to_create)?;
                    }
                },
                None => {

                },
            }

        } else {
            // Skip other content
        }
        //println!("cargo:warning=Counter is: {:?}", counter.clone());
    }
    Ok(())
}

/// Recursively copies the contents of one directory to another. This function will also copy the
/// permission bits of the original files to the destination files.
///
/// This function will **overwrite** the contents of `to`, if files have the same name.
///
/// On success, the total number of files and directories copied is returned.
///
/// ## Errors
///
/// This function will return an error in the following situations, but is not limited to just
/// these cases:
///
/// - The `from` path is not a directory
/// - The `from` path does not exist
/// - The current process does not have the permission rights to access `from` or write `to`
pub fn copy_dir(from: &PathBuf, to: &PathBuf) -> Result<(), std::io::Error> {
    //let to_buf = to.as_ref().to_path_buf();
    // println!("cargo:warning=copy_dir entered! from: {:?}",from.clone().display());
    // println!("cargo:warning=copy_dir entered! to  : {:?}",to.clone().display());

    //First check if the path even exists
    if !from.as_path().exists() {
        //println!("cargo:warning=copy from directory doesn't exist! Exists?'{:?}' ", from.as_path().exists());
        return Ok(());
    }

    let mut from_directory_name: Option<PathBuf> = None;
    //If we are copying a directory, we need to create the directory on the target, and change the copy command
    if from.as_path().is_dir() {
        let directory_to_create = from
            .as_path()
            .file_name()
            .expect("unable to get directory name!");
        // println!("cargo:warning=directory_to_create {:?} to.as_path() {:?}", directory_to_create, to.as_path().file_name());
        let directory_path_to_create: PathBuf =
            [to.to_path_buf().as_os_str(), &directory_to_create]
                .iter()
                .collect();
        // println!("cargo:warning=directory_path_to_create {:?}", directory_path_to_create);
        //Check if directory already exists
        match std::fs::metadata(&directory_path_to_create) as std::io::Result<std::fs::Metadata> {
            Ok(ref _directory_metadata) => {
                // println!("cargo:warning=NOT creating: {:?} MetaData: {:?}", &directory_path_to_create, &directory_metadata);
                from_directory_name = Some(PathBuf::from(directory_to_create));
            }
            _ => {
                // println!("cargo:warning=YES creating: {:?}", &directory_path_to_create);
                std::fs::create_dir_all(&directory_path_to_create)
                    .expect("failed to create director(y/ies)!");
                from_directory_name = Some(PathBuf::from(directory_to_create));
            }
        }
    } else {
        // println!("cargo:warning=from.as_path().is_dir() {:?}", &from.as_path().is_dir());
    }

    //If we are copying from a directory we need to use the new path
    match from_directory_name {
        Some(ref directory_name) => {
            // println!("cargo:warning=match directory_created SOME to:{:?}",
            //         &[to.to_path_buf(), directory_name.clone().to_path_buf()].iter().collect::<PathBuf>()
            // );

            recursive_copy_dir(
                from,
                &[to.to_path_buf(), directory_name.to_path_buf()]
                    .iter()
                    .collect::<PathBuf>(),
            )
            .expect("Failed to recursive_copy_dir:Some!");
        }
        None => {
            // println!("cargo:warning=match directory_created NONE to:{:?}",
            //         &[to.to_path_buf()].iter().collect::<PathBuf>()
            // );
            recursive_copy_dir(from, to).expect("failed to recursive_copy_dir:None!");
        }
    };
    Ok(())
}

/// Recursively copies the contents of one directory to another. This function will also copy the
/// permission bits of the original files to the destination files.
///
/// This function will **overwrite** the contents of `to`, if files have the same name.
///
/// On success, the total number of files and directories copied is returned.
///
/// ## Errors
///
/// This function will return an error in the following situations, but is not limited to just
/// these cases:
///
/// - The `from` path is not a directory
/// - The `from` path does not exist
/// - The current process does not have the permission rights to access `from` or write `to`
pub fn copy_files_with_extension(from: &PathBuf, to: &PathBuf, file_extension_limiter: &str) -> Result<(), std::io::Error> {
    //let to_buf = to.as_ref().to_path_buf();
    // println!("cargo:warning=copy_dir entered! from: {:?}",from.clone().display());
    // println!("cargo:warning=copy_dir entered! to  : {:?}",to.clone().display());

    //First check if the path even exists
    if !from.as_path().exists() {
        //println!("cargo:warning=copy from directory doesn't exist! Exists?'{:?}' ", from.as_path().exists());
        return Ok(());
    }

    for entry in std::fs::read_dir(from)? {
        let path = entry.expect("failed to read entry").path();

        // let metadata = std::fs::metadata(&path)?;
        // let last_modified = metadata
        //     .modified()?
        //     .elapsed()
        //     .expect("std::io::Error")
        //     .as_secs();

        // if last_modified < 24 * 3600 && metadata.is_file() {
        //     println!(
        //         "cargo:warning=Last modified: {:?} seconds, is read only: {:?}, size: {:?} bytes, filename: {:?}",
        //         last_modified,
        //         metadata.permissions().readonly(),
        //         metadata.len(),
        //         path.file_name().ok_or("No filename").expect("No filename!")
        //     );
        // }

        if path.is_file() && path.display().to_string().ends_with(file_extension_limiter) {
            let from_filename = path.file_name().expect("filename not found!");
            let to_filepath = [to, &PathBuf::from(from_filename)].iter().collect::<PathBuf>();
            // println!("cargo:warning=path.is_file()");
            // println!("cargo:warning=from{:?} to filepath{:?}",&path,&filepath);
            let from_attr = std::fs::metadata(&path)?;
            //Check if the file already exists
            match std::fs::metadata(&to_filepath) {
                Ok(to_attr) => {
                    //File exists in the target location
                    match from_attr.modified() {
                        Ok(from_modified) => {
                            match to_attr.modified() {
                                Ok(to_modified) => {
                                    //Only copy files over where the modification date is different
                                    if from_modified != to_modified {
                                        std::fs::copy(path, &to_filepath)?;
                                    }
                                },
                                Err(err) => {
                                    println!("cargo:warning=Unable to determine to's modified value: {:?}. Cannot continue. Error: {:?}",&to_attr,&err);
                                }
                            }
                        },
                        Err(err) => {
                            println!("cargo:warning=Unable to determine from's modified value: {:?}. Cannot continue. Error: {:?}",&from_attr,&err);
                        },
                    }
                },
                Err(err)=> {
                    //File does not exist or there is an error reading the to location path

                    if err.kind() == ErrorKind::NotFound {
                        std::fs::copy(path, &to_filepath)?;
                    } else {
                        println!("cargo:warning=Unable to determine to_filepath's modified value: {:?}. Cannot continue. Error: {:?}",&from_attr,&err);
                    }
                }
            }

            //std::fs::copy(path, &filepath)?;
        } else if path.is_dir() {
            //If the current item we are copying is a directory, we need to create it
            //println!("cargo:warning=path.is_dir()");
            let dirname = path.file_name().expect("filename not found!");
            match  dirname.to_str() {
                Some(dirname_str) => {
                    //Don't copy over .hidden directories
                    if dirname_str.starts_with(".") == false {
                        //let directory_path_to_create = [to, &PathBuf::from(dirname)].iter().collect();
                        //println!("cargo:warning=from {:?} to directory_path_to_create {:?}",&path,&directory_path_to_create);
                        // std::fs::create_dir_all(&directory_path_to_create)
                        //     .expect("failed to create director(y/ies)!");
                        // recursive_copy_dir_files_with_extension(&path, &directory_path_to_create, file_extension_limiter)?;
                    }
                },
                None => {

                },
            }

        } else {
            // Skip other content
        }
        //println!("cargo:warning=Counter is: {:?}", counter.clone());
    }

    Ok(())
}

Thanks for sharing!
My approach is simpler, it would be something like this:
cp -R a /b; cd b/; ./sailfish-cli .
You can of sailfish-cli is a general tool just like tera-cli https://github.com/chevdor/tera-cli

Features: I need a sailfish-cli tool to transform a nested folder a to folder b, will transform all files with ext.stpl to b same folder structure with files without .stpl. I have looked into sailfish and compiler, it mostly support macro for now which is a bit hard to navigate around. The dictionaries data to do the translation can be environment variable or config file through --config, -c If there is any hint to get it done? Thanks

Would this bash script suffice?
#!/bin/bash

if [ "$#" -ne 2 ]; then
    echo "Usage: $0 path_a path_b"
    exit 1
fi

path_a="$1"
path_b="$2"

if [ ! -d "$path_b" ]; then
    mkdir -p "$path_b"
fi

for file in "$path_a"/*; do
    filename=$(basename "$file")
    # Check if file has .stpl extension
    if [[ "$filename" == *.stpl ]]; then
        new_filename="${filename%.stpl}"
        mv "$file" "$path_b/$new_filename"
    else
        mv "$file" "$path_b/$filename"
    fi
done

This doesn't include the part of translating stpl file. The copy part with script is easy, hard part is doing translate recursively the whole directory without writing macro like what we normally do with sailfish. That's why I ask about how to use sailfish compiler directly.

repo: rust-sailfish/sailfish


text:
vsock: Prepare version 0.2.0 release

Summary of the PR
Update changelog and Cargo.toml to version 0.2.0
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:

[x] All commits in this PR have Signed-Off-By trailers (with
git commit -s), and the commit message has max 60 characters for the
summary and max 75 characters for each description line.
[x] All added/changed functionality has a corresponding unit/integration
test.
[x] All added/changed public-facing functionality has entries in the "Upcoming
Release" section of CHANGELOG.md (if no such section exists, please create one).
[x] Any newly added unsafe code is properly documented.

    Uploading vhost-device-vsock v0.2.0 (/home/stefano/repos/vhost-device/vhost-device-vsock)
    Uploaded vhost-device-vsock v0.2.0 to registry `crates-io`
note: waiting for `vhost-device-vsock v0.2.0` to be available at registry `crates-io`.
You may press ctrl-c to skip waiting; the crate should be available shortly.
   Published vhost-device-vsock v0.2.0 at registry `crates-io`

authors: dorindabassey stefano-garzarella

repo: rust-vmm/vhost-device


text:
Tests for Windows under GNU are experiencing a linker failure

Taken from the latest CI logs:
          Warning: .drectve `-exclude-symbols:_ZN17raw_window_handle8borrowed3imp6Active6handle17hcdc9a7e46fa42377E ' unrecognized
          Warning: .drectve `-exclude-symbols:_ZN17raw_window_handle8borrowed3imp6Active10set_active17h87aab7a0dbfa799aE ' unrecognized
          Warning: .drectve `-exclude-symbols:_ZN17raw_window_handle8borrowed3imp6Active12set_inactive17hdc388a803d443f6fE ' unrecognized
          Warning: .drectve `-exclude-symbols:_ZN17raw_window_handle8borrowed3imp12ActiveHandle13new_unchecked17h717ec49c81207b3aE ' unrecognized
          Warning: corrupt .drectve at end of def file
          Warning: corrupt .drectve at end of def file
          Warning: corrupt .drectve at end of def file
          Warning: corrupt .drectve at end of def file
          collect2.exe: error: ld returned 5 exit status

This failure only occurs for *-pc-windows-gnu, not *-pc-windows-msvc. Also it apparently only happens under Windows, as I can build it for x86_64-pc-windows-gnu just fine on my Linux laptop.
I need to go to bed now, but I'll investigate this on my Windows VM this week.

I'm guessing this is an issue with how the build environment is set up on CI and not really a Softbuffer issue... still haven't booted into Windows and tried to reproduce it though.
I previously had weird compile issues in a project with the Windows gnu toolchain running under msys2 with a Rust install from outside msys2; which was fixed by just using msys2's version of Rust. Some weird compile error started happening that hadn't before, but I don't remember if it was like this one: https://github.com/pop-os/keyboard-configurator/commit/0b5827a00f74e2dd48750a2ffeda2546e009092e.

Looking up the error, it looks like these warnings would happen if the libraries were built with msvc, but linked with gnu ld, which doesn't use that directive? Not sure why that would be happening.

Ah: https://github.com/rust-lang/rust/issues/112368. Looks like the warnings appear starting in Rust 1.70, which updates LLVM to have https://github.com/llvm/llvm-project/commit/c5b3de6745c37dd991430b9b88ff97c35b6fc455. The directive would be supported with a sufficiently new version of ld or lld. But it should just be a warning and work anyway?
It's not obvious to my looking at the logs why this is causing a compile failure. All the messages the linker is printing are warnings.
Anyway, it doesn't seem to be a Softbuffer issue, and would occur with any Rust code built in the same environment. I guess...

https://github.com/microsoft/windows-rs/issues/2614#issuecomment-1684152597
I guess the problem is that ld is crashing, not erroring, with nothing useful logged? But it shouldn't be an issue with newer versions of ld.
In any case, not really softbuffer related.

repo: rust-windowing/softbuffer


text:
fix cdc compile errors by integrating cdc

closes #377

see also https://github.com/green-coder/cdc/pull/7

repo: rustic-rs/rustic


text:
MediaSource callbacks

Describe the Bug
When MediaSource set_onsourceopen is called ready_state() returns __Nonexhaustive instead of Open
Steps to Reproduce

Register callback

let callback = Closure::wrap(Box::new(on_source_open) as Box<dyn Fn(&MediaSource)>);

media_source.set_onsourceopen(Some(callback.into_js_value().unchecked_ref()));

Log ready state in callback

fn on_source_open(media_source: &MediaSource) {
    #[cfg(debug_assertions)]
    ConsoleService::info(&format!("Ready State => {:?}", media_source.ready_state()));
}

Expected Behavior
When onsourceopen callback is called ready_state() should already be Open.
Actual Behavior
When onsourceopen callback is called ready_state() returns  __Nonexhaustive.
Additional Context
Using Brave browser Version 1.17.73 Chromium: 87.0.4280.67 (Official Build) (64-bit)
Also, hooking a button to log ready_state() returns Open. It seams that the timing is borked.

Is this perhaps a bug in our WebIDL? Perhaps browsers have changed and/or updated in the meantime and we need to add some new variants?

Did some research and W3C specify only 3 variants. The source also specify the same. Also looked up rust nonexhaustive and it is used to force lib users to account for future addition to Enums.
Conclusion, I really don't know where that __Nonexhaustive is coming from...

This is injected by the wasm-bindgen attribute to handle unknown variants. If possible you may want to try to add logging there or otherwise recreate this in JS if you can to see what the string is.

Well I was wrong! There is no bug. For posterity, be careful what you drop. Rust automatically drop things when they go out of scope. If you drop mediaSource or sourceBuffer it will obviously throw errors.

authors: SionoiS alexcrichton

repo: rustwasm/wasm-bindgen


text:
Skip over unsupported instructions instead of panicking

Fixes #2969
This changes wasm-bindgen-wasm-interpreter to ignore a function rather than panicking if it contains an unsupported instruction. This works around some runtime glue that gets added to our descriptor functions on the WASI target by more-or-less ignoring them.
I also put some work into making sure a helpful error message is given if the actual describe function contains unsupported instructions, by keeping track of the instructions that caused us to skip and including them in the error message if the descriptor is invalid.

I think that the better error messages here are definitely good to have, but I would prefer to not skip over unknown functions. We can't really say ahead of time whether they'll be crucial to the execution and final result or not, so I wouldn't be comfortable automatically skipping them.

I will close this for now as it mostly addresses a WASI issue, apart from what alexcrichton said.
See #3421.

authors: Liamolucko alexcrichton daxpedda


text:
Sample points from meshes keeping node labels

❓ Questions & Help
Hi, I am working on a custom InMemoryDataset which I based on the FAUST example for meshes. However, in my dataset each vertex in the mesh has a class label for segmentation.
When transforming the mesh to point cloud by using the SamplePoints, I was not able to retain the label information corresponding to the sampled points anymore.
I ended up just inserting one line in the SamplePoints transformation to retain these labels:
if self.remove_faces:
        data.face = None

# all pos of a face have the same label (we take the first vertex of all faces here)
data.y = data.y[face[0]]

return data

This seems to work, but is there a better way of doing this?

I think we could optionally return the face_index for each sampled point. What do you think? You could then do data.y = data.y[data.face_index[data.face[0]] to map any vertex feature to a point feature.

That's okay, in my case the vertices of a face have the same label as that face. I want to "propagate" these face labels to the sampled points from that face.
For a general solution, having access to the face_index of each sampled point would probably be a good idea.


text:
initial manpage

Please feel free to edit to make any changes you desire.
I don't care about the copyright of that manpage. Feel free to wipe mine. (I am mostly motivated to have a man page since that is the last Debian packaging issue so far.)
In ronn format. To create convert to roff.
Install ronn.
sudo apt-get install ruby-ronn
Convert.
ronn < man/corridor.8.ronn > man/corridor.8
related:
https://github.com/rustybird/corridor/issues/10

Thanks, merged!

authors: adrelanos rustybird

repo: rustybird/corridor

license: isc


text:
Keyd changes the default keycode for 'Fn' on my macbook

Love your work!
I was hoping I could figure out a quick and dirty patch for my T2 Macbook.
I see that insrc/keys.h the FN key is mapped to 254, however, I need to map it to 464!
I tried changing the array to allow upto 465 to mimic your logic and changed the corresponding for loop in src/keys.c
unfortunately after recompiling it comes back as key 208!
I was wondering if you had any ideas on how I could patch this to work on my mac.
Thanks!
Celes

I see that insrc/keys.h the FN key is mapped to 254, however, I need to map it to 464!

That is keyd's internal code. It should be mapped to KEY_FN on input, which should be correctly defined by your kernel headers as 464. Have you tried running keyd monitor and inspecting the output? You should see something like fn down with a blank config. If not, can you post the output of sudo evtest[^1] while pressing the key? It is also possible that the hardware doesn't actually emit a distinct event for fn, which is a common problem on laptop keyboards.
[^1]: Make sure keyd is disabled and that you select your physical board from the list.

Not OP, but my situation on an M1 Macbook sounds similar. Not sure if I should open a separate issue for it.
When I run sudo keyd monitor I get entries for most remapped keys. There's not output when I press leftcontrol (remmapped to layer(alt) in the main layer.
What seems to be the relevant part of sudo evtest output (with keyd stopped) is:
Event: time 1723288312.142961, -------------- SYN_REPORT ------------
Event: time 1723288312.173686, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e0
Event: time 1723288312.173686, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 0
Event: time 1723288312.173686, -------------- SYN_REPORT ------------
Event: time 1723288312.827211, type 4 (EV_MSC), code 4 (MSC_SCAN), value 700e0
Event: time 1723288312.827211, type 1 (EV_KEY), code 29 (KEY_LEFTCTRL), value 1
Event: time 1723288312.827211, -------------- SYN_REPORT ------------

The config (cobbled together through trial and error)
[ids]
k:05ac:0281

[global]
default_layout = pl

[main]
delete = backspace

rightmeta = layer(altgr)
rightalt = rightcontrol

leftcontrol = layer(fn)
fn = leftcontrol
leftmeta = alt
leftalt = leftmeta

home = C-left
end = C-right
pageup = C-up
pagedown = C-down

brightnessdown = f1
brightnessup = f2
scale = f3
search = f4
record = f5
sleep = f6
previoussong = f7
playpause = f8
nextsong = f9
mute = f10
volumedown = f11
volumeup = f12

[fn]
left = home
right = end
up = pageup
down = pagedown

f1 = brightnessdown
f2 = brightnessup
f3 = scale
f4 = search
f5 = record
f6 = sleep
f7 = previoussong
f8 = playpause
f9 = nextsong
f10 = mute
f11 = volumedown
f12 = volumeup

Are there any updates on this? I can't access the second layer of my touchbar, which seems to be related to this issue.

I see that insrc/keys.h the FN key is mapped to 254, however, I need to map it to 464!

That is keyd's internal code. It should be mapped to KEY_FN on input, which should be correctly defined by your kernel headers as 464.
Have you tried running keyd monitor and inspecting the output? You should see something like fn down with a blank config.
If not, can you post the output of sudo evtest1 while pressing the key? It is also possible that the hardware doesn't actually emit a distinct event for fn, which is a common problem on laptop keyboards.
Footnotes

Make sure keyd is disabled and that you select your physical board from the list. ↩

M1 MacBook but having the same issue. keyd emitting 254 breaks tiny-dfr Touch Bar Fn layer functionality.
keyd monitor detects Fn but evtest detects 254. Tested with blank config ([ids]\n*)
$ sudo keyd monitor
device added: 05ac:0341:c3080866 Apple Internal Keyboard / Trackpad (/dev/input/event0)
device added: 0000:0000:1bf3eacc MacBookPro17,1 Touch Bar (/dev/input/event1)
device added: 05ac:0341:3179765c Apple Internal Keyboard / Trackpad (/dev/input/event2)
device added: 1209:316e:2b020ae1 Dynamic Function Row Virtual Input Device (/dev/input/event5)
device added: 0fac:0ade:efba1ddf keyd virtual keyboard (/dev/input/event6)
device added: 0fac:1ade:d2b36ae6 keyd virtual pointer (/dev/input/event7)
keyd virtual keyboard	0fac:0ade:efba1ddf	enter up
keyd virtual keyboard	0fac:0ade:efba1ddf	fn down
keyd virtual keyboard	0fac:0ade:efba1ddf	fn up
$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:	Apple Internal Keyboard / Trackpad
/dev/input/event1:	MacBookPro17,1 Touch Bar
/dev/input/event2:	Apple Internal Keyboard / Trackpad
/dev/input/event3:	Apple SMC power/lid events
/dev/input/event4:	MacBook Pro J293 Headphone Jack
/dev/input/event5:	Dynamic Function Row Virtual Input Device
/dev/input/event6:	keyd virtual keyboard
/dev/input/event7:	keyd virtual pointer
Select the device event number [0-7]: 6
Input driver version is 1.0.1
Input device ID: bus 0x3 vendor 0xfac product 0xade version 0x0
Input device name: "keyd virtual keyboard"
Supported events:
  Event type 0 (EV_SYN)
  <truncated>
Properties:
Testing ... (interrupt to exit)
Event: time 1732936447.877785, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1732936447.877785, -------------- SYN_REPORT ------------
Event: time 1732936448.119416, type 1 (EV_KEY), code 254 (?), value 1
Event: time 1732936448.119416, -------------- SYN_REPORT ------------
Event: time 1732936448.271307, type 1 (EV_KEY), code 254 (?), value 0
$ sudo systemctl stop keyd
$ sudo keyd monitor
device added: 05ac:0341:c3080866 Apple Internal Keyboard / Trackpad (/dev/input/event0)
device added: 0000:0000:1bf3eacc MacBookPro17,1 Touch Bar (/dev/input/event1)
device added: 05ac:0341:3179765c Apple Internal Keyboard / Trackpad (/dev/input/event2)
device added: 1209:316e:2b020ae1 Dynamic Function Row Virtual Input Device (/dev/input/event5)
Apple Internal Keyboard / Trackpad	05ac:0341:c3080866	enter up
Apple Internal Keyboard / Trackpad	05ac:0341:c3080866	fn down
Apple Internal Keyboard / Trackpad	05ac:0341:c3080866	fn up
$ sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0:	Apple Internal Keyboard / Trackpad
/dev/input/event1:	MacBookPro17,1 Touch Bar
/dev/input/event2:	Apple Internal Keyboard / Trackpad
/dev/input/event3:	Apple SMC power/lid events
/dev/input/event4:	MacBook Pro J293 Headphone Jack
/dev/input/event5:	Dynamic Function Row Virtual Input Device
Select the device event number [0-5]: 0
Input driver version is 1.0.1
Input device ID: bus 0x1c vendor 0x5ac product 0x341 version 0x175
Input device name: "Apple Internal Keyboard / Trackpad"
Supported events:
  Event type 0 (EV_SYN)
  <truncated>
Properties:
Testing ... (interrupt to exit)
Event: time 1732936876.378020, type 4 (EV_MSC), code 4 (MSC_SCAN), value 70028
Event: time 1732936876.378020, type 1 (EV_KEY), code 28 (KEY_ENTER), value 0
Event: time 1732936876.378020, -------------- SYN_REPORT ------------
Event: time 1732936877.134727, type 4 (EV_MSC), code 4 (MSC_SCAN), value ff0003
Event: time 1732936877.134727, type 1 (EV_KEY), code 464 (KEY_FN), value 1
Event: time 1732936877.134727, -------------- SYN_REPORT ------------
Event: time 1732936877.290671, type 4 (EV_MSC), code 4 (MSC_SCAN), value ff0003
Event: time 1732936877.290671, type 1 (EV_KEY), code 464 (KEY_FN), value 0

+1. Keyd correctly detects FN key, but after remapping it stops working as it worked before - for instance, I can't use top row with it.

Any progress or workaround on this? Maybe we can somehow tell keyd that we remap fn to specific keycode? Is operation with keycodes in keyd even possible?

authors: celesrenata fathonix ftelnov rvaiya szabba themg95

repo: rvaiya/keyd


text:
How to implement title bar hide/show function when scroll up/down?

just like this.
https://imgur.com/i8n8t1e

https://stackoverflow.com/questions/76767407/how-to-implement-title-bar-hide-show-when-scrollbar-up-down-in-android

So far, it's not easy to implement because there are no corresponding components for Maui yet
https://github.com/dotnet/maui/issues/2363

https://github.com/rwecho/V2ex.Maui/blob/884b29382e0696d913c136edd727705654ae0f67/src/V2ex.Maui/Behaviors/CollectionViewScrollBehavior.cs#L3
Now I have added a behavior to implement this. But it is not perfect like the Twitter app(Original Android).


text:
Feature suggestion: minimal toolbar for better touch device use & beginner friendliness (mockup included)

I really like the concept of using this editor! I had this idea for a tiny change to make it even more approachable and touch device friendly (imagine firing up lite on a windows 10 tablet and you forgot your bluetooth keyboard and you just want to do a 1-2 letters edit, and now inputting CTRL+SHIFT+P or CTRL+S might be more involved):

This small toolbar would just provide two shortcuts to trigger the given two commands I annotated. Clicking a button would do exactly what entering that command with the keyboard does, so the file browser at the bottom would otherwise remain working as before. (One day maybe a preferences button could be a worthwhile third icon to add.) This toolbar could be enough to get anyone completely unfamiliar with the editor started, and with everything else remaining as-is, including the cool helpful CTRL+SHIFT+P hint text in the every center at launch, people will still be strongly incentivized to get used to the usually quicker keyboard command style.

This isn't something I'd want in the core of lite, but the the plugin system does allow for this functionality to be implemented as a plugin. See the treeview plugin in data/core for how to go about achieving this by creating a custom locked "view" if it's something you're interested in implementing yourself.

That's a shame, I think it'd go a long way towards making the first few minutes a bit more intuitive. But the configurability is certainly appreciated.

repo: rxi/lite


text:
Add a public validate form method

Grabbed this from https://github.com/morgrowe/aspnet-validation

Whoops, wrong repo.

repo: ryanelian/aspnet-validation


text:
disagree with 'Don't over-optimize'

The time log shows us that maybe it's better to calculate the length and store it .
From 0.065ms to 0.035ms.

Sorry that I did't see In modern browsers, this is optimized.;

Why is it closed, so the result is whether modern browsers are optimized?
The results of my tests were also not found to be optimized(chrome 73.0.3683.103):

default: 2.386962890625ms
default: 1.27099609375ms

I performed the same test with the same Chrome version and there is a big difference, really.

authors: andreyluiz sevencai w3cmark

repo: ryanmcdermott/clean-code-javascript

license: mit


text:
Improve example "Function names should say what they do"

Improve example to be more consistent and remove unneeded context

I created two commits. One without and one with prototype example. I would choose for the example with prototype, but leave it up to you (if you accept this pr).

Would the second commit contradict the Don't write to global functions?

Good point! Maybe the first commit is the winner then. Or the native Date object should be replaced with an "own object"?

Agreed with @vsemozhetbyt. Let's not write to global functions :) I like your first commit though, can you remove that commit from this branch?

Reverted commit with prototype :)

:+1: for this change.

Functions should start by a verb to differenciate infinitive and simple past
example: var dateSet = setDate()

Function names should indicate the argument order
example: function addMonthToDate(month, date)

Thanks that's a great improvement!

authors: Tarabass ryanmcdermott sylvainpolletvillard vsemozhetbyt


text:
Rename Azure connections 'role' field to 'roles'

This came up in https://github.com/Azure/radius/pull/1546. Connections role field is currently an array with support for multiple role names, so renaming it to roles is more intuitive.
https://github.com/Azure/radius/blob/main/docs/content/concepts/appmodel-concept/connections-model/snippets/azure-connection.bicep#L14

Moved to new private repo https://github.com/ProjectRadius/bicep/pull/60

repo: rynowak/bicep


text:
Fix lowlighter metrics repo 404 errors

Since lowlighter metrics repo links give 404 errors, I fixed their URL to solve this issue.

Since lowlighter metrics repo links give 404 errors, I fixed their URL to solve this issue.

Thank you for solving this problem 🙏💙

repo: rzashakeri/beautify-github-profile


text:
ubantu报错

~/st-load-master-master$ ./configure && make
Is OSX: NO
st-1.9t is ok.
build http-parser-2.1
Archive:  ../3rdparty/http-parser-2.1.zip
creating: http-parser-2.1/
inflating: http-parser-2.1/AUTHORS
inflating: http-parser-2.1/LICENSE-MIT
inflating: http-parser-2.1/http_parser.h
inflating: http-parser-2.1/http_parser.c
inflating: http-parser-2.1/test.c
inflating: http-parser-2.1/Makefile
inflating: http-parser-2.1/README.md
creating: http-parser-2.1/contrib/
inflating: http-parser-2.1/contrib/url_parser.c
inflating: http-parser-2.1/contrib/parsertrace.c
inflating: http-parser-2.1/.mailmap
inflating: http-parser-2.1/.gitignore
inflating: http-parser-2.1/http_parser.gyp
inflating: http-parser-2.1/.travis.yml
inflating: http-parser-2.1/CONTRIBUTIONS
cc -I. -DHTTP_PARSER_STRICT=1  -Wall -Wextra -Werror -O0 -g  -c http_parser.c
http_parser.c: In function ‘http_parser_parse_url’:
http_parser.c:2093:18: error: this statement may fall through [-Werror=implicit-fallthrough=]
2093 |         found_at = 1;
|         ~~~~~^
http_parser.c:2096:7: note: here
2096 |       case s_req_server:
|       ^~
cc1: all warnings being treated as errors
make: *** [Makefile:35: http_parser.o] Error 1
build http-parser-2.1 failed, ret=2

found_at = 1;
break;  //这里加一个break

repo: rzrobert/st-load-master


text:
Added a root_obj field to the NestedInline class

With this PR you should be able to get the root object (eg. for updating the queryset of deeply nested models based on the root object's pk or other field)

Hey!
Could this PR be reviewed and merged please? Because I really need this for another project. I had solved the issue in a hacky way but I'd really appreciate if this PR could be merged so I can update my code.
https://github.com/ralkan/django-rulengine/pull/3/files
Thanks! :)

repo: s-block/django-nested-inline


text:
VoxelSpace.html

When I cloned your repo and opened VoxelSpace.html, for some reason I get this:

Do you know why I'm getting this? Please note that I'm on a MacBook (just that) using High Sierra

I patched the file to fix two problems. Can you try it again please.

Sure thing! Trying it now

Nope. Unfortunately, I get the same image. Do I not have some dependencies?

Can you open your Javascript console (probably key F12 in your browser) and then refresh the page (key F5). There might be some error messages written by the browser.

I'll try that

Here are the errors I get:

Ok, the problem is, that you are try to open the web page locally. This works in some browsers, but not in all of them. Some prevent specific features when run local webpages. Please take a look at the following link and follow their suggestions.
https://stackoverflow.com/questions/4556429/disabling-same-origin-policy-in-safari

Thanks! That worked!

authors: JohnLetey s-macke

repo: s-macke/VoxelSpace


text:
Better reflection for TypeAliases

Right now all type aliases at type positions are expanded. This is due TypeScript's TypeAliases limitation. I believe that we can do better only by switching to work with syntax tree instead of symbols and types

https://github.com/Microsoft/TypeScript/issues/23772

repo: s-panferov/docscript


text:
Unable to reach the results on the leaderboard

Hi, I am trying to use wav2vec 2.0 Large to replicate the results on the leaderboard. I completely followed your instructions and training parameters, but the results are not good enough.

I can't find what is causing this result

Hi,
I think the gap is caused by different learning rates used.
In the SUPERB paper, we tune the learning rate for each "upstream-downstream" pair and report the optimal result.
@leo19941227 can we share the learning rates that we used for wav2vec 2.0 Large?

Did you use the training learning rate as released in the SUPERB artifacts page?

Did you use the training learning rate as released in the SUPERB artifacts page?

So I should apply lr=1.0e-5 for all the downstream tasks? I am not sure where is SUPERB artifacts page.

Oh I believe this is the problem. You can know the best learning rate here:
https://github.com/s3prl/s3prl/blob/master/s3prl/downstream/docs/superb_artifacts.md
In our artifact server, each checkpoint folder name indicates the best learning rate we found for reporting the final number.

Thank you so much! But take IC as an example, the learning rate is the same as the default learning rate. And the result still does not achieve the goal. Am I missing something else?

Oh! Really sorry about this. I find that the actual best lr for wav2vec2_large_ll60k is lr 1e-3, and the 1e-4 result aligns well with your. The reason I did not release the 1e-3 one is because it was trained by Meta Inc. during our cooperation, however there is some difficulty to release it publicly.

However, for wav2vec2_large_ll60k on the other tasks, this is not the case and I believe you can get the same results after following the reported lr.
Please let me know if you still can't reproduce the results. Thanks!

Oh! Really sorry about this. I find that the actual best lr for wav2vec2_large_ll60k is lr 1e-3, and the 1e-4 result aligns well with your. The reason I did not release the 1e-3 one is because it was trained by Meta Inc. during our cooperation, however there is some difficulty to release it publicly.
LR	IC acc
1e-3	0.9528077841
1e-4	0.9322435
1e-5	0.9116793871
However, for wav2vec2_large_ll60k on the other tasks, this is not the case and I believe you can get the same results after following the reported lr.
Please let me know if you still can't reproduce the results. Thanks!

Oh! Really sorry about this. I find that the actual best lr for wav2vec2_large_ll60k is lr 1e-3, and the 1e-4 result aligns well with your. The reason I did not release the 1e-3 one is because it was trained by Meta Inc. during our cooperation, however there is some difficulty to release it publicly.
LR	IC acc
1e-3	0.9528077841
1e-4	0.9322435
1e-5	0.9116793871
However, for wav2vec2_large_ll60k on the other tasks, this is not the case and I believe you can get the same results after following the reported lr.
Please let me know if you still can't reproduce the results. Thanks!

Thank you very much! I'll try this.


text:
tera builder output all hidden states

Replace the weighted-sum function with outputting all hidden states in the TERA builder to let weighted-sum upstream-agnostic
Include the input features of right before transformer blocks to align with previous hook implementation.

Wait, I find I not yet fully test it. Don't merge it yet.

Can @SungFeng-Huang verify the modifications in upstream/mockingjay/model.py regarding "LayerNorm"?
I'm not very sure about that part. Many thanks!

OK I have tested the output representations with my trained downstream model. The inference scores look good.
Please let me if anything needed to be fix or the PR looks good to you :)


text:
use kube_name on namespace

fixes #36
just noticed there was this variable available and it's actually used on the other parts of the k8s deploy files

Yes, this is the variable that was made exactly to be used in k8s.


text:
is there any way to supoort distributed database ?

Our database TDSQL is an distributed database, it has multiple processes running for one database server, only a few processes provide client services, while others only provide computing services.  since the squrirrel now only collect the coverage info for one process, is there any way to support the multiple processes db testing?

Thanks for your interests in using Squirrel. (FYI, @zr950624 and I are maintaining Squirrel now at here). Squirrel doesn't care about how many processes are runing for the db server, as long as they are all instrumented for the code coverage. For the distributed setting, as long as you instrument the code so that it writes the coverage to a single bitmap, Squirrel should support it. However, that requires improving the instrumentation mechanism for AFL, which is out of the scope of Squirrel.

authors: Changochen showonlady


text:
Tslint with exportedConfig and lynt  have different output

Using tslint with the generated configuration with --exportConfig doesn't show all errors lynt shows
$ npx lynt --exportConfig

✔ tslint.json generated

$ npx lynt

/home/daniel/Documents/projects/ledd/scroll-utility/test/automate/index.ts
  43:15  Invalid 'await' of a non-Promise value.  await-promise

✖ 1 lynt error

$ npx tslint -p .
{ no output }
$

My lynt config in package.json:
  "lynt": {
    "typescript": true,
    "react": true,
    "rules": {
      "no-console": "on"
    }
  },

Weird, I'll look into it within ~2 days (Please feel free to ping me if I haven't said anything by then!). Thanks for reporting this.

I looked up the code, and I think the problem is with the --project options, in tslint/index.ts if project is not specified it uses "." as default, but with the exportConfig this is not applied, then in the tslint/config it checks for the project property. Maybe I'll throw a PR when I have more time

v0.5.4 published with your fix, thanks a bunch!

repo: saadq/lynt


text:
Submit button in AutoForm needs an option to set the submitButtonProps

I came across this issue when trying to set the icon

Thanks for the suggestion, this can be improved indeed.

repo: saas-js/saas-ui


text:
Improve assert_keys_eq and assert_keys_neq macros

These macros had some issues with using ErrorCodes, so I fixed them.
Also, the error codes now log in a similar way as this PR: https://github.com/project-serum/anchor/pull/969

LGTM 👍

authors: macalinao oliver-arrow

repo: saber-hq/vipers


text:
Make Chain.pricesProvider nullable

Summary
Chain.pricesProvider was defined as a non-nullable attribute in ChainSchema. But this attribute is optional in the Safe Config Service Chain model (ref: https://github.com/safe-global/safe-config-service/blob/ff74e49ab2e2846ff3d3479fb18eda0f5a1c7c6d/src/chains/models.py#L139)
Having this as optional makes sense as there might be use cases where token pricing is optional for a given blockchain or the Safe Infrastructure is not being deployed with fiat pricing enabled. So this PR makes that pricesProvider configuration also optional, targeting the alignment of the services.
Changes

Makes Chain.pricesProvider optional.
Modifies unit/controller tests accordingly.

Pull Request Test Coverage Report for Build 9768676345
Details

0 of 6 (0.0%)  changed or added relevant lines in 1 file are covered.
3 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.08%) to 48.501%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

src/datasources/balances-api/coingecko-api.service.ts
0
6
0.0%

Files with Coverage Reduction
New Missed Lines
%

src/datasources/transaction-api/transaction-api.manager.ts
1
90.32%

src/datasources/balances-api/coingecko-api.service.ts
1
22.39%

src/datasources/balances-api/balances-api.manager.ts
1
72.22%

Totals

Change from base Build 9763926440:
-0.08%

Covered Lines:
4213

Relevant Lines:
7001

💛  - Coveralls

authors: coveralls hectorgomezv

repo: safe-global/safe-client-gateway


text:
fix: move contract types to /src

This moves the autogenerated types into the /src directory to fix the service build. (Autodeploy was previously failing as the types were outside of the built dist.)

Pull Request Test Coverage Report for Build 4819545087

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-11.9%) to 82.216%

Totals

Change from base Build 4808279012:
-11.9%

Covered Lines:
491

Relevant Lines:
596

💛  - Coveralls

authors: coveralls iamacook

repo: safe-global/safe-gelato-relay-service


text:
Chore: fix the balances test

What this PR solves
Fixes the balances e2e test.
How does it solve it
The balances are sorted based on value, and USDC apparently depreciated relative to the other tokens in the test Safe.
Ideally we should find the correct row by the token symbol, not just by index. But for now I just fixed it by hardcoding the correct USDC row.

Pull Request Test Coverage Report for Build 2513898633

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 36.845%

Totals

Change from base Build 2513885263:
0.0%

Covered Lines:
3864

Relevant Lines:
9534

💛  - Coveralls

authors: coveralls katspaugh

repo: safe-global/safe-react