[Ecls-list] ECL support for cl-launch and xcvb

[Faré]

2009/11/9 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com>:
> On Mon, Nov 9, 2009 at 12:16 PM, Faré <fahree at gmail.com> wrote:
>> I'll see if that bug is still there if/when I'm past the other bug.
>> Interestingly, the si:getenv function worked at the command-line; it
>> just failed badly when compiled into compute-arguments.
>
> Is there a systematic way for me to reproduce the problem? Some test
> in cl-launch perhaps?
>
Yes, in a fresh directory (where plenty of files will be created), try
   cl-launch -l ecl -B tests

It should successfully test 234 combinations of invocation flags for
cl-launch with ecl (numbered from 0 to 233).

I fixed my issues with ecl's asdf:make-build, and so I'm pleased to
announce that cl-launch 2.33 fully supports the latest ECL from CVS.

One limitation that cl-launch has on ECL (vs on e.g. SBCL) is the
inability to "dump an image from a previous image". This would require
hacking make-build to intercept in a (defmethod perform :before ((op
monolithic-bundle-op) (c system)) ...) the arguments to the last call
to c::builder so I may re-inject them the next time around, assuming
(which is somewhat fragile) that objects won't have moved or been
deleted by then. I do not intend to support this feature in cl-launch,
but will hopefully support it in XCVB that can do the bookkeeping on
its side.

For the record, the issue I finally found and fixed in building an
image was as follows: asdf:traverse is traversing system dependencies
in reverse order or those listed. This was breaking the assumption
that cl-launch was making that it could list its magic prefix system
first (including essential cl-launch support code) and have it loaded,
linked and initialized before the rest of the program (which is
user-provided and can use cl-launch functionality but cannot refer to
ecl-specific cl-launch internals). This assumption used to be
verified, either because an older asdf traversed things in the right
order, or because asdf-ecl previously wasn't using traverse but was
otherwise walking in the source order. In any case, my "fix" (really a
workaround) is to specify the magic cl-launch prefix system both at
the beginning and end of the list of system dependencies to be sure to
be loaded first, whichever end traverse will start from now and in the
future.

I noticed that you're using what looks like an old version of
asdf.lisp. There have been numerous improvements in asdf recently, and
having been following them, I think that current revision 1.369 from
git is probably a good pick for an update, except that it doesn't work
in ECL as-is. It would be nice if you would merge your changes into
upstream.


> If you want, I could integrate cl-launch in the list of libraries and
> programs that are automatically tested. I placed an announcement some
> time ago about this project
> http://ecls.sourceforge.net/logs_lib.html
>
That would be just great! Could you include cl-launch 2.33 there?

Hopefully, I can add xcvb there some day, too, but it doesn't yet
support either ECL or Windows.


> Since then two things have happened. First, I received zero feedback,
> except for the projects that most actively support ECL, Sage,
> OpenAxiom, Fricas and Maxima. The first one is providing several of
> the test platforms, and the last ones have helped with either the
> porting or help and rely on this initiative.
>
I apologize for not responding earlier.
I just don't have many testable libraries at this point of time.

> The other thing is that I have come to realize is that there is no
> systematic way of testing libraries. ASDF does not provide support for
> this. I have posted a call for help, or better for consensus the
> Common Lisp community, but so far the best I got was either being
> ignored or recriminated for being too emphatic about this.
>
Yeah, I saw your messages on the ASDF mailing-list.
I think it's not going to happen there.
I'd like to support something in XCVB, though, but I don't know what yet,
and have been fighting more urgent lacks of feature, first.

> I find that currently there is no excuse for ASDF not to include a
> TEST operation that returns useful information so that _all_ libraries
> use it. Being challenged, I contributed a patch to ASDF that adds two
> things: 1) a logging facility to better discover which components fail
> and 2) a new operator TEST-OP that returns a value, whether the tests
> succeed or not, with at least one example binding to the RT library
> that collects the failures. Again, zero feedback about that.
>
There were discussions on the asdf-devel list, but inconclusive so far.
The difficulty is that there are plenty of incompatible legacy test
facilities for CL, none being the obvious choice to unify the other ones.

> Anyway, that was the usual rant that I feel the need to make from time
> to time :-). I will persist in the effort of building as many
> libraries as I can against current versions of ECL. All I need is
> 1) A repository for downloading periodically
> 2) either the library to use ASDF or provide a simple procedure
> (simple means one lisp statement) to build,
> 3) equally simple form to run tests and return an OK or FAILURE value.
> To add cl-launch, that is all I need and I would strongly encourage
> you to help me on this.

To test cl-launch:

1- pull it from git.
   git {clone|pull} http://common-lisp.net/project/xcvb/git/cl-launch.git
2- create and enter your own private temporary directory
   mkdir /tmp/cl-launch-test ; cd /tmp/cl-launch-test
3- run the test
   /path/to/git/checkout/cl-launch.sh -l ecl -B tests
4- check the exit code

PS: I want to thank you for the stellar support you've been providing.

PPS: did you realize that the current ECL version numbering has a Y2.1K bug? :-)

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
If normative judgments cannot be rational, then science is actually useless.
		-- François Guillaumat