On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote:
I vaguely recall when Chip put that in. He worked pretty hard to
adjust the command line/#! option processing. (Something about
unsafe operations already being done before the script is read.)
The crux of my proposal/request is
On Fri, Sep 15, 2000 at 01:52:00AM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Extend the window to turn on taint mode
As long as we're talking about tainting (this is a good idea, BTW) how
does everyone feel about a few other tainting widgets...
- A way to know when taint mode is on.
On Thu, 14 Sep 2000 15:47:43 -0700, Steve Fink wrote:
Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
anything else sees it. So any features implemented in the tokenizer have
to get smarter about remembering what they did.
This sound pretty much like the same problem you
On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
That's fine for the VM and the support libraries, but I'd *really*
like to see the parser/front-end in Perl. There are dozens of RFCs
that require some non-trivial extensions to the parser. It would
be nice to code these in
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
(Someone remind me, What is the point of -T if not running setuid?)
JH Being paranoid is never a bad idea because They are always out to get you.
That's fine, but tell me what security breach can be caused by not having
a -T?
The perl code
On Fri, Sep 15, 2000 at 09:19:14AM -0400, Chaim Frenkel wrote:
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
(Someone remind me, What is the point of -T if not running setuid?)
JH Being paranoid is never a bad idea because They are always out to get you.
That's fine, but tell me
"AT" == Adam Turoff [EMAIL PROTECTED] writes:
AT The crux of my proposal/request is that when perl6 innards are
AT designed, -T processing is handled the same way -p and -i are.
AT That is, option processing should start out cleaner than what
AT is in 5.7.0 or what was in 5.004 (at least, wrt
At 10:27 PM 9/14/00 -0400, Chaim Frenkel wrote:
"SF" == Steve Fink [EMAIL PROTECTED] writes:
SF I suspect perl can do a much better job than it does now, but if you
SF make it a requirement, you prevent many optimizations. I think the RFC
SF should be very specific about when it applies and
At 02:40 PM 9/14/00 +0100, Piers Cawley wrote:
Simon Cozens [EMAIL PROTECTED] writes:
On Tue, Sep 12, 2000 at 03:17:47PM -0400, Ken Fox wrote:
That's fine for the VM and the support libraries, but I'd *really*
like to see the parser/front-end in Perl. There are dozens of RFCs
that
At 03:06 PM 9/14/00 +0100, Simon Cozens wrote:
On Thu, Sep 14, 2000 at 02:40:31PM +0100, Piers Cawley wrote:
Are there any better reasons than "It would be nice?"
Can there *be* a better reason than "It would be nice"? Seriously,
niceness is a damned fine goal.
No, it isn't. Practical
At 04:52 AM 9/15/00 -0400, Michael G Schwern wrote:
On Fri, Sep 15, 2000 at 01:52:00AM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Extend the window to turn on taint mode
As long as we're talking about tainting (this is a good idea, BTW) how
does everyone feel about a few other tainting
At 10:07 PM 9/13/00 -0600, Nathan Torkington wrote:
Ken Fox writes:
The dogfood theory? One of the design goals for Perl is to make text
munging easy. Parsing falls into that category and therefore we should
use it, i.e. eat our own dogfood.
How about this. During design, we try to make
At 01:15 AM 9/15/00 -0400, Adam Turoff wrote:
On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote:
I vaguely recall when Chip put that in. He worked pretty hard to
adjust the command line/#! option processing. (Something about
unsafe operations already being done before the script
On Fri, 15 Sep 2000, Dan Sugalski wrote:
Doing core work in perl also has startup issues--either we need to parse
perl code every time perl starts, write the optree stuff to be
position-independent, compile perl down to native code, or embed and
process bytecode every time we start.
I
Bart Lateur wrote:
On Thu, 14 Sep 2000 15:47:43 -0700, Steve Fink wrote:
Currently, toke.c turns "foo$bar" into "foo".$bar before the parser or
anything else sees it. So any features implemented in the tokenizer have
to get smarter about remembering what they did.
This sound pretty
On Fri, Sep 15, 2000 at 01:04:50PM -0400, Dan Sugalski wrote:
At 01:15 AM 9/15/00 -0400, Adam Turoff wrote:
On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote:
I vaguely recall when Chip put that in. He worked pretty hard to
adjust the command line/#! option processing.
On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote:
At 04:52 AM 9/15/00 -0400, Michael G Schwern wrote:
On Fri, Sep 15, 2000 at 01:52:00AM -, Perl6 RFC Librarian wrote:
=head1 TITLE
Extend the window to turn on taint mode
As long as we're talking about tainting (this
At 01:53 PM 9/15/00 -0400, Adam Turoff wrote:
On Fri, Sep 15, 2000 at 01:04:50PM -0400, Dan Sugalski wrote:
At 01:15 AM 9/15/00 -0400, Adam Turoff wrote:
On Thu, Sep 14, 2000 at 10:37:40PM -0400, Chaim Frenkel wrote:
I vaguely recall when Chip put that in. He worked pretty hard to
It seems to me that everyone in this thread pretty much agrees that this
is a good idea, but has one of the following reservations:
1) Tracking sufficient information to be able to report errors at the
exact spot they happen involves bloating the optree a lot and slowing down
the whole program;
On Fri, Sep 15, 2000 at 02:11:55PM -0400, Dan Sugalski wrote:
-c in there between the load-time things
(-M, -T, -U, etc...) and the runtime things (-n, -p)
I'd say -c should be last, if only to keep Abigail happy:
% perl -nce '}print $.; {'
-e syntax OK
simon@deep-dark-truthful-mirror
On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote:
Take a look at the Taint modules on CPAN. Mine does just these, and I think
Tom Phoenix's does a bunch more.
Tom's Taint.pm has never worked for me. I just tried installing it
again and it failed a bunch of tests (in both 5.005
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH It may not be. Think CGI.
JH The code is running under what ever poor security measures the silly
JH subclued webmaster set it up to be, and has access to which ever files
JH yadayadayada.
No command line switches there. Only the #!.
If
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Any time the code being executed isn't being run as the person asking for
DS its execution you can have problems. Think daemons in perl, or
DS client-server code. (Like CGI programs, or mailing-list managers) Jobs run
DS automagically by
At 03:38 PM 9/15/00 -0400, Michael G Schwern wrote:
On Fri, Sep 15, 2000 at 01:03:50PM -0400, Dan Sugalski wrote:
Take a look at the Taint modules on CPAN. Mine does just these, and I
think
Tom Phoenix's does a bunch more.
Tom's Taint.pm has never worked for me. I just tried installing it
At 03:58 PM 9/15/00 -0400, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
DS Any time the code being executed isn't being run as the person asking for
DS its execution you can have problems. Think daemons in perl, or
DS client-server code. (Like CGI programs, or
I don't believe that the optree has to be bloated. I think having the
actual line number in the optree vs. having a seperate structure
mapping offsets to line numbers are the same.
Then an error report would be akin to
error_me_this(current_op_address, "Foo didn't baz in time.
On Fri, Sep 15, 2000 at 05:04:23PM -0400, Chaim Frenkel wrote:
"DS" == Dan Sugalski [EMAIL PROTECTED] writes:
But these all lack command line switches that are passed to perl.
DS No, they don't. Not everywhere, certainly. Command-line switches
DS can be passed to all of 'em. Not everyone
At 05:21 PM 9/15/00 -0400, Chaim Frenkel wrote:
I don't believe that the optree has to be bloated. I think having the
actual line number in the optree vs. having a seperate structure
mapping offsets to line numbers are the same.
Then an error report would be akin to
Steve Fink writes:
I suspect perl can do a much better job than it does now, but if you
make it a requirement, you prevent many optimizations. I think the RFC
should be very specific about when it applies and when it gets out of
the way.
I can't be more specific unless I know the
Dan Sugalski wrote:
1) How fast is the C (or whatever) code it emits likely to be?
The perl-in-perl interpreter would not be a deliverable. Speed would
not be its goal. It would be a reference implementation that would be
easier to break and repair. An internals tutorial, if you will.
So
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Emit warnings and errors based on unoptimized code
=head1 VERSION
Maintainer: Nathan Torkington [EMAIL PROTECTED]
Date: Sep 12 2000
Last Modified: Sep 15 2000
Mailing List: [EMAIL PROTECTED]
31 matches
Mail list logo
