IRC channel logs


back to list of logs

<ArneBab_>Arsen: I already used guile scripting in Makefiles — though only once for now.
<Arsen>ArneBab_: what do you use it for
<lilyp>guile scripting is quite nice for doing stuff that make can't, specifically listing files with spaces
<lilyp>though you get funny bugs with reification, so watch out for those
<attila_lendvai>if i have a tail call within a fiber, will that be optimised away, or will that ever-consume stack space?
<attila_lendvai>if the latter, then what construct shall i use to get rid of the tail call?
<lilyp>you could use trampolines, but TCO is a language requirement in Scheme. I don't see how fibers would interfere with that
<lilyp>The fibre itself will of course need whatever stack it requires, but that should not be an issue imho
<attila_lendvai>lilyp, not sure i fully understand everything here. what i'm doing is i start a long-living fiber in schepherd that talks to the daemon that shepherd starts up. this means basically reading and writing through a pipe to the daemon's stdio. this fiber is using tail calls to loop. what i observe (not necessarily due to this) is that the shepherd process uses gigabytes of memory after a few days.
<attila_lendvai>i'm looking for the bug, and/or means to debug this memory leak
<attila_lendvai>debugging such an issue is probably non-trivial... therefore i'm trying to experiment with some wild guesses first.
<lilyp>Hmm, given that Guile is garbage-collected, it'd mean that Shepherd still holds references to lots of stuff declared within those sessions
<lilyp>this could mean that either your tail calls aren't true tail calls or that the argument lists are growing among other things
<lilyp>it could also mean that shepherd itself is leaking memory in the service or elsewhere
<lilyp>for the tco hypothesis try inspecting the stack
<lilyp>if that grows, with each call, you got a bug in your code
<attila_lendvai>lilyp, this is the looping part of the fiber:
<haugh>attila_lendvai, have you tried using (shepherd comm) instead of maintaining a stdio pipe? No idea if it meets your needs but it's probably worth a look
<attila_lendvai>haugh, i don't know what it is, i'll look into it
<wingo>that is not a tail call
<wingo>it's tail relative to the function that for-each calls
<wingo>but not relative to the loop
<attila_lendvai>wingo, oh, thanks! then i'll retreat to think harder...
<attila_lendvai>ACTION also reevaluates his confidence in his understanding of tail calls
<wingo>well just consider that the continuation of your match-lambda is inside for-each, not the continuation of loop
<wingo>you could expand out for-each by hand in another little loop to see that this is the case
<attila_lendvai>haugh, i think (shepherd comm) is not appropriate here because the language that the daemon speaks is not under my control.
<attila_lendvai>wingo, i looked at the definition of for-each, and it also seems to be tail-called. i thought that somehow this setup would retain the tail-call property, because the for-each is also in the tail position (although, i recorded my suspicion in a comment)
<wingo>guile's for-each looks like this inside:
<wingo>(let for-each1 ((l l))
<wingo> (if (not (null? l))
<wingo> (begin
<wingo> (f (car l))
<wingo> (for-each1 (cdr l)))))
<wingo>the call to f is not in tail position, as you can see
<wingo>same for srfi-1 for-each
<attila_lendvai>the manual also notes that "a lot of places which could potentially be tail calls, for instance the last call in a for-each, but only those explicitly described are guaranteed." in
<wingo>ACTION wishes string-every / string-any did not specify that tail property
<wingo>attila_lendvai: it would certainly be possible to run the last application in a for-each in tail position but it would make for-each larger and a bit slower
<wingo>& doesn't buy you much. so guile's for-each is unlikely to change in that way
<attila_lendvai>well, i've learned not to expect tail-call-ness beyond that list, so i'll need to use my own construct anyway if i want to be sure
<attila_lendvai>wingo, on another note: i have a solution for the fibers issue that it triggers a guile deprecation warning (
<attila_lendvai>wingo, it's a pity that cond-expand doesn't have an API where the condition can be any form. my solution involves adding a cond-expand* that eval's the condition at macroexpand-time
<attila_lendvai>do you think that 1) cond-expand's API may ever change in guile? or 2) cond-expand* may be added to guile? or 3) shall i open a PR for fibers that adds cond-expand* as a local utility and uses it to resolve the issue?
<attila_lendvai>wingo, i've commented this on
<wingo>i would really love integration for guile
<sneek>Yey! mwette is back
<mwette>sneek: botsnack
<old>wingo: there's alternative that are not developed by Google and well known in the community
<wingo>are they better?
<old>maybe not for Android
<old>for Linux yes
<wingo>anyway what would be needed isn't integration with google, it would be for guile to produce traces in a format that perfetto (or chrome dev tools, or whatever) could read
<old>then produce CTF
<old>Common Trace Format
<wingo>right right
<old>Disclaimer, I work for the compagny that maintain it
<wingo>neat :)
<flatwhatson>does anyone have a multipart/form-data implementation for (web request)?
<wingo>what's the name of the thing you are recommending instead?
<old>It's support by TraceCompass (Eclipse IDE for trace analysis)
<old>and Babeltrace for converting CTF to anything you want
<old>Depdends on what you want. For generating traces, the best tracer in userspace is lttng-ust
<old>For analyzing, I would go with Babeltrace+TraceCompass
<old>If you have Guix, have a look at gnu/packages/instrumentation.scm, I have packaged most of the things. There's only TraceCompass missing I think
<old>that's the standard of v1.8.3
<old>Version 2 is under draft I think
<old>found it
<ArneBab_>Arsen: I had a check that was hard to write directly in the makefile so I turned to guile where I had more libraries available.
<ArneBab_>flatwhatson: I have a form-data parsing for uploads:
<ArneBab_>flatwhatson: it’s just doing it manually, though.
<Arsen>ah, I see
<mwette>I felt guile-in-make would be really useful if the internal structure was available, so you could write guile code to muck with the dependency tree, etc.
<Zelphir>Isn't there such a thing already? Being able to use Guile in Makefiles? I thought I had seen something like that. Maybe just Guile functions in some places in the Makefile? Not sure.
<mwette>$(guile) in a Makefile is in the same spirit as the $(shell), if I'm not mistaken
<mwette>I don't think you can write guile code to replace the line `target: dep1 dep2'
<old>You can actually embed Guile code in Makefile that generate rules
<flatwhatson>thanks ArneBab, i'm implementing it for sending uploads from the client side, and it seems like manually constructing the body is the way
<mwette>evaluated at Makefile compile-time or run-time?
<Arsen>like $(shell), make-time
<jlicht>Does anyone know how to do a HTTP GET using guile’s web client that supports utf8 (emoji) in the response? I feel like I’m holding it wrong :)
<darth-cheney>Hello all. Anyone aware of a way to interact with the OS's location services through Guile?
<unmatched-paren>darth-cheney: i think you'd need to use dbus in some way
<unmatched-paren>(try ac-d-bus)
<cwebber>check it out check it out
<cwebber>a time traveling distributed debugger for Spritely Goblins!!! by dthompson!
<drakonis>oh its finally here
<dthompson>yup, it's the first usable version. much more to come!
<qookie>how do you take only parts of the a list pattern variable? as in, for example, taking only the first expr of "body" from pattern "(_ n body ...)"
<qookie>the idea i had is to make syntax that translates to "(begin ,@(take body n) (let ((out ,@(list-ref body n))) (begin ,@(drop body (+ n 1)) out)))" (using unquote-splicing for the lack of a better term here)
<qookie>like a generalized version of prog1 & prog2 from elisp (evaluate all exprs in order, but result in the value of the nth one)
<jpoiret>qookie: you will want to use (_ n body rest ...) instead :)
<jpoiret>one thing to remember (it took a long time to click for me) is that pat ... will match pat 0 or more times
<qookie>jpoiret: well that works for prog1, but still doesn't help me generalize for selecting any specific expr out of the given ones
<qookie>although when writing that question i got a different idea for how this could be done
<jpoiret>i don't really understand what you're trying to do with the syntax though
<jpoiret>what does the n refer to?
<qookie>(progn 2 x y z w) evaluates x, y, z, w in order, and yields what z evaluated to
<jpoiret>oh right
<qookie>n being the index of the expr to yield the result of
<jpoiret>well, you can make the syntax transformer recursive in the n, and if n = 0 you just do (let ((out #,body)) (begin rest ... out))
<qookie>oh hmm yeah i could recurse
<jpoiret>if n>0 then just do (begin body (progn #,(- n 1) rest ...))
<qookie>thanks for the idea, i'll try making that work
<jpoiret>my syntax-quote game might be off here but you get the idea
<qookie>yeah, thanks
<qookie>okay i got it working
<qookie>thanks again jpoiret
<jpoiret>ohhh, that works but was not what I had in mind (the generated code will be quite inefficient)
<jpoiret>let me write it down
<cwebber>qookie: I like the domain name of that pastebin