RE: type-inference (version 6.4.20050222) and behaviour of :i

2005-03-07 Thread Simon Marlow
On 06 March 2005 08:49, Daniel Fischer wrote:

 while looking at Greg Buchholz's Joy-combinators (haskell-cafe,
 Friday), I discovered that the type inference of version 6.4.2005.022
 didn't work correctly. The code and comments indicating the
 incorrectly inferred types are attached (Joy2.hs).
 However, the implementation doesn't adhere strictly to the wrongly
 inferred types, e.g.
 
 *Joy2 linrec (id, (id, (id, ((pop ! lit True), (3,(2,1))
 (3,(2,1))
 *Joy2 :t pop ! lit True
 pop ! lit True :: (a, b) - (Bool, b)
 *Joy2 :t linrec
 linrec :: (t - t, (b - b, (b - t, (b - (Bool, b), b - t,
 
 so it might well be that only the display of the inferred type is
 incorrect. 
 
 As for the behaviour of :i,
 in version 6.2.2, default methods for classes were indicated, which I
 find a good idea, in 6.4.20050222 this is not so.
 Further, Hugs gives more instances, e.g. for
 i Show,
 which may (or may not) be due to different exports from the Prelude,
 more serious is that version 6.4.20050222 doesn't give the contexts,
 which is bad if one defines an instance like
 
 instance (Ord a, Num a) = MyClass a where . . .,
 
 when
 i MyClass gives
 
 instance MyClass a.
 
 Maybe, this has already been taken care of, I will today install
 version 
 6.4.20050304 and see.

I believe this is fixed; please test a later version and let us know.

Cheers,
Simon
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


[ ghc-Bugs-1107398 ] internal error: getMBlock: mmap: Invalid argument

2005-03-07 Thread SourceForge.net
Bugs item #1107398, was opened at 2005-01-22 17:41
Message generated for change (Comment added) made by simonmar
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=108032aid=1107398group_id=8032

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Gour (ggd)
Assigned to: Simon Marlow (simonmar)
Summary: internal error: getMBlock: mmap: Invalid argument 

Initial Comment:
In an attempt to compile latest HaRe snapshot on amd64 platform 
(ghc-6.2.2, happy-1.15) I get the following error: 
 
[EMAIL PROTECTED] ~/projects/haskell/hare $ make  
cp -r diffs/tools/* tools  
mkdir -p refactorer/hidir/`uname`  
mkdir -p refactorer/odir/`uname`  
cd editors; ./localpaths HaRe 03/12/2004  
cd editors; ghc --make -fglasgow-exts GenEditorInterfaces -o  
GenEditorInterfaces  
Chasing modules from: GenEditorInterfaces  
Compiling LocalSettings( ./LocalSettings.hs, ./LocalSettings.o )  
ghc-6.2.2: internal error: getMBlock: mmap: Invalid argument  
Please report this as a bug to glasgow-haskell-bugs@haskell.org,  
or http://www.sourceforge.net/projects/ghc/  
make: *** [editors/GenEditorInterfaces] Error 254  
 
 
Sincerely, 
Gour 
  

--

Comment By: Simon Marlow (simonmar)
Date: 2005-03-07 16:26

Message:
Logged In: YES 
user_id=48280

This is most likely due to an interface file from a build on
a 32-bit machine left over in your source tree.

I've fixed GHC so that this will generate a nice error
message rather than a crash in the future.

--

Comment By: Gour (ggd)
Date: 2005-01-31 14:22

Message:
Logged In: YES 
user_id=728695

I'll take this one, but  I can't look at it just yet (x86_64 
hardware still on the way...) 
 
Maybe I should start praying to arrive sooner :-) 
 
Sincerely, 
Gour 
 

--

Comment By: Simon Marlow (simonmar)
Date: 2005-01-31 14:04

Message:
Logged In: YES 
user_id=48280

I'll take this one, but  I can't look at it just yet (x86_64
hardware still on the way...)

--

Comment By: Jens-Ulrik Petersen (juhp)
Date: 2005-01-26 08:15

Message:
Logged In: YES 
user_id=139853

I see this error with 6.3.20050125 on x86_64 too
when compiling Hello.hs.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detailatid=108032aid=1107398group_id=8032
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


RE: 6.4.20050304 RULES panic from CgMonad.lhs other nastiness

2005-03-07 Thread Simon Peyton-Jones
Excellent bug.  It's been there a long time.   You seem to have a talent
for finding dark corners in GHC!

Anyway, it's fixed, and a test added.

SImon

| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Remi Turk
| Sent: 07 March 2005 00:41
| To: glasgow-haskell-bugs@haskell.org
| Subject: 6.4.20050304 RULES panic from CgMonad.lhs  other nastiness
| 
| Hi,
| 
| while still trying to get Data.HashTable to work both in ST and
| IO (I'll probably start complaining about optimizations not
| performed once this is fixed ;), I bumped into the following
| nastiness.
| 
| Comments interleaved with shell copy-paste-work.
| 
| 
|% make clean
|rm -f *.o *.hi a.out
| 
| 
|% /var/tmp/ghc/bin/ghc --make -O Main.hs
|Chasing modules from: Main.hs
|Compiling MHashTable   ( ./MHashTable.hs, ./MHashTable.o )
|Compiling Main ( Main.hs, Main.o )
|ghc-6.4.20050304: panic! (the `impossible' happened, GHC version
6.4.20050304):
|   cgPanic
|zdfMutHashSTArray{v a1ip}
|static binds for:
|local binds for:
|SRT labelghc-6.4.20050304: panic! (the `impossible' happened,
GHC version 6.4.20050304):
|   initC: srt
| 
| Okay, it dies. Almost any new change in the source makes this one
| go away. The next panic is probably partly a consequence of this
| one: MHashTable.o already exists and GHC can't cope with that for
| some reason. That reason may of course be that MHashTable.o
| contains garbage due to the previous bug.
| 
| 
|% /var/tmp/ghc/bin/ghc --make -O Main.hs
|Chasing modules from: Main.hs
|Skipping  MHashTable   ( ./MHashTable.hs, ./MHashTable.o )
|ghc-6.4.20050304: panic! (the `impossible' happened, GHC version
6.4.20050304):
|   tcIfaceGlobal (local): not found:
|MHashTable.updateST{v r87}
|[(rr, Identifier `MHashTable.zdfMutHashSTArray{v rr}'),
| (rs, Type constructor `MHashTable.HT{tc rs}'),
| (rt, Identifier `MHashTable.dir{v rt}'),
| (ru, Data constructor `MHashTable.HT{d ru}'),
| (rv, Identifier `MHashTable.HT{v rv}'),
| (rw, Type constructor `MHashTable.HashTable{tc rw}'),
| (rx, Data constructor `MHashTable.HashTable{d rx}'),
| (ry, Identifier `MHashTable.zdWHashTable{v ry}'),
| (rz, Type constructor `MHashTable.STHashTable{tc rz}'),
| (rA, Class `MHashTable.MutHash{tc rA}'),
| (rB, Type constructor `MHashTable.ZCTMutHash{tc rB}'),
| (rC, Data constructor `MHashTable.ZCDMutHash{d rC}'),
| (rD, Identifier `MHashTable.ZCDMutHash{v rD}'),
| (rE, Identifier `MHashTable.newMHArray{v rE}'),
| (rF, Identifier `MHashTable.readMHArray{v rF}'),
| (rG, Identifier `MHashTable.writeMHArray{v rG}'),
| (rH, Identifier `MHashTable.newMHRef{v rH}'),
| (rI, Identifier `MHashTable.readMHRef{v rI}'),
| (rJ, Identifier `MHashTable.writeMHRef{v rJ}'),
| (rK, Identifier `MHashTable.zdp1MutHash{v rK}'),
| (rL, Identifier `MHashTable.new{v rL}'),
| (rM, Identifier `MHashTable.update{v rM}'),
| (rN, Identifier `MHashTable.zdwpolyzuwriteMHArray{v rN}'),
| (rO, Identifier `MHashTable.polyzuwriteMHArray{v rO}'),
| (rP, Identifier `MHashTable.lit{v rP}'),
| (rQ, Identifier `MHashTable.lvl{v rQ}'),
| (rR, Identifier `MHashTable.zdwnew{v rR}')]
| 
| 
|% make clean
|rm -f *.o *.hi a.out
| 
| Removing all generated files: A Fresh Start with another
| definition of new (see attachment):
| 
| 
|% /var/tmp/ghc/bin/ghc --make -Dnew_undef -no-recomp -O Main.hs
|Chasing modules from: Main.hs
|Compiling MHashTable   ( ./MHashTable.hs, ./MHashTable.o )
|Compiling Main ( Main.hs, Main.o )
|Linking ...
|Main.o(.text+0x57): undefined reference to
`MHashTable_updateST_closure'
|Main.o(.rodata+0x0): undefined reference to
`MHashTable_updateST_closure'
|collect2: ld returned 1 exit status
| 
| 
| Finally, executing the previous command again gives _another_
| error, which is rather weird given that -no-recomp is given...
| 
| 
|% /var/tmp/ghc/bin/ghc --make -Dnew_undef -no-recomp -O Main.hs
|Chasing modules from: Main.hs
|Compiling MHashTable   ( ./MHashTable.hs, ./MHashTable.o )
|Compiling Main ( Main.hs, Main.o )
|ghc-6.4.20050304: panic! (the `impossible' happened, GHC version
6.4.20050304):
|   lookupVers1 MHashTable updateST{v}
| 
| Good night,
| Remi
| 
| --
| Nobody can be exactly like me. Even I have trouble doing it.
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs


Re: 6.4.20050304 RULES panic from CgMonad.lhs other nastiness

2005-03-07 Thread Remi Turk
On Mon, Mar 07, 2005 at 05:07:05PM -, Simon Peyton-Jones wrote:
 Excellent bug.  It's been there a long time.   You seem to have a talent
 for finding dark corners in GHC!
 
 Anyway, it's fixed, and a test added.
 
 SImon

I'll probably build a new release candidate tomorrow, so stay
tuned ;)
One question though: MHashTable.hs (simpl011.hs) itself builds ok
(well, doesn't crash), it's only when Main.hs imports  uses it
that GHC dies, so will
testsuite/tests/ghc-regress/simplCore/should_compile/simpl011.hs
actually catch the bug?

Cheers,
Remi

 | -Original Message-
 | From: [EMAIL PROTECTED]
 [mailto:glasgow-haskell-bugs-
 | [EMAIL PROTECTED] On Behalf Of Remi Turk
 | Sent: 07 March 2005 00:41
 | To: glasgow-haskell-bugs@haskell.org
 | Subject: 6.4.20050304 RULES panic from CgMonad.lhs  other nastiness
 | 
 | Hi,
 | 
 | while still trying to get Data.HashTable to work both in ST and
 | IO (I'll probably start complaining about optimizations not
 | performed once this is fixed ;), I bumped into the following
 | nastiness.
 | 
 | Comments interleaved with shell copy-paste-work.
 | 
 | 
 |% make clean
 |rm -f *.o *.hi a.out
 | 
 | 
 |% /var/tmp/ghc/bin/ghc --make -O Main.hs
 |Chasing modules from: Main.hs
 |Compiling MHashTable   ( ./MHashTable.hs, ./MHashTable.o )
 |Compiling Main ( Main.hs, Main.o )
 |ghc-6.4.20050304: panic! (the `impossible' happened, GHC version
 6.4.20050304):
 | cgPanic
 |zdfMutHashSTArray{v a1ip}
 |static binds for:
 |local binds for:
 |SRT labelghc-6.4.20050304: panic! (the `impossible' happened,
 GHC version 6.4.20050304):
 | initC: srt
 | 
 | Okay, it dies. Almost any new change in the source makes this one
 | go away. The next panic is probably partly a consequence of this
 | one: MHashTable.o already exists and GHC can't cope with that for
 | some reason. That reason may of course be that MHashTable.o
 | contains garbage due to the previous bug.
 | 
 | 
 |% /var/tmp/ghc/bin/ghc --make -O Main.hs
 |Chasing modules from: Main.hs
 |Skipping  MHashTable   ( ./MHashTable.hs, ./MHashTable.o )
 |ghc-6.4.20050304: panic! (the `impossible' happened, GHC version
 6.4.20050304):
 | tcIfaceGlobal (local): not found:
 |MHashTable.updateST{v r87}
 |[(rr, Identifier `MHashTable.zdfMutHashSTArray{v rr}'),
 | (rs, Type constructor `MHashTable.HT{tc rs}'),
 | (rt, Identifier `MHashTable.dir{v rt}'),
 | (ru, Data constructor `MHashTable.HT{d ru}'),
 | (rv, Identifier `MHashTable.HT{v rv}'),
 | (rw, Type constructor `MHashTable.HashTable{tc rw}'),
 | (rx, Data constructor `MHashTable.HashTable{d rx}'),
 | (ry, Identifier `MHashTable.zdWHashTable{v ry}'),
 | (rz, Type constructor `MHashTable.STHashTable{tc rz}'),
 | (rA, Class `MHashTable.MutHash{tc rA}'),
 | (rB, Type constructor `MHashTable.ZCTMutHash{tc rB}'),
 | (rC, Data constructor `MHashTable.ZCDMutHash{d rC}'),
 | (rD, Identifier `MHashTable.ZCDMutHash{v rD}'),
 | (rE, Identifier `MHashTable.newMHArray{v rE}'),
 | (rF, Identifier `MHashTable.readMHArray{v rF}'),
 | (rG, Identifier `MHashTable.writeMHArray{v rG}'),
 | (rH, Identifier `MHashTable.newMHRef{v rH}'),
 | (rI, Identifier `MHashTable.readMHRef{v rI}'),
 | (rJ, Identifier `MHashTable.writeMHRef{v rJ}'),
 | (rK, Identifier `MHashTable.zdp1MutHash{v rK}'),
 | (rL, Identifier `MHashTable.new{v rL}'),
 | (rM, Identifier `MHashTable.update{v rM}'),
 | (rN, Identifier `MHashTable.zdwpolyzuwriteMHArray{v rN}'),
 | (rO, Identifier `MHashTable.polyzuwriteMHArray{v rO}'),
 | (rP, Identifier `MHashTable.lit{v rP}'),
 | (rQ, Identifier `MHashTable.lvl{v rQ}'),
 | (rR, Identifier `MHashTable.zdwnew{v rR}')]
 | 
 | 
 |% make clean
 |rm -f *.o *.hi a.out
 | 
 | Removing all generated files: A Fresh Start with another
 | definition of new (see attachment):
 | 
 | 
 |% /var/tmp/ghc/bin/ghc --make -Dnew_undef -no-recomp -O Main.hs
 |Chasing modules from: Main.hs
 |Compiling MHashTable   ( ./MHashTable.hs, ./MHashTable.o )
 |Compiling Main ( Main.hs, Main.o )
 |Linking ...
 |Main.o(.text+0x57): undefined reference to
 `MHashTable_updateST_closure'
 |Main.o(.rodata+0x0): undefined reference to
 `MHashTable_updateST_closure'
 |collect2: ld returned 1 exit status
 | 
 | 
 | Finally, executing the previous command again gives _another_
 | error, which is rather weird given that -no-recomp is given...
 | 
 | 
 |% /var/tmp/ghc/bin/ghc --make -Dnew_undef -no-recomp -O Main.hs
 |Chasing modules from: Main.hs
 |Compiling MHashTable   ( ./MHashTable.hs, ./MHashTable.o )
 |Compiling Main ( Main.hs, Main.o )
 |ghc-6.4.20050304: panic! (the `impossible' happened, GHC version