Re: [PHP-DEV] huge memory usage in concat op, ZE2

[Andi Gutmans]

I'll try and see what I can do about this.

Andi

At 11:56 AM 12/8/2002 -0800, Tom Fishwick wrote:

I was reading an email from stdin.  But regardless of bad coding style
:-), the script is using _way_ more memory than it should.

$s = '';
while(strlen($s) < 266768) {
$s.= 'd';
}

this code uses 151Megs on my system. the same code uses about 2megs with
php4.3.  php4.3 seems to realloc/memcpy when the string gets big, and
php5 just does malloc's and memcpy's (I don't see calls to free()
though).  I'm thinking the problem might be in zend_mm_realloc?

Tom

Andi Gutmans <[EMAIL PROTECTED]> wrote:
>
> At 12:30 AM 12/8/2002 -0800, Tom wrote:
> >hey there,
> >
> >I'm using the cvs and ZE2, there seems to be some huge memory usage when
> >concatenating a string to a length over 262080 bytes, when the string
> >length gets to that size the malloc call inside
> >zend_mm_add_memory_block starts grabing memory 262168 bytes at a time,
> >every 8th concatenation (i'm concatenating 1 byte at a time).
> >
> >anyone else seen this?
>
> It makes sense that this is happening to you. Reaching the point where you
> add to a string of such size is very bad coding practice (unless you 
really
> have no choice). This is because if the memory manager can't realloc() (it
> very often can't) then it'll have to allocate a new block and use a
> memcpy() to copy over all of the string.
> The current code is less than optimal in this case and I can choose 
various
> strategies to improve on it but there will always be times where the
> malloc()/memcpy() will be necessary.
> So what are you doing? Is it something you have to do?
> Andi
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] huge memory usage in concat op, ZE2

[Tom Fishwick]

I was reading an email from stdin.  But regardless of bad coding style
:-), the script is using _way_ more memory than it should.

$s = '';
while(strlen($s) < 266768) {
$s.= 'd';
}

this code uses 151Megs on my system. the same code uses about 2megs with
php4.3.  php4.3 seems to realloc/memcpy when the string gets big, and
php5 just does malloc's and memcpy's (I don't see calls to free()
though).  I'm thinking the problem might be in zend_mm_realloc?

Tom

Andi Gutmans <[EMAIL PROTECTED]> wrote: 
> 
> At 12:30 AM 12/8/2002 -0800, Tom wrote:
> >hey there,
> >
> >I'm using the cvs and ZE2, there seems to be some huge memory usage when
> >concatenating a string to a length over 262080 bytes, when the string
> >length gets to that size the malloc call inside
> >zend_mm_add_memory_block starts grabing memory 262168 bytes at a time,
> >every 8th concatenation (i'm concatenating 1 byte at a time).
> >
> >anyone else seen this?
> 
> It makes sense that this is happening to you. Reaching the point where you 
> add to a string of such size is very bad coding practice (unless you really 
> have no choice). This is because if the memory manager can't realloc() (it 
> very often can't) then it'll have to allocate a new block and use a 
> memcpy() to copy over all of the string.
> The current code is less than optimal in this case and I can choose various 
> strategies to improve on it but there will always be times where the 
> malloc()/memcpy() will be necessary.
> So what are you doing? Is it something you have to do?
> Andi
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] mail() problem

[Melvyn Sopacua]

On Sun, 8 Dec 2002, stormryder wrote:

s>>> Hi,
s>>> I'm using the mail() function to send out mails.
s>>> The problem I'm having is the subject line shows up in the message body.
s>>> 
s>>> Anybody has any ideas?

If you ask on the right list, like [EMAIL PROTECTED], then maybe somebody 
get's inspired.

PS: it might help to provide some sample code...
-- 
With kind regards,

Melvyn Sopacua



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] mail() problem

[stormryder]

Hi,
I'm using the mail() function to send out mails.
The problem I'm having is the subject line shows up in the message body.

Anybody has any ideas?



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Melvyn Sopacua]

On Sun, 8 Dec 2002, John Coggeshall wrote:

JC>>> 
JC>>> As much as I understand the point of view that renaming the CGI version
JC>>> of PHP from php(.exe) to php-cgi(.exe) so that we don't have to type
JC>>> 'php-cli' perhaps isn't such a good idea, I am completely against
JC>>> changing it now. Changing it the first time is obviously causing
JC>>> problems, changing it again will really muddle the waters... (Okay, if
JC>>> you downloaded PHP between the months of XXX and , it's this...
JC>>> Otherwise, it's that... Unless...)

Ehm - the last __released__ version is php.exe vs. php-cli.exe. We shouldn't
care about RC's/pre's and cvs builds.

Live 'on the edge' - be prepared for a landing.

JC>>> 
JC>>> Regards,
JC>>> 
JC>>> John
JC>>> 
JC>>> 
JC>>> >-Original Message-
JC>>> >From: Melvyn Sopacua [mailto:[EMAIL PROTECTED]] 
JC>>> >Sent: Sunday, December 08, 2002 6:28 PM
JC>>> >To: [EMAIL PROTECTED]
JC>>> >Cc: [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED]
JC>>> >Subject: RE: [PHP-DEV] php.exe - php-cgi.exe
JC>>> >
JC>>> >
JC>>> >On Sun, 8 Dec 2002, Marcus Börger wrote:
JC>>> >
JC>>> >MBr>>> Just because you only need to type the name of the CGI 
JC>>> >sapi once: 
JC>>> >MBr>>> In other word one single time until we decide the name changes. 
JC>>> >MBr>>> But you will use a command line interface hopefully 
JC>>> >very often. I 
JC>>> >MBr>>> for one do and i am not going to type php-cli.exe because it is 
JC>>> >MBr>>> way much to long.
JC>>> >
JC>>> >Sorry Marcus, but - even though I think these names are better 
JC>>> >- the same could be said for a cli: ln -s php-cli php or even: 
JC>>> >alias php /usr/local/bin/php-cli
JC>>> >
JC>>> >For windows - you could move php-cli.exe to 
JC>>> >C:\WINNT\system32\php.exe and it's preferred in the path (or 
JC>>> >set %PATH%).
JC>>> >
JC>>> >But - changing the name for the CGI, breaks server environments...
JC>>> >
JC>>> >I think on windows, the two executables, should be named the 
JC>>> >php.exe and the cgi stored in the standard php4 dir and the 
JC>>> >cli version in bin/. This way you have the best of both worlds 
JC>>> >- it won't break CGI - and a simple PATH adjustment takes care 
JC>>> >of the cli problem.
JC>>> >
JC>>> >For unices, we could provide a --with-cgi-name configure 
JC>>> >option and default to php, with --disable-cli.
JC>>> >
JC>>> >Just my 2c
JC>>> >-- 
JC>>> >With kind regards,
JC>>> >
JC>>> >Melvyn Sopacua
JC>>> >
JC>>> >
JC>>> >
JC>>> >-- 
JC>>> >PHP Development Mailing List 
JC>>> >To unsubscribe, visit: http://www.php.net/unsub.php
JC>>> >
JC>>> >
JC>>> 
JC>>> 
JC>>> --
JC>>> PHP Development Mailing List 
JC>>> To unsubscribe, visit: http://www.php.net/unsub.php
JC>>> 
JC>>> 

-- 
With kind regards,

Melvyn Sopacua



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Bug #20807

[Melvyn Sopacua]

Hi,

the attached patch fixes bug #20807. It's against current HEAD.
Verified to install 'php' and 'php-cli' (without the exe
extension).

-- 
With kind regards,

Melvyn Sopacua


Index: sapi/cli/config.m4
===
RCS file: /repository/php4/sapi/cli/config.m4,v
retrieving revision 1.12
diff -u -r1.12 config.m4
--- sapi/cli/config.m4  14 Nov 2002 01:09:46 -  1.12
+++ sapi/cli/config.m4  9 Dec 2002 00:21:26 -
@@ -22,6 +22,10 @@
   *darwin*)
 BUILD_CLI="\$(CC) \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) 
\$(NATIVE_RPATHS) \$(PHP_GLOBAL_OBJS:.lo=.o) \$(PHP_CLI_OBJS:.lo=.o) 
\$(PHP_FRAMEWORKS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
 ;;
+  *cygwin*)
+SAPI_CLI_PATH=sapi/cli/php.exe
+BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) 
+\$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) 
+\$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
+;;
   *)
 BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) 
\$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) 
\$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
 ;;
Index: sapi/cgi/config9.m4
===
RCS file: /repository/php4/sapi/cgi/config9.m4,v
retrieving revision 1.3
diff -u -r1.3 config9.m4
--- sapi/cgi/config9.m4 1 Dec 2002 21:50:35 -   1.3
+++ sapi/cgi/config9.m4 9 Dec 2002 00:21:26 -
@@ -86,7 +86,14 @@
 AC_MSG_RESULT(yes)
 
 PHP_ADD_MAKEFILE_FRAGMENT($abs_srcdir/sapi/cgi/Makefile.frag)
-SAPI_CGI_PATH=sapi/cgi/php-cgi
+case $host_alias in
+  *cygwin* )
+SAPI_CGI_PATH=sapi/cgi/php-cgi.exe
+;;
+  * )
+SAPI_CGI_PATH=sapi/cgi/php-cgi
+;;
+esac
 PHP_SUBST(SAPI_CGI_PATH)
 
 PHP_TEST_WRITE_STDOUT

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Mike Robinson]

Marcus Börger wrote:
> At 22:08 08.12.2002, Mike Robinson wrote:
> >Christoph Grottolo wrote:
> >
> > > It's worse.
> > >
> > > At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe
> > > (CGI).
> >
> >This is the way it should stay.
> >I'm trying to find the archive of the discussion that lead to this
> >being changed. I'm having a huge problem getting my head 
> around why the
> >name of the CGI executable has to be changed at all. Any pointers or
> >enlightenment would be welcomed. :)
> >
> >Regards
> >Mike Robinson
> 
> 
> Just because you only need to type the name of the CGI sapi
> once: In other word one single time until we decide the name 
> changes. But you will use a command line interface hopefully 
> very often. I for one do and i am not going to type 
> php-cli.exe because it is way much to long.

Every system on the planet that uses php.exe as their CGI executable,
and I suggest there are quite a few, will have a broken setup with a
stock install of php-4.3.0, because typing php-cli.exe at the command
line is too long. And you expect putting huge notes and warnings in the
news file and installer will prevent this from happening.

> The reason against renaming CGI and using its old name for
> the CLI now would have lead us to register_globals=ON for eternity.

Totally different. Apples and oranges.
That was a security-related change, and IMHO, the amount of trouble
_that_ change caused far outweighed the meagre benefits achieved.

This change is going to break a lot of setups for the sake of cli users
saving a few keystrokes.

Sorry. There's just no way this should happen.

Regards
Mike Robinson


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Pear installer and case-insensative OS's

[Melvyn Sopacua]

Hi,

pear won't install on cygwin, simply because the 'PEAR' dir is missing from the cvs 
checkout - culprit:
pear/.cvsignore contains 'pear' (yes lowercase).

Result:
Warning: main(PEAR/Installer.php) [http://www.php.net/function.main]: failed to create 
stream: No such file or directory in /home/msopacua/cvs/php4/pear/install-pear.php on 
line 9

How about renaming that dir?

-- 
With kind regards,

Melvyn Sopacua



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[John Coggeshall]

As much as I understand the point of view that renaming the CGI version
of PHP from php(.exe) to php-cgi(.exe) so that we don't have to type
'php-cli' perhaps isn't such a good idea, I am completely against
changing it now. Changing it the first time is obviously causing
problems, changing it again will really muddle the waters... (Okay, if
you downloaded PHP between the months of XXX and , it's this...
Otherwise, it's that... Unless...)

Regards,

John


>-Original Message-
>From: Melvyn Sopacua [mailto:[EMAIL PROTECTED]] 
>Sent: Sunday, December 08, 2002 6:28 PM
>To: [EMAIL PROTECTED]
>Cc: [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED]
>Subject: RE: [PHP-DEV] php.exe - php-cgi.exe
>
>
>On Sun, 8 Dec 2002, Marcus Börger wrote:
>
>MBr>>> Just because you only need to type the name of the CGI 
>sapi once: 
>MBr>>> In other word one single time until we decide the name changes. 
>MBr>>> But you will use a command line interface hopefully 
>very often. I 
>MBr>>> for one do and i am not going to type php-cli.exe because it is 
>MBr>>> way much to long.
>
>Sorry Marcus, but - even though I think these names are better 
>- the same could be said for a cli: ln -s php-cli php or even: 
>alias php /usr/local/bin/php-cli
>
>For windows - you could move php-cli.exe to 
>C:\WINNT\system32\php.exe and it's preferred in the path (or 
>set %PATH%).
>
>But - changing the name for the CGI, breaks server environments...
>
>I think on windows, the two executables, should be named the 
>php.exe and the cgi stored in the standard php4 dir and the 
>cli version in bin/. This way you have the best of both worlds 
>- it won't break CGI - and a simple PATH adjustment takes care 
>of the cli problem.
>
>For unices, we could provide a --with-cgi-name configure 
>option and default to php, with --disable-cli.
>
>Just my 2c
>-- 
>With kind regards,
>
>Melvyn Sopacua
>
>
>
>-- 
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Melvyn Sopacua]

On Sun, 8 Dec 2002, Marcus Börger wrote:

MBr>>> Just because you only need to type the name of the CGI sapi once:
MBr>>> In other word one single time until we decide the name changes.
MBr>>> But you will use a command line interface hopefully very often. I
MBr>>> for one do and i am not going to type php-cli.exe because it is way
MBr>>> much to long.

Sorry Marcus, but - even though I think these names are better - the same could be 
said for a cli:
ln -s php-cli php
or even:
alias php /usr/local/bin/php-cli

For windows - you could move php-cli.exe to C:\WINNT\system32\php.exe and it's 
preferred in the path (or set %PATH%).

But - changing the name for the CGI, breaks server environments...

I think on windows, the two executables, should be named the php.exe and the cgi 
stored in the standard php4 dir and the cli version in bin/. This way you have the 
best of both worlds - it won't break CGI - and a simple PATH adjustment takes care of 
the cli problem.

For unices, we could provide a --with-cgi-name configure option and default to php, 
with --disable-cli.

Just my 2c
-- 
With kind regards,

Melvyn Sopacua



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Marcus Börger]

At 22:08 08.12.2002, Mike Robinson wrote:

Christoph Grottolo wrote:

> It's worse.
>
> At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and
> php.exe (CGI).

This is the way it should stay.
I'm trying to find the archive of the discussion that lead to this
being changed. I'm having a huge problem getting my head around why
the name of the CGI executable has to be changed at all. Any pointers
or enlightenment would be welcomed. :)

Regards
Mike Robinson



Just because you only need to type the name of the CGI sapi once:
In other word one single time until we decide the name changes.
But you will use a command line interface hopefully very often. I
for one do and i am not going to type php-cli.exe because it is way
much to long.

The reason against renaming CGI and using its old name for the CLI
now would have lead us to register_globals=ON for eternity.

marcus



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php.exe - php-cgi.exe

[Marcus Börger]

At 20:37 08.12.2002, Christoph Grottolo wrote:

Marcus Börger wrote:

> There was no cli and only cgi binary called php.exe.
> Then we decided to have a command line executable (abbrevation CLI).
> And the we decided to use 'php.exe' for the new CLI and to avoid
> confusion we chose to rename the CGI binary from 'php.exe'. So now
> there will be some books and other papers and online docs out there
> which state that php.exe has to be installedIn other words there
> will be users who install CLI as CGI what will lead into errors.
>
> marcus

It's worse.

At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI).

Christoph



But in 4.2.x CLI sapi was experimental so there is no need to change
anything because of that.

marcus





--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] mail() problem

[stormryder]

Hi,
I'm using the mail() function to send out mails.
The problem I'm having is the subject line shows up in the message body.

Anybody has any ideas?

TIA



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Mike Robinson]

Christoph Grottolo wrote:

> It's worse.
> 
> At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and 
> php.exe (CGI).

This is the way it should stay.
I'm trying to find the archive of the discussion that lead to this
being changed. I'm having a huge problem getting my head around why
the name of the CGI executable has to be changed at all. Any pointers
or enlightenment would be welcomed. :)

Regards
Mike Robinson


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Marcus Börger]

At 19:28 08.12.2002, Philip Olson wrote:

On Sun, 8 Dec 2002, Marcus [iso-8859-1] Börger wrote:

> At 17:55 08.12.2002, Philip Olson wrote:
>
> >Wait, so there used to be a php-cli.exe ?  Add
> >that to the history request question :)
> >
> >And so a user tries to install via some install
> >tutorial on foo.com, what problems/errors will
> >they see when accessing via the browser?
>
> There was no spoon :-) ok start again:


From the film "Matrix": "ther is no spoon" :-)))



Not sure what this means.

> There was no cli and only cgi binary called php.exe.
> Then we decided to have a command line executable (abbrevation CLI).
> And the we decided to use 'php.exe' for the new CLI and to avoid confusion
> we chose to rename the CGI binary from 'php.exe'. So now there will be
> some books and other papers and online docs out there which state that
> php.exe has to be installedIn other words there will be users who 
install
> CLI as CGI what will lead into errors.

Please provide version numbers so it can be documented.  Like,
WHEN the changes happened.

Thanks,
Philip


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php.exe - php-cgi.exe

[Christoph Grottolo]

Marcus Börger wrote:

> There was no cli and only cgi binary called php.exe.
> Then we decided to have a command line executable (abbrevation CLI).
> And the we decided to use 'php.exe' for the new CLI and to avoid
> confusion we chose to rename the CGI binary from 'php.exe'. So now
> there will be some books and other papers and online docs out there
> which state that php.exe has to be installedIn other words there
> will be users who install CLI as CGI what will lead into errors.
>
> marcus

It's worse.

At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI).

Christoph



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Mike Robinson]

Marcus Börger wrote:

> There was no cli and only cgi binary called php.exe.
> Then we decided to have a command line executable 
> (abbrevation CLI). And the we decided to use 'php.exe' for 
> the new CLI and to avoid confusion we chose to rename the CGI 
> binary from 'php.exe'. So now there will be some books and 
> other papers and online docs out there which state that 
> php.exe has to be installedIn other words there will be 
> users who install CLI as CGI what will lead into errors.

Well no offence, but renaming the CGI executable is just plain
wrong. The CLI executable should be named php-cli.exe. This seems
like such a nobrainer. Am I missing something? Clue me in.

Regards
Mike Robinson



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] huge memory usage in concat op, ZE2

[Andi Gutmans]

At 12:30 AM 12/8/2002 -0800, Tom wrote:

hey there,

I'm using the cvs and ZE2, there seems to be some huge memory usage when
concatenating a string to a length over 262080 bytes, when the string
length gets to that size the malloc call inside
zend_mm_add_memory_block starts grabing memory 262168 bytes at a time,
every 8th concatenation (i'm concatenating 1 byte at a time).

anyone else seen this?


It makes sense that this is happening to you. Reaching the point where you 
add to a string of such size is very bad coding practice (unless you really 
have no choice). This is because if the memory manager can't realloc() (it 
very often can't) then it'll have to allocate a new block and use a 
memcpy() to copy over all of the string.
The current code is less than optimal in this case and I can choose various 
strategies to improve on it but there will always be times where the 
malloc()/memcpy() will be necessary.
So what are you doing? Is it something you have to do?
Andi


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Philip Olson]

On Sun, 8 Dec 2002, Marcus [iso-8859-1] Börger wrote:

> At 17:55 08.12.2002, Philip Olson wrote:
> 
> >Wait, so there used to be a php-cli.exe ?  Add
> >that to the history request question :)
> >
> >And so a user tries to install via some install
> >tutorial on foo.com, what problems/errors will
> >they see when accessing via the browser?
> 
> There was no spoon :-) ok start again:

Not sure what this means.

> There was no cli and only cgi binary called php.exe.
> Then we decided to have a command line executable (abbrevation CLI).
> And the we decided to use 'php.exe' for the new CLI and to avoid confusion
> we chose to rename the CGI binary from 'php.exe'. So now there will be
> some books and other papers and online docs out there which state that
> php.exe has to be installedIn other words there will be users who install
> CLI as CGI what will lead into errors.

Please provide version numbers so it can be documented.  Like,
WHEN the changes happened.

Thanks,
Philip



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Preston L. Bannister]

Admittedly I didn't hear whatever discussion went on before, but I wonder
why the need for two different executables?  It seems that the presence of
the CGI variables SERVER_NAME and SERVER_SOFTWARE are pretty big hints, so
you could decide at runtime whether to act as CGI or CLI.

For completeness add a couple command line option to force CLI or CGI
behavior and you're pretty much done.

-Original Message-
From: Marcus Borger [mailto:[EMAIL PROTECTED]]
Sent: Sunday, December 08, 2002 9:50 AM

At 17:55 08.12.2002, Philip Olson wrote:

>Wait, so there used to be a php-cli.exe ?  Add
>that to the history request question :)
>
>And so a user tries to install via some install
>tutorial on foo.com, what problems/errors will
>they see when accessing via the browser?
>
>Philip


There was no spoon :-) ok start again:

There was no cli and only cgi binary called php.exe.
Then we decided to have a command line executable (abbrevation CLI).
And the we decided to use 'php.exe' for the new CLI and to avoid confusion
we chose to rename the CGI binary from 'php.exe'. So now there will be
some books and other papers and online docs out there which state that
php.exe has to be installedIn other words there will be users who
install
CLI as CGI what will lead into errors.

marcuis


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Marcus Börger]

At 17:55 08.12.2002, Philip Olson wrote:


Wait, so there used to be a php-cli.exe ?  Add
that to the history request question :)

And so a user tries to install via some install
tutorial on foo.com, what problems/errors will
they see when accessing via the browser?

Philip



There was no spoon :-) ok start again:

There was no cli and only cgi binary called php.exe.
Then we decided to have a command line executable (abbrevation CLI).
And the we decided to use 'php.exe' for the new CLI and to avoid confusion
we chose to rename the CGI binary from 'php.exe'. So now there will be
some books and other papers and online docs out there which state that
php.exe has to be installedIn other words there will be users who install
CLI as CGI what will lead into errors.

marcuis




On Sun, 8 Dec 2002, John Coggeshall wrote:

>
> I believe the issue here is that PHP won't display the proper HTTP
> headers in the CLI version:
>
> C:\> Php.exe test.php
>
> X-Powered-By: PHP/4.2.2
> Content-type: text/html
>
> Testing 1 2 3
> C:\>
> C:\> Php-cli.exe test.php
> Testing 1 2 3
> C:\>
>
> >-Original Message-
> >From: Philip Olson [mailto:[EMAIL PROTECTED]]
> >Sent: Sunday, December 08, 2002 11:07 AM
> >To: Alexander Wagner
> >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> >'Christoph Grottolo'; [EMAIL PROTECTED]
> >Subject: Re: [PHP-DEV] php.exe - php-cgi.exe
> >
> >
> >
> >Can someone provide a history of this and the problems
> >one will see when trying to run php.exe as a cgi (i.e.
> >follows one of the many install texts out there).
> >
> >This is _sorta_ documented but not really, only the
> >apache2 docs make any mention of it thus far.
> >
> >Regards,
> >Philip
> >
> >
> >On Sun, 8 Dec 2002, Alexander Wagner wrote:
> >
> >> On Sunday 08 December 2002 01:02, John Coggeshall wrote:
> >> > I think a big ole' message at the end of ./configure will
> >> > drastically reduce the number of problems.
> >>
> >> With php.exe? *g*
> >>
> >> > Also, perhaps a check could be put in the
> >> > CLI version of PHP that would throw an error message if it
> >is being
> >> > used as a CGI...
> >>
> >> A _meaningful_ error-message in the right place would be the right
> >> thing (tm).
> >> Too many people don't read release-notes.
> >>
> >> regards
> >> Wagner
> >>
> >> --
> >> codito ergo sum
> >>
> >> --
> >> PHP Development Mailing List 
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
> >
> >
>



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Philip Olson]

Wait, so there used to be a php-cli.exe ?  Add
that to the history request question :)

And so a user tries to install via some install
tutorial on foo.com, what problems/errors will
they see when accessing via the browser?

Philip


On Sun, 8 Dec 2002, John Coggeshall wrote:

> 
> I believe the issue here is that PHP won't display the proper HTTP
> headers in the CLI version:
> 
> C:\> Php.exe test.php
> 
> X-Powered-By: PHP/4.2.2
> Content-type: text/html
> 
> Testing 1 2 3
> C:\>
> C:\> Php-cli.exe test.php
> Testing 1 2 3
> C:\>
> 
> >-Original Message-
> >From: Philip Olson [mailto:[EMAIL PROTECTED]] 
> >Sent: Sunday, December 08, 2002 11:07 AM
> >To: Alexander Wagner
> >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
> >'Christoph Grottolo'; [EMAIL PROTECTED]
> >Subject: Re: [PHP-DEV] php.exe - php-cgi.exe
> >
> >
> >
> >Can someone provide a history of this and the problems
> >one will see when trying to run php.exe as a cgi (i.e.
> >follows one of the many install texts out there).
> >
> >This is _sorta_ documented but not really, only the
> >apache2 docs make any mention of it thus far.
> >
> >Regards,
> >Philip
> >
> >
> >On Sun, 8 Dec 2002, Alexander Wagner wrote:
> >
> >> On Sunday 08 December 2002 01:02, John Coggeshall wrote:
> >> > I think a big ole' message at the end of ./configure will 
> >> > drastically reduce the number of problems.
> >> 
> >> With php.exe? *g*
> >> 
> >> > Also, perhaps a check could be put in the
> >> > CLI version of PHP that would throw an error message if it 
> >is being 
> >> > used as a CGI...
> >> 
> >> A _meaningful_ error-message in the right place would be the right 
> >> thing (tm).
> >> Too many people don't read release-notes.
> >> 
> >> regards
> >> Wagner
> >> 
> >> --
> >> codito ergo sum
> >> 
> >> --
> >> PHP Development Mailing List 
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >> 
> >
> >
> >
> 


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[John Coggeshall]

I believe the issue here is that PHP won't display the proper HTTP
headers in the CLI version:

C:\> Php.exe test.php

X-Powered-By: PHP/4.2.2
Content-type: text/html

Testing 1 2 3
C:\>
C:\> Php-cli.exe test.php
Testing 1 2 3
C:\>

>-Original Message-
>From: Philip Olson [mailto:[EMAIL PROTECTED]] 
>Sent: Sunday, December 08, 2002 11:07 AM
>To: Alexander Wagner
>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
>'Christoph Grottolo'; [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] php.exe - php-cgi.exe
>
>
>
>Can someone provide a history of this and the problems
>one will see when trying to run php.exe as a cgi (i.e.
>follows one of the many install texts out there).
>
>This is _sorta_ documented but not really, only the
>apache2 docs make any mention of it thus far.
>
>Regards,
>Philip
>
>
>On Sun, 8 Dec 2002, Alexander Wagner wrote:
>
>> On Sunday 08 December 2002 01:02, John Coggeshall wrote:
>> > I think a big ole' message at the end of ./configure will 
>> > drastically reduce the number of problems.
>> 
>> With php.exe? *g*
>> 
>> > Also, perhaps a check could be put in the
>> > CLI version of PHP that would throw an error message if it 
>is being 
>> > used as a CGI...
>> 
>> A _meaningful_ error-message in the right place would be the right 
>> thing (tm).
>> Too many people don't read release-notes.
>> 
>> regards
>> Wagner
>> 
>> --
>> codito ergo sum
>> 
>> --
>> PHP Development Mailing List 
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>
>
>


-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] php.exe - php-cgi.exe

[Philip Olson]

Can someone provide a history of this and the problems
one will see when trying to run php.exe as a cgi (i.e.
follows one of the many install texts out there).

This is _sorta_ documented but not really, only the
apache2 docs make any mention of it thus far.

Regards,
Philip


On Sun, 8 Dec 2002, Alexander Wagner wrote:

> On Sunday 08 December 2002 01:02, John Coggeshall wrote:
> > I think a big ole' message at the end of ./configure will drastically
> > reduce the number of problems.
> 
> With php.exe? *g*
> 
> > Also, perhaps a check could be put in the
> > CLI version of PHP that would throw an error message if it is being used
> > as a CGI...
> 
> A _meaningful_ error-message in the right place would be the right thing (tm). 
> Too many people don't read release-notes.
> 
> regards
> Wagner
> 
> -- 
> codito ergo sum
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Default Return-Path with mail() and qmail

[Daniel Lorch]

hi,

Somehow this is starting to annoy me -- sorry for the unnecessary "noise" I
am causing on this list. I just thought people who are having the same problem
would be looking on marc.theaimsgroup.com or google and find a possible fix.
I'm not forcing anyone to use it.

> Setting Return-Path is useless. It's stripped by sendmail, unless it's allowed
> in the cf file explicetely. Same for postfix version of sendmail.

This also applies to qmail-smtpd, however, I'm talking about qmail-inject.

> You simply need to setup your mailserver correctly and php accordingly, ie:
> let the webserver user be allowed to use the '-f' sendmail flag and provide
> this in the arguments of mail() or via ini_set.

I'm not using mod_php. And the -f switch is a nice quick-fix, but it would
force me to hardcode a Return-Path and how can I be sure that
<[EMAIL PROTECTED]> really exists? It is just more intuitive that
if a user supplies a "From" header, not only human-generated responses
will get back to him, but also machine-generated bounces.

> In no way, should mail() by default equal the RCPT TO user to the From: 
> header - if I would host users,

And I'm sure my users don't want me to read their mails. But I HAVE to
read bounces. I never touch people's personal stuff otherwise.

> I would like to know, if they start spammin' or have buggy scripts. 

That's why logfiles exist.

> What ever the reason - the final control of this option should
> remain with the mailserver administrator, not the mail user.

I'm not hardcoding Return-Path. 

-daniel

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Latest ZE2 changes

[Marcus Börger]

At 00:41 08.12.2002, Marcus Börger wrote:

At 16:48 07.12.2002, Zeev Suraski wrote:

At 17:02 07/12/2002, Marcus Börger wrote:

Hi Zeev,

I have changed the test files and encountered some problems with the way 
you modified my patch:

1) private_002.phpt fails  with
004- Fatal error: Call to private method pass::show() from context 
'fail' in %s on line %d
004+ Fatal error: Call to public method fail::show() from context 'fail' 
in /usr/src/php4-HEAD/tests/classes/private_002.php on line 18

I see the problem.  It should be fixed.


Fixed now, thanks.




The new error message is wrong. We are trying to access pass::show and 
not fail::show().

2) private_007.phpt and private_007b.phpt both fail with the message
Fatal error: Cannot redeclare private bar::priv() as public foo::priv()

That means the children know about their parents privates what is in 
contrast to
our discussion. The reason they do is because you skipped the part of 
the patch
where in zend_do_inheritance() a modified version of 
zend_hash_merge_ex() was
used to prevent this. But you also do not search for the private method 
in the calling
scope. In other words you mainly used the first version of my patch. So 
i tried to
strip down zend_hash_merge_with_argument_if() to the portion we need and 
tried
to skip copying zje privates. But since privates are no longer looked up 
in the
calling scope this fails.

I implement PPP in a different way altogether (it's very loosely based on 
your patch, the actual implementation is very different), in order to 
avoid having two hash lookups for every method call.  I left a comment in 
the code that says we may want to improve the error messages, but the 
current implementation is quite intentional - it's much more efficient.

However this is about what i did in my first patches and gave up after 
discussion with Andi.
Since he was right that the performance loss by the required checks is 
outweighted by the
fact that otherwise classes know about private details of their ancestors. 
And i remeber having
an agreement on this. And yes you did the execute part in another way but 
until now i see
many problems in your way.


3) You left in some snippets of the 'final' patch. Does this mean we are 
going to have
final? A new patch is also available.

No, we're not going to add final, at least not for now.  I may have 
forgotten to remove the scanner part of the patch but it's meaningless :)

Zeev


After the patches today some more things need to be revisited:

4)  You allow changing the visibility. In most languages it is only allowed to
decrease the visibility or it is even disallowed. Increasing the 
visibility is a
very unfamiliar feature.

5) When you look at test private_007b.phpt you will see that the wrong
method is called. This is a consequence of 2. It seems you optimized to
much.


Looking into deep reveals that we must disallow overriding privates now.
That way the test private_007.phpt is illegal and all current tests i developed
would pass (visibility tests are suspended of cause).

If you agree and the current implementation is the way to go i can comit
the private and protected tests (not including private_007 of cause which
is to be discussed).



6) zend_execute.c, line 2350 should be
if (!(EX(fbc)->op_array.fn_flags & (ZEND_ACC_PROTECTED | 
ZEND_ACC_PRIVATE))) {
instead of
if (EX(fbc)->op_array.fn_flags & ZEND_ACC_PUBLIC) {
as we allow (fn_flags & ZEND_FN_PPP_MASK) == 0 being matched to public as 
well.

marcus


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] huge memory usage in concat op, ZE2

[Tom]

hey there,

I'm using the cvs and ZE2, there seems to be some huge memory usage when
concatenating a string to a length over 262080 bytes, when the string
length gets to that size the malloc call inside
zend_mm_add_memory_block starts grabing memory 262168 bytes at a time,
every 8th concatenation (i'm concatenating 1 byte at a time).

anyone else seen this?

Tom


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php