Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 22 01:17
    cuviper labeled #719
  • Jan 22 01:17
    cuviper labeled #719
  • Jan 21 17:43
    ian-p-cooke opened #719
  • 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)

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?
I am usually very conservative about rustc requirements on crates I maintain
but we decided to limit that to about a year old for rayon: https://github.com/rayon-rs/rfcs/blob/master/accepted/rfc0003-minimum-rustc.md
another workaround is to directly require rayon-core = "~1.4" in your own Cargo.toml
to pair with rayon = "~1.0", since 1.1 is the version that needs newer rayon-core too
(~ restricts the minor version too, compared to normal semver policy)
jq-rs
@jq-rs
@cuviper Thanks for the info! The problem is that even if our master has new Rust compiler, the maintenance branches (which may be several years older) do not have it and it won't be upgraded there. So I would be very conservative about changing requirements for old crate versions on the fly. If possible, such requirements should be done for new crate versions only. Here I was expecting that rayon = "~1.0" would not update to rayon-core > 1.4, which needs newer compiler.
jq-rs
@jq-rs
BTW, https://github.com/rayon-rs/rfcs/blob/master/accepted/rfc0003-minimum-rustc.md is very good. To me it looks like "Increases to our minimum supported Rust will also require a new minor release in the semantic version of rayon crates, not just a patch release" means that this is just a glitch here and in the future it should work.
Josh Stone
@cuviper
unfortunately, even with rayon = "~1.0", cargo will still greedily choose the newest compatible rayon-core, and 1.5 is compatible with 1.4