Hi!
?php
ini_set('error_mask', 0);
stupidfatalerror();
?
That's also easily solved by making it INI_SYSTEM.
Note here that fatal errors can not be masked, for obvious reasons.
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN:
Hi!
If you enable error log you would be able to identify errors, even in
legacy code fairly quickly and address them as needed. The speed
increase, by Stas' own admission is very minimal here, I would wager
It's not very minimal. It's not big overall, but it speeds up
operations affected
Hi!
@ is often used to stop error/warning output to the browser on that line,
but the next couple lines of code are used to handle that error. For
example:
if (!($dom = @DOMDocument::load($file_name))) {
log_it('invalid XML: ' . $php_errormsg);
die('invalid XML');
}
So if error
On 08/25/2009 12:42 AM, Stanislav Malyshev wrote:
Hi!
Quite boring to read this thread where two persons argue about
something abstract. Stas, can you give a real life example where your
patch is necessary..?
Any code where you either use @ or error_reporting which is not -1 would
benefit
Hi!
Just wondering why nobody hasn't suggested the obvious (?) alternative
yet: Why not fix error_reporting to work like one expects. As in: If an
error level isn't in it, then nothing happens. Adding an extra option to
do that seems a bit overkill..
Because it would break other funcions
On 08/25/2009 10:35 AM, Stanislav Malyshev wrote:
Hi!
Just wondering why nobody hasn't suggested the obvious (?) alternative
yet: Why not fix error_reporting to work like one expects. As in: If
an error level isn't in it, then nothing happens. Adding an extra
option to do that seems a bit
2009/8/24 Rasmus Lerdorf ras...@lerdorf.com:
I think we should do something along the lines of what Stas is
suggesting. The current approach of allocating and sprintf'ing all
messages regardless of whether they will ever be used for anything is
painful and a huge impediment to adding
Hi,
I think the idea is good intended but will cause troubles of introduced in
5.3. I alone have a bunch of code with custom error handlers that expect to
receive all errors at all times. If the feature allows runtime tweaking via
ini_set/get, then one could add more plumbing code and
On 25-Aug-09, at 2:39 AM, Stanislav Malyshev wrote:
Hi!
If you enable error log you would be able to identify errors, even
in legacy code fairly quickly and address them as needed. The speed
increase, by Stas' own admission is very minimal here, I would wager
It's not very minimal. It's
On Mon, 24 Aug 2009, Stanislav Malyshev wrote:
If you enable error log you would be able to identify errors, even
in legacy code fairly quickly and address them as needed. The speed
increase, by Stas' own admission is very minimal here, I would wager
It's not very minimal. It's not big
On Mon, 24 Aug 2009, Rasmus Lerdorf wrote:
Lukas Kahwe Smith wrote:
anyways to me both E_STRICT and E_DEPRECATED are development tools that
can be totally ignored in production. however E_NOTICE should not occur
in production and we shouldnt encourage people to make them disappear
Derick Rethans wrote:
On Mon, 24 Aug 2009, Rasmus Lerdorf wrote:
Lukas, the problem is that all messages, E_STRICT, E_DEPRECATED,
E_NOTICE, whatever, all cause a performance hit even if the
error_reporting level is such that they will never show up anywhere.
That's what this patch is trying
Andrey Hristov schrieb:
Jani Taskinen wrote:
This should propably be some FAQ somewhere, but please commit things
in one single commit. (sparse checkouts rule! :)
One single commit? I did commit at once.
Jani meant one commit to update all three branches.
--
Sebastian Bergmann
Sebastian Bergmann wrote:
Andrey Hristov schrieb:
Jani Taskinen wrote:
This should propably be some FAQ somewhere, but please commit things
in one single commit. (sparse checkouts rule! :)
One single commit? I did commit at once.
Jani meant one commit to update all three branches.
ah,
Andrey Hristov schrieb:
ah, this is new to me, so far I haven't used SVN in collaboration with
PHP.
Have a look at the Sparse Directory Checkout Instructions section of
http://wiki.php.net/vcs/svnfaq.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://wiki.php.net/vcs/svnfaq
Look for sparse checkouts. I forgot to post a howto for graphical SVN GUIs
like TortoiseSVN, too.
Uwe
-
Uwe Schindler
theta...@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: Andrey Hristov
Hi!
Considering that there shouldn't be any errors in the first place, this
You must be kidding me. Any fopen of non-existing file, and loading of
non-perfect XML from third party produces errors. There is absolutely no
way you can write code that does anything useful that would
Hi!
You're the one asking What do you think? :) People seem to think
that this feature is another invitation to bad practice in 95% of the
cases, and only useful to the last 5% of the people who know what
they're doing... (like goto?)
It's useful to 100% people since these practices are being
Hello,
On Tue, Aug 25, 2009 at 6:36 PM, Stanislav Malyshevs...@zend.com wrote:
Hi!
Considering that there shouldn't be any errors in the first place, this
You must be kidding me. Any fopen of non-existing file, and loading of
non-perfect XML from third party produces errors. There is
Hey Stas:
On Mon, Aug 24, 2009 at 11:43:22PM -0700, Stanislav Malyshev wrote:
That's true. So, if you use code that uses $php_errormsg, of course you
can not use this optimization and should not enable it (at least for
error types and code parts that you use $php_errormsg with).
Exactly.
Hello Jani:
On Tue, Aug 25, 2009 at 11:11:19AM +0300, Jani Taskinen wrote:
On 08/25/2009 10:35 AM, Stanislav Malyshev wrote:
Because it would break other funcions (namely, $php_errormsg, error
handlers, etc.) which may be used by some.
Well, not necessarily. How doesn't your patch break
Daniel Convissor wrote:
Hello Jani:
On Tue, Aug 25, 2009 at 11:11:19AM +0300, Jani Taskinen wrote:
On 08/25/2009 10:35 AM, Stanislav Malyshev wrote:
Because it would break other funcions (namely, $php_errormsg, error
handlers, etc.) which may be used by some.
Well, not necessarily. How
Hi!
Sorry, I just don't get it. If the mask thing kills some level..what's
the point in enabling it in the first place? And IIRC, E_STRICT is not
part of E_ALL..
There's no point in enabling it. The point is that now PHP generates
full set of data even for DISABLED errors. And spends
Attempting to load 2 PHP modules in the same httpd instance.
modified mod_php5.c, php_apache.h, php.sym and sapi_apache2.c
to reflect a unique module name for the second compiled .so, as well as
change the PHP_MAGIC_TYPE to something unique.
basically changing php5_module to php5UNIQUE_module
and
Hi,
even if no known extension uses it I won't remove it in 5.3 as it is a
break of ABI compatibility.
For 6 I assume one might remove it, especially as it doesn't know about
IS_UNICODE.
johannes
On Mon, 2009-08-24 at 08:24 +0200, Patrick ALLAERT wrote:
Hi list,
Apparently, function
I'am making some experiments on Symbian for Nokia mobile and I'am looking
for some basically PHP distribution that can be compiled in.
Regards,
Themis Vassiliadis
I suggest you set up multiple instances of FastCGI instead and let
your web server choose the right CGI gateway per request.
On 8/26/09, Chris Trahey ctra...@csisd.org wrote:
Attempting to load 2 PHP modules in the same httpd instance.
modified mod_php5.c, php_apache.h, php.sym and
27 matches
Mail list logo
