Re: More embedding questions

On Tuesday 16 January 2007 16:56, Isaac Freeman wrote: \ > So, for my purposes I need an embedding interface that allows for more > control of the interpretter, e.g. the ability to inspect/modify > namespace(s) and eventually control which opcodes are allowed, or > register callbacks

More embedding questions

So, for my purposes I need an embedding interface that allows for more control of the interpretter, e.g. the ability to inspect/modify namespace(s) and eventually control which opcodes are allowed, or register callbacks for opcodes (i.e. file access, etc) for security purposes. Tackling the

Re: embedding

munication between the embedding program and the scripts being run by the interpreter... Is this simply not implemented? If not, are there plans to? I would love to help implement this if it would be accepted in the main source tree. If this is already implemented, can someone please give me some poin

embedding

Hello, I am looking to embed parrot in a project of mine, sort of as a configuration/scripting engine. I've looked at embed.h, and it does show how to start an interpreter, and how to make it run code, but I don't see any mechanism for communication between the embedding program and t

Exceedingly lightweight C embedding

This is impressive, though this particular implementation is admittedly limited (no static checking, and doesn't handle errors in the C code gracefully): Allison

Re: embedding ParTcl

On Jul 27, 2005, at 9:46 PM, Thilo Planz wrote: Hi, I have a few beginner's question about ParTcl. I am trying to embed ParTcl into a PIR application, which seems to work quite nicely, except that I have not yet figured out how to do certain things. This is almost certainly no fault

embedding ParTcl

Hi, I have a few beginner's question about ParTcl. I am trying to embed ParTcl into a PIR application, which seems to work quite nicely, except that I have not yet figured out how to do certain things. = 1) Is there a way to reset the Tcl interpreter between invocations? .sub _main @M

Re: embedding/extending interface

chromatic wrote: On Wed, 2005-07-13 at 15:41 +0100, Nicholas Clark wrote: Did anything come of this? Or is chromatic still waiting in the wings for confirmation that this is the right way to go? I'm still waiting for confirmation. I can send my existing (needs polish) patch if that will he

Re: embedding/extending interface

On Wed, 2005-07-13 at 15:41 +0100, Nicholas Clark wrote: > Did anything come of this? Or is chromatic still waiting in the wings for > confirmation that this is the right way to go? I'm still waiting for confirmation. I can send my existing (needs polish) patch if that will help speed the discus

Re: embedding/extending interface

On Wed, 13 Jul 2005, Nicholas Clark wrote: > On Wed, May 11, 2005 at 11:18:30AM +0100, Nicholas Clark wrote: > > On Tue, May 10, 2005 at 01:13:48PM -0400, Jeff Horwitz wrote: > > > as part of both the pugs and mod_parrot effort, i've started working on > > > brin

Re: embedding/extending interface

On Wed, May 11, 2005 at 11:18:30AM +0100, Nicholas Clark wrote: > On Tue, May 10, 2005 at 01:13:48PM -0400, Jeff Horwitz wrote: > > as part of both the pugs and mod_parrot effort, i've started working on > > bringing the embedding and extending interfaces into the modern parro

Re: embedding w/ new calling conventions

Jeff Horwitz wrote: mod_parrot is running into a bit of trouble calling subs written in PIR with the new calling conventions. [ ... ] this may all be premature, as leo's branch is still brand-spanking new, Yep, very premature. I'd be glad to get some test cases, though. -jeff Thanks,

embedding w/ new calling conventions

mod_parrot is running into a bit of trouble calling subs written in PIR with the new calling conventions. some initial observations: * using Parrot_call_sub_* seems to require a get_params opcode (or a .param), else it dies with "no get_params in sub". this is true even when called with a vo

Re: embedding/extending interface

On Tue, May 10, 2005 at 01:13:48PM -0400, Jeff Horwitz wrote: > as part of both the pugs and mod_parrot effort, i've started working on > bringing the embedding and extending interfaces into the modern parrot > era. i'd like to start by adding public APIs (Parrot_*) where nec

embedding/extending interface

as part of both the pugs and mod_parrot effort, i've started working on bringing the embedding and extending interfaces into the modern parrot era. i'd like to start by adding public APIs (Parrot_*) where necessary and adding missing prototypes to the headers. this will clean things

Re: embedding initialization

excellent! now i can get rid of that silly no-op bytecode i've been using. thanks for the quick turnaround, leo. -jeff On Thu, 5 May 2005, Leopold Toetsch wrote: > Jeff Horwitz wrote: > > i'm neck deep in writing the IMC eval code for pugs. ... > > > ... but i imagine there's a more > > elegan

Re: embedding initialization

Jeff Horwitz wrote: i'm neck deep in writing the IMC eval code for pugs. ... ... but i imagine there's a more elegant solution out there. t/src/compiler.t has now all the steps to run a PIR code string from C. It's not elegant though, because there are no APIs, but it should make things running.

Re: embedding initialization

Jeff Horwitz wrote: i'm neck deep in writing the IMC eval code for pugs. if i've already loaded bytecode using Parrot_readbc/loadbc, i can then successfully call the PIR compiler and eval code at will from C/Haskell. great! however, without the Parrot_readbc step, everything bombs out because the

embedding initialization

i'm neck deep in writing the IMC eval code for pugs. if i've already loaded bytecode using Parrot_readbc/loadbc, i can then successfully call the PIR compiler and eval code at will from C/Haskell. great! however, without the Parrot_readbc step, everything bombs out because the packfile isn't set

FYI embedding API change

A lot of the packfile functions that didn't take an C as first argument now have one. This change was necessary to switch PMC constants {un,}packing to freeze/thaw eventually. Sorry for the disruption and the big patch, but it's an all or nothing thingy basically. Thanks, leo

Re: embedding/extending issues

P_" in front are skipped. > many of the functions i need to perform in an embedding environment (PMC > value manipulation, calling parrot subroutines, etc.) are only available > if i include extend.h in addition to embed.h. extend.h is for sure incomplete. But it should only wr

embedding/extending issues

. i may just have to get this from ICU's configuration, but i think parrot, like perl 5 right now, should be able to list all its required dependencies in one place to make life easier for embedders. --- many of the functions i need to perform in an embedding environment (PMC value m

Re: Questions about Embedding Parrot / mod_parrot

Chromatic <[EMAIL PROTECTED]> wrote: > On Mon, 2004-05-24 at 03:43, Leopold Toetsch wrote: >> Yep. The main problem is that by far not all internal code paths are >> using exceptions so that you could interfer the exit handling. This >> needs of course being fixed somewhen. > Is this as simple an

Re: Questions about Embedding Parrot / mod_parrot

On Mon, 2004-05-24 at 03:43, Leopold Toetsch wrote: > Yep. The main problem is that by far not all internal code paths are > using exceptions so that you could interfer the exit handling. This > needs of course being fixed somewhen. Is this as simple and tedious as replacing all Parrot_exit() cal

Re: Questions about Embedding Parrot / mod_parrot

. This is horrible from an embedding perspective. Yep. The main problem is that by far not all internal code paths are using exceptions so that you could interfer the exit handling. This needs of course being fixed somewhen. > ... I believe it should be > a runtime configuration setting to not

Questions about Embedding Parrot / mod_parrot

any places after an error occurs. This function calls any exit callbacks previously entered, and then calls exit(). This is horrible from an embedding perspective. In particular, it should be avoided in the Apache model, where many threads in the same process are handling other requests. I believe it s

Re: Embedding and stack

Nicholas Clark <[EMAIL PROTECTED]> wrote: > +void * > +Parrot_Embed_PMC_get_pointer(Parrot_Interp interp, Parrot_PMC pmc) { > +if(interp->lo_var_ptr) { > +return Parrot_PMC_get_pointer(interp, pmc); > +} else { > +void *result; /* Doubles up as an indicator of stack top. *

Re: Embedding and stack

chored) > 2) No call into parrot from the outside needs to pass in a stack top > (though it may via a separate call if it so chooses) > 3) The embedding wrapper is responsible for setting and resetting the > top of stack. With the appended hack patch which sets/clears the stack top poi

Re: Embedding and stack

Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: > Dan Sugalski wrote: >> 3) The embedding wrapper is responsible for setting and resetting the >> top of stack. > Proof-of-concept: Looks good. Thanks, applied. leo

Re: Embedding and stack

At 9:33 PM +0100 5/3/04, Nicholas Clark wrote: On Mon, May 03, 2004 at 10:46:28AM -0400, Dan Sugalski wrote: 3) The embedding wrapper is responsible for setting and resetting the top of stack. I don't think that this is quite right. The embedding wrapper needs to set (and reset) the top of

Re: Embedding and stack

On Mon, May 03, 2004 at 04:36:38PM -0400, Dan Sugalski wrote: > At 9:33 PM +0100 5/3/04, Nicholas Clark wrote: > >On Mon, May 03, 2004 at 10:46:28AM -0400, Dan Sugalski wrote: > > > >> 3) The embedding wrapper is responsible for setting and resetting the > >> t

Re: Embedding and stack

At 9:43 PM +0100 5/3/04, Nicholas Clark wrote: On Mon, May 03, 2004 at 04:36:38PM -0400, Dan Sugalski wrote: At 9:33 PM +0100 5/3/04, Nicholas Clark wrote: >On Mon, May 03, 2004 at 10:46:28AM -0400, Dan Sugalski wrote: > >> 3) The embedding wrapper is responsible for setting and r

Re: Embedding and stack

On Mon, May 03, 2004 at 10:46:28AM -0400, Dan Sugalski wrote: > 3) The embedding wrapper is responsible for setting and resetting the > top of stack. I don't think that this is quite right. The embedding wrapper needs to set (and reset) the top of stack only if it's not set.

Re: Embedding and stack

Dan Sugalski wrote: 3) The embedding wrapper is responsible for setting and resetting the top of stack. Proof-of-concept: --- src/embed.c 2 May 2004 10:47:54 - 1.113 +++ src/embed.c 3 May 2004 19:08:23 - @@ -666,6 +666,17 @@ void Parrot_runcode(Interp *interpreter, int argc, char

Embedding and stack

may via a separate call if it so chooses) 3) The embedding wrapper is responsible for setting and resetting the top of stack. While I don't want the extension interface to register PMCs by default (since that's generally unneccesary) I'm OK beefing up the interface to have an allo

Parrot Embedding Questions

Hi, I would like to add Parrot as a scripting engine for a software project. Embedding it is no problem, but I was wondering if the current implementation supports the embedder to provide functions to the Parrot bytecode applications? The idea is that I would like to access C functions the

RE: Re[2]: Embedding vs. extending interface types

Dan Sugalski wrote: > And pointless. Let's just rename it to Parrot_Interp everywhere. I've submitted a patch for this already. -- Gordon Henriksen IT Manager ICLUBcentral Inc. [EMAIL PROTECTED]

Re[2]: Embedding vs. extending interface types

At 8:57 AM +0100 1/25/04, Mattia Barbon wrote: Il Sat, 24 Jan 2004 19:42:20 -0500 Gordon Henriksen <[EMAIL PROTECTED]> ha scritto: On Saturday, January 24, 2004, at 11:28 , Mattia Barbon wrote: > I feel I'm becoming annoying, but: the embedding and extending > interface

Re: Embedding vs. extending interface types

On Sunday, January 25, 2004, at 07:08 , Leopold Toetsch wrote: Gordon Henriksen <[EMAIL PROTECTED]> wrote: Speaking of cleaning and uniting, what is with this? #define bufstart obj.u.b.bufstart #define buflen obj.u.b.buflen These are *currently* necessary macros, until the PMC/PObj layout is

Re: Embedding vs. extending interface types

Gordon Henriksen <[EMAIL PROTECTED]> wrote: > Speaking of cleaning and uniting, what is with this? > #define bufstart obj.u.b.bufstart > #define buflen obj.u.b.buflen These are *currently* necessary macros, until the PMC/PObj layout is really carved in stones. You had in your proposal a differ

Re: Embedding vs. extending interface types

On Sunday, January 25, 2004, at 03:44 , Leopold Toetsch wrote: Gordon Henriksen <[EMAIL PROTECTED]> wrote: All embedders see is this: typedef struct Parrot_Interp *Parrot_Interp; I don't do decisions on embedding or extending interfaces. But it seems to be the time to decide (and

Re: Embedding vs. extending interface types

Gordon Henriksen <[EMAIL PROTECTED]> wrote: > All embedders see is this: > typedef struct Parrot_Interp *Parrot_Interp; I don't do decisions on embedding or extending interfaces. But it seems to be the time to decide (and clean/unite) the current names: struct

Re: Embedding vs. extending interface types

On Saturday, January 24, 2004, at 02:28 , Leopold Toetsch wrote: Mattia Barbon <[EMAIL PROTECTED]> wrote: I feel I'm becoming annoying, but: the embedding and extending interfaces are still using different names for Parrot_Interp/Parrot_INTERP. Which one is correct? AFAIK both. Em

Re[2]: Embedding vs. extending interface types

Il Sat, 24 Jan 2004 19:42:20 -0500 Gordon Henriksen <[EMAIL PROTECTED]> ha scritto: > On Saturday, January 24, 2004, at 11:28 , Mattia Barbon wrote: > > > I feel I'm becoming annoying, but: the embedding and extending > > interfaces are still using different

Re: Embedding vs. extending interface types

Mattia Barbon <[EMAIL PROTECTED]> wrote: > Hello, > I feel I'm becoming annoying, but: the embedding and extending > interfaces are still using different names for Parrot_Interp/Parrot_INTERP. > Which one is correct? AFAIK both. Embedding and extending are to differe

Re: Embedding vs. extending interface types

I wrote: Mattia Barbon wrote: I feel I'm becoming annoying, but: the embedding and extending interfaces are still using different names for Parrot_Interp/Parrot_INTERP. Which one is correct? [blahblahblah] Spoke too soon. Parrot_INTERP looks unnecessary. Parrot_Interp already has the n

Re: Embedding vs. extending interface types

On Saturday, January 24, 2004, at 11:28 , Mattia Barbon wrote: I feel I'm becoming annoying, but: the embedding and extending interfaces are still using different names for Parrot_Interp/Parrot_INTERP. Which one is correct? Mattia, Both are correct. Sort of. :) Parrot_INTERP is an opaque

Embedding vs. extending interface types

Hello, I feel I'm becoming annoying, but: the embedding and extending interfaces are still using different names for Parrot_Interp/Parrot_INTERP. Which one is correct? Thanks! Mattia

[PATCH] Embedding interface change

Beware :) This patch changes Parrot_loadbc to Parrot_set_packfile. 0x4C56 diff Description: Binary data

Re: Embedding interface to PMCs

If the pdd is amended, let's not forget to update the check_source script- for that matter, if there are any other items that should be added (perhaps some specific checks for the embedding headers), let me know- I'll be happy to add them. --Josh At 18:57 on 09/11/2003 BST, Nich

FW: Embedding interface to PMCs

(Note: I originally meant to send this message to the list, but accidentally hit the wrong "Reply" button. Sorry if this messes up your mailer's threading.) Arthur Bergman: # Is there any documentation, or code I can read to figure out how use # PMCs in embedded mode? I tried to just include parr

Re: Embedding interface to PMCs

pdd7_codingstd, no body had replied), > but maybe Parrot isn't going to have support for C++ embedding applications. It will. perl 5 does. Therefore the current situation is a bug. Nicholas Clark

Re: Embedding interface to PMCs

- Original Message - From: "Arthur Bergman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, September 11, 2003 7:14 PM Subject: Embedding interface to PMCs > Hi, > > Is there any documentation, or code I can read to

Embedding interface to PMCs

Hi, Is there any documentation, or code I can read to figure out how use PMCs in embedded mode? I tried to just include parrot/parrot.h in sv.c but that results in a million (or so ;) errors, so using parrot/embed would be nice. (it looks like it isn't finished yet, so it is more a question of

Re: Embedding Parrot in Perl

Luke Palmer <[EMAIL PROTECTED]> wrote: > > 2) What do I put as stacktop in Parrot_init()? Its gone. stacktop is now set internally before entering the run loop. > Thanks, > Luke leo

Re: Embedding Parrot in Perl

Juergen Boemmels <[EMAIL PROTECTED]> wrote: > Benjamin Goldberg <[EMAIL PROTECTED]> writes: >> If our DoD is no longer walking the C stack, then stacktop should no >> longer be needed. Until the code is changed, just pass NULL. > AFAIK, the stack is still walked. (I don't like this but thats a >

Re: Embedding Parrot in Perl

Benjamin Goldberg <[EMAIL PROTECTED]> writes: > Luke Palmer wrote: > > > > I started working on some XS code for embedding a Parrot interpreter in > > Perl. I ran into a few problems: > > > > 1) I don't know XS :-) (good way to learn, though)

Re: Embedding Parrot in Perl

On Mon, Aug 25, 2003 at 10:44:59AM -0600, Luke Palmer wrote: > I started working on some XS code for embedding a Parrot interpreter in > Perl. I ran into a few problems: > > 1) I don't know XS :-) (good way to learn, though) Have you looked at what Arthur's been up t

Re: Embedding Parrot in Perl

Luke Palmer wrote: > > I started working on some XS code for embedding a Parrot interpreter in > Perl. I ran into a few problems: > > 1) I don't know XS :-) (good way to learn, though) > > 2) What do I put as stacktop in Parrot_init()? I can't just u

Embedding Parrot in Perl

I started working on some XS code for embedding a Parrot interpreter in Perl. I ran into a few problems: 1) I don't know XS :-) (good way to learn, though) 2) What do I put as stacktop in Parrot_init()? I can't just use a local variable in the calling function,

embedding API

i'm beginning to explore the concept of embedding parrot so i can eventually add Perl 6 support to extproc_perl (embeds perl in oracle). i was talking with dan at OSCON a few weeks ago about accessing data from an embedded parrot interpreter, and i know he is probably moving it up in his pri

Re: Embedding Questions

On Thu, 13 Feb 2003 10:36:43 +0100, Alin Iacob wrote: > On February 13, 2003 2:00 chromatic wrote: >>I'm experimenting with embedding Parrot at the moment, and have a few > questions. > Some time ago Brent Dax propossed the following PDD: > http:[EMAIL PROTECTED]/msg1

Re: Embedding Questions

On February 13, 2003 2:00 chromatic wrote: >I'm experimenting with embedding Parrot at the moment, and have a few questions. > >1) How do I get data into Parrot-space? I can pass arguments to >Parrot_runcode() or I could populate some registers directly, but both >approaches

Embedding Questions

I'm experimenting with embedding Parrot at the moment, and have a few questions. 1) How do I get data into Parrot-space? I can pass arguments to Parrot_runcode() or I could populate some registers directly, but both approaches have their drawbacks. I could probably create PMCs directly

Embedding

Is there a supported way of passing parameters to programs running in an embedded interpreter other than through argv? Is interpreter->pmc_reg.registers[1] = ... supported? The interpreter is supposed to be opaque, right? What about a function(macro?) to support setting registers? Maybe somet

RE: [COMMIT] Embedding overhaul

ven on systems with cgoto enabled. Having said that, I think that the default should be to use the fastest non-JIT core, but there should be optional flags to force Parrot to use a specific core. --Brent Dax <[EMAIL PROTECTED]> @roles=map {"Parrot $_"} qw(embedding regexen Configur

RE: [COMMIT] Embedding overhaul

gs that were accidentally made external no # longer are. # ># ># # ># ># This isn't a problem with config.h. config.h should # *never* be used # ># ># by anyone embedding Parrot, either directly or indirectly. # ># > # ># >Why not? Some parts of Parrot'

RE: [COMMIT] Embedding overhaul

At 7:31 PM -0400 5/18/02, Melvin Smith wrote: >At 07:25 PM 5/18/2002 -0400, Dan Sugalski wrote: >>># Flag handling, or at least feature enabling, should probably be done >>># by core code. We should provide a set_feature() function >>> >>>Right now we have something like this: >>> >>> Parr

RE: [COMMIT] Embedding overhaul

At 07:25 PM 5/18/2002 -0400, Dan Sugalski wrote: >># Flag handling, or at least feature enabling, should probably be done >># by core code. We should provide a set_feature() function >> >>Right now we have something like this: >> >> Parrot_setflag(interpreter, PARROT_CGOTO_FLAG, NULL); >>

RE: [COMMIT] Embedding overhaul

no longer are. ># ># ># ># This isn't a problem with config.h. config.h should *never* be used ># ># by anyone embedding Parrot, either directly or indirectly. ># > ># >Why not? Some parts of Parrot's embedding system have to be ># set up by ># >Co

RE: [COMMIT] Embedding overhaul

few structures have been renamed. # ># >-config.h has been rearranged so that INTVAL, etc. are now # ># aliases for # ># >Parrot_Int, etc. # ># >-A few things that were accidentally made external no longer are. # ># # ># This isn't a problem with config.h. config.h should

RE: [COMMIT] Embedding overhaul

renamed. ># >-config.h has been rearranged so that INTVAL, etc. are now ># aliases for ># >Parrot_Int, etc. ># >-A few things that were accidentally made external no longer are. ># ># This isn't a problem with config.h. config.h should *never* be used ># by anyo

RE: [COMMIT] Embedding overhaul

etc. are now # aliases for # >Parrot_Int, etc. # >-A few things that were accidentally made external no longer are. # # This isn't a problem with config.h. config.h should *never* be used # by anyone embedding Parrot, either directly or indirectly. Why not? Some parts of Parrot's emb

Re: [COMMIT] Embedding overhaul

gt;Parrot_Int, etc. >-A few things that were accidentally made external no longer are. This isn't a problem with config.h. config.h should *never* be used by anyone embedding Parrot, either directly or indirectly. >At this point, I have a plea: BRING ME THE HEAD OF THE COMPTUED GOTO >G

[COMMIT] Embedding overhaul

OK, I've neglected to fix a bunch of mistakes in the embedding system for a few months. These have now been fixed. -Parrot becomes Parrot_Interp -Parrot_String is gone and the string_funcs.h functions are no longer externally visible. -A few structures have been renamed. -config.h has

[PDDs] Embedding and external interfaces

The attached PDDs cover embedding and interfaces shared between embedding and extending ("external" interfaces). The embedding PDD mostly covers stuff already in the core; the external interface PDD is my proposed solution. Read and review, please. --Brent Dax <[EMAIL PROTECTED

Re: [COMMIT] Embedding enhancements

TECTED]> >cc: Perl 6 Internals <[EMAIL PROTECTED]> Subject: Re: [COMMIT] Embedding enhancements

Re: [COMMIT] Embedding enhancements

In message <[EMAIL PROTECTED]> Nicholas Clark <[EMAIL PROTECTED]> wrote: > On Sat, Feb 16, 2002 at 01:46:56AM -0800, Brent Dax wrote: > > NEW CONVENTIONS FOR DATA EXPOSED TO EMBEDDERS: > > > > -All structs should have a name of the form parrot_system_t. This name > > should never be d

Re: [COMMIT] Embedding enhancements

On Sat, Feb 16, 2002 at 01:46:56AM -0800, Brent Dax wrote: > NEW CONVENTIONS FOR DATA EXPOSED TO EMBEDDERS: > > -All structs should have a name of the form parrot_system_t. This name > should never be directly used outside the subsystem in question. > > struct parrot_foo_t { > ... > }; A

RE: [COMMIT] Embedding enhancements

ace their particular # ># HLL exposes) # ># # ># Probably a good first step for an extending and embedding # PDD, if we # ># want just a single one, is to define what's visible where, # and what's # ># black magic in other places, just so we can keep this # stuff straight. # >

RE: [COMMIT] Embedding enhancements

># ># Probably a good first step for an extending and embedding PDD, if we ># want just a single one, is to define what's visible where, and what's ># black magic in other places, just so we can keep this stuff straight. > >*Sigh*. Okay, then we'll need a different inter

RE: [COMMIT] Embedding enhancements

y the core and PMC class authors should see the vtables, and only # people actually writing them in C. (PMC classes written in # perl/python/ruby/whatever should see the interface their particular # HLL exposes) # # Probably a good first step for an extending and embedding PDD, if we # want just a

Re: [COMMIT] Embedding enhancements

Only the core and PMC class authors should see the vtables, and only people actually writing them in C. (PMC classes written in perl/python/ruby/whatever should see the interface their particular HLL exposes) Probably a good first step for an extending and embedding PDD, if we want just a sin

[COMMIT] Embedding enhancements

I committed the first wave of embedding enhancements. These changes focus on two things: a) Better exposure of certain internal datatypes with good external names b) Exposure of subsystems embedders will need to talk to The three subsystems I'm exposing are strings, PMCs, and vtables.

Re: RFC 323 (v1) Perl's embedding API should be simple

routines to: * Create an interpreter * Destroy an interpreter * Run a string * Register a callback function in the embedding app. (I was thinking in the HOST package) Getting/setting values and messing with perl variables in general were things I specifically wanted left *out* of the embeddi

RFC 323 (v1) Perl's embedding API should be simple

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Perl's embedding API should be simple =head1 VERSION Maintainer: Simon Cozens <[EMAIL PROTECTED]> Date: 26 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 323 Version: 1 Status: