IRC channel logs
2024-02-05.log
back to list of logs
<apteryx>and syntax-source is only available on syntax objects, so at the time we define syntax? <old>I wondered something. Continuation in guile are implemented in term of longjmp IIRC. The C standard says that longjmp forward (as in restartable continuation) are undefined behavior <old>how dow guile guarantee such behavior though? By copying the stack? <wingo>guile continuations (of the undelimited kind) do copy (and reinstate) the c stack <old>what about delimited continuation? <old>also this require some modification to the jmp_buf environment to point to the copy address I suppose <old>which, require internal libc knowledge about the implementation <wingo>delimited continuations just copy/restore the managed guile stack <wingo>(undelimited continuations also copy the managed guile stack) <old>Is copying really necessary? For example in fibers if doing rescheduling, just swapping the stacks ought to be enough? <wingo>not too much nastiness with longjmp because reinstating restores the c stack at the same address it was originally <wingo>old: it is necessary if you want to support calling the captured continuation multiple times <wingo>for fibers (and every other use i have had for delimited continuations), once is enough; but copying is not so bad i think <old>I guess it depends on the amount of memory pressure on the process. <old>e.g., if lots of syscall are been made so ask for more memory in order to do the copy, that slowdown the scheduler <old>Anyhow, still lower than kernel scheduling I suppose <wingo>fibers are v small, no syscalls involved <old>right. But copying the stack _might_ do a syscall in libgc <wingo>like, what is the rate at which you suspend fibers? and what is the size of the continuation at suspension points? say you suspend at 10kHz per core, run 32 cores, and each continuation is 2kB. that is an allocation rate of 640MB/s. high, but your GC should be able to support that <old>if memory chunk big enough is not available <wingo>but probably you don't suspend at that rate; some fibers will run to completion without suspending at all. depends on your program <old>It mostly depends on the synchronization or preemption if any <old>so if copying is not a bottleneck for fibers, would it be feasible to call into C? <old>like calling a FFI in a fibers thread <old>or would that break the copying of the stack when rescheduling due to preemption for examlpe <wingo>fibers never copies the c stack <old>okay so you are bound to stay in scheme <old>if there's preeption. If not, I guess you are free to do so <apteryx>can we do optional arguments or keyword arguments with GOOPS' define-method? <janneke>apteryx: mweaver wrote a patch for that which i'm carrying <apteryx>the classic solution would be to use multi-method with different signatures I guess <apteryx>though I suppose that's annoying when working with generic methods in a library, as that mean we're now assuming downstream users will customize (override) both signatures <apteryx>what's the classic output format to have emacs understand source location? $filename:$line:$column ? <janneke>apteryx: yep -- see standards.texi 4.4 Formatting Error Messages <janneke>i guess :$column is optional, but :message is mandatory (and thus, in your example, $column will be interpreted as message, and point will be placed at column 0) <apteryx>ACTION is adding support for source properties to guile-lib's logging library <apteryx>sample output: 2024-02-05 18:35:55 guix/derivations.scm:272:16: (debug): adding input #<<derivation-input> drv: #<derivation /gnu/store/9bykbb5khbsa3mk6wvfn3p7amgfngrmw-grep-mesboot-3.11.drv => /gnu/store/l3jcx4xwr4031hk40hwl77zhzshd9jf3-grep-mesboot-3.11 7f021e2ca550> sub-derivations: ("out")> to list <apteryx>it'd be nice to have the calling procedure name, as Python's logging library can do, but I'm not sure how to do this in Guile <apteryx>daviid: I've sent a small series for Guile-Libs' logging library; you are in CC. Don't hesitate if you have any question. <rekado>roptat: the gitile process grows in memory on every request I tried, even when only 404 is returned. My guess is that the “projects” procedure might be leaky. <civodul>oh i wanted to ask Arun about Gitile support in Guix-Forge :-)