Hi
Last night I got a CVS update of CLOCC, and then tried to build the
'clocc-top' target per the INSTALL file. Using CMUCL 18e on FreeBSD 4.8, I
got a huge core dump, 1.2 gigabytes long.
It happens when compiling the clocc.lisp file. Doesn't matter if I use the
Makefile, or if I go try to compile "by hand", using the Lisp Only
instructions in the INSTALL file.
Anybody else seen this problem?
"Jorge" <······@nomail.org> writes:
> Hi
> Last night I got a CVS update of CLOCC, and then tried to build the
> 'clocc-top' target per the INSTALL file. Using CMUCL 18e on FreeBSD 4.8, I
> got a huge core dump, 1.2 gigabytes long.
>
> It happens when compiling the clocc.lisp file. Doesn't matter if I use the
> Makefile, or if I go try to compile "by hand", using the Lisp Only
> instructions in the INSTALL file.
> Anybody else seen this problem?
Yes. You have to modify clocc.lisp very slightly (why this isn't in
CVS yet, I don't know). Right before the line
(define-setf-expander values (&rest places &environment env)
modify
#-(or allegro clisp mcl)
to
#-(or allegro clisp mcl cmu)
that should do it.
Cheers,
rif
rif wrote:
> Yes. You have to modify clocc.lisp very slightly (why this isn't in
> CVS yet, I don't know). Right before the line
>
> (define-setf-expander values (&rest places &environment env)
It should be pointed out that this form in CLOCC is not ANSI
compliant. CMUCL is allowed to do whatever it wants on it.
(See section 11.1.2.1.2 of the CLHS.)
Paul
> * In message <······················@dls.net>
> * On the subject of "Re: CLOCC vs. CMUCL 18e"
> * Sent on Thu, 01 May 2003 18:16:32 -0500
> * Honorable "Paul F. Dietz" <·····@dls.net> writes:
>
> rif wrote:
>
> > Yes. You have to modify clocc.lisp very slightly (why this isn't in
> > CVS yet, I don't know). Right before the line
> > (define-setf-expander values (&rest places &environment env)
>
> It should be pointed out that this form in CLOCC is not ANSI
> compliant. CMUCL is allowed to do whatever it wants on it.
>
> (See section 11.1.2.1.2 of the CLHS.)
It should be pointed out that this file in CLOCC is marked "bugfixes"
and it fixes some deficiencies in some implementations.
Specifically, CMUCL did not offer (SETF VALUES) until recently,
so this form fixed that.
--
Sam Steingold (http://www.podval.org/~sds) running RedHat9 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Bill Gates is great, as long as `bill' is a verb.
>>>>> "Sam" == Sam Steingold <···@gnu.org> writes:
Sam> It should be pointed out that this file in CLOCC is marked "bugfixes"
Sam> and it fixes some deficiencies in some implementations.
Sam> Specifically, CMUCL did not offer (SETF VALUES) until recently,
Sam> so this form fixed that.
Hmm, my copy of 18b (released Jul 1998) seems to have at least some
form of it. Perhaps it was deficient in some way.
Ray
rif <···@mit.edu> wrote in message news:<···············@five-percent-nation.mit.edu>...
> "Jorge" <······@nomail.org> writes:
>
> > Hi
> > Last night I got a CVS update of CLOCC, and then tried to build the
> > 'clocc-top' target per the INSTALL file. Using CMUCL 18e on FreeBSD 4.8, I
> > got a huge core dump, 1.2 gigabytes long.
> >
> > It happens when compiling the clocc.lisp file. Doesn't matter if I use the
> > Makefile, or if I go try to compile "by hand", using the Lisp Only
> > instructions in the INSTALL file.
> > Anybody else seen this problem?
>
> Yes. You have to modify clocc.lisp very slightly (why this isn't in
> CVS yet, I don't know). Right before the line
>
> (define-setf-expander values (&rest places &environment env)
>
> modify
>
> #-(or allegro clisp mcl)
>
> to
>
> #-(or allegro clisp mcl cmu)
The version of clocc (colcc-05-08-03.tgz) which I got today seems to
be corrected. Nevertheless I'm not able to compile clocc with cmucl
18e, because the compiler is terminating at a memory usage of appox.
230MB.
The same version of clocc can be compiled with 18d without this
enormous memory consumption.
>
> that should do it.
>
> Cheers,
>
> rif
······@topinform.com (Andreas Holz) writes:
> rif <···@mit.edu> wrote in message news:<···············@five-percent-nation.mit.edu>...
>> Yes. You have to modify clocc.lisp very slightly (why this isn't in
>> CVS yet, I don't know). Right before the line
>>
>> (define-setf-expander values (&rest places &environment env)
>>
>> modify
>>
>> #-(or allegro clisp mcl)
>>
>> to
>>
>> #-(or allegro clisp mcl cmu)
>
> The version of clocc (colcc-05-08-03.tgz) which I got today seems to
> be corrected. Nevertheless I'm not able to compile clocc with cmucl
> 18e, because the compiler is terminating at a memory usage of appox.
> 230MB.
>
> The same version of clocc can be compiled with 18d without this
> enormous memory consumption.
There's a bug in the bugfix (not rif's which is correct, but what is
there, which is wrong). CMUCL doesn not have :cmucl on *FEATURES*; it
does, however, have :cmu.
If you modify the modified
#-(or allegro clisp cmucl mcl)
to
#-(or allegro clisp cmu mcl)
then it probably stands a chance of working.
Incidentally, while we're on the subject (in case anyone who deals
with clocc is listening) -- would it not be much better to do:
(eval-when (:compile-toplevel :execute)
(let (x y)
(handler-case
(setf (values x y) (values 1 2))
(error () (pushnew :broken-setf-values *features*)))))
#+broken-setf-values
(define-setf-expander values ...)
because then portability in _time_ becomes much more possible.
Cheers,
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> wrote in message news:<··············@lambda.jcn.srcf.net>...
> ······@topinform.com (Andreas Holz) writes:
>
> > rif <···@mit.edu> wrote in message news:<···············@five-percent-nation.mit.edu>...
> >> Yes. You have to modify clocc.lisp very slightly (why this isn't in
> >> CVS yet, I don't know). Right before the line
> >>
> >> (define-setf-expander values (&rest places &environment env)
> >>
> >> modify
> >>
> >> #-(or allegro clisp mcl)
> >>
> >> to
> >>
> >> #-(or allegro clisp mcl cmu)
Okay, I was now able to compile clocc-top and dumping the
clocc-top.core image.
But if I'm going to compile src/port using "make system" in the
directory src/port I'm getting the f�llowing error:
/home/asholz/lisp/clocc/clocc/bin/run-lisp -I
/home/asholz/lisp/clocc/clocc/clocc-top -i port.system \
-x '(funcall (intern "COMPILE-SYSTEM" :mk) "port")'
; Loading #p"/home/asholz/lisp/clocc/clocc/src/port/port.system".
make: *** [system] Error 1
Andreas
> >
> > The version of clocc (colcc-05-08-03.tgz) which I got today seems to
> > be corrected. Nevertheless I'm not able to compile clocc with cmucl
> > 18e, because the compiler is terminating at a memory usage of appox.
> > 230MB.
> >
> > The same version of clocc can be compiled with 18d without this
> > enormous memory consumption.
>
> There's a bug in the bugfix (not rif's which is correct, but what is
> there, which is wrong). CMUCL doesn not have :cmucl on *FEATURES*; it
> does, however, have :cmu.
>
> If you modify the modified
> #-(or allegro clisp cmucl mcl)
> to
> #-(or allegro clisp cmu mcl)
> then it probably stands a chance of working.
>
> Incidentally, while we're on the subject (in case anyone who deals
> with clocc is listening) -- would it not be much better to do:
>
> (eval-when (:compile-toplevel :execute)
> (let (x y)
> (handler-case
> (setf (values x y) (values 1 2))
> (error () (pushnew :broken-setf-values *features*)))))
> #+broken-setf-values
> (define-setf-expander values ...)
>
> because then portability in _time_ becomes much more possible.
>
> Cheers,
>
> Christophe
>>>>> "ah" == Andreas Holz <······@topinform.com> writes:
ah> The version of clocc (colcc-05-08-03.tgz) which I got today seems to
ah> be corrected. Nevertheless I'm not able to compile clocc with cmucl
ah> 18e, because the compiler is terminating at a memory usage of appox.
ah> 230MB.
it's been modified, but not corrected. CMUCL doesn't have a :cmucl
*feature* ; it does have :cmu. That setf-expander for VALUES is
invalid according to the CL specification; I suggest you remove it
completely.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>