IRC channel logs
2023-09-14.log
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>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 <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. <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 <lloda>ok so 1.+0i is just real which makes sense. <lloda>i'll have to remember never to write x+0i <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>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 <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>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>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. <mwette>IIRC, someone generated a reader-macro for doing hereis strings. <old>graywolf: oldiob.dev/guile---heredoc.html <old>IIRC I sent a RFC on this to guile-dev without news <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 <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? <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 #""" .... """ <old>mwette: that's quite clever <mwette>but it looks like with #" the read-text def and read-hash-extend need to be wrapped in (eval-when (expand load eval) ... ) <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? <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: 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>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 <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