Parrot as an extension language

3 views
Skip to first unread message

Colin Paul Adams

unread,
May 17, 2005, 10:00:14 AM5/17/05
to perl6-i...@perl.org
Hello,

I am writing an XSLT 2.0 processor, and I want to give users the
option to write their own message and error handling routines and the
like in their favourite scripting language. So I thought of using
parrot.

But when I look at http://www.parrotcode.org/docs/embed.html, I can
see no way of getting information back from the script - not even an
exit code. Is there anyway of doing this that I have missed?
--
Colin Adams
Preston Lancashire

Autrijus Tang

unread,
May 17, 2005, 10:15:32 AM5/17/05
to Colin Paul Adams, perl6-i...@perl.org
On Tue, May 17, 2005 at 03:00:14PM +0100, Colin Paul Adams wrote:
> But when I look at http://www.parrotcode.org/docs/embed.html, I can
> see no way of getting information back from the script - not even an
> exit code. Is there anyway of doing this that I have missed?

You may wish to use Parrot_call_sub's "SS" form, where you pass in a
string and get back a string. Something like this:

my $interp = Parrot_new(undef);

# ... load a .pir file or some other code into $interp ...

my $code_pmc = Parrot_find_global(
$interp,
const_string("Namespace"),
const_string("sub_name"),
);

my $return_str = Parrot_call_sub(
$interp,
$code_pmc,
const_string("SS"),
const_string("Your_input_string_here"),
);

Thanks,
/Autrijus/

Colin Paul Adams

unread,
May 17, 2005, 10:40:31 AM5/17/05
to Jeff Horwitz, perl6-i...@perl.org
>>>>> "Jeff" == Jeff Horwitz <je...@smashing.org> writes:

Jeff> you'll probably want to use the Parrot_call_sub_* API to
Jeff> call individual subroutines and get return values. "perldoc
Jeff> extend.c" in the parrot source for more info. you might

Thanks - I'll take a look at that.

Jeff> also have a look at the mod_parrot source
Jeff> (http://www.smashing.org/mod_parrot), which is one of the
Jeff> few apps embedding parrot at the moment. the other is pugs
Jeff> (http://www.pugscode.org), but it's written in haskell.

Why's that a but? Haskell's a good language.

Jeff Horwitz

unread,
May 17, 2005, 10:44:40 AM5/17/05
to Colin Paul Adams, perl6-i...@perl.org
On 17 May 2005, Colin Paul Adams wrote:

> Jeff> also have a look at the mod_parrot source
> Jeff> (http://www.smashing.org/mod_parrot), which is one of the
> Jeff> few apps embedding parrot at the moment. the other is pugs
> Jeff> (http://www.pugscode.org), but it's written in haskell.
>
> Why's that a but? Haskell's a good language.

no argument there -- just assumed you were looking for examples in C! :)

-jeff

Jeff Horwitz

unread,
May 17, 2005, 10:13:21 AM5/17/05
to Colin Paul Adams, perl6-i...@perl.org
you'll probably want to use the Parrot_call_sub_* API to call individual
subroutines and get return values. "perldoc extend.c" in the parrot
source for more info. you might also have a look at the mod_parrot source
(http://www.smashing.org/mod_parrot), which is one of the few apps
embedding parrot at the moment. the other is pugs (http://www.pugscode.org),

but it's written in haskell.

-jeff


On 17 May 2005, Colin Paul Adams wrote:

Colin Paul Adams

unread,
May 17, 2005, 12:31:32 PM5/17/05
to Autrijus Tang, perl6-i...@perl.org
>>>>> "Autrijus" == Autrijus Tang <autr...@autrijus.org> writes:

Autrijus> You may wish to use Parrot_call_sub's "SS" form, where
Autrijus> you pass in a string and get back a string.

I take it SS stands for String-to-String?

Which section within http://www.parrotcode.org/docs/ covers this sort
of thing?

Colin Paul Adams

unread,
May 17, 2005, 12:34:36 PM5/17/05
to Jeff Horwitz, perl6-i...@perl.org
>>>>> "Jeff" == Jeff Horwitz <je...@smashing.org> writes:

>> Why's that a but? Haskell's a good language.

Jeff> no argument there -- just assumed you were looking for
Jeff> examples in C! :)

Actually, examples in any language are fine.
I'm actually writing in Eiffel, but I shall use an interface generator
to automatically build low-level bridging classes from the C header
files.
I intend to make it available as a general extension mechanism for
Eiffel via parrot, as that will be almost zero effort after
implementing what I need for my program.

Jeff Horwitz

unread,
May 17, 2005, 1:17:59 PM5/17/05
to Colin Paul Adams, perl6-i...@perl.org
On 17 May 2005, Colin Paul Adams wrote:

> Actually, examples in any language are fine.
> I'm actually writing in Eiffel, but I shall use an interface generator
> to automatically build low-level bridging classes from the C header
> files.
> I intend to make it available as a general extension mechanism for
> Eiffel via parrot, as that will be almost zero effort after
> implementing what I need for my program.

this is similar to what we did with pugs, except we used haskell's FFI
(foreign function interface) to call out to Parrot's API. see
src/Pugs/Embed/Parrot.hsc in the pugs source.

> --
> Colin Adams
> Preston Lancashire
>

-jeff

Autrijus Tang

unread,
May 17, 2005, 4:13:06 PM5/17/05
to Colin Paul Adams, Autrijus Tang, perl6-i...@perl.org
On Tue, May 17, 2005 at 05:31:32PM +0100, Colin Paul Adams wrote:
> I take it SS stands for String-to-String?

Yes. "PPC" would stand for PMC -> PMC -> String, i.e. take two PMCs
and returns a String.

> Which section within http://www.parrotcode.org/docs/ covers this sort
> of thing?

`perldoc extend.c` as jhorwitz mentioned. I'm not sure it's webified
in /docs/ -- if not, maybe it should be?

Thanks,
/Autrijus/

Jerry Gay

unread,
May 17, 2005, 4:45:54 PM5/17/05
to Autrijus Tang, Colin Paul Adams, perl6-i...@perl.org
On 5/17/05, Autrijus Tang <autr...@autrijus.org> wrote:
> On Tue, May 17, 2005 at 05:31:32PM +0100, Colin Paul Adams wrote:
> > I take it SS stands for String-to-String?
>
> Yes. "PPC" would stand for PMC -> PMC -> String, i.e. take two PMCs
> and returns a String.
>
of course, you meant PPS here, but i can't take credit for the catch :)

from #parrot:
[13:35] Coke: autrijus - did you mean PPS, not PPC ?
[13:35] Coke: (email)
[13:36] autrijus: I meant PPS. ;)
[13:36] autrijus: please reply me to correct my mistake :)
[13:36] autrijus: <- brain autocompletion
[13:37] Coke: I can't easily reply ATM
[13:44] particle: i'll do it

~jerry

Colin Paul Adams

unread,
May 18, 2005, 6:21:29 AM5/18/05
to Autrijus Tang, perl6-i...@perl.org
>>>>> "Autrijus" == Autrijus Tang <autr...@autrijus.org> writes:

Autrijus> On Tue, May 17, 2005 at 03:00:14PM +0100, Colin Paul


Autrijus> Adams wrote:
>> But when I look at http://www.parrotcode.org/docs/embed.html, I
>> can see no way of getting information back from the script -
>> not even an exit code. Is there anyway of doing this that I
>> have missed?

Autrijus> You may wish to use Parrot_call_sub's "SS" form, where
Autrijus> you pass in a string and get back a string. Something
Autrijus> like this:

Autrijus> my $interp = Parrot_new(undef);

Autrijus> # ... load a .pir file or some other code into
Autrijus> $interp ...

Autrijus> my $code_pmc = Parrot_find_global( $interp,
Autrijus> const_string("Namespace"), const_string("sub_name"), );

Autrijus> my $return_str = Parrot_call_sub( $interp,
Autrijus> $code_pmc, const_string("SS"),
Autrijus> const_string("Your_input_string_here"), );

I'm confused by this - what language is it written in? Perl?

And will:

Parrot_PackFile Parrot_readbc(Parrot_Interp, char *filename)

Reads in a bytecode file and returns a packfile structure for it.

accept a .pir file?

Leopold Toetsch

unread,
May 18, 2005, 7:05:32 AM5/18/05
to Colin Paul Adams, Autrijus Tang, perl6-i...@perl.org
Colin Paul Adams wrote:

> Autrijus> my $return_str = Parrot_call_sub( $interp,
> Autrijus> $code_pmc, const_string("SS"),
> Autrijus> const_string("Your_input_string_here"), );
>
> I'm confused by this - what language is it written in? Perl?

APL: Autrijus' Pseudocde Language

> And will:
>
> Parrot_PackFile Parrot_readbc(Parrot_Interp, char *filename)
>
> Reads in a bytecode file and returns a packfile structure for it.
>
> accept a .pir file?

No, but Parrot_load_bytecode(Interp*, const char*) will do, see the
C<load_bytecode> opcode.

leo

Colin Paul Adams

unread,
May 19, 2005, 10:37:31 AM5/19/05
to Autrijus Tang, perl6-i...@perl.org
>>>>> "Autrijus" == Autrijus Tang <autr...@autrijus.org> writes:

Autrijus> You may wish to use Parrot_call_sub's "SS" form, where
Autrijus> you pass in a string and get back a string. Something
Autrijus> like this:

Autrijus> my $interp = Parrot_new(undef);

Autrijus> # ... load a .pir file or some other code into
Autrijus> $interp ...

Autrijus> my $code_pmc = Parrot_find_global( $interp,
Autrijus> const_string("Namespace"), const_string("sub_name"), );

I'm having a problem with this.
For Parrot_find_global, I'm specifying global.h as one of the header
files which must be read to generate definitions from.
But this is failing, apparently because PMC isn't defined.

So I tried to find where PMC was defined - it looked like pobj.h to
me, but if I include that, I run into trouble with size_t (?!) and
DPOINTER (at least).

What headers do I need to read for the parrot_find_global call?

Colin Paul Adams

unread,
May 19, 2005, 11:21:48 AM5/19/05
to Jeff Horwitz, Autrijus Tang, perl6-i...@perl.org
>>>>> "Jeff" == Jeff Horwitz <je...@smashing.org> writes:

>> What headers do I need to read for the parrot_find_global call?

Jeff> Parrot_PMC is the public type, and behind the scenes it's
Jeff> defined as PMC *.

Jeff> all you should need to include is embed.h, extend.h and for
Jeff> now, resources.h. i'm actually working on fleshing these
Jeff> files out to be more consistent wrt the public API.

Jeff> see trunk/src/parrot_util.c in the mod_parrot source for a
Jeff> working example of all this.

Thanks. That reference was useful, as they have to be in that order
(resources.h first). it compiles now.

Jeff Horwitz

unread,
May 19, 2005, 11:00:51 AM5/19/05
to Colin Paul Adams, Autrijus Tang, perl6-i...@perl.org
On 19 May 2005, Colin Paul Adams wrote:

[snip]

> I'm having a problem with this.
> For Parrot_find_global, I'm specifying global.h as one of the header
> files which must be read to generate definitions from.
> But this is failing, apparently because PMC isn't defined.
>
> So I tried to find where PMC was defined - it looked like pobj.h to
> me, but if I include that, I run into trouble with size_t (?!) and
> DPOINTER (at least).
>
> What headers do I need to read for the parrot_find_global call?

Parrot_PMC is the public type, and behind the scenes it's defined as PMC *.

all you should need to include is embed.h, extend.h and for now,
resources.h. i'm actually working on fleshing these files out to be more


consistent wrt the public API.

see trunk/src/parrot_util.c in the mod_parrot source for a working
example of all this.

> --
> Colin Adams
> Preston Lancashire
>

-jeff

Colin Paul Adams

unread,
May 19, 2005, 12:32:02 PM5/19/05
to Jeff Horwitz, Autrijus Tang, perl6-i...@perl.org
>>>>> "Jeff" == Jeff Horwitz <je...@smashing.org> writes:

Jeff> all you should need to include is embed.h, extend.h and for
Jeff> now, resources.h. i'm actually working on fleshing these
Jeff> files out to be more consistent wrt the public API.

I'm getting real close now.

But I'm having problems creating the parrot strings. I'm using

Parrot_new_string

and I'm passing "UTF-8" as the encoding name.

I get back:

Can't make 'UTF-8' charset strings

Despite what the documentation says:

encoding

This specifies the encoding used to encode the characters in the
data. There are currently four character encodings used in Parrot:
singlebyte, UTF-8, UTF-16 and UTF-32. UTF-16 and UTF-32 should use the
native endianness of the machine.

So does that mean I'm limited to singlebyte strings? If so, how do I
specify this encoding, and what is the character set that is used?
(US-ASCII ?)

Colin Paul Adams

unread,
May 19, 2005, 1:18:12 PM5/19/05
to Jeff Horwitz, Autrijus Tang, perl6-i...@perl.org
>>>>> "Colin" == Colin Paul Adams <co...@colina.demon.co.uk> writes:

>>>>> "Jeff" == Jeff Horwitz <je...@smashing.org> writes:

Colin> Can't make 'UTF-8' charset strings

Colin> Despite what the documentation says:

Colin> encoding

Colin> This specifies the encoding used to encode the characters
Colin> in the data. There are currently four character encodings
Colin> used in Parrot: singlebyte, UTF-8, UTF-16 and
Colin> UTF-32. UTF-16 and UTF-32 should use the native endianness
Colin> of the machine.

Well, I found in the code what is actually accepted (iso-8859-1, for
instance, but that is hardly acceptable).

Leopold Toetsch

unread,
May 19, 2005, 3:48:10 PM5/19/05
to Colin Paul Adams, Jeff Horwitz, perl6-i...@perl.org
Colin Paul Adams wrote:

> Parrot_new_string
>
> and I'm passing "UTF-8" as the encoding name.
>
> I get back:
>
> Can't make 'UTF-8' charset strings

^^^^^^^

> Despite what the documentation says:
>
> encoding

Yeah. I'm sorry to say that: you are just hitting a part of Parrot
labeled "under (re)construction" and the docs aren't all up to date.

If you are using vim, "make tags" [1] in the parrot directory, follow
"string_make", which is called from Parrot_new_string() and you'll see a
more but still not complete listing of *charset*s that are supplied
currently. The ultimate list of charsets can be found in charset/*.c or
src/charset.c.

Additionally the interface doc is talking about an encoding, which is
pretty misleading:

fixed_8 - iso_8859_xxx

encoding - charset which one

You currently can just pass a charset, but the default encoding for the
charset "unicode" is "utf8" (now).

> This specifies the encoding used to encode the characters in the
> data. There are currently four character encodings used in Parrot:
> singlebyte, UTF-8, UTF-16 and UTF-32. UTF-16 and UTF-32 should use the
> native endianness of the machine.

That is outdated and future as well. Currently only utf8 encoding is
working (for some degree of working)

> So does that mean I'm limited to singlebyte strings?

No, pass charset "unicode", which defaults to encoding "utf8"

leo

[1] patches for other editors very welcome

Colin Paul Adams

unread,
May 20, 2005, 1:22:04 AM5/20/05
to Leopold Toetsch, Jeff Horwitz, perl6-i...@perl.org
>>>>> "Leopold" == Leopold Toetsch <l...@toetsch.at> writes:

Leopold> Yeah. I'm sorry to say that: you are just hitting a part
Leopold> of Parrot labeled "under (re)construction" and the docs
Leopold> aren't all up to date.

<snip>

>> So does that mean I'm limited to singlebyte strings?

Leopold> No, pass charset "unicode", which defaults to encoding
Leopold> "utf8"

OK. Thanks for that.

Autrijus Tang

unread,
May 20, 2005, 5:43:47 AM5/20/05
to Colin Paul Adams, Autrijus Tang, perl6-i...@perl.org
On Fri, May 20, 2005 at 10:34:39AM +0100, Colin Paul Adams wrote:
> I have a problem with this - namely that the function is variadic, and
> the interface generator can't cope with this.

Hmm, in Haskell FFI, we hard-coded two cases of invocation, treating
the function as two distinct, non-variadic forms:

-- From http://svn.openfoundry.org/pugs/src/Pugs/Embed/Parrot.hsc

-- This is the (() returns Void) form
foreign import ccall "Parrot_call_sub"
parrot_call_sub_vv :: ParrotInterp -> ParrotPMC -> CString -> IO ()

-- This is the ((String, String) returns String) form
foreign import ccall "Parrot_call_sub"
parrot_call_sub_SSS :: ParrotInterp -> ParrotPMC -> CString -> ParrotString -> ParrotString -> IO ParrotString

Surely you can do the same with Eiffel?

Thanks,
/Autrijus/

Colin Paul Adams

unread,
May 20, 2005, 5:34:39 AM5/20/05
to Autrijus Tang, perl6-i...@perl.org
>>>>> "Autrijus" == Autrijus Tang <autr...@autrijus.org> writes:

Autrijus> On Tue, May 17, 2005 at 03:00:14PM +0100, Colin Paul


Autrijus> Adams wrote:
>> But when I look at http://www.parrotcode.org/docs/embed.html, I
>> can see no way of getting information back from the script -
>> not even an exit code. Is there anyway of doing this that I
>> have missed?

Autrijus> You may wish to use Parrot_call_sub's "SS" form, where
Autrijus> you pass in a string and get back a string. Something
Autrijus> like this:

I have a problem with this - namely that the function is variadic, and
the interface generator can't cope with this.

So I'm going to have to do a lot of hand-coding to get round this
problem.

This is a general problem for interface generators, I believe. Would
it be possible to have more friendly functions in embed.h/c for use by
interface generators?
(By more friendly, I mean instead of ..., a single argument of some
list or array type.)

Leopold Toetsch

unread,
May 20, 2005, 5:48:17 AM5/20/05
to Colin Paul Adams, perl6-i...@perl.org
Colin Paul Adams <co...@colina.demon.co.uk> wrote:

> I have a problem with this - namely that the function is variadic, and
> the interface generator can't cope with this.

Have a look at src/inter_run.c e.g.

<void *
Parrot_runops_fromc_arglist(Parrot_Interp interpreter, PMC *sub,
const char *sig, va_list args)>


leo

Colin Paul Adams

unread,
May 20, 2005, 6:03:49 AM5/20/05
to l...@toetsch.at, perl6-i...@perl.org
>>>>> "Leopold" == Leopold Toetsch <l...@toetsch.at> writes:

Leopold> Colin Paul Adams <co...@colina.demon.co.uk> wrote:
>> I have a problem with this - namely that the function is
>> variadic, and the interface generator can't cope with this.

Leopold> Have a look at src/inter_run.c e.g.

Leopold> <void * Parrot_runops_fromc_arglist(Parrot_Interp
Leopold> interpreter, PMC *sub, const char *sig, va_list args)>

That sounds like just the thing!

Colin Paul Adams

unread,
May 20, 2005, 6:00:25 AM5/20/05
to Autrijus Tang, perl6-i...@perl.org
>>>>> "Autrijus" == Autrijus Tang <autr...@autrijus.org> writes:

Autrijus> On Fri, May 20, 2005 at 10:34:39AM +0100, Colin Paul


Autrijus> Adams wrote:
>> I have a problem with this - namely that the function is
>> variadic, and the interface generator can't cope with this.

Autrijus> Hmm, in Haskell FFI, we hard-coded two cases of
Autrijus> invocation, treating the function as two distinct,
Autrijus> non-variadic forms:

Autrijus> -- From
Autrijus> http://svn.openfoundry.org/pugs/src/Pugs/Embed/Parrot.hsc

Autrijus> -- This is the (() returns Void) form foreign import
Autrijus> ccall "Parrot_call_sub" parrot_call_sub_vv ::
Autrijus> ParrotInterp -> ParrotPMC -> CString -> IO ()

Autrijus> -- This is the ((String, String) returns String)
Autrijus> form foreign import ccall "Parrot_call_sub"
Autrijus> parrot_call_sub_SSS :: ParrotInterp -> ParrotPMC ->
Autrijus> CString -> ParrotString -> ParrotString -> IO
Autrijus> ParrotString

Autrijus> Surely you can do the same with Eiffel?

Yes, I can, but that only copes with a single string parameter - there
are very many possibilities (strictly, infinite, though obviously not
in practice).
Also, I shall want to use the object/method calls, which adds further
to the burden.

And I'm not just coding this for my XSLT processor - I am going to
make the Eiffel library freely available to all Eiffel programmers.
That way, any Eiffel program can use any Parrot-targetted scripting
language as an extension language (and the language can be chosen by
the user of the application who wants to do the scripting, not imposed
by the developer of the application).
So this requires a lot of flexibility.

I can easily code by hand (and will, for now) just those subroutines
and methods I shall require for use within my XSLT processor, but to
do them all in general will be too much (so I shall have to request
each application deleoper to add the code necessary that they want).

And this applies to anyone else who wants to use Parrot as a
multi-lingual extension mechanism for another language.

Colin Paul Adams

unread,
May 20, 2005, 12:42:48 PM5/20/05
to Autrijus Tang, perl6-i...@perl.org
>>>>> "Autrijus" == Autrijus Tang <autr...@autrijus.org> writes:

Autrijus> You may wish to use Parrot_call_sub's "SS" form, where
Autrijus> you pass in a string and get back a string. Something
Autrijus> like this:

Autrijus> my $interp = Parrot_new(undef);

Autrijus> # ... load a .pir file or some other code into
Autrijus> $interp ...

Autrijus> my $code_pmc = Parrot_find_global( $interp,
Autrijus> const_string("Namespace"), const_string("sub_name"), );

Autrijus> my $return_str = Parrot_call_sub( $interp,
Autrijus> $code_pmc, const_string("SS"),
Autrijus> const_string("Your_input_string_here"), );

The problem I'm finding with this, is getting back the returned string
characters.
I assume the void * returned is pointing to a Parrot String.
Certainly it's not a const char *.

There is a function declaration

Parrot_string_cstring

in string_funcs.h, but it appears to have no definitoon anywhere, so
that's not much use to me.

Autrijus Tang

unread,
May 20, 2005, 12:53:15 PM5/20/05
to Colin Paul Adams, Autrijus Tang, perl6-i...@perl.org
On Fri, May 20, 2005 at 05:42:48PM +0100, Colin Paul Adams wrote:
> The problem I'm finding with this, is getting back the returned string
> characters.
> I assume the void * returned is pointing to a Parrot String.
> Certainly it's not a const char *.

Yes.

> There is a function declaration
> Parrot_string_cstring
>
> in string_funcs.h, but it appears to have no definitoon anywhere, so
> that's not much use to me.

Yeah, I bumped against that too. You need to look at the "strstart"
field in the ParrotString struct.

In Haskell I use:

peekCString =<< #{peek STRING, strstart} s5

Thanks,
/Autrijus/

Autrijus Tang

unread,
May 20, 2005, 1:03:43 PM5/20/05
to Autrijus Tang, Colin Paul Adams, perl6-i...@perl.org
On Sat, May 21, 2005 at 12:53:15AM +0800, Autrijus Tang wrote:
> On Fri, May 20, 2005 at 05:42:48PM +0100, Colin Paul Adams wrote:
> > There is a function declaration
> > Parrot_string_cstring
> >
> > in string_funcs.h, but it appears to have no definitoon anywhere, so
> > that's not much use to me.
>
> Yeah, I bumped against that too. You need to look at the "strstart"
> field in the ParrotString struct.

Coming to think about it, we should either implement
Parrot_string_cstring or take it away from the includes.

I've checked in a naïve implementation as r8135.

Thanks,
/Autrijus/

Autrijus Tang

unread,
May 20, 2005, 1:15:08 PM5/20/05
to Autrijus Tang, Colin Paul Adams, perl6-i...@perl.org
On Sat, May 21, 2005 at 12:53:15AM +0800, Autrijus Tang wrote:
> Yeah, I bumped against that too. You need to look at the "strstart"
> field in the ParrotString struct.
>
> In Haskell I use:
>
> peekCString =<< #{peek STRING, strstart} s5

Actually, never mind; string_to_cstring is the way to go.

Thanks,
/Autrijus/

Dan Sugalski

unread,
May 20, 2005, 1:47:46 PM5/20/05
to Autrijus Tang, Colin Paul Adams, perl6-i...@perl.org

Well, mostly. string->cstring conversion is potentially lossy, if for
no other reason than embedded nulls will get in your way. I see we're
not exposing anything to do that, though, which we ought to fix.
--
Dan

--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

Colin Paul Adams

unread,
May 20, 2005, 3:10:06 PM5/20/05
to l...@toetsch.at, perl6-i...@perl.org
>>>>> "Leopold" == Leopold Toetsch <l...@toetsch.at> writes:

Leopold> Colin Paul Adams <co...@colina.demon.co.uk> wrote:
>> I have a problem with this - namely that the function is
>> variadic, and the interface generator can't cope with this.

Leopold> Have a look at src/inter_run.c e.g.

Leopold> <void * Parrot_runops_fromc_arglist(Parrot_Interp
Leopold> interpreter, PMC *sub, const char *sig, va_list args)>

Despite what I said before, this is actually worse than
Parrot_call_sub.
The interface generator ignores it completely, rather than generating
an incorrect signature (I suppose that's an improvement really, except
then it can't even be used for subroutines which accept zero
arguments).
And as for hand-writing interfaces, I'm not sure I know HOW to create
a va_list.

Leopold Toetsch

unread,
May 20, 2005, 4:09:41 PM5/20/05
to Colin Paul Adams, perl6-i...@perl.org
Colin Paul Adams wrote:
>>>>>>"Leopold" == Leopold Toetsch <l...@toetsch.at> writes:

> Leopold> <void * Parrot_runops_fromc_arglist(Parrot_Interp
> Leopold> interpreter, PMC *sub, const char *sig, va_list args)>
>
> Despite what I said before, this is actually worse than
> Parrot_call_sub.
> The interface generator ignores it completely,

What interface generator?

> ... rather than generating


> an incorrect signature (I suppose that's an improvement really, except
> then it can't even be used for subroutines which accept zero
> arguments).

signature letter "v" - void.

> And as for hand-writing interfaces, I'm not sure I know HOW to create
> a va_list.

see the various usages in the mentioned file.

leo

C. Scott Ananian

unread,
May 20, 2005, 4:35:29 PM5/20/05
to Dan Sugalski, Autrijus Tang, Colin Paul Adams, perl6-i...@perl.org
On Fri, 20 May 2005, Dan Sugalski wrote:

> Well, mostly. string->cstring conversion is potentially lossy, if for no
> other reason than embedded nulls will get in your way. I see we're not
> exposing anything to do that, though, which we ought to fix.

pascal-style strings (ie, char* and length) are the canonical way to
fix this. C code generally doesn't have too much trouble replacing
strcpy with memcpy, etc...
--scott

Sudan insurgent SGUAT HTKEEPER LCFLUTTER chemical agent hack Semtex
Iraq JMWAVE interception $400 million in gold bullion KUPALM SSBN 731
( http://cscott.net/ )

Dan Sugalski

unread,
May 20, 2005, 4:10:49 PM5/20/05
to Colin Paul Adams, l...@toetsch.at, perl6-i...@perl.org
At 8:10 PM +0100 5/20/05, Colin Paul Adams wrote:
> >>>>> "Leopold" == Leopold Toetsch <l...@toetsch.at> writes:
>
> Leopold> Colin Paul Adams <co...@colina.demon.co.uk> wrote:
> >> I have a problem with this - namely that the function is
> >> variadic, and the interface generator can't cope with this.
>
> Leopold> Have a look at src/inter_run.c e.g.
>
> Leopold> <void * Parrot_runops_fromc_arglist(Parrot_Interp
> Leopold> interpreter, PMC *sub, const char *sig, va_list args)>
>
>Despite what I said before, this is actually worse than
>Parrot_call_sub.
>The interface generator ignores it completely, rather than generating
>an incorrect signature (I suppose that's an improvement really, except
>then it can't even be used for subroutines which accept zero
>arguments).

Then the question is: What'd work? There are limits to what's going
to be useful if you're not in a position to do full variadic function
calls, and I'm not sure that we should put too many special cases in.
On the other hand, I know how much of a pain this can be, since I did
the first implementation of parrot's NCI interface, which has the
same sorts of issues to deal with.

So, I see four real options:

1) Someone fixes the Eiffel interface generator to understand C
variadic functions.
2) We provide a function and method call interface that assumes
you've already pre-filled in the registers according to parrot's
calling conventions
3) We build some sort of really simple call interface that takes an
array PMC with the parameters stuffed into it
4) Parrot provides some sort of facility to autogenerate shim
functions based on a passed-in signature

None of them are particularly good, and they'll all potentially cause
you problems with an interface generator. 1's the best (and not just
because it means we don't have to do anything :) but that's probably
untenable. #4 is probably the next easiest thing, but I'm not sure
that you could use that without at least some tweaks to the interface
generator, and it'd be a bit dodgy on systems we don't have JIT
capabilities on. #s 2&3 are sub-optimal, and either require some work
on the caller's part (or changes to the interface generator) or kinda
limit what you can do.

Teaching the interface generator about variadic functions is probably
the easiest thing -- in principle it's not that tough (Hey, I did
one, I get to say that :) though that does depend on what the code in
the interface generator looks like.

Dan Sugalski

unread,
May 20, 2005, 4:44:34 PM5/20/05
to C. Scott Ananian, Autrijus Tang, Colin Paul Adams, perl6-i...@perl.org
At 4:35 PM -0400 5/20/05, C. Scott Ananian wrote:
>On Fri, 20 May 2005, Dan Sugalski wrote:
>
>>Well, mostly. string->cstring conversion is potentially lossy, if
>>for no other reason than embedded nulls will get in your way. I see
>>we're not exposing anything to do that, though, which we ought to
>>fix.
>
>pascal-style strings (ie, char* and length) are the canonical way to
>fix this. C code generally doesn't have too much trouble replacing
>strcpy with memcpy, etc...

That's what parrot strings are. (Well, a bit more than that, since we
carry around encoding and charset information as well) It's only when
you drop down to C-style "blob 'o memory with an in-band EOS marker"
that you run into trouble.

There are interfaces in the extension system to get a void * and
length back from a PMC when fetching string data out, but I see we
don't have that for plain strings. I'll probably fix that this
weekend if someone doesn't beat me to it.

C. Scott Ananian

unread,
May 20, 2005, 5:30:04 PM5/20/05
to Colin Paul Adams, l...@toetsch.at, perl6-i...@perl.org
On Fri, 20 May 2005, Colin Paul Adams wrote:

> Leopold> <void * Parrot_runops_fromc_arglist(Parrot_Interp
> Leopold> interpreter, PMC *sub, const char *sig, va_list args)>

> And as for hand-writing interfaces, I'm not sure I know HOW to create
> a va_list.

void *Parrot_runops_fromc_argsN(Parrot_Interp i, PMC *sub,
const char *sig, ...) {
void *result;
va_list ap;
va_start(ap, sig);
result = Parrot_runops_fromc_arglist(i,sub,sig,ap);
va_end(ap);
return result;
}
void *Parrot_runops_fromc_args0(Parrot_Interp i, PMC *sub, con