>>>>> "Goffioul" == Goffioul Michael writes:
>> o You've changed some of the regex's in cl-info.lisp to include \r.
>> Is that intended to support Windows? Will they break Unix? I
>> suspect not, but I haven't tested it.
Goffioul> Yes, it's to support Windows (I'm using ECL under Win32 with the MSVC
Goffioul> compiler). I don't think it would affect Unix because the \r is always
Goffioul> optional ( typically "\r?" or "[\r\n]+").
Ok. This seems reasonably safe.
>> o You've renamed a lot of variables like ".return" to just "return".
>> Shouldn't ECL be fixed so that ".return" is valid?
Goffioul> For reasons I couldn't still figure out, ECL fails to
Goffioul> expand macros whose arg names start with a dot. But this
Goffioul> only happen when compiling Maxima. The easy fix was
Goffioul> just to change the argument name.
Given the comment that it wants to be sure the arg is not a special
var, we need to be careful. Maxima has a zillion special variables
that don't use the * convention.
>> o In maxima-build.lisp, why do you need to say
>> :load-source-instead-of-binary t?
Goffioul> I modified the compilation system such that it compiles
Goffioul> Maxima into a single FAS file (in ECL context, it's a
Goffioul> shared library/DLL) instead of a myriad of single FAS
Goffioul> files. It loads much faster and is the ECL equivalent of
Ok. I was just wondering why that was different.
[snip]
>> o Modifying the slatec lisp files is not a good idea. I think that is
>> probably a bug in f2cl.
Goffioul> Indeed, I already had the problem when porting
Goffioul> MatLISP. However, when ECL compiles the file, it only
Goffioul> keeps the first type declaration for FUNJY, which makes
Goffioul> the generated C code wrong (type mismatch).
Ok. I think I've fixed f2cl so it doesn't do this anymore.
Definitely a bug in f2cl.
Ray