heap profiling and name truncation

I'm trying to use the built-in ghc heap profiling and running into a large roadblock: the names of producers are truncated, often into uselessness, and there doesn't seem to be an option to control this. Am I missing something in the docs? Abe ___

Re: explicit signatures and default for integer literals

Ghc can't assume in this context - the object file produced by compilation could be linked into code that provides other instances. Abe On 5/31/05, Dinko Tenev [EMAIL PROTECTED] wrote: On 5/31/05, robert dockins [EMAIL PROTECTED] wrote: Dinko Tenev wrote: First we observe that, g =

limited-scope retry?

Suppose that a program using the Control.Concurrent.STM module had a producer/consumer setup - one thread writing to a channel, the other thread reading from the channel. It seems natural to want a function that the producer can call that will block until the consumer has finished consuming

Re: GADTs and pedagogy was Re: GADTs and fundeps

You mean, if the data type being defined doesn't actually use the generality of GADTs, allow GADT syntax, and deriving() too? Yes, that would be very nice for the HaskellDemo and new users. I'd definitely switch all of my non-GADT datatypes to use that. One worry I have about this is that

Re: Scoped type variables

Please! I've lost count of the number of times when I've written code as f :: a - b f (x :: a) = ... wishing that I didn't have to locally bind the 'a'. I'm not sure I understand the objection raised by Jon; the 'implicit declaration' of type variables in type signatures has never bothered me,

Re: Bug in touchForeignPtr?

If finalizers are not the right thing, what else is? I've found that when writing an interface to a C library that requires resource management, it's much better to use the withX (see Control.Exception.bracket) style of function than to use finalizers - programs are much easier to reason about

overzealous defaulting?

I'm not sure if this is an actual bug, as opposed to an odd instance of defaulting: *GUI.Parser let printQ q = runQ q = print *GUI.Parser :t printQ printQ :: forall a. (Show a) = Q a - IO () *GUI.Parser let p = printQ *GUI.Parser :t p p :: Q Integer - IO () ...but I'm not sure when that would

Re: GHCI/FFI/GMP/Me madness

FWIW, I couldn't reproduce this problem on my system (i.e. str_test always printed 1). GHC 6.2.1, libgmp 4.1.3, debian unstable Abe On Mon, 9 Aug 2004 17:57:14 +0200, Remi Turk [EMAIL PROTECTED] wrote: On Sun, Aug 08, 2004 at 07:34:04AM -0700, Sigbjorn Finne wrote: Hi, please be aware

imports with --make?

Is there any way to use --make but provide paths to search for .hi files, *not* .hs files? For example, if a library doesn't use ghc's package system, and is distributed in precompiled form, there doesn't seem to currently be a way to point ghc at the import files when using --make - it always

Re: Generics... no Tuples 2 either...

I've been frustrated by the same lack of instances; as a stopgap, here's one for a three-tuple. The pattern is pretty clear and can easily be extended to whatever size you'd like. tupCon = mkConstr 1 (,,) Prefix instance (Data a, Data b, Data c) = Data (a, b ,c) where gfoldl k z (a, b, c) =

force garbage collection?

Is there any way to force collection of all unreachable data structures? Abe ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users