wilfred has quit [Quit: Connection closed for inactivity]
unyu has joined #ocaml
waleee has quit [Ping timeout: 265 seconds]
aquijoule__ has joined #ocaml
vicfred has joined #ocaml
aquijoule_ has quit [Ping timeout: 252 seconds]
vicfred_ has joined #ocaml
vicfred_ has quit [Client Quit]
vicfred has quit [Ping timeout: 265 seconds]
mikess has left #ocaml [#ocaml]
mbuf has joined #ocaml
hackinghorn has joined #ocaml
zebrag has quit [Quit: Konversation terminated!]
sleepydog has joined #ocaml
motherfsck has quit [Ping timeout: 244 seconds]
vb_ has joined #ocaml
mbuf has quit [*.net *.split]
vb has quit [*.net *.split]
mbuf has joined #ocaml
wingsorc has quit [Quit: Leaving]
mro has joined #ocaml
shawnw has quit [Ping timeout: 258 seconds]
mbuf has quit [Quit: Leaving]
zozozo has quit [Quit: WeeChat 2.9]
zozozo has joined #ocaml
unyu has quit [Quit: WeeChat 3.2]
unyu has joined #ocaml
unyu has quit [Client Quit]
vizard has joined #ocaml
shawnw has joined #ocaml
berberman has quit [Ping timeout: 244 seconds]
berberman has joined #ocaml
TheLemonMan has joined #ocaml
gravicappa has joined #ocaml
glassofethanol has joined #ocaml
elf_fortrez has joined #ocaml
olle has joined #ocaml
Framacien has joined #ocaml
Framacien has quit [Client Quit]
yoctocell has joined #ocaml
yoctocell has quit [Remote host closed the connection]
yoctocell has joined #ocaml
adanwan has quit [Remote host closed the connection]
shawnw has quit [Ping timeout: 268 seconds]
adanwan has joined #ocaml
elf_fortrez has quit [Quit: Client closed]
kakadu has joined #ocaml
elf_fortrez has joined #ocaml
dhil has joined #ocaml
bartholin has joined #ocaml
elf_fortrez has quit [Quit: Client closed]
aquijoule__ has quit [Ping timeout: 265 seconds]
richbridger has joined #ocaml
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
Exagone313 has joined #ocaml
dinosaure has quit [Ping timeout: 244 seconds]
nyuhu has quit [Ping timeout: 272 seconds]
dinosaure has joined #ocaml
Chouhartem has quit [Ping timeout: 244 seconds]
nyuhu has joined #ocaml
<Guest9474>
glassofethanol: I find Base/Core so much better designed, the ocaml stdlib feels so painful and spotty compared to it
Exa has quit [Ping timeout: 268 seconds]
Guest9474 is now known as Leonidas
Leonidas has quit [Changing host]
Leonidas has joined #ocaml
Exagone313 is now known as Exa
<glassofethanol>
Guest9474: That's fair, I find that Stdlib provides what I need for now, but Base/Core looks good, but I've been learning Lwt so I'll probs use Base since that's small enough and good enough for what I need
<Leonidas>
Also Async is better designed than Lwt :p
<Leonidas>
But admittedly it created quite a schism
<Leonidas>
Core(_kernel) has the disadvantage of being giant and having massive amounts of dependencies, admittedly.
<fluxm>
am I a bad person for hoping both of them to be replaced with The Effect System?-)
<Leonidas>
in such case I am the same kind of bad person
Chouhartem has joined #ocaml
mro has quit [Remote host closed the connection]
<kakadu>
Not replaced but maybe totally redesigned. (5 cents from another bad person)
<olle>
If effects are typed, they would have to redesign it?
<d_bot>
<Deadrat> I hope ecosystem converges on common effect interfaces
<d_bot>
<Deadrat> To avoid the async/lwt split all over again
waleee has joined #ocaml
joni has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 250 seconds]
<companion_cube>
Leonidas: what base/core lacks, though, is stability
<companion_cube>
imho
<companion_cube>
also do they still require a CLA to contribute?
<Leonidas>
companion_cube: I agree. Also contributing is hard, but not because of CLA but source-drops
<companion_cube>
I think it's probably better designed and more consistent
<companion_cube>
but it's also explicitely designed aroudn the needs of JST :)
<Leonidas>
Also I found JST software to be written in an odd way
<Leonidas>
companion_cube: well, yeah, but the ocaml stdlib is written around the needs of compiler writers
<Leonidas>
thus giving rise to altlibs to begin with
<companion_cube>
a lot of people, historically, have been writing compiler-adjacent stuff in OCaml :)
<companion_cube>
I mean, the stdlib is a decent start, my beef wasn't so much the design as the missing stuff
<d_bot>
<Anurag> companion_cube: re stability, i've definitely had an awkward time with JST upgrades in the past, but the stability story is definitely improving. Its a small sample but upgrades from 0.12-0.14 series at old job were really painless (i can only remember 1 function in a little used library that had to be changed). It also helps a lot now that they publish changelogs on the discourse forum.
<d_bot>
<Anurag>
<d_bot>
<Anurag> So while there is still some churn compared to other ocaml libs, overall stability story is definitely improving (atleast for established libraries like base, core_kernel, async etc)
<companion_cube>
@Anurag: for base they could try semver? :p
<companion_cube>
anyway, I don't want to criticize, it's just a bit different than what the stdlib sticks to
<d_bot>
<Anurag> semver would indeed be nice, but I should start being more careful about that myself before proposing other to use semantic versions hehe :p
<companion_cube>
😂
<companion_cube>
I say that but containers doesn't strictly adhere to it, not for all modules anyway
<sleepydog>
I'd like to see more projects take TeX/Metafont's versioning scheme, and converge on some irrational number with each release :)
<companion_cube>
tex is extremely backward compatible, isn't it?
<sleepydog>
I don't know. It would have to be, I suppose
<sleepydog>
I'm only joking, but it does exude confidence (or insanity?) to adopt a versioning scheme that adds another digit with each release
mro has joined #ocaml
mro has quit [Remote host closed the connection]
<sim642>
It's just a roundabout way of saying that the version scheme is natural numbers
<companion_cube>
how about a Gödel encoding of versions?
<thizanne>
"Behold, the new release of Containers, vλx.λy.x (x (x y))_λx.λy.x(x y)"
TheLemonMan has joined #ocaml
<octachron>
Why stop at irrationals? Converging towards a chaitin's constant seems like a better refuge in audacity.
rak has quit [Quit: Segmentation fault (core recycled)]
rak has joined #ocaml
waleee has quit [Ping timeout: 250 seconds]
<companion_cube>
thizanne: compatibility iff the terms are extensionally equal
<thizanne>
:D
joni has quit [Remote host closed the connection]
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
motherfsck has joined #ocaml
favonia has joined #ocaml
bartholin has quit [Quit: Leaving]
elf_fortrez has joined #ocaml
olle has quit [Ping timeout: 258 seconds]
glassofethanol has quit [Quit: leaving]
glassofethanol has joined #ocaml
favonia has quit [Ping timeout: 264 seconds]
favonia has joined #ocaml
elf_fortrez has quit [Quit: Client closed]
favonia has quit [Ping timeout: 240 seconds]
favonia has joined #ocaml
mro has joined #ocaml
<d_bot>
<monk> as someone completely new to ocaml, i find Base/Core very nice and fleshed out, but the stdlib's simplicity sometimes has me reaching into it from the `Caml` module to skip over the complexity and safety guards used by Base/Core
<d_bot>
<monk> example in the #beginners channel was pulling out a line of ints from stdin using Scanf
<companion_cube>
scanf is dirty though
<d_bot>
<NULL> Is it ? It has weak grammar recognition capabilities, but is it problematic otherwise ?
Tuplanolla has joined #ocaml
<companion_cube>
it's just tricky to use properly
<d_bot>
<NULL> Now I don't know if I unknowingly stepped in those, if I luckily avoided them or if I'm oblivious to them
mro has quit [Quit: Leaving...]
<d_bot>
<monk> i really can't speak to that but for reading a set number of eg Ints from Stdin it's simplicity is nice
<d_bot>
<monk> its*
<companion_cube>
yeah sure
<companion_cube>
:p
<companion_cube>
if things are separated by spaces it's ok iirc
<d_bot>
<undu> you can't enforce minimum length of the captured field, which makes parsing with scanf sometimes not possible
glassofethanol has quit [Quit: leaving]
<d_bot>
<NULL> Not sure what you mean here
<d_bot>
<Alistair> If I have the following library:
<companion_cube>
if there's a mli file along a ml file, the compiler uses it, is all
<d_bot>
<Alistair> Yes I know that, but if I put: ```
<d_bot>
<Alistair> module Frontend : sig
<d_bot>
<Alistair> include Frontend
<d_bot>
<Alistair> end
<d_bot>
<Alistair> module Located : sig
<d_bot>
<Alistair> include Located
<d_bot>
<Alistair> end
<d_bot>
<Alistair> module Id : sig
<d_bot>
<Alistair> include Id
<d_bot>
<Alistair> end
<d_bot>
<Alistair> ``` in `syntax.mli` it won't compile
<companion_cube>
`include module type of Frontend`, probably
<companion_cube>
but you should `module Frontend = Frontend` instead, it'll be cleaner
<d_bot>
<Alistair> That works, thank you
elf_fortrez has joined #ocaml
TheLemonMan has joined #ocaml
waleee has joined #ocaml
schube[m] has joined #ocaml
unyu has joined #ocaml
elf_fortrez has quit [Ping timeout: 246 seconds]
copy has quit [Quit: copy]
copy has joined #ocaml
TheLemonMan has quit [Quit: "It's now safe to turn off your computer."]
yoctocell has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
yoctocell has joined #ocaml
neiluj has joined #ocaml
<neiluj>
Hi! Is there a way to assign an opam switch a directory?
<companion_cube>
go to the directory and you can make a new opam switch in it: `opam sw create . 4.12.0` (or whatever version you want)
<companion_cube>
it'll put the switch in _opam
oriba has joined #ocaml
<neiluj>
thanks companion_cube! unfortunately it's an existing switch from another directory
<companion_cube>
ah. make a new one, you can't move a switch
<neiluj>
I see, thanks for the advice :) Another question: how do you generate docs for an executable? I got it working for a library with a dune rule.
<companion_cube>
oh I never tried
<neiluj>
maybe make a library and a small executable calling the main function?
<companion_cube>
I think odoc wants a library? what would do look like for an executable?
<companion_cube>
yes that always works
<neiluj>
yeah, that makes sense
<neiluj>
thanks :)
<octachron>
It is rather the dune driver for odoc that wants a library, odoc itself can work with an executable.
<companion_cube>
good to know!
<cemerick>
speaking of odoc; the output it generates via odig for ocamlgraph happens to not include any documentation comments, just modules and types. All of the other modules in the odig-orchestrated output seems complete though. What should I look for to address that?
<neiluj>
thanks! Concerning my first question, a soft link to the _opam directory does the trick!
<octachron>
cemerick, with odoc 2 or odoc 1.5?
<cemerick>
octachron: 1.5.2
<octachron>
ocamlgraph feels like one of the library where the rendering might be partial in 1.5 compared to 2
<cemerick>
oh, are we talking about a question of ocamldoc/odoc compat?
<octachron>
It is more than odoc 2 is really different from odoc 1.5. But no ,since ocamldoc documentation of ocamlgraph is fine, that is probably not the issue.
yoctocell has quit [Quit: ERC (IRC client for Emacs 28.0.50)]
favonia has quit [Ping timeout: 264 seconds]
favonia has joined #ocaml
<octachron>
(Odig works for me with ocamlgraph + odoc 2)
dhil has quit [Ping timeout: 250 seconds]
neiluj has quit [Ping timeout: 268 seconds]
dhil has joined #ocaml
Stumpfenstiel has joined #ocaml
neiluj has joined #ocaml
favonia has quit [Ping timeout: 252 seconds]
favonia has joined #ocaml
favonia has quit [Client Quit]
vizard has quit [Ping timeout: 258 seconds]
dhil has quit [Ping timeout: 268 seconds]
shawnw has joined #ocaml
vizard has joined #ocaml
glassofethanol has joined #ocaml
dhil has joined #ocaml
gravicappa has quit [Ping timeout: 268 seconds]
vizard has quit [Ping timeout: 258 seconds]
romildo has joined #ocaml
<romildo>
Is there any OCaml developers on NixOS here? I am getting an error building a project using the packages provided by NixOS.
<Corbin>
A Nix error or an OCaml error?
<romildo>
± dune build
<romildo>
File "_none_", line 1:
<romildo>
Error: No implementations provided for the following modules:
<romildo>
Migrate_parsetree__Migrate_parsetree_versions referenced from /nix/store/107myxypfawcs0mrvcrrmvj6wa4cpgx3-ocaml4.12.0-ppx_import-1.8.0/lib/ocaml/4.12.0/site-lib/ppx_import/ppx_import.cmxa(Ppx_import__Ppx_types_migrate),
<romildo>
Migrate_parsetree__Migrate_parsetree_driver referenced from /nix/store/107myxypfawcs0mrvcrrmvj6wa4cpgx3-ocaml4.12.0-ppx_import-1.8.0/lib/ocaml/4.12.0/site-lib/ppx_import/ppx_import.cmxa(Ppx_import)
<romildo>
Maybe a packaging error... Or maybe I am missing something. I do not know.