- ghc-devs - Haskell.org

Re: [commit: testsuite] master: linker_unload fails when using dynamic GHCi. (a5875c4)
by Simon Marlow 22 Aug '13

22 Aug '13

On 22/08/13 19:24, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/testsuite > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/a5875c4e4fb83993142c8e8294b47516a… > >> --------------------------------------------------------------- > > commit a5875c4e4fb83993142c8e8294b47516adf6a77f > Author: Austin Seipp <aseipp(a)pobox.com> > Date: Thu Aug 22 13:22:22 2013 -0500 > > linker_unload fails when using dynamic GHCi. > > This is because dynamic GHCi can't load archive files, and linker_unload > explicitly does this via loadArchive(). Sigh. I've no idea why the linker has an explicit check for this, there's no reason why it can't work. I'll fix it. Cheers, Simon

2 1

Validate failures
by Austin Seipp 22 Aug '13

22 Aug '13

Simon, While validating the changes for #8144, I noticed there were several failures that seem like a result of your recent commits (amd64/Linux): Unexpected failures: . T4059 [bad stderr] (normal) . T4850 [bad stderr] (normal) . T5423 [bad stderr] (normal) . T7037 [bad stderr] (normal) . atomicinc [exit code non-0] (normal) . outofmem [bad stderr] (normal) . outofmem2 [bad stderr] (normal) I see several of the these fail, like: =====> T7037(normal) 1205 of 3760 [0, 6, 0] cd ./rts && $MAKE -s --no-print-directory T7037 </dev/null >T7037.run.stdout 2>T7037.run.stderr Actual stderr output differs from expected: --- /dev/null 2013-08-15 19:58:16.771097011 -0500 +++ ./rts/T7037.run.stderr 2013-08-22 13:27:33.531638515 -0500 @@ -0,0 +1 @@ +Makefile:74: xxx/home/a/ghc/ghc-pristine/libraries/base/dist-install/buildxxx *** unexpected failure for T7037(normal) This is because in 269c89062dd5b6d2b8bc4d41e5dca0eca2308d02, you added: +$(warning xxx$(BASE_DIR)xxx) Which I presume is perhaps left-over debugging cruft? I also see this failure: $ make TEST="atomicinc" ... =====> atomicinc(normal) 15 of 41 [0, 0, 0] cd . && '/home/a/ghc/ghc-pristine/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -o atomicinc atomicinc.c -no-hs-main >atomicinc.comp.stderr 2>&1 Compile failed (status 256) errors were: Warning: -rtsopts and -with-rtsopts have no effect with -no-hs-main. Call hs_init_ghc() from your main() function to set these options. atomicinc.o: In function `main': atomicinc.c:(.text+0x20): undefined reference to `atomic_inc' atomicinc.c:(.text+0x60): undefined reference to `atomic_dec' collect2: error: ld returned 1 exit status But I'm not sure what's causing it, since this hasn't been touched in a while. -- Regards, Austin - PGP: 4096R/0x91384671

2 3

DPH tests
by Jan Stolarek 22 Aug '13

22 Aug '13

When I do full testsuite run (either with 'make fulltest' or './validate --slow') there is a bunch of DPH tests which take Very Long Time to run (approx. half of the time needed to run testsuite, if not more). These tests are consistently failing. What would DPH team and others say to disabling these tests temporarily? I think that since February there hasn't been much going on in the DPH repository and compiler/vectorize folder. We'd have thhese tests enabled again when work on DPH picks up again. Janek

3 4

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