Re: Parrot as an extension language
Dan == Dan Sugalski [EMAIL PROTECTED] writes: Dan So, I see four real options: Dan 1) Someone fixes the Eiffel interface generator to understand Dan C variadic functions. 2) We provide a function and method Dan call interface that assumes you've already pre-filled in the Dan registers according to parrot's calling conventions 3) We Dan build some sort of really simple call interface that takes an Dan array PMC with the parameters stuffed into it 4) Parrot Dan provides some sort of facility to autogenerate shim functions Dan based on a passed-in signature I was thinking of option (3). Dan #s 23 are sub-optimal, Dan and either require some work on the caller's part (or changes Dan to the interface generator) or kinda limit what you can do. It's inevitable that the caller has to do some work in a strongly typed language. Dan Teaching the interface generator about variadic functions is Dan probably the easiest thing -- in principle it's not that Dan tough (Hey, I did one, I get to say that :) though that does Dan depend on what the code in the interface generator looks Dan like. But what code can you possibly generate if the source language is strongly typed? You can't generate an infinite number of function definitions. -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
Dan Sugalski [EMAIL PROTECTED] wrote: 1) Someone fixes the Eiffel interface generator to understand C variadic functions. Yep :) 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 That exists already albeit not in extend.* 3) We build some sort of really simple call interface that takes an array PMC with the parameters stuffed into it What's the difference WRT va_list? If the interface code can stuff things into an array, it sould as well be able to prepare a va_list. 4) Parrot provides some sort of facility to autogenerate shim functions based on a passed-in signature Besides the combinatorial problem that we already have in nci.c, why can't this interface function not do the call in the first place, if it has to investigate the signature anyway? leo
Re: Parrot as an extension language
Leopold == Leopold Toetsch [EMAIL PROTECTED] writes: Leopold What's the difference WRT va_list? If the interface code Leopold can stuff things into an array, it sould as well be able Leopold to prepare a va_list. You are quite right. I'll harass the author of the interface generator. -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
Colin Paul Adams wrote: Leopold == Leopold Toetsch [EMAIL PROTECTED] writes: Leopold What's the difference WRT va_list? If the interface code Leopold can stuff things into an array, it sould as well be able Leopold to prepare a va_list. You are quite right. I'll harass the author of the interface generator. BTW (again) which interface generator for which Eiffel? Can you please provide a link to the docs. Thanks, leo
Re: Parrot as an extension language
Leopold == Leopold Toetsch [EMAIL PROTECTED] writes: Leopold BTW (again) which interface generator for which Eiffel? Oops. I missed that last bit. All current Eiffel compilers are supported. -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
Colin == Colin Paul Adams [EMAIL PROTECTED] writes: Leopold == Leopold Toetsch [EMAIL PROTECTED] writes: Leopold What's the difference WRT va_list? If the interface code Leopold can stuff things into an array, it sould as well be able Leopold to prepare a va_list. Colin You are quite right. I'll harass the author of the Colin interface generator. Well, maybe that isn't right after all. According to the following, it's not possible: http://gcc.gnu.org/ml/gcc/2000-10/msg00174.html -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
Colin Paul Adams wrote: Colin == Colin Paul Adams [EMAIL PROTECTED] writes: Leopold == Leopold Toetsch [EMAIL PROTECTED] writes: Leopold What's the difference WRT va_list? If the interface code Leopold can stuff things into an array, it sould as well be able Leopold to prepare a va_list. Colin You are quite right. I'll harass the author of the Colin interface generator. Well, maybe that isn't right after all. According to the following, it's not possible: http://gcc.gnu.org/ml/gcc/2000-10/msg00174.html I'd say you just have to hack the function generator in c_glue_code. The code has to emit a C function that loops over its argument types (available somewhere in the AST), assembles a Parrot function signature string and the va_list. But I don't speak Eiffel. leo
Re: Parrot as an extension language
Autrijus == Autrijus Tang [EMAIL PROTECTED] 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.) -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
Colin Paul Adams [EMAIL PROTECTED] 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
Re: Parrot as an extension language
Autrijus == Autrijus Tang [EMAIL PROTECTED] 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 Adams Preston Lancashire
Re: Parrot as an extension language
Leopold == Leopold Toetsch [EMAIL PROTECTED] writes: Leopold Colin Paul Adams [EMAIL PROTECTED] 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 Adams Preston Lancashire
Re: Parrot as an extension language
Autrijus == Autrijus Tang [EMAIL PROTECTED] 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. -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
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/
pgpbLrF1rNwO3.pgp
Description: PGP signature
Re: Parrot as an extension language
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 nave implementation as r8135. Thanks, /Autrijus/ pgpUNo6gVdymw.pgp Description: PGP signature
Re: Parrot as an extension language
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/
pgpGlKoL0Zxas.pgp
Description: PGP signature
Re: Parrot as an extension language
At 1:15 AM +0800 5/21/05, Autrijus Tang wrote:
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.
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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Parrot as an extension language
Leopold == Leopold Toetsch [EMAIL PROTECTED] writes: Leopold Colin Paul Adams [EMAIL PROTECTED] 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. -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
Colin Paul Adams wrote: Leopold == Leopold Toetsch [EMAIL PROTECTED] 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
Re: Parrot as an extension language
At 8:10 PM +0100 5/20/05, Colin Paul Adams wrote: Leopold == Leopold Toetsch [EMAIL PROTECTED] writes: Leopold Colin Paul Adams [EMAIL PROTECTED] 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 23 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 --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot as an extension language
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/ )
Re: Parrot as an extension language
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. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Parrot as an extension language
Dan Sugalski wrote: 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. There was a disucssion WRT that on #parrot today: Autrijus had implemented: const char *Parrot_string_cstring(Interp *, const STRING *); This was in string_funcs.h only albeit it didn't have an Interp* argument originally. It returns str-strstart, which is currently not quite right or safe. We can do one of: a) return the length additionally to strstart b) internally delimit C-strings by an invisibile NUL. And we have to limit this function for fixed8-encoded strings and make clear that the returned string is immutable. For other cases we have already string_to_cstring (and an interface in extend.h) which returns a malloced copy of the string. leo
Re: Parrot as an extension language
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, const char *sig){
return Parrot_runops_fromc_argsN(i, sub, sig);
}
void *Parrot_runops_fromc_args1(Parrot_Interp i, PMC *sub, const char *sig,
void **args){
return Parrot_runops_fromc_argsN(i, sub, sig, args[0]);
}
void *Parrot_runops_fromc_args2(Parrot_Interp i, PMC *sub, const char *sig,
void **args){
return Parrot_runops_fromc_argsN(i, sub, sig, args[0], args[1]);
}
/* .. etc .. */
typedef void (*pf_t)(Parrot_Interp i, PMC *sub, const char *sig, void **args);
void *Parrot_runops_fromc_args(Parrot_Interp i, PMC *sub, const char *sig,
void **args, int num_args){
static const pf_t dispatch[] = { Parrot_runops_fromc_args0,
Parrot_runops_fromc_args1,
Parrot_runops_fromc_args2,
/* ... etc ... */ };
assert(num_args (sizeof(dispatch)/sizeof(*dispatch)));
return (dispatch[num_args])(i, sub, sig, args);
}
See? Easy! =)
Of course, if your arguments array is not homogeneous, this scheme gets
more complicated (that's why the va_list is being used to start with),
but it's still quite possible. It is very rare to find functions of more
than, say, 10 arguments.
--scott
Echelon JMBLUG GRALLSPICE cryptographic KUGOWN Waihopai HBDRILL ESODIC
SEAL Team 6 Nader Bush LICOZY RUCKUS Sabana Seca ODEARL COBRA JANE
( http://cscott.net/ )
Re: Parrot as an extension language
On Fri, 20 May 2005, Dan Sugalski wrote: 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 See http://java.sun.com/j2se/1.4.2/docs/guide/jni/spec/functions.html#wp4256 I think what's missing currently is the interface which takes the 'jvalue *' in the JNI interface; ie option #3 (if I understand you correctly). In my implementation of the JNI (for the FLEX java compiler's runtime) I implemented everything in terms of this 'MethodA' variant; the '...' version easily packs up to a va_list, and then the va_list version needs to parse the method/sub's signature and generate an appropriate array of PMCs which can be passed to the (canonical) 'MethodA' version. --scott AMTHUG Waco, Texas ODEARL overthrow assassinate Sabana Seca Albanian strategic Blair blowfish atomic AP GPFLOOR AVBUSY cryptographic pending ( http://cscott.net/ )
Re: Parrot as an extension language
Autrijus == Autrijus Tang [EMAIL PROTECTED] 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 Adams Preston Lancashire
Re: Parrot as an extension language
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
Re: Parrot as an extension language
Jeff == Jeff Horwitz [EMAIL PROTECTED] 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. -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
Colin == Colin Paul Adams [EMAIL PROTECTED] writes: Jeff == Jeff Horwitz [EMAIL PROTECTED] 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). -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
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
Re: Parrot as an extension language
Leopold == Leopold Toetsch [EMAIL PROTECTED] 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. -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
Autrijus == Autrijus Tang [EMAIL PROTECTED] 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? -- Colin Adams Preston Lancashire
Re: Parrot as an extension language
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 Cload_bytecode opcode. leo
Parrot as an extension language
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
Re: Parrot as an extension language
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: 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
Re: Parrot as an extension language
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/ pgpMe8pdQExhO.pgp Description: PGP signature
