Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

It's an inherent 'feature' of opensource projects, which has its advantages 
and disadvantages.  One of the good things about OSS is the relatively 
short 'time to market'.  The price is that you have to be willing to accept 
buglets.  The trick is to find the right mixture between time to market and 
the risk of instability.

In my humble opinion (humility is a virtue), new modules are fine to add 
while in the release process, as long as there's at least one RC after 
them, to ensure they don't mess up the build or anything trivial like 
that.  It takes 2-3 months between each and every release, and it'd be a 
shame for the new module author to receive wide exposure and feedback for 
his new code.  In my opinion, the CVS rules should be changed to reflect 
that, just to make Jani happy, or we'd stay outlaws in his mind forever :)

Zeev

At 23:21 20/3/2001, Sascha Schumann wrote:
> > The SAPI extension was never used by anyone before so there's no harm in
> > adding it (this is not changing/patching existing functionality).
> > It does make two changes to two build files but I took a very close look at
> > them and it doesn't seem like they can cause us problems.
>
> Regardless of how simple a change may look, it can cause
> problems.  IMNSHO, only well-tested changes for critical bugs
> should be applied to a release branch ever, otherwise we will
> never get rid of patchlevel releases.  Our continous need for
> those point to a quite embarrasing problem in our release
> process which we finally need to overcome.
>
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg
>
>
>--
>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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] Changing ip2long() return value to string

[Zeev Suraski]

Should be safe...

At 02:23 21/3/2001, Sean R. Bright wrote:
>IP addrs are unsigned longs and zvals only handle signed longs, so the only
>way to avoid <0 values is to convert to a string before returning.  Anyone
>have issue with this?
>
>Sean
>
>--
>===
>Sean Bright
>[EMAIL PROTECTED] / [EMAIL PROTECTED] / http://www.seanbright.com/
>===
>
>
>
>--
>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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 13:10 21/3/2001, Sascha Schumann wrote:
> > In my humble opinion (humility is a virtue), new modules are fine to add
> > while in the release process, as long as there's at least one RC after
> > them, to ensure they don't mess up the build or anything trivial like
> > that.
>
> Oh, messing up the build is a trivial thing?

Yes, it is.  Non trivial things are things that are difficult to find, 
which require long and thorough testing, such as changes to core API 
functions or very common modules.  Figuring whether the build works or not 
is trivial.

> > It takes 2-3 months between each and every release, and it'd be a
> > shame for the new module author to receive wide exposure and feedback for
> > his new code.
>
> As the Midgard extension recently showed, a single line in an
> extension can break everything else.  And it can easily go
> unnoticed, especially if it is not reviewed by experienced
> people.

Easily unnoticed?  I beg to differ.  As soon as someone tried to build it, 
it failed.  That's why it's trivial, and that's why it's relatively safe to 
do it even while RC's are going.  The rule of 'dont break the CVS build' is 
crucial, and should be followed especially with RC's.  But the worst case 
situation of adding a new module is a broken build, which is noticed 
immediately, and thus is not dangerous.

> All new modules can gain wide exposure by distributing them
> separately.  They don't need to be in our tree, and
> they especially don't need to be added during the release
> process.  It is not worth the risk.

The risk is pretty much non existent, as I demonstrated.  Especially with a 
SAPI module, what you say isn't true.

> So few people have asked for the FastCGI module during the
> last two years that I doubt that it was necessary to push it
> into 4.0.5.

Zeus moved its recommendation from using the native ISAPI/Zeus module to 
using FastCGI, because of instability.  So you can expect FastCGI to be 
more popular.

> > In my opinion, the CVS rules should be changed to reflect
> > that, just to make Jani happy, or we'd stay outlaws in his mind forever :)
>
> The CVS rules are fine as they are.

Yes, so says you.  But I beg to differ.

Zeev


--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

No disrespect for the config.m4, it's not all that important if it's 
optimized or not :)

At 13:09 21/3/2001, Ben Mansell wrote:
>On Tue, 20 Mar 2001, Jani Taskinen wrote:
>
> > On Tue, 20 Mar 2001, Andi Gutmans wrote:
> >
> > >At 08:32 PM 3/20/2001 +0100, Derick Rethans wrote:
> > >>On Tue, 20 Mar 2001, Andi Gutmans wrote:
> > >>
> > >> > andi  Tue Mar 20 10:13:21 2001 EDT
> > >> >
> > >> >   Added files: (Branch: PHP_4_0_5)
> > >> > /php4/sapi/fastcgiCREDITS Makefile.in README.FastCGI 
> config.m4
> > >> >   fastcgi.c php.sym php_fastcgi.h
> > >> >   Log:
> > >> >   - MFH
> > >>
> > >>erhm, I thought that during the Release Process no new things were being
> > >>added
> > >
> > >The SAPI extension was never used by anyone before so there's no harm in
> > >adding it (this is not changing/patching existing functionality).
> > >It does make two changes to two build files but I took a very close 
> look at
> > >them and it doesn't seem like they can cause us problems.
> >
> > Still, it's against the rules.. :) And the config.m4 for it
> > isn't..hmm..optimized.
>
>Improvements are welcome... I'm no expert in the build system so theres
>no surprises that its far from optimized.
>
>Ben
>
>
>--
>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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 15:50 21/3/2001, Sascha Schumann wrote:
> > Yes, it is.  Non trivial things are things that are difficult to find,
> > which require long and thorough testing, such as changes to core API
> > functions or very common modules.  Figuring whether the build works or not
> > is trivial.
>
> That might be true for a single build.  We support dozens of
> platforms and figuring out whether a change breaks something
> on one particular platform is not as simple as you obviously
> assume.

I don't think that there would be a real life situation in which a new 
module would break a build under one platform, and won't under another 
platform, without you actually using the module.  The author has to be 
exceptionally 'talented' to achieve that.

> > > As the Midgard extension recently showed, a single line in an
> > > extension can break everything else.  And it can easily go
> > > unnoticed, especially if it is not reviewed by experienced
> > > people.
> >
> > Easily unnoticed?  I beg to differ.
>
> Zeev, there is a difference between the terms 'will' and
> 'can'.  I've used the latter.

I know, and as I said, I disagree.  I don't think it can go unnoticed in 
the further RC.

Zeev


--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 16:20 21/3/2001, Sascha Schumann wrote:
> > I don't think that there would be a real life situation in which a new
> > module would break a build under one platform, and won't under another
> > platform, without you actually using the module.  The author has to be
> > exceptionally 'talented' to achieve that.
>
> The config.m4 just has to reach a certain complexity to
> become incomprehensible.  I suggest reading ext/gd/config.m4
> for starters.

As you may know, new scripts don't tend to be born with nuclear simulations 
as their config.m4, as the gd extension grew to have during the years.

> > I know, and as I said, I disagree.  I don't think it can go unnoticed in
> > the further RC.
>
> Ah, of course.  Just as newly introduced bugs in the code are
> catched by further RCs..

No, not even similarly.

Zeev


-- 
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: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 16:44 21/3/2001, Hartmut Holzgraefe wrote:
>Sascha Schumann wrote:
> > Guys, please play by the rules which are laid down in
> > RELEASE_PROCESS.  Further decreasing the quality of PHP
> > releases doesn't help anyone and just makes us look bad.
>
>yes, that's it, let's play by the rules during a RC cycle or
>don't have rules at all
>
>rules for release cycles might be changed between RC cycles,
>but should definetly be applied unchanged while in use

I definitely don't agree with this definitely.  A good thing about 
opensource projects is that there aren't committees and thick rule books 
that move and act at the speed of a dinosaur.  When it begins to look that 
way, you know you're in the wrong direction.
It doesn't mean that we shouldn't have rules, but I'll never support rules 
such as 'dont debate/change the rules while [ANYTHING]'.  If the rules are 
broken, or there was lacking vision when we authored them, it should be 
fixed on the spot.

Zeev


-- 
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]

[PHP-DEV] Re: This won't get us nowhere (WAS: cvs: php4(PHP_4_0_5) /sapi/fastcgi)

[Zeev Suraski]

I'm completely agree (my breath is fine, though :)

Zeev

At 17:52 21/3/2001, Cynic wrote:
>Sascha & Zeev,
>
>May I please ask you to calm down a bit? Flamewars and insults
>won't help anyone.
>
>I think you both could use a few minutes to take your breath.
>
>
>At 16:38 21.3. 2001, Zeev Suraski wrote the following:
>--
> >At 17:15 21/3/2001, Sascha Schumann wrote:
> >>> I definitely don't agree with this definitely.  A good thing about
> >>> opensource projects is that there aren't committees and thick rule books
> >>> that move and act at the speed of a dinosaur.  When it begins to look 
> that
> >>> way, you know you're in the wrong direction.
> >>
> >>OpenSource does not mean careless committers and bug-riddled
> >>software.  OpenSource software can excel in code quality and
> >>stableness.
> >>
> >>Your personal goal seems to differ from that target.  I think
> >>that is a pity.
> >
> >Your argumentative tone is also a pity.
> >
> >As for the issue at hand, we differ greatly at the amount of importance 
> we attribute to considering rules as if they were God-given.  I care 
> about PHP's quality a lot, quite before you were even a contributor to 
> the project.  I'm not coming to downplay your caring, but I'm not sure 
> what makes you think you can downplay mine.
> >
> >The fact that you see what I say as if opensource software means 
> bug-riddled software or careless committers still doesn't mean that's 
> what I'm saying, and obviously (as I'm sure you know deep inside), it's 
> not.  That's just your binary way of looking at things, which is 
> thankfully not shared by most people.  I stand completely behind what I 
> said, but obviously not behind your summary of what I said.
> >
> >The bottom line is that, as I said, the trick in good opensource 
> software is taking calculated risks, and mixing agility with quality 
> assurance.  One can look through your binary glasses, and then it's 
> either complete lack of quality, or complete lack of risks, and one can 
> look with reasonable experienced eyes and strive to get to the right 
> mixture.  I, for one, don't enjoy looking through these binary glasses.
> >
> >Zeev
> >
> >
> >--
> >PHP Quality Assurance 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]
>--end of quote--
>
>
>[EMAIL PROTECTED]
>-
>And the eyes of them both were opened and they saw that their files
>were world readable and writable, so they chmoded 600 their files.
> - Book of Installation chapt 3 sec 7

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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: This won't get us nowhere (WAS: cvs: php4(PHP_4_0_5) /sapi/fastcgi)

[Zeev Suraski]

At 17:49 21/3/2001, Zeev Suraski wrote:
>I'm completely agree (my breath is fine, though :)

I, even :)

Zeev


-- 
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: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 17:15 21/3/2001, Sascha Schumann wrote:
> > I definitely don't agree with this definitely.  A good thing about
> > opensource projects is that there aren't committees and thick rule books
> > that move and act at the speed of a dinosaur.  When it begins to look that
> > way, you know you're in the wrong direction.
>
> OpenSource does not mean careless committers and bug-riddled
> software.  OpenSource software can excel in code quality and
> stableness.
>
> Your personal goal seems to differ from that target.  I think
> that is a pity.

Your argumentative tone is also a pity.

As for the issue at hand, we differ greatly at the amount of importance we 
attribute to considering rules as if they were God-given.  I care about 
PHP's quality a lot, quite before you were even a contributor to the 
project.  I'm not coming to downplay your caring, but I'm not sure what 
makes you think you can downplay mine.

The fact that you see what I say as if opensource software means 
bug-riddled software or careless committers still doesn't mean that's what 
I'm saying, and obviously (as I'm sure you know deep inside), it's 
not.  That's just your binary way of looking at things, which is thankfully 
not shared by most people.  I stand completely behind what I said, but 
obviously not behind your summary of what I said.

The bottom line is that, as I said, the trick in good opensource software 
is taking calculated risks, and mixing agility with quality assurance.  One 
can look through your binary glasses, and then it's either complete lack of 
quality, or complete lack of risks, and one can look with reasonable 
experienced eyes and strive to get to the right mixture.  I, for one, don't 
enjoy looking through these binary glasses.

Zeev


-- 
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: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

In an attempt to fulfill Cynic's request, I'll only say that this whole 
thread began when I suggested that the release-process is modified to 
reflect that adding new modules is allowed.

Zeev

At 18:03 21/3/2001, Sascha Schumann wrote:
> > The bottom line is that, as I said, the trick in good opensource software
> > is taking calculated risks, and mixing agility with quality assurance.  One
> > can look through your binary glasses, and then it's either complete lack of
> > quality, or complete lack of risks, and one can look with reasonable
> > experienced eyes and strive to get to the right mixture.  I, for one, don't
> > enjoy looking through these binary glasses.
>
> Then please start explaining what the right mixture is.
> Apparently, we have not found the right mixture yet, unless
> of course, patchlevel releases are part of that Great Plan.
>
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] 4.0.5RC1 crash...

[Zeev Suraski]

Is this a new issue in 4.0.5?  Or did the problem exist in older versions 
as well?

Zeev

At 18:44 21/3/2001, Dan Kalowsky wrote:
>Follow up on the earlier reporting of having memory issues to 4.0.5RC1.
>
>We've been able to reproduce the problem once again.  Although it seems
>to be only happening after EXTREMELY long periods of time and continuous
>heavy usage during that time.  Currently I'm not able to point exactly
>to any specific area causing it (I know the script, but the line is
>unknown) so let's see what I can give you to help debug this a bit
>further
>
>This time around we've got a bit more information for your enjoyment
>though...
>Snippits from the /var/log/httpd-error.log file:
>
>[Fri Mar 16 09:42:37 2001] [notice] SIGHUP received.  Attempting to
>restart
>[Fri Mar 16 09:42:38 2001] [notice] Apache/1.3.17 (Unix) mod_perl/1.24
>PHP/4.0.5RC1 configured -- resuming normal operations
>zend_hash.c(202) :  Freeing 0x083066E4 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x08173124 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x0835E6E4 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x081E37A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>[Fri Mar 16 17:13:05 2001] [error] [client 172.16.64.5] File does not
>exist: /usr/local/www/data/interactive/internet/index.html
>
>
>Yet again even more.  from Friday March 19th
>zend_hash.c(202) :  Freeing 0x081B9E24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x081B86A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x081A8E24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x0819F5A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x081BAE24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x081A96A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x081B8E24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 212 times
>zend_opcode.c(304) :  Freeing 0x08205024 (2100 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 1 time
>./zend_language_scanner.l(1059) :  Freeing 0x0820D824 (39 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 8 times
>zend_hash.c(461) :  Freeing 0x081DCBA4 (76 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 13 times
>./zend_execute.c(1629) :  Freeing 0x0824B564 (24 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_variables.c(117) : Actual location (location was relayed)
>Last leak repeated 41 times
>Last leak repeated 6 times
>var.c(475) :  Freeing 0x0833AA24 (2 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 15 times
>var.c(562) :  Freeing 0x0833A9A4 (12 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 16 times
>session.c(501) :  Freeing 0x082529A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(188) : Actual location (location was relayed)
>session.c(500) :  Freeing 0x0833BFE4 (12 bytes),
>script=/usr/local/www/data/Login/users_login.php
>mod_files.c(134) :  Freeing 0x0822DFA4 (33 bytes),
>script=/usr/local/www/data/Login/users_login.php
>mod_files.c(209) :  Freeing 0x081BBC64 (5 bytes),
>script=/usr/local/www/data/Login/users_login.php
>mod_files.c(201) :  Freeing 0x08335E24 (16 bytes),
>script=/usr/local/www/data/Login/users_login.php
>session.c(873) :  Freeing 0x081F60A4 (33 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_compile.c(1605) :  Freeing 0x083186E4 (12 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 3 times
>main.c(1059) :  Freeing 0x081B9C24 (48 bytes),
>script=/usr/local/www/data/home/menu_walled_garden.php
>
>
>
>This goes on for some time, so if you want to see it all, you can find
>the full version at http://www.deadmime.org/~dank/sitics-error.log
>
>But it also leaves an interesting spot in the middle:
>
>---
>zend_opcode.c(168) : Block 0x081ACAC0 status:
>zend_variable

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 20:50 21/3/2001, Sascha Schumann wrote:
>On Wed, 21 Mar 2001, Andi Gutmans wrote:
>
> > A couple of these were buffer overflows IIRC which were security issues.
> > Remember the group@ emails about those?
>
> Fixes against format-string attacks and for file-upload
> issues went into 4.0.3.  Or what are you referring to?

The Apache module issue was a security problem.  A fairly major one, too.

Zeev


-- 
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: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

But I referred to 4.0.3pl1 :)

At 21:23 21/3/2001, Sascha Schumann wrote:
> > The Apache module issue was a security problem.  A fairly major one, too.
>
> Yes, that is why I mentioned 4.0.4pl1 as an exception in an
> earlier email.
>
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 21:25 21/3/2001, Sascha Schumann wrote:
>On Wed, 21 Mar 2001, Andi Gutmans wrote:
>
> > Why do we need to have an interrogation. Relax, it's not such a big deal.
>
> I'm completely relaxed.  I just dislike twisting history.

Sascha,

As Cynic said, it's really a good idea to stop the flame wars.  Being 
cynical (nice coincidence) doesn't help, because it draws cynical remarks 
from the other side (as you could see).  Let's just stop.  The argument 
diverted to unrelated issues anyway.

Zeev


-- 
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: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

It's definitely considered experimental.

Zeev

At 22:19 21/3/2001, Jason Greene wrote:
>Though I am still considered new to this group, I thought I would put in 
>my two cents.
>
>Are we considering fastcgi module stable?  We currently release 
>EXPERIMENTAL modules
>as part of the distribution. If fastcgi is considered EXPERIMENTAL, then I 
>don't see why the
>module itself could not be included in the RC branch. The only piece that 
>really has to be checked
>is config.m4, and in this scenario there doesn't appear to be 
>problems(efficient or not). As long as
>the withval test is valid, and the module is not enabled by default it 
>really shouldn't affect php
>as a whole. I believe that this is a fine exception to the rule.
>
>However, if fastcgi is being labled stable, then, IMHO, I believe it 
>should wait for thorough testing,
>and the next freeze.
>
>I think that Sascha, and Jani have concerns with this being the first 
>domino in a series of continually
>growing exceptions to the release process. An RP ruleset is one of those 
>things that is often considered
>  "Holy",and shouldn't have reoccuring exceptions. Zeev has expressed 
> valid points about the functionality
>  being important and shouldn't wait.  Which, if there is big need for it, 
> why can't there be a compromise?
>
>Perhaps everyone should consider altering the RP ruleset, to include an 
>exception about adding new
>modules.
>
>If the exception policy was in place here are some questions of thought:
>What would be necessary to make it safe to php in a whole?
>What should the requirements be to allow this to happen ( ex. a lot of 
>user demand, replaces something considered unstable) ?
>Should this require any re-testing?
>Should this require x amount of RCs to follow and how many?
>Should there be a vote on whether or not to allow the module in?
>Is this module something that should first be released as an add-on?
>
>I honestly agree with both positions on this one, and I think  good can 
>come from both of them : )
>
>-Jason
>
>
>
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Sascha Schumann" <[EMAIL PROTECTED]>
>Cc: "PHP Developers Mailing List" <[EMAIL PROTECTED]>; "PHP Quality 
>Assurance Team Mailing List" <[EMAIL PROTECTED]>
>Sent: Wednesday, March 21, 2001 1:33 PM
>Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: 
>php4(PHP_4_0_5) /sapi/fastcgi
>
>
> > But I referred to 4.0.3pl1 :)
> >
> > At 21:23 21/3/2001, Sascha Schumann wrote:
> > > > The Apache module issue was a security problem.  A fairly major 
> one, too.
> > >
> > > Yes, that is why I mentioned 4.0.4pl1 as an exception in an
> > > earlier email.
> > >
> > > - Sascha Experience IRCG
> > >   http://schumann.cx/http://schumann.cx/ircg
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
> >
> > --
> > 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]
> >

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 22:19 21/3/2001, Jason Greene wrote:
>If the exception policy was in place here are some questions of thought:
>What would be necessary to make it safe to php in a whole?

I'd say that a module that has no effect on building PHP is fine to add as 
an experimental module.  The only reason I believe we need at least one RC 
afterwards, is to ensure that trivial problems weren't introduced (mostly, 
a broken build).

>What should the requirements be to allow this to happen ( ex. a lot of 
>user demand, replaces something considered unstable) ?

I think that these are the same requirements for any other module that we 
decide to admit to the tree.  Since it's not a big deal, if it belongs in 
the PHP 4.0 tree, then it's ok to add it whilst in RC's.

>Should this require any re-testing?
>Should this require x amount of RCs to follow and how many?

IMHO, one more RC.

>Should there be a vote on whether or not to allow the module in?

We don't have a body with 'jurisdiction' other than the PHP Group, so I'd 
say no;  Whatever loose guidelines we use today to admit new modules can 
apply here as well.

>Is this module something that should first be released as an add-on?
>
>I honestly agree with both positions on this one, and I think  good can 
>come from both of them : )

I think that by saying you agree with both positions you attribute to me 
things that I didn't say :)  I'm all in favour of a stable release 
process.  I'm not in favour in considering the release process guidelines 
as 'holy', and if I or anybody else thinks they can be improved, the right 
step would be to raise it for discussion.  As I said to Hartmut, the minute 
bureaucracy becomes sacred, you know you're doing something wrong.  I 
considered the fact that the release process did not account for new 
experimental modules a limitation of the release process.  Even the US 
constitution required a few amendments before they got it right :)

Zeev


--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] is_reference() ?

[Zeev Suraski]

At 22:30 21/3/2001, Björn Schotte wrote:
>Hi,
>
>I recently had a discussion with Alexander Aulbach
>(submitter of bug reports with unset() and the
>inconsistencies with unset($foo) and unset($bar["bla"])
>(the latter works, the former not))

Huh?  Both work...?


>  and we agreed
>that there definitively would be need of a funtion
>called
>
>   is_reference(varname)
>
>Sometimes we would like to know if $foo is a references
>variable or not (e.g. to ship around the unset() bug
>issue).
>
>What do you think?

This has been discussed before (as far as I recall).  The engine may 
convert certain variables to be references on the fly, without the user 
requesting it.  So, is_reference() won't mean much to end users.

Zeev


--
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] is_reference() ?

[Zeev Suraski]

At 22:36 21/3/2001, Björn Schotte wrote:
>Hi,
>
> > It's not really possible right now due to the way Zend engine works.
>
>So it would be better to reopen the bug reports
>which considered the unset() issue?

unset() is consistent with the way it is defined - it removes a certain 
symbol from the namespace.  If you refer to the fact you use unset() to 
unset not only the symbol itself, but also all other symbols that reference 
to the same value - that's true, but that's just the way it is...  You can 
assign null to them instead.

Zeev


--
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] is_reference() ?

[Zeev Suraski]

At 22:39 21/3/2001, Björn Schotte wrote:
>Hi Zeev,
>
> > >inconsistencies with unset($foo) and unset($bar["bla"])
> > >(the latter works, the former not))
> > Huh?  Both work...?
>
>Here it is in detail:
>
>http://www.php.net/bugs.php?id=8937
>http://www.php.net/bugs.php?id=8972

Ok, as I thought, it has to do with the fact the unset()'ing a variable 
won't unset any references to it.  It (the way globals/statics work) is a 
changed behavior from PHP 3.0, but it's an intended behavior and isn't 
considered a bug.

Zeev


--
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] [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs:

[Zeev Suraski]

Fredrick,

While the tone of the messages was heated, they were very much 
on-topic.  If it doesn't interest you, then don't participate.

Zeev

At 01:04 22/3/2001, Fredrik Ohrn wrote:

>Flame each other all you want. I don't mind.
>
>But please, stick to one list, stop crossposing to every list and your mum.
>This is getting pretty annoying.
>
>
>/Fredrik
>
>--
>Do fish get thirsty?
>
>Fredrik Öhrn   Chalmers University of Technology
>[EMAIL PROTECTED]  Sweden
>
>
>--
>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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


--
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: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 16:38 21/3/2001, Thies C. Arntzen wrote:
> i fully agree to sascha. plus i see no real reason to include
> a new module once we are in "release-process". new modules
> are by default not "producition-stable" so why hurry to
> include them in a "official-release"?

For wide exposure.  SAPI modules will not get very far without it.

> the no. 1 (and maybe only goal) for a release should be
> stability and well tested functionality IMHO.

Stability is irrelevant with new modules - they did not exist before, so 
they can't be less stable, and figuring whether their addition breaks PHP 
is trivial, and would be discovered in a second if they manage to do that 
somehow.  New modules are no different from any of the unstable modules 
that exist in PHP, and there are plenty of them.

Zeev


-- 
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]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

I don't get it.  So if it was two weeks ago, a second before I said 
"4.0.5RC1 is out" it was ok, and now it isn't?  It doesn't make any sense.

Code changes are one thing.  Bugs that originate in code changes (whether 
they're new features, bug fixes or rewrites) may take very long time to 
find.  The sad truth is that there's actually a good chance they won't be 
found even if there isn't a single line of code changed during the entire 
release period.  That's just the nature of software bugs.  The more people 
test, and the more time they get to test it - the better.  Obviously, 
though, every release only gets 'truly' tested once it actually hits the 
road and undergoes mass distribution.  We just try to maximize the chances 
of making it safe.

New modules do not significantly increase the chances of messing up the 
release.  Furthermore, if they do mess up the release, it's trivial to find 
that out.  Nothing of what was said on php-dev/php-qa in this thread 
contradicted it (it doesn't mean that the build process is not important or 
anything;  it does mean that it's trivial to determine whether it got 
messed up or not by a new module).  Because of the clear gain vs. 
negligible loss, when Ben approached us and asked whether it's ok to put it 
in 4.0.5, knowing that there's another RC coming up in a couple of hours - 
we said that it's fine.  If it's going to take changing RELEASE_PROCESS to 
'allow' this to keep things quiet, then we should do it.  We shouldn't 
consider RELEASE_PROCESS as the bible, but as guidelines to work by and 
improve on as we gather experience.

Zeev

At 03:26 22/3/2001, Anil Madhavapeddy wrote:
>The point is, why did this issue come up in the first place?
>The time between releases is large, and the time in RC-branch is small.
>
>If it's so important that this module makes it in (which I can agree with),
>then I'm surprised it wasn't brought up when you first announced that
>PHP-4.0.5 would be out soon (which was a good bit of notice before RC).
>
>If it was a time issue, it wouldn't have hurt to delay the RC by a week or
>so until all the features were in, after all this time waiting for it :-)
>
>Anil

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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: cvs: php4(PHP_4_0_5)/sapi/fastcgi

[Zeev Suraski]

At 12:14 22/3/2001, Ron Chmara wrote:
>1. Adding new/experimental extensions _can_ invisibly bug the rest of a
>build, if they require such nastiness as the recent pthread debugging.
>It's not only a minor configure issue when a built app breaks due to library
>issues, because extensions can be linked in conflicting ways. It does
>happen, it has happened in rather annoying, small ways (see mod_ssl
>vs. mysql client and -lpthread linking issues.). These bugs suck, but
>they do happen, because extensions are not ever totally isolated if they
>are running on the same system, and linking to something else.

A new module that *is not enabled* would have to go through a lot of 
efforts in order to break the build.  Of course, if you enable it, you're 
on your own, much like you're on your own with any experimental 
module.  The risk of breaking *the stable* PHP parts is negligible.  Right 
now, we knowingly ship PHP with large code portions which are not 
stable.  We consider this ok, because these modules are considered 
experimental.  Until this approach is changed, there's really no difference 
between adding new experimental modules during the RC process, or before 
it.  That's why they're *modules*, and why PHP's modular.

Everything else you said is fine, except it doesn't really apply to the 
issue at hand.

Zeev


-- 
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]

[PHP-DEV] Re: [PHP-QA] 4.0.5RC2

[Zeev Suraski]

I just realized my letter about the RC2 release was never actually queued 
and sent (it was up since Sunday evening).  At any rate - 
http://www.php.net/distributions/php-4.0.5RC2.tar.gz.

I believe this would be the last RC for 4.0.5, with a release towards the 
end of next week (assuming nobody actually tested RC2 until now).

Zeev

At 13:10 20/3/2001, Zeev Suraski wrote:
>I intend to package 4.0.5RC2 tonight, if someone still has any patches 
>that should go into 4.0.5, please commit them in the next few hours.
>Andre - I did commit the output buffering fixes quite a few days ago...
>
>Zeev
>
>--
>Zeev Suraski <[EMAIL PROTECTED]>
>CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>
>
>--
>PHP Quality Assurance 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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] builtin functions / constructs

[Zeev Suraski]

What's the point of returning the language constructs though?  By 
definition, each of them has its own semantics, so I can't see any use for 
that...

Zeev

At 15:08 23/3/2001, Hartmut Holzgraefe wrote:
>Stefan Livieratos wrote:
> >
> > Hi,
> >
> > "Cynic" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
> > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > Is there a way to get names of available "language constructs"
> > > in a PHP program? I mean, I don't think there's currently
> > > a way a PHP script can know if e. g. zend_version() is available
> > > (other than function_exists( 'zend_version' ), that is).
> > > Is something along get_builtin_constructs() possible?
> >
> > Take a look at get_defined_functions(),
> > http://www.php.net/manual/en/function.get-defined-functions.php .
>
>does this return things like unset()?
>no it doesn't!
>
>there's a difference between builtin functions and language constructs
>
>--
>Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77
>
>Besuchen Sie uns auf der CeBIT 2001 - in Halle 6 Stand F62/4
>
>--
>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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] builtin functions / constructs

[Zeev Suraski]

unset() is not a function, and using it has very different semantics than a 
function call (e.g., you can't use unset() as a part of a bigger 
expression, but only as a full 'unset();' statement).  There aren't too 
many built-in constructs that behave exactly like functions, as a matter of 
fact, I don't think there are any.  The ones that come close:

- isset() and empty() - their different semantics is that they won't 
display a warning when fed a non existent argument (regardless of error 
reporting).
- print, include, require - do not require parentheses
- echo - does not require parentheses, and still accepts a coma-separated 
list of arguments


At 17:12 23/3/2001, Hartmut Holzgraefe wrote:
>Stefan Livieratos wrote:
> >
> > "Hartmut Holzgraefe" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
> > > does this return things like unset()?
> > > no it doesn't!
> > >
> > > there's a difference between builtin functions and language constructs
> >
> > You are right of course. I was misled by the example Cynic used. On the
> > other hand I don't know how useful a function that returns all
> > language constructs would be. Could someone give me an example for
> > using such a function in a sensible way?
>
>i just wanted to show that there are things that look like functions
>but aren't
>
>i'd suggest that those few should be added to the result of
>get_defined_functions, either under 'internal' or as a third
>block 'constructs'
>
>--
>Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77
>
>Besuchen Sie uns auf der CeBIT 2001 - in Halle 6 Stand F62/4
>
>--
>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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] builtin functions / constructs

[Zeev Suraski]

At 18:20 23/3/2001, Cynic wrote:
>As for the sensible purpose:
>I'm writing phLXR. It's like LXR, except it's written in PHP, for PHP
>programs, and (me being still firmly rooted in the NT world) with
>portability in mind -> no Glimpse. I want the internal PHP stuff (be
>it a function, a "language construct" (who cares? it feels and tastes
>like a function!), or your coffee cup to be links to PHP documentation.
>And the more I can get automagically through a call, the less maintenance
>work will be required from the user.

The language constructs PHP supports aren't a moving target, so there's no 
much sense in having a function that returns them.  You should be quite 
safe hardcoding these constructs in your application.

Zeev


-- 
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] builtin functions / constructs

[Zeev Suraski]

At 18:49 23/3/2001, Hartmut Holzgraefe wrote:
>Zeev Suraski wrote:
> > The language constructs PHP supports aren't a moving target, so there's no
> > much sense in having a function that returns them.  You should be quite
> > safe hardcoding these constructs in your application.
>
>it should be even more save to hardcode them in PHP itself

Yeah, but doesn't make sense.  A function is useless (i.e. nothing but 
bloat) if it always returns the same thing.

Zeev


-- 
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] builtin functions / constructs

[Zeev Suraski]

There's no real motivation to do that actually.  These constructs are very 
unique, and the fact they have construct-specific syntax doesn't have any 
negative impact, as it's still within the standard syntax rules of PHP (all 
but echo, which is a remnant of PHP/FI 2, and perhaps it was a mistake to 
copy its syntax as-is).
Let's not look for problems where they don't exist...

Zeev

At 20:31 23/3/2001, Phil Driscoll wrote:
> >it should be even more save to hardcode them in PHP itself
>
>...or better still not to have language constructs at all so that everything
>that looks like a function also works like a function.
>
>
>:)
>--
>Phil Driscoll
>Dial Solutions
>+44 (0)113 294 5112
>http://www.dialsolutions.com
>http://www.dtonline.org

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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]

[PHP-DEV] RC3?

[Zeev Suraski]

There were a few fixes since RC2 was tagged (a socket fix, a pgsql fix, a 
checkdnsrr fix).  It may be a good idea to have an RC3, but I want to hear 
some feedback from others (RC2 seemed generally quite stable, so if we go 
with RC3, it should only delay the release until the beginning of next week).

Zeev


--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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]

[PHP-DEV] RC3 will be released tonight

[Zeev Suraski]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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]

[PHP-DEV] Re: [PHP-QA] RC3?

[Zeev Suraski]

Can't reproduce it under RH 6.2, but I don't mind seeing that fix in the CVS...

Zeev

At 13:55 27/3/2001, Derick Rethans wrote:
>Hello,
>
>there is a bug #10002, should be fixed too IMHO
>
>Derick
>
>On Tue, 27 Mar 2001, Zeev Suraski wrote:
>
> > There were a few fixes since RC2 was tagged (a socket fix, a pgsql fix, a
> > checkdnsrr fix).  It may be a good idea to have an RC3, but I want to hear
> > some feedback from others (RC2 seemed generally quite stable, so if we go
> > with RC3, it should only delay the release until the beginning of next 
> week).
> >
> > Zeev
> >
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
> >
> > --
> > PHP Quality Assurance 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]
> >
>
>Derick Rethans
>
>-
> PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
>  SRM: Site Resource Manager - www.vl-srm.net
>-
> JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
>  Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands
>-

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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]

[PHP-DEV] non-thread-safe yet pthreads-friendly build of PHP?

[Zeev Suraski]

Is there any way to build PHP with pthreads, with ZTS disabled?  The reason 
I'm asking is that there are some thread-safe 3rd party libraries which are 
linked against pthreads, and apparently, if PHP isn't built with pthreads - 
it crashes.  Any experience with it?

Zeev


--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] non-thread-safe yet pthreads-friendly build of PHP?

[Zeev Suraski]

Ok, thanks!

Zeev

At 00:29 28/3/2001, Rasmus Lerdorf wrote:
> > Is there any way to build PHP with pthreads, with ZTS disabled?  The reason
> > I'm asking is that there are some thread-safe 3rd party libraries which are
> > linked against pthreads, and apparently, if PHP isn't built with pthreads -
> > it crashes.  Any experience with it?
>
>If you link Apache with pthreads that should suffice.  Just add -lpthreads
>to the Apache LIBS line.
>
>-Rasmus

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] (apparently) leaky zend

[Zeev Suraski]

At 12:26 28/3/2001, Wez Furlong wrote:
>Hi All,
>
>I've been noticing a whole bunch of memory leaks that appear to be coming
>from zend while running a complex script.
>
>zend_hash.c(202) :  Freeing 0x088D11E4 (20 bytes), script=/wwwroot/view.php
>Last leak repeated 37 times
>./zend_execute.c(2144) :  Freeing 0x089D8E3C (48 bytes),
>script=/wwwroot/view.php
>zend_variables.c(131) : Actual location (location was relayed)
>Last leak repeated 27 times
>zend_hash.c(291) :  Freeing 0x08A86FD4 (46 bytes), script=/wwwroot/view.php
>Last leak repeated 191 times
>zend_hash.c(461) :  Freeing 0x08A943E4 (76 bytes), script=/wwwroot/view.php
>Last leak repeated 18 times
>
>plus a load more like it.
>
>Before I file a bug report, I wanted to see if I could track it down, but
>it's proving difficult.
>
>The script makes heavy use of PCRE and use of the jstring extension, so my
>money is on one of those two,
>but I can't see anything obvious that might be causing it.
>
>What concerns me is that it appears that the same pointers are being freed
>multiple times.

How do you see that?  That 'last leak repeated 18 times' doesn't mean the 
pointer got freed 18 times, but rather, that a leak from zend_hash.c(461) 
repeated itself 18 times...

There's no magical way of solving this, other than trying to cut down the 
script to the smallest piece of code that still leaks, and then trying to 
figure out what causes the leak (or sending this cut-down piece of code to 
php-dev for help...)

Zeev


-- 
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] Leaking references

[Zeev Suraski]

I don't have enough mental strength to dive into that script right now, but 
be advised that if you create circular references (which apparently you do) 
then yes, it will leak.  PHP doesn't support circular references.

Zeev

At 15:06 28/3/2001, Wez Furlong wrote:
>[I can't reach the PHP web site (100% packet loss), so I can't open a bug
>report at this time]
>
>I have found a leak in the Zend engine:
>
>class A
>{
> var $t = null;
>
> function &run(&$t)
> {
> $this->t = &$t;
> return $this->t->run();
> }
>
>}
>
>class C {
> var $obj = null;
>
> function &load_and_run()
> {
> $this->obj = & new A;
> return $this->obj->run($this);
> }
>
> function &run()
> {
> return "";
> }
>}
>
>function &load_it()
>{
> $t =& new C;
> echo $t->load_and_run();
>}
>
>echo load_it();
>
>Running this script yields:
>
>zend_hash.c(291) :  Freeing 0x0818E474 (37 bytes), script=leak.php
>Last leak repeated 1 time
>zend_hash.c(202) :  Freeing 0x08193D1C (20 bytes), script=leak.php
>Last leak repeated 1 time
>./zend_execute.c(1848) :  Freeing 0x0818E414 (48 bytes), script=leak.php
>zend_API.c(208) : Actual location (location was relayed)
>Last leak repeated 1 time
>./zend_execute.c(1847) :  Freeing 0x08193F3C (12 bytes), script=leak.php
>Last leak repeated 1 time
>
>I know the script looks odd - it's part of a complex script that dynamically
>includes scripts to load classes.
>You get more leaks if you add more member variables to class A.
>
>I would guess that something (possibly the instance of class A) is not being
>freed/released somewhere that it should.
>
>--Wez.
>
>PS: If one of you guys could put this in the bug DB under my name, I would
>appreciate it.
>
>
>--
>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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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]

[PHP-DEV] PHP 4.0.5RC3

[Zeev Suraski]

RC3 is out - http://www.php.net/distributions/php-4.0.5RC3.tar.gz

Zeev


--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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]

[PHP-DEV] Re: [PHP-QA] PHP 4.0.5RC3

[Zeev Suraski]

Next time www.php.net updates it should be there...

At 17:14 28/3/2001, Cynic wrote:
>404 (error code, not a PHP version :)
>
>At 17:01 28.3. 2001, Zeev Suraski wrote the following:
>--
> >RC3 is out - http://www.php.net/distributions/php-4.0.5RC3.tar.gz
> >
> >Zeev
> >
> >
> >--
> >Zeev Suraski <[EMAIL PROTECTED]>
> >CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
> >
> >--
> >PHP Quality Assurance 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]
>--end of quote--
>
>
>[EMAIL PROTECTED]
>-
>And the eyes of them both were opened and they saw that their files
>were world readable and writable, so they chmoded 600 their files.
> - Book of Installation chapt 3 sec 7

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] [Fwd: [PHP-QA] security patches against 4_0_5]

[Zeev Suraski]

It made it into RC3 (looked ok to me)

At 19:24 28/3/2001, André Langhorst wrote:
>Does anyone see a problem with this patch?
>--
>· André Langhorstt: +49 331 5811560 ·
>· [EMAIL PROTECTED]  m: +49 173 9558736 ·
>* PHP Quality Assurance  http://qa.php.net  *
>
>
>X-Mozilla-Status2: 
>Return-Path: <[EMAIL PROTECTED]>
>Received: from toye.php.net (va.php.net [198.186.203.51])
> by strahler.kreuzfeuer.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) 
> with SMTP id f2RE85q06536
> for <[EMAIL PROTECTED]>; Tue, 27 Mar 2001 16:08:05 +0200
>Received: (qmail 24394 invoked by uid 1013); 27 Mar 2001 14:03:11 -
>Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>Precedence: bulk
>Delivered-To: mailing list [EMAIL PROTECTED]
>Received: (qmail 24387 invoked from network); 27 Mar 2001 14:03:10 -
>X-Authentication-Warning: nameserver.bicnet.it: Host domino.bicnet.it 
>[151.99.231.30] claimed to be domino
>Message-ID: <00b701c0b6c8$63cf5360$[EMAIL PROTECTED]>
>From: "Romolo Manfredini" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Date: Tue, 27 Mar 2001 16:15:33 +0200
>MIME-Version: 1.0
>Content-Type: multipart/mixed;
> boundary="=_NextPart_000_00B3_01C0B6D9.272616E0"
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook Express 5.50.4522.1200
>X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
>Subject: [PHP-QA] security patches against 4_0_5
>
>Does someone see problems in merging the following patches in 4_0_5
>
>They patch two serius problems in 4_0_5
>
>copy function:
>the safe mode check, checks only ownership of source, then it call 
>php_copy_file, so if the httpd process have OS right to open the target 
>file, any user can overwrite a file writable by httpd with a file owned by 
>himself.
>
>move_uploaded_file
>similar problem as user can overwrite any file with the uploaded one.
>
>waiting for comments.
>
>Romolo Manfredini
>
>
>--
>PHP Quality Assurance 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]
>--
>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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


--
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: [PHP-QA] PHP 4.0.5RC3

[Zeev Suraski]

Looks like a bug then.  I'll check it out.


At 19:51 28/3/2001, Cynic wrote:
>how often does it update? Three hours later it's still not there.
>
>At 17:34 28.3. 2001, Zeev Suraski wrote the following:
>--
> >Next time www.php.net updates it should be there...
> >
> >At 17:14 28/3/2001, Cynic wrote:
> >>404 (error code, not a PHP version :)
> >>
> >>At 17:01 28.3. 2001, Zeev Suraski wrote the following:
> >>--
> >>>RC3 is out - http://www.php.net/distributions/php-4.0.5RC3.tar.gz
> >>>
> >>>Zeev
>--end of quote--
>
>
>[EMAIL PROTECTED]
>-
>And the eyes of them both were opened and they saw that their files
>were world readable and writable, so they chmoded 600 their files.
> - Book of Installation chapt 3 sec 7

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] PHP 4.0.5RC3

[Zeev Suraski]

Should be fixed...

At 22:02 28/3/2001, Matt White wrote:
>Okay, so I have a little bit of time.
>
>The error was introduced between versions 1.315.2.1 and 1.315.2.2.
>
>If I comment out the line in question it builds (with crypt() support!) 
>and runs as ISAPI:
>
>PHP Version 4.0.5RC3
>
>System Windows NT 5.0 build 2195
>Build Date Mar 28 2001
>Server API ISAPI
>
>
>I'll bang on it more this evening and see if it breaks.
>
>- Matt
>
> >>> "Matt White" <[EMAIL PROTECTED]> 03/28/01 02:53PM >>>
>Bad news...
>
>Compile failure on Win32.
>
>Configuration: php4dllts - Win32 
>Release_TS_inline
>Compiling...
>.
>.
>.
>basic_functions.c
>V:\php-4.0.5RC3\ext\standard\basic_functions.c(2489) : error C2065: 
>'core_globals' : undeclared identifier
>V:\php-4.0.5RC3\ext\standard\basic_functions.c(2489) : error C2223: left 
>of '->safe_mode' must point to struct/union
>bcmath.c
>.
>.
>.
>Error executing cl.exe.
>
>php4isapi.dll - 2 error(s), 32 warning(s)
>
>
>I don't have time right now to dig into it, but I'll look later.
>
>- Matt
>
>
> >>> Zeev Suraski <[EMAIL PROTECTED]> 03/28/01 10:01AM >>>
>RC3 is out - http://www.php.net/distributions/php-4.0.5RC3.tar.gz
>
>Zeev
>
>
>--
>Zeev Suraski <[EMAIL PROTECTED]>
>CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>
>
>--
>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]
>
>
>
>--
>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]
>
>
>
>--
>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]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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]

[PHP-DEV] RC4

[Zeev Suraski]

RC4 was released with a fix to the ZTS build and some ming fix build.  It's 
pretty much the same as RC3.

Zeev


--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] Question about socket ext. file descriptors

[Zeev Suraski]

Note that the situation isn't as bad as you thought - it's not that it's 
not using the resource mechanism.  It is, if it wasn't, we'd be getting 
loads of complaints from people running out of descriptors very 
quickly.  It just uses old, PHP 3 style resources, of type 
IS_LONG.  They're still destroyed when the request ends, so it's all safe 
and all.  It simply doesn't use the PHP 4 style, of type IS_RESOURCE, which 
are actually destroyed when they're no longer needed.  It's a good idea to 
update this code, but it's not very dangerous the way it is now.

Lars - apparently you got it wrong;  The integers you are getting are *not* 
file descriptors.  They're resource handles, of type IS_LONG.  They might 
accidentally correspond to the file descriptors, but it'd be complete 
coincidence.  In short, regardless of whether we upgrade the file functions 
to use IS_RESOURCE resources or not, what they return cannot be relied upon 
as file descriptor numbers, simply because they're not.

I hope that clears it up...

Zeev

At 14:06 29/3/2001, Andi Gutmans wrote:
>Lars,
>
>I understand what you're saying but there is one important problem with 
>the current implementation which I think outweighs everything else. The 
>fact that right now you are likely to leak file descriptors. This is very 
>bad especially as Apache processes live for many requests. If the person 
>forgets to close the socket(), his program exits before it reaches that 
>code, or someone presses the STOP button on his browser PHP will leak file 
>descriptors. Very quickly the Apache process will have no file descriptors 
>left. This has to be fixed. I prefer seeing it fixed with resources but in 
>the least it should be fixed not to leak fd's even if you go with the 
>integer fix implementation. But it is not very PHP to do that. You already 
>have an fd resource as far as I know in ext/standard so you can use that.
>
>Andi
>
>At 02:02 AM 3/29/2001 -0800, Lars Torben Wilson wrote:
>>Andi Gutmans writes:
>> > Why do you need to rely on such behavior? Are you trying to do something
>> > naught? :)
>> > I think in general it's not a good idea to rely on the value and type of
>> > resources (even though this is an integer).
>> > I'm not quite sure why it returns integers and not resources. Looks like a
>> > bad thing to me as the extension can easily have file descriptor 
>> leaks. The
>> > socket should really be saved either in the resource list or in a socket
>> > extension local list in order to be able to cleanup at shutdown.
>> > I think in the meanwhile you should assume it might change to using 
>> resources.
>> >
>> > Andi
>>
>>That was what I had been thinking, until I started using
>>select(). Since select() needs to know the max fd # you're working
>>with, it's easy to have it as an int. Unless, of course, select()'s
>>PHP implementation is updated to automatically take this into
>>account. I could always parse the 'Resource #n' string, but that is
>>clumsy. There are other things as well, but this is the first one to
>>come to mind.
>>
>>I totally agree that in general it's a good idea to use resources and
>>leave the housekeeping to PHP, but in situations like this I wonder if
>>the usefulness of the int descriptor doesn't outweight the benefit of
>>turning it into a resource.
>>
>>Basically, I guess I'm approaching socket programming in PHP from a C
>>perspective, and thinking that others might as well. Having the
>>descriptors as ints does tend to relieve some aches, but it might be
>>more PHP-like to move that behind a resourse type and let PHP keep
>>track of the highest fd (for stuff like select()).
>>
>>I guess I also sorta think that when you start messing around with
>>stuff like fd_set() and select(), you expect to be given enough rope
>>to hang yourself with. :)
>>
>>I've no particular leaning to one side or the other, but I'd like to
>>know what people think about this.
>>
>>
>>Thanks again,
>>
>>Torben
>>
>> > At 10:56 PM 3/28/2001 -0800, Lars Torben Wilson wrote:
>> >
>> > >At present, the sockets extension uses integers as file descriptors
>> > >(e.g. socket() return value). At first I thought maybe they should
>> > >have been resources until I tried writing some socket code, when I
>> > >realized that it's easier under many circumstances for them to be
>> > >ints. Is this going to be behaviour that can be relied upon?
>> > >
>

Re: [PHP-DEV] Question about socket ext. file descriptors

[Zeev Suraski]

At 15:41 29/3/2001, Andi Gutmans wrote:
>At 03:35 PM 3/29/2001 +0200, Zeev Suraski wrote:
>>Note that the situation isn't as bad as you thought - it's not that it's 
>>not using the resource mechanism.  It is, if it wasn't, we'd be getting 
>>loads of complaints from people running out of descriptors very 
>>quickly.  It just uses old, PHP 3 style resources, of type 
>>IS_LONG.  They're still destroyed when the request ends, so it's all safe 
>>and all.  It simply doesn't use the PHP 4 style, of type IS_RESOURCE, 
>>which are actually destroyed when they're no longer needed.  It's a good 
>>idea to update this code, but it's not very dangerous the way it is now.
>
>I think you are wrong. Look at the function accept_connect(). You are 
>creating a new file descriptor and not saving it anywhere!

So this function may be an exception to the rule.  But generally, all of 
the file/socket functions use ZEND_REGISTER_RESOURCE() or 
zend_list_insert(), so they're fine.

Zeev


-- 
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] Question about socket ext. file descriptors

[Zeev Suraski]

ext/sockets does indeed appear to be broken;  It doesn't obey the standard 
PHP return value rules at all (errors are negative numbers instead of 
false, resource are passed back as-is instead of as resources).

I was actually looking at the other socket functions, fsockopen() and 
friends.  They're ok.

Zeev

At 15:52 29/3/2001, Andi Gutmans wrote:
>Well we were talking about the ext/socket extension and all functions 
>there which create file descriptors are leaking. It's not an exception. 
>Check open_listen_sock() and accept_connect().
>You were probably looking at the fd set functions which are just 
>emalloc()'ed memory. The happen to use resources but even if they hadn't 
>it would be a leak which the Zend memory manager would clean up. The file 
>descriptors is the real problem.
>
>Andi

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
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] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

Two reasons:
(1) It never behaved that way, and we're not in the language design phase, 
but almost 4.5 years after it got started.
(2) The Web being PHP's primary environment where system exit codes have no 
meaning at all, makes this argument useless in well over 90% (est) of the cases

If (1) wasn't true, we could consider it, and frankly, chances are it would 
have ended up behaving like its C counterpart.  However, because there's no 
overwhelming reason to change it other than a few people not liking a 
longer name for their relatively-rare usage, breaking compatibility makes 
no sense.

Zeev

At 17:57 19/12/2001, Jason Greene wrote:
>Zeev,
>
>Why don't we follow C/C++/Java/Perl/Python, and almost every other 
>language on this one, and make exit behave like exit should.
>
>-Jason
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Lars Torben Wilson" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>; "Vlad Krupin" <[EMAIL PROTECTED]>; "Jani Taskinen" 
><[EMAIL PROTECTED]>; "PHP Developers Mailing List"
><[EMAIL PROTECTED]>
>Sent: Wednesday, December 19, 2001 6:59 AM
>Subject: Re: [PHP-DEV] Question: Should exit() print out the integer 
>exit-status?
>
>
> > exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
> > should fit :)
> >
> >
> > At 14:49 19/12/2001, Lars Torben Wilson wrote:
> > >Zeev Suraski writes:
> > > > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
> > > > >Two ways to fix it then, either update the manual, or fix exit(). 
> I go for
> > > > >the last one then. Ppl who relied on the undocumented feature 
> then, did
> > > > >simply the wrong thing.
> > > >
> > > > Only the documentation was wrong to begin with!  A documentation bug
> > > should
> > > > not become a feature, especially when it never worked that way, so 
> anybody
> > > > who actually used this function saw that it was behaving differently.
> > > >
> > > > Zeev
> > >
> > >Well, from another point of view, both were wrong. :) The manual
> > >documented behaviour which didn't exist, so it was wrong. In another
> > >sense, the code behaved in a fashion which had a very high WTF factor,
> > >so it couild be called 'wrong' too.
> > >
> > >An easy way to set and check the exit status of a PHP script would
> > >make a lot of life a hell of a lot easier.
> > >
> > >
> > >--
> > >  Torben Wilson <[EMAIL PROTECTED]>
> > >  http://www.thebuttlesschaps.com
> > >  http://www.hybrid17.com
> > >  http://www.inflatableeye.com
> > >  +1.604.709.0506
> >
> >
> > --
> > 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]
> >


-- 
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] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

sys_exit()/system_exit() sound nice to me, definitely nicer than all of my 
suggestions :)

At 23:13 19/12/2001, Jason Greene wrote:
>Zeev,
>
>I understand argument 1, and that's why I like the idea of overloading 
>integer output. I still wonder
>if there is a web page out there that calls exit(integer)
>
>Argument 2 is good, because PHP is focused toward the web, which I 
>understand that it should be.
>However, I believe the language syntax and style can make a good general 
>purpose scripting language
>as well. Things like this can keep PHP from increasing beyond the 10% cmd 
>line usage.
>
>If adding an additional function is all that you will settle for, then I 
>would suggest
>we use sys_exit() or system_exit() that way we resemble some of the 
>languages out there.
>(Java - System.exit(), Python - Sys.exit())
>
>-Jason
>
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Jason Greene" <[EMAIL PROTECTED]>
>Cc: "Lars Torben Wilson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Vlad Krupin" 
><[EMAIL PROTECTED]>; "Jani Taskinen" <[EMAIL PROTECTED]>; "PHP
>Developers Mailing List" <[EMAIL PROTECTED]>
>Sent: Wednesday, December 19, 2001 2:26 PM
>Subject: Re: [PHP-DEV] Question: Should exit() print out the integer 
>exit-status?
>
>
> > Two reasons:
> > (1) It never behaved that way, and we're not in the language design phase,
> > but almost 4.5 years after it got started.
> > (2) The Web being PHP's primary environment where system exit codes have no
> > meaning at all, makes this argument useless in well over 90% (est) of 
> the cases
> >
> > If (1) wasn't true, we could consider it, and frankly, chances are it would
> > have ended up behaving like its C counterpart.  However, because there's no
> > overwhelming reason to change it other than a few people not liking a
> > longer name for their relatively-rare usage, breaking compatibility makes
> > no sense.
> >
> > Zeev
> >
> > At 17:57 19/12/2001, Jason Greene wrote:
> > >Zeev,
> > >
> > >Why don't we follow C/C++/Java/Perl/Python, and almost every other
> > >language on this one, and make exit behave like exit should.
> > >
> > >-Jason
> > >
> > >- Original Message -
> > >From: "Zeev Suraski" <[EMAIL PROTECTED]>
> > >To: "Lars Torben Wilson" <[EMAIL PROTECTED]>
> > >Cc: <[EMAIL PROTECTED]>; "Vlad Krupin" <[EMAIL PROTECTED]>; "Jani Taskinen"
> > ><[EMAIL PROTECTED]>; "PHP Developers Mailing List"
> > ><[EMAIL PROTECTED]>
> > >Sent: Wednesday, December 19, 2001 6:59 AM
> > >Subject: Re: [PHP-DEV] Question: Should exit() print out the integer
> > >exit-status?
> > >
> > >
> > > > exit_with_status(), silent_exit(), quiet_exit(), etc. etc.  Something
> > > > should fit :)
> > > >
> > > >
> > > > At 14:49 19/12/2001, Lars Torben Wilson wrote:
> > > > >Zeev Suraski writes:
> > > > > > At 14:04 19/12/2001, [EMAIL PROTECTED] wrote:
> > > > > > >Two ways to fix it then, either update the manual, or fix exit().
> > > I go for
> > > > > > >the last one then. Ppl who relied on the undocumented feature
> > > then, did
> > > > > > >simply the wrong thing.
> > > > > >
> > > > > > Only the documentation was wrong to begin with!  A 
> documentation bug
> > > > > should
> > > > > > not become a feature, especially when it never worked that way, so
> > > anybody
> > > > > > who actually used this function saw that it was behaving 
> differently.
> > > > > >
> > > > > > Zeev
> > > > >
> > > > >Well, from another point of view, both were wrong. :) The manual
> > > > >documented behaviour which didn't exist, so it was wrong. In another
> > > > >sense, the code behaved in a fashion which had a very high WTF factor,
> > > > >so it couild be called 'wrong' too.
> > > > >
> > > > >An easy way to set and check the exit status of a PHP script would
> > > > >make a lot of life a hell of a lot easier.
> > > > >
> > > > >
> > > > >--
> > > > >  Torben Wilson <[EMAIL PROTECTED]>
> > > > >  http://www.thebuttlesschaps.com
> > > > >  http://www.hybrid17.com
> > > > >  http://www.inflatableeye.com
> > > > >  +1.604.709.0506
> > > >
> > > >
> > > > --
> > > > 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]
> > > >
> >
> >
> > --
> > 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]
> >


-- 
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] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

At 15:18 20/12/2001, Yasuo Ohgaki wrote:
>Nobody should complain about BC changes if changes are notified
>early enough and there is alternative way to do the same thing.
>IMHO. (This has been done for some features such as track vars ;)

That's a very impractical statement in my opinion...  Breaking 
compatibility hurts (almost) regardless of when you announce you're going 
to break it.  Users would still have to go over their code and fix it.

What I *really* fail to understand is the gain we get by modifying exit()'s 
behavior, as opposed to adding a new function or adding a new $silent 
argument.  Giving a WFF to several people?  Consistency with other 
languages that have nothing to do with the Web environment (which is why we 
got so little complaints about this over *5* years)?

I see this as very similar to the case sensitivity issue, even though this 
is obviously on a much smaller scale.  It's possibly a bad decision that 
was made 5 years ago, but it was made all the same.  Since it does *not* 
have far-reaching negative implications, it shouldn't be changed.

Zeev


-- 
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] Question: Should exit() print out the integer exit-status?

[Zeev Suraski]

This patch is fine with me, but as it would still print out the error 
message, I think it's not fine with some other people...

At 16:29 20/12/2001, Lars Torben Wilson wrote:
>Zeev Suraski writes:
> > At 15:18 20/12/2001, Yasuo Ohgaki wrote:
> > >Nobody should complain about BC changes if changes are notified
> > >early enough and there is alternative way to do the same thing.
> > >IMHO. (This has been done for some features such as track vars ;)
> >
> > That's a very impractical statement in my opinion...  Breaking
> > compatibility hurts (almost) regardless of when you announce you're going
> > to break it.  Users would still have to go over their code and fix it.
> >
> > What I *really* fail to understand is the gain we get by modifying 
> exit()'s
> > behavior, as opposed to adding a new function or adding a new $silent
> > argument.  Giving a WFF to several people?  Consistency with other
> > languages that have nothing to do with the Web environment (which is 
> why we
> > got so little complaints about this over *5* years)?
>
>What would the problem be with the attached patch (against PHP
>4.1.0rc3)? This patch meets the following criteria:
>
>  o Backward compatibility is maintained, since strings passed to
>exit() will still be output. BC will only break in those instances
>where something depends on the fact that PHP will not set the exit
>code when exiting with a string--very unlikely. This should keep
>the BC people happy and not introduce any new surprises.
>  o No new functions need to be created, and no new arguments need to
>be added to exit(). This should keep the No New Functions or
>Arguments For Small Functionalities people happy.
>  o exit() will now behave like other PHP functions wrt its argument
>type. Whereas a PHP programmer expects the calls
>somefunc('2') and somefunc(2) to behave identically, exit() breaks
>this mould. This patch rectifies that, so that exit('2') and
>exit(2) will now behave the same. Again, the only time BC is broken
>is in cases where something depends on i.e. exit('2') outputting
>'0'--which is likely to be *very* rare since it doesn't make any
>sense.
>
>Of course, the criterium which this patch does not fulfil is that of
>killing the output from exit(), which would break BC. However, it
>would still be possible to add an option second argument to exit()
>which would suppress this output, but be off by default.
>
> > I see this as very similar to the case sensitivity issue, even though this
> > is obviously on a much smaller scale.  It's possibly a bad decision that
> > was made 5 years ago, but it was made all the same.  Since it does *not*
> > have far-reaching negative implications, it shouldn't be changed.
> >
> > Zeev
>
>The current behaviour may not be earthshatteringly bad, but it does
>break language consistency and so introduces a higher memory load on
>the user (gotta remember that everything works the same 'cept
>exit()). It also tends to keep some people (OK, at least me) from
>doing much non-web scripting in PHP since it's a fairly fundamental
>bit of functionality which is something of a bother to work
>around. Not a major bother, but enough.
>
>My point is this: we don't break, lose, or complicate anything with
>this patch, and it makes the language more consistent and generally
>usable.
>
>Just my $0.02 for the night.
>
>
>Torben
>
>--- zend_execute.bakWed Dec 19 16:19:44 2001
>+++ zend_execute.c  Wed Dec 19 16:37:29 2001
>@@ -2379,11 +2379,16 @@
> case ZEND_EXIT:
> if (opline->op1.op_type != IS_UNUSED) {
> zval *ptr;
>+   zval exit_code;
>
> ptr = get_zval_ptr(&opline->op1, 
> Ts, &EG(free_op1), BP_VAR_R);
>-   if (Z_TYPE_P(ptr) == IS_LONG) {
>-   EG(exit_status) = 
>Z_LVAL_P(ptr);
>-   }
>+
>+   exit_code = *ptr;
>+   zval_copy_ctor(&exit_code);
>+   convert_to_long(&exit_code);
>+
>+   EG(exit_status) = 
>Z_LVAL_P(&exit_code);
>+
> zend_print_variable(ptr);
> FREE_OP(&opline->op1, EG(free_op1));
> }
>
>
>
>--
>  Torben Wilson <[EMAIL PROTECTED]>
>  http://www.thebuttlesschaps.com
>  http://www.hybrid17.com
>  http://www.inflatableeye.com
>  +1.604.709.0506


-- 
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] Bug #14538 Updated: dirname fix broke behaviourthat it had since PHP 3

[Zeev Suraski]

At 03:43 16/12/2001, Manuel Lemos wrote:
>So, there why keep giving more reasons to not upgrade?

Because sometimes it's necessary.  The way dirname() behaved was buggy and 
unintended - it simply did not do what it was supposed to do.  Perhaps 
taking it to the extreme - it's kind of like pow(2,2) returning 4.01 
instead of 4.  If such a bug existed in pow() and we fixed it, we wouldn't 
have added an ini switch to turn it on/off.

register_globals is completely different.  register_globals is a concept 
which turned out to be very problematic, but people who bought into it 
should be allowed to go on using it.  We also have to be a bit realistic 
every now and then, and realize that the vast majority of PHP code today, 
and we're talking dozens of millions of lines of code, relies on 
register_globals being on.  That's not true for dirname().  It doesn't mean 
that BC breaks that only affect a small number of people should be taken 
lightly - but obviously, this plays a significant role.

>Admit it, you were not aware and not even documented the change that
>Andi made to the behaviour of a function that worked like that for 3
>years.



>Sure but they way it seems to me is that reporting the problem did not
>make any difference. So why bother reporting?

It's your decision.  Don't expect the dev-team to treat anything you put in 
the bugs database as the 11th commandment.  The dirname() example is 
relatively unique, because the new behavior is not a problem, but a fixed 
behavior which causes incompatibility.

>I am afraid that a lot of people simply do not bother to report
>problems, even when it affects their businesses, because they just get
>this kind of response and they certainly can use the time they spend
>making a useful report in things that can really result in something
>that the need.

Don't worry so much.  You're the first person to bring up this point in 5 
years :)

Zeev


-- 
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] Bug in 4.1.0; _SESSION

[Zeev Suraski]

Can you provide a full code snippet that hangs?  This code snippet doesn't 
appear to hang, are you running it in a function context?

Zeev

At 14:59 21/12/2001, Andreas Aderhold wrote:
>Hi All,
>
>found a bug
>
>this one will cause a infinte loop in 4.1:
>global $_SESSION; // this will cause a infinite loop
>session_start();
>phpinfo()
>?>
>Te docs say that $_SESSION is auto-global in 4.1.0 but it does not say, that
>the explicit global declaration is not allowed. However I would like to use
>the explicit global declaration for improved code readbility.
>
>Andi
>
>--
>www.binarycloud.com
>
>
>
>
>--
>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]


-- 
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] SAPI Module Leaking

[Zeev Suraski]

Are you calling request_shutdown?
Also, are you sure it's actually leaking?  Does it leak 200-400KB on each 
and every request, or does this rate 'slow down' at some point?

Zeev

At 18:20 21/12/2001, Alex Leigh wrote:
>All -
>
>I have written a SAPI module for a new webserver "continuity". The code is
>basically the SAPI code for NSAPI, modified to work with continuity's API.
>Continuity is threaded, based on the pthread libraries.
>
>My problem is that each requests that is handled by PHP leaks about
>200-400KB. I've gone over the code carefully, and I don't see that I am
>doing (or more importantly, not doing) anything differently than any of the
>other SAPI modules.
>
>I have tried php4-4.1.0, as well as the 12/17 cvs snapshot, on both Linux
>and Solaris. I did not configure php with any options other than that to
>include my sapi module "--with-capi".
>
>If someone could give me a reference to SAPI documentation (none of which I
>could find), or give me a lead on what my problem might be, I'd appreciate
>it.
>
>My SAPI code can be had at
>http://www.ashpool.com/dist/php4-capi-v200-p1.tar.gz
>
>--
>Alex Leigh - www.tessier.com - [EMAIL PROTECTED]
>The difference between theory and reality is that
>in theory there is no difference.
>
>
>--
>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]


-- 
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] SAPI Module Leaking

[Zeev Suraski]

The way TSRM is written is not designed for servers that don't reuse 
threads for more than one request, so if that's how it works - you're going 
to see a growing memory image all the time :I

At 22:16 21/12/2001, Alex Leigh wrote:
>Ok. I looked at the ISAPI code, and I am now calling ts_thread_free() when
>the handler exits. This seems to have cleared up the problem immensely, but
>it's still leaking to the tune of ~1k per request. I'll go over my SAPI
>module again to verify that is not the cause of the 1k leak.
>
>Also with php4-20011217120 randomly (13 times in 5000 requests), the page
>(1k test data with no php script commands) fails to serve. Php writes:
>
>Unknown(0) : Warning - Failed opening
>'/web02/content/_default/_default/k1.php' for inclusion
>(include_path='.:/usr/local/lib/php')
>
>To stdout
>
>Alex
>
>On 12/21/01 12:52 PM, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
>
> > Check out DllMain() in php4isapi.c.
> > Are you running the thread attach and thread detach code?
> >
> > Andi
> >
> > At 12:43 PM 12/21/2001 -0600, Alex Leigh wrote:
> >> It can do both. In the testing configuration, it is not pooling but
> >> destroying the threads. They are created as detached threads, which at 
> least
> >> on Solaris go away after they terminate; the ones that exit aren't 
> building
> >> up in the process (I verified this with pstack). I am not specifying an
> >> explicit cleanup handler for the threads, if that makes any 
> difference; they
> >> are exiting normally by returning off the function called in
> >> pthread_create().
> >>
> >>> Does this web server spawn a new thread for each request? Or does it 
> reuse
> >>> its threads?
> >>>
> >>> Andi
> >>>
> >>> At 12:22 PM 12/21/2001 -0600, Alex Leigh wrote:
> >>>> I'm sure it's leaking, it'll readily consume a gig of memory and 
> shows no
> >>>> signs of slowing down. I originally was calling phpinfo(), but it also
> >> leaks
> >>>> equally if I just have the php handler serve a page with no php in it.
> >>>>
> >>>> So, yes, it leaks that amount every request and it never frees.
> >>>>
> >>>> The code as I mentioned is a copy of the NSAPI module (nearly 
> identical),
> >>>> and it basically does:
> >>>>
> >>>>if (php_request_startup(TSRMLS_C) == FAILURE) {
> >>>>   return FAILURE;
> >>>>}
> >>>>
> >>>> ...
> >>>>
> >>>>  php_execute_script(&file_handle TSRMLS_CC);
> >>>>  php_request_shutdown(NULL);
> >>>>
> >>>> Alex
> >>>>
> >>>> On 12/21/01 10:28 AM, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> Are you calling request_shutdown?
> >>>>> Also, are you sure it's actually leaking?  Does it leak 200-400KB 
> on each
> >>>>> and every request, or does this rate 'slow down' at some point?
> >>>>>
> >>>>> Zeev
> >>>>>
> >>>>> At 18:20 21/12/2001, Alex Leigh wrote:
> >>>>>> All -
> >>>>>>
> >>>>>> I have written a SAPI module for a new webserver "continuity". The
> >> code is
> >>>>>> basically the SAPI code for NSAPI, modified to work with
> >> continuity's API.
> >>>>>> Continuity is threaded, based on the pthread libraries.
> >>>>>>
> >>>>>> My problem is that each requests that is handled by PHP leaks about
> >>>>>> 200-400KB. I've gone over the code carefully, and I don't see that 
> I am
> >>>>>> doing (or more importantly, not doing) anything differently than any
> >>>> of the
> >>>>>> other SAPI modules.
> >>>>>>
> >>>>>> I have tried php4-4.1.0, as well as the 12/17 cvs snapshot, on both
> >> Linux
> >>>>>> and Solaris. I did not configure php with any options other than 
> that to
> >>>>>> include my sapi module "--with-capi".
> >>>>>>
> >>>>>> If someone could give me a reference to SAPI documentation (none of
> >>>> which I
> >>>>>> could find)

Re: [PHP-DEV] SAPI Module Leaking

[Zeev Suraski]

Well, it is pretty complicated to fix, even though it's been a very long 
while since I touched this code so I may be wrong.  As far as I recall, the 
TSRM hash tables won't reuse entries that were freed by threads that 
terminated.  Fixing this, especially without hurting performance, may be 
quite complicated.

That said - I'm not sure it accounts for 1KB per request.  There could be 
leaks in other places.

At 23:38 21/12/2001, Alex Leigh wrote:
>Well, at this point it is only leaking 1k per request; that doesn't "sound"
>overly complicated to fix. Do you have an idea of what particularly TSRM is
>leaking, after ts_thread_free() is called? I'd be happy to poke around the
>code.
>
>Alex
>
>On 12/21/01 2:38 PM, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
>
> > The way TSRM is written is not designed for servers that don't reuse
> > threads for more than one request, so if that's how it works - you're going
> > to see a growing memory image all the time :I
> >
> > At 22:16 21/12/2001, Alex Leigh wrote:
> >> Ok. I looked at the ISAPI code, and I am now calling ts_thread_free() when
> >> the handler exits. This seems to have cleared up the problem 
> immensely, but
> >> it's still leaking to the tune of ~1k per request. I'll go over my SAPI
> >> module again to verify that is not the cause of the 1k leak.
> >>
> >> Also with php4-20011217120 randomly (13 times in 5000 requests), the page
> >> (1k test data with no php script commands) fails to serve. Php writes:
> >>
> >> Unknown(0) : Warning - Failed opening
> >> '/web02/content/_default/_default/k1.php' for inclusion
> >> (include_path='.:/usr/local/lib/php')
> >>
> >> To stdout
> >>
> >> Alex
> >>
> >> On 12/21/01 12:52 PM, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> >>
> >>> Check out DllMain() in php4isapi.c.
> >>> Are you running the thread attach and thread detach code?
> >>>
> >>> Andi
> >>>
> >>> At 12:43 PM 12/21/2001 -0600, Alex Leigh wrote:
> >>>> It can do both. In the testing configuration, it is not pooling but
> >>>> destroying the threads. They are created as detached threads, which at
> >> least
> >>>> on Solaris go away after they terminate; the ones that exit aren't
> >> building
> >>>> up in the process (I verified this with pstack). I am not specifying an
> >>>> explicit cleanup handler for the threads, if that makes any
> >> difference; they
> >>>> are exiting normally by returning off the function called in
> >>>> pthread_create().
> >>>>
> >>>>> Does this web server spawn a new thread for each request? Or does it
> >> reuse
> >>>>> its threads?
> >>>>>
> >>>>> Andi
> >>>>>
> >>>>> At 12:22 PM 12/21/2001 -0600, Alex Leigh wrote:
> >>>>>> I'm sure it's leaking, it'll readily consume a gig of memory and
> >> shows no
> >>>>>> signs of slowing down. I originally was calling phpinfo(), but it also
> >>>> leaks
> >>>>>> equally if I just have the php handler serve a page with no php in it.
> >>>>>>
> >>>>>> So, yes, it leaks that amount every request and it never frees.
> >>>>>>
> >>>>>> The code as I mentioned is a copy of the NSAPI module (nearly
> >> identical),
> >>>>>> and it basically does:
> >>>>>>
> >>>>>>if (php_request_startup(TSRMLS_C) == FAILURE) {
> >>>>>>   return FAILURE;
> >>>>>>}
> >>>>>>
> >>>>>> ...
> >>>>>>
> >>>>>>  php_execute_script(&file_handle TSRMLS_CC);
> >>>>>>  php_request_shutdown(NULL);
> >>>>>>
> >>>>>> Alex
> >>>>>>
> >>>>>> On 12/21/01 10:28 AM, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> >>>>>>
> >>>>>>> Are you calling request_shutdown?
> >>>>>>> Also, are you sure it's actually leaking?  Does it leak 200-400KB
> >> on each
> >>>>>>> and every request, or does this rate 'slow down' at some point?
> >&g

Re: [PHP-DEV] SAPI Module Leaking

[Zeev Suraski]

At 00:31 22/12/2001, Alex Leigh wrote:
>It sounds like there was a particular reason for writing it this way ?

Could be, I don't really remember.  There was a basic assumption (which is 
typically true, it's the first time I see it isn't) that threaded servers 
reuse their threads, because it's extremely inefficient not to.

>I am considering what effect it will have on me if I simply require that
>people use thread pooling, and I'm going to do some tests to see whether
>there's still a leak condition or if it stabilizes when I reuse them.

Testing this first is a good idea. It may not be related at all :)


-- 
PHP Development Mailing List 
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] Zend Products for 4.1.x

[Zeev Suraski]

That belongs on a Zend forum, php-dev isn't affiliated with Zend...

Zeev

At 00:00 24/12/2001, Andrew Sitnikov wrote:
>Hello php-dev,
>
>   When it is possible to expect occurrence of products Zend (Debuger, 
> Accelerator) for 4.1.x
>
>Best regards,
>  Andrew Sitnikov
>  e-mail : [EMAIL PROTECTED]
>  GSM: (+372) 56491109
>
>
>--
>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]


-- 
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

[Zeev Suraski]

Could you specify which $n you were using, and also provide the equivalent
Perl script that you used?

Zeev

On Sat, 29 Dec 2001, August Zajonc wrote:

> > This is not really surprising, and the test is not really fair, the
> > PHP code is not written by an experienced php programmer, and thus,
> > would naturally be slower, on person benchmarks like this are simply
> > too dependent on the person writing the code.
> > -Sterling
> 
> Give me a break.
> 
> Did you even check a SINGLE one of the routines? Since you ARE an
> experienced php programmer I'm attaching the nested loop test where PHP
> scored at the BOTTOM of all 30 languages for you to optimize. I mean, I
> looked over a number of the snippets and they are very straightforward,
> especially the "same way" tests.
> 
> This type of knee-jerk (and spectacularly uninformed) discounting of results
> gets us nowhere and as you can probably tell irritates me no end :). There
> are too many folks too quick to sound authoratative on an issue. Read
> through the site, Doug is aware of the problems in benchmarking (everyone
> who has ever tried doing them is probably aware) and worked hard to overcome
> many of them.
> 
> Anyways, the challenge is down, here's the code, optimize away. Then we can
> talk about the real causes for PHP slow performance :) They still may be as
> trivial as bad compile time or config settings but I think this bad php
> programmer thing is a red herring.
> 
> - August
> 
>   $Id: nestedloop.php,v 1.1 2001/05/06 06:13:21 doug Exp $
>  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++)
>  for ($d=0; $d<$n; $d++)
>   for ($e=0; $e<$n; $e++)
>   for ($f=0; $f<$n; $f++)
>$x++;
> print "$x\n";
> ?>
> Perl took 18 CPU secs, PHP 85.
> 
> 
> 
> 

-- 
Zeev Suraski <[EMAIL PROTECTED]>
http://www.zend.com/


-- 
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

[Zeev Suraski]

For that particular case, btw, you should try adding in the Zend
Optimizer.  For this type of somewhat braindead code (no insult intended, 
it's just not very real-world), it would give you a very serious
performance boost.

Zeev

On Sat, 29 Dec 2001, August Zajonc wrote:

> > This is not really surprising, and the test is not really fair, the
> > PHP code is not written by an experienced php programmer, and thus,
> > would naturally be slower, on person benchmarks like this are simply
> > too dependent on the person writing the code.
> > -Sterling
> 
> Give me a break.
> 
> Did you even check a SINGLE one of the routines? Since you ARE an
> experienced php programmer I'm attaching the nested loop test where PHP
> scored at the BOTTOM of all 30 languages for you to optimize. I mean, I
> looked over a number of the snippets and they are very straightforward,
> especially the "same way" tests.
> 
> This type of knee-jerk (and spectacularly uninformed) discounting of results
> gets us nowhere and as you can probably tell irritates me no end :). There
> are too many folks too quick to sound authoratative on an issue. Read
> through the site, Doug is aware of the problems in benchmarking (everyone
> who has ever tried doing them is probably aware) and worked hard to overcome
> many of them.
> 
> Anyways, the challenge is down, here's the code, optimize away. Then we can
> talk about the real causes for PHP slow performance :) They still may be as
> trivial as bad compile time or config settings but I think this bad php
> programmer thing is a red herring.
> 
> - August
> 
>   $Id: nestedloop.php,v 1.1 2001/05/06 06:13:21 doug Exp $
>  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++)
>  for ($d=0; $d<$n; $d++)
>   for ($e=0; $e<$n; $e++)
>   for ($f=0; $f<$n; $f++)
>$x++;
> print "$x\n";
> ?>
> Perl took 18 CPU secs, PHP 85.
> 
> 
> 
> 

-- 
Zeev Suraski <[EMAIL PROTECTED]>
http://www.zend.com/


-- 
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

[Zeev Suraski]

Taking that code and coupling the Zend Optimizer, PHP and Perl were
approximately the same speed (Perl was 8% faster, but that probably varies
across platforms).

W/o the optimizer PHP was 2 times slower, but again, that's only because
this is not a very real-world piece of code, at least for our space
(scripting languages).

Zeev

On Sat, 29 Dec 2001, August Zajonc wrote:

> 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/30 21:42:57 doug Exp $
> # http://www.bagley.org/~doug/shootout/
> 
> use strict;
> 
> my $n = ($ARGV[0] > 0) ? $ARGV[0] : 1;
> my $x = 0;
> my $a = $n;
> while ($a--) {
> my $b = $n;
> while ($b--) {
>   my $c = $n;
>   while ($c--) {
>   my $d = $n;
>   while ($d--) {
>   my $e = $n;
>   while ($e--) {
>   my $f = $n;
>   while ($f--) {
>   $x++;
>   }
>   }
>   }
>   }
> }
> }
> print "$x\n";
> 
> 

-- 
Zeev Suraski <[EMAIL PROTECTED]>
http://www.zend.com/


-- 
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

[Zeev Suraski]

At 00:11 30/12/2001, August Zajonc wrote:
>Does the Zend Cache or APC Cache do things I wasn't aware of? Did you run
>these examples under these caches and see PHP start smoking? Sterling,
>generally these products just cache the result of an intermediate
>compilation step, they do not speed up the actual calls.

If you use caching software, chances are PHP will be faster than Perl even 
without the optimizer.  And it does that without any hassle or special 
planning, unlike Perl for that matter.  If you use the optimizer - it gets 
as quick as Perl, and that's without caching.  Couple the two together - 
and you have a serious performance screamer.  That said, in most real world 
situations, PHP will be faster than Perl even w/o these two.  I don't agree 
that Web apps are just made of small snippets like this.  In Web apps - 
database performance, output handling and caching play a big role, which 
these code snippets don't measure.

FWIW, I agree with you that 'code in C if you need performance' is quite a 
pointless statement, except for very specialized cases.  One of the main 
points in using PHP is *not* using C, because of dev-time, maintenance, 
reliability, etc. etc.

Zeev


-- 
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

[Zeev Suraski]

At 04:07 30/12/2001, August Zajonc wrote:
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
> > If you use caching software, chances are PHP will be faster than Perl even
> > without the optimizer.
>
>Interestingly, Perl is getting bytecode caching soon, RFC 301 I think.
>Probably about time.

That RFC is from over a year ago, what makes you think it's going to happen 
soon..?  It still remains to be seen if they do it in a nice, clean 
transparent way, or the Perl way :)  Anyway, the other problems plaguing 
Perl still apply (having to worry about resources&memory).

>What gets people riled up about these benchmarks is they see them as a whole
>picture slam against their 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.

Well, I think that benchmarking PHP like that out of any context is *bound* 
to result in many people getting the wrong ideas.  So, a big disclaimer 
reading "This may not necessarily have any real world meaning" was due.

Zeev


-- 
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

[Zeev Suraski]

I have to say that taking a look at his site again - he does have 
disclaimers.  Even though none is as strong as 'This may have nothing to do 
with reality', it's not that bad...

At 01:49 30/12/2001, Mike Robinson wrote:
>Zeev Suraski writes:
>
> > Well, I think that benchmarking PHP like that out of any context
> > is *bound* to result in many people getting the wrong ideas.  So, a big
>disclaimer
> > reading "This may not necessarily have any real world meaning" was due.
>
>You betcha, wrong ideas
>I was about to activate the Omega-13.  ;)
>
>Regards
>Mike Robinson


-- 
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] Bug #14729 Updated: after phpinfo() is called, web page is still running...

[Zeev Suraski]

Upgrade to PHP 4.1.1.  It should solve the problem.

Zeev

At 18:50 28/12/2001, [EMAIL PROTECTED] wrote:
>ID: 14729
>User updated by: [EMAIL PROTECTED]
>Reported By: [EMAIL PROTECTED]
>Status: Bogus
>Bug Type: IIS related
>Operating System: Windows XP
>PHP Version: 4.1.0
>New Comment:
>
>I'm sorry, this is not a DNS issue. when I mentioned I setup to Windows XP 
>systems, I also used on on MY network at the office, and I can assure you, 
>my office PC has no DNS issues. I even set everything to the "legit" 
>address on my IIS: "beaktest.beak.com".
>
>Previous Comments:
>
>
>[2001-12-28 11:22:21] [EMAIL PROTECTED]
>
>Probably a netwrok/dns problem.
>Ask support questions on [EMAIL PROTECTED]
>
>
>
>[2001-12-27 23:13:49] [EMAIL PROTECTED]
>
>mysql, php 4.1.0, IIS 5.1
>I have installed php as ISAPI. with the php .dll's in c:\windows\system32 
>dir. when I create a simple html with phpinfo() in it, I get all the info 
>back, but down at the bottom, I can see "Opening page index.php at 
>localhost.." for approx 5 minutes, and then the page returns with a DNS.
>
>I call the page with "http://localhost/test/index.php";
>
>I tested this same situation on another Windows XP machine: copied the 
>php.ini file, and get the same "hanging"...
>
>I don't want to try and run apache, I need IIS 5 to work.
>
>html file:
>
>
>
>
>---   php.ini:  ---
>
>
>[PHP]
>
>; Language Options ;
>
>
>; Enable the PHP scripting language engine under Apache.
>engine = On
>
>; Allow the  tags are recognized.
>short_open_tag = On
>
>; Allow ASP-style <% %> tags.
>asp_tags = Off
>
>; The number of significant digits displayed in floating point numbers.
>precision=  14
>
>; Enforce year 2000 compliance (will cause problems with non-compliant 
>browsers)
>y2k_compliance = Off
>
>; Output buffering allows you to send header lines (including cookies) even
>; after you send body content, at the price of slowing PHP's output layer a
>; bit.  You can enable output buffering during runtime by calling the output
>; buffering functions.  You can also enable output buffering for all files by
>; setting this directive to On.
>output_buffering = Off
>
>; You can redirect all of the output of your scripts to a function.  For
>; example, if you set output_handler to "ob_gzhandler", output will be
>; transparently compressed for browsers that support gzip or deflate encoding.
>; Setting an output handler automatically turns on output buffering.
>;output_handler =
>
>; Transparent output compression using the zlib library
>; Valid values for this option are 'off', 'on', or a specific buffer size
>; to be used for compression (default is 4KB)
>zlib.output_compression = Off
>
>; Implicit flush tells PHP to tell the output layer to flush itself
>; automatically after every output block.  This is equivalent to calling the
>; PHP function flush() after each and every call to print() or echo() and each
>; and every HTML block.  Turning this option on has serious performance
>; implications and is generally recommended for debugging purposes only.
>implicit_flush = Off
>
>; Whether to enable the ability to force arguments to be passed by reference
>; at function call time.  This method is deprecated and is likely to be
>; unsupported in future versions of PHP/Zend.  The encouraged method of
>; specifying which arguments should be passed by reference is in the function
>; declaration.  You're encouraged to try and turn this option Off and make
>; sure your scripts work properly with it in order to ensure they will work
>; with future versions of the language (you will receive a warning each time
>; you use this feature, and the argument will be passed by value instead of by
>; reference).
>allow_call_time_pass_reference = On
>
>
>;
>; Safe Mode
>;
>safe_mode = Off
>
>safe_mode_exec_dir =
>
>; Setting certain environment variables may be a potential security breach.
>; This directive contains a comma-delimited list of prefixes.  In Safe Mode,
>; the user may only alter environment variables whose names begin with the
>; prefixes supplied here.  By default, users will only be able to set
>; environment variables that begin with PHP_ (e.g. PHP_FOO=BAR).
>;
>; Note:  If this directive is empty, PHP will let the user modify ANY
>; environment variable!
>safe_mode_allowed_env_vars = P

Re: [PHP-DEV] MOPS Benchmark

[Zeev Suraski]

I wouldn't pay too much attention to anything in version 0.0.3.  The Zend 
engine was quicker than Perl at this kind of stuff during initial stages of 
development, but as more features and functionality are added, it became 
slower.

That said - if you're using PHP because of performance, you're choosing the 
wrong language.  For instance, I can pretty much assure you that 
Microsoft's CLR is going to be quicker, because it'll be almost in the same 
speed of native code.  The thing about PHP is everything it gives you, and 
the ease of using everything it gives you, while still being quite 
quick.  It's not supposed to be the quickest.

Zeev

At 15:38 01/01/2002, Sebastian Bergmann wrote:
>Sebastian Bergmann wrote:
> >   Updated table:
> >
> > Language  | Elapsed time | MOPS
> > --+--+--
>   Parrot 0.0.3  |   7 seconds  | 26.99
> > Python|  88 seconds  |  2.27
> > Perl  | 102 seconds  |  1.96
> > Ruby  | 124 seconds  |  1.59
> > PHP (+ ZendOptimizer) | 142 seconds  |  1.41
> > PHP   | 158 seconds  |  1.27
> > PHP (Zend Engine 2)   | 177 seconds  |  1.13
>
>   Now I am depressed,
>Sebastian
>
>--
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
>
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
>
>--
>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]


-- 
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] Built-in SOAP based Web Services support (was Re: PHP 5)

[Zeev Suraski]

At 22:24 01/01/2002, Manuel Lemos wrote:
>One thing that I think it is really vital to prevent PHP to leak even
>more users to other languages is to have built-in support for consuming
>Web services.

Manuel,

A friendly suggestion - you always sound as if the house is burning, the 
ceiling is collapsing , and soon enough all will be lost, unless a miracle 
happens.  While this may be true in your opinion, I can tell you that it 
doesn't have a very positive effect on the way your words are accepted by 
the users of this, or any other pro-PHP mailing list.  "If that's the 
truth, we don't want to hear it" sums it up pretty well, especially when 
most people here believe it's not the truth.

About SOAP and Web services - I agree with you that it would be very good 
to have built-in support for it in PHP.  However, suggesting this kind of 
ideas is usually pretty pointless, unless you're willing to actually do 
something about it.  I think the only time it worked in the past was when 
Sascha picked up the challenge of creating a session module for PHP, 
because PHP really needed one (kodus to Sascha on that) - but that's the 
exception to the rule.

I think Rasmus was looking into that a couple of months ago, btw.

Zeev


-- 
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] Built-in SOAP based Web Services support (was Re: PHP 5)

[Zeev Suraski]

At 23:30 01/01/2002, Richard Heyes wrote:
> > However, suggesting this kind of
> > ideas is usually pretty pointless, unless you're willing to actually do
> > something about it.
>
>Well Andi asked for discussion on ideas for php5. And these suggestions imo
>are not pointless, as a developer may well pick up on them and start work on
>them.

It wasn't exactly a suggestion.  It was more like "unless you do it, PHP is 
going to be a useless piece of crap that nobody would use;  if you do it - 
it's still pretty hopeless, but just a tiny bit less".

Zeev


-- 
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] Built-in SOAP based Web Services support (wasRe: PHP 5)

[Zeev Suraski]

At 00:34 02/01/2002, Manuel Lemos wrote:
>What you are saying is that when I make a suggestion people become
>emotional and work very hard to raise as much objections as they can
>instead of staying rational and try to see the benefits of the
>suggestion.

It's about how you make the suggestions, Manuel.  "vital to prevent PHP to 
leak even
more users to other languages" is a pretty annoying sentence to read.  In 
case you're not sure what it means - it means that:
(a) PHP is 'leaking' lots of users today
(b) If we do it, it'll go on leaking as it does today
(c) If we don't - it'll leak even more

If people indeed become emotional about suggestions you make (I certainly 
don't) then you probably have earned it yourself.

At any rate - I did not contradict you.  On the contrary, I said I think 
it's important, even very important.  I'm saying that the position you 
usually take, which is kind-of like the biblical prophets telling everybody 
they're wrong and what they must do to prevent hell from breaking loose, 
isn't one that's going to earn you much interest in your ideas.  You may 
try the positive approach instead, especially if you're just pitching an 
idea for somebody else to implement, with no intention of doing anything 
about it yourself.

You think that my behavior is so predictable, you didn't even appear to 
read what I said.  If it wasn't too transparent I'd be saying that it was 
your response which was quite predictable - you always do that when people 
don't cry in joy in the sound of your ideas...

Zeev


-- 
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] Built-in SOAP based Web Services support (wasRe:PHP 5)

[Zeev Suraski]

At 05:28 02/01/2002, Manuel Lemos wrote:
> > (b) If we do it, it'll go on leaking as it does today
>
>False, if you do it you will give one less reason for users to drop PHP.

That sentence MEANS that though.  Maybe you weren't sure of what you were 
saying, but saying "We have to do X in order to prevent even more users 
from leaking" means that even if we do X, users will go on leaking as they 
do now, and if we don't do X, they'll leak more.

Again, I wasn't expecting you to answer me point by point on this and tell 
me if you think it's right or not.  As I said - "if it's the truth - we 
don't want to hear it" - especially when people here don't think it's the 
truth. Think positive.

>You are still not getting it, I don't have a problem when people do not
>accept my ideais. My problem only happens when arises when people invent
>forced excuses for not accepting my ideas or at least to not put them in
>practice.

What excuses did I make up?  What excuses did I even mention?
I said that the preachy way in which you presented your idea is not going 
to get you anywhere, let alone PHP.  You may have encouraged someone to 
write a CORBA extension, and you definitely pissed off lots of other 
developers.  Is that good?  Did it get you or PHP anywhere better?

I can assure you, by the way, that Andi didn't ask for out-of-the-blue 
ideas from people who don't have any idea on how to do them, and have no 
intention of doing anything about them themselves.  How about a wiseguy 
that will suggest to improve the speed of PHP 10 times around?  Great, 
we're all for it, but have a plan on how to do it, or be willing to work on 
a plan if it's accepted.

>It is like Richard Heyes said very well, while Andi asked for
>suggestions you promptly jumped in just to say it is pointless as if it
>was urgent to refuse my suggestion, or at least present an excuse for
>not implementing it.

I did not refuse your suggestion or present any excuses.  That's only in 
your preset mind.  I said it's good, but I also said that you presented it 
in a very, VERY poor way, as you tend to often do.  There's no conspiracy 
against you, I can assure you that, and if you cause many different people 
to object to the way that you present your ideas, you can assume that the 
problems lie in your hands, and not everybody else's.

>I hope you see this time is not "just Manuel". Things could have worked
>much better if you have to refused the countless times that I bothered
>to lend a hand, even if it was just presenting ideas and no code. Too
>bad that you usually only wanted to get me wrong as if what I was
>suggesting was not going to work in your favour. Anyway, it is not soon,
>but may be is not too late...

I never refused a single time you bothered to lend a hand - I don't recall 
a single time (other than this vague virtual marketing idea which I didn't 
consider too good).  As far as I recall, you said that Rasmus refused your 
help in the past, and I think I was the one that actually pushed for you to 
get a CVS account.  Not sure though, it was a long time ago.  At any rate, 
with all the differences I have with Rasmus, and God know we have lots - if 
he refused to accept your help, you must have done something TERRIBLY wrong.

Zeev


-- 
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: PHP 5

[Zeev Suraski]

At 13:41 02/01/2002, Björn Schotte wrote:
>* [EMAIL PROTECTED] wrote:
> > and remain that way. It's much easier to distribute (one download), and
> > easier to install. (No more fetching of PECL extensions).
>
>Yep. But what about a php_4_3_4_core.tgz (core PHP/ZE/TSRM with
>core extensions) and a release of php_4_3_4_complete.tgz packaged
>with all extensions together?

That can happen, but what does that buy you?

Zeev


--
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: PHP 5

[Zeev Suraski]

At 14:01 02/01/2002, Björn Schotte wrote:
>* Zeev Suraski wrote:
> > >Yep. But what about a php_4_3_4_core.tgz (core PHP/ZE/TSRM with
> > >core extensions) and a release of php_4_3_4_complete.tgz packaged
> > >with all extensions together?
> > That can happen, but what does that buy you?
>
>I can err myself, but it's some sort of BC for me in
>the configuration/installation process.

Well, I think that the main motivation for separating the modules away was 
the release schedule.  I.e., separating the release schedule of each 
extension from the release schedule of the PHP core itself.  If we still 
have a full version and a bare-bones version side by side, I'm not sure how 
much that buys you, in comparison with what we have today...

Zeev


--
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: PHP 5

[Zeev Suraski]

At 16:06 02/01/2002, Björn Schotte wrote:
>* Zeev Suraski wrote:
> > Well, I think that the main motivation for separating the modules away was
> > the release schedule.  I.e., separating the release schedule of each
> > extension from the release schedule of the PHP core itself.
>
>Jep. Just to note: I'm +1 for it.

I'm +1 for separating the less popular ones, but I'm -1 for separating 
everything (look up the archives as to why...)

> >  If we still
> > have a full version and a bare-bones version side by side, I'm not sure 
> how
> > much that buys you, in comparison with what we have today...
>
>It buys me nothing because I would prefer the PECL way.

I wasn't talking about you personally, but the PHP project in general 
:)  If we still have to tie up releases to a stable snapshot of all of the 
extensions, then it won't help the release schedule too much.  It may make 
it easier

>I just wanted to say that it could be useful for Sysadmins
>who don't want to download each PECL extension with the
>PEAR/PECL-installer. (like ApacheToolbox)

It'll probably be easier for most people who don't really care too much 
about the version of each individual extension (which, from my experience 
anyway, accounts for most of the users).

Zeev


--
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: PHP 5

[Zeev Suraski]

At 23:33 02/01/2002, Joe Webster wrote:
>I have something that I am currently dealing with:
>
> Using mod_perl with apache, you can put this in a apache directive
>(vhost, location, directory):
> PerlSetVar somevarname somevarval
> and that would pre-define somevarname equal to somevarval. We are trying
>to move completely to php (we're 1/2 php and 1/2 perl) however, we really
>need to be able to set the vars like this. I did look through the mod_php.c
>and I noticed the php_value, php_flag, php_admin_value, and php_admin_flag,
>but nothing for a variable.

Would it be defined in every PHP script that runs?  Does it really have to 
be a variable, or can it be a constant?

Zeev


-- 
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] Bug #14747: Return exitcodes to shell ($?)

[Zeev Suraski]

I'm +1 on the overloaded exit() that doesn't print out its argument, if it 
looks like a number.  For the sake of world peace.

Zeev

At 00:20 29/12/2001, Vlad Krupin wrote:
>consensus... well, it wasn't reached. I guess, the overloaded solution - 
>exit(string, int) - is the last thing that was proposed and not too many 
>people objected to. My understanding is that that's what will happen. Or 
>am I wrong again?
>
>-being short this time-
>
>
>Vlad
>
>Markus Fischer wrote:
>
>>Yo guys,
>>
>>Derick, Zeev, Everybody who participated in the discussions
>>... where were we now? :-)
>>
>>*smiles* - Markus
>>
>>On Fri, Dec 28, 2001 at 09:39:37PM -, [EMAIL PROTECTED] wrote :
>>>From: [EMAIL PROTECTED]
>>>Operating system: PHP version:  4.1.1
>>>PHP Bug Type: Feature/Change Request
>>>Bug description:  Return exitcodes to shell ($?)
>>>
>>>Hi,
>>>
>>>I tried to use PHP in connection with shellprogramming.
>>>
>>>I would be fine if you could return exit codes to shellscripts. So that you
>>>can use something like "if [ $? -eq 0 ]" to test if the PHP-Script had run
>>>succesful.
>>>
>>>So wouldn`t need to use Perl in future.
>>>
>>>
>>>-- Edit bug report at: http://bugs.php.net/?id=14747&edit=1
>>>
>>>
>>>-- 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]
>
>
>
>
>--
>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]


-- 
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: PHP 5

[Zeev Suraski]

This could probably be done.  It does sound helpful.

Zeev

At 00:29 03/01/2002, Joe Webster wrote:
>Yes it would have to be in every script in the vhost, location or directory
>directive.
>
>It could be a constant =) That would make my life easier.
>
>Thanks,
>-Joe
>
>"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
>5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost...
> > At 23:33 02/01/2002, Joe Webster wrote:
> > >I have something that I am currently dealing with:
> > >
> > > Using mod_perl with apache, you can put this in a apache directive
> > >(vhost, location, directory):
> > > PerlSetVar somevarname somevarval
> > > and that would pre-define somevarname equal to somevarval. We are
>trying
> > >to move completely to php (we're 1/2 php and 1/2 perl) however, we really
> > >need to be able to set the vars like this. I did look through the
>mod_php.c
> > >and I noticed the php_value, php_flag, php_admin_value, and
>php_admin_flag,
> > >but nothing for a variable.
> >
> > Would it be defined in every PHP script that runs?  Does it really have to
> > be a variable, or can it be a constant?
> >
> > Zeev
> >
>
>
>
>--
>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]


-- 
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] Built-in SOAP based Web Services support(wasRe:PHP 5)

[Zeev Suraski]

At 00:48 03/01/2002, Joao Prado Maia wrote:

>On Wed, 2 Jan 2002, Sebastian Bergmann wrote:
>
> > Lukas Smith wrote:
> > > But I think we have pitched the need for SOAP enough now :-)
> >
> >   What's wrong with the SOAP implementation provided by ext/xmlrpc?
> >
> >   Rumour has it, by the way, that a nice PEAR class is underway that
> >   simplifies the use of this extension.
> >
>
>That was exactly my point. It seems they are so involved in discussing
>their personal feelings about Microsoft, Web services in general and the
>whole Manuel x Zeev war that they just decided to ignore my message ;)

It wasn't ignored...  I do think that simplifying SOAP access to the level 
you can use it 'out of the box' with minimal hassle, like you can do with 
sessions, would be a very good thing.  I know you can already use SOAP today :)

Zeev


-- 
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: PHP 5

[Zeev Suraski]

Good point :)

At 01:15 03/01/2002, Sander Steffann wrote:
>Hi,
>
>We do exactly the same with Apache SetEnv:
>
> SetEnv  media_regionaamapeldoorn
> SetEnv  media_regioid  27
> SetEnv  media_module   index
>
>And we get them in the PHP script with
>$GLOBALS['HTTP_SERVER_VARS']['media_regionaam'];
>
>Works great for us.
>Sander
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Joe Webster" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Wednesday, January 02, 2002 11:40 PM
>Subject: Re: [PHP-DEV] Re: PHP 5
>
>
> > This could probably be done.  It does sound helpful.
> >
> > Zeev
> >
> > At 00:29 03/01/2002, Joe Webster wrote:
> > >Yes it would have to be in every script in the vhost, location or
>directory
> > >directive.
> > >
> > >It could be a constant =) That would make my life easier.
> > >
> > >Thanks,
> > >-Joe
> > >
> > >"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message
> > >5.1.0.14.2.20020102234728.028651c0@localhost">news:5.1.0.14.2.20020102234728.028651c0@localhost...
> > > > At 23:33 02/01/2002, Joe Webster wrote:
> > > > >I have something that I am currently dealing with:
> > > > >
> > > > > Using mod_perl with apache, you can put this in a apache
>directive
> > > > >(vhost, location, directory):
> > > > > PerlSetVar somevarname somevarval
> > > > > and that would pre-define somevarname equal to somevarval. We
>are
> > >trying
> > > > >to move completely to php (we're 1/2 php and 1/2 perl) however, we
>really
> > > > >need to be able to set the vars like this. I did look through the
> > >mod_php.c
> > > > >and I noticed the php_value, php_flag, php_admin_value, and
> > >php_admin_flag,
> > > > >but nothing for a variable.
> > > >
> > > > Would it be defined in every PHP script that runs?  Does it really
>have to
> > > > be a variable, or can it be a constant?
> > > >
> > > > Zeev
> > > >
> > >
> > >
> > >
> > >--
> > >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]
> >
> >
> > --
> > 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]
> >
> >
> >


-- 
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] Care to test cli sapi?

[Zeev Suraski]

Looks pretty cool!  Finally someone actually took the time to do it :)

Do you have CVS access?

Zeev

At 06:39 06/01/2002, Edin Kadribasic wrote:
>If you do:
>- unpack cli.tar.gz in /sapi
>- apply main.diff.txt patch in /main
>- ./configure --with-cli
>
>That's it.
>
>This is cut-down version of cgi sapi with most of cgi specific stuff
>removed. Some bugs (like #12219) fixed (therefore the need for patch of
>/main).
>
>Edin
>
>P.S. If the list kills the attachments you can find them at:
>http://www.edin.dk/php/
>
>
>--
>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]


-- 
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] consistent way to handle structs

[Zeev Suraski]

At 04:36 PM 1/11/2002, Darrell Brogdon wrote:
>I thought ZE2 was going to have support for method overloading?

Nope, it's not planned...

Zeev


-- 
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] snaps.php.net ???

[Zeev Suraski]

We moved our server - and this wasn't set-up properly just yet.  It'll be 
back...

At 10:25 PM 1/11/2002, benjamin yates wrote:

>   snaps.php.net is redirecting to www.php.net ...
>
>   is it gone?  anyone know?
>
>   -benjamin
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List 
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: migrating PHPs across machines...

[Zeev Suraski]

At 06:23 PM 1/12/2002, Manuel Lemos wrote:
>I was kidding, but since you took it seriously, just by going to
>http://bugs.php.net/search.php I can see that there 920 outstand bug
>reports to be addressed. How come anybody can think that "repressing
>Manuel" is a better way to spend time than fixing all those bugs?

What on earth do these two issues have to do with each other?  (this is a 
rhetorical question, I'll appreciate it if you didn't answer it).

If people feel like taking a vacation, they'll take a vacation.
If they feel like going to a movie, they'll go see a movie.
If people feel like fixing bugs, they'll fix bugs.
If people are annoyed by what you say, they'll tell you that.  If they 
enjoy doing that for whatever past reasons, they'll also enjoy doing that!

Do you get the idea behind the 'free world' concept?  (the same comment 
from the previous question applies)

You can't cover yourself with some bulletproof vest against criticism, by 
saying that people should spend time fixing bugs instead of replying to 
you.  Each and every person will decide what he wants to do, and you never 
had, don't have, and never will have the dictatorial ability to tell them 
what to do.  You try to do that every time, and just like it never worked 
in the past, it will never work in the future.

Zeev


-- 
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: migrating PHPs across machines...

[Zeev Suraski]

At 08:27 PM 1/12/2002, Manuel Lemos wrote:
>You got me wrong. If you read again in the beginning, I said I was
>kidding. Then I expressed my opinion that fixing PHP bugs would be a
>better way to spend time than come here and start yet another "repress
>Manuel" thread. I never said or intended that you would have to agree.
>You can disagree, but my opinion is that is not reasonable. The world
>can live without this, but bugs need to be fixed soon or later, or else
>they will remain there forever rotten.

Ok then, we can actually agree on this paragraph.  I just wish you didn't 
fallback to telling everyone to start working on bugs whenever they say 
something you don't like :)

Zeev


-- 
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] REMOVEING apidoc.txt and apidoc-zend.txt

[Zeev Suraski]

I think that replacing them with web pointers is a better idea than just 
plain removing them...

Zeev

At 04:41 AM 1/16/2002, Yasuo Ohgaki wrote:
>Hi all.
>
>apidoc.txt and apidoc-zend.txt are obsolete.
>If nobody going to maintain these files, they
>should be removed, IMO. (It's still useful, though)
>
>If we want to keep these, how about make a new
>directory "docs" to keep verious text documents
>that is better to be distributed with source.
>
>Any comments?
>
>--
>Yasuo Ohgaki
>
>
>--
>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]


-- 
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]

[PHP-DEV] ZE repositories

[Zeev Suraski]

Hey,

After moving to the BSD license, and after the project I've been working on 
for the last few months has been launched and I have some free time again, 
there are no longer any good reasons not to put the ZE CVS on 
cvs.php.net.  The key thing it would allow is for all of the cvsweb/lxr 
stuff to work nicely on the ZE/ZE2 repositories as well (cvs.zend.com is 
behind a firewall with port 80 filtered out, so it wasn't possible before).

I plan to do it by the end of the week - I want to make sure it's still 
rsync'd to cvs.zend.com (r/o) so that people who checked it out can still 
update it.

Just a heads-up,

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 4.2.0 / PHP 5.0.0-alpha

[Zeev Suraski]

At 12:33 AM 2/5/2002, Björn Schotte wrote:
>* James Cox wrote:
> > with regard to the release of a v.5 [pre-]alpha, what are your thoughts 
> on a
> > developer vs public announcement?
>
>Will there be any revolutionary things besides of ZE2 inside
>PHP 5? If not, I would suggest a developer's announcement.
>Public announcement would disappoint people, IMHO (because
>I think they would expect something revolutionary of a new
>major-major version of PHP).

I think that the changes implemented are pretty revolutionary, but if 
people want some more meat in PHP 5, it's time to start working (read:  not 
talking :)

Zeev


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: ZE repositories

[Zeev Suraski]

That may be trickier.  License wise, it's under a different license (we're 
not in a position to change it, New Riders, Till and Tobias are).  I also 
think it makes sense to keep it in a different module (like the ZE/ZE2 
will, even though they'll be in the php.net CVS).  The build can probably 
change to automatically include this into the manual, and it should be 
possible to note that this part is under a different OS license.

I personally don't see the real necessity in doing this, by the way, but I 
don't really mind.

Zeev

At 04:05 AM 2/5/2002, Jani Taskinen wrote:

>And the documentation..engine-api-doc or what it is again.
>That should be in the manual too, IMO.
>
>--Jani
>
>
>On Tue, 5 Feb 2002, Yasuo Ohgaki wrote:
>
> >Great news :)
> >
> >Just a reminder. Please don't forget about TSRM.
> >
> >
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP Safe Mode Filesystem Circumvention Problem (fwd)

[Zeev Suraski]

At 08:15 AM 2/5/2002, Rasmus Lerdorf wrote:
>The fact that 3rd party libs can load arbitrary files is not a new
>concept.  Every time I give a moderately detailed PHP talk I mention the
>fact that there is a way to load a file through the oci8 libs.  Of course
>it can be done through the mysql libs as well.  This is not a new concept.
>All someone woulod have had to do to learn of this "vulnerability" would
>have been to go to any of the PHP talks I have given in the past 3 years.

Which means that about a one out of every 10,000 PHP users are aware of it? :)

Seriously though, it should probably be noted some prominent place that 
safe mode isn't safe, at best, it's safer.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: ZE repositories

[Zeev Suraski]

At 10:23 AM 2/5/2002, Derick Rethans wrote:
>On Tue, 5 Feb 2002, Zeev Suraski wrote:
>
> > That may be trickier.  License wise, it's under a different license (we're
> > not in a position to change it, New Riders, Till and Tobias are).  I also
> > think it makes sense to keep it in a different module (like the ZE/ZE2
> > will, even though they'll be in the php.net CVS).  The build can probably
> > change to automatically include this into the manual, and it should be
> > possible to note that this part is under a different OS license.
>
>The build process already works that way, but otherwise I think we just
>should ask New Riders if the licence can be changed is needed.

It should be noted that I believe it'll be better for the manual to lose 
the ugly license it's under and move to the openbook license, than the 
other way around.  But I've already done my share of license wars in my 
life - if you want to talk to New Riders, go ahead.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: ZE repositories

[Zeev Suraski]

At 10:32 AM 2/5/2002, Derick Rethans wrote:
>Under which ugly licence is it now? =) I'm all for make sure these are
>compatible, so that the two repositories caan be merged.

GPL, I believe?

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/msession msession.c

[Zeev Suraski]

It's much better to define TSRMLS_CC to nothing, then #ifdef every 
statement that uses it...

Zeev

At 07:42 PM 2/5/2002, [EMAIL PROTECTED] wrote:
> > [EMAIL PROTECTED] wrote:
> >> This sort of bothers me. Who is this "our" you talk about? As
> >> contributor  of the msession extension, am I not also part of "our"
> >> and don't I get a  say on the priorities of msession?
> >
> > not if these priorities are in contradiction to the overall goals, and
> > as such BC is not *that* important on a developement branch
>
>Perhaps, but it is not "contrary" either.
>
> >
> >> I can understand your position, but the msession extension not a
> >> difficult  peice of code. I have updated the proto comments so they
> >> correctly state  what the functions do. Just tell me what else you
> >> want for comments.
> >
> > the #ifdef OLD_ZEND_PARAM stuff obfuscates it without need,
> > especially in the additional places where you use it like this
> >
> >#ifdef OLD_ZEND_PARAM
> >   php_log_err("Call to connect with non-null s_conn");
> >#else
> >   php_log_err("Call to connect with non-null s_conn" TSRMLS_CC);
> >#endif
> >
> > the behaviour you test for is not at all related to the parameter
> > parsing functions, its just by coincidence that both are related
> > to the same api version number switch
>
>What's a better test?
>
>
>
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Tabs Vs Spaces (and other coding styles)

[Zeev Suraski]

Tabs, they've been used historically.

Zeev

At 07:19 PM 2/5/2002, James Cox wrote:
>Guys,
>
>have we ever decided on this? in our code do we go for tabs or spaces? Is
>there a style guide anywhere on this?
>
>thanks,
>
>james
>
>--
>James Cox :: [EMAIL PROTECTED]
>Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]

[Zeev Suraski]

While I agree with Marko's vote (I'm also very much against it), I derive 
my conclusion from a whole different perspective.

Guys, we are not next to the drawing board right now.  The specs were 
defined and the layout was laid years ago.  At this point in time we're 
only supposed to change something like that if there's an overwhelming 
reason to do it, and none of the reasons mentioned falls into that category.

The reasons to move to case sensitivity and the alternative ways we should 
handle them, in my opinion, are:

- Speed.  We can probably improve the typical case so that it's not any 
slower in runtime.
- Interaction with external component systems - we can have case 
sensitivity implemented at the module level, especially with the Engine 2 
infrastructure, and still remain case insensitive for regular PHP objects.
- "It's just right".  Well, I can totally agree with that, but only if we 
were next to the drawing board, which we're not.

Zeev

At 01:01 PM 2/6/2002, Marko Karppinen wrote:

> >> However, we need vote for if PHP5 will have case
> >> sensitive class/function/constant names.
> >
> > +1 for case-sensitive everything
>
>-1. Differentiating two objects only by the case of their names
>seems absurd to me. This is not how humans function.
>
>Ease of implementation is the only thing speaking for case-sensitiveness in
>my book. Case-insensitiveness is always more work. But I think it's well
>worth the trouble.
>
>Hence case-insensitive, case-preserving is my suggestion.
>
>--Marko
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Lists

[Zeev Suraski]

I'm afraid php-dev-spam may become a bit more popular than you think :)

At 06:58 PM 2/6/2002, Gary Benson wrote:

>I've been thinking about this. What is really needed is some way to send
>automated 'get lost' messages without requiring a list moderator. These
>messages have got to be real easy to send to make this work.
>
>How about this: set up a list (php-dev-spam, say) that isn't archived or
>advertised anywhere. If somebody posts something daft here simply forward
>or bounce it to php-dev-spam which generates an automatic 'your message is
>not suitable for this list, here are some other lists you may wish to try'
>response, and perhaps sends something to php-dev with subject "[PHP-SPAM]
>[EMAIL PROTECTED] berated" so nobody else bothers to bounce it.
>
>What do you reckon?
>Gary
>
>[ [EMAIL PROTECTED] ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Lists

[Zeev Suraski]

At 10:42 PM 2/6/2002, Robinson, Mike wrote:

>I reckon we've been through all this before.
>Closing the list in any way is just a bad idea.

It's just that never before did we lose actual contributors over people who 
make nothing but noise.  Now it is happening.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]

[Zeev Suraski]

At 02:04 AM 2/7/2002, Jason Greene wrote:
>You left off language consistency between variable names, and function
>names.

I consider that the 'warm fuzzy feeling' of purity, which I can totally 
understand and sympathize with.  However, this sort of consistency between 
variables and function names is not mandatory, in my opinion, not mandatory 
enough to break compatibility in such a broad way, and after such a long time.

>We are already completely redesigning OO which is like standing at the
>drawing board.

Even with the whole new object API, most of the code would work without 
modifications (at least mostly all of the PHP object code I got to take a 
look at).  And if it doesn't - turning on PHP 4 compatibility should bridge 
the gap...

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP list server is banning mlemos@acm.org[Fwd:Mensagem automatica: User unknown [Usuario desconhecido]]

[Zeev Suraski]

It's your right, of course, and as always, you never avoid a chance to 
abuse php-dev for your own personal purposes.  I tried to save php-dev the 
trouble, you don't care.

php-dev'ers, please don't reply on php-dev.  Reply to Manuel or me or 
group@, but spare the ones that actually want to spend their time developing.

Zeev

At 12:45 PM 2/7/2002, Manuel Lemos wrote:
>Hello,
[Goodbye]

>Regards,
>Manuel Lemos


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Separating Bug report emails to own list.. Re: Re[3]: [PHP-DEV] Suggestion:

[Zeev Suraski]

+1

At 04:06 AM 2/8/2002, Jani Taskinen wrote:

> Just wanted to let you know that I'm doing exactly that.
> Filtering that annoying noise to other folder. :)
> Which I unfortunately don't have time to read atm.
>
> And I actually have turned my coat on this issue and I'm
> in favor for separating the bug emails to own list.
>
> Two good reasons:
> - People who don't want to read them filter them out anyway
> - It makes php-dev easier to follow
> - The php-dev@ archive (e.g. in web) becomes easier to browse
>   and search for discussions
>
> The php-bugs@ list should be a read-only list where anyone
> with cvs account should be subscribed (by default).
> It being read-only forces any replies to be send to php-dev@
> where more intense discussion over the issues in the reports
> should take place anyway.
>
> --Jani
>
>
>On Thu, 7 Feb 2002, l0t3k wrote:
>
> >Daniel,
> >we've had that conversation before, and the consensus then (which makes
> >sense), is that part of the price of being a developer is ensuring that bugs
> >are resolved in a timely manner. to split the list would make it less likely
> >that a bug gets reviewed (after all its more sexy to create features than to
> >debug them). how that works in actual practice, i dont know. i review bug
> >reports periodically, but i suppose others can just as well filter them
> >out...
> >
> >Daniel Lorch <[EMAIL PROTECTED]> wrote in message
> >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> >> Hi,
> >>
> >> Maybe a solution would be to split PHP-Dev into PHP-Bugs and keep
> >> PHP-Dev for *real* topics such as case sensitivity/PHP5 and other
> >> questions which are about PHP language design. This would keep the
> >> "noise" out of here. Comments?
> >>
> >> --  Daniel Lorch
> >>
> >>
> >
> >
> >
> >
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Separating Bug report emails to own list.. Re: Re[3]: [PHP-DEV] Suggestion:

[Zeev Suraski]

At 03:13 PM 2/8/2002, Andi Gutmans wrote:
>At 03:04 PM 2/8/2002 +0200, Jani Taskinen wrote:
>
>>Do you filter these? :)
>>I didn't do that before, but now that I am doing it, it makes
>>following php-dev@ a LOT easier.
>
>I do :) But I still think that people subscribed to php-dev@ need to not 
>only enjoy upsides but also the downsides of receiving the bug reports in 
>hope that more people will look at them.

I think that the only time this actually has any meaning is with people 
whose email software isn't bright enough to filter it.  Otherwise, I'm 
pretty sure everyone filters it anyway.

php-dev is full of people who aren't actually developing, but are just 
interested in watching the development trends.  Forcing them to see the 
bugs isn't going to do anything in any level - either they'll ignore it, or 
filter it out, because they can't do anything about it anyway.

We both know that just receiving the bug reports doesn't have any meaning 
if you're not willing to actually spend time working on them.

I don't think it's that important (that's my last post on this thread :), 
but it does look kind of odd that instead of just separating the lists, we 
tell people 'filter them!'

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Case sensitivity: Conclusion(?)

[Zeev Suraski]

I think that's a nightmare, WTF-factor wise...  Just my 0.02NIS

Zeev

At 12:14 AM 2/9/2002, Jason Greene wrote:
>If you are already thinking about storing the case sensitive name for
>the class/function why not follow Rasmus's suggestion for calling the
>exact case function first, then look for a case insens match.
>
>search case preserved function_table
>if not found {
> search lowercase function_table
> if not found die with "Unknown function"
>}
>
>There is no performance penalty unless you mix case. There is of course
>the extra memory needed for 2 tables.
>
> >
>--
>Jason T. Greene
>Internet Software Engineer
>
><[EMAIL PROTECTED]>
><[EMAIL PROTECTED]>
><[EMAIL PROTECTED]>
>
>Use PHP: http://www.php.net
>
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Case sensitivity: Conclusion(?)

[Zeev Suraski]

At 01:24 PM 2/9/2002, Thies C. Arntzen wrote:
>On Sat, Feb 09, 2002 at 01:41:21AM +0200, Zeev Suraski wrote:
> > I think that's a nightmare, WTF-factor wise...  Just my 0.02NIS
>
> how much is that in euro?

Not too much.  About  0.005 :)

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php