<LarstiQ>
On the third iteration through the loop, path evolves from `(null)`, to `layout.scm` to `"[UUU\005"` garbage
<LarstiQ>
getenv("XDG_CONFIG_HOME") gives 0x0
<LarstiQ>
right, that's because the previous free leaves it at that, and then the NULL comparison will fail. So I suppose it should be set to NULL after the free?
<LarstiQ>
yeah, now it works
notzmv has quit [Ping timeout: 256 seconds]
<leon-p>
LarstiQ: someone reported that bug already a few days ago, I just haven't gotten around to it
<LarstiQ>
alright, I just did `path = NULL;` after that free on line 378 (and changed the if to a {} block)
notzmv has joined #river
<LarstiQ>
heh, when riverguile crashes in the middle of a layout command some windows go missing
<LarstiQ>
nice bbit of visual feedback for my learning of scheme ;)
Guest35 has joined #river
Guest35 has quit [Client Quit]
leopoldek has quit [Remote host closed the connection]
<leon-p>
figured out how to enable auto-compilation of the layout scripts for riverguile. this should make things a bit faster on startup and on the first user-command. Also macros should work as expected now.
<leon-p>
will probably change the API a bit though. I think I'd prefer (install-layout-demand-handler (lambda (...) ...)) over (define layout-demand-handler (lambda (...) ...))
<LarstiQ>
I have a vague idea what lispish macros are (I do know them from Rust and C of course), should I read up on them in the Guile docs or is there a better source?
<LarstiQ>
in the basics, code-generating-code
<leon-p>
guile docs are nice IF you already know the basic 5%
<leon-p>
otherwise read third-party docs
tiosgz has joined #river
<leon-p>
you don't need to know macros for riverguile though. The issue was that sometimes you'd need to use let* (defined in the C base IIRC) even if let (defined as a macro IIRC) would have been enough
<leon-p>
this was because macro expansion apparently doesn't work as well in scm_c_primitive_load(), which only eval's and doesn't compile
<leon-p>
by calling load-from-path instead, we get proper boot module loading and auto-compiling
<tiosgz>
leon-p: if it changes into (install-... (...)), is there a simple way to debug the layouting?
<tiosgz>
actually, i can just have the function separately and then just install it, right? (silly me)
<leon-p>
I mean, there never was a simple way, but you can just (define handler-impl (lambda ...)) (install-handler handler-impl)
<tiosgz>
by simple way i meant feeding it stuff and checking the output /of course/ :P
<leon-p>
eventually Someone™ could create a graphical application that loads the script and let's you play around with coloured rectangles on a canvas for testing
<tiosgz>
ooh, or... run a nested session of river with riverguile and let you play with terminals, right? ... right?
<leon-p>
yeah, that would also work
orfeas194 has joined #river
<leon-p>
and it works. On my ancient laptop there was a short delay when running the first user command, I guess because the VM had ignored the functions called from there? Now with auto-compiled layout scripts it's gone. Nice
<LarstiQ>
cool!
<LarstiQ>
how does it handle compilation errors? I got some obscure tracebacks and crashes when I had `(remainder not-actually-an-int int)` iirc
<LarstiQ>
or hmm, maybe that was the dynamic crash
<LarstiQ>
I also had some invalid syntax
<leon-p>
scheme errors are handled by the normal guile error handling mechanisms
<LarstiQ>
it will keep running the previous correctly-compiling version of the layouts? (assuming it's not at startup)
<leon-p>
No. it will abort the load process. Which in turn means layout-demand-handler is never set, which causes riverguile to exit
<leon-p>
at least that's what's supposed to happen