[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: possible lisp reader enhancement/modification
|
From: |
Matt Kaufmann |
|
Subject: |
Re: [Gcl-devel] Re: possible lisp reader enhancement/modification |
|
Date: |
Fri, 18 Jul 2003 16:46:17 -0500 |
Hi --
Sorry I couldn't reply soon (I just returned from vacation).
I'm also really sorry to say that I can't provide the test example, since it's
derived directly from AMD design data and I think it would take considerable
effort to "sanitize" it, if that's even possible. But below are some details
from the run, and if someone cares to suggest some allocate settings then I'd
be happy to re-run. Anyhow, here's some info that may halp.
Here I'm focusing on one run from a suite of runs. The timing was as follows:
ACL2 built on GCL:
real 93m14.066s
user 92m47.830s
sys 0m16.260s
ACL2 built on Allegro CL dynamic runtime:
real 32m40.528s
user 32m21.530s
sys 0m10.140s
I built ACL2 by starting with modest allocations and causing growth to occur
slowly (details upon request). Here is the room available when I first
started up ACL2.
ACL2>(room)
2917/2917 82.0%CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
100/100 18.4% FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE READTABLE NIL
400/400 35.2% SYMBOL STREAM
1/2 37.2% PACKAGE
5/38 13.8% ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME CCLOSURE
FAT-STRING
200/200 46.4% STRING
400/400 1.8% CFUN BIGNUM
40/40 56.7% SFUN GFUN CFDATA SPICE NIL
1/100 contiguous (1 blocks)
1000 hole
500 0.1% relocatable
4063 pages for cells
5564 total pages
55769 pages available
4203 pages in heap but not gc'd + pages needed for gc marking
65536 maximum pages
ACL2>
At the end of the run, (room) gave the following.
ACL2>(room)
50251/51062 98.9%350CONS RATIO LONG-FLOAT COMPLEX STRUCTURE
245/225 62.6% 77 FIXNUM SHORT-FLOAT CHARACTER RANDOM-STATE READTABLE NIL
790/900 99.3% 2 SYMBOL STREAM
1/2 64.1% PACKAGE
29/38 3.2% ARRAY HASH-TABLE VECTOR BIT-VECTOR PATHNAME CCLOSURE
FAT-STRING
450/450 97.4%3916STRING
400/400 74.9% 9 CFUN BIGNUM
43/60 97.1% 1 SFUN GFUN CFDATA SPICE NIL
6414/6553 669 contiguous (17 blocks)
382 hole
750 68.2%669 relocatable
52209 pages for cells
59755 total pages
710 pages available
5071 pages in heap but not gc'd + pages needed for gc marking
65536 maximum pages
ACL2>
I particularly noticed a lot of string GCs, such as:
[SGC for 93 STRING pages..(11793 writable)..(T=14).GC finished]
Here are total counts of gc messages.
[SGC for ... CONS pages]: 350
[SGC for ... STRING pages]: 3916
[SGC for ... FIXNUM pages]: 77
[SGC for ... SYMBOL pages]: 2
[SGC for ... CFUN pages]: 9
[SGC for ... SFUN pages]: 1
[SGC for 0 CONTIGUOUS-BLOCKS pages]: 12
[SGC for 0 RELOCATABLE-BLOCKS pages]: 553
I can send you all 4920 lines of SGC messages if you like. I also got this
count:
[GC for ... RELOCATABLE-BLOCKS pages]: 116
-- Matt
cc: "Vadim V. Zhytnikov" <address@hidden>, address@hidden,
address@hidden, address@hidden, address@hidden
From: "Camm Maguire" <address@hidden>
Date: 14 Jul 2003 16:49:42 -0400
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
X-WSS-ID: 130DC8F213915609-01-01
Content-Type: text/plain;
charset=us-ascii
Greetings!
"Matt Kaufmann" <address@hidden> writes:
> Hi, Camm --
>
> OK, it worked! Thanks so much for doing this. I was surprised actually to
Great! No problem -- hope it is useful for others too.
> find that Allegro CL outperformed GCL in my test application, given that
I've
> done lots of other tests where they seem to perform comparably (in fact
GCL has
> had the edge).
>
> Allegro dynamic runtime:
> 4794.130u 26.690s 1:20:49.38 99.4% 0+0k 0+0io 78483pf+0w
>
> Allegro developer image
> 5349.650u 34.900s 1:30:36.18 99.0% 0+0k 0+0io 96292pf+0w
>
> GCL
> 12412.970u 42.110s 3:27:52.93 99.8% 0+0k 0+0io 89326pf+0w
>
> I wonder if there's a way to speed things up. We already do quite a bit of
> proclaiming so maybe the next thing to try would be to increase default
> allocations. In case it's relevant, this was an unusually large
application --
> we had to increase MAX_PAGES by a factor of two -- I think it was by
running
> configure with '--enable-maxpage=64*1024' -- in order to avoid running out
of
> space. I think that's the first time I've had to do that, at least in
recent
> years.
I would be shocked if a speed difference of this magnitude was not due
to excessive garbage collection calls. I would also be shocked if
once this issue is resolved, GCL performance does not return to its
slightly better than Allegro level.
>
> If you have any ideas for speeding up GCL, I'd be interested. But please
don't
> go through any trouble unless you're interested in exploring this further.
> I'll be away until Thursday night, anyhow.
>
I am certainly interested. I feel we should at least be able to match
Allegro if gcl is to be viable in any case. I'm cc'ing Vadim here, as
he has to my knowledge the most experience with performance/memory
allocation issues. What I would like the most is for you to post your
code, or at least an illustrative section, and for Vadim to analyze
the best way to handle the memory as he has with other endeavors in
the past. Is this possible? Without some code to see what's going
on, I don't know how we could help with the performance.
Vadim, in general I'd like some recommendations on how to make this
performance/memory issue more robust in GCL. I'd like to know the
following:
1) Is our GBC too slow?
2) Do we generate too much garbage?
3) Do our default allocations not scale properly with MAXPAGE
4) Do our allocations not scale quickly enough in a running session?
and
5) what is the ideal fix for this in GCL. If I know what how we want
it to behave, I might be able to make in behave that way.
Take care,
> >> In general, it would help me if you had a small
> >> testfile indicating the expected behavior, as there are a number of
> >> precedence assumptions in putting this together with which I am a bit
> >> unfamiliar.
>
> The following file tests some or all of the functionality that was an
issue for
> me, but I don't claim that it's complete. (In particular, I haven't much
used
> ":" instead of "::" except for the keyword package, so I haven't addressed
it.)
>
> ============================================================
>
> (in-package "USER")
>
> (setq xxx 17)
>
> (make-package "FOO" :use nil)
>
> (or (and (eql xxx 17)
> (equal (find-package "USER") (symbol-package 'ab)))
> (error "Error #1"))
>
> FOO::(user::setq yyy 3)
>
> (or (and (eql xxx 17)
> (equal (find-package "USER") (symbol-package 'ab)))
> (error "Error #2"))
>
> (or (and (eql foo::yyy 3)
> (equal (find-package "FOO") (symbol-package 'foo::yyy)))
> (error "Error #3"))
>
> (or (equal FOO:: (user::quote (a :b user:: c d user::
> e))
> '(foo::a :b
> c ; need user::c if not in "USER" package
> foo::d user::e))
> (error "Error #4"))
>
> ============================================================
>
> Thanks!
> -- Matt
> cc: address@hidden, address@hidden, address@hidden,
> address@hidden
> From: "Camm Maguire" <address@hidden>
> Date: 10 Jul 2003 21:24:12 -0400
> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> X-WSS-ID: 1310CE473643692-01-01
> Content-Type: text/plain;
> charset=us-ascii
>
> Hi Matt! Take six. In general, it would help me if you had a small
> testfile indicating the expected behavior, as there are a number of
> precedence assumptions in putting this together with which I am a bit
> unfamiliar. Apparently you want the keyword package implied in ':p to
> override the outside package as 'user::p would inside a list. This
> should accomplish that.
>
> Please let me know,
>
> Take care,
>
>
=============================================================================
> diff -u -r1.14 read.d
> --- read.d 26 Feb 2003 22:21:37 -0000 1.14
> +++ read.d 11 Jul 2003 01:19:14 -0000
> @@ -392,6 +392,11 @@
> Read_object(in) reads an object from stream in.
> This routine corresponds to COMMON Lisp function READ.
> */
> +
> +/* FIXME What should this be? Apparently no reliable way to use value
stack */
> +#define MAX_PACKAGE_STACK 1024
> +static object P0[MAX_PACKAGE_STACK],*PP0=P0,LP;
> +
> object
> read_object(in)
> object in;
> @@ -428,6 +433,19 @@
> });
> a = cat(c);
> } while (a == cat_whitespace);
> + if (c->ch.ch_code == '(') { /* Loose package extension */
> + LP=LP || PP0==P0 ? LP : PP0[-1]; /* push loose packages into
nested lists */
> + if (LP) {
> + if (PP0-P0>=MAX_PACKAGE_STACK)
> + FEerror("Too many nested package specifiers",0);
> + *PP0++=LP;
> + LP=NULL;
> + }
> + } else if (LP)
> + FEerror("Loose package prefix must be followed by a
list",0);
> + if (c->ch.ch_code==')' && PP0>P0) PP0--; /* regardless of error
behavior,
> + will pop stack to
beginning as parens
> + must match before
the reader starts */
> delimiting_char = vs_head;
> if (delimiting_char != OBJNULL && c == delimiting_char) {
> delimiting_char = OBJNULL;
> @@ -499,8 +517,15 @@
> token_buffer[(tok_leng++,length++)] =
char_code(c);
> }
> goto K;
> - } else if (a == cat_whitespace || a == cat_terminating)
> + } else if (a == cat_terminating) {
> break;
> + } else if (a == cat_whitespace) {
> + /* skip all whitespace after trailing colon */
> + if (colon+colon_type==length)
> + goto K;
> + else
> + break;
> + }
> else if ('a' <= char_code(c) && char_code(c) <= 'z')
> c = code_char(char_code(c) - ('a' - 'A'));
> else if (char_code(c) == ':') {
> @@ -587,6 +612,15 @@
> token->st.st_fillp = length - (colon + 2);
> } else
> p = current_package();
> + /* loose package is an empty token following a non-beginning
> + colon with no escape, to allow for ||*/
> + if (!token->st.st_fillp && colon && !escape_flag) {
> + LP=p;
> + goto BEGIN;
> + }
> + /* unless package specified for this symbol, use loose package
if present */
> + if (PP0>P0 && !colon_type)
> + p=PP0[-1];
> vs_push(p);
> x = intern(token, p);
> vs_push(x);
>
=============================================================================
>
> "Matt Kaufmann" <address@hidden> writes:
>
> > Thanks, Camm. Sorry about our mistake before. I ran my test again
and this
> > time I got the following problem (probably because I got past the
previous
> > failure point):
> >
> > >'user::(a :b)
> >
> > (A B)
> >
> > >
> >
> > I believe that we should have gotten (A :B).
> >
> > Thanks --
> > -- Matt
> > cc: address@hidden, address@hidden, address@hidden
> > From: "Camm Maguire" <address@hidden>
> > Date: 10 Jul 2003 18:31:27 -0400
> > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> > X-WSS-ID: 131336C53611643-01-01
> > Content-Type: text/plain;
> > charset=us-ascii
> >
> > Greetings! Here is the 'take five' I wrote about a while ago.
Only
> > difference here is that whitespace between trailing colons and
symbols
> > are also skipped over.
> >
> > Please test and report.
> >
> > Take care,
> >
=============================================================================
> > diff -u -r1.14 read.d
> > --- read.d 26 Feb 2003 22:21:37 -0000 1.14
> > +++ read.d 10 Jul 2003 22:28:16 -0000
> > @@ -392,6 +392,11 @@
> > Read_object(in) reads an object from stream in.
> > This routine corresponds to COMMON Lisp function READ.
> > */
> > +
> > +/* FIXME What should this be? Apparently no reliable way to use
value stack */
> > +#define MAX_PACKAGE_STACK 1024
> > +static object P0[MAX_PACKAGE_STACK],*PP0=P0,LP;
> > +
> > object
> > read_object(in)
> > object in;
> > @@ -428,6 +433,19 @@
> > });
> > a = cat(c);
> > } while (a == cat_whitespace);
> > + if (c->ch.ch_code == '(') { /* Loose package extension */
> > + LP=LP || PP0==P0 ? LP : PP0[-1]; /* push loose packages into
nested lists */
> > + if (LP) {
> > + if (PP0-P0>=MAX_PACKAGE_STACK)
> > + FEerror("Too many nested package specifiers",0);
> > + *PP0++=LP;
> > + LP=NULL;
> > + }
> > + } else if (LP)
> > + FEerror("Loose package prefix must be followed by a
list",0);
> > + if (c->ch.ch_code==')' && PP0>P0) PP0--; /* regardless of error
behavior,
> > + will pop stack to
beginning as parens
> > + must match before
the reader starts */
> > delimiting_char = vs_head;
> > if (delimiting_char != OBJNULL && c == delimiting_char) {
> > delimiting_char = OBJNULL;
> > @@ -499,8 +517,15 @@
> > token_buffer[(tok_leng++,length++)]
= char_code(c);
> > }
> > goto K;
> > - } else if (a == cat_whitespace || a == cat_terminating)
> > + } else if (a == cat_terminating) {
> > break;
> > + } else if (a == cat_whitespace) {
> > + /* skip all whitespace after trailing colon */
> > + if (colon+colon_type==length)
> > + goto K;
> > + else
> > + break;
> > + }
> > else if ('a' <= char_code(c) && char_code(c) <= 'z')
> > c = code_char(char_code(c) - ('a' - 'A'));
> > else if (char_code(c) == ':') {
> > @@ -587,6 +612,15 @@
> > token->st.st_fillp = length - (colon + 2);
> > } else
> > p = current_package();
> > + /* loose package is an empty token following a non-beginning
> > + colon with no escape, to allow for ||*/
> > + if (!token->st.st_fillp && colon && !escape_flag) {
> > + LP=p;
> > + goto BEGIN;
> > + }
> > + /* unless package specified for this symbol, use loose package
if present */
> > + if (PP0>P0 && !colon)
> > + p=PP0[-1];
> > vs_push(p);
> > x = intern(token, p);
> > vs_push(x);
> >
=============================================================================
> > >(setq xxx 17)
> >
> >
> > 17
> >
> > >(make-package "FOO" :use nil)
> >
> >
> > #<"FOO" package>
> >
> > >xxx
> >
> >
> > 17
> >
> > >FOO::(user::setq yyy 3)
> >
> >
> > 3
> >
> > >xxx
> >
> >
> > 17
> >
> > >'xxx
> >
> >
> > XXX
> >
> > >'lisp:: a
> >
> >
> > LISP::A
> >
> > >q
> >
> >
> > Error: The variable Q is unbound.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by EVAL.
> > Broken at EVAL. Type :H for Help.
> > >>'lisp::a
> >
> >
> > LISP::A
> > >>a
> >
> >
> > Error: The variable A is unbound.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by EVALHOOK.
> > Backtrace: system:universal-error-handler > EVALHOOK
> >
> > Broken at EVAL.
> > >>`a
> >
> >
> > A
> > >>'lisp::(a b user::c)
> >
> >
> > (LISP::A LISP::B C)
> > >>'lisp:: (a b user::c)
> >
> >
> > (LISP::A LISP::B C)
> > >>'lisp::
> >
> > (a b user::c)
> >
> >
> > (LISP::A LISP::B C)
> > >>(quote lisp::(a b user::c))
> >
> >
> > (LISP::A LISP::B C)
> > >>(quote lisp::
> >
> > (a b user::c))
> >
> >
> > (LISP::A LISP::B C)
> > >>(quote (q lisp::(a b si::c d) e))
> >
> >
> > (Q (LISP::A LISP::B SYSTEM::C LISP::D) E)
> > >>(quote (q lisp::(a b si::c . . d) e))
> >
> >
> > Error: Two dots appeared consecutively.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by SYSTEM:UNIVERSAL-ERROR-HANDLER.
> > Backtrace: system:universal-error-handler
> >
> > Broken at EVAL.
> > >>
> > Error: The variable LISP::D is unbound.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by EVALHOOK.
> > Backtrace: system:universal-error-handler > EVALHOOK
> >
> > Broken at EVAL.
> > >>
> > Error: The variable E is unbound.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by EVALHOOK.
> > Backtrace: system:universal-error-handler > EVALHOOK
> >
> > Broken at EVAL.
> > >>(quote (q lisp::(a b si::c . . d) e))
> >
> >
> > Error: Two dots appeared consecutively.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by SYSTEM:UNIVERSAL-ERROR-HANDLER.
> > Backtrace: system:universal-error-handler
> >
> > Broken at EVAL.
> > >>
> > Error: The variable LISP::D is unbound.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by EVALHOOK.
> > Backtrace: system:universal-error-handler > EVALHOOK
> >
> > Broken at EVAL.
> > >>
> > Error: The variable E is unbound.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by EVALHOOK.
> > Backtrace: system:universal-error-handler > EVALHOOK
> >
> > Broken at EVAL.
> > >>:q
> >
> >
> > Top level.
> > >(quote (q lisp::(a b si::c d) e))
> >
> >
> > (Q (LISP::A LISP::B SYSTEM::C LISP::D) E)
> >
> > >(quote (q lisp::(a b si::c . . d) e))
> >
> >
> > Error: Two dots appeared consecutively.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by READ.
> > Broken at READ. Type :H for Help.
> > >>
> > Error: The variable LISP::D is unbound.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by EVALHOOK.
> > Backtrace: system:universal-error-handler > EVALHOOK
> >
> > Broken at READ.
> > >>
> > Error: The variable E is unbound.
> > Fast links are on: do (si::use-fast-links nil) for debugging
> > Error signalled by EVALHOOK.
> > Backtrace: system:universal-error-handler > EVALHOOK
> >
> > Broken at READ.
> > >>:q
> >
> >
> > Top level.
> > >'(q lisp::(a b (c d) e) f)
> >
> >
> > (Q (LISP::A LISP::B (LISP::C LISP::D) LISP::E) F)
> >
> > >'(q lisp::(a b si::(c d) e) f)
> >
> >
> > (Q (LISP::A LISP::B (SYSTEM::C SYSTEM::D) LISP::E) F)
> >
> > >'(q lisp::(a b si::(c user::d) e) f)
> >
> >
> > (Q (LISP::A LISP::B (SYSTEM::C D) LISP::E) F)
> >
> > >'(q lisp::(a b si::(c foo::d) e) f)
> >
> >
> > (Q (LISP::A LISP::B (SYSTEM::C FOO::D) LISP::E) F)
> >
> > >(by)
> >
=============================================================================
> >
> >
> > "Matt Kaufmann" <address@hidden> writes:
> >
> > > Hi, Camm --
> > >
> > > Thanks for your "Take four". That helped, but there still
appears to be a
> > > problem: after a package prefix is read, we continue to read
into that package
> > > outside the scope of that prefix. Here is an example.
> > >
> > > GCL (GNU Common Lisp) (2.5.3) Thu Jul 10 09:07:22 CDT 2003
> > > Licensed under GNU Library General Public License
> > > Dedicated to the memory of W. Schelter
> > >
> > > Use (help) to get some basic information on how to use GCL.
> > >
> > > >(setq xxx 17)
> > >
> > > 17
> > >
> > > >(make-package "FOO" :use nil)
> > >
> > > #<"FOO" package>
> > >
> > > >xxx
> > >
> > > 17
> > >
> > > >FOO::(user::setq yyy 3)
> > >
> > > 3
> > >
> > > >xxx
> > >
> > > Error: The variable FOO::XXX is unbound.
> > > Fast links are on: do (si::use-fast-links nil) for debugging
> > > Error signalled by EVAL.
> > > Broken at EVAL. Type :H for Help.
> > > >>:q
> > >
> > > Top level.
> > > >'xxx
> > >
> > > FOO::XXX
> > >
> > > >
> > >
> > > -- Matt
> > > cc: address@hidden, address@hidden, address@hidden,
> > > "Paul F. Dietz" <address@hidden>
> > > From: "Camm Maguire" <address@hidden>
> > > Date: 09 Jul 2003 18:24:21 -0400
> > > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> > > X-WSS-ID: 131249A67698307-01-01
> > > Content-Type: text/plain;
> > > charset=us-ascii
> > >
> > > Hi Matt! OK, Take four. I can't imagine it would be a
problem to
> > > skip over whitespace in the case of our extension (package
designator
> > > before a left paren), so that's what I've included below. As
for
> > > skipping in the case of whitespace between a package
designator and a
> > > symbol, I'll refer this to Paul for comment.
> > >
> > >
=============================================================================
> > > --- read.d 26 Feb 2003 22:21:37 -0000 1.14
> > > +++ read.d 9 Jul 2003 22:19:55 -0000
> > > @@ -392,6 +392,11 @@
> > > Read_object(in) reads an object from stream in.
> > > This routine corresponds to COMMON Lisp function READ.
> > > */
> > > +
> > > +/* FIXME What should this be? Apparently no reliable way to
use value stack */
> > > +#define MAX_PACKAGE_STACK 100
> > > +static object P0[MAX_PACKAGE_STACK],*PP0=P0;
> > > +
> > > object
> > > read_object(in)
> > > object in;
> > > @@ -428,6 +433,7 @@
> > > });
> > > a = cat(c);
> > > } while (a == cat_whitespace);
> > > + if (c->ch.ch_code==')' && PP0>P0) PP0--;
> > > delimiting_char = vs_head;
> > > if (delimiting_char != OBJNULL && c == delimiting_char) {
> > > delimiting_char = OBJNULL;
> > > @@ -587,6 +593,35 @@
> > > token->st.st_fillp = length - (colon + 2);
> > > } else
> > > p = current_package();
> > > + /* FIXME Perhaps one of these is redundant */
> > > + if (!token->st.st_fillp && colon_type) {
> > > + int i=0;
> > > +
> > > + while (a == cat_whitespace) {
> > > + i=1;
> > > + read_char_to(c,in, {
> > > + if (df) {
> > > + vs_reset;
> > > + return(OBJNULL);
> > > + } else
> > > + end_of_stream(in);
> > > + });
> > > + a=cat(c);
> > > + }
> > > + if (i)
> > > + unread_char(c, in);
> > > +
> > > + if (c->ch.ch_code == '(') {
> > > + if (PP0-P0>=MAX_PACKAGE_STACK)
> > > + FEerror("Too many nested package specifiers",0);
> > > + *PP0++=p;
> > > + x=read_object(in);
> > > + vs_reset;
> > > + return (x);
> > > + }
> > > + }
> > > + if (PP0>P0 && !colon_type)
> > > + p=PP0[-1];
> > > vs_push(p);
> > > x = intern(token, p);
> > > vs_push(x);
> > >
=============================================================================
> > >
> > >
> > > Matt Kaufmann <address@hidden> writes:
> > >
> > > > Hi, Camm --
> > > >
> > > > Thank you very much. Sorry I didn't think to mention this
before, but for the
> > > > purpose I have in mind I'd like whitespace after the :: to
be ignored by the
> > > > reader, so for example the following would work.
> > > >
> > > > >'lisp:: a
> > > >
> > > > LISP::||
> > > >
> > > > >
> > > > Error: The variable LISP::A is unbound.
> > > > Fast links are on: do (si::use-fast-links nil) for
debugging
> > > > Error signalled by EVAL.
> > > > Broken at EVAL. Type :H for Help.
> > > > >>:q
> > > >
> > > > Top level.
> > > > >
> > > >
> > > > Here are some more examples (probably you can just ignore
them). I don't so
> > > > much need whitespace ignored before :: and a symbol, but
rather, between :: and
> > > > an open paren.
> > > >
> > > > >'lisp::(a b user::c)
> > > >
> > > > (LISP::A LISP::B C)
> > > >
> > > > >'lisp:: (a b user::c)
> > > >
> > > > LISP::||
> > > >
> > > > >
> > > > Error: The function LISP::A is undefined.
> > > > Fast links are on: do (si::use-fast-links nil) for
debugging
> > > > Error signalled by EVAL.
> > > > Broken at EVAL. Type :H for Help.
> > > > >>:q
> > > >
> > > > Top level.
> > > > >'lisp::
> > > > (a b user::c)
> > > >
> > > > LISP::||
> > > >
> > > > >
> > > > Error: The function LISP::A is undefined.
> > > > Fast links are on: do (si::use-fast-links nil) for
debugging
> > > > Error signalled by EVAL.
> > > > Broken at EVAL. Type :H for Help.
> > > > >>:q
> > > >
> > > > Top level.
> > > > >(quote lisp::(a b user::c))
> > > >
> > > > (LISP::A LISP::B C)
> > > >
> > > > >(quote lisp::
> > > > (a b user::c))
> > > >
> > > > Error: Too many arguments.
> > > > Fast links are on: do (si::use-fast-links nil) for
debugging
> > > > Error signalled by QUOTE.
> > > > Broken at QUOTE. Type :H for Help.
> > > > >>
> > > >
> > > > Is this an easy fix for you that you're willing to make?
> > > >
> > > > Thanks --
> > > > -- Matt
> > > > Cc: address@hidden, address@hidden
> > > > From: Camm Maguire <address@hidden>
> > > > Date: 09 Jul 2003 11:49:11 -0400
> > > > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> > > > Content-Type: text/plain; charset=us-ascii
> > > >
> > > > Greetings! OK, here is take three -- this should ensure
that the
> > > > stack is popped on input error somewhere in the list:
> > > >
> > > >
=============================================================================
> > > > diff -u -r1.14 read.d
> > > > --- read.d 26 Feb 2003 22:21:37 -0000 1.14
> > > > +++ read.d 9 Jul 2003 15:45:45 -0000
> > > > @@ -392,6 +392,11 @@
> > > > Read_object(in) reads an object from stream in.
> > > > This routine corresponds to COMMON Lisp function
READ.
> > > > */
> > > > +
> > > > +/* FIXME What should this be? Apparently no reliable
way to use value stack */
> > > > +#define MAX_PACKAGE_STACK 100
> > > > +static object P0[MAX_PACKAGE_STACK],*PP0=P0;
> > > > +
> > > > object
> > > > read_object(in)
> > > > object in;
> > > > @@ -428,6 +433,7 @@
> > > > });
> > > > a = cat(c);
> > > > } while (a == cat_whitespace);
> > > > + if (c->ch.ch_code==')' && PP0>P0) PP0--;
> > > > delimiting_char = vs_head;
> > > > if (delimiting_char != OBJNULL && c ==
delimiting_char) {
> > > > delimiting_char = OBJNULL;
> > > > @@ -587,6 +593,17 @@
> > > > token->st.st_fillp = length - (colon + 2);
> > > > } else
> > > > p = current_package();
> > > > + /* FIXME Perhaps one of these is redundant */
> > > > + if (c->ch.ch_code=='(' && !token->st.st_fillp
&& colon_type) {
> > > > + if (PP0-P0>=MAX_PACKAGE_STACK)
> > > > + FEerror("Too many nested package
specifiers",0);
> > > > + *PP0++=p;
> > > > + x=read_object(in);
> > > > + vs_reset;
> > > > + return (x);
> > > > + }
> > > > + if (PP0>P0 && !colon_type)
> > > > + p=PP0[-1];
> > > > vs_push(p);
> > > > x = intern(token, p);
> > > > vs_push(x);
> > > >
=============================================================================
> > > > (sid)address@hidden:/fix/t1/camm/gcl/unixport$
./saved_gcl
> > > > GCL (GNU Common Lisp) (2.5.3) Tue Jul 8 17:07:32 UTC
2003
> > > > Licensed under GNU Library General Public License
> > > > Dedicated to the memory of W. Schelter
> > > >
> > > > Use (help) to get some basic information on how to use
GCL.
> > > >
> > > > >(read)
> > > > (quote (q lisp::(a b si::c d) e))
> > > >
> > > > '(Q (LISP::A LISP::B SYSTEM::C LISP::D) E)
> > > >
> > > > >(read)
> > > > (quote (q lisp::(a b si::c . . d) e))
> > > >
> > > > Error: Two dots appeared consecutively.
> > > > Fast links are on: do (si::use-fast-links nil) for
debugging
> > > > Error signalled by READ.
> > > > Broken at READ. Type :H for Help.
> > > > >>
> > > > Error: The variable LISP::D is unbound.
> > > > Fast links are on: do (si::use-fast-links nil) for
debugging
> > > > Error signalled by EVALHOOK.
> > > > Backtrace: system:universal-error-handler > EVALHOOK
> > > >
> > > > Broken at READ.
> > > > >>
> > > > Error: The variable E is unbound.
> > > > Fast links are on: do (si::use-fast-links nil) for
debugging
> > > > Error signalled by EVALHOOK.
> > > > Backtrace: system:universal-error-handler > EVALHOOK
> > > >
> > > > Broken at READ.
> > > > >>(quote (q lisp::(a b si::c d) e))
> > > >
> > > > (Q (LISP::A LISP::B SYSTEM::C LISP::D) E)
> > > > >>:q
> > > >
> > > > Top level.
> > > > >(quote (q lisp::(a b si::c d) e))
> > > >
> > > > (Q (LISP::A LISP::B SYSTEM::C LISP::D) E)
> > > >
> > > > >(by)
> > > >
=============================================================================
> > > >
> > > > Take care,
> > > >
> > > > Matt Kaufmann <address@hidden> writes:
> > > >
> > > > > Thanks, Camm! Rob Sumners put your mods in and built
GCL with them. He looked
> > > > > at your code and described your approach, so I tried
an example with nested
> > > > > package prefixes. Unfortunately, it didn't do what I
expected, which is to use
> > > > > the closest package prefix:
> > > > >
> > > > > GCL:
> > > > >
> > > > > >'lisp::(a b user::c)
> > > > >
> > > > > (LISP::A LISP::B LISP::C)
> > > > >
> > > > > >
> > > > >
> > > > > Allegro CL:
> > > > >
> > > > > CL-USER(1): 'lisp::(a b user::c)
> > > > > (COMMON-LISP::A COMMON-LISP::B C)
> > > > > CL-USER(2):
> > > > >
> > > > > Maybe an easy fix for you?
> > > > >
> > > > > Thanks --
> > > > > -- Matt
> > > > > cc: address@hidden
> > > > > From: Camm Maguire <address@hidden>
> > > > > Date: 08 Jul 2003 12:52:30 -0400
> > > > > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> > > > > Content-Type: text/plain; charset=us-ascii
> > > > >
> > > > > Greetings! Given Paul's analysis, let's put in
this feature. You
> > > > > might want to try this patch:
> > > > >
> > > > > diff -u -r1.14 read.d
> > > > > --- read.d 26 Feb 2003 22:21:37 -0000 1.14
> > > > > +++ read.d 8 Jul 2003 16:47:32 -0000
> > > > > @@ -392,6 +392,9 @@
> > > > > Read_object(in) reads an object from stream
in.
> > > > > This routine corresponds to COMMON Lisp
function READ.
> > > > > */
> > > > > +
> > > > > +static object p0=Cnil;
> > > > > +
> > > > > object
> > > > > read_object(in)
> > > > > object in;
> > > > > @@ -587,6 +590,15 @@
> > > > > token->st.st_fillp = length - (colon
+ 2);
> > > > > } else
> > > > > p = current_package();
> > > > > + if (c->ch.ch_code=='(' && !token->st.st_fillp
&& colon_type) {
> > > > > + p0=p;
> > > > > + x=read_object(in);
> > > > > + p0=Cnil;
> > > > > + vs_reset;
> > > > > + return (x);
> > > > > + }
> > > > > + if (p0!=Cnil)
> > > > > + p=p0;
> > > > > vs_push(p);
> > > > > x = intern(token, p);
> > > > > vs_push(x);
> > > > >
> > > > >
> > > > >
=============================================================================
> > > > > (sid)address@hidden:/fix/t1/camm/gcl/unixport$
./saved_gcl
> > > > > GCL (GNU Common Lisp) (2.5.3) Tue Jul 8 15:22:09
UTC 2003
> > > > > Licensed under GNU Library General Public License
> > > > > Dedicated to the memory of W. Schelter
> > > > >
> > > > > Use (help) to get some basic information on how to
use GCL.
> > > > >
> > > > > >(quote lisp::(a b c))
> > > > >
> > > > > (LISP::A LISP::B LISP::C)
> > > > >
> > > > > >(quote (a b c))
> > > > >
> > > > > (A B C)
> > > > >
> > > > > >(by)
> > > > >
=============================================================================
> > > > >
> > > > > I'll test this and commit to the unstable branch if
all is well.
> > > > > Comments welcome, as always.
> > > > >
> > > > > Take care,
> > > > >
> > > > > Matt Kaufmann <address@hidden> writes:
> > > > >
> > > > > > Thanks for the quick reply!
> > > > > >
> > > > > > -- Matt
> > > > > > cc: address@hidden, "Paul F. Dietz"
<address@hidden>
> > > > > > From: Camm Maguire <address@hidden>
> > > > > > Date: 02 Jul 2003 15:42:16 -0400
> > > > > > User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
> > > > > > Content-Type: text/plain; charset=us-ascii
> > > > > >
> > > > > > Greetings, and thanks for your suggestion!
> > > > > >
> > > > > > I'm forwarding this to the list to solicit
opinions from our ANSI
> > > > > > standard experts on whether such a change
would be permissible in ANSI
> > > > > > common lisp. Comments?
> > > > > >
> > > > > > Take care,
> > > > > >
> > > > > > Matt Kaufmann <address@hidden> writes:
> > > > > >
> > > > > > > Hi --
> > > > > > >
> > > > > > > I wonder if it would be possible to modify
the GCL reader so that package
> > > > > > > prefixes can apply to lists, not just
symbols. Here's an example of what I
> > > > > > > mean.
> > > > > > >
> > > > > > > >'lisp::(a b)
> > > > > > >
> > > > > > > LISP::||
> > > > > > >
> > > > > > > >
> > > > > > > Error: The function A is undefined.
> > > > > > > Fast links are on: do (si::use-fast-links
nil) for debugging
> > > > > > > Error signalled by EVAL.
> > > > > > > Broken at EVAL. Type :H for Help.
> > > > > > > >>
> > > > > > >
> > > > > > > Here is the corresponding log for Allegro
Common Lisp.
> > > > > > >
> > > > > > > CL-USER(2): 'lisp::(a b)
> > > > > > > (COMMON-LISP::A COMMON-LISP::B)
> > > > > > > CL-USER(3):
> > > > > > >
> > > > > > > I'm pretty sure that there's no CLtL
requirement to make such a change. It's
> > > > > > > even possible that GCL does this right and
Allegro CL does it wrong. But
> > > > > > > anyhow, I thought I'd ask, because it would
be very handy to have such a
> > > > > > > capability in GCL (it could affect which
Lisp is used under ACL2 at AMD).
> > > > > > >
> > > > > > > Thanks --
> > > > > > > -- Matt
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > --
> > > > > > Camm Maguire
address@hidden
> > > > > >
==========================================================================
> > > > > > "The earth is but one country, and mankind its
citizens." -- Baha'u'llah
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Camm Maguire
address@hidden
> > > > >
==========================================================================
> > > > > "The earth is but one country, and mankind its
citizens." -- Baha'u'llah
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Gcl-devel mailing list
> > > > > address@hidden
> > > > > http://mail.gnu.org/mailman/listinfo/gcl-devel
> > > > >
> > > > >
> > > > >
> > > >
> > > > --
> > > > Camm Maguire
address@hidden
> > > >
==========================================================================
> > > > "The earth is but one country, and mankind its
citizens." -- Baha'u'llah
> > > >
> > > >
> > > >
> > >
> > > --
> > > Camm Maguire
address@hidden
> > >
==========================================================================
> > > "The earth is but one country, and mankind its citizens." --
Baha'u'llah
> > >
> > >
> > >
> >
> > --
> > Camm Maguire
address@hidden
> >
==========================================================================
> > "The earth is but one country, and mankind its citizens." --
Baha'u'llah
> >
> >
> >
> >
>
> --
> Camm Maguire address@hidden
>
==========================================================================
> "The earth is but one country, and mankind its citizens." --
Baha'u'llah
>
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- Re: Segfault in change-class (was Re: [Gcl-devel] defgeneric method fix), (continued)
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Matt Kaufmann, 2003/07/10
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/10
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/10
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Matt Kaufmann, 2003/07/10
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/10
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Matt Kaufmann, 2003/07/11
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/14
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification,
Matt Kaufmann <=
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Vadim V. Zhytnikov, 2003/07/19
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Matt Kaufmann, 2003/07/19
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Vadim V. Zhytnikov, 2003/07/20
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/20
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Matt Kaufmann, 2003/07/21
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification, Camm Maguire, 2003/07/28
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification ?JUNK MAIL? 4, Matt Kaufmann, 2003/07/28
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification ?JUNK MAIL? 4, Camm Maguire, 2003/07/28
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification ?JUNK MAIL? 4, Matt Kaufmann, 2003/07/29
- Re: [Gcl-devel] Re: possible lisp reader enhancement/modification ?JUNK MAIL? 4, Camm Maguire, 2003/07/30