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

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,

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

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. Dep

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

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, functio

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

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 e

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

>> 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 a

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

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('displa

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

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 =

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

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

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

> 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://

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

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

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

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

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

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 i

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

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

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

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

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

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.

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

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 ty

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

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 behav

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

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. Th

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

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 in

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

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,

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

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 th

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

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 y

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

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 sca

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

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 unani

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

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 te

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

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 th

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

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 > >

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

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

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

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 m

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

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

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

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 > > clo

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

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

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

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 goi

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

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)

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

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 line

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

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 lef

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

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. >

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

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 m

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

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

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

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 b

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

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’

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

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/wor

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

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

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

> 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,

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

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 p

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

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, >>

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

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: >

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

> 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

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

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, >> >> >> >

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

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, >

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

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_sa

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

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

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

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 sap

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

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.

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

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

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

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

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

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

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

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 >

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

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 applic

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

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/ma

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

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

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

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.ls

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

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 r

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

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

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

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_w

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

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_

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

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 stan

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

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 >>

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

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 make

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

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

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

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 ht

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

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

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

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=

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

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

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

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.

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

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(t

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

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 timezo

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

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 > >

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

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 dat

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

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 R

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

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 enco

Re: [PHP-DEV] [RFC] Vote results for default ctors RFC

"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 remem

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

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 eno

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

"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

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

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 f