Hi, I am working here with a description logic classifier in GCL and
it's bailing out with a "Frame stack overflow" error with a frame
stack of height 653. Normally I would think that this is a termination
issue, but this algorithm is tested and believed to work, yet my
data is pretty big, so I would expect it to run long and deep. But
why should there even be a stack overflow on a machine with virtual
memory? I have set ulimit -s unlimited but to no avail. Is there some
maximum frame stack size parameter in GCL that could be increased?
thanks,
-Gunther
"G. Schadow" <·················@gusw.net> wrote:
> Hi, I am working here with a description logic classifier in GCL and
> it's bailing out with a "Frame stack overflow" error with a frame
> stack of height 653....
I don't know any answers to your questions, but it might help if
you'd mention the kind of machine you're using. For example, the
SPARC's standard calling convention implies a minimum frame size
of 96 bytes, and 96*653 is suspiciously close to 2^16, which is
the sort of number a clueless systems programmer might choose for
the default stack size.
The PowerPC's standard calling convention may imply a similarly
large size for stack frames, but I don't remember the details.
Will
In article <························@newssvr28.news.prodigy.com>,
"G. Schadow" <·················@gusw.net> wrote:
> Hi, I am working here with a description logic classifier in GCL and
> it's bailing out with a "Frame stack overflow" error with a frame
> stack of height 653. Normally I would think that this is a termination
> issue, but this algorithm is tested and believed to work, yet my
> data is pretty big, so I would expect it to run long and deep. But
> why should there even be a stack overflow on a machine with virtual
> memory? I have set ulimit -s unlimited but to no avail. Is there some
> maximum frame stack size parameter in GCL that could be increased?
Is your data structure really recursive, so that only a deeply recursive
algorithm is appropriate to process it? If not, Common Lisp has lots of
good iterative operators that are often more appropriate. People who
come to the Lisp family via Scheme often try to do everything
recursively, but there may be better ways to structure the code.
--
Barry Margolin, ······@alum.mit.edu
Woburn, MA
Barry Margolin <······@alum.mit.edu> writes:
> In article <························@newssvr28.news.prodigy.com>,
> "G. Schadow" <·················@gusw.net> wrote:
>
> > Hi, I am working here with a description logic classifier in GCL and
> > it's bailing out with a "Frame stack overflow" error with a frame
> > stack of height 653. Normally I would think that this is a termination
> > issue, but this algorithm is tested and believed to work, yet my
> > data is pretty big, so I would expect it to run long and deep. But
> > why should there even be a stack overflow on a machine with virtual
> > memory? I have set ulimit -s unlimited but to no avail. Is there some
> > maximum frame stack size parameter in GCL that could be increased?
>
> Is your data structure really recursive, so that only a deeply recursive
> algorithm is appropriate to process it? If not, Common Lisp has lots of
> good iterative operators that are often more appropriate. People who
> come to the Lisp family via Scheme often try to do everything
> recursively, but there may be better ways to structure the code.
FWIW, I use the rule of thumb "recurse on the car and loop on the cdr."