Jeff Clites [EMAIL PROTECTED] wrote:
ICU somehow manages (optionally?) to suffix all it its symbols with the
version number, automagically (meaning, they don't look that way in the
source or the headers).
urename.h is responsible for this. All the symbols get a version suffix.
JEff
leo
ICU somehow manages (optionally?) to suffix all it its symbols with
the version number, automagically (meaning, they don't look that way
in the source or the headers). We should figure out how they are doing
that, and see if we can use the same approach. I don't know if it's
linker magic, or
Leopold Toetsch wrote:
Jeff Clites [EMAIL PROTECTED] wrote:
ICU somehow manages (optionally?) to suffix all it its symbols with the
version number, automagically (meaning, they don't look that way in the
source or the headers).
urename.h is responsible for this. All the symbols get a
Arthur Bergman [EMAIL PROTECTED] wrote:
... , then call into
parrot using for example void Parrot_runcode(Parrot_Interp, int argc,
char *argv[]); Now my argument is that currently this does not work
because the stacktop is not set! so what Parrot_runcode should do is in
{
On 3 May 2004, at 13:27, Leopold Toetsch wrote:
because the stacktop is not set! so what Parrot_runcode should do is
in
{
if(!parrot-stacktop) {
set_stacktop
When you call Capp_x_run_plugin from different locations, this
wouldn't work. So the correct sequence is:
app_x_run_plugin(...) {
Arthur Bergman wrote:
On 2 May 2004, at 12:37, Leopold Toetsch wrote:
Can't you call that somewhere in an outer frame? E.g. where you create
the interpreter.
No, because I might be creating the interpreter in a callback from the
application, and then access that interpreter in ANOTHER callback
On 3 May 2004, at 09:11, Leopold Toetsch wrote:
Arthur Bergman wrote:
On 2 May 2004, at 12:37, Leopold Toetsch wrote:
Can't you call that somewhere in an outer frame? E.g. where you
create
the interpreter.
No, because I might be creating the interpreter in a callback from
the application, and
Arthur Bergman [EMAIL PROTECTED] wrote:
... The obvious answer
seems to be to have the embedding interface set the top of stack in
each embedding function if it is not set. This would do the right thing
and make it easy to embed parrot.
No. I've posted already this example:
{
PMC
Arthur Bergman [EMAIL PROTECTED] wrote:
All I want to do is.
1) create a parrot interpreter
2) create some pmcs
3) call some code inside parrot with those pmcs
I've now added a missing init function that sets the stack top:
Parrot_init_stacktop(Interp*, void*);
This function can be used
On 2 May 2004, at 10:54, Leopold Toetsch wrote:
Arthur Bergman [EMAIL PROTECTED] wrote:
... The obvious answer
seems to be to have the embedding interface set the top of stack in
each embedding function if it is not set. This would do the right
thing
and make it easy to embed parrot.
No. I've
On 2 May 2004, at 11:47, Leopold Toetsch wrote:
All I want to do is.
1) create a parrot interpreter
2) create some pmcs
3) call some code inside parrot with those pmcs
I've now added a missing init function that sets the stack top:
Parrot_init_stacktop(Interp*, void*);
This function can be
Arthur Bergman [EMAIL PROTECTED] wrote:
On 2 May 2004, at 11:47, Leopold Toetsch wrote:
Parrot_init_stacktop(Interp*, void*);
This function can be used as a replacement for Parrot_init(). I hope
that simplifies step 1)
No, it entirely misses the point, every time I call into parrot the
On 2 May 2004, at 12:37, Leopold Toetsch wrote:
that simplifies step 1)
No, it entirely misses the point, every time I call into parrot the
place I called parrot_init_stacktop might not, or most likely will not
be in my current stack.
Can't you call that somewhere in an outer frame? E.g. where
On 30 Apr 2004, at 12:54, Leopold Toetsch wrote:
... Would it be possible for parrot to
provide an embedder's interface to all the (exported) functions that
checks whether the stack top pointer is set, and if not (ie NULL) it
pulls the address of a local variable in it
This doesn't work:
{
On 30 Apr 2004, at 19:30, Leopold Toetsch wrote:
Like it or not DOD/GC has different impacts on the embedder. Above
rules
are simple. There is no when the PMC isn't used any more decrement a
refcount and when you do that and that then icnrement a refcount or
some such like in XS. This is really
Arthur Bergman wrote:
I am now going to be impolite.
Meh...
Leo: There are some embedding applications where it's simply not
possible to get the top of the stack. For example, let's say I want to
write a Parrot::Interp module for Perl 5 (on a non-Ponie core):
my $i=new Parrot::Interp;
Arthur Bergman [EMAIL PROTECTED] wrote:
THERE ARE CASES
Arthur, please let's quietly talk about possible issues.
Many libraries that you want to use, demand that you call
The_lib_init(bla). This isn't inappropriate, it's a rule. (dot).
Parrot is GC based. (dot).
This imposes different
Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
Arthur Bergman wrote:
I am now going to be impolite.
Meh...
Leo: There are some embedding applications where it's simply not
possible to get the top of the stack.
Not possible, or some of ... just don't like that ;)
write a Parrot::Interp
On 2 May 2004, at 00:20, Leopold Toetsch wrote:
Arthur Bergman [EMAIL PROTECTED] wrote:
THERE ARE CASES
Arthur, please let's quietly talk about possible issues.
Many libraries that you want to use, demand that you call
The_lib_init(bla). This isn't inappropriate, it's a rule. (dot).
Parrot is GC
Nicholas Clark [EMAIL PROTECTED] wrote:
1: Right now, would it be possible for parrot only to install its signal
handlers when it starts the runloop?
(given that ponie isn't using the runloop)
Currently Parrot installs just one handler (SIGHUP) for testing only.
See src/events.c. So old
On Fri, Apr 30, 2004 at 01:54:58PM +0200, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
1: Right now, would it be possible for parrot only to install its signal
handlers when it starts the runloop?
(given that ponie isn't using the runloop)
Currently Parrot
Nicholas Clark [EMAIL PROTECTED] wrote:
On Fri, Apr 30, 2004 at 01:54:58PM +0200, Leopold Toetsch wrote:
And instead the perl regression tests that use SIGHUP fail.
(There are also tests on SIGUSR1, but not SIGUSR2, it seems)
Argh. I grepped through all perl 5.8.0 tests and didn't find
On Fri, Apr 30, 2004 at 06:25:50PM +0200, Leopold Toetsch wrote:
Well, Parrot does DOD/GC. It'll not start refcounting ... But I really
don't think, that this is an issue. You just need to start your app like
this:
main() {}
void *stack_top;
return real_main(stack_top); // pass
On Fri, Apr 30, 2004 at 06:25:50PM +0200, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
This is true. And yes you need to set a stack top if you're expecting the
stack walking to find things you own. But I'm thinking about the case where
the embedding app registers all
Nicholas Clark [EMAIL PROTECTED] wrote:
On Fri, Apr 30, 2004 at 06:25:50PM +0200, Leopold Toetsch wrote:
register each PMC with CParrot_register_pmc().
But I suspect that there will be embedders of parrot who want to do this -
register only
Nicholas Clark [EMAIL PROTECTED] wrote:
If I understand this correctly, then this is far more restrictive than the
perl5 embedding interface.
This is *one* way to start things up. You can start the app with
Parrot_run_native. You can set the stack top. You can register each PMC
with
26 matches
Mail list logo
