1. Just some interesting facts
- Posted by akusaya at gmx.net
Dec 05, 2005
-
Last edited Dec 06, 2005
Try this:
object a
a = 0
for i = 1000000 to 1 by -1 do
a = {i, a}
a[1] = a
end for
print(1,a)
A message like "A stack overflow was encountered at address 0043d335"
will appear after about two thousand.
procedure b(object c)
?c
b(c+1)
end procedure
b(0)
After more than 600000 depth, it still runs!
So Eu stack is better than C stack. Or Eu doesn't use real stack.
2. Re: Just some interesting facts
- Posted by Jason Gade <jaygade at yahoo.com>
Dec 05, 2005
-
Last edited Dec 06, 2005
akusaya wrote:
>
> Try this:
>
>
> object a
> a = 0
> for i = 1000000 to 1 by -1 do
> a = {i, a}
> a[1] = a
> end for
> print(1,a)
> A message like "A stack overflow was encountered at address 0043d335"
> will appear after about two thousand.
It looks like the stack overflow is coming from the print statement, not the for
loop or sequence creation. I can get it to pass by commenting out or removing the
print statement.
> procedure b(object c)
> ?c
> b(c+1)
> end procedure
> b(0)
>
>
> After more than 600000 depth, it still runs!
>
>
> So Eu stack is better than C stack. Or Eu doesn't use real stack.
>
>
--
"Actually, I'm sitting on my butt staring at a computer screen."
- Tom Tomorrow
j.
3. Re: Just some interesting facts
- Posted by Robert Craig <rds at RapidEuphoria.com>
Dec 05, 2005
-
Last edited Dec 06, 2005
Jason Gade wrote:
> akusaya wrote:
> > Try this:
> >
> > object a
> > a = 0
> > for i = 1000000 to 1 by -1 do
> > a = {i, a}
> > a[1] = a
> > end for
> > print(1,a)
> > A message like "A stack overflow was encountered at address 0043d335"
> > will appear after about two thousand.
>
> It looks like the stack overflow is coming from the print statement, not the
> for loop or sequence creation. I can get it to pass by commenting out or
> removing
> the print statement.
Yes. It builds a sequence that's nested a million levels deep,
but print() fails because print is implemented using a recursive
C routine, and it eventually blows the hardware stack limit that's
set when the interpreter is built. I've been aware for a long time
that this type of thing could happen. I recoded some recursive
routines as non-recursive, to reduce the risk, but when you
are dealing with recursive data structures, recursion is very handy.
If you replace print() with pretty_print(), it will work,
because pretty_print() is written in Euphoria.
I'll boost the stack limit in the next release,
but there will always be a limit, if I want reasonable efficiency.
Unless someone knows how to get DOS or Windows to automatically
enlarge the stack. In practice, people never seem to hit the existing
limit unless they are just fooling around.
> > procedure b(object c)
> > ?c
> > b(c+1)
> > end procedure
> > b(0)
> >
> >
> > After more than 600000 depth, it still runs!
> >
> >
> > So Eu stack is better than C stack. Or Eu doesn't use real stack.
Euphoria manages it's own call stack for running Euphoria routines.
It will grow that stack as required.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
