- Glasgow-haskell-users

Problems with 6.x compilers
by Michael Marte 22 Nov '05

22 Nov '05

Hello, I am having some annoying problems with the 6.x compilers: 6.4 and 6.4.1: When repeating a build (with ghc --make) all modules are rebuild even if nothing has changed. With earlier compilers, only linking takes place in this setting. Can I change this behaviour? I cannot develop this way. 6.2 and up: The object file is named after the module, not after the source file as in 5.04. As there are several main modules in my project, each in its own source file, all I get is a big mess. Any suggestions? Thank you, Michael

2 1

RE: GHC targetting Java?
by Simon Peyton-Jones 22 Nov '05

22 Nov '05

It was never fully functional, and is now seriously bit-rotted. But the vestiges are still there if anyone feels like resurrecting it. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of John Goerzen | Sent: 22 November 2005 16:43 | To: glasgow-haskell-users(a)haskell.org | Subject: GHC targetting Java? | | Hi, | | I just noticed the GhcWithJavaGen in mk/config.mk. It sounds | interesting and useful. I decided to switch it on and experiment, but: | | Could not find module `PrimRep': | use -v to see a list of the files searched for | (imported from javaGen/JavaGen.lhs) | | It seems that I'm missing some needed files. Any idea where I'd find | them? Any other reference on the Java target from GHC? | | (This is GHC 6.4.1) | | Thanks, | | -- John | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

GHC targetting Java?
by John Goerzen 22 Nov '05

22 Nov '05

Hi, I just noticed the GhcWithJavaGen in mk/config.mk. It sounds interesting and useful. I decided to switch it on and experiment, but: Could not find module `PrimRep': use -v to see a list of the files searched for (imported from javaGen/JavaGen.lhs) It seems that I'm missing some needed files. Any idea where I'd find them? Any other reference on the Java target from GHC? (This is GHC 6.4.1) Thanks, -- John

1 0

RE: Broken build
by Simon Peyton-Jones 22 Nov '05

22 Nov '05

I believe I have fixed this. (It was my fault, late last week.) I'm compiling now to test. Meanwhile it'd be worth your having another go. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Dinko Tenev | Sent: 20 November 2005 14:07 | To: glasgow-haskell-users(a)haskell.org | Subject: Broken build | | I updated from HEAD recently, and got some strange error messages | while building the stuff under libraries/X11: | | ../../ghc/compiler/ghc-inplace -H32m -O0 -W -fno-warn-unused-matches | -fwarn-unused-imports -cpp -fffi -Iinclude -I/usr/X11R6/include | -ignore-package X11 -O -dcore-lint -W -fno-warn-unused-matches | -fwarn-unused-imports -keep-hc-files -package base -fgenerics -c | Graphics/X11/Xlib/Font.hs -o Graphics/X11/Xlib/Font.o -ohi | Graphics/X11/Xlib/Font.hi | | Font.hsc:70:0: | Unacceptable argument type in foreign declaration: Display | When checking declaration: | foreign import ccall unsafe "static HsXlib.h &XQueryFont" queryFont :: Display | -> Font | -> IO FontStruct | | ...as well as several others for the same file, along the same lines. | | I am none the wiser by the messages, but the comment for | ghc/compiler/prelude/TysWiredIn.lhs#rev1.75 seems to be related. Is | this a regression? | | BTW, could someone give me a clue what the point is with a type like | the one mentioned? | | Regards, | Dinko | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

Patch: Add support for using --mk-dll with --make
by Esa Ilari Vuokko 21 Nov '05

21 Nov '05

Hi! Attached small simple patch that allows using --mk-dll with --make. Behaviour before patch was to link .exe instead .dll, as batchmode simply called staticLink - now doMkDLL is called instead. * Add support for using --mk-dll with --make I changed documentation a bit, and moved --mk-dll from 4.17.3 "Alternative modes of operation" into 4.17.21 "Linking options." This documentation change isn't tested, as I don't have necessary tools installed on my machine. But it *seems* harmless (and I think, more intuitive.) Due to lack of tools, and because there's little to say, I didn't touch 11.5. "Building and using Win32 DLLs." Patch should apply cleanly on cvs HEAD with patch -p0 under fptools. Any comments are welcome. Thanks in advance, --Esa

1 0

Patch for Word64
by Matt 21 Nov '05

21 Nov '05

I was doing some work with Word64 and noticed that it was about 3 times slower than Int64. The reason appears to be expensive conversions from Int64# to Word64# and vice versa. I modified the libraries to remove the conversion overhead, and the result is that Int64# and Word64# now have equal performance, at least on the domain that I tested (==, +, -). I can't check into the tree, so I was told to send my changes to this list. Could someone else check them in? I have attached a patch file representing my changes. -Matt or [ricebowl, wearkilts, soysauce] on #haskell on Freenode

2 1

Broken build
by Dinko Tenev 20 Nov '05

20 Nov '05

I updated from HEAD recently, and got some strange error messages while building the stuff under libraries/X11: ../../ghc/compiler/ghc-inplace -H32m -O0 -W -fno-warn-unused-matches -fwarn-unused-imports -cpp -fffi -Iinclude -I/usr/X11R6/include -ignore-package X11 -O -dcore-lint -W -fno-warn-unused-matches -fwarn-unused-imports -keep-hc-files -package base -fgenerics -c Graphics/X11/Xlib/Font.hs -o Graphics/X11/Xlib/Font.o -ohi Graphics/X11/Xlib/Font.hi Font.hsc:70:0: Unacceptable argument type in foreign declaration: Display When checking declaration: foreign import ccall unsafe "static HsXlib.h &XQueryFont" queryFont :: Display -> Font -> IO FontStruct ...as well as several others for the same file, along the same lines. I am none the wiser by the messages, but the comment for ghc/compiler/prelude/TysWiredIn.lhs#rev1.75 seems to be related. Is this a regression? BTW, could someone give me a clue what the point is with a type like the one mentioned? Regards, Dinko

1 0

RE: Compiling GHC in Windows, Mingw
by Simon Marlow 18 Nov '05

18 Nov '05

On 17 November 2005 21:37, Esa Ilari Vuokko wrote: > On 11/17/05, Esa Ilari Vuokko <eivuokko(a)gmail.com> wrote: >> I will start a new clean build, hope it goes away and I need to look >> into buying non-broken hardware... ;) > > The build failed and I sent mail about it on cvs-ghc list this time, > even if something seemed to rip away my message and just leave > attachmenent.. > > Anyway, I downloaded few nightly builds and it seems this happens > with 11-17 build as well, but not with 11-16, so it's really recent. I think I have just fixed this (modification to the mangler in ghc/driver/mangler), please try again. Cheers, Simon

2 2

RE: Confusing Typing Problem
by Simon Peyton-Jones 18 Nov '05

18 Nov '05

Tricky! It certainly is confusing, but that's the way Hindley-Milner type inference for mutually recursive functions works. The local-defn version works differently because it - assumes a monomorphic type for f - completely typechecks g, including generalisation - finishes typechecking f That could be done if one typechecked the original defns in the "right" order, but it's not clear what the right order is. You specified the order by choosing which defn to nest. The other way round won't work g _ = f where f = A g Specifying a type sig should fix the problem, and does. | > a throw-away comment specifying that all explicit type signatures | > in a binding group must have the same context up to renaming of | variables | > [10,Section 4.5.2]. This is a syntactic restriction that can easily | > be checked prior to type checking. Our comments here, however, suggest | > that it is unnecessarily restrictive. | | Why does ghc still use that unnecessary restriction? It doesn't any more. The HEAD lifts the restriction; that'll be in GHC 6.6. Meanwhile you could try a snapshot build from the download site. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Bernd Brassel | Sent: 18 November 2005 10:16 | To: glasgow-haskell-users(a)haskell.org | Subject: Confusing Typing Problem | | I am a bit confused by GHC behaviour for the following variants of a | program: | | data A = A (Int -> A) | | f = A g | | g _ = f | | h = g 'c' | | ghc: | > Error: | > Couldn't match `Int' against `Char' | | The problem is that a small change ommits the error: | data A = A (Int -> A) | | f = A g | where | g _ = f | | h = g 'c' | | ghc: | > Ok, modules loaded | | But I really need the functions to be top-level, thus I added type | signatures: | data A = A (Int -> A) | | f :: A | f = A g | | g :: a -> A | g _ = f | | h :: A | h = g 'c' | | ghc: | > Ok, modules loaded | | Fine, but what I really need, is this: | | data A = A (Int -> A) | | f :: A | f = A g | | g :: Ord a => a -> A | g _ = f | | h :: A | h = g 'c' | | > Contexts differ in length | > The signature contexts in a mutually recursive group should all be | > identical | > ... | > Couldn't match `Int' against `Char' | | Again the problem does not occur for local functions: | | data A = A (Int -> A) | | f :: A | f = A g | where | g :: Ord a => a -> A | g _ = f | | h :: A | h = g 'c' | | Why is ghc treating local and global functions differently? Is there | really a difference in decidability of the Polymorphic Type Inference? | And regarding the "contexts differ in length", I read a comment in | "Typing Haskell in Haskell": | | > a throw-away comment specifying that all explicit type signatures | > in a binding group must have the same context up to renaming of | variables | > [10,Section 4.5.2]. This is a syntactic restriction that can easily | > be checked prior to type checking. Our comments here, however, suggest | > that it is unnecessarily restrictive. | | Why does ghc still use that unnecessary restriction? | | Cheers | Bernd | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-hask

1 0

RE: kind inference
by Simon Peyton-Jones 18 Nov '05

18 Nov '05

one could. but GHC doesn't. feels low prio to me... | -----Original Message----- | From: Ross Paterson [mailto:ross@soi.city.ac.uk] | Sent: 17 November 2005 12:45 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: kind inference | | On Thu, Nov 17, 2005 at 12:32:37PM -0000, Simon Peyton-Jones wrote: | > Yes it's deliberate. (Turned out to be easy and convenient.) Yes it | > goes beyond H98, so GHC types a few too many programs even in H98 mode. | > I guess I should document it. | | I think the H98 rule is arbitrarily restrictive. But what about going | further and considering the occurrences of type constructors in instance | declarations, type signature declarations and expression type signatures?

3 3