IRC channel logs
2025-01-20.log
back to list of logs
<lloda>'Bug reports should be closed by sending email to nnn-done@bugs.debian.org. The message body needs to contain an explanation of how the bug was fixed.' <lloda>you can mention the commit also <lloda>hmm don't use bugs.debian.org. Just send the message to 75413-done@the same domain as the bug report sorry i can't check rn <rubujeto>Wish me luck and courage, before I become a serious Schemer ;) <ray1729>What sort of value is (web client) expecting for the Accept header? I tried a request with #:headers '((accept . "text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, */*;q=0.8")) but this threw an exception. <ray1729>Answering my own question, it wants the parsed version of that string, which you can get by calling (parse-header 'accept s) <stevelitt>dsmith, thank you so much for pointing me to https://bpa.st/EMPQ . This got me past the mental block I was having, and I can now generalize your printlist3 in all sorts of situations and understand why it works and why it's tail recursive. <ArneBab>sneek later tell ttz: thank you for the benchmarking! I always love reliable data like this! Is there a chance you could get a few datapoints in-between and check the big-O scaling for the different datastructures? The base runtime (for some reasonable size of inputs) and the big-O complexity for the different datastructures would be wonderful to have in a table in the guile reference manual. <ArneBab>rlb: thank you for getting 3.0.10 into Debian! <mwette>I'm working on standlone-guile-app compiler. I assume boot-9.go (and it's 9 dep's) need to be included in the binary? Is that right? <rlb>mwette: not sure I have enough context, but I'm pretty sure effectively everything needs boot-9. <rlb>Are you embedding the .go files into elf sections or something? <mwette>Yes. Embedding the .go's in the elf and then calling load_thunk_from_memory, in order. <rlb>...next up, "global" tree shaker :) <rlb>(Though I guess we can't include the C code refs there...) <mwette>I'm not loading everything, only necessary. But loading deps for boot-9 and then boot-9, before others. <rlb>I kinda (naively?) wish we could rely on something like C dead code elimination to allow us to avoid some of the preprocessor intermingling -- i.e. possibly easier to read/manipulate, and less likely to hide mistakes. Of course then I'd probably just complain that we can't use a compiler warnings or a linter to find dead code... <dsmith>Back in the day, C libraries had one function per file. So when you linked, you only pulled in what you needed. Static linking of course. <Arsen>nowadays we have LTO.. which is far better at the job, so I'd say we progressed <dsmith>Hmm. There was a tool, by Red Hat I think, that could analyze the lib usage of all programs and rebuild the C libs without ununsed functions. For embedded systems. <dsmith>Mainly for saving space on limited flash. <rlb>Yeah, but I'm even thinking of (not exactly, but gives the idea) "if (HAVE_FOO) ..." though of course that wouldn't work if you had to refer to bindings that wouldn't exit, but it might work fine in caess like "if (BIG_ENDIAN) ...". <rlb>ACTION types too fast for this kdb... <rlb>(that's my story...) <rlb>I often wonder where I should put the boundary wrt using #idfefs within a function and just having two flavors of the function -- not always obvious to me... <dsmith>rlb, There is another extreme. Two files and link one or the other depending on platform or whatever. <dsmith>rlb, Linux kernel tries to keep ifdefs in headers. Even as far as writing vacuous macros for unneeded functions so the C code is cleaner <rlb>Oh, sure thought that makes the stricter division even harder to maintain, i.e. wrt the risk there of ensuring changes stay in sync across flavors. <rlb>In any case, I suspect libguile will always have larger files (and that would otherwise be a *lot* of files). <rlb>Also suspect it'll have a lot of ifdefs. <rlb>Only scarcely related, but I noted just how few build deps guile has when I was doing all that rebuilding for the really3.0.10 restoration. <rlb>(there I'm building in an schroot unshare, so you see exactly what it has to get and install) <rlb>Let's just say that emacs' list is "more" :) <dsmith>Zortech C++ had each function in the library wrapped in an #if. One C file for easy editing. At build time, you compiled to a bunch of .o's with one function in each. <rlb>...wow...hadn't thought about that word in a long time. <dsmith>Yeah, about '85 or so. First C++ compiler I used. <mwette>ugh. I get "In procedure load-thunk-from-memory: incompatible bytecode version" <mwette>I hash the dirname of the file paths. <rlb>From loader.c it seems like it's just not getting the constant values it expects from the "segment", though I don't yet know much at all about how the loader works. <rlb>Very naively wonder "offset problem"? <mwette>The other file to look at is init.c <mwette>Hmm. It will take some digging, I think. I may be too naive with how boot-9 has to be loaded in. There are a lot of primitive-load's in there.