- Glasgow-haskell-users

Should ghc -msse imply gcc -msse
by Johan Tibell 17 Jan '13

17 Jan '13

Hi all, You can turn on e.g. SSE 4.1 by passing -msse4.2 to ghc. This doesn't currently imply that we compile any C code with -msse4.2 turned on, so if someone really want to use SSE4.2, they have to do: ghc -msse4,2 -optc-msse4.2 Do we want to change this so it's enough to pass -msse4.2 to ghc? -- Johan

3 5

Irritating compilation error on Windows32.
by Caitlin 17 Jan '13

17 Jan '13

Hi all. I wrote the following test program: bar x = x * x on a Win32 (SP3) machine using the Haskell Platform and GHC-7.6.1 (standalone) and I have noticed the same frustrating errors. Any suggestions would be most appreciated. Thanks, ~Caitlin C:\>ghci GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> Prelude> :l bar [1 of 1] Compiling Main ( bar.hs, interpreted ) *** Exception: CreateDirectory ".": permission denied (Access is denied.) > > :l bar.hs [1 of 1] Compiling Main ( bar.hs, interpreted ) *** Exception: CreateDirectory ".": permission denied (Access is denied.) > > :l "C:\\bar.hs" [1 of 1] Compiling Main ( C:\bar.hs, interpreted ) *** Exception: CreateDirectory "C:\\": permission denied (Access is denied.) > >

1 0

What is the scheduler type of GHC?
by Magicloud Magiclouds 16 Jan '13

16 Jan '13

Hi, Just read a post about schedulers in erlang and go lang, which informed me that erlang is preemptive and go lang is cooperative. So which is used by GHC? From ghc wiki about rts, if the question is only within haskell threads, it seems like cooperative. -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

3 2

Master thesis
by Vikraman 16 Jan '13

16 Jan '13

Hi, I am looking to hack on ghc/haskell for my master thesis. What are some areas that I should be looking into? Any suggestions are welcome.

2 1

Newtype wrappers
by Krzysztof Gogolewski 15 Jan '13

15 Jan '13

The idea can be extended to other situations where unsafeCoerce is justified: empty types and phantom types. Given declarations data Void data Void' data Const a b = Const a we can create O(1) wrappers: f :: F Void -> F Void' -- empty datatypes are exchangeable g :: F (Const a Int) -> F (Const a Bool) -- phantom parameter is insignificant assuming they do not mess with invariants of F. >From this perspective I prefer proposal 2 (a new constraint): new types of coercions might be added by adding special cases in the constraint solver. It is also a reuse of syntax: we can write foo = newtypeCast :: [Int] -> [Age] instead of adding a new form of declaration. _____________________ As for safety, in some sense Map a b is parametric in a and b except the Ord instance of a. We can coerce Map a b into Map c d if we can coerce a into c, b into d and the Ord a instance matches Ord c instance (for example, one is derived from the other). This could be implemented via an instance like this: instance (a ~~ c, b ~~ d, Ord a ~~ Ord c) => Map a b ~~ Map c d where ~~ is kind-polymorphic "equality up to newtypes". If Map was, say, indexed (nonparametric) in the first argument, that would be: instance b ~~ d => Map a b ~~ Map a d etc. Krzysztof Gogolewski

1 0

chao!
by asyropoulos＠aol.com 15 Jan '13

15 Jan '13

http://www.orthopaedie-nickles.de/tmp/yahoo.php

1 0

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