Michael Weber wrote:
> [...] otherwise there would be a `marshalList' and `marshalListN' with
> same type signature, which I also regarded as confusing.
That was a problem with your approach, not mine... :-)
> [...] But how else can you marshall an arbitrary length list? For
> Int lists, ther
On Wed, Oct 06, 1999 at 12:04:03 +0200, Sven Panne wrote:
> Michael Weber wrote:
>>marshalListN :: Int -> [a] -> IO Addr
>
> I don't see a reason for the duplication of length information, e.g.
> what should `marshalListN 1000 [1,2,3]' mean? And
> `marshalListN 2 [1,2,3]' is equivalent to `ma
Michael Weber wrote:
> Maybe it's worth to know how many objects a list has (without explicit
> zeroElem), so I'd suggest to extend the class to:
>
>marshalList ::[a] -> IO Addr
We agree here.
>marshalListN :: Int -> [a] -> IO Addr
I don't see a reason for the duplic
[My apologies: some day - I promise - I'll learn to choose the right mailing
list... 8->]
On Mon, Oct 04, 1999 at 13:45:43 +0200, Sven Panne wrote:
[micro-marshalling]
> I know Manuel's code already and the one H/Direct produces. Has anybody
> else some FFI-related code and/or suggestions? This c
"Manuel M. T. Chakravarty" wrote:
> I wouldn't call autoconf a hack :-)
OK, MEGA-hack. :-) But it's m4 which is the real culprit...
> [...] Anyway, such a class seems to be a nice way for expressing
> the information about marshalable data types.
The class is actually more about "micro"-mar
Sven Panne <[EMAIL PROTECTED]> wrote,
> "Manuel M. T. Chakravarty" wrote:
> > [...] So, how about providing functions that advance the `mem'
> > pointer for you or even have `writeXXXOffAddr' return the
> > next address after the datum just written?
> > [...] This is, however, maybe not so helpfu
"Manuel M. T. Chakravarty" wrote:
> [...] So, how about providing functions that advance the `mem'
> pointer for you or even have `writeXXXOffAddr' return the
> next address after the datum just written?
> [...] This is, however, maybe not so helpful because of alignment
> constraints that are har
Sven Panne <[EMAIL PROTECTED]> wrote,
> Simon Marlow wrote:
> > Manuel M. T. Chakravarty wrote:
> > [...] we should really enforce a stack discipline and use a wrapper
> > > function:
> > > alloca :: Int -> (Addr -> IO a) -> IO a
> >
> > Nice idea. I'm not sure about the implementation though
Simon Marlow wrote:
> Manuel M. T. Chakravarty wrote:
> [...] we should really enforce a stack discipline and use a wrapper
> > function:
> > alloca :: Int -> (Addr -> IO a) -> IO a
>
> Nice idea. I'm not sure about the implementation though: did you
> have in mind using C's malloc/free?
Perh
> I completely agree. Why not drop passing
> (Mutable)ByteArrays to foreign functions altogether - if a
> program wants to pass Haskell data to C land, the Right
> Thing is to use a StablePtr.
Agreed, if the call can re-enter the RTS.
> Now there maybe efficiency
> considerations when using t
"Sigbjorn Finne (Intl Vendor)" <[EMAIL PROTECTED]> wrote,
> To clarify a little - while the arguments to a
> 'foreign import' should at least live for the
> duration of an invocation of a (safe) foreign
> import, there's no guarantee that heap references
> you pass out won't move. Hence, the sche
To clarify a little - while the arguments to a
'foreign import' should at least live for the
duration of an invocation of a (safe) foreign
import, there's no guarantee that heap references
you pass out won't move. Hence, the scheme outlined
in the code of the original message isn't really going
t
It is currently not, but I think it should be. Will update the FFI
spec to mention this issue.
--sigbjorn
> -Original Message-
> From: Sven Panne [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 22, 1999 15:41
> To: GHC Users
> Subject: Staying alive
>
>
> In a recent discussio
13 matches
Mail list logo
