00:04 <darchitect> yeah I work as a ML Engineer and am not really impressed with LLMs, that's y I came here to see if anyone get me excited about the progress... In my mind reasoning is search... search through the possible programs that optimize a goal and fit a tiven type. We don't have anything close yet ... at least not to my knowledge

00:04 <darchitect> given *

00:34 <neiluj> hi

00:36 <neiluj> got this monad https://bpa.st/NKTA for stack memory management (ltop is the stack pointer at a point of time, gerepilecopy cleans the stack from ltop to stack pointer and returns the given variable), but would like to postpone the gerepilecopy call to the end of the computation

00:36 <neiluj> is there an easy way to do so?

00:37 <neiluj> there's this alternative way https://bpa.st/3UUA also (without monad)

17:54 <discocaml> <akashi_the_mechanic> Is it expected that alcotest doesn't print anything if I run `dune test` again after a successful test run? I noticed that I need to run `dune clean` before running `dune test` again for alcotest to print the result after a successful test run.

17:56 <hannes> akashi_the_mechanic: you can also use "dune runtest --force" instead of a clean

18:09 <discocaml> <akashi_the_mechanic> Thanks, it works. Still wierd decision imo. When people see nothing on the screen, they might assume somethings go wrong.

18:10 <hannes> I might have the wrong impression about the

18:10 <hannes> amount of work you did after all that time, but it certainly has nothing to

18:10 <hannes> do with your gender.

18:10 <hannes> oh sorry

18:10 <hannes> akashi_the_mechanic: I agree

18:36 <discocaml> <deepspacejohn> dune only runs runs tests if they changed or failed previously. So running a test successfully and then re-running again is a no-op. I don't know exactly what went into the design decision, except that dune also behaves the same way regarding builds. There's also the old unix convention of only printing on failure, not success (with unix you can usually assume that no output = success).

18:45 <discocaml> <deepspacejohn> and, FWIW, dune's built-in expect or cram tests never print on success either way, even when re-run.

19:25 <rage> discocaml: is there a way to force dune to rerun the tests regardless of success/failure?

19:25 <rage> also, hi

19:25 <rgrinberg> you could make the test action depend on (universe)

19:26 <rage> perfect, that worked. thanks

19:30 <rage> so I have another testing question. I've been trying to get ppx_inline_test working but as external tests (as in they run in the test/ folder) and I've had no luck

19:31 <rage> I followed the guide on the dune website, did (library (name proj) (inline_tests) (preprocess (pps ppx_inline_test))), it builds the library, but then how do I run it?

21:16 <remexre> if I have code like `let a = match x with Foo y -> Foo y | Bar -> z in a == x`, is it legal for the OCaml compiler to optimize it to `let a = match x with Foo _ -> x | Bar -> z in a == x`?

21:17 <discocaml> <._null._> I want to say yes

22:08 <dh`> anyone know offhand how to get sub-second timing with lwt? it has timeouts but they seem to only work in integer seconds

22:09 <dh`> remexre: why wouldn't it be?

22:14 <remexre> dh`: in the original version, that expression should evaluate to false; in the optimized one, it's true when x matches (Foo _)

22:14 <remexre> note (==), not (=)

22:17 <dh`> oh, ==. hmm

22:18 <discocaml> <s.alad> anyone doing advent of code in OCaml?

22:18 <dh`> my inclination is that if you use == you can't expect things to behave sensibly, but that's not actually fair :-)

22:18 <discocaml> <._null._> https://discord.com/channels/436568060288172042/1047893927929323560

22:18 <dh`> shouldn't it optimize it to match x with Foo _ -> false | Bar -> z == x?

22:19 <dh`> re lwt, n/m, seems like it works to spawn a real thread out of lwt and have it do normal things

22:19 <remexre> that's another order of optimizations that would make sense, and that one i'm considerably more sure is legal

22:19 <octachron> `==` is not specified on immutable value.

22:19 <discocaml> <leviroth> The behavior of == is not specified for immutable values,

22:20 <discocaml> <leviroth> ....yeah that