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?
>> >>
>>
>>
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 th
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 sc
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 g
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 ru
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_ve
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
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 free
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 di
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
--
PH
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 differenc
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/con
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
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
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
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 M
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 Wi
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 Dov
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
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 a
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
> importan
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 goe
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
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"Bina
-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
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 defau
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:
>
>
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 Deve
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 done
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
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 re
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 c
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 sile
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 oversight
> 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, rat
42 matches
Mail list logo
