IRC channel logs

2021-08-07.log

back to list of logs

<rlb>mfiano: fwiw, recommend reporting non-debian bugs "here", i.e. bug-guile@gnu.org since they'll just have to be forwarded otherwise.
<Sheilong>I am appending items to a list with append! however it is not making any effect to the list.
<Sheilong>The list is defined in the body of a let statement and the value is appended in another let nested to this one.
<Sheilong>I wrote a minimal example to show what is going on here https://paste.ofcode.org/wdjEUWbyVYwgBAbvfaS6pC
<Sheilong>append! is not mutation the list. I don't know what I am doing wrong here
<lloda>that isn't how append! works. The appended list is the return value
<lloda> https://srfi.schemers.org/srfi-1/srfi-1.html#append!
<lloda>the argument might get modified or not. You use append! instead of append when you don't care what happens to it, that's the only difference
<Sheilong>lloda: At least here it seems to modify the list if there is already elements on it. If the list is empty it does not.
<lloda>you can't count on that. The result is the return value, not the argument.
<Sheilong>My problem here is to save a result from a computation in a list in by appending it and reusing these values yielded from the computation later on.
<lloda>i think this is what you want
<lloda> https://paste.debian.net/1206851/
<lloda>personally i find do unreadable
<chrislck>named let = ftw
<clone>In guile 3.0.7, I can't use this extended symbol read syntax: https://www.gnu.org/software/guile/manual/html_node/Symbol-Read-Syntax.html#Symbol-Read-Syntax
<clone>did that get removed? the (read-enable 'r7rs-symbols) syntax doesn't work either, it looks like it expands to the not-working #{}# syntax
***chris is now known as Guest1725
<rlb>clone: may or may not be related, but I believe wingo changed the reader a good bit recently.
<rlb>Is there a way to catch an (error ...) raised during a syntax-rules expansion or similar? (Current application is writing tests for some macro expansion error handling.)
<leoprikler>you could try compiling your scheme to bytecode "on the fly", but I don't know how practical that is
<lloda>clone: works fine here (?)
<lloda>3.0.7
<lloda>both #{}# and the r7rs || if you enable it
<lloda>what error do you get?
<rlb>leoprikler: thanks - and yeah, I should have thought of that. i.e. if it'll work, just test via a catch around an explicit macroexpand of the relevant form.
<clone>lloda: #{foo bar}# gives me
<clone>ice-9/boot-9.scm:1685:16: In procedure raise-exception:
<clone>Unbound variable: #{foo bar}#
<jgart>Hi Guilers!
<jgart>do you happen to know if there is something built into guile that reads a file as a string? Something similar to this function: https://paste.sr.ht/~jgart/f03d300dc83a408ce8c494644c320889f2b7bd01
<clone>jgart: i think you want get-string-all from ice-9 textual-ports
<jgart>clone, thanks!
<avp>Hello Guilers. I'm testing Guile-SMC on binary data parsing. Here are first results -- Guile-PNG: https://github.com/artyom-poptsov/guile-png
<lloda>clone: and if you write foo-bar, what do you get?
<clone>#{foo-bar}# gives: Unbound variable: foo-bar
<lloda>you need to quote symbols
<lloda>foo-bar alone without the #{ }# will give you the same
<lloda>if you do (define #{foo bar}# 0) that will work fine
<clone>oh that makes sense, i thought #{foo}# meant 'foo, thanks
<lloda>yw
<lloda>maybe the doc needs an actual example bc it's not the first time that i see someone think that