Yes, that's my current understanding. I see this with ByteString and
Data.Vector.Storable, but not
Data.Vector/Data.Vector.Unboxed/Data.Text. As ByteStrings are pretty
widely used for IO, I expected that somebody else would have
experienced this too.
I would expect some memory fragmentation with
So the problem is only with the data structures on the heap that are pinned
in place to play nice with C?
I'd be curious to understand the change too, though per se pinned memory (a
la storable or or bytestring) will by definition cause memory fragmentation
in a gc'd lang as a rule, (or at least
Hello,
We've noticed that some applications exhibit significantly worse
memory usage when compiled with ghc-7.6.1 compared to ghc-7.4, leading
to out of memory errors in some cases. Running one app with +RTS -s,
I see this:
ghc-7.4
525,451,699,736 bytes allocated in the heap
53,404,833,048 by
Hello,
perhaps we should have a well-defined place in the repo where we keep the
finger-prints associated with tags and branches in the main repo?
This would make it a lot easier to get to a fully defined
previous/different state.
On this note, could someone send the link to the 7.6 fingerprint?
Well, it doesn't quite have the same drawbacks as submodules, because our solution places a burden
only on someone who wants to recover a particular repository state, rather than on everyone doing
development.
I think it's worth keeping an eye on submodules in case they fix the gotchas in the U
On 19/09/2012 02:15, Iavor Diatchki wrote:
> exactly what git's submodule machinery does, so it seems pointless to
> implement the functionality which is already there with a standard
> interface. Thoughts?
http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Theperspecti
The missing dataCast1 is just a bug, yes. I suppose someone who uses Bag
and cares can submit something about fixing gunfold.
On Thu, Sep 20, 2012 at 7:22 AM, José Pedro Magalhães wrote:
> Right now I was just planning to fix the missing dataCast1 from Bag, and
> the rest from
> Data.Data (see h
Right now I was just planning to fix the missing dataCast1 from Bag, and
the rest from
Data.Data (see http://hackage.haskell.org/trac/ghc/ticket/7256). I think
those are just
a bug, unrelated to the abstraction story, no?
Cheers,
Pedro
On Thu, Sep 20, 2012 at 12:19 PM, Edward Kmett wrote:
> No
Note: It was probably built with an eye towards how Data.Map and the like
performed abstraction. However, This isn't necessary to protect the
invariants of a bag.
The constructors exposed via Data do not have to be the actual constructors
of the data type. With this you can quotient out the portio
On 20 Sep 2012, at 09:40, José Pedro Magalhães wrote:
instance Data a => Data (Bag a) where
gfoldl k z b = z listToBag `k` bagToList b -- traverse abstract type
abstractly
toConstr _ = abstractConstr $ "Bag("++show (typeOf (undefined::a))++")"
gunfold _ _ = error "gunfold"
dataTypeOf _
On Wed, Aug 29, 2012 at 12:01 PM, Philip Holzenspies
wrote:
> Dear GHCers,
>
> I'm performing traversals over GHC-API results (HsSyn et al). For this
> purpose, I'm using SYB generics.
>
> I found that I couldn't use "ext1Q" for a function with type "Data x =>
> Bag x -> String", i.e. that this fu
11 matches
Mail list logo
