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]
Num
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
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 optimiza
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
> error_me_this(c
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
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. Aborting")
> "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 counts on the magic
DS> shebang line to find the command
Dave Storrs wrote:
>
> As to solving problem #1 (which is, arguably, the bigger problem),
> suppose we add a new switch to perl? I propose we add the -H switch
> (mnemonic: *H*elpful errors/warnings). When -H is set, the optree would
> be generated with a sufficient amount of bloat that
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,
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 instal
> "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> automagical
> "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 t
On Fri, Sep 15, 2000 at 02:00:04PM -0400, Adam Turoff wrote:
> I'm kinda surfing the edge here. -T is definately an internals issue,
> but $TAINT? taint()? is_tainted()?
>
> I'm not sure if they should be exposed into the language from the
> internals, or if a superstudly taint.xs in stdlib i
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 a
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 ~/p
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;
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 t
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 t
On Fri, Sep 15, 2000 at 12:53:29PM -0400, Dan Sugalski wrote:
> The only reason I can see nice winning over fast is if nice brings in whole
> new concepts to the language. (Like, say, matrix ops or Damian's currying stuf)
Well, taking the idea of writing the parser in Perl, let's have a look
at
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.
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
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
At 09:19 AM 9/15/00 -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 what
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
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 t
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
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.
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
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
> "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 le
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
> "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 p
> > 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 cod
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 yo
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.
35 matches
Mail list logo
