Re: [PHP-DEV] mbstring/exif/win32
Both 4.3 and Head still have a problem with mbstring not being default under win32. Exif module can be compiled but not loaded because it uses a function from mbstring. Exif tests for HAVE_MBSTRING and COMPILE_DL_MBSTRING. The question is why HAVE_MBSTRING is defined but COMPILE_DL_MBSTRING is undefined. I cannot see where HAVE_MBSTRING could be defined on win32. Several places use this line to check for its presence: #if HAVE_MBSTRING !defined(COMPILE_DL_MBSTRING) This works fine for say main/rfc1867.c. Does it work for you? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring/exif/win32
At 13:17 16.12.2002, Edin Kadribasic wrote: Both 4.3 and Head still have a problem with mbstring not being default under win32. Exif module can be compiled but not loaded because it uses a function from mbstring. Exif tests for HAVE_MBSTRING and COMPILE_DL_MBSTRING. The question is why HAVE_MBSTRING is defined but COMPILE_DL_MBSTRING is undefined. I cannot see where HAVE_MBSTRING could be defined on win32. Several places use this line to check for its presence: #if HAVE_MBSTRING !defined(COMPILE_DL_MBSTRING) This works fine for say main/rfc1867.c. Does it work for you? Edin Sorry i loaded the wrong exif module. Now it works perfect with all versions. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
At 09:14 AM 11/13/2002 -0500, Andrei Zmievski wrote: On Wed, 13 Nov 2002, Melvyn Sopacua wrote: FWIW: * If this is ever going to make core as a part of PHP's i18n efforts, you are going to have to deal with the 'unseen' at some point. You are not going to identify them, by testing it within a select group. For this reason, the userbase is always the guinnea-pig with every new feature in a release. Explain to me please why --enable-mbstring is not enough. The userbase is not going to be a guinea-pig since only a subset of users will have a need for mbsting and those that do can use the switch. Those that don't will not even notice that it's not enabled. It's not that I think enabling it is such a bad idea but as we're going for PHP 5 right after PHP 4.3 anyway I don't think it's too bad to wait for that. I'm sure lots of people will test PHP 5 RC's so there'll be lots of testing (long sentence but I hope it can be understood :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On Fri, 15 Nov 2002, Andi Gutmans wrote: It's not that I think enabling it is such a bad idea but as we're going for PHP 5 right after PHP 4.3 anyway I don't think it's too bad to wait for that. I'm sure lots of people will test PHP 5 RC's so there'll be lots of testing (long sentence but I hope it can be understood :) I think we will still have 4.4.0 before PHP 5. The timeframe between 4.3.0 and 5 is just too large not to have another release. -Andrei http://www.gravitonic.com/ Everything should be made as simple as possible, but not simpler. -- Albert Einstein -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
At 11:14 PM 11/14/2002 -0500, Andrei Zmievski wrote: On Fri, 15 Nov 2002, Andi Gutmans wrote: It's not that I think enabling it is such a bad idea but as we're going for PHP 5 right after PHP 4.3 anyway I don't think it's too bad to wait for that. I'm sure lots of people will test PHP 5 RC's so there'll be lots of testing (long sentence but I hope it can be understood :) I think we will still have 4.4.0 before PHP 5. The timeframe between 4.3.0 and 5 is just too large not to have another release. Hmm, no matter when we create a PHP 5 CVS the timeframe will be too large. That's OK. I don't see a problem with having a 4.4.0 if it's needed but that doesn't mean I think work on PHP 5 should start right after 4.3.0. Preferably we'd stick to 4.3.x though. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Derick Rethans wrote: On Wed, 13 Nov 2002, Yasuo Ohgaki wrote: Jani Taskinen wrote: Oh, I forgot: How many bug reports have we got so far for that fuckup with 4.2.3 ??? I _REALLY_ don't want to see another wave of those for 4.3.0.. Do you mean array input handling bug? It's not mbstring developers' fault. It doesn't really matter who's fault it was, it's a fact that the mbstring module caused this fuckup. This would be the reason why it should be enabled by default. Bug is reported repeatedly even if it isn't enabled by default. Most importantly, person who patched didn't test the patch well since it isn't enabled by default probably. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
For me it was the wide stream of bugreports coming in; can't speak for the others though. If the stream of bug reports was the criteria the whole of PHP should be considered highly experimental :) Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On 11/13/02, Derick Rethans [EMAIL PROTECTED] wrote: On Wed, 13 Nov 2002, Marcus Börger wrote: At 04:11 13.11.2002, Jani Taskinen wrote: Since when have we started to use users as guinea-pigs for testing EXPERIMENTAL extensions without them even really knowing about it?!! mbstring is not EXPERIMENTAL and i said let them try it. That does not mean test it. We think it works . uhm, I don't think it works stable enough. Which part of have used it in production for 2 years with 0 problems means that it's not stable? :) The parts that myself (and Marcus) want to push *are* very stable. Let's just disable the non-stable, lazy programmer hacky parts by default and everyone will be happy. (Still no responses to my no-nonsense suggestion) --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
At 10:53 13.11.2002, Wez Furlong wrote: On 11/13/02, Derick Rethans [EMAIL PROTECTED] wrote: On Wed, 13 Nov 2002, Marcus Börger wrote: At 04:11 13.11.2002, Jani Taskinen wrote: Since when have we started to use users as guinea-pigs for testing EXPERIMENTAL extensions without them even really knowing about it?!! mbstring is not EXPERIMENTAL and i said let them try it. That does not mean test it. We think it works . uhm, I don't think it works stable enough. Which part of have used it in production for 2 years with 0 problems means that it's not stable? :) And where does EXPERIMENTAL come from? It simply is not! The parts that myself (and Marcus) want to push *are* very stable. push is the right word i should have used. Let's just disable the non-stable, lazy programmer hacky parts by default and everyone will be happy. That would be the best solution for me :-) (Still no responses to my no-nonsense suggestion) --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
At 10:53 13-11-2002, Wez Furlong wrote: On 11/13/02, Derick Rethans [EMAIL PROTECTED] wrote: On Wed, 13 Nov 2002, Marcus Börger wrote: At 04:11 13.11.2002, Jani Taskinen wrote: Since when have we started to use users as guinea-pigs for testing EXPERIMENTAL extensions without them even really knowing about it?!! mbstring is not EXPERIMENTAL and i said let them try it. That does not mean test it. We think it works . uhm, I don't think it works stable enough. Which part of have used it in production for 2 years with 0 problems means that it's not stable? :) The parts that myself (and Marcus) want to push *are* very stable. Let's just disable the non-stable, lazy programmer hacky parts by default and everyone will be happy. FWIW: * If this is ever going to make core as a part of PHP's i18n efforts, you are going to have to deal with the 'unseen' at some point. You are not going to identify them, by testing it within a select group. For this reason, the userbase is always the guinnea-pig with every new feature in a release. * Getting real bug reports is a good thing(tm). Breaking compilation because of sloppy symbol protections sucks(r). The number of bugs should not be a factor in this scenario, because once it becomes core, you're gonna have to deal with them anyway. * Enabling by default for 4.3.0 is actually the best point in time, unless there's going to be a 4.4.0. You don't want this to be done in 5.0.0, because the new OO layer, other new features and especially BC-breaking issues will have to be focused on. (I'm not saying PHP 5 is intending to break BC - just that there is a high probability issues arrise, which we're not foreseeable). A x.x.0 release is the best release to do it in, because people who demand a high level of stability already will skip it and still it will have a large enough audience to flush out the bugs nobody thought of. All in all - I think we should enable the parts mentioned by Wez, in RC1. The default behavior should be it's compiled in, but doesn't impact any functions. If there is a large number of distinct bug reports, then it's obvious the extension is not mature enough for it and because of the schedule (not the number) it should be disabled in the final release. This is of course based on the assumption, that there are no unresolved bugs with the 'stable parts' at present. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On Wed, 13 Nov 2002, Melvyn Sopacua wrote: FWIW: * If this is ever going to make core as a part of PHP's i18n efforts, you are going to have to deal with the 'unseen' at some point. You are not going to identify them, by testing it within a select group. For this reason, the userbase is always the guinnea-pig with every new feature in a release. Explain to me please why --enable-mbstring is not enough. The userbase is not going to be a guinea-pig since only a subset of users will have a need for mbsting and those that do can use the switch. Those that don't will not even notice that it's not enabled. -Andrei http://www.gravitonic.com/ I must say I find television very educational. The minute somebody turns it on, I go to the library and read a good book. - Groucho Marx -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Andrei Zmievski [EMAIL PROTECTED] wrote: On Wed, 13 Nov 2002, Melvyn Sopacua wrote: FWIW: * If this is ever going to make core as a part of PHP's i18n efforts, you are going to have to deal with the 'unseen' at some point. You are not going to identify them, by testing it within a select group. For this reason, the userbase is always the guinnea-pig with every new feature in a release. Explain to me please why --enable-mbstring is not enough. The userbase is not going to be a guinea-pig since only a subset of users will have a need for mbsting and those that do can use the switch. Those that don't will not even notice that it's not enabled. I think your words only a subset of users would be more accurate if it went only a subset of users who can write bug reports in English. Moriyoshi -Andrei http://www.gravitonic.com/ I must say I find television very educational. The minute somebody turns it on, I go to the library and read a good book. - Groucho Marx -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
At 15:14 13-11-2002, Andrei Zmievski wrote: On Wed, 13 Nov 2002, Melvyn Sopacua wrote: FWIW: * If this is ever going to make core as a part of PHP's i18n efforts, you are going to have to deal with the 'unseen' at some point. You are not going to identify them, by testing it within a select group. For this reason, the userbase is always the guinnea-pig with every new feature in a release. Explain to me please why --enable-mbstring is not enough. For the same reason, that there is no --disable-standard. Of course - if mbstring is not going to become core, this doesn't apply. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On November 13, 2002 07:50 am, Melvyn Sopacua wrote: FWIW: * If this is ever going to make core as a part of PHP's i18n efforts, you are going to have to deal with the 'unseen' at some point. You are not going to identify them, by testing it within a select group. For this reason, the userbase is always the guinnea-pig with every new feature in a release. If mbstring proves to be as popular as some people say many people will take a chance and enable the extension while compiling given the size of PHP user base that should be more then enough people to discover bugs in the extension. However, there is no need to put some 2 million (or whatever the latest netcraft data is) hosts running PHP at risk by enabling it by default. Unfortunately every extension has bugs, but usually such bugs do not affect PHP overall performance, mbstring is different, a bug in it can affect PHP behavior. Because of this I believe we need exercise extreme caution before even considering enabling it by default. * Getting real bug reports is a good thing(tm). Breaking compilation because of sloppy symbol protections sucks(r). The number of bugs should not be a factor in this scenario, because once it becomes core, you're gonna have to deal with them anyway. Given prior history, when an extension has many bugs or is being heavily modified it was/is marked experimental and kept so several months even after the development was halted and bugs were addressed. Why an important extension like mbstring should be different? * Enabling by default for 4.3.0 is actually the best point in time, unless there's going to be a 4.4.0. You don't want this to be done in 5.0.0, because the new OO layer, other new features and especially BC-breaking issues will have to be focused on. (I'm not saying PHP 5 is intending to break BC - just that there is a high probability issues arrise, which we're not foreseeable). I think there is a 60% chance that they'll be further 4.3.X releases after 4.3.0 simply because this release represents a fair number of large changes and most likely will require several bug fixing releases. It is even remotly possible that 4.4.X may happen, but I am in no position to make such promises so, this is something I can only make educated guesses on. A x.x.0 release is the best release to do it in, because people who demand a high level of stability already will skip it and still it will have a large enough audience to flush out the bugs nobody thought of. Sure, but if the people who try it get burnt by the mbstring extension, you can be sure that in the next release at least half of them will disable it straight off. And if these people are hosting providers, they'll refuse the turn it on for their customers because they would consider it a hindrance to the stability of their PHP. You are going to accomplish the exact opposite of what you've set out to do. All in all - I think we should enable the parts mentioned by Wez, in RC1. The default behavior should be it's compiled in, but doesn't impact any functions. If there is a large number of distinct bug reports, then it's obvious the extension is not mature enough for it and because of the schedule (not the number) it should be disabled in the final release I am lazy and I am sure many other people are too, certain features like overloading make life rather simple in that regard. You can be sure many people who are as lazy as I am will turn it on. Because to them it would be an important feature. Consider if a person is trying to make large, existing application support multi-byte, with overload they can avoid changing a large chunks of their code, they'll try it. If it does not work, many will simply drop mbstring because for all its wonderful functionality, it does not work as advertised. So, saying lets enable part A because it is stable and disable part B and C, just does not work. It is either all or nothing. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
At 15:14 13-11-2002, Andrei Zmievski wrote: On Wed, 13 Nov 2002, Melvyn Sopacua wrote: FWIW: * If this is ever going to make core as a part of PHP's i18n efforts, you are going to have to deal with the 'unseen' at some point. You are not going to identify them, by testing it within a select group. For this reason, the userbase is always the guinnea-pig with every new feature in a release. Explain to me please why --enable-mbstring is not enough. For the same reason, that there is no --disable-standard. Of course - if mbstring is not going to become core, this doesn't apply. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Andrei Zmievski wrote: Explain to me please why --enable-mbstring is not enough. Obviously, --enable-mbstring is not enough. There are several reasons including crashes without mbstring. If one think it's not stable (while real users do not think its unstable), --enable mbstring should be enough. There are problems --disable-mbstirng or --enable-mbstring=shared, but it's users problem, if it's enabled by default. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Hi, Thanks for the report. Although I found a bug in the overloading code, I wonder why the mail() function entry was not found on RINIT. Any insights? Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote: Hi, Thanks for the report. Although I found a bug in the overloading code, I wonder why the mail() function entry was not found on RINIT. Any insights? It seems the mail() function is not avaliable on that system because sendmail was not found on the system. The function mail() on unix systems appears to be dependant on sendmail avaliablity or atleast something that would cause the HAVE_SENDMAIL flag to be set. Ilia Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Oops, why didn't I notice such a trivial thing before asking a braindead question... Anyway I bet the problem should be gone by my patch that was just commited. Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote: Hi, Thanks for the report. Although I found a bug in the overloading code, I wonder why the mail() function entry was not found on RINIT. Any insights? It seems the mail() function is not avaliable on that system because sendmail was not found on the system. The function mail() on unix systems appears to be dependant on sendmail avaliablity or atleast something that would cause the HAVE_SENDMAIL flag to be set. Ilia Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most PHP programs are developed with non-multibyte languages in mind and mbstring only adds unnecessary overhead. People who need it can easily enable it or ask their ISPs to enable it, if they had done so already. 2) mbstring extension is a fairly complex piece of code and iirc is the youngest extension of this magnitude that is enabled by default. Although the extension developers are very prompt at fixing bugs, the fact they need to do this fairly frequently, at least to me, implies that the extension is not yet mature enough to be enabled by default. Also, judging by the number of changes in the CVS to the extension, a lot of new functionality was added to the extension recently and has not been tested outside the pre process. Maybe by next PHP release is made, it will be better tested and more stable. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
I've just tried the latest CVS, it still crashes, the backtrace is same as before. Ilia On November 12, 2002 05:21 pm, Moriyoshi Koizumi wrote: Oops, why didn't I notice such a trivial thing before asking a braindead question... Anyway I bet the problem should be gone by my patch that was just commited. Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote: Hi, Thanks for the report. Although I found a bug in the overloading code, I wonder why the mail() function entry was not found on RINIT. Any insights? It seems the mail() function is not avaliable on that system because sendmail was not found on the system. The function mail() on unix systems appears to be dependant on sendmail avaliablity or atleast something that would cause the HAVE_SENDMAIL flag to be set. Ilia Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On Tue, 12 Nov 2002, Ilia A. wrote: Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most PHP programs are developed with non-multibyte languages in mind and mbstring only adds unnecessary overhead. People who need it can easily enable it or ask their ISPs to enable it, if they had done so already. 2) mbstring extension is a fairly complex piece of code and iirc is the youngest extension of this magnitude that is enabled by default. Although the extension developers are very prompt at fixing bugs, the fact they need to do this fairly frequently, at least to me, implies that the extension is not yet mature enough to be enabled by default. Also, judging by the number of changes in the CVS to the extension, a lot of new functionality was added to the extension recently and has not been tested outside the pre process. Maybe by next PHP release is made, it will be better tested and more stable. I must (still) agree. +1 for making it disabled for now.. (people who need it, already know to use --enable-mbstring with 4.2.3) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Moriyoshi Koizumi wrote: Hi, Thanks for the report. Although I found a bug in the overloading code, I wonder why the mail() function entry was not found on RINIT. Any insights? If sendmail binary cannot be found at configure time, mail() may not be compiled in PHP under UNIX like OS :( IMO, we should always compile mail() function. Distributors sometimes release PHP packages (i.e. RPM) w/o mail() sometimes. -- Yasuo Ohgaki Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring and 4.3.0
Jani Taskinen writes: I must (still) agree. +1 for making it disabled for now.. (people who need it, already know to use --enable-mbstring with 4.2.3) Exactly. It should remain off by default until it's solid. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Mike Robinson wrote: Jani Taskinen writes: I must (still) agree. +1 for making it disabled for now.. (people who need it, already know to use --enable-mbstring with 4.2.3) Exactly. It should remain off by default until it's solid. Guys, please comment when you use it actually. i.e. mention unsolid things, problems, etc. Bug reports are welcome. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
At 23:56 12.11.2002, Ilia A. wrote: Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most PHP programs are developed with non-multibyte languages in mind and mbstring only adds unnecessary overhead. People who need it can easily enable it or ask their ISPs to enable it, if they had done so already. NO. Most people do not have the choice and ISPs usually take the default. If the default is not approriate they do not use it. If you read the whole thread you find enough reasons how apps benefit from mbstring and what could be easily achieved with languages like german. 2) mbstring extension is a fairly complex piece of code and iirc is the youngest extension of this magnitude that is enabled by default. Although the extension developers are very prompt at fixing bugs, the fact they need to do this fairly frequently, at least to me, implies that the extension is not yet mature enough to be enabled by default. Also, judging by the number of changes in the CVS to the extension, a lot of new functionality was added to the extension recently and has not been tested outside the pre process. Maybe by next PHP release is made, it will be better tested and more stable. Ilia Ok there are some problems and that is the backside of it: Some of us implement new functionality and some merge code from the original development tree. In other words: Maybe we should slow down or even stop feature development until 4.3 is out After php 4.3 we hope the new implementation can be used. As long as function overloading isn't used there is no harm from mbstring (disable is the default). And some extra bytes shouldn't affect anybody today. If you say most apps are not designed to use mbstring then it's nice that all those could try mbstring which would like to. So we can get feedback. As long as it isn't default there will be none or only little feedback. The stability is very high and we have many *.phpt tests to help us find failures and make it even more stable. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Since when have we started to use users as guinea-pigs for testing EXPERIMENTAL extensions without them even really knowing about it?!! You can't FORCE anybody to use it. 99% of apps out there DO NO NEED IT..get it?? (they've managed without it very long time..) --Jani On Wed, 13 Nov 2002, Marcus Börger wrote: At 23:56 12.11.2002, Ilia A. wrote: Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most PHP programs are developed with non-multibyte languages in mind and mbstring only adds unnecessary overhead. People who need it can easily enable it or ask their ISPs to enable it, if they had done so already. NO. Most people do not have the choice and ISPs usually take the default. If the default is not approriate they do not use it. If you read the whole thread you find enough reasons how apps benefit from mbstring and what could be easily achieved with languages like german. 2) mbstring extension is a fairly complex piece of code and iirc is the youngest extension of this magnitude that is enabled by default. Although the extension developers are very prompt at fixing bugs, the fact they need to do this fairly frequently, at least to me, implies that the extension is not yet mature enough to be enabled by default. Also, judging by the number of changes in the CVS to the extension, a lot of new functionality was added to the extension recently and has not been tested outside the pre process. Maybe by next PHP release is made, it will be better tested and more stable. Ilia Ok there are some problems and that is the backside of it: Some of us implement new functionality and some merge code from the original development tree. In other words: Maybe we should slow down or even stop feature development until 4.3 is out After php 4.3 we hope the new implementation can be used. As long as function overloading isn't used there is no harm from mbstring (disable is the default). And some extra bytes shouldn't affect anybody today. If you say most apps are not designed to use mbstring then it's nice that all those could try mbstring which would like to. So we can get feedback. As long as it isn't default there will be none or only little feedback. The stability is very high and we have many *.phpt tests to help us find failures and make it even more stable. marcus -- - For Sale! - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Oh, I forgot: How many bug reports have we got so far for that fuckup with 4.2.3 ??? I _REALLY_ don't want to see another wave of those for 4.3.0.. --Jani On Wed, 13 Nov 2002, Marcus Börger wrote: At 23:56 12.11.2002, Ilia A. wrote: Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most PHP programs are developed with non-multibyte languages in mind and mbstring only adds unnecessary overhead. People who need it can easily enable it or ask their ISPs to enable it, if they had done so already. NO. Most people do not have the choice and ISPs usually take the default. If the default is not approriate they do not use it. If you read the whole thread you find enough reasons how apps benefit from mbstring and what could be easily achieved with languages like german. 2) mbstring extension is a fairly complex piece of code and iirc is the youngest extension of this magnitude that is enabled by default. Although the extension developers are very prompt at fixing bugs, the fact they need to do this fairly frequently, at least to me, implies that the extension is not yet mature enough to be enabled by default. Also, judging by the number of changes in the CVS to the extension, a lot of new functionality was added to the extension recently and has not been tested outside the pre process. Maybe by next PHP release is made, it will be better tested and more stable. Ilia Ok there are some problems and that is the backside of it: Some of us implement new functionality and some merge code from the original development tree. In other words: Maybe we should slow down or even stop feature development until 4.3 is out After php 4.3 we hope the new implementation can be used. As long as function overloading isn't used there is no harm from mbstring (disable is the default). And some extra bytes shouldn't affect anybody today. If you say most apps are not designed to use mbstring then it's nice that all those could try mbstring which would like to. So we can get feedback. As long as it isn't default there will be none or only little feedback. The stability is very high and we have many *.phpt tests to help us find failures and make it even more stable. marcus -- - For Sale! - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
At 04:11 13.11.2002, Jani Taskinen wrote: Since when have we started to use users as guinea-pigs for testing EXPERIMENTAL extensions without them even really knowing about it?!! mbstring is not EXPERIMENTAL and i said let them try it. That does not mean test it. We think it works . You can't FORCE anybody to use it. 99% of apps out there DO NO NEED IT..get it?? (they've managed without it very long time..) --Jani Yes they lived without correct display of characters because there was no solution. For example i would like to send german umlauts even when someone has another charset installation on his machine. With mbstring this is easy. On Wed, 13 Nov 2002, Marcus Börger wrote: At 23:56 12.11.2002, Ilia A. wrote: Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most PHP programs are developed with non-multibyte languages in mind and mbstring only adds unnecessary overhead. People who need it can easily enable it or ask their ISPs to enable it, if they had done so already. NO. Most people do not have the choice and ISPs usually take the default. If the default is not approriate they do not use it. If you read the whole thread you find enough reasons how apps benefit from mbstring and what could be easily achieved with languages like german. 2) mbstring extension is a fairly complex piece of code and iirc is the youngest extension of this magnitude that is enabled by default. Although the extension developers are very prompt at fixing bugs, the fact they need to do this fairly frequently, at least to me, implies that the extension is not yet mature enough to be enabled by default. Also, judging by the number of changes in the CVS to the extension, a lot of new functionality was added to the extension recently and has not been tested outside the pre process. Maybe by next PHP release is made, it will be better tested and more stable. Ilia Ok there are some problems and that is the backside of it: Some of us implement new functionality and some merge code from the original development tree. In other words: Maybe we should slow down or even stop feature development until 4.3 is out After php 4.3 we hope the new implementation can be used. As long as function overloading isn't used there is no harm from mbstring (disable is the default). And some extra bytes shouldn't affect anybody today. If you say most apps are not designed to use mbstring then it's nice that all those could try mbstring which would like to. So we can get feedback. As long as it isn't default there will be none or only little feedback. The stability is very high and we have many *.phpt tests to help us find failures and make it even more stable. marcus -- - For Sale! - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On November 12, 2002 09:42 pm, Marcus Börger wrote: At 23:56 12.11.2002, Ilia A. wrote: Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most PHP programs are developed with non-multibyte languages in mind and mbstring only adds unnecessary overhead. People who need it can easily enable it or ask their ISPs to enable it, if they had done so already. NO. Most people do not have the choice and ISPs usually take the default. If the default is not approriate they do not use it. Through the course of my work I have to deal with many ISPs from all over the world, of all sizes. In my experience over 60% of ISPs have non-default PHP configuration. And most of the remaining 40% are more then willing to add additional extension(s), especially if those extensions do not require external libraries. Keep in mind most ISPs will not upgrade to 4.3.0 and will most likely wait for a few releases past 4.3.0 to upgrade. If you read the whole thread you find enough reasons how apps benefit from mbstring and what could be easily achieved with languages like german. Any extension is useful if it was not the author(s) would not have spent time and effort writing it. The fact it is useful, does not automatically imply we should enable it by default. The question on the agenda wether ever single user who upgrades needs to have mbstring enabled by default. My belief that unless majority of PHP users will benefit from this extension we should not enable it by default. All the arguments in favor had not convinced me that this would be the case. 2) mbstring extension is a fairly complex piece of code and iirc is the youngest extension of this magnitude that is enabled by default. Although the extension developers are very prompt at fixing bugs, the fact they need to do this fairly frequently, at least to me, implies that the extension is not yet mature enough to be enabled by default. Also, judging by the number of changes in the CVS to the extension, a lot of new functionality was added to the extension recently and has not been tested outside the pre process. Maybe by next PHP release is made, it will be better tested and more stable. Ilia Ok there are some problems and that is the backside of it: Some of us implement new functionality and some merge code from the original development tree. In other words: Maybe we should slow down or even stop feature development until 4.3 is out After php 4.3 we hope the new implementation can be used. As long as function overloading isn't used there is no harm from mbstring (disable is the default). And some extra bytes shouldn't affect anybody today. If you say most apps are not designed to use mbstring then it's nice that all those could try mbstring which would like to. So we can get feedback. As long as it isn't default there will be none or only little feedback. The stability is very high and we have many *.phpt tests to help us find failures and make it even more stable. mbstring has many dedicated developers whom are doing excellent maintaining and upgrading this extension. Which at the moment makes mbstring very much a work in progress, there is hardly a day without at least one or two CVS commits to it. Since this is a work in progress, it is simply not safe to enable it by default if we want to claim any sort of stability for 4.3.0 release. There is a chance it'll work out, but IMHO there is even a greater chance it will cause problems like it did in 4.2.3 with mangling of POST requests, 4.3.0 will have more then enough new stuff as is. Perhaps by the next major release, mbstring will be a lot more mature and thoroughly tested in production enviroment. At that point we can discuss this issue again and consider whether this extension has merit for most users and based on that decide whether or not to enable it by default. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Jani Taskinen wrote: Oh, I forgot: How many bug reports have we got so far for that fuckup with 4.2.3 ??? I _REALLY_ don't want to see another wave of those for 4.3.0.. Do you mean array input handling bug? It's not mbstring developers' fault. -- Yasuo Ohgaki On Wed, 13 Nov 2002, Marcus Börger wrote: At 23:56 12.11.2002, Ilia A. wrote: Since I've gotten involved in this conversation would like to add my opinion to the tally. I too believe that at least at this point, the mbstring extension should not be enabled by default. There are two reasons for this decision: 1) Majority of PHP users do not require this functionality. Most PHP programs are developed with non-multibyte languages in mind and mbstring only adds unnecessary overhead. People who need it can easily enable it or ask their ISPs to enable it, if they had done so already. NO. Most people do not have the choice and ISPs usually take the default. If the default is not approriate they do not use it. If you read the whole thread you find enough reasons how apps benefit from mbstring and what could be easily achieved with languages like german. 2) mbstring extension is a fairly complex piece of code and iirc is the youngest extension of this magnitude that is enabled by default. Although the extension developers are very prompt at fixing bugs, the fact they need to do this fairly frequently, at least to me, implies that the extension is not yet mature enough to be enabled by default. Also, judging by the number of changes in the CVS to the extension, a lot of new functionality was added to the extension recently and has not been tested outside the pre process. Maybe by next PHP release is made, it will be better tested and more stable. Ilia Ok there are some problems and that is the backside of it: Some of us implement new functionality and some merge code from the original development tree. In other words: Maybe we should slow down or even stop feature development until 4.3 is out After php 4.3 we hope the new implementation can be used. As long as function overloading isn't used there is no harm from mbstring (disable is the default). And some extra bytes shouldn't affect anybody today. If you say most apps are not designed to use mbstring then it's nice that all those could try mbstring which would like to. So we can get feedback. As long as it isn't default there will be none or only little feedback. The stability is very high and we have many *.phpt tests to help us find failures and make it even more stable. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On Tue, 12 Nov 2002, Ilia A. wrote: mbstring has many dedicated developers whom are doing excellent maintaining and upgrading this extension. Which at the moment makes mbstring very much a work in progress, there is hardly a day without at least one or two CVS commits to it. Since this is a work in progress, it is simply not safe to enable it by default if we want to claim any sort of stability for 4.3.0 release. There is a chance it'll work out, but IMHO there is even a greater chance it will cause problems like it did in 4.2.3 with mangling of POST requests, 4.3.0 will have more then enough new stuff as is. Perhaps by the next major release, mbstring will be a lot more mature and thoroughly tested in production enviroment. At that point we can discuss this issue again and consider whether this extension has merit for most users and based on that decide whether or not to enable it by default. I very much agree and am extremly reluctant to have mbstring enabled by default, even though it is a very promising extension. -Andrei http://www.gravitonic.com/ When I get a little money, I buy books; and if any is left I buy food and clothes. -- Erasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Andrei Zmievski wrote: I very much agree and am extremly reluctant to have mbstring enabled by default, even though it is a very promising extension. I can change my mind only if someone writes smart module loader that detects module dependency. Otherwise, it's just confusing. i.e. undefined symbol errors from modules depend on mbstring. PHP dies badly with it obviously. Disabling it is the same as asking for troubles. I'm 0 iff there is smart loader patch. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Hmm, there might be no much need to fix this bug as it is not enabled by default... If the script still sefaults with my patch, I can no longer determine theplace at which it goes wrong just with your backtrace precisely, as it is apparently a double-free bug. Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: I've just tried the latest CVS, it still crashes, the backtrace is same as before. Ilia On November 12, 2002 05:21 pm, Moriyoshi Koizumi wrote: Oops, why didn't I notice such a trivial thing before asking a braindead question... Anyway I bet the problem should be gone by my patch that was just commited. Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote: Hi, Thanks for the report. Although I found a bug in the overloading code, I wonder why the mail() function entry was not found on RINIT. Any insights? It seems the mail() function is not avaliable on that system because sendmail was not found on the system. The function mail() on unix systems appears to be dependant on sendmail avaliablity or atleast something that would cause the HAVE_SENDMAIL flag to be set. Ilia Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On November 13, 2002 12:28 am, Moriyoshi Koizumi wrote: Hmm, there might be no much need to fix this bug as it is not enabled by default... If the script still sefaults with my patch, I can no longer determine theplace at which it goes wrong just with your backtrace precisely, as it is apparently a double-free bug. I'll look into the problem in more detail tommorow. Ilia Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: I've just tried the latest CVS, it still crashes, the backtrace is same as before. Ilia On November 12, 2002 05:21 pm, Moriyoshi Koizumi wrote: Oops, why didn't I notice such a trivial thing before asking a braindead question... Anyway I bet the problem should be gone by my patch that was just commited. Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote: Hi, Thanks for the report. Although I found a bug in the overloading code, I wonder why the mail() function entry was not found on RINIT. Any insights? It seems the mail() function is not avaliable on that system because sendmail was not found on the system. The function mail() on unix systems appears to be dependant on sendmail avaliablity or atleast something that would cause the HAVE_SENDMAIL flag to be set. Ilia Moriyoshi Ilia A. [EMAIL PROTECTED] wrote: On November 7, 2002 10:04 am, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? On the note of overloading done by mbstring, it appears this behavior is not entirely stable. On at least one test system (Sun OS 5.9) it causes crashes and overruns by using the test script in the test suite. Ex: sapi/cli/php -d mbstring.func_overload=1 -r '' Unknown(0) : Fatal error - (null)() [http://www.php.net/ref.mbstring]: mbstring couldn't find function mail. Could not startup. [Tue Nov 12 21:01:33 2002] Script: '-' --- php4/Zend/zend_execute.h(44) : Block 0x001FB640 status: Beginning: Overrun (magic=0x001FE7F8, expected=0x7312F8DC) End: Unknown --- The test script itself (ext/mbstring/tests/overload.phpt) causes a segmentation fault. Here is a back trace: #0 0x001528f8 in shutdown_memory_manager (silent=1, clean_cache=1) at php4/Zend/zend_alloc.c:461 #1 0x0011d944 in php_module_shutdown () at php4/main/main.c:1219 #2 0x0018d8d0 in main (argc=39, argv=0xffbffa74) at php4/sapi/cli/php_cli.c:761 Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On Wed, 13 Nov 2002, Marcus Börger wrote: At 04:11 13.11.2002, Jani Taskinen wrote: Since when have we started to use users as guinea-pigs for testing EXPERIMENTAL extensions without them even really knowing about it?!! mbstring is not EXPERIMENTAL and i said let them try it. That does not mean test it. We think it works . uhm, I don't think it works stable enough. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On Wed, 13 Nov 2002, Yasuo Ohgaki wrote: Jani Taskinen wrote: Oh, I forgot: How many bug reports have we got so far for that fuckup with 4.2.3 ??? I _REALLY_ don't want to see another wave of those for 4.3.0.. Do you mean array input handling bug? It's not mbstring developers' fault. It doesn't really matter who's fault it was, it's a fact that the mbstring module caused this fuckup. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
--snip uhm, I don't think it works stable enough. I think the decision making went right, and I've got no more objection to that point. but I wonder how this could be certified as a stable module that is not widely used by the core developers? Moriyoshi Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On Wed, 13 Nov 2002, Moriyoshi Koizumi wrote: --snip uhm, I don't think it works stable enough. I think the decision making went right, and I've got no more objection to that point. but I wonder how this could be certified as a stable module that is not widely used by the core developers? For me it was the wide stream of bugreports coming in; can't speak for the others though. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring and 4.3.0
Historically, I have been against mbstring being enabled by default. My feelings towards anything being enabled by default, unless it is considered core functionality, is pretty negative though. The reasoning to consider a extension as a part of core, is prone to be obscure. It's interesting what would happen if mysql extension turned out to be harmful. but the mysql extension isn't invasive of other parts of the language, and can be safely disabled. I do not believe mbstring can be safely disabled, and i do not think that you have the transparent stuff disabled by default. the theory of mbstring is good; i am just concerned that a: it really hasn't been explained and discussed much on list, and b: there are two development trees, which just doesn't make sense. it's like some kind of underground secret society or something... -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
--snip but the mysql extension isn't invasive of other parts of the language, and can be safely disabled. I do not believe mbstring can be safely disabled, and i do not think that you have the transparent stuff disabled by default. Right, I'm sure those two cases are different. I just wanted to illustrate that there are quite a few aspects to think of before excluding / including an extension in a default build. There are definitely considerable number of people out there who will easily be bothered by that change. If you doubt it is safely disabled, please look through the relevant part of mbstring, and if you still have questions, please ask me then. the theory of mbstring is good; i am just concerned that a: it really hasn't been explained and discussed much on list, and b: there are two development trees, which just doesn't make sense. it's like some kind of underground secret society or something... I agree with you on these points. You may well consider me as a member of underground kong-foo coder syndicate, though I'm Japanese and not good at any marshal art stuff :) Moriyoshi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
I see the known-good codeset conversion implementation as a *very* good reason to have mbstring enabled by default. (Just look at all the problems with iconv and recode on different systems out there). I agree that the magic features for lazy programmers (function overloading and transparent encoding) are slightly worrying, but they are disabled by default, and as I have said - I don't use those, but I do use the conversion functions and *that* configuration works just fine. The conversion functions are something that really should be there by default, as it allows people to write portable globalized scripts. Remember that a large majority of users are vhosted and have not control over the build of PHP. By not providing a reliable and portable codeset conversion API, we are holding back the masses from writing (and distributing) killer apps in PHP. Yes, I can enable mbstring at configure time, and yes, the CJK people can do likewise, but what about the rest of the world running from vhosts when they want to use unicode, quoted-printable, uu-encoding, name of your favourite encoding here encodings which are also supported by mbstring? We took the decision to enable it by default; let's not be short-sighted and disable it primarily out of ignorance (no offence intended). I've yet to see someone comment on my suggestions for a practical solution that would shut up both myself and the people advocating disabling it. --Wez. On 11/07/02, Derick Rethans [EMAIL PROTECTED] wrote: On Thu, 7 Nov 2002, Marcus Boerger wrote: To make php be easier usable in non US-ASCII (127chars) environments especially those requiring UCS-2, UTF-8 or other any character mapping other than iso-8859-1 or -15 we should more likly try to integrate mbstring fully in php. As long as we cannot or want not make it a core component such as ext/standard we should enable it by default. If people want it they can use --enable-mbstring. I see no reason why it should be enabled by default as long as it's not fully integrated in the core. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
I think Wez got a point here. Disabling mbstring can make many unhappy. -- Maxim Maletsky [EMAIL PROTECTED] Wez Furlong [EMAIL PROTECTED] wrote... : I see the known-good codeset conversion implementation as a *very* good reason to have mbstring enabled by default. (Just look at all the problems with iconv and recode on different systems out there). I agree that the magic features for lazy programmers (function overloading and transparent encoding) are slightly worrying, but they are disabled by default, and as I have said - I don't use those, but I do use the conversion functions and *that* configuration works just fine. The conversion functions are something that really should be there by default, as it allows people to write portable globalized scripts. Remember that a large majority of users are vhosted and have not control over the build of PHP. By not providing a reliable and portable codeset conversion API, we are holding back the masses from writing (and distributing) killer apps in PHP. Yes, I can enable mbstring at configure time, and yes, the CJK people can do likewise, but what about the rest of the world running from vhosts when they want to use unicode, quoted-printable, uu-encoding, name of your favourite encoding here encodings which are also supported by mbstring? We took the decision to enable it by default; let's not be short-sighted and disable it primarily out of ignorance (no offence intended). I've yet to see someone comment on my suggestions for a practical solution that would shut up both myself and the people advocating disabling it. --Wez. On 11/07/02, Derick Rethans [EMAIL PROTECTED] wrote: On Thu, 7 Nov 2002, Marcus Boerger wrote: To make php be easier usable in non US-ASCII (127chars) environments especially those requiring UCS-2, UTF-8 or other any character mapping other than iso-8859-1 or -15 we should more likly try to integrate mbstring fully in php. As long as we cannot or want not make it a core component such as ext/standard we should enable it by default. If people want it they can use --enable-mbstring. I see no reason why it should be enabled by default as long as it's not fully integrated in the core. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
I completely agree with Wez. mbstring has very foundamental functionalities for multibyte users. Multibyte users can 'not' build any useful application without mbstring. We must understand there are so many users who are using multibyte character encoding. multibyte string functions for multibyte users has nealy same meaning with string functions for singlebyte users. If PHP lacks string functions, who can use PHP ? I think mbstring enabled by default in PHP 4.3 is very good decision. 'function overloading' in mbstring is to make easier multibyte-aware application, but, it is disabled by default. I also agree with Wez, the official zend API for function overloading is needed. I will change the implemantaion if some official API is available. Rui On Fri, 8 Nov 2002 10:13:29 + [EMAIL PROTECTED] (Wez Furlong) wrote: I see the known-good codeset conversion implementation as a *very* good reason to have mbstring enabled by default. (Just look at all the problems with iconv and recode on different systems out there). I agree that the magic features for lazy programmers (function overloading and transparent encoding) are slightly worrying, but they are disabled by default, and as I have said - I don't use those, but I do use the conversion functions and *that* configuration works just fine. The conversion functions are something that really should be there by default, as it allows people to write portable globalized scripts. Remember that a large majority of users are vhosted and have not control over the build of PHP. By not providing a reliable and portable codeset conversion API, we are holding back the masses from writing (and distributing) killer apps in PHP. Yes, I can enable mbstring at configure time, and yes, the CJK people can do likewise, but what about the rest of the world running from vhosts when they want to use unicode, quoted-printable, uu-encoding, name of your favourite encoding here encodings which are also supported by mbstring? We took the decision to enable it by default; let's not be short-sighted and disable it primarily out of ignorance (no offence intended). I've yet to see someone comment on my suggestions for a practical solution that would shut up both myself and the people advocating disabling it. --Wez. -- - Rui Hirokawa [EMAIL PROTECTED] [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
To make php be easier usable in non US-ASCII (127chars) environments especially those requiring UCS-2, UTF-8 or other any character mapping other than iso-8859-1 or -15 we should more likly try to integrate mbstring fully in php. As long as we cannot or want not make it a core component such as ext/standard we should enable it by default. And it do not see why it is dangerous or why it should harm any test? All hose mbstring settings affecting the tests are no set in such a way that activating mbstring cannot harm AND mbstring is deply tested for its own. When currently any test is affected by mbstring this should be reported so we can adjust test settings! marcus At 16:04 07.11.2002, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? Comments are welcome. -Andrei http://www.gravitonic.com/ * We are not a clone. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On Thu, 7 Nov 2002, Marcus Boerger wrote: To make php be easier usable in non US-ASCII (127chars) environments especially those requiring UCS-2, UTF-8 or other any character mapping other than iso-8859-1 or -15 we should more likly try to integrate mbstring fully in php. As long as we cannot or want not make it a core component such as ext/standard we should enable it by default. If people want it they can use --enable-mbstring. I see no reason why it should be enabled by default as long as it's not fully integrated in the core. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring and 4.3.0
On Thu, 7 Nov 2002, Marcus Boerger wrote: To make php be easier usable in non US-ASCII (127chars) environments especially those requiring UCS-2, UTF-8 or other any character mapping other than iso-8859-1 or -15 we should more likly try to integrate mbstring fully in php. As long as we cannot or want not make it a core component such as ext/standard we should enable it by default. If people want it they can use --enable-mbstring. I see no reason why it should be enabled by default as long as it's not fully integrated in the core. +1. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
I agree with you that the codeset conversion functions should be there by default (iconv and recode seem to have patchy/variable support on different platforms; mbstring is reliable since we know exactly what is supported in there). I've been using the conversion functions of mbstring in production for around 2 years now - I've never had a problem with them, so they are more than stable IMO. I think disabling mbstring by default would be a not-very-productive step backwards, but I'm happy to compromize: The issue is with the function table hacking, so why not either: o #ifdef it out and use a configure option to enable the potentially dangerous functionality. o Provide a zend-api for overloading function entries. This was something that came up a while ago on php-dev when the namespace purists were trying to ditch the _() function in the gettext extension. it might look something like this: int _zend_overload_function(char *func_name, void (*handler)(INTERNAL_FUNCTION_PARAMETERS), long apino TSRMLS_DC); #define zend_overload_function(func_name, handler) \ _zend_overload_function((func_name), (handler), \ ZEND_EXTENSION_API_NO TSRMLS_CC) In this way, _zend_overload_function can check to see which extension API is being used and then bail if it doesn't match (although this could be caught more generally by the module version info). More importantly, we can hide the gory details of the function table hash and implement the overload in a safe way. --Wez. On Thu, 7 Nov 2002, Marcus Boerger wrote: To make php be easier usable in non US-ASCII (127chars) environments especially those requiring UCS-2, UTF-8 or other any character mapping other than iso-8859-1 or -15 we should more likly try to integrate mbstring fully in php. As long as we cannot or want not make it a core component such as ext/standard we should enable it by default. And it do not see why it is dangerous or why it should harm any test? All hose mbstring settings affecting the tests are no set in such a way that activating mbstring cannot harm AND mbstring is deply tested for its own. When currently any test is affected by mbstring this should be reported so we can adjust test settings! marcus At 16:04 07.11.2002, Andrei Zmievski wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? Comments are welcome. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
On Thu, 7 Nov 2002, Derick Rethans wrote: On Thu, 7 Nov 2002, Marcus Boerger wrote: To make php be easier usable in non US-ASCII (127chars) environments especially those requiring UCS-2, UTF-8 or other any character mapping other than iso-8859-1 or -15 we should more likly try to integrate mbstring fully in php. As long as we cannot or want not make it a core component such as ext/standard we should enable it by default. If people want it they can use --enable-mbstring. I see no reason why it should be enabled by default as long as it's not fully integrated in the core. Zeev could give some figures about how many PHP users there are in those countries that really need this? :) Anyway, I'm +1 for making it disabled by default. The people who really need it already need to use --enable-mbstring since that's how it was in 4.2.3 anyway. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
Hi, Now the transparent encoding conversion is disabled by default, and so is the function overloading. And the extension is not likely to cause any harm to other tests; recently some test failures related to output handlers were reported in fact, but the problem have been properly avoided. Then why do we even have to continue the same discussion? Is it the big deal how many people use mbstring? Now mbstring is not just for CJK people, because it also offers numerous unicode functionality. mb_convert_case(), contributed by Wez, is one of the examples. Besides I wonder why such dangerousness has not been warned up to now if that's the case. Moriyoshi Andrei Zmievski [EMAIL PROTECTED] wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? Comments are welcome. -Andrei http://www.gravitonic.com/ * We are not a clone. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring and 4.3.0
It's interesting to me that this topic is brought up again and again about once every 3 or 4 months. The same points are rehashed each time, and the same result is reached, nothing is changed about mbstring. I believe this is partially because developers ask questions about mbstring, and receive no definitive answer to them (see the archives for a few examples). Historically, I have been against mbstring being enabled by default. My feelings towards anything being enabled by default, unless it is considered core functionality, is pretty negative though. On the flip side though, what exactly were these concerns brought up at the PHP Conference? Is it possible to share them with those of us who were not able to attend? Please include as much detail as possible. On Friday, November 8, 2002, at 01:06 AM, Moriyoshi Koizumi wrote: Hi, Now the transparent encoding conversion is disabled by default, and so is the function overloading. And the extension is not likely to cause any harm to other tests; recently some test failures related to output handlers were reported in fact, but the problem have been properly avoided. Then why do we even have to continue the same discussion? Is it the big deal how many people use mbstring? Now mbstring is not just for CJK people, because it also offers numerous unicode functionality. mb_convert_case(), contributed by Wez, is one of the examples. Besides I wonder why such dangerousness has not been warned up to now if that's the case. Moriyoshi Andrei Zmievski [EMAIL PROTECTED] wrote: At the PHP Conference in Germany several of us have discussed the current state of mbstring and there was a proposal to not have it enabled by default for 4.3.0 release. It seems that the extension attempts to do magic stuff by overloading functions in the executor globals and, as Thies said, that could be dangerous. Also, doesn't it affect run-tests.php script currently? Comments are welcome. -Andrei http://www.gravitonic.com/ * We are not a clone. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php --- Dan KalowskyThe future is always uncertain, http://www.deadmime.org/~dankand the end is always near. [EMAIL PROTECTED]- Roadhouse Blues, [EMAIL PROTECTED] The Doors -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring functions in 4.2.3
Hi, AFAIK, php_stat() and tsrm_virtual_cwd() related problems under multibyte win32 environment were already fixed by Rui. But the bugs are still active under some unix operating systems that accept Shift_JIS as its locale charset/encoding if you specify it, as EUC-JP is most suitable to use with php (and lots of packages out there) in general. Anyway these are not directly relevant to --mbstr-enc-trans. Excuse me if this is wrong, I'm rather new to mbstring :) Moriyoshi Koizumi Wez Furlong [EMAIL PROTECTED] wrote: Hi Erica, Personally, I would roll my own tarball/package based on the now fixed code in the 4.2 branch of CVS. However, as I mentioned in your original PR, there is a bug that affects file_exists on some systems; AFAIK, this has yet to be resolved which I why I suggested that you ask here, and why I am mentioning it now for those on php-dev who are slightly too busy to check the details in the PR :-) --Wez. On 09/20/02, Erica Douglass [EMAIL PROTECTED] wrote: I'm making a PHP package that will be distributed to potentially hundreds of people. I based the package off 4.2.3, since that's the latest version from PHP.Net. However, I have encountered a nasty bug with the mbstring-enc-trans extension as described here: http://bugs.php.net/bug.php?id=19518 I have a Japanese client who will be using this server, and I feel that this is an important extension to have, since both of my vendors' packages ship with it, as well. My question is: in what PHP version is this extension stable, or should I just abandon all hope for using this extension and document it as buggy? Also, are there any other extensions in my package that could cause conflicts? Any extensions that you feel are important to have that I'm missing? I want to get this right the first time. :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring functions in 4.2.3
Hi Erica, Personally, I would roll my own tarball/package based on the now fixed code in the 4.2 branch of CVS. However, as I mentioned in your original PR, there is a bug that affects file_exists on some systems; AFAIK, this has yet to be resolved which I why I suggested that you ask here, and why I am mentioning it now for those on php-dev who are slightly too busy to check the details in the PR :-) --Wez. On 09/20/02, Erica Douglass [EMAIL PROTECTED] wrote: I'm making a PHP package that will be distributed to potentially hundreds of people. I based the package off 4.2.3, since that's the latest version from PHP.Net. However, I have encountered a nasty bug with the mbstring-enc-trans extension as described here: http://bugs.php.net/bug.php?id=19518 I have a Japanese client who will be using this server, and I feel that this is an important extension to have, since both of my vendors' packages ship with it, as well. My question is: in what PHP version is this extension stable, or should I just abandon all hope for using this extension and document it as buggy? Also, are there any other extensions in my package that could cause conflicts? Any extensions that you feel are important to have that I'm missing? I want to get this right the first time. :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
Jim Winstead wrote: Yasuo Ohgaki [EMAIL PROTECTED] wrote: Marcus B?rger wrote: We already had some discussion on some IF statements in ini files already. I guess we might call to another mail thread here and hope we find a volunteer. I will not invent any work here since that would be totally useless. I think having a IF in php.ini is good idea. it's too bad we don't have an implementation of a complete programming language laying around. Having IF like feature does not mean to have a new language. It could be a XML parser, for example. There could be multiple php.ini for each SAPI and user named php.ini from PHP 4.3.0. Therefore, it's not strictly required obviously. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
Wez Furlong wrote: Having been using it to handle more than 105,000 email messages over the last 18 months *in production*, I have to disagree. *SNIP* Now, the mbstr-enc-trans might have had some stability issues, but as I've been saying, it is NOT enabled by default, and lets print a warning about it when it is turned on. mbstr-enc-trans is introduced when Rui merged mbstring(jstring) to php4 source tree. It was added since php3-i18n had this capability built in. Rui removed mbstr-enc-trans option so that it's ready to be a default module. We can control encoding translation by mbstring.encoding_translation = On|Off now. (the name may be better to be renamed to input_encoding_translation or input_translation. Opinions?) AFAIK, there is no serious bug in mbstring. If there is serious problem, let us know so that it can be addressed. Speaking of API, current API will not be changed. The API is there since php3 days. This is another reason why mbstring is considered stable. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
AFAIK, there is no serious bug in mbstring. If there is serious problem, let us know so that it can be addressed. Then start with removing double url decoding of the input... and then fix the mad separator counter ... Stefan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
Derick pretty much said it for me... but more explicitly, mbstring isn't stable enough to be default. -- james -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 6:41 AM To: Masaki Fujimoto Cc: James Cox; Wez Furlong; Php-Dev Subject: Re: [PHP-DEV] mbstring On Mon, 2 Sep 2002, Masaki Fujimoto wrote: Hi, let me vote not to remove mbstring (as a default one). I'd vote for setting it off by default _for now_, and enable it after 4.3. has branched, so we have a kick ass i18n solution in PHP5 replacing all code it duplicates. yes, I can understand the thought that singlebyte users seem mbstirng module is somehow 'extra' one. but please understand that this module is indispensable for multibyte users (at least), and AFAIK there are growing numbers of multibyte users of PHP. we japanese, korean and chinese have to handle 3 (or more) types of encoding (+ UNICODE), and we cannot even count number characters (not bytes) w/out mbstring. besides, I (we?) always make best effort that multibyte features do not harm any other ones, and if it causes bugs, we (Yasuo, Rui or I) will fix it ASAP (maybe:). Too bad that you can't predict anything. of course we can --enable-mbstring even if msbstirg is disabled by default, but please remember that not all the users can always exec 'configure' and edit php.ini. (use dl() ? hmm...) Every respectable sysadm in eastern countries installing PHP should be aware fo this and enable mbstring for his users. finally, it is true that mbstring is not the 'golden bullet':), but it would be far better if we have some kind of bullets, isn't it ? Derick -- - Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ -- - PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net -- - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, Marcus Börger wrote: AND exif is disliked by the developers on this list so why do we care now? Markus, that makes no sense. Just because some ppl don't want it exif enabled by default doesn't make us 'dislike' exif, it doesn't make us (atleast not me) like you less. Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
On 09/01/02, James Cox [EMAIL PROTECTED] wrote: mbstring isn't a gold module which should be enabled by default. But there was a discussion and it was agreed to enable it by default! That is, it's still -- as i see it -- just a bit more than experimental. mbstring work is being done on sourceforge! Actually, thats incorrect. mbstring in PHP CVS is based on work that has matured since PHP 3. A new, rewritten version is being developed outside of our CVS so as not to screw things up for the mainstream. So I want to 'disable' it by default. If you want encoding, just enable it. But you're right, i've never needed to create a truely globalized/localized app. (and from general principles, if you feel you need to localize any more than your ui/strings.) But the issue is not with mbstring encoding, it's with people who turn on an advanced feature without reading the docs. --enable-mbstring is on by default and works just fine. --enable-mbstr-enc-trans is the advanced option (that was causing problems for RedHat because people were enabling it without configuring it correctly for their system) - this option is DISABLED by default. Why can't we just keep it at that? Lets make a comparison: the session module has an little option called --enable-trans-sid. This option is similar to the mbstring option in question, in that it transparently converts stuff. Now, should we disable the session module by default because someone didn't read the docs and just enabled it and then complained that it was rewriting stuff?? Or how about another comparison: apache has a -DBIG_SECURITY_HOLE (or similar define) that allows it to run as root. Should they remove that option just because some idiot out there adds it to their compile options without understanding what it does? (And there *are* production systems that require this in order to function - Cobalt Raqs for example). Why can't we have the configure print a warning that the enc-trans may cause problems if it is not configured correctly for your system/application? Enabling mbstring by default was a milestone that meant that people could start writing some real-world applications because the PHP infrastructure for them was guaranteed to be there by default; don't just drop it out now because people don't read the docs. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
At 05:15 02/09/2002, Yasuo Ohgaki wrote: Marcus Börger wrote: At 01:24 02.09.2002, you wrote: Brian France wrote: I know there are things the exif needs from mbstring and there is no way to have exif link against mbstring or require it. But couldn't exif check to see if mbstring is loaded (or built in) and if not print a warning that some of its functionality may not work correctly unless mbstring is loaded (or built in)? It's not a good idea. What we need is smart ini parser and module loader that understand module dependecy and proper loading order. We already had some discussion on some IF statements in ini files already. I guess we might call to another mail thread here and hope we find a volunteer. I will not invent any work here since that would be totally useless. I think having a IF in php.ini is good idea. -1 on that. php.ini should not be scriptable, it opens a whole new set of problems. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
At 03:41 02/09/2002, Brian France wrote: I know this is ugly, but what about making the extensions handle it themselves? It's actually not ugly at all. Letting the modules handle it themselves is the Right Way, because only they know what they need. The only question is whether we need to give them some extra infrastructure to make the process easier. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
Having been using it to handle more than 105,000 email messages over the last 18 months *in production*, I have to disagree. I have to say that I'm appalled that most of the people making these I completely agree comments have probably never even tried to use mbstring; most certainly haven't even read the bugzilla report and therefore don't even realize what the problem is. rant to=php-dev If you're going vote on something, *PLEASE* make yourselves aware of the real issues. PHP needs some forward thinkers, and brainlessly agreeing to disable a module, based on the valid principle of PECL removing cruft, is not forward thinking. The noise has only helped to obscure the issue even more, because people are all jumping on the PECL is great bandwagon, when that is *not* the issue here. It's nice to see that people want to keep PHP clean, but *please* let's understand what we are voting for before we actually vote. /rant Now, the mbstr-enc-trans might have had some stability issues, but as I've been saying, it is NOT enabled by default, and lets print a warning about it when it is turned on. Don't penalize serious developers because of this (already resolved) issue. --Wez. On 09/02/02, James Cox [EMAIL PROTECTED] wrote: Derick pretty much said it for me... but more explicitly, mbstring isn't stable enough to be default. Derick wrote: Every respectable sysadm in eastern countries installing PHP should be aware fo this and enable mbstring for his users. No, PHP should include encoding support by default - this was already discussed and decided here on php-dev. (That's why it's enabled by default in 4.2). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
I do agree with Wez (not 'completely agree', though ;) FWIW, mbstring was/is indeed enabled by default under Windows, and I think that at this stage this is not a good idea. There was at least one serious crash in the code that was introduced by the changes, into both the mbstring version and the non mbstring version of the input handling routines, but I don't really attribute it to mbstring. happens. I do think that the large amount of duplicate code in there is not a good idea at all, and it should be refactored into a more generic solution - fixing the same bug twice, once under Windows (because it was in the mbstring code) and once under UNIX (becasue it was also in the non-mbstring code) was not fun at all. I also think that the large amount of mbstring-related MFH's were not a good idea either. Good i18n support is a strategic goal for PHP, and mbstring should be a big step in that direction. But I think that the people here who said that it's something for v5.0 and not v4.x made a good point. Zeev At 11:52 02/09/2002, Wez Furlong wrote: Having been using it to handle more than 105,000 email messages over the last 18 months *in production*, I have to disagree. I have to say that I'm appalled that most of the people making these I completely agree comments have probably never even tried to use mbstring; most certainly haven't even read the bugzilla report and therefore don't even realize what the problem is. rant to=php-dev If you're going vote on something, *PLEASE* make yourselves aware of the real issues. PHP needs some forward thinkers, and brainlessly agreeing to disable a module, based on the valid principle of PECL removing cruft, is not forward thinking. The noise has only helped to obscure the issue even more, because people are all jumping on the PECL is great bandwagon, when that is *not* the issue here. It's nice to see that people want to keep PHP clean, but *please* let's understand what we are voting for before we actually vote. /rant Now, the mbstr-enc-trans might have had some stability issues, but as I've been saying, it is NOT enabled by default, and lets print a warning about it when it is turned on. Don't penalize serious developers because of this (already resolved) issue. --Wez. On 09/02/02, James Cox [EMAIL PROTECTED] wrote: Derick pretty much said it for me... but more explicitly, mbstring isn't stable enough to be default. Derick wrote: Every respectable sysadm in eastern countries installing PHP should be aware fo this and enable mbstring for his users. No, PHP should include encoding support by default - this was already discussed and decided here on php-dev. (That's why it's enabled by default in 4.2). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
Wez, lets loose the crap here. I am happy to see mbstring in PHP! I have used it too, when I needed multibyte support. But you see, it's not really all that solid. It needs more work (hence this apparent development outside of php.net). All I am saying is that we should disable it by default in current releases. For PHP5, we should have proper mbstring support that should probably also be transparent; by that I mean I see no reason for it not to be as standard functionality rather than an extension, if that is necessary. I will let Phil know that he can update his errata to just removing the one compile option -- however, he demonstrates a valid point: unexpected behaviour sucks. This includes the building of modules that you don't need. if it were me, i'd rather just be able to build the bare-bones PHP binary without an extensions, and compile others in as i needed them. By enabling extensions by default, what you end up doing is increasing the size of the end product... now that, in most cases, doesn't make a difference, however for scenarios where you have very little space to play with... having extensions compiled in by default that you don't know about sucks. if we want to do some kind of auto-compile thing, then perhaps a script which detects-and-compiles every extension could get stuck in /php4 for those who were really lazy. As I see it, PHP was designed with speed and simplicity in mind. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. Compiling modules by default which are buggy just compounds the problem. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 13:19 02/09/2002, James Cox wrote: As I see it, PHP was designed with speed and simplicity in mind. It was indeed.. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. Not really. Speed-wise, adding modules has a negligible effect. As far as simplicity goes, we're talking about simplicity for the developer. Bundling features does make things simpler for the majority of the target audience. Compiling modules by default which are buggy just compounds the problem. I obviously agree with that. I do want to see mbstring become an integrated part of PHP, but not a moment sooner than when it is stable. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 13:19 02/09/2002, James Cox wrote: As I see it, PHP was designed with speed and simplicity in mind. It was indeed.. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. Not really. Speed-wise, adding modules has a negligible effect. As far as simplicity goes, we're talking about simplicity for the developer. Bundling features does make things simpler for the majority of the target audience. Compiling modules by default which are buggy just compounds the problem. I obviously agree with that. I do want to see mbstring become an integrated part of PHP, but not a moment sooner than when it is stable. exactly.. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
On 09/02/02, James Cox [EMAIL PROTECTED] wrote: But you see, it's not really all that solid. It needs more work (hence this apparent development outside of php.net). But it *is* VERY stable in the default configuration. All I am saying is that we should disable it by default in current releases. For PHP5, we should have proper mbstring support that should probably also be transparent; by that I mean I see no reason for it not to be as standard functionality rather than an extension, if that is necessary. The transparent encoding style options - including that of the sessions should *never* be enabled by default precisely because they are transparent and cause unexpected behaviour for people that haven't read the docs. I will let Phil know that he can update his errata to just removing the one compile option -- however, he demonstrates a valid point: unexpected behaviour sucks. This includes the building of modules that you don't need. Umm, but the behaviour was only unexpected because he enabled an option without reading the docs to find out what it does. (regardless of the fact that there was a slight bug: the very next bug report would be along the lines of PHP is changing encodings automatically). if it were me, i'd rather just be able to build the bare-bones PHP binary without an extensions, and compile others in as i needed them. By enabling extensions by default, what you end up doing is increasing the size of the end product... now that, in most cases, doesn't make a difference, however for scenarios where you have very little space to play with... having extensions compiled in by default that you don't know about sucks. But in that situation, you would be paying close attention to what you were building anyway. As I see it, PHP was designed with speed and simplicity in mind. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. No, you can always disable those extensions. The default extensions were *voted* in for a reason. Compiling modules by default which are buggy just compounds the problem. Yes, but the bug was only present in an advanced optional feature that would cause unexpected behaviour for non-mbstring aware people anyway. *and it has already been fixed a number of weeks ago* As I've said, mbstring is very stable in it's default configuration - the codebase has been around for years and tested to death by a very dedicated i18n team *in production*. The development you keep referring to is part of a streamable filter *add-on* that does not change the existing code that people rely on. Why don't you test the current CVS to see if it still has a problem, if it does, lets fix it. Please don't take a step backwards by disabling this extension by default just because you are afraid that people can abuse advanced options. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
But it *is* VERY stable in the default configuration. All I am saying is that we should disable it by default in current releases. For PHP5, we should have proper mbstring support that should probably also be transparent; by that I mean I see no reason for it not to be as standard functionality rather than an extension, if that is necessary. The transparent encoding style options - including that of the sessions should *never* be enabled by default precisely because they are transparent and cause unexpected behaviour for people that haven't read the docs. Exactly. Most unexpected behaviour cases were in regards to transparent encoding. I have discovered this myself after spending couple of hours trying to hunt down a bug. This is why, we have agreed back then that transparent encoding option should be turned off by default, which Yasuo did. We have also agreed to leave mbstring module itself on by default because there seemed to be no stability issues with it. Therefore I think that the things should be left as they are in the cvs, mbstring enabled by default and transparent encoding disabled by default. The windows version should have the same defaults as well. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
Wez, lets loose the crap here. I am happy to see mbstring in PHP! I have used it too, when I needed multibyte support. James, Let's stay consistent here. Your opinion changes more than Microsoft's .NET strategy... In your original message you stated that you wanted to remove mbstring. If you've changed your opinion fine, but don't chide Wez for responding to the opinion so forcefully expressed in your original message. Furthermore, you've said that you've never used mbstring extension and that mbstring is certainly not a gold extension in prior messages, what do you think Wez is going to respond too? But you see, it's not really all that solid. It needs more work (hence this apparent development outside of php.net). All I am saying is that we should disable it by default in current releases. For PHP5, we should have proper mbstring support that should probably also be transparent; by that I mean I see no reason for it not to be as standard functionality rather than an extension, if that is necessary. _Every_ extension needs more work, a redesign, etc. The mbstring extension minus perhaps some of the newer features is quite solid, much more so than many of the other standard php extension (for example, xml and domxml), its being redesigned and reworked -- that's true, but that is imho just a matter of evolution and improvement. I will let Phil know that he can update his errata to just removing the one compile option -- however, he demonstrates a valid point: unexpected behaviour sucks. This includes the building of modules that you don't need. Yes, unexpected behaviour does suck, but this is not unexpected... if you explicitly _enable_ a configuration option, and then it yields a certain documented behaviour, I would hardly call that unexpected... if it were me, i'd rather just be able to build the bare-bones PHP binary without an extensions, and compile others in as i needed them. By enabling extensions by default, what you end up doing is increasing the size of the end product... now that, in most cases, doesn't make a difference, however for scenarios where you have very little space to play with... having extensions compiled in by default that you don't know about sucks. if we want to do some kind of auto-compile thing, then perhaps a script which detects-and-compiles every extension could get stuck in /php4 for those who were really lazy. As I see it, PHP was designed with speed and simplicity in mind. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. Compiling modules by default which are buggy just compounds the problem. As Zeev stated this doesn't really hurt speed, actually what you're suggesting would provide a larger speed hit (although not signifigant) than the current situation. As far as compiling in buggy modules -- yes, of course, that's stating the obvious. However mbstring is certainly not that buggy, unless you enable a further option, and that's debatable. From reading Wez's message, I really don't see a reason to unbundle/unenable it -- as long as new development doesn't cause a new api (backwards compat), i wasn't aware before that it didn't cause any bc issues. I don't know how many people remember the bundling of XML with PHP4, but there were _quite_ a few kinks with that integration, causing segfaults and unexpected behaviour (especially when dealing with objects). When bundling a new extension, you should always expect a few kinks, with mbstring it seems that there are less than usual (we also had major problems with MySQL integration by the way...) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
As I see it, PHP was designed with speed and simplicity in mind. Having the burden of a large number of extra modules compiled in by default doesn't help, and deviates from this path. No, you can always disable those extensions. The default extensions were *voted* in for a reason. Still, I think it makes more sense to enable, not disable. What extensions are enabled by default anyhow? I am not aware of a list. Perhaps that's why i get odd errors when working with php, because there are extensions i didn't expect built in. Compiling modules by default which are buggy just compounds the problem. Yes, but the bug was only present in an advanced optional feature that would cause unexpected behaviour for non-mbstring aware people anyway. *and it has already been fixed a number of weeks ago* As I've said, mbstring is very stable in it's default configuration - the codebase has been around for years and tested to death by a very dedicated i18n team *in production*. The development you keep referring to is part of a streamable filter *add-on* that does not change the existing code that people rely on. maybe i'm jaded against mbstring here, but i experienced two unexpected crashes which i traced back to mbstring, but with no real cause that i could find, as well as watching the cvs commits -- and also wondering why on earth they feel they want to work on mbstring sf.jp. CVS is quite capable of maintaining code (hence branches). Why don't you test the current CVS to see if it still has a problem, if it does, lets fix it. I will do that. Please don't take a step backwards by disabling this extension by default just because you are afraid that people can abuse advanced options. I'm not taking a step backwards, just trying to remove the potential for confusion. If people think that register_globals is confusing, and causes issues, then we should also not build stuff by default. I *HATE* it when I don't know what's being built. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, James Cox wrote: JC Still, I think it makes more sense to enable, not disable. What extensions are enabled by default anyhow? I am not aware of a list. Perhaps that's why i get odd errors when working with php, because there are extensions i didn't expect built in. ./configure --help | egrep -- '--(without|disable)' exception to the rule being mysql. -- Melvyn. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, James Cox wrote: JC Still, I think it makes more sense to enable, not disable. What extensions are enabled by default anyhow? I am not aware of a list. Perhaps that's why i get odd errors when working with php, because there are extensions i didn't expect built in. ./configure --help | egrep -- '--(without|disable)' exception to the rule being mysql. Yes. It was a rhetorical question -- i wonder if this is worth another page in the manual? james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, James Cox wrote: JC On Mon, 2 Sep 2002, James Cox wrote: JC JC JC Still, I think it makes more sense to enable, not disable. JC What extensions are enabled by default anyhow? I am not aware of JC a list. Perhaps that's why i get odd errors when working with JC php, because there are extensions i didn't expect built in. JC JC ./configure --help | egrep -- '--(without|disable)' JC JC exception to the rule being mysql. JC JC Yes. It was a rhetorical question -- I believe you :-) JC i wonder if this is worth another page JC in the manual? Definetely. Remember register_globals? You just can't mention it often enough. Further more if people can count on this behaviour, they can more easily create buildscripts. But then mysql shouldn't be the exception and a new module, can never be enabled by default in a new release (don't recall this ever happening, but still). -- Melvyn. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. Is --disable-something is too hard to get used to? Yes it is. Why? Because PHP has so many options at this point, finding which modules are automatically enabled isn't terribly easy. More to the point, it's a PITA to find out during the build you forgot to explicitly disable a feature. In general it is easier to enable a feature than to disable a feature (witness Clippy). --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
At 22:52 02/09/2002, Dan Kalowsky wrote: On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. -1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 22:52 02/09/2002, Dan Kalowsky wrote: On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. -1 Nice to see you argue that one so eloquently... -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 23:21 02/09/2002, James Cox wrote: Nice to see you argue that one so eloquently... I have in the past, numerous times. I don't think I or anybody else should have to repeat themselves like broken records, you can look it up in the archives. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 02 September 2002 04:16 pm, Zeev Suraski wrote: At 22:52 02/09/2002, Dan Kalowsky wrote: On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. -1 - -1!! Are you crazy?! remove --with-mysql as default?! I must be seeing things.mysql is a major reason ppl use php and some(not all!!) dumb sysadmins don't enable anything but the defaults and forget about asking them to enable som'in for you - -- ~Paul Nicholson It said uses Windows 98 or better, so I loaded Linux! Registered Linux User #183202 using Register Linux System # 81891 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9c85KDyXNIUN3+UQRAj6MAJ9Dbu0T4pCN9h/d0vtgsbJp+dIV1gCbB+Z6 Xva9XSblcuCZzGDeLW8D2RQ= =FHIi -END PGP SIGNATURE- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
-Original Message- From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 9:53 PM To: Yasuo Ohgaki Cc: PHP Development Mailing list Subject: Re: [PHP-DEV] mbstring On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on removing any default modules that are not essential to PHP's running. -1 on changing this with PHP 4.x - with PHP 5.x people realize that something big has changed. The register_golabls thing should have also been changed in PHP 5 and not in 4.x, but anyway it's too late for that now ;) Ah. I'm against changing this. But IF it's changed change it with 5. Is --disable-something is too hard to get used to? Yes it is. Why? Because PHP has so many options at this point, finding which modules are automatically enabled isn't terribly easy. More to the point, it's a PITA to find out during the build you forgot to explicitly disable a feature. Well... What about an _optional_ curses based, linux-kernel-like make menuconfig? +--+ | - Extensions | | [x] mySQL| | [x] GD | | .| | .| | .| | [ ] HyperWave | | .| | .| | [x] zlib | || | - Options | | [ ] enable transparent session id | +--+ | Here some description of the option or the | | Extension for examle | || +--+ Regards, Sebastian Nohn -- +49 170 471 8105 - [EMAIL PROTECTED] - http://www.nohn.net/ PGP Key Available - Did I help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/3HYH6NR8ZI0WI/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
On Tue, Sep 03, 2002 at 06:06:29AM +0200, Sebastian Nohn wrote : Well... What about an _optional_ curses based, linux-kernel-like make menuconfig? +--+ | - Extensions | | [x] mySQL | | [x] GD | | . | | . | | . | | [ ] HyperWave | | . | | . | | [x] zlib | | | | - Options| | [ ] enable transparent session id | +--+ | Here some description of the option or the | | Extension for examle | | | +--+ That would be an uebercool thing. Nice overview, load and save different configurations, etc. Just don't forget the text boxes for the extra parameters (GD could need a path to the library). I just think this will remain in our dreams. -- GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc Finally, if someone actually flying a plane is relying on a freakin' webcam to land, we're all in trouble. - A /. poster. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
On Sun, 1 Sep 2002, James Cox wrote: The other he mentions is mbstring seems to cause problems. I have experienced this too. Guys, i don't want to be mean or sound racist or anything else you throw at me. But mbstring really isn't a core module, and very few people will require kr/zh/ru style encoding. I vote to remove mbstring as a default module. +1 And for those who say that i could just disable it -- well, the converse is true. Let us STOP burdening default builds with crap that is unlikely to be used. +1 Derick --- Did I help you? http://www.derickrethans.nl/link.php?url=giftlist Frequent ranting: http://www.derickrethans.nl/ --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
James Cox wrote: I vote to remove mbstring as a default module. +1 -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
James Cox wrote: I vote to remove mbstring as a default module. +1 Let us STOP burdening default builds with crap that is unlikely to be used. Amen. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
On Sun, 1 Sep 2002, James Cox wrote: I vote to remove mbstring as a default module. +1000 And for those who say that i could just disable it -- well, the converse is true. Let us STOP burdening default builds with crap that is unlikely to be used. Another voice of reason! Welcome! --- Dan KalowskyA little less conversation, http://www.deadmime.org/~danka little more action. [EMAIL PROTECTED]- A Little Less Conversation, [EMAIL PROTECTED]Elvis Presley -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
At 10:49 AM +0100 9/1/02, James Cox wrote: I vote to remove mbstring as a default module. I completely agree! I do have one request, when the time comes to remove it from the default also change the PHP core code so that it can be built as a shared extension and loaded on the fly. Currently it can only be compiled into PHP statically and building it as .so means hacking the PHP source and the mbstring module (which I have already done with a small patch). Just my 2 cents. Thanks, Brian BTW, sorry if this has been already done in the CVS tree and I didn't catch it. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
I do have one request, when the time comes to remove it from the default also change the PHP core code so that it can be built as a shared extension and loaded on the fly. Currently it can only be compiled into PHP statically and building it as .so means hacking the PHP source and the mbstring module (which I have already done with a small patch). Where is your patch? -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 6:29 PM +0100 9/1/02, James Cox wrote:
Where is your patch?
The patch basically renames php_treat_data to php_treat_data_default,
creates a function pointer called php_treat_data that is defaulted to
php_treat_data_default, removes all mbstrings references in php_main.h
and makes mbstring.c change the php_treat_data to mbstr_treat_data in
the INIT function and restores its value in SHUTDOWN.
This allows us to only load the mbstrings extension on the machines
that need it, which is a very small percentage of our over all server
count.
This patch is based off of the 4.2.2 release and there have been
changes in CVS to the exif extension that may need mbstring to be
static because it is expecting mbstr_treat_data to be handling the
php_treat_data stuff.
There was also talk about moving the changing mbstr_treat_data to be
the default handler since there was so much duplicate code in
mbstring.
Thanks,
Brian
--
diff -rc php-4.2.2/ext/mbstring/mbstring.c php-4.2.2/ext/mbstring/mbstring.c
*** php-4.2.2/ext/mbstring/mbstring.c Wed Apr 24 02:46:23 2002
--- php-4.2.2/ext/mbstring/mbstring.c Mon Jun 10 14:10:58 2002
***
*** 93,98
--- 93,100
{ MULTIPART_CONTENT_TYPE,
sizeof(MULTIPART_CONTENT_TYPE)-1, NULL,
rfc1867_post_handler },
{ NULL, 0, NULL, NULL }
};
+
+ void mbstr_treat_data(int arg, char *str, zval* destArray TSRMLS_DC);
#endif
static struct mb_overload_def mb_ovld[] = {
***
*** 529,534
--- 531,538
#if defined(MBSTR_ENC_TRANS)
sapi_unregister_post_entry(mbstr_post_entries);
sapi_register_post_entries(mbstr_post_entries);
+
+ php_treat_data = mbstr_treat_data;
#endif
REGISTER_LONG_CONSTANT(MB_OVERLOAD_MAIL, MB_OVERLOAD_MAIL,
CONST_CS | CONST_PERSISTENT);
***
*** 552,557
--- 556,565
#if HAVE_MBREGEX
zend_hash_destroy(MBSTRG(ht_rc));
+ #endif
+
+ #if defined(MBSTR_ENC_TRANS)
+ php_treat_data = php_treat_data_default;
#endif
return SUCCESS;
diff -rc php-4.2.2/main/php_main.h php-4.2.2/main/php_main.h
*** php-4.2.2/main/php_main.h Mon Mar 4 10:46:55 2002
--- php-4.2.2/main/php_main.h Mon Jun 10 14:09:59 2002
***
*** 53,60
extern int php_init_environ(void);
extern int php_shutdown_environ(void);
- #if defined(MBSTR_ENC_TRANS)
- #define php_treat_data mbstr_treat_data
- #endif
-
#endif
--- 53,56
diff -rc php-4.2.2/main/php_variables.c php-4.2.2/main/php_variables.c
*** php-4.2.2/main/php_variables.c Tue Dec 11 07:31:05 2001
--- php-4.2.2/main/php_variables.c Mon Jun 10 14:09:59 2002
***
*** 28,33
--- 28,34
#include zend_globals.h
+ void *(*php_treat_data)(int arg, char *str, zval* destArray
TSRMLS_DC) = php_treat_data_default;
PHPAPI void php_register_variable(char *var, char *strval, zval
*track_vars_array TSRMLS_DC)
{
***
*** 215,221
}
! void php_treat_data(int arg, char *str, zval* destArray TSRMLS_DC)
{
char *res = NULL, *var, *val, *separator=NULL;
const char *c_var;
--- 216,222
}
! void php_treat_data_default(int arg, char *str, zval* destArray TSRMLS_DC)
{
char *res = NULL, *var, *val, *separator=NULL;
const char *c_var;
diff -rc php-4.2.2/main/php_variables.h php-4.2.2/main/php_variables.h
*** php-4.2.2/main/php_variables.h Tue Dec 11 07:31:05 2001
--- php-4.2.2/main/php_variables.h Mon Jun 10 14:09:59 2002
***
*** 30,36
#define PARSE_COOKIE 2
#define PARSE_STRING 3
! void php_treat_data(int arg, char *str, zval* destArray TSRMLS_DC);
PHPAPI void php_import_environment_variables(zval *array_ptr TSRMLS_DC);
PHPAPI void php_register_variable(char *var, char *val, pval
*track_vars_array TSRMLS_DC);
/* binary-safe version */
--- 30,39
#define PARSE_COOKIE 2
#define PARSE_STRING 3
! extern void *(*php_treat_data)(int arg, char *str, zval* destArray
TSRMLS_DC);
!
! void php_treat_data_default(int arg, char *str, zval* destArray TSRMLS_DC);
!
PHPAPI void php_import_environment_variables(zval *array_ptr TSRMLS_DC);
PHPAPI void php_register_variable(char *var, char *val, pval
*track_vars_array TSRMLS_DC);
/* binary-safe version */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 20:38 01.09.2002, Brian France wrote: At 6:29 PM +0100 9/1/02, James Cox wrote: Where is your patch? The patch basically renames php_treat_data to php_treat_data_default, creates a function pointer called php_treat_data that is defaulted to php_treat_data_default, removes all mbstrings references in php_main.h and makes mbstring.c change the php_treat_data to mbstr_treat_data in the INIT function and restores its value in SHUTDOWN. This allows us to only load the mbstrings extension on the machines that need it, which is a very small percentage of our over all server count. This patch is based off of the 4.2.2 release and there have been changes in CVS to the exif extension that may need mbstring to be static because it is expecting mbstr_treat_data to be handling the php_treat_data stuff. exif uses mbstring since 4.3 so 4.2.3 would be no problem (...) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 8:47 PM +0200 9/1/02, Marcus Börger wrote: At 20:38 01.09.2002, Brian France wrote: At 6:29 PM +0100 9/1/02, James Cox wrote: Where is your patch? The patch basically renames php_treat_data to php_treat_data_default, creates a function pointer called php_treat_data that is defaulted to php_treat_data_default, removes all mbstrings references in php_main.h and makes mbstring.c change the php_treat_data to mbstr_treat_data in the INIT function and restores its value in SHUTDOWN. This allows us to only load the mbstrings extension on the machines that need it, which is a very small percentage of our over all server count. This patch is based off of the 4.2.2 release and there have been changes in CVS to the exif extension that may need mbstring to be static because it is expecting mbstr_treat_data to be handling the php_treat_data stuff. exif uses mbstring since 4.3 so 4.2.3 would be no problem Which means that my fix would fix it for 4.2.x releases and then it breaks again in 4.3. Break, I mean mbstring can not be built as a shared extension. I know there are things the exif needs from mbstring and there is no way to have exif link against mbstring or require it. But couldn't exif check to see if mbstring is loaded (or built in) and if not print a warning that some of its functionality may not work correctly unless mbstring is loaded (or built in)? Thanks, Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring
At 20:57 01.09.2002, Brian France wrote: At 8:47 PM +0200 9/1/02, Marcus Börger wrote: At 20:38 01.09.2002, Brian France wrote: At 6:29 PM +0100 9/1/02, James Cox wrote: Where is your patch? The patch basically renames php_treat_data to php_treat_data_default, creates a function pointer called php_treat_data that is defaulted to php_treat_data_default, removes all mbstrings references in php_main.h and makes mbstring.c change the php_treat_data to mbstr_treat_data in the INIT function and restores its value in SHUTDOWN. This allows us to only load the mbstrings extension on the machines that need it, which is a very small percentage of our over all server count. This patch is based off of the 4.2.2 release and there have been changes in CVS to the exif extension that may need mbstring to be static because it is expecting mbstr_treat_data to be handling the php_treat_data stuff. exif uses mbstring since 4.3 so 4.2.3 would be no problem Which means that my fix would fix it for 4.2.x releases and then it breaks again in 4.3. Break, I mean mbstring can not be built as a shared extension. I meant you do not have to care about exif in 4.2.3 and it does not break thinks in 4.3 since availability is checked. The only thing is that there is be a lack in documentation for the case that mbstring is a shared module. I know there are things the exif needs from mbstring and there is no way to have exif link against mbstring or require it. But couldn't exif check to see if mbstring is loaded (or built in) and if not print a warning that some of its functionality may not work correctly unless mbstring is loaded (or built in)? I think we could, especially since 4.3 features are not sipulated yet. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
At 11:49 01.09.2002, James Cox wrote: Phil Copeland redhat pointed me at this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72752 Seems that there are a number of issues (i'm going to verify patch his fixes right now). The other he mentions is mbstring seems to cause problems. I have experienced this too. Guys, i don't want to be mean or sound racist or anything else you throw at me. But mbstring really isn't a core module, and very few people will require kr/zh/ru style encoding. I vote to remove mbstring as a default module. And for those who say that i could just disable it -- well, the converse is true. Let us STOP burdening default builds with crap that is unlikely to be used. The problem with removing mbstring as a default module would be its upcoming integration into Zend engine for full I18n of php. So i would prefer making it a module that does not harm anything. In other words it must not change anything until some character conversion is really needed. I see the reasons for making it a non default module but i also think it will become a core module. The remaining question is: Do we want full I18n for php? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
On 01/09/02, James Cox [EMAIL PROTECTED] wrote: The other he mentions is mbstring seems to cause problems. I have experienced this too. Umm, dont enable the transparent encoding support then. I don't, and I've had no problems. But mbstring really isn't a core module, and very few people will require kr/zh/ru style encoding. But what about all the other encodings (not just charsets)? I vote to remove mbstring as a default module. I guess you have never tried to create a truely globalized/localized application then? I'm -1 on removing it, because PHP needs a consistent charset encoding API that is portable across platforms. iconv and recode are no good because their supported charsets vary from system to system and version to version; some libraries actually have broken encoding tables Enabling mbstring by default was a very good move (tm). But enabling the transparent encoding support option just because it's there is not a very good move. Just because people enable stuff they don't understand is not a good reason to disable this module. Actually, I'm -2 on removing it; -1 because PHP scripts can use it, and and additional -1 because PHP extensions that need to play with encodings can (and do) also use this portable API. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
I vote to remove mbstring as a default module. I guess you have never tried to create a truely globalized/localized application then? I'm -1 on removing it, because PHP needs a consistent charset encoding API that is portable across platforms. iconv and recode are no good because their supported charsets vary from system to system and version to version; some libraries actually have broken encoding tables Wez, let me rephrase: mbstring isn't a gold module which should be enabled by default. That is, it's still -- as i see it -- just a bit more than experimental. mbstring work is being done on sourceforge! So I want to 'disable' it by default. If you want encoding, just enable it. But you're right, i've never needed to create a truely globalized/localized app. (and from general principles, if you feel you need to localize any more than your ui/strings.) That's not what I read, perhaps you can just double clarify this -- you do not at all want to remove mbstring from PHP (and move it say, to pear)... If this is correct, than I'm +1, otherwise I'm -1. Mbstring is very important when it comes to creating i18n applications. Also, you seem to forget that PHP is not only used in England, but other areas where it is _quite_ important, and _quite_ necessary. -Sterling -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
Brian France wrote: I know there are things the exif needs from mbstring and there is no way to have exif link against mbstring or require it. But couldn't exif check to see if mbstring is loaded (or built in) and if not print a warning that some of its functionality may not work correctly unless mbstring is loaded (or built in)? It's not a good idea. What we need is smart ini parser and module loader that understand module dependecy and proper loading order. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
At 01:24 02.09.2002, Yasuo Ohgaki wrote: Brian France wrote: I know there are things the exif needs from mbstring and there is no way to have exif link against mbstring or require it. But couldn't exif check to see if mbstring is loaded (or built in) and if not print a warning that some of its functionality may not work correctly unless mbstring is loaded (or built in)? It's not a good idea. What we need is smart ini parser and module loader that understand module dependecy and proper loading order. PLEASE charme down on exif/mbstring liaison. ext/exif is by now the most capable implemetnation available freely (with the restriction that it can only read things) so i guess i can invent some workaround. Or the users who really like that liaison can enable both modules. For me the only reason to depend on both is the combination of ACDSee and php. More will follow but i hope until then mbstring/I18n is fully integrated in php5.0. So my vote is +1 for having I18n support for php by mbstring being default. AND exif has no affect. It works whether or not mbstring is there. Just some tags might cause some problems (WinXP specific and one more). AND exif is disliked by the developers on this list so why do we care now? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
At 01:24 02.09.2002, you wrote: Brian France wrote: I know there are things the exif needs from mbstring and there is no way to have exif link against mbstring or require it. But couldn't exif check to see if mbstring is loaded (or built in) and if not print a warning that some of its functionality may not work correctly unless mbstring is loaded (or built in)? It's not a good idea. What we need is smart ini parser and module loader that understand module dependecy and proper loading order. We already had some discussion on some IF statements in ini files already. I guess we might call to another mail thread here and hope we find a volunteer. I will not invent any work here since that would be totally useless. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
I know this is ugly, but what about making the extensions handle it themselves?
Your example of session_pgsql:
In the extension init code:
ext_enabled = 1;
if ( dlsym( NULL, psql_module_entry ) == NULL
dlsym( NULL, _psql_module_entry ) == NULL )
{
// print some warning about needing the pgsql extension
// or pgsql should be loaded before this one in the php.ini
ext_enabled = 0;
}
if ( dlsym( NULL, session_module_entry ) == NULL
dlsym( NULL, _session_module_entry ) == NULL )
{
// print some warning about needing the session extension
// or session should be loaded before this one in the php.ini
ext_enabled = 0;
}
The second call with a underscore is to handle Openbsd and old
version of FreeBSD, I think a.out things. I am sure this can be
handled differently, but you get the point.
Cheers,
Brian
At 9:19 AM +0900 9/2/02, Yasuo Ohgaki wrote:
We know current module loader is not smart :)
As number of modules increases, number of module depends on another
increases. Examples are mbstirng/mailparse/exif,
session/msession/session_pgsql and bunch of session save handler
modules out there, session_pgsql depends of session and pgsql module,
etc.
(Loading sessoin save handler as module does not work at all, since
current module loader isn't take into module dependency at all)
I would like to see smart module loader and/or ini parser that can
address this issue. PHP crashes easily w/o it.
IF statemnet is better than now, but it's not good enough.
I don't think this carefully, but here is my idea.
Add following member so that get_module() retrive
loading weight (we need this so that we can control sub module
loading order)
list modules depend on
Check if module required is there, raise E_WARNING
if module cannot be loaded.
Sort modules so that modules are loaded w/o problem.
Load modules.
This is easy to implement, isn't it?
We may better to have smart ini parser, but it may not be
required strictly for this purpose.
I don't have plan to write this, since I need to modify
engine code. I hope Andi or Zeev like this idea for PHP5 :)
BTW, I'm +1 for having IF statement in php.ini.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
At 9:25 AM +0900 9/2/02, Yasuo Ohgaki wrote: As all of us know, PHP crashes easily when module is loaded improperly. Has anybody tracked down why this is? This could have been the problem, but is fixed now: http://bugs.php.net/?id=17643 (I think this link is right, bugs is down right now) Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
We should have generic code for this. IMHO.
--
Yasuo Ohgaki
Brian France wrote:
I know this is ugly, but what about making the extensions handle it
themselves?
Your example of session_pgsql:
In the extension init code:
ext_enabled = 1;
if ( dlsym( NULL, psql_module_entry ) == NULL
dlsym( NULL, _psql_module_entry ) == NULL )
{
// print some warning about needing the pgsql extension
// or pgsql should be loaded before this one in the php.ini
ext_enabled = 0;
}
if ( dlsym( NULL, session_module_entry ) == NULL
dlsym( NULL, _session_module_entry ) == NULL )
{
// print some warning about needing the session extension
// or session should be loaded before this one in the php.ini
ext_enabled = 0;
}
The second call with a underscore is to handle Openbsd and old version
of FreeBSD, I think a.out things. I am sure this can be handled
differently, but you get the point.
Cheers,
Brian
At 9:19 AM +0900 9/2/02, Yasuo Ohgaki wrote:
We know current module loader is not smart :)
As number of modules increases, number of module depends on another
increases. Examples are mbstirng/mailparse/exif,
session/msession/session_pgsql and bunch of session save handler
modules out there, session_pgsql depends of session and pgsql module,
etc.
(Loading sessoin save handler as module does not work at all, since
current module loader isn't take into module dependency at all)
I would like to see smart module loader and/or ini parser that can
address this issue. PHP crashes easily w/o it.
IF statemnet is better than now, but it's not good enough.
I don't think this carefully, but here is my idea.
Add following member so that get_module() retrive
loading weight (we need this so that we can control sub module
loading order)
list modules depend on
Check if module required is there, raise E_WARNING
if module cannot be loaded.
Sort modules so that modules are loaded w/o problem.
Load modules.
This is easy to implement, isn't it?
We may better to have smart ini parser, but it may not be
required strictly for this purpose.
I don't have plan to write this, since I need to modify
engine code. I hope Andi or Zeev like this idea for PHP5 :)
BTW, I'm +1 for having IF statement in php.ini.
--
Yasuo Ohgaki
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
