00:15 <discocaml_> <psychokitty> Just trying to think of hacky ways to emit the relevant DEDENT tokens if one wished to parse a whitespace significant grammar. One (cursed) idea was to basically insert special tokens (at extreme cost for each line) into the lex buffer.

00:16 <discocaml_> <psychokitty> Other generators work on states (that you can change in semantic actions) and allow you to mutate the lex buffer, i.e. `yybegin` and `yypushback` in JFlex. Not saying this is good, but it makes the problem straightforward.

05:49 <discocaml_> <NULL> Why not pass the current indent level as an argument to the le er?

05:49 <discocaml_> <NULL> Why not pass the current indent level as an argument to the lexer?

07:49 <discocaml_> <psychokitty> The current indent level is something the lexer must compute.

07:54 <discocaml_> <psychokitty> In most implementations, the lexer maintains a stack of indentation levels (initially seeded with a single 0). Then, when the lexer in the "program" mode sees a newline character, it computes how much whitespace follows it. It then consults the indentation stack. If the whitespace just scanned represents a larger indent than that which is on the parsing stack, you push and remember to emit an INDENT token. If it's less than the top elemen

07:55 <discocaml_> <psychokitty> I explain this not because it's particularly relevant to OCaml or whatever, but because you can see it's a pain regardless.

07:55 <discocaml_> <psychokitty> I've found one solution on GitHub that's rather involved. Seems a decision between two evils whichever way you cut it.

07:57 <discocaml_> <psychokitty> So, the "modes" of more lex-esque implementations of lexer generators allow the lexer to complete a semantic action and immediately go into another mode. Whereas, mutually recursive rules (as in ocamllex) kind of expect to complete some work and return back.

07:58 <discocaml_> <Bozhidar> Is there any timeline for OCaml 5.1? I see that the list of changes after 5.0 is pretty big already (see https://github.com/ocaml/ocaml/blob/trunk/Changes), so I was wondering if there are any plans for 5.1 already. Lots of interesting changes coming.

08:00 <discocaml_> <NULL> If you allow a `DEDENT n` token, it seems rather fine, no?

08:02 <discocaml_> <psychokitty> Yeah, so I did that (expecting, later to basically preprocess the fully lexed file) and then feed an expanded version to menhir. The issue is that the dedents need to appear _after_ the newline.

08:02 <discocaml_> <psychokitty> So, my understanding is that I'd need a way to be able to invoke another rule in an ocamllex action, then emit two tokens.

08:02 <discocaml_> <psychokitty> The "rather involved" solution I speak of on GitHub yields lists of tokens from ocamllex to deal with this.

08:03 <discocaml_> <psychokitty> So, my understanding is that I'd need a way to be able to invoke another rule in an ocamllex action, then emit two tokens (and, if I can emit two tokens, why not `n` + 1 tokens for a `DEDENT n`).

08:04 <discocaml_> <psychokitty> I've actually kind of shelved this for now, resolving to just write a handwritten lexer if I get back around to it. Although, I do wonder if it's really so bad producing lists from the lexer and then feeding menhir the individual sublists' tokens.

08:06 <discocaml_> <psychokitty> Oh, yeah, the solution I gave of yielding two tokens (newline + indent/dedent) would also need to advance the internal lex buffer beyond the whitespace for the next munch, so it still suffers from that limitation.

08:42 <discocaml_> <NULL> There's another slightly ugly solution which is to shadow your entry point into a function which stores its state (and as such tokens to return before calling the main function)

13:08 <discocaml_> <lukstafi> Does anyone recall discussions of a `Typedtree` pass for PPX? I'm asking in the context of the sorry state of OCaml debugger. Hoping for `[%debug_this ...]` expressions that print the state of the local environment.

13:13 <discocaml_> <octachron> This is mostly a dead-end. Types don't exist at runtime, your `[%debug_this ... ]` function cannot work on any polymorphic functions.

13:14 <companion_cube> The debugger is also a bit of a dead end, sadly, so we don't have any good solution

13:19 <discocaml_> <lukstafi> My `[%debug_this ...]` function would only exist at compile time. At runtime, there would only be `printf` statements.

13:21 <discocaml_> <lukstafi> I don't accept this answer. I don't want to live in the dark ages anymore (after writing some code in Python and TypeScript). Maybe I try resurrecting `ocamlearlybird`...

13:24 <discocaml_> <octachron> @lukstafi , you don't have the information to have accurate `printf` calls at compile time.

13:25 <discocaml_> <octachron> OCaml is a functional language, you cannot assume that all functions are monomorphic.

13:26 <discocaml_> <lukstafi> What about at the time `Typedtree`s are constructed? In any case, if Merlin can know the types, they must exist.

13:28 <discocaml_> <lukstafi> Monomorphic and single-threaded is good enough for debugging conceptual issues. (That's my use-case, not tricky code fortunately.)

13:28 <discocaml_> <octachron> Merlin knows the type schemes.

13:30 <discocaml_> <octachron> Sure, you can have a debug printer for monomorphic functions but then:

13:30 <discocaml_> <octachron> - users can call the printer with the type too

13:30 <discocaml_> <octachron> - you are covering a small part of the language without any possibility of evolution, aka a dead end.

13:31 <companion_cube> What is the non dead end solution? Dwarf support?

13:31 <discocaml_> <octachron> Corrections with monomorphic functions with no abstract types without an exported printer.

13:33 <discocaml_> <octachron> Probably, dwarf support with exported runtime type information in the native compiler.

13:35 <discocaml_> <octachron> Maybe dead-end is a bit too strong. Maybe more `local maximum with no path forward toward the global maximum`.

13:36 <discocaml_> <dariusf> you could try https://github.com/dariusf/ppx_debug, it does what you're describing by getting the types from cmt files during the build. But yes it doesn't work with polymorphic functions and expects that printers are available and follow certain conventions

13:36 <discocaml_> <dariusf> Just curious, what do you think about ocamldebug, is there a path forward by improving it?

13:37 <discocaml_> <lukstafi> Thank you, I wasn't aware of it! Helpful! (Should have googled, dang.)

13:42 <discocaml_> <octachron> Possibly? At the very least, I have the impression that there is room for improving ocamldebug tool integration and user experience? And it is not clear to me if such improvement could be transferred or not to an eventual native debugger.

13:47 <companion_cube> As long as ocamldebug is stuck in bytecode only, imho, it'll remain of very limited usefulness.

13:47 <companion_cube> Being compatible with gdb, rr, etc would be immensely better

13:48 <discocaml_> <lukstafi> If something like `ocamlearlybird` worked out of the box, I would mock the parts of my program that require to be run natively, for debugging.

13:49 <discocaml_> <NULL> I wouldn't be so sure; how often do programs need to run natively, how many people want compatibility with other languages' tools ?

13:50 <companion_cube> Hmmm, everyone? :D

13:50 <discocaml_> <NULL> I can at least tell you I don't

13:50 <companion_cube> Everyone compiles to native, afaik. And basically anyone who comes to ocaml from another language will expect gdb/lldb to work

13:51 <discocaml_> <NULL> I don't "compile to native", I run dune

13:51 <companion_cube> Ofc we're so used to not having a working debugger that we don't see it this way

13:51 <companion_cube> Dune will run in native mode by default...

13:51 <discocaml_> <NULL> If dune provides debuggable compiled files with a flag, that's good enough for me

13:51 <discocaml_> <masterbuilder> I was not expecting gdb to really work at all so I think what is available already is a good start, not really fully usable yet though

13:51 <companion_cube> Bytecode doesn't even have consistently good stack traces

13:52 <discocaml_> <NULL> (Does dune build compile to native ?)

13:52 <companion_cube> Yes

13:52 <companion_cube> Of course it does :/

13:52 <discocaml_> <masterbuilder> there is a flag you must set to enable bytecode compilation

13:52 <companion_cube> It'd be pretty useless otherwise

13:52 <discocaml_> <masterbuilder> or configuration option rather

13:53 <discocaml_> <NULL> That tells how much I care of the compilation mode

13:56 <discocaml_> <lukstafi> @dariusf is there a roadmap to get `ppx_debug` to `opam`? If I could help, I think I could find some time.

13:58 <discocaml_> <lukstafi> @dariusf is there a roadmap to get `ppx_debug` to `opam`? (ETA: I mean to the public repository.) If I could help, I think I could find some time.

14:05 <mclovin> The next OUPS meetup will be on the 16th of march https://discuss.ocaml.org/t/oups-meetup-march-2023/11470

14:12 <discocaml_> <dariusf> not atm. it was more of a proof of concept, and i haven't found anyone else wanting to use it for real yet 😄

14:20 <companion_cube> @NULL if it was bytecode, you'd heard dozens of times "careful, use such and such flag to get decent perf"

14:22 <discocaml_> <NULL> What's the difference when `--profile=release` then ? Is it just that warnings aren't considered errors ?

14:24 <zozozo> @NULL iirc, in the dev profile, things are compiled with opaque to limit cross-module optimisations so as to make compiling things faster

14:25 <companion_cube> Release will enable cross module inlining and so on, at the price of slower compilation and worse modular compilation (ie changing a module will sometimes recompile the module's dependents)

14:25 <discocaml_> <dariusf> is performance the main problem with bytecode?

14:25 <companion_cube> So it's better, but afaict the gap between bytecode and native is generally a lot wider

14:25 <companion_cube> Especially since there are few optimizations with bytecode

14:28 <discocaml_> <dariusf> seems like that could be somewhat mitigated by mocking as @lukstafi said. though i agree having to modify code to debug it is a pain

14:55 <discocaml_> <lukstafi> `ppx_debug` is great! (At least on paper, I'm having some build issues.) It has to be better advertised!

15:49 <discocaml_> <Alistair> OCaml meetup in london when?

15:51 <discocaml_> <Alistair> (In all seriousness I'd love to help organise some form of OCaml meetup in London -- perhaps we can get some help from some of the London-based OCaml companies like JS / TriliTech / Meta?)

15:59 <Armael> you could also contact the ocaml fundation, I think they have funding for that kind of things

16:33 <discocaml_> <RegularSpatula> Has anyone tried this for debugging https://github.com/dariusf/ppx_interact ? Still needs bytecode, but looks neat

21:14 <technomancy> is there a way to open a TCP server socket without bringing in any 3rd-party libraries?

21:14 <technomancy> I'd settle for libraries from apt in a pinch

21:53 <companion_cube> With the unix module you can

21:53 <companion_cube> With listen/accept

21:54 <technomancy> oh cool. not sure why the search engines were having a hard time with that, but thanks

22:01 <companion_cube> It'll return FDs, not channels, so you can remake them into channels if you want the buffering

23:57 <technomancy> https://github.com/ocaml/caml-mode given that the readme recommends upgrading to emacs 19, I'm assuming this is hilariously outdated?