Hi,
I'm using CLISP on NT. When running:
(defun read-file (name)
(let ((x (make-array '(1046529) :element-type :single-float
:initial-element 0.0 :fill-pointer 0 :adjustable t))
(y (make-array '(1046529) :element-type :single-float
:initial-element 0.0 :fill-pointer 0 :adjustable t))
(z (make-array '(1046529) :element-type :single-float
:initial-element 0.0 :fill-pointer 0 :adjustable t)))
(with-open-file (in name)
(do ((xx (read in nil 'eof) (read in nil 'eof))
(yy (read in nil 'eof) (read in nil 'eof))
(zz (read in nil 'eof) (read in nil 'eof)))
((eql zz 'eof))
(progn (vector-push-extend xx x)
(vector-push-extend yy y)
(vector-push-extend zz z))))
(values x y z)))
(compile 'read-file)
(setf result (multiple-value-bind (mx my mz) (read-file "big_file.txt")
(list mx my mz)))
on a big file (about 27 MB) I get the message:
*** - Program stack overflow. RESET
*** - Program stack overflow. RESET
and so on. I wouldn't have expected read-file to fill up the stack. How
can I get around this problem?
Rolf
From: Sam Steingold
Subject: Re: Program stack overflow in CLISP
Date:
Message-ID: <ug0a23m6o.fsf@xchange.com>
> * In message <·················@ilt.fhg.de>
> * On the subject of "Program stack overflow in CLISP"
> * Sent on Tue, 04 Sep 2001 15:35:20 +0200
> * Honorable Rolf Wester <······@ilt.fhg.de> writes:
>
> I'm using CLISP on NT. When running:
you might prefer to ask CLISP-specific questions on <clisp-list>.
> (compile 'read-file)
> (setf result (multiple-value-bind (mx my mz) (read-file "big_file.txt")
> (list mx my mz)))
>
> on a big file (about 27 MB) I get the message:
>
> *** - Program stack overflow. RESET
> *** - Program stack overflow. RESET
>
> and so on. I wouldn't have expected read-file to fill up the stack.
I am pretty sure this is the printer problem: you probably have
*print-circle* set to T or something.
> How can I get around this problem?
try
(progn
(setq result (multiple-value-call #'list (read-file "big_file.txt")))
nil)
if you are still having problems, please e-mail <clisp-list>
--
Sam Steingold (http://www.podval.org/~sds)
Support Israel's right to defend herself! <http://www.i-charity.com/go/israel>
Read what the Arab leaders say to their people on <http://www.memri.org/>
What garlic is to food, insanity is to art.
Sam Steingold <···@gnu.org> writes:
> (progn
> (setq result (multiple-value-call #'list (read-file "big_file.txt")))
> nil)
Didn't reply to the OP because I had no solution for the real
problem. But there is MULTIPLE-VALUE-LIST in CL :)
--
Janis Dzerins
If million people say a stupid thing it's still a stupid thing.
Rolf Wester <······@ilt.fhg.de> writes:
> (defun read-file (name)
> (let ((x (make-array '(1046529) :element-type :single-float
> :initial-element 0.0 :fill-pointer 0 :adjustable t))
> (y (make-array '(1046529) :element-type :single-float
> :initial-element 0.0 :fill-pointer 0 :adjustable t))
> (z (make-array '(1046529) :element-type :single-float
> :initial-element 0.0 :fill-pointer 0 :adjustable t)))
> (with-open-file (in name)
> (do ((xx (read in nil 'eof) (read in nil 'eof))
> (yy (read in nil 'eof) (read in nil 'eof))
> (zz (read in nil 'eof) (read in nil 'eof)))
> ((eql zz 'eof))
^^
The problem you have here is that you are only testing for end of file
on one of the resulting inputs. Given the example call given below, you
are most likely hitting the true End of file on the read that assigns a
value to the variable XX. Once you have reached the end-of-file, the
standard doesn't really say what happens if you keep on reading beyond
that point.
In some Lisp systems, the end of file signal is only generated for the
read that actually exhausts the file, and other undefined behavior
occurs if you keep on reading.
You should try the following test and see if it does any better:
((or (eq xx 'eof) (eq yy 'eof) (eq zz 'eof)))
> (progn (vector-push-extend xx x)
> (vector-push-extend yy y)
> (vector-push-extend zz z))))
> (values x y z)))
>
> (compile 'read-file)
> (setf result (multiple-value-bind (mx my mz) (read-file "big_file.txt")
> (list mx my mz)))
>
> on a big file (about 27 MB) I get the message:
>
> *** - Program stack overflow. RESET
> *** - Program stack overflow. RESET
>
> and so on. I wouldn't have expected read-file to fill up the stack. How
> can I get around this problem?
> Rolf
I expect that some other resource is using up the stack. Reading random
garbage by going past the real end of file is a likely culprit.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu