Re: [PHP-DEV] [path] fixing errors, take 2
On Sun, Dec 19, 2010 at 04:31, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Since my first attempt to make error reporting in PHP more efficient (see
epic thread here:
http://www.pubbs.net/200908/php/49633-php-dev-patch-error-masks.html) I
thought about another approach to fixing it.
This approach eliminates the need for additional .ini setting and shortcuts
only those errors that would not have any consequences - i.e. would not be
displayed, logged, stored, converted to exception or otherwise have any
effect on the outside world. The benefit of this approach is obvious -
nothing changes for the user, only the code runs faster. The cost is that we
add one handler to utility_functions and thus code that overrides error
callback (debuggers, etc.) would have to provide their own handler if they
want the same functionality (by default if this handler detects somebody
stole error callback it turns off).
The patch is attached.
Any objections for trunk?
AFAICT from the patch..
if (@strpos()) {} else { var_dump(error_get_last()); }
will give you the last error that happened before strpos()?
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [path] fixing errors, take 2
On Sun, Dec 19, 2010 at 10:56, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
AFAICT from the patch..
if (@strpos()) {} else { var_dump(error_get_last()); }
will give you the last error that happened before strpos()?
Hmm... that unfortunately depends on ignore_repeated_errors, I didn't see
this use case. With error_get_last() we probably can't fix it since it
requires storing full error message for every error. That kind of sucks :(
I like the idea behind the patch, and I cannot think of a clean way
around the error_get_last() problem.
error_get_last() also has issues with user defined error handler, so I
suppose we should just document it properly..
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] SplObjectStorage::removeCommon and removeUncommon
On Sun, Dec 19, 2010 at 15:49, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Sun, 19 Dec 2010 05:33:56 -, Matthew Turland tobias...@gmail.com wrote: Attached are source/test and manual patches for the addition of two methods to the SplObjectStorage class. These methods, removeCommon and removeUncommon, add support for the difference and intersection set operations, respectively. I'm sorry, I must be missing something because what exactly is the difference between removeCommon and removeAll? Is this just bikeshedding over the method names, or did you not bother reading the patches? (the doc patch even includes examples). -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] SplObjectStorage::removeCommon and removeUncommon
On Sun, Dec 19, 2010 at 16:16, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Sun, 19 Dec 2010 15:12:17 -, Hannes Magnússon hannes.magnus...@gmail.com wrote: On Sun, Dec 19, 2010 at 16:05, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Sun, 19 Dec 2010 15:03:22 -, Hannes Magnússon hannes.magnus...@gmail.com wrote: On Sun, Dec 19, 2010 at 15:49, Gustavo Lopes glo...@nebm.ist.utl.pt wrote: On Sun, 19 Dec 2010 05:33:56 -, Matthew Turland tobias...@gmail.com wrote: Attached are source/test and manual patches for the addition of two methods to the SplObjectStorage class. These methods, removeCommon and removeUncommon, add support for the difference and intersection set operations, respectively. I'm sorry, I must be missing something because what exactly is the difference between removeCommon and removeAll? Is this just bikeshedding over the method names, or did you not bother reading the patches? (the doc patch even includes examples). I did, and near the end it has: SPL_ME(SplObjectStorage, removeAll, arginfo_Object, 0) + SPL_ME(SplObjectStorage, removeCommon, arginfo_Object, 0) So there's already a removeAll. Read the doc patch. The description says it all, but if you still wonder then look at the example. In the example, substituting removeCommon by removeAll has exactly the same result: Haha. I was under the impression removeAll().. did what the method name says, sorry :P -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/mbstring dependencies
On Mon, Dec 6, 2010 at 09:31, Dmitry Stogov dmi...@zend.com wrote:
Hi,
The proposed patch completely removes ext/mbstring compile-time
dependencies. As result the same php binaries may be used for Asian and
European languages without performance degradation. ext/mbstring now may be
compiled as a DSO. I'm going to commit the patch on Wednesday.
Any comments are welcome.
Random scrolling through the patch:
Index: ext/mbstring/mbstring.c
+// to = php_mb_convert_encoding(from, from_len, encoding_to,
encoding_from, to_length);
+// return to ? 0 : -1;
and WS
+!memcmp(none, name, sizeof(none) - 1 {
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] git anyone?
On Thu, Nov 25, 2010 at 16:28, Herman Radtke hermanrad...@gmail.com wrote: I am not in favour; I will repeat what I just wrote to Davey: DVCS is also a lot more egocentric thing, instead of collaboration. You want your stuff exposed to as many developers as possible instead of walled gardens. It might be easy enough to share, but discovery is a lot harder. Developers can already wall themselves off now with the github mirror. No. People. Stop saying that. It simply isn't true. The 'github mirror' hasn't been active for 6months. It got killed because our box simply couldn't handle the job. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
