(I am not sure, if keeping the cc to libraries is ok, apologies in
case it is not.)
On Mon, Jul 19, 2004 at 06:23:21PM -0700, John Meacham wrote:
> I am curious what the best way to go about writing specialized versions
> is,
> placing the copying functions in a class, with (slow) default method
On Tue, Jul 20, 2004 at 02:56:15AM +0200, Carsten Schultz wrote:
> On Thu, Jul 15, 2004 at 04:26:27AM -0700, John Meacham wrote:
> > I am thinking a family of routines. (with psuedosignatures)
> >
> > copySpan: range -> MArray -> whereto -> MArray -> m ()
> > extractSpan : range -> IArray -> IArra
On Thu, Jul 15, 2004 at 04:26:27AM -0700, John Meacham wrote:
> I am thinking a family of routines. (with psuedosignatures)
>
> copySpan: range -> MArray -> whereto -> MArray -> m ()
> extractSpan : range -> IArray -> IArray
> extractSpanM : range -> MArray -> m IArray
> saveSpan : range -> IArray
> Feedback welcome as usual - I've probably forgotten lots of stuff on
> these lists.
>
> Cheers,
> Simon
Hi Simon,
Since you are working on the backend is there any chance that GHC could
support symbol names in the heap?
I tried to add this previously and failed miserably.
I would be ha
"Simon Marlow" <[EMAIL PROTECTED]> writes:
> - completely new back-end (post-STG) based on a C-- intermediate
> language, including a largely rewritten native code generator.
I'm looking forward to this.
> - generalised algebraic data types (currently in development, might
> not make
On 19 July 2004 14:20, Shae Matijs Erisson wrote:
>> - generalised algebraic data types (currently in development, might
>> not make it into the release).
>
> What does this mean exactly?
http://research.microsoft.com/Users/simonpj/papers/gadt/index.htm
> Ian Lynagh has built ghc-cvs debs
This message is to keep everyone updated on our future release plans.
We are currently planning two new releases around the end of August: one
from the STABLE branch and one from the HEAD.
STABLE: 6.2.2
-
This will be the final release from the 6.2 branch, containing bugfixes
only rel
On 17 July 2004 05:31, John Meacham wrote:
> So, I was looking at the implementation of ForeignPtr's in an attempt
> to
> determine why they were slow, and have an idea to speed them up..
>
> right now we have:
>
> ForeignPtr a
> = ForeignPtr ForeignObj# !(IORef [IO ()])
> | MallocPtr (Muta
On 17 July 2004 01:47, John Meacham wrote:
> so, ByteArray# seems to be equivalant to a raw pointer in speed, with
> the advantage that it is garbage collected.
>
> however foreignptrs are twice as slow! and even slower than an IORef.
Were you using mallocForeignPtr here? Or newForeignPtr?
> a
