Re: autocompilation support in master
Mark H Weaver m...@netris.org wrote: On Tue, Jun 09, 2009 at 12:24:48AM +0100, Neil Jerram wrote: GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o language/ecmascript/spec.go language/ecmascript/spec.scm ERROR: Stack overflow This is still happening for me after pulling the latest master today. I have the same problem on Debian Lenny/x86, and am able to work around it by increasing the stack size resource limit. On my system, ulimit -s 16384 (within bash) before running make does the trick. Unfortunately, this is not a portable solution. Yes, I've experienced this too. Works for me when I bump up my stack to 9000 from 8192. I've also found that's it's compiler dependent. Gcc 4.4 works I think, while 4.3 fails. (Not sure about that, as I'm not at that machine right now). -Dale Mark
Re: autocompilation support in master
On Tue, Jun 09, 2009 at 09:27:37AM +0200, Andy Wingo wrote: It's a strange thing, and I don't see it on my x86-32 laptop running Fedora. But I've heard reports of this. A backtrace at the time of stack overflow would be helpful. Strangely, the stack overflow doesn't happen when I run the compile command (as echoed by make) directly from the command line. I only see it happen when compiling via make. To generate the backtrace, I added the following lines near the top of guile-tools. Is there a better way? (debug-enable 'debug) (debug-enable 'backtrace) (debug-set! depth 100) (write (debug-options-interface)) (newline) The resulting backtrace follows. This is git master from a few days ago, commit 12798872ff39e27dbcf90675c3d3554ae27df750. Mark GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o language/ecmascript/spec.go language/ecmascript/spec.scm (show-file-name #t stack 4 debug backtrace depth 100 maxdepth 1000 frames 3 indent 10 width 79 procnames cheap) Backtrace: In ice-9/psyntax-pp.scm: 20: 271 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 272 [# core-form # # ...] In unknown file: ?: 273* [map #program 4060aa30 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 274* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 275 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 276 [# core-form # # ...] In unknown file: ?: 277* [map #program 405fa110 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 278* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 279 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 280 [# core-form # # ...] In unknown file: ?: 281* [map #program 405fee40 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 282* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 283 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 284 [# core-form # # ...] In unknown file: ?: 285* [map #program 405fb0e0 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 286* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 287 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 288 [# core-form # # ...] In unknown file: ?: 289* [map #program 405fc9f0 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 290* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 291 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 292 [# core-form # # ...] In unknown file: ?: 293* [map #program 40608020 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 294* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 295 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 296 [# core-form # # ...] In unknown file: ?: 297* [map #program 40540cf0 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 298* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 299 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 300 [# core-form # # ...] In unknown file: ?: 301* [map #program 4060a130 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 302* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 303 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 304 [# core-form # # ...] In unknown file: ?: 305* [map #program 406020c0 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 306* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 307 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 308 [# core-form # # ...] In unknown file: ?: 309* [map #program 405f6ed0 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 310* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 311 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 312 [# core-form # # ...] In unknown file: ?: 313* [map #program 4060cf40 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 314* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 315 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 316 [# core-form # # ...] In unknown file: ?: 317* [map #program 40605410 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 318* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 319 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 320 [# core-form # # ...] In unknown file: ?: 321* [map #program 405fac30 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] In ice-9/psyntax-pp.scm: 24: 322* [# # # # ...] In ice-9/psyntax-pp.scm: 20: 323 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 324 [# core-form # # ...] In unknown file: ?: 325* [map #program 4053e7f0 at
(debug-options 'full) is broken
According to node User level options interfaces of api-options.texi, (debug-options 'full) should print a list of options, but it fails with ERROR: unbound variable: option-name. The other options interfaces (eval-options, read-options, print-options, traps) are broken as well. The problem is here, in boot-9.scm: (defmacro define-option-interface (option-group) (let* ((option-name car) (option-value cadr) (option-documentation caddr) ;; Below follow the macros defining the run-time option interfaces. (make-options (lambda (interface) `(lambda args (cond ((null? args) (,interface)) ((list? (car args)) (,interface (car args)) (,interface)) (else (for-each (lambda (option) (display (option-name option)) (if ( (string-length (symbol-string (option-name option))) 8) (display #\tab)) (display #\tab) (display (option-value option)) (display #\tab) (display (option-documentation option)) (newline)) (,interface #t))) [...etc...] How was this supposed to work? How were the local bindings of option-name, option-value, and option-documentation supposed to be referenced from within the expansion of this non-hygienic macro? Mark Guile Scheme interpreter 0.5 on Guile 1.9.0 Copyright (C) 2001-2008 Free Software Foundation, Inc. Enter `,help' for help. scheme@(guile-user) (debug-options 'full) Backtrace: In unknown file: ?: 0* [#vm b7b876b8 #program b7a9aef0 at standard input:0:0 ()] ?: 1* [debug-options full] ?: 2* [for-each #program 861bda0 (option) (# # # # ...)] ?: 3* [# #] ERROR: In procedure module-lookup: ERROR: unbound variable: option-name scheme@(guile-user)
Emacs Lisp revived
Hi all, I finally started real work on implementing the elisp compiler and just pushed a first start-off code to branch elisp. It is however not yet usable for anything, but also already has some very few things done. Some important points I'd like to mention and welcome comments: 1) In implementing all those special forms like progn, prog1, if, while, ... I think it is best to translate a basic set directly to TreeIL via the compiler, but also implement some (where that's reasonably possible) simply as elisp macros (or even some things as functions). What do you think about this plan? 2) It seems that elisp uses nil as false value (and does not have a dedicated false); so the question raises, should be then always use #f for nil, or maybe TreeIL's void? But some experiments show that void is rather interpreted as true: tree-il@(guile-user) (if (void) (const 1) (const 2)) 1 scheme@(guile-user) (if (if #f 0) 1 2) 1 Not related, but I came across it: (if (begin) 1 2) gives an error, don't know if that's expected. I think I remember already reading some discussion about this topic in general for Guile's elisp support; so what should we do here? My code so far uses #f as nil, BTW. 3) I still haven't got building lexical constructs in TreeIL working (and I figure that named-lets for compiling the while-construct are even more interesting), but will hopefully manage to do so soon... Yours, Daniel
Re: autocompilation support in master
On Tue 09 Jun 2009 20:47, Mark H Weaver m...@netris.org writes: On Tue, Jun 09, 2009 at 09:27:37AM +0200, Andy Wingo wrote: It's a strange thing, and I don't see it on my x86-32 laptop running Fedora. But I've heard reports of this. A backtrace at the time of stack overflow would be helpful. Strangely, the stack overflow doesn't happen when I run the compile command (as echoed by make) directly from the command line. I only see it happen when compiling via make. Hm, that is indeed odd. Also odd is that here, I only get errors building this if I set my ulimit below 128 *kilo*bytes. gcc (GCC) 4.4.0 20090506 (Red Hat 4.4.0-4) To generate the backtrace, I added the following lines near the top of guile-tools. Is there a better way? (debug-enable 'debug) (debug-enable 'backtrace) (debug-set! depth 100) (write (debug-options-interface)) (newline) No, this is the best way we have currently. As I understand it, the debugging evaluator is slower than the normal one -- but at this point, who cares? With the VM we are already faster and we keep backtraces. We should have backtraces on, always. Does anyone have objections to that? If not, I'll make that change within the week. GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o language/ecmascript/spec.go language/ecmascript/spec.scm (show-file-name #t stack 4 debug backtrace depth 100 maxdepth 1000 frames 3 indent 10 width 79 procnames cheap) Backtrace: In ice-9/psyntax-pp.scm: 20: 271 [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 5: 272 [# core-form # # ...] In unknown file: ?: 273* [map #program 4060aa30 at ice-9/psyntax-pp.scm:4:2061 (x415) ((# . #))] Hmmm. I'll poke some options. Thanks for the BT. Andy -- http://wingolog.org/
Re: (debug-options 'full) is broken
On Tue 09 Jun 2009 21:27, Mark H Weaver m...@netris.org writes: According to node User level options interfaces of api-options.texi, (debug-options 'full) should print a list of options, but it fails with ERROR: unbound variable: option-name. The other options interfaces (eval-options, read-options, print-options, traps) are broken as well. The problem is here, in boot-9.scm: (defmacro define-option-interface (option-group) (let* ((option-name car) (option-value cadr) (option-documentation caddr) ;; Below follow the macros defining the run-time option interfaces. (make-options (lambda (interface) `(lambda args (cond ((null? args) (,interface)) ((list? (car args)) (,interface (car args)) (,interface)) (else (for-each (lambda (option) (display (option-name option)) (if ( (string-length (symbol-string (option-name option))) 8) (display #\tab)) (display #\tab) (display (option-value option)) (display #\tab) (display (option-documentation option)) (newline)) (,interface #t))) [...etc...] How was this supposed to work? How were the local bindings of option-name, option-value, and option-documentation supposed to be referenced from within the expansion of this non-hygienic macro? Umm... Oops :) See, these things used to be memoizing macros, the thing that Guile's old defmacros were built on. I translated them to defmacros, but, um, not very well, apparently ;-) I'll see if I can push a fix. BTW I pushed something that might affect the stack overflow issue, can you give that a try? I have one report of it working where it didn't use to work. Cheers, Andy -- http://wingolog.org/
Re: Emacs Lisp revived
Howdy, On Tue 09 Jun 2009 22:07, Daniel Kraft d...@domob.eu writes: I finally started real work on implementing the elisp compiler and just pushed a first start-off code to branch elisp. It is however not yet usable for anything, but also already has some very few things done. Yay!! I hope to have time to look at your branch soon :) 1) In implementing all those special forms like progn, prog1, if, while, ... I think it is best to translate a basic set directly to TreeIL via the compiler, but also implement some (where that's reasonably possible) simply as elisp macros (or even some things as functions). What do you think about this plan? A core should compile to tree-il, and then you should be able to build the rest with macros. What fun, no? :) 2) It seems that elisp uses nil as false value (and does not have a dedicated false); so the question raises, should be then always use #f for nil, or maybe TreeIL's void? Don't use void. You should use Guile's %nil, and we should have a make-nil instruction. %nil was added to Guile for precisely this purpose. tree-il@(guile-user) (if (void) (const 1) (const 2)) Oh yes, (void) is true indeed. (I'm happy you're using the tree-il repl btw, that's nice :) Not related, but I came across it: (if (begin) 1 2) gives an error, don't know if that's expected. Yes, it is an error. Surprising to me when I found that out, but even R5RS prohibits it. 3) I still haven't got building lexical constructs in TreeIL working (and I figure that named-lets for compiling the while-construct are even more interesting), but will hopefully manage to do so soon... Ooh, sorry for not getting back to you about that. I'm sleepy now though ;) Here's some examples: scheme@(guile-user) (use-modules (language tree-il)) scheme@(guile-user) (unparse-tree-il (compile '(let ((x 10)) (+ x x)) #:to 'tree-il)) $3 = (let (x) (x33) ((const 10)) (apply (toplevel +) (lexical x x33) (lexical x x33))) scheme@(guile-user) (unparse-tree-il (compile '(let ((x 10)) (+ x x)) #:to 'tree-il)) $4 = (let (x) (x34) ((const 10)) (apply (toplevel +) (lexical x x34) (lexical x x34))) scheme@(guile-user) (unparse-tree-il (compile '(let ((x 10)) (+ x x)) #:to 'tree-il)) $5 = (let (x) (x35) ((const 10)) (apply (toplevel +) (lexical x x35) (lexical x x35))) scheme@(guile-user) (compile '(let ((x 10)) (+ x x)) #:to 'tree-il) $6 = #let src: #f names: (x) vars: (x36) vals: (#const src: #f exp: 10) body: #application src: #f proc: #toplevel-ref src: #f name: + args: (#lexical-ref src: #f name: x gensym: x36 #lexical-ref src: #f name: x gensym: x36) You see what changes and what does not? The gensyms are fresh names for the lexically bound vars. They are introduced in the binding constructs and included in the references. You can make a gensym with the `gensym' procedure. Happy hacking! Andy -- http://wingolog.org/
Re: autocompilation support in master
Andy Wingo wi...@pobox.com wrote: BTW I pushed something that might affect the stack overflow issue, can you give that a try? I have one report of it working where it didn't use to work. It still overflows the stack on my system, but since you changed the order of compilation, it now fails on a different file. This with commit 9ea12179fa8e1ba12cde4a10c35504a80012. I also removed the (debug-enable 'debug), so the backtrace looks a little different. Mark GUILE_AUTO_COMPILE=0 ../meta/uninstalled-env guile-tools compile -o language/ecmascript/compile-ghil.go language/ecmascript/compile-ghil.scm Backtrace: In ice-9/psyntax-pp.scm: 5842: 44* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 45* [# () # ()] In ice-9/psyntax-pp.scm: 782: 46 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 47* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 48* [# () # ()] In ice-9/psyntax-pp.scm: 782: 49 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 50* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 51* [# () # ()] In ice-9/psyntax-pp.scm: 782: 52 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 53* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 54* [# () # ()] In ice-9/psyntax-pp.scm: 782: 55 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 56* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 57* [# () # ()] In ice-9/psyntax-pp.scm: 782: 58 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 59* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 60* [# () # ()] In ice-9/psyntax-pp.scm: 782: 61 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 62* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 63* [# () # ()] In ice-9/psyntax-pp.scm: 782: 64 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 65* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 66* [# () # ()] In ice-9/psyntax-pp.scm: 782: 67 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 68* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 69* [# () # ()] In ice-9/psyntax-pp.scm: 782: 70 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 71* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 72* [# () # ()] In ice-9/psyntax-pp.scm: 782: 73 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 74* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 75* [# () # ()] In ice-9/psyntax-pp.scm: 782: 76 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 77* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 78* [# () # ()] In ice-9/psyntax-pp.scm: 782: 79 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 80* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 81* [# () # ()] In ice-9/psyntax-pp.scm: 782: 82 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 83* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 84* [# () # ()] In ice-9/psyntax-pp.scm: 782: 85 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 86* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 87* [# () # ()] In ice-9/psyntax-pp.scm: 782: 88 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 89* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 90* [# () # ()] In ice-9/psyntax-pp.scm: 782: 91 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 92* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 93* [# () # ()] In ice-9/psyntax-pp.scm: 782: 94 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 95* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 96* [# () # ()] In ice-9/psyntax-pp.scm: 782: 97 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 98* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 99* [# () # ()] In ice-9/psyntax-pp.scm: 782: 100 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 101* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 102* [# () # ()] In ice-9/psyntax-pp.scm: 782: 103 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 104* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 105* [# () # ()] In ice-9/psyntax-pp.scm: 782: 106 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 107* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 108* [# () # ()] In ice-9/psyntax-pp.scm: 782: 109 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 110* [chi-let1039 (# # #) (# # # # ...) (()) ...] In ice-9/psyntax-pp.scm: 535: 111* [# () # ()] In ice-9/psyntax-pp.scm: 782: 112 [# core-form # # ...] In ice-9/psyntax-pp.scm: 5842: 113* [chi-let1039 (# # #) (# # # #
Re: autocompilation support in master
Earlier, I wrote: Strangely, the stack overflow doesn't happen when I run the compile command (as echoed by make) directly from the command line. I only see it happen when compiling via make. I just noticed something. Look at the result of (debug-options) in the first backtrace I sent: (show-file-name #t stack 4 debug backtrace depth 100 maxdepth 1000 frames 3 indent 10 width 79 procnames cheap) Notice the stack 4, which means that the stack limit (as far as guile is concerned) is only 4 words, i.e. 160 kilobytes. Other times, I see much larger numbers there, which are close to the actual stack resource limit (as set by setrlimit), and in those cases the stack doesn't overflow. I'm not able to reliably reproduce these problems, but it seems that the problem is not in the compiler, but in the code that initializes guile's internal notion of its stack limit. Indeed, I'm able to compile the ecmascript code with a 512 kilobyte stack, as long as guile doesn't get confused about its stack limit. Mark
Re: autocompilation support in master
I wrote: (show-file-name #t stack 4 debug backtrace depth 100 maxdepth 1000 frames 3 indent 10 width 79 procnames cheap) Notice the stack 4, which means that the stack limit (as far as guile is concerned) is only 4 words, i.e. 160 kilobytes. Other times, I see much larger numbers there, which are close to the actual stack resource limit (as set by setrlimit), and in those cases the stack doesn't overflow. It turns out that 4 is the initial value of guile's internal stack limit, as part of the definition of scm_debug_opts[] in eval.c. That value is supposed to be overwritten by init_stack_limit() in debug.c, but it will be left unchanged if getrlimit() fails, or if both the hard and soft stack limits are set to infinity. I suggest increasing the initial value of 4 to something more reasonable, perhaps 128000 words (which is approximately what my system needs to successfully compile the ecmascript code), and printing an error message if getrlimit fails. Mark
Re: autocompilation support in master
Apologies for sending so many emails in so short a time, but I've put together the final pieces of this puzzle. GNU Make 3.81, the version in Debian lenny, sets the stack soft limit to match the hard limit so that alloca does not fail. On my system, the default stack hard limit is infinite, so Make sets the soft limit to be infinite as well. When both the hard and soft limits are infinite, Guile's init_stack_limit() function in debug.c leaves the internal stack limit at the initial value of 4 words, i.e. 160 kilobytes, as set in eval.c. On my system, I need somewhere between 384-512 kilobytes to compile the ecmascript code. 512k succeeds, and 384k fails. That's all. Time for sleep now :) Mark I wrote: (show-file-name #t stack 4 debug backtrace depth 100 maxdepth 1000 frames 3 indent 10 width 79 procnames cheap) Notice the stack 4, which means that the stack limit (as far as guile is concerned) is only 4 words, i.e. 160 kilobytes. Other times, I see much larger numbers there, which are close to the actual stack resource limit (as set by setrlimit), and in those cases the stack doesn't overflow. It turns out that 4 is the initial value of guile's internal stack limit, as part of the definition of scm_debug_opts[] in eval.c. That value is supposed to be overwritten by init_stack_limit() in debug.c, but it will be left unchanged if getrlimit() fails, or if both the hard and soft stack limits are set to infinity. I suggest increasing the initial value of 4 to something more reasonable, perhaps 128000 words (which is approximately what my system needs to successfully compile the ecmascript code), and printing an error message if getrlimit fails. Mark
