Hello!
I packed PHP 4.4.1RC9 today, which you can find here:
http://downloads.php.net/derick/
Please test it carefully, and report any bugs in the bug system, but
only if you have a short reproducable test case.
If everything goes well, we will release it on August 7th. This will be
the last P
On 22.07.2008, at 09:03, Dmitry Stogov wrote:
dmitry Tue Jul 22 07:03:01 2008 UTC
Modified files: (Branch: PHP_5_3)
/php-src/ext/pharphar.c phar_internal.h phar_object.c
/php-src/ext/phar/tests frontcontroller11.phpt
/php-src/ext/phar/tests/cache_list
Hi Jani,
Please reply via the mailing list.
Works both ways...
You did weird ws changes in HEAD but not in 5.3 and vise-versa. That's
VERY bad thing considering this script must be SAME for both branches.
That file was nowhere near the same for both branches in the first place,
which is
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.
hi,
On Tue, Jul 22, 2008 at 12:29 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
> I'd understand better if I knew what you were talking about. Did I miss
> something during that 8-line merge? If so, wouldn't it be more normal to
> just tell me?
If it is not possible to test a change, it is always goo
If it is not possible to test a change, it is always good to take a
look at the snaps log. There was first an error about the confutils.js
script, runtime error.
Now that's just weird, because I _did_ test that. No errors here.
Then it was the error about a remaining phpinfo
section that sh
On Tue, Jul 22, 2008 at 12:42 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
>> section that should have been removed as well.
>
> Yes - I found it. Removed in HEAD now.
Yes, I fixed it earlier already :)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Devel
If it is not possible to test a change, it is always good to take a
look at the snaps log. There was first an error about the confutils.js
script, runtime error.
Now that's just weird, because I _did_ test that. No errors here.
Even weirder. There's no error in the snaps log regarding confut
Evan Priestley wrote:
> support more versions of PHP with your project. It's also
> straightforward to write a script that uses the tokenizer to safely and
> unambiguously remove trailing commas (I'd be happy to furnish such a
The script "convertsyntax.php" at http://cschneid.com/php/ already
prov
Yes - I found it. Removed in HEAD now.
Yes, I fixed it earlier already :)
Heh, I was wondering why the commit didn't go through :)
Thanks.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi,
I am sending this on behalf of Kalle:
1) Closures on class properties just don't work, the only way to do it
is
to do something like:
$c = $a->b;
$c();
Calling: $a->b(); will result in method A::B() does not exists.
2) Closures can be defined as constants values because of its toString
On 22.07.2008, at 13:04, Lukas Kahwe Smith wrote:
1) Closures on class properties just don't work, the only way to do
it is
to do something like:
$c = $a->b;
$c();
Calling: $a->b(); will result in method A::B() does not exists.
would be nice to get this fixed, but at worst it should be do
If it is not possible to test a change, it is always good to take a
look at the snaps log. There was first an error about the confutils.js
script, runtime error.
Now that's just weird, because I _did_ test that. No errors here.
Even weirder. There's no error in the snaps log regarding confut
On Tue, Jul 22, 2008 at 1:38 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
>
If it is not possible to test a change, it is always good to take a
look at the snaps log. There was first an error about the confutils.js
script, runtime error.
>>>
>>> Now that's just weird, because I _did_ tes
http://snaps.php.net/win32/snapshot-6.0.log (last log (06:30):
info.c
ext\standard\info.c(559) : error C2065: 'PHP_WINAPI_COMPILER' :
undeclared identifier
That has nothing to do with either configure.js or confutils.js.
Can we now move on please? I really have other things to do that
expla
On Tue, Jul 22, 2008 at 2:00 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
>
>> http://snaps.php.net/win32/snapshot-6.0.log (last log (06:30):
>>
>> info.c
>> ext\standard\info.c(559) : error C2065: 'PHP_WINAPI_COMPILER' :
>> undeclared identifier
>
> That has nothing to do with either configure.js or c
info.c
ext\standard\info.c(559) : error C2065: 'PHP_WINAPI_COMPILER' :
undeclared identifier
That has nothing to do with either configure.js or confutils.js.
Can you *PLEASE* read *ALL* my answer before replying withing seconds?
There was two problems:
1. the confutil.js
2. the info.c
I
On Tue, Jul 22, 2008 at 2:08 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
>
info.c
ext\standard\info.c(559) : error C2065: 'PHP_WINAPI_COMPILER' :
undeclared identifier
>>>
>>> That has nothing to do with either configure.js or confutils.js.
>>
>> Can you *PLEASE* read *ALL* my answer be
Hi Lukas,
1) Closures on class properties just don't work, the only way to do it is
to do something like:
$c = $a->b;
$c();
Calling: $a->b(); will result in method A::B() does not exists.
Yes, that's expected behaviour (we had a few comments on this on the
list). Compare this to, for example
From yesterday:
From *yesterday*?! Well, that would explain why it does no good to follow
your instructions and look at the snaps log, wouldn't it?
[17:47:26] c:\php4build\snap\configure.js(1342, 4)
Microsoft JScript runtime error: Unknown runtime error
[17:47:30] http://snaps.php.net/wi
Evan Priestley escreveu:
This was floated in 2003 but had weak advocation and didn't seem to come
to a decisive resolution:
http://marc.info/?l=php-internals&m=106685833011253&w=2
Basically, the proposal is to modify the grammar to allow trailing
commas in function and method calls, so th
Hi Christian,
Am Dienstag, den 22.07.2008, 14:15 +0200 schrieb Christian Seiler:
>
> >> Calling: $a->b(); will result in method A::B() does not exists.
>
> Yes, that's expected behaviour (we had a few comments on this on the
> list).
Hm, I'm not sure who expected it that way. At least Stas and
Now stop to discuss this problem. If there is anything left not merged
in HEAD then please send a patch. If not, then the problem is solved,
end of the discussion.
There will be, because obviously that code is working in 5_3.
Sorry to harp on about this, but I still can't break it here. No i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
The HTTP wrapper currently only accepts status codes 200 and 206 as
successful in the 2xx range. Response codes like 202 (Accepted) fail and
throw a warning. However, the HTTP specification defines all 2xx status
codes as successful. This has
Posting to newsgroup php.internals, you wrote:
> [...]
> round(), on the other hand, does more than the standard C functions do:
> With the additional places argument, it allows to round not only to
> integers but to arbitrary places. And this is precisely the thing that
> causes all the problems.
On Tue, Jul 22, 2008 at 3:31 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
>
>>> Now stop to discuss this problem. If there is anything left not merged
>>> in HEAD then please send a patch. If not, then the problem is solved,
>>> end of the discussion.
>>
>> There will be, because obviously that code is
Does anyone know the conditions that broke the script in HEAD, e.g. which
extension/what was missing? Even throwing away the libxml libraries
doesn't
cause an error here.
Easiest way to reproduce the runtime error in confutil is to empty the
lib/ dir and leave only resolv's files.
Heh...
2008/7/22 Rodrigo Saboya <[EMAIL PROTECTED]>
> Evan Priestley escreveu:
>
>> This was floated in 2003 but had weak advocation and didn't seem to come
>> to a decisive resolution:
>>
>>http://marc.info/?l=php-internals&m=106685833011253&w=2
>>
>> Basically, the proposal is to modify the grammar
On Tue, Jul 22, 2008 at 4:31 PM, Steph Fox <[EMAIL PROTECTED]> wrote:
>
>>> Does anyone know the conditions that broke the script in HEAD, e.g. which
>>> extension/what was missing? Even throwing away the libxml libraries
>>> doesn't
>>> cause an error here.
>>
>> Easiest way to reproduce the runti
2008/7/22 Richard Quadling <[EMAIL PROTECTED]>
>
>
> 2008/7/22 Rodrigo Saboya <[EMAIL PROTECTED]>
>
> Evan Priestley escreveu:
>>
>>> This was floated in 2003 but had weak advocation and didn't seem to come
>>> to a decisive resolution:
>>>
>>>http://marc.info/?l=php-internals&m=10668583301125
It was broken, it works now, problem solved, end of the discussion.
Well not really, because HEAD and 5_3 are now different and the fact that we
don't know *why* it failed in HEAD means we don't know if there's a problem
in 5_3.
Waiting for your patches if you need something else in HEAD.
Hi!
Note too that the value actually stored in $f differs from that we may expect
simply reading the source: the difference is very small, but it exists. "Float"
values can always be converted back in decimal base with exact precision, so
for example in our case the $f variable now contains exac
Richard Quadling wrote:
> Actually, would allowing PHP to skip defaulted parameters be a better
> facility to add?
>
> function foo($opt1 = Null, $opt2 = Null){}
>
> foo(,True);
I agree that it would be ugly but possibly useful. OTOH I think it's
better to switch to named parameters in such a ca
Hi all,
Adding these two array functions has been on the TODO for a while, and my
original patch has been collecting dust for almost 2 years. :-) I just
updated the patches now after some small changes (the original version for
5.2 is currently linked on the wiki). A brief description, if I reme
Hi!
so do we even want the toString() method?
IMHO we should drop toString from Closure.
Maybe it could return some relevant information for exporting the
closure across
data
not a huge biggy to me.
I don't think Closure can be meaningfully exported. Can we prohibit it?
I guess this is
Hi!
Hm, I'm not sure who expected it that way. At least Stas and myself
voted *for* allowing it. We need to discuss the semantics (the order how
methods are resolved, interceptors) but I had the feeling that most of
use really much liked that feature.
I'm all for doing it, the problem is the s
Hi Stas,
Am Dienstag, den 22.07.2008, 13:09 -0700 schrieb Stanislav Malyshev:
[...]
> I'm all for doing it, the problem is the syntax $foo->bar() is already
> used. But you can do $foo->bar->__invoke()!
Can't we change zend_std_get_method() to return a zend_internal_function
struct in case of a
Hello Lars,
actually this is a very good idea and should work :-)
marcus
Tuesday, July 22, 2008, 10:15:03 PM, you wrote:
> Hi Stas,
> Am Dienstag, den 22.07.2008, 13:09 -0700 schrieb Stanislav Malyshev:
> [...]
>> I'm all for doing it, the problem is the syntax $foo->bar() is already
>> us
Hello Stanislav,
Tuesday, July 22, 2008, 10:08:11 PM, you wrote:
> Hi!
>> so do we even want the toString() method?
> IMHO we should drop toString from Closure.
Sam here. It makes no sense anyway. This mail thread just proved that.
>>> Maybe it could return some relevant information for expor
Hi!
Can't we change zend_std_get_method() to return a zend_internal_function
struct in case of a closure on a property? The only thing that needs to
That means that:
1. We can't have properties named same as functions anymore
2. We'd have to check properties every time method name was not foun
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 strang
On 10.07.2008, at 01:21, Nuno Lopes wrote:
I didn't test it, but yeah that should fix the # problem. :-) BTW,
I also
had other ideas about checking for , etc. tags in
the inline
HTML scanning part, so the largest chunk of HTML is always grabbed
(I'll
send the patch in the future; didn't m
Hello Stanislav,
Tuesday, July 22, 2008, 11:07:58 PM, you wrote:
> Hi!
>> Can't we change zend_std_get_method() to return a zend_internal_function
>> struct in case of a closure on a property? The only thing that needs to
> That means that:
> 1. We can't have properties named same as functions
Hi!
Nope. It means if you have a function named foo and a property foo that
sores a closure and then call foo(), then obviously the function is called
rather than the closure.
That means you can't call the closure, and nothing alerts you of the
problem.
2. We'd have to check properties eve
Hello Lukas,
you are right, like PDO we decided we have far too many large change than
allowing us to handle in both HEAD and 5.3. We'll sync latest when 5.3 is
out.
marcus
Tuesday, July 22, 2008, 10:18:31 AM, you wrote:
> On 22.07.2008, at 09:03, Dmitry Stogov wrote:
>> dmitry
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
Hello Stanislav,
Wednesday, July 23, 2008, 12:54:48 AM, you wrote:
> Hi!
>> Nope. It means if you have a function named foo and a property foo that
>> sores a closure and then call foo(), then obviously the function is called
>> rather than the closure.
> That means you can't call the closure,
Hi!
H, the amount of problems is pretty long. So even though it might sound
cool to do it. It is the better deceision to not allow it. Also you've
shown several paths where it would slow general execution down. Yet I hate
not being able to easily make it work.
Well, $foo->bar->__invoke() i
Tatsuo Ishii wrote:
I think it should return errors in the case. The intention for the
PostgreSQL API is, avoiding automatic oid assigning by
PostgreSQL. This is necessary for query based replication tools such
as pgpool. Plus, if PostgreSQL fails to assign the specified oid, the
transaction will
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
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
51 matches
Mail list logo
