March 2013 - ghc-devs

Per-generation lists of weak pointers
by Akio Takano 19 Apr '13

19 Apr '13

Hi, I'm working on implementing per-generation lists of weak pointers to speed up garbage collection in programs that allocate a lot of weak pointers. I have a patch [1] that validates and gives a 3x speed up on a benchmark. However I'd like to ask for some advise before finishing and submitting the patch. [1] https://github.com/takano-akio/ghc/commit/c7345c68eaa1e7f9572e693b5e352e386… The problem is that since my patch splits the weak pointer list between generations, it no longer maintains the right order of weak pointers. This could cause finalizers added with addForeignPtrFinalizer to run in the wrong order. I can think of one way to fix it; to make sure that when a WEAK object gets promoted, it is always added to the front of the new list. So my questions are: - Would it be a correct fix? - If so, is it an acceptable fix? For example, is it too fragile a reasoning to rely on? Thank you in advance, Takano Akio

3 5

upstream repos and wiki's "Workflow with validate"
by Nicolas Frisby 15 Apr '13

15 Apr '13

Hi all. I'm prepping for my first GHC commit, so I'm paying attention to all the details. I'm following the workflow described here http://hackage.haskell.org/trac/ghc/wiki/WorkingConventions/Git#Workflowwit… And I have a couple questions. Ultimately, I'm wondering if I'm doing something wrong or if those commands on that wiki page are either out-of-date or don't list some prerequisites. Question #1 When I run ./sync-all new The output shows lots of commits from the upstream repositories. * Is there a sync-all switch to avoid that somehow? * Is ./sync-all push going to push those? That'd be bad. Question #2 I omit dph from my working tree. Consequently, I think, sync-all in the validate tree chokes on some of the commands from that's wiki page's workflow (eg ./sync-all new). This choking prevents it from executing the command on the repos that come after dph in the list (ie the top-level GHC repo). Adding --no-dph doesn't seem to help here. Are there any known pitfalls here that I may have tripped into? Or perhaps some flags I could add to my command lines? Else, it seems that adding dph to my working repo is necessary for validation with this suggested workflow. Thank you for your time.

2 1

RE: Crash on Windows with large data
by Simon Peyton-Jones 14 Apr '13

14 Apr '13

Yitz and others | Would you and your team be interested in looking at this? In principle yes of course. I wish we had a "team", as in a bunch of people whose job it is to make GHC fantastic. However we certainly do have a team of volunteers who do amazing things; and one (totally heroic and overworked) Ian Lynagh who really does have it as his job. So in practice it might be harder. Does anyone feel able to help Yitz? Ian might, depending on how hard it was to put him into a position where he could reproduce it. Plus it depends on how critical it is for you. Simon | -----Original Message----- | From: sefer.org(a)gmail.com [mailto:sefer.org@gmail.com] On Behalf Of | Yitzchak Gale | Sent: 21 March 2013 21:03 | To: Simon Peyton-Jones | Subject: Crash on Windows with large data | | Hi Simon, | | At work, we have an app that ran into a BEX64 crash on Windows when | processing a large and complex data set. I compiled a special version of | our app with GHC 7.6.2 for Windows, because we suspect it needs to run | on 64 bits. | | On Linux, the same app compiled with 7.4.2 runs to completion when | processing the same data, although it does use as much as 15 GB of | memory in the process. The Windows version crashed when it hit something | over 5 GB or memory usage. | | Would you and your team be interested in looking at this? | | The problem is, both our app and our customer's data is proprietary. | The customer is a well-know very large corporation. Due to the nature of | the problem, I doubt there is any reasonable way to isolate the problem. | I imagine we would need to send you the original code and data. Is there | some sort of arrangement that can be made for this situation? | | Thanks, | Yitz

4 3

Why do Names defined in the current module lack a module name?
by Johan Tibell 05 Apr '13

05 Apr '13

Hi, I'm writing an app that uses the GHC API to extract names from modules. I've written a little AST traversal that finds all Names in the type-checked AST and writes them to a file. I noticed that every Name defined in the current module (i.e. Names generated for top-level function definitions) lack a module name i.e. nameModule_maybe return Nothing. Why is this? Should I just assume that every time nameModule_maybe return Nothing the module name is in fact the name of the current module being compiled? -- Johan

3 13

Overlapping families (specificity/degrees of freedom)
by Gabor Greif 03 Apr '13

03 Apr '13

Hi Richard, I have a question regarding type families with overlapping syntax. In below example the last two lines are overlapped, so the first gets selected when I present type equality witness to GHC: > help :: Sing (ls :: Inventory a) -> Sing (r :: Inventory a) -> Sing (l :: a) -> Sing (InterAppend ls r l) > help l@(Snoc _ _) (Snoc _ r) one | Just Eq <- isSame r one = Snoc l one --- OKAY > type family InterAppend (l' :: Inventory a) (r' :: Inventory a) (one' :: a) :: Inventory a > type instance where > InterAppend Empty r one = Empty > InterAppend (More ls l) Empty one = Empty > InterAppend (More ls l) (More rs one) one = More (More ls l) one --- 4 degrees of freedom > InterAppend (More ls l) (More rs r) one = More ls l --- 5 degrees of freedom However I cannot manage to trigger the last line when *not* presenting the witness, e.g. in this case: > help l@(Snoc _ _) (Snoc _ _) _ = l --- DOES NOT WORK IIRC, when implementing something like this in Omega, the type function evaluator considered the number of type variables and tried to match the more constrained leg (i.e. preferred less degrees of freedom). Can you give me a hint how this is supposed to work in your implementation? Must I present a type non-equality witness to trigger the fourth leg of InterAppend above? What I am trying to implement is an intersection algorithm for singleton-typed list witnesses, roughly > intersect :: SingEqual (t :: a) => Sing (lhs :: '[a]) -> Sing (rhs :: '[a]) -> Sing (Intersect lhs rhs) ... but I am not there yet, obviously! I'd be grateful for any hint, cheers, Gabor

3 5

build failure on FreeBSD 9.1
by Kazu Yamamoto 02 Apr '13

02 Apr '13

Hi, GHC head cannot be build on FreeBSD 9.1: ---- libraries/hpc/ghc.mk:3: libraries/hpc/dist-boot/build/.depend-v.haskell: No such file or directory compiler/ghc.mk:426: compiler/stage1/build/.depend-v.haskell: No such file or directory "cp" -p utils/hsc2hs/dist/build/tmp/hsc2hs inplace/lib/bin/hsc2hs utils/hsc2hs/ghc.mk:15: *** Do not know how to prependLibraryPath on freebsd. Stop. gmake: *** [all] Error 2 ---- I can build GHC head on Linux. --Kazu

3 19

[poll] ghc --make extension
by Sergei Trofimovich 29 Mar '13

29 Mar '13

Hi guys! Today I've tried to write a minimal [1] test case for ghc on ia64 (it SIGSEGVs there). The test case consists of a .cmm and some .hs modues. I tried to build them in one run as: $ ghc --make Test.hs TestPrim.hs test-prims.cmm -o t ghc: cannot compile this file to desired target: test-prims.cmm Usage: For basic information, try the `--help' option. Thus had to use ${GHC} -c test-prims.cmm ${GHC} --make test-prims.o Test.hs TestPrim.hs What do you think of allowing to use .c, .cmm and similar files along with .hs files to make one-shot builds a bit easier? If noone is opposed I'll fill a request on bugtracker. Thanks! [1]: https://github.com/trofi/cmm-example -- Sergei

2 1

upcoming changes to ticky profiling
by Nicolas Frisby 29 Mar '13

29 Mar '13

I'm soon to commit some improvements/extensions to ticky-ticky profiling, including changing the format of the ticky report. (To be clear, I'm referring to the file foo generated by +RTS -rfoo -RTS, having used the -ticky compiler flag). Please let me know if your workflow makes any assumptions about the format of the ticky profiling report (eg the current fixed column widths). Please also let me know if there are any particular counters you would like to have enabled; if it's straight-forward, I'd be happy to while I'm in there.

1 1

Stability of Uniques
by Edsko de Vries 29 Mar '13

29 Mar '13

Hi all, Consider the very simple test module Test2 where f = True When walking the AST after renaming I see that f has unique 1912603236 and True has unique 905969694. However, when walking the typechecked AST f seems to have unique 1627390565 instead. Should I expect that the unique associated with identifiers changes between renaming and typechecking? Or is there something else that I'm missing? Thanks! Edsko

2 4

Re: [commit: ghc] master: Track subrepos Cabal (cc097a4)
by Ian Lynagh 27 Mar '13

27 Mar '13

Hi Gabor, On Wed, Mar 20, 2013 at 02:38:27PM -0700, Gabor Greif wrote: > > commit cc097a43c851891c7a1535d2082c7e392230123d > Author: Gabor Greif <ggreif(a)gmail.com> > Date: Wed Mar 20 22:37:43 2013 +0100 > > Track subrepos Cabal If I'm understanding right, this adds a GHC-only patch to fix a couple of typos. Thanks you for your many typo fixes, but in the case of submodules this sort of patch should be sent upstream instead; that way less effort is needed overall, and there is no chance that the patches will be lost when we resync with upstream. We only make GHC-only patches when they are necessary to keep the build working. Thanks Ian

2 3