[Ecls-list] ANN: ECL 9.6.0

[Gabriel Barta]

On Fri, Jun 12, 2009 at 11:15 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> ECL 9.6:
> ========
> Support for Solaris/Intel has been added. The windows ports are right
> now broken. Please stay with 9.4.0 if support for those platforms is
> needed, until we fix the problems. Remaining ports, such as OSX,
> Linux, *BSD are working fine.

Just as a tiny bit of assistance in getting the windows ports working,
I have attached a patch.  I don't think it can be commited as-is, but
maybe it can be used as a guide to the problem areas.

It boils down to:
1) Msvc doesn't have signbit or unistd.h.  I think Solaris and OpenBSD
also don't have signbit, but I don't have access to those platforms.

2) Enabling ECL_IEEE_FP.  It doesn't work without this, as during the
boot it creates inf and nan objects by dividing by 0.0, and without
ECL_IEEE_FP this throws an exception which terminates the boot
process.  I guess it needs to work without ECL_IEEE_FP, but I would
like ieee behaviour, so I didn't look into this any further.

3) The new C stack size is too big for msvc. It seems the old
word-based stack size was 1MB.  It temporarily got reduced to 256 KB
with the move to byte-based stack sizes, but then your latest patch to
main.d increased it to 4MB.  This is too much for msvc and ecl threw
an exception during boot when setting the stack, so I changed it back
to 1MB.  Maybe a non-default stack size can be specified for msvc
builds instead?

4) For the new file and position info for c-compiled code, this would
not compile with msvc.  Specifically cmp/cmpdefs.c would not compile
because it did not want to allow Ct as an initializer in the
compiler_cfuns tables.  This happened because this file was the first
(I assume of many) that was compiled with the definition of ECL_API
that uses the dllimport declspec.  Msvc doesn't seem to want to treat
a dllimport symbol as constant for use in a structure initializer.  I
made it use Cnil instead and that worked.  I don't know what impact
this will have on the actual functionality of using the file and
position information, as I haven't had a chance to work out how to use
those features.  I assume this change is quite wrong.

With this patch, my previous patch 2796465 in the patch tracker, and a
reversion of http://ecls.cvs.sourceforge.net/viewvc/ecls/ecl/src/clos/standard.lsp?r1=1.50&r2=1.51
I am able to build and run this release when compiled on Visual Studio
2008. I still have no clue why that clos change causes an error.

I hope this helps a bit, and thanks all the work you put into ECL.
Gabriel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: msvc_ecl9.6.1.diff
Type: application/octet-stream
Size: 2343 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20090613/37fc13db/attachment.obj>