Christian Renz wrote:
The easiest way isn't avaialble yet. That is custom dynamically loaded
PMCs (classes) representing some functionality.
Hmm... then I think I misunderstood something. I thought PMCs are
only used for language-specific data types (e.g. "PerlScalar",
I thought of wxWindows data
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> t/pmc/io_2 is failing on some tinderboxen that don't have memalign and
> therefore don't have ARENA_DOD_FLAGS set. Besides the wrong count of DOD
> runs, the primary problem is:
> The ParrotIO object is found to be alive in some system areas (probably
>
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> I alread did ask some time ago:
I looked up the original thread: (date 13.02.03)
http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&th=53f5dbdd508603fb&rnum=1
> Is there any compelling reason that *_keyed_int vtables like:
>
> PMC* get_pmc_keyed_int
Clinton Pierce <[EMAIL PROTECTED]> wrote:
>> Subject: Re: [ANNOUNCE] Parrot is feature-frozen until Wednesday
I must somehow have missed this announce. But anyway, I'd like to have
the IO-subsystem fixed, before a release is done.
Are there any patches under construction currently?
I think, putti
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Clinton Pierce <[EMAIL PROTECTED]> wrote:
> >> Subject: Re: [ANNOUNCE] Parrot is feature-frozen until Wednesday
>
> I must somehow have missed this announce.
Me too.
> But anyway, I'd like to have
> the IO-subsystem fixed, before a release is done.
Juergen Boemmels wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
Is there any compelling reason that *_keyed_int vtables like:
PMC* get_pmc_keyed_int (INTVAL* key)
take a pointer to the key?
Just passing the integer key would be shorter and faster.
This is a good idea, and I support it. (As I
Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
> At the moment I have just a patch under construction to remove the
> INTVAL Filehandles like print I0, P0. Don't know if we want to keep
> this ops around for the next release.
These ops are redundant, whe
Going about (finally) implementing my Infinity pmc, I noticed a lot of
redundant code in the Perl* classes. For instance, the polymorphic
behavior isn't implemented in PerlScalar, but rather in each of its
subclasses, which seems to rather defeat the purpose of making them
subclasses.
However, tr
Luke Palmer wrote:
Going about (finally) implementing my Infinity pmc, I noticed a lot of
redundant code in the Perl* classes.
[ ... ]
The way I see this being done is by adding another level of
indirection. PerlScalar would implement its polymorphic behavior in
the set_* methods, and delegate
