Two things to say.
First, you've said INLINE for both functions. GHC understands that as saying
replace a call to this function by the RHS that I'm writing right here. So
GHC doesn't optimise them much, if at all. It waits until it sees a call, then
inlines, then optimises *that*. So try
On 26 March 2005 09:59, MR wrote:
Hi, I get the following error when i run ghci:
[EMAIL PROTECTED]:/mnt/windows/d/Programming/Software$ ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.2.2, for
Haskell 98. / /_\\/ __ / /___| |
Question to the bosses: should I rename HsReadline.c to
HsReadline_cbits.c by cvs-removing it and then cvs-adding it?
Do I just have to do that separately for the HEAD and STABLE branches?
Yes, and yes.
Cheers,
Simon
___
[orff:tools/hc/dev] atze% ghci -package data
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.0, for Haskell
98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\/\/ /_/\/|_| Type :? for help.
Loading package base ... linking
Hi,
the bug fixer may have contacted you separately, but for
the benefit of the mailing list and/or you, this one has now
been fixed (i.e., deriving empty datatypes is not permitted).
Thanks for reporting it.
--sigbjorn
- Original Message -
From: Hal Daume III [EMAIL PROTECTED]
To:
Simon Marlow wrote:
A strange bug indeed, but what brings you to this conclusion?
Because
(1) I hacked the *.S code that start STG execution to call
printf after each instruction, and the allocate stack
space *instruction* caused the problem.
You mean this one:
You mean this one:
subl $RESERVED_C_STACK_BYTES + 4*SIZEOF_LONG,%esp
subracting from %esp caused the program to exit? Surely not!
Specifically, anything after the subl large number,%esp
did not happen. Perhaps causing an uncaught page fault?
(I dont think that the subl
Bug (1): A totally clean, top of the CVS tree does not work on NT 4.0.
Behavior: returns with no result, any program.
Strange: Adding '+RTS -s' makes things work fine.
I think that there is not enough stack space on the C stack,
and the "change %esp register is failing us". The alloca
Simon Marlow wrote:
Bug (1): A totally clean, top of the CVS tree does not work on NT 4.0.
Behavior: returns with no result, any program.
Strange: Adding '+RTS -s' makes things work fine.
I think that there is not enough stack space on the C stack,
and the "change %esp register is
