- Glasgow-haskell-users

Package management
by Brandon Moore 01 May '11

01 May '11

Based on my own misadventures and Albert Y. C. Lai's SICP (http://www.vex.net/~trebla/haskell/sicp.xhtml) it seems the that root of all install problems is that reinstalling a particular version of a particular package deletes any other existing builds of that version, even if other packages already depend on them. Deleting perfectly good versions seems to be the root of all package management problems. There are already hashes to keep incompatible builds of a package separate. Would anything break if existing packages were left alone when a new version was installed? (perhaps preferring the most recent if a package flag specifies version but not hash). For example, It seems the butterfly effect http://cdsmith.wordpress.com/2011/01/17/the-butterfly-effect-in-cabal/ could be avoided if the package database was allowed to simultaneously contain a "twittertags-1.0.0-hashA" and "twittertags-1.0.0-hashB" built against different dependencies. The obvious difficulty is a little more trouble to manually specify packages. Are there any other problems with this idea? Brandon

3 3

performance issues in simple arithmetic code
by Denys Rtveliashvili 28 Apr '11

28 Apr '11

Hi, While trying to figure out why some of my code is very slow I have found that it is something related to division. Digging a bit deeper I found an example which shows some unexpected magic and a lack of the expected one. Before raising any tickets in trac I would like to consult with you regarding what I see. Maybe I am misunderstanding the way GHC is supposed to work. ------------------- module Test where import Data.Int import GHC.Exts import GHC.Prim foo :: Int -> Int foo a = let b = a `quot` 1111 c = b `quot` 1113 d = c `quot` 1117 in d bar :: Int -> Int bar !a' = let !(I# a) = a' !(b) = quotInt# a 1111# !(c) = quotInt# b 1113# !(d) = quotInt# c 1117# in I# d ------------------- Here 'foo' is a function written in a common way and 'bar' is essentially identical one, written in a low-level style. * My understanding is that these functions are equivalent in terms of what they do. The only difference is in the code being generated. Unexpected magic is in the Core dump: ------------------- Test.$wfoo = \ (ww_sxw :: GHC.Prim.Int#) -> case ww_sxw of wild1_ax0 { __DEFAULT -> case GHC.Prim.quotInt# wild1_ax0 1111 of wild2_Xxc { __DEFAULT -> case GHC.Prim.quotInt# wild2_Xxc 1113 of wild3_Xxt { __DEFAULT -> GHC.Prim.quotInt# wild3_Xxt 1117; (-9223372036854775808) -> (-8257271295304186) }; (-9223372036854775808) -> (-7418931981405) }; (-9223372036854775808) -> (-6677706553) } Test.bar = \ (a'_ah5 :: GHC.Types.Int) -> case a'_ah5 of _ { GHC.Types.I# ipv_ste -> GHC.Types.I# (GHC.Prim.quotInt# (GHC.Prim.quotInt# (GHC.Prim.quotInt# ipv_ste 1111) 1113) 1117) } ------------------- Question 1: what is the meaning of those magic numbers -9223372036854775808, -6677706553, -7418931981405, -8257271295304186? Question 2: under which circumstances those strange branches of execution will be used and what those results would mean? Question 3: why is the Core for 'foo' so different to 'bar'? The lack of expected magic is in the assembler code: ------------------- addq $16,%r12 cmpq 144(%r13),%r12 ja .Lcz1 movl $1117,%ecx movl $1113,%r10d movl $1111,%r11d movq 7(%rbx),%rax cqto idivq %r11 cqto idivq %r10 cqto idivq %rcx movq $ghczmprim_GHCziTypes_Izh_con_info,-8(%r12) movq %rax,0(%r12) leaq -7(%r12),%rbx addq $8,%rbp jmp *0(%rbp) ------------------- Question: can't it use cheap multiplication and shift instead of expensive division here? I know that such optimisation is implemented at least to some extent for C--. I suppose it also won't do anything smart for expressions like a*4 or a/4 for the same reason. With kind regards, Denys Rtveliashvili

5 5

parsing types
by Ranjit Jhala 27 Apr '11

27 Apr '11

Hi all, can someone give me a hint as to the best way to parse a type from a string. Ideally, I'd like a function stringType :: String -> Maybe Type or possibly, stringType :: (GhcMonad m) => String -> m (Maybe Type) such that, stringType s == Just t if in the current GHC context the string s is the name of the type t. For example, I'd like: stringType "Int" to return a value equal to intTy (from TysWiredIn). My investigations have led me to parseType :: P (LHsType RdrName) and I suspect that with some work (mainly creating an appropriate PState, and mapping the name back, I can extract what I want, but I was wondering if there is some simpler route that I've overlooked. Thanks! Ranjit.

4 6

Perplexing GHC-7.0.3 behavior with hairy type-level code (regression from 6.12.3??)
by Bjorn Buckwalter 26 Apr '11

26 Apr '11

Hello all, I am doing some fairly hairy type-level stuff with FunctionalDependencies, UndecidableInstances, and other. Without going into details I have the following function which compiles fine: vecMat :: (Transpose m m', MatrixVector m' v v', Num a) => Vec v a -> Mat m a -> Vec v' a vecMat v m = transpose m `matVec` v However, I am perplexed by the following: 1. This does NOT compile despite the type signature being identical to that of 'vecMat': vecMat2 :: (Transpose m m', MatrixVector m' v v', Num a) => Vec v a -> Mat m a -> Vec v' a vecMat2 v m = vecMat v m The error message is along the lines of the below where 'HMap ...' is the context for the MatrixVector instance... I'll provide more details as needed. Could not deduce (HMap (DotProd, v) m' v') arising from a use of `vecMat' from the context (Transpose m m', MatrixVector m' v v', Num a) bound by the type signature for vecMat2 :: (Transpose m m', MatrixVector m' v v', Num a) => Vec v a -> Mat m a -> Vec v' a 2. If I omit the type signature the definition of 'vecMat2' does compile: vecMat2 v m = vecMat v m 3. If I omit the second argument it also compiles: vecMat2 v = vecMat v 4. However, if I omit both arguments it does NOT compile: vecMat2 = vecMat So I guess I have two questions. First: why would 1 not compile? Second: why are 2, 3, and 4 not equivalent? Pointers to relevant documentation welcome. I broke my GHC-6.12.3 installation when upgrading to the latest HP with GHC-7.0.3 so I cannot test 2, 3, and 4 but I know that 1 DID compile on GHC-6.12.3. Is the change of behavior in GHC-7.0.3 a bug or a bug fix? I'll be happy to elaborate on the code if it would be useful, and try to find a minimal example. But I wanted to check if the behavior I am seeing makes any sense at all first. In case you cannot wait the 'matVec' definition is from: https://github.com/bjornbm/dimensional-vectors/blob/master/Numeric/Units/Di… Thanks, Bjorn

2 1

Head does not build on OS X
by Johan Tibell 22 Apr '11

22 Apr '11

Here's the error. I've run make clean, but it didn't help: "/usr/bin/ghc" -H64m -O -fasm -package-conf libraries/bootstrapping.conf -package-name Cabal-1.11.0 -hide-all-packages -i -ilibraries/Cabal/. -ilibraries/Cabal/dist-boot/build -ilibraries/Cabal/dist-boot/build/autogen -Ilibraries/Cabal/dist-boot/build -Ilibraries/Cabal/dist-boot/build/autogen -Ilibraries/Cabal/. -optP-include -optPlibraries/Cabal/dist-boot/build/autogen/cabal_macros.h -package array-0.3.0.2 -package base-4.3.1.0 -package containers-0.4.0.0 -package directory-1.1.0.0 -package filepath-1.2.0.0 -package old-time-1.0.0.6 -package pretty-1.0.1.2 -package process-1.0.1.5 -package unix-2.4.2.0 -fwarn-tabs -Wall -fno-ignore-asserts -XHaskell98 -XCPP -no-user-package-conf -rtsopts -odir libraries/Cabal/dist-boot/build -hidir libraries/Cabal/dist-boot/build -stubdir libraries/Cabal/dist-boot/build -hisuf hi -osuf o -hcsuf hc -c libraries/Cabal/./Distribution/Simple/PreProcess/Unlit.hs -o libraries/Cabal/dist-boot/build/Distribution/Simple/PreProcess/Unlit.o "/usr/bin/ghc" -H64m -O -fasm -package-conf libraries/bootstrapping.conf -package-name hoopl-3.8.7.0 -hide-all-packages -i -ilibraries/hoopl/src -ilibraries/hoopl/dist-boot/build -ilibraries/hoopl/dist-boot/build/autogen -Ilibraries/hoopl/dist-boot/build -Ilibraries/hoopl/dist-boot/build/autogen -Ilibraries/hoopl/. -optP-include -optPlibraries/hoopl/dist-boot/build/autogen/cabal_macros.h -package base-4.3.1.0 -package containers-0.4.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -no-user-package-conf -rtsopts -odir libraries/hoopl/dist-boot/build -hidir libraries/hoopl/dist-boot/build -stubdir libraries/hoopl/dist-boot/build -hisuf hi -osuf o -hcsuf hc -c libraries/hoopl/src/Compiler/Hoopl/Shape.hs -o libraries/hoopl/dist-boot/build/Compiler/Hoopl/Shape.o "/usr/bin/ghc" -H64m -O -fasm -package-conf libraries/bootstrapping.conf -i -iutils/unlit/. -iutils/unlit/dist/build -iutils/unlit/dist/build/autogen -Iutils/unlit/dist/build -Iutils/unlit/dist/build/autogen -no-user-package-conf -rtsopts -c utils/unlit/unlit.c -o utils/unlit/dist/build/unlit.o "inplace/bin/mkdirhier" utils/unlit/dist/build/tmp//. make[1]: *** No rule to make target `settings', needed by `inplace/lib/settings'. Stop. make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2

2 2

GHC/LLDB integration
by William Knop 22 Apr '11

22 Apr '11

Hello all, I've been using LLDB for a few weeks now, initially acquainting myself with its python bindings. It occurred to me early on that they might integrate into GHC's testsuite well, so I began writing a driver. The idea was to encapsulate the launched haskell processes in LLDB and generate more useful debugging information for failed tests (I'd previously been hunting down a few spurious segfaults). However, LLDB is quite immature and currently lacking such capabilities as generating core files, among other things. But while searching for core file generation, I ended up discovering that it is to eventually be implemented as a native plugin. It turns out that the plugin system allows for a lot of extensibility, including language and ABI extension. So I started digging into that and just recently began working on adding a GHRuntime plugin which should allow for demangling of symbols (easy), analysis and description of info tables and call graphs (hard), etc. So before I get too far into it, and because I am not a GHC guru, I'd like to gauge it's ultimate usefulness amongst the community. Given that haskell code goes through several stages of transformation, can more useful information be derived from a debugged executable? Or can more useful debug information be emitted by GHC if it can be interpreted by a purpose-made debugger plugin? If so, what information and functionality would be desirable? Ideas and comments are most welcome. Will

3 3

Type-level operators
by Stefan Holdermans 20 Apr '11

20 Apr '11

Simon, Regarding the note you attached to the Trac ticket on the pretty-printing of kind ascriptions (http://hackage.haskell.org/trac/ghc/ticket/5141#comment:2) > Note, though, that it's likely that we're considering making operators > like '*' into type ''constructors'' rather that type ''variables'. This > is inconsitent with terms, but is jolly convenient: > {{{ > data a + b = Left a | Right b > }}} > Of course there'll be a flag. But let us know if you think that having > operators be type variables is very useful. (I tend to think it's more > confusing than useful.) I myself am perfectly alright with being "forced" to write {{{ data a :+: b = Left a | Right b }}} Although I don't have a *convincing* example of the usefulness of operators as type variables, I like the idea of consistency with the term level: IMO it keeps things predictable. And even as it may not qualify as convincing, I do remember having written code similar to {{{ data (f :+: g) a = Inl (f a) | Inr (g a) data (f :*: g) a = f a :*: g a class FunctorOp ((&) :: (* -> *) -> (* -> *) -> (* -> *)) where ... instance FunctorOp (:+:) where ... instance FunctorOp (:*:) where ... class FunctorOp (&) => CommOp (&) where comm :: f & g -> g & f instance CommOp (:+:) where ... instance CommOp (:*:) where ... f :: (CommOp (&), Functor f, Functor g) -> f & g -> ... f ... = ... }}} All this, of course, just to put in my tuppence worth. Cheers, Stefan

1 0

Installation
by Luca Ciciriello 20 Apr '11

20 Apr '11

Hi All.I'm using GHC with MacOS X 10.6.7 (Xcode4). I've installed GHC 7.0.3 and the HackageDB package hsgsom. Then, for my motivation, I've uninstalled GHC.To remove GHC I've used the uninstaller tool and I've manually removed the folder /Library/Frameworks/GHC.framework. I've also manually removed the folder /Users/MyUser/Library/Haskell and the folder /Users/MyUser/.cabal Now I've installed GHC again, but when I try to install the package hsgsom cabal tells to me that the package is already installed and I have to use the --reinstall flag. So, where the information of the installed packages are stored on my system? How can I remove all Haskell dependencies from my system in order to start with a clean installation? Thanks in advance for any answer. Luca.

2 2

Using the GHC heap profiler
by Tim Docker 19 Apr '11

19 Apr '11

My question on the ghc heap profiler on stack overflow: http://stackoverflow.com/questions/5306717/how-should-i-interpret-the-outpu… remains unanswered :-( Perhaps that's not the best forum. Is there someone here prepared to explain how the memory usage in the heap profiler relates to the "Live Bytes" count shown in the garbage collection statistics? Many thanks, Tim

6 12

C-- roundtripping: switch, if and other control flow statements
by Edward Z. Yang 15 Apr '11

15 Apr '11

Hello all, I'm interested in improving GHC's C-- parser's support (and also making accomodations for the parser in our C-- pretty-printer) to the point where we can round-trip output from -ddump-opt-cmm with no semantic change. There are several roadblocks on the way here, but the one I'm currently tackling is the fact that the parser does not understand flow control statements like such: if (b) goto foo; It requires that the statement be closed in braces, and this will generate a new, anonymous block containing the instruction: if (b) { goto foo; } becomes if (b) goto temp ... temp: goto foo; This is, somewhat surprisingly, preventing me from getting a nice minimal test-case for a bug in the linear register allocator. I need a way to not get an anonymous block being generated. I've tried extending the grammar to accept both, but for switch statements making the change at the obvious point introduces a reduce-reduce conflict. I suspect I can hack my way around it, but for now I've renamed the keyword to 'raw_switch', which doesn't accept blocks on the right side of the case. Cheers, Edward

1 0