Re: [PHP-DEV] GMP memory allocator, various issues

[Remi Collet]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 11/10/2014 08:17, Remi Collet a écrit :
> Le 11/10/2014 07:37, Remi Collet a écrit :
> 
>> I will try to create a patch, for test, as we really need to fix 
>> this problem, especially it gmp going to go into core (bigint 
>> patch).
> 
> See 
> https://bugs.php.net/patch-display.php?bug=63595&patch=gmp-memory.patch&revision=1413008196

Sorry,
> 
use
https://bugs.php.net/patch-display.php?bug_id=63595&patch=gmp-memory.patch&revision=latest
  (against 5.6.1)

Test suite result is unchanged
(I have tests/gmp_remroot.phpt failed [1] with or without the patch)

Execution time of the test suite seems not significantly changed.


Remi.


P.S. $ cat tests/gmp_remroot.diff
036+ string(3) "-36"
036- string(2) "36"
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlQ412cACgkQYUppBSnxahhhBgCfV0Vw7LiwizkuwFDBVivc0meX
hVEAoNL4dVP4ZjDs56qpOPIlehlbJ7ZL
=ZIQy
-END PGP SIGNATURE-

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Big Integer Support

[Lester Caine]

On 11/10/14 01:18, Andrea Faulds wrote:
>>> >> What you want is 64-bit data handling. This is arbitrary-bit data 
>>> >> handling. It’s not a “wrong approach”.
>> > 
>> > So BIGINT on 32 bit platforms will be different to BIGINT on 64 bit
>> > platforms? BIGINT is a fix length number not a variable one …
> “Bigints” typically refer to arbitrary-size integers, that is, their size is 
> bounded only by the amount of RAM available.
> 
> I don’t know what you think a “bigint” is, but it’s different to everyone 
> else.

PLEASE rename the page name for this and stop using BIGINT for it ...

BIGINT is the SQL99-compliant 64-bit signed integer type

http://www.firebirdsql.org/refdocs/langrefupd25-bigint.html
http://www.postgresql.org/docs/9.1/static/datatype-numeric.html
http://dev.mysql.com/doc/refman/5.5/en/integer-types.html

BIGINT is very much an 8 byte data value which we have been struggling
with on PHP for some time. Now that it's available in 64bit builds, we
need a simple transparent way to maintain that in 32bit builds ...

If you are proposing BigInteger that is something else
http://docs.oracle.com/javase/7/docs/api/java/math/BigInteger.html and
GMP already provides that. Miking it up with the BIGINT standard which
is something we DO need is the problem here ...

-- 
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Big Integer Support

[Pierre Joye]

On Oct 11, 2014 4:14 PM, "Lester Caine"  wrote:
>
> On 11/10/14 01:18, Andrea Faulds wrote:
> >>> >> What you want is 64-bit data handling. This is arbitrary-bit data
handling. It’s not a “wrong approach”.
> >> >
> >> > So BIGINT on 32 bit platforms will be different to BIGINT on 64 bit
> >> > platforms? BIGINT is a fix length number not a variable one …
> > “Bigints” typically refer to arbitrary-size integers, that is, their
size is bounded only by the amount of RAM available.
> >
> > I don’t know what you think a “bigint” is, but it’s different to
everyone else.
>
> PLEASE rename the page name for this and stop using BIGINT for it ...
>
> BIGINT is the SQL99-compliant 64-bit signed integer type
>
> http://www.firebirdsql.org/refdocs/langrefupd25-bigint.html
> http://www.postgresql.org/docs/9.1/static/datatype-numeric.html
> http://dev.mysql.com/doc/refman/5.5/en/integer-types.html
>
> BIGINT is very much an 8 byte data value which we have been struggling
> with on PHP for some time. Now that it's available in 64bit builds, we
> need a simple transparent way to maintain that in 32bit builds ...
>
> If you are proposing BigInteger that is something else
> http://docs.oracle.com/javase/7/docs/api/java/math/BigInteger.html and
> GMP already provides that. Miking it up with the BIGINT standard which
> is something we DO need is the problem here ...

No.

The problem is on the other end of the wire. Big integer concept, in a
programming language context, or libraries (openssl, Crypto++, etc), is
pretty clear.

Can we now move to discussions about the implementations and open
questions? That will be much more useful.

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

[Pierre Joye]

On Oct 11, 2014 3:34 AM, "Andrea Faulds"  wrote:
>

> I would vote against any such proposal, and I hope others on the list
would join me in doing so.

I fully agree with you here.

Re: [PHP-DEV] [RFC] Big Integer Support

[Lester Caine]

On 11/10/14 14:36, Pierre Joye wrote:
> 
> On Oct 11, 2014 4:14 PM, "Lester Caine"  > wrote:
>>
>> On 11/10/14 01:18, Andrea Faulds wrote:
>> >>> >> What you want is 64-bit data handling. This is arbitrary-bit
> data handling. It’s not a “wrong approach”.
>> >> >
>> >> > So BIGINT on 32 bit platforms will be different to BIGINT on 64 bit
>> >> > platforms? BIGINT is a fix length number not a variable one …
>> > “Bigints” typically refer to arbitrary-size integers, that is, their
> size is bounded only by the amount of RAM available.
>> >
>> > I don’t know what you think a “bigint” is, but it’s different to
> everyone else.
>>
>> PLEASE rename the page name for this and stop using BIGINT for it ...
>>
>> BIGINT is the SQL99-compliant 64-bit signed integer type
>>
>> http://www.firebirdsql.org/refdocs/langrefupd25-bigint.html
>> http://www.postgresql.org/docs/9.1/static/datatype-numeric.html
>> http://dev.mysql.com/doc/refman/5.5/en/integer-types.html
>>
>> BIGINT is very much an 8 byte data value which we have been struggling
>> with on PHP for some time. Now that it's available in 64bit builds, we
>> need a simple transparent way to maintain that in 32bit builds ...
>>
>> If you are proposing BigInteger that is something else
>> http://docs.oracle.com/javase/7/docs/api/java/math/BigInteger.html and
>> GMP already provides that. Miking it up with the BIGINT standard which
>> is something we DO need is the problem here ...
> 
> No.
> 
> The problem is on the other end of the wire. Big integer concept, in a
> programming language context, or libraries (openssl, Crypto++, etc), is
> pretty clear.
> 
> Can we now move to discussions about the implementations and open
> questions? That will be much more useful.

BIGINT is a cleanly defined concept and something we have had to cope
with for some time since PHP does not support 64 bit integers cleanly.
Now that 64 bit builds support a clean 64 bit integer, the problem
arises that 32 bit builds will handle this in the old way.

I'll be quite frank,, and the idea of BigInteger was not something I was
even aware of but it does NOT use 'bigint' as a shorthand for it, so
mixing the two concepts up does not make any sense!

What needs tidying up here is the confusion being created for those of
us who use 'BIGINT' day in day out. GMP provides larger range integer
values, while the proposed rfc is ONLY describing handling 64 bit wrap
around ... which is what is needed to tidy up bigint handling on 32bit
platforms. There are two conflicting requirements which this rfc is
mixing up. Creating an unlimited integer size via GMP should correctly
fix all of the knock on effects such as shift on the whole integer
rather than just 64bits of it. While on the other hand, we need a clean
bigint alternative for 32bit platforms to mirror that on 64bit builds
... which does not involve GMP

-- 
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Big Integer Support

[Johannes Schlüter]

On Sat, 2014-10-11 at 17:05 +0100, Lester Caine wrote:
> BIGINT is a cleanly defined concept and something we have had to cope
> with for some time since PHP does not support 64 bit integers cleanly.
> Now that 64 bit builds support a clean 64 bit integer, the problem
> arises that 32 bit builds will handle this in the old way.

Arbitrary-precision arithmetic
From Wikipedia, the free encyclopedia
  (Redirected from Bigint)
http://en.wikipedia.org/wiki/Bigint

In computer science, arbitrary-precision arithmetic, also called
bignum arithmetic, multiple precision arithmetic, or sometimes
infinite-precision arithmetic, indicates that calculations are
performed on numbers whose digits of precision are limited only
by the available memory of the host system. This contrasts with
the faster fixed-precision arithmetic found in most arithmetic
logic unit (ALU) hardware, which typically offers between 8 and
64 bits of precision
[...]

But that's bikesheding, if we like we can call it also
yellow-blue-striped birds with red dots. Please discuss the contents not
the painting. Thanks.

johannes



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Big Integer Support

[Lester Caine]

On 11/10/14 19:22, Johannes Schlüter wrote:
> But that's bikesheding, if we like we can call it also
> yellow-blue-striped birds with red dots. Please discuss the contents not
> the painting. Thanks.

I AM discussing the content ... it will not fix the problem that was
ORIGINALLY being discussed it just changes to yet another abstract
concept which can not be used as a 'bigint' index on arrays in 32bit
builds of PHP ...

It may be that we now need two rfc's one for BigInteger and one to fix
the problem of BIGINT ...

-- 
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
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC] Remove deprecated functionality in PHP 7

[Nikita Popov]

Hi internals!

We currently have a number of deprecated features, which we likely want to
remove in PHP 7. I've created a tracking RFC listing deprecated
functionality (if I missed something, please tell):

https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7

I expect many of these are no-brainers (like assigning new by-reference),
but other items like removal of ext/mysql may need additional consideration.

Unless there are items that are particularly contested, I'd like to handle
the bulk of these in a single vote and only have separate votes for
ext/ereg and ext/mysql, as these are arguably more intrusive.

Thanks,
Nikita

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

[Rowan Collins]

On 11/10/2014 04:10, Marco Pivetta wrote:


That would actually be worse, as it wouldn't be possible to pass them to
methods with a `callable` hint or similars such as `array_map`.


That sounds like a good counter to your own argument that there is no 
use-case for these functions. Indeed, there are plenty of use cases for 
call_user_func() and call_user_func_array() which have nothing 
whatsoever to do with variadics, so are as valid as they ever were.


func_get_args() and func_num_args(), OTOH, existed solely to support 
variadics, and anything taking advantage of them being functions rather 
than a language structure would have to be quite exotic and arcane, so 
in principle they could, eventually, be removed, but I agree with others 
that it's far too soon to remove a feature which has been around since 
4.0 just becuase 5.6 includes a better alternative.



In general, I understand why there's a lot of fuss about BC compat here,
but I don't see why providing them as separate file or using something like
a "global include" is a problem. Is/would something like that (be) possible
via ini setting?


If they're included in the core distribution, then why make them 
optional at all? If it's just a question of how the functions behave, 
then surely an included (and C-level) implementation should be sought 
which has the better behaviour?


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Deprecation of func_get_args(), call_user_func_array() and related API

[Andrea Faulds]

On 11 Oct 2014, at 23:42, Rowan Collins  wrote:

> func_get_args() and func_num_args(), OTOH, existed solely to support 
> variadics, and anything taking advantage of them being functions rather than 
> a language structure would have to be quite exotic and arcane, so in 
> principle they could, eventually, be removed, but I agree with others that 
> it's far too soon to remove a feature which has been around since 4.0 just 
> becuase 5.6 includes a better alternative.

They have some (admittedly limited) use beyond variadics. If you make a 
function and later make it redirect to another, you can preserve your typehints 
by using func_get_args() rather than using the … syntax.

> If they're included in the core distribution, then why make them optional at 
> all? If it's just a question of how the functions behave, then surely an 
> included (and C-level) implementation should be sought which has the better 
> behaviour?

This matches my own thoughts. There is nothing wrong with these functions. 
There are just some issues with their implementation. We do not need to get rid 
of the functions, that would be an absurd overreaction. We should just fix the 
implementations.
--
Andrea Faulds
http://ajf.me/





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7

[Kris Craig]

On Oct 11, 2014 1:52 PM, "Nikita Popov"  wrote:
>
> Hi internals!
>
> We currently have a number of deprecated features, which we likely want to
> remove in PHP 7. I've created a tracking RFC listing deprecated
> functionality (if I missed something, please tell):
>
> https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
>
> I expect many of these are no-brainers (like assigning new by-reference),
> but other items like removal of ext/mysql may need additional
consideration.
>
> Unless there are items that are particularly contested, I'd like to handle
> the bulk of these in a single vote and only have separate votes for
> ext/ereg and ext/mysql, as these are arguably more intrusive.
>
> Thanks,
> Nikita

+1 on all of that.

As far as ext/mysql is concerned, I would eagerly vote in favor of removing
it.  It performs poorly, is procedural, less secure, doesn't support
prepared statements, etc.

It's always annoyed me how sites like w3schools still teach people to use
ext/mysql.  It's been deprecated for quite awhile now and I think it's time
to pull the plug on it.

--Kris

Re: [PHP-DEV] [RFC] Remove deprecated functionality in PHP 7

[Rasmus Lerdorf]

> On Oct 11, 2014, at 16:47, Kris Craig  wrote:
> 
>> On Oct 11, 2014 1:52 PM, "Nikita Popov"  wrote:
>> 
>> Hi internals!
>> 
>> We currently have a number of deprecated features, which we likely want to
>> remove in PHP 7. I've created a tracking RFC listing deprecated
>> functionality (if I missed something, please tell):
>> 
>>https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
>> 
>> I expect many of these are no-brainers (like assigning new by-reference),
>> but other items like removal of ext/mysql may need additional
> consideration.
>> 
>> Unless there are items that are particularly contested, I'd like to handle
>> the bulk of these in a single vote and only have separate votes for
>> ext/ereg and ext/mysql, as these are arguably more intrusive.
>> 
>> Thanks,
>> Nikita
> 
> +1 on all of that.
> 
> As far as ext/mysql is concerned, I would eagerly vote in favor of removing
> it.  It performs poorly, is procedural, less secure, doesn't support
> prepared statements, etc.
> 
> It's always annoyed me how sites like w3schools still teach people to use
> ext/mysql.  It's been deprecated for quite awhile now and I think it's time
> to pull the plug on it.

Keep in mind though that it would be mostly symbolic. The majority of users get 
their PHP and extensions from distros. And distros have been separating out 
core-bundled extensions for a decade now. Users have absolutely no idea whether 
their php-mysql package comes from core or from pecl, nor do they care. So, 
unbundling it on our side will have close to zero impact on its use. In fact, 
in a weird way it might actually help make people continue to use it because if 
we unbundle it and stick it in pecl we would obviously not have it spew out 
'deprecated' notices like we do as of 5.5. I mean, we still could, of course, 
but it would be weird having a non-core pecl extension declare itself 
deprecated. 

I am not against unbundling it, I just don't think it will achieve what you 
hope it will.

-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Big Integer Support

[Rowan Collins]

On 11/10/2014 20:39, Lester Caine wrote:

it will not fix the problem that was
ORIGINALLY being discussed


Your assuming that Andrea's RFC is a response to that particular 
discussion, rather than simply assuming that it's a valid discussion in 
its own right.


It's perfectly possible to have two discussions at once, even about 
slightly-related things.


--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Big Integer Support

[Rowan Collins]

On 11/10/2014 10:13, Lester Caine wrote:

BIGINT is the SQL99-compliant 64-bit signed integer type


It's a matter of context. In C, and therefore in related discussions 
(which includes the internals of PHP), integers are referred to as 
"short" (for 16-bit), "long" (for 32-bit) and "long  long" (for 64-bit), 
but never as "big". SQL is unusual in calling a 32-bit integer "BigInt" 
rather than some variant of "long" or "32", and since we're not 
discussing databases here, it's of only marginal relevance.


I can see why, having spent more time in SQL than C, you might jump to 
the wrong meaning of "BigInt", and it might even be worth considering 
this potential confusion when writing the end-user documentation for 
this new feature, should it be implemented.


But, as others have said, that's really not an issue which should 
dominate the discussion at this stage.


--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 7 and readline

[Remi Collet]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

For a lot of time, PHP can use readline (default) or libedit (prefered
choice in all downstream) distribution.

Readline is GPLv3 so is not compatible with PHP License

I think is time to drop  readline support (or, at least switch libedit
as the default).


Remi.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlQ6G/4ACgkQYUppBSnxahjPuQCdGx6jVwCeClmCSxGpZXnIKtzx
4mEAn0Gtwk4STklQytdAsZvd9W1JB5kR
=Clvf
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP 7 and json

[Remi Collet]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Bug 63520 is still not fixed.


We have 2 alternative extensions

- - jsonc the older one, probably not perfect, but used in a lot of
downstream distributions

- - jsond the recent one


I think it is time to switch ext/json to another implementation and so
make PHP really "free" again.


Remi.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlQ6HLkACgkQYUppBSnxahg3tACgi3DVjPpK3bN9fbiPLsV2QZfj
asAAmQF/3cvlnhut/nOQIZVBd9kbQiJq
=au/C
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php