<afrosenpai>
is #general the only channel on discord in which the irc is configured to work?
waleee has quit [Ping timeout: 250 seconds]
<afrosenpai>
s/the irc/irc/
octachron_ has joined #ocaml
slothby has quit [Ping timeout: 268 seconds]
nimaje has quit [Ping timeout: 268 seconds]
octachron has quit [Ping timeout: 268 seconds]
waleee-cl has joined #ocaml
nimaje has joined #ocaml
slothby has joined #ocaml
spip has joined #ocaml
bobo_ has quit [Ping timeout: 256 seconds]
<d_bot>
<NULL> #general is the only channel bridged to IRC, yes; you can also count the feeds as "bridges" if you want
waleee-cl has quit [Ping timeout: 240 seconds]
kaph has quit [Ping timeout: 250 seconds]
hackinghorn has quit [Ping timeout: 240 seconds]
zebrag has quit [Quit: Konversation terminated!]
CalimeroTeknik has quit [Quit: バイバイ]
waleee-cl has joined #ocaml
CalimeroTeknik has joined #ocaml
cross_ is now known as cross
<b0o>
In the changelog for ocaml-lsp, there's this entry -- Breaking: ocamllsp drops support for .merlin files, and as a consequence no longer depends on dot-merlin-reader. (#523)
<b0o>
What is the new way to configure merlin?
<d_bot>
<NULL> I think merlin still uses those files when used alone; the LSP gets the info that those files are supposed to have from dune
<b0o>
(this was driving me NUTS for the past 24 hours, trying to figure out why my vendored modules weren't being picked up by the lsp)
<b0o>
I am trying to contribute to rescript-vscode's analysis sub-project which doesn't use dune for some reason, it just has a .merlin file
<d_bot>
<joris> Hello. I'm still totally confused about the rule odoc (odig) uses to select comment for file modules to put as short description in module index
<d_bot>
<joris> i have files which follow the same pattern and some have descriptions but most don't 🤯
hornhack has joined #ocaml
hornhack has quit [Changing host]
jlrnick has joined #ocaml
fcc977 has joined #ocaml
mro has joined #ocaml
fcc977 has quit [Remote host closed the connection]
fcc977 has joined #ocaml
<d_bot>
<joris> > Documentation tools such as odig may use the first line to generate a summary of the module.
<d_bot>
<joris> *may* 😄 i guess i better look at the code
<d_bot>
<joris> so in the basic case it does not generate any synopsis for module index of test_lib. But i have files with some, and i don't understand how (but basically i want that everywhere obviously)
gravicappa has joined #ocaml
<d_bot>
<joris> but on my code i have cases which are obviously better like this
jakzale has quit [Remote host closed the connection]
seeg has quit [Remote host closed the connection]
seeg has joined #ocaml
jakzale has joined #ocaml
b0o has joined #ocaml
xiongxin has quit [Quit: xiongxin]
mro has joined #ocaml
<d_bot>
<VPhantom> Yes there's several options I depend on in `ocamlformat` which will disappear in the next release. I hope the end result will still be decent. My current setup with 0.19 is almost perfect. (If only closing tags were on separate lines, then it'd be perfect to minimize developer hassle and commit diffs.)
<companion_cube>
just fork ocamlformat ;)
<companion_cube>
it's not a proper OCaml project if you don't have at least 2 or 3 alternatives.
<d_bot>
<VPhantom> Yikes, that'd kind of defeat the purpose of having a common standard. I already hate that I have to set so many options in the config file to get things nice and readable.
<d_bot>
<VPhantom> True. 😛
<companion_cube>
there'll never be a common standard
<companion_cube>
it's 20 years too late for that
<d_bot>
<VPhantom> I did like that when I touched Dune, I used its `.ocamlformat` automatically and could edit a line without breaking anything else.
<d_bot>
<VPhantom> If there's no goal of a common standard, then I strongly disagree with their impending removal of important options. 😕
<d_bot>
<VPhantom> …but I _really_ don't want to maintain a fork of something this complex.
<d_bot>
<darrenldl> actually why provide options at all if they wanted strict uniformity
<d_bot>
<VPhantom> Like `prettier`.
<Corbin>
Wait, why are reformatting-only commits a problem? They should be just as bisectable as their neighbors, and code formatters can be configured so that every commit is formatted.
<hannes>
darrenldl: exactly, I never understood why ocamlformat doesn't join forces with ocp-indent and just propose the single >style<.
<Corbin>
I understand that it's *ugly*, but code formatting isn't about pretty code; it's about readable, uniform, non-bikesheddable code.
<companion_cube>
@darrendl because there are already several incompatible styles in the wild
<hannes>
Corbin: well, git praise is the issue I have with these commits.
<companion_cube>
like, normal, and janestreet :p
<d_bot>
<darrenldl> then pick one and die on said hill if you are going to wave the flag of uniformity : p
<Corbin>
hannes: Friendship ended with git-blame, now git-bisect is your best friend~
<companion_cube>
but then you don't get adoption, @darrendl
<d_bot>
<darrenldl> feels like eating a cake and wanting to have it too
<companion_cube>
well, it's an unsolvable problem
<companion_cube>
no agreement on what OCaml should look like
<companion_cube>
the new tool has to accomodate existing code
<d_bot>
<darrenldl> id rather accept that and stop dropping options
<companion_cube>
(and even then it didn't always succeed in doing that imho; I don't use it for example because it drives me fucking mad)
<hannes>
companion_cube: I'd push that single style everywhere I can, if it does not interfere with ocp-indent, and not change in every (minor) revision. so far ocamlformat hasn't convinced me since the output changes in every version.
<companion_cube>
if the style didn't fuck with code I explicitly write, I'd consider it
<companion_cube>
but tough luck
<companion_cube>
ocamlformat tries to do too much.
<d_bot>
<darrenldl> maybe i should move back to ocp-indent hm
<d_bot>
<VPhantom> I haven't tried ocp-indent; I wonder how it compares.
<companion_cube>
well it just does indentation, which means at least it doesn't undo your formatting
<zozozo>
personally, I tend to really dislike ocamlformat's default, and compared to ocp-indent it robs you of any power over formatting of some things (in some cases, you want to adjuts formatting to make things more readable, e.g. big printf statements)
perrierjouet has quit [Quit: WeeChat 3.4]
<Corbin>
companion_cube: I think that the idea that your code has an explicit style is exactly the idea that the bikeshed's paint has a color. Your choice of style, and commitment to it, is your choice of paint.
<companion_cube>
sure, but I also like readable code
perrierjouet has joined #ocaml
<companion_cube>
and none of the existing styles are readable enough because they're oblivious to OCaml's syntax's problems.
<d_bot>
<darrenldl> time to make yet another formatter ( : D
<d_bot>
<joris> the problem is, ocaml syntax is so loose that there are widely different styles in the wild, and ocamlformat is one. And this one was initially super opinionated (like putting separator at the beginning of the line, that was never done in most OS projects as far as i know)
<companion_cube>
zozozo and I are just sticking to ocp-indent
<companion_cube>
yep @joris
<companion_cube>
imho syntaxes which use {} have an easier time, because most things are in a block, and formatting blocks is easy
<d_bot>
<joris> but the major problem is that, code style depends on code style. And by style i mean what is the way you write ocaml. It influences the style that is readable for you
<d_bot>
<joris> for instance, if you tend to split everything i very small file, then you usually obviously like super sparse syntax. But if you tend to write quite big files, in the form of thousands of lines, then sparse syntax you will find it super unreadable
<d_bot>
<joris> it's just an example
<companion_cube>
yep yep
<companion_cube>
and if you write nested matches, or imperative code, your needs are different
<d_bot>
<joris> yep. For instance i use nested matches a lot, and we used to have a code style at work that allows you to not indend nested match if it is the last case
<d_bot>
<joris> it might look like a stylisc choice only, but it also in the long run influences how you write your code semantically
<d_bot>
<joris> and when you change the style, you actually end up changing the code pattern use, so it actually does not really help that much with "uniformity"
<d_bot>
<joris> at least if it keeps changing
<companion_cube>
💯
<Corbin>
joris: That's a way of looking at it, but we could also look at code formatters as *erasing* personal styles.
<companion_cube>
which, fuck that
<d_bot>
<joris> i really do like the idea of erasing personal styles inside a project
<zozozo>
another problem with ocamlformat's "style" is that, well it's ocamlformat's style, as in: as far as I know there weren't really any concertation on what a good style woiuld be for ocaml, and so it's a bit strange to want to bring everyone to that one style arbitrarily
<companion_cube>
then we just need a new syntax
<d_bot>
<joris> but i don't really like that it prevents a project to pick a style that fits its ocaml flavor
<companion_cube>
one that is compatible with formatting.
<d_bot>
<darrenldl> reasonml2 when
<d_bot>
<joris> btw, @companion_cube i don't think it is only block syntax vs ocaml syntax, because to some extand the issue also happens with reason
<zozozo>
at that point, why not store marshalled ASTs, and each person can have its editor configure to display code as one wants
<d_bot>
<joris> i think it is also because ocaml is an increadibly broad language
<companion_cube>
does it? do reason users have wildly different formatting styles?
<d_bot>
<joris> Not really because refmt was here from the start
<d_bot>
<joris> But they are also unhappy about the patterns it enforces
<Corbin>
zozozo: As long as the abstract syntax is terse, sure. But if it supports even one single optional do-nothing leaf operation, then humans will argue over the style question of how many do-nothing leaves to insert, and after which operations; they'll insist that the leaves have a magical code-organizing quality.
<d_bot>
<joris> Though I cannot speak for opensource reason dev
<Corbin>
e.g. whitespace in Lisps!
<companion_cube>
@joris rust people don't seem to dislike the formatter too much
<companion_cube>
you still get a handful of "styles" but it's mostly about sparseness
<d_bot>
<joris> It depends. I remember people complaining about the default format to write monadic code that was unreadable
<d_bot>
<joris> It is just there are a lot less different ways to write rust than to write ocaml I believe
<d_bot>
<joris> But yes it is mostly about sparseness
<companion_cube>
ah, monadic code with >>= would suck, for sure
<zozozo>
Corbin: sure, but then that's also why projects have guidelines (or tyranical leaders, which works quite effectively, ^^)
<d_bot>
<joris> And code review
<companion_cube>
let* would work well in a reasonml like syntax
<d_bot>
<joris> But once again rust as a much lesser surface than ocaml. Idk how it is now but when I left nobody was even writing recursion because no tce
<companion_cube>
I don't know that rust has that small a syntax :p
<d_bot>
<joris> No record update, no objects, no functional vs imperative style
<companion_cube>
there's the whole async stuff, closures with move, blocks, lifetimes…
<companion_cube>
yes record update
<companion_cube>
{x: 1, ..r}
<d_bot>
<joris> Ah yes true
zebrag has joined #ocaml
<Corbin>
It's not just about immediate syntax, but modularity. Ideally, every module could be written in its own code style, so that it *doesn't matter* if you're using modules authored by other people. But the only way I've found to make this work is to put every module in its own file *and* design the language so that modules are tiny.
<companion_cube>
which is definitely not the case :D
rgrinberg has joined #ocaml
<Corbin>
Sure. So the lesson for OCaml users, as with many other languages, is either stop collaborating or relax one's opinions about code style.
Danishman has joined #ocaml
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dalek-caan has joined #ocaml
Haudegen has quit [Quit: Bin weg.]
mro has quit [Remote host closed the connection]
mro has joined #ocaml
mro has quit [Ping timeout: 268 seconds]
mro has joined #ocaml
salkin has joined #ocaml
mro has quit [Ping timeout: 256 seconds]
mbuf has quit [Quit: Leaving]
hackinghorn has quit [Ping timeout: 268 seconds]
bartholin has quit [Quit: Leaving]
mro has joined #ocaml
mro has quit [Ping timeout: 256 seconds]
vijon has joined #ocaml
vijon has quit [Client Quit]
<d_bot>
<cemerick> I see it's another morning of tears re: ocamlformat 🙃
rgrinberg has joined #ocaml
<d_bot>
<VPhantom> Personally I'd be fine with it if they weren't deprecating a bunch of useful options.
<d_bot>
<VPhantom> I love that my code is uniform and that it catches my occasional scoping mistakes (i.e. with a multi-statement pattern match or a runaway if/else).
<d_bot>
<undu> I also haven't been happy with it, it's impossible to keep a consistent style while upgrading it because not eve normal style is stable
<d_bot>
<cemerick> something like it is essential IMO, but yeah, its current direction leaves a _lot_ to be desire
perrierjouet has quit [Quit: WeeChat 3.4]
<d_bot>
<undu> unless you're jane street in that case the style is worh keeping, it's a very bad mesag to send
gdd has quit [Ping timeout: 256 seconds]
<d_bot>
<cemerick> gofmt came around, and now the only thing people seem to want is to enforce some small N of "blessed" styles
perrierjouet has joined #ocaml
<d_bot>
<cemerick> I agree w/ @companion_cube, might as well have 4 - 10 ocamlformat forks with wildly varying options
Haudegen has joined #ocaml
rgrinberg has quit [Read error: Connection reset by peer]
rgrinberg has joined #ocaml
<d_bot>
<VPhantom> If ocamlformat already has a lot of options, might as well have all the options people ask for, and rely on each project's `.ocamlformat` to allow contributors to easily and painlessly contribute. I think that would be the best compromise, short of having an official style defined as part of the language itself.
<d_bot>
<VPhantom> If we forked it, then we'd have _two_ possible formatting tools to worry about. (Obligatory <https://xkcd.com/927/>)
mro has joined #ocaml
salkin has quit [Ping timeout: 268 seconds]
<companion_cube>
which is ok since it's per project anyway
mro has quit [Ping timeout: 250 seconds]
troydm has quit [Ping timeout: 240 seconds]
gentauro has joined #ocaml
gentauro has quit [Quit: leaving]
gentauro has joined #ocaml
<d_bot>
<cemerick> who's "we" there? The canonical project is looked after quite nicely by fb and js folks, but obviously it doesn't meet everyone's needs
gentauro has quit [Client Quit]
<companion_cube>
zozozo: maybe we should fork it and make an acceptable style ;)
gentauro has joined #ocaml
<zozozo>
companion_cube: that could be an interesting idea
<zozozo>
but we'd need a name for the fork
<zozozo>
ccfmt ?
<d_bot>
<VPhantom> Several people mentioned "forking", I was merely applying a subject to that.
<d_bot>
<Anurag> Supporting every additional option comes with a cost (specially if the development team is small). The OCaml format project hasn’t reached 1.0 yet so now will be the time to leave your feedback on the issue tracker to pick better defaults.
<d_bot>
<VPhantom> My issue isn't with the defaults, it's that I use several of the options being removed to get the legibility I'm looking for. The removals are already merged, just not released yet (as of 0.19). i.e. <https://github.com/ocaml-ppx/ocamlformat/pull/1898>
<companion_cube>
zozozo: :D
dalek-caan has quit [Quit: dalek-caan]
<companion_cube>
although I'm worried it's just not able technically to preserve some choices
<companion_cube>
(like parentheses)
<d_bot>
<Anurag> My point being that if an option you use is being removed, you can start a discussion about what the new default behavior should be within OCaml format. Example: <https://github.com/ocaml-ppx/ocamlformat/issues/1958>
<zozozo>
companion_cube: yeah, there's quite a few things that can't very reasonbaly be kept in the parsetree...
<companion_cube>
@anurag at this point, it's even options that are not there yet at all 😂
<d_bot>
<VPhantom> Yeah that #1900 PR is especially painful. Keeping delimiters on separate lines vs content for long lists is key to not only keeping diffs clean but also making edits easier. I hate having to do a bunch of maneuvers just to add a new last item in a list; it shouldn't be harder than inserting one mid-way.
<d_bot>
<VPhantom> I guess I should look for issues like 1958 about the 4 removals that keep me pinned at 0.19.
salkin has joined #ocaml
mro has joined #ocaml
mro has quit [Ping timeout: 268 seconds]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Anarchos has joined #ocaml
<Anarchos>
I have a strange behaviour with Unix : my server reads (Unix.read) from a socket by chunks of 8192 . It read some chunks then read a 8191 bytes chunk, and then blocks on read. I know i sent more bytes so why does it read 8191(then blocks) and not 8192 ?
<d_bot>
<cemerick> seeing (IMO) basics like align-cases (just to pick one off the top of my head) go away sends a very clear signal that the project is intended to provide a very small set of normative styles. Providing feedback in contrast to that objective would just be shouting into the wind.
<d_bot>
<VPhantom> @cemerick Oh I thought that 0.20 actually removed those options. I haven't looked at the diffs yet though. If they're still just flagged as deprecated, there might still be time to try reversing their decision. The pull requests included no explanation; it must've been documented elsewhere.
<Anarchos>
it blocks in middle of theories/Bourbaki_S4.prf
<haesbaert>
can you make the reader a netcat process as well, nc -l 127.0.0.1 5757 > /dev/null
<companion_cube>
is it possible that your server crashes because it doesn't get exactly 8192 bytes?
<haesbaert>
see if it can dump everything on a netcat listener, just to confirm it's your reader who is doing something wrong
<haesbaert>
I was the maintainer of netcat and would be surprised if there is something wrong
<Anarchos>
haesbaert i dumped with the -o /tmp/nc.traf
Tuplanolla has joined #ocaml
<Anarchos>
haesbaert it stops at 0x2e000 bytes
<haesbaert>
did you try the netcat listener ?
<haesbaert>
cause as I said the writer blocks if the reader cant keep up
<haesbaert>
ah you're using the other netcat, but still.
<Anarchos>
companion_cube sure, but i made a mess with my try/catch, i dunno if i can print every exception raised ....
rgrinberg has joined #ocaml
mro has quit [Remote host closed the connection]
<Anarchos>
what is weird is that if i change the order of files, the behaviour is correct
<companion_cube>
and all the files are the same exact size?!
<Anarchos>
companion_cube no
<Anarchos>
the S4 is the bigger then is the S3
jlrnick has quit [Ping timeout: 268 seconds]
travv0 has left #ocaml [#ocaml]
Anarchos has quit [Quit: Vision[]: i've been blurred!]
rgrinberg has quit [Remote host closed the connection]
rgrinberg has joined #ocaml
gravicappa has quit [Ping timeout: 250 seconds]
<d_bot>
<cemerick> no, the options are all there still; ocamlformat just emits deprecation warnings (which I personally don't see on a regular basis when applying formatting in vscode)
mro has joined #ocaml
mro has quit [Remote host closed the connection]
wyrd has quit [Ping timeout: 276 seconds]
mro has joined #ocaml
<d_bot>
<VPhantom> Might be worth opening a ticket then. Of my 4 vanishing options only one has an issue asking reinstatement (shared earlier in here). I keep procrastinating on it because I'll have to come up with examples with before/after to illustrate my point. 😛
<d_bot>
<VPhantom> (I'd also want to try to contribute one thing which is still bugging me, but I bet I'd just play domino and break 50 other things…)
Serpent7776 has quit [Quit: leaving]
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rgrinberg has joined #ocaml
Danishman has quit [Quit: Leaving]
<d_bot>
<monk> as an example in using `ppx_deriving.show`, how would one go about deriving a pretty printer for a basic association list of `type ('k, 'v) t = ('k * 'v) list`?
<d_bot>
<monk> my experience thus far has honestly been pretty confusing
rgrinberg has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<d_bot>
<monk> i'm just super lost as how to leverage ppx_deriving and walk away with the feeling that outside of writing the most primitive `to_string` functions, writing and deriving printers is super complicated for anything not using primitive types and hiding behind an abstract type
perrierjouet has quit [Quit: WeeChat 3.4]
perrierjouet has joined #ocaml
<d_bot>
<octachron> `type ('k, 'v) t = ('k * 'v) list [@@deriving show]` works as expected?
<d_bot>
<octachron> Aka it produces a `'a Fmt.t -> 'b Fmt.t -> ('a,'b) t Fmt.t` function.
<d_bot>
<monk> i had mine wrapped up in a module type + implementation but the gist is I would have to then write formatters for the two parametric types, right?
<d_bot>
<octachron> You will need to have a formatter corresponding to particular instance of the type parameter, yes?
<d_bot>
<octachron> The association list formatter cannot work if it doesn't know how to print neither the key nor the values.
<d_bot>
<monk> i think part of my struggle is taking type classes for granted and now struggling to understand code organization under this scenario
<d_bot>
<monk> i threw together two printers for 'k and 'v under the presumption they are string and int respectively. where would one put these printers?
<d_bot>
<monk> utility file with printers you will use across a library?
<d_bot>
<octachron> For basic types, you should really use the `Fmt` library that already defines those basic printers (and a set of useful combinators).
<d_bot>
<octachron> The stdlib's `Format` has the issue of having a horribly outdated API, and this issue is fixed by `Fmt`.
<d_bot>
<monk> thank you for that information
<d_bot>
<monk> i wish that was more widely... broadcasted
<d_bot>
<monk> i think you have told me about Fmt in passing but i had thrown that info out of my brain since now and have been on a whirlwind of trying to competently pretty-print values of my own defined types
<d_bot>
<monk> my problem was probably starting from ppx_deriving which completely skipped over "what is the best way to go about printing values from user defined types"
<d_bot>
<octachron> Yeah, I should try to start writing tutorials on that subject.
<d_bot>
<monk> i don't want you to feel responsible for my frustration but i do agree something addressing that and plastered all over the place for beginners to find would be appreciated
<d_bot>
<octachron> It is kind of the issue with starting with the boilerplate generator without having written the boilerplate first.
<d_bot>
<monk> looking at my open tabs it is clear i was jumping between 3 or so topics that were orthogonal to the primary question of "why the hell can i not manage basic printing of my module types"
<d_bot>
<monk> aaaah
<d_bot>
<monk> okay well, thank you, i can now see my association list without ad-hoc printing
unyu has quit [Quit: Reboot.]
Tuplanolla has quit [Quit: Leaving.]
perrierjouet has quit [Quit: WeeChat 3.4]
perrierjouet has joined #ocaml
<d_bot>
<monk> `Fmt` has made a big difference already, wish i came upon that sooner
quernd has quit [Quit: Ping timeout (120 seconds)]