Re: [PHP-DEV] [RFC] Zend Signal Handling
On Wed, Jul 23, 2008 at 7:54 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hi! Do we really need this option? Is someone going to disable it and why? I see only reason to disable it if one has some weird system where sigaction is either absent or doesn't work as it should. Not that I know of any, but Unix variants are full of surprises. I'd keep it enabled by default, unless we are on OS that doesn't have sigaction (e.g. Windows or some extremely weird Unix) or in ZTS, of course. Windows has signal (and SigAction) support. Obviously (sigh) not using the same API but it is possible to achieve the same behaviors using the windows API. For example, there is already exception for special cases like SIGALRM, windows API also uses a timer (CreateWaitableTimer co). Once the code is in cvs, I can give it a try to port zend_signal to windows (not before alpha1 but before alpha2 :) 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] [PATCH] No runtime fetching of built-in global constants
Hi Matt, Sorry if I missed it. Does this patch make any performance difference? I assume it saves on hash lookup during compilation and its really insignificant time. However it add new scanner rules which may slowdown the whole scanner. For now I don't see a big reason, but may be I didn't see something. Do you have any other postponed patches? I remember something about string optimizations and long multiply. Thanks. Dmitry. Matt Wilmas wrote: 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/const_ct_optimization.diff http://realplain.com/php/const_ct_optimization_5_3.diff Thanks, Matt - Original Message - From: Matt Wilmas Sent: Friday, April 18, 2008 Hi all, I changed things so that the many built-in constants (CONST_PERSISTENT ones) will be replaced at compile-time, saving the FETCH_CONSTANT opcode, if these changes are usable. This was added for TRUE/FALSE/NULL 2 years ago, but seems like it can be done for lots of others too. Since the change 2 years ago, other constants have been getting looked up also, but just discarded. And if a constant wasn't found, its name was lowercased and looked up again (for case-insensitive TRUE/FALSE/NULL). Lowercasing has been removed, since case-insensitive constants can't be done (guess an exception was made for TRUE/FALSE/NULL :-)), and TRUE/FALSE/NULL get flagged in the scanner (not reserved words, which Marcus did briefly a few years ago), skipping a hash lookup. BTW, to get this compile-time optimization in a namespace, it needs to be prefixed (::CONSTANT). I also removed an unnecessary memcmp() in zend_get_constant() -- old code that was needed a long time ago, it appears. http://realplain.com/php/const_ct_optimization.diff http://realplain.com/php/const_ct_optimization_5_3.diff Thoughts? Thanks, Matt -- 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 / run-tests.php
Marcus Boerger schrieb: to be honest this is the wrong way. The correct way of fixing this is to have PHP 6 name it correct: string and binary. And to have b for binary Aside from the question of how to write a portable test, here is an example speaking for your argument of making a distinction between binary (strings) and strings (= always unicode) in the var_dump()/print_r()/etc. output of PHP 6. In early PHP 6 days var_dump((binary)PHP) has printed string, like PHP 5 does. And in earlier versions of PHP 6 var_dump(PHP) has printed unicode. There was a distinction between the two types of strings in PHP 6. That was nice, because it was simple to test if SELECT varbinary_column really returned a binary (string) or a (unicode) string. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] question about backward-compatibility break/bug in php 5.2.6
Hi,
Last week I submitted a bug report on the issue described below. The
response (also below) was that this is not a bug. I fail to see how it
could *not* be a bug given that strtotime is parsing an invalid date
into a seemingly-arbitrary and definitely-meaningless number,
strtotime() has always accepted month and day numbers 0 in order to
express last month of the previos year and last day of the previous
month. Take:
var_dump (date ('Y-m-d H:i:s', strtotime ('2008-00-01 12:00:00')));
This gives:
string(19) 2007-12-01 12:00:00
Here, the 00 is interpreted as month before January and thus December
of the previous year. Then, take:
var_dump (date ('Y-m-d H:i:s', strtotime ('2008-02-00 12:00:00')));
This gives:
string(19) 2008-01-31 12:00:00
Here, the 00 is interpreted as day before the first day of that month
and thus the 31st of January.
Take both together, you get:
var_dump (date ('Y-m-d H:i:s', strtotime ('2008-00-00 12:00:00')));
string(19) 2007-11-30 12:00:00
Now, take the date '-01-01'. This is a valid date according to ISO
8601 and simply means the 1st of January in 1 BC (but according to a
proleptic gregorian calendar, because ISO 8601 defines it as that). So
'-00-00' is actually the 30th of November of 2 BC (proleptic
gregorian calendar).
Now, the return value of strtotime() is actually defined as the number
of seconds since the 1st of January 1970, 00:00:00 UTC. If you add
-62169966000 seconds to that date, you get the 30th of November 2 BC
(proleptic gregorian calendar) at 00:00:00 of your time zone.
Also, it is not a regression. On my 32bit CPU, strtotime() still returns
false for your date since a 32bit integer cannot represent such a large
number and thus strtotime() can't return a valid timestamp. But on a
64bit CPU, integers are large enough to hold that number and strtotime()
can return a valid timestamp. If you compile a very old PHP version on a
64bit system, it will yield the same results.
As somebody already commented in the bug reports: It's not a bug.
You can write yourself a wrapper if you want to catch that specific date:
function my_strtotime($str, $ts = null) {
if ($ts === null) $ts = time ();
return $str == '-00-00 00:00:00' ? false : strtotime ($str, $ts);
}
Regards,
Christian
--
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.
There is one case which *may* cause problems:
function doSomething ($callback) {
if (!is_callable ($callback)) {
throw new Exception (...);
}
// special treatment
if ($callback == 'default') {
...
} else {
...
}
}
Here, the comparison of $callback with 'default' will yield a notice
that $callback couldn't be converted. The comparison will fail
correctly, of course, but it could cause some confusion. The correct
way of comparing would obviously be using ===, that won't cause these
hickups.
Personally, I don't care whether a object-to-string cast is present or
not.
I don't think Closure can be meaningfully exported. Can we prohibit it?
Unfortunately, currently not, see the var_export code.
I think we can make working clone there - just copy all data, etc.
Perhaps. But I'd recommend this should be postponed, as there are quite
a few subtleties regarding semantics of bound variables involved. Should
there seem to be a strong need for cloning closures by the community,
this can always be implemented in a future PHP version. IMHO.
Regards,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Php 5.3 Snap - Lambda functions and $this scope
Hi, Wouldn't it be better (and maybe safer) to allow the use of $this as a closure instead of passing it to the new lambda function? We had that in a previous patch. We had quite a few discussions on what the best syntax would be, actually. In the end, Dmitry and I chose to implement it in this way because it seemed more consistent with current PHP behaviour and because more people on internals seemed to like it than dislike it. As for the consistency with current PHP behaviour: $this is always present in any class method which is non-static. Every other variable (except superglobals) used in a method or function must explicitly be defined - either as a parameter, or in the function or via 'global $foo'. So $this is already special. So using the presence or absence of the 'static' keyword in front of the 'function' keyword to determine whether $this is available inside the closure seems much more natural. Of course, there will be people who disagree with this. But we've already discussed closure syntax quite a bit while discussion my original patch and I believe the compromise we've reached is quite acceptable for everybody. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] closures questions
On 24.07.2008, at 11:10, Christian Seiler wrote: Personally, I don't care whether a object-to-string cast is present or not. So lets remove it? I don't think Closure can be meaningfully exported. Can we prohibit it? Unfortunately, currently not, see the var_export code. I think we can make working clone there - just copy all data, etc. Perhaps. But I'd recommend this should be postponed, as there are quite a few subtleties regarding semantics of bound variables involved. Should there seem to be a strong need for cloning closures by the community, this can always be implemented in a future PHP version. IMHO. I agree that both are not super high priority. So lets keep them for 5.4/6.0, ok? 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] [PATCH] No runtime fetching of built-in global constants
Hi Dmitry, - Original Message - From: Dmitry Stogov Sent: Thursday, July 24, 2008 Hi Matt, Sorry if I missed it. No problem. :-) Does this patch make any performance difference? I assume it saves on hash lookup during compilation and its really insignificant time. However it add new scanner rules which may slowdown the whole scanner. For now I don't see a big reason, but may be I didn't see something. Yes, I tried to explain the differences in the original message (below). In runtime, FETCH_CONSTANT is saved for the built-in, global constants (CONST_PERSISTENT). During compilation, no hash lookup is needed for TRUE/FALSE/NULL since they are caught by the scanner, as you saw. The compile-time hash lookups were added when you eliminated runtime fetching for TRUE/FALSE/NULL a couple years ago, which has since been looking up the other built-in constants too and discarding them, so I just use them. :-) Also, right now if the constant isn't found (zend_get_ct_const()), there's lowercasing and a second lookup -- only for catching case-insensitive TRUE/FALSE/NULL! One thing I was wondering about is if this would cause a problem for opcode caches if they need to know it's really a constant constant and not a literal constant. If so, can probably have a compiler_options flag to disable my compile-time substitution, and the opcode cache can do what it wants (substitution with own optimizer, etc.). Do you have any other postponed patches? I remember something about string optimizations and long multiply. Yeah. :-) The multiply long one [1] is a pretty small thing that probably should be reviewed for a decision (MM's safe_address() function especially), though it does speed up mul_function() (* operator) on more platforms. The string changes/optimizations patch [2] is mostly fine, I think. Just wondering if it's OK to remove the INIT_STRING opcode. BTW, it has changes that make the scanner simpler/smaller if you're concerned about the constants patch adding a few rules. ;-D [1] http://marc.info/?l=php-internalsm=121630449331340w=2 [2] http://marc.info/?l=php-internalsm=121569400218314w=2 Thanks. Dmitry. Thanks, Matt Matt Wilmas wrote: 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/const_ct_optimization.diff http://realplain.com/php/const_ct_optimization_5_3.diff Thanks, Matt - Original Message - From: Matt Wilmas Sent: Friday, April 18, 2008 Hi all, I changed things so that the many built-in constants (CONST_PERSISTENT ones) will be replaced at compile-time, saving the FETCH_CONSTANT opcode, if these changes are usable. This was added for TRUE/FALSE/NULL 2 years ago, but seems like it can be done for lots of others too. Since the change 2 years ago, other constants have been getting looked up also, but just discarded. And if a constant wasn't found, its name was lowercased and looked up again (for case-insensitive TRUE/FALSE/NULL). Lowercasing has been removed, since case-insensitive constants can't be done (guess an exception was made for TRUE/FALSE/NULL :-)), and TRUE/FALSE/NULL get flagged in the scanner (not reserved words, which Marcus did briefly a few years ago), skipping a hash lookup. BTW, to get this compile-time optimization in a namespace, it needs to be prefixed (::CONSTANT). I also removed an unnecessary memcmp() in zend_get_constant() -- old code that was needed a long time ago, it appears. http://realplain.com/php/const_ct_optimization.diff http://realplain.com/php/const_ct_optimization_5_3.diff Thoughts? Thanks, Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/soap ctor errors
Okay, we're taking care of that.
David
Am 23.07.2008 um 22:49 schrieb Lukas Kahwe Smith:
Hi,
Should not be too hard for someone with C knowledge to produce a fix
I would assume. Any takers? Not sure if Dmitry has time for this on
such short notice ..
regards,
Lukas
On 23.07.2008, at 20:07, Noah Fontes wrote:
-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 with Lukas here, currently you have to be proactive against
the location of the WSDL-file. I currently do like this in my
SoapClient's:
class MySoapClient extends SoapClient {
public function __construct($wsdl ,$options = array()) {
if(is_resource(@fopen($wsdl, 'r'))) {
parent::__construct($wsdl, $options);
} else {
throw new Exception(Parsing WSDL: Couldn't load from '$wsdl');
}
}
}
to be able to catch that problem as an Exception.
Regards,
Knut Urdalen
Lukas Kahwe Smith wrote:
Hi,
why do I get warnings when I have failures in my ext/soap ctor?
try {
$client = new SoapClient('http://i_dont_exist.com/some.wsdl',
array('exceptions' = true));
} catch (Exception $e) { }
I guess even without the 'exceptions' = true it should always
return
all issues as an exception. I think this was agreed upon for
constructor errors in PHP5, no?
regards,
Lukas
+1 for this.
Regards,
Noah
- --
Noah Fontes
Bitextender
http://www.bitextender.com/
Phone: +1 919 349 9826
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIh3NKhitK+HuUQJQRAmywAKCH7w7pq7r9dV+UHF81Ky7/9XzYOgCgjAGB
DopF3tsQm31fzXxDhWYU2S8=
=QPf5
-END PGP SIGNATURE-
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Lukas Kahwe Smith
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
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
So... who's gonna commit it? :) David Am 23.07.2008 um 19:40 schrieb Noah Fontes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Zülke wrote: Yeah. We discussed that quite a while back when I sent over the ignore_errors options patch-like thing in November: 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? I think PHP implicitly follows any Location headers it can. That's probably not the right behavior, but for an automated process it's not bad. I think that 3xx status codes, if they appear without a Location header, should also probably not throw errors. They could provide valuable information about the status of a page (particularly 304 Not Modified), so I've updated the patch: http://cynigram.com/~nfontes/http_fopen_wrapper.patch BTW, any chance this could be rolled into 5.3? I think the BC break is pretty non-notable, and it would be nice to stop throwing errors for successful responses. Regards, Noah - -- Noah Fontes Bitextender http://www.bitextender.com/ Phone: +1 919 349 9826 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIh20nhitK+HuUQJQRAqipAJ9pndnS4K4L5GtPzoYsEguYQSgSXwCfb6yC YnohwjT8KYCiADQehg4Jm2A= =UzO8 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Closures and reflection improvements
Hi,
I'd like to add the following patch to reflection before the feature
freeze, because it does not change any current reflection behaviour but
adds quite a bit of good stuff for closures.
With the current closure implementation, __invoke always has the same
signature as the original lambda function, this makes passing parameters
per reference possible. But this does not show in current reflection:
$o = new ReflectionObject (function ($a) {});
$m = $o-getMethod ('__invoke');
var_dump ($m-getNumberOfParameters());
Currently, this does a lookup in the class function table. But the
signature of the method found in the function table has no parameters.
For the normal engine to have a different signature for a specific
closure, the get_method handler is used.
My patch does the following:
* If a reflection method named '__invoke' is requested for an object
of the 'Closure' class (in any way possible: via constructor,
via ReflectionObject-getMethod, via ReflectionParameter
constructor, ...), the correct invoke signature is used by
reflection.
* If the same method for the class 'Closure' (without an object)
is requested, the standard signautre (no parameters) will be used.
* If you pass a callable object (closure or otherwise) as the only
parameter to the ReflectionMethod constructor, __invoke will be
used as default method. Example:
$m = new ReflectionMethod ($closure);
is identical to
$m = new ReflectionMethod ($closure, '__invoke');
For Post-5.3 we could even think of adding a new object handler for
retrieving methods for reflection generally (get_method will not work
correctly since the std_get_method handler does scope checking and
prints error messages) and thus allowing e.g. COM, Java or SOAP objects
to provide useful dynamic information for reflection. But to keep the
changes in 5.3 as non-invasive as possible, it is probably best to have
this single exception for closures.
You can find the patch here:
http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-5.3.patch
http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-fixes-6.patch
The patch is fairly straight-forward and should be easily reviewed.
Here are some tests for this patch:
http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-tests-5.3.tar.gz
http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-closure-tests-6.tar.gz
I also found a segfault in *all* PHP versions in the ReflectionParameter
constructor. The above patches already fix that, but here's a patch that
fixes this for PHP 5.2:
http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflection-segfault-fix-5.2.patch
For the segfault I also created following test case (works with 5.2, 5.3
and 6.0), NOT included in the above .tar.gzs.
http://www.christian-seiler.de/temp/php/2008-07-24-reflection/reflectionParameter_invalidMethodInConstructor.phpt
Regards,
Christian
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] No runtime fetching of built-in global constants
According to constants patch, it definitely will break PHP encoders and
may be opcode caches, but as you mentioned the compiler_option will
solve the issue. In this case we probable may substitute any constants
(not only persistent). Anyway I don't see a big reason for special
handling of TRUE/FALSE/NULL in scanner. Also it'll break function
true(){} and may be something else (I'm not sure if it's good or bad :).
Multiple long looks fine, but on which systems did you test it?
I'll try to take a deeper look into string optimization patch today or
tomorrow.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Thursday, July 24, 2008
Hi Matt,
Sorry if I missed it.
No problem. :-)
Does this patch make any performance difference?
I assume it saves on hash lookup during compilation and its really
insignificant time. However it add new scanner rules which may slowdown
the whole scanner.
For now I don't see a big reason, but may be I didn't see something.
Yes, I tried to explain the differences in the original message (below). In
runtime, FETCH_CONSTANT is saved for the built-in, global constants
(CONST_PERSISTENT). During compilation, no hash lookup is needed for
TRUE/FALSE/NULL since they are caught by the scanner, as you saw. The
compile-time hash lookups were added when you eliminated runtime fetching
for TRUE/FALSE/NULL a couple years ago, which has since been looking up the
other built-in constants too and discarding them, so I just use them. :-)
Also, right now if the constant isn't found (zend_get_ct_const()), there's
lowercasing and a second lookup -- only for catching case-insensitive
TRUE/FALSE/NULL!
One thing I was wondering about is if this would cause a problem for opcode
caches if they need to know it's really a constant constant and not a
literal constant. If so, can probably have a compiler_options flag to
disable my compile-time substitution, and the opcode cache can do what it
wants (substitution with own optimizer, etc.).
Do you have any other postponed patches?
I remember something about string optimizations and long multiply.
Yeah. :-) The multiply long one [1] is a pretty small thing that probably
should be reviewed for a decision (MM's safe_address() function especially),
though it does speed up mul_function() (* operator) on more platforms.
The string changes/optimizations patch [2] is mostly fine, I think. Just
wondering if it's OK to remove the INIT_STRING opcode. BTW, it has changes
that make the scanner simpler/smaller if you're concerned about the
constants patch adding a few rules. ;-D
[1] http://marc.info/?l=php-internalsm=121630449331340w=2
[2] http://marc.info/?l=php-internalsm=121569400218314w=2
Thanks. Dmitry.
Thanks,
Matt
Matt Wilmas wrote:
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/const_ct_optimization.diff
http://realplain.com/php/const_ct_optimization_5_3.diff
Thanks,
Matt
- Original Message -
From: Matt Wilmas
Sent: Friday, April 18, 2008
Hi all,
I changed things so that the many built-in constants
(CONST_PERSISTENT
ones) will be replaced at compile-time, saving the FETCH_CONSTANT
opcode,
if
these changes are usable. This was added for TRUE/FALSE/NULL 2 years
ago,
but seems like it can be done for lots of others too.
Since the change 2 years ago, other constants have been getting looked
up
also, but just discarded. And if a constant wasn't found, its name was
lowercased and looked up again (for case-insensitive TRUE/FALSE/NULL).
Lowercasing has been removed, since case-insensitive constants can't be
done
(guess an exception was made for TRUE/FALSE/NULL :-)), and
TRUE/FALSE/NULL
get flagged in the scanner (not reserved words, which Marcus did
briefly a
few years ago), skipping a hash lookup. BTW, to get this compile-time
optimization in a namespace, it needs to be prefixed (::CONSTANT).
I also removed an unnecessary memcmp() in zend_get_constant() -- old
code
that was needed a long time ago, it appears.
http://realplain.com/php/const_ct_optimization.diff
http://realplain.com/php/const_ct_optimization_5_3.diff
Thoughts?
Thanks,
Matt
--
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
David Zülke wrote: So... who's gonna commit it? :) I'll commit in the next few hours if nobody objects. Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] No runtime fetching of built-in global constants
I would propose the attached patch for this optimization.
Opcode caches and encoders will have to disable this optimization with
ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION
Any objections?
Thanks. Dmitry.
Matt Wilmas wrote:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Thursday, July 24, 2008
Hi Matt,
Sorry if I missed it.
No problem. :-)
Does this patch make any performance difference?
I assume it saves on hash lookup during compilation and its really
insignificant time. However it add new scanner rules which may slowdown
the whole scanner.
For now I don't see a big reason, but may be I didn't see something.
Yes, I tried to explain the differences in the original message (below). In
runtime, FETCH_CONSTANT is saved for the built-in, global constants
(CONST_PERSISTENT). During compilation, no hash lookup is needed for
TRUE/FALSE/NULL since they are caught by the scanner, as you saw. The
compile-time hash lookups were added when you eliminated runtime fetching
for TRUE/FALSE/NULL a couple years ago, which has since been looking up the
other built-in constants too and discarding them, so I just use them. :-)
Also, right now if the constant isn't found (zend_get_ct_const()), there's
lowercasing and a second lookup -- only for catching case-insensitive
TRUE/FALSE/NULL!
One thing I was wondering about is if this would cause a problem for opcode
caches if they need to know it's really a constant constant and not a
literal constant. If so, can probably have a compiler_options flag to
disable my compile-time substitution, and the opcode cache can do what it
wants (substitution with own optimizer, etc.).
Do you have any other postponed patches?
I remember something about string optimizations and long multiply.
Yeah. :-) The multiply long one [1] is a pretty small thing that probably
should be reviewed for a decision (MM's safe_address() function especially),
though it does speed up mul_function() (* operator) on more platforms.
The string changes/optimizations patch [2] is mostly fine, I think. Just
wondering if it's OK to remove the INIT_STRING opcode. BTW, it has changes
that make the scanner simpler/smaller if you're concerned about the
constants patch adding a few rules. ;-D
[1] http://marc.info/?l=php-internalsm=121630449331340w=2
[2] http://marc.info/?l=php-internalsm=121569400218314w=2
Thanks. Dmitry.
Thanks,
Matt
Matt Wilmas wrote:
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/const_ct_optimization.diff
http://realplain.com/php/const_ct_optimization_5_3.diff
Thanks,
Matt
- Original Message -
From: Matt Wilmas
Sent: Friday, April 18, 2008
Hi all,
I changed things so that the many built-in constants
(CONST_PERSISTENT
ones) will be replaced at compile-time, saving the FETCH_CONSTANT
opcode,
if
these changes are usable. This was added for TRUE/FALSE/NULL 2 years
ago,
but seems like it can be done for lots of others too.
Since the change 2 years ago, other constants have been getting looked
up
also, but just discarded. And if a constant wasn't found, its name was
lowercased and looked up again (for case-insensitive TRUE/FALSE/NULL).
Lowercasing has been removed, since case-insensitive constants can't be
done
(guess an exception was made for TRUE/FALSE/NULL :-)), and
TRUE/FALSE/NULL
get flagged in the scanner (not reserved words, which Marcus did
briefly a
few years ago), skipping a hash lookup. BTW, to get this compile-time
optimization in a namespace, it needs to be prefixed (::CONSTANT).
I also removed an unnecessary memcmp() in zend_get_constant() -- old
code
that was needed a long time ago, it appears.
http://realplain.com/php/const_ct_optimization.diff
http://realplain.com/php/const_ct_optimization_5_3.diff
Thoughts?
Thanks,
Matt
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.647.2.27.2.41.2.74
diff -u -p -d -r1.647.2.27.2.41.2.74 zend_compile.c
--- Zend/zend_compile.c 24 Jul 2008 11:47:49 - 1.647.2.27.2.41.2.74
+++ Zend/zend_compile.c 24 Jul 2008 14:40:12 -
@@ -3804,6 +3804,12 @@ static zend_constant* zend_get_ct_const(
if (c-flags CONST_CT_SUBST) {
return c;
}
+ if (!CG(current_namespace)
+ !(CG(compiler_options) ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION)
+ Z_TYPE(c-value) != IS_CONSTANT
+ Z_TYPE(c-value) != IS_CONSTANT_ARRAY) {
+ return c;
+ }
return NULL;
}
/* }}} */
@@ -5169,12 +5175,14 @@ void zend_do_use(znode *ns_name, znode *
void zend_do_declare_constant(znode *name, znode *value TSRMLS_DC) /* {{{ */
{
zend_op
Re: [PHP-DEV] 5.3 feature freeze rapidly approaching
Em Qua, 2008-07-23 às 18:52 +0200, Marcus Boerger escreveu: And then there are these: - should we finally change: typedef int (*apply_func_args_t)(void *pDest, int num_args, va_list args, zend_hash_key *hash_key); to typedef int (*apply_func_args_t)(void *pDest TSRMLS_DC, int num_args, va_list args, zend_hash_key *hash_key); so that we can drop a bunch of TSRMLS_FETCH()'es. Would it be like that? http://felipe.ath.cx/diff/zend_hash_apply_with_arguments.diff -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] question about backward-compatibility break/bug in php 5.2.6
Ah, yes, the change responsible is the following: http://cvs.php.net/viewvc.cgi/php-src/ext/date/lib/timelib.h? r1=1.10.2.11.2.4r2=1.10.2.11.2.5pathrev=PHP_5_2 It fixes bug #44209 http://bugs.php.net/bug.php?id=44209. OK, thanks, it's good to understand the change in behavior. Or to put it that way: The current behaviour of PHP 5.2.6 is the expected behaviour (at least what reading the source tells about the author's intentions) and it was broken before. As to whether it's a good idea that strtotime() accepts invalid dates, I'll stay out of that discussion. If this is the way it's always been (accepting zero month and day values as you described earlier), then I suspect that you'll be reluctant to change behavior without significant thought (and of course, I wouldn't expect otherwise, even though I've expressed my disagreement with the current behavior). What's the best way to get this fully documented? Should I submit a new bug report relating to the documentation, rather than a PHP bug? Jack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] question about backward-compatibility break/bug in php 5.2.6
Hi! This 64-bit machine is running 5.2.5 and returns false on the all-zero datetime string. It was upgraded last week to 5.2.6 and started returning the large negative integer. Ah, yes, the change responsible is the following: http://cvs.php.net/viewvc.cgi/php-src/ext/date/lib/timelib.h?r1=1.10.2.11.2.4r2=1.10.2.11.2.5pathrev=PHP_5_2 It fixes bug #44209 http://bugs.php.net/bug.php?id=44209. timelib.h didn't include limits.h and thus always defined LONG_MAX / LONG_MIN to the 32bit values for longs and thus the check in timelib.c for LONG_MIN failed in 5.2.5 for your timestamp. But as 5.2.6 fixed that (LONG_MIN from limits.h used when present), your timestamp became valid and strtotime() returned it. Or to put it that way: The current behaviour of PHP 5.2.6 is the expected behaviour (at least what reading the source tells about the author's intentions) and it was broken before. As to whether it's a good idea that strtotime() accepts invalid dates, I'll stay out of that discussion. Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] question about backward-compatibility break/bug in php 5.2.6
I'm not sure that there's any problem with the documentation (although it wouldn't hurt to mention it in the comments). What is it about -00-00 00:00:00 that makes it an invalid date? (See Christian's explanation) Zach On Thu, Jul 24, 2008 at 11:09 AM, Jack Steadman [EMAIL PROTECTED] wrote: Ah, yes, the change responsible is the following: http://cvs.php.net/viewvc.cgi/php-src/ext/date/lib/timelib.h? r1=1.10.2.11.2.4r2=1.10.2.11.2.5pathrev=PHP_5_2 It fixes bug #44209 http://bugs.php.net/bug.php?id=44209. OK, thanks, it's good to understand the change in behavior. Or to put it that way: The current behaviour of PHP 5.2.6 is the expected behaviour (at least what reading the source tells about the author's intentions) and it was broken before. As to whether it's a good idea that strtotime() accepts invalid dates, I'll stay out of that discussion. If this is the way it's always been (accepting zero month and day values as you described earlier), then I suspect that you'll be reluctant to change behavior without significant thought (and of course, I wouldn't expect otherwise, even though I've expressed my disagreement with the current behavior). What's the best way to get this fully documented? Should I submit a new bug report relating to the documentation, rather than a PHP bug? Jack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] No runtime fetching of built-in global constants
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Thursday, July 24, 2008
According to constants patch, it definitely will break PHP encoders and
may be opcode caches, but as you mentioned the compiler_option will
solve the issue. In this case we probable may substitute any constants
(not only persistent).
I just figured the persistent ones were about all that could be done (and
safe to substitute). Almost every built-in constant is persistent -- except
SID (session id) that I know of, which can be redefined during runtime, I
believe. And user constants wouldn't necessarily exist yet, unless they
were define()'d before an include, etc...
Anyway I don't see a big reason for special
handling of TRUE/FALSE/NULL in scanner. Also it'll break function
true(){} and may be something else (I'm not sure if it's good or bad :).
No, it won't break function true() {} or anything, I kept that in mind
(though I think it's bad) :-), and it still returns T_STRING (too bad it has
to duplicate string still when it's actually a constant). Marcus added
T_TRUE, etc. 4 years ago and then reverted it because of what you mention, I
assume (reserved word, though I wouldn't be against it!). See v1.112 and
1.115 of zend_language_scanner.l.
(OK, I just now saw your next message with the different patch... will reply
to that also.) My thinking with the special handling of TRUE/FALSE/NULL in
the scanner was to save the lowercasing and second lookup if they aren't
written in lowercase (and it happens for all other constants that aren't
found, e.g. user ones). Just seems to waste more time than needed.
Multiple long looks fine, but on which systems did you test it?
I'll try to take a deeper look into string optimization patch today or
tomorrow.
Thanks. Dmitry.
Thanks,
Matt
Matt Wilmas wrote:
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Thursday, July 24, 2008
Hi Matt,
Sorry if I missed it.
No problem. :-)
Does this patch make any performance difference?
I assume it saves on hash lookup during compilation and its really
insignificant time. However it add new scanner rules which may slowdown
the whole scanner.
For now I don't see a big reason, but may be I didn't see something.
Yes, I tried to explain the differences in the original message (below).
In
runtime, FETCH_CONSTANT is saved for the built-in, global constants
(CONST_PERSISTENT). During compilation, no hash lookup is needed for
TRUE/FALSE/NULL since they are caught by the scanner, as you saw. The
compile-time hash lookups were added when you eliminated runtime
fetching
for TRUE/FALSE/NULL a couple years ago, which has since been looking up
the
other built-in constants too and discarding them, so I just use them.
:-)
Also, right now if the constant isn't found (zend_get_ct_const()),
there's
lowercasing and a second lookup -- only for catching case-insensitive
TRUE/FALSE/NULL!
One thing I was wondering about is if this would cause a problem for
opcode
caches if they need to know it's really a constant constant and not a
literal constant. If so, can probably have a compiler_options flag to
disable my compile-time substitution, and the opcode cache can do what
it
wants (substitution with own optimizer, etc.).
Do you have any other postponed patches?
I remember something about string optimizations and long multiply.
Yeah. :-) The multiply long one [1] is a pretty small thing that
probably
should be reviewed for a decision (MM's safe_address() function
especially),
though it does speed up mul_function() (* operator) on more platforms.
The string changes/optimizations patch [2] is mostly fine, I think.
Just
wondering if it's OK to remove the INIT_STRING opcode. BTW, it has
changes
that make the scanner simpler/smaller if you're concerned about the
constants patch adding a few rules. ;-D
[1] http://marc.info/?l=php-internalsm=121630449331340w=2
[2] http://marc.info/?l=php-internalsm=121569400218314w=2
Thanks. Dmitry.
Thanks,
Matt
Matt Wilmas wrote:
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/const_ct_optimization.diff
http://realplain.com/php/const_ct_optimization_5_3.diff
Thanks,
Matt
- Original Message -
From: Matt Wilmas
Sent: Friday, April 18, 2008
Hi all,
I changed things so that the many built-in constants
(CONST_PERSISTENT
ones) will be replaced at compile-time, saving the FETCH_CONSTANT
opcode,
if
these changes are usable. This was added for TRUE/FALSE/NULL 2 years
ago,
but seems like it can be done for lots of others too.
Since the change 2 years ago, other constants have
RE: [PHP-DEV] question about backward-compatibility break/bug in php 5.2.6
I'm not sure that there's any problem with the documentation (although it wouldn't hurt to mention it in the comments). What is it about -00-00 00:00:00 that makes it an invalid date? (See Christian's explanation) Zero values for month and day are NOT valid. PHP treats them as valid, but according to GNU (on whose requirements strtotime's parsing is based, according to the docs), month values must be in the range of 1-12 and day values must be 1-31. Come to think of it, I wonder how PHP handles something like '2008-06-31' - does it treat that as July 1? Or does it call it an invalid date? Seems like the same sort of behavior - should be considered invalid, but I'm betting that PHP handles it transparently. The upshot is that we can't actually rely on strtotime to determine whether a string is a valid date/time. The docs don't ever explicitly say that the date strings themselves are checked for validity, but returning false on failure implies to me that it will return false if it can't get a *valid* date out of the string. Jack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] question about backward-compatibility break/bug in php 5.2.6
Thank you for taking the time to explain this to me. A couple more points below: strtotime() has always accepted month and day numbers 0 in order to express last month of the previos year and last day of the previous month. Take: So my biggest issue with this is that it's exception-case behavior, treating truly invalid dates as valid dates for no obvious reason. Who needs this functionality? Why is it even a good idea? A close second is that this behavior is completely undocumented. http://us.php.net/strtotime states that the time argument to strtotime is The string to parse, according to the GNU Date Input Formats syntax and that false is returned on failure. GNU date formats do NOT allow for zero months and days (see http://www.gnu.org/software/tar/manual/html_node/Calendar-date-items.htm l#SEC116). No official mention is made of the exception case that you describe. The closest the docs come is a user comment on the strtotime page from June 19 of this year (perhaps someone who upgraded to 5.2.6 and found this behavior for the first time?) warning other users that 2008-00-14 is interpreted as 2007-12-14. Also, it is not a regression. On my 32bit CPU, strtotime() still returns false for your date since a 32bit integer cannot represent such a large number and thus strtotime() can't return a valid timestamp. But on a 64bit CPU, integers are large enough to hold that number and strtotime() can return a valid timestamp. If you compile a very old PHP version on a 64bit system, it will yield the same results. This is not actually the case. Take one of our machines (first part of php -i included here): System = Linux wollaston 2.6.9-55.0.9.ELsmp #1 SMP Tue Sep 25 02:16:15 EDT 2007 x86_64 Build Date = Jul 22 2008 11:41:54 Configure Command = './configure' '--with-mysql=/usr/lib64' '--with-gettext' '--with-openssl' '--enable-ftp' '--with-zlib-dir=/usr/lib64' '--enable-pcntl' '--with-pdo-mysql=/usr' '--without-sqlite' '--without-pdo-sqlite' '--with-apac he=../apache_1.3.41' '--with-curl' '--enable-cli' Server API = Command Line Interface Virtual Directory Support = disabled Configuration File (php.ini) Path = /usr/local/lib Loaded Configuration File = /usr/local/Zend/Platform/etc/php.ini PHP API = 20041225 PHP Extension = 20060613 Zend Extension = 220060519 Debug Build = no Thread Safety = disabled Zend Memory Manager = enabled IPv6 Support = enabled Registered PHP Streams = php, file, data, http, ftp, compress.zlib, https, ftps Registered Stream Socket Transports = tcp, udp, unix, udg, ssl, sslv3, sslv2, tls Registered Stream Filters = string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, convert.iconv.*, zlib.* This program makes use of the Zend Scripting Language Engine: Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies with Zend Extension Manager v1.2.0, Copyright (c) 2003-2006, by Zend Technologies with Zend Optimizer v3.2.8, Copyright (c) 1998-2007, by Zend Technologies with jobqueue_client wrapper v1.0, Copyright (c) 2004-2007, by Zend Technologies with DISABLED Zend Download Server v1.0.6, Copyright (c) 2003-2005, by Zend Technologies with DISABLED Zend Platform v3.0.3, Copyright (c) 1999-2007, by The Zend Platform presently supports only Apache, ISAPI and FastCGI SAPIs with Zend Debugger v5.2.8, Copyright (c) 1999-2007, by Zend Technologies with gd wrapper v1.0, Copyright (c) 2004-2007, by Zend Technologies with mod_cluster wrapper v1.0, Copyright (c) 2004-2007, by Zend Technologies This 64-bit machine is running 5.2.5 and returns false on the all-zero datetime string. It was upgraded last week to 5.2.6 and started returning the large negative integer. Downgrading back to 5.2.5 fixed the problem and it again returns false. Aside from that, the original tests I ran and included with the bug report were both run on 64-bit machines, one running 5.2.5 and the other (the machine whose info is above) running 5.2.6. In fact we don't have any 32-bit machines for me to even try this out on. *Something* changed in date handling between 5.2.5 and 5.2.6. Whether you perpetuate the exception case or not, it *is* a regression. Jack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] No runtime fetching of built-in global constants
Hi again Dmitry, Well, that should get the main runtime optimization job done just as well. :-) I was just trying for more compile-time improvement also (it was definitely measurable with fake tests), especially for those not using an opcode cache, with no lookup needed for the 3 basic constants, and only one without lowercasing for others. One other thing it looks like with your patch, to be careful of, is wrongly substituting SID (session id) like I mentioned in the previous message, or other case-insensitive constants that could match at compile time, to later be defined as case sensitive, which should have priority. Know what I mean? Thanks, Matt - Original Message - From: Dmitry Stogov Sent: Thursday, July 24, 2008 I would propose the attached patch for this optimization. Opcode caches and encoders will have to disable this optimization with ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION Any objections? Thanks. Dmitry. Matt Wilmas wrote: Hi Dmitry, - Original Message - From: Dmitry Stogov Sent: Thursday, July 24, 2008 Hi Matt, Sorry if I missed it. No problem. :-) Does this patch make any performance difference? I assume it saves on hash lookup during compilation and its really insignificant time. However it add new scanner rules which may slowdown the whole scanner. For now I don't see a big reason, but may be I didn't see something. Yes, I tried to explain the differences in the original message (below). In runtime, FETCH_CONSTANT is saved for the built-in, global constants (CONST_PERSISTENT). During compilation, no hash lookup is needed for TRUE/FALSE/NULL since they are caught by the scanner, as you saw. The compile-time hash lookups were added when you eliminated runtime fetching for TRUE/FALSE/NULL a couple years ago, which has since been looking up the other built-in constants too and discarding them, so I just use them. :-) Also, right now if the constant isn't found (zend_get_ct_const()), there's lowercasing and a second lookup -- only for catching case-insensitive TRUE/FALSE/NULL! One thing I was wondering about is if this would cause a problem for opcode caches if they need to know it's really a constant constant and not a literal constant. If so, can probably have a compiler_options flag to disable my compile-time substitution, and the opcode cache can do what it wants (substitution with own optimizer, etc.). Do you have any other postponed patches? I remember something about string optimizations and long multiply. Yeah. :-) The multiply long one [1] is a pretty small thing that probably should be reviewed for a decision (MM's safe_address() function especially), though it does speed up mul_function() (* operator) on more platforms. The string changes/optimizations patch [2] is mostly fine, I think. Just wondering if it's OK to remove the INIT_STRING opcode. BTW, it has changes that make the scanner simpler/smaller if you're concerned about the constants patch adding a few rules. ;-D [1] http://marc.info/?l=php-internalsm=121630449331340w=2 [2] http://marc.info/?l=php-internalsm=121569400218314w=2 Thanks. Dmitry. Thanks, Matt Matt Wilmas wrote: 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/const_ct_optimization.diff http://realplain.com/php/const_ct_optimization_5_3.diff Thanks, Matt - Original Message - From: Matt Wilmas Sent: Friday, April 18, 2008 Hi all, I changed things so that the many built-in constants (CONST_PERSISTENT ones) will be replaced at compile-time, saving the FETCH_CONSTANT opcode, if these changes are usable. This was added for TRUE/FALSE/NULL 2 years ago, but seems like it can be done for lots of others too. Since the change 2 years ago, other constants have been getting looked up also, but just discarded. And if a constant wasn't found, its name was lowercased and looked up again (for case-insensitive TRUE/FALSE/NULL). Lowercasing has been removed, since case-insensitive constants can't be done (guess an exception was made for TRUE/FALSE/NULL :-)), and TRUE/FALSE/NULL get flagged in the scanner (not reserved words, which Marcus did briefly a few years ago), skipping a hash lookup. BTW, to get this compile-time optimization in a namespace, it needs to be prefixed (::CONSTANT). I also removed an unnecessary memcmp() in zend_get_constant() -- old code that was needed a long time ago, it appears. http://realplain.com/php/const_ct_optimization.diff http://realplain.com/php/const_ct_optimization_5_3.diff Thoughts? Thanks, Matt
Re: [PHP-DEV] [PATCH] No runtime fetching of built-in global constants
Thank you for noticing SID issue. So it seems like we able to substitute only persistent constants. Thanks. Dmitry. Matt Wilmas wrote: Hi again Dmitry, Well, that should get the main runtime optimization job done just as well. :-) I was just trying for more compile-time improvement also (it was definitely measurable with fake tests), especially for those not using an opcode cache, with no lookup needed for the 3 basic constants, and only one without lowercasing for others. One other thing it looks like with your patch, to be careful of, is wrongly substituting SID (session id) like I mentioned in the previous message, or other case-insensitive constants that could match at compile time, to later be defined as case sensitive, which should have priority. Know what I mean? Thanks, Matt - Original Message - From: Dmitry Stogov Sent: Thursday, July 24, 2008 I would propose the attached patch for this optimization. Opcode caches and encoders will have to disable this optimization with ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION Any objections? Thanks. Dmitry. Matt Wilmas wrote: Hi Dmitry, - Original Message - From: Dmitry Stogov Sent: Thursday, July 24, 2008 Hi Matt, Sorry if I missed it. No problem. :-) Does this patch make any performance difference? I assume it saves on hash lookup during compilation and its really insignificant time. However it add new scanner rules which may slowdown the whole scanner. For now I don't see a big reason, but may be I didn't see something. Yes, I tried to explain the differences in the original message (below). In runtime, FETCH_CONSTANT is saved for the built-in, global constants (CONST_PERSISTENT). During compilation, no hash lookup is needed for TRUE/FALSE/NULL since they are caught by the scanner, as you saw. The compile-time hash lookups were added when you eliminated runtime fetching for TRUE/FALSE/NULL a couple years ago, which has since been looking up the other built-in constants too and discarding them, so I just use them. :-) Also, right now if the constant isn't found (zend_get_ct_const()), there's lowercasing and a second lookup -- only for catching case-insensitive TRUE/FALSE/NULL! One thing I was wondering about is if this would cause a problem for opcode caches if they need to know it's really a constant constant and not a literal constant. If so, can probably have a compiler_options flag to disable my compile-time substitution, and the opcode cache can do what it wants (substitution with own optimizer, etc.). Do you have any other postponed patches? I remember something about string optimizations and long multiply. Yeah. :-) The multiply long one [1] is a pretty small thing that probably should be reviewed for a decision (MM's safe_address() function especially), though it does speed up mul_function() (* operator) on more platforms. The string changes/optimizations patch [2] is mostly fine, I think. Just wondering if it's OK to remove the INIT_STRING opcode. BTW, it has changes that make the scanner simpler/smaller if you're concerned about the constants patch adding a few rules. ;-D [1] http://marc.info/?l=php-internalsm=121630449331340w=2 [2] http://marc.info/?l=php-internalsm=121569400218314w=2 Thanks. Dmitry. Thanks, Matt Matt Wilmas wrote: 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/const_ct_optimization.diff http://realplain.com/php/const_ct_optimization_5_3.diff Thanks, Matt - Original Message - From: Matt Wilmas Sent: Friday, April 18, 2008 Hi all, I changed things so that the many built-in constants (CONST_PERSISTENT ones) will be replaced at compile-time, saving the FETCH_CONSTANT opcode, if these changes are usable. This was added for TRUE/FALSE/NULL 2 years ago, but seems like it can be done for lots of others too. Since the change 2 years ago, other constants have been getting looked up also, but just discarded. And if a constant wasn't found, its name was lowercased and looked up again (for case-insensitive TRUE/FALSE/NULL). Lowercasing has been removed, since case-insensitive constants can't be done (guess an exception was made for TRUE/FALSE/NULL :-)), and TRUE/FALSE/NULL get flagged in the scanner (not reserved words, which Marcus did briefly a few years ago), skipping a hash lookup. BTW, to get this compile-time optimization in a namespace, it needs to be prefixed (::CONSTANT). I also removed an unnecessary memcmp() in zend_get_constant() -- old code that was needed a long time ago, it appears. http://realplain.com/php/const_ct_optimization.diff http://realplain.com/php/const_ct_optimization_5_3.diff Thoughts? Thanks, Matt
Re: [PHP-DEV] question about backward-compatibility break/bug in php 5.2.6
On Jul 24, 2008, at 11:30 AM, Jack Steadman wrote: The upshot is that we can't actually rely on strtotime to determine whether a string is a valid date/time. The docs don't ever explicitly say that the date strings themselves are checked for validity, but returning false on failure implies to me that it will return false if it can't get a *valid* date out of the string. -62169966000 is a valid date. Perhaps instead of checking if strtotime returns a false for your error condition, check if it returns a value 1. -- Jordan CM Wambaugh Lead Software Engineer Forrent Media Solutions [EMAIL PROTECTED]
Re: [PHP-DEV] 5.3 feature freeze rapidly approaching
Hello Felipe, awesome Just commit. marcus Thursday, July 24, 2008, 5:08:03 PM, you wrote: Em Qua, 2008-07-23 às 18:52 +0200, Marcus Boerger escreveu: And then there are these: - should we finally change: typedef int (*apply_func_args_t)(void *pDest, int num_args, va_list args, zend_hash_key *hash_key); to typedef int (*apply_func_args_t)(void *pDest TSRMLS_DC, int num_args, va_list args, zend_hash_key *hash_key); so that we can drop a bunch of TSRMLS_FETCH()'es. Would it be like that? http://felipe.ath.cx/diff/zend_hash_apply_with_arguments.diff -- Regards, Felipe Pena. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: towards a 5.3 release
Hi!
b.php:
?php
namespace Foo;
class A {
function __construct() {throw new Exception('hi');}
Here in your proposal exhaustive autoload happens for all cases where
you do not actually override Exception in Foo.
?php
include 'a.php';
include 'b.php';
try {
$a = new A;
} catch (Foo::Exception $e) {
echo caught\n;
}
?
throws a Foo::Exception and echoes caught, demonstrating the
importance of load order as well.
You could do use Foo::Exception in b.php too, to solve it.
Stas, your response is quite frustrating to this problem and fits a
pattern. It seems the default response is always no or that's not a
real problem and is almost always condescending. It makes it extremely
No, there's no default response. Just in this case it happens that
your proposal introduces significant problem - performance hit on some
innocent construct without any indication of it happening. And the
solution for it that you propose is not better than the original state
of affairs - doing use solves both cases, and if not doing use then
your case has more problems. It has nothing to do with me or you - it
has to do with how things work in the engine.
difficult to have an intelligent debate with you. If you don't think
something is a real problem, perhaps a better default response is why
I think it is a problem, however I do not think this solution is going
to make things better. I am sorry if it looked like condescending to
you, it was not my intent. However, the conclusion still stays - I think
as proposed, this solution introduces more problems than solves. I would
be happy to find a solution that is better - and I am looking for one -
but right not it isn't good enough.
--
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
[PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
On Jul 24, 2008, at 8:05 PM, Rasmus Lerdorf wrote: Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/ Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. See my Wiki on it at http://wiki.php.net/svnmigration, I'm planning to get back to it this weekend. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
On Thu, Jul 24, 2008 at 8:05 PM, Rasmus Lerdorf [EMAIL PROTECTED] wrote: Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? You can count me in. I converted all of my websites and inside projects from CVS to SVN earlier this year. It seemed a daunting task, but it was trivial at best. I didn't use any of the automated tools, though, I did it all manually. Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. Not to mention the community of developers for SVN, add-ons, et cetera, and the ease of use via Apache. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. I'd agree. It may not hurt to write a quick script to do real-life commits to both services from the command line, as well, in the beginning. -- /Daniel P. Brown Better prices on dedicated servers: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
Gwynne Raskind wrote: On Jul 24, 2008, at 8:05 PM, Rasmus Lerdorf wrote: Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. See my Wiki on it at http://wiki.php.net/svnmigration, I'm planning to get back to it this weekend. Yes, I read that. But the conversion of the repository itself is only half the battle. There are a bunch of scripts in CVSROOT that need to be ported over to SVN somehow. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
On Jul 24, 2008, at 8:23 PM, Rasmus Lerdorf wrote: Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. See my Wiki on it at http://wiki.php.net/svnmigration, I'm planning to get back to it this weekend. Yes, I read that. But the conversion of the repository itself is only half the battle. There are a bunch of scripts in CVSROOT that need to be ported over to SVN somehow. My plan was to work on those next. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
I'd love to see this conversion. Let's make sure we get enough folks to volunteer to check the history of our source trees although we should in any case keep the CVS one around for browsing just in case... Andi -Original Message- From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] Sent: Thursday, July 24, 2008 5:06 PM To: PHP Developers Mailing List Subject: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net? Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
I've done a bunch of stuff with svn commit hooks and am willing to lend a hand. -lucas (mobile) On Jul 24, 2008, at 17:06, Rasmus Lerdorf [EMAIL PROTECTED] wrote: Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/ Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
On Thu, Jul 24, 2008 at 8:28 PM, Andi Gutmans [EMAIL PROTECTED] wrote: I'd love to see this conversion. Let's make sure we get enough folks to volunteer to check the history of our source trees although we should in any case keep the CVS one around for browsing just in case... Is this something with which we'd want only folks with existing CVS accounts to help? If we were to open up the initial SVN to people not (or not yet) affiliated with the group, we may be able to garner some responses from well-versed SVN folks (specifically CVS-to-SVN) who may just not have time to dedicated to the advancement of PHP as a whole. -- /Daniel P. Brown Better prices on dedicated servers: Intel 2.4GHz/60GB/512MB/2TB $49.99/mo. Intel 3.06GHz/80GB/1GB/2TB $59.99/mo. Dedicated servers, VPS, and hosting from $2.50/mo. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
If it's not happening in the next month, I'd be happy to help. I did the SimpleTest CVS to SVN conversion in about 5 minutes (including waiting on the history to be converted). I've also worked with the hook scripts and such in SVN so I might be able to help out there if someone else doesn't already have it covered. On a slightly related note, would anyone else be interested in seeing a Git repository along side Subversion? Even if people can't commit to the Git repo, I'd be happy to help set it up with the ability for them to push changes back to the SVN repo once they've prepared their patches. -T Rasmus Lerdorf wrote: Now that Subversion 1.5 has been out for a little while and it is at the point where it might actually have some benefit to us, do we have some volunteers who have some time to try converting over the repository and all the post-commit and ACL rules from CVSROOT? Talking to people here at OSCON, the consensus seems to be that moving to Subversion at this point would worthwhile. The Git/Bzr/Merc folks have better tools to deal with a central svn repository than cvs at this point, and the svn workflow and Windows tools won't leave all our less technical committers floundering. I think the most convenient approach would be to do the conversion directly on the cvs.php.net machine and run the two side-by-side with periodic imports to svn while we test things and then a freeze and a switchover at some point. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS to SVN Migration
At this point it's clear that moving from CVS to SVN for PHP has become a more or less official project. As such, there is a new mailing list [EMAIL PROTECTED] for anyone who wants to help with the move. If you're familiar with what I've already done so far (http://wiki.php.net/svnmigration) and want to help, I beg you on my knees to subscribe (send a mail to [EMAIL PROTECTED] ) and let us know what you want to do :). It's past time for PHP to make this step a just a little bit further into the future and I hope we can work together to make it happen. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Volunteers for Subversion 1.5 conversion of cvs.php.net?
On Jul 24, 2008, at 10:14 PM, Sean Coates wrote: Do we have a preference of Apache's SVN or svnserve? The former requires Apache 2+, AFAIK. I'd like to kick this discussion over to the svn-migration@ list; there are a lot of points to consider in this question and internals@ has enough threads as it is. -- Gwynne, Daughter of the Code This whole world is an asylum for the incurable. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
