Re: Proposal: make asdf output go to *standard-output*

Hi Richard,

I'm entirely in favor of this change. Thanks for doing such a great  
write up, by the way. It makes it very clear what you want and why.


On Dec 14, 2006, at 3:57 PM, Richard M Kreuter wrote:

> Hello,
>
> I'd like to propose that asdf send its output to *standard-output* (by
> having asdf:operate bind asdf::*verbose-out* to cl:*standard-output*
> instead of *trace-output*), and that it be documented that .asd files
> and asdf extensions that print output should do so to
> *standard-output*, too.  A patch to this effect is appended.
>
> Here's the rationale: there has be some way to stifle output during
> asdf:operate in order for programs to use asdf in contexts where it's
> necessary to be persnickety about output (e.g., Unix-style scripts and
> cron jobs).  At present, there's no way to do this without digging
> into asdf.lisp itself, and then there are various deficiencies:
>
> (0) asdf:operate's verbose keyword doesn't stifle very much output
>     when nil is supplied.  Compiler and loader output, as well as any
>     compile-time or load-time print operations in .asd files or in
>     system components still get out.
>
> (1) asdf:operate's verbose keyword only stifles output from that call
>     to operate -- output will still be emitted if asdf:operate is
>     called during the operation without :verbose nil.  This is the de
>     facto standard way to require prerequisite asdf systems, and there
>     are a several incidences of this in the wild.
>
> (2) The stream that asdf uses for output internally, *verbose-out*, is
>     not exported, and so it's unclear where systems and extensions are
>     supposed to send their output.  There's at least one system
>     available that prints to *standard-output* in the .asd file.
>
> (3) *verbose-out* gets bound to the wrong standard stream
>     (*trace-output*).  The Lisp compiler and loader print to
>     *standard-output*, if at all; *trace-output* has a different
>     purpose, and having asdf send output there is usability annoyance
>     if you're saving traces or timings to a file and using asdf at the
>     same time.
>
> Also, for completeness,
>
> (4) The oddball explain-op class is made extra screwy by the above:
>     :verbose nil makes asdf:perform on direct instances of explain-op
>     into no-ops, and subclasses of explain-op that don't either break
>     package system encapsulation or depend on asdf internals can't
>     rely on superclass's methods doing anything.  (Probably the method
>     of asdf:perform that specializes on instances of asdf:explain-op
>     should print to *standard-output* directly, rather than to
>     asdf:*verbose-out*, but that's a separate issue that I don't care
>     much about.)
>
> Here are the upsides of the proposed change:
>
> * output from operators defined in asdf.lisp, from .asd files, from
>   asdf extensions, and from the Lisp compiler and loader will all go
>   to the same place, and so users can silence all of that by rebinding
>   *standard-output* around their top-level calls to asdf:operate.
>
> * asdf:operate's verbose argument will stifle only what it already
>   does (i.e., output from find-system, register-system,
>   run-shell-command, and perform on explain-ops), for people who care
>   about that interface.
>
> * *trace-output* will be freed up for its useful, standard purpose.
>
> This change is, strictly speaking, incompatible with what goes on
> inside asdf.lisp right now, but won't affect existing systems or
> extensions, unless they already break package system encapsulation or
> depend on asdf printing to *trace-output*.  Users of an updated
> asdf.lisp will just be able to say the following wherever they need to
> silence asdf:
>
> (let ((*standard-output* (make-broadcast-stream)))
>   (asdf:operate ...))
>
> Thanks,
> RmK
>
> --- asdf.lisp	2006-12-14 15:12:09.000000000 -0500
> +++ asdf.lisp.~1.102.~	2006-12-13 15:56:20.000000000 -0500
> @@ -872,7 +872,7 @@
>    (let* ((op (apply #'make-instance operation-class
>  		    :original-initargs args
>  		    args))
> -	 (*verbose-out* (if verbose *standard-output* (make-broadcast- 
> stream)))
> +	 (*verbose-out* (if verbose *trace-output* (make-broadcast-stream)))
>  	 (system (if (typep system 'component) system (find-system  
> system))))
>      (unless (version-satisfies system version)
>        (error 'missing-component :requires system :version version))
>
> --- asdf.texinfo.~1.5.~	2004-08-18 08:54:26.000000000 -0400
> +++ asdf.texinfo	2006-12-14 15:37:56.000000000 -0500
> @@ -188,6 +188,11 @@
>  (asdf:operate 'asdf:load-op '@var{foo})
>  @end example
>
> +Output from asdf and asdf extensions are supposed to be sent to  
> the CL
> +stream @code{*standard-output*}, and so rebinding that stream around
> +calls to @code{asdf:operate} should redirect all output from asdf
> +operations.
> +
>  That's all you need to know to use asdf to load systems written by
>  others.  The rest of this manual deals with writing system
>  definitions for Lisp software you write yourself.
> @@ -204,6 +209,7 @@
>  * The defsystem form::
>  * A more involved example::
>  * The defsystem grammar::
> +* Other code in .asd files::
>  @end menu
>
>  @node  The defsystem form, A more involved example, Defining  
> systems with defsystem, Defining systems with defsystem
> @@ -316,7 +322,7 @@
>  have been processed, but before the component in question has been
>  compiled.
>
> -@node  The defsystem grammar,  , A more involved example, Defining  
> systems with defsystem
> +@node  The defsystem grammar,  Other code in .asd files, A more  
> involved example, Defining systems with defsystem
>  @comment  node-name,  next,  previous,  up
>  @section The defsystem grammar
>
> @@ -409,6 +415,23 @@
>  within an editor without clobbering its source location)
>  @end itemize
>
> +@node Other code in .asd files, , The defsystem grammar, Defining  
> systems with defsystem
> +@section Other code in .asd files
> +
> +Files containing defsystem forms are regular Lisp files that get
> +executed by @code{load}.  Consequently, you can put whatever Lisp  
> code
> +you like into these files (e.g., code that examines the compile-time
> +environment and adds appropriate features to @code{*features*}).
> +However, some conventions should be followed, so that users can
> +control certain details of execution of the Lisp in .asd files:
> +
> +@itemize
> +@item
> +Any informative output (other than warnings and errors, which are the
> +condition system's to dispose of) should be sent to the standard CL
> +stream @code{*standard-output*}, so that users can easily control the
> +disposition of output from asdf operations.
> +@end itemize
>
>
>  @node The object model of asdf, Error handling, Defining systems  
> with defsystem, Top
> @@ -594,6 +617,9 @@
>
>  @end itemize
>
> +Operations that print output should send that output to the standard
> +CL stream @code{*standard-output*}, as the Lisp compiler and  
> loader do.
> +
>  @node Components,  , Operations, The object model of asdf
>  @comment  node-name,  next,  previous,  up
>  @section Components
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> cclan-list mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cclan-list

--
Gary Warren King, metabang.com
Cell: (413) 885 9127
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM





-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV