Should marking a system preloaded drop its build information?

Pascal Bourguignon pjb at informatimago.com
Thu Sep 15 08:37:04 UTC 2016


Perhaps there could be a asdf operation to load and "freeze" a system?  So both options would be available. 

-- 
__Pascal Bourguignon__

> Le 15 sept. 2016 à 01:05, Faré <fahree at gmail.com> a écrit :
> 
> In the patch he submitted, Daniel Kochmanski modified
> register-preloaded-system so that it eagerly replaces any previously
> loaded system with a placeholder object that has no build information.
> In the current ASDF, the preloaded system is only lazily registered if
> the system is requested but not previously loaded (or is cleared). In
> my current working branch, it is eagerly registered but only if no
> previous system was loaded or after clearing it. [Going from lazy to
> eager registration fixes a bug with already-loaded-systems and thus
> require-system.]
> 
> The big design question is: should registering a system as preloaded
> drop its build information?
> 
> Advantage of erasing the existing system information: the behavior of
> the image is uniform on all machines, and trying to resume development
> on a machine without the same source code at the same location won't
> cause a flurry of filesystem accesses at the wrong paths. [Note that
> immutable systems never try to access the filesystem, unlike regular
> preloaded systems, even with build information present.]
> 
> Advantage of keeping the existing build information: you can resume
> the production image and resume incremental development on a machine
> that has the same source code at the same location. And if you to drop
> it, you can explicitly call clear-system after you call
> register-preloaded-system.
> 
> I am strongly inclined to keeping the build information around: it's
> always easy to erase the information later, but hard to reconstitute
> dropped information.
> 
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> A Libertarian Constitutional Amendment: Congress shall make no law.
> 




More information about the asdf-devel mailing list