At the risk of charging in like an entire stampede of cluelessness,
Quoting Matthew Flatt mfl...@cs.utah.edu:
At Thu, 12 Jul 2012 11:25:44 +0900, Alex Shinn wrote:
I disagree - I think a stack grown too large is likely indicative
of a programming error, or at the very least an inefficient
Hallo,
On Thu, Jul 12, 2012 at 4:25 AM, Alex Shinn alexsh...@gmail.com wrote:
I disagree - I think a stack grown too large is likely indicative
of a programming error, or at the very least an inefficient
algorithm. In the general case I want my programs to be
able to allocate as much heap
On Thu, Jul 12, 2012 at 4:39 PM, Alex Queiroz asand...@gmail.com wrote:
Hallo,
On Thu, Jul 12, 2012 at 4:25 AM, Alex Shinn alexsh...@gmail.com wrote:
I disagree - I think a stack grown too large is likely indicative
of a programming error, or at the very least an inefficient
algorithm. In
On Thu, Jul 12, 2012 at 9:47 AM, Alex Shinn alexsh...@gmail.com wrote:
Wow, if you've got a magical Scheme compiler that
can read my mind and fix all my bugs for me I'll switch
right now! :)
Are you really saying that it is ok for a Scheme program to crash
with a segmentation fault
On Thu, Jul 12, 2012 at 4:51 PM, Alex Queiroz asand...@gmail.com wrote:
On Thu, Jul 12, 2012 at 9:47 AM, Alex Shinn alexsh...@gmail.com wrote:
Wow, if you've got a magical Scheme compiler that
can read my mind and fix all my bugs for me I'll switch
right now! :)
Are you really saying
I have been experimenting with the Spock Scheme to JavaScript compiler. I
encountered a bug in its implementation of the Cheney on the MTA approach to
tail-calls and continuations. The bug also exists for Chicken.
In the Cheney on the MTA approach there needs to be a check, at regular
Marc Feeley scripsit:
In this example, there will be an arbitrarily long sequence of C calls
(in the unwinding of the recursion to even) with no Scheme call, so
stack size checks will not be performed during the unwinding, yet the
C stack grows during the unwinding. There is no stack
It seems that compiling with clang (llvm 3.0)
prevents the crash, at least for values up to 20 million, on
OS X and Linux. Any higher and I start to hit swap.
I don't know why this works.
Plain gcc on linux, and llvm-gcc (llvm 2.7) on OS X 10.7, do crash
at about 600k here w/ stack ulimit 8M.
On 2012-07-11, at 2:31 PM, John Cowan wrote:
Marc Feeley scripsit:
In this example, there will be an arbitrarily long sequence of C calls
(in the unwinding of the recursion to even) with no Scheme call, so
stack size checks will not be performed during the unwinding, yet the
C stack grows
On 2012-07-11, at 3:44 PM, Jim Ursetto wrote:
It seems that compiling with clang (llvm 3.0)
prevents the crash, at least for values up to 20 million, on
OS X and Linux. Any higher and I start to hit swap.
I don't know why this works.
Plain gcc on linux, and llvm-gcc (llvm 2.7) on OS X
On 2012-07-11, at 2:31 PM, John Cowan wrote:
Marc Feeley scripsit:
In this example, there will be an arbitrarily long sequence of C calls
(in the unwinding of the recursion to even) with no Scheme call, so
stack size checks will not be performed during the unwinding, yet the
C stack grows
On Jul 11, 2012, at 2:47 PM, Marc Feeley wrote:
I'm pretty sure LLVM is simply implementing the tail-call itself. So there
is no stack growth in the unwinding phase.
That is possible. We do currently disable __attribute__((noreturn))
on functions across the board when using clang, and last
or not, though.
--shiro
From: John Cowan co...@mercury.ccil.org
Subject: Re: [Chicken-users] Unbounded stack growth
Date: Wed, 11 Jul 2012 14:31:58 -0400
While you're right, it's not clear that this matters enough to fix.
It's not a *correctness* error, since every implementation will blow up
From: Marc Feeley fee...@iro.umontreal.ca
Subject: [Chicken-users] Unbounded stack growth
Date: Wed, 11 Jul 2012 13:23:30 -0400
I have been experimenting with the Spock Scheme to JavaScript compiler. I
encountered a bug in its implementation of the Cheney on the MTA approach to
tail-calls
Performance should not trump safety and correctness.
Absolutely right, yet everybody has a different perception of what
performance, safety and correctness means. Segfaulting on
_stack-overflow_ is not something that I'd call incorrect or unsafe
- I'd call it inconvenient and it may be the
On 2012-07-11, at 5:59 PM, Felix wrote:
Performance should not trump safety and correctness.
Absolutely right, yet everybody has a different perception of what
performance, safety and correctness means. Segfaulting on
_stack-overflow_ is not something that I'd call incorrect or unsafe
-
On Thu, Jul 12, 2012 at 10:52 AM, Marc Feeley fee...@iro.umontreal.ca wrote:
On 2012-07-11, at 5:59 PM, Felix wrote:
Performance should not trump safety and correctness.
Absolutely right, yet everybody has a different perception of what
performance, safety and correctness means.
17 matches
Mail list logo
