=head1 TITLE
A method of allowing foreign objects in perl
=head1 VERSION
Maintainer: Dan Sugalski <[EMAIL PROTECTED]>
Date: August 02, 2000
Version: 1
Mailing List: perl6-internals
Number: XXX
=head1 ABSTRACT
Currently it's a darned pain to deal with objects creat
[un-CC'ed to librarian - is this correct procedure?]
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> =head1 TITLE
>
> A method of allowing foreign objects in perl
I like it.
> =head1 VERSION
>
> Maintainer: Dan Sugalski <[EMAIL PROTECTED]>
> Date: A
he struct that evolved in Perlmacs for mixing
>Perl and ELisp objects:
Feel free to define some recommended functions. Give 'em all upper-case
names so they don't get confused with real methods. (I hope) A PERL_ prefix
might not be a bad thing either.
On the other hand, we may have a
we call the destroy method
> and assume that everything hanging off the object pointer is gone. That
> only leaves the perl bits to clean up, and we know about those.
Don't assume that the Perl interpreter is the sole root of
accessibility. Maybe some other language has 'us'
rs and booleans) directly
into the "SV *" that seems like a big win.
For foreign objects, I'm not sure why you're forcing a two level
dispatch. Why not let the foreign code register dispatches directly
in the scalar's vtbl? If we did it that way, a foreign object
is just:
[
sts in perl 5? No. Some magic cookie that perl's internals
passes to extension code? Yep, you bet. Probably should've used PMC instead
of SV * to distinguish them.
As for returning refs rather than real objects, well, I'm not sure that we
want to do that, but some sort of decouplin
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> actual work. The
> dispatch routine has a function signature like so:
>
> int status = dispatch(void *native_obj, sv
> *perl_scalar, char *method_called,
> int *num_args_in, perl_arg_stack
> *arg_stack,
>
assume that the Perl interpreter is the sole root of
>accessibility. Maybe some other language has 'us' (i.e., the
>interpreter) as an object and needs to mark all its own objects that
>we refer to for the benefit of its own GC.
Right, and I'm not. The destroy method is r
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > Feel free to define some recommended functions. Give 'em all upper-case
> > > names so they don't get confused with real methods. (I hope) A PERL_
> > prefix
> > > might not be a bad thing either.
> >
> >The only one I feel strongly about here is TYPE
At 08:22 AM 8/3/00 -0700, Benjamin Stuhl wrote:
>--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > actual work. The
> > dispatch routine has a function signature like so:
> >
> > int status = dispatch(void *native_obj, sv
> > *perl_scalar, char *method_called,
> > int *num_ar
At 11:51 AM 8/3/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > > Feel free to define some recommended functions. Give 'em all upper-case
> > > > names so they don't get confused with real methods. (I hope) A PERL_
> > > prefix
> > > > might not be a bad thing either.
>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> What, doing a
>
>name = (PMC->vtable[NAME])(PMC);
>
> is inflexible? I'm not talking about embedding data into the vtable, rather
> make one of the table entries a pointer to a function that returns the type
> name.
Oh, cool. I misunderstood you.
On Thu, Aug 03, 2000 at 08:22:28AM -0700, Benjamin Stuhl wrote:
> One thing: remember, there is a lot of talk about having
> perl6 use Unicode internally, which means that things like
> method names should be wchar_t * (or whatever).
No, that's the beauty of utf8: the C datatype is still char* an
--- Bart Schuller <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 03, 2000 at 08:22:28AM -0700, Benjamin Stuhl
> wrote:
> > One thing: remember, there is a lot of talk about
> having
> > perl6 use Unicode internally, which means that things
> like
> > method names should be wchar_t * (or whatever).
>
>
On Thu, Aug 03, 2000 at 01:15:54PM -0400, Dan Sugalski wrote:
> >One thing: remember, there is a lot of talk about having
> >perl6 use Unicode internally, which means that things like
> >method names should be wchar_t * (or whatever).
>
> Good point. I shall have to think Unicode more. (UTF-32, a
On Thu, Aug 03, 2000 at 08:50:56PM +0200, Bart Schuller wrote:
> No, that's the beauty of utf8: the C datatype is still char* and as long
> as you stick to 7-bits ASCII you won't know the difference...
... other than the fact that it's painfully slow to handle. (Wow, middle of a
character! Where
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 03, 2000 at 01:15:54PM -0400, Dan Sugalski wrote:
> > >One thing: remember, there is a lot of talk about having
> > >perl6 use Unicode internally, which means that things like
> > >method names should be wchar_t * (or whatever).
> >
> > Good p
f the object
> > > pointer is gone. That only leaves the perl bits to clean up, and
> > > we know about those.
> >
> >Don't assume that the Perl interpreter is the sole root of
> >accessibility. Maybe some other language has 'us' (i.e., the
>
on't
be found.
There's a lot of talk about doing a mark-sweep collector for perl,
but I'm not sure adopting a 30 year old obsolete gc algorithm is
such a good idea. Certainly we have to be careful about moving
objects, but generational collectors have a lot of advantages we
should
I think we are trying to accommodate any of several GC systems to be
selected amongst in future.
Ken Fox <[EMAIL PROTECTED]> wrote:
> John Tobey wrote:
> > Picture this. A Lisp (or Java, ...) structure holds a Perl
> > interpreter. A Perl variable holds a reference to the Lisp structure.
> > St
John Tobey wrote:
> I think we are trying to accommodate any of several GC systems to be
> selected amongst in future.
Then the Perl API needs to allow for the GC to move objects. If that
can't happen, the majority of interesting collectors can't be used.
> Ken Fox <[E
On Fri, 4 Aug 2000, Ken Fox wrote:
> John Tobey wrote:
...
> There's a lot of talk about doing a mark-sweep collector for perl,
> but I'm not sure adopting a 30 year old obsolete gc algorithm is
> such a good idea. Certainly we have to be careful about moving
>
Dan Sugalski wrote:
DS> TheObj *foo;
DS> SV *new_sv;
DS> foo = new TheObj("A parameter");
DS> sv = perl_new_sv();
DS> perl_make_sv_object(sv, "Some::Package", foo, &dispatch_routine,
DS> &destroy_routine);
DS>
DS> perl_return(perl_make_re
Ken Fox <[EMAIL PROTECTED]> wrote:
> John Tobey wrote:
> > I think we are trying to accommodate any of several GC systems to be
> > selected amongst in future.
>
> Then the Perl API needs to allow for the GC to move objects. If that
> can't happen, the majority
Benjamin Stuhl <[EMAIL PROTECTED]> writes:
>--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> actual work. The
>> dispatch routine has a function signature like so:
>>
>> int status = dispatch(void *native_obj, sv
>> *perl_scalar, char *method_called,
>> int *num_args_in, perl
John Tobey wrote:
> Picture this. A Lisp (or Java, ...) structure holds a Perl
> interpreter. A Perl variable holds a reference to the Lisp structure.
> Structure and interpreter become inaccessible to all threads. Perl
> will never know it's done with the Lisp structure, neither Perl nor
At 03:29 AM 8/4/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > Your extended way's cool too--RFC it and we can do that as well.
>
>I've been wanting to. It would be nice (at least for me) for you to
>start suggesting more RFC "assignments" like this. Community is not
>the same as "no ownership"
| | |
|-+-|
If Perl uses reference-counting as its only garbage collection, this
loop will have to be broken explicitly. But if we anticipate possibly
implementing mark-and-sweep, our mark routine should call Lisp's mark
routine on those Lisp objects we still reference, which would allow
those we don't to be collected.
-John
won't come again for a long time.
> our mark routine should call Lisp's mark routine on those Lisp objects
> we still reference, which would allow those we don't to be collected.
In general it isn't going to be possible to integrate tightly with a
foreign collector. Fo
| | | |
> | car | cdr |
> | | |
> |-+-|
>
>If Perl uses reference-counting as its only garbage collection, this
>loop will have to be broken explicitly. But if we anti
At 09:25 AM 8/6/00 -0400, Ken Fox wrote:
>John Tobey wrote:
> > But if we anticipate possibly implementing mark-and-sweep
>
>We're definitely going to have some sort of traversing collector. It
>might only augment the ref count collector.
I'd rather not have multiple GC schemes going at once. (Th
Dan Sugalski wrote:
> At 09:25 AM 8/6/00 -0400, Ken Fox wrote:
> > We're definitely going to have some sort of traversing collector. It
> > might only augment the ref count collector.
>
> I'd rather not have multiple GC schemes going at once. (Though we may need
> some sort of "refered to by" fie
At 10:36 PM 8/8/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 09:25 AM 8/6/00 -0400, Ken Fox wrote:
> > > We're definitely going to have some sort of traversing collector. It
> > > might only augment the ref count collector.
> >
> > I'd rather not have multiple GC schemes going at once. (Th
e everyone happy.
Whether or not strings appear to be objects in Perl, they will
certainly need vtables in perl.
Larry
Beware of dependencies between shared objects. Let's assume 2 chunks of
core functionality are seperated off into say A.so and B.so. This will
work fine as long as there are no interdependencies between A.so and
B.so. Let's however assume A.so needs to call something in B.so.
is to be able
to take groups of objects and pass them between threads (but not
necessarily have them be shared) instead of having several individual
mutex-protected objects.
Maybe an extension on the compartments idea: Allow a parrot program to
declare a new PMC container. Then when the prog
This and other RFCs are available on the web at
http://tmtowtdi.perl.org/rfc/
=head1 TITLE
A method of allowing foreign objects in perl
=head1 VERSION
Maintainer: Dan Sugalski <[EMAIL PROTECTED]>
Date: August 02, 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
Number: 32
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Interfaces for linking C objects into perlsubs
=head1 VERSION
Maintainer: David Nicol <[EMAIL PROTECTED]>
Date: 7 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 61
=head1 AB
I think the importance of splitting the core functionality into shared
objects is more general than that. There was some discussion a short time
ago about making a pared-down version for embedding, which would seem to
require some sort of functionality reduction. There is also the desire of
> perl punts. We require that the code we interface to defines a
> dispatch function for each object, and we then just call the dispatch
> function with enough information for it to Do The Right Thing.
>
> Perl will define some generic conversion
> routines (to int, float, and string) which the f
At 05:33 PM 8/4/00 -0400, John Porter wrote:
> > perl punts. We require that the code we interface to defines a
> > dispatch function for each object, and we then just call the dispatch
> > function with enough information for it to Do The Right Thing.
> >
> > Perl will define some generic convers
Perl6 RFC Librarian wrote:
>
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Interfaces for linking C objects into perlsubs
>
> =head1 VERSION
>
> Maintainer: David Nicol <[EMAIL PROTECTED]>
> D
At 01:04 AM 8/8/00 +, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>Interfaces for linking C objects into perlsubs
This sounds more like we want perl to act like C's prologue code, so we can
invoke C programs without firing up a sub-process. It sounds rather nice,
but gettin
Hildo Biersma quoted RFC 62 and then went on thusly:
> > C is an excellent medium for sharing the glory of the internals
> > of Perl with the C programming community. It is hoped that the
> > interface deescribed herein will become an excellent medium for
> > sharing the glory of the internals o
Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
>This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
>=head1 TITLE
>
>Interfaces for linking C objects into perlsubs
>
>=head1 VERSION
>
> Maintainer: David Nicol <[EMAIL PROTEC
On Tue, 8 Aug 2000, Nick Ing-Simmons wrote:
> Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
> >This document is not precisely concerned with the details of the
> >implementation
> >of the interfaces it specifies, beyond a general attempt to restric
> >itself to the possible.
>
> But this list
Dan Sugalski <[EMAIL PROTECTED]> writes:
>On Tue, 8 Aug 2000, Nick Ing-Simmons wrote:
>
>> Perl6 Rfc Librarian <[EMAIL PROTECTED]> writes:
>> >This document is not precisely concerned with the details of the
>> >implementation
>> >of the interfaces it specifies, beyond a general attempt to restric
#x27;t know about doing it all within the process we have already,
but I can implement the interface (for C) by automating the creation
of a short C program that can accept input in some form that I
will provide to it, compiling it, linking it against the provided
objects, and keeping around the re
nput in some form that I
>will provide to it, compiling it, linking it against the provided
>objects, and keeping around the result, as a standalone file in a
>temporary file space available to this program, all the preceding
>at compile time, and at run time marshalling the input dat
49 matches
Mail list logo
