Re: [PHP-DEV] strange autoload behavior

[Marcus Boerger]

Hello Jochem,

  seems like we have quite some nice additions to the manual here in this
thread. Now to the real issue, Exceptions don't bubble up. That is they
are simply ignored. And once all __autoload work is done and the class
still doesn't exist an E_ERROR is issued. The work around for cases where
the class must not exist (e.g. when no E_ERROR is needed would be
collecting the exceptions. That is the base Exception class would get an
additional property and getter:
  private $previous_exception;
  function public getPreviousException();
That way we could let the exceptions bubble up (though some smaller engine
changes are necessary).

marcus

Thursday, July 10, 2008, 7:14:33 PM, you wrote:

> Derick Rethans schreef:
>> On Thu, 10 Jul 2008, Gergely Hodicska wrote:
>> 
 exceptions thrown during autoload are ignored.
>>> And one more thing, this is in the manual:
>>> "Note: Exceptions thrown in __autoload function cannot be caught in the 
>>> catch
>>> block and results in a fatal error."
>>>
>>> I think your explanation makes much more clear what happens, maybe it would
>>> worth to upgrade the manual. While the quoted text suggests that that if 
>>> throw
>>> an exception I just can't catch it and will bubble up to top level and this
>>> cause the fatal error.
>> 
>> You can actually catch it *in* the autoload method, it just wouldn't 
>> bubble out of it.

> the manual could do with that tidbit, maybe also the hack for 'getting the
> exception out' of __autoload() ...

> function __autoload($class)
> {
> try {
> throw new Exception('foo');
> } catch (Exception $e) {
> self::handleDebug($e);
> 
> if (!class_exists($class, false))
> eval(sprintf('
>  class %1$s
>  {
>  public function __construct(){
> throw new AL_Exception("Class %1$s not found: %2$s"); }
>  public function __call($m, $a)   {
> throw new AL_Exception("Class %1$s not found: %2$s"); }
>  public  static function __callStatic($m, $a) {
> throw new AL_Exception("Class %1$s not found: %2$s"); }
>  }', $class, $e->__toString()));
> }
> }

> which works best when __autoload() isn't triggered by class_exists("Foo", 
> true)


>> 
>> regards,
>> Derick
>> 





Best regards,
 Marcus


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

Re: [PHP-DEV] to be discussed items

[Marcus Boerger]

Hello Lukas,

Monday, July 14, 2008, 2:58:13 PM, you wrote:

> Hi,

> I am about to move all "to be discussed items" [1] to the future PHP  
> release section (so after 5.3):

> 1) userspace streams filter that acts as a default filter through  
> which require/include read their files (Sebastian, Sara)

I don't care but want to remind that the user streams do not in the
slightest folloow any name scheme whatsoever. So I rather have them ripped
and reimplemented.

> 2) XMLWriter: Add writeNode([xmlreader obj]), allow to create a push/ 
> pull parser

should be easy enough and is simply a new function in an ext, can't just
somebody do it?

> 3) add a function that returns tsrm_thread_id() - already covered by  
> zend_thread_id() but only in debug ZTS mode (Wez)

Iirc the last time we discussed it we saw it to be a debug only function.

> 4) DOM recover error reporting mode
> 5) PDO: allow the DSN to be passed as array, proposal phase. An  
> initial proposal was done here (pierre, lukas)

Can we first decide whether this effort is worth anything (as in whether
we reimplement the whole extension)?

> 6) namespaces for internal classes

The general idea so far was that the user should namespace their names and
PHP uses the global name space. Just as in any other language. However
that does not mean that some ext could have namespaces. But given that
until now we lived without we would make it much harder for users if now
we would put all (or even any tiny bit of) internal functionality inside
namesoace. Just because everything has to be done twice then from the user
perspective. So this is contraproductive. It would also take away the
freedom to ignore namespaces.

> 7) deprecate/remove ticks

Deprecate, as this is a minor version and not a major version. If we
remove them which personally I'd love to do, then we should drop tons of
other deprecated stuff as well and get rid of the stupid no removing
unless major version change rule.

> 8) Algorithm Optimizations - string search

Anythign that makes PHP faster should always be welcome. Unless:
- comes with API additions -> RM decision
- internal API change -> next minor version
- extenal API change -> next major verision

Best regards,
 Marcus


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

[PHP-DEV] --disable-mbregex in HEAD?

[Moriyoshi Koizumi]

Hi there,

(Yeah, it's been a long time.. Many of you might well have thought
I'm dead :)

This time I want to revisit the following issue:
http://article.gmane.org/gmane.comp.php.devel/50681

Is there any point to disable mbregex alone instead of disabling the
whole mbstring stuff? Unless the decision whether to send the module into
PECL (or anywhere you want it to go) has been made, I suppose it should
not.

Regards,
Moriyoshi

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

Re: [PHP-DEV] to be discussed items

[Andrey Hristov]

Lukas Kahwe Smith wrote:

Hi,

I am about to move all "to be discussed items" [1] to the future PHP 
release section (so after 5.3):


1) userspace streams filter that acts as a default filter through which 
require/include read their files (Sebastian, Sara)
2) XMLWriter: Add writeNode([xmlreader obj]), allow to create a 
push/pull parser
3) add a function that returns tsrm_thread_id() - already covered by 
zend_thread_id() but only in debug ZTS mode (Wez)


Regarding this, PHP is not pthreads conformant. The thread_id has own 
type and it is implementation specific. There is pthread_equal() to make 
comparison, although it is not used in the PHP code and the thread id is 
considered to be an int, last time I checked.



4) DOM recover error reporting mode
5) PDO: allow the DSN to be passed as array, proposal phase. An initial 
proposal was done here (pierre, lukas)

6) namespaces for internal classes
7) deprecate/remove ticks
8) Algorithm Optimizations - string search

For 6) it does not seem like we know a good solution at this stage. For 
8) we might decide to selectively incorporate patches. Though it would 
be the authors job to present us two RMs with easy to evaluate candidate 
patches to consider.


regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]

[1] http://wiki.php.net/todo/php53#to_be_discussed



Best,
Andrey

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

Re: [PHP-DEV] to be discussed items

[Pierre Joye]

hi Marcus,

On Mon, Jul 14, 2008 at 11:15 PM, Marcus Boerger <[EMAIL PROTECTED]> wrote:

>> 2) XMLWriter: Add writeNode([xmlreader obj]), allow to create a push/
>> pull parser
>
> should be easy enough and is simply a new function in an ext, can't just
> somebody do it?

It is not hard but not a small thing either (nested elements,
attributes, etc.). It could accept a DOM node as well.

However I will not have the time to do it before the 24th so if anyone
is interested, please raise the hand :)

Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] to be discussed items

[Lukas Kahwe Smith]

On 15.07.2008, at 13:25, Pierre Joye wrote:


hi Marcus,

On Mon, Jul 14, 2008 at 11:15 PM, Marcus Boerger <[EMAIL PROTECTED]>  
wrote:


2) XMLWriter: Add writeNode([xmlreader obj]), allow to create a  
push/

pull parser


should be easy enough and is simply a new function in an ext, can't  
just

somebody do it?


It is not hard but not a small thing either (nested elements,
attributes, etc.). It could accept a DOM node as well.

However I will not have the time to do it before the 24th so if anyone
is interested, please raise the hand :)


traditionally we have also added new non BC breaking features in the  
first couple patch releases. So stuff like this could also just wait  
for 5.3.x (where 0 < x < 5). so in this context "future php releases"  
means any php release after 5.3.0


regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]




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

Re: [PHP-DEV] --disable-mbregex in HEAD?

[Marcus Boerger]

Hello Moriyoshi,

Tuesday, July 15, 2008, 1:05:35 PM, you wrote:

> Hi there,

> (Yeah, it's been a long time.. Many of you might well have thought
> I'm dead :)

> This time I want to revisit the following issue:
> http://article.gmane.org/gmane.comp.php.devel/50681

> Is there any point to disable mbregex alone instead of disabling the
> whole mbstring stuff? Unless the decision whether to send the module into
> PECL (or anywhere you want it to go) has been made, I suppose it should
> not.

(just for Derick answered here)
I never liked this. So imo we can simply get rid of this switch and enable
mbregex as soon as there is mbstring to begin with and regex stuff.


Best regards,
 Marcus


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

[PHP-DEV] Re: to be discussed items

[Rob Richards]

Hi Lukas,

Lukas Kahwe Smith wrote:

Hi,

I am about to move all "to be discussed items" [1] to the future PHP 
release section (so after 5.3):


2) XMLWriter: Add writeNode([xmlreader obj]), allow to create a 
push/pull parser


I also don't think I would be able to find the time to get this done in 
the next week. Probably a 5.3.x feature.




4) DOM recover error reporting mode


I don't agree with this one at all. The libxml_use_internal_errors 
function can be used to suppress errors. I'd prefer to drop this one 
completely.


Rob

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

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Andrey Hristov]

 Hi Marcus,
Marcus Boerger wrote:

Hello Andrey,

Tuesday, July 15, 2008, 3:12:27 PM, you wrote:


andrey  Tue Jul 15 13:12:27 2008 UTC


  Modified files:  
/php-src/ext/mysql  php_mysql.c 
/php-src/ext/mysqli   mysqli.c 
/php-src/ext/mysqlndmysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c 
mysqlnd_wireprotocol.c 
  Log:

  Sync with bzr


what did you synch? what is bzr? is this developed elsewhere? If so why
does php have a copy... especially in src


bzr stands for Bazaar. We have internally switched from svn to bazaar. 
There is also public repository


bzr clone lp:~andrey-mysql/php-mysqlnd/trunk

I think Ulf will soon write a blog entry about it.
There is a problem with CVS, because it should be compilable all the 
time. Internally bzr is used till a feature matures. Then it gets 
synced. Also when offline one can fix bugs without fearing that can 
break something. We sync code very often. If php.net was using more 
sophisticated revision control system we wouldn't bother to use bzr 
internally, as I am not a fan of administering a RCS.


Most of the times a new feature lies on the backs of few people, i.e 
me+Ulf or Johannes+Ulf . Ulf does heavy-weight testing. We don't like 
pushing code without having proper tests for it. Without internal RCS 
this won't work flawlessy - sending patches around makes things 
complicated. Asynchronous query support in mysqlnd is such a feature, 
that waits for more tests (it has already some), before we put it to 
CVS. We had a branch, currently abandoned, to play with client side 
query caching. I think it's more in the interest of the PHP users, if we 
provide well tested code and not put experimental stuff, that breaks. We 
are on our way to clean mysqli from experimental stuff by either 
stabilizing it or developing it anew.


You might think that we have closed-sourced something, but that's 
definitely not true. When we used svn we had a public svn repo, which 
was actually used. The bzr repo at launchpad mirrors our internal bzr repo.



Best regards,
 Marcus



Regards,
Andrey

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Pierre Joye]

On Tue, Jul 15, 2008 at 4:10 PM, Andrey Hristov <[EMAIL PROTECTED]> wrote:

> bzr stands for Bazaar. We have internally switched from svn to bazaar. There
> is also public repository
>
> bzr clone lp:~andrey-mysql/php-mysqlnd/trunk
>
> I think Ulf will soon write a blog entry about it.

I do not like to repeat myself (for the wellness of the reader), but
we have mailing lists. Blogs are nice for whatever you use it but they
are not the way to communicate with internals.

> There is a problem with CVS, because it should be compilable all the time.

No, you can disable by default until you reach a usable state (#2).
But do you really commit non compilable code in your repository?!?

> You might think that we have closed-sourced something, but that's definitely
> not true. When we used svn we had a public svn repo, which was actually
> used. The bzr repo at launchpad mirrors our internal bzr repo.

Drop the launchpad and use php's cvs. We have actually two development
branches (5.3 until the 24th and HEAD) and PECL. The latter let you
experiment as much as you wish.

It is impossible to work smoothly together if the development (besides
what resides in your personnal HDD) is not in our repository. As it is
fine for a PECL extension, it is hardly a good thing for key component
like the mysql extension(s).

Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Ulf Wendel]

Pierre Joye schrieb:

Drop the launchpad and use php's cvs. We have actually two development
branches (5.3 until the 24th and HEAD) and PECL. The latter let you
experiment as much as you wish.


Pierre, you are not in the position to tell us what repository we use 
for internal developments and experimental features.


Or should I start flaming againt the developing of a new PHP parser at 
svn://whisky.macvicar.net/php-re2c . Looks like there are two classes of 
developers in your world. The bad and the good. The good can use their 
own repositories. The bad may not. And MySQL is bad.


Ulf

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Scott MacVicar]

Ulf Wendel wrote:

Pierre Joye schrieb:

Drop the launchpad and use php's cvs. We have actually two development
branches (5.3 until the 24th and HEAD) and PECL. The latter let you
experiment as much as you wish.


Pierre, you are not in the position to tell us what repository we use 
for internal developments and experimental features.


Or should I start flaming againt the developing of a new PHP parser at 
svn://whisky.macvicar.net/php-re2c . Looks like there are two classes of 
developers in your world. The bad and the good. The good can use their 
own repositories. The bad may not. And MySQL is bad.


Ulf



The implementation of the new scanner was an experiment at first to see 
how viable it was, as soon as it was finished we created a patch and the 
repository was no longer used.


We could have potentially created a new branch for this but neither nuno 
or myself had karma for Zend/ at the time.


Scott

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

[PHP-DEV] lstat call on each directory level

[Amir Hardon]

Hi,

I've noticed a weird behavior when doing file access from PHP:
PHP seems to make an lstat call on each of the parent directories of the
accessed file, for example see this script:



When running with strace -e lstat I see this:
lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
lstat("/var/www/metacafe", {st_mode=S_IFDIR|0755, st_size=4096, ...}) =
0
lstat("/var/www/metacafe/test", 0x7fbfff9b10) = -1 ENOENT (No such file
or directory)

Measuring total syscalls time for an apache process on a production
server, I found out
that ~33% of the time it spends in syscalls is spent on lstat.

I did a pretty deep web search on the issue and came out with nothing.
I'll also note that I did a small experiment - moving our root portal
folder to /,
this gave an amazing performance improvement!

So my questions are:
What is the reason for doing these lstat calls?
How can it be disabled? if not by configuration, maybe by patching php
(can you direct me to where is this being done in php's source?)


Thanks!
-Amir.

Re: [PHP-DEV] --disable-mbregex in HEAD?

[Moriyoshi Koizumi]

Marcus Boerger wrote:
> Hello Moriyoshi,
> 
> (just for Derick answered here)
> I never liked this. So imo we can simply get rid of this switch and enable
> mbregex as soon as there is mbstring to begin with and regex stuff.

Me neither. As far as I know, the switch exists just for historical
reasons. Since --enable-mbregex takes effect only when --enable-mbstring
is specified, it'd be the same as if there was the single option.

Aside from this, what about removing bundled libmbfl and oniguruma from
HEAD and requiring users' using external ones? Now that intl extension
was merged and I don't think it makes sense.

Regards,
Moriyoshi

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Lukas Kahwe Smith]

On 15.07.2008, at 16:50, Scott MacVicar wrote:


Ulf Wendel wrote:

Pierre Joye schrieb:
Drop the launchpad and use php's cvs. We have actually two  
development

branches (5.3 until the 24th and HEAD) and PECL. The latter let you
experiment as much as you wish.
Pierre, you are not in the position to tell us what repository we  
use for internal developments and experimental features.
Or should I start flaming againt the developing of a new PHP parser  
at svn://whisky.macvicar.net/php-re2c . Looks like there are two  
classes of developers in your world. The bad and the good. The good  
can use their own repositories. The bad may not. And MySQL is bad.

Ulf


The implementation of the new scanner was an experiment at first to  
see how viable it was, as soon as it was finished we created a patch  
and the repository was no longer used.


We could have potentially created a new branch for this but neither  
nuno or myself had karma for Zend/ at the time.



I think its totally legit that mysqlnd was developed externally. i  
also think its legit to develop larger experimental features in an  
external repo until we have something better to offer than CVS.  
however day to day stuff should happen in php-src. now that mysqlnd is  
resynced and that you guys have no more experimental features to test  
out before 5.3.0, i would hope that da to day work now happens in php- 
src.


the async stuff is scheduled for 5.3.1 at the earliest and so if you  
feel it makes development easier, i see no big problem if bzr is used  
for this. just make sure to resync soon enough before 5.3.1 so that  
the community has a chance to examine the work inside php-src.


my 2 cents ..

regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]




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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Marcus Boerger]

Hello Ulf,

Tuesday, July 15, 2008, 4:32:10 PM, you wrote:

> Pierre Joye schrieb:
>> Drop the launchpad and use php's cvs. We have actually two development
>> branches (5.3 until the 24th and HEAD) and PECL. The latter let you
>> experiment as much as you wish.

> Pierre, you are not in the position to tell us what repository we use 
> for internal developments and experimental features.

> Or should I start flaming againt the developing of a new PHP parser at 
> svn://whisky.macvicar.net/php-re2c . Looks like there are two classes of 
> developers in your world. The bad and the good. The good can use their 
> own repositories. The bad may not. And MySQL is bad.

You really proove here that a) our communication needs to get better and
that blogs don't help as they are ignored ffrom most developers. And b) we
reallt need to most to a better repository like SVN or HG.

Other than that, nobody tells you what you do or use. We just would like to
know. And in regards to re2c I can only repeat what Scott said. It was a
one time experiment that was announced on the list to be followed along and
comitted as a whole as soon as agreed on (not when finished to be precise).

Best regards,
 Marcus


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

Re: [PHP-DEV] --disable-mbregex in HEAD?

[Marcus Boerger]

Hello Moriyoshi,

Tuesday, July 15, 2008, 4:58:38 PM, you wrote:

> Marcus Boerger wrote:
>> Hello Moriyoshi,
>> 
>> (just for Derick answered here)
>> I never liked this. So imo we can simply get rid of this switch and enable
>> mbregex as soon as there is mbstring to begin with and regex stuff.

> Me neither. As far as I know, the switch exists just for historical
> reasons. Since --enable-mbregex takes effect only when --enable-mbstring
> is specified, it'd be the same as if there was the single option.

> Aside from this, what about removing bundled libmbfl and oniguruma from
> HEAD and requiring users' using external ones? Now that intl extension
> was merged and I don't think it makes sense.

Would be fine with me as well.

Best regards,
 Marcus


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Pierre Joye]

Hi Ulf,

On Tue, Jul 15, 2008 at 4:32 PM, Ulf Wendel <[EMAIL PROTECTED]> wrote:
> Pierre Joye schrieb:
>>
>> Drop the launchpad and use php's cvs. We have actually two development
>> branches (5.3 until the 24th and HEAD) and PECL. The latter let you
>> experiment as much as you wish.
>
> Pierre, you are not in the position to tell us what repository we use for
> internal developments and experimental features.

I am in the position to tell you that I disagree with your choices.
I'm even more concerned as I try to maintain and test the current
windows releases for our PHP releases. Given the almost complete lack
of answers from MySql to my requests, I'm actually in the positions to
worry about what is happening here. That being said, I will leave you
in peace now. I told you my thoughts, my worries and the reasoning
behind them. I also showed more than once my willingness to help (and
not only for mysqlnd) . If the only results is such answers...

> Or should I start flaming againt the developing of a new PHP parser at
> svn://whisky.macvicar.net/php-re2c . Looks like there are two classes of
> developers in your world. The bad and the good. The good can use their own
> repositories. The bad may not. And MySQL is bad.

See Scott answer and I can hardly see a relation between the two.

-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] --disable-mbregex in HEAD?

[Christian Hoffmann]

On 2008-07-15 16:58, Moriyoshi Koizumi wrote:

Aside from this, what about removing bundled libmbfl and oniguruma from
HEAD and requiring users' using external ones? Now that intl extension
was merged and I don't think it makes sense.
Huge ++ from me, especially regarding oniguruma. If you'd want to make 
it optional (but not required), I've sent a related patch to this list 
weeks ago.


--
Christian Hoffmann



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Ulf Wendel]

Pierre Joye schrieb:

On Tue, Jul 15, 2008 at 4:32 PM, Ulf Wendel <[EMAIL PROTECTED]> wrote:

Pierre Joye schrieb:

Drop the launchpad and use php's cvs. We have actually two development
branches (5.3 until the 24th and HEAD) and PECL. The latter let you
experiment as much as you wish.

Pierre, you are not in the position to tell us what repository we use for
internal developments and experimental features.


I am in the position to tell you that I disagree with your choices.
I'm even more concerned as I try to maintain and test the current
windows releases for our PHP releases. Given the almost complete lack
of answers from MySql to my requests, I'm actually in the positions to


What's your point, what requests are you talking about?

Any recent mails to Andrey, who has just returned from 5(!) weeks of 
vacation to me, Georg, Johannes, any requests on [EMAIL PROTECTED]


I saw one person complaining about mysqlnd being compiled into PHP 
although no mysql extension was compiled into PHP: bug - open to anybody 
to fix. As its a build quirk, I have not even followed up on the 
discussion. PHP has a very vivid team of developers fixing many issues 
before they go down to the maintainers, see the constant work on bug 
reports. I relied on that to happen. Is that the issue you are talking 
about?



Or should I start flaming againt the developing of a new PHP parser at
svn://whisky.macvicar.net/php-re2c . Looks like there are two classes of
developers in your world. The bad and the good. The good can use their own
repositories. The bad may not. And MySQL is bad.


See Scott answer and I can hardly see a relation between the two.


The parser has been developed at other places for good reasons. mysqlnd 
has been developed at other places for good reasons as well.


Ulf



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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Pierre Joye]

On Tue, Jul 15, 2008 at 5:42 PM, Ulf Wendel <[EMAIL PROTECTED]> wrote:

> What's your point, what requests are you talking about?

Please ask Johannes, I told them to him live last time we met. If
there is doubts, I will happily repeat them.

> I saw one person complaining about mysqlnd being compiled into PHP although
> no mysql extension was compiled into PHP: bug - open to anybody to fix.

Ok, I will fix that as It does not make sense to enable mysqlnd when
no mysql extensions are enabled (but that's the least of my worries).

>   PHP has a
> very vivid team of developers fixing many issues before they go down to the
> maintainers, see the constant work on bug reports. I relied on that to
> happen. Is that the issue you are talking about?

How can that happen when you do many maybe unrelated changes in one
commit? How can I (or other) granulary review a commit in this case
(if something is broken)?

We are one week before a freeze and we just see than one of the most
important change for this release is developed outside our tree, I
seriously hope that you understand our worries (I'm not alone to
worry). We may not have have the time to deal with the last minutes
issues introduced by a last minute sync (== disable).

--
Pierre

http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Andrey Hristov]

Marcus,
Marcus Boerger wrote:

Hello Ulf,

Tuesday, July 15, 2008, 4:32:10 PM, you wrote:


Pierre Joye schrieb:

Drop the launchpad and use php's cvs. We have actually two development
branches (5.3 until the 24th and HEAD) and PECL. The latter let you
experiment as much as you wish.


Pierre, you are not in the position to tell us what repository we use 
for internal developments and experimental features.


Or should I start flaming againt the developing of a new PHP parser at 
svn://whisky.macvicar.net/php-re2c . Looks like there are two classes of 
developers in your world. The bad and the good. The good can use their 
own repositories. The bad may not. And MySQL is bad.


You really proove here that a) our communication needs to get better and
that blogs don't help as they are ignored ffrom most developers. And b) we
reallt need to most to a better repository like SVN or HG.


I am pretty lazy, thus I use my Thunderbird as a RSS reader. I get 
planetmysql as a feed and if I am not interested in an article, I skip 
it. It doesn't require even to go anymore to planetmysql . But even 
more, Ulf is also on planetphp, so you will get the message, if there is 
something. Internals is full of other things. I recall Wez saying that 
the PDO discussion should stay at the PDO list and not be on internals, 
because he doesn't have the bandwidth to follow internals.



Other than that, nobody tells you what you do or use. We just would like to
know. And in regards to re2c I can only repeat what Scott said. It was a
one time experiment that was announced on the list to be followed along and
comitted as a whole as soon as agreed on (not when finished to be precise).


Well, we experiment internally. Being it async queries, prepared 
statements cache, client side query cache, zval caching, memory 
allocation caching, whatever. Then it goes to cvs, ONCE WE HAVE PROPER 
TESTS. I am talking about patches which are not typical 100 lines and 
that need really a lot of testing, before anyone can scream that MySQL 
(SUN) makes things worse. What we do is for the best of the community. 
We strive to have more things open source, because we believe in open 
source to the extent that we fight for it, you just don't hear these 
things in the public. I wish PHP the best, I am living with the project 
in the last 8 years. I am giving more than I am expected for the sake 
that others will be satisfied with the work and will use PHP.


Everyone is welcomed to participate in the mysqlnd development and the 
extension has seen changes from outside, as well the mysql extensions 
and we never complained that someone does it. I just moved the changes 
to our internal revision control system, as Bazaar gives us more freedom 
to work than CVS - recently there was a Blog entry on planetphp from a 
dev, who synced PHP but forgot to sync Zend. Wanted to dev while on 
train but the sources did not build so his time was wasted.



Best regards,
 Marcus




Best,
Andrey

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Andrey Hristov]

 Pierre,
Pierre Joye wrote:

Hi Ulf,

On Tue, Jul 15, 2008 at 4:32 PM, Ulf Wendel <[EMAIL PROTECTED]> wrote:

Pierre Joye schrieb:

Drop the launchpad and use php's cvs. We have actually two development
branches (5.3 until the 24th and HEAD) and PECL. The latter let you
experiment as much as you wish.

Pierre, you are not in the position to tell us what repository we use for
internal developments and experimental features.


I am in the position to tell you that I disagree with your choices.
I'm even more concerned as I try to maintain and test the current
windows releases for our PHP releases. Given the almost complete lack
of answers from MySql to my requests, I'm actually in the positions to
worry about what is happening here. That being said, I will leave you
in peace now. I told you my thoughts, my worries and the reasoning
behind them. I also showed more than once my willingness to help (and
not only for mysqlnd) . If the only results is such answers...


As much as I don't like using Windows we do test our code on Windows. We 
do test it on Fedora, Debian, Solaris (x86 and sparc), and even more. We 
can test on more than the PHP project can test - hpux and other rarities.
Dunno if you have ever heard of Pushbuild, it's internal MySQL which 
supports constant building after every commit on a matrix of platforms. 
We use similar tool which uses the same platforms to run PHP tests. So 
we take quality next to our hearts. If you are on another opinion Ulf 
will get insulted, believe me. He does the dirty job of testing not only 
mysqlnd but PDO. How many times he did grumble because of PDO problems - 
I know, because I am constantly communicating with him.



Or should I start flaming againt the developing of a new PHP parser at
svn://whisky.macvicar.net/php-re2c . Looks like there are two classes of
developers in your world. The bad and the good. The good can use their own
repositories. The bad may not. And MySQL is bad.


See Scott answer and I can hardly see a relation between the two.



Best,
Andrey

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Andrey Hristov]

Pierre,
Pierre Joye wrote:

On Tue, Jul 15, 2008 at 5:42 PM, Ulf Wendel <[EMAIL PROTECTED]> wrote:


What's your point, what requests are you talking about?


Please ask Johannes, I told them to him live last time we met. If
there is doubts, I will happily repeat them.


I saw one person complaining about mysqlnd being compiled into PHP although
no mysql extension was compiled into PHP: bug - open to anybody to fix.


Ok, I will fix that as It does not make sense to enable mysqlnd when
no mysql extensions are enabled (but that's the least of my worries).


  PHP has a
very vivid team of developers fixing many issues before they go down to the
maintainers, see the constant work on bug reports. I relied on that to
happen. Is that the issue you are talking about?


How can that happen when you do many maybe unrelated changes in one
commit? How can I (or other) granulary review a commit in this case
(if something is broken)?

We are one week before a freeze and we just see than one of the most
important change for this release is developed outside our tree, I
seriously hope that you understand our worries (I'm not alone to
worry). We may not have have the time to deal with the last minutes
issues introduced by a last minute sync (== disable).


the sync you saw was mostly whitespace. As an example during my vacation 
 Dmitri of the Zend fame complained about valgrind problems with 
mysqlnd. I took time from my vacation to look after the cause and 
provide patches, _through_ CVS, for him and all the community to resolve 
the problems. Is that a closed source development?


If I today commit the async stuff, you will see it as one patch, one big 
patch, which you will have hours to review in its whole. It won't be 
series of patches which you have to connect to realize the whole picture.



On another topic, the branches. I have the feeling that HEAD is pretty 
much abandoned, changing constantly in some direction. I and we look at 
HEAD in a different way. If HEAD would have been released today as PHP6 
the MySQL extension would have been ready for that. Nobody likes merges, 
but we do make them. Both MySQL extensions were fully Unicode ready with 
tests using 2 and 3 byte UTF-8 sequences so we can _ensure_ quality. 
It's not a playground with half-baked features. Either you get something 
baked or you don't get it.



--
Pierre

http://blog.thepimp.net | http://www.libgd.org



Andrey

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqlimysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[David Soria Parra]

Everyone is welcomed to participate in the mysqlnd development and the 
extension has seen changes from outside, as well the mysql extensions 
and we never complained that someone does it. I just moved the changes 
to our internal revision control system, as Bazaar gives us more freedom 
to work than CVS - recently there was a Blog entry on planetphp from a 
dev, who synced PHP but forgot to sync Zend. Wanted to dev while on 
train but the sources did not build so his time was wasted.


Do you talk about our GIT mirrors? They should build now 
(git.experimentalworks.net). There were some problems with importing the 
phar files as they were copied/linked in the CVSROOT, causing problems 
with branch points.


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Ulf Wendel]

Pierre Joye schrieb:

On Tue, Jul 15, 2008 at 5:42 PM, Ulf Wendel <[EMAIL PROTECTED]> wrote:


What's your point, what requests are you talking about?


Please ask Johannes, I told them to him live last time we met. If
there is doubts, I will happily repeat them.


So, you have one question related to Windows builds - I did not know that.

According to Johannes you both have chatted on IRC about it after you 
met. The chat did not help to clearify the question. Can you rephrase 
the question, what version of PHP are we talking about?



I saw one person complaining about mysqlnd being compiled into PHP although
no mysql extension was compiled into PHP: bug - open to anybody to fix.


Ok, I will fix that as It does not make sense to enable mysqlnd when
no mysql extensions are enabled (but that's the least of my worries).


Cool. Its annoying to see anything in a binary which is not needed 
(here: mysqlnd). Like it makes no sense to have ext/pdo compiled into 
PHP if no driver is compiled into PHP. I hope we're not down to a point 
where we really need consult each other for such a minor change...



  PHP has a
very vivid team of developers fixing many issues before they go down to the
maintainers, see the constant work on bug reports. I relied on that to
happen. Is that the issue you are talking about?


How can that happen when you do many maybe unrelated changes in one
commit? How can I (or other) granulary review a commit in this case
(if something is broken)?


I have no clue if Andrey has combined several fixes in one commit. At 
this point I have to rely on him choosing a proper granularity for a 
commit. Too large commits can always happen. You can work for a month in 
your local CVS copy and commit 100k at one - no difference.



We are one week before a freeze and we just see than one of the most
important change for this release is developed outside our tree, I
seriously hope that you understand our worries (I'm not alone to
worry). We may not have have the time to deal with the last minutes
issues introduced by a last minute sync (== disable).


So, this is the real issue behind this discussion, or is there more, 
such as the Windows question from above?


mysqlnd has been committed into PHP 5.3 branch (and into HEAD) in 
October 2007. Since then several updates have been comitted into the 
CVS. This is yet another update. For whatever reason you seem to see a 
difference between this and previous updates.


Do you want to hint that no extension maintainer should update their 
extensions any more due to the announced code freeze on July, 24th 
because you do not have enough time between code freeze and alpha 1? If 
so, the time between code freeze and alpha 1 seems too short.


Ulf

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Pierre Joye]

On Tue, Jul 15, 2008 at 7:05 PM, Ulf Wendel <[EMAIL PROTECTED]> wrote:
> Pierre Joye schrieb:
>>
>> On Tue, Jul 15, 2008 at 5:42 PM, Ulf Wendel <[EMAIL PROTECTED]> wrote:
>>
>>> What's your point, what requests are you talking about?
>>
>> Please ask Johannes, I told them to him live last time we met. If
>> there is doubts, I will happily repeat them.
>
> So, you have one question related to Windows builds - I did not know that.
>
> According to Johannes you both have chatted on IRC about it after you met.
> The chat did not help to clearify the question. Can you rephrase the
> question, what version of PHP are we talking about?
>
>>> I saw one person complaining about mysqlnd being compiled into PHP
>>> although
>>> no mysql extension was compiled into PHP: bug - open to anybody to fix.
>>
>> Ok, I will fix that as It does not make sense to enable mysqlnd when
>> no mysql extensions are enabled (but that's the least of my worries).
>
> Cool. Its annoying to see anything in a binary which is not needed (here:
> mysqlnd). Like it makes no sense to have ext/pdo compiled into PHP if no
> driver is compiled into PHP. I hope we're not down to a point where we
> really need consult each other for such a minor change...
>
>>>  PHP has a
>>> very vivid team of developers fixing many issues before they go down to
>>> the
>>> maintainers, see the constant work on bug reports. I relied on that to
>>> happen. Is that the issue you are talking about?
>>
>> How can that happen when you do many maybe unrelated changes in one
>> commit? How can I (or other) granulary review a commit in this case
>> (if something is broken)?
>
> I have no clue if Andrey has combined several fixes in one commit. At this
> point I have to rely on him choosing a proper granularity for a commit. Too
> large commits can always happen. You can work for a month in your local CVS
> copy and commit 100k at one - no difference.

Except that nobody does that for daily jobs and fixes.


>> We are one week before a freeze and we just see than one of the most
>> important change for this release is developed outside our tree, I
>> seriously hope that you understand our worries (I'm not alone to
>> worry). We may not have have the time to deal with the last minutes
>> issues introduced by a last minute sync (== disable).
>
> So, this is the real issue behind this discussion, or is there more, such as
> the Windows question from above?

No, the real issue is:  The extension should be developed and
maintained in php-src.

Whether we'll have to disable it or not if it is broken is a temporary
measure and is really unimportant.


> mysqlnd has been committed into PHP 5.3 branch (and into HEAD) in October
> 2007. Since then several updates have been comitted into the CVS. This is
> yet another update. For whatever reason you seem to see a difference between
> this and previous updates.

Because we were supposing that you maintain it only here and not only
syncing trees.

> Do you want to hint that no extension maintainer should update their
> extensions any more due to the announced code freeze on July, 24th because
> you do not have enough time between code freeze and alpha 1? If so, the time
> between code freeze and alpha 1 seems too short.

No, I ask why a core extension is developed outside php.net and synced
from time to time. I think I made this point clear.

Anyway, I don't have anything to say about this topic. I made my point
clear hopefully, if not then it is pointless to argue endlessly about
why maintaining a core extension outside php-src is a bad idea, we
will never agree.

-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Ulf Wendel]

Pierre Joye schrieb:

On Tue, Jul 15, 2008 at 7:05 PM, Ulf Wendel <[EMAIL PROTECTED]> wrote:

Pierre Joye schrieb:

On Tue, Jul 15, 2008 at 5:42 PM, Ulf Wendel <[EMAIL PROTECTED]> wrote:


What's your point, what requests are you talking about?

Please ask Johannes, I told them to him live last time we met. If
there is doubts, I will happily repeat them.

So, you have one question related to Windows builds - I did not know that.

According to Johannes you both have chatted on IRC about it after you met.
The chat did not help to clearify the question. Can you rephrase the
question, what version of PHP are we talking about?


Can you reply to this?

Ulf

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Andrey Hristov]

Pierre Joye wrote:

I have no clue if Andrey has combined several fixes in one commit. At this
point I have to rely on him choosing a proper granularity for a commit. Too
large commits can always happen. You can work for a month in your local CVS
copy and commit 100k at one - no difference.


Except that nobody does that for daily jobs and fixes.


The Zend guys are paid to develop and fix Zend.
The Oracle guys support oci8
Google gives Marcus time to do open-source work.
The company you work for supports you in your work on the PHP, because 
then they get first-class PHP developer in house. So, I am quite sure 
people are paid to do the work, one way or another.


Best,
Andrey

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Pierre Joye]

On Tue, Jul 15, 2008 at 7:47 PM, Andrey Hristov <[EMAIL PROTECTED]> wrote:
> Pierre Joye wrote:
>>>
>>> I have no clue if Andrey has combined several fixes in one commit. At
>>> this
>>> point I have to rely on him choosing a proper granularity for a commit.
>>> Too
>>> large commits can always happen. You can work for a month in your local
>>> CVS
>>> copy and commit 100k at one - no difference.
>>
>> Except that nobody does that for daily jobs and fixes.
>
> The Zend guys are paid to develop and fix Zend.
> The Oracle guys support oci8
> Google gives Marcus time to do open-source work.
> The company you work for supports you in your work on the PHP, because then
> they get first-class PHP developer in house. So, I am quite sure people are
> paid to do the work, one way or another.

That's not what I meant, by daily jobs I meant daily commits (be fix
or adding a feature).


Cheers,
-- 
Pierre

http://blog.thepimp.net | http://www.libgd.org

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Andrey Hristov]

Pierre Joye wrote:

On Tue, Jul 15, 2008 at 7:47 PM, Andrey Hristov <[EMAIL PROTECTED]> wrote:

Pierre Joye wrote:

I have no clue if Andrey has combined several fixes in one commit. At
this
point I have to rely on him choosing a proper granularity for a commit.
Too
large commits can always happen. You can work for a month in your local
CVS
copy and commit 100k at one - no difference.

Except that nobody does that for daily jobs and fixes.

The Zend guys are paid to develop and fix Zend.
The Oracle guys support oci8
Google gives Marcus time to do open-source work.
The company you work for supports you in your work on the PHP, because then
they get first-class PHP developer in house. So, I am quite sure people are
paid to do the work, one way or another.


That's not what I meant, by daily jobs I meant daily commits (be fix
or adding a feature).


What do you mean? That every addition should be committed daily in small 
chunks? A feature is a feature, it's integral. Because CVS hinders the 
easiness of work to commit several changeset from a local repository to 
the main one, even just announcing the patches, without even committing 
them to the main repository, shows that you will support some 
distributed RCS to be used for PHP. CVS is ok for 1-2 people touching 
the same code but not for cooperative development without much of 
external communication.


Best,
Andrey

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

Re: [PHP-DEV] lstat call on each directory level

[Rasmus Lerdorf]

Amir Hardon wrote:

I've noticed a weird behavior when doing file access from PHP:
PHP seems to make an lstat call on each of the parent directories of the
accessed file, for example see this script:



When running with strace -e lstat I see this:
lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
lstat("/var/www/metacafe", {st_mode=S_IFDIR|0755, st_size=4096, ...}) =
0
lstat("/var/www/metacafe/test", 0x7fbfff9b10) = -1 ENOENT (No such file
or directory)

Measuring total syscalls time for an apache process on a production
server, I found out
that ~33% of the time it spends in syscalls is spent on lstat.

I did a pretty deep web search on the issue and came out with nothing.
I'll also note that I did a small experiment - moving our root portal
folder to /,
this gave an amazing performance improvement!

So my questions are:
What is the reason for doing these lstat calls?
How can it be disabled? if not by configuration, maybe by patching php
(can you direct me to where is this being done in php's source?)


That's a realpath() call and it should be getting cached by the realpath 
cache, so if you are seeing these on every request, try increasing your 
realpath_cache size in your .ini.  Without checking the realpath, you 
would be able to circumvent open_basedir checking really easily with a 
symlink.


-Rasmus

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/mysql php_mysql.c /ext/mysqli mysqli.c /ext/mysqlnd mysqlnd.c mysqlnd_palloc.c mysqlnd_ps.c mysqlnd_wireprotocol.c

[Ulf Wendel]

Marcus Boerger schrieb:

Tuesday, July 15, 2008, 4:32:10 PM, you wrote:


Pierre Joye schrieb:

Drop the launchpad and use php's cvs. We have actually two development
branches (5.3 until the 24th and HEAD) and PECL. The latter let you
experiment as much as you wish.


Pierre, you are not in the position to tell us what repository we use 
for internal developments and experimental features.


Or should I start flaming againt the developing of a new PHP parser at 
svn://whisky.macvicar.net/php-re2c . Looks like there are two classes of 
developers in your world. The bad and the good. The good can use their 
own repositories. The bad may not. And MySQL is bad.


You really proove here that a) our communication needs to get better and
that blogs don't help as they are ignored ffrom most developers. And b) we
reallt need to most to a better repository like SVN or HG.

Other than that, nobody tells you what you do or use. We just would like to
know. And in regards to re2c I can only repeat what Scott said. It was a
one time experiment that was announced on the list to be followed along and
comitted as a whole as soon as agreed on (not when finished to be precise).


You get me wrong.

I know very well that blogs and development lists do have different 
target audiences. And I know that PHP development and development 
discussions do not only take place on the mailing lists but also on open 
and closed IRC channels as well as during public and private meeeting. I 
tried to follow the circus several years in the past but I settled down 
as you know...


If I blog about PDO bugs and post bug summaries, its for the users and 
readers of the Planets. Being asked about the status, I would not 
hesitate to post a blog URL again over here.


I am not asking for improvements around CVS. I am not convinced that a 
system should be used which can link to other repositories. The re2c 
decision is perfectly valid. Such as its valid to keep local copies of 
the CVS and work on them - even if those local copies reside in yet 
another repository.


Marcus, we don't need to discuss the pros and cons of this in length. 
Your message has been clear in your first reply to the commit. Same goes 
for Jani (or a little later Lukas). Day-to-day mysqlnd changes shall go 
into the CVS as soon as possible. Andrey already explained that he 
applied hot fixes to the CVS (only) recently. Larger changes, new ideas 
might not go into HEAD in the first place but mature on the disk of the 
developer before they get published.


This is not about commercial vs. non-commercial. There are no plans for 
commerical features in mysqlnd which would require a secret repository. 
The code will always go public. A little sooner without an internal 
review or a little later after a mandatory internal review. To me this 
seems similar to two PHP fellows discussing a patch in private for some 
time.


I was recently asked about Unicode support in Postgres and MySQL. The 
question implied that Postgres is said to be ahead of MySQL. After all 
the years, I'm a bit tired of such questions. I replied with an 
enumeration of the advantages of the two systems. Hey, this reminds me a 
bit of this discussion.


To reply to your last point: I don't think the communication between us 
is not working. For example, Jani's short reminder on open ext/mysqli 
bugs (try the search again...) is almost sure to cause a re-allocation 
of Andrey for a few days. And believe me, even those few days hurt and 
cause discussions.


Ulf

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

[PHP-DEV] Namespace problem?

[Stefan Priebsch]

Hi list,

I was playing around with namespaces and stumbled across this:

#!/home/steve/php5.3-200807070430/sapi/cli/php


works fine, whereas

#!/home/steve/php5.3-200807070430/sapi/cli/php


yields: Parse error: syntax error, unexpected T_USE
in /home/steve/namespaces/code/with_braces.php on line 6

Regards,

Stefan

-- 
 >e-novative> - We make IT work for you.
 http://www.e-novative.de

 e-novative GmbH - Poignring 24 - 82515 Wolfratshausen - Germany
 tel/phone +49 (0)8171 267 087 0 - fax +49 (0)8171 267 087 5

 Handelsregister/Trade Register: Amtsgericht München HRB 139407
 Sitz/Registered Office: Wolfratshausen
 Geschäftsführer/Executive:  Dipl. Inform. Stefan Priebsch
 GnuPG Key: 0x7DB67F7F


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

Re: [PHP-DEV] lstat call on each directory level

[Amir Hardon]

On Tue, 2008-07-15 at 11:40 -0700, Rasmus Lerdorf wrote:

> Amir Hardon wrote:
> > I've noticed a weird behavior when doing file access from PHP:
> > PHP seems to make an lstat call on each of the parent directories of the
> > accessed file, for example see this script:
> > 
> >  > $fp=fopen("/var/www/metacafe/test","r");
> > fclose($fp);
> > ?>
> > 
> > When running with strace -e lstat I see this:
> > lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
> > lstat("/var/www/metacafe", {st_mode=S_IFDIR|0755, st_size=4096, ...}) =
> > 0
> > lstat("/var/www/metacafe/test", 0x7fbfff9b10) = -1 ENOENT (No such file
> > or directory)
> > 
> > Measuring total syscalls time for an apache process on a production
> > server, I found out
> > that ~33% of the time it spends in syscalls is spent on lstat.
> > 
> > I did a pretty deep web search on the issue and came out with nothing.
> > I'll also note that I did a small experiment - moving our root portal
> > folder to /,
> > this gave an amazing performance improvement!
> > 
> > So my questions are:
> > What is the reason for doing these lstat calls?
> > How can it be disabled? if not by configuration, maybe by patching php
> > (can you direct me to where is this being done in php's source?)
> 
> That's a realpath() call and it should be getting cached by the realpath 
> cache, so if you are seeing these on every request, try increasing your 
> realpath_cache size in your .ini.  Without checking the realpath, you 
> would be able to circumvent open_basedir checking really easily with a 
> symlink.
> 
> -Rasmus


I've already increased the realpath_cache to the point it didn't give
any more benefit(And it did give benefit),
but there are still many lstat calls, and still placing our portal dir
in the root directory gave a huge performance benefit(After fine-tuning
realpath_cache).
We don't use open_basedir.

I think it might be wise to make this dir check configurable, as the
performance impact is major.
Anyway - can you please direct me to the place where this check is made
in php's source, so I'll be able to disable it manually?


Thanks!
-Amir.

Re: [PHP-DEV] lstat call on each directory level

[Derick Rethans]

On Tue, 15 Jul 2008, Amir Hardon wrote:

> On Tue, 2008-07-15 at 11:40 -0700, Rasmus Lerdorf wrote:
> 
> > That's a realpath() call and it should be getting cached by the 
> > realpath cache, so if you are seeing these on every request, try 
> > increasing your realpath_cache size in your .ini.  Without checking 
> > the realpath, you would be able to circumvent open_basedir checking 
> > really easily with a symlink.
> 
> I've already increased the realpath_cache to the point it didn't give 
> any more benefit(And it did give benefit), but there are still many 
> lstat calls, and still placing our portal dir in the root directory 
> gave a huge performance benefit(After fine-tuning realpath_cache). We 
> don't use open_basedir.
> 
> I think it might be wise to make this dir check configurable, as the 
> performance impact is major. Anyway - can you please direct me to the 
> place where this check is made in php's source, so I'll be able to 
> disable it manually?

I've a patch for php 4.3 and 4.4 online - based on a patch by rasmus:
http://files.derickrethans.nl/patches/php-4.3-skip-path-checks.patch
http://files.derickrethans.nl/patches/php-4.4-skip-path-checks.patch

regards,
Derick

-- 
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

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

Re: [PHP-DEV] lstat call on each directory level

[Rasmus Lerdorf]

Amir Hardon wrote:

On Tue, 2008-07-15 at 11:40 -0700, Rasmus Lerdorf wrote:

Amir Hardon wrote:
> I've noticed a weird behavior when doing file access from PHP:
> PHP seems to make an lstat call on each of the parent directories of the
> accessed file, for example see this script:
> 
> 
> $fp=fopen("/var/www/metacafe/test","r");
> fclose($fp);
> ?>
> 
> When running with strace -e lstat I see this:

> lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
> lstat("/var/www/metacafe", {st_mode=S_IFDIR|0755, st_size=4096, ...}) =
> 0
> lstat("/var/www/metacafe/test", 0x7fbfff9b10) = -1 ENOENT (No such file
> or directory)
> 
> Measuring total syscalls time for an apache process on a production

> server, I found out
> that ~33% of the time it spends in syscalls is spent on lstat.
> 
> I did a pretty deep web search on the issue and came out with nothing.

> I'll also note that I did a small experiment - moving our root portal
> folder to /,
> this gave an amazing performance improvement!
> 
> So my questions are:

> What is the reason for doing these lstat calls?
> How can it be disabled? if not by configuration, maybe by patching php
> (can you direct me to where is this being done in php's source?)

That's a realpath() call and it should be getting cached by the realpath 
cache, so if you are seeing these on every request, try increasing your 
realpath_cache size in your .ini.  Without checking the realpath, you 
would be able to circumvent open_basedir checking really easily with a 
symlink.


-Rasmus


I've already increased the realpath_cache to the point it didn't give 
any more benefit(And it did give benefit),
but there are still many lstat calls, and still placing our portal dir 
in the root directory gave a huge performance benefit(After fine-tuning 
realpath_cache).

We don't use open_basedir.

I think it might be wise to make this dir check configurable, as the 
performance impact is major.
Anyway - can you please direct me to the place where this check is made 
in php's source, so I'll be able to disable it manually?


Well, it is used in other places too, like in figuring out _once paths. 
 Including the same file using different paths still needs to be caught.


Are you calling clearstatcache() manually anywhere?  That blows away the 
entire realpath cache and completely destroys your performance, so you 
will want to avoid doing that very often.


-Rasmus


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

Re: [PHP-DEV] lstat call on each directory level

[Amir Hardon]

On Tue, 2008-07-15 at 12:25 -0700, Rasmus Lerdorf wrote:

> Amir Hardon wrote:
> > On Tue, 2008-07-15 at 11:40 -0700, Rasmus Lerdorf wrote:
> >> Amir Hardon wrote:
> >> > I've noticed a weird behavior when doing file access from PHP:
> >> > PHP seems to make an lstat call on each of the parent directories of the
> >> > accessed file, for example see this script:
> >> > 
> >> >  >> > $fp=fopen("/var/www/metacafe/test","r");
> >> > fclose($fp);
> >> > ?>
> >> > 
> >> > When running with strace -e lstat I see this:
> >> > lstat("/var", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> >> > lstat("/var/www", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
> >> > lstat("/var/www/metacafe", {st_mode=S_IFDIR|0755, st_size=4096, ...}) =
> >> > 0
> >> > lstat("/var/www/metacafe/test", 0x7fbfff9b10) = -1 ENOENT (No such file
> >> > or directory)
> >> > 
> >> > Measuring total syscalls time for an apache process on a production
> >> > server, I found out
> >> > that ~33% of the time it spends in syscalls is spent on lstat.
> >> > 
> >> > I did a pretty deep web search on the issue and came out with nothing.
> >> > I'll also note that I did a small experiment - moving our root portal
> >> > folder to /,
> >> > this gave an amazing performance improvement!
> >> > 
> >> > So my questions are:
> >> > What is the reason for doing these lstat calls?
> >> > How can it be disabled? if not by configuration, maybe by patching php
> >> > (can you direct me to where is this being done in php's source?)
> >>
> >> That's a realpath() call and it should be getting cached by the realpath 
> >> cache, so if you are seeing these on every request, try increasing your 
> >> realpath_cache size in your .ini.  Without checking the realpath, you 
> >> would be able to circumvent open_basedir checking really easily with a 
> >> symlink.
> >>
> >> -Rasmus
> > 
> > I've already increased the realpath_cache to the point it didn't give 
> > any more benefit(And it did give benefit),
> > but there are still many lstat calls, and still placing our portal dir 
> > in the root directory gave a huge performance benefit(After fine-tuning 
> > realpath_cache).
> > We don't use open_basedir.
> > 
> > I think it might be wise to make this dir check configurable, as the 
> > performance impact is major.
> > Anyway - can you please direct me to the place where this check is made 
> > in php's source, so I'll be able to disable it manually?
> 
> Well, it is used in other places too, like in figuring out _once paths. 
>   Including the same file using different paths still needs to be caught.
> 
> Are you calling clearstatcache() manually anywhere?  That blows away the 
> entire realpath cache and completely destroys your performance, so you 
> will want to avoid doing that very often.
> 
> -Rasmus
> 


About clearstatcache() - not using it at all.

Correct me if I'm wrong but this realpath cache is a per-request cache
(when using php as an apache module),
so unless I'm wrong ,the performance benefit I'm getting when moving the
portal to the / dir should be obvious
(our code is splitted to many files, and each file that is being
required, is generating few lstat calls).

About the issue with the _once, did the patch Derick offered handles it
(I haven't examined it yet).
If not, I just need to make sure that the same file isn't being
referenced by two paths and I'm safe right?
(I mean assuming I'll adjust it to php5)



Thanks again to both of you!
-Amir.

Re: [PHP-DEV] lstat call on each directory level

[Travis Swicegood]

On Jul 15, 2008, at 2:25 PM, Rasmus Lerdorf wrote:

Well, it is used in other places too, like in figuring out _once  
paths.  Including the same file using different paths still needs  
to be caught.


Are you calling clearstatcache() manually anywhere?  That blows  
away the entire realpath cache and completely destroys your  
performance, so you will want to avoid doing that very often.


Based on what I've seen, if the realpath cache gets filled it just  
quits caching rather than pruning.  That seemed odd to me.


There was also an issue that Dmitry had fixed in 5.3 a month or so  
ago where it was caching false finds and filling the cache up more  
quickly than necessary.  I found this out through a quick extension I  
wrote to view the contents of the realpath cache.  If anyone wants to  
clean this up for inclusion in the core, I'd be more than happy to  
have it there.  You can grab a copy from my Git server:

git://git.domain51.com/php.realpath.git

-T

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

[PHP-DEV] Include/require into namespace

[Geoffrey Sneddon]

Hi,

With the impending release of PHP 5.3 and the addition of namespaces  
into PHP, there becomes the issue of integrating libraries that are  
designed to still support PHP 4 (please, don't turn this into a  
discussion about whether they should or not: this _is_ a real issue)  
into something designed to use namespaces throughout. A simple  
solution would be to just include/require a file _into_ a namespace,  
which makes the default namespace in that file that namespace.


e.g. (inc. the case of defining a namespace in the included into a  
namespace file),


a.php:


b.php:


Expected output:
Hello, world!
Wow! This is in a namespace both here and there!


--
Geoffrey Sneddon



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

Re: [PHP-DEV] lstat call on each directory level

[Derick Rethans]

On Tue, 15 Jul 2008, Amir Hardon wrote:

> About the issue with the _once, did the patch Derick offered handles 
> it (I haven't examined it yet). If not, I just need to make sure that 
> the same file isn't being referenced by two paths and I'm safe right? 

It does not do any real path checks, so it gives issues when you include 
the same file with two different paths in the include statement. Your 
assesment is correct and just making sure you include them the same way 
does the trick.

regards,
Derick
-- 
Derick Rethans
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org

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

Re: [PHP-DEV] tentative 5.3 release plan

[Christopher Jones]

Lukas Kahwe Smith wrote:

> In our dreams someone would also make PDO a focus area, since the number
> of open bugs is getting ridiculous. This is also a call to the general
> community to try and help to find a PDO maintainer. In the mean time
> people not adapt in C might at least try and plow through the bug
> tickets to find duplicates and verify the open tickets, write tests etc.

For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only
produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll.
The latter uses an older set of Oracle client libraries that allows
connections to Oracle 7 and 8.0 databases.

The impact is that users on Windows will no longer be able to connect
to the older databases unless they compile the extension themselves.

The benefit is reduced user confusion and PDO maintenance.

The change is to remove the pdo-oci8 section of ext/pdo_oci/config.w32
and tidy up associated Windows DLL release infrastructre.

Chris

--
Christopher Jones, Oracle
Email: [EMAIL PROTECTED]Tel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/   Free PHP Book: http://tinyurl.com/f8jad

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

Re: [PHP-DEV] tentative 5.3 release plan

[Lukas Kahwe Smith]

On 15.07.2008, at 23:09, Christopher Jones wrote:



Lukas Kahwe Smith wrote:

> In our dreams someone would also make PDO a focus area, since the  
number
> of open bugs is getting ridiculous. This is also a call to the  
general

> community to try and help to find a PDO maintainer. In the mean time
> people not adapt in C might at least try and plow through the bug
> tickets to find duplicates and verify the open tickets, write  
tests etc.


For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only
produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll.
The latter uses an older set of Oracle client libraries that allows
connections to Oracle 7 and 8.0 databases.

The impact is that users on Windows will no longer be able to connect
to the older databases unless they compile the extension themselves.

The benefit is reduced user confusion and PDO maintenance.

The change is to remove the pdo-oci8 section of ext/pdo_oci/config.w32
and tidy up associated Windows DLL release infrastructre.



I guess for windows it just comes down to what we bundle. We could  
still support older Oracle versions with an optional download. If we  
want to be super fancy, we might even include a note in an error  
message when trying to connect to older versions that there is  
pdo_oci8 available as an optional download from win.php.net (or  
whatever our pecl4win.php.net replacement will be).


regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]




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

Re: [PHP-DEV] tentative 5.3 release plan

[Daniel Convissor]

On Tue, Jul 15, 2008 at 02:09:33PM -0700, Christopher Jones wrote:
> 
> For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only
> produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll.
> The latter uses an older set of Oracle client libraries that allows
> connections to Oracle 7 and 8.0 databases.
> 
> The impact is that users on Windows will no longer be able to connect
> to the older databases unless they compile the extension themselves.

Removing it completely or requring people to build it themselves is 
sub-optimal.  If you really want it out of PHP, please make it a PECL 
package.

Thanks,

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
 4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409

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

Re: [PHP-DEV] lstat call on each directory level

[Lars Strojny]

Hi Rasmus,

Am Dienstag, den 15.07.2008, 11:40 -0700 schrieb Rasmus Lerdorf:
[...]
> That's a realpath() call and it should be getting cached by the realpath 
> cache, so if you are seeing these on every request, try increasing your 
> realpath_cache size in your .ini.  Without checking the realpath, you 
> would be able to circumvent open_basedir checking really easily with a 
> symlink.

Couldn't we do that check only if open_basedir is active?

cu, Lars


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: [PHP-DEV] lstat call on each directory level

[Rasmus Lerdorf]

Lars Strojny wrote:

Hi Rasmus,

Am Dienstag, den 15.07.2008, 11:40 -0700 schrieb Rasmus Lerdorf:
[...]
That's a realpath() call and it should be getting cached by the realpath 
cache, so if you are seeing these on every request, try increasing your 
realpath_cache size in your .ini.  Without checking the realpath, you 
would be able to circumvent open_basedir checking really easily with a 
symlink.


Couldn't we do that check only if open_basedir is active?


Like I said, it is used for other things too, like include_once filename 
resolution.  Check the code.


-Rasmus

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

Re: [PHP-DEV] tentative 5.3 release plan

[Christopher Jones]

Daniel Convissor wrote:

On Tue, Jul 15, 2008 at 02:09:33PM -0700, Christopher Jones wrote:

For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only
produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll.
The latter uses an older set of Oracle client libraries that allows
connections to Oracle 7 and 8.0 databases.

The impact is that users on Windows will no longer be able to connect
to the older databases unless they compile the extension themselves.


Removing it completely or requring people to build it themselves is 
sub-optimal.  If you really want it out of PHP, please make it a PECL 
package.


The plan is to continue shipping php_pdo_oci.dll.  This allows users
to use PDO_OCI to connect to Oracle 8.1, 9.2, 10 and 11 Databases.

The codebase for php_pdo_oci.dll and php_pdo_oci8.dll is the same  (and
only one can be enabled at a given time)

Non-windows users of PDO_OCI would be not affected in anyway whatsoever.

Chris

--
Christopher Jones, Oracle
Email: [EMAIL PROTECTED]Tel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/   Free PHP Book: http://tinyurl.com/f8jad

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

Re: [PHP-DEV] tentative 5.3 release plan

[Christopher Jones]

Lukas Kahwe Smith wrote:
>
> On 15.07.2008, at 23:09, Christopher Jones wrote:
>
>>
>> Lukas Kahwe Smith wrote:
>>
>> > In our dreams someone would also make PDO a focus area, since the
>> number
>> > of open bugs is getting ridiculous. This is also a call to the general
>> > community to try and help to find a PDO maintainer. In the mean time
>> > people not adapt in C might at least try and plow through the bug
>> > tickets to find duplicates and verify the open tickets, write tests
>> etc.
>>
>> For PHP 5.3 on, I'd be happy to see the Windows builds of PDO_OCI only
>> produce php_pdo_oci.dll and no longer also build php_pdo_oci8.dll.
>> The latter uses an older set of Oracle client libraries that allows
>> connections to Oracle 7 and 8.0 databases.
>
> I guess for windows it just comes down to what we bundle.
>
> We could still support older Oracle versions with an optional
> download. If we want to be super fancy, we might even include a note
> in an error message when trying to connect to older versions that
> there is pdo_oci8 available as an optional download from win.php.net
> (or whatever our pecl4win.php.net replacement will be).

I'd prefer to keep the status quo instead of making the build more
complex.  The idea was to simplify the distribution and move forward.

The DB versions in question are Oracle 7 - released in 1993, and
Oracle 8.0 - released in 1997, IIRC.  These versions are even more
uncommon than when PDO_OCI was created in back 2004.

Users of more recent DBs (or on non-Windows platforms) won't be
affected in anyway.

The workaround of building your own PHP on Windows is less of a
problem now there is improved Windows build infrastructure and
documentation.

Chris

--
Christopher Jones, Oracle
Email: [EMAIL PROTECTED]Tel:  +1 650 506 8630
Blog:  http://blogs.oracle.com/opal/   Free PHP Book: http://tinyurl.com/f8jad

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

Re: [PHP-DEV] lstat call on each directory level

[Oleg Grenrus]

There is
apc.include_once_override
Optimize include_once() and require_once()  calls and avoid the
expensive system calls used.

and
apc.stat

Be careful if you change this setting. The default is for this to be
On which means that APC will stat (check) the script on each request
to see if it has been modified. If it has been modified it will
recompile and cache the new version. If you turn this setting off, it
will not check. That means that in order to have changes become active
you need to restart your web server. On a production server where you
rarely change the code, turning stats off can produce a significant
performance boost.

For included/required files this option applies as well, but note that
if you are using relative path includes (any path that doesn't start
with / on Unix) APC has to check in order to uniquely identify the
file. If you use absolute path includes APC can skip the stat and use
that absolute path as the unique identifier for the file.

You might try APC. It stats, but not so much


On Wed, Jul 16, 2008 at 1:20 AM, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
> Lars Strojny wrote:
>>
>> Hi Rasmus,
>>
>> Am Dienstag, den 15.07.2008, 11:40 -0700 schrieb Rasmus Lerdorf:
>> [...]
>>>
>>> That's a realpath() call and it should be getting cached by the realpath
>>> cache, so if you are seeing these on every request, try increasing your
>>> realpath_cache size in your .ini.  Without checking the realpath, you would
>>> be able to circumvent open_basedir checking really easily with a symlink.
>>
>> Couldn't we do that check only if open_basedir is active?
>
> Like I said, it is used for other things too, like include_once filename
> resolution.  Check the code.
>
> -Rasmus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



-- 
Oleg Grenrus

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

Re: [PHP-DEV] tentative 5.3 release plan

[Lukas Kahwe Smith]

On 16.07.2008, at 00:50, Christopher Jones wrote:


> We could still support older Oracle versions with an optional
> download. If we want to be super fancy, we might even include a note
> in an error message when trying to connect to older versions that
> there is pdo_oci8 available as an optional download from win.php.net
> (or whatever our pecl4win.php.net replacement will be).

I'd prefer to keep the status quo instead of making the build more
complex.  The idea was to simplify the distribution and move forward.

The DB versions in question are Oracle 7 - released in 1993, and
Oracle 8.0 - released in 1997, IIRC.  These versions are even more
uncommon than when PDO_OCI was created in back 2004.



Well for Oracle 7 I can definitely see it, but Oracle 8 will still be  
in production in plenty of places. I am fine with not supporting them  
out of the box, but I think we should try to offer them a download  
from PECL by the time 5.3.0 ships. That being said the world will not  
end for me if we do not provide this, especially since I assume very  
few people will have Oracle 8 and running a PDO based app on windows.  
Most people will probably be using ext/oci8 for this kind of setup.


regards,
Lukas Kahwe Smith
[EMAIL PROTECTED]




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

Re: [PHP-DEV] Namespace problem?

[Alexey Zakhlestin]

On Tue, Jul 15, 2008 at 8:08 PM, Stefan Priebsch <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> I was playing around with namespaces and stumbled across this:
>
> #!/home/steve/php5.3-200807070430/sapi/cli/php
> 
>  namespace Foo;
>
>  use Foo::Bar as Something;
>
>  class Bar { }
>
> ?>
>
> works fine, whereas
>
> #!/home/steve/php5.3-200807070430/sapi/cli/php
> 
>  namespace Foo;
>  {
>use Foo::Bar as Something;
>
>class Bar { }
>  }
>
> ?>
>
> yields: Parse error: syntax error, unexpected T_USE
> in /home/steve/namespaces/code/with_braces.php on line 6

"use" is a file-level construct, as far as I remember, so you can't
put it into block

-- 
Alexey Zakhlestin
http://blog.milkfarmsoft.com/