IRC channel logs


back to list of logs

***rekado_ is now known as rekado
<rekado>I have a loop that spawns processes; I want to abort it on SIGINT.
<rekado>this is the test: guile -c '(begin (for-each (lambda (n) (display n) (system* "sleep" "3")) (list 1 2 3 4)))'
<rekado>I tried adding (sigaction SIGINT (lambda args (pk 'got-signal))) but it seems to never be triggered
<leoprikler>could sigint already be intercepted by something else? iirc there was a repl server that did that
<rekado>changing it from SIGINT to SIGCHLD works
<rekado>or… well, I probably *always* get SIGCHLD when a child process terminates
<leoprikler>you could make it sigusr
*rekado rediscovered (ice-9 runq)
<daviid>rlb: i am surprised to read, in the link you pasted yesterday - that libtool (2.4.6-15) unstable; urgency=medium - that it says 'unstable', but i amrunning bullseye
<daviid>if i search debian packages, libtool (2.4.6-15) is part of testing
<daviid>nothing important, just curious
<daviid>it still fails ... on the first 'make' incantation, then works on the second and following ones ... which is ok to work 'locally', but i can't run 'make distcheck'
<daviid>spk121: I think i should keep the change you suggested, about using libg_golf_la_LIBADD instead of libg_golf_la_LIBS
<daviid>I probably used libg_golf_la_LIBS as a 'copy' of what I did look at when starting to need lib*, guile-cv also has a mini C lib ... but not because of any knowledge to justify it on my side
<spk121>daviid: yeah, I think the docs say to prefer _LIBADD,
<daviid>ok, perfect, thanks for the tip
<daviid>have to go afk, bbl
***dongcarl8 is now known as dongcarl
<dftxbs3e> hello, how would you append to a '("list" "of" "strings") inline? '("list" "of" ,@(if #t '("more") '()) "strings") ?
<RhodiumToad>in what context?
<RhodiumToad>,@'("more") works, btw
<dftxbs3e>RhodiumToad, here:
<dftxbs3e>RhodiumToad, thanks a lot for trying to help, your solution doesnt work if I put a condition there, it says: Expecting string got if
<dftxbs3e>RhodiumToad, I had another mistake.. messy, I finally got it thanks a lot! '("list" ,(if (string-prefix? "powerpc64le"
<dftxbs3e>(or (%current-target-system) (%current-system)))
<dftxbs3e>"luajittex") "of" "strings")
<dftxbs3e>is there an Emacs extension to toggle background coloring escape "layers" of Scheme code?
***bitwiz is now known as taw10
***apteryx is now known as Guest20319
***apteryx_ is now known as apteryx
<wingo>aaaah delightful, chicken also does the #t1 thing
<wingo>#;1> (begin #t1)
<wingo>#;2> #true
<wingo>Error: unbound variable: rue
<wingo>very good.
<wingo>scheme is ridiculous sometimes
<leoprikler>is #true a guile-only thingß
<wingo>it is an r7rs thing
<wingo>i think somehow the chicken i ran didn't support r7rs out of the box
<ruffni>i ran into some weird bugs which apparently i introduced into my projects with circular imports (which i can clearly see: is an issue). so i started looking for a tool to visualize my dependencies, because things start to get messy as soon as you have more than a couple of modules (this might also be due lack of ability from my side). reading in the docs there is this sentence: "However Guile does not yet do proper dependency
<ruffni>tracking[...]". does "not yet" refer to an actual plan?
<leoprikler>I'm not sure whether there are plans already, but it most certainly means that those plans have reached a point of maturity where they'd be advertised in greater detail (e.g. "but Guile 3.2 will have it")
<ruffni>do you know if such information stored on the (open) web? the branch names and last commits on savannah don't give any obvious hints
<leoprikler>If it is, then it'll likely be mentioned in the guile-devel mailing list.
<ruffni>i'm already looking into that but i'm not sure about the keywords i should be searching. "dependency tracking" yields results ~10yrs old...
<ruffni>i guess i'll search some more and post to the list if still needed
<wingo>ruffni: no plan, sadly
<wingo>well. i am not sad about it ;) but it would be nice to fix & is important
<rlb>I've also noticed that the error message when you have a dep cycle is a bit mysterious, i.e. I just generally saw "foo undefined" for some foo, and had to learn what that meant. Be nice if we can arrange it to be able to just say that we've hit a cycle.
<rlb>(Assuming what I saw wasn't a result of some of my other mess...)
<wingo>yeah. many things to fix
<wingo>i am back on my bullshit
<wingo>(call-with-input-string "(#true1)" read) => (#t 1)
<wingo>i hate it
<leoprikler>That's fine
<leoprikler>Golfers unite!
<leoprikler>sneek: seen davexunit
<sneek>davexunit?, pretty sure was seen in #guile 10 days ago, saying: it uses the slot args to make a new slot with #:virtual allocation, but it only copies over the standard args. my understanding is that slots should be able to accept arbitrary initargs that metaclasses can use to do custom things..
<wingo>scheme@(guile-user)> (call-with-input-string "(#fa)" read)
<wingo>$3 = (#f a)
<wingo>scheme@(guile-user)> (call-with-input-string "(#f3)" read)
<wingo>ice-9/boot-9.scm:1669:16: In procedure raise-exception:
<wingo>#<unknown port>:1:6: missing '(' in vector or array literal
<wingo>i hate it so much!!!!!!!!!!!!!
<rlb>Heh - maybe "amusing"/related I found that the jvm clj reader decides something is a number if the first char is a unicode "digit", but then rejects the number if all the digits aren't [0-9]...
<wingo>gosh this is so distressing it's funny ;) well, better reproduce the bugs :P
<davexunit>leoprikler: hi I'm here if you have a question
<leoprikler>Ah, yes, it seems your git is down
<wingo>(call-with-input-string "(#true #True #tRue #false #False #fAlse)" read)
<wingo>what does it produce
<wingo>(#t #t #t #f #f #f Alse)
<wingo>that is "just" a bug, but yes wtffff
<leoprikler>the bug is that Rue is not included as well :)
<wingo>leo trolling :)
<davexunit>leoprikler: hmm... seems you are right. ruh roh
<leoprikler>honest question though, should those things be case insensitive?
<leoprikler>what about #fаlse?
<manumanumanu>wingo: that vector one is nice!
<wingo>leoprikler: seriously speaking -- guile parses #true and #false case-insensitively
<wingo>there is a problem with #f because guile doesn't know if it starts a #f32() or #f64()
<wingo>or is false
<wingo>so there are some hacks, and one part is checking that the next char is "a", but it neglects to check case-insensitively
<wingo>which is the bug. but there are a few behaviors in this area that would be nice to improve (requiring a terminating delimiter, notably); i know you talk about golfing but (#t1) is... not nice :)
<civodul>wingo: uh, what's the deal with #fAlse?!
<civodul>ah #f32
<civodul>try_read_ci_chars (port, "lse")
<civodul>you're making interesting discoveries in the process!
<civodul>there's nothing like hand-writter lexers :-)
<RhodiumToad>eh. a hand-written lexer may be preferable to "flex with a lot of horrible coding hacks" which I've dealt with in the past
<RhodiumToad>I found an O(n^3) loop in postgresql's lexer at one point
<civodul>i remember hacking on read.c as an optimization of the program *run time* in 1.8
<civodul>that gives an idea of how much has changed
<rlb>civodul: hah, I have that same thing in the scheme based edn parser I just wrote, but it's even "worse": (read-symbol-or-literal-remainder port (strbuf c) 3 #(#\e #\s #\l #\a) #f))
<rlb>(For "false"...)
<wingo>i think a reasonable path might be the compiler using "read" in scheme instead of c, then having the scheme read implementation be instead "read-syntax" and returning properly annotated syntax objects for every datum, including symbols and numbers
<wingo>not sure if we will be able to transpile read-in-scheme to read-in-c; but it would seem we don't need to. read in c already exists and we have to make the same bugs
<civodul>wingo: you mean instead of using source properties?
<wingo>we can remove source properties from the C reader
<wingo>civodul: yeah
<rlb>wingo: that's more or less what lokke does, I think, fwiw, i.e. the top-level is read or read-for-compiler, and the latter is a slightly different, more complex representation...
<civodul>but you'd like to keep the C reader? for bootstrapping?
<civodul>makes sense
<wingo>the only unsatisfying thing is that it doesn't necessarily reduce the amount of C that we have :P
<civodul>we could generate it... but then that's a bootstrapping headache
<civodul>(and more code, too)
<wingo>yeah. but perhaps useful, if the generated code is editable
<wingo>related to the psyntax question of course :P
<civodul>or we could evaluate it during bootstrap?
<wingo>there is a tension there. you would like to be able to write the reader with all the modules and macros you want
<wingo>but for bootstrapping, you want minimal deps
<wingo>so i think a way forward can be to just write (ice-9 read) that uses whatever modules you want. then we think about bootstrapping etc later
<civodul>i see
<civodul>keeping read.c alongside (ice-9 read) sounds like a reasonable first step, then
<wingo>reproducing dumb bugs is painful tho :)
<wingo>(the right thing for the time being tho)
<wingo>anyway, zzzz, night!
<ArneBab>wingo: that reminds me why I moved from the direct string parser to using (read) in wisp wherever possible. There are so many edge cases … thank you for tackling them! I feel your pain.
***rekado_ is now known as rekado
<rekado>I’d be happy to hear any suggestions regarding SIGINT handling of SYSTEM* invocations
<rekado>I have this: guile -c '(begin (for-each (lambda (n) (display n) (system* "sleep" "3")) (list 1 2 3 4)))'
<rekado>and I cannot abort the loop with C-c
<civodul>rekado: presumably, SIGINT arrives during the waitpid(2) call?
<civodul>what does strace say?
<RhodiumToad>standard behavior for system() at the C level is to ignore sigint in the parent
<leoprikler>and if one were to use system* or fork/exec manuallyß
<ruffni> make check on master branch fails test-out-of-memory. is it bad? is it a bug? should i report?
<rekado>civodul: I see this:
<rekado>it sleeps, gets interrupted, but then resumes sleeping