[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/mysqlnd mysqlnd_result.c

On 2009-06-23, "David Soria Parra" wrote: > dsp Tue Jun 23 14:15:28 2009 UTC > > Modified files: (Branch: PHP_5_3) > /php-src/ext/mysqlnd mysqlnd_result.c > Log: > MFH: Fix bug #48644 mysqlnd does not compile with > '--enable-mysqlnd-threading' > > > h

[PHP-DEV] Re: cvs: php-src(PHP_5_3) / UPGRADING

Hi Greg 2009/5/7 Greg Beaver : > > FYI, use has been a reserved keyword since the initial commit of > zend_language_parser.y in October of 2000 :) (see > http://cvs.php.net/viewvc.cgi/Zend/zend_language_parser.y?revision=1.1&view=markup) Thanks, I never seen it in any use plus the documentation a

[PHP-DEV] Re: cvs: php-src(PHP_5_3) / UPGRADING

Kalle Sommer Nielsen wrote: > kalle Thu May 7 03:14:07 2009 UTC > > Modified files: (Branch: PHP_5_3) > /php-src UPGRADING > Log: > * use is a reserved keyword Hi, FYI, use has been a reserved keyword since the initial commit of zend_language_parser.y in October

[PHP-DEV] Re: [ZEND-ENGINE-CVS] Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_

Lukas Kahwe Smith wrote: On 16.03.2009, at 16:49, Pierre Joye wrote: 2009/3/16 Johannes Schlüter : Hi, On Mon, 2009-03-16 at 09:52 +, "Dmitry Stogov" wrote: Log: Fixed bug #47664 (get_class returns NULL instead of FALSE) [...] @@ -716,7 +716,7 @@ int dup; if (zend_p

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

On 16.03.2009, at 16:49, Pierre Joye wrote: 2009/3/16 Johannes Schlüter : Hi, On Mon, 2009-03-16 at 09:52 +, "Dmitry Stogov" wrote: Log: Fixed bug #47664 (get_class returns NULL instead of FALSE) [...] @@ -716,7 +716,7 @@ int dup; if (zend_parse_parameters(ZEND_NUM_A

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variation

Pierre Joye wrote: The new parsing API and the strictness of this "return NULL" rule is new and arguable. As it is not that important (work 'round is easy), I tend to prefer to minimize the wtf instead of being too strict. This "new parsing API" is not so new, dammit. :) It's a few years old by

[PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variation_

Hi Johannes, Johannes Schlüter wrote: Hi, On Mon, 2009-03-16 at 09:52 +, "Dmitry Stogov" wrote: Log: Fixed bug #47664 (get_class returns NULL instead of FALSE) [...] @@ -716,7 +716,7 @@ int dup; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|o", &obj) == FAIL

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

Hi! Is this not the case for NULL? Null means "no value", which is relatively rarely legitimate return of the function (most of the functions legitimately returning null AFAIK are value-manipulating functions i.e. they can return any type of value). -- Stanislav Malyshev, Zend Software Arch

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

On Mon, Mar 16, 2009 at 6:46 PM, Stanislav Malyshev wrote: > Hi! > >> Why do functions return NULL? (I know the technical answer, obviously, >> I'm interested in the design decision). If FALSE is the error >> condition, whats the point in a separate NULL error condition? > > Because false is not a

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

Hi! Why do functions return NULL? (I know the technical answer, obviously, I'm interested in the design decision). If FALSE is the error condition, whats the point in a separate NULL error condition? Because false is not an error condition. It's a legitimate value, which can be normal answer

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

2009/3/16 Johannes Schlüter : > On Mon, 2009-03-16 at 18:41 +0100, Pierre Joye wrote: >> >> Usually we return NULL in case parameter parsing fails, this is >> >> documented like this: > The documentation is just like with other functions returning NULL for > param parsing and false for other error

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

On Mon, 2009-03-16 at 18:41 +0100, Pierre Joye wrote: > >> Usually we return NULL in case parameter parsing fails, this is > >> documented like this: > > > > If all other functions return NULL with wrong args, why should get_class > > return false? Is there any value in it besides the fact that doc

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

On Mon, Mar 16, 2009 at 6:49 PM, Stanislav Malyshev wrote: > Hi! > >> The new parsing API and the strictness of this "return NULL" rule is >> new and arguable. As it is not that important (work 'round is easy), I >> tend to prefer to minimize the wtf instead of being too strict. > > Minimizing the

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

Hi! The new parsing API and the strictness of this "return NULL" rule is new and arguable. As it is not that important (work 'round is easy), I tend to prefer to minimize the wtf instead of being too strict. Minimizing the WTF may also mean standardizing exception handling - i.e. knowing what

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

On Mon, Mar 16, 2009 at 6:43 PM, Stanislav Malyshev wrote: > Hi! > >>> If all other functions return NULL with wrong args, why should get_class >>> return false? Is there any value in it besides the fact that docs say so? >> >> The main reason is the documentation. It introduces a useless BC break

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

Hi! If all other functions return NULL with wrong args, why should get_class return false? Is there any value in it besides the fact that docs say so? The main reason is the documentation. It introduces a useless BC break which was reported in #47664. Well, sometimes a bug is a bug and we ca

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

2009/3/16 Stanislav Malyshev : > Hi! > >>> Log: >>>  Fixed bug #47664 (get_class returns NULL instead of FALSE) >> >> [...] >>> >>> @@ -716,7 +716,7 @@ >>>        int dup; >>>          if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|o", >>> &obj) == FAILURE) { >>> -               return; >>>

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variat

Hi! Log: Fixed bug #47664 (get_class returns NULL instead of FALSE) [...] @@ -716,7 +716,7 @@ int dup; if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|o", &obj) == FAILURE) { - return; + RETURN_FALSE; } Usually we return NULL in

Re: [PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variati

2009/3/16 Johannes Schlüter : > Hi, > > On Mon, 2009-03-16 at 09:52 +, "Dmitry Stogov" wrote: >> Log: >>   Fixed bug #47664 (get_class returns NULL instead of FALSE) > [...] >> @@ -716,7 +716,7 @@ >>         int dup; >> >>         if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|o", >> &o

[PHP-DEV] Re: cvs: ZendEngine2 / zend_builtin_functions.c /tests 009.phpt php-src/ext/reflection/tests 027.phpt php-src/ext/standard/tests/class_object get_class_error_001.phpt get_class_variation_

Hi, On Mon, 2009-03-16 at 09:52 +, "Dmitry Stogov" wrote: > Log: > Fixed bug #47664 (get_class returns NULL instead of FALSE) [...] > @@ -716,7 +716,7 @@ > int dup; > > if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "|o", > &obj) == FAILURE) { > - return

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/standard/tests/general_functions phpinfo.phpt

zoe wrote: > >> Hi Zoe, >> >> Is there documentation on this change? > Hi Greg - you mean the change I made to the phpinfo.phpt test? If so I > changed it because it was failing and should not have been. Or do you > mean changes to run-tests.php options? I meant to run-tests.php. >> I'm finding i

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/standard/tests/general_functions phpinfo.phpt

Hi Zoe, Is there documentation on this change? Hi Greg - you mean the change I made to the phpinfo.phpt test? If so I changed it because it was failing and should not have been. Or do you mean changes to run-tests.php options? I'm finding it a little bit arbitrary that run-tests keeps chan

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/standard/tests/general_functions phpinfo.phpt

Zoe Slattery wrote: > zoe Wed Mar 4 10:23:01 2009 UTC > > Modified files: (Branch: PHP_5_3) > /php-src/ext/standard/tests/general_functions phpinfo.phpt > Log: > fixed test > > http://cvs.php.net/viewvc.cgi/php-src/ext/standard/tests/general_functions/phpi

[PHP-DEV] Re: cvs: php-src /main output.c /tests/output bug46900.phpt bug46903.phpt ob_014.phpt ob_015.phpt ob_start_basic_002.phpt ob_start_basic_004.phpt

2009/2/15 Michael Wallner : > Robin Fernandes wrote: >> >> robinf Sun Dec 28 19:50:58 2008 UTC >> >> Added files:/php-src/tests/output bug46903.phpt >> bug46900.phpt >> Modified files: /php-src/tests/output >> ob_start_basic_004.phpt >> ob_star

[PHP-DEV] Re: cvs: php-src /main output.c /tests/output bug46900.phpt bug46903.phpt ob_014.phpt ob_015.phpt ob_start_basic_002.phpt ob_start_basic_004.phpt

Robin Fernandes wrote: robinf Sun Dec 28 19:50:58 2008 UTC Added files: /php-src/tests/output bug46903.phpt bug46900.phpt Modified files: /php-src/tests/output ob_start_basic_004.phpt ob_start_basic_002.phpt ob_015.

Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_build.h zend_extensions.c zend_extensions.h zend_modules.h php-src/ext/standard dl.c info.c php-src/win32/build config.w32

Hi! Is current CVS ok now? Yes, it is. Johannes fixed it. OK, thanks Johannes :) -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.

Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_build.h zend_extensions.c zend_extensions.h zend_modules.h php-src/ext/standard dl.c info.c php-src/win32/build config.w32

Stanislav Malyshev schrieb: > Is current CVS ok now? Yes, it is. Johannes fixed it. -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List T

Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_build.h zend_extensions.c zend_extensions.h zend_modules.h php-src/ext/standard dl.c info.c php-src/win32/build config.w32

Hi! Is it intentional that extensions such as Xdebug (cleany built built from source against PHP_5_3) do not load anymore now? No, it wasn't the intent, looks like part of my patch for some reason didn't commit (extensions were working OK on my dev machine). Is current CVS ok now? -- Stan

Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_build.h zend_extensions.c zend_extensions.h zend_modules.h php-src/ext/standard dl.c info.c php-src/win32/build config.w32

On Sat, 2009-01-17 at 14:06 +0100, Sebastian Bergmann wrote: > Pierre Joye wrote: > > Yes, they have to be rebuilt. I will do it for Windows. > > I may have not expressed myself cleary: I did rebuild Xdebug against a > build of PHP_5_3 with the new buildid. The resulting xdebug.so cannot > be l

Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_build.h zend_extensions.c zend_extensions.h zend_modules.h php-src/ext/standard dl.c info.c php-src/win32/build config.w32

Pierre Joye wrote: > Yes, they have to be rebuilt. I will do it for Windows. I may have not expressed myself cleary: I did rebuild Xdebug against a build of PHP_5_3 with the new buildid. The resulting xdebug.so cannot be loaded. -- Sebastian Bergmann http://sebastian-

Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_build.h zend_extensions.c zend_extensions.h zend_modules.h php-src/ext/standard dl.c info.c php-src/win32/build config.w32

hi, On Sat, Jan 17, 2009 at 9:04 AM, Sebastian Bergmann wrote: > Stanislav Malyshev wrote: >> stas Sat Jan 17 02:05:14 2009 UTC >> >> Added files: (Branch: PHP_5_3) >> /ZendEngine2 zend_build.h >> >> Modified files: >> /php-src/win32/build config.w32

[PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_build.h zend_extensions.c zend_extensions.h zend_modules.h php-src/ext/standard dl.c info.c php-src/win32/build config.w32

Stanislav Malyshev wrote: > stas Sat Jan 17 02:05:14 2009 UTC > > Added files: (Branch: PHP_5_3) > /ZendEngine2 zend_build.h > > Modified files: > /php-src/win32/build config.w32 > /php-src/ext/standard dl.c info.c > /Zen

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/date/tests date_default_timezone_get_error.phpt date_default_timezone_set_error.phpt date_default_timezone_set_variation1.phpt date_sun_info_error.phpt date_su

Hi Andy, All these tests are broken in an environment that defines a TZ variable, you need to use date_default_timezone_set() Can you fix these please. Scott andy wharmby wrote: > wharmby Tue Jan 13 13:38:20 2009 UTC > > Added files: (Branch: PHP_5_3) > /php

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/phar/tests ini_set.phpt

Hannes Magnusson wrote: > What about 5.2? I thought the extension was supposed to work fine > there too (at least there are bunch of tests that skip with the reason > "needs 5.2"). So you have three branches in pecl? HEAD, PHP_5_3 and > PHP_5_2? > (Not that fix is required in 5.2, everyone who did

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/phar/tests ini_set.phpt

On Tue, Dec 9, 2008 at 19:54, Gregory Beaver <[EMAIL PROTECTED]> wrote: > Hannes Magnusson wrote: >> bjori Tue Dec 9 13:02:40 2008 UTC >> >> Modified files: (Branch: PHP_5_3) >> /php-src/ext/phar/tests ini_set.phpt >> Log: >> MFH: fix test >> >> >> http://cvs.php.n

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/phar/tests ini_set.phpt

Hannes Magnusson wrote: > bjori Tue Dec 9 13:02:40 2008 UTC > > Modified files: (Branch: PHP_5_3) > /php-src/ext/phar/tests ini_set.phpt > Log: > MFH: fix test > > > http://cvs.php.net/viewvc.cgi/php-src/ext/phar/tests/ini_set.phpt?r1=1.4.2.1&r2=1.4.2.2&dif

[PHP-DEV] Re: cvs: php-src /ext/posix/tests posix_getcwd.phpt posix_getgrnam.phpt posix_getpwnam.phpt posix_getrlimit.phpt posix_initgroups.phpt posix_isatty.phpt posix_mknod.phpt

Em Qua, 2008-12-03 às 19:28 +0100, Christian Seiler escreveu: > Hi Felipe, > > > --SKIP-- > > > found'); ?> > > > found'); ?> > > > ?> > > Shouldn't those be function_exists instead of posix_mknod? > hohoho, I'm crazy. :-) Thanks, Christian. -- Regards, Felipe Pena -- PHP Internals - P

[PHP-DEV] Re: cvs: php-src /ext/posix/tests posix_getcwd.phpt posix_getgrnam.phpt posix_getpwnam.phpt posix_getrlimit.phpt posix_initgroups.phpt posix_isatty.phpt posix_mknod.phpt

Hi Felipe, > --SKIP-- > ?> > ?> > Shouldn't those be function_exists instead of posix_mknod? Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / Zend.m4 acinclude.m4 zend_float.h zend_operators.c zend_strtod.c /tests float_prec_001.phpt

Hi, >> Your macros are not compatible with autoconf 2.13: >>***BUG in Autoconf--please report*** AC_LINK_IFELSE > > Grmpf. Problems like this are why I absolutely loathe autoconf. I'll > install 2.13 right away and fix this. Done, tested with autoconf 2.13 and 2.61: http://news.php.net/php

Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / Zend.m4 acinclude.m4 zend_float.h zend_operators.c zend_strtod.c /tests float_prec_001.phpt

Hi, > Your macros are not compatible with autoconf 2.13: >***BUG in Autoconf--please report*** AC_LINK_IFELSE Grmpf. Problems like this are why I absolutely loathe autoconf. I'll install 2.13 right away and fix this. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing L

[PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / Zend.m4 acinclude.m4 zend_float.h zend_operators.c zend_strtod.c /tests float_prec_001.phpt

Christian Seiler wrote: > cseiler Tue Dec 2 16:19:10 2008 UTC > > Added files: (Branch: PHP_5_3) > /ZendEngine2 zend_float.h > /ZendEngine2/testsfloat_prec_001.phpt > > Modified files: > /ZendEngine2 Zend.m4 acinclud

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/standard math.c

Hi, [For conclusive proposal, see below.] >> 1) Internal FPU precision on x86. > > Do you have any test cases show the error? Sure. Consider the following C code: #include int main (int argc, char **argv) { volatile double v = 100.0; printf ("%.35f\n%.35f\n", 0.002877, 2877.0 / v);

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/standard math.c

Hi Stefan, >> 1) Define some macros for math-related functions that will ensure the >> function itself always uses double precision. Add configure checks for >> these macros. > > Do you know what the rationale behind the standard compiler behaviour is? > Because trying to outsmart the compiler i

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/standard math.c

On 30-Oct-08, at 5:55 AM, Christian Seiler wrote: 1) Internal FPU precision on x86. Do you have any test cases show the error? 2) Specification problem (which rounding mode should actually be used?) 3) Dividing/multiplying by >= 10^23 is not exact. 4) round (1.255, 2) should give 1.26 bu

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/standard math.c

Hello Christian, Thursday, October 30, 2008, 10:55:48 AM, you wrote: > Hi, >> Modified files: (Branch: PHP_5_3) >> /php-src/ext/standard math.c >> Log: >> Fixed bug #42294 (Unified solution for round() based on C99 round) >> [DOC] New implementation of round() to wo

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/standard math.c

Hi, > Modified files: (Branch: PHP_5_3) > /php-src/ext/standard math.c > Log: > Fixed bug #42294 (Unified solution for round() based on C99 round) > [DOC] New implementation of round() to work-around inconsistencies for win32 > and 64 bit platforms. > > This so

[PHP-DEV] Re: CVS Account Request: cseiler

Welcome aboard (soon), and congrats for your patchs. -- Cordialement. -- Nicolas Chaillan | GROUPAKT.fr | UIN : 16549830 [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.groupakt.fr http://www.fmsakt.fr | http://www.prospecttel.com Directeur général. ""Christian Seiler"" <[EMAIL PROTECTED]>

[PHP-DEV] Re: cvs: php-src /ext/pcntl EXPERIMENTAL

Hi, On Thu, 2008-08-07 at 13:07 +, "Antony Dovgal" wrote: > tony2001 Thu Aug 7 13:07:07 2008 UTC > > Removed files: > /php-src/ext/pcntlEXPERIMENTAL > Log: > remove EXPERIMENTAL flag The EXTENSIONS file says EXTENSION: pcntl MAINTENA

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4

Sebastian Nohn kirjoitti: David Soria Parra wrote: -dnl Only allow AC_PROG_CXX if it's explicitly called (by PHP_REQUIRE_CXX) -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [AC_PROG_CXX], [undefine([AC_PROG_CXX]) -AC_DEFUN([AC_PROG_

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4

David Soria Parra wrote: > >> -dnl Only allow AC_PROG_CXX if it's explicitly called (by >> PHP_REQUIRE_CXX) >> -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler >> -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [AC_PROG_CXX], >> [undefine([AC_PROG_CXX]) >> -AC_DEFUN([AC_PROG_CXX], []

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4

Em Dom, 2008-07-27 às 17:17 +0300, Jani Taskinen escreveu: > Felipe Pena kirjoitti: > > Em Dom, 2008-07-27 às 17:05 +0300, Jani Taskinen escreveu: > >> David Soria Parra kirjoitti: > -dnl Only allow AC_PROG_CXX if it's explicitly called (by > PHP_REQUIRE_CXX) > -dnl otherwise AC_PRO

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4

Felipe Pena kirjoitti: Em Dom, 2008-07-27 às 17:05 +0300, Jani Taskinen escreveu: David Soria Parra kirjoitti: -dnl Only allow AC_PROG_CXX if it's explicitly called (by PHP_REQUIRE_CXX) -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4

Em Dom, 2008-07-27 às 17:05 +0300, Jani Taskinen escreveu: > David Soria Parra kirjoitti: > > > >> -dnl Only allow AC_PROG_CXX if it's explicitly called (by > >> PHP_REQUIRE_CXX) > >> -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler > >> -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4

David Soria Parra kirjoitti: -dnl Only allow AC_PROG_CXX if it's explicitly called (by PHP_REQUIRE_CXX) -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [AC_PROG_CXX], [undefine([AC_PROG_CXX]) -AC_DEFUN([AC_PROG_CXX], [])]) +dnl O

[PHP-DEV] Re: cvs: php-src(PHP_5_2) / configure.in /scripts phpize.m4

-dnl Only allow AC_PROG_CXX if it's explicitly called (by PHP_REQUIRE_CXX) -dnl otherwise AC_PROG_LIBTOOL fails if there is no working C++ compiler -AC_PROVIDE_IFELSE([PHP_REQUIRE_CXX], [AC_PROG_CXX], [undefine([AC_PROG_CXX]) -AC_DEFUN([AC_PROG_CXX], [])]) +dnl Only allow AC_PROG_CXX and AC_PROG

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / NEWS /main main.c php_ticks.c php_ticks.h

On 23.07.2008, at 18:13, Andi Gutmans wrote: I think I missed the discussion on this topic. Not that I am a big fan of ticks but I don't see a good enough to reason to remove it at this point. I am not aware of the crashes which were pointed out so maybe that's something we can look into.

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / NEWS /main main.c php_ticks.c php_ticks.h

Antony Dovgal wrote: On 23.07.2008 20:13, Andi Gutmans wrote: I think I missed the discussion on this topic. Not that I am a big fan of ticks but I don't see a good enough to reason to remove it at this point. That's my point either. I am not aware of the crashes which were pointed out so ma

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / NEWS /main main.c php_ticks.c php_ticks.h

On 23.07.2008 20:13, Andi Gutmans wrote: I think I missed the discussion on this topic. Not that I am a big fan of ticks but I don't see a good enough to reason to remove it at this point. That's my point either. I am not aware of the crashes which were pointed out so maybe that's something w

RE: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / NEWS /main main.c php_ticks.c php_ticks.h

gt; From: Antony Dovgal [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 23, 2008 8:51 AM > To: Scott MacVicar > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / NEWS /main main.c > php_ticks.c php_ticks.h > > On 26.06.2008 01:27, Sebastian Berg

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / NEWS /main main.c php_ticks.c php_ticks.h

On 26.06.2008 01:27, Sebastian Bergmann wrote: Dmitry Stogov schrieb: dmitry Wed Jun 25 12:18:22 2008 UTC Modified files: (Branch: PHP_5_2) /php-src NEWS /php-src/main main.c php_ticks.c php_ticks.h Log: Fixed bug #45352 (Segmentation fault because of tick

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/phar/tests rename_dir.phpt rmdir.phpt /ext/phar/tests/tar rename_dir.phpt rmdir.phpt /ext/phar/tests/zip rename_dir.phpt rmdir.phpt

On 17.07.2008, at 04:17, Greg Beaver wrote: Dmitry Stogov wrote: dmitry Thu Jul 10 14:27:21 2008 UTC Added files: (Branch: PHP_5_3) /php-src/ext/phar/tests rename_dir.phpt rmdir.phpt /php-src/ ext/phar/tests/tar rename_dir.phpt rmdir.phpt /php-src/ext/phar/

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / NEWS /main main.c php_ticks.c php_ticks.h

Markus Fischer wrote: Hi, Scott MacVicar wrote: > It's been removed without a replacement since I don't believe there has > been a concrete use case given for it. Probably true, I remember it having used for quite uncommon cases but it was useful (especially in CLI functions, having to work

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / NEWS /main main.c php_ticks.c php_ticks.h

Hi, Scott MacVicar wrote: > It's been removed without a replacement since I don't believe there has > been a concrete use case given for it. Probably true, I remember it having used for quite uncommon cases but it was useful (especially in CLI functions, having to work with signals and such).

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / NEWS /main main.c php_ticks.c php_ticks.h

It's been removed without a replacement since I don't believe there has been a concrete use case given for it. Apart from a profiler, and for that there is XDebug which does a far better job. Scott On 18 Jul 2008, at 18:42, Markus Fischer wrote: Hi, Now that it has been deprecated (also

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / NEWS /main main.c php_ticks.c php_ticks.h

Hi, Now that it has been deprecated (also looking at http://wiki.php.net/doc/scratchpad/upgrade/53?s[]=ticks and http://wiki.php.net/todo/php53?s[]=ticks), I'm wondering whether there's alternative to this functionality? Or is this completely phased out from PHP without a replacement? thank

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/phar/tests rename_dir.phpt rmdir.phpt /ext/phar/tests/tar rename_dir.phpt rmdir.phpt /ext/phar/tests/zip rename_dir.phpt rmdir.phpt

Dmitry Stogov wrote: dmitry Thu Jul 10 14:27:21 2008 UTC Added files: (Branch: PHP_5_3) /php-src/ext/phar/tests rename_dir.phpt rmdir.phpt /php-src/ext/phar/tests/tar rename_dir.phpt rmdir.phpt /php-src/ext/phar/tests/zip rename_dir.phpt rmdir.phpt Log

Re: [PHP-DEV] Re: cvs: php-src /ext/hash CREDITS config.m4 hash.c /ext/hash/tests mhash_001.phpt mhash_002.phpt mhash_003.phpt skip_mhash.inc /ext/mhash config.m4 mhash.c mhash.dsp php_mhash.h /ex

Scott MacVicar schrieb: extension_loaded still works, this was a primary goal. Cool! Sebastian -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Ma

Re: [PHP-DEV] Re: cvs: php-src /ext/hash CREDITS config.m4 hash.c /ext/hash/tests mhash_001.phpt mhash_002.phpt mhash_003.phpt skip_mhash.inc /ext/mhash config.m4 mhash.c mhash.dsp php_mhash.h /ex

extension_loaded still works, this was a primary goal. Scott On 28 Jun 2008, at 17:25, Sebastian Bergmann wrote: Scott MacVicar schrieb: MFB: Make the old mhash API a wrapper around hash There is a BC break, though, for code that uses extension_loaded('mhash'); instead of function_ex

Re: [PHP-DEV] Re: cvs: php-src /ext/hash CREDITS config.m4 hash.c /ext/hash/tests mhash_001.phpt mhash_002.phpt mhash_003.phpt skip_mhash.inc /ext/mhash config.m4 mhash.c mhash.dsp php_mhash.h /ext/mh

Hi Sebastian, On Sat, Jun 28, 2008 at 6:25 PM, Sebastian Bergmann <[EMAIL PROTECTED]> wrote: >> MFB: Make the old mhash API a wrapper around hash > > There is a BC break, though, for code that uses > > extension_loaded('mhash'); > > instead of > > function_exists('mhash'); > > right? The

[PHP-DEV] Re: cvs: php-src /ext/hash CREDITS config.m4 hash.c /ext/hash/tests mhash_001.phpt mhash_002.phpt mhash_003.phpt skip_mhash.inc /ext/mhash config.m4 mhash.c mhash.dsp php_mhash.h /ext/mh

Scott MacVicar schrieb: MFB: Make the old mhash API a wrapper around hash There is a BC break, though, for code that uses extension_loaded('mhash'); instead of function_exists('mhash'); right? -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key

[PHP-DEV] Re: cvs: php-src(PHP_5_2) / NEWS /main main.c php_ticks.c php_ticks.h

Dmitry Stogov schrieb: dmitry Wed Jun 25 12:18:22 2008 UTC Modified files: (Branch: PHP_5_2) /php-src NEWS /php-src/main main.c php_ticks.c php_ticks.h Log: Fixed bug #45352 (Segmentation fault because of tick function What ever happened to the plan to d

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/standard string.c

Sebastian Bergmann wrote: Was this patch required because of an issue introduced in revision 1.445.2.14.2.69.2.23 of the file (the parameter parsing API update)? If so, there might be more issues of a similar kind in there as PHPUnit breaks starting with revision 1.445.2.14.2.69.2.23 of string.c

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/standard string.c

Dmitry Stogov wrote: dmitry Tue Jun 24 06:07:08 2008 UTC Modified files: (Branch: PHP_5_3) /php-src/ext/standard string.c Log: Fixed strtolower/strtoupper to not modify the passed argument Was this patch required because of an issue introduced in revision 1.

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/gd gd.c /ext/gd/tests lines.phpt

Felipe Pena wrote: felipe Sat Jun 21 22:07:53 2008 UTC Modified files: (Branch: PHP_5_3) /php-src/ext/gd gd.c /php-src/ext/gd/tests lines.phpt Log: - New parameter parsing API /usr/local/src/php/php-5.3/ext/gd/gd.c: In function 'zif_imagegammacorrect': /u

[PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_alloc.h

Matt Wilmas wrote: > mattwil Fri Jun 13 04:16:59 2008 UTC > > Modified files: (Branch: PHP_5_3) > /ZendEngine2 zend_alloc.h > Log: > MFH: Add pestrndup() Thanks Matt Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: h

[PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend_compile.c zend_compile.h zend_execute.c zend_vm_def.h zend_vm_execute.h /tests bug44913.phpt php-src NEWS

Dmitry Stogov schrieb: - Fixed bug #44913 (Segfault when using return in combination with nested loops and continue 2) What about PHP_5_2? -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

[PHP-DEV] Re: CVS Account Request: ant

Hi Marcus/Pierre, Yes I've put together a bunch of tests for the session extension and have posted to the QA mailing list with the zip download details. There are quite a few tests (a little over 110 at last count) tested against the latest php 5.2, 5.3 and 6.0 snaps (and on Windows/Linux). Th

[PHP-DEV] Re: CVS Account Request: mimmi

Thomas Mueller wrote: > distributing a new package Which package? For what? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) /main SAPI.c SAPI.h main.c php_globals.h /sapi/apache mod_php5.c ZendEngine2 zend_execute.h zend_execute_API.c

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rasmus Lerdorf wrote: > No, I don't think so. I checked all extensions in php cvs, including > pecl, and none of them call zend_set_timeout() which is the function > that was changed. And I can't see any foreign extension needing to call > that funct

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) /main SAPI.c SAPI.h main.c php_globals.h /sapi/apache mod_php5.c ZendEngine2 zend_execute.h zend_execute_API.c

Edward Z. Yang wrote: Rasmus Lerdorf wrote: exit_on_timeout patch Hi Rasmus, I noticed that this patch modifies the Zend Engine API slightly. Does this translate into any changes that need documentation at php.net? No, I don't think so. I checked all extensions in php cvs, including pecl

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /main SAPI.c SAPI.h main.c php_globals.h /sapi/apache mod_php5.c ZendEngine2 zend_execute.h zend_execute_API.c

Rasmus Lerdorf wrote: > exit_on_timeout patch Hi Rasmus, I noticed that this patch modifies the Zend Engine API slightly. Does this translate into any changes that need documentation at php.net? -- Edward Z. YangGnuPG: 0x869C48DA HTML Purifier

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) / Makefile.frag NEWS acinclude.m4 configure.in /ext/spl php_spl.c /ext/standard/tests/strings 006.phpt 007.phpt highlight_file.phpt strip_tags_basic1.phpt stri

Marcus Boerger wrote: > Yeah, thats right. That is also the reason why we spent several weeks > working on thjise with a small team prior to comitting the work. Also > note that plans for this move are in place for over two years now. And > of course we document changes as we find them, though none

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) / Makefile.frag NEWS acinclude.m4 configure.in /ext/spl php_spl.c /ext/standard/tests/strings 006.phpt 007.phpt highlight_file.phpt strip_tags_basic1.phpt stri

Hello Edward, Sunday, March 16, 2008, 11:04:56 PM, you wrote: > Marcus Boerger wrote: >> Of course it affects that kind of tools. But the scanner was changed a lot >> of times for 5.3 already, so you have to do that anyway. That is the cost >> of making progress - changes. > Agreed; I'm in favor

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) / Makefile.frag NEWS acinclude.m4 configure.in /ext/spl php_spl.c /ext/standard/tests/strings 006.phpt 007.phpt highlight_file.phpt strip_tags_basic1.phpt stri

Marcus Boerger wrote: > Of course it affects that kind of tools. But the scanner was changed a lot > of times for 5.3 already, so you have to do that anyway. That is the cost > of making progress - changes. Agreed; I'm in favor of changes. But to make things as painless as possible those changes s

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_3) / Makefile.frag NEWS acinclude.m4 configure.in /ext/spl php_spl.c /ext/standard/tests/strings 006.phpt 007.phpt highlight_file.phpt strip_tags_basic1.phpt stri

Hello Edward, Sunday, March 16, 2008, 10:42:43 PM, you wrote: > Marcus Boerger wrote: >> - the tokenizer works a bit different as tokenizing works better now, that >> is uses less tokens. >> - the scanner is about 20% faster, overall execution is about 2% faster >> when not using compiler cac

[PHP-DEV] Re: cvs: php-src(PHP_5_3) / Makefile.frag NEWS acinclude.m4 configure.in /ext/spl php_spl.c /ext/standard/tests/strings 006.phpt 007.phpt highlight_file.phpt strip_tags_basic1.phpt strip_ta

Marcus Boerger wrote: > - the tokenizer works a bit different as tokenizing works better now, that > is uses less tokens. > - the scanner is about 20% faster, overall execution is about 2% faster > when not using compiler caches like APC > - in some edgecases error messages are no longer corrup

[PHP-DEV] Re: cvs: php-src(PHP_5_3) / Makefile.frag NEWS acinclude.m4 configure.in /ext/spl php_spl.c /ext/standard/tests/strings 006.phpt 007.phpt highlight_file.phpt strip_tags_basic1.phpt strip_ta

Hello Edward, - the tokenizer works a bit different as tokenizing works better now, that is uses less tokens. - the scanner is about 20% faster, overall execution is about 2% faster when not using compiler caches like APC - in some edgecases error messages are no longer corrupted besides that

[PHP-DEV] Re: cvs: php-src(PHP_5_3) / Makefile.frag NEWS acinclude.m4 configure.in /ext/spl php_spl.c /ext/standard/tests/strings 006.phpt 007.phpt highlight_file.phpt strip_tags_basic1.phpt strip_t

Marcus Boerger wrote: > - Rewrite scanner to be based on re2c instead of flex > The full patch is available as: > http://php.net/~helly/php-re2c-5.3-20080316.diff.txt > This is against php-re2c repository version 98 > An older patch against version 97 is available under: > htt

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /main fopen_wrappers.c

Dmitry Stogov wrote: > Disable path resolution for filenames with stream wrappers > More careful check for relative pathes (./xxx and ../xxx) Hi Dmitry; does this change behavior for any code that might exist already, or does it simply "fix a bug"? -- Edward Z. YangG

[PHP-DEV] Re: cvs: php-src(PHP_5_3) /ext/pdo_odbc odbc_driver.c odbc_stmt.cpdo_odbc.c php_pdo_odbc_int.h

Johannes Schlüter wrote: > Elizabeth, > > looks like you changed the line endings with this commit, please try to > avoid that in future. And well, yes PDO in HEAD is a bit out of sync but > it would still be nice too merge stuff there :-) > > johannes > PDO_ODBC in head is REALLY out of sync,

Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend.c zend.h zend_vm_def.h zend_vm_execute.h php-src NEWS php-src/main fopen_wrappers.c fopen_wrappers.h main.c

Marcus Boerger wrote: Hello Gregory, for include require we anyway use the streams stuff, don't we? include_path searching does not use php streams, because only the plain_wrapper supports include_path (for obvious reasons) Greg -- PHP Internals - PHP Runtime Development Mailing List To

[PHP-DEV] RE: cvs: ZendEngine2(PHP_5_3) / zend.c zend.h zend_vm_def.h zend_vm_execute.h php-src NEWS php-src/main fopen_wrappers.c fopen_wrappers.h main.c

Hi Gregory, It's good idea. I missed this feature when I tried to transparently include file from tar archive. Probably we must do it. Please try to make a patch if you have time (I'm busy now) Thanks. Dmitry. > -Original Message- > From: Gregory Beaver [mailto:[EMAIL PROTECTED] > Sent:

Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend.c zend.h zend_vm_def.h zend_vm_execute.h php-src NEWS php-src/main fopen_wrappers.c fopen_wrappers.h main.c

Hello Gregory, for include require we anyway use the streams stuff, don't we? marcus Wednesday, March 5, 2008, 9:24:39 PM, you wrote: > Dmitry Stogov wrote: >> dmitryWed Mar 5 13:34:16 2008 UTC >> >> Modified files: (Branch: PHP_5_3) >> /php-src NEWS >>

Re: [PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend.c zend.h zend_vm_def.h zend_vm_execute.h php-src NEWS php-src/main fopen_wrappers.c fopen_wrappers.h main.c

Hi! This is a very nice addition - I wonder if you might be interested in a patch to enable stream wrappers in include_path? There are a couple of ways this could be done, but the one I think would be best is checking for "//" immediately following ":" and then attempting to locate a stream wra

[PHP-DEV] Re: cvs: ZendEngine2(PHP_5_3) / zend.c zend.h zend_vm_def.h zend_vm_execute.h php-src NEWS php-src/main fopen_wrappers.c fopen_wrappers.h main.c

Dmitry Stogov wrote: > dmitryWed Mar 5 13:34:16 2008 UTC > > Modified files: (Branch: PHP_5_3) > /php-src NEWS > /php-src/main fopen_wrappers.c fopen_wrappers.h main.c > /ZendEngine2 zend.c zend.h zend_vm_def.h zend_vm_execute.h > Log: >

[PHP-DEV] Re: cvs: php-src / README.UNICODE-UPGRADES /main snprintf.c spprintf.c

Marcus Boerger wrote: > helly Thu Feb 7 18:40:29 2008 UTC > > Modified files: > /php-src README.UNICODE-UPGRADES > /php-src/main snprintf.c spprintf.c > Log: > - Add %Z to *printf > > http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE-UPGRADES?r1=1.

[PHP-DEV] Re: cvs: php-src(PHP_5_2) /ext/dom xpath.c

Antony Dovgal schrieb: On 29.01.2008 18:55, Sebastian Bergmann wrote: sebastian Tue Jan 29 15:55:30 2008 UTC Modified files: (Branch: PHP_5_2) /php-src/ext/dom xpath.c Log: MFH: Add Reflection API metadata for DOMXPath. This broke ext/dom/tests/canonical

[PHP-DEV] Re: CVS Account Request: afz

Ali Fazelzadeh wrote: PEAR Maintainer. for now, i talk with Lorenzo Alberton MDB2(lead maintainer) for developing this package. confirmed. Best regards, -- Lorenzo Alberton http://pear.php.net/user/quipo Quipo Free Inter

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / run-tests.php /ext/bz2/tests 005.phpt /ext/standard/tests/general_functions phpcredits.phpt phpinfo.phpt /ext/standard/tests/strings sha1.phpt /ext/zlib/t

nlopess Fri Sep 14 15:28:04 2007 UTC Log: changes to run-tests.php: - change %s to %a - make %s = [^\r\n]+ - fix tests accordingly I think this is a very bad change. While tests of bundled extensions can be updated accordingly, pecl extension tests have no way to be version agnostic

Re: [PHP-DEV] Re: cvs: php-src(PHP_5_2) / run-tests.php /ext/bz2/tests 005.phpt /ext/standard/tests/general_functions phpcredits.phpt phpinfo.phpt /ext/standard/tests/strings sha1.phpt /ext/zlib/t

Michael Wallner wrote: Nuno Lopes wrote: nlopess Fri Sep 14 15:28:04 2007 UTC Log: changes to run-tests.php: - change %s to %a - make %s = [^\r\n]+ - fix tests accordingly I think this is a very bad change. While tests of bundled extensions can be updated

  1   2   3   4   >