On Wed, Jul 23, 2008 at 7:54 PM, 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
Hi Matt,
Sorry if I missed it.
Does this patch make any performance difference?
I assume it saves on hash lookup during compilation and its really
insignificant time. However it add new scanner rules which may slowdown
the whole scanner.
For now I don't see a big reason, but may be I didn't
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
Aside from the question of how to write a portable test, here is an
example speaking for your argument of making a
Hi,
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,
strtotime() has
Hi!
so do we even want the toString() method?
IMHO we should drop toString from Closure.
There is one case which *may* cause problems:
function doSomething ($callback) {
if (!is_callable ($callback)) {
throw new Exception (...);
}
// special treatment
if ($callback ==
Hi,
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?
We had that in a previous patch. We had quite a few discussions on what
the best syntax would be, actually.
In the end, Dmitry and I chose to implement it in
On 24.07.2008, at 11:10, Christian Seiler wrote:
Personally, I don't care whether a object-to-string cast is present or
not.
So lets remove it?
I don't think Closure can be meaningfully exported. Can we prohibit
it?
Unfortunately, currently not, see the var_export code.
I think we can
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Thursday, July 24, 2008
Hi Matt,
Sorry if I missed it.
No problem. :-)
Does this patch make any performance difference?
I assume it saves on hash lookup during compilation and its really
insignificant time. However it add
Okay, we're taking care of that.
David
Am 23.07.2008 um 22:49 schrieb Lukas Kahwe Smith:
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,
So... who's gonna commit it? :)
David
Am 23.07.2008 um 19:40 schrieb Noah Fontes:
-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:
Hi,
I'd like to add the following patch to reflection before the feature
freeze, because it does not change any current reflection behaviour but
adds quite a bit of good stuff for closures.
With the current closure implementation, __invoke always has the same
signature as the original lambda
According to constants patch, it definitely will break PHP encoders and
may be opcode caches, but as you mentioned the compiler_option will
solve the issue. In this case we probable may substitute any constants
(not only persistent). Anyway I don't see a big reason for special
handling of
David Zülke wrote:
So... who's gonna commit it? :)
I'll commit in the next few hours if nobody objects.
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I would propose the attached patch for this optimization.
Opcode caches and encoders will have to disable this optimization with
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION
Any objections?
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent:
Em Qua, 2008-07-23 às 18:52 +0200, Marcus Boerger escreveu:
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
Ah, yes, the change responsible is the following:
http://cvs.php.net/viewvc.cgi/php-src/ext/date/lib/timelib.h?
r1=1.10.2.11.2.4r2=1.10.2.11.2.5pathrev=PHP_5_2
It fixes bug #44209 http://bugs.php.net/bug.php?id=44209.
OK, thanks, it's good to understand the change in behavior.
Or to
Hi!
This 64-bit machine is running 5.2.5 and returns false on the all-zero
datetime string. It was upgraded last week to 5.2.6 and started
returning the large negative integer.
Ah, yes, the change responsible is the following:
I'm not sure that there's any problem with the documentation (although it
wouldn't hurt to mention it in the comments). What is it about -00-00
00:00:00 that makes it an invalid date? (See Christian's explanation)
Zach
On Thu, Jul 24, 2008 at 11:09 AM, Jack Steadman [EMAIL PROTECTED]
wrote:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Thursday, July 24, 2008
According to constants patch, it definitely will break PHP encoders and
may be opcode caches, but as you mentioned the compiler_option will
solve the issue. In this case we probable may substitute any
I'm not sure that there's any problem with the documentation
(although it wouldn't hurt to mention it in the comments).
What is it about -00-00 00:00:00 that makes it an
invalid date? (See Christian's explanation)
Zero values for month and day are NOT valid. PHP treats them as valid,
Thank you for taking the time to explain this to me. A couple more
points below:
strtotime() has always accepted month and day numbers 0 in order to
express last month of the previos year and last day of the previous
month. Take:
So my biggest issue with this is that it's exception-case
Hi again Dmitry,
Well, that should get the main runtime optimization job done just as well.
:-) I was just trying for more compile-time improvement also (it was
definitely measurable with fake tests), especially for those not using an
opcode cache, with no lookup needed for the 3 basic
Thank you for noticing SID issue.
So it seems like we able to substitute only persistent constants.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi again Dmitry,
Well, that should get the main runtime optimization job done just as well.
:-) I was just trying for more compile-time improvement also (it
On Jul 24, 2008, at 11:30 AM, Jack Steadman wrote:
The upshot is that we can't actually rely on strtotime to determine
whether a string is a valid date/time. The docs don't ever explicitly
say that the date strings themselves are checked for validity, but
returning false on failure implies to
Hello Felipe,
awesome Just commit.
marcus
Thursday, July 24, 2008, 5:08:03 PM, you wrote:
Em Qua, 2008-07-23 às 18:52 +0200, Marcus Boerger escreveu:
And then there are these:
- should we finally change:
typedef int (*apply_func_args_t)(void *pDest, int num_args, va_list args,
Hi!
b.php:
?php
namespace Foo;
class A {
function __construct() {throw new Exception('hi');}
Here in your proposal exhaustive autoload happens for all cases where
you do not actually override Exception in Foo.
?php
include 'a.php';
include 'b.php';
try {
$a = new A;
} catch
Now that Subversion 1.5 has been out for a little while and it is at the
point where it might actually have some benefit to us, do we have some
volunteers who have some time to try converting over the repository and
all the post-commit and ACL rules from CVSROOT?
Talking to people here at
On Jul 24, 2008, at 8:05 PM, Rasmus Lerdorf wrote:
Now that Subversion 1.5 has been out for a little while and it is at
the point where it might actually have some benefit to us, do we
have some volunteers who have some time to try converting over the
repository and all the post-commit and
On Thu, Jul 24, 2008 at 8:05 PM, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
Now that Subversion 1.5 has been out for a little while and it is at the
point where it might actually have some benefit to us, do we have some
volunteers who have some time to try converting over the repository and all
Gwynne Raskind wrote:
On Jul 24, 2008, at 8:05 PM, Rasmus Lerdorf wrote:
Now that Subversion 1.5 has been out for a little while and it is at
the point where it might actually have some benefit to us, do we have
some volunteers who have some time to try converting over the
repository and all
On Jul 24, 2008, at 8:23 PM, Rasmus Lerdorf wrote:
Now that Subversion 1.5 has been out for a little while and it is at
the point where it might actually have some benefit to us, do we
have
some volunteers who have some time to try converting over the
repository and all the post-commit and
I'd love to see this conversion. Let's make sure we get enough folks to
volunteer to check the history of our source trees although we should in
any case keep the CVS one around for browsing just in case...
Andi
-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Sent:
I've done a bunch of stuff with svn commit hooks and am willing to
lend a hand.
-lucas (mobile)
On Jul 24, 2008, at 17:06, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
Now that Subversion 1.5 has been out for a little while and it is at
the point where it might actually have some benefit to
On Thu, Jul 24, 2008 at 8:28 PM, Andi Gutmans [EMAIL PROTECTED] wrote:
I'd love to see this conversion. Let's make sure we get enough folks to
volunteer to check the history of our source trees although we should in
any case keep the CVS one around for browsing just in case...
Is this
If it's not happening in the next month, I'd be happy to help. I did
the SimpleTest CVS to SVN conversion in about 5 minutes (including
waiting on the history to be converted). I've also worked with the hook
scripts and such in SVN so I might be able to help out there if someone
else doesn't
At this point it's clear that moving from CVS to SVN for PHP has
become a more or less official project. As such, there is a new
mailing list [EMAIL PROTECTED] for anyone who wants to
help with the move. If you're familiar with what I've already done so
far
On Jul 24, 2008, at 10:14 PM, Sean Coates wrote:
Do we have a preference of Apache's SVN or svnserve?
The former requires Apache 2+, AFAIK.
I'd like to kick this discussion over to the svn-migration@ list;
there are a lot of points to consider in this question and internals@
has enough
37 matches
Mail list logo
