July 2005 - Glasgow-haskell-users

C--
by Bulat Ziganshin 31 Jul '05

31 Jul '05

Hello glasgow-haskell-users, can you please say about value of using C-- in GHC? will this reduce compile time, increase speed of compiled programs, improve portability or make some other effect? would the C-- compile path replace asm or C path? -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

Inferred type is less polymorphic than expected?
by Benjamin Franksen 30 Jul '05

30 Jul '05

Hi, I get an error message when I compile the following program with ghc-6.4: \begin{code} class Catalog c where traverse :: c -> Viewer -> IO () instance Catalog Int where traverse i v = viewShowable v i type View a = a -> IO () data Viewer = Viewer { viewShowable :: forall s. Show s => View s, viewCatalog :: forall c. Catalog c => View c } printer :: Viewer --printer = Viewer { -- viewCatalog = \x -> traverse x printer, -- viewShowable = putStrLn . show } printer = Viewer { viewCatalog = printCatalog, viewShowable = putStrLn . show } printCatalog :: forall c. Catalog c => View c printCatalog x = traverse x printer data X = X { cat :: Int } instance Catalog X where traverse x v = do viewCatalog v (cat x) main = do let x = X { cat = 20 } traverse x printer \end{code} This is a stripped-down version of my actual code, BTW. The exact mesage is: ~> ghc -fallow-undecidable-instances -fglasgow-exts Bug.lhs Bug.lhs:23:10: Inferred type is less polymorphic than expected Quantified type variable `c' is mentioned in the environment: printCatalog :: c -> IO () (bound at Bug.lhs:28:0) In the `viewCatalog' field of a record In the record construction: Viewer {viewCatalog = printCatalog, viewShowable = putStrLn . show} In the definition of `printer': printer = Viewer {viewCatalog = printCatalog, viewShowable = putStrLn . show} Bug.lhs:27:0: Contexts differ in length When matching the contexts of the signatures for printer :: Viewer printCatalog :: forall c. (Catalog c) => View c The signature contexts in a mutually recursive group should all be identical The code compiles and works fine if the definition of 'printer' is replaced by the out-commented version, that is, if a lambda expression is used that is identical to the definition of 'printCatalog'. BTW, this does not happen with hugs. It looks like a bug to me, but since I use some non-standard features, maybe there is some subtle explanation for this behavior. Ben

2 5

Installation problem
by Dieter 30 Jul '05

30 Jul '05

Hi, I'm using Linux 9.3 on a PC with a 64-architecture. I'd like to install GHC and thought the easiest way would be to take an appropriate rpm-file.So I downloaded an rpm file, it was said to running with SUSE 9.2 without problems. But when starting rpm -i ghc.-6.4-1.i386.rpm I got the message: error: Failed dependencies: libgmp.so.3 is needed by ghc-6.4-1 But it is installed on my systems. I downloaded it again and installed it again and copied it (3 files: - the symlink libgmp.so, the symlink libgmp.so.3 and the file the libgmp.so.3.3.3) into several lib directories. NO SUCCESS What is wrong? Has anyone an idea? Thank you Dieter

1 0

Bug in placing _stub.o files with HEAD
by Einar Karttunen 29 Jul '05

29 Jul '05

Hello I noticed the following behaviour using GHC 6.5.20050728: If compiling a Cabal package containing hs-source-dirs it places the _stub.o under dist/build/<source-dir>/path/to/Module when Cabal expects it in dist/build/path/to/Module. Things appear to work without hs-source-dirs. For example with "hs-source-dirs: src" Network/GnuTLS/IOWrap.hs contains foreign export declarations. runnning Setup build creates the files: dist/build/src/Network/GnuTLS/IOWrap_stub.o src/Network/GnuTLS/IOWrap_stub.h src/Network/GnuTLS/IOWrap_stub.c But Cabal fails to include the IOWrap_stub.o as it is expected as dist/build/Network/GnuTLS/IOWrap_stub.o - Einar Karttunen

1 0

RE: more on GHC 6.4 Debian packages
by Simon Marlow 29 Jul '05

29 Jul '05

On 28 July 2005 22:42, Ian Lynagh wrote: > However, the timeout program tickles known bugs in Linux 2.4 on hppa > (and possibly unknown bugs on ia64, as discussed briefly on ghc-cvs). I'd still like to get your souped-up timeout program into CVS. Would you like to post it? Cheers, Simon

2 1

RE: -split-objs and --make together?
by Simon Marlow 29 Jul '05

29 Jul '05

On 29 July 2005 05:10, Dimitry Golubovsky wrote: > Is it possible to use --make when one or more of modules involved are > split? Not right now, but it's on the ToDo list. Cheers, Simon

1 0

RE: Complexity bug in garbage collector?
by Simon Marlow 29 Jul '05

29 Jul '05

On 29 July 2005 12:53, Josef Svenningsson wrote: > My machine was definitely swapping when I aborted the program. Can that > have any effect on the timings? yes, there's your problem. It's still a nice regular-looking curve though, which is mildly surprising. Simon

1 0

RE: Complexity bug in garbage collector?
by Simon Marlow 29 Jul '05

29 Jul '05

On 16 April 2005 23:19, Josef Svenningsson wrote: > OK, I've cooked up this little program to study the behaviour a > little closer: \begin{code} > module Main where > > main = print $ strictId [1..] > > strictId list = let (c,c') = work list c' > in c > where work [] y' = (y',[]) > work (x:xs) y' = (v,x:v') > where (v,v') = work xs y' > \end{code} > > This program just allocates like crazy til it dies. The funny looking > strictId function is just the strict identity function on lists. (Yes, > there are simpler ways to achieve the same thing. I just think the > above function is particularly sweet :-) > > I do the following: > $ ghc -prof -auto-all --make Main.hs > $ main.exe +RTS -hd -M<VERY MUCH> > > The resulting graph is suspiciously similar in shape to the one of my > previous program. The garbage collector is still my primary suspect, I > simply don't know how to explain the graph otherwise. I don't see a curve in the profile on my machine: http://www.haskell.org/~simonmar/main.exe.ps This was on a Windows box, I also get the same results on a Linux machine. I was only able to test with -M600m on the Windows box. Do you need more to get the curve? Cheers, Simon

2 1

-split-objs and --make together?
by Dimitry Golubovsky 29 Jul '05

29 Jul '05

Is it possible to use --make when one or more of modules involved are split? I tried this with ghc 6.2.2 I do the following (doesn't work) Suppose we have syscall.hs and UNISTD_H.hs: the first contains Main and imports UNISTD_H, and the second is to be split. mkdir UNISTD_H_split ghc -c -split-objs UNISTD_H.hs ar cq libUNISTD_H.a UNISTD_H_split/*.o I get the library and the .hi file: no .o file ghc --make syscall.hs libUNISTD_H.a -o syscall It tries to recompile UNISTD_H.hs because there is no UNISTD_H.o, and links against the object file, not the library When I try ghc syscall.hs libUNISTD.a -o syscall it works, and only syscall.hs is recompiled, but I cannot use --make. I tried to name the library UNISTD_H.a, same result. Is it possible to get ghc recognize the library same way as if it were an object file (which corresponds to the interface file) and use --make? PS1 This is for that experiment with hsffig when the header file contains functions undefined in the default glibc. Linking against the library with split objs works fine, and executable size is much smaller, and unresolved references are gone. Only ability to use --make is missing here. PS2 It would be nice if the perl script splitting the assembler code also created the directory where the split object files go. Dimitry Golubovsky Middletown, CT

1 0

Re: more on GHC 6.4 Debian packages
by Wolfgang Jeltsch 28 Jul '05

28 Jul '05

Am Donnerstag, 28. Juli 2005 20:46 schrieb Iavor Diatchki: > Hello, > > On 7/28/05, Wolfgang Jeltsch <wolfgang(a)jeltsch.net> wrote: > > Am Donnerstag, 28. Juli 2005 16:58 schrieb Ian Lynagh: > [...] > > > There are 6.4 packages in unstable. They aren't installable in > > > unstable, but I think they should be installable on a stable system. > > > > The unstable packages aren't installable on unstable but on stable? > > That's cool. :-) I will try to install them on stable. > > I am relatively new to the Debian distribution so appologies if my > question is silly (I don't understand the above statement). Debian has always the so-called distributions unstable, testing and stable. The package ghc6 from stable contains GHC 6.2.2 while the package ghc6 from unstable contains GHC 6.4. The package ghc6 from unstable isn't installable under Debian unstable but under Debian stable. > What do I need to do to use the "official" ghc 6.4 Debian packages? You may go to http://packages.debian.org/, download the ghc6 package from unstable manually (and possibly also ghc6-doc, ghc6-libsrc, etc.) and install it (them) via dpkg -i. I cannot tell you whether the unstable packages work under testing. > I am using the "testing" distribution, which appears to have something > called ghc-cvs and ghc 6.2 but not ghc 6.4. I didn't know about ghc-cvs so far. The idea of ghc-cvs looks a bit ugly. Why would the Debian project want to have an unstable GHC version in stable? In addition I wonder why ghc-cvs from stable is one year old. > What I did at the moment was to convert the ghc rpm into a debian package > using a tool called 'alien', and this worked without problems. Before doing this, I would always try to get packages specifically made for Debian. > I am confused as to why ghc 6.4 is considered less stable then ghc-cvs > which presumably is changing more or less all the time. That's related to the problem, I pointed out above. Even the ghc-cvs in stable should normally be more unstable than an official release of GHC in unstable. However, once it is in stable, ghc-cvs doesn't change its version anymore. That's the intention behind stable. (Well, Debian uses the term "stable" more to attest that version numbers don't change than to attest that the software runs stable, I think.) > -Iavor Best regards, Wolfgang

2 1