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 available and (2) I really don't have a handle on how to debug DSL-based configuration when it goes wrong (and configuration by environment variable is even more difficult, because the debugging environment isn't available until after the environment variables have been processed).

I hope this is helpful,
R