Re: [PHP-DEV] Re: [patch] error masks
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: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [patch] error masks
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 300-400%. Can you propose many other changes that would speed up any set of opcodes 300% in 10 lines of patch? ;) saving memory and eliminating what effectively is a NOOP is a good idea, making it a configurable, user settable option, will simply lead to much abuse. There would be no abuse that is not happening today, in almost every production install on Earth. Through the whole scenario you have consistently ignored the fact that we talk about errors that are *ignored* today, and only evidence of their general existence somewhere in the code is the slowdown - which is not measurable anyway, since there's no base for comparison, since there's no way to run _without_ the slowdown without this patch. If the ultimate goal here is to save memory, why not simply set the mask to 0, which if understand Stas' original message correctly would equate its value to whatever the error reporting is set to. You can, of course. But, as I explained, because there could be scenarios when you (ok, not you, somebody else) would want to use advanced tools which do not use error_reporting setting but have their own decision mechanisms, and you may be ready to pay the memory/speed penalty, say, for more accurate error statistics, etc. - at least temporary or on the part of your setup. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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 processing is totally turned off, $php_errormsg won't be
populated.
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).
Also, if you use @ to stop warning output to the browser you should read
the manual about display_errors and part of the security guidelines when
it says never enable display_errors in production ;)
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com http://www.zend.com/
(408)253-8829 MSN: s...@zend.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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 from it by not processing errors that go nowhere. I just looked at Zend Framework - with is pretty clean with regard to E_NOTICE/E_STRICT problems - and @ is used in dozens of classes around. The speedup would be probably not very big for whole RL application, but it's a 10-line patch, and little things help too. 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.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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 (namely, $php_errormsg, error handlers, etc.) which may be used by some. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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 overkill.. 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 them? Just do the same but without adding new option. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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 informative E_NOTICE and E_STRICT messages in the future. A good example of the benefit of this patch is upgrading a server running older PHP code that causes a lot of E_STRICT messages. The performance hit can be significant to the point where people may downgrade to the older version until they can get around to cleaning up the code. Having the ability to properly turn off E_STRICT such that not only are E_STRICT messages not shown, but they also don't eat up valuable cpu cycles is something we should have done long ago. It is non-intuitive that disabling an error type doesn't also remove the performance hit associated with generating that error message. -Rasmus As an outsider, and from what I've read here, surely the solution is to simply move the test to determine if an error type is reportable. If anything, as you _ARE_ all saying that there is a slowdown, I should maybe file a bug ... My @ridden code is really slow, even when I turn off error_reporting! So, as an outsider, I'm +1 for speeding up PHP by not running unnecessary code, but -1 for introducing what is surely quite obviously an unnecessary ini entry. speech style=iInspirationalEssentially, it's a bug folks! So let's fix it!/speech Regards, Richard. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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 workaround, but it still doesn't make it BC to the expected behavior for existing 5.x apps. However I fully agree E_NOTICE should: 1) be reserved for informational may-be-bad-but-usually-is-ok messages 2) not have performance impact when disabled (i.e. production) The problem? Right now important errors that could cause data damage if ignored are E_NOTICE instead of E_WARNING. I'm talking E_NOTICE when you using variables that don't exist, missing constants and so on. All of this should be E_WARNING so my production code can stop and notify me when it's encountered, then I wouldn't mind filtering E_NOTICE. Also Stas, consider why are you trying to treat the symptom of unwanted errors slowing things down. I would bet it's something like the stream APIs emitting errors on 404 response and such. Some API-s really throw notices and warnings where it makes no sense, so people mute them out of necessity (or use handlers). I'd rather fix the API-s instead of pretend it doesn't happen by masking the errors. All of the above would be a job for 6.0 IMHO, 5.x has pulled enough changes under our feet and it's really not fun anymore :P Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [patch] error masks
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 not big overall, but it speeds up
operations affected 300-400%. Can you propose many other changes
that would speed up any set of opcodes 300% in 10 lines of patch? ;)
I have a few of those in our custom build of PHP, but none of those
would be ready for general consumption since they take away some of
PHP's conveniences. There are not many such changes, but a fair number
are possible.
saving memory and eliminating what effectively is a NOOP is a good
idea, making it a configurable, user settable option, will simply
lead to much abuse.
There would be no abuse that is not happening today, in almost
every production install on Earth. Through the whole scenario you
have consistently ignored the fact that we talk about errors that
are *ignored* today, and only evidence of their general existence
somewhere in the code is the slowdown - which is not measurable
anyway, since there's no base for comparison, since there's no way
to run _without_ the slowdown without this patch.
You had one really good example from Dan, with respect to
track_errors, which is real easy to miss. The 3rd party library maybe
using that functionality to handle certain errors and by doing a
global ingore errors, you would effectively cut down on error
information and in some cases make the code thing there is no error.
There are a few code paths I can see on google where code works
something like this:
$php_errormsg = null;
some_function();
if ($php_errormsg) {
exit($php_errormsg);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [patch] error masks
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 overall, but it speeds up operations affected 300-400%. Can you propose many other changes that would speed up any set of opcodes 300% in 10 lines of patch? ;) Considering that there shouldn't be any errors in the first place, this is of course a moot point. Sure, 3rd party code (PEAR pcakges?) might throw errors like crazy on PHP 5, they need to be *fixed* anyway. So if the minimal overhead of the *whole* application is not close to affected... I think it'd be a very bad idea to add this extra mask. Yet another ini setting as well. For the record: I'm against adding this. regards, Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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 entirely. 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 to address. To write optimal code, they have to be entirely clean of all messages including E_DEPRECATED and E_STRICT. And how exactly is that a problem? Sure, there are some cases where PHP functions are too noisy, but that should be addressed instead. regards, Derick -- http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org twitter: @derickr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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 to address. To write optimal code, they have to be entirely clean of all messages including E_DEPRECATED and E_STRICT. And how exactly is that a problem? Sure, there are some cases where PHP functions are too noisy, but that should be addressed instead. You are making the assumption that everybody agrees on E_NOTICE, E_STRICT and E_DEPRECATED being things to be fixed in your code. That is not the case and punishing people for not following exactly the same coding style as you doesn't make sense when it could easily be avoided. Background info: We decided to patch PHP to not generate E_NOTICE for undefined variables or (worse) array offsets because we use this language feature a lot and cannot afford the overhead caused by E_NOTICEs even if error_reporting is set to ignore E_NOTICE. And you won't be able to convince us to change this policy because being able to do things like if (!$visited[$city]++) is more valuable (i.e. keeps the code uncluttered) to us than the E_NOTICE. We use http://cschneid.com/php/phplint.php (in a commit hook) instead to catch typos. It's not perfect but does the job for us. Summary: Don't punish different coding styles unless really necessary. Cheers, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ NEWS ext/mysqlnd/mysqlnd_portability.h
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 BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ NEWS ext/mysqlnd/mysqlnd_portability.h
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, this is new to me, so far I haven't used SVN in collaboration with PHP. How do I commit to three branches (which are they ? 5.3, 6.0 and ?) when I can be in only one directory at a time - checkout of 5.3 or 6.0. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ NEWS ext/mysqlnd/mysqlnd_portability.h
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://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ NEWS ext/mysqlnd/mysqlnd_portability.h
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 [mailto:p...@hristov.com] Sent: Tuesday, August 25, 2009 5:24 PM To: Sebastian Bergmann Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Re: svn: /php/php-src/branches/PHP_5_3/ NEWS ext/mysqlnd/mysqlnd_portability.h 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, this is new to me, so far I haven't used SVN in collaboration with PHP. How do I commit to three branches (which are they ? 5.3, 6.0 and ?) when I can be in only one directory at a time - checkout of 5.3 or 6.0. Andrey -- 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] Re: [patch] error masks
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 guaranteedly never produce errors. Moreover, any attempt to do it would make your code 2-3 times slower, as you'd have to do most of the actions twice - once to check if it would succeed and one to actually do it (as with file_exists/fopen) and even then you could fail. is of course a moot point. Sure, 3rd party code (PEAR pcakges?) might throw errors like crazy on PHP 5, they need to be *fixed* anyway. So if They won't be fixed. I am getting an impression nobody's actually reading the comments, only writing. Once again: I'm not talking about people that are looking for errors in their code to debug, I am talking about setups disabling errors ON PURPOSE, because they DO NOT WANT them. Different use case. BTW we discussed that in Chicago meetup and agreed we want to do it. Of course, not that agreeing on anything ever would stand in a way of wasting another bunch of time on repeating same stuff over and over and nobody listening and blocking another useful feature. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [patch] error masks
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 used NOW, and this patch only targets these specific use cases when people are doing it NOW. And no, IMO the agreements in Chicago or wherever should still pass through the ML or something, I assume lots of people were not able to go there, and lots of those people won't be happy with some of the decisions. Yes, I know - including the very people that made that very decision. That makes one hell of a decision taking process. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [patch] error masks
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 absolutely no way you can write code that does anything useful that would guaranteedly never produce errors. Moreover, any attempt to do it would make your code 2-3 times slower, as you'd have to do most of the actions twice - once to check if it would succeed and one to actually do it (as with file_exists/fopen) and even then you could fail. is of course a moot point. Sure, 3rd party code (PEAR pcakges?) might throw errors like crazy on PHP 5, they need to be *fixed* anyway. So if They won't be fixed. I am getting an impression nobody's actually reading the comments, only writing. Once again: I'm not talking about people that are looking for errors in their code to debug, I am talking about setups disabling errors ON PURPOSE, because they DO NOT WANT them. Different use case. BTW we discussed that in Chicago meetup and agreed we want to do it. Of course, not that agreeing on anything ever would stand in a way of wasting another bunch of time on repeating same stuff over and over and nobody listening and blocking another useful feature. 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?) And no, IMO the agreements in Chicago or wherever should still pass through the ML or something, I assume lots of people were not able to go there, and lots of those people won't be happy with some of the decisions. Best, -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch Men never do evil so completely and cheerfully as when they do it from a religious conviction. -- Pascal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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. Totally killing E_STRICT on it's own seems like the biggest win (in the right circumstances). My main point is that we need to think this thing through carefully and document it well. Also, if you use @ to stop warning output to the browser you should read the manual about display_errors and part of the security guidelines when it says never enable display_errors in production ;) Of course. But folks don't want those same messages showing up in the error log, either. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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 them? Just do the same but without adding new option. The patch allows setting reporting to E_ALL while using the mask to kill just E_STRICT. --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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 doesn't your patch break them? Just do the same but without adding new option. The patch allows setting reporting to E_ALL while using the mask to kill just E_STRICT. 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.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] error masks
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 time/memory on that. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Multiple Apache Modules
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 application/x-httpd-php to application/x-UNIQUE-php There is trouble at apache startup with both enabled, but not every time. Is it conceivable to have a user-defined module name(space) for loading multiple php shared objects? The use: 1. Load mulitple PHP modules at startup. 2. Inside virtual hosts, assign whichever php module is appropriate 3. have v-hosts that point to the same files, but use different versions of php\ 4. requests can look like this: php5-2-10.mysite.com php5-3-0.mysite.com php6-0.mysite.com Chris Trahey Web Applications Developer Database Administrator CSISD [Technology]
Re: [PHP-DEV] Dead code
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 _php_math_basetolong at http://lxr.php.net/source/php-src/ext/standard/math.c#802 isn't used anymore since Mon Sep 3 16:26:31 2001 UTC. It was previously used by bindec, hexdec, octdec and base_convert functions but has been replaced by _php_math_basetozval(). None of the PECL extension are using it either (at least in http://svn.php.net/repository/pecl/*/trunk/). Any objection I remove it? -- Patrick --- http://code.google.com/p/peclapm/ - Alternative PHP Monitor -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Distribution for mobile
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
Re: [PHP-DEV] Multiple Apache Modules
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 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 application/x-httpd-php to application/x-UNIQUE-php There is trouble at apache startup with both enabled, but not every time. Is it conceivable to have a user-defined module name(space) for loading multiple php shared objects? The use: 1. Load mulitple PHP modules at startup. 2. Inside virtual hosts, assign whichever php module is appropriate 3. have v-hosts that point to the same files, but use different versions of php\ 4. requests can look like this: php5-2-10.mysite.com php5-3-0.mysite.com php6-0.mysite.com Chris Trahey Web Applications Developer Database Administrator CSISD [Technology] -- -- Tjerk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
