[Ecls-list] Using Femlisp with ECL / Bug reports

[Nicolas Neuss]

Juan Jose Garcia Ripoll <lisp at arrakis.es> writes:

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

Removing the build directory helped.  Seems to work fine now.  Thanks.

> the anonymous repository and it built and tested successfully. See
> Redhat 8.0 in http://ecls.sourceforge.net/status.html

Indeed, I was too fast checking out and have got the patch only now.  Do
you know how large this anonymous cvs delay is?

Now, I am stuck when performing "(asdf:operate 'asdf::load-op 'femlisp)",
which may indicate a bug in your ASDF port.  I get

The variable *COMPILE-PRINT* is unbound.
[Condition of type UNBOUND-VARIABLE]

Loading single files apparently works.  I will try to go through that.
One thing that showed up is the following LOOP construct:

(let ((list (list 1 2 3))
      (result ()))
   (loop for i = (pop list) while i
         for k = (* i i) do (push k result)
         finally (return result)))

Is this construct really non-ANSI?  It worked in Allegro, CMUCL, SBCL.

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

Hmm, I wanted to ask if Matlisp has been ported to ECL, but Michael has
already answered this.  Indeed, Femlisp once depended on Matlisp, but I
found that really inconvenient.  If Matlisp was more widely used and would
provide a more complete interface to BLAS/LAPACK/..., the situation would
probably be different.

> 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.
>
> Regards,
>
> Juanjo

Thanks again,
Nicolas.