08:35 <olle> Is anyone using the effect system for _all_ side-effects? Or only for concurrency/parallelsim?

08:35 <olle> Maybe better to ask on the forum.

09:16 <discocaml> <contificate> I hope not, lol - effectively amounts to obfuscation to do this if there's no effect safety/typing

09:16 <discocaml> <contificate> theoretically, not all side effects can be done with one-shot continuations

09:17 <olle> hm what could not be done that way?

09:18 <discocaml> <contificate> well, people usually note that most monads of note are tail resumptive - so can be done with one-shot delimited control

09:18 <discocaml> <contificate> others though, which involve invoking `k` twice - maybe some non-determinism tricks, would require some extra engineering

09:18 <olle> k?

09:18 <discocaml> <contificate> the continuation of the handler

09:18 <olle> oh

09:18 <discocaml> <contificate> I don't really believe in an "effect" system without safety

09:19 <discocaml> <contificate> what we have is a lightweight delimited control facility

09:19 <olle> that can be nicely abused.

09:19 <discocaml> <contificate> "nicely"

09:19 <olle> ^^

11:52 <discocaml> <drupyog> Are stack fragments on the heap since 5.0 ? They don't seem to be included in Gc.stat.heap_size.

11:54 <discocaml> <drupyog> Are stack fragments on the heap since 5.0 ? They don't seem to be included in any of Gc.stat's mtrics.

11:54 <discocaml> <drupyog> Are stack fragments on the heap since 5.0 ? They don't seem to be included in any of Gc.stat's metrics.

11:55 <discocaml> <drupyog> and if not, is there *any* way to evaluate stack usage nowadays ?

11:59 <discocaml> <drupyog> originally I though Memprof would record stack usage, but I'm not even sure now

12:26 <discocaml> <shalokshalom> How do you think about effect systems vs The Elm Architecture?

12:29 <olle> I'm curious about that too

12:29 <olle> Don't know much about Elm

13:44 <discocaml> <drupyog> @octachron do you have any idea ? 😦

13:45 <discocaml> <drupyog> @octachron do you have any idea (or if I should ask somewhere) ? 😦

14:16 <discocaml> <contificate> It's made even more fun by the fact that calling C functions from OCaml 5 will pivot the stack (back to the system stack) - so there's 2 stacks to worry about (one being a cactus stack).

14:17 <discocaml> <contificate> I vaguely recall some discussion before about his - concerning flame graph collection using `perf` - I can't remember the exact conclusion.

14:17 <discocaml> <contificate> I vaguely recall some discussion before about this - concerning flame graph collection using `perf` - I can't remember the exact conclusion.

14:37 <discocaml> <sim642> I remember reading that OCaml stacks are on the OCaml heap indeed. And that it effectively removes stack overflows

14:39 <discocaml> <contificate> Yeah, that is often said in the context of dissuading people from the fun parlour trick of doing CPS conversion (as people did in OCaml 4) to make any function tail recursive (accumulating continuation closures on the heap as the stack frames)

14:39 <discocaml> <sim642> But continuations make the notion more confusing too: performing an effect and handling it outside and then continuing back in the deep

14:40 <discocaml> <contificate> well, the frames are never copied - so that "continuing" back/relinking of frames is adjusting a pointer

14:41 <discocaml> <sim642> Indeed and that makes it harder to measure "the" size of "the" stack

14:41 <discocaml> <sim642> Because there's a bunch of fragments lying around

14:42 <discocaml> <sim642> But maybe that's irrelevant in @drupyog 's case

14:42 <discocaml> <contificate> I don't think it makes it much harder, given that not `discontinue`ing `k` does not amount to leaking the fiber itself

14:43 <discocaml> <contificate> in other words, there must be a way to track it all - the problem is whether random outside profiling tools expecting to basically work with `rsp` and DWARF info can cope (e.g. perf)

14:43 <discocaml> <sim642> I think I recall that those should work still

14:44 <discocaml> <contificate> lots of profiling tools are just sampling

14:44 <discocaml> <contificate> so this idea of collecting many fragments isn't the default perspective

14:44 <discocaml> <contificate> you could do such a profiler by vibecoding `perf_event_open` and sampling the register holding the domain table/caml state

14:50 <discocaml> <sim642> Section 5.5 describes the DWARF unwinding for fibers

14:51 <discocaml> <sim642> Section 5.5 in the effects paper describes the DWARF unwinding for fibers

14:52 <discocaml> <contificate> then it comes down to asking which profiling tools currently work out of the box

15:06 <discocaml> <octachron> My rough understanding is that OCaml is not using system stack, but its own stacks on the heap. Fibers (stack fragments) are then stored on the heap, with a separate cache for reusing them. But as far as I can see, stack usage is not instrumented (there is at most a GC debug event when allocating new stacks). And it seems that I might have been wrong in thinking that fibers were garbage collected.

15:23 <discocaml> <sim642> My impression was that they would be GC-d but discontinue is more for triggering them to release external resources

15:37 <discocaml> <octachron> Seeing as my test that was just looping and raising an effect ended up OOM-killed in seconds; while adding a finalizer to a wrapper around the continuation works, this doesn't look like it is the case.

15:37 <discocaml> <contificate> There's a telling quote from the paper

15:37 <discocaml> <contificate> > It is also useful to note that even if the memory

15:37 <discocaml> <contificate> > for the fiber stack is managed by the GC, we would still need

15:37 <discocaml> <contificate> > a finalisation mechanism to unwind the stack and release

15:37 <discocaml> <contificate> > other system resources that may be held by the continuation.

15:38 <discocaml> <contificate> they show this `Gc.finalise` resumption thing in the paper, too

15:40 <discocaml> <octachron> @drupyog , going back to your question adding a statmemprof events for stacks allocation/reallocation/freeing looks reasonably easy to do.

19:20 <discocaml> <drupyog> mmh, do you have pointers ?

19:22 <discocaml> <octachron> The stack allocation functions are in runtime/fiber.c

19:22 <discocaml> <drupyog> (also, stack overflow definitely still exists in 5.0 :p)

19:30 <discocaml> <drupyog> ok, I will attempt something

19:47 <olle> Hm why this cermony of open both Effect and Effect.Deep?

19:54 <olle> Ah nevermind

20:06 <discocaml> <deepspacejohn> I don’t think there’s much of a reason to open either, IMO

22:05 <olle> It's from the manual