IRC channel logs


back to list of logs

<lilyp>I just found out something quite interesting and amusing: If you edit your file while compiling and it contains a warning, you can get into a situation where guile won't recompile the file later, but still show the warning (even if the point of editing was to fix that warning)
<haugh>What could be causing the compiler to enter a loop before even the module definition is processed?
<RhodiumToad>before it starts processing it, or before it finishes?
<haugh>Very good point
<lilyp>infinitely expanding syntax mayhaps?
<haugh>lilyp, yeah that was it. Not the first time I've done this to myself.
<haugh>How do you girls debug your macros?
<haugh>I guess I should set up more `syntax-error's
<lilyp>macroexpand works more often than not; after that it's rubber duck time
<lilyp>and now that I have one, if rubber duck doesn't work, it's wooden duck
<haugh>My rubber duck is on strike for better working conditions
<haugh>Does anyone else have this issue with SRFI-64 test suites, where you need to terminate the guile process in order to get the full log written to file?
<lilyp>I don't think they're meant to be invoked interactively, but you could try doing a (gc)
<cow_2001>> <> I was reading about GOOPS.
<cow_2001>"To start using GOOPS you first need to import the (oop goops) module."
<cow_2001>oop goops hehehehehehehehehehehehe`#.
<haugh>lilyp: that works, thank you
<haugh>buffer #scheme
<rlb>Do we already have something like clj's (repeatedly n f)? It builds a list (in clj a lazy seq) of n calls to f? I can use list-tabulate, but I find myself frequently wanting just the side effects (random numbers, etc.), so I thought I'd see if I'd overlooked something.
<RhodiumToad>calls to f with what args? none?
<rlb> fwiw
<rlb>( suspected adding utf-8 test cases, is exposing trouble.)
<RhodiumToad>do you need it to be lazy?
<rlb>nope, just need the N case for now, and of course it's trivial to make one, just wanted to see if we already had it.
<rlb>Similar in clj are repeat, repeatedly, and iterate, handy for different things.
<rlb>But not a big deal.
<rlb>(and arguably not as minimal as some might argue for scheme :) )
<wingo>good evening
<rlb>wingo: fwiw, I'm toying with some generative/randomized string tests (right now for the less giant sparse-index boundary cases, e.g. around 256 and 64k). May already have found some bugs.
<rlb>...and I'll plan to raise the branch as a pr you can comment on after I fix these bugs (unless you prefer otherwise). (For now I'd guess the broader questions matter more, wrt the overall approach, style, etc.)
<rlb>Should the #\uHHHHHH syntax work on anything that integer->char works on? If so, then might have a problem with say #x02b961, unless I'm misunderstanding.
<rlb>(Just hit that in a randomized string test.)
<RhodiumToad>what problem?
<rlb>Reader refuses #\u02b961, but (integer->char #x02b961) is fine.
<rlb>fsvo fine
<rlb>Look like it's part of the cjk unified ideographs extension e, fwiw:
<RhodiumToad>you added the #\u... syntax?
<rlb>oh, wait, I misread, that's only valid for string contents...
<RhodiumToad>there's #\x.... which should accept anything that integer->char does
<rlb>sorry for the noise, and thanks.
<RhodiumToad>(in fact it seems to call integer->char to work)
<rlb>yeah. I just misread the docs.
<rlb>(and misremembered)