Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/date config.w32 /ext/date/lib parse_iso_intervals.re
On Wed, 6 Aug 2008, Pierre Joye wrote: On Tue, Aug 5, 2008 at 11:59 PM, Johannes Schlüter [EMAIL PROTECTED] wrote: Simple question yes/no is enough for me: Can it be done, using the build system, in a per-file way or only per extension? (If yes per-file, I'd prefer that way, else: keep the #ifdef) Per extension (as done in the first fix) only and that's a bad idea to disable it, it is already slow enough. That's irrelevant as MS VC 6 is slow anyway. Please remove this silly #ifdef until you find out what is the *real* cause here. I don't like symptom plugging. Until you find out the real reason, fix this in the build system instead of with hacks in files. (And if you're not willing to change it back, I will). regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb 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/date config.w32 /ext/date/lib parse_iso_intervals.re
hi Derick, On Wed, Aug 6, 2008 at 8:59 AM, Derick Rethans [EMAIL PROTECTED] wrote: On Wed, 6 Aug 2008, Pierre Joye wrote: On Tue, Aug 5, 2008 at 11:59 PM, Johannes Schlüter [EMAIL PROTECTED] wrote: Simple question yes/no is enough for me: Can it be done, using the build system, in a per-file way or only per extension? (If yes per-file, I'd prefer that way, else: keep the #ifdef) Per extension (as done in the first fix) only and that's a bad idea to disable it, it is already slow enough. That's irrelevant as MS VC 6 is slow anyway. Please remove this silly #ifdef until you find out what is the *real* cause here. I don't like symptom plugging. Until you find out the real reason, fix this in the build system instead of with hacks in files. (And if you're not willing to change it back, I will). The RMs clearly stated that we have to keep the #ifdef. I don't think ext/date is any different from any other extensions in core, especially as it is part of the standard feature. That being said, it would be nice if you have a bit more consideration of the work of the other people, especially when they work in their free time on your code, to improve, fix or test it. A despote-like attitude is nice and shiny in PECL or anywhere else but not in php-src/*. Thanks for your understanding. 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] towards alpha2
On 05.08.2008, at 22:55, Steph Fox wrote: - shutdown order issues (Greg) Greg will be back on board next week, but I think this was a ZE item anyway? Yes, probably something for Stas or Dmitry? - unix path separators in spl (Steph/Greg/Marcus) Didn't know that one was on any list, sorry. I committed a flag to provide unix paths in SPL iterators a couple of weeks ago. ok, marked as done. - fix open issues in phar (Greg) There aren't any... or at least, none that I know of. No bug reports open other than documentation. Greg *may* still want to do some performance-related work on return, assuming Dmitry's left him anything that way. these are the ml posts i was referring t:o http://marc.info/?l=php-internalsm=121626110032715 http://marc.info/?l=php-internalsm=121507100804623 You're missing the UPGRADE file from your TODO? I have upgrading the 5.3 scratchpad as a perpetual todo on the wiki. I guess starting with the beta we should have an UPGRADE file though. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- 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/session session.c /ext/session/tests session_decode_variation3.phpt session_encode_variation3.phpt session_encode_variation4.phpt session_encode_variation5.p
On 06.08.2008, at 07:34, Jani Taskinen wrote: janiWed Aug 6 05:34:55 2008 UTC Modified files: /php-src/ext/session session.c /php-src/ext/session/tests session_decode_variation3.phpt session_encode_variation3.phpt session_encode_variation4.phpt session_encode_variation5.phpt session_encode_variation7.phpt session_encode_variation8.phpt Log: - Fixed some inconsistencies with the behaviour of sessions. Changed session_start() to return false when session start fails. I presume your MFH commit brought this change to 5.3 as well? I guess returning false is the reasonable expected behavior and so I would chalk it up as a bug fix and not as a BC break. But it would be good to get this kind of stuff noted on the 5.3 doc scratchpad [1] regards, Lukas Kahwe Smith [EMAIL PROTECTED] [1] http://wiki.php.net/doc/scratchpad/upgrade/53 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Alias stream_context_get_default() as stream_context_set_default()
On Wed, Aug 6, 2008 at 06:24, Davey Shafik [EMAIL PROTECTED] wrote: OK, here's an attempt at a patch[1], I discussed it briefly with Johannes and he felt some discussion was needed with regards to the return value. I personally seem some benefit to returning the new context; Johannes wasn't sure that returning true might not be a better option in that we cannot return the previous value like ini_set(). Why can't we? If there was a default context then return it, otherwise true/false.. Hmh. That could be confusing. I'm fine returning the new context :) [1] http://pixelated-dreams.com/~davey/stream_context_set_default.patch The arginfo is wrong, the parameter is required, not optional. + parse_context_options(context, params TSRMLS_CC); params? Shouldn't this be options? :) -Hannes -- 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(PHP_5_3) /ext/standard string.c
On Tue, 5 Aug 2008, Olivier Hill wrote: What should be MFH'ed? I haven't touched HEAD with this. I don't have cvs access here, will only be able to commit friday. Is there still regression issues or my last patch fixed it? Looks fine - I missed your patch on the list though. regards, Derick -- HEAD before 5_3!: http://tinyurl.com/6d2esb 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
[PHP-DEV] clearstatcache change
I think we either need to make clearstatcache() not affect the realpath cache, or we should add an optional argument to it to specify whether or not the realpath cache should be cleared as well. The realpath cache makes a huge difference on includes and having the cache blown away by a script calling clearstatcache() really hurts. In almost all cases the script is doing it to clear the stat cache for some local file it is doing stuff to and the author has no idea that she is blowing away the realpath_cache as well. And if that script is run on every request, the realpath_cache becomes completely useless. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hello Stanislav,
Wednesday, August 6, 2008, 7:42:29 AM, you wrote:
Hi!
function ($arg) { use $a, $b;
Note that neither static not global allow inside definitions, so from
consistency point of view it doesn't work.
I do not see an argument in complaining about extending a scheme. But I see
the other solution, use in front of the body, as an introduction of a brand
new scheme. Obviously one is very inconsistent. And besides, global could
simply ignore '' as that would have no meaning there at all.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards alpha2
Hi Lukas - shutdown order issues (Greg) Greg will be back on board next week, but I think this was a ZE item anyway? Yes, probably something for Stas or Dmitry? There's a patch out there (from Greg): http://php.markmail.org/search/?q=%22potential+shutdown+order%22+list%3Anet.php.lists.internals that removes regular_list destruction from the Engine and puts it into main.c. There was some discussion with Stas at the time, who more or less ended up in agreement with Greg once he realized there was no dl() involved in the scenario - but no movement, and no alternative proposal. Shutdown order is historically problematic, as I'm sure you're aware - we need to be 100% sure about this one. - unix path separators in spl (Steph/Greg/Marcus) Didn't know that one was on any list, sorry. I committed a flag to provide unix paths in SPL iterators a couple of weeks ago. ok, marked as done. Thanks. these are the ml posts i was referring t:o http://marc.info/?l=php-internalsm=121626110032715 rmdir etc are working now (Dmitry fixed that during his Phar-week). http://marc.info/?l=php-internalsm=121507100804623 Dmitry also improved performance while he was in there, but whether Greg will still want to try and squeeze a few more ms out of it is another matter :) You're missing the UPGRADE file from your TODO? I have upgrading the 5.3 scratchpad as a perpetual todo on the wiki. I guess starting with the beta we should have an UPGRADE file though. OK, let me know when. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
I think it is good as it is.
Realy, I'd prefer even a change to global like this:
function test ($someparam) global ($someGlobalVariable) {
// code here
}
Or even make it consistent with lamda's and make use of use statment
instead of global.
P.S. I know my comment will be yeald at, so please avoid that so not to
polute the list. Just think a little, maybe it is a good idea.
P.S.S. Sometimes I realy want an ability to define superglobal variables in
some way.
Re: [PHP-DEV] [PATCH] Alias stream_context_get_default() as stream_context_set_default()
On Aug 6, 2008, at 03:47 AM, Hannes Magnusson wrote: On Wed, Aug 6, 2008 at 06:24, Davey Shafik [EMAIL PROTECTED] wrote: OK, here's an attempt at a patch[1], I discussed it briefly with Johannes and he felt some discussion was needed with regards to the return value. I personally seem some benefit to returning the new context; Johannes wasn't sure that returning true might not be a better option in that we cannot return the previous value like ini_set(). Why can't we? If there was a default context then return it, otherwise true/false.. Hmh. That could be confusing. I'm fine returning the new context :) There is always a default context :) [1] http://pixelated-dreams.com/~davey/stream_context_set_default.patch The arginfo is wrong, the parameter is required, not optional. I don't see this, but that's just me not knowing, I thought that anything following a | (pipe) was optional, otherwise it was implicitly required, how do you make an argument explicitly required if that is not the case? + parse_context_options(context, params TSRMLS_CC); The patch has been update to fix the params/options mistake, Still at http://pixelated-dreams.com/~davey/stream_context_set_default.patch - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Stanislav Malyshev wrote:
Hi!
function ($arg) { use $a, $b;
Note that neither static not global allow inside definitions, so from
consistency point of view it doesn't work.
What a nitpicking :) So would I say that the global statement is
inconsistent with static because it doesn't allow assignments within the
statement :p
Moriyoshi
--
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/session session.c /ext/session/tests session_decode_variation3.phpt session_encode_variation3.phpt session_encode_variation4.phpt session_encode_variation5.p
Lukas Kahwe Smith kirjoitti: On 06.08.2008, at 07:34, Jani Taskinen wrote: janiWed Aug 6 05:34:55 2008 UTC Modified files: /php-src/ext/sessionsession.c /php-src/ext/session/testssession_decode_variation3.phpt session_encode_variation3.phpt session_encode_variation4.phpt session_encode_variation5.phpt session_encode_variation7.phpt session_encode_variation8.phpt Log: - Fixed some inconsistencies with the behaviour of sessions. Changed session_start() to return false when session start fails. I presume your MFH commit brought this change to 5.3 as well? Of course, among other things people did not bother merging before. I think I mentioned the hash support in the PHP_5_3 commit with [DOC] ? I guess returning false is the reasonable expected behavior and so I would chalk it up as a bug fix and not as a BC break. But it would be good to get this kind of stuff noted on the 5.3 doc scratchpad [1] I would add it but I can't save the page..? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] include bug in 5.3
Hi Since quite some time (weeks), I have this very strange and annoying include bug in 5.3-dev and now I think is the time to report it :) The reproducable script is here: http://trash.chregu.tv/include-bug.php.txt In short, when I have foo/alpha (empty) bar/alpha/bar.php and set the include path to foo/:bar/ and then do include(alpha/bar.php); it throws an not-found error. But if I remove foo/alpha, it works correctly. In the meantime (while I wrote this), I found a similar bug report: http://bugs.php.net/bug.php?id=45044 and added my script. Can please someone look into that, it's not an area where I feel comfortable :) Thanks chregu -- New Office Zurich Opening: http://liip.to/party -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x5CE1DECB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Alias stream_context_get_default() as stream_context_set_default()
On Wed, Aug 6, 2008 at 15:11, Davey Shafik [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 03:47 AM, Hannes Magnusson wrote: On Wed, Aug 6, 2008 at 06:24, Davey Shafik [EMAIL PROTECTED] wrote: OK, here's an attempt at a patch[1], I discussed it briefly with Johannes and he felt some discussion was needed with regards to the return value. I personally seem some benefit to returning the new context; Johannes wasn't sure that returning true might not be a better option in that we cannot return the previous value like ini_set(). Why can't we? If there was a default context then return it, otherwise true/false.. Hmh. That could be confusing. I'm fine returning the new context :) There is always a default context :) [1] http://pixelated-dreams.com/~davey/stream_context_set_default.patch The arginfo is wrong, the parameter is required, not optional. I don't see this, but that's just me not knowing, I thought that anything following a | (pipe) was optional, otherwise it was implicitly required, how do you make an argument explicitly required if that is not the case? Correct, but ext/reflaction doesn't read the zend_parse_parameters(), it reads the arginfos, so those have to match the zend_parse_parameters() statement. ZEND_BEGIN_ARG_INFO_EX(arginfo_stream_context_set_default, 0, 0, 0) should be ZEND_BEING_ARG_INF(arginfo_stream_context_set_default, 0) (meaning all ZEND_ARG_INFO() arguments are required) or ZEND_BEGIN_ARG_INFO_EX(arginfo_stream_context_set_default, 0, 0, 1) (meaning only the first ZEND_ARG_INFO() argument is required) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards alpha2
Steph Fox wrote: Hi Lukas snip these are the ml posts i was referring t:o http://marc.info/?l=php-internalsm=121626110032715 rmdir etc are working now (Dmitry fixed that during his Phar-week). This would be great, I will try to verify all of this next week some time. http://marc.info/?l=php-internalsm=121507100804623 Dmitry also improved performance while he was in there, but whether Greg will still want to try and squeeze a few more ms out of it is another matter It's also worth noting that Dmitry had not tried using phar.cache_list when he noted phpMyAdmin being 4 times slower. After trying it, he said to me offlist that phpMyAdmin in a phar actually outperformed phpMyAdmin on-disk (which was better than what I got in my benchmarks), so I think we're good there. I had a couple of other things to try out, but I don't think any other large improvements are possible. Dmitry had planned to add a new callback to the ZE so that we could stop hooking into zend_compile, not sure if that went anywere? Dmitry? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] clearstatcache change
Rasmus Lerdorf wrote: I think we either need to make clearstatcache() not affect the realpath cache, or we should add an optional argument to it to specify whether or not the realpath cache should be cleared as well. See this: http://bugs.php.net/39367 Considering some people seem to want to clear realpath cache as well, I'd make it an optional parameter which defaults to NOT clear realpath cache: clearstatchache(true); /* BOOM! realpath cache gone.. */ btw. I just noticed chroot() calls this realpath_cache_clean()..intentional? Also some streams stuff uses the php_clear_stat_cache() func but those should propably use the realpatch_cache_del() instead and not blow away whole cache? Here is a patch to add that optional parameter (for PHP_5_3): http://pecl.php.net/~jani/patches/clearstatcache_optional_param.patch --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mysql_set_charset
Hi! I notice that mysql_set_charset function is not part of 5.3 tree and it's test is marked as usage not recommended. Could you explain what is the reason for that? It's quite unusual to drop functions in later versions, and if mysql_set_charset() has some problem we should note that in the manual. -- 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] Inconsistencies in 5.3
Hi! I do not see an argument in complaining about extending a scheme. But I see the other solution, use in front of the body, as an introduction of a brand new scheme. Obviously one is very inconsistent. And besides, global could It will be obviously inconsistent anyway, because it is a new thing, which doesn't work like old things. simply ignore '' as that would have no meaning there at all. So now we should mess with global in order to provide imaginary consistency. Brilliant. -- 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] Inconsistencies in 5.3
Hi! What a nitpicking :) So would I say that the global statement is inconsistent with static because it doesn't allow assignments within the statement :p Sure it is. That's just another thing to show all this consistency talk is blown way out of proportion long ago. Now let's make global accept assignments and ignore them for consistency, should we? -- 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] Re: [PHP] PDO prepared statements and LIKE escaping
If you are supporting international users, then you also have to worry about the full-width versions of the operators (%, *, etc.) Whether they are treated the same as half-width characters depends on the database. Oracle for example treats them as equivalent. -Original Message- From: Lester Caine [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 05, 2008 12:35 AM To: PHP internals Subject: [PHP-DEV] Re: [PHP] PDO prepared statements and LIKE escaping Larry Garfield wrote: I'm building a multi-database system, although my main targets are MySQL, Postgres, and SQLite. How would those handle something like a string that ends in 100%? Personally this is one of the reasons that PDO has never attracted me. Providing the tools to flatten some of the differences between *SQL* variations is just as important as flattening the name differences in functions. My own use of LIKE tends to process the string and then add the wrapping %% when passing it to the param array, but do all databases HANDLE 'escaped %' in the LIKE data? Firebird allows a escape character but you need to include it in the SQL LIKE '%100#%%' ESCAPE '#' But I think MySQL actually uses \% to achieve the same thing - and the ESCAPE '\' is then optional? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] clearstatcache change
Hi, On Wednesday 06 August 2008 18:18:49 Jani Taskinen wrote: Rasmus Lerdorf wrote: I think we either need to make clearstatcache() not affect the realpath cache, or we should add an optional argument to it to specify whether or not the realpath cache should be cleared as well. See this: http://bugs.php.net/39367 Considering some people seem to want to clear realpath cache as well, I'd make it an optional parameter which defaults to NOT clear realpath cache: clearstatchache(true); /* BOOM! realpath cache gone.. */ btw. I just noticed chroot() calls this realpath_cache_clean()..intentional? Also some streams stuff uses the php_clear_stat_cache() func but those should propably use the realpatch_cache_del() instead and not blow away whole cache? Yes, I think too. I added that to your patch: http://arnaud.lb.s3.amazonaws.com/clearstatcache_optional_params.patch :) It also adds the filename argument to clearstatcache([bool clear_realpath_cache[, filename]]) Here is a patch to add that optional parameter (for PHP_5_3): http://pecl.php.net/~jani/patches/clearstatcache_optional_param.patch --Jani -- 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/session session.c /ext/session/tests session_decode_variation3.phpt session_encode_variation3.phpt session_encode_variation4.phpt session_encode_variation5.p
On 06.08.2008, at 17:18, Jani Taskinen wrote: Lukas Kahwe Smith kirjoitti: On 06.08.2008, at 07:34, Jani Taskinen wrote: janiWed Aug 6 05:34:55 2008 UTC Modified files: /php-src/ext/sessionsession.c /php-src/ext/session/testssession_decode_variation3.phpt session_encode_variation3.phpt session_encode_variation4.phpt session_encode_variation5.phpt session_encode_variation7.phpt session_encode_variation8.phpt Log: - Fixed some inconsistencies with the behaviour of sessions. Changed session_start() to return false when session start fails. I presume your MFH commit brought this change to 5.3 as well? Of course, among other things people did not bother merging before. I think I mentioned the hash support in the PHP_5_3 commit with [DOC] ? I guess returning false is the reasonable expected behavior and so I would chalk it up as a bug fix and not as a BC break. But it would be good to get this kind of stuff noted on the 5.3 doc scratchpad [1] I would add it but I can't save the page..? you need to enter a comment or click the minor change box. i guess disabling javascript should also work ;) 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] [Fwd: #45687 [Opn-Bgs]: Why is PCNTL marked experimental]
On 02.08.2008, at 19:03, Maciek Sokolewicz wrote: Right, so, if this _is_ still considered experimental, then we should fix it in the documentation; and if it's not, we should fix the configure script. Which one will it be? :) so i guess it should get rid of the exerimental flag .. at least nobody said it shouldnt, and brian and tony said it should .. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- 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/session session.c /ext/session/tests session_decode_variation3.phpt session_encode_variation3.phpt session_encode_variation4.phpt session_encode_variation5.p
Lukas Kahwe Smith kirjoitti: On 06.08.2008, at 17:18, Jani Taskinen wrote: Lukas Kahwe Smith kirjoitti: On 06.08.2008, at 07:34, Jani Taskinen wrote: janiWed Aug 6 05:34:55 2008 UTC Modified files: /php-src/ext/sessionsession.c /php-src/ext/session/testssession_decode_variation3.phpt session_encode_variation3.phpt session_encode_variation4.phpt session_encode_variation5.phpt session_encode_variation7.phpt session_encode_variation8.phpt Log: - Fixed some inconsistencies with the behaviour of sessions. Changed session_start() to return false when session start fails. I presume your MFH commit brought this change to 5.3 as well? Of course, among other things people did not bother merging before. I think I mentioned the hash support in the PHP_5_3 commit with [DOC] ? I guess returning false is the reasonable expected behavior and so I would chalk it up as a bug fix and not as a BC break. But it would be good to get this kind of stuff noted on the 5.3 doc scratchpad [1] I would add it but I can't save the page..? you need to enter a comment or click the minor change box. i guess disabling javascript should also work ;) Added note. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] clearstatcache change
On Wednesday 06 August 2008 19:56:58 Arnaud Le Blanc wrote: Hi, On Wednesday 06 August 2008 18:18:49 Jani Taskinen wrote: Rasmus Lerdorf wrote: I think we either need to make clearstatcache() not affect the realpath cache, or we should add an optional argument to it to specify whether or not the realpath cache should be cleared as well. See this: http://bugs.php.net/39367 Considering some people seem to want to clear realpath cache as well, I'd make it an optional parameter which defaults to NOT clear realpath cache: clearstatchache(true); /* BOOM! realpath cache gone.. */ btw. I just noticed chroot() calls this realpath_cache_clean()..intentional? Also some streams stuff uses the php_clear_stat_cache() func but those should propably use the realpatch_cache_del() instead and not blow away whole cache? Yes, I think too. I added that to your patch: http://arnaud.lb.s3.amazonaws.com/clearstatcache_optional_params.patch :) It also adds the filename argument to clearstatcache([bool clear_realpath_cache[, filename]]) I reply to myself, actually this may cause troubles to not clear the full cache in plain_wrapper.c :/ I updated the patch, just left the filename argument to clearstatcache(). Here is a patch to add that optional parameter (for PHP_5_3): http://pecl.php.net/~jani/patches/clearstatcache_optional_param.patch --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysql_set_charset
Stanislav Malyshev schrieb: I notice that mysql_set_charset function is not part of 5.3 tree and it's test is marked as usage not recommended. Could you explain what is the reason for that? It's quite unusual to drop functions in later versions, and if mysql_set_charset() has some problem we should note that in the manual. Hi Stas, good find! I think it has happened accidently in 5_3 at Revision 1.213.2.6.2.16.2.2 when patching ext/mysql for mysqlnd some 10 months ago [1] . Its in 5_2 and its in HEAD. Andrey is working on re-introducing it to ext/mysql in the 5_3 branch. I don't recall why I added usage not recommended to the test. Let me check with Georg. He had some concerns on the function as far as I remember. Ulf [1] http://cvs.php.net/viewvc.cgi/php-src/ext/mysql/php_mysql.c?r1=1.213.2.6.2.16.2.1r2=1.213.2.6.2.16.2.2 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysql_set_charset
Ulf Wendel schrieb: and its in HEAD. Andrey is working on re-introducing it to ext/mysql in the 5_3 branch. There it is http://news.php.net/php.cvs/52063 Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysql_set_charset
Hi! There it is http://news.php.net/php.cvs/52063 Thanks! -- 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] clearstatcache change
On Wed, Aug 6, 2008 at 21:00, Arnaud Le Blanc [EMAIL PROTECTED] wrote: On Wednesday 06 August 2008 19:56:58 Arnaud Le Blanc wrote: Hi, On Wednesday 06 August 2008 18:18:49 Jani Taskinen wrote: Rasmus Lerdorf wrote: I think we either need to make clearstatcache() not affect the realpath cache, or we should add an optional argument to it to specify whether or not the realpath cache should be cleared as well. See this: http://bugs.php.net/39367 Considering some people seem to want to clear realpath cache as well, I'd make it an optional parameter which defaults to NOT clear realpath cache: clearstatchache(true); /* BOOM! realpath cache gone.. */ btw. I just noticed chroot() calls this realpath_cache_clean()..intentional? Also some streams stuff uses the php_clear_stat_cache() func but those should propably use the realpatch_cache_del() instead and not blow away whole cache? Yes, I think too. I added that to your patch: http://arnaud.lb.s3.amazonaws.com/clearstatcache_optional_params.patch :) It also adds the filename argument to clearstatcache([bool clear_realpath_cache[, filename]]) I reply to myself, actually this may cause troubles to not clear the full cache in plain_wrapper.c :/ I updated the patch, just left the filename argument to clearstatcache(). Don't forget to update the arginfo -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Stanislav Malyshev wrote: Hi! What a nitpicking :) So would I say that the global statement is inconsistent with static because it doesn't allow assignments within the statement :p Sure it is. That's just another thing to show all this consistency talk is blown way out of proportion long ago. Now let's make global accept assignments and ignore them for consistency, should we? I'd prefer the opposite way in which no initializers are allowed for static. null type was introduced to mark uninitialized variables in the first place, so if we have strictly kept the original intention, there should be no problem with this idea. (I'd say NULL values from the database or other softwares should have been made effectively differentiable with language-defined null values, but this is another issue) Apart from this, the constructs in question share the same semantics where their role is to define variables that refers to values of a non-local data storage, so making the lexical variable declaration statement look like the others is not inconsistent with the current language syntax, whereas the use construct after the argument list is inconsistent with the ordinary function definition unless my proposal [1] is accepted. [1] http://news.php.net/php.internals/39071 Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inconsistencies in 5.3
Hi! language syntax, whereas the use construct after the argument list is inconsistent with the ordinary function definition unless my proposal Because it is _not_ an ordinary function definition. It's like saying '+' is inconsistent with '-' because $a+$b=$b+$a but $a-$b!=$b-$a. I don't have any attachment to any particular syntax in this case, but I am strongly opposed to taking decision on the syntax based on the look of the constructs alone, ignoring underlying semantic differences and all the problems that it would lead to. P.S. btw, in your proposal functions would be inconsistent with methods. -- 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] Inconsistencies in 5.3
Stanislav Malyshev wrote: Hi! language syntax, whereas the use construct after the argument list is inconsistent with the ordinary function definition unless my proposal Because it is _not_ an ordinary function definition. It's like saying '+' is inconsistent with '-' because $a+$b=$b+$a but $a-$b!=$b-$a. Your argument sounds far too extreme. P.S. btw, in your proposal functions would be inconsistent with methods. Should I follow like methods are not functions? or PHP has inconsistent language features. That seems oddly enough. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] clearstatcache change
On Wed, 2008-08-06 at 21:00 +0200, Arnaud Le Blanc wrote: btw. I just noticed chroot() calls this realpath_cache_clean()..intentional? I'd assume that, as /foo inside a chroot is different from /foo outside... Also some streams stuff uses the php_clear_stat_cache() func but those should propably use the realpatch_cache_del() instead and not blow away whole cache? Yes, I think too. I added that to your patch: http://arnaud.lb.s3.amazonaws.com/clearstatcache_optional_params.patch :) It also adds the filename argument to clearstatcache([bool clear_realpath_cache[, filename]]) I reply to myself, actually this may cause troubles to not clear the full cache in plain_wrapper.c :/ I updated the patch, just left the filename argument to clearstatcache(). If you fix the arginfo like Hannes it's, good. If the name of the second parameter in the proto (filename) is the same as in the implementation (pathname) it might even be a bit better :-) johanes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] include bug in 5.3
Hi! and set the include path to foo/:bar/ and then do include(alpha/bar.php); it throws an not-found error. Tried that, worked just fine for me - includes bar/alpha/bar.php. I notice your script on the link does something different, but works for me too with 5.3 CVS. -- 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] include bug in 5.3
On 7.8.2008 3:03 Uhr, Stanislav Malyshev wrote: Hi! and set the include path to foo/:bar/ and then do include(alpha/bar.php); it throws an not-found error. Tried that, worked just fine for me - includes bar/alpha/bar.php. I notice your script on the link does something different, but works for me too with 5.3 CVS. Did you try it on a *BSD Variant? And do you have an empty foo/alpha/ directory? That's what my script does and with which it fails on OS X. It seems to work on Linux. According to http://bugs.php.net/bug.php?id=45044 I'm not the only one with that problem and it really introduces a lot of issues. chregu -- Liip AG // Feldstrasse 133 // CH-8004 Zurich Tel +41 43 500 39 81 // Mobile +41 76 561 88 60 www.liip.ch // blog.liip.ch // GnuPG 0x5CE1DECB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Alias stream_context_get_default() as stream_context_set_default()
On Aug 6, 2008, at 11:38 AM, Hannes Magnusson wrote: On Wed, Aug 6, 2008 at 15:11, Davey Shafik [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 03:47 AM, Hannes Magnusson wrote: On Wed, Aug 6, 2008 at 06:24, Davey Shafik [EMAIL PROTECTED] wrote: OK, here's an attempt at a patch[1], I discussed it briefly with Johannes and he felt some discussion was needed with regards to the return value. I personally seem some benefit to returning the new context; Johannes wasn't sure that returning true might not be a better option in that we cannot return the previous value like ini_set(). Why can't we? If there was a default context then return it, otherwise true/ false.. Hmh. That could be confusing. I'm fine returning the new context :) There is always a default context :) [1] http://pixelated-dreams.com/~davey/stream_context_set_default.patch The arginfo is wrong, the parameter is required, not optional. I don't see this, but that's just me not knowing, I thought that anything following a | (pipe) was optional, otherwise it was implicitly required, how do you make an argument explicitly required if that is not the case? Correct, but ext/reflaction doesn't read the zend_parse_parameters(), it reads the arginfos, so those have to match the zend_parse_parameters() statement. ZEND_BEGIN_ARG_INFO_EX(arginfo_stream_context_set_default, 0, 0, 0) should be ZEND_BEING_ARG_INF(arginfo_stream_context_set_default, 0) (meaning all ZEND_ARG_INFO() arguments are required) or ZEND_BEGIN_ARG_INFO_EX(arginfo_stream_context_set_default, 0, 0, 1) (meaning only the first ZEND_ARG_INFO() argument is required) -Hannes Done, thank you for the explanation :) - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Alias stream_context_get_default() as stream_context_set_default()
On Aug 6, 2008, at 11:38 AM, Hannes Magnusson wrote: On Wed, Aug 6, 2008 at 15:11, Davey Shafik [EMAIL PROTECTED] wrote: On Aug 6, 2008, at 03:47 AM, Hannes Magnusson wrote: On Wed, Aug 6, 2008 at 06:24, Davey Shafik [EMAIL PROTECTED] wrote: OK, here's an attempt at a patch[1], I discussed it briefly with Johannes and he felt some discussion was needed with regards to the return value. I personally seem some benefit to returning the new context; Johannes wasn't sure that returning true might not be a better option in that we cannot return the previous value like ini_set(). Why can't we? If there was a default context then return it, otherwise true/ false.. Hmh. That could be confusing. I'm fine returning the new context :) There is always a default context :) [1] http://pixelated-dreams.com/~davey/stream_context_set_default.patch The arginfo is wrong, the parameter is required, not optional. I don't see this, but that's just me not knowing, I thought that anything following a | (pipe) was optional, otherwise it was implicitly required, how do you make an argument explicitly required if that is not the case? Correct, but ext/reflaction doesn't read the zend_parse_parameters(), it reads the arginfos, so those have to match the zend_parse_parameters() statement. ZEND_BEGIN_ARG_INFO_EX(arginfo_stream_context_set_default, 0, 0, 0) should be ZEND_BEING_ARG_INF(arginfo_stream_context_set_default, 0) (meaning all ZEND_ARG_INFO() arguments are required) or ZEND_BEGIN_ARG_INFO_EX(arginfo_stream_context_set_default, 0, 0, 1) (meaning only the first ZEND_ARG_INFO() argument is required) -Hannes oops, patch is still at: http://pixelated-dreams.com/~davey/stream_context_set_default.patch - Davey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] clearstatcache change
Johannes Schlüter wrote: On Wed, 2008-08-06 at 21:00 +0200, Arnaud Le Blanc wrote: btw. I just noticed chroot() calls this realpath_cache_clean()..intentional? I'd assume that, as /foo inside a chroot is different from /foo outside... Also some streams stuff uses the php_clear_stat_cache() func but those should propably use the realpatch_cache_del() instead and not blow away whole cache? Yes, I think too. I added that to your patch: http://arnaud.lb.s3.amazonaws.com/clearstatcache_optional_params.patch :) It also adds the filename argument to clearstatcache([bool clear_realpath_cache[, filename]]) I reply to myself, actually this may cause troubles to not clear the full cache in plain_wrapper.c :/ I updated the patch, just left the filename argument to clearstatcache(). If you fix the arginfo like Hannes it's, good. If the name of the second parameter in the proto (filename) is the same as in the implementation (pathname) it might even be a bit better :-) Looks good to me too. Don't forget the [DOC] comment on the commit :) -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
