April 2011 - Glasgow-haskell-users

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 21 Apr '11

21 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

C-- source highlighting using source-highlight
by Johan Tibell 15 Apr '11

15 Apr '11

Hi, I've thrown together a small source-highlight language file for C--. You can use it to e.g. highlight C-- code when piped through less. ### Installion ### # This works on Debian/Ubuntu $ sudo apt-get install source-highlight # Put this file anywhere $ cat $HOME/cmm.lang comment start "//" # multi-line comments comment delim "/*" "*/" multiline string delim "\"" "\"" escape "\\" keyword = "aborts|align|aligned|also|as|big|bits|byteorder|case|const", "continuation|cut|cuts|else|equal|export|foreign|goto|if|import|in", "invariant|invisible|jump|little|memsize|pragma|reads|register", "return|returns|section|semi|span|stackdata|switch|target|targets|to", "typedef|unicode|unwinds|writes" number = '\<[+-]?((0x[[:xdigit:]]+)|(([[:digit:]]*\.)? [[:digit:]]+([eE][+-]?[[:digit:]]+)?))u?((int(?:8|16|32|64))|L)?\>' ### Usage ### $ ghc <source> -ddump-cmm | source-highlight --lang-def=$HOME/cmm.lang -f esc -s cmm | less -R Johan

2 1

Meaning of ghc-pkg package-conf flags
by C Rodrigues 14 Apr '11

14 Apr '11

Hello, I'd like to know how ghc-pkg searches package databases and how the command-line flags affect the search. My model of ghc-pkg was that it builds a list of package databases and then searches them starting from the head. I'd like to work with a sandboxed local package database. Looking at what ghc-pkg list prints, I can infer what database list it's using: ghc-pkg list: [user-db, global-db] ghc-pkg list --global: [global-db] ghc-pkg list --global --package-conf=$HOME/sandbox/package.conf.d: [sandbox-db, global-db] However, even though ghc-pkg doesn't show my user database, it still reports broken packages that are in my user database. So ghc-pkg isn't really scanning packages according to this database list. What is it doing?

2 1

Rebuilding ghc changes interface hashes?
by Joachim Breitner 10 Apr '11

10 Apr '11

Dear ghc developers, I am currently rebuilding ghc-7.0.2 to upload some packaging changes. Unfortunately, this had the effect of changing the package id of "base", which would require rebuilding every Haskell library. In the times of ghc-6.12, rebuilding the compiler left the hashes intact. Is there anything new in ghc-7 that interferes here? Also, the initial upload was built using ghc-6.12.1, while the upload now is build with ghc-7.0.2. Given that it is a two-stage compiler, I assume that the output should be identical, but it seems not to be the case. Any idea what could be causing this? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

4 14