IRC channel logs


back to list of logs

<rlb>wingo: oh, was that related to my questions (related to my attempts to implement some of the srfi-13 stuff in scheme)?
<rlb>(...or perhaps something else.)
<ulfvonbelow>hmmm, maybe sigaction should also prevent clobbering of SIGPWR and SIGXCPU handlers, since those seem to be used by libgc
<ulfvonbelow>is there no way to send a signal to a particular thread?
<ulfvonbelow>I ask because there are some system calls that are interruptible only by having a signal delivered, and then returning EINTR
<RhodiumToad>ulfvonbelow: no way in POSIX, or no way in guile?
<ulfvonbelow>no way in guile
<ulfvonbelow>I'm aware of pthread_kill
<RhodiumToad>personally I'm a bit skeptical about basically all of guile's assumptions about threading
<RhodiumToad>hm. is there a good way to write a hash-transduce that doesn't involve having to let/ec to get out of a hash-for-each
<shawnw>What's it do?
<RhodiumToad>see srfi-171
<RhodiumToad>basically it's like a fold, except more easily composable and can stop early rather than having to run to the end
<RhodiumToad>whereas all the hash-* builtin iteration constructs (hash-for-each, hash-fold, etc.) all run to completion
<lloda>in numpy np.sqrt(-(1.+0j)) -> -1j, np.sqrt(-(1.+0.j)) -> -1j, np.sqrt(0.-(1.+0.j)) -> +1j
<lloda>so 0. or 0. doesn't matter but 0.-0. -> +0.
<RhodiumToad>what is the . doing here?
<lloda>in Guile, (sqrt (- 1.+0i)) -> 0.0+1.0i but (sqrt (- 1.+0.i)) -> 0.0-1.0i
<lloda>that's surprising to me bc I'd thought 1.+0i would be a float literal, so the im part should be inexact and negating it should yield im part -0., which is what happens on numpy
<RhodiumToad>in guile, (- 1.+0.i) is -1.0-0.0i ...
<lloda>and (- 1.+0i) -> -1.0
<lloda>ok so 1.+0i is just real which makes sense.
<lloda>i'll have to remember never to write x+0i
<RhodiumToad>ah, I think I see
<RhodiumToad>so x+yi is real only if y is _exactly_ zero
<RhodiumToad>presumably because an inexact y could have underflowed to zero, in which case you want to preserve its sign
<RhodiumToad>and -1.0+0.0i is (inexactly) on the branch cut of the function, so -1.0+0.0i and -1.0-0.0i are taken to be on opposite sides of the cut
<lloda>yeah. I got hit by (sqrt (- 0.+0.i 1.+0.i)) != (sqrt (- 1.+0.i)) for this reason
<lloda>on the first one, im of argument is +0, but on the second, it's -0
<lloda>but if you write the first 0.+0.i as 0. then it's like the second!
<RhodiumToad>hm, because (- 0.0 0.0) is 0.0, but (- 0.0) is -0.0
<RhodiumToad>but it's weird that (- 0.0+0.0i 0.0+0.0i) and (- 0.0 0.0+0.0i) are different
<lloda>bc (- 0 0.0) is -0.0 and the first arg has exact 0 im part
<RhodiumToad>I _suppose_ it makes sense that subtracting an inexact 0 from an exact one gives -0
<RhodiumToad>ACTION wonders why guile doesn't have copysign
<lloda>yeah. I was expecting it would convert to complex-float before the - or something not do a specific (- real complex) op. But it does makes sense
<lloda>we should have copysign
<lloda>it's in C99 so we can just export it
<RhodiumToad>I think at the moment the only way to test the sign of 0 is to divide something by it
<civodul>hmm stumbled upon an infinite loop in ‘analyze’ in libguile/jit.c
<graywolf>Hi :) Is there some heredoc syntax in guile? I want to embed a file into one script, and escaping all " is somewhat annoying...
<rlb>graywolf: may not be adequate, but if you're actually typing the content, and not already using emacs (or presumably a suitable mode in another editor), the modes (like emacs' scheme-mode) will handle the backslashing for you by default.
<rlb>(Not quite what you asked, I know...)
<dsmith>Hmm. Might be possible to make one (ab)using read-hash-extend
<dsmith>Of course, if you write it as a shell script, you could use << and feed the here document to Guile
<graywolf>Nah, I need to embed a .patch file inside a script, so not typing :) I will look into the reader extensions, but probably overkill. Since there is nothing built-in, I guess M-x replace-string it is...
<dsmith>Check out the source for #; and #. for examples. There are others too.
<graywolf>Actually the "use <<" is useful, I have the #! comment anyway where I exec guile, so I can just create a temporary file there using bash heredoc. Thanks for the idea.
<graywolf>Hm, and the syntax highlight breaks...
<mwette>IIRC, someone generated a reader-macro for doing hereis strings.
<old>IIRC I sent a RFC on this to guile-dev without news
<graywolf>old: Thanks for the link, will read
<graywolf>noscript gets confused by the --- and thinks it is a xss attack :D
<mwette>graywolf: ^ 1291955 works, but strport is not needed: remove it
<old>does the link above work?
<old>I can not see for myself since I host the thing
<graywolf>It does :)
<graywolf>mwette: I somehow missed it, thanks!
<mwette>graywolf: yw; it is not bullet-proof wrt oddball end-sequences
<old>graywolf: althought I do not think my thing support your none-escaping of "
<old>I'm sure there's a way tho
<graywolf>I wonder how well does emacs/geiser handle these things. Any experience with that?
<graywolf>I have no idea how smart it is...
<old>badly lol
<old>I had to choose characters that did not confuse paredit
<old>nor being used by Guix G-exp
<old>I think I failed the second objectif IIRC
<mwette>graywolf: I saw that. It may be better to use #""" .... """
<dsmith>old, Nice!
<old>mwette: that's quite clever
<mwette> old: ty
<mwette>but it looks like with #" the read-text def and read-hash-extend need to be wrapped in (eval-when (expand load eval) ... )
<sneek>dsmith: wb!
<old>mwette: I though it was a side effect of readers
<old>which makes sens no since you want the reader to be run at expansion time?
<dsmith>sneek, botsnack
<mwette>old: I think if the setup was in a different module and you used it with, e.g., (use-modules (hereis)) you'd be OK
<mwette>but you are right about the read-hash-extend needing to be evaluated to parse the use
<haugh>I tried to write a heredoc syntax but it fell apart because I couldn't find any consensus on the syntax; basically the whole point is that it's not a sexp, so everyone's editor formats it differently.
<haugh>The ultimate problem as I currently see it is that string literals are not sexps.
<haugh>But yes, I got pretty far using read-hash-extend and (ice-9 rdelim), just can't decide how to wrap it up.
<haugh>There's also the problem of reader hash extensions being global combined with the general need for heredoc parameters (whitespace trimming, interpolation, etc.); you can either overload one hash character or pollute the entire table and either way it's a mess
<haugh>graywolf, take a look at SRFI-109. I tried to implement a small subset of that and still got lost in the sauce.
<haugh>old, I remember when you first started putting this together. Pretty cool to see it come together into something balanced. Maybe I gave up too early.
<minima>hi, is there any recommended logging mechanism in guile? anything simple but marginally better than disseminating a bunch of `display's in my code?
<daviid>minima: fwiw, there is one in guile-lib
<minima>daviid: brilliant, thanks!
<daviid>minima: np, i never used it, but looks pretty good - and uses goops, which is an excellent design choice, and also means it is, by definition, extensible
<minima>thanks daviid
<minima>anyone has any tips on how to serialise a s-exp to a file? the context would be for a guile script to be able to read some config from a file; a flat, csv-like structure would be fine
<graywolf>If it's just sexp, you can just use (write) and (read) I guess?
<minima>yeah, it'd be a simple sexp... no need to escape anything? sorry, this might be a bit of a dumb question
<graywolf>Better try it with some minimal example (since I am new here as well :) ), but I belive if you pass sexp to write, it should just work
<minima>great, thanks graywolf
<graywolf>Technically you can also use (ice-9 pretty-write)
<graywolf>Helps to make it human readable it that is desired
<dsmith>minima, Note that not all guile objects have a read-syntax (hashes for example).
<minima>dsmith: thanks; the s-exp would be a short list of strings; i'm more worried re unicode chars, in case anything needs to be done around it but probably not? and i'm worried if i need to do anything to sanitise the file when i read it
<graywolf>No, in that regard nothing should be required
<daviid>you might need to set the port encoding to utf8 if you write those to a file though ... i don't remember what the default file encoding is 'these days'
<minima>graywolf daviid: thanks, sorry i went afk for a bit