login  home  contents  what's new  discussion  bug reports     help  links  subscribe  changes  refresh  edit
IssueTracker
#48 #define unlikely defined in linux/compiler.h  ← ↑ →  #5 )edit command ignores file name

#49 GCL argument list too long
  
last edited 16 years ago

Edit detail for #49 GCL argument list too long revision 1 of 1
1
Editor:
Time: 2007/11/17 22:58:06 GMT-8
Note: property change 
changed:
-
root <address@bogus.example.com> writes:

> From: root <address@bogus.example.com>
> Subject: address@bogus.example.com: [Axiom-developer] Problem with patch 23 and Solaris 
> 9 identified]
> To: address@bogus.example.com, "Kostas Oikonomou" <address@bogus.example.com>
> Cc: address@bogus.example.com, address@bogus.example.com
> Date: Sat, 8 Jan 2005 12:49:44 -0500
> Reply-to: address@bogus.example.com
> 
> Camm,
> 
> Kostas has found a problem on the solaris 9 platform. The argument list
> given has 154 items.
> 

Yes, and I believe the reason is that his build loaded the
...NAG..chapter function interpreted, as opposed to compiled
(i.e. util.lisp not util.o) as I noted in a earlier post.
Fortunately, GCL's inliner expanded the apply therein and place all
args on the lisp value stack (as opposed to the limited C stack), thus
circumventing the argument limitation.  I've also posted two versions
which avert the problem at the lisp source level, which is preferable,
as the inliner depends on compilation safety options, etc.  Please let
me know if those functions don't fix the problem.  I still don't know
why Kostas' build loaded util.lisp interpreted.

> There used to be a similar problem in AKCL. Do you know what the
> current arg limits are and whether they can be changed?
> 

63, and yes.  In fact, it can be made to be unlimited via libffi (if
memory serves).  We discussed this before, and it was deemed of lower
priority.  Please let me know if we now feel otherwise.  Expanding the
existing code further, which has a huge switch/case branch on the
argument number, would not seem advisable, though of course could be
done.  We could even generate the switch at configure time and put in
another configure options, but there are already too many of these
IMHO.

> Kostas,
> 
> 
> Try loading the function interpreted. There are two possible ways to
> do this. Either start the image and load the file "util.lisp" (rather
> than "util.o"). Or move the function into the file "nocompil.lisp"
> which contains functions which are never compiled. 
> 

In this case, I believe, the advise should go the other way around.
compiling the function and load it would/should be an immediate
workaround, though this is just fortuitous in this case.

> As I recall, the interpreter can handle very long argument lists but
> the compiler cannot.
> 

Calling apply from the interpreter will be limited, and calling any C
function with more that 63 args will trigger this error too.  As we
see here, this can come from either the interpreter or compiler
depending on the inlining performed.  The best solution is to avoid
the situation at the lisp level, which should be straightforward.
Even that JoinInner in nocompil.lisp could be written to take a single
list as an arg, I think, but we shouldn't fool with this at the
present.

Take care,

> Tim
> 
> 
> - ------- Start of forwarded message -------
> X-Original-To: address@bogus.example.com
> Received-SPF: pass (spamd.bsdwebsolutions.com: domain of nongnu.org 
> designates 199.232.76.165 as permitted sender) client-ip=199.232.76.165; 
> address@bogus.example.com; helo=lists.gnu.org;
> To: "Axiom developers" <address@bogus.example.com>
> Date: Sat, 08 Jan 2005 11:20:05 -0500
> From: "Kostas Oikonomou" <address@bogus.example.com>
> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
> User-Agent: Opera M2/7.54 (SunOS, build 751)
> Subject: [Axiom-developer] Problem with patch 23 and Solaris 9 identified
> X-BeenThere: address@bogus.example.com
> X-Mailman-Version: 2.1.5
> Precedence: list
> List-Id: Axiom Developers <axiom-developer.nongnu.org>
> List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/axiom-developer>, 
>       <address@bogus.example.com">mailto:address@bogus.example.com>
> List-Archive: <http://lists.gnu.org/pipermail/axiom-developer>
> List-Post: <address@bogus.example.com">mailto:address@bogus.example.com>
> List-Help: <address@bogus.example.com">mailto:address@bogus.example.com>
> List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/axiom-developer>,
>       <address@bogus.example.com">mailto:address@bogus.example.com>
> Sender: address@bogus.example.com
> X-BSD-MailFrom: address@bogus.example.com
> X-BSD-RcptTo: address@bogus.example.com
> X-MIME-Character-set: iso-8859-1
> X-BSD-AntiVirus: No Virus Found
> X-BSD-MIME-Status: Safe
> X-BSD-Spam-Info: Spam detection software, provided by BSD WebSolutions, Inc.
> X-BSD-Spam-Info: Has scanned this message. If this is believed to be spam
> X-BSD-Spam-Info: A tag has been added to the subject for you own filtering 
> purposes.
> X-BSD-Spam-Info: Please call us at: (845) 485.4818 if you have any questions.
> X-BSD-Spam-Score: 0.5 (/)
> X-BSD-Spam-Report: The following tests were performed:
>       0.6 J_CHICKENPOX_34        BODY: 3alpha-pock-4alpha
>       -0.1 AWL                    AWL: From: address is in the auto white-list
> X-MIME-Autoconverted: from quoted-printable to 8bit by localhost.localdomain 
> id j08HS5x02181
> 
> 
> I just discovered that the problem I reported a few days ago is caused by
> the function "get-NAG-chapter" in "util.lisp".
> 
> Here is a test file "bug.lisp":
> 
> ==========================================================================
> (setq ch "c02")
> (setq fl
>   '("LOADNAG" "|c02aff|" "|c02agf|" "|c05adf|" "|c05nbf|" "|c05pbf|" 
> "|c06eaf|" "|c06ebf|" "|c06ecf|" "|c06ekf|" "|c06fpf|" "|c06fqf|" "|c06frf|" 
> "|c06fuf|" "|c06gbf|" "|c06gcf|" "|c06gqf|" "|c06gsf|" "|d01ajf|" "|d01akf|" 
> "|d01alf|" "|d01amf|" "|d01anf|" "|d01apf|" "|d01aqf|" "|d01asf|" "|d01bbf|" 
> "|d01fcf|" "|d01gaf|" "|d01gbf|" "|d02bbf|" "|d02bhf|" "|d02cjf|" "|d02ejf|" 
> "|d02gaf|" "|d02gbf|" "|d02kef|" "|d02raf|" "|d03edf|" "|d03eef|" "|d03faf|" 
> "|e01baf|" "|e01bef|" "|e01bff|" "|e01bgf|" "|e01bhf|" "|e01daf|" "|e01saf|" 
> "|e01sbf|" "|e01sef|" "|e02adf|" "|e02aef|" "|e02agf|" "|e02ahf|" "|e02ajf|" 
> "|e02akf|" "|e02baf|" "|e02bbf|" "|e02bcf|" "|e02bdf|" "|e02bef|" "|e02daf|" 
> "|e02dcf|" "|e02ddf|" "|e02def|" "|e02dff|" "|e02gaf|" "|e02zaf|" "|e04dgf|" 
> "|e04fdf|" "|e04gcf|" "|e04jaf|" "|e04mbf|" "|e04naf|" "|e04ucf|" "|e04ycf|" 
> "|f01brf|" "|f01bsf|" "|f01maf|" "|f01mcf|" "|f01qcf|" "|f01qdf|" "|f01qef|" 
> "|f01rcf|" "|f01rdf|" "|f01ref|" "|f02aaf|" "|f02abf|" "|f02adf|" "|f02ae!
> f|"  
> "|f02aff|" "|f02agf|" "|f02ajf|" "|f02akf|" "|f02awf|" "|f02axf|" "|f02bbf|" 
> "|f02bjf|" "|f02fjf|" "|f02wef|" "|f02xef|" "|f04adf|" "|f04arf|" "|f04asf|" 
> "|f04atf|" "|f04axf|" "|f04faf|" "|f04jgf|" "|f04maf|" "|f04mbf|" "|f04mcf|" 
> "|f04qaf|" "|f07adf|" "|f07aef|" "|f07fdf|" "|f07fef|" "|s01eaf|" "|s13aaf|" 
> "|s13acf|" "|s13adf|" "|s14aaf|" "|s14abf|" "|s14baf|" "|s15adf|" "|s15aef|" 
> "|s17acf|" "|s17adf|" "|s17aef|" "|s17aff|" "|s17agf|" "|s17ahf|" "|s17ajf|" 
> "|s17akf|" "|s17dcf|" "|s17def|" "|s17dgf|" "|s17dhf|" "|s17dlf|" "|s18acf|" 
> "|s18adf|" "|s18aef|" "|s18aff|" "|s18dcf|" "|s18def|" "|s19aaf|" "|s19abf|" 
> "|s19acf|" "|s19adf|" "|s20acf|" "|s20adf|" "|s21baf|" "|s21bbf|" "|s21bcf|" 
> "|s21bdf|")
> )
> 
> (defun get-NAG-chapter (chapter function-list)
>    (apply 'append
>    (mapcar
>     #'(lambda (f)
>       (cond ((equalp chapter (subseq (string f) 0 (length chapter))) (list f 
> ))))
>     function-list)))
> 
> (si::use-fast-links nil)
> (get-NAG-chapter ch fl)
> ==========================================================================
> 
> 
> bash-2.05$ /home/build/axiom--main--1--patch-23/obj/sol9gcc/bin/lisp
> > (load "bug.lisp")
> Loading bug.lisp
> 
> Error:  Lisps arglist maximum surpassed
> Error signalled by APPLY.
> Broken at SYSTEM::BREAK-LEVEL.  Type :H for Help.
> >> :q
> Top level.
> > (quit)
> bash-2.05$
> 
> 

From unknown Mon Jan 24 21:05:40 -0600 2005
From: 
Date: Mon, 24 Jan 2005 21:05:40 -0600
Subject: additional information
Message-ID: <20050124210540-0600@page.axiom-developer.org>

> Camm,
> 
> Kostas has found a problem on the solaris 9 platform. The argument list
> given has 154 items.
> 

Yes, and I believe the reason is that his build loaded the
...NAG..chapter function interpreted, as opposed to compiled
(i.e. util.lisp not util.o) as I noted in a earlier post.
Fortunately, GCL's inliner expanded the apply therein and place all
args on the lisp value stack (as opposed to the limited C stack), thus
circumventing the argument limitation.  I've also posted two versions
which avert the problem at the lisp source level, which is preferable,
as the inliner depends on compilation safety options, etc.  Please let
me know if those functions don't fix the problem.  I still don't know
why Kostas' build loaded util.lisp interpreted.

> There used to be a similar problem in AKCL. Do you know what the
> current arg limits are and whether they can be changed?
> 

63, and yes.  In fact, it can be made to be unlimited via libffi (if
memory serves).  We discussed this before, and it was deemed of lower
priority.  Please let me know if we now feel otherwise.  Expanding the
existing code further, which has a huge switch/case branch on the
argument number, would not seem advisable, though of course could be
done.  We could even generate the switch at configure time and put in
another configure options, but there are already too many of these
IMHO.

> Kostas,
> 
> 
> Try loading the function interpreted. There are two possible ways to
> do this. Either start the image and load the file "util.lisp" (rather
> than "util.o"). Or move the function into the file "nocompil.lisp"
> which contains functions which are never compiled. 
> 

In this case, I believe, the advise should go the other way around.
compiling the function and load it would/should be an immediate
workaround, though this is just fortuitous in this case.

> As I recall, the interpreter can handle very long argument lists but
> the compiler cannot.
> 

Calling apply from the interpreter will be limited, and calling any C
function with more that 63 args will trigger this error too.  As we
see here, this can come from either the interpreter or compiler
depending on the inlining performed.  The best solution is to avoid
the situation at the lisp level, which should be straightforward.
Even that JoinInner in nocompil.lisp could be written to take a single
list as an arg, I think, but we shouldn't fool with this at the
present.



From unknown Mon Jan 24 21:10:02 -0600 2005
From: 
Date: Mon, 24 Jan 2005 21:10:02 -0600
Subject: additional information
Message-ID: <20050124211002-0600@page.axiom-developer.org>

Greetings!  And thanks for the detective work!

Here's a fix:

(defun get-NAG-chapter (chapter function-list)
   (mapcan
    (lambda (f)
      (cond ((equalp chapter (subseq (string f) 0 (length chapter))) (list f 
))))
    function-list)))

or perhaps better

(defun get-NAG-chapter (chapter function-list)
   (let ((l (length chapter)) r)
      (dolist (f function-list)
        (when (equalp chapter (subseq (string f) 0 l)))
           (push f r))
      (nreverse r)))   

Don't know why this does not occur elsewhere.

From TimDaly Sun Feb 13 07:55:04 -0600 2005
From: Tim Daly
Date: Sun, 13 Feb 2005 07:55:04 -0600
Subject: property change
Message-ID: <20050213075504-0600@page.axiom-developer.org>

Status: pending (next release) => closed

Submitted by : (unknown) at: 2007-11-17T22:58:06-08:00 (16 years ago)
Name :
Axiom Version :
Category : Severity : Status :
Optional subject :  
Optional comment : 

root <address@bogus.example.com> writes:

> From: root <address@bogus.example.com>
> Subject: address@bogus.example.com: [Axiom-developer] Problem with patch 23 and Solaris 
> 9 identified]
> To: address@bogus.example.com, "Kostas Oikonomou" <address@bogus.example.com>
> Cc: address@bogus.example.com, address@bogus.example.com
> Date: Sat, 8 Jan 2005 12:49:44 -0500
> Reply-to: address@bogus.example.com
> 
> Camm,
> 
> Kostas has found a problem on the solaris 9 platform. The argument list
> given has 154 items.
> 

Yes, and I believe the reason is that his build loaded the
...NAG..chapter function interpreted, as opposed to compiled
(i.e. util.lisp not util.o) as I noted in a earlier post.
Fortunately, GCL's inliner expanded the apply therein and place all
args on the lisp value stack (as opposed to the limited C stack), thus
circumventing the argument limitation.  I've also posted two versions
which avert the problem at the lisp source level, which is preferable,
as the inliner depends on compilation safety options, etc.  Please let
me know if those functions don't fix the problem.  I still don't know
why Kostas' build loaded util.lisp interpreted.

> There used to be a similar problem in AKCL. Do you know what the
> current arg limits are and whether they can be changed?
> 

63, and yes.  In fact, it can be made to be unlimited via libffi (if
memory serves).  We discussed this before, and it was deemed of lower
priority.  Please let me know if we now feel otherwise.  Expanding the
existing code further, which has a huge switch/case branch on the
argument number, would not seem advisable, though of course could be
done.  We could even generate the switch at configure time and put in
another configure options, but there are already too many of these
IMHO.

> Kostas,
> 
> 
> Try loading the function interpreted. There are two possible ways to
> do this. Either start the image and load the file "util.lisp" (rather
> than "util.o"). Or move the function into the file "nocompil.lisp"
> which contains functions which are never compiled. 
> 

In this case, I believe, the advise should go the other way around.
compiling the function and load it would/should be an immediate
workaround, though this is just fortuitous in this case.

> As I recall, the interpreter can handle very long argument lists but
> the compiler cannot.
> 

Calling apply from the interpreter will be limited, and calling any C
function with more that 63 args will trigger this error too.  As we
see here, this can come from either the interpreter or compiler
depending on the inlining performed.  The best solution is to avoid
the situation at the lisp level, which should be straightforward.
Even that JoinInner in nocompil.lisp could be written to take a single
list as an arg, I think, but we shouldn't fool with this at the
present.

Take care,

> Tim
> 
> 
> - ------- Start of forwarded message -------
> X-Original-To: address@bogus.example.com
> Received-SPF: pass (spamd.bsdwebsolutions.com: domain of nongnu.org 
> designates 199.232.76.165 as permitted sender) client-ip=199.232.76.165; 
> address@bogus.example.com; helo=lists.gnu.org;
> To: "Axiom developers" <address@bogus.example.com>
> Date: Sat, 08 Jan 2005 11:20:05 -0500
> From: "Kostas Oikonomou" <address@bogus.example.com>
> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1
> User-Agent: Opera M2/7.54 (SunOS, build 751)
> Subject: [Axiom-developer] Problem with patch 23 and Solaris 9 identified
> X-BeenThere: address@bogus.example.com
> X-Mailman-Version: 2.1.5
> Precedence: list
> List-Id: Axiom Developers <axiom-developer.nongnu.org>
> List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/axiom-developer>, 
>       <address@bogus.example.com">mailto:address@bogus.example.com>
> List-Archive: <http://lists.gnu.org/pipermail/axiom-developer>
> List-Post: <address@bogus.example.com">mailto:address@bogus.example.com>
> List-Help: <address@bogus.example.com">mailto:address@bogus.example.com>
> List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/axiom-developer>,
>       <address@bogus.example.com">mailto:address@bogus.example.com>
> Sender: address@bogus.example.com
> X-BSD-MailFrom: address@bogus.example.com
> X-BSD-RcptTo: address@bogus.example.com
> X-MIME-Character-set: iso-8859-1
> X-BSD-AntiVirus: No Virus Found
> X-BSD-MIME-Status: Safe
> X-BSD-Spam-Info: Spam detection software, provided by BSD WebSolutions, Inc.
> X-BSD-Spam-Info: Has scanned this message. If this is believed to be spam
> X-BSD-Spam-Info: A tag has been added to the subject for you own filtering 
> purposes.
> X-BSD-Spam-Info: Please call us at: (845) 485.4818 if you have any questions.
> X-BSD-Spam-Score: 0.5 (/)
> X-BSD-Spam-Report: The following tests were performed:
>       0.6 J_CHICKENPOX_34        BODY: 3alpha-pock-4alpha
>       -0.1 AWL                    AWL: From: address is in the auto white-list
> X-MIME-Autoconverted: from quoted-printable to 8bit by localhost.localdomain 
> id j08HS5x02181
> 
> 
> I just discovered that the problem I reported a few days ago is caused by
> the function "get-NAG-chapter" in "util.lisp".
> 
> Here is a test file "bug.lisp":
> 
> ==========================================================================
> (setq ch "c02")
> (setq fl
>   '("LOADNAG" "|c02aff|" "|c02agf|" "|c05adf|" "|c05nbf|" "|c05pbf|" 
> "|c06eaf|" "|c06ebf|" "|c06ecf|" "|c06ekf|" "|c06fpf|" "|c06fqf|" "|c06frf|" 
> "|c06fuf|" "|c06gbf|" "|c06gcf|" "|c06gqf|" "|c06gsf|" "|d01ajf|" "|d01akf|" 
> "|d01alf|" "|d01amf|" "|d01anf|" "|d01apf|" "|d01aqf|" "|d01asf|" "|d01bbf|" 
> "|d01fcf|" "|d01gaf|" "|d01gbf|" "|d02bbf|" "|d02bhf|" "|d02cjf|" "|d02ejf|" 
> "|d02gaf|" "|d02gbf|" "|d02kef|" "|d02raf|" "|d03edf|" "|d03eef|" "|d03faf|" 
> "|e01baf|" "|e01bef|" "|e01bff|" "|e01bgf|" "|e01bhf|" "|e01daf|" "|e01saf|" 
> "|e01sbf|" "|e01sef|" "|e02adf|" "|e02aef|" "|e02agf|" "|e02ahf|" "|e02ajf|" 
> "|e02akf|" "|e02baf|" "|e02bbf|" "|e02bcf|" "|e02bdf|" "|e02bef|" "|e02daf|" 
> "|e02dcf|" "|e02ddf|" "|e02def|" "|e02dff|" "|e02gaf|" "|e02zaf|" "|e04dgf|" 
> "|e04fdf|" "|e04gcf|" "|e04jaf|" "|e04mbf|" "|e04naf|" "|e04ucf|" "|e04ycf|" 
> "|f01brf|" "|f01bsf|" "|f01maf|" "|f01mcf|" "|f01qcf|" "|f01qdf|" "|f01qef|" 
> "|f01rcf|" "|f01rdf|" "|f01ref|" "|f02aaf|" "|f02abf|" "|f02adf|" "|f02ae!
> f|"  
> "|f02aff|" "|f02agf|" "|f02ajf|" "|f02akf|" "|f02awf|" "|f02axf|" "|f02bbf|" 
> "|f02bjf|" "|f02fjf|" "|f02wef|" "|f02xef|" "|f04adf|" "|f04arf|" "|f04asf|" 
> "|f04atf|" "|f04axf|" "|f04faf|" "|f04jgf|" "|f04maf|" "|f04mbf|" "|f04mcf|" 
> "|f04qaf|" "|f07adf|" "|f07aef|" "|f07fdf|" "|f07fef|" "|s01eaf|" "|s13aaf|" 
> "|s13acf|" "|s13adf|" "|s14aaf|" "|s14abf|" "|s14baf|" "|s15adf|" "|s15aef|" 
> "|s17acf|" "|s17adf|" "|s17aef|" "|s17aff|" "|s17agf|" "|s17ahf|" "|s17ajf|" 
> "|s17akf|" "|s17dcf|" "|s17def|" "|s17dgf|" "|s17dhf|" "|s17dlf|" "|s18acf|" 
> "|s18adf|" "|s18aef|" "|s18aff|" "|s18dcf|" "|s18def|" "|s19aaf|" "|s19abf|" 
> "|s19acf|" "|s19adf|" "|s20acf|" "|s20adf|" "|s21baf|" "|s21bbf|" "|s21bcf|" 
> "|s21bdf|")
> )
> 
> (defun get-NAG-chapter (chapter function-list)
>    (apply 'append
>    (mapcar
>     #'(lambda (f)
>       (cond ((equalp chapter (subseq (string f) 0 (length chapter))) (list f 
> ))))
>     function-list)))
> 
> (si::use-fast-links nil)
> (get-NAG-chapter ch fl)
> ==========================================================================
> 
> 
> bash-2.05$ /home/build/axiom--main--1--patch-23/obj/sol9gcc/bin/lisp
> > (load "bug.lisp")
> Loading bug.lisp
> 
> Error:  Lisps arglist maximum surpassed
> Error signalled by APPLY.
> Broken at SYSTEM::BREAK-LEVEL.  Type :H for Help.
> >> :q
> Top level.
> > (quit)
> bash-2.05$
> 
> 

------------------------------------------------------------


additional information --Mon, 24 Jan 2005 21:05:40 -0600

> Camm,
> 
> Kostas has found a problem on the solaris 9 platform. The argument list
> given has 154 items.
> 

Yes, and I believe the reason is that his build loaded the
...NAG..chapter function interpreted, as opposed to compiled
(i.e. util.lisp not util.o) as I noted in a earlier post.
Fortunately, GCL's inliner expanded the apply therein and place all
args on the lisp value stack (as opposed to the limited C stack), thus
circumventing the argument limitation.  I've also posted two versions
which avert the problem at the lisp source level, which is preferable,
as the inliner depends on compilation safety options, etc.  Please let
me know if those functions don't fix the problem.  I still don't know
why Kostas' build loaded util.lisp interpreted.

> There used to be a similar problem in AKCL. Do you know what the
> current arg limits are and whether they can be changed?
> 

63, and yes.  In fact, it can be made to be unlimited via libffi (if
memory serves).  We discussed this before, and it was deemed of lower
priority.  Please let me know if we now feel otherwise.  Expanding the
existing code further, which has a huge switch/case branch on the
argument number, would not seem advisable, though of course could be
done.  We could even generate the switch at configure time and put in
another configure options, but there are already too many of these
IMHO.

> Kostas,
> 
> 
> Try loading the function interpreted. There are two possible ways to
> do this. Either start the image and load the file "util.lisp" (rather
> than "util.o"). Or move the function into the file "nocompil.lisp"
> which contains functions which are never compiled. 
> 

In this case, I believe, the advise should go the other way around.
compiling the function and load it would/should be an immediate
workaround, though this is just fortuitous in this case.

> As I recall, the interpreter can handle very long argument lists but
> the compiler cannot.
> 

Calling apply from the interpreter will be limited, and calling any C
function with more that 63 args will trigger this error too.  As we
see here, this can come from either the interpreter or compiler
depending on the inlining performed.  The best solution is to avoid
the situation at the lisp level, which should be straightforward.
Even that JoinInner in nocompil.lisp could be written to take a single
list as an arg, I think, but we shouldn't fool with this at the
present.





additional information --Mon, 24 Jan 2005 21:10:02 -0600

Greetings!  And thanks for the detective work!

Here's a fix:

(defun get-NAG-chapter (chapter function-list)
   (mapcan
    (lambda (f)
      (cond ((equalp chapter (subseq (string f) 0 (length chapter))) (list f 
))))
    function-list)))

or perhaps better

(defun get-NAG-chapter (chapter function-list)
   (let ((l (length chapter)) r)
      (dolist (f function-list)
        (when (equalp chapter (subseq (string f) 0 l)))
           (push f r))
      (nreverse r)))   

Don't know why this does not occur elsewhere.



property change --Tim Daly, Sun, 13 Feb 2005 07:55:04 -0600

Status: pending (next release) => closed