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
Mailing List: [EMAIL PROTECTED]
Number: 214
Version: 1
Statu
Bennett Todd wrote:
>
> I think the complaint about mod_perl's weight bears looking at,
> despite the success of the INN embedding. One invocation of INN is
> likely to do a sufficiently heroic amount of work that the weight
> and bulk of a perl in there may well not hurt a bit.
>
> A single htt
On Mon, Sep 11, 2000 at 05:02:13PM -0400, Dan Sugalski wrote:
> If you're essentially adding stack primitives to C, sure. If you're talking
> about a whole new language it's still an issue.
OK, I think I've got my brains in order now. I *think*. This is probably still
going to be a little fuzzy.
Ken Fox <[EMAIL PROTECTED]> writes:
>Dan Sugalski wrote:
>> For something like:
>>
>>@foo = @bar || @baz;
>>
>> I have no problem with the call sequence looking like (pseudo-codish here):
>>
>> set_context(ARRAY, ASSIGN);
>> foo->store(bar->log_or(bar, baz));
>
>But log_or must shor
2000-09-13-03:29:16 Hildo Biersma:
> Some would argue that a better design is required. Apache 2.0 will
> use a mixed thread/process model, and mod_perl 2.0 will run
> selected threads within one process, precisely to alleviate these
> problems. So it's not necessarily perl's fault...
Some would
> print "what's that, $perl?";
>
> Use of uninitialized value in concatenation (.) at -e line 1.
> This is misleading and confuses users. When Perl needs to report
> errors or warnings, it should describe the code the programmer wrote,
> regardless of how that's been translated within Perl.
> > Tom Christiansen wrote:
> > > It [miniperl] isn't substantially smaller, so that does you no good.
> The socket library seems to be the poster child for what to leave
> out, but that's a weak argument
... it would make sense to design a
> miniperl that can dynamically load the "expensiv
I really screwed this up, who has editable rights for the pages.
( .htaccess ?? )
On Tue, 12 Sep 2000 20:35:32 -0400, Bennett Todd <[EMAIL PROTECTED]> wrote :
> I don't even want to embed the current perl in mutt; I'd love to
> have a scripting and extension language embedded in there, but not
> one that's bigger than all the rest of the application.
A couple years ago I wr
2000-09-13-13:56:07 John van V:
> 2000-09-12-20:35:32 Bennett Todd:
> > The exact same design targets --- really really fast, teensy
> > memory footprint --- that define the microcontroller embedded
> > market, also define the entry to these roles on the biggest
> > servers.
>
> I'm not sure what
On Wed, Sep 13, 2000 at 07:24:26AM -0700, Nathan Wiger wrote:
> > print "what's that, $perl?";
> >
> > Use of uninitialized value in concatenation (.) at -e line 1.
>
> > This is misleading and confuses users. When Perl needs to report
> > errors or warnings, it should describe the code the
Simon Cozens writes:
> > Nice!
> Efficient!
> Practical!
>
> Choose two.
I take this oblique comment to mean that it'd bloat the op-tree too
much?
I was thinking of this over lunch. I want to be able to strip the
instruction sequence of line number, package, etc. information, in the
name of a
On Wed, 13 Sep 2000, Nathan Torkington wrote:
> Simon Cozens writes:
> > > Nice!
> > Efficient!
> > Practical!
> >
> > Choose two.
>
> I take this oblique comment to mean that it'd bloat the op-tree too
> much?
>
> I was thinking of this over lunch. I want to be able to strip the
> instructio
Nick Ing-Simmons wrote:
> Ken Fox <[EMAIL PROTECTED]> writes:
> >Dan Sugalski wrote:
> >> For something like:
> >>
> >>@foo = @bar || @baz;
> >>
> >> I have no problem with the call sequence looking like (pseudo-codish here):
> >>
> >> set_context(ARRAY, ASSIGN);
> >> foo->store(bar->l
Dan Sugalski writes:
> I wouldn't worry about this too much. If it's all keyed off an opcode of
> some sort ("Current line info"), we could easily just strip those opcodes
> out. They won't take up that much space relative to the rest of the
> program, but I can see some sort of runtime overhead i
Simon Cozens wrote:
> 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
At 07:09 AM 9/13/00 +, Perl6 RFC Librarian wrote:
>=head1 TITLE
>
>Emit warnings and errors based on unoptimized code
Yay! I'd add, in V2, that:
"Perl should report the *real* line an error took place in for those
statements that span multiple lines"
So if you do:
#! perl -w
my $foo
At 09:50 PM 9/12/00 +0100, Simon Cozens wrote:
>On Tue, Sep 12, 2000 at 04:55:02PM -0400, Dan Sugalski wrote:
> > > Are there any better reasons than "It would be nice?"
> > It'd make things easier? (I'd rather write a parser in perl than C...)
>
>You're going to have to do it some time, for boots
At 03:02 PM 9/12/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > For something like:
> >
> >@foo = @bar || @baz;
> >
> > I have no problem with the call sequence looking like (pseudo-codish here):
> >
> > set_context(ARRAY, ASSIGN);
> > foo->store(bar->log_or(bar, baz));
>
>But log_o
At 03:49 PM 9/13/00 +, John van V wrote:
>I'm really entranced by the prospect of sending frozen structures
>including anonymous subs to to remote devices like out on Mars or Pittsburgh.
With full lexical scope along with it? You're not alone... :)
Da
At 10:07 AM 9/13/00 -0400, Bennett Todd wrote:
>2000-09-13-03:29:16 Hildo Biersma:
> > Some would argue that a better design is required. Apache 2.0 will
> > use a mixed thread/process model, and mod_perl 2.0 will run
> > selected threads within one process, precisely to alleviate these
> > proble
Dan Sugalski writes:
> It's possible, for example, for a tied/overloaded/really-darned-strange
> variable to look true but still be false. If you do:
>
>$foo = $bar || $baz;
>
> and both $bar and $baz are objects, the 'naive' way is to make $foo be
> $bar. But it's distinctly possible that
At 02:20 PM 9/13/00 -0600, Nathan Torkington wrote:
>Dan Sugalski writes:
> > I wouldn't worry about this too much. If it's all keyed off an opcode of
> > some sort ("Current line info"), we could easily just strip those opcodes
> > out. They won't take up that much space relative to the rest of t
At 03:56 PM 9/13/00 -0400, Ken Fox wrote:
>Nick Ing-Simmons wrote:
> > Ken Fox <[EMAIL PROTECTED]> writes:
> > >Dan Sugalski wrote:
> > >> For something like:
> > >>
> > >>@foo = @bar || @baz;
> > >>
> > >> I have no problem with the call sequence looking like (pseudo-codish
> here):
> > >>
>
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Transaction-enabled variables for Perl6
=head1 VERSION
Maintainer: Szabó, Balázs <[EMAIL PROTECTED]>
Date: 17 Aug 2000
Last Modified: 13 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 130
Vers
Dan Sugalski writes:
> No, that's the point. But if someone explicitly strips out the debugging
> info then, well, you don't get much help in debugging, now do you? :)
I buy that. It'd be nice to be able to be one step better than C,
though, and given *something* that you can use to go back to
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> I take this oblique comment to mean that it'd bloat the op-tree too
NT> much?
NT> I was thinking of this over lunch. I want to be able to strip the
NT> instruction sequence of line number, package, etc. information, in the
NT> name
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 the parser a module
with an interface designed so that
28 matches
Mail list logo
