<discocaml>
<_ggole> What is going on here? `one` appears to be abstract in `M` for some reason?
<discocaml>
<_ggole> Wait, is this a scoping thing?
<discocaml>
<_ggole> OK, it is. That is quite the unhelpful error message.
azimut has quit [Ping timeout: 240 seconds]
bibi_ has quit [Quit: Konversation terminated!]
bartholin has joined #ocaml
Tuplanolla has joined #ocaml
Serpent7776 has joined #ocaml
dnaq has quit [Remote host closed the connection]
dnaq has joined #ocaml
szkl has quit [Quit: Connection closed for inactivity]
<discocaml>
<leostera> does anyone know how to tell dune to compile everything in debug mode / with debug symbols? setting `--profile=debug` makes lldb complain that the binary was compiled with optimizations
<discocaml>
<lukstafi> What's the scoping problem? Cannot see it at a glance.
<discocaml>
<lukstafi> Isn't the `-g` option passed with the `:standard` flags by Dune?
<discocaml>
<_ggole> The `ext` in the `(struct type ext = | end)` isn't in scope at top level
<discocaml>
<_ggole> Which makes sense, except I did not realise that this results in the type definition containing it to be made abstract.
<discocaml>
<_ggole> Which makes sense, except I did not realise that this results in the type definition containing it being made abstract.
<discocaml>
<Kali> you need to define empty beforehand
<discocaml>
<leostera> ah yes, i was running the wrong binary 🙃
<discocaml>
<_ggole> No, the call to `mapCPS` is not in tail position
<discocaml>
<passerby> Doesn't CPS always make a function tail-recursive?
<discocaml>
<_ggole> Yeah, but this function is not in CPS
<discocaml>
<passerby> why?
<discocaml>
<Kali> perhaps move to #beginners
<discocaml>
<passerby> Ok
<discocaml>
<_ggole> In CPS you would pass a continuation to mapCPS that takes its return value and performs the rest of the compution with it (prepends `f x`, in this case)
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
Inline has quit [Quit: Leaving]
Serpent7776 has quit [Ping timeout: 245 seconds]
<discocaml>
<lukstafi> Just curious, any chance we will get standard-library immutable arrays? (Properly immutable, i.e. not views on arrays that could change.)
<discocaml>
<octachron> Possibly (aka there is some interest, and even possibly people working on it)
<discocaml>
<octachron> Don't expect them any time soon (there are many small design choices left to make sure that they are not an obstacle towards modular array kinds)
waleee has joined #ocaml
waleee has quit [Ping timeout: 245 seconds]
waleee has joined #ocaml
azimut has joined #ocaml
<companion_cube>
@lukstafi I'm adding them to containers currently :)
<discocaml>
<tym972> Hello, is there an efficient way to store int arrays into hash tables?
<discocaml>
<tym972> I'd like to make a transposition table for my chess program
<discocaml>
<tym972> I'd like to make a transposition table for my modest mail box chess program
fweht has joined #ocaml
cr1901 has quit [Quit: Leaving]
cr1901 has joined #ocaml
<discocaml>
<octachron> What is your issue with storing the int array in the hash table directly?
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #ocaml
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #ocaml
azimut has quit [Ping timeout: 240 seconds]
<discocaml>
<tym972> The process is extremely slow, and I have to copy the array (the copy doesn't explain the slowness). For some depth search it is literally endless. A solution I found is to convert the array into a string and store that string, but I think there is a faster way.
Serpent7776 has joined #ocaml
bibi_ has joined #ocaml
azimut has joined #ocaml
Serpent7776 has quit [Ping timeout: 256 seconds]
average has quit [Quit: Connection closed for inactivity]
lthms has joined #ocaml
alexherbo2 has joined #ocaml
azimut has quit [Ping timeout: 240 seconds]
<discocaml>
<octachron> Extremely slow is not a number. Copying the array should be slower or in the same order of magnitude than hashing it.
<discocaml>
<octachron> If you want to check that you are not hitting a pathological case in term of collisions, you could compare with a map to have a performance baseline.
azimut has joined #ocaml
rgrinberg has joined #ocaml
average has joined #ocaml
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
Tuplanolla has quit [Remote host closed the connection]
Tuplanolla has joined #ocaml
rgrinberg has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
average has quit [Quit: Connection closed for inactivity]
<discocaml>
<lukstafi> Dune's documentation mentions support for `.mli`-only files "which are not a proper part of the OCaml language". I guess it's "half of the `_intf` trick"?
azimut has quit [Ping timeout: 240 seconds]
<companion_cube>
no, it's if you use .mli-only files to declare types
<companion_cube>
I have no idea why you'd do that but some people do
<discocaml>
<lukstafi> I.e. if `Foo` would not have any values anyway.
azimut has joined #ocaml
szkl has joined #ocaml
Serpent7776 has joined #ocaml
cedric has joined #ocaml
dnaq has quit [Remote host closed the connection]
dnaq has joined #ocaml
cedric has quit [Quit: Konversation terminated!]
cedric has joined #ocaml
cedric has quit [Client Quit]
trev has quit [Quit: trev]
Anarchos has joined #ocaml
Anarchos has quit [Ping timeout: 268 seconds]
Serpent7776 has quit [Ping timeout: 256 seconds]
alexherbo2 has quit [Ping timeout: 250 seconds]
<discocaml>
<Ada> like, mli files with no corresponding ml
<discocaml>
<deepspacejohn> I never understood what advantage that had over just declaring the types in a ml. I assume I'm missing something
<discocaml>
<Kali> so that you could include the module type before `module type of`, perhaps
bartholin has quit [Quit: Leaving]
<companion_cube>
I'm missing the point at well
<discocaml>
<deepspacejohn> I'm not sure I follow. mli files are still modules, not module types, right?
<discocaml>
<deepspacejohn> or am I completely misunderstanding