From: Surendra Singhi
Subject: circulatory analysis
Date: 
Message-ID: <cmufes$35g$1@news.asu.edu>
Hi,
   I am executing a large meory hogging program in lisp, while running 
it for some large sized programs I get the following error message:

I am executing the program from xemacs(minor mode: slime), is this error 
message(given below) generated by slime, or clisp.

And what does print means is it something to do with printing and what 
does cicularity analysis means?


*** - PRINT: not enough stack space for carrying out circularity analysis
The following restarts are available:
ABORT          :R1      Abort handling SLIME request.



Thanks,
Surendra Singhi

From: Barry Margolin
Subject: Re: circulatory analysis
Date: 
Message-ID: <barmar-8C4545.21023910112004@comcast.dca.giganews.com>
In article <············@news.asu.edu>,
 Surendra Singhi <·········@netscape.net> wrote:

> Hi,
>    I am executing a large meory hogging program in lisp, while running 
> it for some large sized programs I get the following error message:
> 
> I am executing the program from xemacs(minor mode: slime), is this error 
> message(given below) generated by slime, or clisp.
> 
> And what does print means is it something to do with printing and what 
> does cicularity analysis means?
> 
> 
> *** - PRINT: not enough stack space for carrying out circularity analysis
> The following restarts are available:
> ABORT          :R1      Abort handling SLIME request.

I think this means you have *PRINT-CIRCLE* set to non-NIL, so it's 
trying to find the common objects in order to use #n= and #n# syntax.  
But it had a stack overflow while recursing through the chain of objects 
looking for these commonalities.

-- 
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Pascal Bourguignon
Subject: Re: circulatory analysis
Date: 
Message-ID: <87vfcchhcj.fsf@naiad.informatimago.com>
Surendra Singhi <·········@netscape.net> writes:

> Hi,
>    I am executing a large meory hogging program in lisp, while running
> it for some large sized programs I get the following error message:
> 
> I am executing the program from xemacs(minor mode: slime), is this
> error message(given below) generated by slime, or clisp.

It's generated by clisp.
 
> And what does print means is it something to do with printing and what
> does cicularity analysis means?

See Barry's answer.

> *** - PRINT: not enough stack space for carrying out circularity analysis
> The following restarts are available:
> ABORT          :R1      Abort handling SLIME request.

clisp uses much less stack on compiled code.  Did you compile your
program?  Compiled clisp is also faster than non-compiled, but
debugging of compiled clisp programs is less easy.

You may try to set *PRINT-LEVEL* (and perhaps *PRINT-LENGTH* depending
on the structure of your data) to limit printing deep structures, in
addition to *PRINT-CIRCLE*.

-- 
__Pascal Bourguignon__
From: Bruno Haible
Subject: Re: circulatory analysis
Date: 
Message-ID: <cmvs5b$kfd$1@laposte.ilog.fr>
Pascal Bourguignon wrote:

>> *** - PRINT: not enough stack space for carrying out circularity analysis
>> The following restarts are available:
>> ABORT          :R1      Abort handling SLIME request.
>
> clisp uses much less stack on compiled code.  Did you compile your
> program?  Compiled clisp is also faster than non-compiled, but
> debugging of compiled clisp programs is less easy.
>
> You may try to set *PRINT-LEVEL* (and perhaps *PRINT-LENGTH* depending
> on the structure of your data) to limit printing deep structures, in
> addition to *PRINT-CIRCLE*.

Both of these hints won't help. Compiled code vs. interpreted code is
not an issue here. The issue is the number of objects that are printed
in #n= notation is huge. Also, what may help, is setting *PRINT-ARRAY*
to NIL, whereas *PRINT-LEVEL* and *PRINT-LENGTH* are ignored by clisp's
circularity analysis.

What will help, is increasing the available stack memory, though use
of the -m command line option.

                  Bruno
From: Surendra Singhi
Subject: Re: circulatory analysis
Date: 
Message-ID: <cn104a$mg4$1@news.asu.edu>
Bruno Haible wrote:
> Pascal Bourguignon wrote:
> 
> 
>>>*** - PRINT: not enough stack space for carrying out circularity analysis
>>>The following restarts are available:
>>>ABORT          :R1      Abort handling SLIME request.
>>
>>clisp uses much less stack on compiled code.  Did you compile your
>>program?  Compiled clisp is also faster than non-compiled, but
>>debugging of compiled clisp programs is less easy.
>>
>>You may try to set *PRINT-LEVEL* (and perhaps *PRINT-LENGTH* depending
>>on the structure of your data) to limit printing deep structures, in
>>addition to *PRINT-CIRCLE*.
> 
> 
> Both of these hints won't help. Compiled code vs. interpreted code is
> not an issue here. The issue is the number of objects that are printed
> in #n= notation is huge. Also, what may help, is setting *PRINT-ARRAY*
> to NIL, whereas *PRINT-LEVEL* and *PRINT-LENGTH* are ignored by clisp's
> circularity analysis.
> 
> What will help, is increasing the available stack memory, though use
> of the -m command line option.
> 
>                   Bruno

The funny thing is that i am not printing anything.
But yes I do have a huge huge structure which is 18 levels deep and has 
lots of values in it. And I am trying to make it a 2 level structure 
that should solve the problem, but I was just curious to know the reason 
for this error message.
I have tried all the options except the last one "-m command line" 
option and none of them have worked. I had tried (setf *print-length* 
0) (setf *print-array*  0) besides setting print-circle and print-level 
to true.


-Surendra Singhi
From: Svein Ove Aas
Subject: Re: circulatory analysis
Date: 
Message-ID: <cn11bp$ifr$1@services.kq.no>
Surendra Singhi wrote:

> 
> 
> Bruno Haible wrote:
>> Pascal Bourguignon wrote:
>> 
>> 
>>>>*** - PRINT: not enough stack space for carrying out circularity
>>>>analysis The following restarts are available:
>>>>ABORT          :R1      Abort handling SLIME request.
>>>
>>>clisp uses much less stack on compiled code.  Did you compile your
>>>program?  Compiled clisp is also faster than non-compiled, but
>>>debugging of compiled clisp programs is less easy.
>>>
>>>You may try to set *PRINT-LEVEL* (and perhaps *PRINT-LENGTH* depending
>>>on the structure of your data) to limit printing deep structures, in
>>>addition to *PRINT-CIRCLE*.
>> 
>> 
>> Both of these hints won't help. Compiled code vs. interpreted code is
>> not an issue here. The issue is the number of objects that are printed
>> in #n= notation is huge. Also, what may help, is setting *PRINT-ARRAY*
>> to NIL, whereas *PRINT-LEVEL* and *PRINT-LENGTH* are ignored by clisp's
>> circularity analysis.
>> 
>> What will help, is increasing the available stack memory, though use
>> of the -m command line option.
>> 
>>                   Bruno
> 
> The funny thing is that i am not printing anything.

Anything you return from a top-level call is implicitly printed. Are you
*sure* you aren't printing anything?

> But yes I do have a huge huge structure which is 18 levels deep and has
> lots of values in it. And I am trying to make it a 2 level structure
> that should solve the problem, but I was just curious to know the reason
> for this error message.
> I have tried all the options except the last one "-m command line"
> option and none of them have worked. I had tried (setf *print-length*
> 0) (setf *print-array*  0) besides setting print-circle and print-level
> to true.
> 
Disabling print-array should certainly have fixed it.
I don't suppose you could post a snippet showing the problem somewhere? 
From: Surendra Singhi
Subject: Re: circulatory analysis
Date: 
Message-ID: <cn128p$h96$1@news.asu.edu>
This is a multi-part message in MIME format.
--------------080803020909050205020702
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Svein Ove Aas wrote:

> Surendra Singhi wrote:
> 
> 
>>
>>Bruno Haible wrote:
>>
>>>Pascal Bourguignon wrote:
>>>
>>>
>>>
>>>>>*** - PRINT: not enough stack space for carrying out circularity
>>>>>analysis The following restarts are available:
>>>>>ABORT          :R1      Abort handling SLIME request.
>>>>
>>>>clisp uses much less stack on compiled code.  Did you compile your
>>>>program?  Compiled clisp is also faster than non-compiled, but
>>>>debugging of compiled clisp programs is less easy.
>>>>
>>>>You may try to set *PRINT-LEVEL* (and perhaps *PRINT-LENGTH* depending
>>>>on the structure of your data) to limit printing deep structures, in
>>>>addition to *PRINT-CIRCLE*.
>>>
>>>
>>>Both of these hints won't help. Compiled code vs. interpreted code is
>>>not an issue here. The issue is the number of objects that are printed
>>>in #n= notation is huge. Also, what may help, is setting *PRINT-ARRAY*
>>>to NIL, whereas *PRINT-LEVEL* and *PRINT-LENGTH* are ignored by clisp's
>>>circularity analysis.
>>>
>>>What will help, is increasing the available stack memory, though use
>>>of the -m command line option.
>>>
>>>                  Bruno
>>
>>The funny thing is that i am not printing anything.
> 
> 
> Anything you return from a top-level call is implicitly printed. Are you
> *sure* you aren't printing anything?
> 

I am returning the structure from some functions, its actually being 
destructively modified and then returned, is it equivalent to implicit 
printing? I thought when a function returns something it just returns 
the starting address of it.

I am not printing it on any stream anywhere.

> 
>>But yes I do have a huge huge structure which is 18 levels deep and has
>>lots of values in it. And I am trying to make it a 2 level structure
>>that should solve the problem, but I was just curious to know the reason
>>for this error message.
>>I have tried all the options except the last one "-m command line"
>>option and none of them have worked. I had tried (setf *print-length*
>>0) (setf *print-array*  0) besides setting print-circle and print-level
>>to true.
>>
> 
> Disabling print-array should certainly have fixed it.
> I don't suppose you could post a snippet showing the problem somewhere? 

I will try to do that, but the code is still messy(unlisp like), and its 
huge.

--------------080803020909050205020702
Content-Type: text/x-vcard; charset=utf-8;
 name="efuzzyone.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="efuzzyone.vcf"

begin:vcard
fn:Surendra Singhi
n:Singhi;Surendra
adr:;;;Tempe;AZ;85281;USA
························@netscape.net
version:2.1
end:vcard


--------------080803020909050205020702--
From: Svein Ove Aas
Subject: Re: circulatory analysis
Date: 
Message-ID: <cn1rlo$lk8$1@services.kq.no>
Surendra Singhi wrote:

> Svein Ove Aas wrote:
> 
>> Surendra Singhi wrote:

>>>The funny thing is that i am not printing anything.
>> 
>> 
>> Anything you return from a top-level call is implicitly printed. Are you
>> *sure* you aren't printing anything?
>> 
> 
> I am returning the structure from some functions, its actually being
> destructively modified and then returned, is it equivalent to implicit
> printing? I thought when a function returns something it just returns
> the starting address of it.
> 
> I am not printing it on any stream anywhere.
> 
If you call a function from the REPL, then its return value is printed.
Otherwise, not.