August 2007 - Glasgow-haskell-users

(Compile ghc 6.7) Cannot find package base
by Mads Lindstrøm 12 Aug '07

12 Aug '07

Hi all I tried compiling ghc 6.7 during the night. I used the following script: #!/bin/bash rm -rf $HOME/ghc darcs get --partial http://darcs.haskell.org/ghc cd ghc chmod +x darcs-all ./darcs-all get ./darcs-all --extra get sh boot ./configure --prefix=$HOME echo "Checkpoint make" make echo "Checkpoint make install" make install but when I run ghci I get: GHCi, version 6.7.20070810: http://www.haskell.org/ghc/ :? for help <interactive>:1:22: Failed to load interface for `System.IO': Use -v to see a list of the files searched for. <interactive>:1:22: Failed to load interface for `System.IO': Use -v to see a list of the files searched for. <interactive>:1:22: Failed to load interface for `System.IO': Use -v to see a list of the files searched for. ghc-6.7.20070810: panic! (the 'impossible' happened) (GHC version 6.7.20070810 for i386-unknown-linux): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Is this really a bug or am I doing something wrong? I also tried: ghc-pkg check and got: package ghc-6.7.20070810 has missing dependencies: hpc, template-haskell, readline, unix, Cabal, base, haskell98 If anybody is interested I got the complete build logs, but given there size 2.2 megabytes (180 kilo when compressed with gzip) I choose not to include them in the message. Greetings, Mads Lindstrøm

3 2

Re: Visual Haskell will not Install with Visual Studio 2005, Express Edition
by Esa Ilari Vuokko 12 Aug '07

12 Aug '07

Hi, On 7/27/07, Sean Johnson <elquesogrande0(a)gmail.com> wrote: > Is there some way to install Visual Haskell with VS2005, Express? Perhaps > some workaround or hack? It's probably impossible. Feature matrix for Visual Studio products says "Use 3rd party controls and content. No Macros, Add-ins or Packages". [1] Best regards, Esa [1] http://msdn2.microsoft.com/en-us/vstudio/aa700921.aspx

2 1

compiler-detected nontermination
by Isaac Dupree 10 Aug '07

10 Aug '07

Firstly I'm assuming that GHC's strictness analyser notices things like (bottom = bottom) or could easily do so - please correct me if I'm wrong. GHC in its RTS already throws Nontermination exception in some cases. I think it would be nice if, when the compiler detected nontermination, to replace it with an exception and emit a warning message (hmm... if GHC Core loses source code information, a warning message might be difficult). Is there any intentional use of certain nontermination? This is inspired by the problem that supplying default definitions for class methods that refer to each other (such as Eq's (==) and (/=)), doesn't warn you if you don't define them and only yields your program not to terminate, when you run it! (noticed on haskell-prime list.) Even if it can't be detected automatically, maybe a pragma for classes to tell the compiler what documentation often tells users: {-# MINIMAL_INSTANCE Eq (==) OR (/=) #-} or for Data.Bits.Bits "Minimal complete definition: .&., .|., xor, complement, (shift or (shiftL and shiftR)), (rotate or (rotateL and rotateR)), bitSize and isSigned. " {-# MINIMAL_INSTANCE Bits (.&.) AND (.|.) AND xor AND complement AND (shift OR (shiftL AND shiftR)) AND (rotate OR (rotateL AND rotateR)) AND bitSize AND isSigned #-} Except that Bits is a stupid class in which you're *supposed to* leave bitSize undefined for unlimited-precision types like Integer... GHC already warns if you don't define bitSize... Maybe "AND" --> "," , "OR" --> "|" or something Thoughts? Isaac

2 1

GHC 6.8 release plans
by Ian Lynagh 09 Aug '07

09 Aug '07

Hi all, This is just to let you know our plans for the first release of the up-coming 6.8 branch (which will be called 6.8.1). We are aiming to have a release candidate by the end of August, with all the high priority bugs milestoned for 6.8 fixed: http://hackage.haskell.org/trac/ghc/query?status=new&status=assigned&status… If there are any other bugs that you think are critical for 6.8.1, then please make your case and add yourself to the bug's CC list now! We intend to drop support for Win9x, as we are unable to test it. I understand that the OS itself is no longer supported, and the small number of Win9x users remaining can continue to use the older GHC releases. However, if anyone feels strongly that Win9x support should be continued, and is willing to lead the effort to maintain and test it, then we will of course be willing to help out with any problems that arise. We expect that the release of 6.8.1 will follow, around the end of September. Thanks Ian

1 0

Unexpected boxing in generated code
by Neil Mitchell 07 Aug '07

07 Aug '07

Hi, I've got an inner loop that I think I can see is strict in the Int argument being passed around, but that GHC 6.6.1 isn't unboxing. In the following example both functions take a GHC.Base.Int, which I think should be an Int#. Rec { f60_rS5 :: GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Base.Int -> GHC.Base.Int [GlobalId] [Arity 2 NoCafRefs Str: DmdType LL] f60_rS5 = \ (v1_aWH :: GHC.Prim.State# GHC.Prim.RealWorld) (v2_aWI :: GHC.Base.Int) -> case $wccall_r2kv v1_aWH of wild_X2j { (# ds_d1V4, ds1_d1V3 #) -> case ds1_d1V3 of wild1_X2L { __DEFAULT -> f60_rS5 ds_d1V4 v2_aWI; (-1) -> v2_aWI; 10 -> f561_r2kx ds_d1V4 v2_aWI } } f561_r2kx :: GHC.Prim.State# GHC.Prim.RealWorld -> GHC.Base.Int -> GHC.Base.Int [GlobalId] [Arity 2 NoCafRefs Str: DmdType LL] f561_r2kx = \ (v1_aWm :: GHC.Prim.State# GHC.Prim.RealWorld) (v2_aWn :: GHC.Base.Int) -> case $wccall_r2kv v1_aWm of wild_X2j { (# ds_d1V4, ds1_d1V3 #) -> case ds1_d1V3 of wild1_X2P { __DEFAULT -> case v2_aWn of wild2_a2du { GHC.Base.I# x_a2dw -> case wild1_X2P of wild3_X35 { __DEFAULT -> f60_rS5 ds_d1V4 (GHC.Base.I# (GHC.Prim.+# x_a2dw 1)); 10 -> f561_r2kx ds_d1V4 (GHC.Base.I# (GHC.Prim.+# x_a2dw 1)) } }; (-1) -> v2_aWn } } end Rec } This code comes from a line counting program, I have attached the entire source. My character counting program does infer the correct strictness, although that is based on a single self-recursive function. The largest obvious difference is that the strictness depends on the two functions which call each other - does this impeed GHC's strictness analysis? Thanks Neil

3 4

Adding type signature changes semantics (was [Haskell-cafe] Lazy in either argument?)
by Tim Chevalier 04 Aug '07

04 Aug '07

I'm forwarding this to ghc-users since nobody answered on haskell-cafe, and I'm still curious... (The original message is at http://www.nabble.com/Lazy-in-either-argument--t4133855.html) ---------- Forwarded message ---------- From: Tim Chevalier <catamorphism(a)gmail.com> Date: Jul 26, 2007 4:52 PM Subject: Re: [Haskell-cafe] Lazy in either argument? To: Lennart Augustsson <lennart(a)augustsson.net> Cc: Dan Weston <westondan(a)imageworks.com>, haskell-cafe <haskell-cafe(a)haskell.org> On 7/26/07, Lennart Augustsson <lennart(a)augustsson.net> wrote: > The non-termination is (probably) due to the fact that you can have uninterruptible threads in ghc. > If a thread never allocates it will never be preempted. :( > To elaborate on that, the different behavior between the two versions of Dan's code, one with and one without a type signature, happens because f compiles like so if the type signature isn't given (this is the STG code): f_ri5 = \u [] let-no-escape { f1_sPY = NO_CCS[] \u [] f1_sPY; } in f1_sPY; SRT(f_ri5): [] and like so if the type signature is given: f_ri5 = \u srt:(0,*bitmap*) [] f_ri5; SRT(f_ri5): [f_ri5] If you look at the resulting asm code, the second version of f_ri5 compiles to a loop that allocates on each iteration, whereas the body of the let in the first version of f_ri5 compiles to just: sPY_info: jmp sPY_info (Adding f to the export list so that its SRT is empty doesn't change anything, btw.) This is all with -Onot. So I find this a little confusing. Why is f = let f_1 = f_1 in f_1 compiled so differently from f = f? It seems like f = f should also compile to a loop that doesn't allocate anything. And from the user's perspective, it seems somewhat strange that adding or removing a type signature changes the semantics of their code (although I guess you could make the argument that if you're dealing with threads and nonterminating code, all bets are off.) Can someone better acquainted with the code generator than me explain the rationale behind this? Cheers, Tim -- Tim Chevalier* catamorphism.org *Often in error, never in doubt "Religion is just a fancy word for the Stockholm Syndrome." -- lj user="pure_agnostic"

5 8

Annotation for unfolding wanted
by Georg Martius 03 Aug '07

03 Aug '07

Hi folks, sorry for multiple copies of this email, but my mailserver had a problem and thought I am sending spam which is hopefully not true. Since I got a replay allready I modified my mail a bit. I was wondering why we don't have an annotation or pragma for function to tell the compiler that we _need_ this particular recursive function to be unfolded. If the compiler cannot do this for some reason it should produce an error message to help you modifying your code. I have regularly problems that my code is either not strict enough or my functions are not unfolded. I find it annoying that this is a regular show stopper and consumes much time to fix. Here is an example: a search function for strings, which should return the index and the rest of the string after the first occurrence: search0 will not be unfolded by ghc -O even with {#- INLINE search0 -#} (I don't know why, it looks tail-recursive to me) whereas search1 is just fine. search0 :: Int -> String -> String -> (String, Int) search0 i [] _ = ([],i) search0 i haystack needle = let len = length needle in if isPrefixOf needle haystack then (drop len haystack, i+len) else search0 (seq i (i+1)) (drop 1 haystack) needle search1 :: Int -> String -> String -> (String, Int) search1 i [] _ = ([],i) search1 i haystack needle = let i = elemIndex True $ map (isPrefixOf needle) $ tails haystack len = length needle in case i of Just index -> (drop (index+len) haystack, index + len) Nothing -> ([],0) Regards! Georg -- ---- Georg Martius, Tel: +49 177 6413311 ----- ------- http://www.flexman.homeip.net ----------

8 12

Ticky Ticky profiling
by Cristian Perfumo 02 Aug '07

02 Aug '07

Hi all!. I modified build.mk in order to allow Ticky-Ticky profiling (GhcLibWays=t). Now, when I try to make I get this error: ------------------------------------------------------------------------ == make way=t all; PWD = (the_whole_path)/ghc-6.6.1/rts ------------------------------------------------------------------------ ../compiler/ghc-inplace -H32m -O -fasm -W -fno-warn-unused-matches -fwarn-unused-imports -optc-O2 -static -I. -#include HCIncludes.h -fvia-C -dcmm-lint -hisuf t_hi -hcsuf t_hc -osuf t_o -ticky -#include posix/Itimer.h -c PrimOps.cmm -o PrimOps.t_o ghc-6.6.1: panic! (the 'impossible' happened) (GHC version 6.6.1 for i386-unknown-linux): ToDo: tickyAllocThunk Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Any clue? Thanks in advance. Cristian Perfumo.

3 5

ghc-pkg bash completion
by Lennart Kolmodin 02 Aug '07

02 Aug '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all! I wrote a bash completion to ghc-pkg last year, just cleaned it up a bit and thought I should share it with you guys. You get your copy by typing: ; darcs get http://haskell.org/~kolmodin/code/ghc-bash-completion/ Then, to load it (quick'n'dirty without proper install): ; cd ghc-bash-completion ; source ./ghc-pkg ; source ./ghci A session could look like: ; ghc-pkg <tab><tab> # hit the tab key twice. # it gives your valid options - --auto-ghci-libs --package-conf= -V hide - --define-name= --simple-output -f latest - --force --user -g list - --global --version describe register - --global-conf= -? expose unregister - --help -D field update ; ghc-pkg hide <tab><tab> # gives you a list of # packages and optional flags The ghci support is very minimalistic at this point... it only completes on packages. That's it! Cheers, Lennart -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGsiF14txYG4KUCuERAnxMAJ4nzs8UPrNGevihKKVdSnsyOy3+twCgqQ0J itCHvhD13LEE88UBjBsmXmA= =Sndh -----END PGP SIGNATURE-----

1 0