[PHP-DEV] PHP 4.4.9RC1
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 PHP 4.4 release. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/phar phar.c phar_internal.h phar_object.c /ext/phar/tests frontcontroller11.phpt /ext/phar/tests/cache_list frontcontroller11.phpt /ext/phar/tests
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 frontcontroller11.phpt /php-src/ext/phar/tests/cache_list/files frontcontroller6.phar frontcontroller7.phar /php-src/ext/phar/tests/filesfrontcontroller5.phar frontcontroller6.phar frontcontroller6.phar.inc frontcontroller7.phar frontcontroller7.phar.inc /php-src/ext/phar/tests/tar frontcontroller11.phar.phpt /php-src/ext/phar/tests/tar/filesfrontcontroller6.phar.inc frontcontroller6.phar.tar frontcontroller7.phar.inc frontcontroller7.phar.tar /php-src/ext/phar/tests/zip frontcontroller11.phar.phpt /php-src/ext/phar/tests/zip/filesfrontcontroller6.phar.inc frontcontroller6.phar.zip frontcontroller7.phar.inc frontcontroller7.phar.zip Log: Improved webPhar speed (frontcontroller11.phar.phpt is disabled, should be removed) Hmm .. am I right to assume that phar is currently only being developed in 5.3 and HEAD is kept out of sync? Lukas Kahwe Smith [EMAIL PROTECTED] -- 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(PHP_5_3) / run-tests.php
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 precisely why syncing ws fixes wasn't high on my list of priorities. You could have just poked me... If you can't keep it in sync, don't touch it. Otherwise the bunnies get it.. Those poor bunnies :) Feel free to commit the help texts. I'm done with it. Thanks, will do. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] RecursiveTreeIterator implementation
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 Regards, Arnaud -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 good to take a look at the snaps log. There was first an error about the confutils.js script, runtime error. Then it was the error about a remaining phpinfo section that should have been removed as well. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 should have been removed as well. Yes - I found it. Removed in HEAD now. - Steph -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 confutils.js at all. So what are you talking about? Can you show me? - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Modify language grammar to allow trailing commas in function/method calls
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 provides this functionality so this is already covered :-) - Chris -- 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 /win32/build confutils.js
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
[PHP-DEV] closures questions
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
method:
define('Closure', function(){ echo 'Test'; });
echo constant('Closure'); /* (string) Closure object */
3) Since Closures have this toString method, but its not showing up in
Reflection:
Reflection::export(new ReflectionClass('Closure'));
4) var_export() and Closures is useless, any call to var_export() like
the example
below will all be the same:
$lambda = function()
{
echo 'Λ Lambda';
};
var_export($lambda);
/*
Closure::__set_state(array(
))
*/
Maybe it could return some relevant information for exporting the
closure across
data
5) Its impossible to clone a closure using the cloning keyword:
$a = function(){};
$b = clone $a;
This makes it hard to make a copy of the closure because of objects
always are
passed by reference.
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] closures questions
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 documented.
2) Closures can be defined as constants values because of its
toString method:
define('Closure', function(){ echo 'Test'; });
echo constant('Closure'); /* (string) Closure object */
3) Since Closures have this toString method, but its not showing up
in Reflection:
Reflection::export(new ReflectionClass('Closure'));
so do we even want the toString() method?
4) var_export() and Closures is useless, any call to var_export()
like the example
below will all be the same:
$lambda = function()
{
echo 'Λ Lambda';
};
var_export($lambda);
/*
Closure::__set_state(array(
))
*/
Maybe it could return some relevant information for exporting the
closure across
data
not a huge biggy to me.
5) Its impossible to clone a closure using the cloning keyword:
$a = function(){};
$b = clone $a;
This makes it hard to make a copy of the closure because of objects
always are
passed by reference.
I guess this is a draw back from the OO approach (rather than the
original resource approach), but solvable?
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: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 confutils.js at all. So what are you talking about? Can you show me? Still can't reproduce this, even with a snapshot build. Could you please put the code back as it was - i.e, working? Thanks, - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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_ test that. No errors here. >> >> Even weirder. There's no error in the snaps log regarding confutils.js at >> all. >> >> So what are you talking about? Can you show me? > > Still can't reproduce this, even with a snapshot build. Could you please put > the code back as it was - i.e, working? 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 Can we now move on please? I really have other things to do that explaining why/what/where is (it) broken, problem solved, let us go back to work now. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 explaining why/what/where is (it) broken, problem solved, let us go back to work now. Would you please put my working code back into confutils.js? Thank you, - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 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 -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 did. But a) I can't reproduce any issues at all with confutils.js prior to your changes and b) there's no log pertaining to any config-related error at all. If the error ever existed, I'd like to know what it was so that I can fix the code properly, as opposed to simply reverting the code to a point where it can't work. Thanks, - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 before replying withing seconds? >> >> There was two problems: >> >> 1. the confutil.js >> 2. the info.c > > I did. But a) I can't reproduce any issues at all with confutils.js prior to > your changes and b) there's no log pertaining to any config-related error at > all. If the error ever existed, I'd like to know what it was so that I can > fix the code properly, as opposed to simply reverting the code to a point > where it can't work. >From yesterday: [17:47:26] c:\php4build\snap\configure.js(1342, 4) Microsoft JScript runtime error: Unknown runtime error [17:47:30] http://snaps.php.net/win32/snapshot-6.0.log 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. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] closures questions
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:
function hello () { echo "Hello World!\n"; }
$a->b = 'hello';
$c = $a->b;
$a->b (); // undefined method
$c (); // works
But, as closures implement the __invoke method, it's possible to do
this:
$a->b->__invoke ();
or, of course
call_user_func ($a->b);
(which works with all types of callbacks, even non-closures)
so do we even want the toString() method?
Personally, I don't care.
4) var_export() and Closures is useless
What would you suggest? Having var_export return the function body for
the closures? But what about bound variables? Well, perhaps in the
future you could even export all the bound variables. But for know to
keep it simple I'd say it's best that closures can't be exported.
5) Its impossible to clone a closure using the cloning keyword:
$a = function(){};
$b = clone $a;
That's intended behaviour. What would be the clone of a closure?
Especially with bound variables? This would allow for all sorts of weird
behaviour.
Take, for example, the following:
class Foo {
private $someProperty;
function getPrinter ($outputDevice) {
return function ($text) use ($outputDevice) {
$outputDevice->print ($this->someProperty, $text);
};
}
}
How would you clone that? There are two bound variables in this closure:
$this and $outputDevice. Do you clone them both? Do you clone only
$this? Do you clone only $outputDevice? If you only clone the closure
object itself, it won't change the behaviour from simply creating
another reference to it...
If one *really* needs a clonable *and* callable object, write a class
that implements __clone and __invoke. Then the programmer can control
the exact semantics. Everything else would simply be extremely confusing.
And, if I take another language such as Python for example, there you
can't clone closures either, y = copy.deepcopy (closure) returns the
same object.
This makes it hard to make a copy of the closure because of objects
always are
passed by reference.
I guess this is a draw back from the OO approach (rather than the
original resource approach), but solvable?
No, the original resource approach was just the same. A resource is
basically an integer value which is then used to look up some specific
data. You can't clone a resource either.
Regards,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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/win32/snapshot-6.0.log Y'know, email works... it would've been very simple to just notify me of both issues at the time rather than setting up a public argument about either/both a day later. 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. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Modify language grammar to allow trailing commas in function/method calls
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 this becomes a parseable PHP construct: f(1, 2, 3,); This patch applies only to function and method calls; it does not apply to function or method definitions. It also does not allow the degenerative case of "f(,)". The real value of relaxing this rule is in nontrivial cases that span across multiple lines: sprintf( 'long example pattern with %d conversions: %s', $several, $conversions ); You could just do this: sprintf( 'long example pattern with %d conversions: %s' ,$several ,$conversions ); I really don't see a great benefit here, and as you pointed out it would make code written with trailing commas incompatible with previous versions of PHP. -- Rodrigo Saboya -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] closures questions
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 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. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 idea why it should have failed in HEAD on the snaps box. The file was 100% identical to the 5_3 version until you committed your changes, and the 5_3 snaps aren't broken. And the point of reported breakage is even weirder - it comes on an equivalent line to AC_DEFINE(). 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. Thanks, - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch for HTTP successful status codes
-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 posed some problems for us in writing RESTful applications effectively, as we're trying to take advantage of the full spectrum of successful codes. The patch to fix this problem is relatively straightforward; see http://cynigram.com/~nfontes/http_fopen_wrapper.patch If anyone could take a look at this, I would be most grateful. Thanks and regards, Noah - -- Noah Fontes Bitextender http://www.bitextender.com/ Phone: +1 919 349 9826 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIheUThitK+HuUQJQRArGfAKCJsEZ8QDFcWpoI4g2ZsbzGVsCAxgCgtZEk 7S66/HWfSf16D2FxUTMVsGU= =zalu -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Rounding in PHP and floating point numbers in general
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. ;-)
Agree, all the problems you pointed out are due to the different representation
of the floating point numbers ("float" for short) against the decimal numbers
we humans are used to write.
A "float" is typically a 53 bits number (IEEE 754 double precision) that can
always be represented exactly as decimal.
But the vice-versa it not true, and also very simple decimal numbers do not
have a finite "float" rapresentation and must be trunked or rounded. So for
example the number 0.1(dec) takes infinite decimal binary gigit once
converted to float:
0.1(dec) = 0.00011001100110011001100110011001100110011...(bin)
Since IEEE 754 double-precision numbers hold 53 bits, this value has to be
rounded to
0.00011001100110011001100110011001100110011001100110011010(bit)
(note the rounding on the last 2 binary digits). This latter value is what will
be stored in the $f variable after a statement like this one:
$f = 0.1;
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 exactly
$f == 0.155511151231257827021181583404541015625(dec)
No surprise on that: the "error" was introduced by the PHP parser itself
when the statement "$f = 0.1;" was encountered the first time.
Now going back to the round() function, it is completely misleading to
analize statements like this one
echo round(0.285, 2);
because here we have actually two conversion problems:
1. The "0.285" decimal number must be converted to "float" at the parse
stage of the PHP interpreter, and that brings to "unexpected" results
due to the rounding performed in this conversion.
2. The round() function gets a number that already differs from that we
see in the source, then it perfoms its calculations thinking at the
number as it were a decimal number (multiplying by a power of 10,
adding a rounding term, and then trunking the result), and then
performs a division by a negative power of 10 that cannot be
represented exactly with a float and that must be rounded before the
division be performed, and then the result of the division must be
rounded again to finally give the result of the function.
All these dec-to-bin conversions and "float" roundings sometimes bring to
unexpected results as already pointed out in the 42294 bug: we (humans)
continue to think at numbers like 0.285 as it they were decimals, but these
numbers are actually handled in a completely different base inside the
computer.
The only real bug is the round() function itself, and number_format() or
printf() should be used instead, because these function first convert the
binary float to decimal, and then perform the rounding over the decimal number.
But remember that also these functions operates on floats, i.e. numbers that
already may differ from those we see in the PHP source, so also with these
function we can see "strange" results.
If we really want a round() function, this function should operate just like
number_format() and printf() already do, i.e. returning a string, not a double,
or the second argument of the function should be "deprecated" or dropped at
all.
A final note: programmers concerned with rounding problems and looking for
"exact" results while dealing with floating point numbers are usually
erroneusly using "float" values to store monetary values as if PHP were a desk
calculator, rather than use BCMath or other specialized high-precision library
suitable for business applications.
Just my 0.0199 Euros.
Regards,
___
/_|_\ Umberto Salsi
\/_\/ www.icosaedro.it
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 working in 5_3. > > Sorry to harp on about this, but I still can't break it here. No idea why it > should have failed in HEAD on the snaps box. The file was 100% identical to > the 5_3 version until you committed your changes, and the 5_3 snaps aren't > broken. And the point of reported breakage is even weirder - it comes on an > equivalent line to AC_DEFINE(). > > 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. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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... Checking for arpa\nameser.h ... ..\bindlib_w32 Checking for library resolv_a.lib ... Checking for library resolv.lib ... ERROR: We really need that arpa\nameser.h file - it is part of the bindlib package Actually with that fixed, the thing *still* works for me in HEAD. Sounds like a good idea but... doesn't help here. I'm going to drop this for now and investigate when I've time. But it really wasn't a nasty merging accident (unlike the other one), it's just a weird and - for me at least - unreproducible error. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Modify language grammar to allow trailing commas in function/method calls
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 to allow trailing commas >> in function and method calls, so this becomes a parseable PHP construct: >> >>f(1, 2, 3,); >> >> This patch applies only to function and method calls; it does not apply to >> function or method definitions. It also does not allow the degenerative case >> of "f(,)". >> >> The real value of relaxing this rule is in nontrivial cases that span >> across multiple lines: >>sprintf( >>'long example pattern with %d conversions: %s', >>$several, >>$conversions >>); >> >> > You could just do this: > > sprintf( >'long example pattern with %d conversions: %s' >,$several >,$conversions > ); > > I really don't see a great benefit here, and as you pointed out it would > make code written with trailing commas incompatible with previous versions > of PHP. > > -- > Rodrigo Saboya > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Just thinking of other languages that allow you to skip params simply by using commas. Whilst this isn't supported in PHP, allowing a trailing comma and skipped parameters could look quite interesting! foo(,,,); I must admit, I get stung with this in JS when I'm building AJAX option sets through Prototype for IE (I think like arrays in PHP which allow trailing ,), but I soon learned to do it properly. I don't see this as a huge advantage. Regards, Richard Quadling. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!"
Re: [PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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 runtime error in confutil is to empty the >> lib/ dir and leave only resolv's files. > > Heh... > > Checking for arpa\nameser.h ... ..\bindlib_w32 > Checking for library resolv_a.lib ... > Checking for library resolv.lib ... > ERROR: We really need that arpa\nameser.h file - it is part of the bindlib > package > > Actually with that fixed, the thing *still* works for me in HEAD. Sounds > like a good idea but... doesn't help here. > > I'm going to drop this for now and investigate when I've time. But it really > wasn't a nasty merging accident (unlike the other one), it's just a weird > and - for me at least - unreproducible error. It was broken, it works now, problem solved, end of the discussion. Waiting for your patches if you need something else in HEAD. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Modify language grammar to allow commas to skip defaulted parameters.
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=106685833011253&w=2
>>>
>>> Basically, the proposal is to modify the grammar to allow trailing commas
>>> in function and method calls, so this becomes a parseable PHP construct:
>>>
>>>f(1, 2, 3,);
>>>
>>> This patch applies only to function and method calls; it does not apply
>>> to function or method definitions. It also does not allow the degenerative
>>> case of "f(,)".
>>>
>>> The real value of relaxing this rule is in nontrivial cases that span
>>> across multiple lines:
>>>sprintf(
>>>'long example pattern with %d conversions: %s',
>>>$several,
>>>$conversions
>>>);
>>>
>>>
>> You could just do this:
>>
>> sprintf(
>>'long example pattern with %d conversions: %s'
>>,$several
>>,$conversions
>> );
>>
>> I really don't see a great benefit here, and as you pointed out it would
>> make code written with trailing commas incompatible with previous versions
>> of PHP.
>>
>> --
>> Rodrigo Saboya
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> Just thinking of other languages that allow you to skip params simply by
> using commas. Whilst this isn't supported in PHP, allowing a trailing comma
> and skipped parameters could look quite interesting!
>
> foo(,,,);
>
>
> I must admit, I get stung with this in JS when I'm building AJAX option
> sets through Prototype for IE (I think like arrays in PHP which allow
> trailing ,), but I soon learned to do it properly.
>
> I don't see this as a huge advantage.
>
> Regards,
>
> Richard Quadling.
> --
> -
> Richard Quadling
> Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
> "Standing on the shoulders of some very clever giants!"
>
Actually, would allowing PHP to skip defaulted parameters be a better
facility to add?
function foo($opt1 = Null, $opt2 = Null){}
foo(,True);
Hmm. Doesn't look good does it. But, useful. Having to supply the default
value if you don't want to override the default is sort of
counter-intuitive. Suppling nothing should equal the default value.
Regards,
Richard.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
[PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-DEV] Re: [INTERNALS-WIN] Re: [PHP-CVS] cvs: php-src /win32/build confutils.js
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. Oh please. I missed ONE line in ONE merge. That is not a reason to play this game. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Rounding in PHP and floating point numbers in general
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 exactly
$f == 0.155511151231257827021181583404541015625(dec)
No surprise on that: the "error" was introduced by the PHP parser itself
when the statement "$f = 0.1;" was encountered the first time.
Yes, sure. But IEEE 754 guarantees that the first 15 significant decimal
digits are correct (for double precision anyway), and in your example,
the first 17 significant decimal digits are in fact correct.
So, if you always round to the first 15 significant decimal digits when
outputting the floats, you always get correct results within that
decimal precision.
All these dec-to-bin conversions and "float" roundings sometimes bring to
unexpected results as already pointed out in the 42294 bug: we (humans)
continue to think at numbers like 0.285 as it they were decimals, but these
numbers are actually handled in a completely different base inside the
computer.
Look it from this perspective: If you do echo 0.285 in current PHP, it
will output 0.285. This is due to the 'precision' ini setting (default
is 14) that implicitly rounds the result. And within those 14 decimal
digits, the results ARE guaranteed to be exact by IEEE 754.
The only real bug is the round() function itself, and number_format() or
printf() should be used instead, because these function first convert the
binary float to decimal, and then perform the rounding over the decimal number.
Not entirely true. ;-) number_format() uses round internally (math.c,
PHP 5.3 branch, line 944).
And, sprintf ("%.2f", 0.285) == "0.28" btw. - because even if you
convert the float back to a full decimal number, you get
0.28499...something, so converting to string and rounding then
doesn't work either (at least not as a user would expect). This is the
reason why C for example doesn't bother to provide a round() function
for arbitrary precision, it can only round to integer which always can
be represented in an exact way.
If we really want a round() function, this function should operate just like
number_format() and printf() already do, i.e. returning a string, not a double,
The problem is not returning a double. For example, literal 0.285 in the
source and the result of the expression round (0.2846, 3) are the same
floats. They are not exactly 0.285 but they are represented in the same
way (assuming the FPU mode thing gets added, see my first mail).
The actual problem is that the double you put in to round() is not
always what people think it is (as you already said). So letting round()
return a string() will not solve the underlying issues.
A final note: programmers concerned with rounding problems and looking for
"exact" results while dealing with floating point numbers are usually
erroneusly using "float" values to store monetary values as if PHP were a desk
calculator, rather than use BCMath or other specialized high-precision library
suitable for business applications.
The problem is that bcmath is not available everywhere - neither are
other such libraries. Also, using bcmath is quite cumberstone to read.
With floats you can do $a = $b + $c * $d + $e / $f - $g * $h / $j which
is very clear to read while with bcmath you have lots of nested function
calls which is really bad to read. And even if you have monetary
calculations: Normally, you are WELL within 14 decimal digits precision.
You also have to consider the following: If this were a proposal to
introduce a precision parameter into the round function, I would
completely agree that adding it will cause unecessary problems and
should not be done. But the fact is that it is already there in PHP and
you can't remove it with some serious BC breaks. And people are using
it. So may proposal is to make sure people get the best results
possible. (and since my proposal leaves some key issues open, what the
"best results possible" are is open to discussion, cf. fuzz vs. no-fuzz
etc.)
Anyway, I'll put my proposal into the wiki tomorrow with some additional
thoughts, perhaps my intentions are clearer then.
Regards,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Modify language grammar to allow commas to skip defaulted parameters.
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 case anyway.
But actually it's orthogonal to the original question whether trailing
commas are allowed or not so I'd suggest starting a new thread if you
want to change the topic ;-)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] New functions: array_replace[_recursive]
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 remember
correctly, especially the recursive version (Lukas can maybe give more info.
since he created the original implementation in PHP ;-)):
array_replace() is like the + operator applied to arrays, except that it
WILL overwrite ("replace") existing entries. 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.
In the wrapper function, I removed the SEPARATE_ZVAL() and
convert_to_array_ex() as they appear to be leftover from PHP 4 (before
array_merge[_recursive] checked if the args were arrays first). This made a
big performance difference when I benchmarked 2 years ago! I also updated
it to use array_init_size() (returned array will have at least as many
elements as the largest input array) for another small optimization.
http://realplain.com/php/array_replace.diff
http://realplain.com/php/array_replace_5_3.diff (With NEWS entry)
http://realplain.com/php/array_replace.phpt (Still has the old UEXPECT
section for HEAD; will fix if I commit)
Any thoughts or objections? Should I commit before Thursday, like
tomorrow...?
Thanks,
Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] closures questions
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 a draw back from the OO approach (rather than the original resource approach), but solvable? I think we can make working clone there - just copy all data, etc. -- 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] closures questions
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 syntax $foo->bar() is already used. But you can do $foo->bar->__invoke()! -- 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] closures questions
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 closure on a property? The only thing that needs to be done would be to define the resolution order which is the trickier thing. cu, Lars signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [PHP-DEV] closures questions
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 >> 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 closure on a property? The only thing that needs to > be done would be to define the resolution order which is the trickier > thing. > cu, Lars Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] closures questions
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 exporting the >>> closure across >>> data >> >> not a huge biggy to me. > I don't think Closure can be meaningfully exported. Can we prohibit it? We could add a special case that disallows it. >> I guess this is a draw back from the OO approach (rather than the >> original resource approach), but solvable? > I think we can make working clone there - just copy all data, etc. Yep, it should be possible. On the other hand, we probably would like to change the bound variables then which brings us to having to support properties. Hey, didn't we just disable that? Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] closures questions
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 found 3. __call will be broken - now should we check properties or go to __call when method is not defined? 4. zend_std_get_method should be calling __get too, in case this property is not a direct property! I don't think it's going to work out. Using __invoke is much easier. -- 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
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
Re: [PHP-DEV] re2c issues? (Was Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_language_scanner.l)
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 modify anything yet, and it's
not
related to the subject anyway :-)).
my code doesn't find the optimal largest chunk of inline html, but
almost. It just gives up when it finds a potential tag. It can be
made optimal easily, at some expense. I don't know if it's
beneficial or not.
Still wondering about the behavior of re2c at EOF being different
than
Flex -- can't re2c have an addition/enhancement that simply keeps
track of
the rule that *would have* matched before hitting EOF (e.g.
YYCURSOR >=
YYLIMIT) and then jump to it when doing the YYFILL check?
Yes, this is horrible.. I'm also afraid there might be some other
corner cases that we are returning EOF where we shouldn't. This
behaviour can be workarounded with the state feature though.
Another thing that isn't working is the warning about /* Unterminated
comments... (never seen). The optimization for comment parsing I
was going
to do (along with the above HTML stuff) would also work around that
-- not
using re2c rules, but a manual scan or zend_memnstr() for the
closing */.
Ok, please file a bug report and assign it to me, or go ahead and
fix it yourself :-)
Like I said in the comments for Bug #45372, if the last thing at
the end of
a file is matched by a variable length rule, it will not be returned.
Because of
#define YYFILL(n) { if (YYCURSOR >= YYLIMIT) return 0; }
I put the ? in the subject line because I'm not sure how important
this
really is, but it just seems broken to me (though it's usually with
invalid
code), and I couldn't think of a workaround with my limited
knowledge of
re2c (though I think it would need to be changed internally). Some
things
this affects are 1) the tokenizer extension -- the last token won't
be
returned (if variable length, of course); 2) highlighting (if
someone is
trying to "see" an unclosed string error, for example? PHP
highlighting on
forums...), and parse errors can be different than previously if
the parser
gets one less token, for example:
I'm not much worried about input errors, although I agree the
current approach isn't the best one. As I said, this can be
workrounded with the states thing (IIRC).
It's been awhile since I checked out the details, so I can't recall
at the
moment if there are more serious examples. Also not sure if some
of this is
affecting the ini scanner (see Bug #45384), as I haven't really
look at its
code.
The ini scanner is a bit broken yes.. :/
Maybe Marcus can help us here? Maybe add some new feature to re2c or
help in implementing some workarond?
Whats the status here?
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] closures questions
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 anymore 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. > 2. We'd have to check properties every time method name was not found We could add a flag for this to make it faster. That is whenever someone sets a property to a closure. > 3. __call will be broken - now should we check properties or go to > __call when method is not defined? How is it broken? __call does not get called if there is something callable already. > 4. zend_std_get_method should be calling __get too, in case this > property is not a direct property! Maybe. However this only applies to overloaded objects. Maybe those cannot or should not hold closures. > I don't think it's going to work out. Using __invoke is much easier. > -- > Stanislav Malyshev, Zend Software Architect > [EMAIL PROTECTED] http://www.zend.com/ > (408)253-8829 MSN: [EMAIL PROTECTED] Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] closures questions
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 every time method name was not found We could add a flag for this to make it faster. That is whenever someone sets a property to a closure. Whenever someone sets a property to a closure what happens? Does it mean that every call to write_property argument would be checked for instanceof Closure? What about write_dimension or get_property_ptr_ptr? 3. __call will be broken - now should we check properties or go to __call when method is not defined? How is it broken? __call does not get called if there is something callable already. __call doesn't work anymore if there's a property with the name that is equal to called function. That could be a big surprise for classes that use __call for routing. Maybe. However this only applies to overloaded objects. Maybe those cannot or should not hold closures. What do you mean by "overloaded objects"? Every object has get_property handler. -- 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] Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/phar phar.c phar_internal.h phar_object.c /ext/phar/tests frontcontroller11.phpt /ext/phar/tests/cache_list frontcontroller11.phpt /ext/phar/t
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: >> dmitryTue Jul 22 07:03:01 2008 UTC >> >> Modified files: (Branch: PHP_5_3) >>/php-src/ext/phar phar.c phar_internal.h phar_object.c >>/php-src/ext/phar/testsfrontcontroller11.phpt >>/php-src/ext/phar/tests/cache_listfrontcontroller11.phpt >>/php-src/ext/phar/tests/cache_list/files frontcontroller6.phar >> frontcontroller7.phar >>/php-src/ext/phar/tests/files frontcontroller5.phar >> frontcontroller6.phar >> frontcontroller6.phar.inc >> frontcontroller7.phar >> frontcontroller7.phar.inc >>/php-src/ext/phar/tests/tarfrontcontroller11.phar.phpt >>/php-src/ext/phar/tests/tar/files frontcontroller6.phar.inc >> frontcontroller6.phar.tar >> frontcontroller7.phar.inc >> frontcontroller7.phar.tar >>/php-src/ext/phar/tests/zipfrontcontroller11.phar.phpt >>/php-src/ext/phar/tests/zip/files frontcontroller6.phar.inc >> frontcontroller6.phar.zip >> frontcontroller7.phar.inc >> frontcontroller7.phar.zip >> Log: >> Improved webPhar speed (frontcontroller11.phar.phpt is disabled, >> should be removed) > Hmm .. am I right to assume that phar is currently only being > developed in 5.3 and HEAD is kept out of sync? > Lukas Kahwe Smith > [EMAIL PROTECTED] Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] RecursiveTreeIterator implementation
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 :-) Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] closures questions
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, and nothing alerts you of the > problem. >>> 2. We'd have to check properties every time method name was not found >> >> We could add a flag for this to make it faster. That is whenever someone >> sets a property to a closure. > Whenever someone sets a property to a closure what happens? Does it mean > that every call to write_property argument would be checked for > instanceof Closure? What about write_dimension or get_property_ptr_ptr? >>> 3. __call will be broken - now should we check properties or go to >>> __call when method is not defined? >> >> How is it broken? __call does not get called if there is something callable >> already. > __call doesn't work anymore if there's a property with the name that is > equal to called function. That could be a big surprise for classes that > use __call for routing. >> Maybe. However this only applies to overloaded objects. Maybe those cannot >> or should not hold closures. > What do you mean by "overloaded objects"? Every object has get_property > handler. 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. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] closures questions
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() is not that hard. But if we find a way to make it not clash with __get/__call and whole story with properties - I'm all for it. -- 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] new PostgreSQL API
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 be in abort state anyway. ok, returning errors it is ... 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 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 ... -- 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] [PATCH] RecursiveTreeIterator implementation
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 ? Regards, Arnaud -- 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
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 problem to allow all 2xx codes, even though > some ones like 204 may behave strangely, but as long as it doesn't break > anything... It is a BC break. But people should be checking the retrieved status codes anyway so I don't think its a big issue. +1 -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
