Parrot and STDOUT/STDERR
Arthur Bergman
In my efforts to embed parrot into perl I stumbled upon something
mildly interesting but most likely terribly hard to track down problem.
If I execute a miniperl (but linked into parrot and with it's own
parrot interpreter) it works, but if the caller closes(STDERR) before
invoking miniperl no output is ever seen on STDOUT.
This is terribly annoying since ExtUtils::MakeMaker does silly things
like this, could there be some code in parrot that becomes really
unhappy if STDERR is not open?
Arthur
Leopold Toetsch
Hi Arthur,
> Hi,
> If I execute a miniperl (but linked into parrot and with it's own
> parrot interpreter) it works, but if the caller closes(STDERR) before
> invoking miniperl no output is ever seen on STDOUT.
Parrot's IO system is currently reworked heavily and its not finished
yet. I'm sure Juergen Boemmels comes up with a solution for this.
> This is terribly annoying since ExtUtils::MakeMaker does silly things
> like this, could there be some code in parrot that becomes really
> unhappy if STDERR is not open?
From a quick look at it I would think:
io/io_unix.c:PIO_unix_init returns -1:
io = PIO_unix_fdopen(interpreter, layer, STDERR_FILENO, PIO_F_WRITE);
if (!io) return -1;
which calls internal_exception in io/PIO_init()
if (!PIO_STDIN(interpreter) || !PIO_STDOUT(interpreter)
|| !PIO_STDERR(interpreter)) {
internal_exception(PIO_ERROR, "PIO init std handles failed.");
}
which is the end of the interpreter, but never seen, because the message
goes to STDERR.
> Arthur
leo
Juergen Boemmels
> Arthur Bergman <s...@nanisky.com> wrote:
>
> Hi Arthur,
>
> > Hi,
>
> > If I execute a miniperl (but linked into parrot and with it's own
> > parrot interpreter) it works, but if the caller closes(STDERR) before
> > invoking miniperl no output is ever seen on STDOUT.
>
> Parrot's IO system is currently reworked heavily and its not finished
> yet. I'm sure Juergen Boemmels comes up with a solution for this.
One problem is that the parrot interpreter closes the filehandles when
it is finished with it. This is wrong for the standard handles. They
come from an external source and should not be closed on interpreter exit,
just flushed. I think thats nothing special of the standard handles
but this should be the default behaviour of all fdopened files.
> > This is terribly annoying since ExtUtils::MakeMaker does silly things
> > like this, could there be some code in parrot that becomes really
> > unhappy if STDERR is not open?
No STDERR should not let the init fail, but might set the handle to
PerlUndef. This is possible since the standard handles are PMCs
now. In this case the write to the closed handle will fail, but not
the just the fact that STDERR is closed.
Another possibility would be to redirect STDERR to something like
/dev/null, maybe via an PIO_null_layer. This way a write to the closed
STDERR will be just ignored.
> >From a quick look at it I would think:
>
> io/io_unix.c:PIO_unix_init returns -1:
>
> io = PIO_unix_fdopen(interpreter, layer, STDERR_FILENO, PIO_F_WRITE);
> if (!io) return -1;
The init function should not fail on a closed handle.
> which calls internal_exception in io/PIO_init()
>
> if (!PIO_STDIN(interpreter) || !PIO_STDOUT(interpreter)
> || !PIO_STDERR(interpreter)) {
> internal_exception(PIO_ERROR, "PIO init std handles failed.");
> }
>
> which is the end of the interpreter, but never seen, because the message
> goes to STDERR.
There is no clean way to get this message ever. If there is no STDERR
then even fprintf will fail.
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Nicholas Clark
> No STDERR should not let the init fail, but might set the handle to
> PerlUndef. This is possible since the standard handles are PMCs
^^^^
We keep using that 4 letter word.
How much s/Perl/Parrot/ig do we need before the entire core system is
not using anything named "Perl"?
[and hence in the future the Perl 6 implementation can mess with the Perl
PMCs to its hearts content without affect the semantics of existing language
implementations]
Nicholas Clark
Leopold Toetsch
> On Fri, Aug 15, 2003 at 04:22:36PM +0200, Juergen Boemmels wrote:
>> No STDERR should not let the init fail, but might set the handle to
>> PerlUndef. This is possible since the standard handles are PMCs
> ^^^^
> We keep using that 4 letter word.
> How much s/Perl/Parrot/ig do we need before the entire core system is
> not using anything named "Perl"?
$ perl classes/pmc2c.pl --tree classes/perl*.pmc
PerlArray
Array
PerlHash
PerlInt
perlscalar
scalar
PerlNum
perlscalar
scalar
perlscalar
scalar
PerlString
perlscalar
scalar
PerlUndef
PerlInt
perlscalar
scalar
The Perl* classes do implement the perlish way (like autoextending
array, or morphing to a different Perl scalar. These are basically our
only current working scalars (the lower case named base classes are
abstract classes)
When we have more classes like a Python hierarchy, we will see, how and
how far the functionality does match. If we find some, we can put in an
intermediate ParrotScalar.
But when it comes to PerlUndef (like above) you are right. Its used in
Array too for example.
> Nicholas Clark
leo
Michal Wallace
> When we have more classes like a Python hierarchy, we will see, how and
> how far the functionality does match. If we find some, we can put in an
> intermediate ParrotScalar.
I was thinking about this earlier today. Once dynamic
PMCs are working, Perl* probably ought to be loaded
dynamically, especially if perls 5 and 6 wind up
needing different implementations.
As far as python goes... I've done some reading on C
and I think I feel confident enough to try tackling
a pyobject <-> pmc two-way bridge (just a generic
wrapper for the two vtables). I figure it would be
nice if we could just wrap the generic pyobject
interface, and then hopefully all the existing
python modules will just work. :)
Aside from that, I was going to follow Dan's lead.
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------