IRC channel logs
2024-12-05.log
back to list of logs
<dsmith>civodul, Confirmed for me that reverting that 7379049d3 allows git to build again. <apteryx>what is the pair syntax supposed to do in #:export or #:re-export? I thought it'd export x as y in #:re-export ((x . y)), but it doesn't seem to do tAT <apteryx>I guess if I had a (some module), I could import/export it with (some . module) <apteryx>but it seems that won't work, and I'll have to add a bunch of define + regular export <daviid>apteryx: #:export will create and export a new name, no matter what, which will hide any imported one of the same name .. #:re-export will take care of the situation that the (re-)exported name already exists (has been imported from another module) <apteryx>I'd like to use re-export, but it doesn't seem possible when the imported symbols were #:prefix'd <apteryx>(see my example at the URL above for more context) <apteryx>I was checking in a REPL that had the module in scope. After changing module and ,use (guix build pyproject-build-system), I have a binding for 'site-packages', which suggests it works. <sneek>I've been a process for 2 months <sneek>This system has been up 19 weeks, 2 days, 23 hours, 39 minutes <elpogo>Is anyone aware of any documentation of the guile bootstrap process? <dsmith>Sure! It's not published though. Just scattered about in the source tree in "automake" files... <dsmith>elpogo, But seriously, no, I don't think so. <dsmith>Maybe wingo mentioned a few things in his blog some time ago? <elpogo>All I gathered from various blogs so far is that there's a scheme interpreter (written in C) that loads the compiler (written in guile). I'm trying to figure out where that interpreter is (is it essentially eval.c in libguile?) <elpogo>s/written in guile/written in scheme/ <dsmith>Other lispy systems and some other langs need an existing implementation to build. <dsmith>But Guile can bootstrap itself from a C compiler. <dsmith>Instead of an already running Guile. Or some other Scheme. <dsmith>The distributed tarballs have pre-compiled .go files, so building from a tarball goes much faster that building from git