Re: [PHP-DEV] Proposal: Raise severity of undefined constants

[Yasuo Ohgaki]

Hi Rowan,

On Wed, Jan 28, 2015 at 7:21 AM, Rowan Collins 
wrote:

> What do people think?


I would like to vote +1 for this indeed.
My concern is that there are too many users ignore E_NOTICE. Use of
undefined
constant is fatal error IMHO, though. I will not vote and let people decide.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

RE: [PHP-DEV] Proposal: Raise severity of undefined constants

[Ferenc Kovacs]

2015.01.28. 6:04 ezt írta ("François Laupretre" ):
>
> > De : Rowan Collins [mailto:rowan.coll...@gmail.com]
> > I would like to propose that the error given for an undefined constant
> > should be raised from E_NOTICE, probably to E_RECOVERABLE_ERROR, in
> > PHP 7.
>
> +1
>

I don't like that.
Depending if we want to keep the behavior on the long term I would either
go with E_WARNING or E_DEPRECATED
Turning it into E_RECOVERABLE_ERROR would be for most users just as bad as
removing it while we still have to support the behavior so no real gain for
us.

Re: [PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

[Yasuo Ohgaki]

Hi Stas,

On Wed, Jan 28, 2015 at 4:48 AM, Stanislav Malyshev 
wrote:

> >>> Cons
> >>>  - Existing code modifications. (It's E_DEPRECATED. User may ignore.)
> >>>  - (Please point it out more disadvantages)
>
> I think removing or disrupting functions without a very good reason
> (such as, functionality going away or this function is abused or is
> broken in many use cases) is wrong. These functions don't seem broken,
> they just do something that you can do in another way. I don't think it
> is necessary to deprecated them.


I was about to add more of these functions for consistency indeed. e.g.
session_set_serialize_handler()
I changed my mind after discussion with Andrey. He insisted ini_set/get()
provides more consistency
and user friendliness. And I agreed with him.

There may be people like me and PHP may not need more simple ini_set/get()
copy functions.
What do you think about CODING_STANDARD part?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

[Yasuo Ohgaki]

Hi Xinchen,

On Wed, Jan 28, 2015 at 3:15 PM, Xinchen Hui  wrote:

> actually, this should already be in access.log(the last 500 error
> one).. I don't see why you need it in error log
>

PHP log  would be more useful with user ID/name to identify
who was trying to tamper with system, for example.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

[Thomas Bley]

>>   Request-Uri: /custom/foobar
>>   Request-Params: {"action":"edit"}
> actually, this should already be in access.log(the last 500 error
> one).. I don't see why you need it in error log

Sorry, my example is not precise enough. Normally, $_POST, 
$_SESSION['username'] and php://input are not part of access.log. So having 
ajax requests with all kinds of inputs makes things more difficult.
Parsing complete access logs can be quite slow and logging php://input for 
every request might not be possible in most cases.

Regards
Thomas


Xinchen Hui wrote on 28.01.2015 07:15:

> On Wed, Jan 28, 2015 at 2:11 PM, Thomas Bley  wrote:
>> There are some workarounds with register_shutdown_function to extend E_ERROR
>> messages, but I think that's quite dirty in a system with many parallel
>> requests.
>> Here is an example:
>>
>> > ini_set('error_reporting', E_ALL);
>> ini_set('display_errors', 0);
>> ini_set('log_errors', 1);
>> ini_set('error_log', 'php_error.log');
>> ini_set('date.timezone', 'Europe/Berlin');
>> ini_set('memory_limit', '16M');
>>
>> $_SERVER['HTTP_HOST'] = 'mywebsite.com';
>> $_SERVER['REQUEST_URI'] = '/custom/foobar';
>> $_REQUEST = array('action' => 'edit');
>>
>> function check_for_fatal() {
>>   $error = error_get_last();
>>   if ($error['type'] == E_ERROR) {
>> $errstr = '';
>> if (!empty($_SERVER['REQUEST_URI'])) {
>>   $errstr .= '  Request-Uri: '.$_SERVER['REQUEST_URI'].PHP_EOL;
>> }
>> $errstr .= '  Request-Params: '.json_encode($_REQUEST);
>> file_put_contents('php_error.log', $errstr. PHP_EOL, FILE_APPEND);
>>   }
>> }
>>
>> register_shutdown_function('check_for_fatal');
>>
>> $str = str_repeat('##', 2*1024*1024);
>>
>> gives:
>>
>> [28-Jan-2015 07:00:53 Europe/Berlin] PHP Fatal error:  Allowed memory size of
>> 16777216 bytes exhausted (tried to allocate 20971521 bytes) in test.php on
>> line 27
>>   Request-Uri: /custom/foobar
>>   Request-Params: {"action":"edit"}
> actually, this should already be in access.log(the last 500 error
> one).. I don't see why you need it in error log
> 
> thanks
>>
>>
>> Regards
>> Thomas
>>
>>
>>
>> Xinchen Hui wrote on 27.01.2015 13:26:
>>
>>> Hey:
>>>
>>> On Tue, Jan 27, 2015 at 11:08 AM, Yasuo Ohgaki  wrote:
 Hi Thomas,

 On Tue, Jan 27, 2015 at 11:45 AM, Thomas Bley  wrote:

> Here is the rfc:
>
> https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference
>
> Thanks to reeze for coding and putting it on the wiki.
>

 It looks good to me.

 Future Scope
 set_error_handler() callback might be able to handle E_ERROR to be able to
 append additional information to memory_limit exhaustions (or others).

 I really want to catch E_RROR by user defined error handler. The only
 reason why this was disabled is abuse of error handler. We may document
 abuse of error handler with E_ERROR may result in undefined behavior
 including memory leak/crash and allow it.
>>> I feel it's kindof wrong direction.
>>>
>>> if you want custom logs, maybe you should use custom logger.
>>>
>>> thanks

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net
>>>
>>>
>>>
>>> --
>>> Xinchen Hui
>>> @Laruence
>>> http://www.laruence.com/

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

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

[Xinchen Hui]

On Wed, Jan 28, 2015 at 2:11 PM, Thomas Bley  wrote:
> There are some workarounds with register_shutdown_function to extend E_ERROR 
> messages, but I think that's quite dirty in a system with many parallel 
> requests.
> Here is an example:
>
>  ini_set('error_reporting', E_ALL);
> ini_set('display_errors', 0);
> ini_set('log_errors', 1);
> ini_set('error_log', 'php_error.log');
> ini_set('date.timezone', 'Europe/Berlin');
> ini_set('memory_limit', '16M');
>
> $_SERVER['HTTP_HOST'] = 'mywebsite.com';
> $_SERVER['REQUEST_URI'] = '/custom/foobar';
> $_REQUEST = array('action' => 'edit');
>
> function check_for_fatal() {
>   $error = error_get_last();
>   if ($error['type'] == E_ERROR) {
> $errstr = '';
> if (!empty($_SERVER['REQUEST_URI'])) {
>   $errstr .= '  Request-Uri: '.$_SERVER['REQUEST_URI'].PHP_EOL;
> }
> $errstr .= '  Request-Params: '.json_encode($_REQUEST);
> file_put_contents('php_error.log', $errstr. PHP_EOL, FILE_APPEND);
>   }
> }
>
> register_shutdown_function('check_for_fatal');
>
> $str = str_repeat('##', 2*1024*1024);
>
> gives:
>
> [28-Jan-2015 07:00:53 Europe/Berlin] PHP Fatal error:  Allowed memory size of 
> 16777216 bytes exhausted (tried to allocate 20971521 bytes) in test.php on 
> line 27
>   Request-Uri: /custom/foobar
>   Request-Params: {"action":"edit"}
actually, this should already be in access.log(the last 500 error
one).. I don't see why you need it in error log

thanks
>
>
> Regards
> Thomas
>
>
>
> Xinchen Hui wrote on 27.01.2015 13:26:
>
>> Hey:
>>
>> On Tue, Jan 27, 2015 at 11:08 AM, Yasuo Ohgaki  wrote:
>>> Hi Thomas,
>>>
>>> On Tue, Jan 27, 2015 at 11:45 AM, Thomas Bley  wrote:
>>>
 Here is the rfc:

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

 Thanks to reeze for coding and putting it on the wiki.

>>>
>>> It looks good to me.
>>>
>>> Future Scope
>>> set_error_handler() callback might be able to handle E_ERROR to be able to
>>> append additional information to memory_limit exhaustions (or others).
>>>
>>> I really want to catch E_RROR by user defined error handler. The only
>>> reason why this was disabled is abuse of error handler. We may document
>>> abuse of error handler with E_ERROR may result in undefined behavior
>>> including memory leak/crash and allow it.
>> I feel it's kindof wrong direction.
>>
>> if you want custom logs, maybe you should use custom logger.
>>
>> thanks
>>>
>>> Regards,
>>>
>>> --
>>> Yasuo Ohgaki
>>> yohg...@ohgaki.net
>>
>>
>>
>> --
>> Xinchen Hui
>> @Laruence
>> http://www.laruence.com/
>>
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

[Thomas Bley]

There are some workarounds with register_shutdown_function to extend E_ERROR 
messages, but I think that's quite dirty in a system with many parallel 
requests.
Here is an example:

 'edit');

function check_for_fatal() {
  $error = error_get_last();
  if ($error['type'] == E_ERROR) {
$errstr = '';
if (!empty($_SERVER['REQUEST_URI'])) {
  $errstr .= '  Request-Uri: '.$_SERVER['REQUEST_URI'].PHP_EOL;
}
$errstr .= '  Request-Params: '.json_encode($_REQUEST);
file_put_contents('php_error.log', $errstr. PHP_EOL, FILE_APPEND);
  }
}

register_shutdown_function('check_for_fatal');

$str = str_repeat('##', 2*1024*1024);

gives:

[28-Jan-2015 07:00:53 Europe/Berlin] PHP Fatal error:  Allowed memory size of 
16777216 bytes exhausted (tried to allocate 20971521 bytes) in test.php on line 
27
  Request-Uri: /custom/foobar
  Request-Params: {"action":"edit"}


Regards
Thomas



Xinchen Hui wrote on 27.01.2015 13:26:

> Hey:
> 
> On Tue, Jan 27, 2015 at 11:08 AM, Yasuo Ohgaki  wrote:
>> Hi Thomas,
>>
>> On Tue, Jan 27, 2015 at 11:45 AM, Thomas Bley  wrote:
>>
>>> Here is the rfc:
>>>
>>> https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference
>>>
>>> Thanks to reeze for coding and putting it on the wiki.
>>>
>>
>> It looks good to me.
>>
>> Future Scope
>> set_error_handler() callback might be able to handle E_ERROR to be able to
>> append additional information to memory_limit exhaustions (or others).
>>
>> I really want to catch E_RROR by user defined error handler. The only
>> reason why this was disabled is abuse of error handler. We may document
>> abuse of error handler with E_ERROR may result in undefined behavior
>> including memory leak/crash and allow it.
> I feel it's kindof wrong direction.
> 
> if you want custom logs, maybe you should use custom logger.
> 
> thanks
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
> 
> 
> 
> -- 
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
> 


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

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

[Thomas Bley]

Hi,

the idea behind the rfc is not to change error messages, it's only to append 
useful information to them.
Changing lines/filenames is surely something controversial and might be only 
useful when compiling configuration files or templates to php code. Therefore 
we have 3 options in the voting section.

> Maybe better access to logging system for custom logging would be more
> efficient instead?

The logging system can be accessed with 1 line of code (trigger_error, throw 
new exception, etc), so from userland perspective I don't see any deficits here.
In case someone needs multiple error handlers, it might be necessary to 
implement sth. like spl_set_error_handler (similar to spl_autoload_register), 
but that's not in the scope of this rfc.

Regards
Thomas


Stanislav Malyshev wrote on 27.01.2015 20:43:

> Hi!
> 
>> I feel it's kindof wrong direction.
>> 
>> if you want custom logs, maybe you should use custom logger.
> 
> Same here, API basing on modifying something that is supposed to be
> internal engine things feels wrong, even if it does work. Changing error
> message is borderline, changing things like lines/filenames just feels
> wrong.
> 
> Maybe better access to logging system for custom logging would be more
> efficient instead?
> 
> -- 
> Stas Malyshev
> smalys...@gmail.com
> 
> -- 
> 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] Proposal: Raise severity of undefined constants

[François Laupretre]

> De : Rowan Collins [mailto:rowan.coll...@gmail.com]
> I would like to propose that the error given for an undefined constant
> should be raised from E_NOTICE, probably to E_RECOVERABLE_ERROR, in
> PHP 7.

+1


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

Re: [PHP-DEV] Improvements to for-each implementation

[Dmitry Stogov]

I've created a branch and pull request for easier collaboration and
tracking.

https://github.com/php/php-src/pull/1034

It's the same diff I published yesterday. Nothing changed or added yet.

Thanks. Dmitry.

On Wed, Jan 28, 2015 at 1:36 AM, Nikita Popov  wrote:

> On Tue, Jan 27, 2015 at 5:55 PM, Dmitry Stogov  wrote:
>
>> Hi,
>>
>> I'm working on a PoC, implementing the proposed behavior -
>> https://gist.github.com/dstogov/a311e8b0b2cabee4dab4
>>
>> Only few PHPT tests had to be changed to confirm new behavior and
>> actually they started to behave as HHVM.
>> 2 tests are still unfixed XFAILed. Foreach by reference is still need to
>> be improved to support different array modifications.
>>
>> The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
>> destruction of 200 arrays on each request)
>>
>> Thanks. Dmitry.
>>
>
> I quickly looked over the patch, some notes:
>
> * 171: Can directly use GET_OP1_ZVAL_PTR_DEREF
> * For iterator failures (exception) you use FREE_OP1_IF_VAR(). Is this
> enough? If the object is a TMP_VAR, don't we have to free it as well?
> * For objects it will still be possible to modify the hashtable during
> iteration even in the _R case, correct? I assume we just don't care about
> this edge case.
> * 315: In RESET_RW you now always create a reference for VAR|CV operands.
> However for the get_iterator case we don't need this, right?
> * 328: In the non VAR|CV case SEPARTE_ARRAY is not used. As we're going to
> change the IAP, this is probably necessary in this case as well.
> * For RW iterator failures FREE_OP1_VAR_PTR() is used. This probably
> leaks in the TMP case. (Same for the "invalid argument" case.)
>
> What concerns me a bit is the new FETCH_RW implementation, because it no
> longer checks the internal pointer against the external one. This
> effectively means that foreach by reference behavior will be influenced a
> lot by details of the hashtable implementation. An example:
>
> $array = [0, 1, 2, 3, 4, 5, 6, 7];
> unset($array[0], $array[1], $array[2], $array[3]);
> foreach ($array as &$ref) {
> var_dump($ref);
> //$array[42] = 42;
> }
>
> Without the commented line this will just print the numbers 4, 5, 6, 7. If
> you uncomment the line it will only print 4. (Because the append caused a
> rehash and arData was compacted, so the position now points past all
> elements). The previous output would have been 4, 5, 6, 7, 42, which is
> closer to what you would expect. Maybe better to keep the pos !=
> nInternalPointer code?
>
> Thanks,
> Nikita
>

Re: [PHP-DEV] Improvements to for-each implementation

[Xinchen Hui]

Hey:

On Wed, Jan 28, 2015 at 11:47 AM, Dmitry Stogov  wrote:
> Hi,
>
> I have this in mind. May be It's even possible to remove JMP.
>
> FE_RESET op1= op2= result=
> OP_DATA op1= result=
> 1: statements...
> FE_FETCH op1= op2= result=
> OP_DATA result=
> 2:  FREE 
>
> Anyway, it's not a big problem implementing this, but eliminating of array
> duplication is more important.
> We still have to solve more serious problems first.
>
of course, I just was curious maybe this could give us more
improvement added to that ~1%.

thanks
> Thanks. Dmitry.
>
> On Wed, Jan 28, 2015 at 6:22 AM, Xinchen Hui  wrote:
>>
>> Hey:
>>
>> On Wed, Jan 28, 2015 at 12:55 AM, Dmitry Stogov  wrote:
>> > Hi,
>> >
>> > I'm working on a PoC, implementing the proposed behavior -
>> > https://gist.github.com/dstogov/a311e8b0b2cabee4dab4
>> >
>> > Only few PHPT tests had to be changed to confirm new behavior and
>> > actually
>> > they started to behave as HHVM.
>> > 2 tests are still unfixed XFAILed. Foreach by reference is still need to
>> > be
>> > improved to support different array modifications.
>> >
>> > The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
>> > destruction of 200 arrays on each request)
>>
>> I just have got an idea:
>>
>> Droping use of ZEND_OP_DATA make it possible to generate better
>> foreach loop opcodes
>>
>> previously FE_RESET and FE_FETCH  share one same OP_DATA based on offset.
>>
>> 0 FE_RESET
>> 1 FE_FETCH fail-> 5
>> 2 OP_DATA
>> 3  . statements
>> 4 JMP 1
>> 5
>>
>> without depending on that OP_DATA, we can change this to
>>
>> 0 FE_RESET
>> 1 JMP 3
>> 2 statements
>> 3 FE_FETCH success->2
>> 4 
>>
>> that will reduce on JMP in every foreach loop
>>
>> could you please also try this?
>>
>> thanks
>>
>> >
>> > Thanks. Dmitry.
>> >
>> >
>> >
>> > On Thu, Jan 22, 2015 at 1:38 PM, Benjamin Coutu 
>> > wrote:
>> >>
>> >> Hi Nikita,
>> >>
>> >> I would suggest using the proposal for the by-value case and sticking
>> >> with
>> >> the current behavior for the by-reference case as you suggested.
>> >> Granted, we
>> >> then cannot remove the internal pointer all together, but we would just
>> >> use
>> >> it for the less common by-reference case as well as for the legacy
>> >> reset/next functions, of course. This would still improve most for-each
>> >> traversals. At least we then wouldn't have to find a replacement
>> >> solution
>> >> for rest/prev/next/end. Moreover we can then move the internal position
>> >> pointer out of the hashtable structure into zend_array because it is
>> >> only
>> >> used for userland arrays, not other hash tables (such as object
>> >> properties
>> >> or internal structures that build upon the hashtable struct).
>> >>
>> >> Thanks,
>> >>
>> >> Ben
>> >>
>> >> == Original ==
>> >> From: Nikita Popov 
>> >> To: Benjamin Coutu 
>> >> Date: Thu, 22 Jan 2015 10:53:19 +0100
>> >> Subject: Re: [PHP-DEV] Improvements to for-each implementation
>> >>
>> >> Doing this was the idea I had in mind as well, i.e. change the
>> >> semantics
>> >> of
>> >> foreach to say that it will always work on a copy for by-value
>> >> iteration
>> >> (which ironically avoids having to actually copy it). Note that this
>> >> will
>> >> differ from the current behavior in a number of ways. In particular it
>> >> means that changes to arrays that were references prior to iteration
>> >> will
>> >> not influence the iteration.
>> >>
>> >> The real question is what we should do in the by-reference case. Given
>> >> that
>> >> we need to acquire references to elements of the original array we
>> >> can't
>> >> reasonably work with copy-semantics (at least I don't see how). So
>> >> would
>> >> we
>> >> just stick with the previous behavior (using the hash position hack)
>> >> for
>> >> that?
>> >>
>> >> Nikita
>> >>
>> >>
>> >> --
>> >> PHP Internals - PHP Runtime Development Mailing List
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >>
>> >
>>
>>
>>
>> --
>> Xinchen Hui
>> @Laruence
>> http://www.laruence.com/
>
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Improvements to for-each implementation

[Dmitry Stogov]

Hi,

I have this in mind. May be It's even possible to remove JMP.

FE_RESET op1= op2= result=
OP_DATA op1= result=
1: statements...
FE_FETCH op1= op2= result=
OP_DATA result=
2:  FREE 

Anyway, it's not a big problem implementing this, but eliminating of array
duplication is more important.
We still have to solve more serious problems first.

Thanks. Dmitry.

On Wed, Jan 28, 2015 at 6:22 AM, Xinchen Hui  wrote:

> Hey:
>
> On Wed, Jan 28, 2015 at 12:55 AM, Dmitry Stogov  wrote:
> > Hi,
> >
> > I'm working on a PoC, implementing the proposed behavior -
> > https://gist.github.com/dstogov/a311e8b0b2cabee4dab4
> >
> > Only few PHPT tests had to be changed to confirm new behavior and
> actually
> > they started to behave as HHVM.
> > 2 tests are still unfixed XFAILed. Foreach by reference is still need to
> be
> > improved to support different array modifications.
> >
> > The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
> > destruction of 200 arrays on each request)
>
> I just have got an idea:
>
> Droping use of ZEND_OP_DATA make it possible to generate better
> foreach loop opcodes
>
> previously FE_RESET and FE_FETCH  share one same OP_DATA based on offset.
>
> 0 FE_RESET
> 1 FE_FETCH fail-> 5
> 2 OP_DATA
> 3  . statements
> 4 JMP 1
> 5
>
> without depending on that OP_DATA, we can change this to
>
> 0 FE_RESET
> 1 JMP 3
> 2 statements
> 3 FE_FETCH success->2
> 4 
>
> that will reduce on JMP in every foreach loop
>
> could you please also try this?
>
> thanks
>
> >
> > Thanks. Dmitry.
> >
> >
> >
> > On Thu, Jan 22, 2015 at 1:38 PM, Benjamin Coutu 
> wrote:
> >>
> >> Hi Nikita,
> >>
> >> I would suggest using the proposal for the by-value case and sticking
> with
> >> the current behavior for the by-reference case as you suggested.
> Granted, we
> >> then cannot remove the internal pointer all together, but we would just
> use
> >> it for the less common by-reference case as well as for the legacy
> >> reset/next functions, of course. This would still improve most for-each
> >> traversals. At least we then wouldn't have to find a replacement
> solution
> >> for rest/prev/next/end. Moreover we can then move the internal position
> >> pointer out of the hashtable structure into zend_array because it is
> only
> >> used for userland arrays, not other hash tables (such as object
> properties
> >> or internal structures that build upon the hashtable struct).
> >>
> >> Thanks,
> >>
> >> Ben
> >>
> >> == Original ==
> >> From: Nikita Popov 
> >> To: Benjamin Coutu 
> >> Date: Thu, 22 Jan 2015 10:53:19 +0100
> >> Subject: Re: [PHP-DEV] Improvements to for-each implementation
> >>
> >> Doing this was the idea I had in mind as well, i.e. change the semantics
> >> of
> >> foreach to say that it will always work on a copy for by-value iteration
> >> (which ironically avoids having to actually copy it). Note that this
> will
> >> differ from the current behavior in a number of ways. In particular it
> >> means that changes to arrays that were references prior to iteration
> will
> >> not influence the iteration.
> >>
> >> The real question is what we should do in the by-reference case. Given
> >> that
> >> we need to acquire references to elements of the original array we can't
> >> reasonably work with copy-semantics (at least I don't see how). So would
> >> we
> >> just stick with the previous behavior (using the hash position hack) for
> >> that?
> >>
> >> Nikita
> >>
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/
>

[PHP-DEV] Re: imagick on PHP 7 was Stepping stones to a working php7 ...

[Jan Ehrhardt]

Dan Ackroyd in php.internals (Mon, 26 Jan 2015 17:58:40 +):
>On 26 January 2015 at 00:02, Lester Caine  wrote:
>> /imagick ... need to get a copy to work with
>
>Imagick is now working on 7; you will need to use the PHP 7 branch
>from https://github.com/mkoppanen/imagick/tree/phpseven

Did you compile that with the git head of php-src? I did and stumbled
into some problems.

ext/standard/php_smart_string_public.h is now almost empty. You should
include ext/standard/php_smart_string.h and change some functions:
https://github.com/Jan-E/imagick/commit/243c206cf5528255b406a76e1807dd64af209ced

Z_BVAL_P does not exist anymore. Possible fix:

-   convert_to_boolean(multiline);
-   query_multiline = Z_BVAL_P(multiline);
+   convert_to_double(multiline);
+   query_multiline = Z_DVAL_P(multiline);

See
https://github.com/Jan-E/imagick/commit/c0711521a926ba8fed7b61ae106c6d9039fc71f4

And besides that there were the usual fixes for VC11 and a few
deprecated functions. See all my commits at:
https://github.com/Jan-E/imagick/commits/phpseven

After these commits php_imagick.dll compiled with VC11 and (for Lester)
showed itself in phpinfo:
https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm

Complete build:
https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip

Jan

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

Re: [PHP-DEV] Improvements to for-each implementation

[Xinchen Hui]

Hey:

On Wed, Jan 28, 2015 at 11:22 AM, Xinchen Hui  wrote:
> Hey:
>
> On Wed, Jan 28, 2015 at 12:55 AM, Dmitry Stogov  wrote:
>> Hi,
>>
>> I'm working on a PoC, implementing the proposed behavior -
>> https://gist.github.com/dstogov/a311e8b0b2cabee4dab4
>>
>> Only few PHPT tests had to be changed to confirm new behavior and actually
>> they started to behave as HHVM.
>> 2 tests are still unfixed XFAILed. Foreach by reference is still need to be
>> improved to support different array modifications.
>>
>> The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
>> destruction of 200 arrays on each request)
>
> I just have got an idea:
>
> Droping use of ZEND_OP_DATA make it possible to generate better
> foreach loop opcodes
>
> previously FE_RESET and FE_FETCH  share one same OP_DATA based on offset.
>
> 0 FE_RESET
> 1 FE_FETCH fail-> 5
> 2 OP_DATA
> 3  . statements
> 4 JMP 1
> 5
>
> without depending on that OP_DATA, we can change this to
>
> 0 FE_RESET
> 1 JMP 3
> 2 statements
> 3 FE_FETCH success->2
> 4 
>
> that will reduce on JMP in every foreach loop
>
> could you please also try this?
I mean, dropping both ZEND_FE_RESET and FE_FETCH share one ZEND_OP_DATA.

the previously example should be:

> 0 FE_RESET
> 1 JMP 3
> 2 statements
> 3 FE_FETCH success->2
   4 ZEND_OP_DATA
> 5 

thanks
>
> thanks
>
>>
>> Thanks. Dmitry.
>>
>>
>>
>> On Thu, Jan 22, 2015 at 1:38 PM, Benjamin Coutu  wrote:
>>>
>>> Hi Nikita,
>>>
>>> I would suggest using the proposal for the by-value case and sticking with
>>> the current behavior for the by-reference case as you suggested. Granted, we
>>> then cannot remove the internal pointer all together, but we would just use
>>> it for the less common by-reference case as well as for the legacy
>>> reset/next functions, of course. This would still improve most for-each
>>> traversals. At least we then wouldn't have to find a replacement solution
>>> for rest/prev/next/end. Moreover we can then move the internal position
>>> pointer out of the hashtable structure into zend_array because it is only
>>> used for userland arrays, not other hash tables (such as object properties
>>> or internal structures that build upon the hashtable struct).
>>>
>>> Thanks,
>>>
>>> Ben
>>>
>>> == Original ==
>>> From: Nikita Popov 
>>> To: Benjamin Coutu 
>>> Date: Thu, 22 Jan 2015 10:53:19 +0100
>>> Subject: Re: [PHP-DEV] Improvements to for-each implementation
>>>
>>> Doing this was the idea I had in mind as well, i.e. change the semantics
>>> of
>>> foreach to say that it will always work on a copy for by-value iteration
>>> (which ironically avoids having to actually copy it). Note that this will
>>> differ from the current behavior in a number of ways. In particular it
>>> means that changes to arrays that were references prior to iteration will
>>> not influence the iteration.
>>>
>>> The real question is what we should do in the by-reference case. Given
>>> that
>>> we need to acquire references to elements of the original array we can't
>>> reasonably work with copy-semantics (at least I don't see how). So would
>>> we
>>> just stick with the previous behavior (using the hash position hack) for
>>> that?
>>>
>>> Nikita
>>>
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>
>
>
>
> --
> Xinchen Hui
> @Laruence
> http://www.laruence.com/



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Improvements to for-each implementation

[Xinchen Hui]

Hey:

On Wed, Jan 28, 2015 at 12:55 AM, Dmitry Stogov  wrote:
> Hi,
>
> I'm working on a PoC, implementing the proposed behavior -
> https://gist.github.com/dstogov/a311e8b0b2cabee4dab4
>
> Only few PHPT tests had to be changed to confirm new behavior and actually
> they started to behave as HHVM.
> 2 tests are still unfixed XFAILed. Foreach by reference is still need to be
> improved to support different array modifications.
>
> The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
> destruction of 200 arrays on each request)

I just have got an idea:

Droping use of ZEND_OP_DATA make it possible to generate better
foreach loop opcodes

previously FE_RESET and FE_FETCH  share one same OP_DATA based on offset.

0 FE_RESET
1 FE_FETCH fail-> 5
2 OP_DATA
3  . statements
4 JMP 1
5

without depending on that OP_DATA, we can change this to

0 FE_RESET
1 JMP 3
2 statements
3 FE_FETCH success->2
4 

that will reduce on JMP in every foreach loop

could you please also try this?

thanks

>
> Thanks. Dmitry.
>
>
>
> On Thu, Jan 22, 2015 at 1:38 PM, Benjamin Coutu  wrote:
>>
>> Hi Nikita,
>>
>> I would suggest using the proposal for the by-value case and sticking with
>> the current behavior for the by-reference case as you suggested. Granted, we
>> then cannot remove the internal pointer all together, but we would just use
>> it for the less common by-reference case as well as for the legacy
>> reset/next functions, of course. This would still improve most for-each
>> traversals. At least we then wouldn't have to find a replacement solution
>> for rest/prev/next/end. Moreover we can then move the internal position
>> pointer out of the hashtable structure into zend_array because it is only
>> used for userland arrays, not other hash tables (such as object properties
>> or internal structures that build upon the hashtable struct).
>>
>> Thanks,
>>
>> Ben
>>
>> == Original ==
>> From: Nikita Popov 
>> To: Benjamin Coutu 
>> Date: Thu, 22 Jan 2015 10:53:19 +0100
>> Subject: Re: [PHP-DEV] Improvements to for-each implementation
>>
>> Doing this was the idea I had in mind as well, i.e. change the semantics
>> of
>> foreach to say that it will always work on a copy for by-value iteration
>> (which ironically avoids having to actually copy it). Note that this will
>> differ from the current behavior in a number of ways. In particular it
>> means that changes to arrays that were references prior to iteration will
>> not influence the iteration.
>>
>> The real question is what we should do in the by-reference case. Given
>> that
>> we need to acquire references to elements of the original array we can't
>> reasonably work with copy-semantics (at least I don't see how). So would
>> we
>> just stick with the previous behavior (using the hash position hack) for
>> that?
>>
>> Nikita
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC][Vote] Return Types

[Dmitry Stogov]

No problem, I'll verify if (fix if necessary) and commit.

Thanks. Dmitry.
On Jan 28, 2015 5:37 AM, "Levi Morrison"  wrote:

> Dmitry,
>
> I updated the patch to latest master and (seem to have) fixed a memory
> issue with it. However when I pushed it back up Travis had a lot of failing
> return types tests. Could you (and anyone else willing) pull it and see if
> you are getting failing tests for release and debug builds?
>
> Cheers,
>
> Levi Morrison
>
>
> On Tue, Jan 27, 2015 at 1:13 PM, Dmitry Stogov  wrote:
>
>> Hi Levi,
>>
>> Do you like me to make final check and merge your pull request?
>> We need it :)
>>
>> Thanks. Dmitry.
>>
>> On Sat, Jan 24, 2015 at 8:01 AM, Levi Morrison  wrote:
>>
>>> On Fri, Jan 23, 2015 at 5:06 PM, Levi Morrison  wrote:
>>> > As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will
>>> > close in a few hours. I want to thank everyone who has voted so far,
>>> > and encourage anyone who has not yet voted to do so.
>>>
>>> I have close the voting. It has passed with a vote of 47 to 3.
>>>
>>> I will update the patch to the latest master and then ping Dmitry to
>>> do a final pass before merging it into master.
>>>
>>
>>
>

Re: [PHP-DEV] Improvements to for-each implementation

[Dmitry Stogov]

On Jan 28, 2015 2:36 AM, "Nikita Popov"  wrote:
>
> On Tue, Jan 27, 2015 at 5:55 PM, Dmitry Stogov  wrote:
>>
>> Hi,
>>
>> I'm working on a PoC, implementing the proposed behavior -
https://gist.github.com/dstogov/a311e8b0b2cabee4dab4
>>
>> Only few PHPT tests had to be changed to confirm new behavior and
actually they started to behave as HHVM.
>> 2 tests are still unfixed XFAILed. Foreach by reference is still need to
be improved to support different array modifications.
>>
>> The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
destruction of 200 arrays on each request)
>>
>> Thanks. Dmitry.
>
>
> I quickly looked over the patch, some notes:
>
> * 171: Can directly use GET_OP1_ZVAL_PTR_DEREF

Right.

> * For iterator failures (exception) you use FREE_OP1_IF_VAR(). Is this
enough? If the object is a TMP_VAR, don't we have to free it as well?

For IS_TMP_VAR I try to avoid refcounter incrementation/decrementation. So
the OP1 zval has to be freed in ZEND_FREE or in HANDLE_EXCEPTION. Hawever,
I'm not 100% sure. It need to be checked more careful.

> * For objects it will still be possible to modify the hashtable during
iteration even in the _R case, correct? I assume we just don't care about
this edge case.

I think you are right. I missed this and it may make us problems :(

> * 315: In RESET_RW you now always create a reference for VAR|CV operands.
However for the get_iterator case we don't need this, right?

Right. Good catch.

> * 328: In the non VAR|CV case SEPARTE_ARRAY is not used. As we're going
to change the IAP, this is probably necessary in this case as well.

In this case SEPARATE_ARRAY is done in FE_FETCH_RW.

> * For RW iterator failures FREE_OP1_VAR_PTR() is used. This probably
leaks in the TMP case. (Same for the "invalid argument" case.)

The same as above, but needs to be checked.

>
> What concerns me a bit is the new FETCH_RW implementation, because it no
longer checks the internal pointer against the external one. This
effectively means that foreach by reference behavior will be influenced a
lot by details of the hashtable implementation. An example:
>
> $array = [0, 1, 2, 3, 4, 5, 6, 7];
> unset($array[0], $array[1], $array[2], $array[3]);
> foreach ($array as &$ref) {
> var_dump($ref);
> //$array[42] = 42;
> }
>
> Without the commented line this will just print the numbers 4, 5, 6, 7.
If you uncomment the line it will only print 4. (Because the append caused
a rehash and arData was compacted, so the position now points past all
elements). The previous output would have been 4, 5, 6, 7, 42, which is
closer to what you would expect. Maybe better to keep the pos !=
nInternalPointer code?

Yes. This is the main problem, however, the old implementation wasn't good
enough as well. It caught many (but not all cases). It's the reason why we
had few tests XFAILEd. This need to be solved in some other way, similar to
your old proposal but in more efficient way.

Thanks for review, it's very useful.
I'll probably able to provide next version of PoC in a couple of days.

Dmitry.

>
> Thanks,
> Nikita

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

[Andrea Faulds]

Hey everyone,

Anatol (aka welting) has done some excellent work, and a lot more extensions 
now build on the bigint branch, even if not all of them are fully ported:

https://wiki.php.net/rfc/bigint#todo

This should mean that testing “real-world applications” for performance is now 
possible.

Thanks!

--
Andrea Faulds
http://ajf.me/





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

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[Pierre Joye]

On Wed, Jan 28, 2015 at 8:10 AM, Jan Ehrhardt  wrote:
> Sebastian Bergmann in php.internals (Tue, 27 Jan 2015 21:36:49 +0100):
>>Am 27.01.2015 um 21:13 schrieb Pierre Joye:
>>> However there is one thing we do need to care, and this is 3rd party
>>> extensions. This is all I care about and why I initiated pickle.
>>
>> It just that I am not convinced that the problem you are trying to solve
>> with a tool such as pickle exists. From my experience, people either
>> build everything manually from source (because they work on the source)
>> or they install binaries packaged by a vendor using the appropriate
>> package manager.
>
> The problem is a real one. One example: for Windows PECL extensions are
> buolt at http://windows.php.net/downloads/pecl/

they are available on http://pecl.php.net, only snapshots are there only.

> The current trend makes it virtually impossible to add PHP7 to these
> builds, because for instance you have to checkout 'phpng' branches for
> propro, raphf and pecl_http and the 'phpseven' branch for imagick. At
> the moment that these branches are merged into master and separate
> branches for PHP5 are created, the PHP5 builds will be broken.
>
> If you aren't involved in developing the sources of an extension it
> becomes a trial-and-error game to see if the extension builds for PHP7.

This is not specific to windows. Having discussed that with many
distros, developers, ISPs etc. this is actually a big problem. The
biggest being the totally meaningless of a branch from a semver point
of view. What to do with a package version where there is no
difference in the public API for 5 and 7? 2.x for 7 and 1.x for 5?
What's next? 3. for 7 and 4.x for 8? this is an endless pain.

That's why I would rather propose a single branch for any php
supported php version, as we always have done.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

Re: [PHP-DEV] [RFC][Vote] Return Types

[Levi Morrison]

Dmitry,

I updated the patch to latest master and (seem to have) fixed a memory
issue with it. However when I pushed it back up Travis had a lot of failing
return types tests. Could you (and anyone else willing) pull it and see if
you are getting failing tests for release and debug builds?

Cheers,

Levi Morrison


On Tue, Jan 27, 2015 at 1:13 PM, Dmitry Stogov  wrote:

> Hi Levi,
>
> Do you like me to make final check and merge your pull request?
> We need it :)
>
> Thanks. Dmitry.
>
> On Sat, Jan 24, 2015 at 8:01 AM, Levi Morrison  wrote:
>
>> On Fri, Jan 23, 2015 at 5:06 PM, Levi Morrison  wrote:
>> > As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will
>> > close in a few hours. I want to thank everyone who has voted so far,
>> > and encourage anyone who has not yet voted to do so.
>>
>> I have close the voting. It has passed with a vote of 47 to 3.
>>
>> I will update the patch to the latest master and then ping Dmitry to
>> do a final pass before merging it into master.
>>
>
>

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[Jan Ehrhardt]

Sebastian Bergmann in php.internals (Tue, 27 Jan 2015 21:36:49 +0100):
>Am 27.01.2015 um 21:13 schrieb Pierre Joye:
>> However there is one thing we do need to care, and this is 3rd party
>> extensions. This is all I care about and why I initiated pickle.
>
> It just that I am not convinced that the problem you are trying to solve
> with a tool such as pickle exists. From my experience, people either
> build everything manually from source (because they work on the source)
> or they install binaries packaged by a vendor using the appropriate
> package manager.

The problem is a real one. One example: for Windows PECL extensions are
buolt at http://windows.php.net/downloads/pecl/

The current trend makes it virtually impossible to add PHP7 to these
builds, because for instance you have to checkout 'phpng' branches for
propro, raphf and pecl_http and the 'phpseven' branch for imagick. At
the moment that these branches are merged into master and separate
branches for PHP5 are created, the PHP5 builds will be broken.

If you aren't involved in developing the sources of an extension it
becomes a trial-and-error game to see if the extension builds for PHP7.

Jan

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

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[Pierre Joye]

On Jan 28, 2015 3:36 AM, "Sebastian Bergmann"  wrote:
>
> Am 27.01.2015 um 21:13 schrieb Pierre Joye:
> > However there is one thing we do need to care, and this is 3rd party
> > extensions. This is all I care about and why I initiated pickle.
>
>  It just that I am not convinced that the problem you are trying to solve
>  with a tool such as pickle exists. From my experience, people either
>  build everything manually from source (because they work on the source)
>  or they install binaries packaged by a vendor using the appropriate
>  package manager.

And there is no appropriate one right now. Discussions in composer channel
confirm that.

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

Re: [PHP-DEV] Proposal: Raise severity of undefined constants

[Andrea Faulds]

Hey Rowan,

I actually was thinking about doing this myself, if function/constant 
autoloading passed. That would mean that if you really needed this behaviour 
for some reason, you could write a constant autoloader that reimplements it.

One concern I’d have is the use of constants in constant scalar expressions. In 
implementation, we’d need to make sure those produce an error, not just normal 
constant usage.

Anyway, I’m very much in favour of this. Please go ahead!

Thanks.
--
Andrea Faulds
http://ajf.me/





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

[PHP-DEV] Re: [VOTE] Remove hex support in numeric strings

[Nikita Popov]

On Sat, Jan 17, 2015 at 8:40 PM, Nikita Popov  wrote:

> Hi internals!
>
> The RFC proposing to remove support for hexadecimal strings in
> is_numeric_string() is now in voting:
>
> https://wiki.php.net/rfc/remove_hex_support_in_numeric_strings
>
> Thanks,
> Nikita
>

The RFC was accepted unanimously with 29 votes in favor :)

Nikita

Re: [PHP-DEV] Improvements to for-each implementation

[Nikita Popov]

On Tue, Jan 27, 2015 at 5:55 PM, Dmitry Stogov  wrote:

> Hi,
>
> I'm working on a PoC, implementing the proposed behavior -
> https://gist.github.com/dstogov/a311e8b0b2cabee4dab4
>
> Only few PHPT tests had to be changed to confirm new behavior and actually
> they started to behave as HHVM.
> 2 tests are still unfixed XFAILed. Foreach by reference is still need to
> be improved to support different array modifications.
>
> The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
> destruction of 200 arrays on each request)
>
> Thanks. Dmitry.
>

I quickly looked over the patch, some notes:

* 171: Can directly use GET_OP1_ZVAL_PTR_DEREF
* For iterator failures (exception) you use FREE_OP1_IF_VAR(). Is this
enough? If the object is a TMP_VAR, don't we have to free it as well?
* For objects it will still be possible to modify the hashtable during
iteration even in the _R case, correct? I assume we just don't care about
this edge case.
* 315: In RESET_RW you now always create a reference for VAR|CV operands.
However for the get_iterator case we don't need this, right?
* 328: In the non VAR|CV case SEPARTE_ARRAY is not used. As we're going to
change the IAP, this is probably necessary in this case as well.
* For RW iterator failures FREE_OP1_VAR_PTR() is used. This probably leaks
in the TMP case. (Same for the "invalid argument" case.)

What concerns me a bit is the new FETCH_RW implementation, because it no
longer checks the internal pointer against the external one. This
effectively means that foreach by reference behavior will be influenced a
lot by details of the hashtable implementation. An example:

$array = [0, 1, 2, 3, 4, 5, 6, 7];
unset($array[0], $array[1], $array[2], $array[3]);
foreach ($array as &$ref) {
var_dump($ref);
//$array[42] = 42;
}

Without the commented line this will just print the numbers 4, 5, 6, 7. If
you uncomment the line it will only print 4. (Because the append caused a
rehash and arData was compacted, so the position now points past all
elements). The previous output would have been 4, 5, 6, 7, 42, which is
closer to what you would expect. Maybe better to keep the pos !=
nInternalPointer code?

Thanks,
Nikita

[PHP-DEV] Proposal: Raise severity of undefined constants

[Rowan Collins]

Hi All,

I would like to propose that the error given for an undefined constant 
should be raised from E_NOTICE, probably to E_RECOVERABLE_ERROR, in PHP 7.


I'm happy to expand this into a proper RFC, and work on patches for the 
engine, tests, and spec, but want to see if initial reception to the 
idea is favourable first.


Current behaviour: any bare word which is not a defined constant is 
treated as though it were a quoted string, with an E_NOTICE issued.


Proposed behaviour: an E_RECOVERABLE_ERROR is issued; if the error is 
caught, either the existing string behaviour could be retained, or the 
value could be treated as NULL. (I'm open to other alternatives.)


PROS

1. Consistency.

An undefined class constant (e.g. Foo::BAR) gives a fatal error, but a 
normal global constant gives only a notice. Class constants being "more 
modern" made this seem reasonable, but with namespaces, it's even worse 
- a qualified namespace constant (e.g. Foo\BAR) gives a fatal error, as 
does a global constant in namespace notation (e.g. \BAR); but a 
namespace constant referenced relative to the current namespace is a 
bare word, and gives only a notice (e.g. namespace Foo; const BAR=42; 
echo BAAR;).


Functions and classes also give fatal errors if used without declaring; 
variables do not, but this is more useful, because they can meaningfully 
be created as null, and there isn't a syntax to declare a local 
variable, only to initialise it.


2. Inherent severity.

It's probably relatively common to turn off E_NOTICE in error_reporting, 
or to miss one notice among many others. But an undefined constant 
magically turning into a string could cause relatively major problems.


Firstly, a constant is likely to have some value which needs to be used 
or matched somewhere else. A READ_ONLY flag mis-typed as REED_ONLY could 
be interpreted as int(0) (i.e. intval('REED_ONLY')) and cause a 
catastrophic error.


Secondly, keywords are also bare words, and any expression can be a 
statement. Thus the following is an infinite loop, no matter what 
blahblah() returns:

while(true) {
if ( blahblah() ) {
brek;
}
}

Obviously, there are other mistakes which could cause such errors, but 
this is one that the engine could easily pick up on and protect the user.



CONS

Like most changes, the downside is a break in compatibility.

As far as I can make out, the current behaviour is actually for 
compatibility back as far as PHP 3 (correct me if I'm wrong, I didn't 
dig far).


I'm not aware of any notice officially deprecating barewords-as-strings, 
but nor can I find many references to it in the manual at all. Its use 
for array keys has been explicitly discouraged in the manual since some 
time in 2001. [1]


Outside code golf, I'd be very surprised if any code written or updated 
in the last 10 years deliberately uses this "feature", and I think 
changing it in PHP 7 is justifiable given the benefits to maintainers of 
even the simplest non-OO, non-namespaced code.



What do people think?

[1] 
http://web.archive.org/web/20010614144157/http://www.php.net/manual/en/language.types.array.php#language.types.array.donts


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] [RFC] [VOTE] Fast Parameter Parsing API

[Dmitry Stogov]

The voting is closed. It's passed with 19 voters for and 1 against.

Thanks. Dmitry.

On Mon, Jan 19, 2015 at 5:25 PM, Pierre Joye  wrote:

>
> On Jan 19, 2015 9:17 PM, "Dmitry Stogov"  wrote:
> >
> > I'd like to initiate a vote on this RFC:
> > https://wiki.php.net/rfc/fast_zpp
> > 
> >
> > It proposes an additional fast way to parse arguments of internal
> functions.
> >
> > The implementation was included into phpng before merging into php-7, but
> > we were agree to vote on it when alternative implementation is available,
> > but nobody interested in alternative implementation now.
>
> Well, time and moving target were more a problem than not interested
>
> > Thanks. Dmitry.
>

Re: [PHP-DEV] imagick on PHP 7 was Stepping stones to a working php7 ...

[Lester Caine]

On 27/01/15 19:21, Dan Ackroyd wrote:
>> I'm getting a
>> > unknown type name ‘smart_str’ after failing to find php_smart_str.h
>> > because my php7 build has php_smart_string.h.
> Apologies - this was caused by the filename being changed in the PHP
> src, and me compiling against the version left in the
> /usr/local/include/php directory. It is fixed now.
> 
> btw, apparently 'make distclean' doesn't seem to clean up the header
> files in '/usr/local/include/php/ext/' for me at least on Centos.

That has fixed imagick, but I can't get phpinfo to run on the rebuilt
php-fpm after syncing with the pdo changes. Not sure where I went wrong,
but pdo_sqlite is complaining about the API change yet has the new
source ...

Just running from a clean build to see what happens ...

OK - nginx is now starting clean, but when I enable imagick extension
then running phpinfo fails. The extension seems to be working OK otherwise.

-- 
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] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[Sebastian Bergmann]

Am 27.01.2015 um 21:13 schrieb Pierre Joye:
> However there is one thing we do need to care, and this is 3rd party
> extensions. This is all I care about and why I initiated pickle.

 It just that I am not convinced that the problem you are trying to solve
 with a tool such as pickle exists. From my experience, people either
 build everything manually from source (because they work on the source)
 or they install binaries packaged by a vendor using the appropriate
 package manager.

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

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Pierre Joye]

On Jan 27, 2015 4:36 PM, "Derick Rethans"  wrote:
>
> On Tue, 27 Jan 2015, Pierre Joye wrote:
>
> > On Jan 27, 2015 11:25 AM, "Yasuo Ohgaki"  wrote:
> > >
> > > On Tue, Jan 27, 2015 at 12:56 PM, Kalle Sommer Nielsen 
> > > wrote:
> > >
> > > > I think the warning is fair as it is, if it is annoying for small
> > > > use cases like on the CLI then simply: php -d date.timezone=UTC -r
> > > > "echo date('H:i:s');" or the dirty way by using the silent
> > > > operator. It used to be a notice prior 5.3 I think or something.
> > > >
> > > > While I do agree that most applications should be using UTC, which
> > > > should be set by default we sometimes need to tell userland the
> > > > hard way how things work, and/or what they should care about, like
> > > > the E_WARNING, E_CORE_ERROR, E_DEPRECATED for old php.ini
> > > > settings.
> > > >
> > > > -1 for removing it from my side.
> > >
> > > I can understand your argument. Perhaps, we may reconsider to
> > > introduce E_DEBUG/E_USER_DEBUG for these purposes. There are many
> > > functions, e.g. file related, that I feel E_WARNING is excessive.
> >
> > I do not have a strong opinion on that. So keep it or make it UTC
> > default but please do not add yet another warning/notice/whatever.
> >
> > Also, setting a timezone is not about Dev or other fancy tasks, it is
> > about making datetime processing right.
> >
> > If anything I would enforce the default at configure/build time. So it
> > at least gets the correct one from a host point of view.
>
> That would be nice, but it's unfortuntately not really possible. You
> can't find out what timezone the OS is using in a portable way. Not even
> among different linux distributions, let alone having Windows in the
> mix. We tried this before, and because it caused so many issues, the
> current warning was added (instead of trying to guess a timezone).

Either we get a valid one at install time or we bail out during make
install. Do not worry about windows here, no biggie either.

I am not saying we must do that but it is by far friendlier that we do now
or what it is proposed.

> cheers,
> Derick

Re: [PHP-DEV] [RFC][Vote] Return Types

[Dmitry Stogov]

Hi Levi,

Do you like me to make final check and merge your pull request?
We need it :)

Thanks. Dmitry.

On Sat, Jan 24, 2015 at 8:01 AM, Levi Morrison  wrote:

> On Fri, Jan 23, 2015 at 5:06 PM, Levi Morrison  wrote:
> > As a reminder, this RFC (https://wiki.php.net/rfc/return_types) will
> > close in a few hours. I want to thank everyone who has voted so far,
> > and encourage anyone who has not yet voted to do so.
>
> I have close the voting. It has passed with a vote of 47 to 3.
>
> I will update the patch to the latest master and then ping Dmitry to
> do a final pass before merging it into master.
>

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[Pierre Joye]

On Jan 27, 2015 4:43 PM, "Sebastian Bergmann"  wrote:
>
> Am 27.01.2015 um 10:00 schrieb Lester Caine:
> > composer has not even managed to get added to some distributions yet
>
>  This is not about PEAR Installer vs. Composer or something else. This
>  is about the PHP core getting untangled from third-party software that
>  impedes the development of PHP itself.
>
>  As a sidenote, to most (if not all) PHP developers that I have met
>  since PHP 5 came out there is nothing of value in PEAR (as in the
>  packages hosted on pear.php.net). These packages became obsolete the
>  moment the PEAR Installer supported channels other than pear.php.net.
>  Now that most (if not all) commonly used libraries, components,
>  frameworks, tools, etc. no longer (exclusively) offer their releases
>  as PEAR packages, the PEAR Installer has become irrelevant. It should
>  no longer be bundled with PHP (neither should any other package
>  manager). PEAR has served its purpose, it provided value for the PHP
>  ecosystem for a time, but now it should be retired.

Sebastian,

It is good and all that to throw great principles into such discussions
into this thread.

However there is one thing we do need to care, and this is 3rd party
extensions. This is all I care about and why I initiated pickle.

The other parts of what I would like to tackle is the way we do them. Let
face it, right it is a mess. Php7, if we don't discuss the actual issue
will be even worst.

The current trend to create branches for 7 is a bad idea. It is a
maintenance and release nightmare. Nothing is ready to deal with that. It
is also a real pain from a semantic version point of view.

We have been asked to discuss this issue many times and it is the only
point for pickle to reach beta phase.

I would rather start to see how we can help 3rd extensions (and solve the
sapi ones too) developer by providing solutions, standard and tools instead
of talking about a de facto dead cow.

Cheers,
Pierre

Re: [PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

[Paul Dragoonis]

On 27 Jan 2015 19:49, "Stanislav Malyshev"  wrote:
>
> Hi!
>
> >>> Cons
> >>>  - Existing code modifications. (It's E_DEPRECATED. User may ignore.)
> >>>  - (Please point it out more disadvantages)
>
> I think removing or disrupting functions without a very good reason
> (such as, functionality going away or this function is abused or is
> broken in many use cases) is wrong. These functions don't seem broken,
> they just do something that you can do in another way. I don't think it
> is necessary to deprecated them.

I share the same mindset as Stas.

Let's work on resolving bugs instead of breaking BC ? :)

>
> --
> Stas Malyshev
> smalys...@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Re: [PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

[Stanislav Malyshev]

Hi!

>>> Cons
>>>  - Existing code modifications. (It's E_DEPRECATED. User may ignore.)
>>>  - (Please point it out more disadvantages)

I think removing or disrupting functions without a very good reason
(such as, functionality going away or this function is abused or is
broken in many use cases) is wrong. These functions don't seem broken,
they just do something that you can do in another way. I don't think it
is necessary to deprecated them.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

[Stanislav Malyshev]

Hi!

> I feel it's kindof wrong direction.
> 
> if you want custom logs, maybe you should use custom logger.

Same here, API basing on modifying something that is supposed to be
internal engine things feels wrong, even if it does work. Changing error
message is borderline, changing things like lines/filenames just feels
wrong.

Maybe better access to logging system for custom logging would be more
efficient instead?

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] imagick on PHP 7 was Stepping stones to a working php7 ...

[Dan Ackroyd]

On 26 January 2015 at 21:06, Lester Caine  wrote:
> I'm getting a
> unknown type name ‘smart_str’ after failing to find php_smart_str.h
> because my php7 build has php_smart_string.h.

Apologies - this was caused by the filename being changed in the PHP
src, and me compiling against the version left in the
/usr/local/include/php directory. It is fixed now.

btw, apparently 'make distclean' doesn't seem to clean up the header
files in '/usr/local/include/php/ext/' for me at least on Centos.

cheers
Dan

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

Re: [PHP-DEV] Improvements to for-each implementation

[Yasuo Ohgaki]

Hi Dmitry,

On Wed, Jan 28, 2015 at 1:55 AM, Dmitry Stogov  wrote:

> I'm working on a PoC, implementing the proposed behavior -
> https://gist.github.com/dstogov/a311e8b0b2cabee4dab4
>
> Only few PHPT tests had to be changed to confirm new behavior and actually
> they started to behave as HHVM.
> 2 tests are still unfixed XFAILed. Foreach by reference is still need to be
> improved to support different array modifications.
>
> The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
> destruction of 200 arrays on each request)
>

Great!

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

[Yasuo Ohgaki]

Hi all,

On Wed, Jan 28, 2015 at 3:09 AM, Yasuo Ohgaki  wrote:

> On Tue, Jan 27, 2015 at 9:26 PM, Xinchen Hui  wrote:
>
>> if you want custom logs, maybe you should use custom logger.
>
>
> It requires to catch all errors, I suppose. If PHP allows it, either would
> work.


I considered a little more. With error handler that catches E_ERROR cannot
be
complex handler as complex handler may use various resources that  may
cause
all kinds of errors. Therefore, complex custom error handler logger may
miss to
log important errors.

Best practice would be separating app log and system(PHP) error log.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Improvements to for-each implementation

[Rasmus Lerdorf]

On 01/27/2015 08:55 AM, Dmitry Stogov wrote:
> The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
> destruction of 200 arrays on each request)

Awesome!



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

[Yasuo Ohgaki]

Hi Xinhcen,

On Tue, Jan 27, 2015 at 9:26 PM, Xinchen Hui  wrote:

> if you want custom logs, maybe you should use custom logger.


It requires to catch all errors, I suppose. If PHP allows it, either would
work.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Improvements to for-each implementation

[Dmitry Stogov]

Hi,

I'm working on a PoC, implementing the proposed behavior -
https://gist.github.com/dstogov/a311e8b0b2cabee4dab4

Only few PHPT tests had to be changed to confirm new behavior and actually
they started to behave as HHVM.
2 tests are still unfixed XFAILed. Foreach by reference is still need to be
improved to support different array modifications.

The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
destruction of 200 arrays on each request)

Thanks. Dmitry.



On Thu, Jan 22, 2015 at 1:38 PM, Benjamin Coutu  wrote:

> Hi Nikita,
>
> I would suggest using the proposal for the by-value case and sticking with
> the current behavior for the by-reference case as you suggested. Granted,
> we then cannot remove the internal pointer all together, but we would just
> use it for the less common by-reference case as well as for the legacy
> reset/next functions, of course. This would still improve most for-each
> traversals. At least we then wouldn't have to find a replacement solution
> for rest/prev/next/end. Moreover we can then move the internal position
> pointer out of the hashtable structure into zend_array because it is only
> used for userland arrays, not other hash tables (such as object properties
> or internal structures that build upon the hashtable struct).
>
> Thanks,
>
> Ben
>
> == Original ==
> From: Nikita Popov 
> To: Benjamin Coutu 
> Date: Thu, 22 Jan 2015 10:53:19 +0100
> Subject: Re: [PHP-DEV] Improvements to for-each implementation
>
> Doing this was the idea I had in mind as well, i.e. change the semantics of
> foreach to say that it will always work on a copy for by-value iteration
> (which ironically avoids having to actually copy it). Note that this will
> differ from the current behavior in a number of ways. In particular it
> means that changes to arrays that were references prior to iteration will
> not influence the iteration.
>
> The real question is what we should do in the by-reference case. Given that
> we need to acquire references to elements of the original array we can't
> reasonably work with copy-semantics (at least I don't see how). So would we
> just stick with the previous behavior (using the hash position hack) for
> that?
>
> Nikita
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] master make error on ubuntu 64 14.04 : error: unknown type name ‘int64_t’

[Anatol Belski]

On Tue, January 27, 2015 17:21, marius adrian popa wrote:
> In file included from
> /home/mariuz/work/php-src/ext/date/lib/timelib.h:24:0,
> from /home/mariuz/work/php-src/ext/date/lib/astro.c:26:
> /home/mariuz/work/php-src/ext/date/lib/timelib_structs.h:125:1: error:
> unknown type name ‘int64_t’ typedef int64_t timelib_long; ^
> /home/mariuz/work/php-src/ext/date/lib/timelib_structs.h:126:1: error:
> unknown type name ‘uint64_t’ typedef uint64_t timelib_ulong; ^
> /home/mariuz/work/php-src/ext/date/lib/timelib_structs.h:154:2: error:
> unknown type name ‘int32_t’ int32_t  offset; ^
>
>
Please try after ./buildconf --force and reconfiguring.

Thanks.

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

[PHP-DEV] master make error on ubuntu 64 14.04 : error: unknown type name ‘int64_t’

[marius adrian popa]

In file included from /home/mariuz/work/php-src/ext/date/lib/timelib.h:24:0,
 from /home/mariuz/work/php-src/ext/date/lib/astro.c:26:
/home/mariuz/work/php-src/ext/date/lib/timelib_structs.h:125:1: error:
unknown type name ‘int64_t’
 typedef int64_t timelib_long;
 ^
/home/mariuz/work/php-src/ext/date/lib/timelib_structs.h:126:1: error:
unknown type name ‘uint64_t’
 typedef uint64_t timelib_ulong;
 ^
/home/mariuz/work/php-src/ext/date/lib/timelib_structs.h:154:2: error:
unknown type name ‘int32_t’
  int32_t  offset;
  ^

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Matteo Beccati]

On 27/01/2015 16:39, Bob Weinand wrote:

Actually, the example ini files could even start with a friendly reminder that 
date.timezone should be set.


Not arguing here. I'm on your side here, we can give the timezone a better 
visibility in the ini without problems.


Good :)


The point is just to have date() (with UTC obviously) usable without getting warned in a 
simple ./sapi/cli/php -r '/* something with date() */' call. And no, I don't want to 
always forget to explicitly set "-ddate.timezone=UTC". It's not comfortable 
that way.


So, you'd prefer to make life harder for end users in order to make life 
easier to those calling sapi/cli/php without a php.ini.


To me, it doesn't sound like a good plan, sorry.

I don't get why

echo 'date.timezone=UTC' >> $prefix/lib/php.ini

isn't comfortable enough for you.


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] [RFC] Remove the date.timezone warning

[Bob Weinand]

> Am 27.01.2015 um 16:27 schrieb Matteo Beccati :
> 
> On 27/01/2015 15:12, Bob Weinand wrote:
>> If you use the distros default, it often is UTC too. Then we have
>> this same issue, just without warning. This warning often doesn't
>> help at all, because it just doesn't appear at all.
> 
> Well, if the distro sets display_errors = Off but doesn't also set a proper 
> timezone, I would dare to say it's a bug in their packages.
> 
> Vanilla PHP doesn't do that; it does if you blindly use php.ini-production, 
> but then it's your own fault if you don't set it.
> 
> Actually, the example ini files could even start with a friendly reminder 
> that date.timezone should be set.

Not arguing here. I'm on your side here, we can give the timezone a better 
visibility in the ini without problems.

The point is just to have date() (with UTC obviously) usable without getting 
warned in a simple ./sapi/cli/php -r '/* something with date() */' call. And 
no, I don't want to always forget to explicitly set "-ddate.timezone=UTC". It's 
not comfortable that way.

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

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Matteo Beccati]

On 27/01/2015 15:12, Bob Weinand wrote:

If you use the distros default, it often is UTC too. Then we have
this same issue, just without warning. This warning often doesn't
help at all, because it just doesn't appear at all.


Well, if the distro sets display_errors = Off but doesn't also set a 
proper timezone, I would dare to say it's a bug in their packages.


Vanilla PHP doesn't do that; it does if you blindly use 
php.ini-production, but then it's your own fault if you don't set it.


Actually, the example ini files could even start with a friendly 
reminder that date.timezone should be set.



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] Re: [RFC][DISCUSSION] Removal of dead SAPIs and extensions

[Xinchen Hui]

Hey:


On Tue, Jan 27, 2015 at 9:44 PM, Ferenc Kovacs  wrote:
>
>
> On Tue, Jan 27, 2015 at 2:06 PM, Anatol Belski 
> wrote:
>>
>> Hi Hui,
>>
>> On Tue, January 27, 2015 13:32, Xinchen Hui wrote:
>> > Hey:
>> >
>> >
>> > On Tue, Jan 27, 2015 at 6:23 PM, Anatol Belski 
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >>
>> >> On Mon, January 19, 2015 18:04, Anatol Belski wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>>
>> >>>
>> >>> I think the research on
>> >>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now far
>> >>> enough to be discussed.
>> >>>
>> >>> So far I only could not test sapi/nsapi because it needs a
>> >>> SunOs/IPlanet.
>> >>> But independent from that, it'd make sense someone to recheck my
>> >>> perceptions, or just the areas one is interested in.
>> >>>
>> >>> Also hereby I'm calling the authors/maintainers of the corresponding
>> >>> units to give the info about their intentions.
>> >>>
>> >>> Lets think about it, anyway. Maybe I've missed some extension yet,
>> >>> then that were a chance to add it to the RFC.
>> >>>
>> >>
>> >> thanks' for the feedback so far. I've changed the title now to
>> >>
>> >> "Removal of dead or not yet PHP7 ported SAPIs and extensions"
>> >>
>> >>
>> >> Also extended the RFC with the information we've got so far - added the
>> >>  extensions suggested by Dmitry and the feedback arrived inbetween.
>> >>
>> >> Please check this again, I plan to start the vote on this next week.
>> >>
>> > removing extensions is okey, since they can goes to PECL
>> >
>> > but for SAPIs, where it can go... :<
>> >
>> They wouldn't have to go anywhere if they were supported well. With SAPIs
>> - many of the servers are either very old or don't support the SAPI
>> module. Thus porting those SAPIs, even if there were some willing,
>> wouldn't make not much sense (well, maybe for the learning fun).
>>
>> Where should they go - I'd say nowhere. Extensions as well. The removal
>> should be tagged as any other RFC patch. Then it can be picked from the
>> tag by the persons ready/willing to maintain them, and taken into PECL or
>> ported to PHP7 and included again. Depending on the vote results of
>> course.
>>
>> Regards
>>
>> Anatol
>>
>
> what laruence is trying to say that we don't really have a syberia for SAPIs
> as we have for exts(pecl), but given how these SAPIs are not
> maintained/compatible with PHP7, I don't think that it is a blocker problem.
:),  thanks!

> just maybe something we could improve with the future (would also make it
> easier to develop SAPIs supporting multiple php versions for example opcache
> and phpdbg, currently those are a bit PITA for the maintainers).
>
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Removal of dead SAPIs and extensions

[Anatol Belski]

Hi Ferenc,

On Tue, January 27, 2015 14:46, Ferenc Kovacs wrote:
> On Tue, Jan 27, 2015 at 2:44 PM, Ferenc Kovacs  wrote:
>
>
>>
>>
>> On Tue, Jan 27, 2015 at 2:06 PM, Anatol Belski 
>> wrote:
>>
>>
>>> Hi Hui,
>>>
>>>
>>> On Tue, January 27, 2015 13:32, Xinchen Hui wrote:
>>>
 Hey:



 On Tue, Jan 27, 2015 at 6:23 PM, Anatol Belski
 
 wrote:


> Hi,
>
>
>
> On Mon, January 19, 2015 18:04, Anatol Belski wrote:
>
>
>> Hi,
>>
>>
>>
>>
>> I think the research on
>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now
>> far enough to be discussed.
>>
>> So far I only could not test sapi/nsapi because it needs a
>> SunOs/IPlanet.
>> But independent from that, it'd make sense someone to recheck my
>>  perceptions, or just the areas one is interested in.
>>
>> Also hereby I'm calling the authors/maintainers of the
>> corresponding units to give the info about their intentions.
>>
>> Lets think about it, anyway. Maybe I've missed some extension
>> yet, then that were a chance to add it to the RFC.
>>
>
> thanks' for the feedback so far. I've changed the title now to
>
> "Removal of dead or not yet PHP7 ported SAPIs and extensions"
>
>
>
> Also extended the RFC with the information we've got so far -
> added the extensions suggested by Dmitry and the feedback arrived
> inbetween.
>
> Please check this again, I plan to start the vote on this next
> week.
>
 removing extensions is okey, since they can goes to PECL

 but for SAPIs, where it can go... :<

>>> They wouldn't have to go anywhere if they were supported well. With
>>> SAPIs
>>> - many of the servers are either very old or don't support the SAPI
>>> module. Thus porting those SAPIs, even if there were some willing,
>>> wouldn't make not much sense (well, maybe for the learning fun).
>>>
>>> Where should they go - I'd say nowhere. Extensions as well. The
>>> removal should be tagged as any other RFC patch. Then it can be picked
>>> from the tag by the persons ready/willing to maintain them, and taken
>>> into PECL or ported to PHP7 and included again. Depending on the vote
>>> results of course.
>>>
>>> Regards
>>>
>>>
>>> Anatol
>>>
>>>
>>>
>> what laruence is trying to say that we don't really have a syberia for
>> SAPIs as we have for exts(pecl), but given how these SAPIs are not
>> maintained/compatible with PHP7, I don't think that it is a blocker
>> problem. just maybe something we could improve with the future (would
>> also make it easier to develop SAPIs supporting multiple php versions
>> for example opcache and phpdbg, currently those are a bit PITA for the
>> maintainers).
>>
>
> sorry, for the confusion, ofc. opcache isn't a SAPI, but it is also
> provided as a pecl extension for php < 5.5, so while it is still a PITA
> for the devs, is unrelated to the topic of SAPIs.
>
>
ahh, in that sense that SAPIs are not supported to be built externally.
Yep, that were an improvement to the build scripts and the infrastructure.
But well, as it's not there - so lets retire them in a branch. Still
better than drag them along possibly getting bug reports.

Regards

Anatol



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

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Bob Weinand]

> Am 27.01.2015 um 12:49 schrieb Matteo Beccati :
> 
> On 27/01/2015 12:28, Nikita Popov wrote:
>> So let the distros solve it ... and allow PHP to still be usable without an
>> ini file.
> 
> So, I install php from sources and (simulating the RFC):
> 
> # php -d date.timezone='' -r 'var_dump(@date("Y-m-d H:i:s"));'
> string(19) "2015-01-27 11:39:43"
> # date
> Tue Jan 27 12:39:45 CET 2015
> 
> how many people would think "WTF"?
> 
> how many "oh right, PHP defaults to UTC unless I change my php.ini"?
> 
> how many "my mistake! of course my laptop should use UTC!"?
> 
> 
> Cheers
> -- 
> Matteo Beccati
> 
> Development & Consulting - http://www.beccati.com/

If you use the distros default, it often is UTC too. Then we have this same 
issue, just without warning. This warning often doesn't help at all, because it 
just doesn't appear at all.

If you use no ini, you probably are much more aware of that already...

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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Removal of dead SAPIs and extensions

[Ferenc Kovacs]

On Tue, Jan 27, 2015 at 2:44 PM, Ferenc Kovacs  wrote:

>
>
> On Tue, Jan 27, 2015 at 2:06 PM, Anatol Belski 
> wrote:
>
>> Hi Hui,
>>
>> On Tue, January 27, 2015 13:32, Xinchen Hui wrote:
>> > Hey:
>> >
>> >
>> > On Tue, Jan 27, 2015 at 6:23 PM, Anatol Belski 
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >>
>> >> On Mon, January 19, 2015 18:04, Anatol Belski wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>>
>> >>>
>> >>> I think the research on
>> >>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now far
>> >>> enough to be discussed.
>> >>>
>> >>> So far I only could not test sapi/nsapi because it needs a
>> >>> SunOs/IPlanet.
>> >>> But independent from that, it'd make sense someone to recheck my
>> >>> perceptions, or just the areas one is interested in.
>> >>>
>> >>> Also hereby I'm calling the authors/maintainers of the corresponding
>> >>> units to give the info about their intentions.
>> >>>
>> >>> Lets think about it, anyway. Maybe I've missed some extension yet,
>> >>> then that were a chance to add it to the RFC.
>> >>>
>> >>
>> >> thanks' for the feedback so far. I've changed the title now to
>> >>
>> >> "Removal of dead or not yet PHP7 ported SAPIs and extensions"
>> >>
>> >>
>> >> Also extended the RFC with the information we've got so far - added the
>> >>  extensions suggested by Dmitry and the feedback arrived inbetween.
>> >>
>> >> Please check this again, I plan to start the vote on this next week.
>> >>
>> > removing extensions is okey, since they can goes to PECL
>> >
>> > but for SAPIs, where it can go... :<
>> >
>> They wouldn't have to go anywhere if they were supported well. With SAPIs
>> - many of the servers are either very old or don't support the SAPI
>> module. Thus porting those SAPIs, even if there were some willing,
>> wouldn't make not much sense (well, maybe for the learning fun).
>>
>> Where should they go - I'd say nowhere. Extensions as well. The removal
>> should be tagged as any other RFC patch. Then it can be picked from the
>> tag by the persons ready/willing to maintain them, and taken into PECL or
>> ported to PHP7 and included again. Depending on the vote results of
>> course.
>>
>> Regards
>>
>> Anatol
>>
>>
> what laruence is trying to say that we don't really have a syberia for
> SAPIs as we have for exts(pecl), but given how these SAPIs are not
> maintained/compatible with PHP7, I don't think that it is a blocker problem.
> just maybe something we could improve with the future (would also make it
> easier to develop SAPIs supporting multiple php versions for example
> opcache and phpdbg, currently those are a bit PITA for the maintainers).
>

sorry, for the confusion, ofc. opcache isn't a SAPI, but it is also
provided as a pecl extension for php < 5.5, so while it is still a PITA for
the devs, is unrelated to the topic of SAPIs.


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Removal of dead SAPIs and extensions

[Ferenc Kovacs]

On Tue, Jan 27, 2015 at 2:06 PM, Anatol Belski 
wrote:

> Hi Hui,
>
> On Tue, January 27, 2015 13:32, Xinchen Hui wrote:
> > Hey:
> >
> >
> > On Tue, Jan 27, 2015 at 6:23 PM, Anatol Belski 
> > wrote:
> >
> >> Hi,
> >>
> >>
> >> On Mon, January 19, 2015 18:04, Anatol Belski wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>>
> >>> I think the research on
> >>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now far
> >>> enough to be discussed.
> >>>
> >>> So far I only could not test sapi/nsapi because it needs a
> >>> SunOs/IPlanet.
> >>> But independent from that, it'd make sense someone to recheck my
> >>> perceptions, or just the areas one is interested in.
> >>>
> >>> Also hereby I'm calling the authors/maintainers of the corresponding
> >>> units to give the info about their intentions.
> >>>
> >>> Lets think about it, anyway. Maybe I've missed some extension yet,
> >>> then that were a chance to add it to the RFC.
> >>>
> >>
> >> thanks' for the feedback so far. I've changed the title now to
> >>
> >> "Removal of dead or not yet PHP7 ported SAPIs and extensions"
> >>
> >>
> >> Also extended the RFC with the information we've got so far - added the
> >>  extensions suggested by Dmitry and the feedback arrived inbetween.
> >>
> >> Please check this again, I plan to start the vote on this next week.
> >>
> > removing extensions is okey, since they can goes to PECL
> >
> > but for SAPIs, where it can go... :<
> >
> They wouldn't have to go anywhere if they were supported well. With SAPIs
> - many of the servers are either very old or don't support the SAPI
> module. Thus porting those SAPIs, even if there were some willing,
> wouldn't make not much sense (well, maybe for the learning fun).
>
> Where should they go - I'd say nowhere. Extensions as well. The removal
> should be tagged as any other RFC patch. Then it can be picked from the
> tag by the persons ready/willing to maintain them, and taken into PECL or
> ported to PHP7 and included again. Depending on the vote results of
> course.
>
> Regards
>
> Anatol
>
>
what laruence is trying to say that we don't really have a syberia for
SAPIs as we have for exts(pecl), but given how these SAPIs are not
maintained/compatible with PHP7, I don't think that it is a blocker problem.
just maybe something we could improve with the future (would also make it
easier to develop SAPIs supporting multiple php versions for example
opcache and phpdbg, currently those are a bit PITA for the maintainers).


-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Removal of dead SAPIs and extensions

[Anatol Belski]

Hi Hui,

On Tue, January 27, 2015 13:32, Xinchen Hui wrote:
> Hey:
>
>
> On Tue, Jan 27, 2015 at 6:23 PM, Anatol Belski 
> wrote:
>
>> Hi,
>>
>>
>> On Mon, January 19, 2015 18:04, Anatol Belski wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> I think the research on
>>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now far
>>> enough to be discussed.
>>>
>>> So far I only could not test sapi/nsapi because it needs a
>>> SunOs/IPlanet.
>>> But independent from that, it'd make sense someone to recheck my
>>> perceptions, or just the areas one is interested in.
>>>
>>> Also hereby I'm calling the authors/maintainers of the corresponding
>>> units to give the info about their intentions.
>>>
>>> Lets think about it, anyway. Maybe I've missed some extension yet,
>>> then that were a chance to add it to the RFC.
>>>
>>
>> thanks' for the feedback so far. I've changed the title now to
>>
>> "Removal of dead or not yet PHP7 ported SAPIs and extensions"
>>
>>
>> Also extended the RFC with the information we've got so far - added the
>>  extensions suggested by Dmitry and the feedback arrived inbetween.
>>
>> Please check this again, I plan to start the vote on this next week.
>>
> removing extensions is okey, since they can goes to PECL
>
> but for SAPIs, where it can go... :<
>
They wouldn't have to go anywhere if they were supported well. With SAPIs
- many of the servers are either very old or don't support the SAPI
module. Thus porting those SAPIs, even if there were some willing,
wouldn't make not much sense (well, maybe for the learning fun).

Where should they go - I'd say nowhere. Extensions as well. The removal
should be tagged as any other RFC patch. Then it can be picked from the
tag by the persons ready/willing to maintain them, and taken into PECL or
ported to PHP7 and included again. Depending on the vote results of
course.

Regards

Anatol











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

Re: [PHP-DEV] VCS Account Request: buhlerax

[Alexandre Pereira Bühler]

Good morning,
I want to help in the projects below
Its create an account on git for me?
Thank you

List:   php-internals
Subject:[PHP-DEV] VCS Account Request: buhlerax
From:   "Alexandre Pereira Bühler" ! br>

Date:   2015-01-11 20:38:28
Message-ID: cvs-account-2916 () php ! net

Good night,
I want a git account to update the web-gtk page 
(http://git.php.net/?p=web/gtk.git;a=summary).
And to continue the development of php-gtk 
(http://git.php.net/?p=php/gtk-src.git;a=summary)
Also to create new manuals for the php-gtk 
(http://git.php.net/?p=doc/gtk.git;a=summary)

Thank you.


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

--
Alexandre Pereira Bühler
Linux User: 397.546

Simão &  Bühler Ltda (Infobrindes)
http://www.simaoebuhler.com.br
alexan...@simaoebuhler.com.br
Telefone: (41) 3039-5428

Infobrindes (Simão &  Bühler Ltda)
Brindes e material promocional.
http://www.infobrindes.com.br
ka...@infobrindes.com.br
Telefone: (41) 3082-8667

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

Re: [PHP-DEV] Re: [RFC][DISCUSSION] Removal of dead SAPIs and extensions

[Xinchen Hui]

Hey:

On Tue, Jan 27, 2015 at 6:23 PM, Anatol Belski  wrote:
> Hi,
>
> On Mon, January 19, 2015 18:04, Anatol Belski wrote:
>> Hi,
>>
>>
>> I think the research on
>> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now far enough
>> to be discussed.
>>
>> So far I only could not test sapi/nsapi because it needs a SunOs/IPlanet.
>>  But independent from that, it'd make sense someone to recheck my
>> perceptions, or just the areas one is interested in.
>>
>> Also hereby I'm calling the authors/maintainers of the corresponding
>> units to give the info about their intentions.
>>
>> Lets think about it, anyway. Maybe I've missed some extension yet, then
>> that were a chance to add it to the RFC.
>>
>
> thanks' for the feedback so far. I've changed the title now to
>
> "Removal of dead or not yet PHP7 ported SAPIs and extensions"
>
> Also extended the RFC with the information we've got so far - added the
> extensions suggested by Dmitry and the feedback arrived inbetween.
>
> Please check this again, I plan to start the vote on this next week.
removing extensions is okey, since they can goes to PECL

but for SAPIs, where it can go... :<

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



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV][RFC] Enable error_handler callback parameters to be passed by reference

[Xinchen Hui]

Hey:

On Tue, Jan 27, 2015 at 11:08 AM, Yasuo Ohgaki  wrote:
> Hi Thomas,
>
> On Tue, Jan 27, 2015 at 11:45 AM, Thomas Bley  wrote:
>
>> Here is the rfc:
>>
>> https://wiki.php.net/rfc/error_handler_callback_parameters_passed_by_reference
>>
>> Thanks to reeze for coding and putting it on the wiki.
>>
>
> It looks good to me.
>
> Future Scope
> set_error_handler() callback might be able to handle E_ERROR to be able to
> append additional information to memory_limit exhaustions (or others).
>
> I really want to catch E_RROR by user defined error handler. The only
> reason why this was disabled is abuse of error handler. We may document
> abuse of error handler with E_ERROR may result in undefined behavior
> including memory leak/crash and allow it.
I feel it's kindof wrong direction.

if you want custom logs, maybe you should use custom logger.

thanks
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net



-- 
Xinchen Hui
@Laruence
http://www.laruence.com/

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

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Matteo Beccati]

On 27/01/2015 12:28, Nikita Popov wrote:

So let the distros solve it ... and allow PHP to still be usable without an
ini file.


So, I install php from sources and (simulating the RFC):

# php -d date.timezone='' -r 'var_dump(@date("Y-m-d H:i:s"));'
string(19) "2015-01-27 11:39:43"
# date
Tue Jan 27 12:39:45 CET 2015

how many people would think "WTF"?

how many "oh right, PHP defaults to UTC unless I change my php.ini"?

how many "my mistake! of course my laptop should use UTC!"?


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] [RFC] Remove the date.timezone warning

[Nikita Popov]

On Tue, Jan 27, 2015 at 12:22 PM, Derick Rethans  wrote:

> > Everything else being there to simplify implementation of websites
> > which anticipate a geographically narrow target audience?
> >
> > Anyway, I absolutely don't get why out of all the hundreds of ini
> > settings that we have, some of them vastly more important than setting
> > a timezone (like display_errors or error_reporting - newbies trip over
> > these much more often), the only one we actually require you to
> > specify is date.timezone. That seems very disproportional.
>
> But easily solved by distributions. Debian could easily stick the
> following in a post-install hook to fix it:
>
> echo -n 'date.timezone=' > /etc/php/config.d/date.ini
> cat /etc/timezone >> /etc/php/config.d/date.ini
>

So let the distros solve it ... and allow PHP to still be usable without an
ini file.

Nikita

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Derick Rethans]

On Tue, 27 Jan 2015, Nikita Popov wrote:

> On Tue, Jan 27, 2015 at 7:40 AM, Matteo Beccati  wrote:
> 
> > On 27/01/2015 01:34, Bob Weinand wrote:
> >
> >> Hey,
> >>
> >> I'd like to request removal of the date.timezone warning.
> >>
> >> Here is the RFC:
> >> https://wiki.php.net/rfc/date.timezone_warning_removal <
> >> https://wiki.php.net/rfc/date.timezone_warning_removal>
> >>
> >
> > The warning is certainly annoying, but making it default to UTC or a wrong
> > timezone because the right one can't be guessed is a major WTF.
> >
> > Ideally the initial setup of php.ini could be handled by the distro
> > package system, if it's not already?
> 
> Isn't UTC the only "right" default timezone there is for a server?

This is not a server setting, this is a PHP application level setting. 
And there, UTC is not the "right" default choice.

> Everything else being there to simplify implementation of websites 
> which anticipate a geographically narrow target audience?
> 
> Anyway, I absolutely don't get why out of all the hundreds of ini 
> settings that we have, some of them vastly more important than setting 
> a timezone (like display_errors or error_reporting - newbies trip over 
> these much more often), the only one we actually require you to 
> specify is date.timezone. That seems very disproportional.

But easily solved by distributions. Debian could easily stick the 
following in a post-install hook to fix it:

echo -n 'date.timezone=' > /etc/php/config.d/date.ini
cat /etc/timezone >> /etc/php/config.d/date.ini

cheers,
Derick

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

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Derick Rethans]

On Tue, 27 Jan 2015, Florian Anderiasch wrote:

> On 01/27/2015 07:40 AM, Matteo Beccati wrote:
> > On 27/01/2015 01:34, Bob Weinand wrote:
> >>
> >> I'd like to request removal of the date.timezone warning.
> >>
> >> Here is the RFC: 
> >> https://wiki.php.net/rfc/date.timezone_warning_removal 
> >> 
> > 
> > The warning is certainly annoying, but making it default to UTC or a 
> > wrong timezone because the right one can't be guessed is a major 
> > WTF.
> 
> I don't see how this would be a *major* WTF. Maybe a minor one as PHP 
> didn't have to have a default one, so maybe an oddity.
> 
> I'd argue that it's about setting a good example, UTC is the only sane 
> default for server software unless you know what you're doing.

They only sane default is no default, so that users have to make a 
choice as what to set it too. That gives the least amount of surprise.

> We're always arguing about removing options from php.ini

I think the argument is often about *not adding options*. Which is 
different from removing options.

cheers,
Derick

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

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Derick Rethans]

On Tue, 27 Jan 2015, Yasuo Ohgaki wrote:

> While I can understand the reason behind opposition, but current web 
> is not bounded to local country. Most applications today logs time 
> using UTC and time stamp is converted whatever local time as needed, 
> isn't it? Of course, it depends on application though. Having UTC as 
> the default makes sense to me.

But not to me. Here in the UK, it would be right during winter, but then 
suddenly in summer my time would be wrong! It would be quite a WTF 
factor, and it's best fixed by having people actively make a choice on 
which timezone they want to use.

> Besides time management best practice, users have learned enough, 
> haven't them?

You'd be surprised how many people get timezones and time management 
wrong. I've given several talks about this and any time many attendees 
are surprised by the complexity.

cheers,
Derick
-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

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

Re: [PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

[Yasuo Ohgaki]

Hi Martin,

On Tue, Jan 27, 2015 at 5:41 PM, Martin Keckeis 
wrote:

> This would also deprecate following functions?
> http://php.net/manual/en/function.gc-enable.php
> http://php.net/manual/en/function.set-include-path.php
> http://php.net/manual/en/function.set-time-limit.php
> http://php.net/manual/en/function.error-reporting.php
>

I suppose so, but we may have some exceptions.
There will be many others. I haven't count all of them yet.
Other examples are

http://php.net/manual/en/function.mb-internal-encoding.php
http://php.net/manual/en/function.mb-detect-order.php
http://php.net/manual/en/function.mb-language.php
http://php.net/manual/en/function.iconv-set-encoding.php

mb_internal_encoding() and iconv_set_encoding() will be deprecated
functions, though.
Global encoding setting should be used as the RFC that removes module own
encoding
setting passed. I'll make them to set/get global encoding setting as well
as add E_DEPRECATED
errors.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] Discussion for RFC: Set appropriate/better defaults.

[Lester Caine]

On 27/01/15 10:40, Yasuo Ohgaki wrote:
> I suppose RFC 1738 user is using urldecode() as rawurldecodoe() cannot
> decode '+'.  So you and your users wouldn't have BC issues.
> 
> Please let me know if I'm missing something.

It's one of those check boxes on my crib sheet for converting legacy
sites to 5.4 ... I've had niggles on occasions when a '+' has got lost
in the code and tracking why can be a problem which is why I commented.
It's the changes in these areas which can cause hair pulling because
some other 'bodge' has been used in the past :(

-- 
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] Re: PHP7 Homework for everyone reading this list

[Lester Caine]

On 27/01/15 10:41, Jan Ehrhardt wrote:
>> We surely need a list of the extensions that have been ported to PHP7
>> >and where to find them.
> And now imagick introduced a branch 'phpseven'...

I've not yet managed to compile even the new imagick but I have been
doing my homework ...

http://php7.lsces.org.uk/ is running with php_interbase, while the base
http://lsces.org.uk/ is running via PHP5.4 Same code base, just two
different php-fpm compiles so the server stats on the right are a direct
comparison of performance.

Underlying framework is ADOdb, Smarty, Firebird and Nginx with a colour
version of Bootstrap3 as the base theme structure.

php_interbase is compiling with a number of warnings, but much less that
imagick and some of the other extensions.
http://php7.lsces.org.uk/phpinfo.php giving the breakdown.

-- 
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] Re: Discussion for RFC: Set appropriate/better defaults.

[Yasuo Ohgaki]

Hi Ferenc,

On Tue, Jan 27, 2015 at 6:44 PM, Ferenc Kovacs  wrote:

> On Tue, Jan 27, 2015 at 3:35 AM, Yasuo Ohgaki  wrote:
>
>> Hi all,
>>
>> On Tue, Jan 27, 2015 at 11:06 AM, Yasuo Ohgaki 
>> wrote:
>>
>> >  - session.hash_function=1 : Use SHA1 rather than MD5
>>
>>
>> I realized that we should remove hashing for better performance.
>>
>> Since session ID is generated from crypt secure RNG (/dev/urandom by
>> default),
>> simply converting the data into text is enough. Hashing is _slow_.
>>
>> Any comments?
>>
>
> on the contrary, both sha1 and md5 is super fast, so I don't think that is
> a good argument.
> and if you remove the hashing there will be no known length for the
> session id, and sooner or later people will screw themselves when bumping
> into some limit or getting their session id truncated (be that a cookie max
> length or a db field).
>

MD5 and SHA1 is reasonably fast. However, when I implemented
session.lazy_write
I found hashing is spoiling performance with simple script benchmark.

A lot of session IDs may be generated with browsers that do not
support/enable cookie.
Many sites can ignore the overhead, but busy sites get benefits from raw
session ID.
It may be small, but it uses less CPU cycle for sure. We may set long
enough fixed
length ID with raw session ID.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Lester Caine]

On 27/01/15 10:24, Yasuo Ohgaki wrote:
> While I can understand the reason behind opposition, but current web is not
> bounded to local country. Most applications today logs time using UTC and
> time stamp is converted whatever local time as needed, isn't it? Of course,
> it depends on application though. Having UTC as the default makes sense
> to me.
> 
> Besides time management best practice, users have learned enough,
> haven't them?

Best practice when working cross timezones is to store all information
as UTC and display using a clients local timezone. It all falls apart
when one starts trying to put into practice. Most 'local' PHP
installations will be run on machines with their real time clock set to
local time. If they are accessed by remote clients, the browsers tz
offset will be used in the absence of a real DST correct timezone. Many
sites will be using 'seconds' as the time base without knowing if leap
seconds are included or not and wondering why things are not quite right.

So basically defaulting the majority of PHP installs to UTC is simply
wrong, if only because we can't even agree on how UTC is calculated.

It was hoped that the new tzdist working group might bring a bit of
sanity, but it seems providing a standard to work to is not what any of
these working groups is chartered to provide - just rules so that
everybody can carry on doing their own thing :(

-- 
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] Remove the date.timezone warning

[Nikita Popov]

On Tue, Jan 27, 2015 at 7:40 AM, Matteo Beccati  wrote:

> On 27/01/2015 01:34, Bob Weinand wrote:
>
>> Hey,
>>
>> I'd like to request removal of the date.timezone warning.
>>
>> Here is the RFC:
>> https://wiki.php.net/rfc/date.timezone_warning_removal <
>> https://wiki.php.net/rfc/date.timezone_warning_removal>
>>
>
> The warning is certainly annoying, but making it default to UTC or a wrong
> timezone because the right one can't be guessed is a major WTF.
>
> Ideally the initial setup of php.ini could be handled by the distro
> package system, if it's not already?
>
>
> Cheers


Isn't UTC the only "right" default timezone there is for a server?
Everything else being there to simplify implementation of websites which
anticipate a geographically narrow target audience?

Anyway, I absolutely don't get why out of all the hundreds of ini settings
that we have, some of them vastly more important than setting a timezone
(like display_errors or error_reporting - newbies trip over these much more
often), the only one we actually require you to specify is date.timezone.
That seems very disproportional.

Nikita

Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list

[Jan Ehrhardt]

Jan Ehrhardt in php.internals (Mon, 26 Jan 2015 00:12:11 +0100):
>Michael Wallner in php.internals (Sun, 25 Jan 2015 18:32:18 +0100):
>>On 23/01/15 22:18, Jan Ehrhardt wrote:
>>> Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400):
 "master" branch.
>>> 
>>> propro, raphf and pecl_http do not compile with the master branch.
>>> You'll have to checkout the phpng branch. These extensions did compile
>>> and load:
>>> https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm
>>
>>Dmitry is sort of right, actually. The plan is to merge phpng back into
>>master of course, and do legacy releases out of the R_2_* branches.
>
>But then we have the problem the other way around: you will have to
>checkout special branches to compile for 5.x. Will that be 'phpog'?
>Or is your plan to make a special version for PHP 5.x?
>
>I noticed Joe Watkins has a 'five' branch besides master in pthreads.
>Just guessing: is the 'five' for PHP 5.x and the master for PHP7?
>
>We surely need a list of the extensions that have been ported to PHP7
>and where to find them.

And now imagick introduced a branch 'phpseven'...

Jan

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

Re: [PHP-DEV] Discussion for RFC: Set appropriate/better defaults.

[Yasuo Ohgaki]

Hi Lester,

On Tue, Jan 27, 2015 at 6:19 PM, Lester Caine  wrote:

> On 27/01/15 02:06, Yasuo Ohgaki wrote:
> > Another example is http_build_query(). It should escape ' ' as '%20' by
> > default, not '+'.
>
> The quick response is probably 'why', but I probably know the answer,
> becuase some standard has changed. The problem with this one is that
> using a '+' sign when encoding page names is so much easier to read than
> $20, and many of the systems I'm still supporting have had as a standard
> since PHP4 days. Editing stored data to cope with that change is not as
> easy as changing code, so what is easy to say in an RFC can have a lot
> more deeper implications!


I should have mentioned that urldecode() supports both '+' and '%20'.
Therefore, there is no compatibility issue as long as stored data is
decoded by urldecode().

http://3v4l.org/KcW4V

I suppose RFC 1738 user is using urldecode() as rawurldecodoe() cannot
decode '+'.  So you and your users wouldn't have BC issues.

Please let me know if I'm missing something.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Florian Anderiasch]

On 01/27/2015 07:40 AM, Matteo Beccati wrote:
> On 27/01/2015 01:34, Bob Weinand wrote:
>> Hey,
>>
>> I'd like to request removal of the date.timezone warning.
>>
>> Here is the RFC:
>> https://wiki.php.net/rfc/date.timezone_warning_removal
>> 
> 
> The warning is certainly annoying, but making it default to UTC or a
> wrong timezone because the right one can't be guessed is a major WTF.

I don't see how this would be a *major* WTF. Maybe a minor one as PHP
didn't have to have a default one, so maybe an oddity.

I'd argue that it's about setting a good example, UTC is the only sane
default for server software unless you know what you're doing.

We're always arguing about removing options from php.ini and while it
isn't about *removal* here I don't see why there can't be a sane default.

I just reread the RFC, so I'm -1 on next minor version, but +1 on PHP 7.

~Florian

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

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Yasuo Ohgaki]

Hi all,

While I can understand the reason behind opposition, but current web is not
bounded to local country. Most applications today logs time using UTC and
time stamp is converted whatever local time as needed, isn't it? Of course,
it depends on application though. Having UTC as the default makes sense
to me.

Besides time management best practice, users have learned enough,
haven't them?

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

[PHP-DEV] Re: [RFC][DISCUSSION] Removal of dead SAPIs and extensions

[Anatol Belski]

Hi,

On Mon, January 19, 2015 18:04, Anatol Belski wrote:
> Hi,
>
>
> I think the research on
> https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts is now far enough
> to be discussed.
>
> So far I only could not test sapi/nsapi because it needs a SunOs/IPlanet.
>  But independent from that, it'd make sense someone to recheck my
> perceptions, or just the areas one is interested in.
>
> Also hereby I'm calling the authors/maintainers of the corresponding
> units to give the info about their intentions.
>
> Lets think about it, anyway. Maybe I've missed some extension yet, then
> that were a chance to add it to the RFC.
>

thanks' for the feedback so far. I've changed the title now to

"Removal of dead or not yet PHP7 ported SAPIs and extensions"

Also extended the RFC with the information we've got so far - added the
extensions suggested by Dmitry and the feedback arrived inbetween.

Please check this again, I plan to start the vote on this next week.

Thanks.

Anatol

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

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[Lester Caine]

On 27/01/15 09:56, Sebastian Bergmann wrote:
> Am 27.01.2015 um 10:52 schrieb Lester Caine:
>> > On 27/01/15 09:42, Sebastian Bergmann wrote:
>>> >> PEAR has served its purpose, it provided value for the PHP
>>> >> ecosystem for a time, but now it should be retired.
>> > 
>> > So what happens to http://pear.php.net ?
>  That is a good question. I think that PEAR should stop being an
>  "official" PHP project. And following that thought pear.php.net
>  should be moved to a different domain. The same thing happened
>  with Smarty which used to be hosted at smarty.php.net.

Well perhaps you should check .. http://www.smarty.net/ has been the
home of smarty for a long time. That is another project that I rely on
extensively, just as key functions from PEAR are ... and we would
perhaps still have a usable phpdocumentor as well if that had not been
farmed off.

And had ADOdb been taken more seriously we would not have the mess that
is PDO today. Is now the time for a different home for 'realPHP' ?

-- 
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] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[Sebastian Bergmann]

Am 27.01.2015 um 10:52 schrieb Lester Caine:
> On 27/01/15 09:42, Sebastian Bergmann wrote:
>> PEAR has served its purpose, it provided value for the PHP
>> ecosystem for a time, but now it should be retired.
> 
> So what happens to http://pear.php.net ?

 That is a good question. I think that PEAR should stop being an
 "official" PHP project. And following that thought pear.php.net
 should be moved to a different domain. The same thing happened
 with Smarty which used to be hosted at smarty.php.net.

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

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[Lester Caine]

On 27/01/15 09:42, Sebastian Bergmann wrote:
> PEAR has served its purpose, it provided value for the PHP
>  ecosystem for a time, but now it should be retired.

So what happens to http://pear.php.net ?

-- 
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] Re: Discussion for RFC: Set appropriate/better defaults.

[Ferenc Kovacs]

On Tue, Jan 27, 2015 at 3:35 AM, Yasuo Ohgaki  wrote:

> Hi all,
>
> On Tue, Jan 27, 2015 at 11:06 AM, Yasuo Ohgaki  wrote:
>
> >  - session.hash_function=1 : Use SHA1 rather than MD5
>
>
> I realized that we should remove hashing for better performance.
>
> Since session ID is generated from crypt secure RNG (/dev/urandom by
> default),
> simply converting the data into text is enough. Hashing is _slow_.
>
> Any comments?
>

on the contrary, both sha1 and md5 is super fast, so I don't think that is
a good argument.
and if you remove the hashing there will be no known length for the session
id, and sooner or later people will screw themselves when bumping into some
limit or getting their session id truncated (be that a cookie max length or
a db field).

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[Sebastian Bergmann]

Am 27.01.2015 um 10:00 schrieb Lester Caine:
> composer has not even managed to get added to some distributions yet

 This is not about PEAR Installer vs. Composer or something else. This
 is about the PHP core getting untangled from third-party software that
 impedes the development of PHP itself.

 As a sidenote, to most (if not all) PHP developers that I have met
 since PHP 5 came out there is nothing of value in PEAR (as in the
 packages hosted on pear.php.net). These packages became obsolete the
 moment the PEAR Installer supported channels other than pear.php.net.
 Now that most (if not all) commonly used libraries, components,
 frameworks, tools, etc. no longer (exclusively) offer their releases
 as PEAR packages, the PEAR Installer has become irrelevant. It should
 no longer be bundled with PHP (neither should any other package
 manager). PEAR has served its purpose, it provided value for the PHP
 ecosystem for a time, but now it should be retired.

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

Re: [PHP-DEV] [PATCH] Fix potential int overflow in date extension.

[Derick Rethans]

On Tue, 20 Jan 2015, Joshua Rogers wrote:

> On 20/01/15 06:15, Joshua Rogers wrote:
> > --
> >  ext/date/lib/tm2unixtime.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> Somebody please take a look at /ext/date/lib/parse_tz.c too:
> 
> 438timelib_sll timelib_get_current_offset(timelib_time *t)
> [..]
> 446return (t->z + t->dst) * -60;
> Should that be cast timelib_sll too?
> 
> I think perhaps the function should be an int, seeing as it looks like
> the result should be negative. Somebody please check.

The result can be either positive or negative as t->z can be both. 
timelib_sll seems right though, as it stands for "long long signed".
I don't quite see how this can overflow though - as t->z and t->dst come 
just close to 10 (and it's internal provided data).

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine

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

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Lester Caine]

On 27/01/15 07:11, Sebastian Bergmann wrote:
>> The warning is certainly annoying, but making it default to UTC or a wrong
>> > timezone because the right one can't be guessed is a major WTF.
>  Couldn't agree more; -1 for removing the warning.

Ditto
The warning is a pain but only where the timezone setting is not
ACTUALLY being handled by some other process.

-- 
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] Remove the date.timezone warning

[Derick Rethans]

On Tue, 27 Jan 2015, Matteo Beccati wrote:

> On 27/01/2015 01:34, Bob Weinand wrote:
> > 
> > I'd like to request removal of the date.timezone warning.
> > 
> > Here is the RFC:
> > https://wiki.php.net/rfc/date.timezone_warning_removal
> > 
> 
> The warning is certainly annoying, but making it default to UTC or a 
> wrong timezone because the right one can't be guessed is a major WTF.

Exactly.

> Ideally the initial setup of php.ini could be handled by the distro 
> package system, if it's not already?

None of the distros do it well enough. Some even invent stupid stuff 
like "System.Localtime" as their timezone identifier, while they really 
should just figure out what timezone is configured for the system, and 
put that in a datetime.ini setting in their php.d/ dir or whatever they 
use.

cheers,
Derick

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

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Derick Rethans]

On Tue, 27 Jan 2015, Pierre Joye wrote:

> On Jan 27, 2015 11:25 AM, "Yasuo Ohgaki"  wrote:
> >
> > On Tue, Jan 27, 2015 at 12:56 PM, Kalle Sommer Nielsen 
> > wrote:
> >
> > > I think the warning is fair as it is, if it is annoying for small 
> > > use cases like on the CLI then simply: php -d date.timezone=UTC -r 
> > > "echo date('H:i:s');" or the dirty way by using the silent 
> > > operator. It used to be a notice prior 5.3 I think or something.
> > >
> > > While I do agree that most applications should be using UTC, which 
> > > should be set by default we sometimes need to tell userland the 
> > > hard way how things work, and/or what they should care about, like 
> > > the E_WARNING, E_CORE_ERROR, E_DEPRECATED for old php.ini 
> > > settings.
> > >
> > > -1 for removing it from my side.
> >
> > I can understand your argument. Perhaps, we may reconsider to 
> > introduce E_DEBUG/E_USER_DEBUG for these purposes. There are many 
> > functions, e.g. file related, that I feel E_WARNING is excessive.
> 
> I do not have a strong opinion on that. So keep it or make it UTC 
> default but please do not add yet another warning/notice/whatever.
> 
> Also, setting a timezone is not about Dev or other fancy tasks, it is 
> about making datetime processing right.
> 
> If anything I would enforce the default at configure/build time. So it 
> at least gets the correct one from a host point of view.

That would be nice, but it's unfortuntately not really possible. You 
can't find out what timezone the OS is using in a portable way. Not even 
among different linux distributions, let alone having Windows in the 
mix. We tried this before, and because it caused so many issues, the 
current warning was added (instead of trying to guess a timezone).

cheers,
Derick

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

Re: [PHP-DEV] [RFC] Remove the date.timezone warning

[Derick Rethans]

On Tue, 27 Jan 2015, Bob Weinand wrote:

> I'd like to request removal of the date.timezone warning.
> 
> Here is the RFC:
> https://wiki.php.net/rfc/date.timezone_warning_removal 
> 

Absolutely not.

cheers,
Derick

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

Re: [PHP-DEV] Discussion for RFC: Set appropriate/better defaults.

[Lester Caine]

On 27/01/15 02:06, Yasuo Ohgaki wrote:
> Another example is http_build_query(). It should escape ' ' as '%20' by
> default, not '+'.

The quick response is probably 'why', but I probably know the answer,
becuase some standard has changed. The problem with this one is that
using a '+' sign when encoding page names is so much easier to read than
$20, and many of the systems I'm still supporting have had as a standard
since PHP4 days. Editing stored data to cope with that change is not as
easy as changing code, so what is easy to say in an RFC can have a lot
more deeper implications!

-- 
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] Vote results for default ctors RFC

[Tony Marston]

"Stanislav Malyshev"  wrote in message news:54c533a4.3090...@gmail.com...


Hi!


2) I don't see a flood of people coming to the mailing list complaining
about this feature, so I'm not compelled to want it in the language.


That's true for most features, and that's normal - in fact, I can't
remember a feature or a fix where we had a flood of people coming to the
list.

And a pretty strange reason to refuse a new thing - nobody develops new
things by sitting and waiting for people to complain enough about not
having this exact thing. Apple didn't make iPhone because a lot of
people came to them and asked them to make an iPhone. Of course, I'm not
comparing my little RFC to a technological breakthrough, but the whole
premise that new things can be made only when enough people complained
about not having it sounds wrong to me.


Well said.

One way of gauging if people have problems which would be solved by an RFC 
such as this would be to look in the bug database. A quick search using 
"constructor" yielded over 300 results. I didn't examine all of them, but 
several would have been solved with this RFC.


Introducing something only when enough people have complained about not 
having it is not always the right way to go. When the motor car was invented 
it was not because there was a demand for motor cars. Everybody was using 
horses at the time, and if you asked them what they wanted they would have 
answered "faster horses".


--
Tony Marston


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

Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[Lester Caine]

On 27/01/15 05:03, Pierre Joye wrote:
>>> That is not easy. Certainly not as easy as just "pecl install
>>> > > " anything similar short of that is not sufficient.
>> >
>> > pickle install 
>> >
>> > Or if your composer based project needs an ext, composer will do that for
> you.
>> >
>> > Easy enough?
> I forgot to mention that you do not need composer to run or install pickle.
> Just grab the phar. Fully independent and stand alone.

But why do we need more and more third party packages to make something
that has been happily working for years continue to work? Just grab this
that or the other because we can't be bothered to include this or that
function these days ...

It is bad enough that we have so many different 'enhanced bundles' and
it would be nice to retain a base system that one can simply download in
one hit. PEAR has a vast library of useful material that will all have
to be tidied up to work with PHP7, but throwing awway the installer just
becuse it's not getting as much care as other parts of the
infrastructure is not the right approach.

composer has not even managed to get added to some distributions yet ...
it's not part of SUSE ... so one HAS to have an internet connection to
be able to access it. I'm I going to have to start using pickle as well?
I've not had any need for it so far ...

-- 
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] Re: [PHP-CVS] com php-src: Revert "Disable PEAR by default": configure.in

[Tony Marston]

"Sebastian Bergmann"  wrote in message news:54c65325.3030...@php.net...


Am 26.01.2015 um 13:56 schrieb Lester Caine:

how would YOU propose to replace it?


I am not talking about replacing but removing.


Bad idea. PEAR is still being used, so dropping it without providing an 
alternative would cause nothing but grief for large numbers of users. Or 
don't you care how much grief you cause?


--
Tony Marston


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

Re: [PHP-DEV] Re: Deprecating all INI set/get functions and use ini_set/get()

[Martin Keckeis]

Hello,

2015-01-27 3:20 GMT+01:00 Yasuo Ohgaki :

> Hi all,
>
> On Sun, Jan 25, 2015 at 9:29 AM, Yasuo Ohgaki  wrote:
>
> > I would like to propose INI set/get function deprecation, raise
> > E_DEPRECATED,
> > and make PHP_INI_MH() use the CODING_STANDARDS.
> >
> > For example, session module has following INI set/get functions
> >
> >  - http://php.net/manual/en/function.session-save-path.php
> >  - http://php.net/manual/en/function.session-module-name.php
> >  - http://php.net/manual/en/function.session-cache-expire.php
> >  - http://php.net/manual/en/function.session-cache-limiter.php
> >  - http://php.net/manual/en/function.session-name.php
> >
> > There are 5 PHP functions for session module alone. Some of them include
> > runtime check, but
> > these checks can be done with PHP_INI_MH() by using state parameter. In
> > fact, runtime
> > check should be done in PHP_INI_MH() to avoid bugs.
> >
> > Use of ini_set/get() has following pros and cons
> >
> > Pros
> >  - Less API, hence simpler API.
> >  - Modules will be less buggy.
> > i.e. PHP_INI_MH() must handle "state" properly, but it tends to be
> > forgotten, 3rd party modules especially.
> >  - Consistent coding style/API across modules, both internal and script.
> >  - Reduced documentations. INI descriptions are only in INI section.
> >  - Less documentations, hence less documentation bugs.
> >  - Better documentation. All user needs to know will be in INI section.
> >  - Awareness of INI setting use. Users are better to know they are using
> > INI. i.e. All INI values has the same limitations,
> > INI_SYSTEM/INI_PERDIR/INI_USER, stage limitations if any.
> >  - (Please point it out more advantages)
> >
> > Cons
> >  - Existing code modifications. (It's E_DEPRECATED. User may ignore.)
> >  - (Please point it out more disadvantages)
> >
> > Comments are appreciated.
> >
> > Regards,
> >
> > P.S. Enum for PHP_INI_MH() "stage" parameter type is better in PHP7. IMO.
> >
>
> Since there isn't comment, I guess everyone on this list agree this
> proposal.
>
> Shall I start writing this RFC?
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>


This would also deprecate following functions?
http://php.net/manual/en/function.gc-enable.php
http://php.net/manual/en/function.set-include-path.php
http://php.net/manual/en/function.set-time-limit.php
http://php.net/manual/en/function.error-reporting.php