[PHP-DEV] [PATCH] --enable-inline-optimization => --disable-inline-optimization

2002-04-20 Thread Yasuo Ohgaki
Hi all, It seems we are better have --enable-inline-optimization option after all. Andi told some "inline" directive has removed to make zend_execute.c work well with -O2. (I don't have problem with -O3 also) How about make inline optimization as default option? and have a --disable-inline-opti

[PHP-DEV] Re: factorizing pgsql code

2002-04-20 Thread Yasuo Ohgaki
Sascha Schumann wrote: > Here is a patch which aims at reducing the redundant code in > pgsql.c (-685, +211 lines). > > http://apache.org/~sascha/pgsql.diff > > It also significantly reduces the number of memcpy's, > sprintf's and so on and immensily improves readability of t

Re: [PHP-DEV] CVS Account Request: peter

2002-04-20 Thread Peter
Hello Marcus, PHP functions regularly change from the old system of returning a negative value to using false. The PHP documentation for sockets show all the sockets functions using a negative number. In 4.1.12 there are at least two functions changed to return false for an error. I could upda

[PHP-DEV] Re: REMOVING Inline optimization option

2002-04-20 Thread Yasuo Ohgaki
Sascha Schumann wrote: > It ought not to be removed. > > Reason? The GCC optimizer easily takes a couple of hundred > mega bytes of memory to compile zend_execute.c depending on > the optimization level and the architecture. That is pretty > bad, especially when administrator

[PHP-DEV] Re: factorizing pgsql code

2002-04-20 Thread Yasuo Ohgaki
Sascha Schumann wrote: > Here is a patch which aims at reducing the redundant code in > pgsql.c (-685, +211 lines). > > http://apache.org/~sascha/pgsql.diff > > It also significantly reduces the number of memcpy's, > sprintf's and so on and immensily improves readability of t

[PHP-DEV] Re: REMOVING Inline optimization option

2002-04-20 Thread Sascha Schumann
It ought not to be removed. Reason? The GCC optimizer easily takes a couple of hundred mega bytes of memory to compile zend_execute.c depending on the optimization level and the architecture. That is pretty bad, especially when administrators have not set up process limit

[PHP-DEV] factorizing pgsql code

2002-04-20 Thread Sascha Schumann
Here is a patch which aims at reducing the redundant code in pgsql.c (-685, +211 lines). http://apache.org/~sascha/pgsql.diff It also significantly reduces the number of memcpy's, sprintf's and so on and immensily improves readability of the affected parts of the code.

[PHP-DEV] PHP License

2002-04-20 Thread Edin Kadribasic
Should article 6 of the PHP license be updated to reflect the recent changes in the Zend License? Edin -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Shared PHP library

2002-04-20 Thread Stig S. Bakken
On Sat, 2002-04-20 at 17:53, Andrei Zmievski wrote: > I would like to know if we can modify the build process to build and > install a PHP library, without any SAPI modules, so that libphp.a and > libphp.so get installed in the appropriate locations. I need this in > order to develop PHP support f

Re: [PHP-DEV] REMOVING Inline optimization option

2002-04-20 Thread Stig S. Bakken
On Sat, 2002-04-20 at 21:55, Andi Gutmans wrote: > At 23:15 20/04/2002 +0900, Yasuo Ohgaki wrote: > >Shall we remove --enable-inline-optimization option? > >Since it does not do anything for a long time, AFAIK. > >(Or does it actually work under some systems?) > > > >Any comments? > > Does removi

Re: [PHP-DEV] RFI: Request for Interfaces

2002-04-20 Thread Sterling Hughes
> Following on from my RFC about an interface mechanism, what we really > need is some brainstorming on what interfaces we need or would like to > have in PHP. I'm aiming at PHP 5. > > The following concepts have already been mentioned either by myself or > others as being something we'd like to

[PHP-DEV] RFI: Request for Interfaces

2002-04-20 Thread Wez Furlong
Following on from my RFC about an interface mechanism, what we really need is some brainstorming on what interfaces we need or would like to have in PHP. I'm aiming at PHP 5. The following concepts have already been mentioned either by myself or others as being something we'd like to see in PHP:

Re: [PHP-DEV] Inline optimization

2002-04-20 Thread Andi Gutmans
At 23:18 20/04/2002 +0900, Yasuo Ohgaki wrote: >Andi Gutmans wrote: >>> >>>What about leaving -O2 but adding -finline-functions >> >>-O2 will inline the functions marked as inline. That should be good >>enough because we inline where it's important. >>I wouldn't go with -O3 nor with -finline-func

Re: [PHP-DEV] REMOVING Inline optimization option

2002-04-20 Thread Andi Gutmans
At 23:15 20/04/2002 +0900, Yasuo Ohgaki wrote: >Shall we remove --enable-inline-optimization option? >Since it does not do anything for a long time, AFAIK. >(Or does it actually work under some systems?) > >Any comments? Does removing mean that if someone specifies it configure will continue hap

Re: [PHP-DEV] Re: Bug #16687 Updated: Constants not being interpreted in "variable variables"

2002-04-20 Thread Andi Gutmans
At 20:33 20/04/2002 +0300, Zeev Suraski wrote: >It applies, to a degree. If you directly reference $GLOBALS anywhere in >your function, you can also reference it indirectly. If you don't, >however, indirect reference won't work. > >E.g., > >function foo() >{ > $foo = "GLOBALS"; >

Re: [PHP-DEV] seg fault in recode.c on line 80

2002-04-20 Thread Magnus Määttä
On Sat, 20 Apr 2002 20:32:22 +0200 (CEST) [EMAIL PROTECTED] wrote: > Hello again, > > I comitted a patch to the CVS, can you retest? It worked now.. > Derick > > On Sat, 20 Apr 2002, Magnus Määttä wrote: > > > With Apache 2.0.36-dev, newest PHP cvs.. > > > > Starting program: /usr/local/www

Re: [PHP-DEV] seg fault in recode.c on line 80

2002-04-20 Thread Magnus Määttä
On Sat, 20 Apr 2002 20:32:22 +0200 (CEST) [EMAIL PROTECTED] wrote: Yes, ill test it now.. > Hello again, > > I comitted a patch to the CVS, can you retest? > > Derick > > On Sat, 20 Apr 2002, Magnus Määttä wrote: > > > With Apache 2.0.36-dev, newest PHP cvs.. > > > > Starting program: /usr/

Re: [PHP-DEV] seg fault in recode.c on line 80

2002-04-20 Thread derick
Hello again, I comitted a patch to the CVS, can you retest? Derick On Sat, 20 Apr 2002, Magnus Määttä wrote: > With Apache 2.0.36-dev, newest PHP cvs.. > > Starting program: /usr/local/www/httpd2/bin/httpd > [New Thread 1024 (LWP 9606)] > > Program received signal SIGSEGV, Segmentation fault

[PHP-DEV] RFC: PHP Interfaces

2002-04-20 Thread Wez Furlong
[This is quite long, so grab a cup/can/bottle/glass of your favourite beverage and get comfortable] Following on from the recent talk about streams and filters, I've been thinking about how useful it would be for extension authors to have some kind of lightweight interface mechanism. I'm not talk

Re: [PHP-DEV] seg fault in recode.c on line 80

2002-04-20 Thread derick
Hello, I can make a quick patch, but not test it. Are you waillin to try my patch? Derick On Sat, 20 Apr 2002 [EMAIL PROTECTED] wrote: > Hello, > > it's clear why this crashes... the globals are not initialized. And from: > php_recode.h: > > /* Checking for thread safety and issue warning

Re: [PHP-DEV] seg fault in recode.c on line 80

2002-04-20 Thread derick
Hello, it's clear why this crashes... the globals are not initialized. And from: php_recode.h: /* Checking for thread safety and issue warning if necessary. */ #ifdef ZTS #warning Recode module has not been tested for thread-safety. #endif It looks as it just needs some work (but not that much

[PHP-DEV] seg fault in recode.c on line 80

2002-04-20 Thread Magnus Määttä
With Apache 2.0.36-dev, newest PHP cvs.. Starting program: /usr/local/www/httpd2/bin/httpd [New Thread 1024 (LWP 9606)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 9606)] 0x40406e41 in zm_startup_recode (type=1, module_number=9, tsrm_ls=0x8196898) at /mnt

Re: [PHP-DEV] Re: Bug #16687 Updated: Constants not being interpreted in "variable variables"

2002-04-20 Thread Zeev Suraski
It applies, to a degree. If you directly reference $GLOBALS anywhere in your function, you can also reference it indirectly. If you don't, however, indirect reference won't work. E.g., function foo() { $foo = "GLOBALS"; print $$foo["bar"]; // won't work } func

[PHP-DEV] Shared PHP library

2002-04-20 Thread Andrei Zmievski
I would like to know if we can modify the build process to build and install a PHP library, without any SAPI modules, so that libphp.a and libphp.so get installed in the appropriate locations. I need this in order to develop PHP support for some applications, since they will need to link against t

Re: [PHP-DEV] Re: Bug #16687 Updated: Constants not being interpreted in "variable variables"

2002-04-20 Thread Markus Fischer
Andi, does this also apply to the $GLOBALS variable? If so, I think we can then add an apropriate Note: to the http://www.php.net/manual/en/language.variables.predefined.php page. - Markus On Sat, Apr 20, 2002 at 04:23:03PM +0300, Andi Gutmans wrote : > The way _GET an

Re: [PHP-DEV] ext/pgsql build broken on win32 (HEAD)

2002-04-20 Thread Edin Kadribasic
> > c:\php4build\HEAD\ext\pgsql\pgsql.c(1505) : fatal error C1057: unexpected > > end of > > file in macro expansion > > Could you tell me line number for current source? > I've committed sevral patches today, so I cannot tell > which one was it. Line 1505 in the latest CVS. Edin -- PHP Deve

Re: [PHP-DEV] ext/pgsql build broken on win32 (HEAD)

2002-04-20 Thread Yasuo Ohgaki
Edin Kadribasic wrote: >>These warnings helped me to fix 2 bugs :) > > > I'm glad to hear that. Now I have a new problem: > > c:\php4build\HEAD\ext\pgsql\pgsql.c(1505) : fatal error C1057: unexpected > end of > file in macro expansion Could you tell me line number for current source? I've com

Re: [PHP-DEV] Inline optimization

2002-04-20 Thread Yasuo Ohgaki
Andi Gutmans wrote: >> >> What about leaving -O2 but adding -finline-functions > > > > -O2 will inline the functions marked as inline. That should be good > enough because we inline where it's important. > I wouldn't go with -O3 nor with -finline-functions. > Andi Sounds good to me. How abou

[PHP-DEV] REMOVING Inline optimization option

2002-04-20 Thread Yasuo Ohgaki
Shall we remove --enable-inline-optimization option? Since it does not do anything for a long time, AFAIK. (Or does it actually work under some systems?) Any comments? -- Yasuo Ohgaki -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Bug #16687 Updated: Constants not being interpreted in "variable variables"

2002-04-20 Thread Andi Gutmans
The way _GET and friends are implemented is the most efficient way of doing it as it is taken care at compile-time. For the same reason in Engine 2 you can't indirectly reference $this (which shouldn't bother anyone). Over time people won't have to support versions below 4.1.0 anymore. In the me

Re: [PHP-DEV] Inline optimization

2002-04-20 Thread Andi Gutmans
At 18:17 19/04/2002 +0200, Marcus Börger wrote: >At 15:46 19.04.2002, you wrote: >>Any objection for changing -O2 -> -O3 when >>--enable-inline-optimization is used? (when GCC is used) >> >>-- >>Yasuo Ohgaki > > >What about leaving -O2 but adding -finline-functions -O2 will inline the functions

Re: [PHP-DEV] ext/pgsql build broken on win32 (HEAD)

2002-04-20 Thread Edin Kadribasic
> These warnings helped me to fix 2 bugs :) I'm glad to hear that. Now I have a new problem: c:\php4build\HEAD\ext\pgsql\pgsql.c(1505) : fatal error C1057: unexpected end of file in macro expansion Edin -- PHP Development Mailing List To unsubscribe, visit: http://www.

Re: [PHP-DEV] Feature request: anonymous usage of returned values

2002-04-20 Thread Andi Gutmans
This isn't planned for Engine 2 but you could use: list($year) = localtime($time); Andi At 03:17 20/04/2002 +0200, Markus Fischer wrote: > I've brought this up on the Zend Engine2 list a while ago. > The result was that it is not planned to support > dereferencing of arrays from