On Fri, 12 Jan 2007, Isaac Freeman wrote:
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 bet
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
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
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
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
> > > bringing the embedding and extending in
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 parrot
> > era. i'd like t
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,
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 necessary
> and adding mi
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
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.
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
Jeff Horwitz <[EMAIL PROTECTED]> wrote:
> dan asked to keep everyone up to date on any issues i've had while
> developing mod_parrot.
Great thanks.
> ... following are the problems i've encountered.
> ---
> i currently get parrot's configuration from config_lib.pasm. however, it
> is not readi
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. *
On Mon, May 03, 2004 at 10:46:28AM -0400, Dan Sugalski wrote:
> Okay, here's the rules for PMCs that live outside parrot, and calling
> into parrot from the outside.
>
> 1) *ALL* PMCs which are created outside parrot must be registered
> (unless they're otherwise anchored)
> 2) No call into parr
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
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 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
> >> top of stack.
> >
> >I don't think that
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 resetting the
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.
Otherwise this scen
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 *
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
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
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 clean/unite)
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 Interp* / struct Parrot_Inte
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. Embedding and ex
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 different APIs. The former
has acc
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 needed op
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 type,
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, Nicholas Clark <[E
On Thu, Sep 11, 2003 at 09:30:29PM +0300, Vladimir Lipskiy wrote:
> to document the idea of Juergen Bommels to include the
>
> extern "C" {
>
I take it you meant the full game:
#ifdef __cplusplus
extern "C" {
#endif
> specification () in each header in pdd7_codingstd, no body had replied),
>
- 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 figure out how use
> PMCs in embedded m
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
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
>
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)
> >
> > 2) What do I put as stacktop in P
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 to with ponie?
You can
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 use a
>local variable in
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]/msg11922.html
Thanks, that answe
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 have their drawbacks.
38 matches
Mail list logo
