Re: [PHP-DEV] mbstring/exif/win32

At 13:17 16.12.2002, Edin Kadribasic wrote: > Both 4.3 and Head still have a problem with mbstring not being default > under win32. Exif module can be compiled but not loaded because it > uses a function from mbstring. Exif tests for HAVE_MBSTRING and > COMPILE_DL_MBSTRING. The question is why HAV

Re: [PHP-DEV] mbstring/exif/win32

> Both 4.3 and Head still have a problem with mbstring not being default > under win32. Exif module can be compiled but not loaded because it > uses a function from mbstring. Exif tests for HAVE_MBSTRING and > COMPILE_DL_MBSTRING. The question is why HAVE_MBSTRING is > defined but COMPILE_DL_MBSTRI

[PHP-DEV] mbstring/exif/win32

Both 4.3 and Head still have a problem with mbstring not being default under win32. Exif module can be compiled but not loaded because it uses a function from mbstring. Exif tests for HAVE_MBSTRING and COMPILE_DL_MBSTRING. The question is why HAVE_MBSTRING is defined but COMPILE_DL_MBSTRING is unde

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

[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, tha

[PHP-DEV] mbstring regexp working in 4.2.3?

I've been testing some the regexp functions (two so far) of the mbstring functions in 4.2.3 and they don't work. I've submitted two bug reports but before continuing my testing of more mbstring functions I wanted to ask ... 1- did any of the regexp (split, ereg_match ...) ever work in this lib

Re: [PHP-DEV] mbstring functions in 4.2.3

Hi, AFAIK, php_stat() and tsrm_virtual_cwd() related problems under multibyte win32 environment were already fixed by Rui. But the bugs are still active under some unix operating systems that accept Shift_JIS as its locale charset/encoding if you specify it, as EUC-JP is most suitable to use w

Re: [PHP-DEV] mbstring functions in 4.2.3

Hi Erica, Personally, I would roll my own tarball/package based on the now fixed code in the 4.2 branch of CVS. However, as I mentioned in your original PR, there is a bug that affects file_exists on some systems; AFAIK, this has yet to be resolved which I why I suggested that you ask here, and

[PHP-DEV] mbstring functions in 4.2.3

Hi! I'm making a PHP package that will be distributed to potentially hundreds of people. I based the package off 4.2.3, since that's the latest version from PHP.Net. However, I have encountered a nasty bug with the mbstring-enc-trans extension as described here: http://bugs.php.net/bug.php?id=195

Re: [PHP-DEV] mbstring

> AFAIK, there is no serious bug in mbstring. > If there is serious problem, let us know so that it can be > addressed. Then start with removing double url decoding of the input... and then fix the "mad" separator counter ... Stefan -- PHP Development Mailing List To unsu

Re: [PHP-DEV] mbstring

Wez Furlong wrote: > Having been using it to handle more than 105,000 email messages over > the last 18 months *in production*, I have to disagree. *SNIP* > Now, the mbstr-enc-trans might have had some stability issues, but as > I've been saying, it is NOT enabled by default, and lets print a > wa

Re: [PHP-DEV] mbstring

Jim Winstead wrote: > Yasuo Ohgaki <[EMAIL PROTECTED]> wrote: > >>Marcus B?rger wrote: >> >>>We already had some discussion on some IF statements in ini >>>files already. I guess we might call to another mail thread here >>>and hope we find a volunteer. I will not invent any work here since >>>th

Re: [PHP-DEV] mbstring

On Tue, Sep 03, 2002 at 06:06:29AM +0200, Sebastian Nohn wrote : > Well... What about an _optional_ curses based, linux-kernel-like "make > menuconfig"? > > +--+ > | - Extensions | > | [x] mySQL

RE: [PHP-DEV] mbstring

> -Original Message- > From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 02, 2002 9:53 PM > To: Yasuo Ohgaki > Cc: PHP Development Mailing list > Subject: Re: [PHP-DEV] mbstring > > > On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: > > > I

Re: [PHP-DEV] mbstring

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 02 September 2002 04:16 pm, Zeev Suraski wrote: > At 22:52 02/09/2002, Dan Kalowsky wrote: > >On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: > > > If we should reduce number of modules built by default, 1st > > > module should be MySQL. Removing My

RE: [PHP-DEV] mbstring

At 23:21 02/09/2002, James Cox wrote: >Nice to see you argue that one so eloquently... I have in the past, numerous times. I don't think I or anybody else should have to repeat themselves like broken records, you can look it up in the archives. Zeev -- PHP Development Mailing List

RE: [PHP-DEV] mbstring

> > At 22:52 02/09/2002, Dan Kalowsky wrote: > >On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: > > > > > If we should reduce number of modules built by default, 1st > > > module should be MySQL. Removing MySQL does not cause any > > > technical problems at all. > > > >I'll agree to that as well. +1 on

Re: [PHP-DEV] mbstring

At 22:52 02/09/2002, Dan Kalowsky wrote: >On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: > > > If we should reduce number of modules built by default, 1st > > module should be MySQL. Removing MySQL does not cause any > > technical problems at all. > >I'll agree to that as well. +1 on removing --with-mys

Re: [PHP-DEV] mbstring

On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: > If we should reduce number of modules built by default, 1st > module should be MySQL. Removing MySQL does not cause any > technical problems at all. I'll agree to that as well. +1 on removing --with-mysql as a default. Although realize I'm also +1 on re

RE: [PHP-DEV] mbstring

On Mon, 2 Sep 2002, James Cox wrote: JC>>> > On Mon, 2 Sep 2002, James Cox wrote: JC>>> > JC>>> > JC>>> Still, I think it makes more sense to enable, not disable. JC>>> > What extensions are enabled by default anyhow? I am not aware of JC>>> > a list. Perhaps that's why i get odd errors when wor

RE: [PHP-DEV] mbstring

> > On Mon, 2 Sep 2002, James Cox wrote: > > JC>>> Still, I think it makes more sense to enable, not disable. > What extensions are enabled by default anyhow? I am not aware of > a list. Perhaps that's why i get odd errors when working with > php, because there are extensions i didn't expect bui

RE: [PHP-DEV] mbstring

On Mon, 2 Sep 2002, James Cox wrote: JC>>> Still, I think it makes more sense to enable, not disable. What extensions are enabled by default anyhow? I am not aware of a list. Perhaps that's why i get odd errors when working with php, because there are extensions i didn't expect built in. ./co

RE: [PHP-DEV] mbstring

> > As I see it, PHP was designed with speed and simplicity in > mind. Having the > > burden of a large number of extra modules compiled in by default doesn't > > help, and deviates from this path. > > No, you can always disable those extensions. The default extensions were > *voted* in for

RE: [PHP-DEV] mbstring

> Wez, > > lets loose the crap here. I am happy to see mbstring in PHP! I have > used it too, when I needed multibyte support. > James, Let's stay consistent here. Your opinion changes more than Microsoft's .NET strategy... In your original message you stated that you wanted to rem

Re: [PHP-DEV] mbstring

> But it *is* VERY stable in the default configuration. > > > All I am saying is that we should > > disable it by default in current releases. For PHP5, we should have proper > > mbstring support that should probably also be transparent; by that I mean I > > see no reason for it not to be as stand

RE: [PHP-DEV] mbstring

On 09/02/02, "James Cox" <[EMAIL PROTECTED]> wrote: > But you see, it's not really all that solid. It needs more work (hence this > apparent development outside of php.net). But it *is* VERY stable in the default configuration. > All I am saying is that we should > disable it by default in curre

RE: [PHP-DEV] mbstring

> At 13:19 02/09/2002, James Cox wrote: > >As I see it, PHP was designed with speed and simplicity in mind. > > It was indeed.. > > >Having the burden of a large number of extra modules compiled in by > >default doesn't help, and deviates from this path. > > Not really. Speed-wise, adding mo

RE: [PHP-DEV] mbstring

At 13:19 02/09/2002, James Cox wrote: >As I see it, PHP was designed with speed and simplicity in mind. It was indeed.. >Having the burden of a large number of extra modules compiled in by >default doesn't help, and deviates from this path. Not really. Speed-wise, adding modules has a negligi

RE: [PHP-DEV] mbstring

Wez, lets loose the crap here. I am happy to see mbstring in PHP! I have used it too, when I needed multibyte support. But you see, it's not really all that solid. It needs more work (hence this apparent development outside of php.net). All I am saying is that we should disable it by default

RE: [PHP-DEV] mbstring

I do agree with Wez (not 'completely agree', though ;) FWIW, mbstring was/is indeed enabled by default under Windows, and I think that at this stage this is not a good idea. There was at least one serious crash in the code that was introduced by the changes, into both the mbstring version and

RE: [PHP-DEV] mbstring

Having been using it to handle more than 105,000 email messages over the last 18 months *in production*, I have to disagree. I have to say that I'm appalled that most of the people making these "I completely agree" comments have probably never even tried to use mbstring; most certainly haven't ev

Re: [PHP-DEV] mbstring

At 03:41 02/09/2002, Brian France wrote: >I know this is ugly, but what about making the extensions handle it >themselves? It's actually not ugly at all. Letting the modules handle it themselves is the Right Way, because only they know what they need. The only question is whether we need to

Re: [PHP-DEV] mbstring

At 05:15 02/09/2002, Yasuo Ohgaki wrote: >Marcus Börger wrote: >>At 01:24 02.09.2002, you wrote: >> >>>Brian France wrote: >>> I know there are things the exif needs from mbstring and there is no way to have exif link against mbstring or require it. But couldn't exif check to see if

RE: [PHP-DEV] mbstring

On 09/01/02, "James Cox" <[EMAIL PROTECTED]> wrote: > mbstring isn't a "gold" module which should be enabled by default. But there was a discussion and it was agreed to enable it by default! > That is, it's still -- as i see it -- just a bit more than experimental. > mbstring work is being done

Re: [PHP-DEV] mbstring

On Mon, 2 Sep 2002, Marcus Börger wrote: > AND exif is disliked by the developers on this list so why do we care now? Markus, that makes no sense. Just because some ppl don't want it exif enabled by default doesn't make us 'dislike' exif, it doesn't make us (atleast not me) like you less. Der

RE: [PHP-DEV] mbstring

ox; Wez Furlong; Php-Dev > Subject: Re: [PHP-DEV] mbstring > > > On Mon, 2 Sep 2002, Masaki Fujimoto wrote: > > > Hi, > > > > let me vote not to remove mbstring (as a default one). > > I'd vote for setting it off by default _for now_, and enable it after

RE: [PHP-DEV] mbstring

> > So I want to 'disable' it by default. If you want encoding, > just enable it. But you're right, i've never needed to create a > truely globalized/localized app. (and from general principles, if > you feel you need to localize any more than your ui/strings.) > > > > That's not what I read,

Re: [PHP-DEV] mbstring

On Mon, 2 Sep 2002, Masaki Fujimoto wrote: > Hi, > > let me vote not to remove mbstring (as a default one). I'd vote for setting it off by default _for now_, and enable it after 4.3. has branched, so we have a kick ass i18n solution in PHP5 replacing all code it duplicates. > yes, I can unde

Re: [PHP-DEV] mbstring

On Mon, 2 Sep 2002, Yasuo Ohgaki wrote: > James Cox wrote: > > > > mbstring isn't a "gold" module which should be enabled by default. > > If we should reduce number of modules built by default, 1st > module should be MySQL. Removing MySQL does not cause any > technical problems at all. Yeah, t

Re: [PHP-DEV] mbstring

On Sun, 1 Sep 2002, Shane Caraveo wrote: > Jim Winstead wrote: > > it's too bad we don't have an implementation of a complete programming > > language laying around. > > > > jim > > Yeah, sure would be usefull, then we could just get rid of ini, and use > the language... Too much interesting

Re: [PHP-DEV] mbstring

Jim Winstead wrote: > Yasuo Ohgaki <[EMAIL PROTECTED]> wrote: > >>Marcus B?rger wrote: >> >>>We already had some discussion on some IF statements in ini >>>files already. I guess we might call to another mail thread here >>>and hope we find a volunteer. I will not invent any work here since >>>th

Re: [PHP-DEV] mbstring

Yasuo Ohgaki <[EMAIL PROTECTED]> wrote: > Marcus B?rger wrote: >> We already had some discussion on some IF statements in ini >> files already. I guess we might call to another mail thread here >> and hope we find a volunteer. I will not invent any work here since >> that would be totally useless.

Re: [PHP-DEV] mbstring

Hi, let me vote not to remove mbstring (as a default one). yes, I can understand the thought that singlebyte users seem mbstirng module is somehow 'extra' one. but please understand that this module is indispensable for multibyte users (at least), and AFAIK there are growing numbers of multibyt

Re: [PHP-DEV] mbstring

Marcus Börger wrote: > At 01:24 02.09.2002, you wrote: > >> Brian France wrote: >> >>> I know there are things the exif needs from mbstring and there is no >>> way to have exif link against mbstring or require it. But couldn't >>> exif check to see if mbstring is loaded (or built in) and if no

Re: [PHP-DEV] mbstring

James Cox wrote: > > mbstring isn't a "gold" module which should be enabled by default. If we should reduce number of modules built by default, 1st module should be MySQL. Removing MySQL does not cause any technical problems at all. > > That is, it's still -- as i see it -- just a bit more tha

Re: [PHP-DEV] mbstring

Forgot to mention this. This will not solve module loading order issues. Not only checks if modules needed in there, but also we should be able to load module in order. To achive this, we need to change module loading code which is written in the engine. -- Yasuo Ohgaki Yasuo Ohgaki wrote: > W

Re: [PHP-DEV] mbstring

We should have generic code for this. IMHO. -- Yasuo Ohgaki Brian France wrote: > I know this is ugly, but what about making the extensions handle it > themselves? > > Your example of session_pgsql: > > In the extension init code: > > ext_enabled = 1; > > if ( dlsym( NULL, "psql_module_entr

Re: [PHP-DEV] mbstring

At 9:25 AM +0900 9/2/02, Yasuo Ohgaki wrote: >As all of us know, PHP crashes easily when module is loaded >improperly. Has anybody tracked down why this is? This could have been the problem, but is fixed now: http://bugs.php.net/?id=17643 (I think this link is right, bugs is down right now) B

Re: [PHP-DEV] mbstring

I know this is ugly, but what about making the extensions handle it themselves? Your example of session_pgsql: In the extension init code: ext_enabled = 1; if ( dlsym( NULL, "psql_module_entry" ) == NULL && dlsym( NULL, "_psql_module_entry" ) == NULL ) { // print some warning about

Re: [PHP-DEV] mbstring

As all of us know, PHP crashes easily when module is loaded improperly. This is what we should fix. As I mentioned in personal mail, it's not difficult to fix at module loader level. -- Yasuo Ohgaki Marcus Börger wrote: > At 01:24 02.09.2002, Yasuo Ohgaki wrote: > >> Brian France wrote: >> >>

  1   2   >