Re: [PHP-DEV] Re: [4.3] Current critical bugs

On Tue, Oct 15, 2002 at 06:33:33PM +0200, Markus Fischer wrote: > On Tue, Oct 15, 2002 at 06:23:17PM +0200, Tom Sommer wrote : > > Andrei Zmievski wrote: > > >Summary: max_execution_time affects large uploads > > >URL: http://bugs.php.net/bug.php?id=16880 [...] > I neither think this is

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

While I think it is a bit unintuitive to have $_FILES separate like it is (rather than a part of $_POST, for example), I think it would be much worse to also separate it from $_REQUEST. After all, as Sterling pointed out, it is part of the request. Chris Derick Rethans wrote: >On Wed, 16 Oct

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

On Wed, Oct 16, 2002 at 02:38:52AM -0500, Chris Shiflett wrote : > While I think it is a bit unintuitive to have $_FILES separate like it > is (rather than a part of $_POST, for example), I think it would be much > worse to also separate it from $_REQUEST. After all, as Sterling pointed > out,

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

On Wed, 16 Oct 2002, Markus Fischer wrote: > On Wed, Oct 16, 2002 at 02:38:52AM -0500, Chris Shiflett wrote : > > While I think it is a bit unintuitive to have $_FILES separate like it > > is (rather than a part of $_POST, for example), I think it would be much > > worse to also separate it fr

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main config.w32.h.in

Unless you fix the rest of the occurences of these symbolic defines this patch (which is the same Stig commited) is a bit problematic and will not work properly. Take a look at http://lxr.php.net/source/php4/main/main.c#1100 and see how PEAR_INSTALL_DIR is registered; size

Re: Re: [PHP-DEV] OCI extension help offer

I'm sure glad this in the headlines again ;-) As Thies knows, I already proposed another important change, which is supporting multiple character sets. This is very important on shared web platforms, and I have experienced the trouble that arises from the way the oci ext treats the session env

Re: Re: Re: [PHP-DEV] OCI extension help offer

Oh, and just to be clear about it: I am absolutely positive on a completely new (perhaps unified) extension for PHP 5, and would gladly participate. I Just don't think that changing anything in the current situation would be useful. Abdul <[EMAIL PROTECTED]> schrieb am 16.10.02 10:22:18: > I'm

Re[2]: [PHP-DEV] short_open_tag

Hello Dan, Tuesday, October 15, 2002, 7:41:16 PM, you wrote: DH> The web is a rapidly changing market and standards are being activley DH> evolved. and its not about XML document headers. Yes, the web is rapidly changing, but PHP shouldn't and couldn't change so fast. DH> I have written semi s

Re: [PHP-DEV] OCI extension help offer

<[EMAIL PROTECTED]> wrote... : > I'm sure glad this in the headlines again ;-) > > As Thies knows, I already proposed another important change, which is supporting >multiple character sets. This is very important on shared web platforms, and I have >experienced the trouble that arises from the

Re: [PHP-DEV] OCI extension help offer

<[EMAIL PROTECTED]> wrote... : > Oh, and just to be clear about it: I am absolutely positive on a completely new >(perhaps unified) extension for PHP 5, and would gladly participate. I Just don't >think that changing anything in the current situation would be useful. I'd never meant to :) -

RE: Re: [PHP-DEV] OCI extension help offer

> -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Envoyé : mercredi 16 octobre 2002 10:22 > À : [EMAIL PROTECTED] > Objet : Re: Re: [PHP-DEV] OCI extension help offer > > > I'm sure glad this in the headlines again ;-) +1 > As Thies knows, I already proposed a

Re: [PHP-DEV] OCI extension help offer

> It might be interesting to change only the extension name from oci8 to oci (which >would be less confusing when working with 9i). Unless your code relies on extension >names, it will still work. > > -1 for merging ora_ with oci_ extensions unless you can disable ora_* functions at >compile

Re: [PHP-DEV] [PATCH] New function file_put()

Derick Rethans wrote: > Please write a new test for this without piggy backing on the old one. > We're trying to get one function tested per tests so that differenc > functions in the same test can not be the cause of 'screw-ups'. Ok, I attached a file ext/standard/tests/file/file_put_contents.

Re: [PHP-DEV] OCI extension help offer

Hm, quite a few issues... Here are my thoughts regarding one of them. > > As Thies knows, I already proposed another important change, which is supporting >multiple character sets. This is very important on shared web platforms, and I have >experienced the trouble that arises from the way the o

Re: [PHP-DEV] OCI extension help offer

[EMAIL PROTECTED] schrieb am 16.10.02 12:13:57: > > It might be interesting to change only the extension name from oci8 to oci (which >would be less confusing when working with 9i). Unless your code relies on extension >names, it will still work. Nice idea, but I guess this is sheer "cosmetics"

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main config.w32.h.in

Markus Fischer wrote: > Please test before commit: Well, I only tested whether or not it compiles. Which it does, so it's not the same patch as before. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http:

Re: [PHP-DEV] OCI extension help offer

<[EMAIL PROTECTED]> wrote... : > Hm, quite a few issues... Here are my thoughts regarding one of them. > > > > As Thies knows, I already proposed another important change, which is supporting >multiple character sets. This is very important on shared web platforms, and I have >experienced th

Re: Re: [PHP-DEV] OCI extension help offer

[EMAIL PROTECTED] schrieb am 16.10.02 14:27:35: > > I think, at this point, it is up to Thies to review the patch. > I hope he's not too harsh on it ;-), since this code is certainly *not* ready for merging into the cvs tree. Meaning: it merges perfectly, but doesn't compile correctly on Orac

Re: [PHP-DEV] OCI extension help offer

<[EMAIL PROTECTED]> wrote... : > [EMAIL PROTECTED] schrieb am 16.10.02 12:13:57: > > > It might be interesting to change only the extension name from > > > oci8 to oci (which would be less confusing when working with 9i). Unless > > > your code relies on extension names, it will still work. >

Re: [PHP-DEV] OCI extension help offer

<[EMAIL PROTECTED]> wrote... : > [EMAIL PROTECTED] schrieb am 16.10.02 14:27:35: > > > > I think, at this point, it is up to Thies to review the patch. > > > > I hope he's not too harsh on it ;-), since this code is certainly *not* > ready for merging into the cvs tree. Meaning: it merges pe

[PHP-DEV] zend_compile.h patch

Any objections to exporting another function from zend_compile.h by applying this patch? I need this in order to compile pear/PECL/bcompiler on Windows. Edin Index: zend_compile.h === RCS file: /repository/Zend/zend_compile.h,v ret

[PHP-DEV] Re: Multibyte ([PHP-INST] Re: "If-Modified-Since"..)

> >ply correctly to requests with If-Modified-Since: header other than to > > modify PHP source code. > > Try CVS version. Thank you. The CVS version seemed to work correctly on this matter. > Hmm... Let us know the problem so that we can fix problems before > release. What I found is as fol

Re: [PHP-DEV] zend_compile.h patch

Edin Kadribasic wrote: >Any objections to exporting another function from zend_compile.h by >applying this patch? I need this in order to compile >pear/PECL/bcompiler on Windows. > >Edin > actually it's not needed 'at present' cause the compiled bytecodes do not use inheritance (as the compiled

Re: [PHP-DEV] zend_compile.h patch

I get linking errors when I tried to compile it on windows. The error was that zend_do_inheritance symbol was not found. Are you saying that this call is not needed? Could it be removed then? Edin - Original Message - From: "Alan Knowles" <[EMAIL PROTECTED]> To: "Edin Kadribasic" <[EMAI

Re: [PHP-DEV] zend_compile.h patch

Edin Kadribasic wrote: >I get linking errors when I tried to compile it on windows. The >error was that zend_do_inheritance symbol was not found. Are you >saying that this call is not needed? Could it be removed then? > > At them moment, you can comment out the bcompiler_inherit call (it's nev

Re: [PHP-DEV] Plan for PHP 5.0

> If someone gives me an account on an OSX box (or even better, puts an > OSX box into my mailbox! ;-) I will make it work. Don't know how useful/useable this is, but Sourceforge's compile farm includes a box with OSX (10.1). - Colin -- PHP Development Mailing List To u

Re: [PHP-DEV] short_open_tag

Since the general consensus by the developers is not to remove the short_tags or even disable them. Perhaps we should consider alternate solutions to this problem. Given the buzzword popularity of XML and its slowly growing popularity among website designers (XHTML) this issue is likely to come

[PHP-DEV] nl2br is broken in PHP4.3.0pre1

Hi, It seems like the nl2br() function is broken when the input string does not contain any newlines. [sagi@domino tmp]$ php -v PHP 4.3.0-pre1 (cli), Copyright (c) 1997-2002 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies [sagi@domino tmp]$ cat test.php [sagi@domino

Re: [PHP-DEV] nl2br is broken in PHP4.3.0pre1

Hey, this is already fixed in CVS. thanks, Derick On Wed, 16 Oct 2002, Sagi Bashari wrote: > Hi, > > It seems like the nl2br() function is broken when the input string does > not contain any newlines. > [sagi@domino tmp]$ php -v > PHP 4.3.0-pre1 (cli), Copyright (c) 1997-2002 The PHP Group

RE: [PHP-DEV] nl2br is broken in PHP4.3.0pre1

Derick Rethans writes: > Hey, > > this is already fixed in CVS. > > thanks, > Derick Have you decided yet on the release cycle for 4.3? Are we any closer to branching 4.3.0 or are we going to do 4.3.0pr2 for further testing, or? :) Regards Mike Robinson -- PHP Development Mailing Lis

RE: [PHP-DEV] nl2br is broken in PHP4.3.0pre1

On Wed, 16 Oct 2002, Mike Robinson wrote: > Have you decided yet on the release cycle for 4.3? Are we any > closer to branching 4.3.0 or are we going to do 4.3.0pr2 for > further testing, or? :) That's all up to Andrei, but I would favor for a pre2 during the next week for further testing,

Re: [PHP-DEV] nl2br is broken in PHP4.3.0pre1

On Wed, 16 Oct 2002, Derick Rethans wrote: > That's all up to Andrei, but I would favor for a pre2 during the next > week for further testing, but it looks good so far. Yes, we'll make another 'pre' release early next week. Lots of good bugs have been fixed since pre1. -Andrei

[PHP-DEV] [PATCH] Changing entity charset handling in ext/standard/html.c

Hi, I know this may cause a potential BC problem, but I think htmlentities() should be more consistent with mbstring modules. The attached patch changes the behaviour of htmlentities() or its internal counterparts, to take the character set of the characters as the value of mbstring.internal_

Re: [PHP-DEV] [PATCH] Changing entity charset handling inext/standard/html.c

Unfortunately, we absolutely must remain 100% backwards compatible with htmlentities(), so this patch should not be applied. However, I don't see a problem with making phpinfo determine the charset and passing that on to the internal htmlentities function? --Wez. On Thu, 17 Oct 2002, Moriyoshi

Re: [PHP-DEV] [PATCH] Changing entity charset handling inext/standard/html.c

Wez Furlong <[EMAIL PROTECTED]> wrote: > Unfortunately, we absolutely must remain 100% backwards compatible with > htmlentities(), so this patch should not be applied. Were there any discussions exactly about this issue? Though I have to see some historical reason, however I don't understand why

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

On Wed, 16 Oct 2002, Derick Rethans wrote: >On Wed, 16 Oct 2002, Markus Fischer wrote: > >> On Wed, Oct 16, 2002 at 02:38:52AM -0500, Chris Shiflett wrote : >> > While I think it is a bit unintuitive to have $_FILES separate like it >> > is (rather than a part of $_POST, for example), I think i

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

On Thu, 17 Oct 2002, Jani Taskinen wrote: >On Wed, 16 Oct 2002, Derick Rethans wrote: > >>On Wed, 16 Oct 2002, Markus Fischer wrote: >> >>> On Wed, Oct 16, 2002 at 02:38:52AM -0500, Chris Shiflett wrote : >>> > While I think it is a bit unintuitive to have $_FILES separate like it >>> > is (rat

Re: [PHP-DEV] [PATCH] Changing entity charset handling inext/standard/html.c

Search the archives for the discussion. phpinfo could determine the charset as your patch does at the start, and then pass the info in php_escape_html_entities. Seems easy to me. --Wez. On 10/16/02, "Moriyoshi Koizumi" <[EMAIL PROTECTED]> wrote: > Wez Furlong <[EMAIL PROTECTED]> wrote: > > Unfo

Re: [PHP-DEV] nl2br is broken in PHP4.3.0pre1

On Wed, 16 Oct 2002, Andrei Zmievski wrote: >On Wed, 16 Oct 2002, Derick Rethans wrote: >> That's all up to Andrei, but I would favor for a pre2 during the next >> week for further testing, but it looks good so far. > >Yes, we'll make another 'pre' release early next week. Lots of good bugs >hav

[PHP-DEV] Xerces?

Hi all, I have done limited looking but as far as I can tell Xerces is not supported by PHP. A) hopefully I am wrong and just didn't look hard enough. B) If not, any validating parsers that are supported that do DTD validation? It looks like there's an experimental Xalan ext out there, but no X

Re: [PHP-DEV] Xerces?

There is only Sablotron support. No Xerces. Feel free to contribute the code to support Xerces. -Rasmus On Wed, 16 Oct 2002, Alex Black wrote: > Hi all, > > I have done limited looking but as far as I can tell Xerces is not supported > by PHP. > > A) hopefully I am wrong and just didn't look

Re: [PHP-DEV] nl2br is broken in PHP4.3.0pre1

Jani Taskinen <[EMAIL PROTECTED]> wrote: > Just wondering..but what is a 'good bug' ? > IMO, every bug is BAD. :) evil ones :) -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [binarycloud-dev] Re: [PHP-DEV] Xerces?

> There is only Sablotron support. No Xerces. Feel free to contribute the > code to support Xerces. hi Rasmus, Sab is an XSLT processor, Xerces is a validating XML parser. You were probably thinking Xalan, which is the apachexml XSLT processor. Yes, I'd also like to have access to Xalan via ph

Re: [PHP-DEV] Xerces?

Since Xalan is written java, won't ext/java do that work anyway? On Wed, Oct 16, 2002 at 02:56:50PM -0700, Alex Black wrote : > Hi all, > > I have done limited looking but as far as I can tell Xerces is not supported > by PHP. > > A) hopefully I am wrong and just didn't look hard enoug

Re: [PHP-DEV] Xerces?

Has anyone started any work work on this? On Wednesday, October 16, 2002, at 05:59 PM, Rasmus Lerdorf wrote: > There is only Sablotron support. No Xerces. Feel free to contribute > the > code to support Xerces. > > -Rasmus > > On Wed, 16 Oct 2002, Alex Black wrote: > >> Hi all, >> >> I have d

Re: [PHP-DEV] Xerces?

Xalan and Xerces have both java and c versions. Markus Fischer wrote: > Since Xalan is written java, won't ext/java do that work > anyway? > > On Wed, Oct 16, 2002 at 02:56:50PM -0700, Alex Black wrote : > >>Hi all, >> >>I have done limited looking but as far as I can tell Xerces is no

[PHP-DEV] Re: Multibyte ([PHP-INST] Re: "If-Modified-Since"..)

Ryo Takagi wrote: > If the line: > > print ( mb_convert_encoding( $jstr, "ISO-2022-JP" ) ) ; > > in this script is modified to: > > print ( mb_convert_encoding( $jstr, "ISO-2022-JP", "EUC-JP" ) ) ; > > then it works again. This cannot be fixed. Check & modify your detect order by mb

[PHP-DEV] Re: Multibyte ([PHP-INST] Re: "If-Modified-Since"..)

Forgot to what it's doing. Since the multibyte char sequence is too short, mbstring is failing to detect encoding correctly. In this case, we can specify encoding or modify detect order. -- Yasuo Ohgaki Yasuo Ohgaki wrote: > Ryo Takagi wrote: > >> If the line: >> >> print ( mb_convert_en

Re: [PHP-DEV] Xerces?

> Since Xalan is written java, won't ext/java do that work > anyway? Sorta, That's a little funky but yes it would work. I would far prefer to have a c-extension for the C++ version. My (limited) experience with php/java is... Slightly funk. It does work but it seems ornry :) Still no one h

Re: [PHP-DEV] Re: Multibyte ([PHP-INST] Re: "If-Modified-Since"..)

nah... "If it(==from_encoding) is not specified, the internal encoding will be used." (http://jp.php.net/manual/en/function.mb-convert-encoding.php) so it's just because mbstring.internal_encoding is not properly set? Masaki Fujimoto On Thu, 17 Oct 2002 08:17:27 +0900 Yasuo Ohgaki <[EMAIL PROT

Re: [PHP-DEV] short_open_tag

Ilia A. wrote: > Since the general consensus by the developers is not to remove the short_tags > or even disable them. Perhaps we should consider alternate solutions to this > problem. Given the buzzword popularity of XML and its slowly growing > popularity among website designers (XHTML) this

Re: [PHP-DEV] short_open_tag

IMHO, i think that short tags should be taken out of php and just use the Ilia A. wrote: > > Since the general consensus by the developers is not to remove the short_tags > > or even disable them. Perhaps we should consider alternate solutions to this > > problem. Given the buzzword popularity

Re: [PHP-DEV] short_open_tag

On October 16, 2002 10:18 pm, Yasuo Ohgaki wrote: > Ilia A. wrote: > > Since the general consensus by the developers is not to remove the > > short_tags or even disable them. Perhaps we should consider alternate > > solutions to this problem. Given the buzzword popularity of XML and its > > slowly

Re: [PHP-DEV] [PATCH] Changing entity charset handling

Wez Furlong wrote: > Search the archives for the discussion. > phpinfo could determine the charset as your patch does at the start, phpinfo() better not to detect charsets, since user are using it to see variables' values. i.e. Variables may contains different encoding var to var. Applying htmle

Re: [PHP-DEV] Re: Multibyte ([PHP-INST] Re: "If-Modified-Since"..)

Masaki Fujimoto wrote: > nah... > > "If it(==from_encoding) is not specified, the internal encoding will be > used." (http://jp.php.net/manual/en/function.mb-convert-encoding.php) > > so it's just because mbstring.internal_encoding is not properly set? > Thanks for heads up. I made the same mi

Re: [PHP-DEV] short_open_tag

Ilia A. wrote: >>Isn't BIG caution for short_open_tag=Off while having short_open_tag=On >>enough for now? Something like; > > > Nope, please consider a hosting enviroment where an average user does not even > have access to the php.ini file. In fact, most ISP won't make user's life > difficul

Re: [PHP-DEV] short_open_tag

On October 16, 2002 11:11 pm, Yasuo Ohgaki wrote: > Ilia A. wrote: > >>Isn't BIG caution for short_open_tag=Off while having short_open_tag=On > >>enough for now? Something like; > > > > Nope, please consider a hosting enviroment where an average user does not > > even have access to the php.ini f

Re: [PHP-DEV] short_open_tag

We had the same discussion. I brought it up last time. There were patch for "http://www.php.net/manual/en/language.basic-syntax.php Current php.ini-dist has == ; Allow the tags are recognized. short_open_tag = On == Adding appropriate comment is better than adding token to lang

Re: [PHP-DEV] short_open_tag

On October 16, 2002 11:46 pm, Yasuo Ohgaki wrote: > We had the same discussion. I brought it up last time. > > There were patch for " > The outcome was modified manual page that discourages > use of short tag for portable script. > > http://www.php.net/manual/en/language.basic-syntax.php Given th

[PHP-DEV] zip extension fixes (cause it's totally borked :)

attached fixes should enable the zip extension to a) build, b) build as a module want to give me Karma (or patch it in) Regards Alan ? .libs ? Makefile ? Makefile.fragments ? Makefile.global ? Makefile.objects ? acinclude.m4 ? aclocal.m4 ? autom4te.cache ? build ? config.cache ? config.guess

Re: [PHP-DEV] short_open_tag

Ilia A. wrote: >> We should have warned people not to use short tags years ago. > What happened in the past is in the past, lets concentrate on the future. Sure. We should. >>The best way to go is discourage use of short tag >>whenever possible, change default few years later, IMHO. >> >>Even

Re: [PHP-DEV] [PATCH] Changing entity charset handlinginext/standard/html.c

Yep, as far as I read the archives, I haven't found any discussions on the charset related backwards problems. So I wrote "*exactly* about this issue". You may want to redirect me to bug #9392 (http://bugs.php.net/bug.php?id=9392), but it doens't seem to help... In addition, I found determini

Re: [PHP-DEV] [PATCH] Changing entity charset handlinginext/standard/html.c

On 10/17/02, "Moriyoshi Koizumi" <[EMAIL PROTECTED]> wrote: > Yep, as far as I read the archives, I haven't found any discussions on the > charset related backwards problems. So I wrote "*exactly* about this > issue". Search for "htmlentities charset". Both myself and thies (and probably other