[PHP-DEV] New function: bcpowmod()

[Sara Golemon]

I'd like to add a new function to the bcmath module.  It's very similar to
the bcpow() function except that it takes advantage of a fast
exponentiation method when used with a modulous.

Based on the function call into libbcmath to bc_raisemod() {bcpow() uses
bc_raise()}, it would seem to make the most sense to call the php version
of the function "bcpowmod()", but with the change in naming conventions
I'm more inclined to call it something closer to "bcmath_raisemod()" or
"bcmath_powmod()".

Am I overcomplicating things by agonizing over the name?

I'd love to hear your thoughts

-Pollita



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

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

[Leon Atkinson]

> > As Leon has suggested, why not just compile the variants into different
> > directories?  Say add a "cli/" (since the CLI is newer).  Only one
> directory
> > would go into the PATH (presumably).
> >
>
> That would also affect the ini setting for extension_dir. The default
> value is ./ indicating the same directory as the executable. I would
> prefer everthing to be in the same directory. This way I dont have to mess
> with php.ini when I have multiple installations on the same system.

Yes, that's true.  On the other hand, there's something strange about
php.ini's extension_dir and the extensions directory.  I found it a lot
easier and cleaner to wipe out that line from php.ini than move all the
extension up a directory.  (If you don't set extension_dir, it uses
"c:\php4\extensions".)  Wow, I guess I may have really stepped in it because
I was just about to suggest the php.ini default setting change. ;)

Leon



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

[PHP-DEV] I want to join php development team

[Fong Chun Man]

Dear sir/madam,

I want to join PHP development team , can you help me ? I 
am likly to join ,please contact me by my ICQ number is 164665800 or my 
e-mail :[EMAIL PROTECTED] ,I am waiting for your repeat . Thanks a 
lot .


Dennis

Lonely Christmas(³¯«³¨³)¡A­·ºå»P­·(Twins)¡A¯º¤¤¦³²\(·¨¤då_)...
Over 800 latest ringtones, only on Yahoo!

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

[Frank M. Kromann]

> 
> As Leon has suggested, why not just compile the variants into different
> directories?  Say add a "cli/" (since the CLI is newer).  Only one
directory
> would go into the PATH (presumably).
> 

That would also affect the ini setting for extension_dir. The default
value is ./ indicating the same directory as the executable. I would
prefer everthing to be in the same directory. This way I dont have to mess
with php.ini when I have multiple installations on the same system.

- Frank




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

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

[Preston L. Bannister]

Thanks Hartmut, that added some much needed clarity.

One comment I have to offer is the clutter you mention strongly suggests a
refactoring was needed to lift from common code the CLI or CGI affected
code.

Including or omitting entire modules appropriate for each environment is
also a pretty good argument for seperating the two variants.

As Leon has suggested, why not just compile the variants into different
directories?  Say add a "cli/" (since the CLI is newer).  Only one directory
would go into the PATH (presumably).

In the case of the Win32 variant, it looks like distinct DLLs (if using a
PHP DLL) might be a good idea.


-Original Message-
From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 09, 2002 8:44 AM

Shane Caraveo wrote:

> It would have been simple enough to combine
> cli into the cgi binary and be done with it, and I suggested as much
> that it should be done a very long time ago.
 >  I don't recall any major
 > reasons why it wasn't done, other than that cli has been experimental.

Way back CGI and CLI *did* share one binary (the CGI binary)
and the code was cluttered with code behaviour depending
on the environment the binary was called in.
The code with all these situation-dependant if() blocks
was a true mess getting even worse with every new
CGI- or CLI-only feature added.
Even worse: some features and extensions don't make sense
in a CGI (ncurses, gtk, pcntl, argc/argv parsing) while other
features belong into a CGI binary only.

The introduction of the seperate CLI binary or SAPI
happened for two reasons:
- removal of situation-dependant code in the CGI
   thus cleaning up the code base(as stated above)
- the ability to build the CLI alongside with
   *every* SAPI

So we can argue about binary naming, but definetly
*not* about about the CGI/CLI split.
No matter how similar the two binaries might look,
they *aren't*


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

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

[John Coggeshall]

>Please mention the name change at least in the NEWS file and 
>maybe php-cli could even output a readable error when beeing 
>called as cgi.

As I already said, we should put this in the message created at the end
of ./configure, in the release notes, in the news file, on the website,
and perhaps send a mass e-mail to everyone whom has ever worked with PHP
;)

John


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

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

[Harald Radi]

"Andrei Zmievski" <[EMAIL PROTECTED]> schrieb im Newsbeitrag
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...

> I am actually in favor of CLI executable being 'php'. If it's a problem
> on Windows, then we could possibly compromise and have the CGI version
> being called php.exe, but I think that it's important we keep it 'php'
> on UNIX.

reconfiguring iis to point to a new cgi is not a simple search&replace as it
is for other webservers, thus reconfiguring a site with many virtual
webservers can be a horrible task. anyways the administrator is free to
rename it back to php.exe, but in no case i would name both, the cli and the
cgi, php.exe, that will cause lots of confusion imho.

harald

> * Change is the only constant. *
what will acceleration be in that context then ?



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

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

[Frank M. Kromann]

> 
> Please mention the name change at least in the NEWS file and maybe
php-cli
> could even output a readable error when beeing called as cgi.

These are good points.

- Frank




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

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

[Christoph Grottolo]

> When installing a sapi for a web server i do it once and
> every time i update it i look if i have to change something in the
> setup - even file names. And  before updating anything i test the
> stuff on a non production system.

I hope (and I know) there's more evolution in php 4.3 than a senseless
rename of php.exe on windows.

I know you're right - but beeing right is not always the same as doing the
right thing.

Please mention the name change at least in the NEWS file and maybe php-cli
could even output a readable error when beeing called as cgi.

Christoph



-- 
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:35 09.12.2002, Christoph Grottolo wrote:

Hi
> "evolution" is not an excuse here. We want to use PHP on the
> command line and many people will do also. And we make the
> command line usage as easy as possible. Even if that requires
> some mauals being updated and marking some bug reports as
> bogus.
>
> marcus

If you really want to easy shell access to php on windows you can provide a
batch script for startup ("php-cli %1"). To save even more keystrokes, call
this script p.bat and let it guess the file extension of the script
itself("php-cli %1.php"). Like this you would have to type

p index

instead of

php index.php

and you'd save 6 more keystrokes - even without a bc break.

If you provide (a more advanced version of) this script with the win32
distribution as php.bat, everybody has what s(he) wants/needs.

Or is this really a philosophical question?

Christoph


Seems so :-)

If i want to use php on the command line i expect to call php.

But then the problem seems to be the administrators :-(

When installing a sapi for a web server i do it once and every time i
update it i look if i have to change something in the setup - even file names.
And  before updating anything i test the stuff on a non production system.
Therfore i do not see any administrator having a problem with renaming the
cgi version. Only unexpirienced admins not following above rules will put
themselves into trouble. But these can be helped and hopefully they learn
that on next upgrade schedule they RTFM. People only experimenting without
regard to manuals or with regard to outdated manuals are used to such problems.

And then: why the hell do i write manual pages?

marcus


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

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

[Christoph Grottolo]

Hi
> "evolution" is not an excuse here. We want to use PHP on the
> command line and many people will do also. And we make the
> command line usage as easy as possible. Even if that requires
> some mauals being updated and marking some bug reports as
> bogus.
>
> marcus

If you really want to easy shell access to php on windows you can provide a
batch script for startup ("php-cli %1"). To save even more keystrokes, call
this script p.bat and let it guess the file extension of the script
itself("php-cli %1.php"). Like this you would have to type

p index

instead of

php index.php

and you'd save 6 more keystrokes - even without a bc break.

If you provide (a more advanced version of) this script with the win32
distribution as php.bat, everybody has what s(he) wants/needs.

Or is this really a philosophical question?

Christoph



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

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

[Frank M. Kromann]

Hi,

How big can this problem be ? There is basically only a few ways to
install or upgrade PHP. 

1) Installing from source or binaries, in this case you would have to know
at least a minimum about how the system works and it is very easy to
rename php-cgi.exe to php.exe on these these systems.

2) Using an installer. In this case the installer should make sure the
correct file is used. This would be the way Win32 administrators are used
to install/upgrade systems anyway.

Some of the code I'm responsible for is used on more than 250 servers so I
made sure my install program (which is a php script) makes the changes
needed to match the version of PHP I use in each install/update..

- Frank

> On Mon, 9 Dec 2002, Marcus Börger wrote:
> 
> > >You are correct in your assumption that I have difficulty
> > >understanding the issues behind this change. After asking several
> > >times for an explanation, and after having gone over the archives
> > >to find some related discussion (and asking for pointers to that
> > >as well), I came to conclusion that this change is totally wrong.
> > >This change has nothing to do with fixing anything. It's breaking
> > >BC in a huge way, at the historical level, for the sake of a minor
> > >convenience for a very small group of users.
> > >
> > >Throwing lame excuses at it, like "it's evolution", doesn't cut
> > >it with me. I'm still at the same place. This is just wrong. It
> > >has nothing to do with stirring anything up.
> > >
> > >Regards
> > >Mike Robinson
> > 
> > What do you want then? For historical reasons you will allow
> > us only to introduce total new functionality and bug fixes? No
> > more improvements that will have any influence on some working
> > systems out there? Then i'll answer stay where you are and do
> > not do any version upgrade
> > 
> > "evolution" is not an excuse here. We want to use PHP on the
> > command line and many people will do also. And we make the
> > command line usage as easy as possible. Even if that requires
> > some mauals being updated and marking some bug reports as
> > bogus.
> 
> You couldn't write my thoughts down in a better way :)
> 
> Derick
> 
> -- 
> 
>
-
>  Derick Rethans http://derickrethans.nl/

>  PHP Magazine - PHP Magazine for Professionals  
http://php-mag.net/
>
-
> 
> 
> -- 
> 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

[Marcus Börger]

At 19:46 09.12.2002, Andrei Zmievski wrote:

On Mon, 09 Dec 2002, Andi Gutmans wrote:
> 
> Maybe phpsh would be a good idea for the name of the CLI? It wouldn't
> confuse ppl as much as php-cli
> 
>
> I'm really not that sure it makes sense to rename the CGI from php to
> php-cgi after such a long time. It's not as if we're breaking BC for the
> sake of adding very much needed functionality.
>
> Anyway, I'm -0 for the change and +0 to find a more suitable name for the
> CLI :)

I am actually in favor of CLI executable being 'php'. If it's a problem
on Windows, then we could possibly compromise and have the CGI version
being called php.exe, but I think that it's important we keep it 'php'
on UNIX.


I am strongly against having two different names for the same thing on 
different
machine targets. And Remeber: you can use the win executable by calling 'php'
without '.exe' as well.

marcus


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

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

[Andrei Zmievski]

On Mon, 09 Dec 2002, Andi Gutmans wrote:
> 
> Maybe phpsh would be a good idea for the name of the CLI? It wouldn't 
> confuse ppl as much as php-cli
> 
> 
> I'm really not that sure it makes sense to rename the CGI from php to 
> php-cgi after such a long time. It's not as if we're breaking BC for the 
> sake of adding very much needed functionality.
> 
> Anyway, I'm -0 for the change and +0 to find a more suitable name for the 
> CLI :)

I am actually in favor of CLI executable being 'php'. If it's a problem
on Windows, then we could possibly compromise and have the CGI version
being called php.exe, but I think that it's important we keep it 'php'
on UNIX.

-Andrei   http://www.gravitonic.com/
* Change is the only constant. *

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

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

[Leon Atkinson]

Would it be a tragedy to name both the CLI and CGI versions "php" on UNIX
and "php.exe" on Windows?

On UNIX, it doesn't seem like there'd be much confusion because "make
install" would put sapi/cli/php in /usr/local/bin and sapi/cgi/php in
/usr/local/apache/cgi-bin.

For the Windows distro, php.exe in the root of the archive could be the CGI
(as usual) and "sapi/php.exe" could be the CLI version.

It might be better to have sapi/cli/php.exe (along with parallel changes for
the DLLs in that directory).


Leon



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

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

[John Coggeshall]

>
>Maybe phpsh would be a good idea for the name of the CLI? It wouldn't 
>confuse ppl as much as php-cli
>

Why when I look at "phpsh" I think "Sushi"...

John


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

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

[Andi Gutmans]

At 05:34 PM 12/9/2002 +0100, Marcus Börger wrote:

At 14:52 09.12.2002, Mike Robinson wrote:

Wez Furlong writes:

On Sun, 8 Dec 2002, Mike Robinson wrote:
> > Sorry. There's just no way this should happen.

> But it has happened, and it's going stay this way.
>
> Now, if you don't have anything positive to contribute,
> please stop stirring up threads like this (again) without
> first understanding the issues behind them.  It just wastes
> time, which is better spent developing, bug fixing,
> documenting - doing just about anything else is more productive.

You are correct in your assumption that I have difficulty
understanding the issues behind this change. After asking several
times for an explanation, and after having gone over the archives
to find some related discussion (and asking for pointers to that
as well), I came to conclusion that this change is totally wrong.
This change has nothing to do with fixing anything. It's breaking
BC in a huge way, at the historical level, for the sake of a minor
convenience for a very small group of users.

Throwing lame excuses at it, like "it's evolution", doesn't cut
it with me. I'm still at the same place. This is just wrong. It
has nothing to do with stirring anything up.

Regards
Mike Robinson


What do you want then? For historical reasons you will allow
us only to introduce total new functionality and bug fixes? No
more improvements that will have any influence on some working
systems out there? Then i'll answer stay where you are and do
not do any version upgrade

"evolution" is not an excuse here. We want to use PHP on the
command line and many people will do also. And we make the
command line usage as easy as possible. Even if that requires
some mauals being updated and marking some bug reports as
bogus.



Maybe phpsh would be a good idea for the name of the CLI? It wouldn't 
confuse ppl as much as php-cli


I'm really not that sure it makes sense to rename the CGI from php to 
php-cgi after such a long time. It's not as if we're breaking BC for the 
sake of adding very much needed functionality.

Anyway, I'm -0 for the change and +0 to find a more suitable name for the 
CLI :)

Andi


--
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:44 09.12.2002, Hartmut Holzgraefe wrote:

Shane Caraveo wrote:


It would have been simple enough to combine cli into the cgi binary and 
be done with it, and I suggested as much that it should be done a very 
long time ago.
>  I don't recall any major
> reasons why it wasn't done, other than that cli has been experimental.

Way back CGI and CLI *did* share one binary (the CGI binary)
and the code was cluttered with code behaviour depending
on the environment the binary was called in.
The code with all these situation-dependant if() blocks
was a true mess getting even worse with every new
CGI- or CLI-only feature added.
Even worse: some features and extensions don't make sense
in a CGI (ncurses, gtk, pcntl, argc/argv parsing) while other
features belong into a CGI binary only.

The introduction of the seperate CLI binary or SAPI
happened for two reasons:
- removal of situation-dependant code in the CGI
  thus cleaning up the code base(as stated above)
- the ability to build the CLI alongside with
  *every* SAPI

So we can argue about binary naming, but definetly
*not* about about the CGI/CLI split.
No matter how similar the two binaries might look,
they *aren't*



Thanks for the explanationi totally agree here with the exception
being the name of the cli executable :-)

marcus



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

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

[Hartmut Holzgraefe]

Shane Caraveo wrote:


It would have been simple enough to combine 
cli into the cgi binary and be done with it, and I suggested as much 
that it should be done a very long time ago. 
>  I don't recall any major
> reasons why it wasn't done, other than that cli has been experimental.

Way back CGI and CLI *did* share one binary (the CGI binary)
and the code was cluttered with code behaviour depending
on the environment the binary was called in.
The code with all these situation-dependant if() blocks
was a true mess getting even worse with every new
CGI- or CLI-only feature added.
Even worse: some features and extensions don't make sense
in a CGI (ncurses, gtk, pcntl, argc/argv parsing) while other
features belong into a CGI binary only.

The introduction of the seperate CLI binary or SAPI
happened for two reasons:
- removal of situation-dependant code in the CGI
  thus cleaning up the code base(as stated above)
- the ability to build the CLI alongside with
  *every* SAPI

So we can argue about binary naming, but definetly
*not* about about the CGI/CLI split.
No matter how similar the two binaries might look,
they *aren't*

--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe
Email: [EMAIL PROTECTED]
Tel.:  +49-711-99091-77


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

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

[Derick Rethans]

On Mon, 9 Dec 2002, Marcus Börger wrote:

> >You are correct in your assumption that I have difficulty
> >understanding the issues behind this change. After asking several
> >times for an explanation, and after having gone over the archives
> >to find some related discussion (and asking for pointers to that
> >as well), I came to conclusion that this change is totally wrong.
> >This change has nothing to do with fixing anything. It's breaking
> >BC in a huge way, at the historical level, for the sake of a minor
> >convenience for a very small group of users.
> >
> >Throwing lame excuses at it, like "it's evolution", doesn't cut
> >it with me. I'm still at the same place. This is just wrong. It
> >has nothing to do with stirring anything up.
> >
> >Regards
> >Mike Robinson
> 
> What do you want then? For historical reasons you will allow
> us only to introduce total new functionality and bug fixes? No
> more improvements that will have any influence on some working
> systems out there? Then i'll answer stay where you are and do
> not do any version upgrade
> 
> "evolution" is not an excuse here. We want to use PHP on the
> command line and many people will do also. And we make the
> command line usage as easy as possible. Even if that requires
> some mauals being updated and marking some bug reports as
> bogus.

You couldn't write my thoughts down in a better way :)

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
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 14:52 09.12.2002, Mike Robinson wrote:

Wez Furlong writes:

On Sun, 8 Dec 2002, Mike Robinson wrote:
> > Sorry. There's just no way this should happen.

> But it has happened, and it's going stay this way.
>
> Now, if you don't have anything positive to contribute,
> please stop stirring up threads like this (again) without
> first understanding the issues behind them.  It just wastes
> time, which is better spent developing, bug fixing,
> documenting - doing just about anything else is more productive.

You are correct in your assumption that I have difficulty
understanding the issues behind this change. After asking several
times for an explanation, and after having gone over the archives
to find some related discussion (and asking for pointers to that
as well), I came to conclusion that this change is totally wrong.
This change has nothing to do with fixing anything. It's breaking
BC in a huge way, at the historical level, for the sake of a minor
convenience for a very small group of users.

Throwing lame excuses at it, like "it's evolution", doesn't cut
it with me. I'm still at the same place. This is just wrong. It
has nothing to do with stirring anything up.

Regards
Mike Robinson


What do you want then? For historical reasons you will allow
us only to introduce total new functionality and bug fixes? No
more improvements that will have any influence on some working
systems out there? Then i'll answer stay where you are and do
not do any version upgrade

"evolution" is not an excuse here. We want to use PHP on the
command line and many people will do also. And we make the
command line usage as easy as possible. Even if that requires
some mauals being updated and marking some bug reports as
bogus.

marcus


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

[PHP-DEV] RC3 plans

[Andrei Zmievski]

While there are some opinions that RC3 should be put out in a week or
so, I disagree. I'd like to release it on Wednesday at the latest,
and before then have everyone trying to either fix the critical bugs
that are in the system, or at least recategorize them if no one is going
to bother to fix them.

-Andrei   http://www.gravitonic.com/

"Then again, E=mc^2 may only be a local phenomenon."
  -- Einstein

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

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

[Joao Prado Maia]

On Mon, 9 Dec 2002, Mike Robinson wrote:

> Wez Furlong writes:
>
> On Sun, 8 Dec 2002, Mike Robinson wrote:
> > > Sorry. There's just no way this should happen.
>
> > But it has happened, and it's going stay this way.
> >
> > Now, if you don't have anything positive to contribute,
> > please stop stirring up threads like this (again) without
> > first understanding the issues behind them.  It just wastes
> > time, which is better spent developing, bug fixing,
> > documenting - doing just about anything else is more productive.
>
> You are correct in your assumption that I have difficulty
> understanding the issues behind this change. After asking several
> times for an explanation, and after having gone over the archives
> to find some related discussion (and asking for pointers to that
> as well), I came to conclusion that this change is totally wrong.
> This change has nothing to do with fixing anything. It's breaking
> BC in a huge way, at the historical level, for the sake of a minor
> convenience for a very small group of users.
>
> Throwing lame excuses at it, like "it's evolution", doesn't cut
> it with me. I'm still at the same place. This is just wrong. It
> has nothing to do with stirring anything up.
>

For whatever it's worth, I totally agree with you on this one, Mike. I
just hope more people would come out and be vocal about this issue.

Dear god, just imagine the amount of reports about their installations not
working after upgrading to 4.3...

Joao


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

[PHP-DEV] I want to join PHP development team

[Fong Chun Man]

Dear sir/madam,

 I want to join PHP development team , can you help me ? I 
am likly to join ,please contact me by my ICQ number is 164665800 or my 
e-mail :[EMAIL PROTECTED] ,I am waiting for your repeat . Thanks a 
lot .


Dennis

Lonely Christmas(³¯«³¨³)¡A­·ºå»P­·(Twins)¡A¯º¤¤¦³²\(·¨¤då_)...
Over 800 latest ringtones, only on Yahoo!

Re: [PHP-DEV] 4.3 when?

[Dan Kalowsky]

Actually I'd say don't roll 4.3 until the New Year.  You're going to 
get the holiday break for many students coming up in a few days.  This 
will give them (me) a large amount of free time to get back to hacking 
and checking source/bugs.

More than that, I tend to think releasing stuff near holidays is a bad 
idea... no one around to fix things that go really bad, etc etc.

On Monday, December 9, 2002, at 04:24 AM, Andi Gutmans wrote:

Hi,

I'd like to start working towards a beta of ZE2 but it seems that 4.3 
is still lingering and I'd like to wait until after 4.3.
What's happening with that? Shouldn't we get it out before Christmas?
If any bad bugs creep in that'd mean we can use the relatively silent 
2-3 weeks following Christmas to fix them.

Andi


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

>---<
Dan Kalowsky"Momma take this badge offa me,
http://www.deadmime.org/~dankI can't use it anymore."
[EMAIL PROTECTED]- "Knockin on Heavens Door",
[EMAIL PROTECTED]Bob Dylan


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

Re: [PHP-DEV] 4.3 when?

[Andrei Zmievski]

On Mon, 09 Dec 2002, Wez Furlong wrote:
> I have a patch from Melvyn for streams under *BSD systems, and the
> critical bugs should also be fixed, particularly 20539, 19919 and 19292.
> 
> [15209] Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x
> [19292] random error: open_basedir restriction in effect. File is in wrong directory
> [19919] segmentation violation in sapi_apache_header_handler, mod_php4.c  line 208
> [20109] iplanet 6 core dump w/NSAPI load
> [20190] Random mem corruption: zend_get_executed_filename() mismatch
> [20467] Buffer overflow returning binary (sybase)
> [20539] PHP CLI Segmentation Fault
> [20802] memory limit crash

Plus our QA team is not quite what it used to be and Derick is gone for
a couple of days. We were planning to roll RC3 with a short test cycle,
but it would be good to do that with the abovementioned bugs fixed. If
we don't fix them, then we need to bear responsibility for them showing
up in 4.3.0.

-Andrei   http://www.gravitonic.com/

"Later in this talk, I intend to define
 the universe and give three examples." -- Larry Wall

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

[PHP-DEV] I want to join php development team

[Fong Chun Man]

Dear sir/madam,

 I want to join PHP development team , can you help me ? I 
am likly to join , My ICQ number is 164665800 , please contact me by my e-mail 
:[EMAIL PROTECTED] ,I am waiting for your repeat . Thanks a lot .



Dennis


Lonely Christmas(³¯«³¨³)¡A­·ºå»P­·(Twins)¡A¯º¤¤¦³²\(·¨¤då_)...
Over 800 latest ringtones, only on Yahoo!

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

[Mike Robinson]

Wez Furlong writes:

On Sun, 8 Dec 2002, Mike Robinson wrote:
> > Sorry. There's just no way this should happen.

> But it has happened, and it's going stay this way.
> 
> Now, if you don't have anything positive to contribute, 
> please stop stirring up threads like this (again) without 
> first understanding the issues behind them.  It just wastes 
> time, which is better spent developing, bug fixing, 
> documenting - doing just about anything else is more productive.

You are correct in your assumption that I have difficulty
understanding the issues behind this change. After asking several
times for an explanation, and after having gone over the archives
to find some related discussion (and asking for pointers to that
as well), I came to conclusion that this change is totally wrong.
This change has nothing to do with fixing anything. It's breaking
BC in a huge way, at the historical level, for the sake of a minor
convenience for a very small group of users.

Throwing lame excuses at it, like "it's evolution", doesn't cut
it with me. I'm still at the same place. This is just wrong. It
has nothing to do with stirring anything up. 

Regards
Mike Robinson



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

Re: [PHP-DEV] bugs.php.net categories for PECL modules

[Christian Stocker]

On Mon, 2002-12-09 at 13:12, Jani Taskinen wrote:
> On 9 Dec 2002, Christian Stocker wrote:
> 
> >Hi
> >
> >as PECL is getting more and more attention, it would be nice, if they
> >had their own categories in bugs.php.net. There's category "PEAR", but I
> >don't think this is the right place. The question for me is just, if
> >they should be in a PECL topcategory or just in the appropriate other
> >categories (in our case, should imagick be in PECL/imagick or in
> >Graphics/imagick?)
> >
> >What do others think?
> 
> 
> It needs it's own bug system. Please don't add anymore 
> categories in the existing one, it's full.

I don't mind having its own bug system, but

1) Do user know, if it's in PECL or not?

2) As more and more extension go into PECL (someday all), this system
will be as full as todays... (except maybe the core modules like
Scripting Engine et al)

chregu, just some thoughts throwing around..


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

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

[Shane Caraveo]

Jani Taskinen wrote:

On Mon, 9 Dec 2002, Shane Caraveo wrote:



Simply because calling the command line interface should be easy - as easy
as calling awk or perl or whatever. Every server api module like cgi must be
installed, so the name does not matter there. But having long names for
command line utils is a bad idea.

marcus




Well, fortunately I never have time for qa, handling bugs, etc. etc. so
I wont have to deal with the backlash that this name change **WILL**
cause.  I feel sorry for those who have the time to deal with it, as
that will be about all they will deal with, rather than handling more
important bugs and issues.  Basicly, the namechange goes against several



Don't worry, we'll make some quick-resolve for it too.
We didn't get overwhelmed by that register_globals issue either.
(like some people thought we would :)



years of history in php, tons of documentation, general community
knowledge, etc., and top it off with the fact that in reality, probably
less than 1 percent of users use php as a command line language.



It's evolution. :) And we do hope that the amount of people using 
PHP on command line increases. Besides, having the "php-cgi" binary
makes it very clear what it is about. But naming the CLI binary 
"php-cli" definately does not.

I'm actually a bit uncertain why we actually have separate binaries.
(or I've forgot why they were separated..anyone?)
 
--Jani

"evolution" doesn't cut it.  It would have been simple enough to combine 
cli into the cgi binary and be done with it, and I suggested as much 
that it should be done a very long time ago.  I don't recall any major 
reasons why it wasn't done, other than that cli has been experimental. 
"evolution" would have been to fix the executable we have had, rather 
than creating multiple executables that do essentialy the same thing, 
and this issue would have been avoided altogether.
Shane




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

Re: [PHP-DEV] 4.3 when?

[Wez Furlong]

I have a patch from Melvyn for streams under *BSD systems, and the
critical bugs should also be fixed, particularly 20539, 19919 and 19292.

[15209] Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x
[19292] random error: open_basedir restriction in effect. File is in wrong directory
[19919] segmentation violation in sapi_apache_header_handler, mod_php4.c  line 208
[20109] iplanet 6 core dump w/NSAPI load
[20190] Random mem corruption: zend_get_executed_filename() mismatch
[20467] Buffer overflow returning binary (sybase)
[20539] PHP CLI Segmentation Fault
[20802] memory limit crash

--Wez.

On Mon, 9 Dec 2002, Andi Gutmans wrote:

> Any idea how many more bugs are waiting to be addressed?
>
> Andi
>
> At 12:36 PM 12/9/2002 +, Wez Furlong wrote:
> >Because we are still finding and fixing bugs in the RCs.
> >
> >--Wez.
> >
> >On Mon, 9 Dec 2002, Andi Gutmans wrote:
> >
> > > Now that still leave my original question about 4.3. Why the hell aren't we
> > > rolling it?
> >
> >
> >
> >--
> >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 Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c

[Sebastian Bergmann]

Sebastian Bergmann wrote:
> sebastian   Mon Dec  9 06:45:47 2002 EDT
>
>   Modified files:
> /php4/sapi/cli  php_cli.c
>   Log:
>   Fix build.
>
>
> Index: php4/sapi/cli/php_cli.c
> diff -u php4/sapi/cli/php_cli.c:1.54 php4/sapi/cli/php_cli.c:1.55
> --- php4/sapi/cli/php_cli.c:1.54Sun Dec  8 05:23:50 2002
> +++ php4/sapi/cli/php_cli.c Mon Dec  9 06:45:46 2002
> @@ -23,6 +23,7 @@
>  #include "php.h"
>  #include "php_globals.h"
>  #include "php_variables.h"
> +#include "zend_hash.h"
>  #include "zend_modules.h"
>
>  #include "SAPI.h"

  I committed the patch above because I was getting a

php_cli.obj: error LNK2001:
Unresolved external symbol __imp___zend_hash_init

  error when building sapi/cli on Win32. Adding the

#include "zend_hash.h"

  to php4/sapi/cli/php_cli.c fixed the problem, so I committed.

  But now I'm getting the same error. Any idea why?

  Confused,
Sebastian

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

Re: [PHP-DEV] 4.3 when?

[Andi Gutmans]

Any idea how many more bugs are waiting to be addressed?

Andi

At 12:36 PM 12/9/2002 +, Wez Furlong wrote:

Because we are still finding and fixing bugs in the RCs.

--Wez.

On Mon, 9 Dec 2002, Andi Gutmans wrote:

> Now that still leave my original question about 4.3. Why the hell aren't we
> rolling it?



--
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] 4.3 when?

[Wez Furlong]

Because we are still finding and fixing bugs in the RCs.

--Wez.

On Mon, 9 Dec 2002, Andi Gutmans wrote:

> Now that still leave my original question about 4.3. Why the hell aren't we
> rolling it?



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

Re: [PHP-DEV] 4.3 when?

[Andi Gutmans]

At 02:24 PM 12/9/2002 +0200, Jani Taskinen wrote:

On Mon, 9 Dec 2002, Andi Gutmans wrote:

>At 02:13 PM 12/9/2002 +0200, Jani Taskinen wrote:
>>On Mon, 9 Dec 2002, Andi Gutmans wrote:
>>
>> >Hi,
>> >
>> >I'd like to start working towards a beta of ZE2 but it seems that 4.3 is
>> >still lingering and I'd like to wait until after 4.3.
>> >What's happening with that? Shouldn't we get it out before Christmas?
>>
>> Try checking the "Verified" and "Critical" bugs for e.g. "Scripting
>> Engine Problem"
>> once and a while..
>
>That's the answer to my question? I don't see any bug there which is a show
>stopper for 4.3.

Heh..so it's a good reason not to bother fixing/looking into them?


I have looked at some of them in the past and some of them I just haven't 
had time to look at. You did succeed in getting me to look at them again 
but it still doesn't mean they are show stoppers. As far as the engine is 
concerned 4.3 can roll.
No new bugs since 4.2.x have been introduced as far as I know.

I thought bugs marked as "Critical" were supposed to be fixed before
release?


I didn't mark them as critical. I don't think any of those are show 
stoppers. I suggest before people mark stuff as critical they check with 
the author if it makes sense. Many releases in the past have gone out with 
what you call "critical" bugs. Or we can have a new category "show stopper" 
where the difference between critical and show stopper is communication and 
agreement with the author.

Now that still leave my original question about 4.3. Why the hell aren't we 
rolling it?

Andi


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

Re: [PHP-DEV] 4.3 when?

[Jani Taskinen]

On Mon, 9 Dec 2002, Andi Gutmans wrote:

>At 02:13 PM 12/9/2002 +0200, Jani Taskinen wrote:
>>On Mon, 9 Dec 2002, Andi Gutmans wrote:
>>
>> >Hi,
>> >
>> >I'd like to start working towards a beta of ZE2 but it seems that 4.3 is
>> >still lingering and I'd like to wait until after 4.3.
>> >What's happening with that? Shouldn't we get it out before Christmas?
>>
>> Try checking the "Verified" and "Critical" bugs for e.g. "Scripting 
>> Engine Problem"
>> once and a while..
>
>That's the answer to my question? I don't see any bug there which is a show 
>stopper for 4.3.

Heh..so it's a good reason not to bother fixing/looking into them?
I thought bugs marked as "Critical" were supposed to be fixed before
release? 

--Jani



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

Re: [PHP-DEV] 4.3 when?

[Andi Gutmans]

At 02:13 PM 12/9/2002 +0200, Jani Taskinen wrote:

On Mon, 9 Dec 2002, Andi Gutmans wrote:

>Hi,
>
>I'd like to start working towards a beta of ZE2 but it seems that 4.3 is
>still lingering and I'd like to wait until after 4.3.
>What's happening with that? Shouldn't we get it out before Christmas?

Try checking the "Verified" and "Critical" bugs for e.g. "Scripting 
Engine Problem"
once and a while..

That's the answer to my question? I don't see any bug there which is a show 
stopper for 4.3.

Andi


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

Odp: [PHP-DEV] 'include' function

[Krzysztof Socki]

> function ala() {
>include file.php;
> }
>
I want neither to explicitly include any file nor to define any function in
my script. My point is to give access to the source to the user but to hide
the script's real functionality. Do you have any experience with modifying
PHP parser, specifically adding new language constructs? Thanks.

KS.



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

Re: [PHP-DEV] 4.3 when?

[Jani Taskinen]

On Mon, 9 Dec 2002, Andi Gutmans wrote:

>Hi,
>
>I'd like to start working towards a beta of ZE2 but it seems that 4.3 is 
>still lingering and I'd like to wait until after 4.3.
>What's happening with that? Shouldn't we get it out before Christmas?

Try checking the "Verified" and "Critical" bugs for e.g. "Scripting Engine Problem"
once and a while..

--Jani


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

Re: [PHP-DEV] bugs.php.net categories for PECL modules

[Jani Taskinen]

On 9 Dec 2002, Christian Stocker wrote:

>Hi
>
>as PECL is getting more and more attention, it would be nice, if they
>had their own categories in bugs.php.net. There's category "PEAR", but I
>don't think this is the right place. The question for me is just, if
>they should be in a PECL topcategory or just in the appropriate other
>categories (in our case, should imagick be in PECL/imagick or in
>Graphics/imagick?)
>
>What do others think?


It needs it's own bug system. Please don't add anymore 
categories in the existing one, it's full.
 
--Jani



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

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

[Jani Taskinen]

On Mon, 9 Dec 2002, Shane Caraveo wrote:

>
>> 
>> Simply because calling the command line interface should be easy - as easy
>> as calling awk or perl or whatever. Every server api module like cgi must be
>> installed, so the name does not matter there. But having long names for
>> command line utils is a bad idea.
>> 
>> marcus
>> 
>> 
>
>Well, fortunately I never have time for qa, handling bugs, etc. etc. so
>I wont have to deal with the backlash that this name change **WILL**
>cause.  I feel sorry for those who have the time to deal with it, as
>that will be about all they will deal with, rather than handling more
>important bugs and issues.  Basicly, the namechange goes against several

Don't worry, we'll make some quick-resolve for it too.
We didn't get overwhelmed by that register_globals issue either.
(like some people thought we would :)

>years of history in php, tons of documentation, general community
>knowledge, etc., and top it off with the fact that in reality, probably
>less than 1 percent of users use php as a command line language.

It's evolution. :) And we do hope that the amount of people using 
PHP on command line increases. Besides, having the "php-cgi" binary
makes it very clear what it is about. But naming the CLI binary 
"php-cli" definately does not.

I'm actually a bit uncertain why we actually have separate binaries.
(or I've forgot why they were separated..anyone?)
 
--Jani



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

[PHP-DEV] bugs.php.net categories for PECL modules

[Christian Stocker]

Hi

as PECL is getting more and more attention, it would be nice, if they
had their own categories in bugs.php.net. There's category "PEAR", but I
don't think this is the right place. The question for me is just, if
they should be in a PECL topcategory or just in the appropriate other
categories (in our case, should imagick be in PECL/imagick or in
Graphics/imagick?)

What do others think?

chregu


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

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

[Wez Furlong]

On Sun, 8 Dec 2002, Mike Robinson wrote:
> 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.

Any sysadmin upgrading to a new release should read the release notes,
or be fired. (It's quite simple)

There are a number of things to review before upgrading to PHP 4.3.
One of the big things to note is that the CGI version of PHP has not
been functioning correctly for some time now (see Shane's recent
thread), and that 4.3 will finally correct this issue.

> > 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.

It's called progress.  We try to retain BC as much as possible and as
much as makes sense, but sometimes we have to make some progress.
That's what we are doing here.

In case you haven't noticed, a lot of work is being done to elevate PHP
beyond the status of a web-only language; this is a positive step in
that direction.

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

CGI was broken anyhow - this is going to *fix* a lot of setups,
regardless of "saving a few keystrokes".

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

But it has happened, and it's going stay this way.

Now, if you don't have anything positive to contribute, please stop
stirring up threads like this (again) without first understanding the
issues behind them.  It just wastes time, which is better spent
developing, bug fixing, documenting - doing just about anything else is
more productive.

--Wez.


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

[PHP-DEV] 4.3 when?

[Andi Gutmans]

Hi,

I'd like to start working towards a beta of ZE2 but it seems that 4.3 is 
still lingering and I'd like to wait until after 4.3.
What's happening with that? Shouldn't we get it out before Christmas?
If any bad bugs creep in that'd mean we can use the relatively silent 2-3 
weeks following Christmas to fix them.

Andi


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

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

[Derick Rethans]

On Sun, 8 Dec 2002, Mike Robinson 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.
> 
> 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.

It means I have to type four more characters, no thanks. (Just wanting 
to show that it's _your_ opinion to have it called php-cli.exe, which 
doesn't match my opinion).

Derick
-- 
-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


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

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

[Shane Caraveo]

Simply because calling the command line interface should be easy - as easy
as calling awk or perl or whatever. Every server api module like cgi must be
installed, so the name does not matter there. But having long names for
command line utils is a bad idea.

marcus




Well, fortunately I never have time for qa, handling bugs, etc. etc. so
I wont have to deal with the backlash that this name change **WILL**
cause.  I feel sorry for those who have the time to deal with it, as
that will be about all they will deal with, rather than handling more
important bugs and issues.  Basicly, the namechange goes against several
years of history in php, tons of documentation, general community
knowledge, etc., and top it off with the fact that in reality, probably
less than 1 percent of users use php as a command line language.

Shane



--
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]

yup, works for me, thanks andi.

Andi Gutmans <[EMAIL PROTECTED]> wrote: 
> 
> Tom,
> 
> This should be fixed now. Please update your Zend CVS and let me know if it 
> works for you.
> 
> Andi
> 
> At 08:06 PM 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
> 
> 
> -- 
> 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] FR: echo line

[Derick Rethans]

On 7 Dec 2002, Jari Vuoksenranta wrote:

> I have a feature request: I'd like to have '#' comment like
> macro which would expand "_ foo" to "?> foo\n 
> Has this been requested before?  If so, why it wasn't implented?

I would personally kick the butt of the guy who adds this to CVS.
This is totally unreadable and sooo perlish.

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


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

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

[Derick Rethans]

On Sat, 7 Dec 2002, Daniel Lorch wrote:

> Hi Andi,
> 
> > Are you sure you should be using malloc()/free() and not emalloc()/efree()?
> > Also please use strlcpy() instead of strncpy(). (Weird I mentioned it twice 
> > in one day :)
> > http://www.courtesan.com/todd/papers/strlcpy.html
> 
> Probably there are even more things broken in my patch :) I'm quite new to C
> and I'm happy it works without segfaulting. strlcpy looks interesting and
> I'll read through the link as soon as I find some free time.
> 
> Oh, this patch is explicitly *NOT* meant to go into the main branch. It's
> just an additional patch for whoever needs it, sorry for not pointing this
> out more explicitly.

If it would be going into CVS I think we need some way to not always 
have this on.

Derick

-- 

-
 Derick Rethans http://derickrethans.nl/ 
 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
-


-- 
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]

Tom,

This should be fixed now. Please update your Zend CVS and let me know if it 
works for you.

Andi

At 08:06 PM 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


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

[PHP-DEV] New PECL Radius

[Michael Bretterklieber]

Hi,

I added the new PECL radius to the cvs repository, now I have some 
questions:

My next todo is to write the documentation. This PECL follows the php 
source-code-style and not the PEAR source-code-style.
What about with the documentation of PECL's, do I have to write the docu 
for PEAR or for PHP or for both?

Another ToDo is to write PEAR classes that wrap the PECL functions, my 
questions is if I have autom. the permission to put my classes into the 
cvs repository under pear/Radius (I already have a cvs account)?

Who is responsible for Branches and Tag's in PECL's?
Am I allowed to set tags and make branches?
Has PEAR the same Tags as PHP?

If I finished all my ToDo's what must I do that this extension is autom. 
contributed with each new PHP release?

bye,
--
--- --
Michael Bretterklieber		- [EMAIL PROTECTED]	
JAWA Management Software GmbH 	- http://www.jawa.at
Liebenauer Hauptstr. 200	-- privat 
A-8041 GRAZ			GSM: ++43-(0)676-93 96 698		
Tel: ++43-(0)316-403274-12	E-mail:   [EMAIL PROTECTED]
Fax: ++43-(0)316-403274-10 	http://www.inode.at/mbretter
--- --
"...the number of UNIX installations has grown to 10, with more expected..."
	   - Dennis Ritchie and Ken Thompson, June 1972


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