- ghc-devs - Haskell.org

What promotes to (* :: BOX) ?
by Gabor Greif 24 Apr '13

24 Apr '13

Hi devs! I guess I found a gap in the promotion mechanism: > data Prom1 = Symic Symbol gets promoted to to a kind (Prom1 :: BOX) with (Symic "AAA" :: Prom1). So far so good. But how can I define by promotion (Prom2 :: BOX) with (Typic Int :: Prom2) ? I'd like to write > data Prom2 = Typic Type but haven't found such a beast in TypeLits. So my question is basically, which type-level identifier promotes to (* :: BOX) when mentioned in a `data` definition? I am thankful for any hints! Cheers, Gabor

5 7

Re: Proxy, new Typeable, and type-level equality
by Richard Eisenberg 24 Apr '13

24 Apr '13

I have updated the wiki page at http://hackage.haskell.org/trac/ghc/wiki/TypeLevelReasoning with these ideas. If you have further thoughts on all of this, please update that page and send an email out so we know to look at the changes! My timeline for implementing all of this (not hard, but it needs to be done) is around the end of the month. Thanks, Richard On Apr 4, 2013, at 11:11 AM, Edward A Kmett <ekmett(a)gmail.com> wrote: > Note the eq lib and the type-eq/(:~:) GADT-based approach are interchangeable. > > You can upgrade a Leibnizian equality to a type equality by applying the Leibnizian substitution to an a :~: a. > > lens also has a notion of an Equality family at the bottom of the type semilattice for lens-like constructions, which is effectively a naked Leibnizian equality sans newtype wrapper. > > The only reason eq exists is to showcase this approach, but in practice I recommend just using the GADT, modulo mutterings about the name. :) > > That said those lowerings are particularly useful, if subtle -- Oleg wrote the first version of them, which I simplified to the form in that lib and they provide functionality that is classically not derivable for Leibnizian equality. > > Sent from my iPhone > > On Apr 4, 2013, at 3:01 AM, Erik Hesselink <hesselink(a)gmail.com> wrote: > >> On Wed, Apr 3, 2013 at 6:08 PM, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: >>> Comments? Thoughts? >> >> Edward Kmett 'eq' library uses a different definition of equality, but >> can also be an inspiration for useful functions. Particularly, it >> includes: >> >> lower :: (f a :~: f b) -> a :~: b >> >> Another question is where all this is going to live? In a separate >> library? Or in base? And should it really be in a GHC namespace? The >> functionality is not bound to GHC. Perhaps something in data would be >> more appropriate. >> >> Erik >> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org >> http://www.haskell.org/mailman/listinfo/libraries >

2 2

Re: Per-generation lists of weak pointers
by Akio Takano 24 Apr '13

24 Apr '13

Thank you very much for your help, I just updated the patches on the ticket. On Sun, Apr 21, 2013 at 10:50 AM, Edward Z. Yang <ezyang(a)cs.stanford.edu>wrote: > In your ticket, you mention this patch introduces a race condition. One > possible fix is to have addCFinalizerToWeak# check if the pointer is > already > dead, and just run the finalizer immediately if it is. I think this > preserves the semantics, but this needs to be checked closely. > > Edward > > Excerpts from Akio Takano's message of Fri Apr 19 02:58:50 -0700 2013: > > I removed the invariant by adding a new primop, addCFinalizerToWeak#. I > > opened a ticket for the issue. > > > > http://hackage.haskell.org/trac/ghc/ticket/7847 > > > > - Akio > > > > On Thu, Mar 21, 2013 at 2:40 PM, Simon Marlow <marlowsd(a)gmail.com> > wrote: > > > > > On 11/03/13 03:17, Akio Takano wrote: > > > > > >> 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/** > > >> c7345c68eaa1e7f9572e693b5e352e**386df7d680< > 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? > > >> > > > > > > I don't like the way that we rely on the ordering of the weak pointer > list > > > right now. I think this invariant arose accidentally when the support > for > > > C finalizers was added. It was wrong for some time, see: > > > > > > http://hackage.haskell.org/**trac/ghc/ticket/7160< > http://hackage.haskell.org/trac/ghc/ticket/7160> > > > > > > and as per my comments in that commit log, I think we should do it > > > differently. I don't know how hard that would be though. > > > > > > Incidentally, I implemented per-generation weak pointers in the > local-gc > > > branch, but didn't get around to porting it back over into the > mainline (I > > > still have a ToDo for that). My version probably has the ordering > bug, but > > > you could always look at the branch to see how my approach compares to > > > yours. > > > > > > Cheers, > > > Simon > > > > > > >

1 0

installing primitive and vector
by Kazu Yamamoto 23 Apr '13

23 Apr '13

Hello, When building GHC head, primitive and vector are also compiled. But "make install" does not install them. Are there any way to install primitive and vector in addition to other libraries? --Kazu

2 3

Re: ghc-devs Digest, Vol 116, Issue 39
by Kyle Van Berendonck 22 Apr '13

22 Apr '13

Hi, `Implemented getPageFaults for win32` breaks the build. The patch needs some more stuff added. I'll re-submit it soon-ish after I get it to build correctly. Regards. On Mon, Apr 22, 2013 at 8:00 PM, <ghc-devs-request(a)haskell.org> wrote: > Send ghc-devs mailing list submissions to > ghc-devs(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/ghc-devs > or, via email, send a message with subject or body 'help' to > ghc-devs-request(a)haskell.org > > You can reach the person managing the list at > ghc-devs-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ghc-devs digest..." > > > Today's Topics: > > 1. Re: [commit: ghc] master: Use ffi_prep_closure_loc rather > than ffi_prep_closure (310735e) (Sergei Trofimovich) > 2. Re: [commit: ghc] master: Use ffi_prep_closure_loc rather > than ffi_prep_closure (310735e) (Ian Lynagh) > 3. Re: Fwd: Implemented getPageFaults for win32 (Edward Z. Yang) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 21 Apr 2013 21:34:31 +0300 > From: Sergei Trofimovich <slyich(a)gmail.com> > Subject: Re: [commit: ghc] master: Use ffi_prep_closure_loc rather > than ffi_prep_closure (310735e) > To: ghc-devs(a)haskell.org > Cc: ghc-commits(a)haskell.org > Message-ID: <20130421213431.1b0ecc6c@sf> > Content-Type: text/plain; charset="us-ascii" > > > commit 310735e7adce0145c653386c21686b4a1b96aea9 > > Author: Ian Lynagh <ian(a)well-typed.com> > > Date: Sun Apr 21 16:03:40 2013 +0100 > > > > Use ffi_prep_closure_loc rather than ffi_prep_closure > > > > The latter is deprecated. Part of #7718. > > > > >--------------------------------------------------------------- > > > > rts/Adjustor.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/rts/Adjustor.c b/rts/Adjustor.c > > index fbf95df..e4d6e8c 100644 > > --- a/rts/Adjustor.c > > +++ b/rts/Adjustor.c > > @@ -131,7 +131,7 @@ createAdjustor (int cconv, > > barf("createAdjustor: failed to allocate memory"); > > } > > > > - r = ffi_prep_closure(cl, cif, (void*)wptr, hptr/*userdata*/); > > + r = ffi_prep_closure_loc(cl, cif, (void*)wptr, hptr/*userdata*/, > code); > > if (r != FFI_OK) barf("ffi_prep_closure failed: %d", r); > > The barf() text (/ffi_prep_closure/ffi_prep_closure_loc/) might be > adjusted as well. > > > return (void*)code; > > -- > > Sergei >

1 0

Fwd: Implemented getPageFaults for win32
by Kyle Van Berendonck 22 Apr '13

22 Apr '13

---------- Forwarded message ---------- From: Kyle Van Berendonck <kvanberendonck(a)gmail.com> Date: Sun, Apr 14, 2013 at 5:56 PM Subject: Implemented getPageFaults for win32 To: ghc-devs(a)haskell.org Author: Kyle Van Berendonck <kvanberendonck(a)gmail.com> 2013-04-14 17:45:39 Committer: Kyle Van Berendonck <kvanberendonck(a)gmail.com> 2013-04-14 17:45:39 Parent: 52efb2c8aefbd448e765e62a34c3e53ab7202a11 (No need to map over all blocks, setting up PIC.) Branch: master Follows: ghc-darcs-git-switchover Precedes: Implemented getPageFaults for win32 ----------------------------- rts/win32/GetTime.c ----------------------------- index bfab43a..50a2c4d 100644 @@ -157,6 +157,13 @@ W_ getPageFaults(void) { /* ToDo (on NT): better, get this via the performance data - that's stored in the registry. */ + that's stored in the registry. + + nb: this includes the number of soft page faults, but it's better than nothing + */ + PROCESS_MEMORY_COUNTERS pmc; + if (GetProcessMemoryInfo(GetCurrentProcess(), &pmc, sizeof(pmc))) { + return pmc.PageFaultCount; + } return 0; }

2 1

Re: [commit: ghc] master: Use ffi_prep_closure_loc rather than ffi_prep_closure (310735e)
by Sergei Trofimovich 21 Apr '13

21 Apr '13

> commit 310735e7adce0145c653386c21686b4a1b96aea9 > Author: Ian Lynagh <ian(a)well-typed.com> > Date: Sun Apr 21 16:03:40 2013 +0100 > > Use ffi_prep_closure_loc rather than ffi_prep_closure > > The latter is deprecated. Part of #7718. > > >--------------------------------------------------------------- > > rts/Adjustor.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/rts/Adjustor.c b/rts/Adjustor.c > index fbf95df..e4d6e8c 100644 > --- a/rts/Adjustor.c > +++ b/rts/Adjustor.c > @@ -131,7 +131,7 @@ createAdjustor (int cconv, > barf("createAdjustor: failed to allocate memory"); > } > > - r = ffi_prep_closure(cl, cif, (void*)wptr, hptr/*userdata*/); > + r = ffi_prep_closure_loc(cl, cif, (void*)wptr, hptr/*userdata*/, code); > if (r != FFI_OK) barf("ffi_prep_closure failed: %d", r); The barf() text (/ffi_prep_closure/ffi_prep_closure_loc/) might be adjusted as well. > return (void*)code; -- Sergei

2 1

Re: Per-generation lists of weak pointers
by Edward Z. Yang 21 Apr '13

21 Apr '13

In your ticket, you mention this patch introduces a race condition. One possible fix is to have addCFinalizerToWeak# check if the pointer is already dead, and just run the finalizer immediately if it is. I think this preserves the semantics, but this needs to be checked closely. Edward Excerpts from Akio Takano's message of Fri Apr 19 02:58:50 -0700 2013: > I removed the invariant by adding a new primop, addCFinalizerToWeak#. I > opened a ticket for the issue. > > http://hackage.haskell.org/trac/ghc/ticket/7847 > > - Akio > > On Thu, Mar 21, 2013 at 2:40 PM, Simon Marlow <marlowsd(a)gmail.com> wrote: > > > On 11/03/13 03:17, Akio Takano wrote: > > > >> 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/** > >> c7345c68eaa1e7f9572e693b5e352e**386df7d680<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? > >> > > > > I don't like the way that we rely on the ordering of the weak pointer list > > right now. I think this invariant arose accidentally when the support for > > C finalizers was added. It was wrong for some time, see: > > > > http://hackage.haskell.org/**trac/ghc/ticket/7160<http://hackage.haskell.org/trac/ghc/ticket/7160> > > > > and as per my comments in that commit log, I think we should do it > > differently. I don't know how hard that would be though. > > > > Incidentally, I implemented per-generation weak pointers in the local-gc > > branch, but didn't get around to porting it back over into the mainline (I > > still have a ToDo for that). My version probably has the ordering bug, but > > you could always look at the branch to see how my approach compares to > > yours. > > > > Cheers, > > Simon > > > >

1 0

[PATCH] Stage1Only only builds stage 1
by Trevor Elliott 19 Apr '13

19 Apr '13

Hi Everyone, I created a ticket that includes some changes to allow the Stage1Only flag to only build stage 1. This makes it easier to build cross compilers where the target won't be a suitable environment to actually host a stage 2 compiler. http://hackage.haskell.org/trac/ghc/ticket/7841 Thanks! --trevor

1 0

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