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
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
"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
On 12-Aug-2002, Simon Marlow <[EMAIL PROTECTED]> wrote:
>
> I'd be equally happy (perhaps happier) if the header file spec was
> removed altogether. In a sense, this would leave the Haskell part of a
> foreign binding even more portable, because it doesn't have to specify
> the names of header f
> 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 spec.
Isn't that just a different syntax for the sa
> System.Mem.performGC does a major GC. When would a partial GC be
> enough?
I've described the image-processing example a bunch of times.
We have an external resource (e.g., memory used to store images) which
is somewhat abundant and cheap but not completely free (e.g.,
eventually you start t
> > What do you expect to happen if the finaliser calls a foreign
> > exported function?
>
> Good question.
>
> I do not expect that to work on any platform that has difficulty
> implementing newForeignPtr (because you could use it to implement
> newForeignPtr).
>
> I don't know if it would be
> >> - I'd like to see a standard way to call the GC from C
> >>
> >> http://www.mail-archive.com/ffi@haskell.org/msg00565.html
> >>
> >> Note that Hugs and GHC have had this for ages except that we call
> >> the function 'performGC' and there's no way to control how many
> >> generations are c
Alastair Reid <[EMAIL PROTECTED]> writes:
> I'm not sure which position you're preferring here. I lean a bit
> towards using the old names for the new functions (the ones with free
> functions) and finding new names for the old functions (the ones with
> closure arguments).
That would be my pre
>
> > (no, I'm not sure why they're in the C section of the FFI
> > spec either).
>
> Because they are for implementing calls to C code in Haskell
> that is compiled to .NET ILX.
>
> This doesn't mean that I want to necessarily defend them,
> but this was the reason for their inclusion. Essenti
10 matches
Mail list logo
