Next: , Previous: , Up: Top   [Contents][Index]


13 TODO list

Here is an old list of things to do, in addition to the bugs that are now tracked on launchpad: https://launchpad.net/asdf.

13.1 Outstanding spec questions, things to add

** packaging systems

*** manual page component?

** style guide for .asd files

You should either use keywords or be careful with the package that you evaluate defsystem forms in. Otherwise (defsystem partition ...) being read in the cl-user package will intern a cl-user:partition symbol, which will then collide with the partition:partition symbol.

Actually there’s a hairier packages problem to think about too. in-order-to is not a keyword: if you read defsystem forms in a package that doesn’t use ASDF, odd things might happen.

** extending defsystem with new options

You might not want to write a whole parser, but just to add options to the existing syntax. Reinstate parse-option or something akin.

** document all the error classes

** what to do with compile-file failure

Should check the primary return value from compile-file and see if that gets us any closer to a sensible error handling strategy

** foreign files

lift unix-dso stuff from db-sockets

** Diagnostics

A “dry run” of an operation can be made with the following form:

(traverse (make-instance '<operation-name>)
          (find-system <system-name>)
          'explain)

This uses unexported symbols. What would be a nice interface for this functionality?

13.2 Missing bits in implementation

** reuse the same scratch package whenever a system is reloaded from disk

** proclamations probably aren’t

** when a system is reloaded with fewer components than it previously had, odd things happen

We should do something inventive when processing a defsystem form, like take the list of kids and setf the slot to nil, then transfer children from old to new list as they’re found.

** (stuff that might happen later)

*** Propagation of the :force option.

“I notice that

(asdf:compile-system :araneida :force t)

also forces compilation of every other system the :araneida system depends on. This is rarely useful to me; usually, when I want to force recompilation of something more than a single source file, I want to recompile only one system. So it would be more useful to have make-sub-operation refuse to propagate :force t to other systems, and propagate only something like :force :recursively.

Ideally what we actually want is some kind of criterion that says to which systems (and which operations) a :force switch will propagate.

The problem is perhaps that “force” is a pretty meaningless concept. How obvious is it that load :force t should force compilation? But we don’t really have the right dependency setup for the user to compile :force t and expect it to work (files will not be loaded after compilation, so the compile environment for subsequent files will be emptier than it needs to be)

What does the user actually want to do when he forces? Usually, for me, update for use with a new version of the Lisp compiler. Perhaps for recovery when he suspects that something has gone wrong. Or else when he’s changed compilation options or configuration in some way that’s not reflected in the dependency graph.

Other possible interface: have a “revert” function akin to make clean.

(asdf:revert 'asdf:compile-op 'araneida)

would delete any files produced by (compile-system :araneida). Of course, it wouldn’t be able to do much about stuff in the image itself.

How would this work?

traverse

There’s a difference between a module’s dependencies (peers) and its components (children). Perhaps there’s a similar difference in operations? For example, (load "use") depends-on (load "macros") is a peer, whereas (load "use") depends-on (compile "use") is more of a “subservient” relationship.


Next: , Previous: , Up: Top   [Contents][Index]