IRC channel logs
2025-12-13.log
back to list of logs
<old>oh oh. My CI failed on arch-linux for Guile 3.0.11 <old>Paths using coverage sampling <old>oh actually srfi-64 seems to have .. changed ? <rlb>it's been overhauled <rlb>and there are at least one or two unresolved bits -- i.e. some (unusual) forms that worked before don't atm <old>well it seems I only had to delete cache of Guile for srfi-64 <old>but I do get some weird failure now in my test-suite that I did not in 3.0.9 <rlb>shouldn't have had to delete the cache --- if that's not a local issue, sounds like a bug? <old>a group now only count for 1 <rlb>The known issues are with say form with a "missing body" -- we used to allow it (and we need clarification of the spec), but currently we don't. <old>instead of N under the group <rlb>I forget which form(s). <old>oh that's quite embarassing <rlb>Though we can also fix it by changing the macro to put a #f before the optional body... <old>how am I going to be compatible with older version :-/ <old>Well for example I have the following test <old>ACTION loading codeberg .. <old>See at line 9, we set the number of total test to be 3 <old>that's because there are 3 test-equal <old>but now, in guile 3.0.1, the number of test is 2, the number of test-group <old>so there is a different semantic for what is considered a test between the two versions <rlb>Hmm, I don't know much about the counts wrt srfi-64 but looking at the spec, it sounds like maybe it should be 2 "the number of test groups". <rlb>when there are groups? <rlb>i.e. each test group counts as 1 <old>The optional count must match the number of test-cases executed by this group. (Nested test groups count as a single test case for this count.) <old>right so Guile 3.0.11 got it right <rlb>yeah, I got the impression that the overhaul may have been "careful" <old>but that left me we, how I shall reconcile this to keep supporting older of Guile <rlb>can you adjust via cond-expand? <rlb>ACTION hasn't thought about it... <old>I suppose, but then I need to suppor two sets of number :p <rlb>Do we include the Z in the keys... <old>that's quite cumbersome <rlb>There were some additional cond-expand cases I thought we should add a good while back, but I've forgotten the specifics. <old>I think I will make thin wrapper around srfi-64 and using cond-expand I will omit the count number <old>oh well! At least arch-linux gaves me a head up on this! <rlb>ahh -- or you could just (test-begin "foo" (maybe-count 3))? <mwette>Use of load in a module generates a warning if at top-level, or if in a module procedure. Does the second case make sense? <mwette>what m68k systems are around anymore <dsmith>At VTI, we had a whole family of devices that used a coldfire. Unfortunately it had no MMU, so everything was statically linked, just one common address space for all processes and kernel. Ugh! <mwette>I remember the original macintosh that was on 68000 and was called "a petri disk for viruses". <dsmith>The 68k at the asm level was nice. Enough register to not be constrained and yet not to many to be overwhelmed. (8 data and 8 address) <mwette>I did work on that, too, using gcc-m68k before the days of autoconf. Had to building gcc against a long README file. <rlb>dpk: I don't know if it's been discussed already much, but old pointed out that there may (of course) be security considerations wrt any broader noncharacters strategy for rnrs. e.g., I assume --- the risk that you can "smuggle" say ascii bytes (quotes, whatever) past any escaping/filtering guard functions as noncharacters. <rlb>(depending of course on the context) <Deltafire>how do i access the docstring for a macro? ,describe and (procedure-documentation) only seem to work for procedures <Deltafire>the specific example is define-record-type* from (guix records) <old>Deltafire: you need to call describe on the macro expander <old>but it's hard to reference a macro directly because it expand <old>(procedure-properties (macro-transformer (module-ref (resolve-interface '(srfi srfi-9)) 'define-record-type))) <old>unfortunatelly, no doc for srfi-9 <mwette>but that's significant info for others <ArneBab>old: can we somehow add that to ,describe? <ArneBab>It would be nice if ,d define-record-type* just worked. <old>if it's imported in your module yes <old>that ought to work if you put it in your .guile <old>seems to work: (describe const) => "Return a procedure that accepts any number of arguments and returns\nVALUE." <old>(describe current-filename) => "A macro that expands to the current filename: the filename that\nthe (current-filename) form appears in. Expands to #f if this\ninformation is unavailable." <ArneBab>that makes (describe ...) work; do you know what we need for ,d? <old>(you probably want to call display in the macro tho) <old>we need to change the implementation of the meta command ,describe <old>I could to that latter if you're interested to review the patc <old>actually it's weird .. it should already support that <Deltafire>the documentation suggests that it should, but it doesn't appear to <Deltafire>hmm.. just tried with guile 2.0.14 and it works as expected <ArneBab>I guess if old is fixing it already, we could directly have a PR.