[xcvb-devel] run-program/process-output-stream

[Peter Keller]

On Fri, Apr 15, 2011 at 12:24:11AM -0400, Faré wrote:
> >> As I realize it has to deal with portability, I'm considering having
> >> master either depend on driver, or be merged into driver so that it
> >> remains a single file. What do you think?
> >
> > IMHO, I personally would make a subdirectory called xcvb/vendor and break
> > up both driver.lisp and master.lisp into individual files representing
> > their little areas.
> >
> Yes and no. Once again, for the driver as well as the master or asdf,
> the ability to load the whole shebang in one command is appreciable;
> and since they are the kind of things you load before anything else,
> that command must be load (or require, once it becomes standard),
> and not some fancy thing. OR, you could assume that ASDF will always
> be present (a somewhat depressing thought, since the xcvb master
> is meant to replace ASDF, but possibly realistic),
> and indeed define a system that you may subdivide as you want.

Ah, so there is some other reason for a particular source layout instead
of categorization for human understanding purposes. :) Given the above,
I'd merge driver.lisp and master.lisp together into one file. It would
be around 1100 lines (and likely more after time), but most of the
functionality in those filea are pretty distinct from each other. I'd
just separate the sections with comment blocks.

> > Yeah. In dealing with the newline issue, I did this:
> >
> > ;; add a "newline" to a string
> > (defmacro nl (str) `(format nil "~A~%" ,str))
> >
> Sounds good.

Come to think of it, the above defmacro can just be a defun, no need to
do macro expansion...

> As of late, ASDF does magic to achieve features
> :asdf-windows and :asdf-unix. We could do similarly in say xcvb-driver.

I was just curious because then certain unit tests could be made to be more
unix or windows specific, for example:

(defvar *cat* #+unix "/bin/cat" #+win32 "type")

> >> Having to deal with PATHs under Windows is the promise of HELL.
> > Maybe you can lift this interface:
> >
> > http://perldoc.perl.org/File/Spec.html
> >
> I don't think it's relevant for xcvb-master.
> No, the problem would rather beto either detect
> some essential programs and use their full name.

Ok, I see what you mean. I barely know anything about windows, so I
can't give much better information on that topic.

Later,
-pete