On Wed, 16 Oct 2002, Melvyn Sopacua wrote:
At 23:13 15-10-2002, Yasuo Ohgaki wrote:
Another option.
How about remove $_FILES contents from $_REQUEST?
It seems it has less impact.
I don't think Zeev and Derick will be able to go on any trips for a while
then :-)
First 'force'
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 critical
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
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, it
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 from
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;
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
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
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. ?php is more compatable with standards on the web than ? ...
DH and its not about XML document headers.
Yes, the web is rapidly changing, but PHP
[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 way
[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 :)
--
-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 another
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 time
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
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 oci
[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, or
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:
[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 the
[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 Oracle
[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.
Nice idea,
[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 perfectly,
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
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 follows.
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
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 [EMAIL
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
never
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 http://www.php.net/
To
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
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
?php
print
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
Zend
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 List
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,
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
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
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
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
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 it would
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 (rather than a part
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:
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
have been
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
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 hard
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
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
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 enough.
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 done limited
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 not
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
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_encoding(
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
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
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
IMHO, i think that short tags should be taken out of php and just use
the ?php to start the parser.
if a patch is added then the parser just has more to look out for. What
is the XML standard changes to something else. We cannot see what is
coming next.
But if short_open_tags is turned off by
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 growing
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
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 mistake
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
difficult by
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 file. In
We had the same discussion. I brought it up last time.
There were patch for ?xml just like yours.
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
Current php.ini-dist has
==
; Allow the
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 ?xml just like yours.
The outcome was modified manual page that discourages
use of short tag for portable script.
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
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 if we
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
63 matches
Mail list logo
