[31985] in Perl-Users-Digest
Perl-Users Digest, Issue: 3249 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Dec 30 16:09:23 2010
Date: Thu, 30 Dec 2010 13:09:06 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 30 Dec 2010 Volume: 11 Number: 3249
Today's topics:
how do you make perl to c++ translater <r@thevoid1.net>
Re: how do you make perl to c++ translater <uri@StemSystems.com>
Re: how do you make perl to c++ translater <tadmc@seesig.invalid>
Re: how do you make perl to c++ translater <cartercc@gmail.com>
Re: how do you make perl to c++ translater <hjp-usenet2@hjp.at>
Re: Posting Guidelines for comp.lang.perl.misc ($Revisi <ralph@happydays.com>
Re: signal handler is not called while piped open is ac <derykus@gmail.com>
Re: signal handler is not called while piped open is ac <eponymousalias@yahoo.com>
Re: signal handler is not called while piped open is ac <derykus@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 30 Dec 2010 03:13:33 -0800 (PST)
From: Robin <r@thevoid1.net>
Subject: how do you make perl to c++ translater
Message-Id: <8ce19f45-3c48-4c52-a63b-f37963c9b52a@o14g2000yqe.googlegroups.com>
Does anyone have any hints as to how this would be done?
roll,
-r
------------------------------
Date: Thu, 30 Dec 2010 06:26:28 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: how do you make perl to c++ translater
Message-Id: <87pqsjo61n.fsf@quad.sysarch.com>
>>>>> "R" == Robin <r@thevoid1.net> writes:
R> Does anyone have any hints as to how this would be done?
yes. you write it.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Thu, 30 Dec 2010 10:05:09 -0600
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: how do you make perl to c++ translater
Message-Id: <slrnihpc46.10u.tadmc@tadbox.sbcglobal.net>
Robin <r@thevoid1.net> wrote:
> Does anyone have any hints as to how this would be done?
It is very simple and takes only 3 steps:
1) Learn Perl
2) Learn C++
3) translate between them
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
------------------------------
Date: Thu, 30 Dec 2010 12:07:32 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: how do you make perl to c++ translater
Message-Id: <1c8938e3-ceb6-4c34-9657-ae7eff4332a6@j25g2000yqa.googlegroups.com>
On Dec 30, 6:13=A0am, Robin <r...@thevoid1.net> wrote:
> Does anyone have any hints as to how this would be done?
Why would you want to do that? Why not just write your program in C++
to begin with?
I think an even better question would be, 'Why not have Perl compiled
to intermediate byte code?' or, 'Why not have Perl compiled to native
instruction sets?'
Actually, I'm waiting for someone to attempt to implement Perl to run
on both the JVM and the .NET platforms. Think about it ... Perl
running as Java byte code and/or as MSIL byte code! In these times,
much, much better than compiled as C++ source.
CC.
------------------------------
Date: Thu, 30 Dec 2010 21:51:25 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: how do you make perl to c++ translater
Message-Id: <slrnihps6e.a3b.hjp-usenet2@hrunkner.hjp.at>
On 2010-12-30 20:07, ccc31807 <cartercc@gmail.com> wrote:
> On Dec 30, 6:13 am, Robin <r...@thevoid1.net> wrote:
>> Does anyone have any hints as to how this would be done?
>
> Why would you want to do that? Why not just write your program in C++
> to begin with?
>
> I think an even better question would be, 'Why not have Perl compiled
> to intermediate byte code?'
Perl *is* compiled to intermediate byte code. There just isn't any
useful way to dump and reuse that code.
> or, 'Why not have Perl compiled to native instruction sets?'
Once upon a time the answer was "because it's hard to do properly and
perl runs on many hardware platforms and you'd have to write a compiler
for each of them". Nowadays x86 and x86_64 are probably the only
important hardware platforms for perl, so what remains is "because it's
hard to do properly."
> Actually, I'm waiting for someone to attempt to implement Perl to run
> on both the JVM
People have talked about that ever since the Java hype began in 96.
AFAIK nobody even seriously attempted it. So I wouldn't hold my breath.
> and the .NET platforms. Think about it ... Perl
> running as Java byte code and/or as MSIL byte code! In these times,
> much, much better than compiled as C++ source.
I'm not sure Perl fits well into these frameworks, so you would probably
have to write some wrapper code around your Perl modules. In the other
direction: You can already call Java from Perl, probably .NET, too.
Instant access to any improvements in interpreter technology (especially
JIT) might be an advantage, tough.
hp
------------------------------
Date: Wed, 29 Dec 2010 11:39:27 -0500
From: Ralph Malph <ralph@happydays.com>
Subject: Re: Posting Guidelines for comp.lang.perl.misc ($Revision: 1.9 $)
Message-Id: <14a81$4d1b6449$ce534406$22282@news.eurofeeds.com>
so long and yet so useless.
Still, not a candidate for the broken urinal award since
piss erupting everywhere in a men's room at least has a reason to be
there.
------------------------------
Date: Wed, 29 Dec 2010 02:09:11 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: signal handler is not called while piped open is active
Message-Id: <4ed988fd-5e7d-4cfc-84b7-c83bede948fa@u25g2000pra.googlegroups.com>
On Dec 28, 5:48=A0pm, Glenn <eponymousal...@yahoo.com> wrote:
> Given the following simple script:
>
> #!/usr/bin/perl -w --
>
> my $terminate =3D 0;
> my $failed =A0 =A0=3D 0;
>
> sub print_signal {
> =A0 =A0 my $signame =3D shift;
> =A0 =A0 $terminate =3D 1;
> =A0 =A0 die "got a SIG$signame signal\n";
>
> }
>
> $SIG{INT} =A0=3D \&print_signal;
> $SIG{QUIT} =3D \&print_signal;
> $SIG{TERM} =3D \&print_signal;
>
> open PIPE, '|-', "sleep 30";
> print PIPE "nighty night\n";
> $failed |=3D ! close PIPE;
> print "OS error: =A0$!\n";
> print "Child error: =A0$?\n";
> if (!$terminate) {
> =A0 =A0 print "sleeping after PIPE handling ...\n";
> =A0 =A0 sleep 30;}
>
> print "terminated by signal\n" if $terminate;
> print "failed: =A0$failed\n";
>
> Why is the signal hander not called if I interrupt the script with
> SIGINT or SIGQUIT while the PIPE is open? =A0I don't see this behavior
> documented anywhere. =A0I expect the %SIG settings to be obeyed as
> documented, both during and after the PIPE processing.
>
> Here's the complete behavior, in detail, when the signal is sent while
> the PIPE i/o is underway. =A0In each case, I run the script in a shell,
> in the foreground.
>
> SIGINT from keyboard =3D> kills PIPE i/o but does not call signal
> handler
> SIGQUIT from keyboard =3D> kills PIPE i/o but does not call signal
> handler
> SIGINT from another terminal =3D> has no effect whatsoever
> SIGQUIT from another terminal =3D> has no effect whatsoever
> SIGTERM from another terminal =3D> signal handler is called
>
> Why is there any difference at all depending on where the signal comes
> from, and on what signal is sent?
>
> How do we get these blatant failures documented in the Perl manual?
>
> Note that the signal handlers are clearly still in play after the PIPE
> i/o is killed, because a signal sent from any source during the
> script's own later sleep() call (either SIGINT, SIGQUIT, or SIGTERM)
> does kill the script.
Yes, I see evidence of the INT handler if,
for instance, I add:
END { sleep 5; } # --> got a SIGINT signal
I'm not sure why only the signal handler output is
seen only in the parent process however.
>
> Under this circumstance, how do I get a reliable indication that a
> signal was sent (and not just that the PIPE handling failed for quite
> possibly some other reason)?
>
> I'm using Perl 5.8.8 for my testing.
That should reliably be returned by your
check of $! and $? after close().
On 5.10.1 and FreeBSD, your child $? check was:
Child error: 2
which is waitpid output indicating that child
termination was due to a SIGINT.
(${^CHILD_ERROR_NATIVE} is also 2.)
See perldoc -f waitpid and perldoc -f wait.
You can inspect the child status to see if there
was signal termination:
$signal_termination =3D $? & 127
See perldoc -f system
--
Charles DeRykus
------------------------------
Date: Wed, 29 Dec 2010 09:37:26 -0800 (PST)
From: Glenn <eponymousalias@yahoo.com>
Subject: Re: signal handler is not called while piped open is active
Message-Id: <f4280b50-71dd-4012-bba0-e044d8747bfa@j25g2000yqa.googlegroups.com>
> Yes, I see evidence of the INT handler if,
> for instance, I add:
>
> =A0 =A0 END { sleep 5; } =A0# --> got a SIGINT signal
>
> I'm not sure why only the signal handler output is
> seen only in the parent process however.
The child process is running /bin/sleep, not Perl.
> > Under this circumstance, how do I get a reliable indication that a
> > signal was sent (and not just that the PIPE handling failed for quite
> > possibly some other reason)?
>
> > I'm using Perl 5.8.8 for my testing.
>
> That should reliably be returned by your
> check of $! and $? after close().
>
> On 5.10.1 and FreeBSD, your child $? check was:
>
> =A0 =A0Child error: 2
>
> which is waitpid output indicating that child
> termination =A0was due to a SIGINT.
> (${^CHILD_ERROR_NATIVE} is also 2.)
> See perldoc -f waitpid and perldoc -f wait.
>
> You can inspect the child status to see if there
> was signal termination:
>
> =A0 =A0$signal_termination =3D $? & 127
> See perldoc -f system
I was afraid the test code would elicit that kind of response. The
point is, I'm not really interested in the child status -- that's just
a red herring, something I'm reporting in this test program only
because it's something I can probe. What I care about is whether or
not the parent process received a signal. In this testing, the child
happens to receive the same signal if I generate it from the keyboard,
simply because (I'm guessing) it's sent to the entire process tree (by
the shell). But if I send the signal from a different terminal,
targeted specifically at the parent process, then the child process
won't be receiving it, and thus its exit status is irrelevant.
------------------------------
Date: Wed, 29 Dec 2010 11:55:02 -0800 (PST)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: signal handler is not called while piped open is active
Message-Id: <69ad8f99-0124-4ef3-acb6-6185cbd12641@d1g2000pra.googlegroups.com>
On Dec 29, 9:37=A0am, Glenn <eponymousal...@yahoo.com> wrote:
> > Yes, I see evidence of the INT handler if,
> > for instance, I add:
>
> > =A0 =A0 END { sleep 5; } =A0# --> got a SIGINT signal
>
> > I'm not sure why only the signal handler output is
> > seen only in the parent process however.
>
> The child process is running /bin/sleep, not Perl.
>
Oh d'oh... exec happens immediately.
>
> > > Under this circumstance, how do I get a reliable indication that a
> > > signal was sent (and not just that the PIPE handling failed for quite
> > > possibly some other reason)?
>
> > > I'm using Perl 5.8.8 for my testing.
>
> > That should reliably be returned by your
> > check of $! and $? after close().
>
> > On 5.10.1 and FreeBSD, your child $? check was:
>
> > =A0 =A0Child error: 2
>
> > which is waitpid output indicating that child
> > termination =A0was due to a SIGINT.
> > (${^CHILD_ERROR_NATIVE} is also 2.)
> > See perldoc -f waitpid and perldoc -f wait.
>
> > You can inspect the child status to see if there
> > was signal termination:
>
> > =A0 =A0$signal_termination =3D $? & 127
> > See perldoc -f system
>
> I was afraid the test code would elicit that kind of response. =A0The
> point is, I'm not really interested in the child status -- that's just
> a red herring, something I'm reporting in this test program only
> because it's something I can probe. =A0What I care about is whether or
> not the parent process received a signal. =A0In this testing, the child
> happens to receive the same signal if I generate it from the keyboard,
> simply because (I'm guessing) it's sent to the entire process tree (by
> the shell). =A0But if I send the signal from a different terminal,
> targeted specifically at the parent process, then the child process
> won't be receiving it, and thus its exit status is irrelevant.
Hm, the program does ignore signals
(except KILL and STOP of course) sent to
just the parent from another terminal.
However, and I'm not sure why, if I signal
the process group - not just the parent,
it works:
kill -2 -11730 # from another terminal
The result in the running program:
parent=3D11730; # added debug print
got a SIGINT signal
--
Charles DeRykus
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 3249
***************************************
