Mon Aug 13 19:56:30 PDT 2007 Roman Leshchinskiy <[EMAIL PROTECTED]>
* Another indexed types testcase
It exhibits a regression in the type functions patch.
A ./tests/ghc-regress/indexed-types/should_compile/Class2.hs
M ./tests/ghc-regress/indexed-types/should_compile/all.T +1
_
Hi
I have downloaded, build, and installed GHC. When I do:
ghci
it works fine. Bug when I do:
ghci -package hpc
I get:
GHCi, version 6.7.20070812: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Loading package old-locale-1.0 ... linking ... done.
Build description = HEAD on i386-unknown-linux
(cam-02-unx.europe.corp.microsoft.com)
Build location= /playpen/ghc/nightly/HEAD-cam-02-unx
Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx
Nightly build started on cam-02-unx at Mon Aug 13 19:30:00 BST 2007.
checki
On Mon, Aug 13, 2007 at 12:30:55PM -0300, Isaac Dupree wrote:
> Isaac Dupree wrote:
>> Stefan O'Rear wrote:
>>> You patched GHC, so the version number (which is extracted from darcs)
>>> automatically went up. GHC assumes (incorrectly) that this broke the
>>> interface format, and is trying to sto
Isaac Dupree wrote:
Stefan O'Rear wrote:
You patched GHC, so the version number (which is extracted from darcs)
automatically went up. GHC assumes (incorrectly) that this broke the
interface format, and is trying to stop you from shooting yourself in
the foot.
But this was from a clean checko
Stefan O'Rear wrote:
You patched GHC, so the version number (which is extracted from darcs)
automatically went up. GHC assumes (incorrectly) that this broke the
interface format, and is trying to stop you from shooting yourself in
the foot.
But this was from a clean checkout that only containe
Stefan O'Rear wrote:
You patched GHC, so the version number (which is extracted from darcs)
automatically went up. GHC assumes (incorrectly) that this broke the
interface format, and is trying to stop you from shooting yourself in
the foot.
But this was from a clean checkout that only containe
Isaac Dupree wrote:
with my hacky patches
it looks to me like they should produce exactly the same behavior as the
current version, except I changed getFastStringTable to equal undefined...
Isaac
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http:/
On Mon, Aug 13, 2007 at 12:11:13PM -0300, Isaac Dupree wrote:
> Currently FastString uses a custom-made hash table for their construction.
> I wanted to see how performance compared, using a binary search tree
> instead. Using FiniteMap made a module import loop that was hard to
> resolve, so
Currently FastString uses a custom-made hash table for their
construction. I wanted to see how performance compared, using a binary
search tree instead. Using FiniteMap made a module import loop that was
hard to resolve, so I switched to Data.Map for testing (I know it's only
available since ghc
Currently FastString uses a custom-made hash table for their
construction. I wanted to see how performance compared, using a binary
search tree instead. Using FiniteMap made a module import loop that was
hard to resolve, so I switched to Data.Map for testing (I know it's only
available since
Ian Lynagh wrote:
Hi Roman,
On Mon, Aug 13, 2007 at 02:15:48PM +1000, Roman Leshchinskiy wrote:
when forking. With the current HEAD on OS X, I get a lot of testsuite
failures of the following form:
Compile failed (status 256) errors were:
i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual
Hi Roman,
On Mon, Aug 13, 2007 at 02:15:48PM +1000, Roman Leshchinskiy wrote:
> when forking. With the current HEAD on OS X, I get a lot of testsuite
> failures of the following form:
>
> Compile failed (status 256) errors were:
> i686-apple-darwin8-gcc-4.0.1: Internal error: Virtual timer expi
13 matches
Mail list logo
