Add random.org support?

[iddm]

I know this crate is mostly for generating random values offline but it's name implies everything related to random. So I would like to propose to add randomorg crate as an optional feature which can be used with the rand's default interface.

[burdges]

We do not yet know how the redesign will support failable Rngs or if they'll support the associated error type required by anything network related, like say pulsar requires. I believe prevailing wisdom was that network randomness sources should only be used to partially contribute the seed used to initialize a PRNG anyways.

[dhardy]

I would think network-randomness sources should be in a separate crate in any case, because of dependencies and niche usage. So I don't see what this issue is for?

[pitdicker]

it's name implies everything related to random.

That is maybe a bit misleading. The discussion whether rand should be split up into multiple crates is still ongoing. But there seems to be agreement that rand should not include every source of randomness and every PRNG under the sun. Maybe not even any...

But rand and especially the new rand_core are designed to make crates with different sources of randomness integrate well. If you implement the Rng trait it will work together fine. And you maybe want to keep an eye on https://github.com/dhardy/rand. The redesign for the next version of rand is happening there, and the Rng trait becomes a bit simpler but needs more methods.

@vityafx Is this something you can work with for your randomorg crate?

[iddm]

@pitdicker Yes, I can try to do my best. I can try implement the Rng trait, though, I believe, it will also need to do some refactoring of the crate (it is not very-well thread-safe though it's rust interface is, it's mostly because of message id parameter of the random.org's API) but I think everything is possible. So, when I do this, what should I do next, making a PR to dhardy/rand with optional feature of my crate and some code which uses it when the feature is enabled?

[pitdicker]

I think you want to provide an interface somewhat like https://crates.io/crates/xoroshiro (a crate implementing Rng, picked somewhat randomly). Then a PR to Rand should not be necessary, it should just work when a library imports both your crate and Rand.

[iddm]

Looks nice to me. But how does it work, I mean this mechanism of Rust? Does something has weak symbols and they are is simply overridden by another crate? 2017-12-12 17:55 GMT+03:00 Paul Dicker <notifications@github.com>:

…

I think you want to provide an interface somewhat like https://crates.io/crates/xoroshiro (a crate implementing Rng, picked somewhat randomly). Then a PR to Rand should not be necessary, it should just work when a library imports both your crate and Rand. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#176 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABF-Aa3ENDywe_LBEr08uxaj111mKnRSks5s_pPOgaJpZM4P1bnG> .

-- Best, Victor Polevoy.

[dhardy]

You know about traits, right? You just do:

pub struct RandomOrg {
    // state, if you need any, goes here
}
impl RandomOrg for Rng {
    fn next_u32(&mut self) -> u32 ...
}

[iddm]

You probably meant

impl Rng for RandomOrg {
}

Yes, I know. I meant, how this will work with using only of the rand api.
Nevermind, I have found out :)

[iddm]

@pitdicker There is a problem. I have found that Rng trait requires 100% success of the generator (the signature of it's methods are exactly integers, not result type) but the RandomOrg crate can fail due to network inaccessibility or anything else.. Will there be a trait which allow generation failures?

[dhardy]

@vityafx fallible generators is something we've discussed a lot. See the "error" issues here and the rand-core RFC.

[pitdicker]

@vityafx With the links from @dhardy you have maybe found the try_fill method in the redesign, and the available error types and functions just below that? And ReseedingRng contains an example how these functions can be used to gracefully handle an error (if possible).

As there is not really a bug in rand here, do you agree this issue can be closed?
It is okay to mention me from an issue in your repro if necessary.

[iddm]

Yes, I agree. Thank you. Gonna try to implement everything what is needed as soon as I will have time.

[iddm]

@pitdicker Still don't fully understand, how can I implement failable Rng? The try_fill method is the only way of using a "failable" generators? I thought the Rng trait will be splitted into 2 versions: normal and failable with, for example:

fn next_u32(&mut self) -> Result<u32, Error>;