gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Gcl-devel] ANSI on Windows build failure.


From: Mike Thomas
Subject: RE: [Gcl-devel] ANSI on Windows build failure.
Date: Tue, 30 Sep 2003 14:57:30 +1000

Hi Camm.

| 1)  I proclaimed safety to 3 and speed to 0, then saved the trad image
|     before compiling pcl.  Subsequent build of pcl went fine, but I'm
|     thinking now that I must have left optimizations on somehow.

I did it per the patch at the end of this message in the pcl source files:


| If my guess is right (i.e. that we can currently only
|     compile pcl with optimization), this situation should obviously not
|     persist, but the short end is that I'd expect a function not
|     defined error to be probable.  I've not yet reproduced it myself.
|     Will try to look at this some more.

Thanks.

| 2) These are due to GCL's moving 'package-operations' to the top of
|    the init file.  We should really rework this, but it is likely not
|    simple, as it would require toggling between reading interpreted
|    init code and compiled function initialization code in the same
|    initialization sequence for a given file.  Right now GCL moves such
|    non-compiled top-level package forms to the effective top of the
|    file, and stores them in the .data file.  Compiled functions only
|    are in the .o file.  The init process therefore has only two places
|    with which to distinguish and order init code -- we'd have to come
|    up with some way of interspersing the .data and .o to preserve the
|    strict meaning of any non-trivial top-level sequence.   I get
|    exactly the same warnings as you do.  These warnings are often more
|    alarming than necessary, as any package-op form which does not
|    depend on code above it in a source file can be safely moved to the
|    top, yet GCL currently complains for all such cases without
|    distinguishing safe from non-safe moves.  Maybe there is a nice
|    algorithm for this?  But again, the short end is that these exports
|    (I think) work just fine when moved to the top despite the warning,
|    and alas probably do not shed light on your situation.

I tried replacing:

<   (setq *non-package-operation* t)

with

>    (let ((npo-old *non-package-operation*))
>      (setq *non-package-operation* t)

and restoring at the end of the let body throughout gcl_cmptop.lsp but
clearly this was a naive approach as I didn't realise that the output was
being reordered - it certainly got rid of the warnings, but unfortunately
not the failed export!!

| 3) There are quite a few pending ansi fixes which need to go in the
|    pcl code, and this is also the most difficult section to debug and
|    modify, IMHO.  Luckily, cmucl uses pcl too.  I thought at one point
|    that pcl was a finished product and that we'd just as soon work
|    with Dr. Schelter's last copy as any, but to the contrary, I
|    believe now that Paul's tests have sparked quite a bit of
|    successful work on pcl in the cmucl camp.  I can see absolutely no
|    reason for us to maintain any separate pcl tree apart from the
|    pcl_gcl_low.lisp file -- therefore I think a very fruitful exercise
|    is to attempt to load the cmucl pcl tree into gcl on an interpreted
|    basis at first, and then compile, and then replace what we have
|    with that.

Can you please briefly explain why you want to do this (I'm not objecting, I
just don't comprehend what this would do to help us).  I loaded PCL as
originally found in the Schelter tarballs using interpreted GCL a long time
ago, but can't remember what happened other than the fact that I succeeded
in doing the build.  It certainly wasn't good enough to compile CL-PDF which
was what I really wanted to do.

|  cmucl's public domain license is perfectly compatible
|    with out lgpl.  If anyone would like to help with this, one can
|    look at the init sequence in sys_pcl_gcl.c in unixport, and replace
|    the pcl binary object init calls with lsp_init source calls, as in
|    sys_pre_gcl.c.  One hopefully can then obtain an interpreted-only
|    pcl image and go from there.  I will also be attempting this in the
|    days to come.

I agree that if we can get a leg up from CMUCL then that is a good idea.

It's interesting that Roger Corman choose to use Closette as a starting
point for CCL on Windows rather than PCL despite Closette's limitations.

Cheers

Mike Thomas.


=========== PCL SPEED-SAFETY PATCH ==============================

Index: pcl/defsys.lisp
===================================================================
RCS file: /cvsroot/gcl/gcl/pcl/defsys.lisp,v
retrieving revision 1.3
diff -r1.3 defsys.lisp
93c93
<   '(optimize (speed 3) (safety #+kcl 0 #-kcl 1) (space 0)
---
>   '(optimize (speed 1) (safety 3) (space 0)
Index: pcl/pcl_fin.lisp
===================================================================
RCS file: /cvsroot/gcl/gcl/pcl/pcl_fin.lisp,v
retrieving revision 1.1
diff -r1.1 pcl_fin.lisp
161c161
<   (declare (optimize (speed 3) (safety 0)))
---
>   (declare (optimize (speed 1) (safety 3)))
360c360
<   (declare (optimize (speed 3) (safety 0)))
---
>   (declare (optimize (speed 1) (safety 3)))
884c884
<   (declare (optimize (speed 3) (safety 0)))
---
>   (declare (optimize (speed 1) (safety 3)))
1075c1075
<   (declare (optimize (speed 3) (safety 0)))
---
>   (declare (optimize (speed 1) (safety 3)))
Index: pcl/pcl_low.lisp
===================================================================
RCS file: /cvsroot/gcl/gcl/pcl/pcl_low.lisp,v
retrieving revision 1.1
diff -r1.1 pcl_low.lisp
68c68
< (defvar *optimize-speed* '(optimize (speed 3) (safety 0)))
---
> (defvar *optimize-speed* '(optimize (speed 1) (safety 3)))







reply via email to

[Prev in Thread] Current Thread [Next in Thread]