Should marking a system preloaded drop its build information?
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.
Faré writes:
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.]
Additional adventage is a more uniform handling of the code (for instance in `find-system') and could pave a way for `monotonic-system' (from lack of better name atm) – system which only upgrades to the higher versions like ASDF does right now. Rationale for registering a new system is as follows: preloaded-systems and immutable-systems are separate kind of system treated differently in the code and have a separate class, because of their very nature. Like we have prebuilt-system, or require-system, we have also immutable and preloaded systems, which doesn't have build information (preloaded system is a system, which is loaded by definition, without any operations, while immutable system is a preloaded system, whichcan't be removed). Otherwise we should call them systems with immutability (or preload) flags.
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.
We don't have to necessarily loose the ability to keep the existing build information. While it's not good to expose it in the production image, stepping back to it is indeed something we want. Such change won't introduce much of the problem, if we drop direct hash-table access from user code and mandate registering immutable-systems only with the function register-immutable-system (same with the preloaded). Then an instance could store the original system in a slot, which gets registered during the call to `deregister-immutable-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.
Best regards, Daniel -- Daniel Kochmański ;; aka jackdaniel | Poznań, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi
On Thu, Sep 15, 2016 at 2:41 AM, Daniel Kochmański <daniel@turtleware.eu> wrote:
Additional adventage is a more uniform handling of the code (for instance in `find-system') and could pave a way for `monotonic-system' (from lack of better name atm) – system which only upgrades to the higher versions like ASDF does right now.
That would require a way of detecting the version before you load the system, for which ASDF has an ad hoc protocol that doesn't fit the normal system definition protocol. ASDF is a bit special because it has to be able to upgrade itself while it's running. Other systems don't usually have this constraint -- they can ask ASDF to upgrade them.
Rationale for registering a new system is as follows: preloaded-systems and immutable-systems are separate kind of system treated differently in the code and have a separate class, because of their very nature.
I don't buy that. Immutable systems could be made thus by adding a slot immutable-p to all systems. The reason we're using a table instead is because we want fast access to the list of only those systems that are immutable without groveling a large list of all the defined systems, that most usually aren't. At which point we don't need the slot.
[To preserve the build information] an instance could store the original system in a slot, which gets registered during the call to `deregister-immutable-system'.
If you preserve the build information, why change the system object at all? You seem all set on defining new classes for preloaded and immutable systems, but don't explain why it's useful, just offer workaround for all the detrimental effects of the design. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites
Faré writes:
Rationale for registering a new system is as follows: preloaded-systems and immutable-systems are separate kind of system treated differently in the code and have a separate class, because of their very nature.
I don't buy that. Immutable systems could be made thus by adding a slot immutable-p to all systems. The reason we're using a table instead is because we want fast access to the list of only those systems that are immutable without groveling a large list of all the defined systems, that most usually aren't. At which point we don't need the slot.
I believe it would be improvement upon current design (explicit consulting with separate hash tables, special cases in the code, calling something a xxx-system while it's in fact xxx-flagged-system). I'm not insisting on that change, since the issue which made me work on that is (mostly, if not entirely) solved. Either way I think that at least removing immutability flag from the system should be abstracted by a protocol (i.e `deregister-immutable-system' or something of this kind) instead of calling remhash. This will make such desing changes possible in the future if someone will find it important without breaking the backward compatibility.
[To preserve the build information] an instance could store the original system in a slot, which gets registered during the call to `deregister-immutable-system'.
If you preserve the build information, why change the system object at all?
You seem all set on defining new classes for preloaded and immutable systems, but don't explain why it's useful, just offer workaround for all the detrimental effects of the design.
You said it, it's desirable to not carry build information exposed in non-development host, but getting rid of the data isn't much so. Such solution keeps both qualities.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org I'd rather write programs that write programs than write programs — Dick Sites
Regards, Daniel -- Daniel Kochmański ;; aka jackdaniel | Poznań, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu "Be the change that you wish to see in the world." - Mahatma Gandhi
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@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.
On Thu, Sep 15, 2016 at 4:37 AM, Pascal Bourguignon <pjb@informatimago.com> wrote:
Perhaps there could be a asdf operation to load and "freeze" a system? So both options would be available.
Already done: you can first use load-system then use register-immutable-system (since ASDF 3.1.5, thanks to Dave Cooper). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Dynamic typing is simply lazy static typing. — Pierre de Lacaze, explaining Lisp to Haskellers
participants (4)
-
Daniel Kochmański -
Dave Cooper -
Faré -
Pascal Bourguignon