August 2013 - ghc-devs

Deriving clauses for EmptyDataDecls [was: request for reviews for my first patch -- ticket 7401]
by Austin Seipp 14 Aug '13

14 Aug '13

On Mon, Aug 12, 2013 at 9:33 AM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > My proposal below doesn't really give different behavior for EmptyDataDecls in the two scenarios… the available constructs are the same under either H98 or H2010. It's just that the "distance" from the spec is different. > > Personally, I'm loathe to stray from a well-defined note in a standard for this. You're right, sorry about that. I suppose we can let someone else weigh in on this note. > I see my proposal below as a feasible solution to #7401, but I would actually favor not implementing any change here, because the workaround -- using standalone deriving -- is so easy and doesn't seem to have any real drawbacks (e.g. performance). Hmmm, I'm sort of ambivalent at this point. Looking at the user manual[1], the relevant point for -XStandaloneDeriving is that "Unlike a deriving declaration attached to a data declaration, GHC does not restrict the form of the data type..." At the same time, from a user POV, I'd think it's reasonably annoying to reject: data Foo deriving (Eq, Show, Ord) in favor of: data Foo deriving instance Eq deriving instance Show deriving instance Ord with an extra extension - and if you happen to mention a type variable, then it gets even longer since the context isn't inferred. Also, given that EmptyDataDecls in its current form is now standard in H2010, but StandaloneDeriving is not, this makes for longer code for people who do want to be standards compliant to write the trivial instance. And as a user of H2010, I'd see an empty data type as "a data type" - and not an extension. So I might expect deriving to work consistently with it, like with any other H2010 data type. This, I suppose, is what I was alluding to when I talked about 'inconsistency' earlier. Although, then it is a question of the standard itself! And then maybe it should be under an extra flag. I think there are legitimate points on all sides here. But, I think this is pretty squarely a 'user interface problem'. It's easy for us no matter what. So, I have CC'd glasgow-haskell-users - I think there's room for voices on this note, and I'd really appreciate users and developers weighing in. [1] http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/deriving.html > Richard > > On Aug 12, 2013, at 12:55 AM, Austin Seipp wrote: > >> On Sun, Aug 11, 2013 at 10:00 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: >>> But, instead of creating a new extension for this feature, what about just co-opting EmptyDataDecls? More concretely, I propose this: >>> >>> Under H98: EmptyDataDecls allows both the declaration of empty data decls and deriving instances for them. >>> >>> Under H2010: EmptyDataDecls allows deriving instances for empty data decls. >>> >>> This proposal brings the annoyance that H2010 no longer implies EmptyDataDecls. >>> >>> Thoughts? >>> >>> Richard >>> >> >> IMHO, I'd find this inconsistency in extension behavior much more >> annoying than just going against the standard on this note. But that's >> just my 0.02c. >> >> -- >> Regards, >> Austin - PGP: 4096R/0x91384671 > -- Regards, Austin - PGP: 4096R/0x91384671

2 1

Segfault on x86 with -O2
by Kazu Yamamoto 14 Aug '13

14 Aug '13

Hi, Some changes in the last 8 days fixed segfault on 32bit x86 with -O2: http://ghc.haskell.org/trac/ghc/ticket/7953 I read recent log messages but I cannot guess which commits fixed this bug. Does anyone guess? P.S. Thanks to this, now I started running Mighty with multicore IO manager on mew.org. I'm watching whether or not multicore IO manager works stably in the real world. --Kazu

3 5

RTS option parsing
by David Laing 13 Aug '13

13 Aug '13

Hi, I'm brand new to GHC development, and have been looking at: http://ghc.haskell.org/trac/ghc/ticket/4243 I was initially thinking of something like getopt_long_only, as per: http://linux.die.net/man/3/getopt_long however it looks like the portability of that function isn't the greatest, and from looking at rts/RtsFlags.c:procRtsOpts(...) it might not be the best solution. Unless I've missed something, it seems that the processing of each flag is independent of the others, at least once we get into procRtsOpts(...), and the processing of a flag either mutates the RtsFlags variable or results in an error. If that's not likely / wanted to change I think there are some nifty ways to abstract that, as long as function pointers aren't frowned on in the RTS code :) Since it looks like it would be a sizeable patch, should I put together a proof-of-concept and ask for feedback sooner rather than later? I'd hate to emerge from my codecave with a fully-formed but unacceptable solution. While I'm at it - does anyone have any thoughts or wishlists for a cleaned up option parser? Cheers, Dave

3 3

Two Hoopl questions
by Jan Stolarek 13 Aug '13

13 Aug '13

I have two questions about using Hoopl: 1) I'm debugging some Hoopl transformations that often fall into an infinite loop. Probably the easiest way to find the cause would be to allow only a limited number of iterations and then examining the rewritten output. I think that optimization fuel was designed exactly with this scenario in mind, but Compiler.Hoopl module in hoopl library does not re-export functions needed to use Fuel (e.g. runWithFuel). Why are these functions hidden? Is there another interface for using fuel? 2) In my algorithm I need to initialize all of the blocks in a graph with bottom element of a lattice, except for the entry block, which needs some other initial values. I've written something like this: cmmCopyPropagation dflags graph = do let entry_blk = g_entry graph g' <- dataflowPassFwd graph [(entry_blk, (Top , Top))] $ analRewFwd cpLattice cpTransfer cpRewrite return . fst $ g' cpLattice = DataflowLattice "copy propagation" (Bottom, Bottom) cpJoin However, it seems that Bottom values passed to cpLattice are ignored - I could replace them with `undefined` and the code would still run without causing an error. Is there something obviously wrong in the way I pass initial fact values to dataflowPassFwd, or should I look for the problem in other parts of my code? Janek

4 15

Hoopl 3.9 not on hackage
by Thomas Schilling 13 Aug '13

13 Aug '13

I just noticed that the latest version of hoopl (shipped with 7.6.3) is not on Hackage. Is there a reason for this (other than oversight)? / Thomas

4 4

Re: [Haskell-iPhone] Can anyone help me test GHC-iOS compiler?
by Luke Iannini 13 Aug '13

13 Aug '13

Hi Stephen/all, I got LLVM 3.0 installed and started building again but hit a very strange problem now wherein tons of layout-based code (as in http://en.wikibooks.org/wiki/Haskell/Indentation) is suddenly erroring out, e.g. compiler/coreSyn/CoreUnfold.lhs:481:2: parse error (possibly incorrect indentation or mismatched brackets) (some files also seem to be triggered by mixed tabs and spaces) I can fix the errors one by one by converting the code to use more concrete indentation (like do thing1 thing2 ) but it's all over the tree. Anyone have any idea what might cause this? Cheers Luke On Fri, Aug 9, 2013 at 6:14 AM, Stephen Blackheath [to GHC-iPhone] < likeliest.complexions.stephen(a)blacksapphire.com> wrote: > Luke, > > Try llvm version 3.0 - that's what I'm using, and it definitely worked > before. llvm-3.1 is broken for GHC+ARM. As for llvm >= 3.2, I'm not sure if > it's been fixed yet, but it wasn't working last time I tried a couple of > months ago. I think this was because llvm is getting fussier about its > input and GHC hasn't been "tightened up" yet. > > It's really easy to build llvm from source. > > > Steve > > > On 09/08/13 20:35, Luke Iannini wrote: > >> v3 output: https://gist.github.com/**lukexi/7ca55b36269703236f1f<https://gist.github.com/lukexi/7ca55b36269703236f1f> >> >> >> On Fri, Aug 9, 2013 at 4:34 AM, Luke Iannini <lukexipd(a)gmail.com >> <mailto:lukexipd@gmail.com>> wrote: >> >> OK, that got me past that one. >> >> Now I'm stuck here during compilation of integer-simple: >> https://gist.github.com/**lukexi/d9f8bfd8bca56d5d0ee9<https://gist.github.com/lukexi/d9f8bfd8bca56d5d0ee9> >> >> ("unsupported relocation on symbol"/"co-processor offset out of >> range") >> >> >> On Fri, Aug 9, 2013 at 4:00 AM, Luke Iannini <lukexipd(a)gmail.com >> <mailto:lukexipd@gmail.com>> wrote: >> >> OK, I'm underway on this. >> >> First roadbump was: >> >> >> "inplace/bin/ghc-stage1" -static -H32m -O -Iincludes >> -Iincludes/dist -Iincludes/dist-**derivedconstants/header >> -Iincludes/dist-ghcconstants/**header -Irts -Irts/dist/build >> -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts >> -irts/dist/build -irts/dist/build/autogen -Irts/dist/build >> -Irts/dist/build/autogen -O2 -c rts/Apply.cmm -o >> rts/dist/build/Apply.o >> >> >> >> >> You are using a new version of LLVM that hasn't been tested yet! >> We will try though... >> /usr/local/bin/llc: : error: unable to get target for >> 'arm-apple-darwin10', see --version and --triple. >> >> >> which I figured out were because the homebrew LLVM 3.4 only >> includes host platforms by default (x86/x86-64) >> Reinstalling it with all-targets enables them all: >> brew install llvm --with-clang --all-targets --HEAD >> >> Trying again now. >> >> >> >> >> On Thu, Aug 8, 2013 at 5:29 PM, Luke Iannini <lukexipd(a)gmail.com >> <mailto:lukexipd@gmail.com>> wrote: >> >> Update: I've got GHC HEAD building on 10.9 again, tonight >> I'll dive into the iOS patch! >> Cheers >> Luke >> >> >> On Wed, Aug 7, 2013 at 9:12 PM, Carter Schonwald >> <carter.schonwald(a)gmail.com >> <mailto:carter.schonwald@**gmail.com<carter.schonwald(a)gmail.com>>> >> wrote: >> >> if you're on 10.8, just DL the 4.6 CLI tools to get >> things working again. >> >> If you're on 10.9, you'll need to use recent GHC head + >> CLANG HEAD, (ok, the most recent XCODE 5 dev preview CLI >> tools may have all the needed clang patches, but thats >> still needing its own validation, orthogonal to the IOS >> related issues ) >> >> >> On Tue, Aug 6, 2013 at 7:06 PM, Luke Iannini >> <lukexipd(a)gmail.com <mailto:lukexipd@gmail.com>> wrote: >> >> Hi Stephen, >> >> I installed 10.9 for another project and thus am in >> the middle of fixing up my system to be able to >> build GHC again, but I think I'm close — as soon as >> I have it going I'll try this. >> >> In the meantime someone still on 10.8 should >> definitely try the patch! >> >> Hope you're great! >> Luke >> >> >> On Tue, Aug 6, 2013 at 6:42 PM, Stephen Blackheath >> [to GHC-iPhone] >> <likeliest.complexions.**stephen(a)blacksapphire.com<likeliest.complexions.stephen(a)blacksapphire.com> >> <mailto:likeliest.complexions.** >> stephen(a)blacksapphire.com<likeliest.complexions.stephen(a)blacksapphire.com> >> >> >> >> wrote: >> >> Hi all, >> >> A couple of months ago I got some patches >> applied to GHC mainline for the ability to cross >> compile to iOS. I've been doing other things and >> now I want to test those changes. The trouble >> is, I am having Apple trouble and I can't get >> Xcode to work. >> >> If anyone is interested in testing it for me, >> I'd appreciate it. >> >> The patch attached here needs to be applied to >> GHC head. Using this, I was able to get the >> cross compiler to build. The instructions are >> here: >> >> http://ghc.haskell.org/trac/__** >> ghc/wiki/Building/__**CrossCompiling/iOS<http://ghc.haskell.org/trac/__ghc/wiki/Building/__CrossCompiling/iOS> >> >> <http://ghc.haskell.org/trac/**ghc/wiki/Building/ >> **CrossCompiling/iOS<http://ghc.haskell.org/trac/ghc/wiki/Building/CrossCompiling/iOS> >> > >> >> >> Steve >> >> ______________________________**_________________ >> iPhone mailing list >> iPhone(a)haskell.org <mailto:iPhone@haskell.org> >> >> http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> >> >> >> >> ______________________________**_________________ >> iPhone mailing list >> iPhone(a)haskell.org <mailto:iPhone@haskell.org> >> http://www.haskell.org/**mailman/listinfo/iphone<http://www.haskell.org/mailman/listinfo/iphone> >> >> >> >> >> >> >>

2 8

Proposal: provide cas and barriers symbols even without -threaded
by Ryan Newton 12 Aug '13

12 Aug '13

The "atomic-primops" library depends on symbols such as store_load_barrier and "cas", which are defined in SMP.h. Thus the result is that if the program is linked WITHOUT "-threaded", the user gets a linker error about undefined symbols. The specific place it's used is in the 'foreign "C"' bits of this .cmm code: https://github.com/rrnewton/haskell-lockfree-queue/blob/87e63b21b2a6c375e93… I'm trying to explore hacks that will enable me to pull in those functions during compile time, without duplicating a whole bunch of code from the RTS. But it's a fragile business. It seems to me that some of these routines have general utility. In future versions of GHC, could we consider linking in those routines irrespective of "-threaded"? -Ryan

4 30

request for reviews for my first patch -- ticket 7401
by Ömer Sinan Ağacan 12 Aug '13

12 Aug '13

Hi all, I just started GHC development made a commit for ticket 7401: http://ghc.haskell.org/trac/ghc/ticket/7401 My patch is here: https://github.com/osa1/ghc/commit/3ec257ff48372de30df59cd8854ce28954c9db95 `make test` succeeds. My test case for this patch is something like this: data D deriving Eq main :: IO () main = print ((undefined :: D) == (undefined :: D)) example: ➜ haskell ./ghc/inplace/bin/ghc-stage2 --interactive derive.hs GHCi, version 7.7.20130806: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( derive.hs, interpreted ) Ok, modules loaded: Main. ghci> main True it :: () This behavior(returning True) is consistent with standalone deriving version: ➜ haskell cat derive_standalone.hs {-# LANGUAGE StandaloneDeriving #-} data D deriving instance Eq D main :: IO () main = print ((undefined :: D) == (undefined :: D)) ➜ haskell ./ghc/inplace/bin/ghc-stage2 --interactive derive_standalone.hs GHCi, version 7.7.20130806: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( derive_standalone.hs, interpreted ) Ok, modules loaded: Main. ghci> main True it :: () ghci> Leaving GHCi. However, if you want (==) implementation in this case to be `error "Void (==)`, I think I can also do that by first fixing the code generated by StandaloneDeriving extension and then fixing my current patch. Any comments and reviews would be appreciated! --- Ömer Sinan Ağacan http://osa1.net

4 8

Another request for reviews -- ticket 3452
by Ömer Sinan Ağacan 12 Aug '13

12 Aug '13

Hi all, I'm a starter who just made his second patch for another simple task from trac. I updated current status of ticket to "patch" but I guess I also need to post here to get some reviews on this. Ticket: http://ghc.haskell.org/trac/ghc/ticket/3452 Patch is linked there with an example output and some comments. Thanks, --- Ömer Sinan Ağacan http://osa1.net

1 0

Cannot compile phase 2 after recent Roles patch
by Dr. ERDI Gergo 12 Aug '13

12 Aug '13

Hi, I cannot compile GHC starting from e8aa8ccb 'Implement "roles" into GHC'. The error message I get is: >>>>>>>>>>>>>>>>>>>>>>>>> *** Core Lint errors : in result of Desugar (after optimization) *** {-# LINE 290 "libraries/terminfo/System/Console/Terminfo/Base.hs #-}: Warning: [RHS of System.Console.Terminfo.Base.mkCallback :: System.Console.Terminfo.Base.CharOutput -> GHC.Types.IO (GHC.Ptr.FunPtr System.Console.Terminfo.Base.CharOutput)] Role incompatibility: expected P, got R in Sym Foreign.C.Types.NTCo:CInt[0] -> (GHC.Types.IO (Sym Foreign.C.Types.NTCo:CInt[0]))_R <<<<<<<<<<<<<<<<<<<<<<<< followed by a dump of Core (see attached). -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' chown -R us.us yourbase (#gnome)

2 2