<pgiarrusso>
splittable PRNG, like what you need for concurrent Monte Carlo simulations? I can see why you’d want it for multithreaded tests…
<pgiarrusso>
IIRC, the alternatives require either locks on the PRNG, or might make the PRNG on different threads not independent
<companion_cube>
it's also useful for property based testing
<Corbin>
It can be useful even when the generation/simulation is single-threaded but the order of work units is non-deterministic; making the RNG split so that each work unit gets the right RNG seed means that the output will look smooth in any direction.
Sankalp has quit [Ping timeout: 276 seconds]
Sankalp has joined #ocaml
szkl has joined #ocaml
bobo_ has joined #ocaml
spip has quit [Ping timeout: 258 seconds]
rgrinberg has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
adanwan has quit [Remote host closed the connection]
adanwan has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
Haudegen has joined #ocaml
trev_ has joined #ocaml
trev_ has quit [Quit: trev_]
trev_ has joined #ocaml
trev_ is now known as trev
trev has quit [Changing host]
trev has joined #ocaml
gravicappa has joined #ocaml
Serpent7776 has joined #ocaml
amk has quit [Ping timeout: 250 seconds]
amk has joined #ocaml
amk has quit [Ping timeout: 240 seconds]
amk has joined #ocaml
amk has quit [Read error: Connection reset by peer]
azimut has quit [Ping timeout: 240 seconds]
azimut has joined #ocaml
amk has joined #ocaml
aspe has joined #ocaml
asm has joined #ocaml
asm has quit [Changing host]
Putonlalla1 is now known as Putonlalla
aspe has quit [Quit: aspe]
aspe has joined #ocaml
aspe has quit [Quit: aspe]
aspe has joined #ocaml
olle has joined #ocaml
<d_bot>
<Bluddy> continuing deterministic work after saving state would really benefit from a serialized RNG
<d_bot>
<Bluddy> companion_cube: CCRandom forces handling of the random state, but if you want to integrate it into your application state data structure, you have no easy option of serializing/deserializing it other than Marshal.
<d_bot>
<Bluddy> hmm... unless I got confused
<d_bot>
<Bluddy> ok my bad - for some reason I thought CCRandom forced handling the Random.State
bartholin has joined #ocaml
adanwan has quit [Remote host closed the connection]
adanwan has joined #ocaml
kaustuv has joined #ocaml
<kaustuv>
Dune question: I have a program 'x2y' that convers any file of the form 'file.x' into 'file.y'. I have a directory tree 'd' that has many such .x files at various levels in the tree. How can I use dune to make the corresponding .y files?
azimut has quit [Ping timeout: 240 seconds]
azimut has joined #ocaml
wingsorc has quit [Quit: Leaving]
Serpent7776 has quit [Read error: Connection reset by peer]
dextaa has joined #ocaml
Serpent7776 has joined #ocaml
azimut has quit [Ping timeout: 240 seconds]
Haudegen has quit [Quit: Bin weg.]
aspe has quit [Quit: aspe]
rgrinberg has joined #ocaml
omegatron has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<Et7f3 (@me on reply)> y=ml ?
troydm1 has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
troydm has joined #ocaml
<zozozo>
kaustuv: from what I know, you cannot yet have custom generic rules in dune files, so to do that with dune, you'd need to write a dune file that contains a rule stanza for each of the files to convert
<zozozo>
but, you can potentially generate automatically such a dune file before calling dune
<d_bot>
<Et7f3 (@me on reply)> if y=ml you could abuse formating stanza.
<kaustuv>
zozozo: OK, thanks. That's what I've been implementing this morning after failing to find anything in the dune docs.
<zozozo>
it's a known limitation of dune currently
<zozozo>
I do the same (generate *a lot* of dune files) for tests in one of my projects
kaustuv has quit [Remote host closed the connection]
<vsiles>
zozozo: for this .x -> .y translation, I'd probably write a Makefile/script and call that from dune. Or generate the dune file using the tuareg/ml mode of dune files
rgrinberg has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<geoff> A rule that generates dune files in each of the sub directories with a rule that does the conversion with a `*.x` glob deps? An ocaml script might be needed to find the subdirectories in need of the dune files though, I don't remember seeing a way to crawl sub directories solely with user actions. I feel like you should be able to have dune orchestrate it though (without having to run anything separate before invoking dune)
malc has left #ocaml [ERC (IRC client for Emacs 28.0.50)]
trev has joined #ocaml
gdd has quit [Ping timeout: 272 seconds]
<sim642>
Would it be possible to make domains stubs for 4.14, which would just do things sequentially?
<sim642>
Might be neat to have a single project that can parallelize on 5.0, but stay sequential on <5.0, without lots of conditional compilation trickery to make it happen
<companion_cube>
or, not sequentially, but just use regular threads… that'd be useful
<olle>
zozozo: hm
<zozozo>
companion_cube: I think the threads API is still there in 5.0 , and has the same semantics as before (or at least that was the case at some point)
<companion_cube>
yeah but that's not the point :)
<companion_cube>
if you can use the Domain API on < 5.0, it means you can write code that works well on 5.0, and no worse than before on < 5.0
<companion_cube>
if you use threads, it'll still suck on 5.0
<olle>
What's that, domains?
<olle>
Some memory concept?
<companion_cube>
well, not suck, but just be monocore
<sim642>
DLS might be a problem, not sure if the threads API has anything similar
<companion_cube>
not really, alas
<companion_cube>
you can use a sort of map from `Thread.id` to things
<zozozo>
companion_cube: ah, right
aspe has joined #ocaml
<sim642>
companion_cube, true
<octachron>
There is also the issue that before 4.13 a thread might never yield if it is stuck in a non-allocating loop.
<zozozo>
companion_cube: I guess the best you could do is lwt/async-like lib whose backend changes between 4.14 and 5.0 ?
<d_bot>
<anmonteiro> Olle: domains are the fundamental multicore abstraction in OCaml
<d_bot>
<anmonteiro> I think there’s a version of lwt_preemptive that uses domains
<zozozo>
Maybe dbunzli will write one such lib (one can hope, :p )
<companion_cube>
you could have a lwt pool that either uses threads, or the new lwt-domains, yeah
aspe has quit [Remote host closed the connection]
aspe has joined #ocaml
aspe has quit [Client Quit]
aspe has joined #ocaml
<companion_cube>
dbunzli tires me, zozozo, so I hope not :p
<zozozo>
companion_cube: ah, there's that, indeed. Luckily for me, I've yet to have any problem with any of his libraries
<companion_cube>
it's more that he's always opposed to any change I want to make to the stdlib :p
<sim642>
Aww, I tried the most naive Domain as Thread stubbing on 4.14 and randomly picked pingping.ml from the Domain test suite. Gets stuck in a busyloop without sprinkling Thread.yield
<sim642>
Or maybe that's just a particularly evil example requiring fairness
<octachron>
companion_cube, sorry about that, I was thinking of Random.state serialization when I said that adoption in the stdlib would be very likely. (And I had forgotten the history of to_hex).
trev has quit [Remote host closed the connection]
<companion_cube>
heh, it's fine
<companion_cube>
otoh the stdlib doesn't have any blessed serialization format, so how would that work?
<sim642>
Blessed by Marshal obviously
<companion_cube>
:D well you can already do that, right?
<octachron>
you could serialize the state to an hexadecimal string
<companion_cube>
that's not general enough!
<companion_cube>
to any char transducer
<d_bot>
<dinosaure> `of_hex`/`to_hex` will be useful, `ocaml-hex` is a nightmare
<d_bot>
<dinosaure> but I prefer `base64` to serialize random state :p
<companion_cube>
sure, it's also a lot more complicated and requires choices (alphabet, padding, etc.)
<companion_cube>
for something like a hash, hex is largely sufficient
<companion_cube>
(like what, err, git does?)
<sadiq_>
sim642, that would be an interesting example if it gets stuck. Do you have a link to it somewhere public?
sadiq_ is now known as sadiq
<sadiq>
the compiler actually generates polling points in loops and other places to ensure we don't get stuck.
azimut has joined #ocaml
<companion_cube>
is the impact on sequential code of _that_ well evaluated?
<sadiq>
oh right. Sorry, I read it the other way around and thought you'd subbed Domain for Thread.
gravicappa has quit [Ping timeout: 246 seconds]
aspe has quit [Ping timeout: 246 seconds]
<sim642>
Why don't the safepoints help for pingping with Thread though?
<sadiq>
that I was pondering.
<sadiq>
yea, I'm not sure.
aspe has joined #ocaml
<sadiq>
might be worthy of an issue? As far as I can see the tick thread ends up setting the young limit correctly and that should trigger preemption at the next poll point.
<sim642>
Under gdb the two threads do alternate hitting st_thread_yield, so maybe something else is going on
<octachron>
The test does work ... slowly. Changing the limit to 100 gives me a runtime of 5 seconds.
<sim642>
I just realized the same. Adding Thread.yield-s after the put-s makes it run in 0.3s
<sim642>
So I guess it's fine, but just has terrible scheduling