Re: [PHP-DEV] [RESULT] [RFC] PHP 5.7
Hi, On 08/01/2015 21:28, Andrea Faulds wrote: The vote on the PHP 5.7 RFC has closed. By 19 votes to 14, the RFC has been rejected. This means we won’t be having a PHP 5.7 release, unless another RFC is made and voted on. I am still convinced that it was premature to open the voting on the 5.7 RFC. The current PHP7 doesn't have huge BC breaks as far as I can tell, and that's why I (and possibly others) have voted "no". As of now, PHP 5.7 would have been for me just one more PHP version to take into account for CI/QA/testing. A burden if you will. This might however change in the future, depending on the results of forthcoming RFCs. If some "evil" BC breaks get to PHP7, then having 5.7 might have been handy, but we've just ruled out this possibility. Still, I just didn't feel it was right to vote "yes" based on such uncertainty. Cheers -- Matteo Beccati Development & Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.21RC1 is ready for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 08/01/2015 20:13, Anthony Ferrara a écrit : > That test is bogus and is testing undocumented functionality. Thanks for your explanation. Horde test suite have be fixed by upstream. Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlSvq2MACgkQYUppBSnxahgDLwCfVu3i4orx+JVCwXD2saG3g787 eeMAn0JtcF/CmvyS4F9WOrGAzTe5JVeW =fYdX -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5.21RC1 is ready for testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 08/01/2015 20:20, Adam Harvey a écrit : > On 8 January 2015 at 10:24, Remi Collet > wrote: >> Is this expected ? >> >> Notice the diff between (see attachement) : - - 5.4.35 and 5.4.36 >> show 5 changes, - - 5.5.20 and 5.521RC1 show only 2 - - 5.6.4 >> and 5.6.5RC1 show only 2 > > Since you mentioned on IRC that this seemed inconsistent, My first check was too quick. After another review, diff is expected (lot of changes between 5.4 and 5.5 in crypt.c). Remi. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlSvq6UACgkQYUppBSnxahgB2QCgrszBplLXIRXfS9lGOqwHYUG7 etsAoJm9Bfz09W0vPVVD5NV4vB8/AWhr =ayYs -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] snaps.php.net is closed?
Hi all, I cannot access snaps.php.net while. I guess snaps.php.net is closed infavor of github download. However, bugs.php.net referes to it. https://bugs.php.net/bug.php?id=68679 If snaps.php.net is closed, bugs.php.net should be fixed. Shouldn't it be announce somewhere? (Or I missed) Can anyone take care this? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] libsodium for PHP 7?
On Fri, 2015-01-02 at 12:05 -0500, Scott Arciszewski wrote: > Right now, the libsodium PECL package is in the beta channel. Would it be > possible to include libsodium as a core extension in PHP 7? If so, what > hurdles would need to be cleared before that happens? This should be an FAQ, maybe somebody can put it on the wiki or somewhere: For most users it doesn't matter if an extension is bundled or distributed via PECL. Once Linux/Unix distributors get a hand on it they package it as an independent package, independently from being in core or not and the user has to install the "phpX-foo" package. For Windows this is similar - most extensions are provided as dll which has to be activated. The only once for whom this is a notable difference are the ones who build PHP themselves, but for them it shouldn't be a big hurdle. Having it in PECL means that it simplifies PHP release process (one less moving piece) and the maintainers are more flexible in regards to evolving the extension API by not being bound to PHP's stricter BC rules. By being bundled (in theory) it gets more eyes looking at it (while we have enough bundled extensions which receive barely attention as a counter-prove) It has to be bundled if we want to force it on all users (we hardly do that) or some other core components depend on it. In my personal opinion we should continue moving stuff out instead of in. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libsodium for PHP 7?
You're right, a cursory Google search reveals that someone is maintaining a php5-nacl package that uses libsodium. This simplifies instructions greatly! :D On Jan 9, 2015 6:11 AM, "Johannes Schlüter" wrote: > On Fri, 2015-01-02 at 12:05 -0500, Scott Arciszewski wrote: > > Right now, the libsodium PECL package is in the beta channel. Would it be > > possible to include libsodium as a core extension in PHP 7? If so, what > > hurdles would need to be cleared before that happens? > > This should be an FAQ, maybe somebody can put it on the wiki or > somewhere: > > For most users it doesn't matter if an extension is bundled or > distributed via PECL. Once Linux/Unix distributors get a hand on it they > package it as an independent package, independently from being in core > or not and the user has to install the "phpX-foo" package. For Windows > this is similar - most extensions are provided as dll which has to be > activated. The only once for whom this is a notable difference are the > ones who build PHP themselves, but for them it shouldn't be a big > hurdle. > > Having it in PECL means that it simplifies PHP release process (one less > moving piece) and the maintainers are more flexible in regards to > evolving the extension API by not being bound to PHP's stricter BC > rules. > > By being bundled (in theory) it gets more eyes looking at it (while we > have enough bundled extensions which receive barely attention as a > counter-prove) > > It has to be bundled if we want to force it on all users (we hardly do > that) or some other core components depend on it. > > In my personal opinion we should continue moving stuff out instead of > in. > > johannes > > >
Re: [PHP-DEV] [BugFest] Feature request #38685: str_[i]replace(): Add support for (string needle, array replace)
Hi, Just wanted to say: +1 on this and thank you for proposing a patch. I myself created a feature request for it on bugs.php.net some time ago, now closed as duplicate: https://bugs.php.net/bug.php?id=62315 Cheers, Andrey. On Fri, Jan 9, 2015 at 2:08 AM, François Laupretre wrote: > Hi, > > I just created the RFC : > > https://wiki.php.net/rfc/cyclic-replace > > I tried to include everything we agreed upon. Tell me if I missed something. > > Please note that the current PR does not implement the whole RFC. You may > review the RFC while I update the code. > > Please also give me your opinion about implementing a similar feature in > preg_replace() and preg_filter(). > > Regards, > > François > > > -- > PHP Internals - PHP Runtime Development Mailing List > 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] [BugFest] Feature request #38685: str_[i]replace(): Add support for (string needle, array replace)
> De : François Laupretre [mailto:franc...@tekwire.net] > > I just created the RFC : > > https://wiki.php.net/rfc/cyclic-replace Just added full array multi-level recursion support to the RFC. Still debugging the code and adding new tests. > Please also give me your opinion about implementing a similar feature in > preg_replace() and preg_filter(). So ? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Crypt Warnings (was PHP 5.5.21RC1 is ready for testing)
All,
As identified in the previous thread, there is an issue when providing
invalid salts to crypt() where it will silently fall back to STD_DES.
This was evidenced by a fix to crypt() when upgrading blowfish to 1.3.
Causing a failing test for Horde_Auth:
$ php -r 'var_dump(crypt("foobar", "*0OayF9ttbxIs"));'
string(13) "*0OayF9ttbxIs"
With 5.4.36 / 5.5.21RC1 (with)
$ php55 -r 'var_dump(crypt("foobar", "*0OayF9ttbxIs"));'
string(2) "*1"
The new behavior is absolutely correct due to *0 and *1 being error
conditions, so any salt with *0 should immediately fail with *1 (to
prevent one equaling the other). Previously it was used as a salt for
STD_DES.
This raises another issue though. Currently, an invalid bcrypt salt
such as $2$10$... would actually result in a DES hash:
string(13) "$2rcByx51ejoM"
Which is completely incorrect.
This not only hides errors, but it falls back to an absurdly insecure
format while hiding them. It's worth noting that this case will cause
HHVM to fail with *0.
Changing this fallback behavior to the correct error should happen.
However, this will likely break a number of live systems which are
currently relying on the incorrect behavior (likely without knowing
it).
It's worth nothing that failing is the currently documented behavior:
http://php.net/crypt
Therefore, I'm suggesting we add an E_DEPRECATED error when we detect
an invalid STD_DES salt but still execute the fallback:
https://github.com/php/php-src/pull/989
Then in a future version (7.1, 8, whatever) remove the fallback and
keep the error along with returning a failure indication (*0).
I'm open to tweaking the error message, and possibly changing to
E_WARNING if people think it's worth it.
Thoughts?
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Pre-Vote] Return Types
> The implementation misses support for reflection. > I think, it doesn't make a lot of sense to introduce Reflection support for > return types but not for argument types. > Probably, it's better to provide a single and consistent RFC for both. There is a draft RFC for this that Sara and I have each worked on a bit: https://wiki.php.net/rfc/reflectionparameter.typehint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Pre-Vote] Return Types
yeah, I remember I saw something :) Lets do the core work first and then decide how the Reflection should look like. Thanks. Dmitry. On Fri, Jan 9, 2015 at 9:26 PM, Levi Morrison wrote: > > The implementation misses support for reflection. > > I think, it doesn't make a lot of sense to introduce Reflection support > for > > return types but not for argument types. > > Probably, it's better to provide a single and consistent RFC for both. > > There is a draft RFC for this that Sara and I have each worked on a > bit: https://wiki.php.net/rfc/reflectionparameter.typehint >
[PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye wrote: > The fact that hhvm implements a significant part of the extensions (or > other areas) using PHP+additional syntax as well as adding cleaner > APIs or mechanisms for the C parts only confirms me one thing: the > very 1st problem we have to solve is to ease the extension creation, > by drastically changing the internals APIs & tools. Bundling script > does not help here, we are using a scotch tape to repair something > that should have been replaced or redesigned since long already. I am > not blaming anyone, the engine design, historically, does not make > such changes easy. > Funny to see you mention this. I literally just pulled together a meeting today to discuss HHVM's admittedly unstable extension API. One idea to emerge from this was to design a new extension API agnostic of underlying implementation. An API which, if done right, could be adapted equally to both PHP7 and HHVM *and* provide the opportunity to introduce PHP5 shims so that a single extension could be written to function identically under any PHP runtime, and any version. If done right, could make extensions not just source compatible, but *binary* compatible as well. The engine details can change, but the public-facing extension API could offer a consistent way of doing the one and only thing that extensions should have to do: Glue PHP into external libraries. That's a bit pie in the sky, I'll admit, but wouldn't that be cool? Fact is, JNI does this for Java already, so there's precedence to learn from. Heck, we're actually halfway there with HHVM's "ext_zend_compat" layer, which makes PHP extensions (mostly) source compatible with HHVM. While I could work on this in the dark, manipulating HHVM's APIs with one hand and adding proxy interfaces to PHP (as an extension) with the other, I'd much rather have involvement from others. What do you think? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [BugFest] Feature request #38685: str_[i]replace(): Add support for (string needle, array replace)
> De : François Laupretre [mailto:franc...@tekwire.net] > > > I just created the RFC : > > > > https://wiki.php.net/rfc/cyclic-replace > > Just added full array multi-level recursion support to the RFC. Final (?) patch pushed to PR. In sync with RFC. > > Please also give me your opinion about implementing a similar feature in > > preg_replace() and preg_filter(). No opnion here ? Do we need to wait 2 weeks to start voting ? It seems no one has anything more to say. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
Hey Sara, > On 10 Jan 2015, at 01:10, Sara Golemon wrote: > > Funny to see you mention this. I literally just pulled together a > meeting today to discuss HHVM's admittedly unstable extension API. > One idea to emerge from this was to design a new extension API > agnostic of underlying implementation. An API which, if done right, > could be adapted equally to both PHP7 and HHVM *and* provide the > opportunity to introduce PHP5 shims so that a single extension could > be written to function identically under any PHP runtime, and any > version. If done right, could make extensions not just source > compatible, but *binary* compatible as well. The engine details can > change, but the public-facing extension API could offer a consistent > way of doing the one and only thing that extensions should have to do: > Glue PHP into external libraries. > > That's a bit pie in the sky, I'll admit, but wouldn't that be cool? > Fact is, JNI does this for Java already, so there's precedence to > learn from. Heck, we're actually halfway there with HHVM's > "ext_zend_compat" layer, which makes PHP extensions (mostly) source > compatible with HHVM. > > While I could work on this in the dark, manipulating HHVM's APIs with > one hand and adding proxy interfaces to PHP (as an extension) with the > other, I'd much rather have involvement from others. > > What do you think? Yes, I like this idea. Three APIs for TheFacebook under the sky, Seven for the Zend-lords in their halls of stone, Nine for the Engines doomed to die, One for the Dark Lord on his dark throne, In the Land of Native where the Undefined Behaviours lie. One API to rule them all, One API to find them, One API to bring them all and in the darkness bind them In the Land of Native where the Undefined Behaviours lie. *ahem* Er, sorry about that. I think this is a good idea. Most PHP extensions do not require tight coupling to the Zend Engine (or indeed HHVM). Something simple which exposes class, function and constant definition, and abstract PHP value (zval) handling, would be enough for the vast majority of extensions, I should think. There’ll always be a place for tightly-coupled extensions which need to use the engine’s “native” API, but something simple and cross-implementation would work for most extensions, allow better cross-implementation PHP code compatibility, and generally be a Good Thing(TM), I think. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
On Fri, Jan 9, 2015 at 5:41 PM, Andrea Faulds wrote: > Three APIs for TheFacebook under the sky, > Seven for the Zend-lords in their halls of stone, > Nine for the Engines doomed to die, > One for the Dark Lord on his dark throne, > In the Land of Native where the Undefined Behaviours lie. > One API to rule them all, One API to find them, > One API to bring them all and in the darkness bind them > In the Land of Native where the Undefined Behaviours lie. > *slowclap* > I think this is a good idea. Most PHP extensions do not require > tight coupling to the Zend Engine (or indeed HHVM). Something > simple which exposes class, function and constant definition, > and abstract PHP value (zval) handling, would be enough for > the vast majority of extensions, I should think. > Exactly. This is what we learned from making ext_zend_compat. Basic glue extensions are the majority, those places where a lot of extensions currently "link deep" are simply because they can, but not because they need to. > There’ll always be a place for tightly-coupled extensions which > need to use the engine’s “native” API, but something simple and > cross-implementation would work for most extensions, allow > better cross-implementation PHP code compatibility, and generally > be a Good Thing(TM), I think. > For the handful that do funky stuff like OpCache+, Xdebug, etc... They can explicitly reach behind the artifice with the understanding that they're not necessarily going to work from version to version without loads of #ifdefs and kinky machinations. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
On 10 Jan 2015 01:10, "Sara Golemon" wrote: > > On Thu, Jan 8, 2015 at 5:44 PM, Pierre Joye wrote: > > The fact that hhvm implements a significant part of the extensions (or > > other areas) using PHP+additional syntax as well as adding cleaner > > APIs or mechanisms for the C parts only confirms me one thing: the > > very 1st problem we have to solve is to ease the extension creation, > > by drastically changing the internals APIs & tools. Bundling script > > does not help here, we are using a scotch tape to repair something > > that should have been replaced or redesigned since long already. I am > > not blaming anyone, the engine design, historically, does not make > > such changes easy. > > > Funny to see you mention this. I literally just pulled together a > meeting today to discuss HHVM's admittedly unstable extension API. > One idea to emerge from this was to design a new extension API > agnostic of underlying implementation. An API which, if done right, > could be adapted equally to both PHP7 and HHVM *and* provide the > opportunity to introduce PHP5 shims so that a single extension could > be written to function identically under any PHP runtime, and any > version. If done right, could make extensions not just source > compatible, but *binary* compatible as well. The engine details can > change, but the public-facing extension API could offer a consistent > way of doing the one and only thing that extensions should have to do: > Glue PHP into external libraries. > > That's a bit pie in the sky, I'll admit, but wouldn't that be cool? > Fact is, JNI does this for Java already, so there's precedence to > learn from. Heck, we're actually halfway there with HHVM's > "ext_zend_compat" layer, which makes PHP extensions (mostly) source > compatible with HHVM. > > While I could work on this in the dark, manipulating HHVM's APIs with > one hand and adding proxy interfaces to PHP (as an extension) with the > other, I'd much rather have involvement from others. > > What do you think? Hi Sara, Somewhat Pie in the sky but at the same time also achievable with good planning and design. I'd support this definitely and this abstraction layer would solve constant maintainability of extensions by not having to update themselves constantly to support latest versions of PHP due to a lack of abstraction. Did that make sense ? > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Re: [PHP-DEV] One API to rule them all? (Was: Extension Prepend Files)
On Fri, Jan 9, 2015 at 5:48 PM, Paul Dragoonis wrote: > Somewhat Pie in the sky but at the same time also achievable with good > planning and design. I'd support this definitely and this abstraction layer > would solve constant maintainability of extensions by not having to update > themselves constantly to support latest versions of PHP due to a lack of > abstraction. > Yep. Exactly what I'm thinking. I forsee defining this PHP<->Native Interface (I hereby dub it "PNI") as part of the php-langspec such that part of being a conforming implementation includes supporting this API. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [BugFest] Feature request #38685: str_[i]replace(): Add support for (string needle, array replace)
On Jan 10, 2015 8:35 AM, "François Laupretre" wrote: > > > De : François Laupretre [mailto:franc...@tekwire.net] > > > > > I just created the RFC : > > > > > > https://wiki.php.net/rfc/cyclic-replace > > > > Just added full array multi-level recursion support to the RFC. > > Final (?) patch pushed to PR. In sync with RFC. > > > > Please also give me your opinion about implementing a similar feature in > > > preg_replace() and preg_filter(). > > No opnion here ? > > Do we need to wait 2 weeks to start voting ? It seems no one has anything > more to say. Yes please. Even more now as some are still in vacations.
