00:35 <d_bot> <Wulfman> Is there someone that know `core.command` and ocmal `exception` i don't understand with `try command.run mycommand with My_Exception -> 1` return `uncaught exception My_Exception` .?...

00:35 <d_bot> <Wulfman> Why isn't the try catch block catching it ?

00:52 <d_bot> <NULL> When an error reaches toplevel, `Exception: My_exception` is printed. If it's not the message you get, it indicates that something (like `command.run`) catches all exceptions and exits early. If it is indeed the case, you want to put your try/except inside the argument of `command.run`

00:53 <d_bot> <NULL> (I don't know `core.command` though, I can't help more about that)

02:30 <d_bot> <leviroth> I agree, I think the thought is that you put all of your program logic, including exception handling, inside the command

02:44 <d_bot> <leviroth> Oddly this one-line program prints the uncaught exception differently than it does if I remove the `let _ignoreme` bit: `let () = let _ignoreme = Core.sec in raise (Invalid_argument "foo")`

02:45 <d_bot> <leviroth> It seems to do this if I reference anything in `Core` that isn't just re-exported from `Core_kernel`, so I assume it has something to do with how dune decides to link things.

09:21 <hackinghorn> hi, any guide on using In_channel, Out_channel?

09:23 <d_bot> <darrenldl> is bindlib the goto these days?

09:24 <d_bot> <darrenldl> hackinghorn: what specific things you're trying to do?

09:26 <hackinghorn> I just want to write to a file using Out_channel

09:27 <hackinghorn> looks like there is nothing much on Out_channel with capital O

09:28 <rgrinberg> hackinghorn Out_channel.write_all?

09:31 <hackinghorn> I don't know, I guess. Maybe I can try that, I guess

09:31 <hackinghorn> do I have to open or close or anything?

09:31 <hackinghorn> a line of explanation would be good

09:32 <hackinghorn> okay I guess I can try that

09:32 <rgrinberg> Here's an example: Out_channel.write_all "test" ~data:"foo bar baz"

09:32 <rgrinberg> closing and opening is done for you by this function

09:33 <hackinghorn> aight, thanks, that looks simple

09:33 <d_bot> <let Butanium = raise Not_found;;> ```ocaml

09:33 <d_bot> <let Butanium = raise Not_found;;> let log_datas ?(close=true) f file (datas: 'a list) =

09:33 <d_bot> <let Butanium = raise Not_found;;> let oc = get_oc file in

09:33 <d_bot> <let Butanium = raise Not_found;;> List.iter (fun x -> Printf.fprintf oc "%s" @@ f x) datas;

09:33 <d_bot> <let Butanium = raise Not_found;;> if close then close_out oc; oc

09:33 <d_bot> <let Butanium = raise Not_found;;> ```

09:33 <d_bot> <let Butanium = raise Not_found;;> with

09:34 <d_bot> <let Butanium = raise Not_found;;> ```ocaml

09:34 <d_bot> <let Butanium = raise Not_found;;> let get_oc file = open_out @@ file.file_path ^ file.file_name

09:34 <d_bot> <let Butanium = raise Not_found;;> ```

09:34 <d_bot> <let Butanium = raise Not_found;;> this prints datas from a list in a file

09:35 <d_bot> <let Butanium = raise Not_found;;> full module here if you want to give it a look https://github.com/Butanium/monte-carlo-tree-search-TSP/blob/master/tools/File_log.ml

10:11 <hackinghorn> write_all shows me "No such file or directory"

10:11 <d_bot> <Wulfman> @NULL @therewolf Thanks :). I do observe the same odd behavior from the command line with the message changing from `Fatal Error : exception exn` to `Uncaught exception : exn` . When you say "catches all exceptions and exits early", what mechanism are you thinking for exiting ? doesn't running `exit` throw and exception ? can we "catch" the effect of exit ?

10:11 <hackinghorn> maybe i need to create directory

11:21 <d_bot> <Wulfman> Ho... I think core.command open a separate thread of something like that. The stack trace is really short and doesn't start from my entry-point

12:16 <d_bot> <leviroth> @Wulfman I don't think `exit` raises an exception. I think it calls the unix `exit` function, ending the process directly.

15:58 <d_bot> <antron> how is the performance of mutable fields affected by multicore?

16:12 <sadiq> there should be no difference?

16:12 <sadiq> apart from maybe some cache effects with remember sets and different threads

16:13 <companion_cube> the write barrier didn't change at all?

16:14 <sadiq> nohttps://github.com/ocaml/ocaml/blob/trunk/runtime/memory.c#L617 trunk

16:15 <sadiq> https://github.com/ocaml-multicore/ocaml-multicore/blob/5.00/runtime/memory.c#L129 multicore

16:15 <sadiq> so the more nuanced answer is that yes but not on x86

16:15 <companion_cube> good, good

16:16 <sadiq> there's maybe a tiny difference in marking behaviour

16:16 <sadiq> antron: have you found one?

16:16 <d_bot> <antron> no, i haven't found a difference. but i'm considering using some relatively short-lived records with mutable fields, and worried if that will be a problem in multicore

16:17 <sadiq> on x86 you shouldn't see anything

16:17 <d_bot> <antron> ok, good. what about other architectures?

16:18 <sadiq> on arm64 the memory model could have a small impact

16:18 <sadiq> (though again, would be surprised if you could see it)

16:19 <d_bot> <antron> is it something like on the scale of the cost of a few extra arithmetic instructions or so?

16:20 <sadiq> https://kcsrk.info/papers/pldi18-memory.pdf has it overall at 0.6% but doesn't break out the stores

16:21 <sadiq> also the ThunderX was a funky chip, I suspect the difference will be even smaller on something like the M1

16:21 <sadiq> antron: it's the memory barrier

16:21 <sadiq> https://github.com/ocaml-multicore/ocaml-multicore/blob/5.00/runtime/memory.c#L156

16:22 <sadiq> x86 is always acquire-release and on the M1 (and the modern ARM cores) it's also pretty well optimised

16:22 <sadiq> for the M1 especially so because of x86 emulation

16:38 <d_bot> <antron> thank you

17:05 <sadiq> no problem

21:18 <rgrinberg> hackinghorn indeed you need to create the dir first

21:28 <d_bot> <Kakadu> Could you recommend some reading (except reading C) about closure representation when flambda is enabled?

21:29 <companion_cube> afaik closure representation is the same

21:29 <companion_cube> there's just fewer closures :p

21:33 <d_bot> <Kakadu> I tried to print them from C and it looks like they are not the same

21:38 <d_bot> <Kakadu> or maybe I'm wrong....

21:39 <d_bot> <RegularSpatula> They’re basically an alternative interface to the normal in and out channels…the mli docs are decent for these. Did you still need a couple more examples ?

22:18 <zozozo> kakadu: the representation of closures is the same, but flambda might generate different sets of closures than closure

23:19 <d_bot> <Kakadu> It looks like there is a difference but I don't yet fully understand where it is. (See README https://github.com/kakadu/asdf)

23:20 <d_bot> <Kakadu> if somebody has any text description about flambda and partial applications of closures, it will be appreciated.

23:39 <zozozo> kakadu: okay, so the results you get are perfectly fine as far as I can tell

23:40 <zozozo> the main difference is that flambda is able to see that the "free variables" of your closures are actually compile-time constants, so there is no need for the closures to contain these, since they are known at compile-time, and can simply be substituted in the code

23:41 <zozozo> the overall way closures are represented is the same, but flambda can optimize the code so that it generates different, smaller closures (e.g. with some free variables removed)

23:42 <zozozo> kakadu: also, note that the "closure with X free variables" output of your examples is completely wrong

23:43 <zozozo> I'll try and do a small writeup tomorrow about closure representation (it's the second time the topic has come up on irc, maybe it's time to have a doc to point people to, ^^)