Benjamin Stuhl writes:
: --- Bart Schuller <[EMAIL PROTECTED]> wrote:
: > Larry knew what he was doing when he decided on utf8.
:
: It has also led to the perl5 internals being, to put it
: bluntly, a horrible mess. And forget about the regex
: engine.
That's a vast oversimplification. It has v
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
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 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
At 07:54 AM 8/6/00 -0400, John Tobey wrote:
>On Sun, Aug 06, 2000 at 01:24:10AM -0400, Dan Sugalski 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.
> > > Structure and int
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. The ref count might be 5
bits at the bottom of flags and we can do this:
enum gc_flags { sticky = 16 };
On Sun, Aug 06, 2000 at 01:24:10AM -0400, Dan Sugalski 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.
> > Structure and interpreter become inaccessible to all threads. Perl
>
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"
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
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
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 of interesting collectors can't be
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
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
> objects, but generational collect
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 <[EMAIL PROTECTED]> wrote:
> >
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:
> 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
> the
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 06:11 PM 8/2/00 -0400, John Tobey wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > At 05:39 PM 8/2/00 -0400, John Tobey wrote:
> > > > > A scalar is made an object via a call into the perl
> > > > > library. The scalar is marked as an object and
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
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
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
--- 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 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
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.
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.
>
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
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 06:11 PM 8/2/00 -0400, John Tobey wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 05:39 PM 8/2/00 -0400, John Tobey wrote:
> > > > A scalar is made an object via a call into the perl library. The
> > > > scalar is marked as an object and stuck into a package. Attached to
> > > > the scal
--- 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,
>
At 08:04 PM 8/2/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > TheObj *foo;
> > SV *new_sv;
> > foo = new TheObj("A parameter");
> > sv = perl_new_sv();
> > perl_make_sv_object(sv, "Some::Package", foo, &dispatch_routine,
> > &destroy_ro
Dan Sugalski wrote:
> TheObj *foo;
> SV *new_sv;
> foo = new TheObj("A parameter");
> sv = perl_new_sv();
> perl_make_sv_object(sv, "Some::Package", foo, &dispatch_routine,
> &destroy_routine);
>
> perl_return(perl_make_ref(sv));
Are yo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 05:39 PM 8/2/00 -0400, John Tobey wrote:
> > > A scalar is made an object via a call into the perl library. The
> > > scalar is marked as an object and stuck into a package. Attached to
> > > the scalar is a pointer to the native object, a pointer to a
At 05:39 PM 8/2/00 -0400, John Tobey wrote:
>[un-CC'ed to librarian - is this correct procedure?]
I'd say so, yep. Take that as official for the moment.
> > A scalar is made an object via a call into the perl library. The
> > scalar is marked as an object and stuck into a package. Attached to
>
[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: August 02, 2000
> Version: 1
> Mailing L
33 matches
Mail list logo
