- ghc-devs - Haskell.org

can't build head: parser file name / module name conflict
by Carter Schonwald 22 Aug '13

22 Aug '13

hey all, i'm trying to build head to test out some stuff, and i'm hitting the following error message (http://ghc.haskell.org/trac/ghc/ticket/8143 ) compiler/stage1/build/Parser.hs:1:1: File name does not match module name: Saw: `Main' Expected: `Parser' make[1]: *** [compiler/stage1/build/.depend-v.haskell] Error 1 any thoughts?

3 2

What are the current rules about object duplication during GC?
by Ryan Newton 21 Aug '13

21 Aug '13

Is the status quo still the same as it was in this paper? http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/pa… That is, there is a low-probability that a race will result in immutable objects being duplicated, but not mutable objects. But that leaves me wondering exactly which types are currently included in the duplicatable vs. "take the lock" category [2]. The reason I'm asking is because *defeating GHC compile-time and runtime optimizations* is precisely the goal of the recent work to make a safe/reliable infrastructure for CAS-based lockfree data structures in GHC. For example, the atomic-primops package uses the Any kind and type coercions to store objects (pointers) in a form that makes them opaque to the compiler, preventing them from being unboxed and reboxed (changing pointer identity). Actually, the current policy of this library that false negatives (failing CAS) must be tolerated, which is *usually* not an onerous obligation. So if the heap objects in question CAN be duplicated, that is still ok, but I would like to know if it is the case, that is, if Any is treated any differently than, say, Int. My guess is *no, *but I'd like to confirm this. That is, it seems that Anyeffects the compiler (which promises not to enter the pointer<http://www.haskell.org/ghc/docs/7.6.3/html/libraries/ghc-prim-0.3.0.0/GHC-P…>), but the physical representation of a thunk or function doesn't change, and thus the GC must treat those objects exactly as it would if they were *not*coerced to Any. Sound right? Cheers, -Ryan [1] P.S. The places I checked before asking on this list were here: http://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC And here: http://ghc.haskell.org/trac/ghc/wiki/GarbageCollectorNotes If there is newer documentation for the GC, please let me know. [2] One hint is on line 531 of StgMiscClosures.cmm<https://github.com/ghc/ghc/blob/d61c623ed6b2d352474a7497a65015dbf6a72e12/rt…> : // PRIM rather than CONSTR, because PRIM objects cannot be duplicated by the GC. Yet there are 62 different types of objects in ClosureTypes.hs, so I'm not sure what all the rules are.

2 1

GHC branch "atomics" pushed
by Ryan Newton 21 Aug '13

21 Aug '13

Hi all, There should be very little that is controversial about this branch because it adds primops upon which nothing else depends and which users will not see directly. But for now I've added it to a branch called "atomics" (likewise use the "atomics" testsuite branch of course). As soon as Carter and I work out a bit more of the future roadmap I'll merge it into master. Carter, would you like to use this branch to develop the improved LLVM support for the primops that are now added there? Cheers, -Ryan P.S. Carter, as you requested I'll add an extra trac ticket for discussion.

3 3

Instantiating a type with fresh, flexi type variables
by Dr. ERDI Gergo 20 Aug '13

20 Aug '13

For my pattern-synonyms branch (see prev. email) I had to write the following function, incl. making TcValidity.fvTypes public: tcInstTypes :: [TcType] -> TcM [TcType] tcInstTypes tys = do { let tvs = fvTypes tys ; (_, _, subst) <- tcInstTyVars tvs ; return $ map (substTy subst) tys } I'm surprised I had to write this myself, and this made me wonder if there's a much better way to handle cases where I have some kind of definition which has some inferred type, and then various use sites of that definition must all have types that can be unified with this original inferred type. Is there? Thanks, Gergo

3 3

DNS entry for git.haskell.org active now!
by Herbert Valerio Riedel 20 Aug '13

20 Aug '13

Hello GHC Devs, Hopefully, the new DNS entry for git.haskell.org should be visible for all of you by the time you read this. This mostly completes the migration part of the GitolitePlan[1]. With the new hostname, the URLs to use for `sync-all` to fetch via git://, http://, or ssh:// (ordered by increasing latency & url length) are ./sync-all -r git://git.haskell.org remote set-url origin ./sync-all -r http://git.haskell.org remote set-url origin ./sync-all -r ssh://git@git.haskell.org remote set-url origin ...and for setting the push-URL (via ssh://) use ./sync-all -r ssh://git@git.haskell.org remote set-url --push origin Please note that the (deprecated) `/libraries` symlink to `/packages` is only supported at the old http://darcs.haskell.org/ Git repo location. Finally, the new Gitweb interface[2] to the GHC Git repos should have become accessible for everyone (w/o hacking `/etc/hosts`). Cheers, hvr [1]: http://ghc.haskell.org/trac/ghc/wiki/GitolitePlan [2]: http://git.haskell.org/

3 5

Advice about TcDeriv
by Joachim Breitner 20 Aug '13

20 Aug '13

Hi, to support deriving NT instances properly, TcDeriv needs to be modified. But there are some structural obstacles: So far, all classes which had to be had the “type of interest” as their only type argument. Therefore, DerivSpec, the data structure in that file, carries information about what instances to derive, in the field dc_tc :: TyCon. But with NT it is different: * It has two parameters, * the type of interest is likely not the last parameter (e.g. NT Age Int) * and it can happen that there is a type variable in the last parameter (e.g. NT Int a => NT Age a). All that is difficult to squeeze into the existing data structure. The data type also has the ds_tys :: [Type] parameter, which contains all type parameters to the class (e.g. [Int, a]). So at first I thought about simply removing dc_tc and use the data from (last ds_tys) whenever needed. But in the case of type families, ds_tc is not just the type constructor of (last ds_tys), but rather what it resolves to. So before I rewrite lots of code there, I’d like to get some advice: Should I extend the DerivSpec to support multi-parameter-typeclasses (and figure out how to support data families here), or rather bypass the whole lot and handle NT instance generation separately? Or is there maybe another, more elegant way? Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 4

RE: lambda mining
by Simon Peyton-Jones 19 Aug '13

19 Aug '13

(devs: this thread is about adding useful new benchmarks to nofib.) Oh bother. I'd forgotten about dependencies. I don't want to make building nofib depend on libraries other those in GHC anyway (bytestring, unix ok, asynch perhaps not). If that makes it tricky, maybe we should give up on the idea. S From: José Pedro Magalhães [mailto:jose.pedro.magalhaes@cs.ox.ac.uk] Sent: 05 August 2013 08:41 To: Simon Peyton-Jones Subject: Re: lambda mining I'm not entirely sure how to do that, though. Do I just add it to the "real" subset? How about dependencies (e.g. bytestring >= 0.9, unix >= 2.5.0, async >= 2.0.0.0, ...) Cheers, Pedro On Fri, Aug 2, 2013 at 9:02 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: great! Just add it :-) simon From: José Pedro Magalhães [mailto:jpm@cs.ox.ac.uk<mailto:jpm@cs.ox.ac.uk>] Sent: 30 July 2013 07:48 To: Simon Peyton-Jones Cc: Nicolas Wu; Wouter Swierstra; Jeroen Bransen Subject: Re: lambda mining Hi Simon, (CC-ing co-authors) Yes, I think it might work fine. Its running time can also be adjusted easily, depending on the maps given as input and some internal parameters. How would we go about adding it to nofib? Thanks, Pedro On Tue, Jul 30, 2013 at 7:04 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Pedro Wandering past your home page I took a look at your "lambda mining" paper. Would it be suitable as a nofib benchmark? Moderate size, authentic code... Would you be interested? Simon

3 4

Non-parallel version of GC
by Edward Z. Yang 19 Aug '13

19 Aug '13

Hello all, How would people feel about an alternate GC implementation in GHC which is not parallel? A GC like this would be simpler to understand, maybe a little faster when parallel collection is not being used, and (most importantly for my case) easier to extend with interesting features. In particular, this implementation would not have gen_workspace or gc_thread; these would either be unnecessary or folded directly into the actual generation object. Thanks, Edward

2 3

Literal overflow test fails
by Simon Peyton-Jones 19 Aug '13

19 Aug '13

On 32 bit Windows I get this (with HEAD). libraries\Win32\Graphics\Win32\GDI\HDC.hs:145:14: Warning: Literal 2147483648 of type Int overflows The offending code is: setTextCharacterExtra dc extra = failIf (== 0x80000000) "SetTextCharacterExtra" $ c_SetTextCharacterExtra dc extra The new literal-overflow test objects to 0x80000000 :: Int. I'm not sure if it should object; in this case we are deliberately using the bit-pattern for minBound. Also what happens on a 64-bit architecture? What should the behaviour here be? - should we use minBound here? - what should the new literal-overlflow code do for 0xblah constants? This is currently breaking the HEAD build. Simon

4 4

Wired-in type class
by Joachim Breitner 19 Aug '13

19 Aug '13

Dear List, I have some questions about the inner parts of GHC, where I need to learn a lot. This is related to my attempts on newtype casting, but should probably be kept separate from the conceptual discussions. Say I need to create a wired-in type class, because it cannot be represented in Haskell. The Core type constructor that will come out of it will have one field of type ~R#, which is the reason why I cannot write it in Haskell. It seems that defining something wired-in is not a very local operation that affects, at least primops.txt.pp and TysPrim.lhs. Does it affect more? It seems that there is not precedent of a wired-in type class. Is that possible without touching too many parts of the compiler? Or is it saner to just have "class NT a b" in a module in ghc-prim without the constraint and use special magic when compiling that file to add the required field to the data constructor representing the class? (Similar to how the kind of ~ is adjusted during compilation?) Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

4 7