On Fri, 20 Feb 2004, Dan Sugalski wrote:
> At 2:37 PM -0500 2/20/04, Simon Glover wrote:
> > I'm currently trying to put together a first draft of PDD 11 (extensions)
> > based on extend.pod plus the comments in extend.c and I've got a few
> > questions:
> >
> >[NB. I've dropped the Parrot_PMC
At 2:37 PM -0500 2/20/04, Simon Glover wrote:
I'm currently trying to put together a first draft of PDD 11 (extensions)
based on extend.pod plus the comments in extend.c and I've got a few
questions:
[NB. I've dropped the Parrot_PMC prefixes below to save typing]
i) We have _get_string, _get_p
I'm currently trying to put together a first draft of PDD 11 (extensions)
based on extend.pod plus the comments in extend.c and I've got a few
questions:
[NB. I've dropped the Parrot_PMC prefixes below to save typing]
i) We have _get_string, _get_pointer, _get_intval, _get_numval,
_get_c
On Fri, 17 Oct 2003, Simon Glover wrote:
>
> How do we create a Parrot_STRING in an extension? Parrot_Ints
> and Parrot_Floats are easy, since they're just declarations, and
> for PMCs there's Parrot_PMC_new, but there doesn't appear to be
> an equivalent for strings.
We don't yet -- it's an
How do we create a Parrot_STRING in an extension? Parrot_Ints
and Parrot_Floats are easy, since they're just declarations, and
for PMCs there's Parrot_PMC_new, but there doesn't appear to be
an equivalent for strings.
Simon
On Fri, 17 Oct 2003, Simon Glover wrote:
>
> On Fri, 17 Oct 2003, Dan Sugalski wrote:
>
> > On Fri, 17 Oct 2003, Simon Glover wrote:
> >
> > >
> > > What, if any, validation of their input should the register access
> > > functions in th
On Fri, 17 Oct 2003, Dan Sugalski wrote:
> On Fri, 17 Oct 2003, Simon Glover wrote:
>
> >
> > What, if any, validation of their input should the register access
> > functions in the extension API do? Currently, they don't do any,
> > which means that you
On Fri, 17 Oct 2003, Simon Glover wrote:
>
> What, if any, validation of their input should the register access
> functions in the extension API do? Currently, they don't do any,
> which means that you can create a buffer overflow simply by using
> a register
What, if any, validation of their input should the register access
functions in the extension API do? Currently, they don't do any,
which means that you can create a buffer overflow simply by using
a register number >31 or <0; eg,
Parrot_set_intreg(interpreter, 100
On Wed, Jun 26, 2002 at 08:04:05AM -0700, Sean O'Rourke wrote:
> I'd suggest having types be integers handed out at run-time.
I thought about this before I suggested what I did, hence they TYPE
macro :) Remember, an enum is really just an integer, and your question
is about how you manage that.
On Wed, 26 Jun 2002, Dave Goehrig wrote:
> 1.) Data creation function having both of the following properties:
> a.) Create & register new PMCs
> b.) Toggle GC on/off
>
> say with the following API for sake of arugment:
> let TYPE be either a char* or
Dan,
I've started work on a XS wrapper extension for Parrot, and have been spending
a lot of time looking the current Perl5 API relative to Python's and Ruby's.
I am working under the assumption that the Parrot extension API will have
a minimum of the following parts:
1.
At 02:50 PM 6/1/2002 -0400, Dan Sugalski wrote:
>At 2:17 PM -0400 6/1/02, Melvin Smith wrote:
>>Now there are a dozen ways to handle this. Using flags, keeping args on the
>>stack until return, yada yada yada...
>>Since extensions are supposed to be isolated from the interpreter
>>internals, I'm
At 2:17 PM -0400 6/1/02, Melvin Smith wrote:
>Now there are a dozen ways to handle this. Using flags, keeping args on the
>stack until return, yada yada yada...
>
>I'd like to hear suggestions, or maybe reference to past discussions I might
>have missed on how we shall handle this. Actually I want
>Now there are a dozen ways to handle this. Using flags, keeping args on the
>stack until return, yada yada yada...
One option is we don't pass args to native on the normal stack, rather
create a scratchpad Array PMC and pass it instead, so the routine
can access it randomly. However, I'm unsure
At 02:17 PM 6/1/2002 -0400, Melvin Smith wrote:
># t.pasm
>loadlib P0, "libpqt.so"
>print "Loaded\n"
>callnative P1, P0, "PQt_init"
>end
The correct code is actually:
loadlib P0, "libpqt.so"
print "Loaded\n"
# Save an argument for native method
save "Testing..."
# callnative calls a native metho
I'm working on an experimental extension API, which is going
well, but I'm pondering how the GC should cooperate with
native calls.
Currently I have some code like:
# t.pasm
loadlib P0, "libpqt.so"
print "Loaded\n"
callnative P1, P0, "PQt_init"
end
/*
17 matches
Mail list logo
