January 2013 - Glasgow-haskell-users

time submodule not accepting patches
by José Pedro Magalhães 14 Jan '13

14 Jan '13

Hi, I cannot push any patch to the time submodule of the GHC repo. For instance, creating a new branch succeeds locally, and succeeds in pushing, but the branch is never created on the remote. Also, no commit email is generated. Could this be fixed? Thanks, Pedro

1 0

Re: Bytestring and GHC 7.6.2
by Ian Lynagh 14 Jan '13

14 Jan '13

On Tue, Jan 08, 2013 at 08:10:18PM +0000, Duncan Coutts wrote: > > Either way, lemme know if this is all fine, and I'll make the 0.10.0.2 > release. Looks good, thanks! I've updated the GHC 7.6 repo to match the tag. Thanks Ian

2 1

Understand disassemble for segfault on android
by Nathan Hüsken 13 Jan '13

13 Jan '13

Hey, I am still investigating the segfaults of the exectuable produced by ghc to arm-linux-androideabi cross compiler. I need help. Can someone tell me if my conclusions are correct? The crash happens here: Dump of assembler code for function stg_returnToStackTop: 0x003f059c <+0>: push {r4, lr} 0x003f05a0 <+4>: sub sp, sp, #16 0x003f05a4 <+8>: ldr r1, [r0, #140] ; 0x8c => 0x003f05a8 <+12>: ldr r12, [r1, #12] 0x003f05ac <+16>: ldr r1, [r12, #12] 0x003f05b0 <+20>: mov r2, #0 Since it is in the begining of stg_returnToStackTop, it has to be LOAD_THREAD_STATE(); I believe the code for this is produced by loadThreadState: loadThreadState dflags tso stack = do catAGraphs [ -- tso = CurrentTSO; mkAssign (CmmLocal tso) stgCurrentTSO, -- stack = tso->stackobj; mkAssign (CmmLocal stack) (CmmLoad (cmmOffset dflags (CmmReg (CmmLocal tso)) (tso_stackobj dflags)) (bWord dflags)), (...) So I believe the instruction are mapped like this: ldr r1, [r0, #140] <-> tso = CurrentTSO ldr r12, [r1, #12] <-> stack = tso->stackobj If that is true, the loaded tso pointer ([r0, #140]) must be wrong. When I look at the backtrace at the moment of crash: #0 0x003f0588 in stg_returnToStackTop () #1 0x003c2e74 in schedule (initialCapability=0x3f057c, task=0x52f350) at rts/Schedule.c:463 #2 0x003c2e74 in schedule (initialCapability=0x52f340, task=0x400a42f0) at rts/Schedule.c:463 #3 0x003c4cb0 in scheduleWaitThread (tso=0x401033c0, ret=0x0, pcap=0xbe843b6c) at rts/Schedule.c:2351 There is a "tso" value passed to scheduleWaitThread (tso=0x401033c0). Should be this is the same address, form where the tso is loaded in the instruction: ldr r1, [r0, #140] <-> tso = CurrentTSO ? If so, the value in r0 is way of. info register r0 0x3f057c 4130172 r1 0xe24dd010 -498216944 Are my conclusions so far correct, and I have to find out why r0 is having the wrong value? Thanks! Nathan

1 1

Building on android - compiled program segfaults
by Nathan Hüsken 13 Jan '13

13 Jan '13

Hi, I was succesfull in building ghc (pulled from git) to compile for arm-linux-androideabi! Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this Main.hs: main = putStrLn "Hello, World" I get an executable, which I can run on my android device. Unfortantly it segfaults. Running it with ./Main +RTS -DS gives: cap 0: initialised Now I am trying to debug this in gdb. When I try to display the stack (which should be in r13 on arm of I understand correctly, I get); (gdb) p8 $r13 0xbef00a74: 0x0 0xbef00a70: 0x0 0xbef00a6c: 0x3c2e74 0xbef00a68: 0x530350 0xbef00a64: 0x0 0xbef00a60: 0x0 0xbef00a5c: 0x0 0xbef00a58: 0x0 And now I am clueless. So I tried the good old printf debugging in the rts. Using this, I see that it gets before the call to scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c). But when I put a printf in the beginning of scheduleWaitThread (in Schedule.c) it is not shown. What else can I do to find out more? Thanks! Nathan

3 4

Environment variables in cabal config?
by Stephen Paul Weber 13 Jan '13

13 Jan '13

Is there any way to set the paths in my cabal-install config relative to $HOME or similar? I tried ~ and $HOME and neither of those worked. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

1 0

Pin a package?
by Stephen Paul Weber 13 Jan '13

13 Jan '13

Is there a way to tell cabal to refuse to upgrade a package? I'd like to pin my `bytestring` to the version that shipped with my GHC. I just had a weird experience. When I try to `cabal install iconv` (with my settings) it tried to downgrade my `bytestring`, when I download and do the configure+build by hand, it works, but when I try to install the local version it again begins to try to downgrade my bytestring. If I just `register --inplace` it works fine. Wut? -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

3 3

make install failing
by Stephen Paul Weber 13 Jan '13

13 Jan '13

I just did a clean build of my cross-compiling GHC with --prefix set in the top-level ./configure call. When I run `make install` I get: "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg" --force --global-package-db "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/package.conf.d" update rts/package.conf.install /bin/sh: 1: /home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg: not found make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 Grepping the output for pkg: $ make install 2>&1 | grep pkg "rm" -f "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg" ln -s i486-pc-nto-qnx8.0.0-ghc-pkg-7.7.20130112 "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg" "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg" --force --global-package-db "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/package.conf.d" update rts/package.conf.install /bin/sh: 1: /home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg: not found /bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg is a symlink to i486-pc-nto-qnx8.0.0-ghc-pkg-7.7.20130112 which does not exist (and I see no attempt to make it exist), and either way it seems that we are installing with a cross-compile prefix, but not invoking with that. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

1 0

Re: Fundeps and type equality
by Iavor Diatchki 12 Jan '13

12 Jan '13

Hello Conal, GHC implementation of functional dependencies is incomplete: it will use functional dependencies during type inference (i.e., to determine the values of free type variables), but it will not use them in proofs, which is what is needed in examples like the one you posted. The reason some proving is needed is that the compiler needs to figure out that for each instantiation of the type `ta` and `tb` will be the same (which, of course, follows directly from the FD on the class). As far as I understand, the reason that GHC does not construct such proofs is that it can't express them in its internal proof language (System FC). It seems to me that it should be fairly straight-forward to extend FC to support this sort of proof, but I have not been able to convince folks that this is the case. I could elaborate, if there's interest. In the mean time, the way forward would probably be to express the dependency using type families, which I find tends to be more verbose but, at present, is better supported in GHC. Cheers, -Iavor PS: cc-ing the GHC users' list, as there was some talk of closing the ghc-bugs list, but I am not sure if the transition happened yet. On Tue, Dec 25, 2012 at 6:15 PM, Conal Elliott <conal(a)conal.net> wrote: > I ran into a simple falure with functional dependencies (in GHC 7.4.1): > > > class Foo a ta | a -> ta > > > > foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool > > foo = (==) > > I expected that the `a -> ta` functional dependency would suffice to prove > that `ta ~ tb`, but > > Pixie/Bug1.hs:9:7: > Could not deduce (ta ~ tb) > from the context (Foo a ta, Foo a tb, Eq ta) > bound by the type signature for > foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool > at Pixie/Bug1.hs:9:1-10 > `ta' is a rigid type variable bound by > the type signature for > foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool > at Pixie/Bug1.hs:9:1 > `tb' is a rigid type variable bound by > the type signature for > foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool > at Pixie/Bug1.hs:9:1 > Expected type: ta -> tb -> Bool > Actual type: ta -> ta -> Bool > In the expression: (==) > In an equation for `foo': foo = (==) > Failed, modules loaded: none. > > Any insights about what's going wrong here? > > -- Conal > > _______________________________________________ > Glasgow-haskell-bugs mailing list > Glasgow-haskell-bugs(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > >

9 20

(mips64el) Cross-building GHC
by jugree＠lavabit.com 11 Jan '13

11 Jan '13

Hello. I would like to port GHC to mips64el. I have never tried cross-building before. So I will probably post more questions later. Actually, I am not sure that I am using the right term. I am going to use my i686 machine to build GHC for mips64el. In terms of this page(0): B = i686-unknown-linux H = mips64el-unknown-linux T = mips64el-unknown-linux Is the above correct? What I did: 1. Downloaded this(1) tarball (on i686) and unpacked it. 2. Executed the following commands(2): ghc-7.6.1$ cp /bin/pwd utils/ghc-pwd/ghc-pwd ghc-7.6.1$ perl boot ghc-7.6.1$ ./configure --enable-hc-boot --build=i686-unknown-linux --host=mips64el-unknown-linux --target=mips64el-unknown-linux Output: checking for gfind... no checking for find... /usr/bin/find checking for sort... /usr/bin/sort checking for ghc... /usr/bin/ghc checking version of ghc... 6.12.1 checking build system type... i686-unknown-linux-gnu checking host system type... mips64el-unknown-linux-gnu checking target system type... mips64el-unknown-linux-gnu HOST: mips64el-unknown-linux-gnu GHC build : i386-unknown-linux GHC host : mips-unknown-linux GHC target : mips-unknown-linux configure: Building in-tree ghc-pwd ghc: unrecognised flags: -no-user- Usage: For basic information, try the `--help' option. configure: error: Building ghc-pwd failed /ghc-7.6.1$ grep "no-user" ./* ./aclocal.m4: if ! "$WithGhc" -v0 -no-user-$GHC_PACKAGE_DB_FLAG -hidir utils/ghc-pwd/dist-boot -odir utils/ghc-pwd/dist-boot -stubdir utils/ghc-pwd/dist-boot --make utils/ghc-pwd/Main.hs -o utils/ghc-pwd/dist-boot/ghc-pwd ./configure: if ! "$WithGhc" -v0 -no-user-$GHC_PACKAGE_DB_FLAG -hidir utils/ghc-pwd/dist-boot -odir utils/ghc-pwd/dist-boot -stubdir utils/ghc-pwd/dist-boot --make utils/ghc-pwd/Main.hs -o utils/ghc-pwd/dist-boot/ghc-pwd How can I fix this? I can't find any information about this option. Thank you. PS: I only use free software (as defined by the FSF). Can I be sure that I won't install any non-free programs during the process? (0) http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation (1) http://www.haskell.org/ghc/dist/7.6.1/ghc-7.6.1-src.tar.bz2 (2) http://hackage.haskell.org/trac/ghc/wiki/Building/Porting

3 4

missing mtl (which exists) when installing filemanip package
by HP Wei 11 Jan '13

11 Jan '13

I did the following: download filemanip-0.3.6.2.tar.gz tar xvf ... cd filemanip-0.3.6.2 runhaskell Setup configure --prefix=$HOME/ghc --> it tells me Setup: At least the following dependencies are missing: mtl -any, unix-compat -any So, I did the following: download unix-compat-0.4.1.0.tar.gz tar xvf ... cd unix-compat-0.4.1.0 runhaskell Setup configure --prefix=$HOME/ghc runhaskell Setup build runhaskell Setup install --> under $HOME/ghc/lib I see unix-compat-0.4.1.0/ that was newly added by the Setup processes. --> under $HOME/ghc/lib I also see mtl-2.0.1.0/ This was there already before the above operations. Then, I went back cd filemanip-0.3.6.2 runhaskell Setup configure --prefix=$HOME/ghc --> it tells me Setup: At least the following dependencies are missing: mtl -any Question: why can't $HOME/ghc/lib/mtl-2.0.1.0/ be recognized during the above Setup configure ?? What do I need to do ? thanks HP

3 2