October 2007 - Glasgow-haskell-users

6.8.1-candidate tested
by Serge D. Mechveliani 18 Oct '07

18 Oct '07

Dear GHC developers, I have tested ghc-6.8.0.20071015-src.tar.bz2 on DoCon and on Dumatel. It looks all right (except the bug-candidate for -O which is common to all GHC versions and which I recently reported ). On DoCon, ghc-6.8.0.20071015 1) builds the project 2-3 times faster than ghc-6.6.1, 2) its produced .a code is 1.6 times larger, 3) the test runs 1.4 times faster, 4) the minimal space (2500 Kb) for the test running remains. This looks all right. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 2

-O bug?
by Serge D. Mechveliani 18 Oct '07

18 Oct '07

Dear GHC developers, The point (1) below looks like a bug (in all GHC versions!). (1) -O for demo-test. Take (the public) docon-2.10 build it under -O, install, and build also under -O its test program by cd demotest ghc $doconCpOpt -O --make Main Either the latter compilation will loop forever or it will take an unnaturally large resource. Yes, the functions T_.test, T_tt are defined in rather a particular way (see them). I always build this test under -Onot, because compiling with optimization has not much sense for this part. But slill. (2) -O2 In my DoCon programs, -O2 was always worse than -O: the code is about 1.3 times larger and 1.2 times slower. There are some particular points in my programs. For example, almost everywhere I set Integer rather than Int, I do not recall others, now. In never complained on (1) and (2) because did not recall of them and because they do not bite me in practice, so far. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

bug in 6.8.1-candidate
by Serge D. Mechveliani 17 Oct '07

17 Oct '07

Dear GHC developers, this is a bug report on ghc-6.8.1-candidate. The archive http://botik.ru/pub/local/Mechveliani/ghcBugs/bug-6.8.0-sep28.zip contains a project for which `making' under ghc-6.8.0.20070928-src produces a report of kind ---------------------------------------------------- ... <many modules compiled> GBasFld_.hs: ... ghc-6.8.0.20070928: panic! (the 'impossible' happened) (GHC version 6.8.0.20070928 for i386-unknown-linux): initC: srt_lbl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ---------------------------------------------------- unzip it, please, and see install.txt. Then, see GBasFld_.hs, it is small, and it looks like ghc cannot compile it. In ghc-6.6.1, this project works all right. The project can easily be reduced to the size of about a single GBasFld_.hs module (see install.txt). Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

empty export warning
by Serge D. Mechveliani 17 Oct '07

17 Oct '07

People, here is a more precise report about empty _export_ in ghc-6.8.1-candidate: I use -------------------------------- module M1 (f, module M2) where import M2 () f = ... -------------------------------- in the situation when M1 imports some instances from M2 and reexports these instances. And ghc-6.8.1-candidate reports "Warning: The export item `module M2' exports nothing" 1) Can I fix anything here? 2) Should this warning be different? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 2

Prevent optimization from tempering with unsafePerformIO
by Bernd Brassel 17 Oct '07

17 Oct '07

Hello, I am writing a compiler from the functional logic language Curry to Haskell. As the result is a real extension of Haskell, there has to be SOME side effect involved. Unfortunately, this seems to prevent me from using any of ghc's optimizations on the resulting code. I have tried for some time to invoke the no-inline pragmata, but they seem to have no effect at all. Recently at ICFP, Neil Mitchell told me that there definitely is a way to avoid this problem. But does anybody know how? Thanks for your help! Bernd Brassel

7 13

Orphan Instances with GHC 6.8
by Adrian Hey 17 Oct '07

17 Oct '07

Hello Folks, One thing different from 6.6 and 6.8 is I find that with -Wall I get a lot more warnings about orphan instances, even if the code has not changed. Has the definition of what an Orphan instance is changed? Or is this a bug? If so, is the bug in 6.6 or 6.8? I can make them go away with the -fno-warn-orphans flag, but I'm still curious as to why I didn't have to do this before. Thanks -- Adrian Hey

2 3

Prevent optimization from tempering with unsafePerformIO
by Bernd Brassel 16 Oct '07

16 Oct '07

Hello, I am writing a compiler from the functional logic language Curry to Haskell. As the result is a real extension of Haskell, there has to be SOME side effect involved. Unfortunately, this seems to prevent me from using any of ghc's optimizations on the resulting code. I have tried for some time to invoke the no-inline pragmata, but they seem to have no effect at all. Recently at ICFP, Neil Mitchell told me that there definitely is a way to avoid this problem. But does anybody know how? Thanks for your help! Bernd Brassel

2 2

undecidable & overlapping instances: a bug?
by Jorge Marques Pelizzoni 13 Oct '07

13 Oct '07

Hi, all! I am quite intrigued at the behaviour examplified in the attached module. It's true I am a newbie and probably don't quite get the whole consequence spectrum of -fallow-undecidable-instances, but why providing that dummy instance (commented out) get the thing to compile? By the way, I'm using GHC 6.6 on WinXP (actually, latest Visual Haskell with MS Visual Studio 2005) and the error message I get is: FooModule.hs:13:9: Could not deduce (Show a) from the context (Concrete a b) arising from use of `bar' at FooModule.hs:13:9-13 Possible fix: add (Show a) to the class or instance method `foo' In the expression: bar x In the definition of `foo': foo x = bar x In the definition for method `foo' A second question: which kinds of overlapping are covered by -fallow-overlapping-instances? It seems that the following (also in the attached module) is not allowed: instance (Show a, Abstract a b) => Concrete a b where foo x = show x instance (Abstract a b) => Concrete a b which gives me the message: FooModule.hs:17:0: Duplicate instance declarations: instance [overlap ok] (Show a, Abstract a b) => Concrete a b -- Defined at FooModule.hs:17:0 instance [overlap ok] (Abstract a b) => Concrete a b -- Defined at FooModule.hs:30:0 Thanks in advance for any pointers. Cheers, Jorge.

1 0

Determining GHC version use to compile an executable?
by Ravi Nanavati 10 Oct '07

10 Oct '07

I was wondering if there was a clever way to determine the GHC version that was used to compile a particular executable. I looked in the RTS flags and didn't see anything obvious, but I was wondering if I missed something or if there was a clever back door. It's not a big deal if there isn't but, if there is, it might help me diagnose a problem. Thanks, - Ravi

3 2

is -fno-monomorphism-restriction evil?
by Jorge Marques Pelizzoni 09 Oct '07

09 Oct '07

Hi, all! It may be a side-effect of being a newbie, but many times I find the -fno-monomorphism-restriction quite handy. Is it intrinsically evil? I mean, has anyone had a bad time using it or does it imply some runtime performance overhead? I guess it is not portable, is it? Thanks in advance. Cheers, Jorge.

2 1