I have an intensive linear recursive process that is difficult to
elegantly code tail recursively for various reasons. The program
works except when the input exceeds a size of say 30,000 characters
and then bombs out with a memory problem. Is there any way to
reconfigure the CL memory to allow for this sort of case since the
problem is obviously a memory overflow problem? I see ROOM listed as
a CL function but no indication on what functions reconfigure CL. I'm
using CLisp in case these functions are external.
Mark
Mark Tarver <··········@ukonline.co.uk> writes:
> I have an intensive linear recursive process that is difficult to
> elegantly code tail recursively for various reasons. The program
> works except when the input exceeds a size of say 30,000 characters
> and then bombs out with a memory problem. Is there any way to
> reconfigure the CL memory to allow for this sort of case since the
> problem is obviously a memory overflow problem? I see ROOM listed as
> a CL function but no indication on what functions reconfigure CL. I'm
> using CLisp in case these functions are external.
You're right that ROOM is there mostly so that people have a foothold
on telling when things are going awry, but that's about it. (Of
course, even the output of ROOM will vary widely in what information
it offers, what terminology it uses, and so on... but it's intended
to be at least somewhat intelligible and something that can give you
useful hints.)
But you really have to talk to the vendor (or see their doc) to have a
meaningful dialog about how to adjust things. That's just way beyond
the scope of what the standard set out to do. Implementors have plenty
of freedom about how to implement things, and trying to write a standard
that said how to summarize things where you don't know what you're
summarizing is more than what you should expect. Many people suggested
leaving out these "environment functions" (room, trace, inspect, ed, etc.)
but the general sense was that it was useful to at least nudge vendors a
little in the direction of offering facilities of this kind since they
had been traditionally available.
On 1 Dec, 05:53, Kent M Pitman <······@nhplace.com> wrote:
> Mark Tarver <··········@ukonline.co.uk> writes:
> > I have an intensive linear recursive process that is difficult to
> > elegantly code tail recursively for various reasons. The program
> > works except when the input exceeds a size of say 30,000 characters
> > and then bombs out with a memory problem. Is there any way to
> > reconfigure the CL memory to allow for this sort of case since the
> > problem is obviously a memory overflow problem? I see ROOM listed as
> > a CL function but no indication on what functions reconfigure CL. I'm
> > using CLisp in case these functions are external.
>
> You're right that ROOM is there mostly so that people have a foothold
> on telling when things are going awry, but that's about it. (Of
> course, even the output of ROOM will vary widely in what information
> it offers, what terminology it uses, and so on... but it's intended
> to be at least somewhat intelligible and something that can give you
> useful hints.)
>
> But you really have to talk to the vendor (or see their doc) to have a
> meaningful dialog about how to adjust things. That's just way beyond
> the scope of what the standard set out to do. Implementors have plenty
> of freedom about how to implement things, and trying to write a standard
> that said how to summarize things where you don't know what you're
> summarizing is more than what you should expect. Many people suggested
> leaving out these "environment functions" (room, trace, inspect, ed, etc.)
> but the general sense was that it was useful to at least nudge vendors a
> little in the direction of offering facilities of this kind since they
> had been traditionally available.
Thanks for that; I've Googled on the subject and it seems that in
CLisp you have to edit the configuration files to change the call
stack setup.
Not the easy change-a-global approach I hoped for.
Mark