IRC channel logs
2023-04-06.log
back to list of logs
<daviid>the lines that changes are 12 and 38 <rlb>daviid: hmm, am I misreading? i.e. line 38 looks the same in the first case, and 12 changed to somethin with a "#;" in it (on line 30)? <daviid>rlb: oh right, lines 12 and 30 ... :) <daviid>rlb: i don't think it matters, but fwiw, vf is bound to a <vfunc> instance, <vfunc> is a <method> subclass, <method> defines the specializers solt, among others ... <rlb>But what does "#;" do? <rlb>Oh, hah, didn't realize. <rlb>And what's the failure? <daviid>rlb: well, as i said, that module compiles fine, with line 12 or with line 30, but with line 12, trying to use it will raise match exception, due to the expansion of line 12 not doing what i think it should do ... <rlb>So the syntax-rules clause isn't matching, or the vfunc-checks call is broken, or...? <daviid>rlb: thanks for the help, going afk 10min, be right back ... i just wish i understand hy line 8 [from the later paste] would not expand 'properly' if calling (vfunc-checks 'vf-name (slot-ref vf 'specializers)) ? but i am syntax-* rusty :) <rlb>daviid: I definitely don't follow all that yet, but if the match that's failing is the one inside vfunc-checks, I imagine I might try adding some debugging output (format (current-error-port) ...) or whatever to see what's going on, though undoubtedly there are fancier ways. <flatwhatson>daviid: the error is match failing on a <vfunc> record. i assume your (specializer ...) patterns are meant to match that, but those are actually just matching lists <flatwhatson>you need a match pattern which will match a single object, eg. ($ <vfunc> foo bar baz) to destructure the record <daviid>flatwhatson: the match failing is a consequence of a 'miss-expansion' of the code, there is no match error in the last paste ... <flatwhatson>oh i see, so if (slot-ref vf 'specializers) is in the macro it doesn't work, but if it's in the helper function it does work <daviid>flatwhatson: if you look at this paste https://paste.centos.org/view/e2edeb61 line 8 calls (vfunc-checks 'vf-name vf), and in that version, the vfunc-checks receives the vf and line 20, define a local specializers as (slot-ref vf 'specializers) ... that works fine - however, if do as in here, https://paste.centos.org/view/77fd3331 .. although the module compiles fine, no error ... any example that attempt to defie a vfunc fails ... <flatwhatson>strange, because the different behaviours affect the return value of specializers-vfunc-lookup, causing results to have the wrong type <daviid>flatwhatson: by the way, did yu see my msg about the projects you moved to notabug needs a bit of love ... to update their clone istructions, which was pointing still to gitlab/github ... <flatwhatson>i think i got everything updated, and submitted patches to update the URLs in guix <flatwhatson>with this error, i wonder if the failing match is actually *not* either of the ones in your vfunc-checks procedure <flatwhatson>we don't get a backtrace from the compilation error, so the assumption about which match is failing might be wrong <daviid>flatwhatson: there is no match failure :)( - there is an expansion failure, which then provoques a 'false' match failure ... <flatwhatson>i guess the difference is because slot-ref is a macro, and the eager expansion goes wrong <daviid>right, what should i do to get it right? <flatwhatson>a simple technique for debugging expansion is to quote the body of the macro, so it returns a quoted expansion <flatwhatson>then call the macro in the repl to inspect the returned expansion (pretty-print comes in handy) <daviid>flatwhatson: slot-ref isn't a macro by the way <flatwhatson>it's defined as a macro in ice-9/match.scm line 37, maybe that's the problem? <flatwhatson>at least it's suspicious. that local definition *shouldn't* cause problems, but... <flatwhatson>you should still try investigating the expansion, this is clearly expansion-related weirdness <daviid>flatwhatson: the (ice-9 match) is not exported, so it shouldn't interfere with the (oop goops) slot-ref, i thkink <daviid>*the (ice-9 match) slot-ref isn't exported ... <daviid>i would think our maintainers carefully took care of this ... <daviid>flatwhatson: the working version just pass vf to the vfunc-checks call - it won't help to pp it .. but i am now trying to peek as suggested by rlb earlier <daviid>and here is a 'peek' trace of the vfunc-checks calls, which shows that in this version that 'doesn't work', one vfunc gets the wrong specializers, let me paste <daviid>i see the reason it complains at compile time actually is about get-flags-vfunc of the <nuclear-icon> class, and that is a module - (nuclear-icon) - that both the simple-pantable.scm and the animated-paintable.scm examples import then after i change anything in my define-vfunc machinery, i need to recompile all modules that uses it ... <daviid>oh my god! i totally forgot to force a recompile of the (nuclear-icon), and now it works ... <daviid>rlb, flatwhatson thanks very much for your help <rlb>daviid: hah, I *almost* suggested "rm -rf ~/.cache/guile/ccache" and/or "make clean" -- reflexively done a lot of that wrt the lokke syntax pile, and yeah, glad you got it. <rlb>(Somewhat related, I'm still wondering if I might want a guile option to *not* load a stale .go if compilation of a newer .scm fails, etc. At least I think that's what I've observed, and offhand, I don't think I want that a lot of the time. But I need to go double-check my recollection first.) <rlb>I *think* I usually want it to just stop on the first failure. <flatwhatson>i guess this kind of problem could be solved by having something like .d dependencies generated for each .go, listing all of the .scm including macros which were involved in the compilation, then "make" would know what to recompile when the macro is changed <flatwhatson>maybe some kind of hook on macro expansion that can be used to record each macro as it's expanded <lloda>C-M n/p don't work properly over #; :-\ <wingo>guild should take a -L option <cow_2001>chapter 3.4 is about concurrency. oh boy. <haugh>where's the documentation for doc-snarf? <haugh>who documents the documentation generator? <haugh>The output of `guild doc-snarf doc-snarf.scm` is not super encouraging