Re: Outstanding parrot issues?

On Thu, Apr 29, 2004 at 11:09:28AM -0400, Dan Sugalski wrote:
> Since I've only been mildly keeping track...
> 
> Are there outstanding issues that Ponie has with Parrot and, if so, 
> which ones? (If there are open bug reports for them that's cool, skip 
> those if you want)

I'm not sure if we have any open bug reports. I'll list the issues I can
remember here now, and check them against bug reports at the weekend.

ponie is failing some regression tests, (and skipping others that would
fail) because of signal handling.
Ultimately it would be nice if carrot's signal handling was as transparent
as perl's when embedded, and ultimately pone will be using parrot's runloop
so it will only be using parrot's signal handling, but I'm wondering

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)
2: Long term can parrot interwork nicely with existing signal handlers
   by storing the function pointer returned by signal() when it installs
   its handler, and calling that function when its signal handler is called?



IIRC ponie isn't playing nicely with how parrot does embedding. I'd like
parrot's embedding to be as "clean" as perl's.

IIRC parrot is currently assuming that we give it the address of a local
variable (for the stack top) before doing anything else, which is making
a big assumption about the calling locations of various parrot functions
within the code of the embedding program. 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 (and restores it to NULL on
the way out). I think that this would mean that any externally visible
parrot call could be made without having to set up any stack top, and all
the internal garbage collection would work perfectly.


IIRC there only interface to call into parrot bytecode subs currently
assumes that one sets up the full parrot calling convention (eg putting
values into PMC regs). Will there be a way to call in without needing to
become an extender of parrot? Can the NCI code work for calling into parrot,
as well as calling out?

Also IIRC parrot is still creating globally visible symbols that aren't
well prefixed, so may cause linker fun. But that's not really a ponie
issue.


Sorry if I'm behind the times on parrot, and some of what I remember is
wrong.

Nicholas Clark