Glasgow-haskell-users

Download

glasgow-haskell-users@haskell.org

June 2011

41 participants
32 discussions

Addr# field in ForeignPtr
by Roman Leshchinskiy 01 Jun '11

01 Jun '11

Hi all, GHC defines ForeignPtr as: data ForeignPtr a = ForeignPtr Addr# ForeignPtrContents -- we cache the Addr# in the ForeignPtr object, but attach -- the finalizer to the IORef (or the MutableByteArray# in -- the case of a MallocPtr). The aim of the representation -- is to make withForeignPtr efficient; in fact, withForeignPtr -- should be just as efficient as unpacking a Ptr, and multiple -- withForeignPtrs can share an unpacked ForeignPtr. Note -- that touchForeignPtr only has to touch the ForeignPtrContents -- object, because that ensures that whatever the finalizer is -- attached to is kept alive. Is it ok to modify the Addr# field? Or do the libraries assume that it always points to the start of the block described by ForeignPtrContents? Changing the Addr# field would be quite useful for pointing to the middle of a memory block. For instance, Storable vectors are currently defined as: data Vector a = Vector {-# UNPACK #-} !(Ptr a) {-# UNPACK #-} !Int {-# UNPACK #-} !(ForeignPtr a) If I could use the Addr# field of the ForeignPtr, I could get rid of the Ptr. Alternatively, I could define my own version of ForeignPtr if only ForeignPtrContents was exported (abstractedly would be enough). Roman

2 1

testsuite, failures galore
by Daniel Fischer 01 Jun '11

01 Jun '11

So my last testsuite run (validate --slow) with a new HEAD produced 651 unexpected failures :( Okay, the thing is that I forgot to add EXTRA_HC_OPTS=-optl-lz, see http://hackage.haskell.org/trac/ghc/ticket/3756 So, unless I miscounted, 611 of those were in way threaded1 due to: > Linking arrowrun001 ... > /usr/lib/gcc/i586-suse-linux/4.5/../../../libbfd.a(compress.o): In > function `bfd_uncompress_section_contents': > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:96:0: > undefined reference to `inflateInit_' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:106:0: > undefined reference to `inflateReset' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:103:0: > undefined reference to `inflate' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:108:0: > undefined reference to `inflateEnd' > > collect2: ld gab 1 als Ende-Status zurück > > *** unexpected failure for arrowrun001(threaded1) The ticket has low priority, but if anybody has an idea how to check whether libbfd depends on libz in the configure script, I'd appreciate it. Of the remaining 40 unexpected failures, 14 were due to the removal of datatype contexts (tcrun006 and tcrun029), 7 (tcrun007) were due to a parse error because -XGenerics does nothing anymore (so ghc couldn't parse "{|"), 3 due to a missing Show instance in dph. The remaining may or may not be serious, looking at them now.

3 10