On 19 Feb 2019, at 1:18, 73budden wrote:
Hi!
Every time I read "asdf", I feel a pain. I've read that there is an
attempt to gain resources to improve asdf. I have a sort of plan.
1. Shims. Recent tightening of rules for system definitions is ok, but
there are old systems with no maintainers. If such system does not
obey the rules, one can introduce "shim" concept. I've met them in JS
culture where they serve as third-party adapters to connect two
mismatching things.
In the simplest way shim is just an alternative directory hierarchy
with shim asd files, isomorphic to local lisp directory structure.
When looking for system, asdf must search in shims directory first,
and only then in the directory of the file itself. Also things like
quicklisp might take care of installing shims where they exist.
Maintanence of shims for all popular systems can be done within a
separate git repository.
For the moment, I think the only issue related to rules tightening is
that we ask people to use the proper complex system names (see my recent
change to the ASDF manual, available from the page on `common-lisp.net`.
Is that what you are referring to? Or are there other issues causing
pain?
If it's just that, insert the name of the asd file (name only -- no
extension) into `*known-systems-with-bad-secondary-system-names*`.
E.g.,
```
(setf (gethash "terrible-legacy-system"
*known-systems-with-bad-secondary-system-names*) t)
```
... and that will suppress the warnings for you.
That set has "cl-ppcre" built into it, and I'm happy to add other
systems that are in common use, but unmaintained.
I should put documentation of this into the manual
The shims idea is interesting, but isn't it a lot of trouble to make and
maintain a shim (which has to somehow indicate where to find the source
files for the library), compared to forking a system?
If you have a more specific idea for how this works, I'd be happy to
discuss it further.
2. Get rid of upgrade. Upgrade feature requires to maintain a 3d array
of possible cases, where dimensions are "old asdf version", "new asdf
version" and "lisp implementation". It is hard to maintain and it will
get harder and harder to maintain as the time goes on. Also upgrade is
a good test of CLOS, but running tests at the very beginning of image
bootstrap is not a good idea because there is no e.g. SLIME to work
with convenience.
I don't know about doing away with upgrade, but certainly cutting
**way** down on the upgrades we support is a good idea. For CMUCL, we
now only test and support 3.3.0+
I'm willing to do that for many more implementations, if I can figure
out what ASDF versions they are shipping on what target platforms.
3. Last, but most important actually. Prioritize manual, FAQ, Wiki and
all like this.
I'm ok with that, but I don't have the time for an end-to-end rewrite of
the manual. Note that I am also going to integrate **everything** into
the manual, because I don't have the time to support more than one
documentation set (e.g., Fare's Markdown stuff will get folded into the
manual).
Part of the problem is that the manual doesn't have a clear structure.
It shoold somehow start off by teaching only the basics, in a very
brief discussion, then get to more advanced topics, then the object
model, and stuff that only an extender, developer, or maintainer would
want to know. But it's quite possible I will retire or die before I
manage to do that level of rewrite.
Restructuring is *really* not something that Texinfo makes easy, but
Texinfo seems to be the worst documentation system ... except for all
the other ones.
A contribution I would *love* to have is an adaptation of the SBCL
manual code that extracts symbols and docstrings for inclusion in
Texinfo. At one point I looked into Didier's library (DecIt, I think?),
but while it's good at extraction, I couldn't see how what it extracts
could be moved around and integrated with large blocks of text.
I'm happy to accept FAQ suggestions and get them into the manual.
Instead, when loading asdf, allow the user to pass the parameter that
fills asdf database with the initial loaded system information. It
would be also good to have an utility to extract this database from
some old asdf versions. This way we have a slight chance to make
things easier, upgrade process explicit and under user's control.
I'm not exactly sure what is meant by the above.
I have a number of different projects I work on, each with their own set
of libraries. I have made simple functions for each of these projects
that populates `asdf:*central-registry*`, and when I sit down to work on
one of these systems, I just invoke that function. That's always been
sufficient for me. So something like:
```
CL-USER> (shop2)
"SHOP2 libraries available."
NIL
CL-USER> (asdf:test-system "shop2")
```
I still use `*central-registry*` for that because (1) I wrote it before
Fare's new DSL was
