Compiling a module which imports the 14 smaller modules takes much
less time than compiling the monolithic module - it's almost 5 times
faster (see below).
We've found the cause of this, and committed a fix. The full
HTMLMonda98.hs now compiles in 27 seconds for me, without optimisation
On 10 August 2005 09:04, Frederik Eaton wrote:
Compiling a module which imports the 14 smaller modules takes much
less time than compiling the monolithic module - it's almost 5 times
faster (see below).
We've found the cause of this, and committed a fix. The full
HTMLMonda98.hs now
Hi, i have the following error when running my program
interactive: internal error: scavenge_one: strange object 47
Please report this as a bug to glasgow-haskell-bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
is this a compiler's bug or my program's ?
Gregory Wright [EMAIL PROTECTED] writes:
(snip)
the failure is
not related to what I am trying to build. It doesn't matter if I run
the same command,
runhaskell Setup.hs configure
in the haskell-src-exts subdirectory. The failure is the same.
The failure also occurs if I try to
On 09 August 2005 16:11, Niels wrote:
I'm triggering the bug that was first reported here
http://sourceforge.net/tracker/index.php
?func=detailatid=108032aid=935792group_id=8032
which was fixed in 6.2.1
im issuing the following ghc command:
'ghc -o out --make -main-is
On 09 August 2005 17:16, Simon Peyton-Jones wrote:
I'm not against this, although you can work around the problem by
adding a library that defines the missing type classes (Typeable8,
Typeable9 etc), and making your compiler generate the instance
itself. There is nothing magic about
Fixed, thanks!
Simon
On 09 August 2005 20:45, Adam Sampson wrote:
While writing a testcase for another bug (details to follow), I found
that System.Posix.IO.queryFdOption doesn't work.
The problem appears to be that queryFdOption uses testBit incorrectly;
it assumes the second argument is
On 09 August 2005 20:56, Adam Sampson wrote:
While tracking down a bug in Ginsu earlier, I found that the cause is
an unexpected side-effect of the System.Cmd functions: they set FD 0
(and consequently anything that it's been dupped to, so probably FD 1
and FD 2 as well) to non-blocking mode.
Bugs item #1248208, was opened at 2005-07-31 03:03
Message generated for change (Comment added) made by simonpj
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=1248208group_id=8032
Please note that this message will contain a full copy of the comment
Yes, you could I suppose. But then there'd be a different peculiar
change in behaviour at arity 7. I'm not sure that'd be an advantage.
Simon
| -Original Message-
| From: Simon Marlow
| Sent: 10 August 2005 10:58
| To: Simon Peyton-Jones; Frank Huch; glasgow-haskell-bugs@haskell.org
|
(I agree with the two Simons; just want to throw in a few more
considerations.)
Just curious ... What's the use case, Frank? (It is probably related to
debugging or assertion checking; do you have code details that you want
to share?) Do you *really* want to do type-case on those multi-arity
Hi and thanks for your discussion.
Our programs have (at the moment) nothing to do with debugging or
assertions.
We are implementing a Curry-to-Haskell-Compiler. Curry is a
functional-logic language, extending Haskell with needed narrowing
(efficient (lazy) search for free, logic variables).
Bugs item #635718, was opened at 2002-11-08 21:43
Message generated for change (Comment added) made by simonmar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=635718group_id=8032
Please note that this message will contain a full copy of the comment
Why do we set file descriptors to nonblocking mode anyway if they are
waited on by a select. there shouldn't be a need to use both mechanisms.
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Glasgow-haskell-bugs mailing list
14 matches
Mail list logo
