Re: [PHP-DEV] PHP7 releases vs Windows Sources?

Hi! > about signing, recently I got a question that somebody couldn't verify > the tarball signature, because he was trying to verify the extracted > contents instead of the compressed file. > he was trying to do that, because that is how the kernel.org > releases are signed: >

Re: [PHP-DEV] php 7/git buid on linux/64: fatal error @ 'Installing PEAR environment';

On Jun 16, 2015 11:35 PM, "Hannes Magnusson" wrote: > > On Tue, Jun 16, 2015 at 9:14 AM, Sebastian Bergmann wrote: > > Am 16.06.2015 um 18:10 schrieb Ferenc Kovacs: > >> did not have more time to test though, so any feedback is appreciated. > > > > I still think that the right solution would be

Re: [PHP-DEV] Re: [PHP-WEBMASTER] RE: [PHP-DEV] PHP7 releases vs Windows Sources?

On Wed, Jun 17, 2015 at 12:17 AM, Johannes Schlüter wrote: > On Mon, 2015-06-15 at 22:45 +0700, Pierre Joye wrote: >> Yep, this could work and were probably proper solution. Except we >> wouldn't add some issue for the non Windows users :) I'm not sure, why >> is it done so ATM, probably it has it

Re: [PHP-DEV] PHP7 releases vs Windows Sources?

On Wed, Jun 17, 2015 at 12:20 AM, Christoph Becker wrote: > Johannes Schlüter wrote: > > > On Tue, 2015-06-16 at 02:02 +0200, Christoph Becker wrote: > >> Johannes Schlüter wrote: > >> > >>> It is not including the generated parsers. This means the user might > use > >>> a different version, whic

Re: [PHP-DEV] PHP7 releases vs Windows Sources?

Johannes Schlüter wrote: > On Tue, 2015-06-16 at 02:02 +0200, Christoph Becker wrote: >> Johannes Schlüter wrote: >> >>> It is not including the generated parsers. This means the user might use >>> a different version, which might cause a bug which might be hard to >>> debug as usage of provided f

Re: [PHP-DEV] Re: [VOTE] JSON number to string

Hi Jakub, On Wed, Jun 17, 2015 at 5:16 AM, Jakub Zelenka wrote: > On Tue, Jun 9, 2015 at 7:23 PM, Jakub Zelenka wrote: > > > > > The voting is now open: > > > > https://wiki.php.net/rfc/json_numeric_as_string#voting > > > > > The RFC has been rejected (all 4 proposed options). > > The bug https

[PHP-DEV] Re: [VOTE] JSON number to string

Hi On Tue, Jun 9, 2015 at 7:23 PM, Jakub Zelenka wrote: > > The voting is now open: > > https://wiki.php.net/rfc/json_numeric_as_string#voting > > The RFC has been rejected (all 4 proposed options). The bug https://bugs.php.net/bug.php?id=68456 (proposing such flag for float decoding) will be c

Re: [PHP-DEV] Re: [PHP-WEBMASTER] RE: [PHP-DEV] PHP7 releases vs Windows Sources?

On Mon, 2015-06-15 at 22:45 +0700, Pierre Joye wrote: > Yep, this could work and were probably proper solution. Except we > wouldn't add some issue for the non Windows users :) I'm not sure, why > is it done so ATM, probably it has its historical reasons. But this > would probably cause us need to

Re: [PHP-DEV] [VOTE] JSON number to string

Martin, I am guessing it's the same reason as Derick?. On Wed, Jun 17, 2015 at 12:39 AM, Pascal MARTIN, AFUP < mail...@pascal-martin.fr> wrote: > > Le 09/06/2015 20:23, Jakub Zelenka a écrit : > >> The voting is now open: >> >> https://wiki.php.net/rfc/json_numeric_as_string#voting >> > > Hi, > >

Re: [PHP-DEV] [VOTE] JSON number to string

Le 09/06/2015 20:23, Jakub Zelenka a écrit : The voting is now open: https://wiki.php.net/rfc/json_numeric_as_string#voting Hi, Discussing this RFC with other people at AFUP, we would, by a small margin, also be on the -1 side (for all 4 points). Still, if this was to pass, we would be +1

Re: [PHP-DEV] php 7/git buid on linux/64: fatal error @ 'Installing PEAR environment';

On Tue, Jun 16, 2015 at 9:14 AM, Sebastian Bergmann wrote: > Am 16.06.2015 um 18:10 schrieb Ferenc Kovacs: >> did not have more time to test though, so any feedback is appreciated. > > I still think that the right solution would be to simply not bundle / > install PEAR anymore. That probably

Re: [PHP-DEV] php 7/git buid on linux/64: fatal error @ 'Installing PEAR environment';

Am 16.06.2015 um 18:10 schrieb Ferenc Kovacs: > did not have more time to test though, so any feedback is appreciated. I still think that the right solution would be to simply not bundle / install PEAR anymore. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http

Re: [PHP-DEV] php 7/git buid on linux/64: fatal error @ 'Installing PEAR environment';

On Wed, Jun 10, 2015 at 5:19 PM, wrote: > Hi Patrick > > On Wed, Jun 10, 2015, at 08:15 AM, Patrick ALLAERT wrote: > > ereg_*() functions are deprecated since a long time and has been removed > in > > PHP 7. > > Understood. > > Since I'm simply attempting to build PHP7 from source, not, as yet, '

Re: [PHP-DEV] [RFC][VOTE] Throwable Interface

Hello, Voting for the Throwable Interface RFC has been changed to remain open only through today at midnight EST so the patch can be merged and tested before the next alpha release. https://wiki.php.net/rfc/throwable-interface Regards, Aaron Piotrowski -- PHP Internals - PHP Runtime Developmen

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Make CALL VM with FP and IP in global registers not to return anything from opcode handlers. Set OPLINE to NULL to terminate VM loop instead. This saves 1 CPU

right. thanks. Dmitry. On Tue, Jun 16, 2015 at 3:20 PM, Matt Wilmas wrote: > Hi Dmitry, > > - Original Message - > From: "Dmitry Stogov" > Sent: Tuesday, June 16, 2015 > > Commit:48ed660cdf6fe94ac2cd8eac217ea97340766e75 > Author:Dmitry Stogov Tue, 16 Jun 2015 > 14:11:16

Re: [PHP-DEV] [RFC] Throwable Interface

On Tue, Jun 16, 2015 at 1:41 AM, Marcio Almada wrote: > Hi, > > 2015-06-15 19:25 GMT-03:00 Aaron Piotrowski : > > > >> On Jun 15, 2015, at 4:02 PM, Anatol Belski > wrote: > >> I would then suggest Aaron to stick to the minimal voting period > (announcing this as early as possible), if the voting

[PHP-DEV] Re: [PHP-CVS] com php-src: Make CALL VM with FP and IP in global registers not to return anything from opcode handlers. Set OPLINE to NULL to terminate VM loop instead. This saves 1 CPU inst

Hi Dmitry, - Original Message - From: "Dmitry Stogov" Sent: Tuesday, June 16, 2015 Commit:48ed660cdf6fe94ac2cd8eac217ea97340766e75 Author:Dmitry Stogov Tue, 16 Jun 2015 14:11:16 +0300 Parents: 3180b8e100285e5bd9088e9981608dfd14f6ff27 Branches: master Link: http://

Re: [PHP-DEV] PHP7 releases vs Windows Sources?

On Tue, 2015-06-16 at 02:02 +0200, Christoph Becker wrote: > Johannes Schlüter wrote: > > > On Tue, 2015-06-16 at 00:02 +0200, Christoph Becker wrote: > > > >> Why should these downloads be disabled? They contain exactly what could > >> be checked out from the respective tag. > > > > It is not

Re: [PHP-DEV] Migrating PHP classes to built in namespace

I've missed out on most of this discussion via email, bit I've watching the threads anyway. It seems to me the main debate is about backwards compatibility, and where the classes belong. My reason for starting this thread was not really out of necessity, but merely to argue semantics. So if it is

Re: [PHP-DEV] Packed array is not fast?

First of all, I tried it against a PHP5 codebase, not PHP7. I simply patched it about return type (casted it to our ulong , taking care of 32/64 platforms), then I very simply #define zend(_inline)_hash_func to mumurhash2. Then I ran a callgrind on an extension of mine (closed source), that heavi

Re: [PHP-DEV] Packed array is not fast?

Hi Julien, Could you be more specific. From the first look MurmurHash2is more expensive, but may be it reduces number of collisions. what implementation(s) did you use (src or patch)? how did you measure the speed? did you try to embed it into PHP? Thanks. Dmitry. On Tue, Jun 16, 2015 at 10:24 A

Re: [PHP-DEV] PHP7 releases vs Windows Sources?

On Tue, Jun 16, 2015 at 12:42 AM, Stanislav Malyshev wrote: > Hi! > > > Then this fix doesn't make any sense -- you are saying if I download > > the .tar.gz and .zip and extract those two, I will have precisely the > > same sources? > > Should be the same sources. We shouldn't distribute anything

Re: [PHP-DEV] Packed array is not fast?

Just to throw back another discussion based on this topic, has anyone considered changing the hash algorithm about string keys (real hashes) ? I gave MurmurHash2 a try, it was twice faster than DJB33 in my benchs (64bits platform and 64bits MurmurHash2 variant). 128bits MurmurHash3 however was a l