[PHP-DEV] Who coded upload flaw?

Curious how this upload flaw got through. One would think this code, of all the bits of code out there would have been most carefully screened as uploading files is a natural trouble spot. I know historically there were a number of security questions with it, and now this. - AZ -- PHP Dev

RE: [PHP-DEV] Apache2 and PHP CVS from today

de so that in a few months would have the option of rolling out statically when it mattered. Thought Apache beta might be a good point to start doing that. - August -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 26, 2002 9:23 AM To: August; [

RE: [PHP-DEV] Simple Apache 1.3 vs 2.0 benchmarks

- AZ -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]] Sent: Monday, February 25, 2002 10:05 PM To: August Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Simple Apache 1.3 vs 2.0 benchmarks Uh, but did you benchmark straight cgi's between the two servers? How about straigh

Re: [PHP-DEV] Apache2 and PHP CVS from today

hat for production stuff, going static may be worth the extra compile time. - August -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Apache2 and PHP CVS from today

Hey Yasuo, Could you give a complete url to the DSO recommendation? Most instructions on creating a high performance version of php recommend static compiles. Thanks... - AZ -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] August wrote: > Sebastian wrote: >>

[PHP-DEV] Simple Apache 1.3 vs 2.0 benchmarks

#include as usual, all normal benchmark disclaimers. This is -dev, so let's assume folks have a grasp of the gap between performance benchmarking and the real world. Before flaming please give credit to folks who are able to use this information in a larger and broader context, while recognizing

Re: [PHP-DEV] Apache2 and PHP CVS from today

here? I find DSO useful for testing and development, but for deployment it makes little sense to be using DSO, the cost of 60 seconds of compile is negligible when looking at something that will be installed for timeframes exceeding a day or two, especially for larger server farms. - August

Re: [PHP-DEV] Apache2 and PHP CVS from today

compile time for some potential real world savings. Love to see some better numbers on this of course, but in my experience going the static route results in a measurable performance win. As far as I know httpd2 still allows static modules. - August -- PHP Development Mailing List <http://www.

[PHP-DEV] 4.2 TODO nomination

see PHP running on this. - August -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Apache2 and PHP CVS from today

procedure changed for statically compiling php with apache? I haven't seen any documentation of it. - August -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Apache2 and PHP CVS from today

ut the php support. Now that the beta is here would be great to see php getting solid on Apache. - August -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Moving extensions to PECL

In conjunction with this, increasing the findability of the PECL might be a good idea. At the least an explict search at php.net either in "documentation" or "whole site" should result in at least one hit other than a changelog entry. - AZ - Original Message - From: "Jon Parise" <[EMAI

[PHP-DEV] Re: MOPS Benchmark

- AZ - Original Message - From: "Sebastian Bergmann" <[EMAIL PROTECTED]> Newsgroups: php.dev To: <[EMAIL PROTECTED]> Sent: Monday, December 31, 2001 11:04 AM Subject: Re: [PHP-DEV] Re: MOPS Benchmark > August Zajonc wrote: > > My results are very cl

[PHP-DEV] Re: MOPS Benchmark

/s:2.89 php 4.1.0 (and 4.0.6) Elapsed time: 215 M op/s:0.93 python 1.5.2 Elapsed time: 92 M op/s:2.15 python -OO 1.5.2 Elapsed time: 81 M op/s:2.45 Would be interesting to profile these and see where the time goes. - August -- PHP Development Mailing List

[PHP-DEV] Re: Engine 2 mailing list archive

That was me :) Fantastic, especially the fact that someone had a copy of the old messages. Might consider reflecting the archive either through the newsgroup interface or marc.theaimsgroup.com... Thanks a lot, been hoping for this for a while. - August - Original Message - From: "

Re: [PHP-DEV] Re: Shootout

efully this will avoid the Omega-13 :) - August - Original Message - From: "Zeev Suraski" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "August Zajonc" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Saturday, December 29, 2001 3:51 PM Subject: RE

Re: [PHP-DEV] Re: Shootout

k carefully and he's got disclaimers everywhere, plus this is -dev, where one would imagine folks have a better grasp on the gap between performance benchmarking and the real world, much less language qualities as a whole... I've learned my lesson, this can suck up a good number of ho

Re: [PHP-DEV] Re: Shootout

o has to make budget decisions, and we compared the win from the optimizer with that of the cache for OUR applications and made a decision. Does that mean I and others are not worth are salt as programmers? Hardly, that is rediculously narrow sighted. - August -- PHP Development Mailing List &

Re: [PHP-DEV] Re: Shootout

eir favorite language, even if the benchmark is pretty clear about testing something pretty narrow which I think these are, they are remarkably honest for a benchmark. - August -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Shootout

s anything else I have seen put out. The open source community loves to critize, but I see few of these theoretical "real world" benchmarks floating around. I'm frankly surprised at some of the strong reactions to these benchmarks... think I'm going to get back to work :) -

Re: Re[2]: [2]: [PHP-DEV] Re: Shootout

Mmmm :) I suggest you check out php-gtk. People are writing mail clients in PHP (and they are actually *suprisingly* good). The strengths of PHP (and time spent learning it) in one area carry over to others. We'll have to be wondering about misuse when a CS student writes an operating system in

Re: [PHP-DEV] Re: Shootout

ot;code it in C if you care about performance" is a bogus argument, those of us coding real world apps have to occasionaly meet deadlines. Given that, it is nicer to see PHP perform better. Hopefully at the end of this dicussion that may be the case, or at least we'll all be up on how important various compile flags are. - August -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Shootout

these synthetics. What was suprising to me is that other scripting players like perl did reasonably well on some of them. Java has a more impressive showing than I would I have thought as well. Certainly some interesting food for thought. - August Curious looking forward (ZE2) where PHP is m

Re: [PHP-DEV] Re: Shootout

Sure, These are not my tests but Doug's. He compiled default so --debug and --inline-optimization not kicking in. Startup cost also counted, but he tried to run long enough to amortize that. n was 16. perl code was something like this. #!/usr/local/bin/perl # $Id: nestedloop.perl,v 1.2 2000/12/

Re: [PHP-DEV] Re: Shootout

e as trivial as bad compile time or config settings but I think this bad php programmer thing is a red herring. - August http://www.bagley.org/~doug/shootout/ */ $n = ($argc == 2) ? $argv[1] : 1; $x = 0; for ($a=0; $a<$n; $a++) for ($b=0; $b<$n; $b++) for ($c=0; $c<$n; $c++) fo

Re: [PHP-DEV] Re: Shootout

e as trivial as bad compile time or config settings but I think this bad php programmer thing is a red herring. - August http://www.bagley.org/~doug/shootout/ */ $n = ($argc == 2) ? $argv[1] : 1; $x = 0; for ($a=0; $a<$n; $a++) for ($b=0; $b<$n; $b++) for ($c=0; $c<$n; $c++) fo

Re: [PHP-DEV] Re: Shootout

e as trivial as bad compile time or config settings but I think this bad php programmer thing is a red herring. - August http://www.bagley.org/~doug/shootout/ */ $n = ($argc == 2) ? $argv[1] : 1; $x = 0; for ($a=0; $a<$n; $a++) for ($b=0; $b<$n; $b++) for ($c=0; $c<$n; $c++) fo

[PHP-DEV] Re: Shootout

Can someone run a few of these tests on a machine with --disable-debug. I'd be curious to know how much of a difference that might make. -AZ -- PHP Development Mailing List To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To c

[PHP-DEV] Re: Shootout

other languages. Really suprising, but really valuable. For folks doing performance sensitive work it may pay to look at some of the other languages listed or write more c extensions to PHP. Might also be nice to see what can be done to kick PHP's performance up a couple of notches. - A

RE: [PHP-DEV] Unbuffered fgetc needed for stdin

Andi Gutmans [mailto:[EMAIL PROTECTED]] > Sent: Saturday, December 15, 2001 1:34 PM > To: August Zajonc; [EMAIL PROTECTED] > Subject: Re: [PHP-DEV] Unbuffered fgetc needed for stdin > > > This usually depends on how you configured your tty. I think by > default it > is buffer

[PHP-DEV] Unbuffered fgetc needed for stdin

I've really run into a wall trying to get single charachters from stdin. Something similar to the getchar macro or a real fgetc would be nice. The current behavior is that more than a signle charachter can be typed and fgetc only returns when it sees a "\n". I'd like it to return immediatly aft

[PHP-DEV] Re: Random Row From Database

How is this -dev? How is it php? This is crossposted. -AZ "Hew Staff" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Hi, > > I'm trying to pull a random row from my database and display the contents. > > I know that the code: > SELECT * FROM TABLENAME WHERE R

[PHP-DEV] Re: Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)

Redirecting bugs to -qa is excellent. -dev is no fun to actually subscribe to with the number of support requests alone coming in. I imagine folks have gotten pretty good at ignoring em but... Let's do it. Be nice to see the possibility of third party comments to bugs as well for confirms, worksf

Re: [PHP-DEV] Re: Wow ! Good news (to me at least) ...

0011109143452.04339e98@localhost... > I promised that anybody that I'll break the neck of anybody that complains > about not going with the GPL. Please inform me of any PHP conferences you > intend to attend, so I know where to find you :) > > Zeev > > At 20:28 08/11/200

RE: [PHP-DEV] [UPDATE] NGScan

t looking at the new scanner the license seems very open? AZ -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 5:10 PM To: August Zajonc Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] [UPDATE] NGScan At 23:57 9/7/2001, August Zajonc wrote: >Why

Re: [PHP-DEV] [UPDATE] NGScan

Why not have an abstraction? It would seem this would allow scanners with different licenses to co-exist, and more to the point there's an immediate technical win here, with code already written. Looking over the patch it appears that this wouldn't effect most people unless they --disable-zend-sc

Re: [PHP-DEV] [UPDATE] NGScan

Be interested in seeing this go in. I've been fooling with Apache 2.0.20 and this does some nice things in that respect. Apache is _this_ close to being beta, again :) AZ "Thies C. Arntzen" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > On Mon, Jul 09, 2001 at 08:55:09AM -070

Re: [PHP-DEV] PHP 4.0 Bug #9914 Updated: session_id loss with redirection via header() method

I'd like to +1 this feature change request. AZ - Original Message - From: <[EMAIL PROTECTED]> Newsgroups: php.dev Sent: Thursday, March 22, 2001 8:09 AM Subject: [PHP-DEV] PHP 4.0 Bug #9914 Updated: session_id loss with redirection via header() method > ID: 9914 > Updated by: sniper > R

Re: [PHP-DEV] Bug #10319: multipart/form-data does not work with Opera browser

I suspect this is likely a browser issue rather than a PHP issue. Can you flesh out a bit what PHP is doing wrong and what needs to be done to fix this "BUG"? Alternatively, you could submit a question to php-general... AZ - Original Message - From: <[EMAIL PROTECTED]> Newsgroups: php.d

Re: [PHP-DEV] Suggestion for bug system

What about leveraging an existing bug system? There is Alexandria over at sourceforge which looks like it is still in development, and by enhancing it projects at sourceforge may also benefit. It sometimes seems that some of the best aspects of open source are not taken advantage of. A ton of sy