Re: [PHP-DEV] HEAD eats all memory
On Mon, 1 Dec 2003 20:46:38 +0200 (EET) Jani Taskinen <[EMAIL PROTECTED]> wrote: > >It still tries to eat memory =( > > Was there some script to go with this..? or it doesn't matter, cause it seems to be happening on the stage of parsing ENV or SERVER variables. > >gcc-2.96 > > There is no such gcc version.. # gcc --version 2.96 RH-based distribution, you know =) > > >autoconf 2.50 > > No workie. works ok for me. > >libtool 1.5 > > No workie. again, works ok for me. --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
On Mon, 01 Dec 2003 19:51:59 +0100 Sebastian Bergmann <[EMAIL PROTECTED]> wrote: > Jani Taskinen wrote: > > Was there some script to go with this..? > > Maybe this is related to the problem with PHP's logos I posted earlier? I suppose no. 'cause this problem appears with _any_ script. --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
On Tue, 2 Dec 2003, Antony Dovgal wrote: >On Mon, 01 Dec 2003 19:51:59 +0100 >Sebastian Bergmann <[EMAIL PROTECTED]> wrote: > >> Jani Taskinen wrote: >> > Was there some script to go with this..? >> >> Maybe this is related to the problem with PHP's logos I posted earlier? > >I suppose no. >'cause this problem appears with _any_ script. Try the latest CVS, derick fixed something related.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory (solved?)
On Mon, 1 Dec 2003 20:12:38 +0100 (CET) Derick Rethans <[EMAIL PROTECTED]> wrote: > > Reverting your patch fixes the problem, cause the problem seems to be in header > > parsing routines. > > Again, the problem is definitely in this patch. > > Hmm, interesting. But I'll need to have abetter 'bug' report before I > can do anything about it as things work just fine for me... ok, I'll try to figure out the exact reason. --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEAD eats all memory
On Tue, 2 Dec 2003 09:10:49 +0200 (EET) Jani Taskinen <[EMAIL PROTECTED]> wrote: > On Tue, 2 Dec 2003, Antony Dovgal wrote: > > >On Mon, 01 Dec 2003 19:51:59 +0100 > >Sebastian Bergmann <[EMAIL PROTECTED]> wrote: > > > >> Jani Taskinen wrote: > >> > Was there some script to go with this..? > >> > >> Maybe this is related to the problem with PHP's logos I posted earlier? > > > >I suppose no. > >'cause this problem appears with _any_ script. > > Try the latest CVS, derick fixed something related.. Ok, it works for me now. Thanx for help and sorry to trouble you =) --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
For the next 18-24 months, we are going to have to deal with code running in both PHP 4 and 5. Why not declare "var" an alias for "public", not throw E_STRICT for it and be done with it? If not this issue will be a real PITA for PEAR users. - Stig On Sun, 2003-11-30 at 00:10, Andi Gutmans wrote: > The strict was introduced so that we can add warnings about practices we > recommend and deprecated behavior. > I think "var" belongs there. > We could remove E_STRICT from E_ALL (although that'd be a bit hacky) and > save ppl the trouble of seeing these warnings. > Then again, we could remove the warning about var but I'm not sure I'd want > to do that. > > Andi > > At 12:22 PM 11/28/2003 -0500, Daniel Convissor wrote: > >On Fri, Nov 28, 2003 at 10:04:39AM +0100, Derick Rethans wrote: > > > > > > Strict is strict, that's the whole point. You can either fix your code > > > or disable strict. > > > >The "fixed" code can't run on PHP 4. This strict idea needs a minor > >reevaluation. Using var in PHP 5 isn't really "broken" and in order to > >run code that can run on both 4 and 5 users need to jump through hoops > >and, more importantly, disable the strict checking, which causes them to > >miss REAL deprication problems. > > > >--Dan > > > >-- > > FREE scripts that make web and database programming easier > >http://www.analysisandsolutions.com/software/ > > T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y > > 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335 f: 718-854-0409 > > > >-- > >PHP Internals - PHP Runtime Development Mailing List > >To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Adding PECL extensions into php-src (Was: Re: [PHP-CVS] cvs: php-src / buildconf)
I reverted this. We usually discuss changes like these before committing. (on [EMAIL PROTECTED] so people not on IRC will know too) Some reason why not do this like you did: 1) It doesn't work with windows 2) What if I have local changes and want to run ./cvsclean && ./buildconf ? Yet another option for buildconf which should be as simple as possible? 3) This can be done better :) Now, for the better solution for adding PECL extensions into php-src: a) Add the STABLE PHP4/5 branch(es) into the PECL/foobar extension. (Current STABLE for PHP 4 is "PHP_4_3") b) Remove the files from these STABLE branches in which the PECL/foobar extension is not supposed to be included. c) Link the PECL/foobar in CVSROOT/modules to php-src/ext If someone can tell why using the CVSROOT/modules for this is not working solution, please speak up or be quiet forever.. =) --Jani On Mon, 1 Dec 2003, Ilia Alshanetsky wrote: >iliaa Mon Dec 1 16:37:36 2003 EDT > > Modified files: >/php-src buildconf > Log: > The least intrusive way to 'import' PECL extensions into the main tree. > For the moment this deals with tidy, further extensions can be added at a > later point. > > >Index: php-src/buildconf >diff -u php-src/buildconf:1.60 php-src/buildconf:1.61 >--- php-src/buildconf:1.60 Wed Jun 25 08:56:40 2003 >+++ php-src/buildconf Mon Dec 1 16:37:35 2003 >@@ -1,5 +1,5 @@ > #!/bin/sh >-# $Id: buildconf,v 1.60 2003/06/25 12:56:40 sas Exp $ >+# $Id: buildconf,v 1.61 2003/12/01 21:37:35 iliaa Exp $ > > eval `grep '^EXTRA_VERSION=' configure.in` > case "$EXTRA_VERSION" in >@@ -12,19 +12,32 @@ > esac > > devok=0 >+pecl_args=0 > >-while test $# -gt 0; do >- if test "$1" = "--copy"; then >-automake_flags=--copy >- fi >- >- if test "$1" = "--force"; then >-devok=1 >-echo "Forcing buildconf" >- fi >+# Import 'gold' extensions from PECL >+GOLDEN='tidy' > >- shift >+for i in $*; do >+ if test "$i" = "--pecl-import"; then >+ pecl_args=1 >+ elif test "$i" = "--copy"; then >+ automake_flags=--copy >+ pecl_args=0 >+ elif test "$i" = "--force"; then >+ devok=1 >+ echo "Forcing buildconf" >+ pecl_args=0 >+ elif test $pecl_args -eq 1; then >+ # Allow the developer to specify some custom PECL extensions to fetch >+ GOLDEN=$GOLDEN" "$i >+ fi >+done; >+ >+cd ext; >+for ext in $GOLDEN; do >+ cvs co -d $ext pecl/$ext; > done >+cd ..; > > if test "$dev" = "0" -a "$devok" = "0"; then > echo "You should not run buildconf in a release package." > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: HEAD eats all memory
On Mon, 1 Dec 2003 20:56:53 +0200 (EET) Jani Taskinen <[EMAIL PROTECTED]> wrote: > On Mon, 1 Dec 2003, Antony Dovgal wrote: > > >BTW, I've already asked about this message: > > > >buildconf: autoconf version 2.50 (ok) > >buildconf: Your version of autoconf likely contains buggy cache code. > > Running cvsclean for you. > > To avoid this, install autoconf-2.13 and automake-1.5. > > > > Don't use autoconf > 2.13, it's really SLOW and also buggy. ok > Eh..if that was true, I would never ever run this every day: > > # ./cvsclean && ./buildconf > buildconf: checking installation... > buildconf: autoconf version 2.13 (ok) > buildconf: libtool version 1.4.3 (ok) > . > . > > Or would I? :) changing automake to 1.4-p6 and libtool to 1.4.3 helped. thank you very much, Jani. --- WBR, Antony Dovgal aka tony2001 [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
On Tue, 2 Dec 2003, Melvyn Sopacua wrote: > On Monday 01 December 2003 23:27, Derick Rethans wrote: > > > > I don't quite understand the problem. E_STRICT was only meant for people > > > who really want to be pedantic. I think we can make it not part of E_ALL. > > > Is that OK? > > > > SOunds good to me, -Wall with gcc doesn't show all errors either... I > > feel it's very close to this. > > If you're going to do this, then do it backwards compatible and 'leave' E_ALL > at 2047 and move E_STRICT to 2048. > Many apache administrators will thank you for this ;) E_STRICT already is 2048... it's just that E_ALL shouldn't include it. Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Leaks (reported during shutdown)
This is the simple test script: Steps to reproduce: 1) Start Apache 2) Access the script and let it run for some seconds 3) Stop the request. 4) Shutdown Apache Maybe these leaks are intentional but thinking that there are so many leaks makes me think there really is some bug somewhere? :) Some of these (bcmath ones) seem to be caused by that fact that RSHUTDOWN is not run at all when you happen to press 'Stop' in your browser. (There's some bug report about this, iirc :) --Jani /src/php4/Zend/zend_execute.c(1611) : Freeing 0x08260924 (12 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_execute.c(1758) : Freeing 0x082608E4 (12 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_opcode.c(295) : Freeing 0x0826074C (360 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_language_scanner.l(1331) : Freeing 0x0826171C (6 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_language_scanner.l(1436) : Freeing 0x082616E4 (2 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_opcode.c(65) : Freeing 0x08260714 (4 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_hash.c(272) : Freeing 0x082606AC (53 bytes), script=/www/htdocs/t.php Last leak repeated 76 times /src/php4/Zend/zend_compile.c(137) : Freeing 0x0825C65C (18 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_opcode.c(230) : Freeing 0x0825C61C (12 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_language_scanner.l(352) : Freeing 0x0825C40C (84 bytes), script=/www/htdocs/t.php /src/php4/ext/bcmath/libbcmath/src/init.c(69) : Freeing 0x0825C36C (1 bytes), script=/www/htdocs/t.php Last leak repeated 2 times /src/php4/ext/bcmath/libbcmath/src/init.c(54) : Freeing 0x0825C31C (29 bytes), script=/www/htdocs/t.php Last leak repeated 2 times /src/php4/ext/interbase/interbase.c(588) : Freeing 0x0825C1CC (9 bytes), script=/www/htdocs/t.php /src/php4/ext/interbase/interbase.c(583) : Freeing 0x0825C18C (9 bytes), script=/www/htdocs/t.php /src/php4/ext/interbase/interbase.c(578) : Freeing 0x0825C144 (18 bytes), script=/www/htdocs/t.php /src/php4/ext/mbstring/mbstring.c(999) : Freeing 0x0825C10C (8 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_alloc.c(218) : Actual location (location was relayed) /src/php4/Zend/zend_ini.c(203) : Freeing 0x0825C0CC (11 bytes), script=/www/htdocs/t.php Last leak repeated 2 times /src/php4/ext/sockets/sockets.c(485) : Freeing 0x0825809C (16384 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_hash.c(188) : Freeing 0x0825804C (32 bytes), script=/www/htdocs/t.php Last leak repeated 9 times /src/php4/main/main.c(1507) : Freeing 0x08257F3C (44 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_API.c(562) : Actual location (location was relayed) /src/php4/main/main.c(1506) : Freeing 0x08257EFC (12 bytes), script=/www/htdocs/t.php /src/php4/main/main.c(1489) : Freeing 0x082579AC (44 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_API.c(562) : Actual location (location was relayed) /src/php4/main/main.c(1488) : Freeing 0x0825796C (12 bytes), script=/www/htdocs/t.php /src/php4/main/main.c(1607) : Freeing 0x0825787C (12 bytes), script=/www/htdocs/t.php /src/php4/main/main.c(1559) : Freeing 0x082577CC (44 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_API.c(562) : Actual location (location was relayed) /src/php4/main/main.c(1558) : Freeing 0x0825778C (12 bytes), script=/www/htdocs/t.php /src/php4/main/php_variables.c(175) : Freeing 0x082576EC (12 bytes), script=/www/htdocs/t.php Last leak repeated 59 times /src/php4/main/php_variables.c(52) : Freeing 0x082576B4 (7 bytes), script=/www/htdocs/t.php Last leak repeated 59 times /src/php4/Zend/zend_hash.c(450) : Freeing 0x08256DDC (128 bytes), script=/www/htdocs/t.php Last leak repeated 1 time /src/php4/main/main.c(1310) : Freeing 0x08255CE4 (44 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_API.c(562) : Actual location (location was relayed) /src/php4/main/main.c(1309) : Freeing 0x08255CA4 (12 bytes), script=/www/htdocs/t.php /src/php4/main/php_variables.c(234) : Freeing 0x08255BF4 (44 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_API.c(562) : Actual location (location was relayed) Last leak repeated 1 time /src/php4/main/php_variables.c(233) : Freeing 0x08255BB4 (12 bytes), script=/www/htdocs/t.php Last leak repeated 1 time /src/php4/main/main.c(1448) : Freeing 0x08253884 (44 bytes), script=/www/htdocs/t.php /src/php4/Zend/zend_API.c(562) : Actual location (location was relayed) /src/php4/Zend/zend_ptr_stack.c(29) : Freeing 0x08253704 (256 bytes), script=/www/htdocs/t.php Last leak repeated 2 times /src/php4/Zend/zend_stack.c(27) : Freeing 0x08253244 (256 bytes), script=/www/htdocs/t.php Last leak repeated 6 times /src/php4/main/main.c(1447) : Freeing 0x081A7294 (12 bytes), script=/www/htdocs/t.php [Tue Dec 2 10:33:42 2003] [notice] caught SIGTERM, shutting down -- PHP Internals - PHP Runtime Development Mailing List
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
AK>> but this is a whole world clearer...
AK>>
AK>> foreach($s->person->children as $person) {
AK>> $firstname_text_value = $person->firstname->value;
AK>> }
I agree 100%. It looks cool if yo do $a = $b and behind the scenes it
launches whole train of magic and runs a lot of code, but it's not that
cool if you think beyond the look.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
At 09:18 AM 12/2/2003 +0100, Derick Rethans wrote: On Tue, 2 Dec 2003, Melvyn Sopacua wrote: > On Monday 01 December 2003 23:27, Derick Rethans wrote: > > > > I don't quite understand the problem. E_STRICT was only meant for people > > > who really want to be pedantic. I think we can make it not part of E_ALL. > > > Is that OK? > > > > SOunds good to me, -Wall with gcc doesn't show all errors either... I > > feel it's very close to this. > > If you're going to do this, then do it backwards compatible and 'leave' E_ALL > at 2047 and move E_STRICT to 2048. > Many apache administrators will thank you for this ;) E_STRICT already is 2048... it's just that E_ALL shouldn't include it. Done. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
On Tuesday 02 December 2003 09:18, Derick Rethans wrote: > On Tue, 2 Dec 2003, Melvyn Sopacua wrote: > > On Monday 01 December 2003 23:27, Derick Rethans wrote: > > > > I don't quite understand the problem. E_STRICT was only meant for > > > > people who really want to be pedantic. I think we can make it not > > > > part of E_ALL. Is that OK? > > > > > > SOunds good to me, -Wall with gcc doesn't show all errors either... I > > > feel it's very close to this. > > > > If you're going to do this, then do it backwards compatible and 'leave' > > E_ALL at 2047 and move E_STRICT to 2048. > > Many apache administrators will thank you for this ;) > > E_STRICT already is 2048... it's just that E_ALL shouldn't include it. Good - I was kinda afraid it would be some hack, that changed the value of E_ALL regardless. How about E_PEDANTIC being E_ALL | E_STRICT? Sounds logical to me. -- Melvyn === FreeBSD sarevok.webteckies.org 5.2-BETA FreeBSD 5.2-BETA #2: Mon Dec 1 17:58:47 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ SAREVOK_NOFW_DBG i386 === pgp0.pgp Description: signature
Re: [PHP-DEV] Compatibility problems with PHP 5
Stig S. Bakken wrote: For the next 18-24 months, we are going to have to deal with code running in both PHP 4 and 5. Why not declare "var" an alias for "public", not throw E_STRICT for it and be done with it? If not this issue will be a real PITA for PEAR users. +1 from me (not that my vote counts, but... :-)) - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
At 11:40 PM 12/1/2003 +0100, Stig S. Bakken wrote: For the next 18-24 months, we are going to have to deal with code running in both PHP 4 and 5. Why not declare "var" an alias for "public", not throw E_STRICT for it and be done with it? If not this issue will be a real PITA for PEAR users. Stig, E_STRICT will be disabled by default. It is only meant for people who want to be sure that they are using the recommended methods, and that definitely includes not using var. People who don't feel like it don't need to use it. It'd be ridiculous to have two new pedantic modes just because of this. It's not as if there are so many things we can recommend on anyway. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32 time.c
I think there are quite a few Win98 users and I see no reason to dump it, especially as it supports the system calls we need. At 11:34 PM 12/1/2003 +, Steph wrote: Can anyone explain to me why we're not dumping support for win98 at the same time pls? (Given that the PHP5 build system doesn't work on win98 any more.. ) > -Original Message- > From: Andi Gutmans [mailto:[EMAIL PROTECTED] > Sent: 01 December 2003 22:09 > To: Frank M. Kromann; Wez Furlong > Cc: [EMAIL PROTECTED]; Wez Furlong > Subject: Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32 time.c > > > At 01:42 PM 12/1/2003 -0800, Frank M. Kromann wrote: > >Hi, > > > >It is my understanding that most of the Win95 users are developing on the > >win platform and deploying on a server (Win or Linux). I have no idea of > >how meny users we have on Win95, but I have no problem in > removing support > >for it in PHP5. Lets move on :-) > > Yeah, I think it's OK for us to dump Win95. > Whoever doesn't want to upgrade due to MS expensive upgrade policy should > be going for Linux anyway :) > > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /win32 time.c
At 11:42 PM 12/1/2003 +, Steph wrote: > Because win98 supports the functions we want to use (while win95 > does not). > And the build system has nothing to do with the runtime support :) Agreed, but sooner or later it will.. Andi, why (specifically) did Zend drop win98 support? We haven't dropped Win98 support for all products. There are some technical reasons we aren't supporting Windows 98 officially for the Studio only but they might be resolved at some stage. The PHP5 build system doesn't work because batch files created for w2k and friends don't work on dos.. that's the _only_ reason currently, it's still possible to build on win98 so long as you run a bunch of stuff from the commandline first. Most Windows users don't build PHP by themselves so it doesn't matter. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Andi Gutmans wrote: E_STRICT will be disabled by default. It is only meant for people who want to be sure that they are using the recommended methods, and that definitely includes not using var. The problem is that it doesn't match the real world. People _are_ using PEAR and people _are_ using PHP4. So they simply _can't_ change var to public. So E_STRICT is currently way too noisy for them. Hence they'll not use it. That's why I think two levels (e.g. E_STRICT for backward compatible stuff and E_PEDANTIC for everything) makes sense. Or call it E_DEPRECATED and E_STRICT if you want. I for one would love to use E_DEPRECATED if it existed but I can't use E_NOTICE (I use uninitialized variables all the time, it's one of the main features of PHP for me) or E_STRICT (my code has to work on PHP4). - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: About bug #26182..(Object properties created redundantly)
I commited a fix. I am not quite sure why the existing code was doing what
it was so I'm waiting for Zeev (who wrote that part) to verify that my fix
is OK. (He's travelling right now so it'll take some time).
In the meanwhile, if any of your scripts break because of my fix please let
me know.
Andi
At 08:53 PM 12/1/2003 +0200, Jani Taskinen wrote:
This script:
class A {
function NotAConstructor(){
if(isset($this->x)){
//just for demo
}
}
}
$t=new A();
var_dump($t);
?>
Output with php4:
object(a)(0) {
}
Output with php5:
object(a)#1 (1) {
["x"]=>
NULL
}
The property x gets created by that check if it exists in the class..
Pretty high WTF factor IMO. And someone might rely that a property STAYS
unset even if they happen to check it in their methods.
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Hello Christian, Tuesday, December 2, 2003, 1:14:12 PM, you wrote: > Andi Gutmans wrote: >> E_STRICT will be disabled by default. It is only meant for people who >> want to be sure that they are using the recommended methods, and that >> definitely includes not using var. > The problem is that it doesn't match the real world. People _are_ using > PEAR and people _are_ using PHP4. So they simply _can't_ change var to > public. So E_STRICT is currently way too noisy for them. Hence they'll > not use it. That's why I think two levels (e.g. E_STRICT for backward > compatible stuff and E_PEDANTIC for everything) makes sense. Or call it > E_DEPRECATED and E_STRICT if you want. > I for one would love to use E_DEPRECATED if it existed but I can't use > E_NOTICE (I use uninitialized variables all the time, it's one of the > main features of PHP for me) or E_STRICT (my code has to work on PHP4). I see all your concerns. But from my point of view pear has (of course) the problem that it is written in php4 and for php4. So PEAR needs to address the move towards php5 code anyway. An optional E_STRICT would help here wouldn't it? -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Hello Melvyn, Tuesday, December 2, 2003, 10:53:17 AM, you wrote: > On Tuesday 02 December 2003 09:18, Derick Rethans wrote: >> On Tue, 2 Dec 2003, Melvyn Sopacua wrote: >> > On Monday 01 December 2003 23:27, Derick Rethans wrote: >> > > > I don't quite understand the problem. E_STRICT was only meant for >> > > > people who really want to be pedantic. I think we can make it not >> > > > part of E_ALL. Is that OK? >> > > >> > > SOunds good to me, -Wall with gcc doesn't show all errors either... I >> > > feel it's very close to this. >> > >> > If you're going to do this, then do it backwards compatible and 'leave' >> > E_ALL at 2047 and move E_STRICT to 2048. >> > Many apache administrators will thank you for this ;) >> >> E_STRICT already is 2048... it's just that E_ALL shouldn't include it. > Good - I was kinda afraid it would be some hack, that changed the value of > E_ALL regardless. > How about E_PEDANTIC being E_ALL | E_STRICT? Sounds logical to me. This sounds like a good approach to me (at leat it is named like what it is). -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Windows 95
So what's the verdict? Are we dumping Windows 95? Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] reflection api -> camelcaps
I'd like to convert the reflection API to the current php standard of CamelCaps (instead of underscores) for it's class and method names. Any objections? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows 95
Based on the comments on the cvs list I think this would be a good idea. +1 Ilia On December 2, 2003 12:51 pm, Andi Gutmans wrote: > So what's the verdict? Are we dumping Windows 95? > > Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows 95
Yep :) - Original Message - From: "Andi Gutmans" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 02, 2003 5:51 PM Subject: [PHP-DEV] Windows 95 > So what's the verdict? Are we dumping Windows 95? > > Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_API.c
Hello Stanislav,
Tuesday, December 2, 2003, 10:01:40 AM, you wrote:
AK>>> but this is a whole world clearer...
AK>>>
AK>>> foreach($s->person->children as $person) {
AK>>> $firstname_text_value = $person->firstname->value;
AK>>> }
> I agree 100%. It looks cool if yo do $a = $b and behind the scenes it
> launches whole train of magic and runs a lot of code, but it's not that
> cool if you think beyond the look.
If you want full control and no magic then you can still use DOM.
SimpleXML aims to help with simple xml structures and tries to provide the
easiest way of working with it. Atm there are three rules with SXE objects:
1) a property maps to an element
2) any property aka element converted to or used as a string represents the
textual content of it
3) a sxe object used as an array allows to work with its attributes
i think this is easy to understand and pretty nice
i know too that this doesn't deal with all probelms - i can live with that
because thanks to rob i can convert any sxe object to a dom object and vice
versa - great! - i like this :-)
--
Best regards,
Marcusmailto:[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection api -> camelcaps
Hello George, Tuesday, December 2, 2003, 6:58:58 PM, you wrote: > I'd like to convert the reflection API to the current php standard of > CamelCaps (instead of underscores) for it's class and method names. > Any objections? No objections. Strong agreement.' -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Marcus Boerger wrote: I see all your concerns. But from my point of view pear has (of course) the problem that it is written in php4 and for php4. So PEAR needs to address the move towards php5 code anyway. An optional E_STRICT would help here wouldn't it? [My concern is that if E_STRICT warns about var then PEAR developers are tempted to change their code to PPP. This will screw PEAR users who are (for whatever reason) stuck with PHP4.] Ok, let's take a step back and ask why you want people to change var to public in the first place: I assume you want to make people rethink how they use member variables and promote safer programming. Am I right so far? Now I have the feeling that if you deprecate var you simply make people search and replace var by public globally. Nothing gained at all. What you really want is that people can change var to PPP one by one after carefully examining the usage of a variable. Having grep var * as a tool to identify places to be examined is great, if I replaced all var by public in the first place I lose this. And no, I don't believe in forcing people to stop developing for a week and go over all their code at once to migrate it to the new model. Maybe you see an analogy with my __clone() reasoning here (-:C - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection api -> camelcaps
On Tue, 2 Dec 2003, George Schlossnagle wrote: > I'd like to convert the reflection API to the current php standard of > CamelCaps (instead of underscores) for it's class and method names. > Any objections? yes Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection api -> camelcaps
On Dec 2, 2003, at 1:18 PM, Derick Rethans wrote: On Tue, 2 Dec 2003, George Schlossnagle wrote: I'd like to convert the reflection API to the current php standard of CamelCaps (instead of underscores) for it's class and method names. Any objections? yes Care to elaborate? George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Again, people don't have to use E_STRICT. I think having two new E_'s is a bit of an overkill especially as there aren't that many things we can add to them. At 07:18 PM 12/2/2003 +0100, Christian Schneider wrote: Marcus Boerger wrote: I see all your concerns. But from my point of view pear has (of course) the problem that it is written in php4 and for php4. So PEAR needs to address the move towards php5 code anyway. An optional E_STRICT would help here wouldn't it? [My concern is that if E_STRICT warns about var then PEAR developers are tempted to change their code to PPP. This will screw PEAR users who are (for whatever reason) stuck with PHP4.] Ok, let's take a step back and ask why you want people to change var to public in the first place: I assume you want to make people rethink how they use member variables and promote safer programming. Am I right so far? Now I have the feeling that if you deprecate var you simply make people search and replace var by public globally. Nothing gained at all. What you really want is that people can change var to PPP one by one after carefully examining the usage of a variable. Having grep var * as a tool to identify places to be examined is great, if I replaced all var by public in the first place I lose this. And no, I don't believe in forcing people to stop developing for a week and go over all their code at once to migrate it to the new model. Maybe you see an analogy with my __clone() reasoning here (-:C - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection api -> camelcaps
George Schlossnagle wrote: > I'd like to convert the reflection API to the current php standard of > CamelCaps (instead of underscores) for it's class and method names. Why deviate from PEAR CS in this? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows 95
Yes. - Frank > So what's the verdict? Are we dumping Windows 95? > > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Andi Gutmans wrote: Again, people don't have to use E_STRICT. I think having two new E_'s is Why then introduce it at all? Or why not slightly change it to be useful for a lot more people? > a bit of an overkill especially as there aren't that many things we > can add to them. I think all of the deprecated functions with alternative names in PHP4 already could be added to E_DEPRECATED. This would provide a useful tool for people trying to change outdated functions with current ones without sacrificing backward compatibility. Ok, enough from me on this thread, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection api -> camelcaps
On Dec 2, 2003, at 1:22 PM, Sebastian Bergmann wrote: George Schlossnagle wrote: I'd like to convert the reflection API to the current php standard of CamelCaps (instead of underscores) for it's class and method names. Why deviate from PEAR CS in this? Well, as the classes are builtin's it's not so clear to me that the packag naming rules apply directly. But this is a sound objection. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compatibility problems with PHP 5
Hello Christian, Tuesday, December 2, 2003, 7:18:11 PM, you wrote: > Marcus Boerger wrote: >> I see all your concerns. But from my point of view pear has (of course) the >> problem that it is written in php4 and for php4. So PEAR needs to address >> the move towards php5 code anyway. An optional E_STRICT would help here >> wouldn't it? > [My concern is that if E_STRICT warns about var then PEAR developers are > tempted to change their code to PPP. This will screw PEAR users who are > (for whatever reason) stuck with PHP4.] > Ok, let's take a step back and ask why you want people to change var to > public in the first place: I assume you want to make people rethink how > they use member variables and promote safer programming. Am I right so > far? Now I have the feeling that if you deprecate var you simply make > people search and replace var by public globally. Nothing gained at all. > What you really want is that people can change var to PPP one by one > after carefully examining the usage of a variable. Having grep var * as > a tool to identify places to be examined is great, if I replaced all var > by public in the first place I lose this. And no, I don't believe in > forcing people to stop developing for a week and go over all their code > at once to migrate it to the new model. Maybe you see an analogy with my > __clone() reasoning here (-:C I agree, but wouldn't it be nice to have a tool at hand that can tell you if you have decided for all places at any time you want? -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection api -> camelcaps
On Tue, 2 Dec 2003, George Schlossnagle wrote: > On Dec 2, 2003, at 1:22 PM, Sebastian Bergmann wrote: > > > George Schlossnagle wrote: > >> I'd like to convert the reflection API to the current php standard of > >> CamelCaps (instead of underscores) for it's class and method names. > > > > Why deviate from PEAR CS in this? > > Well, as the classes are builtin's it's not so clear to me that the > packag naming rules apply directly. But this is a sound objection. This raises my question of my the new Exception class uses CamelCaps instead of underscores? For instance, its methods are: getMessage(), getCode(), etc. I don't think any other built-in method or packaged extension does this. -adam -- [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection api -> camelcaps
On Dec 2, 2003, at 1:51 PM, Adam Maccabee Trachtenberg wrote: On Tue, 2 Dec 2003, George Schlossnagle wrote: On Dec 2, 2003, at 1:22 PM, Sebastian Bergmann wrote: George Schlossnagle wrote: I'd like to convert the reflection API to the current php standard of CamelCaps (instead of underscores) for it's class and method names. Why deviate from PEAR CS in this? Well, as the classes are builtin's it's not so clear to me that the packag naming rules apply directly. But this is a sound objection. This raises my question of my the new Exception class uses CamelCaps instead of underscores? For instance, its methods are: getMessage(), getCode(), etc. I don't think any other built-in method or packaged extension does this. I've been re-pointed to CODING_STANDARDS, which changed since last I looked. Classnames get underscores, method names get camelcaps. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection api -> camelcaps
On Tue, 2 Dec 2003, George Schlossnagle wrote: > > On Dec 2, 2003, at 1:18 PM, Derick Rethans wrote: > > > On Tue, 2 Dec 2003, George Schlossnagle wrote: > > > >> I'd like to convert the reflection API to the current php standard of > >> CamelCaps (instead of underscores) for it's class and method names. > >> Any objections? > > > > yes > > Care to elaborate? Sure, i'll repeat what I said on IRC: 19:47 <@Derick> 1. it's not any standard 19:47 <@Derick> 2. it's ugly as hell 19:47 <@Derick> (it was 'standard' for a while but due to popluair demand we removed it from coding_standards) 19:57 <[GeorgeS]> Derick: didn't see the change to CODING_STANDARDS. But that's a good reason. Please have a look at the archives for this, as I remember having a discussion about this too. IMO all internal functions use the underscore way, so why deviate for methods? (This is as far as I go, no need to discuss this again) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows 95
On Tue, 2 Dec 2003, Andi Gutmans wrote: >So what's the verdict? Are we dumping Windows? YES! :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows 95
On Tue, 2 Dec 2003, Andi Gutmans wrote: > So what's the verdict? Are we dumping Windows 95? Do you mean Windows 95 or PHP support for Windows 95? Actually... both work for me ;-) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows 95
At 09:48 PM 12/2/2003 +0100, Derick Rethans wrote: On Tue, 2 Dec 2003, Andi Gutmans wrote: > So what's the verdict? Are we dumping Windows 95? Do you mean Windows 95 or PHP support for Windows 95? Actually... both work for me ;-) Okay, I officially broke it now with my latest TSRM patch ;) Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] old snapshots?
Hey Folks: I'm looking for old snapshots of php5 win32 packages. From my browsing around the tree, snaps.php.net only has the past few ones. Do they exist somewhere, please? This question hasn't been answered when asked in my bug report replies. I'm trying to pinpoint when a particular bug arose. Thanks, --Dan -- FREE scripts that make web and database programming easier http://www.analysisandsolutions.com/software/ T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] old snapshots?
On Tue, 2 Dec 2003, Daniel Convissor wrote: > I'm looking for old snapshots of php5 win32 packages. From my browsing > around the tree, snaps.php.net only has the past few ones. Do they exist > somewhere, please? No, we don't archive those. But you can do a cvs checkout with a certain date: cvs -d :pserver:[EMAIL PROTECTED]:/repository co -D 2003-11-15 -d php-5.0dev php-src regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fix for #24773 Requires ZE/ZE2 Karma
I've got a fix for Bug #24773 ( http://bugs.php.net/24773 ) However, I've neither the confidence nor the karma to apply it. Patches for ZE1 and ZE2: http://frankenbox.alphaweb.net/test/24773-ze1.diff http://frankenbox.alphaweb.net/test/24773-ze2.diff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection api -> camelcaps
On 12/2/03 7:51 PM, Adam Maccabee Trachtenberg wrote: On Tue, 2 Dec 2003, George Schlossnagle wrote: On Dec 2, 2003, at 1:22 PM, Sebastian Bergmann wrote: George Schlossnagle wrote: I'd like to convert the reflection API to the current php standard of CamelCaps (instead of underscores) for it's class and method names. Why deviate from PEAR CS in this? Well, as the classes are builtin's it's not so clear to me that the packag naming rules apply directly. But this is a sound objection. This raises my question of my the new Exception class uses CamelCaps instead of underscores? For instance, its methods are: getMessage(), getCode(), etc. I don't think any other built-in method or packaged extension does this. ext/dom and ext/xsl use camelCaps as well chregu -adam -- christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | [EMAIL PROTECTED] | gnupg-keyid 0x5CE1DECB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] reflection api -> camelcaps
On Tue, 2 Dec 2003, Christian Stocker wrote: > > This raises my question of my the new Exception class uses CamelCaps instead > > of underscores? > > > > For instance, its methods are: getMessage(), getCode(), etc. > > > > I don't think any other built-in method or packaged extension does this. > > ext/dom and ext/xsl use camelCaps as well here it makes a bit sense because it's the Dom standard to do so and to have the possibility to point at the dom docs instead of forcing the developers to write documentation ;-) Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] old snapshots?
On Tue, Dec 02, 2003 at 10:34:04PM +0100, Derick Rethans wrote: > > No, we don't archive those. But you can do a cvs checkout with a certain > date: > > cvs -d :pserver:[EMAIL PROTECTED]:/repository co -D 2003-11-15 > -d php-5.0dev php-src I was afraid of that. So, I'd need to then compile/build it, right? Joy... Yes, I'm spoiled. Thanks, --Dan -- FREE scripts that make web and database programming easier http://www.analysisandsolutions.com/software/ T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] New win32 build system
I've committed the build infrastructure for the "real programmers don't need an IDE" build system for win32. Why? - It's frustrating to have to use VC6 to work on PHP if you have a newer version that has incompatible project files. - It's annoying to mess around with libxml2 stuff until it stabilizes :-) and a pain to have to remember to edit the config.w32.h header each time, and a pain to have to avoid accidentally committing those changes each time. - It's difficult to set up a fully working build environment for PHP without installing everything. - It's difficult for people without VC6 to create a win32 project file for their extensions. Requirements: You need windows script host (cscript.exe) and JScript installed. This should be a standard config on windows machines since win98 (perhaps optional under win98). You also need the Microsoft build tools (cl.exe, link.exe and nmake.exe). These are freely available as part of the Platform SDK, but also come with VC++/Visual Studio. Finally, you need the php_build dir that contains all the headers and libraries for the things that php is linked against; see [1] for details. Usage: Check out PHP 5 and run buildconf.bat from the root of the php source. This script is roughly equivalent to the unix buildconf in that it scans ext/* and sapi/* for config.w32 files describing optional build components and generates a configure script named configure.js Now run "cscript configure.js --help" to get a list of configure options; enable and disable stuff as appropriate. Then type nmake to build the things you configured. You will find the various .exe and .dll files in the build dir that configure selects for you based on debug and zts settings; it will be one of the usual Debug_TS, Release_TS, Debug or Release dirs found under the source root. You can also run the test suite by running "nmake test". [we have some issues under win32 with current CVS!] TODO: - Write config.w32 files for more extensions and sapis. They're quite easy (just a couple of javascript function calls) and can be put together almost without thinking by copying the guts of the config.m4 file from the same extension. - add those .rc files with version info the generated .dll's and .exe's - Test if it actually works under win98 (Steph?) There are only two places that I suspect might have difficulty under win98. [1] http://www.php.net/manual/en/install.windows.php#install.windows.build -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Hi Wez, Cool. So far it also requires apache. ++diable+apache does not seam to work! - Frank > I've committed the build infrastructure for the > "real programmers don't need an IDE" build system for win32. > > Why? > - It's frustrating to have to use VC6 to work on PHP if you > have a newer version that has incompatible project files. > - It's annoying to mess around with libxml2 stuff until it > stabilizes :-) and a pain to have to remember to edit > the config.w32.h header each time, and a pain to have to > avoid accidentally committing those changes each time. > - It's difficult to set up a fully working build environment > for PHP without installing everything. > - It's difficult for people without VC6 to create a win32 > project file for their extensions. > > Requirements: > You need windows script host (cscript.exe) and JScript installed. > This should be a standard config on windows machines since win98 > (perhaps optional under win98). > > You also need the Microsoft build tools (cl.exe, link.exe and nmake.exe). > These are freely available as part of the Platform SDK, but also > come with VC++/Visual Studio. > > Finally, you need the php_build dir that contains all the > headers and libraries for the things that php is linked > against; see [1] for details. > > Usage: > Check out PHP 5 and run buildconf.bat from the root of the php > source. This script is roughly equivalent to the unix buildconf > in that it scans ext/* and sapi/* for config.w32 files describing > optional build components and generates a configure script > named configure.js > > Now run "cscript configure.js --help" to get a list of configure > options; enable and disable stuff as appropriate. > > Then type nmake to build the things you configured. > > You will find the various .exe and .dll files in the build dir > that configure selects for you based on debug and zts settings; > it will be one of the usual Debug_TS, Release_TS, Debug or Release > dirs found under the source root. > > You can also run the test suite by running "nmake test". > [we have some issues under win32 with current CVS!] > > TODO: > - Write config.w32 files for more extensions and sapis. > They're quite easy (just a couple of javascript function calls) > and can be put together almost without thinking by copying the > guts of the config.m4 file from the same extension. > - add those .rc files with version info the generated .dll's and .exe's > - Test if it actually works under win98 (Steph?) > There are only two places that I suspect might have difficulty > under win98. > > [1] > http://www.php.net/manual/en/install.windows.php#install.windows.build > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
--disable-apache Works For Me (tm) What goes wrong for you? --Wez. - Original Message - From: "Frank M. Kromann" <[EMAIL PROTECTED]> To: "Wez Furlong" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, December 03, 2003 12:18 AM Subject: Re: [PHP-DEV] New win32 build system > Hi Wez, > > Cool. So far it also requires apache. ++diable+apache does not seam to > work! > > - Frank -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
On Tue, Dec 02, 2003 at 11:40:18PM -, Wez Furlong wrote: > I've committed the build infrastructure for the > "real programmers don't need an IDE" build system for win32. Neat. Could you add a README.WIN32-BUILD-SYSTEM file that contains all of the information that you provided in this email? -- Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Here is the output C:\PHP\php5>cscript /nologo configure.js --with-php-build=Release_TS --disable-apache Saving configure options to config.nice.bat Checking for cl ... cl.exe Checking for link ... link.exe Checking for nmake ... nmake.exe Checking for make ... Build dir: Release_TS PHP Core: php5ts.dll and php5ts.lib ERROR: Could not find apache headers - Frank > --disable-apache Works For Me (tm) > What goes wrong for you? > > --Wez. > > - Original Message - > From: "Frank M. Kromann" <[EMAIL PROTECTED]> > To: "Wez Furlong" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, December 03, 2003 12:18 AM > Subject: Re: [PHP-DEV] New win32 build system > > > > Hi Wez, > > > > Cool. So far it also requires apache. ++diable+apache does not seam to > > work! > > > > - Frank > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] BC broken for strrpos()/strripos()
Hi devs,
this night i saw that the BC of strrpos()/strripos()
is broken by a patch commited by pollita 7 months ago :
http://cvs.php.net/diff.php/php-src/ext/standard/string.c?login=2&r1=1.370&r2=1.371&ty=u
The documenation of both function states if the second parameter is an
integer instead of string then its value is used as a ord of the character
to be used during the search. This no more true with HEAD.
A script to reproduce :
var_dump(strrpos("ABCDEF","DEF"));
var_dump(strrpos("ABCDEF","DAF"));
var_dump(strrpos("ABCDEF",ord("D")));
?>
HEAD :
int(3)
bool(false)
bool(false)
PHP 4.3.5-dev (cli) (built: Dec 2 2003 00:13:37) (DEBUG):
int(3)
int(3)
int(3)
What do you think? Is it ok to break the BC here or not? As you see the
other change introduced with the patch is to use the whole needle string
while searching, not only the first character.
Comments are welcome,
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Ahh, fixed now :-) --with-php-build specifies the path to the php_build dir (the one that contains those headers and libs), not the target dir, which is chosen automatically. cscript /nologo configure.js --disable-apache should be all you need (cross your fingers!) --Wez. - Original Message - From: "Frank M. Kromann" <[EMAIL PROTECTED]> To: "Wez Furlong" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, December 03, 2003 12:24 AM Subject: Re: [PHP-DEV] New win32 build system > Here is the output > > C:\PHP\php5>cscript /nologo configure.js --with-php-build=Release_TS > --disable-apache > Saving configure options to config.nice.bat > Checking for cl ... cl.exe > Checking for link ... link.exe > Checking for nmake ... nmake.exe > Checking for make ... > > Build dir: Release_TS > PHP Core: php5ts.dll and php5ts.lib > > ERROR: Could not find apache headers > > - Frank -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Done. > Neat. Could you add a README.WIN32-BUILD-SYSTEM file that contains > all of the information that you provided in this email? > > -- > Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Hi Wez, If I don't specify --with-php-build I get this Saving configure options to config.nice.bat Checking for cl ... cl.exe Checking for link ... link.exe Checking for nmake ... nmake.exe Checking for make ... ERROR: Could not find the php_build dir; please specify it using the --with-php-build option to configure - Frank > Ahh, fixed now :-) > > --with-php-build specifies the path to the php_build dir > (the one that contains those headers and libs), > not the target dir, which is chosen automatically. > > cscript /nologo configure.js --disable-apache > > should be all you need (cross your fingers!) > > > --Wez. > > - Original Message - > From: "Frank M. Kromann" <[EMAIL PROTECTED]> > To: "Wez Furlong" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, December 03, 2003 12:24 AM > Subject: Re: [PHP-DEV] New win32 build system > > > > Here is the output > > > > C:\PHP\php5>cscript /nologo configure.js --with-php-build=Release_TS > > --disable-apache > > Saving configure options to config.nice.bat > > Checking for cl ... cl.exe > > Checking for link ... link.exe > > Checking for nmake ... nmake.exe > > Checking for make ... > > > > Build dir: Release_TS > > PHP Core: php5ts.dll and php5ts.lib > > > > ERROR: Could not find apache headers > > > > - Frank > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
--with-php-build should be the path to the dir where you unzipped: http://www.php.net/extra/win32build.zip. Maybe I should rename it from php_build (that name comes from Edin's snap building scripts, and his big brother version of that zip file). --Wez. - Original Message - From: "Frank M. Kromann" <[EMAIL PROTECTED]> To: "Wez Furlong" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, December 03, 2003 12:36 AM Subject: Re: [PHP-DEV] New win32 build system > Hi Wez, > > If I don't specify --with-php-build I get this > > Saving configure options to config.nice.bat > Checking for cl ... cl.exe > Checking for link ... link.exe > Checking for nmake ... nmake.exe > Checking for make ... > ERROR: Could not find the php_build dir; please specify it > using the --with-php-build option to configure > > - Frank -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Hi Wez, Why is that needed ? I build all the stuff that I need from sources so I have my own file structure for external header and library files. - Frank > --with-php-build should be the path to the dir where you > unzipped: http://www.php.net/extra/win32build.zip. > > Maybe I should rename it from php_build (that name comes > from Edin's snap building scripts, and his big brother > version of that zip file). > > --Wez. > > - Original Message - > From: "Frank M. Kromann" <[EMAIL PROTECTED]> > To: "Wez Furlong" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, December 03, 2003 12:36 AM > Subject: Re: [PHP-DEV] New win32 build system > > > > Hi Wez, > > > > If I don't specify --with-php-build I get this > > > > Saving configure options to config.nice.bat > > Checking for cl ... cl.exe > > Checking for link ... link.exe > > Checking for nmake ... nmake.exe > > Checking for make ... > > ERROR: Could not find the php_build dir; please specify it > > using the --with-php-build option to configure > > > > - Frank > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
The main reason is that it is the easiest way to get things to built right now; I do plan to accomodate your own layout, but haven't coded support for that yet :) I'll make this particular thing optional (but print a warning) for now; can you build without it? (I take it you have your preferred paths in your env vars) --Wez. - Original Message - From: "Frank M. Kromann" <[EMAIL PROTECTED]> To: "Wez Furlong" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, December 03, 2003 12:46 AM Subject: Re: [PHP-DEV] New win32 build system > Hi Wez, > > Why is that needed ? I build all the stuff that I need from sources so I > have my own file structure for external header and library files. > > - Frank > > > --with-php-build should be the path to the dir where you > > unzipped: http://www.php.net/extra/win32build.zip. > > > > Maybe I should rename it from php_build (that name comes > > from Edin's snap building scripts, and his big brother > > version of that zip file). > > > > --Wez. > > > > - Original Message - > > From: "Frank M. Kromann" <[EMAIL PROTECTED]> > > To: "Wez Furlong" <[EMAIL PROTECTED]> > > Cc: <[EMAIL PROTECTED]> > > Sent: Wednesday, December 03, 2003 12:36 AM > > Subject: Re: [PHP-DEV] New win32 build system > > > > > > > Hi Wez, > > > > > > If I don't specify --with-php-build I get this > > > > > > Saving configure options to config.nice.bat > > > Checking for cl ... cl.exe > > > Checking for link ... link.exe > > > Checking for nmake ... nmake.exe > > > Checking for make ... > > > ERROR: Could not find the php_build dir; please specify it > > > using the --with-php-build option to configure > > > > > > - Frank > > > > > > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: BC broken for strrpos()/strripos()
> this night i saw that the BC of strrpos()/strripos() > is broken by a patch commited by pollita 7 months ago : > http://cvs.php.net/diff.php/php-src/ext/standard/string.c?login=2&r1=1.370&r2=1.371&ty=u > The documenation of both function states if the second parameter is an > integer instead of string then its value is used as a ord of the character > to be used during the search. This no more true with HEAD. > Good catch. This should not have been broken, I'll fix this. > What do you think? Is it ok to break the BC here or not? As you see the > other change introduced with the patch is to use the whole needle string > while searching, not only the first character. > That break was intentional. Having strrpos() behave differently from strpos() in regards to needle size was not a good thing. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
> The main reason is that it is the easiest way to get things to > built right now; I do plan to accomodate your own layout, > but haven't coded support for that yet :) Ok. Thats fine. I'll be happy to help with this. > > I'll make this particular thing optional (but print a warning) > for now; can you build without it? > (I take it you have your preferred paths in your env vars) Actually I use Visual Studio's directory settings but that works the same way. - Frank -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: BC broken for strrpos()/strripos()
Sara Golemon wrote: The documenation of both function states if the second parameter is an integer instead of string then its value is used as a ord of the character to be used during the search. This no more true with HEAD. Good catch. This should not have been broken, I'll fix this. okie What do you think? Is it ok to break the BC here or not? As you see the other change introduced with the patch is to use the whole needle string while searching, not only the first character. That break was intentional. Having strrpos() behave differently from strpos() in regards to needle size was not a good thing. In this case it should be stated somewhere maybe in the still imaginery "the_thin_differences_between_PHP4_and_PHP5.txt" -Sara Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Wez: Your new compile routine -- which sounds nice, thanks -- seems to come just in time for me... On Tue, Dec 02, 2003 at 11:40:18PM -, Wez Furlong wrote: > You also need the Microsoft build tools (cl.exe, link.exe and nmake.exe). > These are freely available as part of the Platform SDK, but also > come with VC++/Visual Studio. Platform SDK??? Ah, Google to the rescue... http://www.google.com/search?q=+site:www.microsoft.com+platform+sdk Seems http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ is the main page for this product. Unfortunately, the website is by Microsoft. Going to that page using Mozilla with JavaScript turned off, produces a non-helpful page that just says what PSDK is, but no links to anything else. Turning JS on, then the page says "The Microsoft® Platform SDK site requires Microsoft Internet Explorer version 5.0 or later" and that Active X needs to be on. Damn, I hate this freakin company! I just want to download a file! One of the links from Google goes to http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm which looks pretty promising since it's titled "Full Download with Local Install." Alas, no links to actually get the file. By going to http://www.microsoft.com/downloads/search.aspx?displaylang=en and selecting "Platform SDK" from the option list produced over 400 hits and adding "2000," which is my platform, to the terms cut it down to 9, but none of the results look like what I need. Wez, can you pleaes help point me to the right place? Guess it'd be handy to have this explained in your readme file too. > Check out PHP 5 and run buildconf.bat from the root of the php > source. Looks like I'm going to need to build several versions of old php5 sources. Can I correctly assume that if I copy the new php-src/win32/build directory into the downloaded php-src/win32 directory, I'll be able to use it? Thanks, --Dan -- FREE scripts that make web and database programming easier http://www.analysisandsolutions.com/software/ T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y 4015 7th Ave #4AJ, Brooklyn NYv: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] reflection api -> camelcaps
> From: Derick Rethans [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 02, 2003 8:02 PM > On Tue, 2 Dec 2003, George Schlossnagle wrote: > > > > > On Dec 2, 2003, at 1:18 PM, Derick Rethans wrote: > > > > > On Tue, 2 Dec 2003, George Schlossnagle wrote: > > > > > >> I'd like to convert the reflection API to the current php standard of > > >> CamelCaps (instead of underscores) for it's class and method names. > > >> Any objections? > > > > > > yes > > > > Care to elaborate? > > Sure, i'll repeat what I said on IRC: > 19:47 <@Derick> 1. it's not any standard > 19:47 <@Derick> 2. it's ugly as hell > 19:47 <@Derick> (it was 'standard' for a while but due to popluair demand > we > removed it from coding_standards) > 19:57 <[GeorgeS]> Derick: didn't see the change to CODING_STANDARDS. > But that's a good reason. > > Please have a look at the archives for this, as I remember having a > discussion about this too. IMO all internal functions use the underscore > way, so why deviate for methods? (This is as far as I go, no need to > discuss this again) There was an argument raised by Marcus a while back. The main point was that PHP's lack of preserving of case would be a major draw back to studlyCaps. However since he solved the issue the discussion faded away (for obvious reasons). Regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: BC broken for strrpos()/strripos()
> >>What do you think? Is it ok to break the BC here or not? As you see the > >>other change introduced with the patch is to use the whole needle string > >>while searching, not only the first character. > >> > >That break was intentional. Having strrpos() behave differently from > >strpos() in regards to needle size was not a good thing. > > > In this case it should be stated somewhere maybe in the still imaginery > "the_thin_differences_between_PHP4_and_PHP5.txt" > Well, it's in the manual page (down at the bottom). (Note: Ignore the note about converting integers to strings, I've taken that out in light of undoing that particular BC breakage). But you're absolutely right, a spot in a yet-to-be-writen FAQ couldn't hurt. While I was in that file I fixed an offset reporting issue (offset didn't exist in 4.3 so it's not something to MFH) and introduced an optimized version of the string search for single character needles. In strrpos() it'll only be a minor difference, but strripos() saves a pair of needless emallocs. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Wez Furlong wrote: > Then type nmake to build the things you configured. Current CVS breaks at this point for me: E:\home\php\php5>cscript /nologo configure.js --enable-debug --disable-apache Saving configure options to config.nice.bat Checking for cl.exe ... Checking for link.exe ... Checking for nmake.exe ... Checking for make.exe ... Checking for arpa\nameser.h ... ..\bindlib_w32 Build dir: Debug_TS PHP Core: php5ts_debug.dll and php5ts_debug.lib Enabling sapi/cgi Enabling sapi/cli Enabling sapi/isapi Enabling ext/bcmath Enabling ext/calendar Enabling ext/com_dotnet Enabling ext/ctype Enabling ext/dom Enabling ext/ftp Enabling ext/libxml Checking for iconv.lib ... Checking for libxml2.lib ... Checking for libxml/parser.h ... Enabling ext/odbc Enabling ext/pcre Enabling ext/session Enabling ext/simplexml Enabling ext/sqlite Enabling ext/standard Enabling ext/tokenizer Enabling ext/wddx Enabling ext/xml Enabling ext/zlib Checking for zlib.lib ... Checking for zlib.h ... ..\zlib Creating build dirs... Generating files... Generating Makefile Generating main/internal_functions.c Generating main/config.w32.h Done. Type 'nmake' to build PHP E:\home\php\php5>nmake Microsoft (R) Program Maintenance-Dienstprogramm: Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. Alle Rechte vorbehalten. bison --output=Zend/zend_ini_parser.\ -v -d -p ini_ Zend/zend_ini_parser .y Zend/zend_ini_parser.y: conflicts: 4 shift/reduce Zend/zend_ini_parser.y: warning: conflicting outputs to file `Zend/zend_ini_pars er.\\' bison: cannot open file `Zend/zend_ini_parser.\': No such file or directory NMAKE : fatal error U1077: 'bison' : Rueckgabe-Code '0x1' Stop. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New win32 build system
Wez Furlong wrote: > Finally, you need the php_build dir that contains all the > headers and libraries for the things that php is linked > against; see [1] for details. The current version of this archive does not contain libxml2/libxslt. It would be nice if these could be added and even nicer if the contents of this archive could be stored in CVS and have a cronjob automatically package the archive. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
