IRC channel logs

2022-01-02.log

back to list of logs

<haugh[m]>Hello Guile. I'm looking for a full list of per-port reader directives as specified by this page:
<haugh[m]> https://www.gnu.org/software/guile/manual/html_node/Scheme-Read.html#index-read-options
<haugh[m]>Should I assume that only the ones explicitly mentioned, like `#!curly-infix-and-square-brackets`, are implemented?
<haugh[m]>For example, `#!hungry-eol-escapes` is interpreted as a comment by Guile 3.0.5
<chrislck>haugh[m]: https://git.savannah.gnu.org/cgit/guile.git/tree/libguile/read.c#n75
<haugh[m]>chrislck: thank you, seems like this is what I was looking for
<haugh[m]> https://git.savannah.gnu.org/cgit/guile.git/tree/libguile/read.c#n1223
***daviid` is now known as daviid
<manumanumanu>So, friends, I am trying to understand whether there is a reason why guile's cond and case forms use begin instead of let to wrap their bodies. Are there any speed differences? a (let () body ...) without any binding forms in the body behaves like a begin. Turning those begins into lets would get rid of almost all pesky "definition in expression context" situations in guile. There is even a
<manumanumanu>half-serious patch to do so (something like a 4-line change to boot-9.scm)
<manumanumanu>so, I can answer my own question: (let () (display "hej") (display "hå")) optimizes to (begin ...).
<manumanumanu>Then the question of the above would be, if the changes in boot-9 ever happen, should (rnrs) export it's own cond form that conforms to r6rs?
<manumanumanu>this is currently not the case with (define ...) which happily takes definitions in expression context even in r6rs library forms.
<lilyp>manumanumanu: I think this would be a good thing to have in Guile proper; probably the only reason it hasn't happened yet is because there's lots to do for relatively few maintainers
<lilyp>Guile itself is moving rather slowly compared to the stuff that's built on it (like Guix)
<manumanumanu>I don't know, which is why I am asking. There might be some reasons against it. Speed is not it, though, since it already turns a (let () ...) without definitions into a begin (meaning it doesn't have to create a new lexical context which could have slowed things down).
<manumanumanu>The patch that I provided a long time ago is ready to be applied (maybe minus the changes to the do form), apart from the fact that there are no documentation changes. It should be mentioned in incompatibilities with r(6|7)rs and in various other places. English is something like my third language. I could take a stab at it, of course, but I remember the job poor arthur had to put into proof-reading
<manumanumanu>srfi-171 blush a bit :)
<manumanumanu>anyway, off to work!
<tohoyn>is there some reason why the binnmu 3.0.7-1+b1 has not been built for all debian architectures? I'm especially interested in hppa and m68k.
<tohoyn>see https://buildd.debian.org/status/package.php?p=guile-3.0
<jpoiret>is anyone aware of a standard macro that would do something similar to this https://paste.debian.net/1225583/ ?
<jpoiret>I know it can be replicated with quote and unquote-splice, but it's pretty unwieldy
<avalenn>is there any way to get programatically the current index in Value History ?
<avalenn>Without needing to read the REPL prompt.
<lilyp>jpoiret: I don't think there is... if there was, it'd be widely used in Guix
<jpoiret>heh, exactly why i ended up writing it :) well, maybe that could be added to guix itself
<lilyp>fwiw i don't think it makes sense to nest things here
<lilyp>the abstraction that you need is (lambda (cond . args) (if cond args '())
<lilyp>as syntax of course
<jpoiret>but wouldn't you still need quasiquote and unquote-splicing?
<lilyp>yeah, but ,@(list-when PRED package another-package) would still be readable
<lilyp>also, you could extend modify-inputs to have a (when ...) clause
<jpoiret>i was working on the installer, so it's not packages related. It's a matter of taste I suppose
<lilyp>In general, I'd say Scheme basics are easier to grok than any tailor-made API.
<nckx>dsmith: Nothing that isn't logged here: <https://logs.guix.gnu.org/guix/2022-01-02.log>. Don't see the point of blaming porcupirate.
***Server sets mode: +ntz
***sneek_ is now known as sneek
***ns127 is now known as ns12
***Liexei- is now known as Liexei
<dsmith>nckx: Because porcupirate interacted with the bot at Jan 01 16:41:53
<dsmith>And it crashed at Jan 01 16:43:34
<dsmith>I've got a backtrace, but it's useless.
<dsmith>So I was curious what was going on at the time. (Those logs don't have timestamps)
<dsmith>!uptime
<sneek>I've been running for 23 hours
<sneek>This system has been up 23 weeks, 4 days, 6 hours
<dsmith>sneek: botsnack
<sneek>:)
***robin_ is now known as robin
<unmatched-paren>is there any bindings to opengl for guile that are in active development? guile-opengl appears to be dead
<sneek>Welcome back unmatched-paren, you have 2 messages!
<sneek>unmatched-paren, nckx says: Let's see what it does after a restart: https://ci.guix.gnu.org/build/76458/details
<sneek>unmatched-paren, nckx says: Success has been forcibly achieved.
***u_l-lap is now known as unknown_lamer
<unmatched-paren>i tried using guile-cairo (opengl is kinda overkill at this point, but oh well) but the only two font rendering libraries it seems to work with are pango and freetype
<unmatched-paren>one has no guile bindings, and one depends on half the gnome stack
<unmatched-paren>i'd rather not have to depend on gobject and glib just for font rendering