rust-rayon-deb

Fork

Build rayon-demo on stable too

Merge branch 'master' into stable-tests

Forked the octillion test with `Range<u128>` vs. `flat_map` iterators.
The `cfg(nightly)` is no longer needed with stable Rust 1.26, as we only
used `i128` and `impl Trait` that are now stable.

Merge #571

571: Implement our own PRNG for rayon-core r=nikomatsakis a=cuviper

Our need for randomness is very simple, just to spread the work-stealing
somewhat equally across all possible victims. Rather than worrying
about compatibility and updates to the `rand` crate, we now implement a
simple `xorshift*` generator for this. We keep `rand` only as a dev-
dependency for testing purposes.

Closes #570.

Co-authored-by: Josh Stone <cuviper@gmail.com>

Seed the PRNG with a hashed counter

Merge #575

575: u128 and i128 ranges r=cuviper a=paulkernfeld

This is an attempt at #573. I don't have experience with functionality that is conditional on the version of rustc, so I apologize if this PR is completely bonkers. I went with a feature flag in this case, but I would be happy to reimplement this using an alternative method.

Co-authored-by: Paul Kernfeld <paulkernfeld@gmail.com>
Co-authored-by: Josh Stone <cuviper@gmail.com>

tweak macro spacing

Avoid long literals

Use build.rs instead of feature flag, fix len()

Merge #560

560: Parity with std::str iterators r=nikomatsakis a=cuviper

This mimics the rest of the iterators in `std::str` with methods on the
`ParallelString` trait.

Closes #559, as `par_char_indices` is the closest we can do for that.

Co-authored-by: Josh Stone <cuviper@gmail.com>

update docs for ParallelBridge and IterParallel

Build with range128, only on nightly

Don't enable range128 in CI

Use --features range128 instead of --all-features

u128 and i128 ranges

rename AsParallel to ParallelBridge

Implement our own PRNG for rayon-core

Our need for randomness is very simple, just to spread the work-stealing
somewhat equally across all possible victims. Rather than worrying
about compatibility and updates to the `rand` crate, we now implement a
simple `xorshift*` generator for this. We keep `rand` only as a dev-
dependency for testing purposes.

Merge #568

568: link to par_sort resolves r=cuviper a=AndyGauge

I found a dead link.

Co-authored-by: Andy Gauge <andygauge@gmail.com>

link to par_sort across multiple crates

Merge #564

564: inherent mutability -> interior mutability r=cuviper a=MajorBreakfast

It's called "interior" mutability not "inherent" mutability.

Old PR of mine that already fixed this once 😄 https://github.com/rayon-rs/rayon/pull/458

Section in the book https://doc.rust-lang.org/book/second-edition/ch15-05-interior-mutability.html

Co-authored-by: Josef Brandl <mail@josefbrandl.de>

inherent mutability -> interior mutability

Slightly simplify find_char_midpoint

Make string splitting more uniform

Don't split UTF-8 across threads in str::Bytes

Merge pull request #561 from cuviper/ci-rand-0.3

Try another approach to hacking rand in CI

add game of life benchmark

Try another approach to hacking rand in CI

Using `sed` to hack rand-0.3.20 in `Cargo.lock` worked for a while, but
now it's giving us an invalid lockfile, because some of the test/demo
dependencies need rand-0.4 themselves.

Instead, we now just tweak `rayon-core/Cargo.toml` long enough to
generate a complete lock file, which is enough to get a working CI build
on Rust 1.13 again.

make a version of nbody that uses `as_parallel`

use as_parallel

rustfmt nbody.rs

Fix struct field init for 1.13 compat