std: Recreate a `rand` module #14427

alexcrichton · 2014-05-25T20:50:24Z

This commit shuffles around some of the rand code, along with some
reorganization. The new state of the world is as follows:

The librand crate now only depends on libcore. This interface is experimental.
The standard library has a new module, std::rand. This interface will
eventually become stable.

Unfortunately, this entailed more of a breaking change than just shuffling some
names around. The following breaking changes were made to the rand library:

Rng::gen_vec() was removed. This has been replaced with Rng::gen_iter() which
will return an infinite stream of random values. Previous behavior can be
regained with rng.gen_iter().take(n).collect()
Rng::gen_ascii_str() was removed. This has been replaced with
Rng::gen_ascii_chars() which will return an infinite stream of random ascii
characters. Similarly to gen_iter(), previous behavior can be emulated with
rng.gen_ascii_chars().take(n).collect()
{IsaacRng, Isaac64Rng, XorShiftRng}::new() have all been removed. These all
relied on being able to use an OSRng for seeding, but this is no longer
available in librand (where these types are defined). To retain the same
functionality, these types now implement the Rand trait so they can be
generated with a random seed from another random number generator. This allows
the stdlib to use an OSRng to create seeded instances of these RNGs.
Rand implementations for Box<T> and @T were removed. These seemed to be
pretty rare in the codebase, and it allows for libcore to not depend on
liballoc. Additionally, other pointer types like Rc and Arc were not
supported. If this is undesirable, librand can depend on liballoc and regain
these implementations.
The WeightedChoice structure is no longer built with a Vec<Weighted<T>>,
but rather a &mut [Weighted<T>]. This means that the WeightedChoice
structure now has a lifetime associated with it.

cc #13851

[breaking-change]

huonw · 2014-05-25T21:32:23Z

cc me

huonw · 2014-05-26T08:32:24Z

Rand implementations for Box and @t were removed. These seemed to be
pretty rare in the codebase, and it allows for libcore to not depend on
liballoc. Additionally, other pointer types like Rc and Arc were not
supported. If this is undesirable, librand can depend on liballoc and regain
these implementations.

Presumably you mean "allow librand to not depend on liballoc"? Also I think these impls are cute and useful when you need them, but I don't think they're worth having around for now. (I.e. not depending from liballoc is good: can always change in future if the sugar is just too sweet to miss.)

huonw · 2014-05-26T09:36:39Z

src/librand/distributions/mod.rs

@@ -20,8 +20,10 @@ that do not need to record state.



Could you mark this module #[unstable] (or even #[experimental])?

That is, I don't think this is necessarily the best fit for being under std at the moment.

The whole crate is currently marked #![experimental] (although the lint attributes aren't working well enough to pick that up). Do you think I should mark this module as having a stability level with a specific message?

It is being reexported as std::rand::distributions, i.e. the normal path to access it is not experimental. I want the reexported std::rand::distributions to be experimental, and I don't really know how we're expecting stability levels to interact with reexported items.

alexcrichton · 2014-05-27T05:20:15Z

Updated with comments.

huonw · 2014-05-28T01:02:38Z

src/libstd/rand/mod.rs

+    /// propagated via the `IoResult` return value.
+    pub fn new() -> IoResult<StdRng> {
+        OSRng::new().map(|mut r| {
+            let mut ret = IsaacWordRng::new_unseeded();


This should be from_rng now?

brson · 2014-05-28T01:08:34Z

I removed my r+ since it appears @huonw is still reviewing.

brson · 2014-05-28T01:11:38Z

Does this leave a way to seed RNG's with a known value, or does it require seeding from another RNG?

alexcrichton · 2014-05-28T01:28:46Z

Yes, SeedableRng::from_seed can be used if you have a known seed.

alexcrichton · 2014-05-28T01:28:56Z

Updated with @huonw's comments.

huonw · 2014-05-28T13:25:26Z

src/librand/lib.rs

    /// ```
-    fn gen_vec<T: Rand>(&mut self, len: uint) -> Vec<T> {


It's mildly annoying that these can't be #[deprecated] like other types, but there's not much we can do about it without larger changes...

huonw · 2014-05-28T13:27:56Z

r=me with a rebase and the two minor doc comments.

alexcrichton · 2014-05-28T15:33:32Z

I went ahead an implemented Rand for the RNG types, I find it a cleaner solution than adding two new methods to SeedableRng which don't have much to do with the Seed type parameter.

huonw · 2014-05-29T11:28:26Z

src/libstd/rand/mod.rs

+    /// Reading the randomness from the OS may fail, and any error is
+    /// propagated via the `IoResult` return value.
+    pub fn new() -> IoResult<StdRng> {
+        OSRng::new().map(|mut r| StdRng { rng: r.gen() })


Heh, this Rand impl is just so magical. :)

This commit shuffles around some of the `rand` code, along with some reorganization. The new state of the world is as follows: * The librand crate now only depends on libcore. This interface is experimental. * The standard library has a new module, `std::rand`. This interface will eventually become stable. Unfortunately, this entailed more of a breaking change than just shuffling some names around. The following breaking changes were made to the rand library: * Rng::gen_vec() was removed. This has been replaced with Rng::gen_iter() which will return an infinite stream of random values. Previous behavior can be regained with `rng.gen_iter().take(n).collect()` * Rng::gen_ascii_str() was removed. This has been replaced with Rng::gen_ascii_chars() which will return an infinite stream of random ascii characters. Similarly to gen_iter(), previous behavior can be emulated with `rng.gen_ascii_chars().take(n).collect()` * {IsaacRng, Isaac64Rng, XorShiftRng}::new() have all been removed. These all relied on being able to use an OSRng for seeding, but this is no longer available in librand (where these types are defined). To retain the same functionality, these types now implement the `Rand` trait so they can be generated with a random seed from another random number generator. This allows the stdlib to use an OSRng to create seeded instances of these RNGs. * Rand implementations for `Box<T>` and `@T` were removed. These seemed to be pretty rare in the codebase, and it allows for librand to not depend on liballoc. Additionally, other pointer types like Rc<T> and Arc<T> were not supported. If this is undesirable, librand can depend on liballoc and regain these implementations. * The WeightedChoice structure is no longer built with a `Vec<Weighted<T>>`, but rather a `&mut [Weighted<T>]`. This means that the WeightedChoice structure now has a lifetime associated with it. * The `sample` method on `Rng` has been moved to a top-level function in the `rand` module due to its dependence on `Vec`. cc rust-lang#13851 [breaking-change]

This commit shuffles around some of the `rand` code, along with some reorganization. The new state of the world is as follows: * The librand crate now only depends on libcore. This interface is experimental. * The standard library has a new module, `std::rand`. This interface will eventually become stable. Unfortunately, this entailed more of a breaking change than just shuffling some names around. The following breaking changes were made to the rand library: * Rng::gen_vec() was removed. This has been replaced with Rng::gen_iter() which will return an infinite stream of random values. Previous behavior can be regained with `rng.gen_iter().take(n).collect()` * Rng::gen_ascii_str() was removed. This has been replaced with Rng::gen_ascii_chars() which will return an infinite stream of random ascii characters. Similarly to gen_iter(), previous behavior can be emulated with `rng.gen_ascii_chars().take(n).collect()` * {IsaacRng, Isaac64Rng, XorShiftRng}::new() have all been removed. These all relied on being able to use an OSRng for seeding, but this is no longer available in librand (where these types are defined). To retain the same functionality, these types now implement the `Rand` trait so they can be generated with a random seed from another random number generator. This allows the stdlib to use an OSRng to create seeded instances of these RNGs. * Rand implementations for `Box<T>` and `@T` were removed. These seemed to be pretty rare in the codebase, and it allows for libcore to not depend on liballoc. Additionally, other pointer types like Rc<T> and Arc<T> were not supported. If this is undesirable, librand can depend on liballoc and regain these implementations. * The WeightedChoice structure is no longer built with a `Vec<Weighted<T>>`, but rather a `&mut [Weighted<T>]`. This means that the WeightedChoice structure now has a lifetime associated with it. cc #13851 [breaking-change]

…ent-workspaces-to-have-proc-macros, r=Veykril fix: allow new, subsequent `rust-project.json`-based workspaces to get proc macro expansion As detailed in rust-lang/rust-analyzer#14417 (comment), `rust-project.json` workspaces added after the initial `rust-project.json`-based workspace was already indexed by rust-analyzer would not receive procedural macro expansion despite `config.expand_proc_macros` returning true. To fix this issue: 1. I changed `reload.rs` to check which workspaces are newly added. 2. Spawned new procedural macro expansion servers based on the _new_ workspaces. 1. This is to prevent spawning duplicate procedural macro expansion servers for already existing workspaces. While the overall memory usage of duplicate procedural macro servers is minimal, this is more about the _principle_ of not leaking processes 😅. 3. Launched procedural macro expansion if any workspaces are `rust-project.json`-based _or_ `same_workspaces` is true. `same_workspaces` being true (and reachable) indicates that that build scripts have finished building (in Cargo-based projects), while the build scripts in `rust-project.json`-based projects have _already been built_ by the build system that produced the `rust-project.json`. I couldn't really think of structuring this code in a better way without engaging with rust-lang/rust-analyzer#7444.

huonw reviewed May 26, 2014
View reviewed changes

huonw reviewed May 28, 2014
View reviewed changes

huonw reviewed May 29, 2014
View reviewed changes

bors closed this May 30, 2014

bors merged commit 925ff65 into rust-lang:master May 30, 2014

alexcrichton deleted the librand branch May 30, 2014 05:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

std: Recreate a `rand` module #14427

std: Recreate a `rand` module #14427

alexcrichton commented May 25, 2014

huonw commented May 25, 2014

huonw commented May 26, 2014

huonw May 26, 2014

alexcrichton May 27, 2014

huonw May 27, 2014

alexcrichton commented May 27, 2014

huonw May 28, 2014

brson commented May 28, 2014

brson commented May 28, 2014

alexcrichton commented May 28, 2014

alexcrichton commented May 28, 2014

huonw May 28, 2014

huonw commented May 28, 2014

alexcrichton commented May 28, 2014

huonw May 29, 2014

		/// ```
		fn gen_vec<T: Rand>(&mut self, len: uint) -> Vec<T> {

std: Recreate a rand module #14427

std: Recreate a rand module #14427

Conversation

alexcrichton commented May 25, 2014

huonw commented May 25, 2014

huonw commented May 26, 2014

huonw May 26, 2014

Choose a reason for hiding this comment

alexcrichton May 27, 2014

Choose a reason for hiding this comment

huonw May 27, 2014

Choose a reason for hiding this comment

alexcrichton commented May 27, 2014

huonw May 28, 2014

Choose a reason for hiding this comment

brson commented May 28, 2014

brson commented May 28, 2014

alexcrichton commented May 28, 2014

alexcrichton commented May 28, 2014

huonw May 28, 2014

Choose a reason for hiding this comment

huonw commented May 28, 2014

alexcrichton commented May 28, 2014

huonw May 29, 2014

Choose a reason for hiding this comment

std: Recreate a `rand` module #14427

std: Recreate a `rand` module #14427