Hi Daniel,
I did manage to get warning suppression implemented in ASDF. (4) turned
out to be not an issue since I only needed to climb up the component
tree to get the information I needed. (4) would still be desirable for
implementing some types of runtime behavior, though.
Daniel Barlow wrote:
> [email protected] writes:
>
>
>>1. A new package created each time an asdf system definition is loaded.
>
>
> To avoid polluting CL-USER or ASDF, yes. People are allowed to
> designate component names with symbols, and some newbie somewhere is
> going to get very confused when stuff starts appearing in CL-USER
Not going to complain about that!
>>These packages are not flushed when the system is redefined or deleted.
>
> This would be nice
>
>
>>Even if you throw in an in-package in the system definition a new
>>package is created. Why is this? If you don't want to use the cl-user
>
>
> Because afaik there's no nice way prior to loading a file to tell that
> it contains an in-package form.
If you are reloading a package that has previously existed on file (that
is the only case in which you create a package, right?) then you should
be able to look at the name of the system that has been requested for an
operation and find out what package the symbol had existed in. Do you
see any problems with this scheme?
>>package, why not create a single asdf-systems package? By the way, a new
>>package is created even if we have a definition being reloaded? Why not
>>reuse the previously defined package?
>
>
> I'm not convinced that using the same package for all these systems
> would work, but it would certainly be an improvement if the scratch
> packages were releted or reused after they're finished with.
Can you think of an example where it would cause a problem? I am a
little annoyed with ASDF leaving around packages in my lisp image.
>
> (Deleting or emptying a single ASDF-SCRATCH package before each
> operation sounds like a really good way to eventual freaky bug when
> multiple threads might be loading a system at the same time)
If you are using a single package for system definitions, deleting or
emptying it would be highly undesirable.
>>2. If you have a specialized operation class that adds slots, and you
>>set values in those slots, then redefining the system does not get rid
>>of the slot values. The problem appears to be that asdf always tries to
>>reuse existing system objects when redefining a class. There is explicit
>>code to unset some of the slot values in parse-component-form. If you
>>add a subclass that defines additional slots, there is no interface for
>>unsetting those slots at the right time. This whole problem could be
>>avoided if new object instances were *always* created when definitions
>>were reloaded, and the necessary data were copied over from the old
>>definition. Is there any reason this approach has not been used? It
>>would also correctly address the issue of handling components that have
>>been removed from a redefined system definition.
>
>
> The reason, such as it is, dates back to the original design of asdf
> in which we thought that people were often going to define
> EQL-specialised methods on particular components to do specialised
> things (we even have a special shorthand syntax for it, although I'm
> not sure that it hasn't bitrotted). So, we try to preserve object
> identity for components - this makes a difference when people evaluate
> defsystem forms interactively instead of reloading the whole file
If you are loading a system definition through define-system, only then
would you be calling parse-component-form, right? In that case, you
can't really effectively get hold of the individual component objects,
so trying to define eql methods on the component objects would be rather
difficult. On the other hand, doing things this way does limit the ease
of extending ASDF, and makes things like handling deleted components
rather difficult. Perhaps it's time to reconsider this design decision?
>>3. parse-component-form is a poorly commented monolithic function, and
>>for no apprent reason.
>
>
> It grew.
:-)
>
>
>>Makes it rather hard to read. In general, it
>>appears that asdf source does not document even key functions such as
>>perform and operate.
>
>
> Have you looked at the README?
Yes, and it isn't a very good substitute for inlined comments and
descriptions. An external documentation of the package to me serves a
very different purpose than in-lined comments, which ought to be a lot
more detailed about the design decisions and functioning of the code. It
is rather tedious to go from reading the code to searching the README
for code documentation, and then perhaps finding it isn't there.
>>4. It appears that perform is only called on files, and not on higher
>>level objects such as systems and modules. Why is that? If there is a
>>property of the system that I want to define at the system level, then
>>I want that property to affect the components within the
>>system. Presently, asdf does not seem to be set up to accomodate such
>>closure.
>
>
> We have actually tried this both ways, and my recollection is that
> there arguemnts against both approaches (sadly, there seems to be
> little argument for either of them). But I can't actually remember
> what the issues are right now, so I'll tackle this another time when
> I'm more awake.
>
Well, the argument for perform'ing on higher level objects is two fold:
you can keep track of operations performed at a higher level, and prune
faster the parts of a system that don't need to be considered for the
particular operation. And perform'ing on higher level objects allows the
creation of a nested dynamic context that better resembles the execution
of a program, giving a more natural programming paradigm for anyone
interested in extending ASDF with their own functionality. Of course,
the implementation would require the operations on low level components
to be performed within the dynamic context of the operations on higher
level components.
>
>>I've had to make some minor changes to asdf to accomodate the
>>extensions I'm making, I'll pass everything by the mailing list once I
>>have them working. (2) and (4) above are larger issues getting in the
>>way of the implementation of my extension. The fix for (2) isn't that
>>hard. For (4) you will likely have to rethink the present
>>traverse-then-perform approach that asdf uses.
>
>
> That's actually quite likely to happen anyway: the plan-then-execute
> approach is a pain far more often than it's actually any use.
Cool!
If you want a hand with some implementation work, I happen to have some
time these days. Be happy to help out.
Sunil
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.