Commit dffc57f1 authored by Francois-Rene Rideau's avatar Francois-Rene Rideau
Browse files

Some changes

parent 059c40b9
......@@ -18,9 +18,6 @@
*** Table? Something to make the before and after stand out
*** Add the missing trailing slash in module pathnames to the slide...
** TODO Missing extension hooks
[[*Missing Extension Hooks]]
*** Can we say what we did to fix this? Extend the published API?
*** Possible bonus: Anything broadly interesting about the change?
+ Take home message about how to build your next API?
+ Ease/difficulty of changing API?
......@@ -318,31 +315,88 @@ Input & ASDF 1 & ASDF 2 \\ \hline
*** POIU (Parallel extension) needed to redefine some classes and methods
**** Hard to maintain as ASDF was evolving
*** ITA needed some extensions for printing compilation progress.
*** Solution: merge the extensions into ASDF2
**** APIs remain undocumented, but at least they are here.
*** It's a social problem with no known technical solution.
**** Solution made easier because the same person became maintainer of all these
* Hot-patching ASDF
** COMMENT 4 slides here
** Meta-Problem: ASDF can't be fixed
** Hot-patching ASDF
*** To upgrade ASDF, a previous ASDF must not have been loaded
**** deep configuration before startup, in every implementation, every program
*** You may rely on a feature...
**** only if all supported implementations have upgraded
*** It brings value for an implementation to upgrade...
**** only after everybody else agreed to upgrade
*** Risks of upgrading to a new version...
**** high: a hidden bug can seriously cripple the implementation
*** After a given implementation upgrades...
**** more disuniformity in features available in installed base
*** Catch-22: there's 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
**** just install a new ASDF, no configuration unless non-standard location
*** You may rely on a feature...
**** anytime, ship recent ASDF if a feature isn't universally installed
*** It brings value for an implementation to upgrade...
**** anytime, under small penalty of lagging behind
*** After a given implementation upgrades...
**** more uniformity in features available in installed base
*** Risks of upgrading to a new version...
**** low: if there's a hidden bug, just upgrade
** Dynamics of coordination
*** In a stable process, each iteration provides more coordination than it requires
*** Allowing for divergence creates an incentive towards convergence
*** Loading ASDF into a running CL image containing ASDF
*** Hot-patching allows ASDF to evolve
*** Why is this critical?
**** Because it's an in-image loader
**** If people can't load a new ASDF on top of an old one, they can never write portable code using new features
**** Unix equivalent: upgrading your login shell or its startup configuration
**** /Unless/ all the implementations get together and /simultaneously/ update their packaged versions
*** So, can we upgrade an already loaded ASDF?
**** Hot-patching allows ASDF to evolve
** Hot-patching ASDF
*** Why is this hard?
**** We are replacing bits of ASDF /while it is running/
**** While it is running /to build and load itself/
**** COMMENT image of snake eating its own tail...
** Hot-patching: how to do it
*** Mostly easy: upgrading data, with =update-instance-for-redefined-class=
......@@ -364,20 +418,6 @@ Input & ASDF 1 & ASDF 2 \\ \hline
**** Worse if multithreaded: no atomicity
* Configuration
** COMMENT 4 slides here
** Configuring ASDF
*** Need to be able to find systems
**** We can find system components from the system definition
**** But we still need to find the system definitions!
*** Need to place compiled files
/Explain the need here/
* Future directions
** COMMENT 2 slides here
......@@ -538,43 +578,6 @@ Input & ASDF 1 & ASDF 2 \\ \hline
**** notable testing by Zach Beane, Samium Gromoff, Daniel Herring...
** Unupgradability of ASDF
*** To upgrade ASDF...
**** ASDF1: deep configuration before startup, in every implementation, every program
**** ASDF2: just install ASDF, no configuration unless non-standard location
**** you may rely on a feature...
***** ASDF1: only if all supported implementations have upgraded
***** ASDF2: anytime, ship recent ASDF if a feature isn't universally installed
**** it brings value for an implementation to upgrade...
***** ASDF1: only after everybody else agreed to upgrade
***** ASDF2: anytime, or the implementation will lag behind
**** After a given implementation upgrades...
***** ASDF1: more disuniformity in features available in installed base
***** ASDF2: more uniformity in features available in installed base
** First, fix upgrade incentives
*** Dynamics of coordination
**** In a stable process, each iteration provides more coordination than it requires
*** Allowing for divergence creates an incentive towards convergence
** General Lessons Learned (Summary)
**** ASDF is an ``in-image'' build system managing systems that are compiled and loaded
......
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