Commit d60dcdaf authored by Francois-Rene Rideau's avatar Francois-Rene Rideau

Another pass at fixing and upgrading ASDF

parent d4ee3edc
......@@ -139,7 +139,7 @@ sub-bullet under a major header.
:components
((:file "blah")
(:module "mod"
:depends-on ("blah")
:depends-on ("blah")
:components
((:file "bar")
(:file "baz")
......@@ -184,51 +184,14 @@ sub-bullet under a major header.
*** missing extension hooks
* Pathname limitations
** CL Pathname FAIL
** Pathname FAILs
*** *The FAIL:* =#p"foo/bar"= can never be portable.
*** CL pathname FAIL: underspecified semantics means not portably usable
**** underspecified semantics => not portably usable
*** CL pathname FAIL: host and device are inherited through merge pathnames
*** *The fix:* ="foo/bar"= can be.
*** CL pathname solution: provide a portable *abstraction*:
**** "relative pathnames with optionally specified type"
*** ASDF FAIL: it was hard to get it actually right
**** Solution: make it hard for the user to get it wrong
*** ASDF FAIL: it was hard to know you were wrong
**** Solution: better fail early for everyone than pass as working for some
*** ASDF2 is much better, but still trips users
**** Solution: keep improving code, error cases, documentation.
** Fixing the FAILs
*** *The FAIL:* Defaulting of file pathname =:type= was irregular
*** *Change*: More predictable addition of types
\begin{tabular}{l|l|l}
Input & ASDF 1 & ASDF 2 \\ \hline
\texttt{(:file "foo")} & \texttt{\#p"foo.lisp"} & \texttt{\#p"foo.lisp"} \\
\texttt{(:file "foo.bar")} & \texttt{\#p"foo.bar"} & \texttt{\#p"foo.bar.lisp"} \\
\texttt{(:file "foo-V1.2")} & \texttt{\#p"foo-V1.2"} & \texttt{\#p"foo-V1.2.lisp"} \\
\texttt{(:static-file "FOO")} & \texttt{\#p"FOO"} & \texttt{\#p"FOO"} \\
\texttt{(:file "FOO"} & & \\
\texttt{\ \ :pathname \#p"FOO")} & \texttt{\#p"FOO.lisp"} & \texttt{\#p"FOO"} \\
% \texttt{(:file "README" :pathname \#p"README")} & \texttt{\#p"README.lisp"} & \texttt{\#p"README"}
\end{tabular}
** Fixing the FAILs
*** *The FAIL:* #p"foo/bar" can never be portable.
*** *The fix:* "foo/bar" can be.
**** Parse strings as "relative pathnames with optionally specified type"
*** You would think this would work:
......@@ -240,8 +203,8 @@ Input & ASDF 1 & ASDF 2 \\ \hline
*** Really working but horrible old solution:
\small
\begin{verbatim}
(:file "foo-bar" :pathname
#.(merge-pathnames
(:file "foo-bar" :pathname
#.(merge-pathnames
(make-pathname
:name "bar" :directory '(:relative "foo")
:type "lisp" :defaults *load-truename*)
......@@ -250,15 +213,34 @@ Input & ASDF 1 & ASDF 2 \\ \hline
*** New solution: =(:file "foo/bar")=
** Fixing the FAILs
** CL Pathname FAIL
*** *The FAIL:* Inherit inappropriate values of host and directory
*** *The FAIL:* host and directory inappropriately inherited
**** COMMENT when merging a relative pathname with =merge-pathnames=
**** Windows (and obscure old file systems)
**** Logical pathnames
*** *Core idea:* Replace =MERGE-PATHNAMES=
*** *Change*: "relative pathnames" don't override host or device.
**** Logical pathnames
*** *The fix:* replace =MERGE-PATHNAMES=
**** "relative pathnames" don't override host or device.
*** Once again, provide portable *abstraction* over implementation
** ASDF pathname FAIL
*** *The FAIL:* Defaulting of file pathname =:type= was irregular
*** *The fix*: More predictable addition of types
\begin{tabular}{l|l|l}
Input & ASDF 1 & ASDF 2 \\ \hline
\texttt{(:file "foo")} & \texttt{\#p"foo.lisp"} & \texttt{\#p"foo.lisp"} \\
\texttt{(:file "foo.bar")} & \texttt{\#p"foo.bar"} & \texttt{\#p"foo.bar.lisp"} \\
\texttt{(:file "foo-V1.2")} & \texttt{\#p"foo-V1.2"} & \texttt{\#p"foo-V1.2.lisp"} \\
\texttt{(:static-file "FOO")} & \texttt{\#p"FOO"} & \texttt{\#p"FOO"} \\
\texttt{(:file "FOO"} & & \\
\texttt{\ \ :pathname \#p"FOO")} & \texttt{\#p"FOO.lisp"} & \texttt{\#p"FOO"} \\
% \texttt{(:file "README" :pathname \#p"README")} & \texttt{\#p"README.lisp"} & \texttt{\#p"README"}
\end{tabular}
** ASDF pathname FAIL
** Fixing the FAILs
*** *The FAIL:* Easy to get module pathname spec wrong
*** *Core idea:* Intelligently interpret pathnames
......@@ -266,7 +248,19 @@ Input & ASDF 1 & ASDF 2 \\ \hline
**** *After:* Always look in "bar/"
** ASDF pathname FAIL
*** hard to get pathnames actually right
**** Fix: make it hard for the user to get it wrong
*** FAIL: hard to know you were wrong
**** Fix: better fail early for everyone than pass as working for some
*** ASDF2 is much better, but still trips users
**** Fix: keep improving code, error cases, documentation.
** Configuration Difficulties
......@@ -304,7 +298,7 @@ Input & ASDF 1 & ASDF 2 \\ \hline
*** ASDF2: configurable output translations, sensible defaults
*** Unaddressed: further configuration discrepancies (e.g, features)
*** Unaddressed: further configuration discrepancies --- see future directions
**** ASDF won't ever do it. XCVB will (not yet).
......@@ -323,11 +317,7 @@ Input & ASDF 1 & ASDF 2 \\ \hline
*** We can't simply be ``transparent'' with respect to semantic discrepancies
between underlying implementations; we must abstract those discrepancies away.
** COMMENT Missing Extension Hooks
** Missing Extension Hooks
*** Principle: anything that can be provided as an extension should be
......@@ -351,9 +341,9 @@ Input & ASDF 1 & ASDF 2 \\ \hline
** Meta-Problem: ASDF can't be fixed
*** To upgrade ASDF, a previous ASDF must not have been loaded
*** *FAIL:* very hard to use any ASDF but what the implementation provides
**** deep configuration before startup, in every implementation, every program
**** to upgrade, deep configuration before startup, in every implementation, every program
*** You may rely on a feature...
......@@ -371,13 +361,13 @@ Input & ASDF 1 & ASDF 2 \\ \hline
**** less uniformity in features available in installed base
*** Catch-22: there's no point trying to fix it unless it's already fixed
*** Catch-22: no point trying to fix it unless it's already fixed
** First, fix upgrade incentives
*** To upgrade ASDF, a previously loaded ASDF is OK and can actually help
*** *Fix:* a previously loaded ASDF is OK and can actually help to upgrade ASDF
**** just install a new ASDF, no configuration unless non-standard location
**** just install new ASDF, only configure to override sensible defaults
*** You may rely on a feature...
......@@ -387,26 +377,28 @@ Input & ASDF 1 & ASDF 2 \\ \hline
**** anytime, under small penalty of lagging behind
*** Risks of upgrading to a new version...
**** low: if there's a hidden bug, just upgrade
*** After a given implementation upgrades...
**** more uniformity in features available in installed base
*** Risks of upgrading to a new version...
** Dynamics of coordination
**** low: if there's a hidden bug, just upgrade
*** Robust process:
** Dynamics of coordination
**** each step provides more coordination than it requires
*** In a stable process, each iteration provides more coordination than it requires
*** Surprise:
*** Allowing for divergence creates an incentive towards convergence
**** Allowing for divergence creates an incentive towards convergence
*** Hot-patching allows ASDF to evolve
**** Because it's an in-image loader
**** Unix equivalent: upgrading your login shell or its startup configuration
*** So, can we upgrade an already loaded ASDF?
** COMMENT Hot-patching ASDF
......@@ -416,34 +408,50 @@ Input & ASDF 1 & ASDF 2 \\ \hline
**** While it is running /to build and load itself/
**** COMMENT image of snake eating its own tail...
** Hot-patching: how to do it
** Hot-patching challenge
*** Non-trivial: upgrading data
*** Mostly easy: upgrading data, with =U-I-F-R-C=
**** fill in new slots depending on old ones
*** Hard: changing a function's signature
**** CLOS won't even let you do it.
*** Harder: ambiguity between dynamic calls vs static calls
*** Hardest: modified functions are in the continuation of =compile-file= or =load=
**** COMMENT Can't update continuation frames; they have no first-class names to be rebound.
**** COMMENT Worse if multithreaded: no atomicity
** Hot-patching tools
*** Mostly easy: =update-instance-for-redefined-class=
**** CLOS makes dynamic data upgrade extraordinarily easy
**** "pull": everything sees the new schema. No "push" stages.
*** Hard: changing a function's signature
**** CLOS won't even let you do it.
*** declare functions =notinline=
*** Rebinding (=fmakunbound=) vs Shadowing (=unintern=)
*** Rebinding (=fmakunbound=)
**** COMMENT unintern must be done in /all/ packages
*** Shadowing (=unintern=)
**** No "rebind to transitional version that wraps the new version, then shadow"
**** COMMENT unintern must be done in /all/ packages
*** Harder: modified functions are in the continuation of =compile-file= or =load=
**** No "rebind to transitional wrapper, then shadow"
**** COMMENT Can't update continuation frames; they have no first-class names to be rebound.
**** Bad: which to use is not portable in practice
**** COMMENT Worse if multithreaded: no atomicity
*** *SUCCESS:* CL does support hot upgrade of code
*** CL support for hot upgrade of code exists but is anything but seamless
**** but it is anything but seamless
* Future directions
** COMMENT 2 slides here
** Future directions
......@@ -455,7 +463,6 @@ Input & ASDF 1 & ASDF 2 \\ \hline
*** Better documentation
** Outstanding bug: across system dependencies do not properly trigger recompilations
+ We /did/ fix a related bug --- module dependencies didn't work in ASDF 1
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment