03:08 <discocaml> <nimbuu> is there any way to get ocamllsp ans ocmalformat to work on single standalone ml files, it works fine with dune projects but doesn't work on just ml files

05:46 <discocaml> <jalsol> I filed the exact same issue through the google forms a few days ago

05:46 <discocaml> <jalsol>

05:46 <discocaml> <jalsol> I asked ChatGPT and it told me to create a dummy project elsewhere

12:07 <discocaml> <deepspacejohn> You don't need dune to use ocamlformat, just an `.ocamlformat` file.

14:29 <discocaml> <tym972_45887> Hi, how to kill a Thread in OCaml?

15:55 <discocaml> <JM> There is a kill function in the Thread module. (And I don't recommend killing a thread in ocaml or any other languages, you'd better have the threads check on some exit conditions and terminate themselves)

15:56 <discocaml> <JM> Ah, actually, I've just read the doc... There's a kill function, but it's not implemented...

15:59 <discocaml> <tym972_45887> I need it for a chess engine, it seems tricky and dangerous to me to put stopping conditions in a negamax

16:03 <discocaml> <JM> The problem is killing the thread as a general rule doesn't work. You need to know what the thread is doing. Was a resource allocated and needs freeing? Was a lock obtained and need unlocking? Etc.

16:03 <discocaml> <JM> So a language/library that allows a generic thread kill function is just allowing future bugs.

16:04 <discocaml> <JM> It's annoying because sometimes the thread is doing a pure computation and killing is fine. But we can't always have nice things 😔

16:07 <discocaml> <JM> Are you trying to time bound the search? Can't the search itself check how long it has been running?

16:09 <discocaml> <tym972_45887> Yes I try to limit the search time, and implement the "stop" function of the UCI communication protocol

16:10 <discocaml> <tym972_45887> The problem is that if I integrate a variable into my negamax, it will distort the entries in the transposition table.

16:11 <discocaml> <tym972_45887> I don't understand the difference.

17:58 <discocaml> <xavierm02_> @tym972_45887 Why is it dangerous? I'd be tempted to just have a ref incremented at each recursive call, and every time it reaches n, I check if a bool "stop" has been set to true (or if too much time has elapsed). If so I raise an exception, that I catch outside of the negamax and cleanly close the thread

17:59 <discocaml> <tym972_45887> It is what I have just done. I was worried about a negative impact on the transposition table but I was wrong. It is perfect

17:59 <discocaml> <xavierm02_> And you reset the n of course. It's here so that you dont check the time at every recursive call which would be dlow

17:59 <discocaml> <xavierm02_> And you reset the n of course. It's here so that you dont check the time at every recursive call which would be slow

18:00 <discocaml> <tym972_45887> I don't have any thread to kill

19:42 <discocaml> <JM> In your specific case, thre is probably no difference. In the general case:

19:42 <discocaml> <JM> The code running in the thread knows what to clean-up (e.g. release the mutex before your exit)

19:42 <discocaml> <JM> The code running the thread has no idea what's going on.

19:42 <discocaml> <JM> So one can be written safely, the other can not.

20:34 <discocaml> <tym972_45887> Ok, thank you for your time.

20:34 <discocaml> <tym972_45887> I simply implemented the search output in the negamax, it's simpler and it works as I want.

21:59 <discocaml> <lukstafi> Quick question: is anyone mainly using OCaml version < 5.2?

22:18 <discocaml> <lukstafi> Never mind.