IRC channel logs
2024-06-02.log
back to list of logs
<Googulator>mihi: getcwd is used one line earlier without failing, so it's presumably not null - that leaves libc as possibly null <Googulator>(and yes, I'm aware "variable" is not quite the right word in a functional language, but Scheme is also not Haskell, so I'm assuming libc is something intermediate between a true variable and the kind of defined values you can have in a pure functional language like Haskell) <Googulator>indeed, if Scheme were lazy like Haskell, then a printout fixing an error where something is unexpectedly null would be a lot more understandable, although still potentially pointing to a language / runtime environment bug <oriansj>well scheme being compiled to byte-code could being doing an optimization pass and skip anything that doesn't have side effects. <matrix_bridge><Andrius Štikonas> You need to use recovery that doesn't support USB booting :O <mihi>stikonas: to be fair, for a not-so-technical person having to reinstall their OS it can be an obstacle to find an empty USB key large enough where you can put your installer on (so when helping out, I usually carry an empty or emptiable USB key with me). So a recovery in firmware that supports the built-in network adapters and can recover macOS from network is certainly convenient (for recovering macOS, not for <mihi>installing Linux). Microsoft tried to add this ("Cloud Reinstall") to Windows 10/11 Recovery for a while, but in my experience it is more often failing than working. <mihi>Googulator, so it fails in string-append when setting cflags because argument is not a string (because it is presumably #f)? And I don't mind anyone calling a lexical let binding a variable, as it behaves as such. Still, when you consider this C code: char *printed = assoc_ref(inputs, "libc"), *headers = assoc_ref(input, "headers"), *libc = assoc_ref(input, "libc"); I would not call libc and printed to be the <mihi>same variable (although a correct assoc_ref implementation probably lets both point to the same string). <mihi>(Still, when there is corrupted memory around, or some parts reside in "free" memory, I can think of many reasons why assoc_ref might return different results for same arguments, especially when you cannot rule out that the GC might have been running between both calls - debugging that might be very tricky, though. <mihi>Googulator, I assume it still breaks (does not fix the issue) when you do the printing between the bindings for libs and cflags? <mihi>i.e. adding an extra binding (_ignored (begin (display "GETCWD ") (display (getcwd)) (display "LIBC") (display (assoc-ref inputs "libc")) (newline))) ? <mihi>argh I meant (_ignored (begin (display "GETCWD ") (display (getcwd)) (display "LIBC") (display libc) (newline)) <mihi>oriansj, I'm pretty sure both (display) and (setenv) have side-effects, so the compiler cannot skip either call to assoc-ref. <Googulator>OK, it gets weirder: with the debug prints added, it successfully builds glibc-mesboot once, then builds lots of other stuff, then again goes on to build glibc-mesboot(!), and it fails - with the same error and before <Googulator>*AND* I somehow don't see my debug prints in the 2nd (failing) run! <Googulator>As if it's somehow using the original code, instead of the patched one <matrix_bridge><cosinusoidally> presumably Guile has some sort of test suite too? If so, does that get run as part of the build?