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.
On Tue, Jul 22, 2008 at 23:22, Stanislav Malyshev [EMAIL PROTECTED] wrote:
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
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]
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
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
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
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
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
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
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
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
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
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?
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
--
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
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.
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
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
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
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
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
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
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
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 uNonsense besides bBinary?
Question actually goes
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
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 uNonsense besides
-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
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
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
-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
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
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
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
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:
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.
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
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
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
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
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
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
41 matches
Mail list logo
