06:11 <discocaml> <speeddart> What would be the best libraries to assist in writing a sever that uses both websocket connections and good ol http requests (with either html or json response)?

06:20 <companion_cube> dream I guess?

08:43 <greenbagels> mmmmm

08:45 <andrzejku> hello

08:45 <andrzejku> :)

08:46 <greenbagels> so im writing a function to take a list and make a list of all pair-wise combinations of elements of the list

08:46 <greenbagels> so like [1; 2; 3] -> [(1, 2); (2, 3); (1, 3)]

08:47 <greenbagels> the first solution that comes to mind is just to like, map each element to a list like [1; 2; 3] ↦ [[(1, 2); (1, 3)]; [(2, 3)]; []]

08:48 <greenbagels> and then flatten

08:48 <greenbagels> would this be... bad for long lists?

08:49 <greenbagels> since it would take linear stack space

08:50 <greenbagels> (but it has a very simple implementation so its tempting)

08:52 <greenbagels> sorry not linear stack space, quadratic stack space*

08:55 <greenbagels> i guess the solution is just to define a tail recursive flatten myself

09:45 <greenbagels> and... it turns out that i didnt need to do that anyway :)

10:34 <neiluj> Hi! Just finished writing this notebook to show how to use an ocaml library on a example: https://github.com/jtcoolen/ocaml-pari/blob/main/examples/pohlig-hellman.ipynb! Is it understandable?

11:24 <discocaml> <commutativeconjecture> for type systems, you can often be "macro based" or "symbolic". like, if you think of polymorphism: you can implement it in the OCaml way, where type parameters in type polymorphic expressions are treated symbolically. this lets typecheck a fully abstract / non-instantiated polymorphic expression. but you could also do it C++ template / C macros style, where you only type check ground terms, once polymorphic expressions have bee

11:26 <discocaml> <commutativeconjecture> i'd like to have a systematic study of those two approaches. typically, i'd like to go for a lang with a rich and strong type system on ground terms, but macro-based approach for its polymorphism, row polymorphism, static evaluation, etc.

11:26 <discocaml> <commutativeconjecture> any idea of things i should look for to find out more about these?

11:27 <discocaml> <commutativeconjecture> (i'm also interested in mixture of these. like, you already perform some checks on polymorphic expressions, but can find out more errors when applying types to them)

13:12 <discocaml> <froyo> re runtime in c: another good advantage of having it in c is being able to run ocaml on platforms it doesn't target natively, like plan9

13:13 <discocaml> <froyo> you could maintain two separate runtime codebases but why

14:05 <discocaml> <speeddart> Does dream have websockets extension? Couldn’t find

14:39 <discocaml> <speeddart> Looks like it’s the sort of thing that would be in a different package anyways

14:41 <discocaml> <speeddart> Websocket-lwt-Unix?

15:05 <greenbagels> hmm

15:05 <greenbagels> is it better to profile bytecode first instead of native code? or is it a kind of apples to oranges kinda comparison

15:06 <greenbagels> the example perf output on https://ocaml.org/docs/profiling seems to indicate a large portion of output lines might just be internal gc functions

15:13 <greenbagels> oh

15:13 <greenbagels> i guess that page is out-of-date

15:25 <companion_cube> Don't profile bytecode, it's slow and non optimized anyway

15:25 <companion_cube> If you care about perf, profile the native version, compiled in release mode

15:29 <greenbagels> companion_cube: ok so question: im using ocamloptp to generate profiling data; but is there a tool that prints not just execution counts for code paths, but samples time spent in each path?

15:29 <greenbagels> i see that the -p flag no longer exists (i think i read a message saying after 4.08?)

15:29 <companion_cube> Hmm for paths in the code I don't know

15:29 <companion_cube> Just use perf

15:29 <companion_cube> If you're on Linux :)

15:36 <discocaml> <froyo> honestly perf kinda sucks with ocaml... like I know we got demangling support upstream and all that and tried to make it work nicely but... it still sucks and misleads a bit especially with higher order functions involved and the like

15:37 <discocaml> <froyo> imagine a world where we have a first-class native ocaml profiler & debugger

15:38 <discocaml> <froyo> perf would be what I'd use today though yeah

15:39 <discocaml> <froyo> for gc stuff I think olly looks cool but haven't tried it personally

15:44 <greenbagels> demangling with perf? does perf show internal symbol names, not just external ones?

15:45 <discocaml> <commutativeconjecture> in the same vein, what is the recommended way to debug code in ocaml end-of-2023?

15:46 <discocaml> <froyo> greenbagels: demangling as in `camlExample.function_name_421_332` becomes `Example.function_name`

15:47 <discocaml> <froyo> runtime names do show in the report yes

15:47 <discocaml> <froyo> if that's what you mean by internal

15:48 <companion_cube> Debugging is still hard

15:48 <discocaml> <commutativeconjecture> sad, but thx for update

15:48 <companion_cube> I use tracing tools and instrumentation but it's a personal preference

15:48 <discocaml> <commutativeconjecture> i do ppx show + printf every where + git reset --hard

15:49 <discocaml> <froyo> hahaha classic git reset hard

16:05 <discocaml> <bluddy5> IMO this is OCaml's biggest weakness in 2023

16:19 <companion_cube> Lack of debugger? Perhaps, yes

16:20 <companion_cube> That, or the really complex tooling

16:21 <discocaml> <bluddy5> The tooling is ok. Lack of debugger is painful. I'm so much more efficient in python just because I can step to a particular place in the code and examine exactly what's going on.

16:21 <discocaml> <bluddy5> or in c++ etc

16:26 <companion_cube> Tbh when I write rust I still don't use a debugger... Probably because I'm not used to it

16:45 <discocaml> <._null._> One can use ocamldebug on Coq, and I am very grateful for that

16:46 <discocaml> <._null._> It's also the only reason I use emacs

19:00 <discocaml> <functionalprogramming> i dont think the the C++ template parameter-substitution is very interesting

19:02 <discocaml> <functionalprogramming> i would not call it "macro-based"; it is just monomorphization. I think Golang (used to?, before Go generics were a thing) have a similar thing where its just a codegen tool

19:04 <discocaml> <functionalprogramming> why

19:04 <discocaml> <functionalprogramming> why wouldnt you want all the checks so that there is no "substitution failure" and no chance of finding more errors if specializing

19:28 <companion_cube> It's hard to have checks powerful enough for what people use templates for

19:28 <companion_cube> You'd need a very avanced type system

19:54 <discocaml> <commutativeconjecture> because the world is made of trade-offs. the more powerful i want the static things to be, the _even more_ powerful a type system that covers them needs to be. it becomes less of a type system, and more of a general automatic theorem prover about the behaviours of codegen programs.

20:19 <companion_cube> Also see how rust is not fully caught up to C++'s templates

20:25 <discocaml> <functionalprogramming> ah

20:25 <discocaml> <functionalprogramming> idk what u want but sounds fun

20:27 <discocaml> <contificate> let's hope it doesn't catch up

20:32 <discocaml> <commutativeconjecture> ~~fundamentally, all i want is coc + type:type~~

20:54 <companion_cube> Not trying to rain on your parade but doesn't coc mean you need both compile time evaluation, and some notion of erasure?

22:28 <discocaml> <speeddart> I am new to OCaml, are there absolutely no debuggers? Or no hood ones?

22:28 <discocaml> <speeddart> I am new to OCaml, are there absolutely no debuggers? Or no good ones?

22:28 <discocaml> <._null._> There is ocamldebug which comes with the compiler, but it doesn't have support in VSCode

22:29 <discocaml> <._null._> It has a gdb-like interface

22:29 <EmoSpice> Good evening - I have a dune project I am building with nix. It is failing because I dont have git in the install phase ("Error: program git not found in the tree or in PATH"). Can someone explain to me why dune is looking for git?

22:29 <discocaml> <speeddart> Ah ok

22:29 <discocaml> <speeddart> At the very least, I would think you need a debugger less often in a functional language

22:31 <EmoSpice> (Google/DDG has been particularly unhelpful here, but I can confirm that the command run immediately before failure is a `dune install` invocation)

22:43 <greenbagels> are List.rev_merge and List.rev_merge_rev child functions of List.rev

22:44 <greenbagels> oh no, its in stable_sort

23:48 <discocaml> <leostera> when using `Effect.Shallow.discontinue_with`, it seems like I can't match on the exception and continue executing with the same effect handlers 🤔

23:48 <discocaml> <leostera> maybe that's not right, the effects I'm performing aren't failing with "unhandled"

23:48 <discocaml> <leostera> but they don't seem to be doing anything