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'

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 bu

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 w

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 enou

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

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

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

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 w

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 userbas

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 exten

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 extens

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

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 To unsubscribe, visit: http://www.

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 mbst

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 dev

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 > > -- > > -

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 mbs

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

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 appa

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 PROTEC

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 sym

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 i

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,

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. > >Ther

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 .

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 c

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..) --Jan

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 n

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. m

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

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

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 us

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 >

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

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 t

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 w

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 sev

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 overload

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

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

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 encod

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 wan

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.

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

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 rece

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. T

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 integ

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 productio

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

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 cann

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