RE: [PHP-DEV] 4.0.6 BUG with GCC 3.0.1

2001-09-20 Thread Andre Christ

Hi,

  Indeed, binaries (including libs) compiled with gcc 3.x aren't 
 compatible to
  binaries compiled with gcc 2.95. The behaviour you discovered cannot be
  classified a php bug, it is rather a limitation of the new 
 compiler version.
 
 I was under the impression that while your statement is true
 for libraries containing C++ code, the C ABI has not changed.
 Am I wrong?

Well, I'd like to review an article in the latest IX before I can judge
about that ...

Andre


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] 4.0.6 BUG with GCC 3.0.1

2001-09-19 Thread Nael Mohammad



Where can I get the source or binaries for 4.07? I think I've discovered a
bug , but want to make sure with latest build. The bug has to do with Gnu
GCC 3.0.1 libraries. It's incompatible! Trust me it is! And I even tried to
trick PHP by creating a symbolic link referring to the older libraries, no
such luck!

-Nael



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] 4.0.6 BUG with GCC 3.0.1

2001-09-19 Thread Andre Christ

Hi,

 Where can I get the source or binaries for 4.07? I think I've discovered a
 bug , but want to make sure with latest build. The bug has to do with Gnu
 GCC 3.0.1 libraries. It's incompatible! Trust me it is! And I
 even tried to
 trick PHP by creating a symbolic link referring to the older libraries, no
 such luck!

Indeed, binaries (including libs) compiled with gcc 3.x aren't compatible to
binaries compiled with gcc 2.95. The behaviour you discovered cannot be
classified a php bug, it is rather a limitation of the new compiler version.

Greets,
André


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] 4.0.6 BUG with GCC 3.0.1

2001-09-19 Thread Sascha Schumann

On Wed, 19 Sep 2001, Andre Christ wrote:

 Hi,

  Where can I get the source or binaries for 4.07? I think I've discovered a
  bug , but want to make sure with latest build. The bug has to do with Gnu
  GCC 3.0.1 libraries. It's incompatible! Trust me it is! And I
  even tried to
  trick PHP by creating a symbolic link referring to the older libraries, no
  such luck!

 Indeed, binaries (including libs) compiled with gcc 3.x aren't compatible to
 binaries compiled with gcc 2.95. The behaviour you discovered cannot be
 classified a php bug, it is rather a limitation of the new compiler version.

I was under the impression that while your statement is true
for libraries containing C++ code, the C ABI has not changed.
Am I wrong?

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.0.6

2001-06-23 Thread James Moore

Works perfect for me with IIS5/win2k but becareful of which extensions
you use, a lot of extensions are STILL not threadsafe.

- James

 -Original Message-
 From: Phil Driscoll [mailto:[EMAIL PROTECTED]] 
 Sent: 23 June 2001 11:02
 To: Liz; [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: [PHP-QA] Re: [PHP-DEV] 4.0.6
 
 
 On Friday 22 June 2001 19:19, Liz wrote:
  Cool, thanks..
 
  I have a question, has the ISAPI version been stabalised 
 enough that 
  it wont crash works IIS 5 server??  Last time I put it on 
 it screwed 
  it over and my bosses got real mad..  But, I'd rather have it as 
  ISAPI.. but.. I'll have my but kicked if I install it and 
 it wipes out 
  my server.
 
 I can't speak for IIS5 but it is still unusable on my IIS4 box.
 
 Cheers
 -- 
 Phil Driscoll
 
 -- 
 PHP Quality Assurance Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: 
 [EMAIL PROTECTED]
 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-06-22 Thread Phil Driscoll

I've now packaged up the Windows Installer version for 4.0.6 (including crypt 
support) and posted it to
http://www.dialsolutions.com/phil/php/php406-installer.exe

It would be good it a few people could test it before Andi goes public with 
the release. It would be particularly useful to me if anyone who has IIS or 
PWS on NT4 or W2000 could test it as I have changed the bit that configures 
the webserver to avoid an annoying problem with an ocx control that the 
software needs.

Cheers

PS If anyone just needs it for testing the 4.0.6 binary and is afraid that 
the installation wizard might trash their carefully configured system, note 
that the exe is actually in zip format so you can get the bits out manually 
using winzip.
-- 
Phil Driscoll

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] 4.0.6

2001-06-22 Thread Liz

Cool, thanks..

I have a question, has the ISAPI version been stabalised enough that it wont
crash works IIS 5 server??  Last time I put it on it screwed it over and my
bosses got real mad..  But, I'd rather have it as ISAPI.. but.. I'll have my
but kicked if I install it and it wipes out my server.

I used to run it on my portable, but that never had the same problems..


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] 4.0.6 Packaged!

2001-06-21 Thread Andi Gutmans

http://www.php.net/~andi/php-4.0.6.tar.gz

Tomorrow I'll commit it to the phpweb CVS and we'll announce it on Friday.
Please in the meanwhile make sure that no show stoppers have crept in.
Show stoppers == something is completely broken in the core or a terrible 
security hole which needs to be addressed ASAP.
All the rest, little bugglets as found in bugs.php.net will have to wait 
for 4.0.7 which IMO can soon start a release process of its own.
Enjoy,
Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-06-21 Thread Phil Driscoll

On Wednesday 20 June 2001 17:22, Andi Gutmans wrote:

 I suggest in order to get 4.0.6 out of the door I will package it today
 (the release), post it to php-devphp-qa and we can announce it on Friday.

Sounds good. For the last release, in order to synchronise the release of the 
source and the two Windows binary versions, Zeev held off from posting the 
new version to the php.net downloads page until Daniel had brewed up the 
Windows binary zip and I had brewed up the Windows installer.  We emailed the 
stuff to Zeev and then he updated teh web site in one go.

Shall we do that with you this time?

Cheers
-- 
Phil Driscoll

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6 Packaged!

2001-06-21 Thread Rasmus Lerdorf

 http://www.php.net/~andi/php-4.0.6.tar.gz

 Tomorrow I'll commit it to the phpweb CVS and we'll announce it on Friday.
 Please in the meanwhile make sure that no show stoppers have crept in.
 Show stoppers == something is completely broken in the core or a terrible
 security hole which needs to be addressed ASAP.
 All the rest, little bugglets as found in bugs.php.net will have to wait
 for 4.0.7 which IMO can soon start a release process of its own.

I'd like to see Zeev's fix to #11590 in 4.0.6

I just tested it, and it still segfaults.

-Rasmus


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6 Packaged!

2001-06-21 Thread lenar

 I'd like to see Zeev's fix to #11590 in 4.0.6

The same to #11589 .. in my project it's very important.
Ok, it's just my project :( but when i need to hardode
class names instead of just specifinig parent:: - it make's
things more complex than they should be.

lenar.


 I just tested it, and it still segfaults.

 -Rasmus


 --
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]




-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6 Packaged!

2001-06-21 Thread Zeev Suraski

I'd like to see this fix tested a bit more before it gets released.  I 
think that going off with 4.0.6 as it was packaged and starting the 4.0.7 
release process soon afterwards makes the most sense.

Zeev

At 15:54 21/6/2001, Rasmus Lerdorf wrote:
  http://www.php.net/~andi/php-4.0.6.tar.gz
 
  Tomorrow I'll commit it to the phpweb CVS and we'll announce it on Friday.
  Please in the meanwhile make sure that no show stoppers have crept in.
  Show stoppers == something is completely broken in the core or a terrible
  security hole which needs to be addressed ASAP.
  All the rest, little bugglets as found in bugs.php.net will have to wait
  for 4.0.7 which IMO can soon start a release process of its own.

I'd like to see Zeev's fix to #11590 in 4.0.6

I just tested it, and it still segfaults.

-Rasmus


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski [EMAIL PROTECTED]
CTO   co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6 Packaged!

2001-06-21 Thread Andi Gutmans

At 05:54 AM 6/21/2001 -0700, Rasmus Lerdorf wrote:
  http://www.php.net/~andi/php-4.0.6.tar.gz
 
  Tomorrow I'll commit it to the phpweb CVS and we'll announce it on Friday.
  Please in the meanwhile make sure that no show stoppers have crept in.
  Show stoppers == something is completely broken in the core or a terrible
  security hole which needs to be addressed ASAP.
  All the rest, little bugglets as found in bugs.php.net will have to wait
  for 4.0.7 which IMO can soon start a release process of its own.

I'd like to see Zeev's fix to #11590 in 4.0.6

I just tested it, and it still segfaults.

Zeev has fixed it but I think it should only go into 4.0.7-dev. This should 
be branched shortly and hopefully we can aim for another release within a 
month. The NEWS list of 4.0.7 is already very long.
As this bug has been around since 4.0 and we really should get 4.0.6 out I 
suggest releasing it. There will always be problems like this which haven't 
been solved. There are others in bugs.php.net.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-06-21 Thread Andi Gutmans

At 09:03 AM 6/21/2001 +0100, Phil Driscoll wrote:
On Wednesday 20 June 2001 17:22, Andi Gutmans wrote:

  I suggest in order to get 4.0.6 out of the door I will package it today
  (the release), post it to php-devphp-qa and we can announce it on Friday.

Sounds good. For the last release, in order to synchronise the release of the
source and the two Windows binary versions, Zeev held off from posting the
new version to the php.net downloads page until Daniel had brewed up the
Windows binary zip and I had brewed up the Windows installer.  We emailed the
stuff to Zeev and then he updated teh web site in one go.

Shall we do that with you this time?

Last time we did release the sources a few hours before. I don't think 
there's any harm to it but if you guys can get it ready by tomorrow then we 
can put them up together.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6 Packaged!

2001-06-21 Thread Sergio Bruder

On Thu, Jun 21, 2001 at 10:04:45AM +0300, Andi Gutmans wrote:
 http://www.php.net/~andi/php-4.0.6.tar.gz
 
 Tomorrow I'll commit it to the phpweb CVS and we'll announce it on Friday.
 Please in the meanwhile make sure that no show stoppers have crept in.
 Show stoppers == something is completely broken in the core or a terrible 
 security hole which needs to be addressed ASAP.
 All the rest, little bugglets as found in bugs.php.net will have to wait 
 for 4.0.7 which IMO can soon start a release process of its own.
 Enjoy,
 Andi

Compiled under Conectiva Linux Snapshot version (soon-to-be 7.0), cgi
and module version, dinamic modules for imap, ldap, mysql, pgsql,
odbc. binaries RPM's and .src.rpm in snapshot mirrors tomorrow.
(http://snapshot.conectiva.com for more details)

configure used:

./configure \
»···--prefix=%{_prefix} \
»···--disable-debug \
»···--enable-pic \
»···--enable-inline-optimization \
»···--with-exec-dir=%{_bindir} \
»···--with-regex=system \
»···--with-gettext \
»···--with-freetype-dir=%{_prefix} \
»···--with-gd \
»···--with-jpeg-dir=%{_prefix} \
»···--with-png \
»···--with-zlib \
»···--with-db2 \
»···--with-db3 \
»···--with-gdbm \
»···--enable-debugger \
»···--enable-openssl \
»···--enable-magic-quotes \
»···--enable-safe-mode \
»···--enable-sockets \
»···--enable-sysvsem \
»···--enable-sysvshm \
»···--enable-track-vars \
»···--enable-yp \
»···--enable-wddx \
»···--enable-snmp \
»···--enable-dbf \
»···--enable-ftp \
»···--enable-mcrypt \
»···--enable-bcmath \
»···--without-mysql \
»···--without-unixODBC \
»···--with-xml

Sergio Bruder

-- 
 (  
 )) (tm)http://sergio.bruder.net
||-.  http://pontobr.org
|__|-'  [EMAIL PROTECTED], [EMAIL PROTECTED]
we are concerned about the GNU General Public License (GPL)
-- Microsoft press release
--
pub  1024D/0C7D9F49 2000-05-26 Sergio Devojno Bruder [EMAIL PROTECTED]
 Key fingerprint = 983F DBDF FB53 FE55 87DF  71CA 6B01 5E44 0C7D 9F49
sub  1024g/138DF93D 2000-05-26

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6 - ?

2001-06-20 Thread Cynic

RC6 just went out, so I guess if it's the last RC, it could be
approx. time() + 604800. right?

At 21:53 19.6. 2001, Andrei Zmievski wrote the following:
-- 
When are we releasing 4.0.6? I'm asking more as an end user because it
has a few bug fixes that affect our products.

-Andrei
* Power corrupts. Atomic power corrupts atomically. *

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--end of quote-- 


[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6 - ?

2001-06-20 Thread Andi Gutmans

Hopefully ASAP. We should release RC4 unless people find *serious* problems.

Andi

At 02:53 PM 6/19/2001 -0500, Andrei Zmievski wrote:
When are we releasing 4.0.6? I'm asking more as an end user because it
has a few bug fixes that affect our products.

-Andrei
* Power corrupts. Atomic power corrupts atomically. *

--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6 RC3 ./configure

2001-06-20 Thread Cynic

uh, disregard that message. that was pure insanity.



[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6 - ?

2001-06-20 Thread Dan Kalowsky

Andrei Zmievski wrote:
 
 When are we releasing 4.0.6? I'm asking more as an end user because it
 has a few bug fixes that affect our products.
 

As soon as we stop putting in bug fixes to the RCs!  

-- 
Dan Kalowsky  Tonight I think I'll walk alone, 
Worldgate Communications   I'll find my soul as I go home.
Software Engineer - TICS Group  - Temptation

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] 4.0.6

2001-06-20 Thread Andi Gutmans

Hey,

I suggest in order to get 4.0.6 out of the door I will package it today 
(the release), post it to php-devphp-qa and we can announce it on Friday.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] 4.0.6 - ?

2001-06-19 Thread Andrei Zmievski

When are we releasing 4.0.6? I'm asking more as an end user because it
has a few bug fixes that affect our products.

-Andrei
* Power corrupts. Atomic power corrupts atomically. *

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-08 Thread Dave Jones

it is not that odd because it may have treated it like whitespace - imagine
a long line script. now it may treat it not as whitespace and hence the
problem

there is no big difference between whitespace and newline(s) in php, is it?

Both today (4.0.6-dev) and earlier \r is treated as whitespace.
However, in previous versions including 4.0.5 and 4.0.4pl1 \r would not 
mark line endings such as end of // or # comments.
So there is no way that I can think of that a script would have worked with 
4.0.4pl1 and not with 4.0.5.
Anyway, it doesn't really matter now because 4.0.6 should work.

And also line number don't get incremented if there are no line ends, so
all syntax errors are reported as being on line 1.

The issue might have never come up if the code used r mode for opens
rather that rb, since the file are 'text' files.  On platforms that
don't used embedded newline characters as the record delimiters, the
implementation of fread is responsible for mapping the underlying file
format to cannonical form (i.e. \n's delimiting lines).

---
And also line number don't get incremented if there are no line ends, so
all syntax errors are reported as being on line 1.

The issue might have never come up if the code used r mode for opens
rather that rb, since the file are 'text' files.  On platforms that
don't used embedded newline characters as the record delimiters, the
implementation of fread is responsible for mapping the underlying file
format to cannonical form (i.e. \n's delimiting lines).

---
David L. Jones   |  Phone:(614) 292-6929
Ohio State Unviversity   |  Internet:
1971 Neil Ave. Rm. 406   |   [EMAIL PROTECTED]
Columbus, OH 43210   |   [EMAIL PROTECTED]

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Fw: [PHP-DEV] 4.0.6

2001-05-08 Thread Boian Bonev


- Original Message -
From: Boian Bonev [EMAIL PROTECTED]
To: Dave Jones [EMAIL PROTECTED]
Sent: Tuesday, May 08, 2001 6:29 PM
Subject: Re: [PHP-DEV] 4.0.6


 hi,

  And also line number don't get incremented if there are no line ends, so
  all syntax errors are reported as being on line 1.
  The issue might have never come up if the code used r mode for opens
  rather that rb, since the file are 'text' files.  On platforms that
  don't used embedded newline characters as the record delimiters, the
  implementation of fread is responsible for mapping the underlying file
  format to cannonical form (i.e. \n's delimiting lines).

 you are partially correct - if we have only 'native' files - yes this is
the
 case. but imagine tons of downloaded code, parts of it originating from
*nix
 others from windows, and parts of them edited so all the three possible
 combinations are used. perhapse you know that most editors convert line
 endings only for edited lines not for the whole file. now the task of
 correctly counting line numbers is not that easy. neighter file conversion
 is. of course some editors pretend to be that clever to interprete all the
 three formats - something like greedy eating \n\r|\n|\r in this order...

 b.


forgot to say that php must flawlessly interprete all the combinations
provided that it is a platform independant language and never rely on os
specific stuff - win php source must work on unix as unix php source on
windows...



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-08 Thread Andi Gutmans

There is a problem with line numbers if you use \r as line endings. I 
will try and fix it before 4.0.6 (although after my last patch functionally 
\r's will work which is the most important thing).

Andi

At 08:50 AM 5/8/2001 -0400, Dave Jones wrote:
it is not that odd because it may have treated it like whitespace - imagine
a long line script. now it may treat it not as whitespace and hence the
problem

there is no big difference between whitespace and newline(s) in php, is it?

Both today (4.0.6-dev) and earlier \r is treated as whitespace.
However, in previous versions including 4.0.5 and 4.0.4pl1 \r would not 
mark line endings such as end of // or # comments.
So there is no way that I can think of that a script would have worked 
with 4.0.4pl1 and not with 4.0.5.
Anyway, it doesn't really matter now because 4.0.6 should work.

And also line number don't get incremented if there are no line ends, so
all syntax errors are reported as being on line 1.

The issue might have never come up if the code used r mode for opens
rather that rb, since the file are 'text' files.  On platforms that
don't used embedded newline characters as the record delimiters, the
implementation of fread is responsible for mapping the underlying file
format to cannonical form (i.e. \n's delimiting lines).

---
And also line number don't get incremented if there are no line ends, so
all syntax errors are reported as being on line 1.

The issue might have never come up if the code used r mode for opens
rather that rb, since the file are 'text' files.  On platforms that
don't used embedded newline characters as the record delimiters, the
implementation of fread is responsible for mapping the underlying file
format to cannonical form (i.e. \n's delimiting lines).

---
David L. Jones   |  Phone:(614) 292-6929
Ohio State Unviversity   |  Internet:
1971 Neil Ave. Rm. 406   |   [EMAIL PROTECTED]
Columbus, OH 43210   |   [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: Fw: [PHP-DEV] 4.0.6

2001-05-08 Thread Andi Gutmans

At 06:32 PM 5/8/2001 +0300, Boian Bonev wrote:

- Original Message -
From: Boian Bonev [EMAIL PROTECTED]
To: Dave Jones [EMAIL PROTECTED]
Sent: Tuesday, May 08, 2001 6:29 PM
Subject: Re: [PHP-DEV] 4.0.6


  hi,
 
   And also line number don't get incremented if there are no line ends, so
   all syntax errors are reported as being on line 1.
   The issue might have never come up if the code used r mode for opens
   rather that rb, since the file are 'text' files.  On platforms that
   don't used embedded newline characters as the record delimiters, the
   implementation of fread is responsible for mapping the underlying file
   format to cannonical form (i.e. \n's delimiting lines).
 
  you are partially correct - if we have only 'native' files - yes this is
the
  case. but imagine tons of downloaded code, parts of it originating from
*nix
  others from windows, and parts of them edited so all the three possible
  combinations are used. perhapse you know that most editors convert line
  endings only for edited lines not for the whole file. now the task of
  correctly counting line numbers is not that easy. neighter file conversion
  is. of course some editors pretend to be that clever to interprete all the
  three formats - something like greedy eating \n\r|\n|\r in this order...
 
  b.
 

forgot to say that php must flawlessly interprete all the combinations
provided that it is a platform independant language and never rely on os
specific stuff - win php source must work on unix as unix php source on
windows...

I think it should interprete \r\n, \n and \r (which isn't followed by 
a \n) as newlines.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-08 Thread Andi Gutmans

Can you please check the latest CVS and let me know if the line numbers are 
OK now? (when using \r as an end of line).
Thanks,

Andi

At 08:55 PM 5/8/2001 +0300, Andi Gutmans wrote:
There is a problem with line numbers if you use \r as line endings. I 
will try and fix it before 4.0.6 (although after my last patch 
functionally \r's will work which is the most important thing).

Andi

At 08:50 AM 5/8/2001 -0400, Dave Jones wrote:
it is not that odd because it may have treated it like whitespace - imagine
a long line script. now it may treat it not as whitespace and hence the
problem

there is no big difference between whitespace and newline(s) in php, is it?

Both today (4.0.6-dev) and earlier \r is treated as whitespace.
However, in previous versions including 4.0.5 and 4.0.4pl1 \r would 
not mark line endings such as end of // or # comments.
So there is no way that I can think of that a script would have worked 
with 4.0.4pl1 and not with 4.0.5.
Anyway, it doesn't really matter now because 4.0.6 should work.

And also line number don't get incremented if there are no line ends, so
all syntax errors are reported as being on line 1.

The issue might have never come up if the code used r mode for opens
rather that rb, since the file are 'text' files.  On platforms that
don't used embedded newline characters as the record delimiters, the
implementation of fread is responsible for mapping the underlying file
format to cannonical form (i.e. \n's delimiting lines).

---
And also line number don't get incremented if there are no line ends, so
all syntax errors are reported as being on line 1.

The issue might have never come up if the code used r mode for opens
rather that rb, since the file are 'text' files.  On platforms that
don't used embedded newline characters as the record delimiters, the
implementation of fread is responsible for mapping the underlying file
format to cannonical form (i.e. \n's delimiting lines).

---
David L. Jones   |  Phone:(614) 292-6929
Ohio State Unviversity   |  Internet:
1971 Neil Ave. Rm. 406   |   [EMAIL PROTECTED]
Columbus, OH 43210   |   [EMAIL PROTECTED]


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-07 Thread Boian Bonev

 Note that there was no such problem with PHP 4.0.4pl1 and earlier.
 That's very odd, as PHP never considered \r alone to be a linefeed...

it is not that odd because it may have treated it like whitespace - imagine
a long line script. now it may treat it not as whitespace and hence the
problem

there is no big difference between whitespace and newline(s) in php, is it?

b.


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-07 Thread Andi Gutmans

At 06:59 AM 5/8/2001 +0300, Boian Bonev wrote:
  Note that there was no such problem with PHP 4.0.4pl1 and earlier.
  That's very odd, as PHP never considered \r alone to be a linefeed...

it is not that odd because it may have treated it like whitespace - imagine
a long line script. now it may treat it not as whitespace and hence the
problem

there is no big difference between whitespace and newline(s) in php, is it?

Both today (4.0.6-dev) and earlier \r is treated as whitespace.
However, in previous versions including 4.0.5 and 4.0.4pl1 \r would not 
mark line endings such as end of // or # comments.
So there is no way that I can think of that a script would have worked with 
4.0.4pl1 and not with 4.0.5.
Anyway, it doesn't really matter now because 4.0.6 should work.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-03 Thread Jo Giraerts

On Wed, May 02, 2001 at 11:14:38PM +0300, Zeev Suraski wrote:
 At 23:06 2/5/2001, Troels Arvin wrote:
 Note that there was no such problem with PHP 4.0.4pl1 and earlier.
 
 
 That's very odd, as PHP never considered \r alone to be a linefeed...

IIRC, Mac's use \r as an end-of-line. They don't know of \n as do pc's.


-- 
Jo Giraerts
Development Services Engineer
VA Linux Professional Services Europe
Interleuvenlaan 15A, 3001 LEUVEN, BELGIUM
icq:81939849, email:[EMAIL PROTECTED], ph0ne:+32(0)475/437719 

I've got these opium queens that move around my space, 
I said it's waste not, want not, 
I think I'll take another, 
I'm holding all this pain that I'm trying to smother.
branvan3000 - 
Afrodisiac

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-03 Thread Andi Gutmans

I've already commited a fix to the CVS which allows \r \n and \r\n.

Andi

At 07:42 AM 5/3/2001 -0700, Ron Chmara wrote:
Andi Gutmans wrote:
  The problem occurs when a web-developer using a Mac editor edits PHP
  code: If he writes PHP code and his editor uses \r as linefeeds in the
  PHP code, then the strange phenomenon may arise.
 
  The editor only puts \r without \r\n? Wow, I've never seen a system that
  does that :) Were all Mac's like that?

It gets weirder on OS X (yes, I have one OS X box running...). It uses \r\n
*and* \n.

Macs have been that way since '84 or so.

  Anyway, I don't know why you think that worked in 4.0.4

There have been various bugs with it since 3.0.X. Specifically, things
like multi-line SQL statements, the Error/Warning line numbers reported,
etc.

  OK, seriously. This code has not been changed in between 4.0.4 and 4.0.5.
  Are you sure you weren't using a different editor?
  Isn't there a way for you to save as \n or \r\n?

Usually, there's a unix line feed option... but just something to
think about:
Mac OS X is expected to have 5-10 million new users adopting in the
next year.
*Every single one* of those users is getting a box with Apache+PHP
pre-installed (tho not entirely configured.)

That's a lot of fix your linefeed bug responses

-Bop


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-03 Thread Ron Chmara

Andi Gutmans wrote:
 I've already commited a fix to the CVS which allows \r \n and \r\n.
 It gets weirder on OS X (yes, I have one OS X box running...). It uses \r\n
 *and* \n.

Sorry 'bout that, I'm reading email remotely (I'm in D.C., right across from
the chinese embassy), and I'm running a bit behind right now... noticed
the patch a few messages later.
(only 1107 messages to go...)

-Ronabop

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] 4.0.6

2001-05-02 Thread Andi Gutmans

Hi,

I think we should make a list of known 4.0.5 bugs which need to be fixed 
for 4.0.6 and once we fix them branch 4.0.6. I think there have been enough 
changes to warrant a 4.0.6 release soon.
My list of bugs (please add to this):
- COM support is completely broken (bug #10594)
- libtool detection in ./configure seems to be kind of broken (bug #10589). 
Patch posted to php-dev

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-02 Thread Troels Arvin

On Wed, 02 May 2001 13:52:58 +0200, Andi Gutmans [EMAIL PROTECTED] wrote:

 I think we should make a list of known 4.0.5 bugs which need to be
 fixed for 4.0.6

I think that bug #10578 is a very serious problem which should be looked
at before thinking about releasing 4.0.6.

By the way:
The problem _could_ be related to bug #10609.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-02 Thread Andi Gutmans

At 09:02 PM 5/2/2001 +0200, Troels Arvin wrote:
On Wed, 02 May 2001 13:52:58 +0200, Andi Gutmans [EMAIL PROTECTED] wrote:

  I think we should make a list of known 4.0.5 bugs which need to be
  fixed for 4.0.6

I think that bug #10578 is a very serious problem which should be looked
at before thinking about releasing 4.0.6.

Do you have any idea what it could be? I don't have access to Mac OS X. 
What is the line delimiter on Mac OS X? \r\n?
Do you have an extremely short reproducing script?


By the way:
The problem _could_ be related to bug #10609.

I asked him for reproducing scripts.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-02 Thread Andi Gutmans

At 10:06 PM 5/2/2001 +0200, Troels Arvin wrote:
On Wed, 02 May 2001 21:58:03 +0200, Andi Gutmans [EMAIL PROTECTED] wrote:
 I think that bug #10578 is a very serious problem which should be
 looked at before thinking about releasing 4.0.6.
 
  Do you have any idea what it could be? I don't have access to
  Mac OS X.

It's not related to Mac OS X; PHP is executed on a Linux host.

The problem occurs when a web-developer using a Mac editor edits PHP
code: If he writes PHP code and his editor uses \r as linefeeds in the
PHP code, then the strange phenomenon may arise.

The editor only puts \r without \r\n? Wow, I've never seen a system that 
does that :) Were all Mac's like that?
Anyway, I don't know why you think that worked in 4.0.4 because having 
written a big part of the Zend scanner I can assure you it was only 
designed to handle \n or \r\n :) Maybe you got lucky. Anyway please 
clarify the status.


  Do you have an extremely short reproducing script?
It's best demonstrated by going to http://schmidt.tv2.dk/public/linefeedbug/

Note that there was no such problem with PHP 4.0.4pl1 and earlier.

OK, seriously. This code has not been changed in between 4.0.4 and 4.0.5. 
Are you sure you weren't using a different editor?
Isn't there a way for you to save as \n or \r\n?

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-02 Thread Zeev Suraski

At 23:06 2/5/2001, Troels Arvin wrote:
Note that there was no such problem with PHP 4.0.4pl1 and earlier.


That's very odd, as PHP never considered \r alone to be a linefeed...

Zeev


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-02 Thread PHP development @echospace

 The editor only puts \r without \r\n? Wow, I've never seen a system
 that  does that :) Were all Mac's like that?
I did. Several times. Unfortunately. 


 Are you sure you weren't using a different editor?
 Isn't there a way for you to save as \n or \r\n?
And, though you probably can save with \r\n instead, I'd rather
see php handle \r properly. Does that sound feasible? 


Vlad


Re-thinking the Web on a SinglePage(TM)
http://www.echospace.com


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-02 Thread Andi Gutmans

At 01:45 PM 5/2/2001 -0700, PHP development @echospace wrote:
  The editor only puts \r without \r\n? Wow, I've never seen a system
  that  does that :) Were all Mac's like that?
I did. Several times. Unfortunately.


  Are you sure you weren't using a different editor?
  Isn't there a way for you to save as \n or \r\n?
And, though you probably can save with \r\n instead, I'd rather
see php handle \r properly. Does that sound feasible?

We can make the Zend scanner handle it but the rest of PHP  Zend still 
have \n in certain places.
If I commit a patch do you know how to check out and test the CVS tree?

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-02 Thread PHP development @echospace

 
I don't have a mac around anymore, sorry. Maybe the original poster
could - who was that again by the way? I deleted his message:(

Vlad




- Original Message -
From: Andi Gutmans 
To: PHP development @echospace ,[EMAIL PROTECTED]
Sent: Wed, 02 May 2001 23:50:26 +0300
Subject: Re: [PHP-DEV] 4.0.6

At 01:45 PM 5/2/2001 -0700, PHP development @echospace wrote:
  The editor only puts \r without \r\n? Wow, I've never seen a system
  that does that :) Were all Mac's like that?
I did. Several times. Unfortunately.


  Are you sure you weren't using a different editor?
  Isn't there a way for you to save as \n or \r\n?
And, though you probably can save with \r\n instead, I'd rather
see php handle \r properly. Does that sound feasible?

We can make the Zend scanner handle it but the rest of PHP  Zend still 
have \n in certain places.
If I commit a patch do you know how to check out and test the CVS tree?

Andi


Re-thinking the Web on a SinglePage(TM)
http://www.echospace.com


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-05-02 Thread Felix Kronlage

On Wed, May 02, 2001 at 10:06:10PM +0200, Troels Arvin wrote:

 The problem occurs when a web-developer using a Mac editor edits PHP
 code: If he writes PHP code and his editor uses \r as linefeeds in the
 PHP code, then the strange phenomenon may arise.

Don't know wether you have already done that or not...but take a look
at the file with the php-code with a hexeditor. 
Once on the mac and once after it has been put on the linux-host.
Is there seriously just a \r as a linefeed? (how does output of cat 'file-with-phpcode'
look like?)

These are just a few guesses, we had some serious problems with other things and
linefeeds (in a heterogenous env.).

-fkr
-- 
gpg-fingerprint: 076E 1E87 3E05 1C7F B1A0  8A48 0D31 9BD3 D9AC 74D0 
  |http://www.hazardous.org/ | whois -h whois.ripe.de FKR-RIPE  |
  |all your base are belong to us  |  shame on me  | fkr@IRCnet | 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Rui Hirokawa


Andi,

We have plan to add ext/jstring which is a japanese string extension module
to php-4.0.6.
Is there any problem to add this module on CVS tree now ?

On Sun, 29 Apr 2001 22:35:43 +0200
Andi Gutmans [EMAIL PROTECTED] wrote:

 Guys,
 
 I think that despite the release of 4.0.5 tomorrow we are pretty close to 
 having an RC1 for 4.0.6. Lots of things have been fixed/added since 4.0.5 
 (check the NEWS file).
 Can we make a list of things which still need to make it into 4.0.6 before 
 we branch?
 
 Andi

-- 
--
Rui Hirokawa [EMAIL PROTECTED]
maintainer of japanese PHP manual [EMAIL PROTECTED]

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Rui Hirokawa


On Mon, 30 Apr 2001 15:37:14 +0300
Andi Gutmans [EMAIL PROTECTED] wrote:

 At 09:35 PM 4/30/2001 +0900, Rui Hirokawa wrote:
 
 Andi,
 
 We have plan to add ext/jstring which is a japanese string extension module
 to php-4.0.6.
 Is there any problem to add this module on CVS tree now ?
 
 No I don't see a problem with this but please do it quickly. 4.0.6 has 
 already gone a long way since we started RC'ing 4.0.5 and I would like to 
 start RC'ing it pretty soon. You should probably also copy 
 dotnet/EXPERIMENTAL to your directory until it becomes completely stable.

I did.

 
 By the way, do you think jstring is the right name? Is it only for Japanese?

It includes some functions for japanese,but some functions are not 
only for japanese.
For example, this module supports encoding conversion functionality between
Unicode and some other encodings like ISO-8859-X.
Currently, it includes encoding conversion filter for japanese and ISO-8859-X,
but it is relatively easy task to add another conversion filter for some other
language.

I believe this module is small step for PHP internationalization.
I think the name 'jstring' is right name now because it is existing
for japanese string function now.
But  'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name.

-- 
--
Rui Hirokawa [EMAIL PROTECTED]
maintainer of japanese PHP manual [EMAIL PROTECTED]

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Stanislav Malyshev

RH For example, this module supports encoding conversion
RH functionality between Unicode and some other encodings like
RH ISO-8859-X. Currently, it includes encoding conversion filter

Doesn't this duplicate the GNU recode functionality?


-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Andi Gutmans

At 10:47 PM 4/30/2001 +0900, Rui Hirokawa wrote:
  No I don't see a problem with this but please do it quickly. 4.0.6 has
  already gone a long way since we started RC'ing 4.0.5 and I would like to
  start RC'ing it pretty soon. You should probably also copy
  dotnet/EXPERIMENTAL to your directory until it becomes completely stable.

I did.

 
  By the way, do you think jstring is the right name? Is it only for 
 Japanese?

It includes some functions for japanese,but some functions are not
only for japanese.
For example, this module supports encoding conversion functionality between
Unicode and some other encodings like ISO-8859-X.
Currently, it includes encoding conversion filter for japanese and ISO-8859-X,
but it is relatively easy task to add another conversion filter for some other
language.

I believe this module is small step for PHP internationalization.
I think the name 'jstring' is right name now because it is existing
for japanese string function now.
But  'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name.

jstring sounds very Java'ish :)
I think a more descriptive name would be better especially if it is not 
Japanese specific.
Let's wait and see what other people think.
I'm very happy to see this code being merged into PHP 4. Many Japanese 
users have missed out on PHP 4 because these patches were mostly available 
for PHP 3.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Cynic

recode is GPL'd IIRC and thus (your mileage may vary) not very 
usable, doesn't build on win32 systems, and the author has 
no interest in changing that.

At 15:51 30.4. 2001, Stanislav Malyshev wrote the following:
-- 
RH For example, this module supports encoding conversion
RH functionality between Unicode and some other encodings like
RH ISO-8859-X. Currently, it includes encoding conversion filter

Doesn't this duplicate the GNU recode functionality?


-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--end of quote-- 


[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Rui Hirokawa



On Mon, 30 Apr 2001 16:51:15 +0300 (IDT)
Stanislav Malyshev [EMAIL PROTECTED] wrote:

 RH For example, this module supports encoding conversion
 RH functionality between Unicode and some other encodings like
 RH ISO-8859-X. Currently, it includes encoding conversion filter
 
 Doesn't this duplicate the GNU recode functionality?


ext/jstring adds some unique functionalities as follows,

- automatic encoding recognition functionality for japanese and Unicode   encodings.
- the output encoding translation using output buffering functionality.
- adding encoding translation for HTTP input (POST/GET/Cookie).
- adding multibyte compatible string functions like mbstrlen (multibyte enabled 
strlen())

These functionalities are not fully supported by ext/recode or ext/iconv.


 
 
 -- 
 Stanislav Malyshev, Zend Products Engineer
 [EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115
 
 
 
 -- 
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]
 


-- 
--
Rui Hirokawa [EMAIL PROTECTED]
maintainer of japanese PHP manual [EMAIL PROTECTED]

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Sterling Hughes

On Mon, 30 Apr 2001, Rui Hirokawa wrote:



 On Mon, 30 Apr 2001 16:51:15 +0300 (IDT)
 Stanislav Malyshev [EMAIL PROTECTED] wrote:

  RH For example, this module supports encoding conversion
  RH functionality between Unicode and some other encodings like
  RH ISO-8859-X. Currently, it includes encoding conversion filter
 
  Doesn't this duplicate the GNU recode functionality?


 ext/jstring adds some unique functionalities as follows,

 - automatic encoding recognition functionality for japanese and Unicode   encodings.
 - the output encoding translation using output buffering functionality.
 - adding encoding translation for HTTP input (POST/GET/Cookie).
 - adding multibyte compatible string functions like mbstrlen (multibyte enabled 
strlen())

 These functionalities are not fully supported by ext/recode or ext/iconv.


This seems like a very cool thing, however, I agree with Andi and others,
jstring sounds very Java like to me also.

perhaps:

ext/wchar (wide character support?)
ext/mstring (multibyte string functions)
ext/jpstring (japanese string functions)

-Sterling


 
 
  --
  Stanislav Malyshev, Zend Products Engineer
  [EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115
 
 
 
  --
  PHP Development Mailing List http://www.php.net/
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  To contact the list administrators, e-mail: [EMAIL PROTECTED]
 





-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Stanislav Malyshev

C recode is GPL'd IIRC and thus (your mileage may vary) not very
C usable, doesn't build on win32 systems, and the author has no

recode libs are LGPL, IIRC. As for win32, I don't know (not being user of
such systems) but I guess since its functionality do not include anything
that is unix-specific, it should build with little modification.
-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Andi Gutmans

At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote:
ext/wchar (wide character support?)
ext/mstring (multibyte string functions)
ext/jpstring (japanese string functions)

I'd make mstring - mbstring.
The question is if it's worth splitting this up into more than one 
extension. Probably not.
So we should probably be picking out of wchar, mbstring, jpstring.
Rui, what do you think?
Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Stig Sæther Bakken

[Cynic [EMAIL PROTECTED]]
 recode is GPL'd IIRC and thus (your mileage may vary) not very 
 usable, doesn't build on win32 systems, and the author has 
 no interest in changing that.

libiconv is pretty good too.  I don't know if it builds on Win32
though.

 - Stig

-- 
  Stig Sæther Bakken [EMAIL PROTECTED]
  Fast Search  Transfer ASA, Trondheim, Norway

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Sterling Hughes

On 30 Apr 2001, Stig Sæther Bakken wrote:

 [Cynic [EMAIL PROTECTED]]
  recode is GPL'd IIRC and thus (your mileage may vary) not very
  usable, doesn't build on win32 systems, and the author has
  no interest in changing that.

 libiconv is pretty good too.  I don't know if it builds on Win32
 though.


It does.

-sterling


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Colin Viebrock

 I'd make mstring - mbstring.
 The question is if it's worth splitting this up into more than one
 extension. Probably not.
 So we should probably be picking out of wchar, mbstring, jpstring.
 Rui, what do you think?

I'm not Rui, but my vote would be for mbstring (or mb_string).  If this
handles any multi-byte character strings and Unicode, then it's going to be
used for a lot more than Japanese strings.

Hopefully, this will save me from porting String::Unicode into PHP. :)

- Colin


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Rui Hirokawa


On Mon, 30 Apr 2001 17:26:58 +0300
Andi Gutmans [EMAIL PROTECTED] wrote:

 At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote:
 ext/wchar (wide character support?)
 ext/mstring (multibyte string functions)
 ext/jpstring (japanese string functions)
 
 I'd make mstring - mbstring.
 The question is if it's worth splitting this up into more than one 
 extension. Probably not.
 So we should probably be picking out of wchar, mbstring, jpstring.
 Rui, what do you think?

I prefer unified approach is better for php-i18n than splitting 
some modules.
I think mbstring is better, although this module also 
supports single-byte encoding like ISO-8859-X.
Some people might say 'wchar' is better choise,
because this module converts string to wide character internally.

If someone want to add some other encoding support,
he should add mbfilter_xx.c mbfilter_xx.h where xx means some
specific language like ja (japanese).

Anyway, because I am not original author of this module,
I must discuss to Mr. Tsukada ,the original author of jstring
about renaming the module.

-- 
--
Rui Hirokawa [EMAIL PROTECTED]
maintainer of japanese PHP manual [EMAIL PROTECTED]

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Andi Gutmans

At 12:23 AM 5/1/2001 +0900, Rui Hirokawa wrote:

On Mon, 30 Apr 2001 17:26:58 +0300
Andi Gutmans [EMAIL PROTECTED] wrote:

  At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote:
  ext/wchar (wide character support?)
  ext/mstring (multibyte string functions)
  ext/jpstring (japanese string functions)
 
  I'd make mstring - mbstring.
  The question is if it's worth splitting this up into more than one
  extension. Probably not.
  So we should probably be picking out of wchar, mbstring, jpstring.
  Rui, what do you think?

I prefer unified approach is better for php-i18n than splitting
some modules.
I think mbstring is better, although this module also
supports single-byte encoding like ISO-8859-X.
Some people might say 'wchar' is better choise,
because this module converts string to wide character internally.

If someone want to add some other encoding support,
he should add mbfilter_xx.c mbfilter_xx.h where xx means some
specific language like ja (japanese).

Anyway, because I am not original author of this module,
I must discuss to Mr. Tsukada ,the original author of jstring
about renaming the module.

OK. I think wchar or mbstring are both good. jstring will just confuse people.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Hartmut Holzgraefe

Cynic wrote:
 recode is GPL'd IIRC and thus (your mileage may vary) not very
 usable, doesn't build on win32 systems, and the author has
 no interest in changing that.

the recode command is under GPL while the library part is under LGPL
so it's ok as it is license-wise

(even RMS did not take the bait on it during the readline discussion)


-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Hartmut Holzgraefe

Andi Gutmans wrote:
 Can we make a list of things which still need to make it into 4.0.6 
 before we branch?

i have started to create ext/saprfc that will interface with the ABAP/4
Remote Function Call mechanism in SAP R/3, 
but right now it only has a working configure script and no
functionality
within (making it even more useless than ext/rtfm for now)
so i'll wait until 4.0.6 branches off before i add it ...

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Alexander Bokovoy

On Mon, Apr 30, 2001 at 10:47:21PM +0900, Rui Hirokawa wrote:
 
 On Mon, 30 Apr 2001 15:37:14 +0300
 Andi Gutmans [EMAIL PROTECTED] wrote:
 
  At 09:35 PM 4/30/2001 +0900, Rui Hirokawa wrote:
  
  Andi,
  
  We have plan to add ext/jstring which is a japanese string extension module
  to php-4.0.6.
  Is there any problem to add this module on CVS tree now ?
  
  No I don't see a problem with this but please do it quickly. 4.0.6 has 
  already gone a long way since we started RC'ing 4.0.5 and I would like to 
  start RC'ing it pretty soon. You should probably also copy 
  dotnet/EXPERIMENTAL to your directory until it becomes completely stable.
 
 I did.
 
  
  By the way, do you think jstring is the right name? Is it only for Japanese?
 
 It includes some functions for japanese,but some functions are not 
 only for japanese.
 For example, this module supports encoding conversion functionality between
 Unicode and some other encodings like ISO-8859-X.
 Currently, it includes encoding conversion filter for japanese and ISO-8859-X,
 but it is relatively easy task to add another conversion filter for some other
 language.
 
 I believe this module is small step for PHP internationalization.
 I think the name 'jstring' is right name now because it is existing
 for japanese string function now.
 But  'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name.
It would be very good to join this features with existing iconv extension
rather than generate new extensions.
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread tsukada


On Mon, 30 Apr 2001 18:27:26 +0300
Andi Gutmans wrote:

 At 12:23 AM 5/1/2001 +0900, Rui Hirokawa wrote:
 
 On Mon, 30 Apr 2001 17:26:58 +0300
 Andi Gutmans [EMAIL PROTECTED] wrote:
 
   At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote:
   ext/wchar (wide character support?)
   ext/mstring (multibyte string functions)
   ext/jpstring (japanese string functions)
  
   I'd make mstring - mbstring.
   The question is if it's worth splitting this up into more than one
   extension. Probably not.
   So we should probably be picking out of wchar, mbstring, jpstring.
   Rui, what do you think?
 
 I prefer unified approach is better for php-i18n than splitting
 some modules.
 I think mbstring is better, although this module also
 supports single-byte encoding like ISO-8859-X.
 Some people might say 'wchar' is better choise,
 because this module converts string to wide character internally.
 
 If someone want to add some other encoding support,
 he should add mbfilter_xx.c mbfilter_xx.h where xx means some
 specific language like ja (japanese).
 
 Anyway, because I am not original author of this module,
 I must discuss to Mr. Tsukada ,the original author of jstring
 about renaming the module.
 
 OK. I think wchar or mbstring are both good. jstring will just confuse people.
 

I think mbstring is nice.

 Takuya Tsukada



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Andi Gutmans

At 05:56 AM 5/1/2001 +0900, [EMAIL PROTECTED] wrote:

On Mon, 30 Apr 2001 18:27:26 +0300
Andi Gutmans wrote:

  At 12:23 AM 5/1/2001 +0900, Rui Hirokawa wrote:
 
  On Mon, 30 Apr 2001 17:26:58 +0300
  Andi Gutmans [EMAIL PROTECTED] wrote:
  
At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote:
ext/wchar (wide character support?)
ext/mstring (multibyte string functions)
ext/jpstring (japanese string functions)
   
I'd make mstring - mbstring.
The question is if it's worth splitting this up into more than one
extension. Probably not.
So we should probably be picking out of wchar, mbstring, jpstring.
Rui, what do you think?
  
  I prefer unified approach is better for php-i18n than splitting
  some modules.
  I think mbstring is better, although this module also
  supports single-byte encoding like ISO-8859-X.
  Some people might say 'wchar' is better choise,
  because this module converts string to wide character internally.
  
  If someone want to add some other encoding support,
  he should add mbfilter_xx.c mbfilter_xx.h where xx means some
  specific language like ja (japanese).
  
  Anyway, because I am not original author of this module,
  I must discuss to Mr. Tsukada ,the original author of jstring
  about renaming the module.
 
  OK. I think wchar or mbstring are both good. jstring will just confuse 
 people.
 

I think mbstring is nice.

Sounds good.

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-30 Thread Rui Hirokawa


I am also one of the authors of ext/iconv module.
iconv module is only for encoding translation but
jstring (renaming to mbstring) is for general multibyte string 
handling fucntions.
The encoding translation is one of functionalities of mbstring.
I think rather iconv module should be merged into mbstring in the future.

On Mon, 30 Apr 2001 19:53:11 +0300
Alexander Bokovoy [EMAIL PROTECTED] wrote:

 On Mon, Apr 30, 2001 at 10:47:21PM +0900, Rui Hirokawa wrote:
  
  On Mon, 30 Apr 2001 15:37:14 +0300
  Andi Gutmans [EMAIL PROTECTED] wrote:
  
   At 09:35 PM 4/30/2001 +0900, Rui Hirokawa wrote:
   
   Andi,
   
   We have plan to add ext/jstring which is a japanese string extension module
   to php-4.0.6.
   Is there any problem to add this module on CVS tree now ?
   
   No I don't see a problem with this but please do it quickly. 4.0.6 has 
   already gone a long way since we started RC'ing 4.0.5 and I would like to 
   start RC'ing it pretty soon. You should probably also copy 
   dotnet/EXPERIMENTAL to your directory until it becomes completely stable.
  
  I did.
  
   
   By the way, do you think jstring is the right name? Is it only for Japanese?
  
  It includes some functions for japanese,but some functions are not 
  only for japanese.
  For example, this module supports encoding conversion functionality between
  Unicode and some other encodings like ISO-8859-X.
  Currently, it includes encoding conversion filter for japanese and ISO-8859-X,
  but it is relatively easy task to add another conversion filter for some other
  language.
  
  I believe this module is small step for PHP internationalization.
  I think the name 'jstring' is right name now because it is existing
  for japanese string function now.
  But  'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name.
 It would be very good to join this features with existing iconv extension
 rather than generate new extensions.


-- 
--
Rui Hirokawa [EMAIL PROTECTED]
maintainer of japanese PHP manual [EMAIL PROTECTED]

-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] 4.0.6

2001-04-29 Thread Andi Gutmans

Guys,

I think that despite the release of 4.0.5 tomorrow we are pretty close to 
having an RC1 for 4.0.6. Lots of things have been fixed/added since 4.0.5 
(check the NEWS file).
Can we make a list of things which still need to make it into 4.0.6 before 
we branch?

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-29 Thread derick

On Sun, 29 Apr 2001, Andi Gutmans wrote:

 Guys,

 I think that despite the release of 4.0.5 tomorrow we are pretty close to
 having an RC1 for 4.0.6. Lots of things have been fixed/added since 4.0.5
 (check the NEWS file).
 Can we make a list of things which still need to make it into 4.0.6 before
 we branch?

AFAIK, James made a list of bugs that should be fixed in 4.0.6, but that
can wait until we branched I guess.

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-29 Thread Andi Gutmans

At 10:09 PM 4/29/2001 +0200, [EMAIL PROTECTED] wrote:
On Sun, 29 Apr 2001, Andi Gutmans wrote:

  Guys,
 
  I think that despite the release of 4.0.5 tomorrow we are pretty close to
  having an RC1 for 4.0.6. Lots of things have been fixed/added since 4.0.5
  (check the NEWS file).
  Can we make a list of things which still need to make it into 4.0.6 before
  we branch?

AFAIK, James made a list of bugs that should be fixed in 4.0.6, but that
can wait until we branched I guess.

Best to fix the bugs before we branch. Where's the list?

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-29 Thread Sterling Hughes

On Sun, 29 Apr 2001, Andi Gutmans wrote:

 Guys,

 I think that despite the release of 4.0.5 tomorrow we are pretty close to
 having an RC1 for 4.0.6. Lots of things have been fixed/added since 4.0.5
 (check the NEWS file).
 Can we make a list of things which still need to make it into 4.0.6 before
 we branch?


I have some Curl extension work that I'd like to put into 4.0.6 (it should
be finished and in by tomorrow, so unless your aiming on rolling the rc
today, all is fine with me).

-Sterling



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6

2001-04-29 Thread Andi Gutmans

At 04:06 AM 4/29/2001 -0400, Sterling Hughes wrote:
On Sun, 29 Apr 2001, Andi Gutmans wrote:

  Guys,
 
  I think that despite the release of 4.0.5 tomorrow we are pretty close to
  having an RC1 for 4.0.6. Lots of things have been fixed/added since 4.0.5
  (check the NEWS file).
  Can we make a list of things which still need to make it into 4.0.6 before
  we branch?
 

I have some Curl extension work that I'd like to put into 4.0.6 (it should
be finished and in by tomorrow, so unless your aiming on rolling the rc
today, all is fine with me).

Go ahead...

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] 4.0.6

2001-04-29 Thread James Moore


 Guys,

 I think that despite the release of 4.0.5 tomorrow we are pretty close to
 having an RC1 for 4.0.6. Lots of things have been fixed/added since 4.0.5
 (check the NEWS file).
 Can we make a list of things which still need to make it into
 4.0.6 before
 we branch?

 Andi

K I have a list of bugs that need to be at least reviewed by the appropraite
developers, this list needs to be added to/altered etc can you please send
feedback on which issues should be fixed before 4.0.6, there are some there
that will not be some that are a 2 second fix etc... Could the QA TEam also
look at them and where possible provide scripts that reproduce the problem
and/or just add an and me note.

=== List of bugs ===
List of iteresting bugs so far:
===

Zend Related

6491 (Incorrect setting of PHP_SELF under certain circumstances)
8130 (Shallow Copy problems)
8414 (set_timout_limit problem
 (very weird not the normal set_timeout_limit bogus report)
8889 (Memory consumption.. decent discussion included)
9289 $argv/$argc weirdness (unverifed)
9462 Include/Require need to be binary safe (see report for example)
9505 (Patch included OS400 specific)
10299 Same as 8889.

To be verified in Zend
--
10029 Not sure about this one
  but its here due to my lack of understanding of Zend :)

Build Related
-
8045 Configuration order of ccvs and mcrypt

CGI Related
---
9041 #! at top of script problem. (this one really needs fixing!)

Enviroment Related
--
8725 (putenv problems (see report)) Can anyone verify this?

ini_* funcs
---
10431 ini_alter eats the include_path (unverified)

Interbase Related
-
10458 Bugs #9257 and #10292 located and fixed - see diff
  (can someone check the fix please)

Sockets Related
---
9427 (PHP blocks waiting for packets (needs to be verified))

Time Related

9640 strtotime behaving weirdly (derick did you get to the bottom of this)?
9878 gmmktime doesnt work with daylight saving
 (can anyone verify this?) (test script included)

URL Related
---
1249 url_parse() is a bit too strict

To be verified
--
9526 Can anyone verify this? (safmode copy problems)
9780 Seems like the dirname etc confusion due to standards
===

- James


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] 4.0.6

2001-04-29 Thread derick

On Sun, 29 Apr 2001, James Moore wrote:

 === List of bugs ===
 List of iteresting bugs so far:
 ===

 Zend Related
 
 6491 (Incorrect setting of PHP_SELF under certain circumstances)
 8130 (Shallow Copy problems)
 8414 (set_timout_limit problem
  (very weird not the normal set_timeout_limit bogus report)
 8889 (Memory consumption.. decent discussion included)
 9289 $argv/$argc weirdness (unverifed)
 9462 Include/Require need to be binary safe (see report for example)
 9505 (Patch included OS400 specific)
 10299 Same as 8889.

 To be verified in Zend
 --
 10029 Not sure about this one
   but its here due to my lack of understanding of Zend :)

I think bug 8621 does belong here too, it's the -a mode that segfaults. B.
Boyev tried to look into this, but couldn't get to the bottom.

 Time Related
 
 9640 strtotime behaving weirdly (derick did you get to the bottom of this)?
 9878 gmmktime doesnt work with daylight saving
  (can anyone verify this?) (test script included)

I couldn't understand the date format in bug 9640
But Id like to add 9050 to this part of your list.

Derick


-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




RE: [PHP-DEV] 4.0.6

2001-04-29 Thread Andi Gutmans

At 11:36 PM 4/29/2001 +0100, James Moore wrote:
snip
K I have a list of bugs that need to be at least reviewed by the appropraite
developers, this list needs to be added to/altered etc can you please send
feedback on which issues should be fixed before 4.0.6, there are some there
that will not be some that are a 2 second fix etc... Could the QA TEam also
look at them and where possible provide scripts that reproduce the problem
and/or just add an and me note.

=== List of bugs ===
List of iteresting bugs so far:
===

I hope you keep good notes :)

Zend Related

6491 (Incorrect setting of PHP_SELF under certain circumstances)

Someone who knows this better should state his opinion. Maybe Sascha who 
knows all the RFC's by heart :) And I guess it depends what the PHP manual 
says too.

8130 (Shallow Copy problems)

For now this is going to have to stay a feature.

8414 (set_timout_limit problem
  (very weird not the normal set_timeout_limit bogus report)
8889 (Memory consumption.. decent discussion included)

I mailed Brian and am waiting for a response from him. I'd like to work 
with him together on this one.

9289 $argv/$argc weirdness (unverifed)
9462 Include/Require need to be binary safe (see report for example)

I don't understand why this is a bug. He should code better :) This is how 
the OS works or am I missing something?

9505 (Patch included OS400 specific)

No idea why this was a bug but I changed the code to how he wanted because 
it doesn't make a difference to us. Commited to CVS.

10299 Same as 8889.

To be verified in Zend
--
10029 Not sure about this one
   but its here due to my lack of understanding of Zend :)

It's probably not a problem but I mailed Zeev to look at it.


Build Related
-
8045 Configuration order of ccvs and mcrypt

CGI Related
---
9041 #! at top of script problem. (this one really needs fixing!)

I see where the code needs to be changed. The question is if we should 
really skip this in CGI or not. I think we shouldn't. We don't want to and 
won't do it for Apache, ISAPI and so on...


Enviroment Related
--
8725 (putenv problems (see report)) Can anyone verify this?

ini_* funcs
---
10431 ini_alter eats the include_path (unverified)

Interbase Related
-
10458 Bugs #9257 and #10292 located and fixed - see diff
   (can someone check the fix please)

Sockets Related
---
9427 (PHP blocks waiting for packets (needs to be verified))

Time Related

9640 strtotime behaving weirdly (derick did you get to the bottom of this)?
9878 gmmktime doesnt work with daylight saving
  (can anyone verify this?) (test script included)

URL Related
---
1249 url_parse() is a bit too strict

To be verified
--
9526 Can anyone verify this? (safmode copy problems)
9780 Seems like the dirname etc confusion due to standards

The standard we took is dirname on Linux. From a Linux shell do dirname /tmp/

Andi


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] 4.0.6 and gd 2

2001-04-18 Thread Wez Furlong

On 2001-04-18 06:43:33, "Kurth Bemis" [EMAIL PROTECTED] wrote:
 configure: warning: If configure fails try --with-xpm-dir=DIR
 checking for freetype(2) (needed by gd 2.0+)... no
 ...

 heres my config line
 ./configure --with-mysql=/usr/local/mysql 
 --with-apache=/usr/src/apache_1.3.19 --enable-ftp --with-gd 
 --enable-freetype-4bit-antialias-hack --with-jpeg-dir=/usr/src/jpeg-6b 
 --enable-gd-native-ttf --with-png-dir=/usr/local/lib

Try this instead:

./configure --with-mysql=/usr/local/mysql 
 --with-apache=/usr/src/apache_1.3.19 --enable-ftp --with-gd 
 --with-jpeg-dir=/usr/src/jpeg-6b 
 --with-png-dir=/usr/local/lib
 --with-freetype-dir

This implies --enable-gd-native-ttf, so you don't need to specify it.
There is no such option as --enable-freetype-4bit-antialias-hack (anymore).

 checking whether to include FreeType 1.x support... no - FreeType 2.x is to 
 be used instead

I'm concerned by this message.

If this doesn't work for you, please file a bug report at http://bugs.php.net, and 
email me (personally) your config.log.

--Wez.


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]