Re: [PHP-DEV] question about backward-compatibility break/bug in php 5.2.6
> Hello all, > > Last week I submitted a bug report on the issue described below. The > response (also below) was that this is not a bug. I fail to see how it > could *not* be a bug given that strtotime is parsing an invalid date > into a seemingly-arbitrary and definitely-meaningless number, rather > than returning false as it is supposed to. Can someone explain to me > why this is "intended" behavior? We do rely on strtotime returning > false on invalid dates, and this behavior changed between 5.2.5 and > 5.2.6. Do we need to update our code to check for this arbitrary > negative integer? I would prefer not to do that. Date is not invalid. Some diety was born at -62169966000 Unixtime. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
I was waiting after Rasmus said he wanted to compare to the internal Signals code they have at Yahoo before asking againd about inclusion. Gopal is familiar with the Yahoo code as well and we're planning to get together tomorrow and to review and make sure there aren't any critial oversights on this implementation. If the timeline allows 5.3 would be great but we may want to wait until Friday to commit. It makes sense to me to enable by default on systems that have sigaction and disable on those without. This happens curretly in the patch if it's enabled and not present. I did check some discussions from other projects where this has come up and of was found to be available on almost all systems a number of years ago. I can dig this up and add to the rfc soon. -lucas (mobile) On Jul 23, 2008, at 10:55, "Stanislav Malyshev" <[EMAIL PROTECTED]> wrote: Hi! Do we really need this option? Is someone going to disable it and why? I see only reason to disable it if one has some weird system where sigaction is either absent or doesn't work as it should. Not that I know of any, but Unix variants are full of surprises. I'd keep it enabled by default, unless we are on OS that doesn't have sigaction (e.g. Windows or some extremely weird Unix) or in ZTS, of course. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: towards a 5.3 release
Stanislav Malyshev wrote: Hi! Of course its predictable. What Greg meant is "error prone". The difference is if we want to by default lower the chance of programming mistakes or ensure maximum performance with little effort for users with autoload (and long include path lists). I think silent performance disaster is much worse than error message which makes it obvious what the mistake was. Me too. This is the problem I am referring to: a.php: b.php: c.php: The above code will throw an ::Exception, not a Foo::Exception. With the proposed change, it works as advertised. This code: throws a Foo::Exception and echoes "caught", demonstrating the importance of load order as well. This is *far* from an obvious error message, it is a silent logic error that is far more serious than a silent performance problem. Stas, your response is quite frustrating to this problem and fits a pattern. It seems the default response is always "no" or "that's not a real problem" and is almost always condescending. It makes it extremely difficult to have an intelligent debate with you. If you don't think something is a real problem, perhaps a better default response is "why does this person think it is an issue and I don't?" The impression your response gives is that your first thought is instead "why is XXX such an idiot who must waste my time?" I know you well enough to know that this is not what you're thinking, but it would save a lot of time if we can skip the "what the hell" stage and move right to "let's verify this and fix it" or "more evidence needed, I see your point but what about XX?" Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] unix path separators in spl
Hello Steph, Wednesday, July 23, 2008, 10:24:35 PM, you wrote: > Hi Marcus, >> how about having this as an option inside the SPL classes that gets >> turned on by Phar automatically? Inside SPL we could have it as a user >> set-only flag. > The attached patch does this, at the SPL end. Can I commit it (or something > very close) before the 5_3 freeze please? It's a fix is it not? anyway, please go ahead and submit. > NB The patch was created with DOS line endings and then converted to *nix, > it won't apply cleanly in its current state. It's just for review. > Thanks, > - Steph Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] question about backward-compatibility break/bug in php 5.2.6
Hello all, Last week I submitted a bug report on the issue described below. The response (also below) was that this is not a bug. I fail to see how it could *not* be a bug given that strtotime is parsing an invalid date into a seemingly-arbitrary and definitely-meaningless number, rather than returning false as it is supposed to. Can someone explain to me why this is "intended" behavior? We do rely on strtotime returning false on invalid dates, and this behavior changed between 5.2.5 and 5.2.6. Do we need to update our code to check for this arbitrary negative integer? I would prefer not to do that. Thanks, Jack Steadman Smarter Travel Media LLC -- Operating system: RHEL 4/5 PHP version: 5.2.6 PHP Bug Type: Date/time related Bug description: strtotime parses -00-00 00:00:00 as valid date Description: MySQL uses '-00-00 00:00:00' as a default value for non-null datetime fields. Until 5.2.6, strtotime correctly returned false (or -1 before 5.1) when passed this value - it's not a valid date/time. 5.2.6 returns '-62169966000' which is not useful. Reproduce code: --- http://bugs.php.net/bug.php?id=42971 http://bugs.php.net/bug.php?id=44453 This is not a bug. MySQL is being silly to use this string as a default value. In PHP 5.3 you can now detect this however, by using date_parse_from_format( "Y-m-d H:i:s"); and then check the contents of date_get_last_errors(). [18 Jul 1:31pm UTC] jack+phpdotnet at smartertravelmedia dot com First of all, those previously-reported bugs are with the DateTime class, not strtotime. If DateTime uses strtotime or its underlying implementation, that's not for me to know. I searched the bug database before submitting this report and did not find the two you mentioned. Your "similar bugs" prompt didn't flag them either. Second, how is this not a bug? strtotime's manual page says, "Returns a timestamp on success, FALSE otherwise." The string of zeroes that mysql uses is NOT a valid datetime string, so how is strtotime "successfully" parsing it into a random negative number? That's aside from the fact that this is a behavior *change* from 5.2.5 to 5.2.6 - that alone makes it a problem. Third, you can think mysql is silly for using this as a default all you want, but they've been doing it since at least version 3.23 if not before. Just because you don't agree with it doesn't mean PHP shouldn't handle it as advertised - namely to return false if an invalid date/time string is passed to strtotime. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Php 5.3 Snap - Lambda functions and $this scope
This is based on a bug submitted at http://bugs.php.net/bug.php?id=45604
Description:
When creating a normal function inside a class and calling it, the
function doesn't have access to $this.
"Fatal error: Using $this when not in object context"
When creating a lambda function inside a class, $this is visible from
the new function's scope and can be accessed normally.
Wouldn't it be better (and maybe safer) to allow the use of $this as a
closure instead of passing it to the new lambda function?
Currently trying to use $this as a closure dies with a "Fatal error:
Cannot use $this as lexical variable" error.
Example for the suggestion.
$x = function () use ($this) { return $this->hello; };
Reproduce code:
---
>
> class something
> {
> public $hello = 'Hello world!';
>
> public function world()
> {
> $x = function () { return $this->hello; };
> return $x();
> }
> }
>
> $s = new something();
> echo $s->world();
>
> ?>
Expected result:
Not to be able to use $this.
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. there was never a lengthy thread on this .. but all mentioning of the topic seemed to generate agreement that it should be removed and that there are indeed problematic areas, lots of bug reports and no proper way to fix them and no good use case to keep them. now tony seems to say that there is a use case. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/soap ctor errors
Hi,
Should not be too hard for someone with C knowledge to produce a fix I
would assume. Any takers? Not sure if Dmitry has time for this on such
short notice ..
regards,
Lukas
On 23.07.2008, at 20:07, Noah Fontes wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Zülke wrote:
I know this is horribly old, but I just stumbled across the same
issue
again and realized it has not been tackled yet.
Shouldn't we fix that for 5.3?
David
Am 08.01.2007 um 14:51 schrieb Knut Urdalen:
I agree with Lukas here, currently you have to be proactive against
the location of the WSDL-file. I currently do like this in my
SoapClient's:
class MySoapClient extends SoapClient {
public function __construct($wsdl ,$options = array()) {
if(is_resource(@fopen($wsdl, 'r'))) {
parent::__construct($wsdl, $options);
} else {
throw new Exception("Parsing WSDL: Couldn't load from '$wsdl'");
}
}
}
to be able to catch that problem as an Exception.
Regards,
Knut Urdalen
Lukas Kahwe Smith wrote:
Hi,
why do I get warnings when I have failures in my ext/soap ctor?
try {
$client = new SoapClient('http://i_dont_exist.com/some.wsdl',
array('exceptions' => true));
} catch (Exception $e) { }
I guess even without the 'exceptions' => true it should always
return
all issues as an exception. I think this was agreed upon for
constructor errors in PHP5, no?
regards,
Lukas
+1 for this.
Regards,
Noah
- --
Noah Fontes
Bitextender
http://www.bitextender.com/
Phone: +1 919 349 9826
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIh3NKhitK+HuUQJQRAmywAKCH7w7pq7r9dV+UHF81Ky7/9XzYOgCgjAGB
DopF3tsQm31fzXxDhWYU2S8=
=QPf5
-END PGP SIGNATURE-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC question (Re: [PHP-DEV] [PATCH] Allow use($var..) statement ubiquitously)
On 23.07.2008, at 18:21, Moriyoshi Koizumi wrote: I would like to keep this as a RFC page in wiki.php.net. Are there any conventions or rules that I should keep in mind? (or just-not- supposed-to-do-that-because-your-proposal-is-stupid-and-will-never- be-accepted?) we have not really done any rules .. just common sense. if you create a new page in the rfc namespace, it already comes up with a template (though that template could use some tweaking). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] unix path separators in spl
Hi Marcus,
how about having this as an option inside the SPL classes that gets
turned on by Phar automatically? Inside SPL we could have it as a user
set-only flag.
The attached patch does this, at the SPL end. Can I commit it (or something
very close) before the 5_3 freeze please?
NB The patch was created with DOS line endings and then converted to *nix,
it won't apply cleanly in its current state. It's just for review.
Thanks,
- Steph
Index: ext/spl/spl_directory.c
===
RCS file: /repository/php-src/ext/spl/spl_directory.c,v
retrieving revision 1.45.2.27.2.23.2.26
diff -u -r1.45.2.27.2.23.2.26 spl_directory.c
--- ext/spl/spl_directory.c 23 Jul 2008 06:12:29 -
1.45.2.27.2.23.2.26
+++ ext/spl/spl_directory.c 23 Jul 2008 20:19:29 -
@@ -175,6 +175,8 @@
static inline void spl_filesystem_object_get_file_name(spl_filesystem_object
*intern TSRMLS_DC) /* {{{ */
{
+ char slash = intern->flags & SPL_FILE_DIR_UNIXPATHS ? '/' :
DEFAULT_SLASH;
+
if (!intern->file_name) {
switch (intern->type) {
case SPL_FS_INFO:
@@ -184,7 +186,7 @@
case SPL_FS_DIR:
intern->file_name_len = spprintf(&intern->file_name, 0,
"%s%c%s",
spl_filesystem_object_get_path(intern, NULL TSRMLS_CC),
-DEFAULT_SLASH,
intern->u.dir.entry.d_name);
+slash,
intern->u.dir.entry.d_name);
break;
}
}
@@ -615,6 +617,9 @@
if (ctor_flags & SPL_FILE_DIR_SKIPDOTS) {
flags |= SPL_FILE_DIR_SKIPDOTS;
}
+ if (ctor_flags & SPL_FILE_DIR_UNIXPATHS) {
+ flags |= SPL_FILE_DIR_UNIXPATHS;
+ }
if (parsed == FAILURE) {
php_set_error_handling(EH_NORMAL, NULL TSRMLS_CC);
return;
@@ -1244,6 +1249,7 @@
zval zpath, zflags;
spl_filesystem_object *intern =
(spl_filesystem_object*)zend_object_store_get_object(getThis() TSRMLS_CC);
spl_filesystem_object *subdir;
+ char slash = intern->flags & SPL_FILE_DIR_UNIXPATHS ? '/' :
DEFAULT_SLASH;
spl_filesystem_object_get_file_name(intern TSRMLS_CC);
@@ -1257,7 +1263,7 @@
subdir =
(spl_filesystem_object*)zend_object_store_get_object(return_value TSRMLS_CC);
if (subdir) {
if (intern->u.dir.sub_path && intern->u.dir.sub_path[0]) {
- subdir->u.dir.sub_path_len = spprintf(&subdir->u.dir.sub_path, 0,
"%s%c%s", intern->u.dir.sub_path, DEFAULT_SLASH, intern->u.dir.entry.d_name);
+ subdir->u.dir.sub_path_len = spprintf(&subdir->u.dir.sub_path, 0,
"%s%c%s", intern->u.dir.sub_path, slash, intern->u.dir.entry.d_name);
} else {
subdir->u.dir.sub_path_len =
strlen(intern->u.dir.entry.d_name);
subdir->u.dir.sub_path =
estrndup(intern->u.dir.entry.d_name, subdir->u.dir.sub_path_len);
@@ -1290,9 +1296,10 @@
spl_filesystem_object *intern =
(spl_filesystem_object*)zend_object_store_get_object(getThis() TSRMLS_CC);
char *sub_name;
int len;
+ char slash = intern->flags & SPL_FILE_DIR_UNIXPATHS ? '/' :
DEFAULT_SLASH;
if (intern->u.dir.sub_path) {
- len = spprintf(&sub_name, 0, "%s%c%s", intern->u.dir.sub_path,
DEFAULT_SLASH, intern->u.dir.entry.d_name);
+ len = spprintf(&sub_name, 0, "%s%c%s", intern->u.dir.sub_path,
slash, intern->u.dir.entry.d_name);
RETURN_STRINGL(sub_name, len, 0);
} else {
RETURN_STRING(intern->u.dir.entry.d_name, 1);
@@ -2624,6 +2631,7 @@
REGISTER_SPL_CLASS_CONST_LONG(FilesystemIterator, "KEY_AS_FILENAME",
SPL_FILE_DIR_KEY_AS_FILENAME);
REGISTER_SPL_CLASS_CONST_LONG(FilesystemIterator,
"NEW_CURRENT_AND_KEY",
SPL_FILE_DIR_KEY_AS_FILENAME|SPL_FILE_DIR_CURRENT_AS_FILEINFO);
REGISTER_SPL_CLASS_CONST_LONG(FilesystemIterator, "SKIP_DOTS",
SPL_FILE_DIR_SKIPDOTS);
+ REGISTER_SPL_CLASS_CONST_LONG(FilesystemIterator, "UNIX_PATHS",
SPL_FILE_DIR_UNIXPATHS);
spl_ce_FilesystemIterator->get_iterator =
spl_filesystem_tree_get_iterator;
Index: ext/spl/spl_directory.h
===
RCS file: /repository/php-src/ext/spl/spl_directory.h,v
retrieving revision 1.12.2.5.2.4.2.11
diff -u -r1.12.2.5.2.4.2.11 spl_directory.h
--- ext/spl/spl_directory.h 19 Jul 2008 11:20:18 -
1.12.2.5.2.4.2.11
+++ ext/spl/spl_directory.h 23 Jul 2008 20:20:36 -
@@ -133,6 +133,7 @@
#define SPL_FILE_DIR_KEY(intern,mode)
((intern->flags&SPL_FILE_DIR_KEY_MODE_MASK)==mode)
#define SPL_FILE_DIR_SKIPDOTS 0x1000 /* Tells whether i
Re: [PHP-DEV] 5.3 feature freeze rapidly approaching
Marcus Boerger wrote: should we use the alpha time to constify our c level API? Sounds like a good idea. -- 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 To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/soap ctor errors
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Zülke wrote:
> I know this is horribly old, but I just stumbled across the same issue
> again and realized it has not been tackled yet.
>
> Shouldn't we fix that for 5.3?
>
>
> David
>
>
>
> Am 08.01.2007 um 14:51 schrieb Knut Urdalen:
>
>> I agree with Lukas here, currently you have to be proactive against
>> the location of the WSDL-file. I currently do like this in my
>> SoapClient's:
>>
>> class MySoapClient extends SoapClient {
>> public function __construct($wsdl ,$options = array()) {
>> if(is_resource(@fopen($wsdl, 'r'))) {
>> parent::__construct($wsdl, $options);
>> } else {
>> throw new Exception("Parsing WSDL: Couldn't load from '$wsdl'");
>> }
>> }
>> }
>>
>> to be able to catch that problem as an Exception.
>>
>> Regards,
>> Knut Urdalen
>>
>> Lukas Kahwe Smith wrote:
>>> Hi,
>>>
>>> why do I get warnings when I have failures in my ext/soap ctor?
>>>
>>> try {
>>> $client = new SoapClient('http://i_dont_exist.com/some.wsdl',
>>> array('exceptions' => true));
>>> } catch (Exception $e) { }
>>>
>>> I guess even without the 'exceptions' => true it should always return
>>> all issues as an exception. I think this was agreed upon for
>>> constructor errors in PHP5, no?
>>>
>>> regards,
>>> Lukas
>>>
+1 for this.
Regards,
Noah
- --
Noah Fontes
Bitextender
http://www.bitextender.com/
Phone: +1 919 349 9826
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIh3NKhitK+HuUQJQRAmywAKCH7w7pq7r9dV+UHF81Ky7/9XzYOgCgjAGB
DopF3tsQm31fzXxDhWYU2S8=
=QPf5
-END PGP SIGNATURE-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / run-tests.php
Hi Marcus, Am Mittwoch, den 23.07.2008, 18:57 +0200 schrieb Marcus Boerger: [...] > to be honest this is the wrong way. The correct way of fixing this is to > have PHP 6 name it correct: string and binary This would not solve the problem of writing portable tests for 5_3 and HEAD. Currently we have a number of tests with %s(4) "test" to circumvent this problem. But this workaround will reliably lead us to obscure bugs. This is the reason we discussed the introduction of the placeholder on the QA-list. But if you know a better way to do it, I'm really happy to implement that. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] [RFC] Zend Signal Handling
Hi! Do we really need this option? Is someone going to disable it and why? I see only reason to disable it if one has some weird system where sigaction is either absent or doesn't work as it should. Not that I know of any, but Unix variants are full of surprises. I'd keep it enabled by default, unless we are on OS that doesn't have sigaction (e.g. Windows or some extremely weird Unix) or in ZTS, of course. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Zülke wrote: > Yeah. We discussed that quite a while back when I sent over the > "ignore_errors" options patch-like thing in November: > http://thread.gmane.org/gmane.comp.php.devel/46003 > > I think we should do it. > > But what about other 3xx redirect codes? How are those handled? I think PHP implicitly follows any Location headers it can. That's probably not the right behavior, but for an automated process it's not bad. I think that 3xx status codes, if they appear without a Location header, should also probably not throw errors. They could provide valuable information about the status of a page (particularly 304 Not Modified), so I've updated the patch: http://cynigram.com/~nfontes/http_fopen_wrapper.patch BTW, any chance this could be rolled into 5.3? I think the BC break is pretty non-notable, and it would be nice to stop throwing errors for successful responses. Regards, Noah - -- Noah Fontes Bitextender http://www.bitextender.com/ Phone: +1 919 349 9826 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIh20nhitK+HuUQJQRAqipAJ9pndnS4K4L5GtPzoYsEguYQSgSXwCfb6yC YnohwjT8KYCiADQehg4Jm2A= =UzO8 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / run-tests.php
Moin Marcus!
Marcus Boerger schrieb:
to be honest this is the wrong way. The correct way of fixing this is to
have PHP 6 name it correct: string and binary. And to have b for binary
prefix rather then u for unicode. Or did PHP 6 change in the meanwhile and
we support u"Nonsense" besides b"Binary"?
I'm not sure if a change to PHP would help solving the original question
on portable tests which I raised on the QA list. I asked for a way to
write "portable" tests. That is a test which can be run on both PHP 5
and PHP 6 -- one file for both PHP 5 and PHP 6 (like in early PHP 6 days
with UEXPECTF), not two versions that need to be kept in sync (like
nowadays).
Currently we have:
PHP 5
var_dump("PHP" . chr(0) . " rocks!") --> string(9) "PHProcks"
var_dump((binary)"PHP" . chr(0) . " rocks!") --> string(9) "PHProcks"
PHP 6
var_dump("PHP" . chr(0) . " rocks!") --> unicode(9) "PHProcks"
var_dump((binary)"PHP" . chr(0) . " rocks!") --> unicode(9) "PHProcks"
The patch to run-tests.php allows you to use in your EXPECTF or
EXPECTREGEXP section:
%unicode|string%(9) "PHProcks"
With PHP 5, run-tests.php will search for string(9) "PHProcks" and with
PHP 6 it will search for unicode(9) "PHProcks": one EXPECTF section, one
test file for both PHP 5 and PHP 6.
If I get you right, you suggest that it should read as follows in PHP 6:
var_dump("PHP" . chr(0) . " rocks!") --> string(9) "PHProcks"
var_dump((binary)"PHP" . chr(0) . " rocks!") --> binary(9) "PHProcks"
This may be correct and desired. However, if you change it, I'm back to
my question: is there a way to write a "portable" test?
Ulf
--
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_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 maybe that's something we can look into. Yes, I don't recall any crashes caused my ticks, too. Blah..just search the bug database..you'll get plenty of reports. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src / run-tests.php
Hello Lars,
to be honest this is the wrong way. The correct way of fixing this is to
have PHP 6 name it correct: string and binary. And to have b for binary
prefix rather then u for unicode. Or did PHP 6 change in the meanwhile and
we support u"Nonsense" besides b"Binary"?
Question actually goes to Andrei, who should decide whether we get a sane
output or not.
marcus
Wednesday, July 23, 2008, 6:10:14 PM, you wrote:
> lstrojnyWed Jul 23 16:10:14 2008 UTC
> Modified files:
> /php-srcrun-tests.php
> Log:
> Allowing "%unicode|string%" as a placeholder. In 6, this placeholder is
> resolved
> to "unicode", in <6 to "string". This allows to easily write portable tests.
> Patch by uw
>
>
>
> http://cvs.php.net/viewvc.cgi/php-src/run-tests.php?r1=1.366&r2=1.367&diff_format=u
> Index: php-src/run-tests.php
> diff -u php-src/run-tests.php:1.366 php-src/run-tests.php:1.367
> --- php-src/run-tests.php:1.366 Tue Jul 22 19:53:00 2008
> +++ php-src/run-tests.php Wed Jul 23 16:10:14 2008
> @@ -24,7 +24,7 @@
>
> +--+
> */
>
> -/* $Id: run-tests.php,v 1.366 2008/07/22 19:53:00 felipe Exp $ */
> +/* $Id: run-tests.php,v 1.367 2008/07/23 16:10:14 lstrojny Exp $ */
>
> /* Sanity check to ensure that pcre extension needed by this script is
> available.
> * In the event it is not, print a nice error message indicating that this
> script will
> @@ -478,7 +478,7 @@
> $html_output =
> is_resource($html_file);
> break;
> case '--version':
> - echo '$Revision: 1.366 $' . "\n";
> + echo '$Revision: 1.367 $' . "\n";
> exit(1);
>
> default:
> @@ -1711,6 +1711,11 @@
>
> if (isset($section_text['EXPECTF'])) {
> $wanted_re = preg_quote($wanted_re, '/');
> + $wanted_re = str_replace(
> + array('%unicode\|string%',
> '%string\|unicode%'),
> + version_compare(PHP_VERSION,
> '6.0.0-dev') == -1 ? 'string' : 'unicode',
> + $wanted_re
> + );
> // Stick to basics
> $wanted_re = str_replace('%e', '\\' .
> DIRECTORY_SEPARATOR, $wanted_re);
> $wanted_re = str_replace('%s', '[^\r\n]+',
> $wanted_re);
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 feature freeze rapidly approaching
Hello Lukas, Wednesday, July 23, 2008, 1:26:00 PM, you wrote: > Hi, > This is just a reminder from your friendly co-RMs that the PHP 5.3 > feature freeze is rapidly approaching: > http://wiki.php.net/todo/php53 > As you can see there are still a bunch of open topics. For the very > important ones we have tried to contact the authors and work out a > schedule to get them done. If there is anything missing on this list > please make sure to let us know _ASAP_ (or forever hold your peace). > Please try to get your items done today or over the course of tomorrow > (we are not giving a specific timezone, but try for sooner rather than > later ..). Once we have reached the 25th, we will start being a bit > more strict, so again please make sure we know about the things you > want to do (this includes bug fixes - which we might deem feature > changes) so that things will go smoothly for an alpha1 on the 31st. > Thank you all for the work that has been done in the past weeks. > Things are shaping up nicely. My main worry point atm is that we are > not sure about the status of re2c. After alpha1 I will release a new re2c version: 0.14.0. I also have to do a few internal API changes: - exception handling, two new functions and a modified one plus a structure change. All of these changes deal with mem leaks in exception handling. However I haven't fixed all issues yet. - changing the error mode needs to be changed as well. Right now a function that uses this and calls a function that uses this as well will have wrong error handling mode after the inner call returns. And then there are these: - should we finally change: typedef int (*apply_func_args_t)(void *pDest, int num_args, va_list args, zend_hash_key *hash_key); to typedef int (*apply_func_args_t)(void *pDest TSRMLS_DC, int num_args, va_list args, zend_hash_key *hash_key); so that we can drop a bunch of TSRMLS_FETCH()'es. - should we use the alpha time to constify our c level API? I recently came across this while building PHP on another machine with C++ extensions and it is a major pain in the ass. Basically we have to disallow any help the compiler could give us. We might even find one or the other reall error doing so. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC question (Re: [PHP-DEV] [PATCH] Allow use($var..) statement ubiquitously)
I would like to keep this as a RFC page in wiki.php.net. Are there any conventions or rules that I should keep in mind? (or just-not- supposed-to-do-that-because-your-proposal-is-stupid-and-will-never-be- accepted?) Moriyoshi On 2008/07/18, at 8:23, Moriyoshi Koizumi wrote: Hi, Attached are the patches that allow the "use" statement that was introduced with closures to appear within every function statement except method definitions. I think this feature is a good addition because it resolves inconsistency between closures and unticked functions. In a nutshell, is equivalent to While, and are of course not the same.HEAD-20080718.patch.diff.txt>PHP_5.3-20080718.patch.diff.txt> Moriyoshi -- 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] 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 we can look into. Yes, I don't recall any crashes caused my ticks, too. -- Wbr, Antony Dovgal -- 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_2) / NEWS /main main.c php_ticks.c php_ticks.h
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. Andi > -Original Message- > 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 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 function > > > > What ever happened to the plan to deprecate/remove ticks? Just curious. > > Now that the ticks are deprecated, how am I supposed to catch signals in PHP? > Ticks are/were the only way (known to me) to do it. > > -- > Wbr, > Antony Dovgal > > -- > 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] [RFC] Zend Signal Handling
I want to give this a last consideration (by tomorrow). Main things are: - Checking into sigaction() support on various UNIX flavors. I am not sure that all exotic systems have it available and we want to be able to run on those (e.g. older IRIX, AIX, HP-UX versions). - Want to see what to do on Windows if anything. I don't believe we really covered this previously accept for our timeout thread so I think it is a non issue. I would prefer this patch to be in PHP 5.3 but I have a feeling we should keep the patch as-is and enable this to be configured out (don't care if it's implicit and not explicit). Andi > -Original Message- > From: Antony Dovgal [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 23, 2008 5:20 AM > To: Scott MacVicar > Cc: Lucas Nealan; internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC] Zend Signal Handling > > On 23.07.2008 16:08, Scott MacVicar wrote: > >> Do we really need this option? > >> Is someone going to disable it and why? > >> > > > > The defines need to be there for anyone who doesn't have sigaction > > available > > PHP_CHECK_FUNC(sigaction) in configure.in should be enough for that. > > -- > Wbr, > Antony Dovgal > > -- > 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] DVAL_TO_LVAL() change, different behavior
Johannes, this seems fairly critical to me. On 12.04.2008 14:45, Matt Wilmas wrote: 5.2 result: 0 255 0 1 2 1 0 255 254 5.3 result: 2147483647 255 255 255 255 1 0 0 0 No overflow now, except between LONG_MAX and ULONG_MAX. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DVAL_TO_LVAL() change, different behavior
Hi all, Just wanted to bring attention to this message again. Didn't hear any other opinions, but I think the change should be reverted. I wonder if there will be new bug reports about broken code if a public release is made as the code is now? - Matt - Original Message - From: "Matt Wilmas" Sent: Saturday, April 12, 2008 > Hi all, > > I have some code where I need to grab the last 1-3 bytes from numbers > (bitwise AND), and a few weeks ago I was looking to see how I'd handle the > possible, though unlikely, scenario of numbers > LONG_MAX (still only care > about those last bytes). But I realized it worked just fine with the & > operator (because of how overflow worked converting a double operand), and > could rely on that without needing an additional check/workaround. That was > with PHP 5.2. > > I remembered the DVAL_TO_LVAL() macro was changed in Dec. and checked things > just now with 5.3. Of course it's different with this code: > > $num = PHP_INT_MAX * 2 + 1; > > echo > (int) ($num + 1), "\n", > $num++ & 255, "\n", > $num++ & 255, "\n", > $num++ & 255, "\n", > $num & 255, "\n"; > > $num = -PHP_INT_MAX; > > echo > $num-- & 255, "\n", > $num-- & 255, "\n", > $num-- & 255, "\n", > $num & 255; > > 5.2 result: > 0 > 255 > 0 > 1 > 2 > 1 > 0 > 255 > 254 > > 5.3 result: > 2147483647 > 255 > 255 > 255 > 255 > 1 > 0 > 0 > 0 > > No overflow now, except between LONG_MAX and ULONG_MAX. > > It was changed for bug #42868, which is about a string function?! I see the > problem with overflow wrongly creating a negative start/offset param, etc. > but do people really have >2GB strings that they are passing values > > PHP_INT_MAX?? That bug refers to #30695, which resulted in a similar change > being reverted. The only difference is the earlier change caused a problem > at LONG_MAX, which this works around, only to move the same issue to > ULONG_MAX. > > Looks like the overflow-no-matter-what behavior has always been there (with > just a small tweak in 2001 -- zend_operators.c v1.105). I think I've seen > some commits elsewhere similar to the strspn() fix posted in the bug > report... That seems like a better way for these edge cases; or maybe a new > thing (conversion specifier?) for zend_parse_parameters() to limit longs to > LONG_MIN/LONG_MAX without overflow. > > So can the traditional, legacy overflow behavior be restored? > > > Thanks, > Matt -- 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_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 function What ever happened to the plan to deprecate/remove ticks? Just curious. Now that the ticks are deprecated, how am I supposed to catch signals in PHP? Ticks are/were the only way (known to me) to do it. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 feature freeze rapidly approaching
Hi Lukas, all, Don't know if my two Zend-related patches can be used, or how much time there is to add them (after alpha 1...?). Waiting to hear about "No runtime fetching of built-in global constants." And the second, "Some string changes/optimizations," I'm sure it's fine to update the syntax highlighting and remove the duplicate NOWDOC-related things (pretty trivial). Just wondering if the removal of the INIT_STRING opcode is acceptable. Otherwise... 1) As far as any of those re2c issues, *I* don't know about fixing them, and the few extra scanner tweaks/optimizations I said I had in mind can be done anytime. 2) There's a small bug (forever?) with handling of numeric string array keys (of LONG_MAX/LONG_MIN). Simple, will fix next, since you mentioned bugs. 3) The change that was made to the DVAL_TO_LVAL() macro, which I think should be reverted. Will send a follow-up reminder in a minute about that. Finally, there are a couple small things I had in mind for a while to send along sometime for opinions (haven't done any yet): *) Some consistency updates for formatted print (printf) stuff -- userland function and internal. Been a long time since I looked at any of it, so not sure about specifics! *) A small heredoc syntax addition after seeing an old feature request. *) Fix for old behavior/bug with preg_replace() and /e modifier where it causes weird escaping of quotes. Though this could mess up people that are using their own workaround as I would have, unless it's a flag/option. I know it may be too late for these things :*/, but just wanted to mention them, and I'd still send them to the list if done... I wouldn't consider them major or dangerous. Thanks Johannes and Lukas! - Matt - Original Message - From: "Lukas Kahwe Smith" Sent: Wednesday, July 23, 2008 > Hi, > > This is just a reminder from your friendly co-RMs that the PHP 5.3 > feature freeze is rapidly approaching: > http://wiki.php.net/todo/php53 > > As you can see there are still a bunch of open topics. For the very > important ones we have tried to contact the authors and work out a > schedule to get them done. If there is anything missing on this list > please make sure to let us know _ASAP_ (or forever hold your peace). > > Please try to get your items done today or over the course of tomorrow > (we are not giving a specific timezone, but try for sooner rather than > later ..). Once we have reached the 25th, we will start being a bit > more strict, so again please make sure we know about the things you > want to do (this includes bug fixes - which we might deem feature > changes) so that things will go smoothly for an alpha1 on the 31st. > > Thank you all for the work that has been done in the past weeks. > Things are shaping up nicely. My main worry point atm is that we are > not sure about the status of re2c. > > regards, > Johannes and Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] No runtime fetching of built-in global constants
Hi all, Never heard anything about this optimization after sending it 3 months ago (should've sent a follow-up sooner)... Is this something that can be done? Dmitry? Details in original message. Patch is unchanged, I just updated them for the current file versions. http://realplain.com/php/const_ct_optimization.diff http://realplain.com/php/const_ct_optimization_5_3.diff Thanks, Matt - Original Message - From: "Matt Wilmas" Sent: Friday, April 18, 2008 > Hi all, > > I changed things so that the many "built-in" constants (CONST_PERSISTENT > ones) will be replaced at compile-time, saving the FETCH_CONSTANT opcode, if > these changes are usable. This was added for TRUE/FALSE/NULL 2 years ago, > but seems like it can be done for "lots" of others too. > > Since the change 2 years ago, other constants have been getting looked up > also, but just discarded. And if a constant wasn't found, its name was > lowercased and looked up again (for case-insensitive TRUE/FALSE/NULL). > Lowercasing has been removed, since case-insensitive constants can't be done > (guess an exception was made for TRUE/FALSE/NULL :-)), and TRUE/FALSE/NULL > get flagged in the scanner (not reserved words, which Marcus did briefly a > few years ago), skipping a hash lookup. BTW, to get this compile-time > optimization in a namespace, it needs to be prefixed (::CONSTANT). > > I also removed an unnecessary memcmp() in zend_get_constant() -- old code > that was needed a long time ago, it appears. > > http://realplain.com/php/const_ct_optimization.diff > http://realplain.com/php/const_ct_optimization_5_3.diff > > Thoughts? > > > Thanks, > Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] New functions: array_replace[_recursive]
Hi Christian,
- Original Message -
From: "Christian Schneider"
Sent: Wednesday, July 23, 2008
> Matt Wilmas wrote:
> > array_replace() is like the + operator applied to arrays, except that it
> > WILL overwrite ("replace") existing entries.
>
> Excuse my ignorance but what's the difference between
> $array = array_replace($array1, $array2);
> and
> $array = $array2 + $array1;
> apart from different order of the entries in the resulting array?
The order of the entries is the only difference, I believe. :-) I think
that's desirable however, and having the non-recursive version makes it
match array_merge(), etc. As for bloat or something, there's virtually no
extra code: only PHP_FUNCTION() and then in the wrapper function it just
uses zend_hash_merge() just like the + operator, except with its "overwrite"
param set to 1.
> > array_replace_recursive() will do the same except that it becomes
> > recursive only when both the destination and source entries are
> > arrays, otherwise the new source entry still replaces any existing
> > one.
>
> Hmm, generic enough to be included?
What Lukas said. :-)
> - Chris
- Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
On 23.07.2008 16:08, Scott MacVicar wrote: Do we really need this option? Is someone going to disable it and why? The defines need to be there for anyone who doesn't have sigaction available PHP_CHECK_FUNC(sigaction) in configure.in should be enough for that. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] New functions: array_replace[_recursive]
On 23.07.2008, at 14:11, Christian Schneider wrote: array_replace_recursive() will do the same except that it becomes recursive only when both the destination and source entries are arrays, otherwise the new source entry still replaces any existing one. Hmm, generic enough to be included? A frequent use case is merging a multi dimensional configuration array with a multi dimensional array containing defaults. At the same time I cannot find a single use case for the current array_merge_recursive(). regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] New functions: array_replace[_recursive]
Matt Wilmas wrote:
> array_replace() is like the + operator applied to arrays, except that it
> WILL overwrite ("replace") existing entries.
Excuse my ignorance but what's the difference between
$array = array_replace($array1, $array2);
and
$array = $array2 + $array1;
apart from different order of the entries in the resulting array?
> array_replace_recursive() will do the same except that it becomes
> recursive only when both the destination and source entries are
> arrays, otherwise the new source entry still replaces any existing
> one.
Hmm, generic enough to be included?
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
Antony Dovgal wrote: On 23.07.2008 15:42, Scott MacVicar wrote: http://wiki.php.net/rfc/zendsignals The RFC looks really nice, but we need to make a decision on it really fast, since 5_3 feature freeze is set for tomorrow. I believe this can & should go in 5_3, any objections? Enable it by default and change -–enable-zend-signals to --disable-zend-signals Do we really need this option? Is someone going to disable it and why? The defines need to be there for anyone who doesn't have sigaction available, I guess I'm not bothered about having the option but if it is there it shouldn't be an explicit --enable Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
On 23.07.2008 15:42, Scott MacVicar wrote: http://wiki.php.net/rfc/zendsignals The RFC looks really nice, but we need to make a decision on it really fast, since 5_3 feature freeze is set for tomorrow. I believe this can & should go in 5_3, any objections? Enable it by default and change -–enable-zend-signals to --disable-zend-signals Do we really need this option? Is someone going to disable it and why? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
Antony Dovgal wrote: On 06.07.2008 22:56, Lucas Nealan wrote: Hi Internals, I am proposing the following RFC to improve signal handling in the Zend Engine: http://wiki.php.net/rfc/zendsignals The RFC looks really nice, but we need to make a decision on it really fast, since 5_3 feature freeze is set for tomorrow. I believe this can & should go in 5_3, any objections? Enable it by default and change -–enable-zend-signals to --disable-zend-signals Would be nice to get some sort of ZTS implementation in there, i'm less concerned about Windows it can be added at some other point. If it doesn't work out we can just disable it by default for the 5.3 release. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
On 06.07.2008 22:56, Lucas Nealan wrote: Hi Internals, I am proposing the following RFC to improve signal handling in the Zend Engine: http://wiki.php.net/rfc/zendsignals The RFC looks really nice, but we need to make a decision on it really fast, since 5_3 feature freeze is set for tomorrow. I believe this can & should go in 5_3, any objections? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] new PostgreSQL API
Hartmut Holzgraefe wrote: I finished testing now, the new test case "27large_object_oid.phpt" tests for the new parameters. The test passes with PostgreSQL 8.4 but fails with older versions as i haven't found a good way to test for the new capabilities in the skip test. i'm now testing by pg_version results and have split the test in two files, one skipped if pg_version<8.3, the other if <8.4 I committed my changes to the 5.3 branch only for now as the tests for "oid passed as string" fail in HEAD, i will commit there too once i have that fixed ... unicode string handling added for HEAD and committed MFB there, too -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Zend Signal Handling
On 06.07.2008, at 20:56, Lucas Nealan wrote: Hi Internals, I am proposing the following RFC to improve signal handling in the Zend Engine: http://wiki.php.net/rfc/zendsignals The purpose of zend internal deferred signal handling is to improve the stability of PHP and extensions when running under any forking SAPI. Additionally heavy users of APC or other bytecode caches under Apache 1.x may also see a performance improvement. Please see follow the link above to the complete RFC for details. I look forward to hearing feedback. Whats going on here. How does this all affect windows? Is this planned to go into 5.3? regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.3 feature freeze rapidly approaching
Hi, This is just a reminder from your friendly co-RMs that the PHP 5.3 feature freeze is rapidly approaching: http://wiki.php.net/todo/php53 As you can see there are still a bunch of open topics. For the very important ones we have tried to contact the authors and work out a schedule to get them done. If there is anything missing on this list please make sure to let us know _ASAP_ (or forever hold your peace). Please try to get your items done today or over the course of tomorrow (we are not giving a specific timezone, but try for sooner rather than later ..). Once we have reached the 25th, we will start being a bit more strict, so again please make sure we know about the things you want to do (this includes bug fixes - which we might deem feature changes) so that things will go smoothly for an alpha1 on the 31st. Thank you all for the work that has been done in the past weeks. Things are shaping up nicely. My main worry point atm is that we are not sure about the status of re2c. regards, Johannes and Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for HTTP successful status codes
Yeah. We discussed that quite a while back when I sent over the "ignore_errors" options patch-like thing in November: http://thread.gmane.org/gmane.comp.php.devel/46003 I think we should do it. But what about other 3xx redirect codes? How are those handled? David Am 22.07.2008 um 23:22 schrieb Stanislav Malyshev: Hi! codes as successful. This has posed some problems for us in writing RESTful applications effectively, as we're trying to take advantage of the full spectrum of successful codes. I think there should be no big problem to allow all 2xx codes, even though some ones like 204 may behave strangely, but as long as it doesn't break anything... -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- 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] ext/soap ctor errors
I know this is horribly old, but I just stumbled across the same issue
again and realized it has not been tackled yet.
Shouldn't we fix that for 5.3?
David
Am 08.01.2007 um 14:51 schrieb Knut Urdalen:
I agree with Lukas here, currently you have to be proactive against
the location of the WSDL-file. I currently do like this in my
SoapClient's:
class MySoapClient extends SoapClient {
public function __construct($wsdl ,$options = array()) {
if(is_resource(@fopen($wsdl, 'r'))) {
parent::__construct($wsdl, $options);
} else {
throw new Exception("Parsing WSDL: Couldn't load from '$wsdl'");
}
}
}
to be able to catch that problem as an Exception.
Regards,
Knut Urdalen
Lukas Kahwe Smith wrote:
Hi,
why do I get warnings when I have failures in my ext/soap ctor?
try {
$client = new SoapClient('http://i_dont_exist.com/some.wsdl',
array('exceptions' => true));
} catch (Exception $e) { }
I guess even without the 'exceptions' => true it should always
return all issues as an exception. I think this was agreed upon for
constructor errors in PHP5, no?
regards,
Lukas
--
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] [PATCH] RecursiveTreeIterator implementation
Hello Arnaud,
Wednesday, July 23, 2008, 8:36:53 AM, you wrote:
> Hello Marcus,
> On Wednesday 23 July 2008 01:16:14 Marcus Boerger wrote:
>> Hello Arnaud,
>>
>> Tuesday, July 22, 2008, 11:23:47 AM, you wrote:
>>
>> > Hello,
>>
>> >> > Care to look into the MultipleIterator next?
>> >>
>>
>> > That's done, for 5_3 [1] and HEAD [2].
>> > And a test [3][4] covering mostly all the cases.
>>
>> > [1] http://arnaud.lb.s3.amazonaws.com/MultipleIterator_5_3.patch
>> > [2] http://arnaud.lb.s3.amazonaws.com/MultipleIterator_HEAD.patch
>> > [3] http://arnaud.lb.s3.amazonaws.com/multiple_iterator_001_5_3.phpt
>> > [4] http://arnaud.lb.s3.amazonaws.com/multiple_iterator_001_HEAD.phpt
>>
>> Great work once more. I just moved the stuff all into spl_observer.c to
>> avoid increasing the amount of stuff that gets exported in the headers.
>> I also did a few minor tweaks and cleanups, nothing important though.
>>
>> - setFlags parses directly into &intern->flags which is a long for that
>> reason
>> - added !EG(exception) for the loops, though I have another patch that will
>> make exception handling better
>>
>> I've also upgraded you, you've got php-src access now, use it wisely :-)
> Thanks :) I will try to not break everything ;)
> I did not found anything about "Spl(Array|Index|Member)Reference" on the TODO,
> are there any discussion on that ?
Nope. My idea was to have an overloaded object that proxies writes to an
Arraym an Index and so forth. When you write to such an instance than
instead the saved reference would be written to.
class SplArrayReference {
function __construct(Array &$array, $index) {
$this->array = &$array;
$this->index = $index;
}
function __set($value) {
$this->array[$this->index] = $value;
}
//..
}
Where __set is the c-level zend_object_set_t set handler. Given its
concept, structure and the fact that we have closures now, it would
probably better to do those in pecl/Spl_Types. But I might be wrong
in my assumtion that all of these can be done by closures anyway.
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
