guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#26339: [PATCH v2 01/12] system: Pass <bootloader-parameter> to grub.


From: Ludovic Courtès
Subject: bug#26339: [PATCH v2 01/12] system: Pass <bootloader-parameter> to grub.
Date: Tue, 09 May 2017 11:45:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Heya,

Danny Milosavljevic <address@hidden> skribis:

> On Tue, 09 May 2017 09:03:00 +0200
> address@hidden (Ludovic Courtès) wrote:
>
>> No apparently it worked on Hydra (but as I wrote before, the way
>> build-aux/compile-all.scm builds things doesn’t catch
>> macro-used-before-defined errors, so testing locally doesn’t help much).
>
> Hmm, but aren't the .go files the compiled files?  I've removed those before 
> testing.  And the guix script has "--no-auto-compile". I don't really 
> understand this part yet...

Hydra does compile Scheme files, but not with compile-all.scm.  Instead
it simply relies on Guile’s auto-compilation mechanism.  So everything
is built in one process but differently, which can lead to this subtle
bug (essentially compile-all.scm has a load phase followed by a build
phases, whereas auto-compilation builds files on demand.)

>> I was concerned that @@ would effectively cause the same problem as
>> #:use-module, but apparently that’s fine.
>
> The idea was that it would load the module just in time when the procedure is 
> executed.  In any case, module-ref can't hurt either, so that's in master now.

Yup, thanks for the quick hot fix!

>> We’ll keep reviewing/merging the rest of the series, which apparently
>> provides a nicer bootloader abstraction.
>
> It does.  I think the state in master now is good and we can review the 
> remainder at our leisure and I can stop hot-fixing things now.  Phiew... :)

Indeed.  :-)

> Though, it would be nice if there was a way to run the interpreted version 
> locally - without it taking several hours each time.  Would it be possible 
> for guile to have some static analysis that catches these things?  Doesn't 
> seem that difficult: Just walk the modules, remember when you see record 
> definitions, remember when you see record usage.  In fact I'll write a 
> throwaway script to do just that for next time.  (I've already got my 
> Makefile generator to find Guile module cycles :) )

It’s not that simple to find macro-used-before-defined errors, I’m
afraid.  If you build each file separately (as in “for i in *.scm; do
guild compile $i; done”), you definitely catch this issue.

Circular dependencies could be caught and (guix modules) has some of the
tools for that, though they are not necessarily a problem.

Thanks for your responsiveness!

Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]