On Sat, 21 Feb 2004, Mattia Barbon wrote:
> Il Fri, 20 Feb 2004 16:12:40 -0500 (EST) Simon Glover <[EMAIL PROTECTED]> ha scritto:
>
> > Here's a first draft of PDD 11. It's based on a combination of the
> > existing extend.pod and the comments in extend.c, with additional
> > text
> > by yours
are the ones that are largely unaware of the structure
and architecture of Parrot. They deal mainly in data as abstract
entities, and Parrot itself as a black box that, at best, can make
subroutine or method calls. This is sufficient for many extensions
which act as black box processing units a
On Wed, 29 Oct 2003, Leopold Toetsch wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > (void *)get_pointer()
> > void set_pointer(void *)
>
> Good. So we can clean up cheating in Sub PMCs, where we are using
> _integer vtables, when actually absolute byte-code addressess are
> passed.
Ye
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> (void *)get_pointer()
> void set_pointer(void *)
Good. So we can clean up cheating in Sub PMCs, where we are using
_integer vtables, when actually absolute byte-code addressess are
passed.
> Dan
leo
ting
entry (like, say, the get/set int keyed int entries) neither of which is
really a good option for extensions.
So, once the screaming pumpkin departs, I want to add these two entries to
the vtable:
(void *)get_pointer()
void set_pointer(void *)
with their keyed variants. The default acti
gle searches by URL. (Though it's possible, IIRC)
So, some questions:
1. Are PMCs being designed such that compiled Parrot extensions
should be using them for all their internal operations where
possible, or is it more likely that an extension writer should be
using their own struc
Darren Duncan wrote:
[snip]
> I decided that I shouldn't waste my time with the Perl 5 XS system and
> go straight to using the corresponding Parrot extension mechanism
> instead. Partly this is because the latter should be more mature by
> the time I am ready to write the C, and also because it s
C, and also
because it should be a lot better designed and a joy to work with than XS.
So, some questions:
1. Are PMCs being designed such that compiled Parrot extensions should be using them
for all their internal operations where possible, or is it more likely that an
extension writer should
an do it better.
>
> >Also, on a tangent, I hope someone is pondering, or planning to
> >ponder, the practicallity of some kind of perl5 XS to perl6 interface
> >that would enable perl5 extensions to be ported to perl6 with less
> >effort than a complete rewrite. It needn&#x
practicallity of some kind of perl5 XS to perl6 interface
>that would enable perl5 extensions to be ported to perl6 with less
>effort than a complete rewrite. It needn't be clean, elegant, or
>fast, but I think there's too much good work on CPAN to ignore.
I was hoping to avoid
27;ll just be happy to see Apoc 5, so I know what I should support when I
rip out the guts of the regex engine. ;^)
# Also, on a tangent, I hope someone is pondering, or planning to
# ponder, the practicallity of some kind of perl5 XS to perl6 interface
# that would enable perl5 extensions to be
nterface
that would enable perl5 extensions to be ported to perl6 with less
effort than a complete rewrite. It needn't be clean, elegant, or
fast, but I think there's too much good work on CPAN to ignore.
Tim.
On Sat, Mar 02, 2002 at 12:24:18PM -0800, Brent Dax wrote:
> # It confused me at first. Conceptually it seems that there is
> # a sudden jump
> # from perl syntax to C syntax, without any visual alert marks.
> # Reading it again I few times I realise that the above is
> # (almost) C syntax,
> # ap
Nicholas Clark:
# On Fri, Mar 01, 2002 at 05:17:28AM -0800, Brent Dax wrote:
# > After banging my head against a wall for a few hours with
# Perl 5's XS, I
# > have an idea for how Parrot can do it better.
# >
# > Basically, the big problems with XS are:
# > -It's ugly as hell
# > -It make
On Fri, Mar 01, 2002 at 05:17:28AM -0800, Brent Dax wrote:
> After banging my head against a wall for a few hours with Perl 5's XS, I
> have an idea for how Parrot can do it better.
>
> Basically, the big problems with XS are:
> -It's ugly as hell
> -It makes the extender do tons of e
this definition:
char *
TypeMap_Parrot_String_TO_char_PTR(struct Parrot_Interp *interpreter,
Parrot_String arg)
{ return Parrot_string_to_chars(interpreter, arg); }
Note that for most extensions you won't even need a typemap. These
three and a few others would likely
ardized somehow? Perl 6 binary level compatibility, for
> extensions? In a way that distributing binary modules would be at least
> possible? It's already a big trouble to consider the various different
> os/cpu combinations, configure options is not feasible at all! Compilers I
> c
17 matches
Mail list logo
