Anyone mind if I commit this? One thing I'm not sure of, though -- I
try to behave myself and use Parrot_getenv rather than a plain
getenv(), but I'm not convinced the API is complete -- Parrot_getenv
saves back a boolean saying whether to free the returned string or
not, but what should I call to
Dan Sugalski [EMAIL PROTECTED] wrote:
We need the ability to layer PMCs. Nothing new, we need something of
the sort for transparent read-only-ness and probably thread-safety
What about the current implementation [1]:
* PMCs that have read-only variants have the Cconst_too flag set
* the PMC
Stéphane Payrard [EMAIL PROTECTED] wrote:
To avoid to go back the slow world of perl5 where many things
need to be tested before figuring what to do, performancewise,
there is little choice but to have two versions of each PMC
class, a fast one that is devoid of property support and another
Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
We need the ability to layer PMCs. Nothing new, we need something of
the sort for transparent read-only-ness and probably thread-safety
What about the current implementation [1]:
* PMCs that have read-only variants have the Cconst_too
Your answer is about compiling a subroutine that
does something. What's wrong with the current
wording:
How do I generate a sub call with a
variable-length parameter list in PIR?
Use unprototyped calls and functions and pass
as many arguments as you have.
Well, for one
Leopold Toetsch wrote:
William Coleda [EMAIL PROTECTED] wrote:
I was going to submit this as a patch, but I ended up with a conflict,
and Dan threatened he wouldn't apply it anyway, so I'll just post it
here for comment. Feel free to apply any or all of it. I would be very
happy to hear of a
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
Leopold Toetsch wrote:
Dan Sugalski [EMAIL PROTECTED] wrote:
We need the ability to layer PMCs. Nothing new, we need something of
the sort for transparent read-only-ness and probably thread-safety
What about the current implementation [1]:
*
