Re: [PHP-DEV] tentative 5.3 release plan
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?
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
?php
namespace Foo;
use Foo::Bar as Something;
class Bar { }
?
works fine, whereas
#!/home/steve/php5.3-200807070430/sapi/cli/php
?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/
Re: [PHP-DEV] Namespace problem?
On Wed, Jul 16, 2008 at 08:50, Alexey Zakhlestin [EMAIL PROTECTED] wrote:
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
?php
namespace Foo;
use Foo::Bar as Something;
class Bar { }
?
works fine, whereas
#!/home/steve/php5.3-200807070430/sapi/cli/php
?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
I thought the only argument against using curly braces for namespaces
was exactly his example you can use namespace foo; {} if you really
want to?
-Hannes
Re: [PHP-DEV] Namespace problem?
On Wed, Jul 16, 2008 at 11:34 AM, Hannes Magnusson
[EMAIL PROTECTED] wrote:
I thought the only argument against using curly braces for namespaces
was exactly his example you can use namespace foo; {} if you really
want to?
OK:
namespace foo;
{
}
Not OK:
{
use Foo:Bar as Something;
}
--
Alexey Zakhlestin
http://blog.milkfarmsoft.com/
--
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
Hello. I think this should be optimized. I'm not an expert ofcourse, but as I understood there is only one case witch need a special treatment - require/include _one when a file with equal contents is included from different directories. You can make a switch witch controls if lstat is made or not in these cases. People who know what they are doing will switch it to off and make sure their includes don't result in Fatal error (anyway, to my opinion it is bad desing if such thing happens). Ofcourse open_basedir users will don't have any benefit from it, but that's their choise. So I think you should think it out and make this optimization to 5.3 release. It would be great optimization, IMHO.
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
Hello Andrey, Tuesday, July 15, 2008, 6:30:50 PM, you wrote: 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. Well, then he wouldn't be able to follow PHP development and hence would develop PDO in a non PHP way. That said it is no wonder I have always been against these special cases. We are chaos and that takes time. Yet we decided for ourself to be the open platform where users have direct influence if they whish to. Given our success I see no reason to change this. 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 Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP] Changing PHP.ini
I had the same problem 2 days ago, the thing is the ; - display_errors = off in line 74 is just information. You have another display_errors (mine is in line 374) change that to: on. Op 16 jul 2008, om 04:34 heeft Thorsten Suckow-Homberg het volgende geschreven: By visiting php.info in a web browser I have confirmed the location of my php.ini file as /usr/local/php5/lib/php.ini. I open that file and edit the line: ; - display_errors = Off and change it to display_errors = On I then retstart Appache and visit php.info which still reports display_errors = Off. What else can I do? Should be simple: create a script with the following code: ?php phpinfo(); ? Then open that script in your browser. The generated output does also provide information about the path of the loaded php.ini. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- 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
Arvids Godjuks wrote: Hello. I think this should be optimized. I'm not an expert ofcourse, but as I understood there is only one case witch need a special treatment - require/include _one when a file with equal contents is included from different directories. You can make a switch witch controls if lstat is made or not in these cases. People who know what they are doing will switch it to off and make sure their includes don't result in Fatal error (anyway, to my opinion it is bad desing if such thing happens). Ofcourse open_basedir users will don't have any benefit from it, but that's their choise. So I think you should think it out and make this optimization to 5.3 release. It would be great optimization, IMHO. But all these lstats should be getting cached, so I don't see how it would affect performance very much. If you are blowing your realpath cache, you need to take a look at why that is happening. We probably should disconnect clearstatcache() from the realpath_cache, and we could perhaps look at doing partial path caches through our own realpath implementation. The other thing that can suck is when you have an include_path miss. We don't cache misses like this, so if you are relying on include_path to find your files and you don't hit it on the first try, you are going to see a bunch of stats. But that is again something that is easily fixed by not writing crappy code. I think that breaking code that looks like this: require_once './a.inc'; require_once 'a.inc'; require_once '../a.inc'; require_once 'includes/a.inc'; when these all refer to the same a.inc file depending on where the parent file is and what the coder had for breakfast that morning would be a very bad idea. -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
Lukas Kahwe Smith wrote: 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. Of the Oracle 8.x releases, there will be more 8.1 in use than 8.0 and only the latter is directly affected. Php_pdo_oci.dll will connect to Oracle 8.1. 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
On 16.07.2008, at 16:13, Christopher Jones wrote: Lukas Kahwe Smith wrote: 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. Of the Oracle 8.x releases, there will be more 8.1 in use than 8.0 and only the latter is directly affected. Php_pdo_oci.dll will connect to Oracle 8.1. Ah ok, I was thinking 8.x .. now it makes more sense to me. 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 schrieb:
OK:
namespace foo;
{
}
Not OK:
{
use Foo:Bar as Something;
}
Then that is a showstopper that effectively does not allow to use braces
around a namespace, so I'd boldly suggest either fixing the curly braces
notation to allow use statements or disallow curly braces around
namespaces, because as it is, it doesn't really seem useful.
Regards,
Stefan
--
e-novative - We make IT work for you.
e-novative GmbH - HR: Amtsgericht München HRB 139407
Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch
http://www.e-novative.de - GnuPG Key: 0x7DB67F7F
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace problem?
The use can be used only as top-level statement.
Thanks. Dmitry.
Stefan Priebsch wrote:
Hi list,
I was playing around with namespaces and stumbled across this:
#!/home/steve/php5.3-200807070430/sapi/cli/php
?php
namespace Foo;
use Foo::Bar as Something;
class Bar { }
?
works fine, whereas
#!/home/steve/php5.3-200807070430/sapi/cli/php
?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
Regards,
Stefan
--
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
On Tue, 15 Jul 2008, Andrey Hristov wrote: 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. Sorry, but those things should go to the mailinglist. Have it also on a blog is fine, but I doubt every php developer follows planet PHP as there's so much nonsense on it. 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] 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
Derick Rethans schrieb: On Tue, 15 Jul 2008, Andrey Hristov wrote: 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. Sorry, but those things should go to the mailinglist. Have it also on a blog is fine, but I doubt every php developer follows planet PHP as there's so much nonsense on it. I'm sure there's no need to discuss the differences between an article/blogging and development discussions on other channels. Is there any particular blog posting which has been must go dev-list in your eyes? Ulf -- 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
On Wed, 2008-07-16 at 06:45 -0700, Rasmus Lerdorf wrote: Arvids Godjuks wrote: Hello. I think this should be optimized. I'm not an expert ofcourse, but as I understood there is only one case witch need a special treatment - require/include _one when a file with equal contents is included from different directories. You can make a switch witch controls if lstat is made or not in these cases. People who know what they are doing will switch it to off and make sure their includes don't result in Fatal error (anyway, to my opinion it is bad desing if such thing happens). Ofcourse open_basedir users will don't have any benefit from it, but that's their choise. So I think you should think it out and make this optimization to 5.3 release. It would be great optimization, IMHO. But all these lstats should be getting cached, so I don't see how it would affect performance very much. If you are blowing your realpath cache, you need to take a look at why that is happening. We probably should disconnect clearstatcache() from the realpath_cache, and we could perhaps look at doing partial path caches through our own realpath implementation. The other thing that can suck is when you have an include_path miss. We don't cache misses like this, so if you are relying on include_path to find your files and you don't hit it on the first try, you are going to see a bunch of stats. But that is again something that is easily fixed by not writing crappy code. I think that breaking code that looks like this: require_once './a.inc'; require_once 'a.inc'; require_once '../a.inc'; require_once 'includes/a.inc'; when these all refer to the same a.inc file depending on where the parent file is and what the coder had for breakfast that morning would be a very bad idea. -Rasmus Since the realpath cache is only relevant for a single request(right?), removing these lstats calls will a major benefit. Before moving our portal dir to the / dir, ~40% of our page requests were slow on the server side (I'm not sure if my company policies allow me to expose exactly what is considered slow), after moving it ~20% of the page requests were slow! this is significant. And there are still many lstat calls made inside our portal's directory tree. So I think that a php.ini directive for switching off these lstats which will be off by default, will be a great thing. -Amir.
Re: [PHP-DEV] lstat call on each directory level
Amir Hardon wrote: On Wed, 2008-07-16 at 06:45 -0700, Rasmus Lerdorf wrote: Arvids Godjuks wrote: Hello. I think this should be optimized. I'm not an expert ofcourse, but as I understood there is only one case witch need a special treatment - require/include _one when a file with equal contents is included from different directories. You can make a switch witch controls if lstat is made or not in these cases. People who know what they are doing will switch it to off and make sure their includes don't result in Fatal error (anyway, to my opinion it is bad desing if such thing happens). Ofcourse open_basedir users will don't have any benefit from it, but that's their choise. So I think you should think it out and make this optimization to 5.3 release. It would be great optimization, IMHO. But all these lstats should be getting cached, so I don't see how it would affect performance very much. If you are blowing your realpath cache, you need to take a look at why that is happening. We probably should disconnect clearstatcache() from the realpath_cache, and we could perhaps look at doing partial path caches through our own realpath implementation. The other thing that can suck is when you have an include_path miss. We don't cache misses like this, so if you are relying on include_path to find your files and you don't hit it on the first try, you are going to see a bunch of stats. But that is again something that is easily fixed by not writing crappy code. I think that breaking code that looks like this: require_once './a.inc'; require_once 'a.inc'; require_once '../a.inc'; require_once 'includes/a.inc'; when these all refer to the same a.inc file depending on where the parent file is and what the coder had for breakfast that morning would be a very bad idea. -Rasmus Since the realpath cache is only relevant for a single request(right?), removing these lstats calls will a major benefit. No, of course not. It would be a useless cache if that was the case. The cache spans requests. Before moving our portal dir to the / dir, ~40% of our page requests were slow on the server side (I'm not sure if my company policies allow me to expose exactly what is considered slow), after moving it ~20% of the page requests were slow! this is significant. And there are still many lstat calls made inside our portal's directory tree. Yes, you need to figure out why you are not hitting the cache, or why you are seeing so many lstat calls. There are 3 main possibilities: 1. You have a crapload of files and they simply won't fit in the cache. Increase your realpath_cache size to address this. 2. Something somewhere is calling clearstatcache() often. Don't do that. 3. You are relying on include_path to find your files and you are always missing the file on the first couple of tries. Hint, it is a good idea to get rid of . from the beginning of your include_path and always use ./foo.inc to include something from the current directory instead of having include_path do this for you. That lets you put some other path first in the include_path and you can then include path/file.inc and have that be relative to the first path in your include_path. And make sure all your include_path includes are relative to that first path. Never include something that will hit the second component of include_path. -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
On Wed, Jul 16, 2008 at 6:13 PM, Ulf Wendel [EMAIL PROTECTED] wrote: Derick Rethans schrieb: On Tue, 15 Jul 2008, Andrey Hristov wrote: 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. Sorry, but those things should go to the mailinglist. Have it also on a blog is fine, but I doubt every php developer follows planet PHP as there's so much nonsense on it. I'm sure there's no need to discuss the differences between an article/blogging and development discussions on other channels. Is there any particular blog posting which has been must go dev-list in your eyes? Can you not simply post everything relevant to PDO and php internals to the internals list? Like bug reports, improvements, RFC, etc. (is it not obvious?) 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
Pierre Joye schrieb: On Wed, Jul 16, 2008 at 6:13 PM, Ulf Wendel [EMAIL PROTECTED] wrote: Derick Rethans schrieb: On Tue, 15 Jul 2008, Andrey Hristov wrote: 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. Sorry, but those things should go to the mailinglist. Have it also on a blog is fine, but I doubt every php developer follows planet PHP as there's so much nonsense on it. I'm sure there's no need to discuss the differences between an article/blogging and development discussions on other channels. Is there any particular blog posting which has been must go dev-list in your eyes? Can you not simply post everything relevant to PDO and php internals to the internals list? Like bug reports, improvements, RFC, etc. (is it not obvious?) No, it is not obvious. Bug reports filed by myself since February: [ 1] http://bugs.php.net/bug.php?id=45432 [ 2] http://bugs.php.net/bug.php?id=44409 [ 3] http://bugs.php.net/bug.php?id=44173 [ 4] http://bugs.php.net/bug.php?id=44154 [ 5] http://bugs.php.net/bug.php?id=44151 [ 6] http://bugs.php.net/bug.php?id=44337 [ 7] http://bugs.php.net/bug.php?id=44362 [ 8] http://bugs.php.net/bug.php?id=44159 [ 9] http://bugs.php.net/bug.php?id=44202 [10] http://bugs.php.net/bug.php?id=44200 [11] http://bugs.php.net/bug.php?id=44166 [12] http://bugs.php.net/bug.php?id=44189 [13] http://bugs.php.net/bug.php?id=44169 [14] http://bugs.php.net/bug.php?id=44158 [15] http://bugs.php.net/bug.php?id=44155 [16] http://bugs.php.net/bug.php?id=44327 Bug reports I have gone through and check if they are related to PDO_MYSQL - which they are not in my eyes. I have commented in the bug system to all of them but one: [17] http://bugs.php.net/bug.php?id=40740 [18] http://bugs.php.net/bug.php?id=44707 [19] http://bugs.php.net/bug.php?id=42322 [20] http://bugs.php.net/bug.php?id=43443 [21] http://bugs.php.net/bug.php?id=41125 Bug reports which are related to PDO_MYSQL and which I have commented on in the bug system: [22] http://bugs.php.net/bug.php?id=41997 [23] http://bugs.php.net/bug.php?id=42499 [24] http://pecl.php.net/bugs/bug.php?id=12794 [25] http://pecl.php.net/bugs/bug.php?id=12401 Improvements: I have offered 44 new general PDO tests on the php-qa mailing list in late April, http://marc.info/?l=php-qam=120949456225995w=2 . 44 new means roughly +100%. The PDO bug list has a shocking length of 99 entries: http://bugs.php.net/search.php?search_for=boolean=1limit=Allorder_by=direction=DESCcmd=displaystatus=Openbug_type[]=PDO+relatedphp_os=phpver=assign=author_email=bug_age=0 . What improvements or RFC's did I blog about instead of sending them to the PHP development list. Its just not obvious to me. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] RecursiveTreeIterator implementation
On 16.07.2008, at 17:47, Arnaud Le Blanc wrote: On Wednesday 09 July 2008 20:06:14 Marcus Boerger wrote: Hello Arnaud, if you can provicde the same for HEAD then I'll submit it. And if you're fast enough we might even get it into 5.3.0 :-) Johannes, Lukas, how much time does he have? marcus Hi, I would like to add a method to allow to change the prefix strings, but are there any chances for this patch to be commited into 5.3 ? from the RM perspective .. if you get it commited before the 24th its ok with us .. the usefulness or relevance of this will be decided by Marcus/Etienne. 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?
Hi! around a namespace, so I'd boldly suggest either fixing the curly braces notation to allow use statements or disallow curly braces around Use statements should be at the top, as the influence whole file scope. namespaces, because as it is, it doesn't really seem useful. What doesn't seem useful? What exactly you are trying to do? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace problem?
Stanislav Malyshev schrieb: Hi! around a namespace, so I'd boldly suggest either fixing the curly braces notation to allow use statements or disallow curly braces around Use statements should be at the top, as the influence whole file scope. I know, but namespace must be the first statement in a script, so I can't put use _before_ the namespace. namespaces, because as it is, it doesn't really seem useful. What doesn't seem useful? What exactly you are trying to do? Trying to use curly braces around my namespace for readability. But I can't put a use statement _into_ these namespaces, neither can I put the use _before_ the namespace. That means: I cannot use namespaces with curly braces combined with a use statement. This makes the curly braces pretty pointless. Regards, Stefan -- e-novative - We make IT work for you. e-novative GmbH - HR: Amtsgericht München HRB 139407 Sitz: Wolfratshausen - GF: Dipl. Inform. Stefan Priebsch http://www.e-novative.de - GnuPG Key: 0x7DB67F7F -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential shutdown order issue
Hi,
Does anyone agree that there is an issue to fix here? Messing with the
shutdown order is probably the last thing any RM would like to see
happening ..
regards,
Lukas
On 16.06.2008, at 04:55, Gregory Beaver wrote:
Hi,
I'm getting errors of hashtable already destroyed when running
phpMyAdmin with PHP 5.3, and (of course), thinking this is a phar
issue,
I've traced through and found a problem in the shutdown order.
Basically, php_request_shutdown() calls zend_deactivate() which calls
zend_destroy_rsrc_list(EG(regular_list)). On the next line,
zend_post_deactivate_modules() is called, which steps through the
module
list and unloads all the dynamically loaded modules. If one of these
modules (like mysqli) declares a resource type, then in
module_destructor() zend_clean_module_rsrc_dtors() is called, which
calls zend_clean_modules_rsrc_dtors_cb() (zend_list.c:253).
This function then walks over EG(regular_list), which had been
previously destroyed.
I think this issue could be fixed by moving the
zend_destroy_rsrc_list(EG(regular_list)) call after the module
shutdown. I've attached a patch demonstrating the principle (this
fixes
the hashtable destroyed message and I don't get anything bad like a
segfault).
Could someone with more brains double-check this one? I think it
can be
reproduced with a debug build using mysqli loaded dynamically and any
script that uses mysqli, but I've only reproduced it with phpMyAdmin.
Thanks,
Greg
Index: Zend/zend.c
===
RCS file: /repository/ZendEngine2/zend.c,v
retrieving revision 1.308.2.12.2.35.2.18
diff -u -r1.308.2.12.2.35.2.18 zend.c
--- Zend/zend.c 29 Apr 2008 08:15:16 - 1.308.2.12.2.35.2.18
+++ Zend/zend.c 16 Jun 2008 02:53:00 -
@@ -901,7 +901,8 @@
shutdown_compiler(TSRMLS_C);
} zend_end_try();
- zend_destroy_rsrc_list(EG(regular_list) TSRMLS_CC);
+ /* shutdown order issue */
+ /* zend_destroy_rsrc_list(EG(regular_list) TSRMLS_CC); */
#ifdef ZEND_DEBUG
if (GC_G(gc_enabled) !CG(unclean_shutdown)) {
Index: main/main.c
===
RCS file: /repository/php-src/main/main.c,v
retrieving revision 1.640.2.23.2.57.2.22
diff -u -r1.640.2.23.2.57.2.22 main.c
--- main/main.c 21 May 2008 15:55:31 - 1.640.2.23.2.57.2.22
+++ main/main.c 16 Jun 2008 02:53:02 -
@@ -1527,6 +1527,8 @@
zend_post_deactivate_modules(TSRMLS_C);
} zend_end_try();
+ zend_destroy_rsrc_list(EG(regular_list) TSRMLS_CC);
+
/* 9. SAPI related shutdown (free stuff) */
zend_try {
sapi_deactivate(TSRMLS_C);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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?
Hi! That means: I cannot use namespaces with curly braces combined with a use statement. This makes the curly braces pretty pointless. Well, don't use them then :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace problem?
On 16.07.2008, at 22:14, Stanislav Malyshev wrote: Hi! That means: I cannot use namespaces with curly braces combined with a use statement. This makes the curly braces pretty pointless. Well, don't use them then :) I think Stefan was just pointing out that allowing something that is rarely useful is just needlessly confusing, because it makes you think there is something you are missing. 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?
Hi! I think Stefan was just pointing out that allowing something that is rarely useful is just needlessly confusing, because it makes you think there is something you are missing. It may be true in some cases, but in general PHP allows to do tons of stuff that is not useful, or at least does not seem to be useful. But I don't think it's productive to spend time on disallowing such things - same time could be spent developing real features :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential shutdown order issue
Stanislav Malyshev wrote: Hi! zend_destroy_rsrc_list(EG(regular_list)). On the next line, zend_post_deactivate_modules() is called, which steps through the module list and unloads all the dynamically loaded modules. If one of these dl() is really troublesome... I think this issue could be fixed by moving the zend_destroy_rsrc_list(EG(regular_list)) call after the module shutdown. I've attached a patch demonstrating the principle (this fixes the hashtable destroyed message and I don't get anything bad like a segfault). But many resource dtors may need some action from modules they belong to. If modules are already past shutdown, that may be a problem. If we must spend time on supporting dl(), then I'd propose to fix module dtor so that it wouldn't try to access EG(regular_list) - if it happens as you described, it doesn't need it anyway. Hi, This has nothing to do with dl(). mysqli was loaded in php.ini via extension=mysqli.so I can't test the proposed fix until August, but it sounds like it would also fix the issue without messing with shutdown. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Phar ... brilliant, a couple of questions?
Jochem Maas wrote:
[snip]
I have a few questions, some of the answers may deserve
a few lines in the docs.
1. to what extent is Phar capable/designed to handle self
updating Phars .. especially with regard to multi-user access
(I'm thinking in terms of a website+CMS+userdata in a Phar
updated by a few people 'concurrently')
This is a great question - it needs to be added to the phar FAQ in the
manual (which I suppose should be in the using phar section).
My best advice is this:
do not use phar if you want to write to the code or to files in the
code space.
phar archives should contain *only* read-only data and code. Your best
bet is to use a product designed for concurrency: a database.
Why? Imagine - every time you update a single file in a phar archive,
the whole archive must be rebuilt from scratch. This could take up to
60 seconds for large applications with 100s of megabytes of files. Not
fun even if you have 1 concurrent user.
2. is there a (quick) way to reference a Phar object of
the current (as in Phar::isRunning()) Phar file - I figure
the engine can do new Phar(Phar::isRunning()) faster/better, no?
in the stub, put this code:
$__myphar = new Phar(__FILE__);
and use $__myphar when you need it. Alternatively, you could do:
define('MYPHAR', __FILE__);
in the stub, and then when you need it:
$phar = new Phar(MYPHAR);
However, if you want to quickly access the contents of a single file
within the phar archive, use the streams layer:
For instance, if you know the path to the file, you can always do this:
$a = file_get_contents(__DIR__ . '/file.txt');
or even
$a = file_get_contents(__DIR__ . '/../file.txt');
3. are there technical reasons for not being able to create/access
an sqllite db inside a Phar?
As Scott said, we have talked about this and have a plan to implement
read-only sqlite, and also read-write if the database is external and
mounted using Phar::mount()
4. Am I crazy to think of building a dynamic website, cms, including
all user [uploaded] files, installation config .. complete with
command line interface for updates, upgrades, module/config
management, etc, etc ... all in one Phar? is that feasable?
what kind of read and/or write concurrency could one expect?
if building self updating Phars is okay, then maybe an example
in the manual could be done to emphasis a few do's, dont's,
limitations, etc.
No, you are not crazy. However, you must design so that uploaded files
are saved on the local filesystem, the configuration file is also saved
on the local filesystem, and a database is used for oft-referenced items
that need concurrency.
This is not so different from a regular PHP app - you have to set the
writable bit on upload directories, and do a little bit of config that way.
The only problem with Phar::mount() is that phar.cache_list is not
available (i.e., the instant you call Phar::mount(), copy-on-write
happens, which is a lot of memory copying), something that I need to
ponder when I have some time, as there may be a way around this
limitation that doesn't kill performance.
Personally, I would design the app so that it works without code change
in or out of a phar archive, which is actually not hard to do in PHP
5.3. Config items can be adjusted by checking whether Phar::running()
is 0-length, which it is if called outside of a phar archive.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/phar/tests rename_dir.phpt rmdir.phpt /ext/phar/tests/tar rename_dir.phpt rmdir.phpt /ext/phar/tests/zip rename_dir.phpt rmdir.phpt
Dmitry Stogov wrote: dmitry Thu Jul 10 14:27:21 2008 UTC Added files: (Branch: PHP_5_3) /php-src/ext/phar/tests rename_dir.phpt rmdir.phpt /php-src/ext/phar/tests/tar rename_dir.phpt rmdir.phpt /php-src/ext/phar/tests/zip rename_dir.phpt rmdir.phpt Log: Added tests that demonstrate serious PHAR errors They cannot be easly fixed without algorithms modification Hi Dmitry, These tests all demonstrate modification of virtual directories, i.e. directories that are not really in the archive as entries, but simply are part of a path of existing files. However, I think we can easily add support for this by adding an iteration loop at the end of phar_wrapper_rename and phar_wrapper_rmdir implementations that cycles over all of the files and renames their directories. It would be slow, but truth be told, this is only going to be done on phar construction anyways, so performance is not a huge issue there. There is a similar loop that can be cut/pasted from phar_make_dirstream in phar/dirstream.c that scans all files to find matches that are in the requested directory. With slight modification to the loop the tests will pass (i.e. instead of adding the file to the opendir hash, perform the rename of the directory portion of the filename using a clever spprintf and a few temporary null bytes at directory separator boundaries in the original file, then zend_hash_add a new entry and either remove the old one or mark it deleted if it has open refcounts). The rmdir implementation should simply fail if any file or directory exists in the virtual directory. If no one fixes this by August 13 or so, I will try my hand at it. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] questions about namespaces, functions vs. closures
Hi,
Some questions about namespaces now that PHP 5.3 continues to evolve
1) Do we need functions in namespaces now that we have closures?
One of the main reasons I wanted functions in namespaces was to
implement callbacks. Now that we have closures in PHP 5.3, for me there
is no longer any good reason to have functions in namespaces other than
porting legacy code.
Because the only remaining serious naming conflict is between namespaced
functions and static class methods, I wonder how many people would find
closures an acceptable substitute for allowing functions in namespaces?
Also, see #3 as a way to solve the question of porting old code.
My assumption is that namespaces are best as a library helper for
re-usable classes.
2) Do we really need namespaced constants?
These can conflict with class constants and there is no way to resolve
the difference external to that namespace.
3) Now that it has been pointed out that use can't be used in brackets,
could we consider moving namespace syntax to a syntax proposal Dmitry
made a while ago:
?php
namespace Foo {
}
namespace Bar {
// this shows how to port legacy code - you simply have to explicitly
use old functions.
use ::blah();
}
namespace {
function blah(){}
}
?
The last example would be for porting legacy un-namespaced code (for
instance, utility functions) or global application code that uses the
previous stuff.
If possible, could answers to these questions be limited to +1/-1? I
would like to get a sense of how controversial these ideas are rather
than to just debate them. If you absolutely must reply with other
ideas, then please start a new thread.
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] questions about namespaces, functions vs. closures
On Wednesday 16 July 2008 9:36:24 pm Greg Beaver wrote:
Hi,
Some questions about namespaces now that PHP 5.3 continues to evolve
1) Do we need functions in namespaces now that we have closures?
One of the main reasons I wanted functions in namespaces was to
implement callbacks. Now that we have closures in PHP 5.3, for me there
is no longer any good reason to have functions in namespaces other than
porting legacy code.
Because the only remaining serious naming conflict is between namespaced
functions and static class methods, I wonder how many people would find
closures an acceptable substitute for allowing functions in namespaces?
Also, see #3 as a way to solve the question of porting old code.
My assumption is that namespaces are best as a library helper for
re-usable classes.
I don't know whether +1 or -1 would mean keep namespaced functions here, so
I will just say Keep namespaced functions!
very_long_function_names_for_namespacing is just as much a problem as long
class names for the same reason. My primary development system is 99%
functions, and uses name-based namespacing now. Real namespaces would be
quite a boon and solve a dozen or so problems for us, if they work right.
2) Do we really need namespaced constants?
Eh, +0.5. :-)
3) Now that it has been pointed out that use can't be used in brackets,
could we consider moving namespace syntax to a syntax proposal Dmitry
made a while ago:
?php
namespace Foo {
}
namespace Bar {
// this shows how to port legacy code - you simply have to explicitly
use old functions.
use ::blah();
}
namespace {
function blah(){}
}
?
I don't recall the full proposal so I cannot comment as the devil is in the
details. In general, transitioning from non-namespaced code to namespaced
code should be as graceful as possible (e.g., avoiding a requirement to
explicitly name all global functions you're going to use within a given block
before using them.)
The last example would be for porting legacy un-namespaced code (for
instance, utility functions) or global application code that uses the
previous stuff.
If possible, could answers to these questions be limited to +1/-1? I
would like to get a sense of how controversial these ideas are rather
than to just debate them. If you absolutely must reply with other
ideas, then please start a new thread.
Sorry, it wasn't really possible. :-(
--
Larry Garfield
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
