I did see this once. I think that not everything got rebuilt. It
might have been happening because the ecl executable was not finding
the right libecl.so file. No not...
It was solved by removing the ecl-0.9f subdir, reuntaring the files,
./configure, and make/make install.
On Fri, Aug 05, 2005 at 10:40:34AM +0200, Juan Jose Garcia Ripoll wrote:
> On Thu, 2005-08-04 at 19:26 +0200, Nicolas Neuss wrote:
> > Juan Jose Garcia Ripoll <lisp@...> writes:
> > > You need TCP sockets for slime to work. Configure ECL with the flag
> > > --with-tcp and rebuild it.
> > Now it does not start up any more:
> > $ ecl
> > Unrecoverable error:
> > Lisp initialization error.
> This is strange. Configuring --with-tcp and without it should make no
> real difference, as it only decides whether to build some extra module
> or not (the code in the library for it is minimal). Did you remove the
> _build_ directory before configuring again?
> > > Fixed in CVS. My latest commit to fix translation problems when :VERSION
> > > = :WILD was a total disaster born out of the lack of sleep.
> > Are CVS changes immediately visible to others? I probably did not get them
> > yet, because the problem still remains.
> There is a delay for anonymous access. However one my test machines uses
> the anonymous repository and it built and tested successfully. See
> Redhat 8.0 in http://ecls.sourceforge.net/status.html
> > > I am looking now into the output of the compiler. Most likely, the array
> > > operations are not being inlined. However, I would never implement these
> > > operations in lisp itself, but rather link against an optimized BLAS
> > > library. I do that even when programming in C/C++.
> > OK, but at some points I have to do other FP operations than BLAS. If an
> > implementation fails to optimize those simple loops, it will probably fail
> > also for the more complicated cases. Furthermore, having those routines in
> > Lisp adds quite some portability, because FFI is not standardized.
> UFFI is a defacto standard, which is supported by most Common-Lisp
> implementations. However, even though you are right and UFFI will not be
> capable of, for instance, retreiving the pointer of a single-float
> array, typically the code that this adds is minimal and one can design a
> good interface on top of this. I think Matlisp does this.
> Incidentally, I had a look at your code and indeed an array operation is
> not being inlined and thus spoils all the performance gain from unboxing
> the real numbers. I will work into that.
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> Ecls-list mailing list
SDF Public Access UNIX System - http://sdf.lonestar.org