On Mon, 31 Jul 2000, Nathan Wiger wrote:
> Instead, it would be really cool if Perl6 let you do this:
>
>#! perl -T
>local($^T) = 0;
>$ENV{PATH} = read_config_file();
>local($^T) = 1;
I would prefer something like:
#! perl -T
$ENV{PATH} = untaint( read_config_file() );
OK, this is the last I'll say on it before laying *myself* to rest.
:-)
Simon Cozens <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 01, 2000 at 02:31:15AM -0400, Sam Tregar wrote:
> > Note that we don't have to take that "chance," but I don't think we should
> > turn it down lightly. I suppose a reaso
On Tue, Aug 01, 2000 at 02:31:15AM -0400, Sam Tregar wrote:
> Note that we don't have to take that "chance," but I don't think we should
> turn it down lightly. I suppose a reasonable question is: can we achieve
> our goals without a rewrite? Can we succeed in integrating threading and
> Unicode
> > Umm, well, not necessarily. Not if what I'm doing becomes what we're
> > doing.
>
> Do tell! What have you been doing?
Well, I don't want everybody looking at it in its current (TEMPORARY!)
shambles, but I posted download instructions to this list in a reply
to Simon.
> I'm not here to t
On Tue, 1 Aug 2000, John Tobey wrote:
> Umm, well, not necessarily. Not if what I'm doing becomes what we're
> doing.
Do tell! What have you been doing?
> See http://joel.editthispage.com/stories/storyReader$47 on the
> evils of total rewrites.
This article has been haunting me. My boss lo
Sam Tregar <[EMAIL PROTECTED]> wrote:
> We need to start with the basics and we need to keep things simple and
> understandable. I get the sense that the perl dev community has more than
> its share of efficiency experts. That's a good thing but there's a proper
> time to optimize and this is no
Simon Cozens <[EMAIL PROTECTED]> wrote:
> Counter-counterproposition: Look at the way Sapphire does it. I'm really
> proud of that. It's automagically switchable from inlines to ordinary
> functions to macros. You can choose which wins, and it's neat to debug.
Hear, hear! This is exactly what I
On Tue, 1 Aug 2000, Simon Cozens wrote:
> Counter-counterproposition: Look at the way Sapphire does it. I'm really
> proud of that. It's automagically switchable from inlines to ordinary
> functions to macros. You can choose which wins, and it's neat to debug.
Counter-counter-... Sure I'll take
Dan Sugalski wrote:
>
> > existence of a $^T variable for controlling tainting in the same way
> > that $^W controls warnings.
>
> So put in an RFC. :)
Dan-
Ask and ye shall receive...in POD format ala Tim...
BTW, I've posted this to both lists because your reply was. However,
since $^T would
On Tue, Aug 01, 2000 at 01:00:15AM -0400, Sam Tregar wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > I propose that all internal and external functions be implemented in
> > header files and declared inline. The external runtime API will be
> > generated by compiling non-inline wrappers.
>
Sam Tregar <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Aug 2000, John Tobey wrote:
>
> > I propose that all internal and external functions be implemented in
> > header files and declared inline. The external runtime API will be
> > generated by compiling non-inline wrappers.
> >
> > This will make
On Tue, 1 Aug 2000, John Tobey wrote:
> I propose that all internal and external functions be implemented in
> header files and declared inline. The external runtime API will be
> generated by compiling non-inline wrappers.
>
> This will make possible an interesting performance optimization wit
I propose that all internal and external functions be implemented in
header files and declared inline. The external runtime API will be
generated by compiling non-inline wrappers.
This will make possible an interesting performance optimization with
GNU CC, whereby op_ppaddr is replaced by a loca
13 matches
Mail list logo
