IRC channel logs
2026-04-16.log
back to list of logs
<daviid>mwette: nyacc does not support make uninstall? <dsmith>There was some recent communications about improving error messages so they don't point to eval but to the actual source location. <apteryx>was there a reason guile had to invent its own (ice-9 exceptions) system instead of adopting srfi-35 and srfi-36 condition-style in core? Coming from the later, (ice-9 exceptions) feel a bit low-level/awkward to use. <ieure>apteryx, I don't know, but I see Guile first released in 1993 and SRFI-35/36 were finalized in December 2002. So good possibility those SRFIs didn't exist at the time that code was written. <apteryx>but srfi-35/36 got in before ice-9 exceptions came into existence, IIRC. <dsmith>In 2019 "Rebase throw/catch on top of raise-exception/with-exception-handler" <dsmith>The catch/throw was there a long time before <dsmith>Also: module/ice-9/exceptions.scm: New file, derived from (rnrs conditions). <apteryx>the ordering doesn't matter when using SRFI 35 conditions, as they are named <dsmith>Looks like catch/throw existed in Jim Blandy's initial commit to cvs <apteryx>figured out the ordering: it's current type fields first, followed by inherited type fields. <apteryx>so in my case bucket endpoint code message request-id host-id <apteryx>3rd field appears to have to be bucket; that's nonsensical <apteryx>ACTION goes back to use (srfi srfi-35) <apteryx>hm, (record-type-fields &s3-error) -> (code message request-id host-id bucket endpoint) <apteryx>OK, my previous result was wrong for some reason; the listing shown by record-type-fields is correct: inherited fields first (parents first), then current type fields last, in the order given to the type. <apteryx>hm, why does (port-filename (tmpfile)) return #f? <czan>apteryx: Is your code exiting the dynamic wind before you expect? Does http-get use a continuation to suspend until the result comes in, for example? <apteryx>ah, that's a possibility; that would mean the finalizer of the dynamic-wind would get called right? I can add a pk there to check <czan>Yeah, so then you'd be closing the port before you get to use it. :) <apteryx>good call: (closing-tmp-port-in-dynamic-wind) <apteryx>would someone know how to print a backtrace from the handler of with-exception-handler? <apteryx>ACTION tries (display-backtrace (make-stack #t) (current-error-port)) <rlb>dsmith: well, when I added a trivial generative "random unicode string" test, I of course found that I'd gotten a bit of utf-16 wrong :) (Will be fixed soon.) <rlb>Was just swapping (when needed) the UTF-16 result via the char count, not the utf-16 unit count, so sometimes I wasn't swapping all the units. <rlb>random string test with \U010753 pointed it out :) <JohnCowan>maybe tmpfile creates a file an immediately deletes it while leaving it open, at least on Posix <old>JohnCowan: The tmpfile() function opens a unique temporary file in binary read/write (w+b) mode. The file will be automatically deleted when it is closed or the program terminates. <old>But, deleted is not well defined here <old>unlink from the file-system? <old>also see: 37b4f7146c1a93b38fb3a3945d74ba6f4f6b81ce <old>but I guess that the file is indeed unlink immediatly or is even probably created with memfd_create on Linux to avoid race-condition wrt to unlinking. So you should not assume that tmpfile give you a filename <old>it's just a scratch buffer that will be closed when your exit and on execve <JohnCowan>old: not enough context to interpret the UUID <ekaitz>JohnCowan: it's a guile commit from september <ekaitz>> tmpfile: preserve O_CLOEXEC so children won't prevent removal <old>IIRC from that commit, the FILE object from the C API is close and guile just make a copy of the unlerying file-descriptor <rlb>jcowan: is there a specification for how "bad" sequences are supposed to be handled when converting from utf-8/16/32 with respect to the replacement char? e.g. for (utf16->string #vu8(#xdc 0 #xd8 0)) iconveh produces "#\ufffd\u00d8") --- I'm assuming that's because the initial #xdc is wrong, so it's skipped and then parsing restarts, so we have #xdc00. <rlb>Just trying to see if I can come up with a few reasonable test cases, to include with the switch to replacement_character from question_mark... <rlb>"so we have #xcd00 0, but that ends in the middle of a sequence?" <rlb>(I may be misinterpreting, but I think I would have expected mem_iconveh to report "truncated input" there, at least.) <rlb>OK, thanks. I might set that aside for now, i.e. leave the handler switch, but focus on adding tests in other places where we know the right answer. Can always come back to it later. <rlb>i.e. before we were "whatever iconveh does for 'replace with question mark'", and now we'll just be "whatever iconveh does for 'replace with replacement char'". <jcowan>One thing I know is undefined is how many replacement characters are generated. <jcowan>IOW, if you see bytes 80 80 (which is invalid UTF-8), do you get one U+FFFD or two?