:gift_heart: New library! Pseudo-random number generators: https://github.com/JanCVanB/roc-random
This is only a v0.1 release, with minimally-usable implementations of 8/16/32-bit PCG-RXS-M-XS. I intend to make its API more ergonomic in v0.2, so I'd love to hear how you think v0.1 feels to use! :smile:
I put example.roc
and Random.roc
in examples/cli
(commit 2cbac921f), executed cargo run examples/cli/example.roc
and got:
thread '<unnamed>' panicked at 'Found unbound type variables {102}
in type alias `Random.Seed8` [] : [ Global('Seed8') (Alias `Num.U8`[ but actually (Alias `Num.Num` (Alias `Num.Integer` (Alias `Num.Unsigned8`[ but actually [ Private(`Num.@Unsigned8`) ] ])[ but actually [ Private(`Num.@Integer`) (Alias `Num.Unsigned8`[ but actually [ Private(`Num.@Unsigned8`) ] ]) ] ])[ but actually [ Private(`Num.@Num`) (Alias `Num.Integer` (Alias `Num.Unsigned8`[ but actually [ Private(`Num.@Unsigned8`) ] ])[ but actually [ Private(`Num.@Integer`) (Alias `Num.Unsigned8`[ but actually [ Private(`Num.@Unsigned8`) ] ]) ] ]) ] ]) ]) ]<102>', compiler/can/src/scope.rs:192:17
Did you happen to come across this error before @JanCVanB?
:thinking: I haven't. That's a lot of but actually
lol
I just tested cargo run examples/cli/example.roc
for the first time (I usually build roc
for release and run it with that executable), and I get the same error message that you did. Investigating!
Yes, building for release (cargo build --release
) and using that executable (./target/release/roc examples/cli/example.roc
) seems to work.
Does anyone know if there is a difference between roc foo.roc
and cargo run foo.roc
?
Whoa! This might be the culprit, does cargo run
use a dev/debug runner by default?
[nix-shell:~/code/clones/roc/examples/cli]$ cargo run example.roc
Finished dev [unoptimized + debuginfo] target(s) in 0.29s
Running `/Users/jan/code/clones/roc/target/debug/roc example.roc`
...
Okay, I have a solution for you @Anton , just use the release build/runner/option/thing! cargo run --release examples/cli/example.roc
:smile:
eh, what?
but really, the presence of the --release
flag matters for whether the compiler hits a panic or produces a working executable?
It seems yes, is that bad?
[nix-shell:~/code/clones/roc]$ cargo run examples/cli/example.roc
Finished dev [unoptimized + debuginfo] target(s) in 0.28s
Running `target/debug/roc examples/cli/example.roc`
thread '<unnamed>' panicked at 'Found unbound type variables {102}
in type alias `Random.Seed8` [] : [ Global('Seed8') (Alias `Num.U8`[ but actually (Alias `Num.Num` (Alias `Num.Integer` (Alias `Num.Unsigned8`[ but actually [ Private(`Num.@Unsigned8`) ] ])[ but actually [ Private(`Num.@Integer`) (Alias `Num.Unsigned8`[ but actually [ Private(`Num.@Unsigned8`) ] ]) ] ])[ but actually [ Private(`Num.@Num`) (Alias `Num.Integer` (Alias `Num.Unsigned8`[ but actually [ Private(`Num.@Unsigned8`) ] ])[ but actually [ Private(`Num.@Integer`) (Alias `Num.Unsigned8`[ but actually [ Private(`Num.@Unsigned8`) ] ]) ] ]) ] ]) ]) ]<102>', compiler/can/src/scope.rs:192:17
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
^C
[nix-shell:~/code/clones/roc]$ cargo run --release examples/cli/example.roc
Finished release [optimized] target(s) in 0.29s
Running `target/release/roc examples/cli/example.roc`
🔨 Rebuilding host... Done!
a: 18
b: 18
c: 15
d: 15
e: 17
f: 17
g: 14
h: 14
i: 12
j: 12
k: 19
l: 19
:)
[nix-shell:~/code/clones/roc]$
Context: This is for roc-random's example module (and the Random.roc library interface) copied (and only modified so that the platform path is correct) into the Roc repo's examples/cli/
dir.
oh, ah, no it's fine given that specific error
Can I improve the library to not fail in that way, or is it a temporary problem with the dev/debug runner?
my guess is you're using closures a bunch
and that is hitting this code path
the check that fails is (clearly) not needed for producing programs, but usually when it fails something is wrong
you can safely comment it locally though
Thanks, I'd love to know more! What part should I comment(-out?), and which part of the code is a closure? Something related to Seed8
?
oh no the assert that makes it fail
Ah, I guess what I'm actually asking is this: What can I do as a library author to prevent its users from experiencing this compiler panic when using the library with cargo run
without --release
?
oh, nothing I think
this is one of those "something we believed was true turned out not to be, so crash" assertions
we want it to be noisy so we can investigate it and ideally solve the cause rather than the symptom
but we skip those checks altogether in release builds, so on the one hand we don't get the feedback but on the other hand it might happen to work anyway (as it seems to here) despite our assumption being broken :big_smile:
oh, no this is something that should be true but we have slipped up
it's just that usually the effect is not noticable
Is cargo run
designed for compiler debugging, app debugging, or app execution?
mostly speed
it compiles faster
also you get more info if something panics, or if you use a debugger
Cool, so then as a library author I'll test to both (release and nonrelease) and report issues with either?
well that should not be necessary
we'll get this sorted out now that we have an example that actually fails the assert
High five for the co-discovery, @Anton ! :high_five:️
One last thing, the roc docs
website generator is lovely: https://jancvanb.github.io/roc-random/
that's pretty stuff :D
Last updated: Jul 06 2025 at 12:14 UTC