06:14 <d_bot> <Christophe> I think it's meant to make a clear beginning and a clear ending, same as « … »

10:50 <d_bot> <Et7f3> They are the nearest ascii symbol of «»

10:51 <d_bot> <mk-fg> Sometimes when you copy-paste stuff from the internet there are also unicode "left" and "right" single quotes

10:54 <d_bot> <Et7f3> Aren't they accent ?

11:00 <d_bot> <mk-fg> No, pretty sure just different quotation marks, probably inserted by some CMS backend in place of whatever was typed

11:18 <d_bot> <mk-fg> Googling this out of curiosity, found that single-quote practice is usually either justified as a lazy style (less keypresses) or as a preference among british writers (e.g. https://www.scribophile.com/academy/correct-quotation-mark-usage ), interesting

12:43 <Leonidas> is there a way to get info from ocamllsp? it stopped to display signatures of my codebase and I am wondering what is going on.

12:54 <Guest98> I have a application where I need to read in a file line by line and manipulate the string and write to an output file. I can either create a giant string and flush to the output file at the end or write to the output file multiple times. Which method is more efficient? Thanks in advance!

13:01 <Armael> working line by line has the advantage that it doesn't require you to load the whole file in memory, so that's what I would do

13:01 <Armael> I'm not sure if it matters a lot in terms of performance

13:01 <d_bot> <mk-fg> If you use stdlib i/o functions, those go through libc's fwrite calls, and those will do buffering for you (hence there's flush func in there)

13:03 <d_bot> <mk-fg> Iirc default glibc buffer is ~8K, which is reasonable wrt filesystem write sizes, so unless you explicitly want to avoid some filesystem pathology or need least possible memory footprint, I'd stick with dropping lines through write calls line-by-line

13:04 <Guest98> I am trying to use Unix.write function

13:05 <Guest98> d_bot thanks!

13:06 <d_bot> <mk-fg> That's probably direct syscall interface that won't have any buffering

13:09 <d_bot> <mk-fg> Not sure how well repeated line-sized (e.g. ~100B) writes work wrt performance tbh - with larger buffered ones it's pretty clear, as those would definitely span couple fs pages, so maybe use those if in doubt instead of Unix.write

13:10 <d_bot> <mk-fg> Or otherwise if it's important for the app, I'd probably benchmark such small sequential writes in something resembling production scenario (e.g. same filesystem/hw/cloud/etc)

13:17 <Guest98> Yea I will probably benchmark it and see. Thanks d_bot!

13:20 <d_bot> <mk-fg> If you deal with many such files in parallel and read performance also matters, one thing to watch out for with tiny writes might be degrading read performance on the whole fs due to fragmentation - you can usually check that via filefrag tool on linux, and different filesystems handle such allocation differently

13:21 <d_bot> <mk-fg> You can also avoid that whole issue by using posix_fallocate (on linuxes at least) before doing a lot of writes, like e.g. bittorrents clients do for exactly same reason

14:28 <d_bot> <mbacarella> You are invited to the next OCaml Cafe on Wed, Oct 13 @ 1pm (US Central).

14:28 <d_bot> <mbacarella>

14:28 <d_bot> <mbacarella> Please join us at the next OCaml Cafe, a friendly, low stakes opportunity to ask questions about the OCaml language and ecosystem, work through programming problems that you’re stuck on, and get feedback on your code. Especially geared toward new and intermediate users, experienced OCaml developers will be available to answer your questions. Bring your code and we’ll be happy to review it, assist with debugging, and provid

14:28 <d_bot> <mbacarella>

14:28 <d_bot> <mbacarella> This month, David Allsop of OCaml Labs and the University of Cambridge will present on OPAM, the OCaml package manager. After introducing OPAM, David will discuss the new features of OPAM 2.1, just released at the beginning of August. Following David’s talk, we will open the discussion to all things OCaml-related.

14:28 <d_bot> <mbacarella>

14:28 <d_bot> <mbacarella> Full meeting details, including Zoom link, here: https://www.meetup.com/ocaml-cafe/events/281344155/

18:28 <d_bot> <Ulugbek> Assuming you use vscode:

18:28 <d_bot> <Ulugbek> 1. Make sure you have `Ocaml.trace.server` set to `verbose` (picture 1)

18:28 <d_bot> <Ulugbek> 2. Open `Output` pane (it's located next to `Terminal` pane, usually) and set the dropdown to `OCaml Language Server`

18:28 <d_bot> <Ulugbek>

18:28 <d_bot> <Ulugbek> This way you should see all requests to and responses from ocaml-lsp. If something doesn't work for you, eg jump to def, hover, it's likely that there is a failing response (exception), which should be reported in the pane.

18:28 <d_bot> <Ulugbek> https://cdn.discordapp.com/attachments/436568060288172044/897188834025046016/unknown.png

18:28 <d_bot> <Ulugbek> https://cdn.discordapp.com/attachments/436568060288172044/897188889603743744/unknown.png

23:04 <hackinghorn> hi, how do I use the Janestreet Core instead of the usual one?

23:04 <hackinghorn> with dune, maybe

23:05 <hackinghorn> is it like, having (libraries core) in dune file and open Core in .ml file?