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
[PHP-DEV] mbstring and 4.3.0
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
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
