Re: Add functions in dynext to the extending interface?

2004-08-29 Thread Leopold Toetsch
Mattia Barbon <[EMAIL PROTECTED]> wrote: > Hello, > should they be? I think they are covered by the statemente in > pdd11 (... about the same level of access to Parrot > that bytecode programs ...). Please send a patch. Thanks. > Regards > Mattia leo

Re: [perl #31379] [PATCH] Implement Parrot_call_method

2004-08-29 Thread Leopold Toetsch
Mattia Barbon <[EMAIL PROTECTED]> wrote: > Hello, > this patch implements Parrot_call_method (with test). This code seems to duplicate functions from F and returning results from the call is missing. If should be easy to wrap Parrot_run_meth* and use existing code. leo

Re: perl6 garbage collector?

2004-08-29 Thread Leopold Toetsch
Ozgun Erdogan <[EMAIL PROTECTED]> wrote: > Hi all - > I don't know if this is the right list for this email, but it seemed > like the most relevant one. You might have a look at the roadmap on [EMAIL PROTECTED] or news:perl.ponie.dev. > Currently, we're using perl-5.6.1 and are having problems w

Re: Compile op with return values

2004-08-29 Thread Leopold Toetsch
Steve Fink <[EMAIL PROTECTED]> wrote: [ passing arguments to compilers ] > ... So why does the compile op exist? Your concerns are all valid. The compiler interface needs extension as well as some cleanup. This is true for compilers written in C (loadable as shared libs) and for compilers writte

Re[2]: [perl #31379] [PATCH] Implement Parrot_call_method

2004-08-29 Thread Mattia Barbon
On Sun, 29 Aug 2004 11:09:46 +0200 Leopold Toetsch <[EMAIL PROTECTED]> wrote: > Mattia Barbon <[EMAIL PROTECTED]> wrote: > > > Hello, > > this patch implements Parrot_call_method (with test). > > This code seems to duplicate functions from F and > returning results from the call is missing.

Re: Library loading

2004-08-29 Thread Steve Fink
On Aug-28, Dan Sugalski wrote: > > We dynamically load libraries. Whee! Yay, us. We need a set of > semantics defined and an API to go with them so we can meaningfully > and reliably work with them. Hm. Today I was working with the current implementation of this stuff, and uncovered a bunch of

Re: [perl #31268] [PATCH] Dynamic library with multiple PMCs

2004-08-29 Thread Steve Fink
On Aug-21, Mattia Barbon wrote: > > Hello, > as promised with this patch: > > pmc2c2 ... --library foo --c pmc1.pmc pmc2.pmc pmc3.pmc ... > > outputs pmcX.c and pmc_pmcX.h as it did before, plus > foo.c and pmc_foo.h containig a single Parrot_lib_foo_load > that initialized vtables and MMD

Re: [perl #31346] [PATCH] tests and fixes for Undef PMC

2004-08-29 Thread Dan Sugalski
At 9:36 PM + 8/29/04, Bernhard Schmalhofer via RT wrote: > At 1:43 PM -0700 8/26/04, Bernhard Schmalhofer (via RT) wrote: >This patch adds some test for the Undef PMC. Forgot to actually attach the patch. I guess I was overexcited because my telephone was working again, after five days of rad

Re: perl6 garbage collector?

2004-08-29 Thread Dan Sugalski
At 5:57 PM -0700 8/28/04, Ozgun Erdogan wrote: Hi all - I don't know if this is the right list for this email, but it seemed like the most relevant one. Currently, we're using perl-5.6.1 and are having problems with memory leaks - thanks to reference counting. FWIW, you might want to try weak refer

Re: GC/DOD API

2004-08-29 Thread Leopold Toetsch
Dan Sugalski <[EMAIL PROTECTED]> wrote: [ a slightly modified version of this proposal made it into CVS in the meantime ] > At 10:54 AM +0200 8/24/04, Leopold Toetsch wrote: >> >> DOD_WRITE_BARRIER(interp, aggregate, old_item, new_item) >> >>For hash keys we might need either two such calls (

Roles trying to be nice

2004-08-29 Thread Abhijit Mahabal
Traits can be mean, but roles are "guarenteed"(=forced?) to play nice. But suppose I have a role that wants to play nicer, by ensuring that incorporating it in some class actually makes sense. For example, it may want to ensure that the class has $.foo. (*) I have a few questions: 1: Can this be

Re: Roles trying to be nice

2004-08-29 Thread Luke Palmer
Abhijit Mahabal writes: > Traits can be mean, but roles are "guarenteed"(=forced?) to play nice. But > suppose I have a role that wants to play nicer, by ensuring that > incorporating it in some class actually makes sense. > > For example, it may want to ensure that the class has $.foo. (*) Let m