- Glasgow-haskell-users

Advice on type families and non-injectivity?
by Conal Elliott 14 Jan '13

14 Jan '13

I sometimes run into trouble with lack of injectivity for type families. I'm trying to understand what's at the heart of these difficulties and whether I can avoid them. Also, whether some of the obstacles could be overcome with simple improvements to GHC. Here's a simple example: > {-# LANGUAGE TypeFamilies #-} > > type family F a > > foo :: F a > foo = undefined > > bar :: F a > bar = foo The error message: Couldn't match type `F a' with `F a1' NB: `F' is a type function, and may not be injective In the expression: foo In an equation for `bar': bar = foo A terser (but perhaps subtler) example producing the same error: > baz :: F a > baz = baz Replacing `a` with a monotype (e.g., `Bool`) eliminates the error. Does the difficulty here have to do with trying to *infer* the type and then compare with the given one? Or is there an issue even with type *checking* in such cases? Other insights welcome, as well as suggested work-arounds. I know about (injective) data families but don't want to lose the convenience of type synonym families. Thanks, -- Conal

6 11

Re: [Haskell-cafe] Advice on type families and non-injectivity?
by Conal Elliott 14 Jan '13

14 Jan '13

Thanks, Jake! This suggestion helped a lot. -- Conal On Sun, Jan 13, 2013 at 1:59 PM, Jake McArthur <jake.mcarthur(a)gmail.com>wrote: > I have a trick that loses a little convenience, but may still be more > convenient than data families. > > {-# LANGUAGE TypeFamilies #-} > > import Data.Tagged > > type family F a > > foo :: Tagged a (F a) > foo = Tagged undefined > > bar :: Tagged a (F a) > bar = foo > > > This allows you to use the same newtype wrapper consistently, regardless > of what the type instance actually is; one of the inconveniences of data > families is the need to use different constructors for different types. > > > On Sun, Jan 13, 2013 at 2:10 PM, Conal Elliott <conal(a)conal.net> wrote: > >> I sometimes run into trouble with lack of injectivity for type families. >> I'm trying to understand what's at the heart of these difficulties and >> whether I can avoid them. Also, whether some of the obstacles could be >> overcome with simple improvements to GHC. >> >> Here's a simple example: >> >> > {-# LANGUAGE TypeFamilies #-} >> > >> > type family F a >> > >> > foo :: F a >> > foo = undefined >> > >> > bar :: F a >> > bar = foo >> >> The error message: >> >> Couldn't match type `F a' with `F a1' >> NB: `F' is a type function, and may not be injective >> In the expression: foo >> In an equation for `bar': bar = foo >> >> A terser (but perhaps subtler) example producing the same error: >> >> > baz :: F a >> > baz = baz >> >> Replacing `a` with a monotype (e.g., `Bool`) eliminates the error. >> >> Does the difficulty here have to do with trying to *infer* the type and >> then compare with the given one? Or is there an issue even with type >> *checking* in such cases? >> >> Other insights welcome, as well as suggested work-arounds. >> >> I know about (injective) data families but don't want to lose the >> convenience of type synonym families. >> >> Thanks, -- Conal >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> >

1 0

Re: any successfull ghc registerised builds on arm?
by Austin Seipp 14 Jan '13

14 Jan '13

(CC'ing glasgow-haskell-users, as it got lost somehow. A message or two from me and Karel are also missing the list.) On Mon, Jan 14, 2013 at 1:27 PM, Ben Gamari <bgamari.foss(a)gmail.com> wrote: > Austin Seipp <mad.one(a)gmail.com> writes: > >> I've been working on ARM the past weekend. Here's where I'm at >> (semi-long email ahead.) >> > I've also been working on this slowly over the last few weeks (in all of > the discussion below, I'm building for a Pandaboard with Ubuntu's ghc > 7.4 package). Unfortunately, most of my efforts have been going into > convincing llc and gcc to build compatible objects. With GHC 7.6 simply > taking the brute force approach with SRC_HC_OPTS seems to work, > > SRC_HC_OPTS = -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-mcpu=cortex-a9 -optlc-mcpu=cortex-a9 # -optlc-float-abi=hard > > With this, I can produce a compiler and run the testsuite to generate > this not-entirely-depressing picture, > > OVERALL SUMMARY for test run started at Sat Jan 5 17:12:12 UTC 2013 > 3400 total tests, which gave rise to > 8322 test cases, of which > 4 caused framework failures > 5311 were skipped > > 2649 expected passes > 47 had missing libraries > 59 expected failures > 0 unexpected passes > 252 unexpected failures > > Sadly a good portion of the failures seem to be due to ghci crashing due > to either a segmentation fault or illegal instruction. > This is likely due to linker support needing either to be written or > fixed. I'll have to brush off my linker knowledge and have a look at > these (probably next weekend). Yes, the linker bit was one of the components of the stage2 compiler worrying me the most, especially since in our past conversations, we've both seen it segfault when linking libraries while building things like vector. I really can't wait for a future where GHC on Linux supports dynamic by default out of the box (and ARM should fit in this category, too.) > In my opinion it's worth having a released compiler built as a refernce. The > ghc-7.6 branch is pretty easy to get going if you ever have some spare > CPU cycles available. Spare cycles do occur sometimes, so I'll give a shot to building it with LLVM-3.0 later when I get the chance. >> Overall I think squashing as many bugs as possible in HEAD is the >> correct route at the moment. This is only my opinion. My plans are to >> get a working stage1 registered GHC HEAD, and begin running the >> testsuite against it, filing down bugs. Eventually, this should lead >> to a stage2 as we narrow things down. >> > Is this to say that you've been unable to successfully build a stage 2 > compiler? I'm currently in the middle of a build of HEAD. We'll see how > far this makes it. Yes, on my ODROID I have yet to build a stage2 compiler. This is mostly due to bugs in the LLVM backend in combination with the new code generator, it seems. I get through the entire stage1 build and the build of several of the libraries, but now I'm stuck compiling base with stage1. This is the bug I have yet to fix, in this area: http://hackage.haskell.org/trac/ghc/ticket/7575 I speculate the cause of this bug is eerily similar to the other two bugs I fixed relating to properly narrowing/widening LLVM variable types. Take a look at these bugs and their patches: http://hackage.haskell.org/trac/ghc/ticket/7571 http://hackage.haskell.org/trac/ghc/ticket/7580 so I imagine I can get this fixed tonight and move on. > Out of curiosity, what are the build times on the ODROID? I haven't completed a full build so it's hard to estimate. But with a quick build and 'make -j4', the build seems to chug along fairly respectably, and I'd say I can get through the entire stage1 compiler build in the ballpark of ~30ish minutes. This is a very rough estimate because with enough parallelism, it's hard to see "how far" you are in the build, obviously. At a guess, I speculate a full build of everything at -j4 would be somewhere on the order of an hour and a half, to two-plus hours. > I agree that having nightly buildbots would be very nice. I meant to > setup my PandaBoard in this capacity after finishing my linker work, but > sadly life and hardware failures got in the way. Yes, PandaBoards aren't the most reliable as several of us seem to realize. :) Anything you could contribute here would be wonderful. I'm new to the buildbot infrastructure, so when the "time is right" I'll rally people about this again. > Very true. It would be very nice if we could handle this issue > automatically after we figure out the proper way to handle it manually. I think Karel is right that we may be able to get 90% of the way there with a short hack in DriverPipeline, with some ./configure logic to fix it, but easier said than done, I'm sure (abusrdly long build times don't help I bet.) > To be fair, hacking on the compiler itself is a bit sexier than hacking > on the build system. There are also considerably fewer variables named things like '$$$$$' and '@$$$$' in the compiler than build system, which certainly helps *me*, at least. :) > Historically I've written up my experience on my own nearly non-existent > blog[1][2][3]. Given the vanishingly small probability that someone will > actually find this information, I think I'll start trying to put > together a page on the Wiki instead. I agree that having a centralized > location to place this sort of information is extremely valuable. A good > portion of the effort in starting a project like this is determining > what others have done. > > There already exists a ArmLinuxGhc[4] page on the wiki. That being said, > it's woefully out of date and much of the discussion centers around > other Haskell implementations. I'd say it would be fair to start with a > clean slate on this page and describe the current state of things, the > ideosyncracies of building GHC on ARM (e.g. float ABI issues), and what > remains to be done (a list of failing tests when the reason for failure > is known might be useful). > > Cheers, > > - Ben Agreed. I'll look into cleaning up the wiki page later with a good outline, so hopefully more users can contribute. > > [1] http://bgamari.github.com/posts/2013-01-04-ghc-arm-update.html > [2] http://bgamari.github.com/posts/2012-01-27-ghc-llvm-arm.html > [3] http://bgamari.github.com/posts/2011-10-17-crosscompiling_llvm.html > [4] http://hackage.haskell.org/trac/ghc/wiki/ArmLinuxGhc -- Regards, Austin

2 1

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 13 Jan '13

13 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 12 Jan '13

12 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 12 Jan '13

12 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 12 Jan '13

12 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