Re: ASDF test-op

Todd Sabin wrote:
> Robert Goldman <[email protected]> writes:
> 
>>>  2. control the stream to which ASDF sends output during an operation
>>>
>>> In particular, we'd like to do this for test-ops but other ops could
>>> also make use of this.
>>>
>>> The most general solution might be to
>>>
>>>  1. add a generic function:
>>>
>>>      (defgeneric output-stream-for-component-and-operation (component
>>> operation))
>>>
>>>  2. add an `output-stream` slot to operation
>> 2.5 Add an :output-stream initarg to operation.  I figure that this was
>> implicit in your 2, but just wanted to be explicit...
>> [etc.]
> 
> Hi,
> 
> Doesn't ASDF already write all of its output to a particular stream,
> namely *verbose-out*?  (Provided you've bound it to something, of
> course) Couldn't you just document that test-op writers should write
> to that stream?  Or maybe that doesn't work because, by default, it's
> bound to nil, so you define another dynamic variable *test-output*, or
> something, and document that?
> 
> I guess I don't really understand the problem you're solving, and I'm
> wondering why all the CLOS machinery is necessary...
> 

What we're trying to avoid is having the test outputs be mixed in with
the normal ASDF outputs.

Here's a concrete bad (by "bad" I mean "undesirable," not "buggy")
behavior I have seen:

I have a test-op for a large and complex system.  This test op loads
multiple ASDF components, each of which gets compiled.

The problem is that instead of getting a nice printed output from my
testing, I get a stew of compiler messages and test outputs all mooshed
together.  This makes it hard for me to see if the tests went ok.

So I'd like to send the test outputs off somewhere else, so I don't have
to skip over all the compiler messages.

best,
r




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/