IRC channel logs
2023-11-06.log
back to list of logs
<euouae>and another question, is guile-hall a good project to use for my own guile projects? <apteryx>that's been an annoyance to me as well <apteryx>(my dirty workaround is to hack it with literal value as you said while testing at the REPL) <apteryx>is it a parameter? if it was, perhaps you could bind it to what you want <apteryx>ACTION thinks they found a good solution for the include breakage for relative include during compilation <apteryx>does touching psyntax.scm means all of Guile's .scm modules need to be rebuilt? <apteryx>I want to use a fluid or parameter in ice-9/psyntax.scm; where can/should I define it? <apteryx>it's to use within the 'include' syntax <apteryx>it's going to be bound in some procedures in (system base compile) <apteryx>well, that sounds strange to mix parameter and syntax <apteryx>but it seems the fluid then is akin to a global, and has no 'scope', so it sticks to whatever last value it was set <apteryx>ah, it's not that strange, include expands to a procedure call (call-with-include-port[0 <apteryx>how do I recover from something like this, clearing as little as .go files as possible? Pre-boot error; key: unbound-variable, args: (#f "Unbound variable: ~S" (and=>) #f)make[2]: *** [Makefile:2531: ice-9/psyntax-pp.go] Aborted <apteryx>this did it: grep --include '*.go' -rl 'and=>' stage0/ice-9/ | xargs rm <apteryx>civodul: howdy! are you sometimes looking at guile-devel for patches to apply? <civodul>apteryx: hi! unfortunately not really, as you might have noticed <civodul>i should switch back to that at some point <apteryx>is there someone actively doing that? or is it free style like in Guix, albeit with less hands? :-) <civodul>review is not something people enjoy doing it seems :-) <civodul>so yes, very few hands when it comes to review <apteryx>seems this test is flaky: FAIL: asyncs.test: preemption via sigprof <apteryx>ACTION thought they had sent '[PATCH v5 0/4] Add module depth information to %load-verbosely output' already, but it seems not. Resent it now. <apteryx>civodul: fyi, the above was made following a tip provided for looking at modules being loaded, noting the limitation that the view was 'flat' :-) <apteryx>I probably should have --in-reply-to to keep a single thread; Maxime offered review comments for prior revisions <civodul>i should take a look, but no ETA (esp. with the Guix workshop coming up…) <apteryx>OK! I'm sure it'll be an enjoyable event! <apteryx>since the 'include' syntax in psyntax ends up calling a procedure (call-with-include-port), does it mean it calls that at run time? <apteryx>,expand (include "/tmp/test.scm") doesn't show that <apteryx>it shows the included contents directly <apteryx>ah, 'call-with-include-port' is a helper used at expansion time, not run time <apteryx>and since include by definition is supposed to expand to the source contents, I don't think it can be made a procedure... hm. <apteryx>would there be a better way to prevent a .go file embedding a reference to a build source file path than to hack the file port file name in fport_canonicalize_filename (fports.c) <apteryx>I thought I could capture the original file name in a fluid or parameter but given's include syntactic nature, this doesn't work <apteryx>ACTION studies scm_i_relativize_path <apteryx>I replied to that bug with my findings, and failed experiments <apteryx>where is the source file mapping recorded in the .go? objdump -x doesn't show it <apteryx>wingo_: if you can think of an alternative to "add %file-port-name-canonicalization option" (commit 0157a341577223a981d912c93b568792e9dc67e3) that wouldn't mess with 'include', I'm all ears :-) <apteryx>is the motivation solely to avoid baking a wrong source reference in byte compiled .go files? <apteryx>does someone know how/where the port filename end up in the bytecode of a .go file?