Re: FFI docs

Simon, I started to collect all pending issues concerning the FFI spec on the H' wiki page for the FFI: http://hackage.haskell.org/trac/haskell-prime/wiki/ForeignFunctionInterface There is also another issue concerning newtypes that SimonM brought up a while ago. Manuel > A couple of commen

HTML version of the H98 FFI Addendum

Finally! The Haskell 98 addendum for the Foreign Function Interface 1.0 in HTML format. Browse online or download at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ I apologise for the slowness in producing this format. Manuel PS: XHTML 1.0 with CSS 2.1 produced by tex4ht

Re: Request: withArrayLength

On Tue, 2004-03-23 at 05:55, Sven Panne wrote: > Once upon a time, I wrote: > > Adrian Hey wrote: > > > >> [...] I think.. > >> > >> withArrayLength :: Storable a => [a] -> (Ptr a -> Int -> IO b) -> IO b > >> > >> would be useful because you often need the length in a foreign function > > > > I

ANN: H98 FFI Addendum 1.0, Final Version

Two weeks ago, I wrote, > Release Candidate 16 of the H98 FFI Addendum 1.0 is now > available from [..] > I'd like to propose RC16 as the final form of Version 1.0 of > the FFI Addendum. If you find any problems with this > version, please raise them within the next two weeks. No problems have b

Re: Handle to haskell data

Fergus Henderson <[EMAIL PROTECTED]> wrote, > On 30-Nov-2003, David Waern <[EMAIL PROTECTED]> wrote: > > > > Hi. I want to know if it is possible via FFI and GHC to allocate > > haskell data structures and return some kind of handle to their internal > > representation in the haskell runtime to a

ANN: H98 FFI Addendum 1.0, Release Candidate 16

Dear Haskell Folks, Release Candidate 16 of the H98 FFI Addendum 1.0 is now available from http://www.cse.unsw.edu.au/~chak/haskell/ffi/ Since the last version of the Addendum announced on <[EMAIL PROTECTED]>, namely RC12, the FFI Task Force decided on a slight generalisation of the interface

Re: H98 FFI Addendum 1.0, Release Candidate 15

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > It is true that strictly speaking we don't need to say anything here. > But I think it would be helpful to include a footnote as a guide to > implementors, something along the lines of > >[1] Note that if the platform defines __STDC_ISO_10646__ then

Re: H98 FFI Addendum 1.0, Release Candidate 15

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > And here now a probably naive question of mine: Does the > > notion of Marlow sensibility coincide with platforms that > > follow ISO/IEC 10646? > > We don't want to restrict the standard to sensible systems, because that > rules out Windows :-). W

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

Fergus Henderson <[EMAIL PROTECTED]> wrote, > On 12-Nov-2003, Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote: > > And here now a probably naive question of mine: Does the > > notion of Marlow sensibility coincide with platforms that > > follow ISO/IEC 10646? &

ANN: H98 FFI Addendum 1.0, Release Candidate 15

Release Candidate 15 with all the changes discussed since RC13 is now available from http://www.cse.unsw.edu.au/~chak/haskell/ffi/ The only open problem are a set of questions raised by Simon and Ross to which I have previously answered with another set of questions (see the attached message),

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

Ross Paterson <[EMAIL PROTECTED]> wrote, > You have the bit about unrepresentable Chars becoming '?' in the legacy > byte string part. I think it belongs in locale-dependent CString part. > (I believe the single byte conversion discards all but the lower 8 bits, > though there's probably no need

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

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > I have put RC 14 at > > > > http://www.cse.unsw.edu.au/~chak/haskell/ffi/ > > > > including all the feedback on RC13. Please especially have > > a look at Section 6.3 (Section "CString"), where some of the > > wording changed. > > The spec is sil

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

Ross Paterson <[EMAIL PROTECTED]> wrote, > On Sun, Nov 02, 2003 at 09:31:30PM +1100, Manuel M T Chakravarty wrote: > > Ross Paterson <[EMAIL PROTECTED]> wrote, > > > (That is the Latin-1 subset, so calling them ASCII seems a misnomer.) > > > > Yes, bu

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

I have put RC 14 at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ including all the feedback on RC13. Please especially have a look at Section 6.3 (Section "CString"), where some of the wording changed. Cheers, Manuel ___ FFI mailing list [EMAIL PRO

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

John Meacham <[EMAIL PROTECTED]> wrote, > On Fri, Oct 31, 2003 at 12:32:55PM +, Ross Paterson wrote: > > Making the Right Thing the default, though it may cost more, seems > > appropriate. > > > > In the sentence > > > > The marshalling takes the current Unicode encoding on the > > H

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

Ross Paterson <[EMAIL PROTECTED]> wrote, > In the sentence > > The marshalling takes the current Unicode encoding on the > Haskell side into account. > > (which seems to have been there before), "current" seems wrong, since > the Haskell side is constant. How about something like >

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

Alastair Reid <[EMAIL PROTECTED]> wrote, > > I wonder how this discrepancy between the libraries and the > > report arose. > > For what it's worth, the library has been that way since June 28, 2001: > > http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Foreign/ > Storable.hs?rev=

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

Sven Panne <[EMAIL PROTECTED]> wrote, > Alastair Reid wrote: > > [As I was about to send this, it occured to me that maybe you had made a typo > > and meant to write 'peekByteOff' instead of 'peekElemOff'? This seems less > > dodgy since peekByteOff is more usually used to access elements of st

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

Alastair Reid <[EMAIL PROTECTED]> wrote, > I think it's ok for the finalizer function to delete the environment object if > it wants isn't it? > > This isn't always the right thing to do but I think it is in the common case > that there is a unique environment object for every finalized objec

ANN: H98 FFI Addendum 1.0, Release Candidate 13

Dear FFI Folks, Despite my claim that RC12 would, modulo errata, become Version 1.0 of the FFI Addendum, I like to propose another (last!) set of changes. The two changes are the following: (1) The addition of a variant of foreign finalizers that take an extra environment argument that facil

ANN: H98 FFI Addendum 1.0, Release Candidate 12

Dear Haskell Folks, Release Candidate 12 of the H98 FFI Addendum 1.0 is now available from http://www.cse.unsw.edu.au/~chak/haskell/ffi/ Since the release of RC 11 (12 June), there was only one small change (which was already under discussion before RC 11 was published). Hence, I consider Ver

Re: stdcall

Ross Paterson <[EMAIL PROTECTED]> wrote, > Could the meaning of stdcall be broadened to "the standard calling > convention for libraries on the native system", i.e. pascal on Win32 > (as now) and ccall on Unix? It would save a lot of fuss for interfaces > to portable libraries. If I am not mista

Re: again: nullForeignPtr

Axel Simon <[EMAIL PROTECTED]> wrote, > the discussion on ForeignPtrs without finalizers didn't come to a > conclusion. I specifically need the nullForeignPtr which was easy enough > with the FFI of GHC 5.04: > > newForeignPtr nullPtr (return ()) The discussion came to a conclusion with ne

Re: new ForeignPtr without finalizers

Alastair Reid <[EMAIL PROTECTED]> wrote, > Manuel: > > In other words, it seem much more likely that one would > > partially apply `newForeignPtr' to a finaliser than to a > > pointer that is to be finalised. But this is a minor point. > > Having written some more ffi code over the last couple o

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

Ross Paterson <[EMAIL PROTECTED]> wrote, > On Thu, Jul 03, 2003 at 06:51:31PM +1000, Manuel M T Chakravarty wrote: > > Ross Paterson <[EMAIL PROTECTED]> wrote, > > > > > The new wording: > > > > > > \code{unsafePerformIO} may compromis

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

Ross Paterson <[EMAIL PROTECTED]> wrote, > The new wording: > > \code{unsafePerformIO} may compromise typing; to avoid this, the programmer > should ensure that the result of \code{unsafePerformIO} has a monomorphic > type. > > rules out the following: > > my_hash :: Storable a => a

Re: new ForeignPtr without finalizers

Dean Herington <[EMAIL PROTECTED]> wrote, > On Thu, 12 Jun 2003, Alastair Reid wrote: > > > Manuel: > > > In other words, it seem much more likely that one would > > > partially apply `newForeignPtr' to a finaliser than to a > > > pointer that is to be finalised. But this is a minor point. > >

Re: new ForeignPtr without finalizers

Alastair Reid <[EMAIL PROTECTED]> wrote, > > I'd propose to > > > > * add `newForeignPtr_', > > * reverse the argument order to `newForeignPtr', and > > * reverse the argument order to `addForeignPointerFinalizer' > > (for consistency). > > I agree with adding newForeignPtr_. (Presumably the r

Re: new ForeignPtr without finalizers

Dean Herington <[EMAIL PROTECTED]> wrote, > Alastair Reid wrote: > > > I'm not convinced that merging them into a single function is desirable, but, > > if we wanted to, I think a better FPish solution is to use > > > > Maybe (FinalizerPtr a) > > As multiple finalizers are allowed, perhaps we

Re: exercising the storage manager

Malcolm Wallace <[EMAIL PROTECTED]> wrote, > "Simon Marlow" <[EMAIL PROTECTED]> writes: > > > Does anyone else think that foreignPtrToPtr should really be called > > unsafeForeignPtrToPtr? > > Yes, I agree. Ok, so unless their are any objections, I will rename the function. Manuel

Re: exercising the storage manager

Peter Gammie <[EMAIL PROTECTED]> wrote, > On Tue, 10 Jun 2003, Simon Marlow wrote: > > > Does anyone else think that foreignPtrToPtr should really be called > > unsafeForeignPtrToPtr? > > I was actually advocating that it be disposed of, but thought that would > be too forward of me. What use is

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

Ross Paterson <[EMAIL PROTECTED]> wrote, > On Sun, Jun 08, 2003 at 09:06:07PM +1000, Manuel M T Chakravarty wrote: > > Ross Paterson <[EMAIL PROTECTED]> wrote, > > > On Wed, Jun 04, 2003 at 11:09:43PM +1000, Manuel M T Chakravarty wrote: > > > > StablePt

Re: new ForeignPtr without finalizers

Alastair Reid <[EMAIL PROTECTED]> wrote, > Ashley: > > How do I create a new ForeignPtr that doesn't have any finalizers? > > Malcolm: > > Why would you want to? > > addForeignPtrFinalizer lets you add them later. > I'm guessing that Ashley is making heavy use of this ability. > > [What we have

Re: FFI Help

"Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote, > Would it be worth mentioning or amplifying this point in the FFI spec, > or perhaps in an accompanying Appendix/Commentary of examples and FAQs? > Else someone else is going to trip over it sooner rather than later. Good point. I think this is ce

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

Ross Paterson <[EMAIL PROTECTED]> wrote, > On Wed, Jun 04, 2003 at 11:09:43PM +1000, Manuel M T Chakravarty wrote: > > StablePtr are used to export references to Haskell values to > > C, where they are treated as abstract data. In C one > > traditionally uses (void *)

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

Malcolm Wallace <[EMAIL PROTECTED]> wrote, > > > > data Point > > > > foreign import getMousePos :: Ptr Point -> IO () > > > > foreign import getX :: Ptr Point -> IO Int > > > > foreign import getY :: Ptr Point -> IO Int > > vs > > > data Point = Point (Ptr Point) > > foreign import

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

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > > > > > data Point > > > > > foreign import getMousePos :: Ptr Point -> IO () > > > > > foreign import getX :: Ptr Point -> IO Int > > > > > foreign import getY :: Ptr Point -> IO Int > > > > vs > > > > > data Point = Point (Ptr Point) >

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

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > We routinely use code like this: > > > > data Point > > foreign import getMousePos :: Ptr Point -> IO () > > foreign import getX :: Ptr Point -> IO Int > > foreign import getY :: Ptr Point -> IO Int > > > > The idea being that: > > > > 1) t

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

Ross Paterson <[EMAIL PROTECTED]> wrote, > On Thu, May 22, 2003 at 07:05:38PM +1000, Manuel M T Chakravarty wrote: > > Ross Paterson <[EMAIL PROTECTED]> wrote, > > > and HsStablePtr constrained to (void *)? > > > > This is a kludge. Essentially, we

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

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > Manuel M T Chakravarty <[EMAIL PROTECTED]> writes: > > > > > -=- Changes since RC 9 > > > > > > * 6.2: All the types in CTypes must be newtypes that are exported > > >

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

Ross Paterson <[EMAIL PROTECTED]> wrote, > Minor nits: there's a footnote saying "Finalizers in Haskell cannot > be savely [sic] realised without requiring support for pre-emptive > concurrency". I'd suggest dropping "pre-emptive": with cooperative > concurrency it's perfectly safe to collect the

Re: ForeignPtr naming

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > As Haskell finalizers need pre-emptive concurrency, maybe > > they should go somewhere related to concurrency. Or we > > could have a "Foreign.Concurrent". > > Ok, how about Foreign.Concurrent.newForeignPtr and > Foreign.Concurrent.addForeignPtrFinal

Re: ForeignPtr naming

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > > I'm assuming that we want to keep these functions in some form in > > > GHC - where to put them is one issue; Foreign.ForeignPtr is a > > > possibility (but not ForeignPtr), or GHC.ForeignPtr. > > > > I'd put them in GHC.ForeignPtr and make no other

Re: Comparing [Fun]Ptrs

Volker Stolz <[EMAIL PROTECTED]> wrote, > Hi, I'm looking for a way of comparing Ptrs to null *elegantly*. > The FFI distinguishes between 'Ptr a' and 'FunPtr a', so testing > would mean writing ((==) null[Fun]Ptr). This is rather tedious and a predicate > 'isNull' might be in order so that it's p

Re: Foreign import

"Gustavo Villavicencio" <[EMAIL PROTECTED]> wrote, > I'm a new ffi user and I have some problems with foreign import > declaration. I'm don't have any problem to access C standard functions. > However, I cannot access to my own functions in mylib.h by means of > > foreign import "mylib.h myfun" h

Re: [GUI] Example: Binding C++ to Haskell using the ffi

David Sankel <[EMAIL PROTECTED]> wrote, > for the ffi people: > > Has any though gone into cplusplus? If so, how would > it interface? Would stubs on the c++ side be > generated or would it use the code directly. Interfacing in a clean and comprehensive way to OO languages is hard. For a disc

Finalizers, again!

I have just read Hans Boehm's POPL paper on finalizers. His suggestion for the use of finalizers in single-threaded systems is to provide a `runFinalizers' routine, instead of relying on the asynchronous execution that, as established, requires support for concurrency. I am not sure whether we ha

Re: safe and threadsafe

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > I don't think it was ever the intention that 'safe' should have a > > guaranteed serialisation property. I think the idea was that > > 'threadsafe' was the most desirable, with 'safe' and 'unsafe' only > > available for use if you wanted more efficien

Re: Repeated hs_init()/hs_exit()

Fergus Henderson <[EMAIL PROTECTED]> wrote, > On 28-Jan-2003, Simon Marlow <[EMAIL PROTECTED]> wrote: > > I'm implementing the latest hs_init()/hs_exit() interface in GHC, and > > came across an ambiguity or omission in the spec. We're clear that this > > sequence should be allowed: > > > > hs

Re: Threaded RTS Patch

[I have redirected this to the FFI list, being our favourite finalizer battleground] "Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote, > | For now, I resolved the finalizer issue by making the finalizers > behave > | approximately as in the non-threaded case. > | When the main action finishes, all

ANN: H98 FFI Addendum 1.0, Release Candidate 8

I put a snapshot of the current status of the FFI Addendum as RC8 at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ Despite there still being two unfinished discussion threads, I felt that it is time for another RC, as many people probably don't track the progress in CVS. Cheers, Manuel -=- %

Re: cids and fnames in ccall impents

Ian Lynagh <[EMAIL PROTECTED]> wrote, > On Wed, Nov 06, 2002 at 12:04:22AM +, Ian Lynagh wrote: > > On Tue, Nov 05, 2002 at 09:53:52PM +, Alastair Reid wrote: > > > > > > If it isn't spelled out explicitly already, it would be good to do that. > > > > How about something like this? > >

Re: ["Simon Marlow" ] RE: cvs commit: fptools/libraries/base/Foreign ForeignPtr.hs

Ross Paterson <[EMAIL PROTECTED]> wrote, > On Mon, Jan 20, 2003 at 11:03:36PM +1100, Manuel M T Chakravarty wrote: > > Hence, I propose to leave the definition in the spec as it > > was; ie, the equality of ForeignPtrs is defined via the > > vanilla pointer that they en

Re: Finalizers finalized

Ross Paterson <[EMAIL PROTECTED]> wrote, > On Fri, Jan 17, 2003 at 10:23:27AM +1100, Manuel M T Chakravarty wrote: > > Ross Paterson <[EMAIL PROTECTED]> wrote, > > > > > I'd also like to see the addition of > > > > > > mal

Re: Re-exporting modules in the Foreign hierarchy

Malcolm Wallace <[EMAIL PROTECTED]> wrote, > I do seem to remember a proposal at one stage to remove Foreign.C.TypesISO > altogether by incorporating it fully into Foreign.C.Types. Given that > the latter re-exports everything from the former, is there any reason > for TypesISO to remain separate

Re: Proposal: Pooled memory management

Sven Panne <[EMAIL PROTECTED]> wrote, > Manuel wrote: > > [...] > > * I want to get v1.0 of the spec fixed. We are really only > > in bug fix mode for quite a while and only the finalizer > > problems held us back from finishing the spec. > > That's OK and I understand your motivation. Let's

Re: ["Simon Marlow" ] RE: cvs commit: fptools/libraries/base/Foreign ForeignPtr.hs

Alastair Reid <[EMAIL PROTECTED]> wrote, > > perhaps ForeignPtr should not be an instance of Eq so people can > > provide their own? > > Note that if we did this, we'd want to consider adding an operation > > eqForeignPtr :: FP a -> FP a -> Bool > > FP b-- possi

Re: Proposal: Pooled memory management

Sven Panne <[EMAIL PROTECTED]> wrote, > The FFI libraries currently contain support for explicit allocation > and deallocation via the malloc/free family and support for implicit > allocation and deallocation via alloca and friends. But there is a > very useful level between these extremes: Pooled

Re: Finalizers finalized

Ross Paterson <[EMAIL PROTECTED]> wrote, > I'd also like to see the addition of > > mallocForeignPtrArray :: Storable a => Int -> IO (ForeignPtr a) > > to ForeignPtr, to save people from rolling their own. (Maybe the realloc > and 0 versions too?) The reason I didn't answer to this earli

Re: alignment

Ross Paterson <[EMAIL PROTECTED]> wrote, > On Mon, Jan 13, 2003 at 09:00:33PM +1100, Manuel M T Chakravarty wrote: > > Fergus Henderson <[EMAIL PROTECTED]> wrote, > > > > > On 09-Jan-2003, Ross Paterson <[EMAIL PROTECTED]> wrote: > > > >

Foreign proxy

An interface like the following has been repeatedly proposed (in slightly varying versions): data ForeignObj a-- abstract instance Eq (ForeignObj a) type Finalizer a = FunPtr (a -> IO ()) newForeignObj :: a -> Finalizer a -> IO (ForeignObj a) addFinalizer:: Forei

Finalizers finalized

Sorry for taking so awfully long with a wrap up of the finalizer affair, but here it is. Unanimous agreement: * Alastair was right: Haskell finalizers require pre-emptive concurrency => C-finalizers only in FFI 1.0 Still under discussion: * Names for the C-finalizer functions: - A number o

Re: Finalizers: conclusion?

Antony Courtney <[EMAIL PROTECTED]> wrote, > You indicated that you were somewhat unclear why we need liveness > dependencies. I'll attempt to clarify by sketching some of the details > of the particular C library for which I am writing FFI wrappers. > > I have a C library for 2D vector graphi

Re: alignment

Fergus Henderson <[EMAIL PROTECTED]> wrote, > On 09-Jan-2003, Ross Paterson <[EMAIL PROTECTED]> wrote: > > Two additions I think are required: > > > > 1) The spec should state that mallocBytes and allocaBytes return a block > >of memory sufficiently aligned for any of the primitive types supp

Re: ["Simon Marlow" ] RE: cvs commit: fptools/libraries/base/Foreign ForeignPtr.hs

Alastair Reid <[EMAIL PROTECTED]> wrote, > [Thread moved from the library cvs mailing list] > > Simon Marlow: > > - Fix the Eq instance for ForeignPtr to match the behaviour > > specified by the spec. Two ForeignPtrs are equal iff their > > underlying Ptrs are equal (previously they were equal

Re: C Struct Field Access

Ashley Yakeley <[EMAIL PROTECTED]> wrote, > What's the best strategy for accessing fields in someone else's C struct? > Should I write my own glue file with accessor functions? Or should I make > a Storable instance for the struct? Well, my answer to this is the same as to Antony's C enum quest

Re: declaring C enum types

Antony Courtney <[EMAIL PROTECTED]> wrote, > A relatively mundane question: > > Is there a preferred means of writing a foreign import declaration for a > C function with a prototype that takes an "enum" argument? > > i.e., in C we have: > > enum bar { >GOOD, BAD > }; > > void foo(enum

Re: Finali[zs]ers

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > I've added a finalizer rationale document to the repository, under > haskell-report/ffi (i.e. the same place as the FFI spec). If you have > CVS commit privs, please feel free to modify it, or otherwise suggest > changes on this list. Thanks a lot for

Re: addForeignPtrFinalizer

Alastair Reid <[EMAIL PROTECTED]> wrote, > > It's awkward because it requires a subtle side condition on what is > > a valid finaliser that is going to trip up users and cause strange > > errors. > > It is the same side condition we place on unsafe calls. Safe calls are the default. If somebod

Re: addForeignPtrFinalizer

PS: Is everybody going to be at PLI'02? Then, we could discuss this face to face. Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi

Re: addForeignPtrFinalizer

Alastair Reid <[EMAIL PROTECTED]> wrote, > > I have to say that, given Simon's patch, I am inclined to revert > > back to the old API for foreign pointers. > > I don't think such a change should be made unless Malcolm and I are > able to implement it. > > I'm not yet convinced that Simon's

Re: addForeignPtrFinalizer

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > > Then I'll reformulate my question as a patch. [...] > > > Is there anything fundamentally wrong with this approach? > > > > I still maintain that getting this to work, testing it and, > > especially, maintaining it is a lot of work. > > Isn't it w

Re: FFI digest, Vol 1 #218 - 3 msgs

George Russell <[EMAIL PROTECTED]> wrote, > Simon Marlow wrote > > PS. I'm sorry to keep banging on about this. Ultimately it doesn't > > really matter to me that much, since I only really use mallocForeignPtr. > > I guess I was just intrigued to see if the problem was really as > > difficult as

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

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 is

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

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

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: Updates to FFI spec: performGC

George Russell <[EMAIL PROTECTED]> wrote, > Manuel's new wording (except for the typo "advices" instead of "advises") expresses >this > perfectly, so there probably isn't much point in discussing this further. Ooops - thanks. Manuel ___ FFI mailing l

ANN: H98 FFI Addendum 1.0, Release Candidate 6

Please review RC 6 available at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ A change log is appended. This version features a rather large number of changes over the last version, which is making me a bit uneasy, as I hoped that the spec would converge soon. But many of these changes have

Re: Cheap ForeignPtr allocation

I agree with SimonM that the proposed routines have useful applications. Furthermore, it is trivial for Haskell systems to implement these routines. Hence, I will include them into the spec unless there are serious objections. Cheers, Manuel ___ FFI m

Re: Updates to FFI spec: performGC

Alastair Reid <[EMAIL PROTECTED]> wrote, > George Russell <[EMAIL PROTECTED]> writes: > > Also there are probably hard-real-time GC algorithms (like Baker's > > treadmill) or algorithms which are close to being hard-real-time > > (like the train algorithm) where doing a "full GC" would be a major

Re: isNull{Fun,}Ptr

Malcolm Wallace <[EMAIL PROTECTED]> wrote, > Manuel M T Chakravarty <[EMAIL PROTECTED]> writes: > > > Sure, but there is also > > null = (== []) > > in the Prelude and `Maybe.isNothing'. > > No, the definition of null is > null [] = True

Re: Proposed change to ForeignPtr

George Russell <[EMAIL PROTECTED]> wrote, > Manuel wrote (snipped) > > > I have changed this in the spec now. I attach the wording > > used in the spec. > > > \item[newForeignPtr ::\ Ptr a -> FunPtr (Ptr a -> IO ()) -> IO (ForeignPtr a)] > > Turn a plain memory reference into a foreign objec

Re: module Data.Bits

Alastair Reid <[EMAIL PROTECTED]> wrote, > > > Another conflict between the FFI spec and the current library > > implementation: the spec says > > > "The function bitSize returns 0 for types that don't have a > > fixed bitsize (e.g. Integer)." > > > whereas the current ghc implementation d

Re: module Data.Bits

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > The FFI Addendum actually doesn't commit to which operations > > are in the class. It just says defines all these ops to > > have a context `Bits a', which is definitely the case. In > > other words, you proposed implementation is valid by the > > s

Re: Updates to FFI spec: hs_init() & friends

Malcolm Wallace <[EMAIL PROTECTED]> wrote, > Alastair Reid <[EMAIL PROTECTED]> writes: > > > > So, my proposal is to: > > > [...] > > > > I think only GHC implements anything like this (correct me if wrong, > > Malcolm) and they haven't used it in the way John Meacham is > > interested in. > >

Re: isNull{Fun,}Ptr

Malcolm Wallace <[EMAIL PROTECTED]> wrote, > > Wolfram Kahl suggested to add functions isNullPtr and > > isNullFunPtr (with the expected semantics) to the Ptr > > module. Opinions? > > Ptr and FunPtr are already instances of Eq, so which is easier to type? > isNullPtr x > or > x==nullPt

Re: Updates to FFI spec: performGC

Alastair Reid <[EMAIL PROTECTED]> wrote, > I think the thing to do is add the existing performGC to the standard > (perhaps giving it an hs_ prefix in the process) and leave development > of an extended version of the function for when the GHC folk (or > anyone else with a generational collector)

isNull{Fun,}Ptr

Wolfram Kahl suggested to add functions isNullPtr and isNullFunPtr (with the expected semantics) to the Ptr module. Opinions? Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi

Re: Updates to FFI spec: performGC

Alastair Reid <[EMAIL PROTECTED]> wrote, > > Hmmm, the garbage collector is a black box and has its own > > complicated heuristics for managing memory usage, but you are > > describing a mechanism that depends rather heavily on certain > > assumed behaviours. At the least, that gives the garbage

Re: Updates to FFI spec: hs_init() & friends

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > >> - Changes to hs_init > > >> > > >> http://www.mail-archive.com/ffi@haskell.org/msg00539.html This proposal doesn't work with these types IMHO. The reason is that you won't know which arguments to pass to hs_set_hs_argv (int argc, char *argv

Re: Updates to FFI spec: header files

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > >> - I see the question of Function prototypes as a portability > > >> problem waiting to happen. Either Hugs and GHC are right (you > > >> should use the user-supplied header file or NHC is right (you > > >> should ignore the header file). They can

Re: Proposed change to ForeignPtr

Manuel M T Chakravarty <[EMAIL PROTECTED]> wrote, > We seem to have a consensus on this one. We change the type > of the existing functions to > > newForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO (ForeignPtr a) > addForeignPtrFinalizer :: Forei

Re: module Data.Bits

Malcolm Wallace <[EMAIL PROTECTED]> wrote, > Alastair Reid <[EMAIL PROTECTED]> writes: > > > > The FFI spec says that the operations called 'shift' and 'rotate', > > > shift and rotate their argument to the right. However, the GHC > > > implementation in CVS shifts and rotates to the left, and

Re: Proposed change to ForeignPtr

d function names btw). Manuel -=- Subject: Re: Proposed change to ForeignPtr From: Manuel M T Chakravarty <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Mon, 12 Aug 2002 23:00:22 +1000 (EST) Reply-To: [EMAIL PROTECTED] X-Mailer: Mew version 2.2 on XEmacs 21.4.6 (Common Lisp) We seem to h

Re: Library archives

"Simon Peyton-Jones" <[EMAIL PROTECTED]> wrote, > | .NET is a different beast from other calling conventions in > | that you may want to compile Haskell ccalls to .NET > | intermediate language. In other words, it is about being > | able to implement ccall *on* .NET. Thus, the mix. > > I th

Re: Cheap ForeignPtr allocation

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > I'd like to propose two new functions for the ForeignPtr interface: > > mallocForeignPtr :: Storable a => IO (ForeignPtr a) > mallocForeignPtrBytes :: Int -> IO (ForeignPtr a) > > (the names can change, of course). The implementation

Re: Library archives

Alastair Reid <[EMAIL PROTECTED]> wrote, > > Under .NET each DLL has its own namespace, so the [lib] spec is > > needed to disambiguate. Since it's a namespace issue, I'd feel > > better if on .NET the name of the C function took a different form > > (perhaps .) and [lib] is removed from the spe

Re: Proposed change to ForeignPtr

We seem to have a consensus on this one. We change the type of the existing functions to newForeignPtr :: Ptr a -> FunPtr (Ptr a -> IO ()) -> IO (ForeignPtr a) addForeignPtrFinalizer :: ForeignPtr a -> FunPtr (Ptr a -> IO ()) -> IO () For GHC, I propose to put the closure-based versions int

Re: Proposed change to ForeignPtr

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > > That's a tricky one. From the standards point of view, I am > > > actually *very* reluctant to introduce new names. On the other > > > hand, reusing the old names will lead to a couple of unhappy emails > > > from people using the old interface aga

Re: Library archives

"Simon Marlow" <[EMAIL PROTECTED]> wrote, > > I see a lot of discussion about header files. > > I see a small amount of discussion of libraries with many conflicting > > suggestions. > > I see no _conclusion_. > > Ok, I can't see the conclusion either, but I seem to recall that at one > stage th

  1   2   3   >