Re: ANN: H98 FFI Addendum 1.0, Release Candidate 7

2002-09-26 Thread Alastair Reid
> We have four alternatives: > (1) We leave everything as it is. If you want malloc-type storage > that you can free in a finaliser, you need to write your own > interface to C's malloc() and free(). I think this approach misses the reason we provide MarshalAlloc in the first place. > (2) We

Re: ANN: H98 FFI Addendum 1.0, Release Candidate 7

2002-09-23 Thread Manuel M T Chakravarty
Ross Paterson <[EMAIL PROTECTED]> wrote, > On Sun, Sep 22, 2002 at 02:54:44PM +1000, Manuel M T Chakravarty wrote: > > Ross Paterson <[EMAIL PROTECTED]> wrote, > > > > > Alastair Reid <[EMAIL PROTECTED]> wrote: > > > > I guess the issue is that if someone wanted to use MarshalAlloc.free > > > >

Re: ANN: H98 FFI Addendum 1.0, Release Candidate 7

2002-09-22 Thread Ross Paterson
On Sun, Sep 22, 2002 at 02:54:44PM +1000, Manuel M T Chakravarty wrote: > Ross Paterson <[EMAIL PROTECTED]> wrote, > > > Alastair Reid <[EMAIL PROTECTED]> wrote: > > > I guess the issue is that if someone wanted to use MarshalAlloc.free > > > as a finalizer they would not be able to do so. Since

Re: ANN: H98 FFI Addendum 1.0, Release Candidate 7

2002-09-21 Thread Manuel M T Chakravarty
Ross Paterson <[EMAIL PROTECTED]> wrote, > Alastair Reid <[EMAIL PROTECTED]> wrote: > > I guess the issue is that if someone wanted to use MarshalAlloc.free > > as a finalizer they would not be able to do so. Since we don't > > guarantee that MarshalAlloc.malloc is "stdio.h malloc", they couldn'

Re: ANN: H98 FFI Addendum 1.0, Release Candidate 7

2002-09-20 Thread Ross Paterson
Alastair Reid <[EMAIL PROTECTED]> wrote: > I guess the issue is that if someone wanted to use MarshalAlloc.free > as a finalizer they would not be able to do so. Since we don't > guarantee that MarshalAlloc.malloc is "stdio.h malloc", they couldn't > portably cons up a compatible &free. Yes, yo

Re: ANN: H98 FFI Addendum 1.0, Release Candidate 7

2002-09-19 Thread Alastair Reid
> ... maybe I'm being stupid, but I don't see what the problem is. > Why can't mallocForeignPtr be implemented as: > mallocForeignPtrBytes size = do > r <- c_malloc (fromIntegral size) > newForeignPtr r ptr_c_free > > foreign import ccall unsafe "malloc" > c_malloc :: CInt -> Pt

RE: ANN: H98 FFI Addendum 1.0, Release Candidate 7

2002-09-19 Thread Simon Marlow
> > > RC 7 of the FFI Addendum is now available from > > > > In adding mallocForeignPtr and friends to Hugs, I found > that I needed > > the address of free to pass as a parameter. > > > > There's no suitable way to generate &free from > MarshalAlloc.free (the > > obvious use of a Haskell wra

Re: ANN: H98 FFI Addendum 1.0, Release Candidate 7

2002-09-19 Thread Manuel M T Chakravarty
Alastair Reid <[EMAIL PROTECTED]> wrote, > > RC 7 of the FFI Addendum is now available from > > In adding mallocForeignPtr and friends to Hugs, I found that I needed > the address of free to pass as a parameter. > > There's no suitable way to generate &free from MarshalAlloc.free (the > obvious

Re: ANN: H98 FFI Addendum 1.0, Release Candidate 7

2002-09-18 Thread Alastair Reid
> RC 7 of the FFI Addendum is now available from In adding mallocForeignPtr and friends to Hugs, I found that I needed the address of free to pass as a parameter. There's no suitable way to generate &free from MarshalAlloc.free (the obvious use of a Haskell wrapper would break the whole reason