IRC channel logs

2024-09-23.log

back to list of logs

<cow_2001>someone wrote a thing about guile's srfi-64 implementation and trying to reimplement it https://wolfsden.cz/blog/post/state-of-srfi-64.html
<lloda>there are also taylan's patches https://lists.gnu.org/archive/html/guile-devel/2021-05/msg00011.html
<sneek>ArneBab: Greetings :)
<wingo>heyoo
<wingo>sorry i have been absent :/
<mwette>o/ wingo. What have you been working on?
<wingo>hey :) these days i am half on spritely/hoot, half on trying to replace guile's gc (whippet)
<wingo>but taking a look at the moment at the couple big 3.0.10 regressions, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71891 notably
<mwette>Good things, I see. I am happy to see more work on the gc. And I been seeing issues reported w/ 32-bit in 3.0.10.
<mwette>I'm taking off now for a bit ...
<dthompson>yay wingo in the chat
<sneek>dthompson, you have 1 message!
<sneek>dthompson, ArneBab says: I got into problems with chickadee and readline: chickadee play --repl text.scm (the simplest example) ⇒ (import (ice-9 readline)) ⇒ type a ( ⇒ segmentation fault.
<dthompson>ArneBab: readline is not compatible with the chickadee repl
<dthompson>(ice-9 readline) calls into C code and doesn't cope with delimited continuations well at all. a segfault is a little surprising but it's not gonna work either way.
<dthompson>I should clarify that it's (ice-9 readline) that is incompatible. I've attempted to add my own readline bindings in (chickadee readline) that (chickadee async-repl) uses.
<dthompson>though I think it's probably a waste of time, overall. using the repl from the terminal is a bad experience that I don't want to recommend.
<dpk>is there any way to tell Guile’s ,optimize REPL command to pretend like the current module is declarative and show what the optimized output would be in that case?
<dpk>because as far as i can tell certain optimizations are only done when the bindings involved in the input come from a declarative module (question mark?)
<dpk>(i think this should actually be the default if that is the case)
<graywolf>Hello fellow people. I am trying to do an HTTP call using (web requests), and cannot figure out how to send "Authorization: Bearer foo" header. Any pointers?
<graywolf>s/(web requests)/(web client)/
<graywolf>oooooh the token value has to be a symbol, so I need to (string->symbol token)
<graywolf>Out of curiosity, are symbols garbage collected?
<dpk>graywolf: apparently so
<dpk>(do ((i 0 (+ i 1))) (#f) (symbol->string (string->symbol (number->string i)))) grows the heap a little but it doesn’t get out of control like it does on Schemes that (wrongly) don’t collect symbols
<graywolf>Ah, cool :) Thank you for the information. I know that e.g. ruby does not GC symbols, so I wasn't sure what the case is here. Allocating bunch of them in a loop is a test I should have figure out on my own :/
<dpk>Ruby has GC’d symbols for about 15 years now
<dpk>because it’s too easy to create memory exhaustion DDoS attacks if they’re not GC’d
<dpk>(well, DoS attacks)
<graywolf>Wait what?
<graywolf>Oooh since 2.2.
<graywolf>Good to know :D
<dpk>this is why Schemes that don’t GC symbols really really should
<dpk>because you can’t safely expose a typical Scheme JSON parser (the de facto standard converts object keys to symbols) to the web, say, unless symbols are GC’d
<graywolf>Yeah then lesson I have learned is "use strings for user controlled things", but yeah, GC-ing symbols is obviously much better :)
<graywolf>Well the json parser could have just used strings for keys
<dpk>SXML also has the same issue (element and attribute names are converted to symbols)
<ray1729>graywolf: I have an example here using http-post with an authz header: https://forge.1729.org.uk/ray/guile-toot/src/branch/main/rss2toot.scm#L132
<graywolf>omg it is case sensitive; (Authorization . ,(string-append "Bearer " token)) works, but (authorization . ,(string-append "Bearer " token)) does not.
<graywolf>That is... unexpected.
<retropikzel>It seems that when doing (import (srfi N)) guile does it's own thing and if I'm right tries to load file named srfi-n.scm? Is that documented somewhere?
<retropikzel>I'm trying to make some srfi stuff of my own and have problems loading those libraries to guile when they are named srfi/N.sld. I tried makind srfi/srfi-n.scm file just for guile but could not get it to work either
<morenonatural>could/should/would I leverage streams for multi-thread producers / consumers? does the fibers lib cover this?
<graywolf>Hm, can I exclude a HTTP header from validation? It seems I can do (declare-opaque-header! "Expires"), but that is global settings. From the code it does not seem to be possible to do this per-request, is that correct?
<ArneBab>dthompson: why do you consider the REPL from the terminal a bad experience?
<ArneBab>(I now switched to having a plain REPL in a *shell* buffer and sending codeblocks there, which works very well (except for redefining record types, those redefinitions crash the game …)
<ArneBab>)
<ArneBab>But I would really like to have some completion in a regular shell
<ArneBab>dthompson: is it enough to import (chickadee readline)?
<dthompson>it should automatically use readline
<dthompson>but tbh I really don't like the integration. it's very unpleasant to make readline work in an async context.
<morenonatural>could/should/would I leverage streams for multi-thread producers / consumers? does the fibers lib cover event-driven programming with multiple producers/consumers?
<dthompson>morenonatural: streams as in srfi-41?
<morenonatural>dthompson, yes
<dthompson>I'd recommend fibers for more serious programs
<morenonatural>is srfi-41 not meant to be tweaked for performance?
<morenonatural>I thought they would be pivotal to guile, kinda like ranges in D... but the more I use guile the less incentives I find to use them
<dthompson>they're interesting but they're not really a primitive for parallel computation
<ArneBab>dthompson: I’m running chickadee from my own game loop, so I have the coop-repl manually.
<ArneBab>That’s why I’m ashking for readline :)
<ArneBab>(though the pain got much lower then I found how to connect the REPL directly to Emacs via the *shell* buffer)