| > I remember this discussion of a
| > so-called "special rule" for ForeignObjs from previously, and I still
| > don't understand why it is "special" rather than the obvious and only
| > way to do things.
|
| In case of a tail call to a C routine, ghc could
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
[..]
> The drawback of marsh* is that calls are not uniform. Sometimes
> marsh* are not needed, sometimes they are not sufficient (with array
> and its length passed as separate arguments), initial arguments are
> simpler to pass by partial app
Malcolm Wallace <[EMAIL PROTECTED]> wrote,
> Sven says:
>
> > I'd like to finish discussion around the low-level aspects of the
> > FFI, so I propose the following: If none of the implementors yells
> > loudly that the ForeignObj FFI rule is costly to implement, this
> > lifetime rule should be
Sven Panne <[EMAIL PROTECTED]> wrote,
> In a nutshell: This thread is slowly drifting to more religious areas.
> On the one hand Manuel wants a minimalistic approach with simple
> rules, Sigbjorn/Marcin on the other hand want an easy to use and
> efficient way to pass foreign objects. If they are
[EMAIL PROTECTED] writes:
>
> Sven says:
>
> > I'd like to finish discussion around the low-level aspects of the
> > FFI, so I propose the following: If none of the implementors yells
> > loudly that the ForeignObj FFI rule is costly to implement, this
> > lifetime rule should be left as it is.
> Sven says:
>
> > I'd like to finish discussion around the low-level aspects of the
> > FFI, so I propose the following: If none of the implementors yells
> > loudly that the ForeignObj FFI rule is costly to implement, this
> > lifetime rule should be left as it is. (It can't be hard to
> imple
Sven says:
> I'd like to finish discussion around the low-level aspects of the
> FFI, so I propose the following: If none of the implementors yells
> loudly that the ForeignObj FFI rule is costly to implement, this
> lifetime rule should be left as it is. (It can't be hard to implement,
> because
Sigbjorn Finne wrote:
> But this relies on discipline on the part of the user
Well, even requiring the usage of foreign objects instead of bare
Addrs has something to do with discipline. :-]
> - do you want it to mysteriously fail if you second guessed wrongly
> and left out the allocation of
Mon, 21 Feb 2000 11:57:18 +0100, Sven Panne <[EMAIL PROTECTED]>
pisze:
> Granted, but nevertheless I support Manuel's view: The FFI should
> deal with *primitive* types automatically and libraries/tools should
> take care of the rest.
In principle I agree, but here IMHO manual protection would
Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes:
>
...
> > >
> > > As SimonM said in a previous email (and Michael Weber
> > > pointed out in our earlier discussion), if you pass a
> > > ForeignObj to C and want to be sure that it doesn't get
> > > finalised, you have to StablePtr it. Why
> Mon, 21 Feb 2000 10:20:30 +1100, Manuel M. T. Chakravarty
> <[EMAIL PROTECTED]> pisze:
>
> > I prefer a simple rule like ``when you pass a ForeignObj, you have
> > to take care if it can be the last reference and you don't want
> > it to be deallocated'' over a complex rule like ``if a Foreig
> Much of the "overhead" of StablePtrs at the moment is due to
> the hash table and reference count business that is
> implicitly performed by the stable pointer routines. So
> far, I haven't seen a good explanation as to why this is
> actually needed. If we would get rid of it, StablePtrs
> wo
Marcin 'Qrczak' Kowalczyk wrote:
> On the one hand, I certainly would not be happy to add to all
> those 50 foreign imports that use ForeignObjs code dealing with
> protecting them.
Granted, but nevertheless I support Manuel's view: The FFI should
deal with *primitive* types automatically and lib
Mon, 21 Feb 2000 10:20:30 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> I prefer a simple rule like ``when you pass a ForeignObj, you have
> to take care if it can be the last reference and you don't want
> it to be deallocated'' over a complex rule like ``if a ForeignObj
> if pass
Sigbjorn Finne <[EMAIL PROTECTED]> wrote,
> Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes:
> >
>
> > > Passing foreign objects directly via the FFI does not have this
> > > problem, because there is a special lifetime guarantee for this
> > > kind of values. :-P
> >
> > Actually, do
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) wrote,
> I use C2HS libraries now (but the c2hs program needs so *MUCH*
> memory and time to parse Perl headers that I can't use it here;
> fortunately there is no need to marsh C structures).
The last version of C->HS on the Web page has a *big* sp
Manuel M. T. Chakravarty <[EMAIL PROTECTED]> writes:
>
> >
> > Passing foreign objects directly via the FFI does not have this
> > problem, because there is a special lifetime guarantee for this
> > kind of values. :-P
>
> Actually, doesn't that prove the point that I tried to make
> whe
Sven Panne <[EMAIL PROTECTED]> wrote,
> Marcin 'Qrczak' Kowalczyk wrote:
> > The function is described as unsafe because the result loses the
> > finalizer, right? [...]
>
> Not exactly. The real problem (pointed out to me by Manuel Chakravarty
> some time ago) is exemplified by the following co
Thu, 17 Feb 2000 12:04:52 +0100, Sven Panne <[EMAIL PROTECTED]>
pisze:
> Not exactly. The real problem (pointed out to me by Manuel Chakravarty
> some time ago) is exemplified by the following code snippet:
[...]
I had exactly that thing in mind.
Thu, 17 Feb 2000 14:21:12 +0100, Sven Panne <[E
Marcin 'Qrczak' Kowalczyk wrote:
> The function is described as unsafe because the result loses the
> finalizer, right? [...]
Not exactly. The real problem (pointed out to me by Manuel Chakravarty
some time ago) is exemplified by the following code snippet:
addr <- foreignObjToAddr fo -- las
> The function is described as unsafe because the result loses the
> finalizer, right?
>
> So it is in fact unsafe to store a list of such Addrs in malloced
> memory, passing the pointer to the array to a C function, because
> they can be garbage collected and finalized during storing them,
> bef
21 matches
Mail list logo
