Re: [PHP-DEV] Choosing a distributed version control system for PHP - problems
Pierre Joye wrote: Another great example of a successful is the freedesktop project. They have 100s of sub project and each of them have modules. Can I suggest you have a closer look at this conversion Pierre and work out what is currently missing from it ... hint - as a new developer how do I 'check out (clone)' a copy of libraoffice. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/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] Choosing a distributed version control system for PHP - problems
On Thu, Aug 18, 2011 at 9:32 AM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: Another great example of a successful is the freedesktop project. They have 100s of sub project and each of them have modules. Can I suggest you have a closer look at this conversion Pierre and work out what is currently missing from it ... hint - as a new developer how do I 'check out (clone)' a copy of libraoffice. By RTFM: http://www.libreoffice.org/get-involved/developers/ -- Pierre @pierrejoye | 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] Choosing a distributed version control system for PHP - problems
Pierre Joye wrote: On Thu, Aug 18, 2011 at 9:32 AM, Lester Caineles...@lsces.co.uk wrote: Pierre Joye wrote: Another great example of a successful is the freedesktop project. They have 100s of sub project and each of them have modules. Can I suggest you have a closer look at this conversion Pierre and work out what is currently missing from it ... hint - as a new developer how do I 'check out (clone)' a copy of libraoffice. By RTFM:http://www.libreoffice.org/get-involved/developers/ Exactly ... While there were separate submodules for each section, as a result of converting the modular structure of the original CVS code base, those are now marked as obsolete ( http://cgit.freedesktop.org/libreoffice ) because submodules does not work well, they have simply rolled the modules back into core ... a single monolithic repo :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/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] Choosing a distributed version control system for PHP - problems
On Thu, Aug 18, 2011 at 10:28 AM, Lester Caine les...@lsces.co.uk wrote: Pierre Joye wrote: On Thu, Aug 18, 2011 at 9:32 AM, Lester Caineles...@lsces.co.uk wrote: Pierre Joye wrote: Another great example of a successful is the freedesktop project. They have 100s of sub project and each of them have modules. Can I suggest you have a closer look at this conversion Pierre and work out what is currently missing from it ... hint - as a new developer how do I 'check out (clone)' a copy of libraoffice. By RTFM:http://www.libreoffice.org/get-involved/developers/ Exactly ... While there were separate submodules for each section, as a result of converting the modular structure of the original CVS code base, those are now marked as obsolete ( http://cgit.freedesktop.org/libreoffice ) because submodules does not work well, they have simply rolled the modules back into core ... a single monolithic repo :( That's not the reason but the changes in how it was developed. See gstreamer or xorg for other examples with multiple modules. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: types conversion mistakes in cli's server
done in r315128 On Wed, Aug 17, 2011 at 5:19 PM, Pierre Joye pierre@gmail.com wrote: Hi There are many loosely conversions in the CLI web server. Mostly from (u)int64 to size_t (on 32bit platforms) or in64t to char, or the other way 'round. What was the goal to support 64bit data range for content length (or read data) in 32 bit environments? If LFS support was the goal, it could be possible to make it server large files but the way it is now won't work. Any objection if I change it to use exclusively size_t to avoid any possible issues? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- Pierre @pierrejoye | 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] Choosing a distributed version control system for PHP - problems
Pierre Joye wrote: On Thu, Aug 18, 2011 at 10:28 AM, Lester Caineles...@lsces.co.uk wrote: Pierre Joye wrote: On Thu, Aug 18, 2011 at 9:32 AM, Lester Caineles...@lsces.co.ukwrote: Pierre Joye wrote: Another great example of a successful is the freedesktop project. They have 100s of sub project and each of them have modules. Can I suggest you have a closer look at this conversion Pierre and work out what is currently missing from it ... hint - as a new developer how do I 'check out (clone)' a copy of libraoffice. By RTFM:http://www.libreoffice.org/get-involved/developers/ Exactly ... While there were separate submodules for each section, as a result of converting the modular structure of the original CVS code base, those are now marked as obsolete (http://cgit.freedesktop.org/libreoffice ) because submodules does not work well, they have simply rolled the modules back into core ... a single monolithic repo:( That's not the reason but the changes in how it was developed. Well I started a clone over an hour ago, and it's not 5% through yet ... many of the sections it's currently downloading I do not need to bother about. See gstreamer or xorg for other examples with multiple modules. Again neither of those seem to be using 'superprojects', just the odd library included as a submodule. This was the problem I hit last year. A nice CVS repo got translated into some 200 git repo's, but there still is no easy way of building a 'project' that pulls the say a core build with all the essential modules. You end up writing scripts to pull each and manage them individually. I would anticipate that php is probably larger than the libraoffice codebase, so being able to properly manage modular builds is going to be important? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/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] Choosing a distributed version control system for PHP - problems
On Thu, Aug 18, 2011 at 11:49 AM, Lester Caine les...@lsces.co.uk wrote: This was the problem I hit last year. A nice CVS repo got translated into some 200 git repo's, but there still is no easy way of building a 'project' that pulls the say a core build with all the essential modules. You end up writing scripts to pull each and manage them individually. I would anticipate that php is probably larger than the libraoffice codebase, so being able to properly manage modular builds is going to be important? Again, it is totally unrelated to git or hg but the choices of the developers. The discussion about having extensions (or whatever else) in external modules or in core (no matter which system is used, svn, git or hg) is not related to this topic. ps: it's libreoffice. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
Hey guys, After a brief discussion with Pierre I'm taking this discussion to here. We have the igbinary pecl extension available [1], however not many of our userbase are familiar that it even exists. Here [2] is the performance boost we get from using igbinary with serialize() and unserialize(). Here we get a great perf boost, and what's more excellent as we don't have to break BC to get there! This seems like a no-brainer and a good investment in the speed increase of PHP by default for the future users of the platform. [1] http://pecl.php.net/package/igbinary [2] http://www.php.net/~pierre/vcqa/apcigninary_perf.png Comments please. Regards, Paul Dragoonis.
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
Hi, On Thu, Aug 18, 2011 at 12:12 PM, Paul Dragoonis dragoo...@gmail.com wrote: Hey guys, After a brief discussion with Pierre I'm taking this discussion to here. We have the igbinary pecl extension available [1], however not many of our userbase are familiar that it even exists. Here [2] is the performance boost we get from using igbinary with serialize() and unserialize(). Here we get a great perf boost, and what's more excellent as we don't have to break BC to get there! It would break BC for anyone with serialized strings stored in the current format. Maybe bundle it in core and provide an ini setting like session.serialize_handler, but I don't think making it the default in 5.4 is an option. Regards, Arpad This seems like a no-brainer and a good investment in the speed increase of PHP by default for the future users of the platform. [1] http://pecl.php.net/package/igbinary [2] http://www.php.net/~pierre/vcqa/apcigninary_perf.png Comments please. Regards, Paul Dragoonis. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
I agree with bundling it in the core aswell, but having it as default, as stated, would be a huge BC break. 2011/8/18 Arpad Ray array...@gmail.com Hi, On Thu, Aug 18, 2011 at 12:12 PM, Paul Dragoonis dragoo...@gmail.com wrote: Hey guys, After a brief discussion with Pierre I'm taking this discussion to here. We have the igbinary pecl extension available [1], however not many of our userbase are familiar that it even exists. Here [2] is the performance boost we get from using igbinary with serialize() and unserialize(). Here we get a great perf boost, and what's more excellent as we don't have to break BC to get there! It would break BC for anyone with serialized strings stored in the current format. Maybe bundle it in core and provide an ini setting like session.serialize_handler, but I don't think making it the default in 5.4 is an option. Regards, Arpad This seems like a no-brainer and a good investment in the speed increase of PHP by default for the future users of the platform. [1] http://pecl.php.net/package/igbinary [2] http://www.php.net/~pierre/vcqa/apcigninary_perf.png Comments please. Regards, Paul Dragoonis. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
On Thu, Aug 18, 2011 at 1:30 PM, Arpad Ray array...@gmail.com wrote: Hi, On Thu, Aug 18, 2011 at 12:12 PM, Paul Dragoonis dragoo...@gmail.com wrote: Hey guys, After a brief discussion with Pierre I'm taking this discussion to here. We have the igbinary pecl extension available [1], however not many of our userbase are familiar that it even exists. Here [2] is the performance boost we get from using igbinary with serialize() and unserialize(). Here we get a great perf boost, and what's more excellent as we don't have to break BC to get there! It would break BC for anyone with serialized strings stored in the current format. Maybe bundle it in core and provide an ini setting like session.serialize_handler, but I don't think making it the default in 5.4 is an option. agree with the BC part, just wanted to mention that that igbinary can already be set as a session handler via session.serialize_handler if the extension present. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
On Thu, Aug 18, 2011 at 12:38 PM, Roger Llopart Pla lumben...@gmail.comwrote: I agree with bundling it in the core aswell, but having it as default, as stated, would be a huge BC break. 2011/8/18 Arpad Ray array...@gmail.com Hi, On Thu, Aug 18, 2011 at 12:12 PM, Paul Dragoonis dragoo...@gmail.com wrote: Hey guys, After a brief discussion with Pierre I'm taking this discussion to here. We have the igbinary pecl extension available [1], however not many of our userbase are familiar that it even exists. Here [2] is the performance boost we get from using igbinary with serialize() and unserialize(). Here we get a great perf boost, and what's more excellent as we don't have to break BC to get there! It would break BC for anyone with serialized strings stored in the current format. Maybe bundle it in core and provide an ini setting like session.serialize_handler, but I don't think making it the default in 5.4 is an option. Sorry guys, I didn't realise there was an actual BC break in the serialized structure. I agree with bundling and providing a .ini setting to activate, but off by default. Regards, Arpad This seems like a no-brainer and a good investment in the speed increase of PHP by default for the future users of the platform. [1] http://pecl.php.net/package/igbinary [2] http://www.php.net/~pierre/vcqa/apcigninary_perf.png Comments please. Regards, Paul Dragoonis. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
Hello everyone, My first post after watching the list for a while: my opionion on this would also be incorporate it into the core but with BC compatibility: the serializer could (easily from what i understand) check to see if the serialized format is in the `old` format and read that accordingly, but write it back in the new... That way the problem would 'clear' itself up.. ? (or is this just simple 'user'-level thinking? :P) With kind regards, Robin Speekenbrink Kingsquare Information Services Op 18-8-2011 13:48, Ferenc Kovacs schreef: On Thu, Aug 18, 2011 at 1:30 PM, Arpad Rayarray...@gmail.com wrote: Hi, On Thu, Aug 18, 2011 at 12:12 PM, Paul Dragoonisdragoo...@gmail.com wrote: Hey guys, After a brief discussion with Pierre I'm taking this discussion to here. We have the igbinary pecl extension available [1], however not many of our userbase are familiar that it even exists. Here [2] is the performance boost we get from using igbinary with serialize() and unserialize(). Here we get a great perf boost, and what's more excellent as we don't have to break BC to get there! It would break BC for anyone with serialized strings stored in the current format. Maybe bundle it in core and provide an ini setting like session.serialize_handler, but I don't think making it the default in 5.4 is an option. agree with the BC part, just wanted to mention that that igbinary can already be set as a session handler via session.serialize_handler if the extension present. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
hi!
On Thu, Aug 18, 2011 at 1:12 PM, Paul Dragoonis dragoo...@gmail.com wrote:
After a brief discussion with Pierre I'm taking this discussion to here.
For the record here, I'm not in favor of bundling igbinary (or other
custom serializer). My main concerns are:
. the PHP serializer can be overridden at runtime (as in after the build)
. there will always have some new faster, better, sexier serializer,
depending on the app/usages
. we can't enable it by default (as other stated too here) for BC
reason (and interop)
. not enabling it by default defeats the purpose of bundling it
. easier to support it while being only in pecl ('do you use the core
version or latest pecl?)
Cheers,
--
Pierre
@pierrejoye | 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] Activation of IGBinary serialization extension in 5.4 by default
Some others systems use something similar to syntax checking (ldap password hashes). Baisically, prefix a code to the serialized string to indicate what method was used to serialize. Eg no prefix, or $O$ for the old style. Or $I$ for the igbinary syntax. This has the advantage of allowing additional formats to be added over time without breaking BC. Kiall On Aug 18, 2011 12:49 p.m., Paul Dragoonis dragoo...@gmail.com wrote: On Thu, Aug 18, 2011 at 12:38 PM, Roger Llopart Pla lumben...@gmail.com wrote: I agree with bundling it in the core aswell, but having it as default, as stated, would be a huge BC break. 2011/8/18 Arpad Ray array...@gmail.com Hi, On Thu, Aug 18, 2011 at 12:12 PM, Paul Dragoonis dragoo...@gmail.com wrote: Hey guys, After a brief discussion with Pierre I'm taking this discussion to here. We have the igbinary pecl extension available [1], however not many of our userbase are familiar that it even exists. Here [2] is the performance boost we get from using igbinary with serialize() and unserialize(). Here we get a great perf boost, and what's more excellent as we don't have to break BC to get there! It would break BC for anyone with serialized strings stored in the current format. Maybe bundle it in core and provide an ini setting like session.serialize_handler, but I don't think making it the default in 5.4 is an option. Sorry guys, I didn't realise there was an actual BC break in the serialized structure. I agree with bundling and providing a .ini setting to activate, but off by default. Regards, Arpad This seems like a no-brainer and a good investment in the speed increase of PHP by default for the future users of the platform. [1] http://pecl.php.net/package/igbinary [2] http://www.php.net/~pierre/vcqa/apcigninary_perf.png Comments please. Regards, Paul Dragoonis. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
On Thu, 2011-08-18 at 12:48 +0100, Paul Dragoonis wrote: I agree with bundling and providing a .ini setting to activate, but off by default. An ini setting is evil for this. People use serialized data as transport format having that depend on an ini setting is bad. suggestions: - The decode function could check the format (old format will always begin by one of aisfb or so followed by a colon, igbinary something else) - serialize() might get an extra parameter to set the format - lateron, if we want: if old format is being use a deprecation notice is shown when the older fomrat is being used) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
Just add a check on what format is used on read, write with the new format. Deprecate the old format in next version after 5.4 (or drop it at all in 6.0 or whatever the new major version will be). Make a noise about the change (I can do that for the Russian speaking community with ease). It will be transparent. People using serialized caches can just drop them and re-init. People storing data can recode it with ease - just read it and write it back - it will be in new format. Problem solved :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
2011/8/18 Johannes Schlüter johan...@schlueters.de:
On Thu, 2011-08-18 at 12:48 +0100, Paul Dragoonis wrote:
I agree with bundling and providing a .ini setting to activate, but off by
default.
An ini setting is evil for this. People use serialized data as transport
format having that depend on an ini setting is bad.
we already do this (session.serialize_handler, defaults to our own
format, but can be set to wddx or igbinary)
the userland session handler should be handler agnostic, it shouldn't
really break the application if the serialization format change, as
the handler should know or care whats inside the $data as long as it
can be passed around.
but imo this sucks. your handler cannot look into the data, the only
available methods for packing and unpacking the session data can only
used to read and write the $_SESSION superglobal, so for example if
you to load another session for some reason, you have to save the
value of the $_SESSION, empty $_SESSION, load the encoded session,
call session_decode, fetch the $_SESSION then restore it from your
copy.
and I really hate that the php session format is almost compatible
with serialize/unserialize. if I remember correctly only lacks the
a:number_of_items_in_the_session:{} around the session data.
why did we did this? to save a few bytes? /o\
sorry for the rant.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
On Thu, 2011-08-18 at 15:33 +0200, Ferenc Kovacs wrote:
we already do this (session.serialize_handler, defaults to our own
format, but can be set to wddx or igbinary)
Well the session handler doesn't matter too much and is more of an admin
thing, unlike serialize()/unserialize(). Those are the ones which
shouldn't be set by configuration as they are used programmatically.
The format is relevant for session though, too, as people use memcache
or something to share sessions from multiple hosts.
and I really hate that the php session format is almost compatible
with serialize/unserialize. if I remember correctly only lacks the
a:number_of_items_in_the_session:{} around the session data.
why did we did this? to save a few bytes? /o\
History with register globals, back then each variable had to be
serialized individually based on the list of registered vars. We
resisted from changing the format to keep compatibility. (some people
also want to stay sessions alive while updating)
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
2011/8/18 Johannes Schlüter johan...@schlueters.de: On Thu, 2011-08-18 at 15:33 +0200, Ferenc Kovacs wrote: we already do this (session.serialize_handler, defaults to our own format, but can be set to wddx or igbinary) Well the session handler doesn't matter too much and is more of an admin thing, unlike serialize()/unserialize(). Those are the ones which shouldn't be set by configuration as they are used programmatically. you are right, sorry for the offtopic. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
I'm not so sure about that. For example, class PDO is PHP core. Suppose I
create A\PDO. When PHP is asked for A\PDO and fails to find it then it will
die. Correct me if I'm wrong but I think it does NOT go looking for \PDO.
Another bugbear is classes will most likely be 1 class = 1 file. Functions
will probably end up being all functions of the namespace, 1 file.
Perhaps there's another way to do this that isn't as fraught with confusion,
though I have no idea of what the engine details are or if it's possible.
Suppose you have an autoloading function that triggers the first time a
namespace is mentioned to pull up definitions for that namespace. So when
the engine sees namespace A; declared for the first time It sees if any
autoloaders are present for namespace A. If yes, it fires them loading the
library files for the namespace.
Another, similar, approach is one I've been using in my own framework. When
the class autoloader first sees a namespace, it checks the filesystem for a
namespace definition file that holds functions and constants of the
namespace and then loads it (require_once) along with the requested class.
Since my framework is object oriented calls to a function that doesn't
belong to a specific class will not be emitted outside of a class method and
this has been sufficient to handle the problem for which this RFC is
supposed to solve within PHP 5.3. Just a thought.
On Wed, Aug 17, 2011 at 5:44 PM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
There's nothing saying you can't have the exact same situation right now
with classes and autoloading, too.
Example:
namespace A;
class ReflectionClass
{ /* ... */ }
class MyClass
{ /* ... */ }
What if you have an autoloader that, on encountering A\MyClass then
loads that file? You've now redefined ReflectionClass for the A
namespace.
The main difference, of course, is that if ReflectionClass is not
explicitly imported, PHP will barf and tell you it doesn't know about
A\ReflectionClass.
While I understand your objections, I think that after the functionality
exists, there can be discussions about best practices -- e.g., putting
one function per file when autoloading, or documenting when all
functions for a given namespace will be in a single file. It's really a
matter of the project educating its users -- I don't think it should be
a blocker for implementing it at the language level, though.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.3.7 Released!
The PHP development team would like to announce the immediate availability of PHP 5.3.7. This release focuses on improving the stability of the PHP 5.3.x branch with over 90 bug fixes, some of which are security related. Security Enhancements and Fixes in PHP 5.3.7: * Updated crypt_blowfish to 1.2. (CVE-2011-2483) * Fixed crash in error_log(). Reported by Mateusz Kocielski * Fixed buffer overflow on overlog salt in crypt(). * Fixed bug #54939 (File path injection vulnerability in RFC1867 File upload filename). Reported by Krzysztof Kotowicz. (CVE-2011-2202) * Fixed stack buffer overflow in socket_connect(). (CVE-2011-1938) * Fixed bug #54238 (use-after-free in substr_replace()). (CVE-2011-1148) Key enhancements in PHP 5.3.7 include: * Upgraded bundled Sqlite3 to version 3.7.7.1 * Upgraded bundled PCRE to version 8.12 * Fixed bug #54910 (Crash when calling call_user_func with unknown function name) * Fixed bug #54585 (track_errors causes segfault) * Fixed bug #54262 (Crash when assigning value to a dimension in a non-array) * Fixed a crash inside dtor for error handling * Fixed bug #55339 (Segfault with allow_call_time_pass_reference = Off) * Fixed bug #54935 php_win_err can lead to crash * Fixed bug #54332 (Crash in zend_mm_check_ptr // Heap corruption) * Fixed bug #54305 (Crash in gc_remove_zval_from_buffer) * Fixed bug #54580 (get_browser() segmentation fault when browscap ini directive is set through php_admin_value) * Fixed bug #54529 (SAPI crashes on apache_config.c:197) * Fixed bug #54283 (new DatePeriod(NULL) causes crash). * Fixed bug #54269 (Short exception message buffer causes crash) * Fixed Bug #54221 (mysqli::get_warnings segfault when used in multi queries) * Fixed bug #54395 (Phar::mount() crashes when calling with wrong parameters) * Fixed bug #54384 (Dual iterators, GlobIterator, SplFileObject and SplTempFileObject crash when user-space classes don't call the parent constructor) * Fixed bug #54292 (Wrong parameter causes crash in SplFileObject::__construct()) * Fixed bug #54291 (Crash iterating DirectoryIterator for dir name starting with \0) * Fixed bug #54281 (Crash in non-initialized RecursiveIteratorIterator) * Fixed bug #54623 (Segfault when writing to a persistent socket after closing a copy of the socket) * Fixed bug #54681 (addGlob() crashes on invalid flags) * Over 80 other bug fixes. Windows users: please mind that we do no longer provide builds created with Visual Studio C++ 6. It is impossible to maintain a high quality and safe build of PHP for Windows using this unmaintained compiler. For Apache SAPIs (php5_apache2_2.dll), be sure that you use a Visual Studio C++ 9 version of Apache. We recommend the Apache builds as provided by ApacheLounge. For any other SAPI (CLI, FastCGI via mod_fcgi, FastCGI with IIS or other FastCGI capable server), everything works as before. Third party extension providers must rebuild their extensions to make them compatible and loadable with the Visual Studio C++9 builds that we now provide./p All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.7. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Autotests: Access denied for user 'root'@'localhost' (using password: NO)
On August-17-11 8:04 PM Roger Llopart Pla wrote: That use, or, if it's a development machine, leave it as it is since it does it's work just fine. 2011/8/18 Reindl Harald h.rei...@thelounge.net Am 18.08.2011 01:30, schrieb Stas Malyshev: Hi! well but using root as default is a little bit crazy using user test with empty password is acceptable but root It's not _that_ root. For mysql, it's just a default user name. Most people would run it on development machines with mysql configured not to answer to network, so it's not of a problem it IS THAT root of mysql please do not believe i think it has anything to do with system-root i am doing this job now since ten years :-) using a build/test-server with mysql-driven pure-ftpd and phpmyadmin while having horde-webmail also on the test-machine and you are f**ed with a mysql-root without password the only sense for the default-root without pwd in mysql is to enter mysql -u root and set your pwd directly after install It strikes me that the out-of-the-box test only works on a fresh clean install of MySQL. The install docs for MySQL strongly recommend changing that immediately after the install - which I think most people do - so I doubt very much those are the credentials for the vast majority of MySQL installs in the world. I'm wondering if adding a prompt for the mysql username and password, with the defaults set as is, would be possible, and if so, if someone were to offer a patch why it shouldn't be considered. IMHO, if the defaults were used and the tests ran successfully, I'd be tempted to display a console message along the lines of your myself default root credentials are wide open, are you being silly? Best Regards, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Autotests: Access denied for user 'root'@'localhost' (using password: NO)
On Thu, 2011-08-18 at 11:55 -0400, Mike Robinson wrote: I'm wondering if adding a prompt for the mysql username and password, with the defaults set as is, would be possible, and if so, if someone were to offer a patch why it shouldn't be considered. since you would need quite a few prompts. It's not about MySQL only what about other databases? We also have other tests which are configurable in one way or the other. But you can easily set the mentioned environment variables and be done. IMHO, if the defaults were used and the tests ran successfully, I'd be tempted to display a console message along the lines of your myself default root credentials are wide open, are you being silly? Well as Stas said - on a developer machine where MySQL is not lsitening to the outside and doesn't store confidential data there is no harm in having a mysql root without password. Anybody who can exploit it can already execute arbitrary code which is way more critical. johannes (who doesn't get the excitement in this thread) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Function autoloading through spl_autoload*
Hi! On 8/17/11 3:15 PM, Sebastian Krebs wrote: However, in my opinion the important part is to just make a decision the sooner, the better, as long as there are not too much creepy code out there (I don't know any and I can't imagine, that there is). Because functions with namespace are quite unhandy without autoloading and I don't think, that there is much use of it. We already made the decision, when we introduced the namespaces and made the resolution order what it is now. And we considered all the variants and discussed all the arguments brought here back then. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Autotests: Access denied for user 'root'@'localhost' (using password: NO)
Am 18.08.2011 00:46, schrieb Reindl Harald: Wouldn't it be a good idea to specify here a user/pwd/database for build-systems without force them open root without password? SKIP mysql_get_host_info() [ext/mysql/tests/mysql_get_host_info.phpt] reason: Can't connect to MySQL Server - [1045] Access denied for user 'root'@'localhost' (using password: NO) Please, configure the tests to use whatever database user you want them to use prior to running. If nothing else is configured, the tests need to make a guess on the on the DB credentials. The guess is user=root, password= as such a DB account is available when doing, for example, a source installation of MySQL. Have a look at http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/mysql/tests/connect.inc?revision=296885view=markup . It tries to check the environment for variable to allow for easy configuration but ultimately has some defaults in it. This is a common pattern, for example, check http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/oci8/tests/details.inc?revision=312024view=markup . If no configuration done through environment settings, OCI8 tests default to DB user system, password oracle - whatever user that is. grep -R getenv ext/*/tests/*.inc - ext/ldap - ext/mysqli - ext/mysql - ext/oci8 - ext/pdo_mysql - ext/pdo_pgsql - ext/pdo - ext/sybase grep -R getenv ext/*/tests/*.phpt - ext/curl - ext/pdo_pretty_much_all_of_them A potential pitfall that affects all test writers trying to allow configuration via environment settings is the - certainly sensible - variables_order setting found in php.ini-development and php.ini-production. php.ini-development:variables_order = GPCS php.ini-production:variables_order = GPCS If any of the two is used as a configuration file for running tests through run-tests.php, run-tests.phpt will not be able provide tests with all environment variables, http://lxr.php.net/xref/PHP_5_3/run-tests.php#140 . run-tests.php relies on $_ENV and $_ENV is empty. To make a long story short: tests may require manual configuration prior to running. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
Hi!
On 8/18/11 5:22 AM, Pierre Joye wrote:
. not enabling it by default defeats the purpose of bundling it
Actually, I don't think it does. It's one thing to tell people put this
option into php.ini and quite another is download it from PECL (?),
compile it (?!) and install it. The first is within the limits of any
literate person, the second is sysadmin territory.
. easier to support it while being only in pecl ('do you use the core
version or latest pecl?)
It is a concern, if this extension is not stable yet. Is it?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Choosing a distributed version control system for PHP - problems
On 2011-08-18, Lester Caine les...@lsces.co.uk wrote: Again neither of those seem to be using 'superprojects', just the odd library included as a submodule. It seems that the statements in the RFC were not clear enough, I'll add some explanation. We will very probably not use submodules in php-src anyway. Other module will define what's best for them. Please talk about the RFC and it's content. If you have a certain problem with a certain section in the RFC i'm happy to discuss it. At the moment I cannot see what the topic adds to the RFC discussion. I will clarify some things anyway. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: json_encode option for not escaping unnecessary character
I know that molestation is evil, but how's my patch? ) I would really like to see this functionality in php 5.4. In many projects with utf8, we are forced to use non native json_encode now With regards, Alexander Moskaliov ir...@irker.net 2011/8/4 Scott MacVicar sc...@macvicar.net: Never got the email, will look today at it. Doesn't quite match our coding standards from the first glance. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Choosing a distributed version control system for PHP - problems
David Soria Parra wrote: On 2011-08-18, Lester Caineles...@lsces.co.uk wrote: Again neither of those seem to be using 'superprojects', just the odd library included as a submodule. It seems that the statements in the RFC were not clear enough, I'll add some explanation. We will very probably not use submodules in php-src anyway. Other module will define what's best for them. Just for the record ... the libreoffice clone I started 9 hours ago is still going strong, and I'm estimating that it will finish some time tomorrow afternoon, another 20 hours or so. A single huge repo is going to take time to handle? Or am I doing something wrong? All I've done at the moment is followed the instructions Pierre directed me to ... they were not on the original notes I looked at. Please talk about the RFC and it's content. If you have a certain problem with a certain section in the RFC i'm happy to discuss it. At the moment I cannot see what the topic adds to the RFC discussion. I simply don't see the point of the rfc? Starting with the drawbacks on SVN ... they were ignored when used as reasons to not move from CVS. People had already decided that a move should take place and when DVCS was brought up then it was not seen as a reason hold fire since people wanted to plough on. Lets not plough on with another change without fully understanding the problem? Many of us are already using DVCS, and so the question is one of how do we link from our preferred DVCS system into what ever PHP does. git simply does not work for me and so I am already committed to hg. HAVING broken things down into subrepos in hg, I can now build projects just using the modules I need, and I don't need to carry around lots of unused history. Trying to follow the trees of some single repo projects on github and elsewhere can be almost impossible. I will clarify some things anyway. In 'Moving extension from/to core to/from pecl' 'Commits across multiple subrepositories will lead to separate commits.' When making a change which affects several modules then the reason for the change needs to be properly documented. This is why I say that we need a proper management of these changes. A good example in the past was the bugs introduced into several of the database drivers by global changes. php_interbase and others developed a problem with bolb ID's being corrupted. Trying to track why and where changes had been made was a problem, and just being able to isolate the one driver and fix that was fun. Had the commits to each driver been separated, repairing the damage would have been a lot easier? Changes that create patches to hundreds of files in the one commit would seem to be a lot more of a problem than distributing those commits, and logging the details of each module affected in the base bug/feature report justifying a global change? Moving on from that ... probably 50% of the 'core modules' are essentially optional, so being able to 'pick and choose' the modules you want makes perfect sense, much as we all do when selecting modules in the build process. Why do you need a combined history across an array of modules? Although I don't see anything preventing one being created since all the information is available? I flag changes that have a global effect, but the bulk of commits are always within a single module. If they affect a second module it may well be that something is wrong with the segregation of the activity and that needs to be looked at? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/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] [RFC] Function autoloading through spl_autoload*
On Thu, Aug 18, 2011 at 7:19 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 8/17/11 3:15 PM, Sebastian Krebs wrote: However, in my opinion the important part is to just make a decision the sooner, the better, as long as there are not too much creepy code out there (I don't know any and I can't imagine, that there is). Because functions with namespace are quite unhandy without autoloading and I don't think, that there is much use of it. We already made the decision, when we introduced the namespaces and made the resolution order what it is now. And we considered all the variants and discussed all the arguments brought here back then. could you link the discussion about the function autoloading back then? I only found the namespace resolution discussion, but nothing about functions, except that they should fall back to the global namespace as we don't have/didn't have autoloaders for them. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Activation of IGBinary serialization extension in 5.4 by default
hi Stas!
On Thu, Aug 18, 2011 at 7:27 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
. not enabling it by default defeats the purpose of bundling it
Actually, I don't think it does. It's one thing to tell people put this
option into php.ini and quite another is download it from PECL (?),
compile it (?!) and install it. The first is within the limits of any
literate person, the second is sysadmin territory.
All major distros have it already, so it is the same. Now, if it is
not enabled by default, then many admins won't install it, back to the
same problem. It is very unlikely that someone with root or admin
perms won't be able to install an extra extension from the distro
repository or using the DLL on windows.
. easier to support it while being only in pecl ('do you use the core
version or latest pecl?)
It is a concern, if this extension is not stable yet. Is it?
It is stable. But the concern is not about its stability but the ease
of support. Having it in core means than some users may use (for
example) 5.4.2 version while we are at 5.4.6 or pecl has 3 new
versions. Not a big deal, just easier.
That being said, I'm not opposed to include it, I only don't see it as
a must go :)
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
