Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 04 05:04
    dbregman opened #718
  • Dec 23 2019 14:51
    bors[bot] closed #717
  • Dec 23 2019 14:51

    bors[bot] on master

    Change wording, less "High leve… Merge #717 717: Change wording… (compare)

  • Dec 23 2019 14:33

    bors[bot] on staging.tmp

    (compare)

  • Dec 23 2019 14:33

    bors[bot] on staging

    Change wording, less "High leve… Merge #717 717: Change wording… (compare)

  • Dec 23 2019 14:33

    bors[bot] on staging.tmp

    Change wording, less "High leve… [ci skip][skip ci][skip netlify… (compare)

  • Dec 23 2019 14:33

    bors[bot] on staging.tmp

    [ci skip][skip ci][skip netlify] (compare)

  • Dec 22 2019 11:35
    matthiasbeyer opened #717
  • Dec 22 2019 00:58
    cuviper closed #697
  • Dec 22 2019 00:57
    cuviper closed #698
  • Dec 22 2019 00:54

    cuviper on v1.3.0

    (compare)

  • Dec 22 2019 00:54

    cuviper on rayon-core-v1.7.0

    (compare)

  • Dec 22 2019 00:54

    cuviper on rayon-futures-v0.1.1

    (compare)

  • Dec 21 2019 15:59
    bors[bot] closed #716
  • Dec 21 2019 15:59

    bors[bot] on master

    Remove rayon-futures Remove cfg(rayon_unstable) Update ci/compat-Cargo.lock and 7 more (compare)

  • Dec 21 2019 15:20

    bors[bot] on staging.tmp

    (compare)

  • Dec 21 2019 15:20

    bors[bot] on staging

    Remove rayon-futures Remove cfg(rayon_unstable) Update ci/compat-Cargo.lock and 7 more (compare)

  • Dec 21 2019 15:20

    bors[bot] on staging.tmp

    Remove rayon-futures Remove cfg(rayon_unstable) Update ci/compat-Cargo.lock and 7 more (compare)

  • Dec 21 2019 15:20

    bors[bot] on staging.tmp

    [ci skip][skip ci][skip netlify] (compare)

  • Dec 21 2019 15:20
    bors[bot] closed #715
Niko Matsakis
@nikomatsakis
not sure!
well
yeah I'm not sure what that is measuring
I could investigate
one last thing -- there was this rayon-logs "pre-rfc"
I started skimming it but didn't get too far
Josh Stone
@cuviper
yeah, it's in my inbox
email is a cumbersome format for this
Niko Matsakis
@nikomatsakis
indeed
I think we should encourage him to open it
Josh Stone
@cuviper
:thumbsup:
Niko Matsakis
@nikomatsakis
btw
aturon has been helping to move the parallel compiler work ahead (as you prob saw)
and I'm trying to drag him a bit into these meetings too :)
though he didn't show today, I'll have to berate him ;)
Josh Stone
@cuviper
heh, ok
Niko Matsakis
@nikomatsakis
in particular I want him to help reconcile rust-rayon and normal rayon eventually
Josh Stone
@cuviper
let me know if I need to knock on his door directly
(not that I know exactly where he lives, but we're both PDXish)
:)
on reconciling, at least first we can rebase to my PR rust-lang/rustc-rayon#3
Niko Matsakis
@nikomatsakis
@cuviper btw I'm going to be on PTO for about a month as of next week
Josh Stone
@cuviper
@nikomatsakis ok -- any rayon wishes before you go?
deanmiller
@deanmiller
Hello, I am new to Rust and in the process of exploring libraries. My question is does Rayon currently support or plan to support parallelism (Treads) in WebAssembly in the future? thank you
*Threads^
Josh Stone
@cuviper
@deanmiller it's a bit awkward since wasm doesn't support the normal std::thread APIs
however, we added custom spawn support recently, and you can see it in use here: https://github.com/rustwasm/wasm-bindgen/tree/master/examples/raytrace-parallel
(although github appears to be down at the moment)
Sunjay Varma
@sunjay
What's the best way to just quit the program when a panic occurs?
I was thinking of defining a panic_handler that calls process::exit(1)
But I want to make sure I don't lose any of the panic info (still want the messages printed)
Is this the right way to do it?
Josh Stone
@cuviper
If no panic handler is set, the default is to abort the process, under the principle that panics should not go unobserved.
@sunjay isn't that already what you're asking for?
although rayon's panic handler really only applies to spawns -- other stuff, we just propagate panics to the caller
Sunjay Varma
@sunjay
I'm experiencing the behaviour described here: rayon-rs/rayon#638
I'd like to immediately quit completely as soon as any panic occurs, not wait for all the workers to finish
Hence why I want to use process::exit(1) since that would immediately quit everything
Josh Stone
@cuviper
ah, there's now panic_fuse() for that too
Sunjay Varma
@sunjay
I'm just not sure how to write a panic_handler and I don't see any examples that do anything with the closure parameter :)
Josh Stone
@cuviper
or if you want a global setting, you can set panic=abort in Cargo.toml
Sunjay Varma
@sunjay
Oh awesome! I didn't see panic_fuse
I will use that
Thanks!
:smile:
jq-rs
@jq-rs
Hello. FYI, seems that even with semver system, builds with older compiler are broken with old rayon crates. Thus, rayon compilation will fail on old systems as follows:
Compiling crossbeam-utils v0.6.6 error: 128-bit type is unstable (see issue #35118) | 533 | impl_arithmetic!(u128, "let a = AtomicCell::new(7u128);"); | ^^^^
I am currently looking for a workaround, let me know if you have one already.
Having the .lock file available is one, which I don't have in this case :b
jq-rs
@jq-rs
The workaround is to give command:
cargo update -p rayon-core --precise 1.4.1
Josh Stone
@cuviper
@jq-rs what old system are you running, where you don't have at least Rust 1.26?