* Stack Size? @ 2002-08-05 9:27 Robert Uhl <ruhl@4dv.net> 2002-08-05 15:08 ` Joshua Judson Rosen 2002-08-05 18:55 ` Neil Jerram 0 siblings, 2 replies; 13+ messages in thread From: Robert Uhl <ruhl@4dv.net> @ 2002-08-05 9:27 UTC (permalink / raw) I have the following empirical-integral function defined: (define (integral func from to) (define step (/ (- to from) 2048)) (define (my-int func from to) (if (>= from to) (func to) (+ (func from) (my-int func (+ from step) to)))) (my-int func from to)) I recognise that this may not be the most attractive of ways to do it, but it should do the job. Unfortunately, the following sequence of actions causes a stack overflow: (define (q x) (- 10 (* 8 x))) (integral q 0 1.25) How deep can guile's stack be? This example does _not_ crash on umb-scheme, which is interesting. Can anyone suggest a workaround? -- Robert Uhl <ruhl@4dv.net> Fight to your last cartridge, then fight with your bayonets. No surrender. Fight to the death. --Gen. Henri Guisan, Switzerland, July '40 _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-08-05 9:27 Stack Size? Robert Uhl <ruhl@4dv.net> @ 2002-08-05 15:08 ` Joshua Judson Rosen 2002-08-05 18:55 ` Neil Jerram 1 sibling, 0 replies; 13+ messages in thread From: Joshua Judson Rosen @ 2002-08-05 15:08 UTC (permalink / raw) Cc: guile-user On Mon, Aug 05, 2002 at 03:27:37AM -0600, Robert Uhl <ruhl@4dv.net> wrote: > I have the following empirical-integral function defined: > > (define (integral func from to) > (define step (/ (- to from) 2048)) > (define (my-int func from to) > (if (>= from to) > (func to) > (+ (func from) (my-int func (+ from step) to)))) > (my-int func from to)) > > I recognise that this may not be the most attractive of ways to do it, > but it should do the job. Unfortunately, the following sequence of > actions causes a stack overflow: > > (define (q x) (- 10 (* 8 x))) > (integral q 0 1.25) > > How deep can guile's stack be? This example does _not_ crash on > umb-scheme, which is interesting. Can anyone suggest a workaround? I don't know about guile's stack-limitations, but I can suggest that you write your function in a tail-recursive way, which would allow you to avoid the stack, e.g.: (define (integral func from to) (define step (/ (- to from) 2048)) (define (my-int func from to base-value) (if (>= from to) (+ base-value (func to)) (my-int func (+ from step) to (+ base-value (func from))))) (my-int func from to 0)) _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-08-05 9:27 Stack Size? Robert Uhl <ruhl@4dv.net> 2002-08-05 15:08 ` Joshua Judson Rosen @ 2002-08-05 18:55 ` Neil Jerram 2002-08-05 19:09 ` Robert Uhl <ruhl@4dv.net> 1 sibling, 1 reply; 13+ messages in thread From: Neil Jerram @ 2002-08-05 18:55 UTC (permalink / raw) Cc: guile-user >>>>> "ruhl@4dv" == ruhl@4dv net (Robert Uhl <<ruhl@4dv.net>)> writes: ruhl@4dv> How deep can guile's stack be? From the HEAD CVS manual, in the index under `stack overflow': Stack overflow -------------- Stack overflow errors are caused by a computation trying to use more stack space than has been enabled by the `stack' option. They are reported like this: (non-tail-recursive-factorial 500) -| ERROR: Stack overflow ABORT: (stack-overflow) If you get an error like this, you can either try rewriting your code to use less stack space, or increase the maximum stack size. To increase the maximum stack size, use `debug-set!', for example: (debug-set! stack 200000) => (show-file-name #t stack 200000 debug backtrace depth 20 maxdepth 1000 frames 3 indent 10 width 79 procnames cheap) (non-tail-recursive-factorial 500) => 122013682599111006870123878542304692625357434... If you prefer to try rewriting your code, you may be able to save stack space by making some of your procedures "tail recursive". For a description of what this means, see *Note Proper tail recursion: (r5rs)Proper tail recursion. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-08-05 18:55 ` Neil Jerram @ 2002-08-05 19:09 ` Robert Uhl <ruhl@4dv.net> 2002-08-08 21:28 ` Neil Jerram 0 siblings, 1 reply; 13+ messages in thread From: Robert Uhl <ruhl@4dv.net> @ 2002-08-05 19:09 UTC (permalink / raw) I've re-written the function, but it seems to me that it'd perhaps make more sense for Guile to simply grow the stack until it runs out of memory. Is there a technical reason this doesn't happen? -- Robert Uhl <ruhl@4dv.net> I really have to hand it to Fox this time, they've hit an all new low. And I just love new lows. They remind me that progress is growth, and growth is a two way street. --Rick Felice _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-08-05 19:09 ` Robert Uhl <ruhl@4dv.net> @ 2002-08-08 21:28 ` Neil Jerram 2002-08-08 21:49 ` Robert Uhl <ruhl@4dv.net> 0 siblings, 1 reply; 13+ messages in thread From: Neil Jerram @ 2002-08-08 21:28 UTC (permalink / raw) Cc: guile-user >>>>> "ruhl@4dv" == ruhl@4dv net (Robert Uhl <<ruhl@4dv.net>)> writes: ruhl@4dv> I've re-written the function, but it seems to me that it'd perhaps ruhl@4dv> make more sense for Guile to simply grow the stack until it runs out ruhl@4dv> of memory. Is there a technical reason this doesn't happen? No idea, I'm afraid. Perhaps it's considered a good thing for a language to allow applications to have a grip on their stack usage? According to the output of `(debug-options 'full)', you can turn off stack size checking by setting the limit to 0, i.e.: (debug-set! stack 0) Neil _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-08-08 21:28 ` Neil Jerram @ 2002-08-08 21:49 ` Robert Uhl <ruhl@4dv.net> 2002-08-09 13:48 ` Mikael Djurfeldt ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Robert Uhl <ruhl@4dv.net> @ 2002-08-08 21:49 UTC (permalink / raw) Neil Jerram <neil@ossau.uklinux.net> writes: > > > I've re-written the function, but it seems to me that it'd perhaps > > make more sense for Guile to simply grow the stack until it runs > > out of memory. Is there a technical reason this doesn't happen? > > No idea, I'm afraid. Perhaps it's considered a good thing for a > language to allow applications to have a grip on their stack usage? In a dynamic, functional language such as Scheme--or indeed any language--I'm not so certain I agree. While on the one hand switching to a tail function is certainly more efficient, it seems to me that that's not always the case. And certainly it can often be much clearer to write a bunch of functions which call bunches of functions which... > According to the output of `(debug-options 'full)', you can turn off > stack size checking by setting the limit to 0, i.e.: > > (debug-set! stack 0) Well, I'll not do that unless I need to--but I'd really rather I didn't need to. Que sera sera, I s'pose:-) It seems to me somewhat broken that one must set a debug option explicitly off. Sort of a command-line switch --behave-yourself, when that should be the default behaviour. Certainly, stack size checks may be _very_ useful when testing code. But just as certainly, in production those same checks are a nuisance, and can cause code to break. Or am I just being foolish? It's a definite possibility, I'll grant:-) -- Robert Uhl <ruhl@4dv.net> The purpose of the First Amendment's free-speech guarantee was pretty clearly to protect political discourse. But liberals reject the notion that free speech is therefore limited to political topics, even broadly defined. True, that purpose is not inscribed in the amendment itself. But why leap to the conclusion that a broadly worded constitutional freedom (`the right of the people to keep and bear arms') is narrowly limited by its stated purpose, unless you're trying to explain it away? My New Republic colleague Mickey Kaus says that if liberals interpreted the Second Amendment the way they interpret the rest of the Bill of Rights, there would be law professors arguing that gun ownership is mandatory. --Michael Kinsley Washington Post, January 8, 1990 _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-08-08 21:49 ` Robert Uhl <ruhl@4dv.net> @ 2002-08-09 13:48 ` Mikael Djurfeldt 2002-08-09 13:48 ` Mikael Djurfeldt 2002-08-09 13:48 ` Mikael Djurfeldt 2 siblings, 0 replies; 13+ messages in thread From: Mikael Djurfeldt @ 2002-08-09 13:48 UTC (permalink / raw) Cc: djurfeldt, guile-user ruhl@4dv.net (Robert Uhl <ruhl@4dv.net>) writes: > Neil Jerram <neil@ossau.uklinux.net> writes: > > > > > I've re-written the function, but it seems to me that it'd perhaps > > > make more sense for Guile to simply grow the stack until it runs > > > out of memory. Is there a technical reason this doesn't happen? > > > > No idea, I'm afraid. Perhaps it's considered a good thing for a > > language to allow applications to have a grip on their stack usage? Guile is supposed to be "nice" towards novice users. Infinite recursions is a very common error. Without a stack check, the effect is that the machine freezes due to excessive swapping, preventing the novice user from even examining what has happened. > It seems to me somewhat broken that one must set a debug option > explicitly off. Sort of a command-line switch --behave-yourself, when > that should be the default behaviour. Certainly, stack size checks > may be _very_ useful when testing code. But just as certainly, in > production those same checks are a nuisance, and can cause code to > break. It's probably a bad idea to use large stacks in production code and, if not, it's rather easy to set the option to whatever one wants. Maybe the correct setting is a very large stack? M _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-08-08 21:49 ` Robert Uhl <ruhl@4dv.net> 2002-08-09 13:48 ` Mikael Djurfeldt @ 2002-08-09 13:48 ` Mikael Djurfeldt 2002-08-09 13:48 ` Mikael Djurfeldt 2 siblings, 0 replies; 13+ messages in thread From: Mikael Djurfeldt @ 2002-08-09 13:48 UTC (permalink / raw) Cc: djurfeldt ruhl@4dv.net (Robert Uhl <ruhl@4dv.net>) writes: > Neil Jerram <neil@ossau.uklinux.net> writes: > > > > > I've re-written the function, but it seems to me that it'd perhaps > > > make more sense for Guile to simply grow the stack until it runs > > > out of memory. Is there a technical reason this doesn't happen? > > > > No idea, I'm afraid. Perhaps it's considered a good thing for a > > language to allow applications to have a grip on their stack usage? Guile is supposed to be "nice" towards novice users. Infinite recursions is a very common error. Without a stack check, the effect is that the machine freezes due to excessive swapping, preventing the novice user from even examining what has happened. > It seems to me somewhat broken that one must set a debug option > explicitly off. Sort of a command-line switch --behave-yourself, when > that should be the default behaviour. Certainly, stack size checks > may be _very_ useful when testing code. But just as certainly, in > production those same checks are a nuisance, and can cause code to > break. It's probably a bad idea to use large stacks in production code and, if not, it's rather easy to set the option to whatever one wants. Maybe the correct setting is a very large stack? M _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-08-08 21:49 ` Robert Uhl <ruhl@4dv.net> 2002-08-09 13:48 ` Mikael Djurfeldt 2002-08-09 13:48 ` Mikael Djurfeldt @ 2002-08-09 13:48 ` Mikael Djurfeldt 2002-08-11 22:07 ` Robert Uhl <ruhl@4dv.net> 2002-09-01 17:13 ` Rob Browning 2 siblings, 2 replies; 13+ messages in thread From: Mikael Djurfeldt @ 2002-08-09 13:48 UTC (permalink / raw) Cc: guile-user ruhl@4dv.net (Robert Uhl <ruhl@4dv.net>) writes: > Neil Jerram <neil@ossau.uklinux.net> writes: > > > > > I've re-written the function, but it seems to me that it'd perhaps > > > make more sense for Guile to simply grow the stack until it runs > > > out of memory. Is there a technical reason this doesn't happen? > > > > No idea, I'm afraid. Perhaps it's considered a good thing for a > > language to allow applications to have a grip on their stack usage? Guile is supposed to be "nice" towards novice users. Infinite recursions is a very common error. Without a stack check, the effect is that the machine freezes due to excessive swapping, preventing the novice user from even examining what has happened. > It seems to me somewhat broken that one must set a debug option > explicitly off. Sort of a command-line switch --behave-yourself, when > that should be the default behaviour. Certainly, stack size checks > may be _very_ useful when testing code. But just as certainly, in > production those same checks are a nuisance, and can cause code to > break. It's probably a bad idea to use large stacks in production code and, if not, it's rather easy to set the option to whatever one wants. Maybe the correct setting is a very large stack? M _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-08-09 13:48 ` Mikael Djurfeldt @ 2002-08-11 22:07 ` Robert Uhl <ruhl@4dv.net> 2002-09-01 17:13 ` Rob Browning 1 sibling, 0 replies; 13+ messages in thread From: Robert Uhl <ruhl@4dv.net> @ 2002-08-11 22:07 UTC (permalink / raw) Mikael Djurfeldt <mdj@kvast.blakulla.net> writes: > > Guile is supposed to be "nice" towards novice users. Infinite > recursions is a very common error. Without a stack check, the > effect is that the machine freezes due to excessive swapping, > preventing the novice user from even examining what has happened. We've all written infinite loops in our novitiate; we've all written infinitely-recursing programmes. But I've rarely used environments which cared until I exhausted the machine. The novice can still kill the currently running bit, and then step through his code if he desires... > It's probably a bad idea to use large stacks in production code and, > if not, it's rather easy to set the option to whatever one wants. It's a probably a bad idea to use large amounts of memory in production code. Except that sometimes it's necessary. The situation with excessive stack usage is not quite analogous (I'm not going to argue in favour of excessive function calls!), but somewhat similar. -- Robert Uhl <ruhl@4dv.net> The strongest reason for the right for the people to bear arms is, as a last resort, to protect themselves against tyranny in government. --Thomas Jefferson _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-08-09 13:48 ` Mikael Djurfeldt 2002-08-11 22:07 ` Robert Uhl <ruhl@4dv.net> @ 2002-09-01 17:13 ` Rob Browning 2002-09-01 19:08 ` Lynn Winebarger 2002-09-03 16:00 ` Paul Jarc 1 sibling, 2 replies; 13+ messages in thread From: Rob Browning @ 2002-09-01 17:13 UTC (permalink / raw) Cc: Robert Uhl <ruhl@4dv.net>, guile-user Mikael Djurfeldt <mdj@kvast.blakulla.net> writes: > Guile is supposed to be "nice" towards novice users. Infinite > recursions is a very common error. Without a stack check, the > effect is that the machine freezes due to excessive swapping, > preventing the novice user from even examining what has happened. Yeah, though I *was* surprised the first time I had a perfectly good recursion fall over in guile, one that I believe had been working fine in another scheme. I tend to think that if we're going to enforce a stack limit, it should be fairly high by default. Otherwise if you write a module that you know will be likely to use very large stacks for normal inputs, you've got to either communicate the need to raise the stack limit to everyone using your module via documentation, or you've got to raise the limit with a debug-set! call inside the module, and the latter solution is unworkable when you have two modules that have different ideas of how high the stack limit needs to be, since the result becomes dependent on load order. BTW, how does guile's stack limit apply to guile threads? Is the limit per-thread or global? (A part of me wonders whether or not we're just infringing on ulimit's territory here...) -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-09-01 17:13 ` Rob Browning @ 2002-09-01 19:08 ` Lynn Winebarger 2002-09-03 16:00 ` Paul Jarc 1 sibling, 0 replies; 13+ messages in thread From: Lynn Winebarger @ 2002-09-01 19:08 UTC (permalink / raw) Cc: Robert Uhl <ruhl@4dv.net>, guile-user On Sunday 01 September 2002 12:13, Rob Browning wrote: > Mikael Djurfeldt <mdj@kvast.blakulla.net> writes: > > > Guile is supposed to be "nice" towards novice users. Infinite > > recursions is a very common error. Without a stack check, the > > effect is that the machine freezes due to excessive swapping, > > preventing the novice user from even examining what has happened. There should be a smarter way to choose this kind of stack enforcement, that could be implemented if guile moves towards faster continuations (i.e. requiring more analysis than the parser does now) and stops using a single stack. I'm not sure exactly what I'm talking about, but I have a vague idea that this is probably done in most optimizing scheme interpreters/compilers. I think Dybvig's dissertation is on this very topic. Then a single stack could be used for certain simple types of recursions that would catch the novice cases and, while still being annoying for someone who knows what they're doing when they write a simple,deep recursion, might avoid some of the most egregious trespasses against the non-novice. > I tend to think that if we're going to enforce a stack limit, it > should be fairly high by default. Otherwise if you write a module > that you know will be likely to use very large stacks for normal > inputs, you've got to either communicate the need to raise the stack > limit to everyone using your module via documentation, or you've got > to raise the limit with a debug-set! call inside the module, and the > latter solution is unworkable when you have two modules that have > different ideas of how high the stack limit needs to be, since the > result becomes dependent on load order. It's a bad idea for a default. Most novices are not novices forever, yet compiling this option in seems to optimize for that case. If this is aimed at the application scripting user, the application can have a button for novice/expert mode. If it's for just plain old general purpose REPL usage, everybody's entitled to experience at least one accidental infinite recursion. > (A part of me wonders whether or not we're just infringing on ulimit's > territory here...) The answer is yes. Actually, the answer is plain old scheme mode should never run out of stack because it is not C. Application writers should be able to tweak that behaviour, perhaps, or maybe they should just be able to set a bound on how much system memory the gc is allowed to allocate. You know, register a hook for when that happens so they can ask the user whether to proceed or whatever. There would probably be some standard system exception this could throw if the user wanted to give up so the system wouldn't have to abort. Lynn _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Stack Size? 2002-09-01 17:13 ` Rob Browning 2002-09-01 19:08 ` Lynn Winebarger @ 2002-09-03 16:00 ` Paul Jarc 1 sibling, 0 replies; 13+ messages in thread From: Paul Jarc @ 2002-09-03 16:00 UTC (permalink / raw) Rob Browning <rlb@defaultvalue.org> wrote: > or you've got to raise the limit with a debug-set! call inside the > module, and the latter solution is unworkable when you have two > modules that have different ideas of how high the stack limit needs > to be, since the result becomes dependent on load order. They could check the current limit and change it only if it needs to be raised. FWIW. paul _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2002-09-03 16:00 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-08-05 9:27 Stack Size? Robert Uhl <ruhl@4dv.net> 2002-08-05 15:08 ` Joshua Judson Rosen 2002-08-05 18:55 ` Neil Jerram 2002-08-05 19:09 ` Robert Uhl <ruhl@4dv.net> 2002-08-08 21:28 ` Neil Jerram 2002-08-08 21:49 ` Robert Uhl <ruhl@4dv.net> 2002-08-09 13:48 ` Mikael Djurfeldt 2002-08-09 13:48 ` Mikael Djurfeldt 2002-08-09 13:48 ` Mikael Djurfeldt 2002-08-11 22:07 ` Robert Uhl <ruhl@4dv.net> 2002-09-01 17:13 ` Rob Browning 2002-09-01 19:08 ` Lynn Winebarger 2002-09-03 16:00 ` Paul Jarc
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).