hlisp has quit [Remote host closed the connection]
hlisp has joined #ocaml
nullcone has joined #ocaml
hlisp_ has joined #ocaml
hlisp has quit [Ping timeout: 240 seconds]
hlisp_ has quit [Remote host closed the connection]
hlisp has joined #ocaml
hlisp has quit [Remote host closed the connection]
hlisp has joined #ocaml
mfp has quit [Ping timeout: 264 seconds]
hlisp has quit [Read error: Connection timed out]
hlisp has joined #ocaml
hlisp has quit [Remote host closed the connection]
hlisp has joined #ocaml
jao has quit [Remote host closed the connection]
hlisp has quit [Ping timeout: 246 seconds]
hlisp has joined #ocaml
hlisp has quit [Remote host closed the connection]
hlisp has joined #ocaml
vicfred has quit [Quit: Leaving]
vicfred has joined #ocaml
hlisp has quit [Remote host closed the connection]
hlisp has joined #ocaml
waleee-cl has quit [Quit: Connection closed for inactivity]
webshinra_ has joined #ocaml
webshinra has quit [Ping timeout: 265 seconds]
dborisog has joined #ocaml
hlisp has quit [Remote host closed the connection]
hlisp has joined #ocaml
mbuf has joined #ocaml
narimiran has joined #ocaml
hlisp has quit [Remote host closed the connection]
hlisp has joined #ocaml
hlisp has quit [Ping timeout: 272 seconds]
hlisp has joined #ocaml
hlisp has quit [Ping timeout: 256 seconds]
hlisp has joined #ocaml
hlisp has quit [Remote host closed the connection]
hlisp has joined #ocaml
sz0 has joined #ocaml
hlisp has quit [Remote host closed the connection]
hlisp has joined #ocaml
waleee-cl has joined #ocaml
olle___ has joined #ocaml
oni-on-ion has quit [Remote host closed the connection]
oni-on-ion has joined #ocaml
<Leonidas>
Hi, I got a PR to change the API of a library to a way where it is slightly more convenient but less type safe: https://github.com/Leonidas-from-XIV/orewa/pull/18 Which kind of API would you prefer?
<Leonidas>
An API which makes sure that an empty list of arguments cannot be passed or an API that is more uniform by not splitting the list, but will return an error at runtime?
<olle___>
phew
Haudegen has joined #ocaml
<olle___>
Leonidas: why would it return an error? what kind of error?
<olle___>
why not result type or option?
<Armael>
Leonidas: I don't know the application domain, but I would tend to agree that explicitly handling non-empty lists tend to be a pain in practice
<Armael>
so I guess I would compromise and go for the runtime check
<Armael>
(unless maybe if you want to give strong guarantees about your API; if everything else is completely type safe then it would indeed be a bit sad to have unsafe bits just for this case)
c4rc4s_ has joined #ocaml
engil1 has joined #ocaml
Amaan_ has joined #ocaml
c4rc4s has quit [*.net *.split]
runawayfive has quit [*.net *.split]
engil has quit [*.net *.split]
Amaan has quit [*.net *.split]
c4rc4s_ is now known as c4rc4s
runawayfive has joined #ocaml
hlisp has quit [Remote host closed the connection]
hlisp has joined #ocaml
<Leonidas>
olle___: the underlying API does not support zero arguments. So the choices when encountering [] are to error out or just pretend it succeeded, affecting 0 data.
<Leonidas>
olle___: by error I mean a result type anyway :-)
<Leonidas>
Armael: the API does not have that strong guarantees, it is perfectly possible to string together legal operations in an illegal way.
<Leonidas>
(mostly by using the wrong operation on keys of mismatching type)
<Armael>
then I would probably take (possibly empty) lists in the API
<Armael>
to avoid users being tempted to just use List.hd/List.tl on their side
dckc has quit [Ping timeout: 260 seconds]
<Leonidas>
And then what? Error out? Or return immediately?
<Leonidas>
I feel Erroring out is more OCaml-ish, whereas Ok-aying feels a bit Clojure
<Armael>
idk
<Armael>
if ok-ing can be seen as a "conservative extension" of the specification of the function for the usual cases, then maybe go for that?
<Armael>
(but I don't know anything about redis!)
dckc has joined #ocaml
ferd has quit [Ping timeout: 264 seconds]
<Leonidas>
I am just somewhat worried that Ok will obscure an error in the program
<Leonidas>
*users program
ferd has joined #ocaml
<olle___>
Leonidas: if there's no exception, why would a result type be a problem?
ferd has quit [Ping timeout: 256 seconds]
sz0 has quit [Quit: Connection closed for inactivity]
<olle___>
if there's a builder pattern you can use phantom types to enforce a correct order
<Leonidas>
olle___: It is only a problem, because it is completely avaoidable by forcing the list to have at least one element in the signature.
<Leonidas>
it is not a technical question really, more a question of API design :)
<olle___>
Leonidas: what's the idiomatic choice?
hlisp has quit [Remote host closed the connection]
stux|RC has quit [Quit: Aloha!]
hlisp has joined #ocaml
stux|RC has joined #ocaml
mfp has joined #ocaml
hlisp has quit [Remote host closed the connection]
ferd has joined #ocaml
hlisp has joined #ocaml
Anarchos has joined #ocaml
hlisp has quit [Ping timeout: 272 seconds]
<Leonidas>
I don't think there is an idiomatic choice, it is more what people would consider idiomatic.
<olle___>
stupid people
<Leonidas>
Armael stated that a regular list would feel more idiomatic, I think you seem to lean that way too and the author of the PR clearly feels the same
hlisp has joined #ocaml
hlisp has quit [Remote host closed the connection]
<Anarchos>
Why is dune scheduling nCPU jobs, and not nCPU+1 ?
<Anarchos>
It would some rational to always have a job ready to run as soon as one finished
<theblatte>
intuition and reality rarely align when it comes to parallel performance :)
<theblatte>
also dune already does what you're saying? when a job finishes a slot becomes free and is filled by a new one
<Anarchos>
isn't it faster to have a waiting slot than a free slot to fill ?
<Armael>
also that's highly dependent on the OS scheduler
<Anarchos>
Armael sure, i am aware those few microseconds gained will never be noticed. But for the sake of science, i was wondering which approach would lead to fewer stalls
<theblatte>
Anarchos: maybe I'm misunderstanding your suggestion but how would scheduling n+1 jobs have one "waiting" job? All n+1 will compete for CPU and OS resources
<theblatte>
I would be surprised if it takes several microseconds to schedule a new job
<Anarchos>
theblatte the n jobs could run in parallel, while one is in waiting state, always there to be resumed as soon as one cpu resumes a thread
<theblatte>
I am now sufficiently confused to stop asking questions ;)
<Armael>
Anarchos: anyway dune is not in control of the full system, you can be running other cpu-hungry processes in parallel
<Armael>
so it's probably best to honestly advertise that it wants to use all the cores if possible, and let the OS do its job
<Armael>
and if you're using opam for instance, it's going to run OPAMJOBS instances of dune in parallel
<Armael>
and each instance of dune is going to try to use all the cores
<Armael>
(in practice it's fine because some tasks are IO bound and the scheduler is not too bad)
Anarchos has quit [Remote host closed the connection]
Anarchos has joined #ocaml
<Anarchos>
i build the ocaml compiler from source, then i build opam from source. When i try to create a switch with « opam switch create 4.11.0+trunk », i get « unmet availability conditions: enable-ocaml-beta-repository »
<Anarchos>
what's wrong ?
hlisp has joined #ocaml
amiloradovsky has joined #ocaml
infinity0 has joined #ocaml
olle___ has quit [Ping timeout: 256 seconds]
<waleee-cl>
Anarchos: do opam switch list-available have any output?
<Anarchos>
waleee-cl yes
<waleee-cl>
is the last entries 4.11.0 related?
<Anarchos>
the 4.11.0+trunk is named ocaml-variants