Re: Safe haskell issues building HEAD using 7.2.1

Does trusting all of base mean we trust System.IO.Unsafe? Or is there an explicit "DO NOT TRUST THIS MODULE" attached to it somehow? On Wed, Sep 7, 2011 at 6:13 PM, David Terei wrote: > On 6 September 2011 20:33, Corey O'Connor wrote: > > I'm running into a lot of issues like the following: > >

Re: Any way to compile an old version from git?

Aren't the fingerprints effectively the same as what git submodules already do? If we're going to start recording fingerprints, why not just move to using submodules for the dependent repositories? On Mon, May 23, 2011 at 10:39 AM, David Peixotto wrote: > > On May 22, 2011, at 9:16 PM, Erik de C

Re: Array copy primops

Oh, and obviously it could replace newArray#, which would just be using (\_ -> k) as the function. Is the optimization machinery clever enough to see the constant function on a primop boundary and fold it in? On Sat, Jan 29, 2011 at 7:42 PM, Daniel Peebles wrote: > In a slightly related pr

Re: Array copy primops

function to get elements. This would again be to avoid the initialization cost for large arrays, but provides a way more flexible interface than the clones (which could be implemented in terms of it, but not as quickly). On Tue, Jan 25, 2011 at 5:05 PM, Daniel Peebles wrote: > So, to summariz

Re: Array copy primops

On Tue, Jan 25, 2011 at 5:22 PM, Roman Leshchinskiy wrote: > On 25/01/2011, at 22:05, Daniel Peebles wrote: > > > Roman: I'm thinking that even in the absence of GC during foreign calls, > it still seems worthwhile to provide the plain copying primitives, if only > to save

Re: Array copy primops

So, to summarize what you guys have been talking about, it's looking like the primops would become: copyArray#::Array# a -> Int# -> MutableArray# s a -> Int# -> Int# -> State# s -> State# s copyMutableArray# :: MutableArray# a -> Int# -> MutableArray# s a -> Int# -> Int# -> State#

Array copy primops

Hi, Johan Tibell and I have been working on some new primops for GHC that would allow people to use fast optimized memcpys on unpinned memory. Some preliminary benchmarks have shown that on my Mac, a memcpy-based array copy is about 4x faster than a Haskell-based loop doing the same thing. The use

Re: RFC: migrating to git

I fully support this (especially if it lived on github), but we should probably sort the top contributors to GHC in the past year or so and consider their opinions on the matter in that order :) I certainly would not be on that list. A git(hub)-based workflow would however facilitate any minor cont

Re: Adding some gmp bindings to integer-gmp (with a little bit of baggage)

Hi Sean, I added this patch as a ticket a few days ago after your suggestion, but forgot to mention it here. The ticket is at http://hackage.haskell.org/trac/ghc/ticket/3489 Thanks, Dan On Tue, Sep 1, 2009 at 6:53 AM, Sean Leather wrote: > Hi Daniel, > >> >> Basically, I added cmm bindings to m

Adding some gmp bindings to integer-gmp (with a little bit of baggage)

Hi all, this is my first patch for GHC, so I apologize in advance if I do something wrong! I've actually attached three patches for libraries/base, libraries/integer-gmp, and libraries/integer-simple, but because there is no change to any exposed API and only a couple of extra functions added to G

(Big?) Issue with a GMP FFI replacement

Hi again, I've been working on the GMP "disengagement" recently, and have a fully functional GHC without a trace (no GMP primops, nothing related to them) of GMP in it now (using integer-simple as a replacement). I also, as part of a separate endeavor, have an FFI-based GMP library with bindings a

stgAllocForGMP and friends

Hi all, I'm almost done with a FFI-based GMP binding (an attempt to remove GHC's dependence on GMP primops). Currently I'm just using the default GMP allocation functions (malloc/realloc/free), but it's tempting to do as the current setup does and tell GMP to use the GHC allocator. I have some que

Re: validate fails

For what it's worth, I'm getting the same error (with a partial get from this morning) on Mac OS X. Here's a paste of the output of those make show VALUE you asked for: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=4748#a4748 Thanks, Dan On Sat, May 9, 2009 at 9:27 AM, Ian Lynagh wrote: > On Sa

Re: x86_64 ghc on Mac OS

On Mon, Feb 23, 2009 at 8:05 PM, Ben Lippmeier wrote: > > On 24/02/2009, at 11:37 AM, Daniel Peebles wrote: >> >> I was told in #ghc on freenode to start with an unregistered build, >> but that seems to fail in compiler/main/DynFlags.hs, as the Platform >> module d

x86_64 ghc on Mac OS

on where to get started are welcome! Thanks, Daniel Peebles ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc