02:06 <discocaml> <masterbuilder> Are there any downsides to using Bigarray.Genarray instead of a Bigarray with specific dimensions?

02:07 <discocaml> <masterbuilder> and if so what's the best way to map a file to a specific type of Bigarray? since Unix.map_file returns a Genarray

07:53 <discocaml> <lukstafi> In principle yes, but in practice? From taking a look at the code I don't remember specific optimizations, but would welcome to stand corrected.

09:25 <neiluj> Hello! So I'm writing some bindings to a C library were most inputs/outputs of the functions are a special "recursive" type GEN (which is a pointer to long to have kind of an array of adresses to GEN objects), allowing for some kind of genericity (in this case, you can thus have polynomials (GEN) with coefficients in a special field or whatever (of type GEN). So the bindings are not type safe in

09:25 <neiluj> that you could compose objects to build nonsensical mathematical objects.

09:25 <neiluj> How would you design a type safe wrapper over these bindings

09:26 <neiluj> thought about GADTs to have a single type for all GEN objects but it might be overkill

09:26 <neiluj> *where

09:30 <neiluj> either have a type for each kind of GEN type, or a single sum type for all GEN types, or even a GADT where each constructor maps to a function between subtypes (so a DSL I suppose?) and have an evaluation function

09:30 <neiluj> the last approach might be too heavy

12:56 <adrien> I'm sorry to sin and to Obj.magic a queue into a list but it's really much faster

12:56 <Anarchos> adrien :)

12:57 <adrien> the wonderful thing is that once you've done that, your list updates as you push to the queue

12:59 <Anarchos> adrien don't we have double side linked list ? We could cons at top or end of the list

13:01 <discocaml> <masterbuilder> I see, so is there a way to convert a Genarray into a flat 1D array for example?

13:02 <discocaml> <masterbuilder> or is there a library that offers map_file but without the genericity

13:03 <adrien> queue to list through Obj.magic is really an exception for conversions: I'm actually not entirely sure how it works

13:03 <adrien> (I thought I was sure, and now I'm not sure anymore)

13:05 <adrien> when you say flat 1D array, what would be the type of the elements?

13:05 <discocaml> <froyo> adrien:

13:05 <discocaml> <froyo> https://cdn.discordapp.com/attachments/436568060288172044/1086636464370102402/image.png

13:05 <zozozo> adrien: that's a really bad idea, because the conversation "lies" about the mutability of things

13:07 <zozozo> Even if a queue's cell structure shares the same representation than lists

13:08 <adrien> zozozo: I know all guarantees disappear; I was mostly trying to see the cost of a million prepends + rev

13:11 <discocaml> <masterbuilder> 32 bit int for example

13:15 <discocaml> <masterbuilder> I mean aren't you already asking Genarray to try to create an array with specific dimensions and it will fail if it can't? So in theory you could have a bunch of functions like `map_file_array1` etc., and I think no-op conversions for Bigarrays wouldn't be dubious at all, right?

13:16 <neiluj> emacs (tuareg mode) is so slow with a 7000LOC file :'(

13:16 <neiluj> how do you fix it?

13:21 <discocaml> <masterbuilder> neiluj: are you using native-comp?

13:23 <discocaml> <masterbuilder> also wow what file is that? 7K is too much for my taste, I draw the line at 1K personally

13:23 <neiluj> yes pgtk+nativecomp

13:23 <neiluj> 7K because it's C bindings

13:23 <discocaml> <masterbuilder> I see

13:23 <neiluj> maybe split the Ctypes functor into several ones?

13:24 <discocaml> <masterbuilder> Yeah probably a good idea

13:24 <neiluj> so it's a known issue of native comp?

13:24 <neiluj> (thanks by the way for pointing this out)

13:24 <discocaml> <masterbuilder> No I have definitely opened larger files than that before, not in tuareg-mode though, it may be a little slow to start up but then fine after that

13:25 <discocaml> <masterbuilder> So maybe an issue with tuareg-mode or if you use lsp maybe it's slowness on the lsp side

13:25 <neiluj> hmm good idea lsp perform better

13:25 <neiluj> *may perform

13:29 <discocaml> <froyo> elisp problem not ocaml problem :^)

14:09 <discocaml> <val patate: unit Lazy.t> neiluj: about your "GEN", you cannot really have type-safe binding if it is not type-safe in the original language...

14:10 <discocaml> <val patate: unit Lazy.t> You can allow only for construction of valid values from ocaml, but if you get them from another program, they will always have the possibility of being complete garbage...

14:10 <discocaml> <val patate: unit Lazy.t> (I hope I did not misunderstood your problem)

14:21 <neiluj> yes that's indeed a risk

14:37 <discocaml> <masterbuilder> oh wait, there actually are a bunch of these conversion functions already in the stdlib, didn't see them at first

17:31 <discocaml> <val patate: unit Lazy.t> neiluj: So having a type-safe binding, only makes sense if you break compatibility with the original lib...

17:33 <discocaml> <val patate: unit Lazy.t> On another note, would that be possible to reply to the CompanionCubeBot and have it translated to a reply to the poster on IRC too?

17:40 <neiluj> @val patate: unit Lazy.t the idea was to have a direct translate of the C interface but in ocaml and then build abstractions with the bindings

17:41 <neiluj> what do you mean by breaking compatibility with the original lib?

17:42 <discocaml> <val patate: unit Lazy.t> exactly what you avoid with what you just proposed 🙂

17:42 <discocaml> <val patate: unit Lazy.t> This is what I would go for

17:44 <companion_cube> There is no notion of answer on the IRC side

17:45 <neiluj> good! thanks for the advice :)

17:45 <discocaml> <darrenldl> time to add rfc to irc

17:45 <neiluj> well the IRC client can highlight or even notify when a message contains one's username

18:18 <discocaml> <val patate: unit Lazy.t> I see...

18:20 <discocaml> <darrenldl> just need to make a chatgpt plugin to figure out which line is most likely a reply to what

18:23 <discocaml> <val patate: unit Lazy.t> Please, no

18:42 <olle> When can we expect to have a local version of chatgpt in our pockets?

18:42 <olle> 10 years?

19:15 <olle> Error: This variant expression is expected to have type exn The constructor DocblockSyntaxError does not belong to type exn

19:15 <olle> Meh

19:15 <olle> 6 exception DocblockSyntaxError of string

19:15 <olle> Clearly it does tho

19:16 <olle> Ah, namespace issue

19:24 <olle> Hm, if I put an exception inside %{ }% block in Menhir, won't it be exported?

19:24 <neiluj> given a gadt, is it possible to have generic types parametrized by a "closed" subset of the gadt

19:24 <neiluj> ?

19:25 <neiluj> that would be nice

19:26 <neiluj> this would be a kind of ad-hoc polymorphism?

19:30 <olle> open variants?

19:32 <neiluj> oh yes good idea! thanks :) less powerful than a gadt but you get subtyping

19:34 <olle> +1

23:42 <discocaml> <darrenldl> val patate: we'll witness a uni student project along those lines quick enough, worry not