Re: ASDF test-op

Gary King wrote:
> Hi Robert,
> 
> I think that your proposal(s) are both steps in the right direction.
> Just to clarify (and to think out load), there are two issues we'd like
> to solve:
> 
>  1. allow ASDF to communicate the results of an operation back to the
> caller

This one seems to require more radical surgery and a good deal of thought.

Proposal:  let's put a solution to #2 in place because we can do this
with RELATIVELY little modification to ASDF 1.x.  Your #1 seems to edge
us very clear to ASDF 2.0.

I don't *mind* that, but I'd like to see a solution to #2 not be put on
the back-burner for that long.

>  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...
> 
>  3. add an around method to perform
> 
>         (defmethod perform :around ((operation operation) (c component))
>           (let ((*standard-output*
> (output-stream-for-operation-and-component
>                         operation component)))
>             (call-next-method)))

I am of two minds about this.  I think it's The Right Thing, but I'm
inclined to shy away from messing with the default behavior  --- I'd
prefer to leave that to the implementation.  For example, I don't know
if there are cases where you'd prefer Allegro to do whatever it wants.
E.g., in its multiprocessing version, I don't know if it ever uses
*initial-terminal-io* instead of *standard-output*...  And I don't have
the foggiest idea how this might interact with either LW or ACL's IDEs
or anyone using McCLIM...  I'd propose we see if anyone in the SBCL
community weighs in with an opinion on whether this is desirable.  Also,
do compilers ever write to an error output stream as well as
standard-output?  If so, the above might not be a happy choice.

My idea was more "it will behave in its usual way unless the user
explicitly indicates an interest to change it AND the library packager
ALSO codes to make the behavior changeable."

> 
>  4. and a "default" value for output-stream-for-component-and-operation
> 
>         (defmethod output-stream-for-component-and-operation
>             (component operation)
>           *standard-output*)

Why wouldn't this be

(or (operation-output-stream operation) *standard-output*)

?

or possibly we should have the above and also

(defmethod output-stream-for-component-and-operation (component (op
operation))
   (if (slot-boundp op 'output-stream)
       (operation-output-stream op)
       *standard-output*)))

in place of *standard-output* possibly (call-next-method), depending on
your preferences about CLOS usage...

For that matter, should we have my SLOT-BOUNDP, or should there be an
:initform *standard-output* on that slot of component?

> 
> AFAICT (from an admittedly cursory analysis), these changes would not
> alter anything `downstream` unless and until a new
> `output-stream-for-component-and-operation` method was written.

I don't understand --- your around method seems to give an immediate
change in external behavior.

Suggestion:

Have an operation-output-stream gf AND an
output-stream-for-component-and-operation.  That would permit the
programmer to simply look at the operation if s/he wants as in the
snippet above.

> 
> (There is some danger involved in adding the around method. To mitigate
> against this, I think we should add an new class operation-abstract that
> is the sole superclass of operation and then use that for the around
> method).

Just to clarify - You want to do this to avoid clobbering anyone's
existing :around methods?
> 
> On the other hand, this proposal is sort of the opposite of your. You
> use the result stream to modify `cl-user::*nst-default-report-stream*`
> whereas I'm suggesting using `cl-user::*nst-default-report-stream*` to
> modify the result-stream. E.g., by writing:
> 
>     (defmethod output-stream-for-component/operation
>         ((component (eql (find-system 'my-system))) (operation test-op))
>       cl-user::*nst-default-report-stream*)
> 
> thoughts?

I think your stuff is fine --- I would still use my method to change
that cl-user variable.  The reason is that *nst-default-report-stream*
is a variable used by our local NST unit testing library (should be open
sourced some day soon).  In general, I want it to be set to
*standard-output*, but I would like the :output-stream argument to
(asdf:oos 'asdf:test-op <my-system> :output-stream str) to override its
default (which is *standard-output*).


-- 
Robert P. Goldman
Senior Scientist
Smart Information Flow Technologies (d/b/a SIFT, LLC)

211 N. First St., Suite 300
Minneapolis, MN 55401

Voice:	(612) 384-3454
Email:    [email protected]

-------------------------------------------------------------------------
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/