[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 18:07 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: BTW, there's no good reason not to load all of the extensions you may need in all of your scripts from php.ini. Loading many extensions doesn't pose a significant/noticeable load. Loading using dl() does. Can you explain why the difference matters? Sure. dl() means that module_init is done multiple times. It also means that module_shutdown is done multiple times, *and* has to take care of cleaning up after the extension *completely*. That is, clean whatever functions, classes, ini entries and callbacks this function may have registered. Right now, only PHP functions and ini entries (to a degree) are handled properly. Drawbacks: - It's slow. We encourage putting expensive operations into the module_init, using dl() means they end up being done multiple times. - Under Apache, it's even worse - since in addition to slowliness, it also ends up consuming significantly more memory, since any memory the extension allocates in module_init (e.g., the function entries it registers) cannot be shared between the processes. - It prevents the engine from optimizing function calls at compile time, by looking at what kind of arguments these functions expect. This is left for run-time, which results in significantly slower run-time performance. - Literally, none of the extensions properly cleans up after itself, leaving PHP in various degrees of instability. This rarely translates to crashes, because people don't usually have a script in which they dl() and then use a class, another script in which they use the class without dl()'ing first, and call the 2nd script right after calling the 1st one. Still, from a cleanliness perspective and in theory, it's bad. - Another buglet resulting from this is the crash in debug mode, in case of a memory leak inside an extension, which is reported in the bugs db. It's no biggy, but also has no good solution. I don't think the solution should be fixing all of the extensions to clean up after themselves, when the only gain is having dl() work, and when using dl() is almost always(*) significantly worse than simply adding the extension to the php.ini file. (*) I can't think of any case in which it isn't, but I'm staying humble :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
See my letter to Andrei. I've yet to see an ISP that (knowingly) allows users to load extensions, and wouldn't agree to add them to the php.ini file. This isn't a case of me saying users don't need X or 95.6% of the scripts out there don't need Y. This is me saying that dl() is *bad*, even if people got used to using it, which is why it should be deprecated. Again, notice that it has been deprecated for a long while in thread-safe mode, which means people who develop under Windows (a huge share) don't have it for over a year. dl() is bad in pretty much every sense, including the new sense you mentioned in your letter - dl()'ing extensions in a shared environment. Forcing the ISP to admit any extensions into the php.ini file before it gets loaded to the server is a good thing. If dl() is one of PEAR's foundations, it's time to dig it up and replace it with something more sound and stable :) Using php.ini for loading extensions should be the way to go. Zeev At 18:18 06/08/2001, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] Please don't just say it's useful, please say why :) dl() has absolutely nothing over loading in php.ini, and has many drawbacks. Please allow me to coin a new term: Zeev-ism. Zeev-isms are of the form users don't need X or 95.6% of the scripts out there don't need Y. ;-) The fact is that a lot of people (typically ISP users) don't have access to php.ini or .htaccess. If these people need a third party extension, or one that was not built in their ISP's version of PHP, they either have to get their ISP to include it (and if the ISP is big enough and the client small enough, they won't care), or use dl(). If their ISP hasn't disabled that function, in which case they're screwed anyway of course. I do get kinda worried when you pop out a statement like we're probably going to deprecate dl() anyway, being able to load extensions at run-time sort of is one of PEAR's foundations. Let's try to fix these problems rather than cripping PHP. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [patch] INIT_OVERLOADED_CLASS_ENTRY fix
It's not a big deal and we can commit it (as it's done in the 'put-expensive-operations-here' part of PHP, the module-init, hint hint :). However, is it really necessary? Zeev At 05:53 06/08/2001, Sterling Hughes wrote: Hey, The attached patch adds support for passing a variable to INIT_*CLASS_ENTRY in the name field (instead of just passing a constant string). I've needed this for a function which provides API functionality, registering classes with Zend based on the information passed to it. -Sterling Ps: The Midguard folks needed this feature/ran up against this wall awhile ago as well. Its the only reason I was able to find the problem without hours of painful debugging ;-) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 06:30 06/08/2001, Sterling Hughes wrote: On Mon, 6 Aug 2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. Of course there is. One example is using the same PHP binary to run scripts that use different extensions that wouldn't necessarily want to load all the time through php.ini. Also, just to mention, right now it might not be that big a deal to load them all in php.ini (well something as big PHP-GTK would be, but...), however, as PHP gets more and more extensions written in C, there needs to be this functionality. Why? Whatever extension you use on your box, put them in the php.ini. dl() is never a better option. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
By the way, I can't really quantify significantly, as it depends on what kind of minit you have. For a module such as the COM module, it can double the amount of time it takes the script to run (if you load typelibs). For some other modules, it can be almost anything, if your minit is mostly empty. As a general rule, it's a bad thing, since it repeats things which don't have to be repeated. At 18:34 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: Drawbacks: - It's slow. We encourage putting expensive operations into the module_init, using dl() means they end up being done multiple times. - Under Apache, it's even worse - since in addition to slowliness, it also ends up consuming significantly more memory, since any memory the extension allocates in module_init (e.g., the function entries it registers) cannot be shared between the processes. This doesn't apply under the standalone version, which is what I'm mainly worried about. - It prevents the engine from optimizing function calls at compile time, by looking at what kind of arguments these functions expect. This is left for run-time, which results in significantly slower run-time performance. Can you quantify significantly? - Literally, none of the extensions properly cleans up after itself, leaving PHP in various degrees of instability. This rarely translates to crashes, because people don't usually have a script in which they dl() and then use a class, another script in which they use the class without dl()'ing first, and call the 2nd script right after calling the 1st one. Still, from a cleanliness perspective and in theory, it's bad. I see. I wasn't aware that the extension was supposed to clean up the classes it registers. I will fix PHP-GTK behavior on this. -Andrei Linux is like living in a teepee. No Windows, no Gates, Apache in house. - Usenet signature -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 19:29 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: By the way, I can't really quantify significantly, as it depends on what kind of minit you have. For a module such as the COM module, it can double the amount of time it takes the script to run (if you load typelibs). For some other modules, it can be almost anything, if your minit is mostly empty. As a general rule, it's a bad thing, since it repeats things which don't have to be repeated. I thought you meant significantly worse run-time perfomance because the engine can't optimize for function arguments, not because of what kind of MINIT an extension has. We're still talking about standalone PHP binary here. Ah. Well, YMMV. If you have repeated calls to functions (not class methods, these are not optimized), it can be quite significant - you have an extra opcode that includes some stack manipulation, string duplication and strtolower of the function name, and slower pass_param opcodes. I never actually benchmarked it, but it can be quite significant. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 19:40 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 19:45 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. I have no problems with JIT-Init. We even have a marketable name for it, then. :) :) Anyway, I'm off for a few hours now, reinstalling my machine. I'll answer anything that comes up when I get back ;) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.cincomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 6 Aug 2001, Sterling Hughes wrote: On Mon, 6 Aug 2001, Zeev Suraski wrote: At 19:40 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. Interesting -- what about the extra weight of 50 extensions instead of just one? I think the disk weights about the same regardless of the data inside it :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.cincomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
On Mon, 6 Aug 2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: I think the disk weights about the same regardless of the data inside it :) Yes, but 50 extensions will consume more memory than 1. Nothing noticable, really. Unless you allocate dozens of megabytes in your extension, it won't pose any significant memory load, as it only loads once, shared across all processes/threads of the server. This is not true if you dl() it, by the way. Zeev -- Zeev Suraski [EMAIL PROTECTED] http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 23:57 06-08-01, Sander Steffann wrote: Hi, Deprecate dl()? I think it's one of the most useful functions... :) How so? I can understand that people get used to it, but it's really bad. extensions should be loaded in the php.ini file. There's really no good reason for using dl() over the php.ini method. I agree with you when we are talking about using PHP in a webserver. However, I am seeing more and more use of PHP as a generic scripting language. In this situation, I think dl() is very useful... Imagine a application written in PHP that has a 'special' extension. For example, an extension to access a scanner. You don't want this loaded everywhere, just in your scanner application, and certainly not in your webserver. You can achieve the same goal using a command line entry. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
I disagree in two levels. First, I think that saying We can't protect people from their stupidity, so let's lift all bars is just plain wrong and a bad approach in a real world situation. Sure, it's true, but we can definitely reduce the risks involved in common mistakes that people make. Not bulletproof, but sometimes simply hinting people not to go around places where shots are fired is good enough. On the second level, there are several other reasons not to keep dl() which aren't related to security or preventing people from doing the wrong things. These are: - Slow performance, encourages slow app writing - Complicates the development of extensions and the engine - Will not work in thread safe mode All in all, dl() is simply bad, in just about every level. Zeev At 00:03 07-08-01, George Schlossnagle wrote: In a few words: For a webserver: ban dl() For generic scripting: keep dl() What's really the point of protecting people from their stupidity. If you're going to keep it in the generic scripting engine (which I think has lots of value), why not keep it in the webserver engine as well. There are plenty of php extensions which, imho, operate way to slow to called on a busy production site. Does that mean they should be eliminated? No, it means they should just be used with a 'buyer-beware' mentality. George -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: undefined symbol: zendtext
Looks like I forgot to commit my final fixes... I'll commit them as soon as vmware is reinstalled and I have my Linux box back... At 22:25 06-08-01, Jani Taskinen wrote: I'm getting this with latest CVS. On apache startup. After Zeev's latest commits. I have tried a clean checkout too..no help. --Jani -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.7 coming ... ?
Considering the amount of changes done, plus the few changes pending, plus the QA time, I'd say that it's at least a month away, probably more... Zeev At 00:58 08-08-01, Colin Viebrock wrote: Just planning some upgrades here at easyDNS and wondering if there is a plan yet for when 4.0.7 might be released? - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
At 10:39 08-08-01, Thies C. Arntzen wrote: On Wed, Aug 08, 2001 at 09:28:02AM +0200, Stig Sæther Bakken wrote: [Zeev Suraski [EMAIL PROTECTED]] At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Ok, so it's just a matter of minit_done and rinit_done properties for each module? Let's go for that, and either keep dl() or replace it with php_load_extension() (the difference being that the latter knows what file extension to use on your platform). sascha had a patch for this some time ago - the gain was near to zero. this might make sense once we hit the few hundred extension border... Right. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)
At 21:14 08-08-01, Jani Taskinen wrote: On Wed, 8 Aug 2001, Cynic wrote: At 20:02 8/8/2001, Zeev Suraski wrote the following: -- At 21:01 08-08-01, Jani Taskinen wrote: [moving this to php-dev] First: Great! Woohoo! Thanks Zeev! Andi helped with it too :) I vote for $_EVIL :) How about $_DONT_TOUCH_THIS ? :) Seriously though, I vote for $_REQUEST. After all, it contains data which is (generally) tied to one particular request... This reminds me that should the $_FILES be included in this data too? As it's also something you shouldn't trust and it's also coming from the user. Yep, $_FILES should probably be there too. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)
My top of the list is: $_REQUEST $_EVIL (Andi and I think it's really pretty good, but we both figured we'll end up going with a different alternative :) Zeev At 21:12 08-08-01, Jason Greene wrote: What about using the acronyms in any combination. like $_GPC and $_GC and etc -Jason - Original Message - From: Cynic [EMAIL PROTECTED] To: Jani Taskinen [EMAIL PROTECTED] Cc: Zeev Suraski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 1:25 PM Subject: Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...) At 20:14 8/8/2001, Jani Taskinen wrote the following: -- On Wed, 8 Aug 2001, Cynic wrote: How about $_DONT_TOUCH_THIS ? :) Seriously though, I vote for $_REQUEST. After all, it contains data which is (generally) tied to one particular request... This reminds me that should the $_FILES be included in this data too? As it's also something you shouldn't trust and it's also coming from the user. --Jani Yeah. And $_SESSION too. [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0.7
As those of you who are subscribed to php-cvs may have noticed, Andi and I implemented today the functionality I suggested to replace register_globals: - $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace $HTTP_*_VARS (the old vars still remain for downwards compatibility) - The new variables are auto-globals - they're available in all function contexts - there's no need to import them using the 'global' statement or reference them using $GLOBALS. - $_REQUEST (this name might change) - includes the data from $_GET, $_POST, $_COOKIE and $_FILES, all in one array, for those users who don't really care to differentiate between the various types of input. This change was my last major TODO item for PHP 4.0.7. At this point, we should try to get PHP 4.0.7 out the door soon. I suggest we branch 4.0.7 away next Tuesday, and start the QA process. This should give people enough time to make any final changes they want to put into 4.0.7. One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0 simultaneously, with the only difference between them being the default value for register_globals. This would create lots of noise and encourage people to start actually using the new $_GETfriends features, which can otherwise go unnoticed. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.7
At 21:51 08-08-01, Andrei Zmievski wrote: On Wed, 08 Aug 2001, Zeev Suraski wrote: As those of you who are subscribed to php-cvs may have noticed, Andi and I implemented today the functionality I suggested to replace register_globals: - $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace $HTTP_*_VARS (the old vars still remain for downwards compatibility) - The new variables are auto-globals - they're available in all function contexts - there's no need to import them using the 'global' statement or reference them using $GLOBALS. - $_REQUEST (this name might change) - includes the data from $_GET, $_POST, $_COOKIE and $_FILES, all in one array, for those users who don't really care to differentiate between the various types of input. This change was my last major TODO item for PHP 4.0.7. At this point, we should try to get PHP 4.0.7 out the door soon. I suggest we branch 4.0.7 away next Tuesday, and start the QA process. This should give people enough time to make any final changes they want to put into 4.0.7. One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0 simultaneously, with the only difference between them being the default value for register_globals. This would create lots of noise and encourage people to start actually using the new $_GETfriends features, which can otherwise go unnoticed. What about the import_globals() function that Rasmus suggested? If we turn off register_globals in 4.1, then we'd better have that function ready. Oh yeah, that's still on my TODO list for today :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.7
From what I understand, Sascha doesn't have time to do that in the near future, so waiting for this is probably not the right thing to do. Is this a new issue? Zeev At 22:01 08-08-01, Jason Greene wrote: There is one issue with 4.0.7 that probably should be fixed before branch. The build system currently adds a libtool flag into CFLAGS whether libtool is in link or compile mode. Since this option is only valid in compile, it gets passed to the compiler. This causes a warning with gcc, but for other compilers (a la SUN CC) they fail I emailed Sascha about this, and he said that these options have to be added to CFLAGS, in order to allow automake to still function correctly. So far it looks like the only solutions, is to get rid of automake, and if that is done, I would think that it should occur before branch. -Jason - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 1:48 PM Subject: [PHP-DEV] PHP 4.0.7 As those of you who are subscribed to php-cvs may have noticed, Andi and I implemented today the functionality I suggested to replace register_globals: - $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace $HTTP_*_VARS (the old vars still remain for downwards compatibility) - The new variables are auto-globals - they're available in all function contexts - there's no need to import them using the 'global' statement or reference them using $GLOBALS. - $_REQUEST (this name might change) - includes the data from $_GET, $_POST, $_COOKIE and $_FILES, all in one array, for those users who don't really care to differentiate between the various types of input. This change was my last major TODO item for PHP 4.0.7. At this point, we should try to get PHP 4.0.7 out the door soon. I suggest we branch 4.0.7 away next Tuesday, and start the QA process. This should give people enough time to make any final changes they want to put into 4.0.7. One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0 simultaneously, with the only difference between them being the default value for register_globals. This would create lots of noise and encourage people to start actually using the new $_GETfriends features, which can otherwise go unnoticed. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)
At 22:13 08-08-01, Thies C. Arntzen wrote: On Wed, Aug 08, 2001 at 09:20:55PM +0300, Zeev Suraski wrote: My top of the list is: $_REQUEST $_REQ would be even nicer - and less to type without hiding the meaning. I agree with Andrei on this one... $_EVIL (Andi and I think it's really pretty good, but we both figured we'll end up going with a different alternative :) evil might cause some moral/religious problems for some ppls, i don't think anything in PHP should be called like that. Hmm, interesting point :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Latest CVS Problem
I'm unable to reproduce this under Linux (non thread safe) or Windows (thread safe)... At 23:28 08-08-01, Andrew Lindeman formally [EMAIL PROTECTED] wrote: I can't use fopen (file) to get anything off the internet with the latest cvs... ? $file=fopen(http://php.net/,r;); fpassthru($file); ? Will produce Segmentation Fault (core dumped) No idea why, but it probably needs to be fixed. -- - Andy :) Black holes are where God divided by zero. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Current CVS crash (latest Zend changes)
Are you *sure* you're running the very current CVS, and not some snapshot? Zeev At 01:16 09-08-01, Simon Roberts wrote: Seems like the Zend changes that were just committed broke something - all scripts are causing a segfault. I'm looking at what changed now. Script: ?php phpinfo(); ? Configure: ./configure \ --with-apxs \ --without-midgard \ --without-pgsql \ --enable-debug; \ Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396 (gdb) bt #0 0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396 #1 0x403afef9 in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2393 #2 0x403a79cb in zendparse () at /usr/lib/bison.simple:432 #3 0x403cc57e in compile_file (file_handle=0xb2f0, type=2) at zend_language_scanner.l:364 #4 0x403c29cf in zend_execute_scripts (type=8, file_count=3) at zend.c:803 #5 0x403d587b in php_execute_script (primary_file=0xb2f0) at main.c:1304 #6 0x403d1a5e in apache_php_module_main (r=0x80dacf0, display_source_mode=0) at sapi_apache.c:90 #7 0x403d253a in send_php (r=0x80dacf0, display_source_mode=0, filename=0x0) at mod_php4.c:575 #8 0x403d258e in send_parsed_php (r=0x80dacf0) at mod_php4.c:590 #9 0x8054e8d in ap_invoke_handler () at eval.c:41 #10 0x806708c in ap_some_auth_required () at eval.c:41 #11 0x8067103 in ap_process_request () at eval.c:41 #12 0x805f6d7 in ap_child_terminate () at eval.c:41 #13 0x805f87a in ap_child_terminate () at eval.c:41 #14 0x805f9bd in ap_child_terminate () at eval.c:41 #15 0x805ffde in ap_child_terminate () at eval.c:41 #16 0x80608a3 in main () at eval.c:41 #17 0x4010918e in __libc_start_main (main=0x8060420 main, argc=45, ubp_av=0xb754, init=0x804fa3c _init, fini=0x808a53c _fini, rtld_fini=0x4000cf08 _dl_fini, stack_end=0xb74c) at ../sysdeps/generic/libc-start.c:129 (gdb) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Current CVS crash (latest Zend changes)
Can you send me the file that causes this crash?
At 01:32 09-08-01, Simon Roberts wrote:
Yes, the absolute latest - I saw the Zend changes come past cvs update.
The change looks to be a broken fix in r214 of zend_compile.c - Zend itself
is new to me (and fun :)
@@ -2374,6 +2379,10 @@
retval = zendlex(zendlval TSRMLS_CC);
break;
case T_CLOSE_TAG:
+ if (LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-1]=='\n'
+ ||
(LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-2]=='\r'
LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-1])) {
+ CG(increment_lineno) = 1;
+ }
retval = ';'; /* implicit ; */
break;
case T_OPEN_TAG_WITH_ECHO:
- Original Message -
From: Zeev Suraski [EMAIL PROTECTED]
To: Simon Roberts [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, August 09, 2001 10:19 AM
Subject: Re: [PHP-DEV] Current CVS crash (latest Zend changes)
Are you *sure* you're running the very current CVS, and not some snapshot?
Zeev
At 01:16 09-08-01, Simon Roberts wrote:
Seems like the Zend changes that were just committed broke something -
all
scripts are causing a segfault. I'm looking at what changed now.
Script:
?php phpinfo(); ?
Configure:
./configure \
--with-apxs \
--without-midgard \
--without-pgsql \
--enable-debug; \
Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
(gdb) bt
#0 0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
#1 0x403afef9 in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2393
#2 0x403a79cb in zendparse () at /usr/lib/bison.simple:432
#3 0x403cc57e in compile_file (file_handle=0xb2f0, type=2) at
zend_language_scanner.l:364
#4 0x403c29cf in zend_execute_scripts (type=8, file_count=3) at
zend.c:803
#5 0x403d587b in php_execute_script (primary_file=0xb2f0) at
main.c:1304
#6 0x403d1a5e in apache_php_module_main (r=0x80dacf0,
display_source_mode=0) at sapi_apache.c:90
#7 0x403d253a in send_php (r=0x80dacf0, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#8 0x403d258e in send_parsed_php (r=0x80dacf0) at mod_php4.c:590
#9 0x8054e8d in ap_invoke_handler () at eval.c:41
#10 0x806708c in ap_some_auth_required () at eval.c:41
#11 0x8067103 in ap_process_request () at eval.c:41
#12 0x805f6d7 in ap_child_terminate () at eval.c:41
#13 0x805f87a in ap_child_terminate () at eval.c:41
#14 0x805f9bd in ap_child_terminate () at eval.c:41
#15 0x805ffde in ap_child_terminate () at eval.c:41
#16 0x80608a3 in main () at eval.c:41
#17 0x4010918e in __libc_start_main (main=0x8060420 main, argc=45,
ubp_av=0xb754, init=0x804fa3c _init, fini=0x808a53c _fini,
rtld_fini=0x4000cf08 _dl_fini, stack_end=0xb74c) at
../sysdeps/generic/libc-start.c:129
(gdb)
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Current CVS crash (latest Zend changes)
At 02:49 09-08-01, Simon Roberts wrote: Aiee! I'd just done that, when I got your message. I'd deleted my entire php4 source dir, downloaded from CVS, rebuilt, and it appears to be working. Aiee. I'll keep an eye on it. Bugger (Sorry Zeev) That's fine. Self-repairing bugs are the ones I like best ;) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.7
We can add it as an experimental, sure. When do you think it'd be ready? Zeev At 12:14 09-08-01, David Eriksson wrote: Quoting Zeev Suraski [EMAIL PROTECTED]: This change was my last major TODO item for PHP 4.0.7. At this point, we should try to get PHP 4.0.7 out the door soon. I suggest we branch 4.0.7 away next Tuesday, and start the QA process. This should give people enough time to make any final changes they want to put into 4.0.7. Would you like Universe to be included in the CVS before the branch? (If someone did not notice, Universe is my new CORBA extension that will replace Satellite.) http://universe.2good.nu/ Regards, -\- David Eriksson -/- An expert in a particular computer language is really an expert in the work-arounds necessary to use this language to perform useful work. - Richard B. Johnson -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.7
I won't have time to mess with this... Everyone should make sure that they get their stuff in by Tuesday :) Zeev At 23:47 09-08-01, Jani Taskinen wrote: As the satellite extension has been experimental all of it's lifetime, and it doesn't even compile (at least very easily :) I'd say nuke that one, and put Universe in the CVS. Also, add a warning to configure for satellite '--with-satellite' which breaks the configure and instructs to use '--with-universe' instead and points to the README in there. Would this be good time to create that 'old_extensions' module/directory? And start moving those deprecated extensions there?? And as of 4.1 remove them from the release. A good thing might be to have one central config.m4 which holds all the old configure options, and warns people if they use them? ---Jani On Thu, 9 Aug 2001, Zeev Suraski wrote: We can add it as an experimental, sure. When do you think it'd be ready? Zeev At 12:14 09-08-01, David Eriksson wrote: Quoting Zeev Suraski [EMAIL PROTECTED]: This change was my last major TODO item for PHP 4.0.7. At this point, we should try to get PHP 4.0.7 out the door soon. I suggest we branch 4.0.7 away next Tuesday, and start the QA process. This should give people enough time to make any final changes they want to put into 4.0.7. Would you like Universe to be included in the CVS before the branch? (If someone did not notice, Universe is my new CORBA extension that will replace Satellite.) http://universe.2good.nu/ Regards, -\- David Eriksson -/- An expert in a particular computer language is really an expert in the work-arounds necessary to use this language to perform useful work. - Richard B. Johnson -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/sablot php_sablot.h
At 16:42 10-08-01, Rasmus Lerdorf wrote:
Again, making a bad situation worse is not a good thing. I never said that
my code's perfect, and indeed there are some places where there's still
direct reference to auto-defined variable names, which is not a good
thing. Instead of making the situation worse though, when I face something
like this, I tend to try and improve it.
What exactly have you improved? I agree that the macro duplication is
bad. But having everything, including visible auto-defined variables be
ZNED_ or zend_ doesn't make any sense to me.
An extension now looks like this:
::php_foo.h::
extern zend_module_entry foo_module_entry;
/* ZEND_FOO_API here? */
#ifdef PHP_WIN32
#define PHP_FOO_API __declspec(dllexport)
#else
#define PHP_FOO_API
#endif
#ifdef ZTS
#include TSRM.h
#endif
ZEND_MINIT_FUNCTION(foo);
ZEND_MSHUTDOWN_FUNCTION(foo);
ZEND_RINIT_FUNCTION(foo);
ZEND_RSHUTDOWN_FUNCTION(foo);
ZEND_MINFO_FUNCTION(foo);
ZEND_FUNCTION(my_func);
ZEND_FUNCTION(your_func);
ZEND_BEGIN_MODULE_GLOBALS(foo)
int bar;
ZEND_END_MODULE_GLOBALS(foo)
#ifdef ZTS
#define FOOG(v) TSRMG(foo_globals_id, zend_xmms_globals *, v)
#else
#define FOOG(v) (foo_globals.v)
#endif
::foo.c::
ZEND_DECLARE_MODULE_GLOBALS(foo)
function_entry foo_functions[] = {
ZEND_FE(my_func, NULL)
ZEND_FE(your_func, NULL)
}
zend_module_entry foo_module_entry = {
foo,
foo_functions,
ZEND_MINIT(foo),
ZEMD_MSHUTDOWN(foo),
ZEND_RINIT(foo),
ZEND_RSHUTDOWN(foo),
ZEND_MINFO(foo),
STANDARD_MODULE_PROPERTIES
};
#ifdef COMPILE_DL_FOO
ZEND_GET_MODULE(foo)
#endif
static void php_foo_init_globals(zend_foo_globals *foo_globals)
{
foo_globals-bar = 0;
}
ZEND_INI_BEGIN()
STD_ZEND_INI_ENTRY(foo.bar, 0, ZEND_INI_ALL, OnUpdateInt, bar,
zend_foo_globals, foo_globals)
ZEND_INI_END()
PHP_MINIT_FUNCTION(foo)
{
ZEND_INIT_MODULE_GLOBALS(foo, php_foo_init_globals, NULL);
REGISTER_INI_ENTRIES();
return SUCCESS;
}
ZEND_MSHUTDOWN_FUNCTION(foo)
{
UNREGISTER_INI_ENTRIES();
return SUCCESS;
}
ZEND_MINFO_FUNCTION(foo)
{
php_info_print_table_start();
php_info_print_table_header(2, foo support, enabled);
php_info_print_table_end();
DISPLAY_INI_ENTRIES();
}
ZEND_FUNCTION(my_func)
{
zval **foo_arg;
int argc = ZEND_NUM_ARGS();
int foo;
if (argc 1 || (argc zend_get_parameters_ex(argc, foo_arg) ==
FAILURE)) {
ZEND_WRONG_PARAM_COUNT();
}
convert_to_long_ex(foo_arg);
foo = Z_LVAL_PP(foo_arg);
REUTRN_LONG(foo);
}
Is this really what the goal is here? It seems like a contest to see how
many times Zend can appear in the code. I think some of this stuff
should be PHP_ or for things that really are engine related, perhaps
ENGINE_ to at least pretend that this is a modular architecture where if
someone was brave enough they could try to use the modularity and plug in
another engine.
There was no need to write this long Email just to make the simple point
that you want to make PHP modular in the other way, which it isn't and
never designed to be. Yes, PHP is completely dependant on the Zend engine,
and it's not supposed to be easy to plug in another scripting engine. When
Andi and I separate the engine from PHP it was with one goal - having the
ability to reuse it in applications other than PHP. I remember that you
immediately thought about it the other way around, but it's not any more
true today as it was then, and if you recall, I told you that right
away. An app built on a certain infrastructure is dependant on that
infrastructure, but not the other way around.
However, if everyone on php-dev thinks the above look to a PHP extension
is just fine, I'll stop bickering.
I'm +1 on that :)
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/sablot php_sablot.h
At 17:08 10-08-01, Sascha Schumann wrote: away. An app built on a certain infrastructure is dependant on that infrastructure, but not the other way around. You wrongly assume that the API is equal to the implementation. PHP can use an API which is completely independent of the Zend engine. If I didn't know that the only thing that telling you the truth would be encouraging you, I'd say it. But you're smart enough to figure out what I would have said yourself. However, if everyone on php-dev thinks the above look to a PHP extension is just fine, I'll stop bickering. I'm +1 on that :) -1 here. Bicker on then, bicker on. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/sablot php_sablot.h
Guys, It's really simple, even trivial soft-dev issue, which is discussed in a completely broken manner, because you pour politics into the picture. The Zend Engine is the infrastructure of PHP. Until there's another engine, which is nowhere at sight nor is there any good reason to have one, PHP has one way dependency on the Zend engine, and is basically an app built on top of it. As such, it uses its macros, data types and functions. Duplicating the macros was bad. Period. There's no argument about it from a soft-dev point of view. It's the basic rule of no-code-duplication. I hope nobody disagrees with me on that one. So, where should the macros reside? Let's see. They can either reside in the app that uses them, or the infrastructure that defines their very existence. That's not a very tough call in my book (Jason - you got it pretty wrong with the 'so is any other scripting engine'; The Zend API, on top of which PHP is built is very specific, and there's no other engine in existence that implements any API which resembles it; PHP is already tightly coupled with this infrastructure, long before I nuked the macro bloat). Sascha's right, in the sense that if we were to abstract PHP to support multiple engines, the API and the implementation of the API wouldn't have been the same. In that case, PHP would have had some glue layer between itself and whatever engine it was using. At the risk of encouraging Sascha to write a new engine just to make a point, we aren't in a situation where we need to abstract PHP for multiple engines, nor is there any good reason for ever arriving to such a situation. We're not ASP with several pluggable syntaxes. Do PHP modules contain too many ZEND strings? Just as much as they should, since in practice, they are Zend modules. We can still define PHP macros to wrap the Zend ones for 'political' reasons, I personally think it's childish, but it wouldn't be a first... The advantage to using the Zend API macros directly is that the modules could be compiled outside the context of PHP, and load into the engine in other apps that use this engine in the future. This is just another example of why the basic soft-dev rule of putting the infrastructure-derived macros in the infrastructure and not in the application on top of it is correct. Zeev At 17:21 10-08-01, Jason Greene wrote: Is this really what the goal is here? It seems like a contest to see how many times Zend can appear in the code. I think some of this stuff should be PHP_ or for things that really are engine related, perhaps ENGINE_ to at least pretend that this is a modular architecture where if someone was brave enough they could try to use the modularity and plug in another engine. There was no need to write this long Email just to make the simple point that you want to make PHP modular in the other way, which it isn't and never designed to be. Yes, PHP is completely dependant on the Zend engine, and it's not supposed to be easy to plug in another scripting engine. When Andi and I separate the engine from PHP it was with one goal - having the ability to reuse it in applications other than PHP. I remember that you immediately thought about it the other way around, but it's not any more true today as it was then, and if you recall, I told you that right away. An app built on a certain infrastructure is dependant on that infrastructure, but not the other way around. However, if everyone on php-dev thinks the above look to a PHP extension is just fine, I'll stop bickering. I'm +1 on that :) Zeev I do have to agree with Rasmus here. Yes, Zeev, PHP is completely dependant on its engine, but the macro names are not acting like a truly modular system. The analogy I come up with here is a hash table data structure. What if instead of having a neutral hash_function = weinberger_hash, you had weinberger_hash = whatever. This name convention really does not make much sence, becuase it implys that every hash function must be a weinberger algorythym. If you take a look at the ZEND_FUNCTION macro, this suggests to the module developer that he is writing a function for the ENGINE not the language. You are right that it is the engine's job to register functions, module names, etc. However that is the description of ANY engine, not just Zend. If you are to say that you are modular you MUST be able to clearly differiantiate between all the modules of the system, and yes any of those module should be capable of being replaced. I am not saying that anyone should even try to replace the engine, but I am saying there should be clear distinction between the components of PHP. If I could argue anything else, I would argue simple readibility. It should be clear to the PHP developers that they are using the systems API not one module that is a part of the system even if that module is the engine. -Jason
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/sablot php_sablot.h
At 17:31 10-08-01, Andrei Zmievski wrote: On Fri, 10 Aug 2001, [EMAIL PROTECTED] wrote: This is not about renaming, it's about removing duplicate macro's. Of course it's about renaming. We used to have just PHP_* macros and then Zeev added the ZEND_* versions and now PHP_* ones are just aliased to ZEND_* ones for backwards compatibility. From a technical perspective, if I change the prototype of the activation function, which is obviously in the engine, how does it make sense that I'll have to change macros outside the engine, instead of changing them inside the engine? Or worse, change them in two places? If there's more Zend-o-phobia, we can have #define PHP_* ZEND_* for some Zend macros. I see a benefit in having modules compile independently of PHP so that they can plug into the stand alone engine in the future, but frankly, I don't care too much - we can move them to php.h instead of php3_compat.h. It doesn't change the fact that the replicated macros had to go. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/sablot php_sablot.h
At 19:06 12-08-01, Zeev Suraski wrote: I don't think that this happens too often - I think that comments like Sebastian's are much more Ick, Sterling's that is. Sorry Sebastian ;) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/sablot php_sablot.h
At 14:03 13-08-01, Sterling Hughes wrote: Just to clarify -- I don't think the issue should be ignored -- I just feel that php-dev@ is not the appropriate place for such stuff. Take it up on group@, or find some place else to deal with it (or perhaps another developer meeting where these issues could really be worked on, face to face?) I don't really agree (the only relevant forum is php-dev in my opinion, group is only for administrative stuff), but let's give it a rest for now. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] $_SESSION
Were/are the register_global entries and $HTTP_SESSION_VARS[] entries references to each other or not? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: use indent instead of fixing whitespace by hand?
At 14:31 12-08-01, Thies C. Arntzen wrote: guys, it's really time to setup our own indent(1L) profile and simply run everything in php4/ thru it. i'll spend some time playing with it (while i'm on vacation) unless: does anybody see a reason *not* to swicht to indent (manybe even intergrated into out CVS) once we have a satisfying settings for it? please speak up now - i really don't want to waste my time on it if somebody has a good technical reason why this (running php-sources thru indent) won't work. I think it can be a very good thing, even though it may get a bit tough, it's probably worth trying. Things to watch for: - We have to make a list of each and every last data type that is being defined or used in the php4 source tree. It's going to be a bitch :) - We need to see whether indent knows how to properly handle macros that create function prototypes, etc. As we use macros extensively, if it can't handle them too well, it can probably rule it out. I vaguely remember bumping into trouble with indent a couple of years ago (as you may know, we did use to have a 'make indent' configuration in the php3 days). I don't remember if it was a dead end, or just something I didn't have the mental strength to deal with back then... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] associative arrays
At 12:47 13-08-01, Markus Fischer wrote: I was just kidding, really. You sure have fooled me ;) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #12721: PHP crashes at any code-highlight related command
At 20:07 13-08-01, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Redhat/7.0, kernel 2.2.16 PHP version: 4.0.6 PHP Bug Type: Reproducible crash Bug description: PHP crashes at any code-highlight related command I have (over several versions of apache and php) noticed a very strange bug: PHP keeps crashing the Apache when using .phps files or any of the highlight_*() family (including show_source, of course). The child dies with SIG11, gdb output follows: -- SNIP -- Core was generated by `/usr/local/apache/bin/httpd'. Program terminated with signal 11, Segmentation fault. #0 0x400097fd in ?? () (gdb) bt #0 0x400097fd in ?? () #1 0x4000cea0 in ?? () #2 0x4000d020 in ?? () #3 0x8061793 in php_fopen_primary_script () #4 0x400cfbfc in ?? () -- SNAP -- phpinfo() is at http://www.de-punkt.de/info.php There have been *no* similar issues on this machine (i.e. a build of mysql, which should evoke generic memory or CPU issues as well, runs through pretty clean), it only keeps crashing with PHP (and the Zend Cache, that is ;-) ). Does it crash every time - will a simple highlight_string(hello); crash it? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Branching 4.0.7RC1 today
Just a reminder - I plan on branching 4.0.7 today as planned, in a few hours. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
At 10:23 15-08-01, Stig Sæther Bakken wrote: [Hi, I think one of the problems with this is that even if php-dev comes up with a system for determining which feature it wants to see in PHP, we still depend on Zeev, Andi or someone else @ Zend to implement them. An RFC system would be a support for Zend's decision-making. At the end of the day, due to the licensing issues, php-dev is not the body governing the language, it has an advisory role only. Generally, I agree with you, except it's not because of licensing issues (will we end up with a load of features suddenly getting into PHP if/when the engine license changes?). Many other projects behave that way. With a language definition, vox populi, vox Dei doesn't tend to work very well. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
At 12:15 15-08-01, Sterling Hughes wrote: On Wed, 15 Aug 2001, Zeev Suraski wrote: At 10:23 15-08-01, Stig Sæther Bakken wrote: [Hi, I think one of the problems with this is that even if php-dev comes up with a system for determining which feature it wants to see in PHP, we still depend on Zeev, Andi or someone else @ Zend to implement them. An RFC system would be a support for Zend's decision-making. At the end of the day, due to the licensing issues, php-dev is not the body governing the language, it has an advisory role only. Generally, I agree with you, except it's not because of licensing issues (will we end up with a load of features suddenly getting into PHP if/when the engine license changes?). Many other projects behave that way. With a language definition, vox populi, vox Dei doesn't tend to work very well. Yes, the difference is, this creates a situation where the PHP Development team does not have control of the core language, Zend Technologies Ltd. does. Whether this is a issue with a basis in principle or a basis in practicality is up to debate, however, the problem remains. Sterling, that's bull - popular perhaps - but still, bull. Zend as a commercial entity doesn't decide on PHP's features. Nobody in Zend has control over the language just because he's a Zend employee. Other Zend employees participate in the discussions just like the rest of you, and often make quite constructive remarks, just like the rest. However, it's not as if Zend employees can muck around the language, whereas php-dev can just stand on the side watching. We all like to look up at corporations, blame them for the problems and rebel. It's basic human nature. It just has very little to do with reality in this case. Nothing, in practice, except for that license everybody enjoys bashing (and I claim again and again, that it won't make a radical change if it changes, except for perception). Andi and myself regulate the engine, on a personal basis, since 1997, and it has nothing to do with Zend (which was founded towards the end of 1999). Between us, as a commercial entity, nobody could care less whether there are advices, namespaces or how exactly the object model would look like. That's why the situation wouldn't change radically if/when the engine license changes, much like it wasn't any different *before* the engine license was even introduced, in the PHP 3.0 days. Having regulators over the 'kernel' of the project is certainly not very unique to the PHP, and had a significant role in bringing PHP to where it is today, and not where Perl is today, for example. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Please..
At 13:06 15-08-01, Jani Taskinen wrote: p.s. Zeev, did you forget to tag the Zend / TSRM for 4.0.7 ?? Nah, I even did that last night at 2am... But I got a bug report in the CGI that required fixing, and there's some COM patch that should go in before RC1, so RC1 will be delayed in a few hours... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Please..
At 13:13 15-08-01, Sascha Schumann wrote: On Wed, 15 Aug 2001, Jani Taskinen wrote: Can you guys give up these childish fights and just code? Telling people to just shut up will not resolve the issues which many of us think have to be addressed (regardless of how profane your language becomes). It is very unlikely that the bickering will stop, if a single company continues to exercise so much control over the future of an open system such as PHP. If you feel like bickering, go on bicker and make populist statements as much as you'd like, just let the rest of us do what we're good at, which is developing PHP. Perhaps setting up a separate mailing list like Sterling suggested, a-la [EMAIL PROTECTED] isn't such a bad idea. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Please..
At 13:43 15-08-01, Sebastian Bergmann wrote: Jani Taskinen wrote: Can you guys give up these childish fights and just code? These are not childish fights. Yes they are. They are on childish topics, lead nowhere and consume lots of our time. And I assume there are some people out there, just like Sascha and Thies, who are waiting to code and contribute the Zend Engine, once the license gets changed. You have absolutely no reason to assume that this is the case, except for the license noise that was spawned by the same people who spawn these pointless threads on php-dev. I believe Hartmut will help documenting the API, but that's about it. But chaning the license is only one step that Andi and Zeev need to take, IMHO. A second one would be documenting the Zend Engine's internals. And this can only be done properly by Andi and Zeev, since they planned and coded it. Looking at zend_compile.c and zend_execute.c today just gives me the creeps, from a software developer's view: nearly no comments. Of course, I can guess what is done where, since I know a bit on compiler theory. But with a proper documentation, people like Sascha and Thies could start with their work on the engine right away -- without learning (by guessing) how the Zend Engine actually does what it does. While the Zend API could easily be documented, or updated from what's in ZendAPI on cvs.zend.com, from any developer who wrote some PHP extensions, the documentation of the Zend Engine itself and its internals can IMHO only be done by its creators. With all due respect, 'you get what you pay for' works as far as documentation goes in open source. Fact is, we don't *need* to do *anything*. Nobody in an opensource project does. What we do we do because it's fun (which these threads do a good job of ruining) and because it's interesting. Not because we have to do it. I never liked writing documentation. I don't think that developers in most other opensource projects are significantly different, neither are most of the other developers in the PHP circle (it's not as if the rest of PHP is too documented... Where are the SAPI docs, or the fopen wrappers docs, or the session docs?). Try to understand the Perl source code, for example. For me, things work just fine the way they are, and I'm not searching for extra stuff to do. If somebody finds the entry level too steep to contribute to the engine, by all means, either try to document it, or go away. Don't say that I *have* to do it, because I don't. Sorry for the somewhat aggressive tone, but it's kind of annoying to see people demanding things from you, when you're a volunteer. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Please..
At 13:41 15-08-01, Sascha Schumann wrote: If you feel like bickering, go on bicker and make populist statements as much as you'd like, just let the rest of us do what we're good at, which is developing PHP. Perhaps setting up a separate mailing list like Sterling suggested, a-la [EMAIL PROTECTED] isn't such a bad idea. Thanks for proving that you are not interested in a dialogue. If bickering is your definition of dialogue then all I can say is - you're quite welcome! Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Please..
At 13:53 15-08-01, David Hjortsoe wrote: For me this means that no matter what happens to Zend, the PHP Group can, if it wishes to do so, continue to develop the ZE without any restrictions except to keep the ZE under the license that it is currently under, am I missing something? The only thing you're missing is the point of these threads. They have very little to do with the situation itself, and everything to do with politics. If, God forbid, you only look at the facts - then you're not missing anything. Thanks for providing a rational look! Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
At 18:13 15-08-01, Andrei Zmievski wrote: On Wed, 15 Aug 2001, Zeev Suraski wrote: like. That's why the situation wouldn't change radically if/when the engine license changes, much like it wasn't any different *before* the engine license was even introduced, in the PHP 3.0 days. Having regulators over the 'kernel' of the project is certainly not very unique to the PHP, and had a significant role in bringing PHP to where it is today, and not where Perl is today, for example. You always compare PHP to Perl. How about Python? It's a well designed language that's pretty open for development.. Look at their PEPs system. And you always compare to Python :) I try to compare apples and apples. I don't see Python as an equivalent of PHP, whereas I do see Perl as something that had to potential to be a good thing, and blew it. There are also many other, non-language examples, of opensource projects that work in the same way. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] SAPI_API glitch
Is there any reason to have them even exported? I think we can just nuke SAPI_API altogether (I could be wrong, we might be referencing them somewhere, but I don't think we do) At 17:58 15-08-01, Daniel Beulshausen wrote: hi currently if extensions want to define their own SAPI_POST_*_FUNC (fdf, mbstring) they'll run into trouble, because they are defined as 'SAPI_API void ... my_handler'. this however doesn't work, because you'll need to define SAPI_EXPORTS (to export it) and are thus loosing the sapi_globals_id (which must be imported). nuking SAPI_API from the macro, and using (SAPI_API || PHP_EXT_API) SAPI_POST_*_FUNC would avoid this glitch. anyone objects? daniel /*-- daniel beulshausen - [EMAIL PROTECTED] using php on windows? http://www.php4win.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] SAPI_API glitch
At 18:40 15-08-01, Daniel Beulshausen wrote: At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote: At 18:20 15.08.2001 +0300, Zeev Suraski wrote: Is there any reason to have them even exported? I think we can just nuke SAPI_API altogether (I could be wrong, we might be referencing them somewhere, but I don't think we do) not sure, but we can add it later if it breaks :) no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf extension) They are what? :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] SAPI_API glitch
At 20:20 15-08-01, Daniel Beulshausen wrote: At 19:33 15.08.2001 +0300, Zeev Suraski wrote: At 18:40 15-08-01, Daniel Beulshausen wrote: At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote: At 18:20 15.08.2001 +0300, Zeev Suraski wrote: Is there any reason to have them even exported? I think we can just nuke SAPI_API altogether (I could be wrong, we might be referencing them somewhere, but I don't think we do) not sure, but we can add it later if it breaks :) no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf extension) They are what? :) breaking using exported SAPI_POST_* functions. i conclude, they still should get exported. :) Why? Are modules using any SAPI_POST functions which are defined in PHP? If they are, we should probably change the SAPI_POST_HANDLER definition not to include SAPI_API, and add the SAPI_API explicitly before those functions which are referenced by modules. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 4.0.7RC1 rolled
http://www.php.net/~zeev/php-4.0.7RC1.tar.gz (not mirrored) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] SAPI_API glitch
At 20:35 15-08-01, Daniel Beulshausen wrote: isn't that exactly what i meant in my first mail? :) I'm thick ;) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] 4.0.7RC1 rolled
Done! At 21:32 15-08-01, Jani Taskinen wrote: Could you add a symbolic link for it: php-4.0.7RC-latest.tar.gz And keep that linked to the latest. --Jani On Wed, 15 Aug 2001, Zeev Suraski wrote: http://www.php.net/~zeev/php-4.0.7RC1.tar.gz (not mirrored) -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
At 21:24 15-08-01, Sterling Hughes wrote: Oh - I see! So the Zend on the License is really just shorthand for Zeev and Andi, has nothing to do with Zend Technologies Ltd. Good to know. ;)) In practice, pretty much, yes. I don't remember Doron's, Adi's or Daniel's last contributions :) As I said -- this may have no basis in practicality -- I think it does to some extent, otherwise you wouldn't hear this many reasonable (but sometimes passionate) people complaining. Still, taking your assumption that the license and Zend's control of it is meaningless, why not go ahead and change the license today? If it means nothing, why are you with a license that causes such strife in the PHP community? A small part in the PHP developer community, mind you. As I told Stig, it is what you make of it - practically, it's nothing. If you'd like, I'll go setup a sourceforge project for the Zend engine today! I don't want to see the engine as a sourceforge project today, tomorrow, or anytime in the future, thank you very much :) As I said in LinuxTag, the license issue was blown out of proportion completely. It has no practical meaning for any PHP user or developer. Changing the license only means that we will no longer be able to re-license the engine to other companies who make commercial use of it. So basically, changing it means a loss of a source of possible income for Zend, while giving the PHP community nothing (MySQL AB *lives* from that source of income exactly). Perception wise, it might make the world much more rosy. To be bluntly honest, I seriously doubt it (we're not in a bad shape today, plus I have every reason to believe that things won't change radically ifwhen we change the license). As far as Zend is perceived, much like the license issue was a non issue until some made it an issue, I fear that once it's gone, there'll be something else to replace it. When you don't like somebody or something, you can find whatever suite of 'objective' reasons to back you up. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] basic_functions.c broken
Fixed. At 01:35 16-08-01, Alexander Wirtz wrote: Hi folks, basic_functions.c D:\home\php\php4\ext\standard\basic_functions.c(306) : error C2065: 'zif_exp2' : nichtdeklarierter Bezeichner D:\home\php\php4\ext\standard\basic_functions.c(306) : error C2099: Initialisier ung ist keine Konstante D:\home\php\php4\ext\standard\basic_functions.c(307) : error C2065: 'zif_exp10' : nichtdeklarierter Bezeichner D:\home\php\php4\ext\standard\basic_functions.c(307) : error C2099: Initialisier ung ist keine Konstante D:\home\php\php4\ext\standard\basic_functions.c(308) : error C2065: 'zif_log2' : nichtdeklarierter Bezeichner D:\home\php\php4\ext\standard\basic_functions.c(308) : error C2099: Initialisier ung ist keine Konstante I can confirm this on my linux-box: basic_functions.c:306: `zif_exp2' undeclared here (not in a function) basic_functions.c:306: initializer element for `basic_functions[157].handler' is not constant basic_functions.c:307: `zif_exp10' undeclared here (not in a function) basic_functions.c:307: initializer element for `basic_functions[158].handler' is not constant basic_functions.c:308: `zif_log2' undeclared here (not in a function) basic_functions.c:308: initializer element for `basic_functions[159].handler' is not constant basic_functions.c:310: `zif_cbrt' undeclared here (not in a function) basic_functions.c:310: initializer element for `basic_functions[160].handler' is not constant make[3]: *** [basic_functions.lo] Error 1 make[3]: Leaving directory /data/www/php4/ext/standard' Regards Alex -- | Alexander Wirtz | eMail: [EMAIL PROTECTED]| | web@ctive GmbH| WWW: http://www.web-active.com | -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Linux Today Article
Very nice non-PC statement! :) Zeev At 02:20 16-08-01, Blake Schwendiman wrote: Just my opinion, but right now (meaning this year, maybe a little longer) I feel that PHP is more than adequate for developing small, medium and large sites. I work on both sides of the fence. My day job has been developing portions of large web sites using ASP/COM/COM+ and the evolution of these tools which is the frame of the .NET product/service. For my personal and more interesting work, I prefer PHP by far. I feel that there is a mass of hype surrounding new development paradigms, but we are far from declaring one technology a winner. ASP is provided by a company with a great deal of resources and an interest in providing tools to its customers. I don't have a problem with that, but right now I don't think many of the customers really know what they want. With no offense intended toward many working hard on and with XML, I say XML hasn't proved its worth in very many places. I personally don't know anyone who is using XML for anything and very few who have plans to use it. So why should I get worried about whether a language currently supports one of its extensions. Am I using it? Are my customers using it? Really? The ASP model has some wonderful features. Components can be great, but too much componentization can be a nightmare. In my personal experience an enterprise component architecture is a double-edged sword. It's great to be able to plug in well-built components and use them, but the downside is that component writers disappear, companies go out of business, support can be difficult to obtain and so on. I've rambled a bit, but my feeling is that the Linux Today Article is premature. PHP can (and likely will) support the features mentioned in the article, but the real question is, are these really the features that are going to be used? Will I be developing web applications with these features in 1 year, 3 years or 5 five years? Is PHP or ASP (.NET) providing me with the real tools I need to develop web applications today? For me, both tools provide what I need today, but I like PHP better. Blake -Original Message- From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 15, 2001 2:30 PM To: php-dev mailinglist Subject: Re: [PHP-DEV] Linux Today Article Edin Kadribasic wrote: Where is the PHP enterprise component architecture? What exactly would that be? What about clustering and failover? This has nothing to do with the language, IMHO, but with the platform, ie. the web server. I guess there are solutions to provide clustering and fail-over to Apache and MySQL, for instance. Where are the WSDL and UDDI implementations? What are WSDL and UDDI? Are there libraries out there can be wrapped into an extension? Show me a framework. Horde is a framework, and I guess there are some more out there. But I fear that there is truth in this. We should analyze what, besides the upcoming changes on the language level (with the Zend Engine 2.0), we need to make PHP compatible with ASP.NET. Maybe Zend has some feedback from their enterprise clients on what features are requested, etc. -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Please..
As you know, most of your questions were hypothetical. I tried to answer them and take them seriously, even if they weren't very likely or serious :) At 11:05 16-08-01, Ron Chmara wrote: 1. If the relationship between Zend Tech and PHP becomes irreconcilable, can PHP and Zend fork and/or recover in some other means? Yes. 2. If all of the current PHP and Zend core developers die in a fire at a convention, can the codebase continue, or will the ZE possibly become the property of somebody who could demand $1,500 (USD) per server for licensing, and lock down the source, thus killing PHP and Zend? No. 3. Is the Zend license preventing useful submissions from people who write damn good code, but are FSF believers/zealots, so they refuse to contribute, because it doesn't have the RMS seal of approval? Yes. So does the PHP license, though, and many other licenses, like the ASF license. 4. If an alternate engine was written, would it be possible to use with PHP? Could an engine be written from Zend code, or would it have to be clean-room code, and if so, from what version of PHP? Obviously, other engines can be written. I was involved in writing two such engines in the past. Because parts in PHP are very tightly coupled with the engine infrastructure, it would have to be very similar to the existing engine, to a degree that makes it kind-of dumb to do in the first place. I'm not a lawyer, but I guess that if you were to call it your own, and release it under a different license, you would have to write it from scratch. 5. If, say, Microsoft beats Zeev and Andi in a Redmond basement for three weeks, until they sign away all rights with bloody, mangled hands, can PHP go forward, or does it have to back up? (See the tim robbins antitrust movie... he becomes a software giant through artful purchasing, and the occasional assasination...) They tried to, but we fought back bravely ;) What you make of this question depends on what you think our contribution is to the project. From a legal standpoint, it can go on just fine, we just won't be in the work force. 6. If a core member goes insane, can they damage PHP without being held in check somehow? If half the core dies, is it distributed enough that the other half can continue? Being a member of the PHP Group doesn't buy you too much nowadays. Core to the license debate: 7. Can the Q license currently used be adapted to meet the needs/fears of GPL/BSD and similar folks, without compromising the Zend Tech needs for having a saleable product? (there's quite a few licenses out there...) from what I understand, Stallman's complaint are the credits clauses, others are worried about selling closed source (ironically, isn't a Zend package designed specifically for this pupose?) I *really* don't care about Stallman specifically, or about GPL compatibility. I'm a strong supporter of the BSD style license, and if the Zend Engine license changes, chances are it will be to a BSD license, like PHP's. Core to the debate debate: 8. Do some people just need to shoot off some steam, and accomodate others who do? I get 1000+ emails a day, this is nothing in comparison. Of course, I also go days without reading certain lists, which helps. :-) I'll leave that one to somebody else :) Rasmus, Zeev and Andi are not eternal, neither is PHP or Zend. Planning now, however, makes the future easier. Some folks live in volatile parts of the world about to go to war, :-) , some do not. Some take breathers when they are angered, some do not. So I'm interested in how PHP survives everything from worst case to best case... it seems bulletproof, in code terms, because the Q license allows at least one form of forking, if not several. Right. Having now re-read the Q license a few times, the PHP license a few times, this seems unrelated to licensing, and more related to mindshare or the power fluctuations of a given group, or reactionary impulse to Zend being part commercial, part free. Even in worst case, PHP could recover in months to a year or so, with the hardest part being the social damage of bitter debate, or a focus entirely on an engine rewrite. I dunno. ANy lawyers on the list? At least you read it and tried to understood it, which is more than what the average person does... Anyways, I'm off to go play in the SF bay now. Have fun, folks! Have fun, Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Linux Today Article
I don't usually buy into long term visions, because they virtually never work. Microsoft changed its vision twice in the last 5 years, *completely*, from end to end. Sun (and the other Java followers) have also changed their Java vision several times during its short lifespan, also, from end to end. In reality, where a language goes is strongly decided by the userbase, and not by the vendors. In the .NET case it might work, because Microsoft is one of the only companies that actually stand a chance at imposing their will on the market, if what they offer is reasonably good (which .NET is, apparently). Giving it a try doesn't hurt, though. I just explained why I liked Blake's non politically correct statement :) Zeev At 10:58 16-08-01, Kristian Koehntopp wrote: On Thu, Aug 16, 2001 at 02:24:27AM +0300, Zeev Suraski wrote: I've rambled a bit, but my feeling is that the Linux Today Article is premature. PHP can (and likely will) support the features mentioned in the article, but the real question is, are these really the features that are going to be used? Very nice non-PC statement! :) A programming language is not only a tool and a framework, it also is a set of people sharing a common vision and working together - a community. What Microsoft provided with .net is not so much a product - yet. It is a vision, though, and a plan where they want to go in the next few years. So to compete here, PHP need not only be superior in technical checklist items, it also has to provide a kind of development roadmap, a plan where it wants to be in 3 and in 5 years, and what services it will provide to developers then. That is the PHP vision that the language and the system needs to stand the marketing onslaught by Microsoft. Note how other communities, notably Perl, provided such a vision in the past (e.g. the mythical Perl compiler), and continue to provide such visions now (e.g. Perl 6 and flexible scanners to turn Perl into the one language to parse all syntaxes). Larry provides even more - with his speeches and interviews he even provides a kind of philosophy behind Perl, a greater concept to explain not only how, but also why things have been done the way they have been done. As you can see in the case of Perl, the vision need not be final, useful or even true, it just needs to be cool, and believable. It is being used as a tool to bind the community tigther together, to provide hope and a sense of direction. To come back to PHP: What is the place of PHP in 3 and in 5 years, what are the next big projects tackled in the development of PHP, and what is the larger idea behind PHP - what does the language _want_ to become, and what audience will it cater. If you can answer these questions for your developing audience, these answers will have a large influence on the qualification and quantity of audience you have. PHP 2005 - If you code it, they will come. Kristian -- Kristian Köhntopp, NetUSE AG Dr.-Hell-Straße, D-24107 Kiel Tel: +49 431 386 435 00, Fax: +49 431 386 435 99 -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Please..
At 13:19 16-08-01, Sascha Schumann wrote: Having now re-read the Q license a few times, the PHP license a few times, this seems unrelated to licensing, and more related to You might want to reread the QPL then. The important point is clause 3 which prohibits distributing changes, unless they are provided as patches. This is highly unpractical, because it even does not permit you to run a CVS server where something simple as browsing the CVS using Chora or doing a checkout would already constitute distributing the changes. So, any source-code which is under the QPL will hardly become a source for further external development, because the changes are unmaintainable. From the annotated license: Any technique is acceptable for keeping changes separate - generally, you would have to mark changes very clearly for them to be separate. We don't want to hard-code the idea that the form must be patches. http://www.trolltech.com/products/download/freelicense/annotated.html (this is not an encouragement to make you fork, just pointing out that you're wrong). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Please..
At 13:39 16-08-01, Sascha Schumann wrote: From the annotated license: Any technique is acceptable for keeping changes separate - generally, you would have to mark changes very clearly for them to be separate. We don't want to hard-code the idea that the form must be patches. And that is exactly what they did. They explicitly suggest using patches. You are not safe to use anything else, because the interpretation of 'separateness' can differ from court to court. While courts usually listen to a license author's interpretation, the wording here needs improvements in order to meet the meaning of the Annotated License..As Applied To The Qt Free Edition Version 2.0. Could be. Chances are that with the company who wrote the license explaining what it meant the way it did, it'll be an uphill battle to fight against it. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Output Compression Issues
At 14:55 16-08-01, Troels Arvin wrote:
On Thu, 16 Aug 2001 07:44:50 +0200, John Donagher [EMAIL PROTECTED]
wrote:
So, we really want to disable output compression when we are serving
anything but HTML/text.
I agree on that. I have heard that some older versions of both major
browsers have trouble with compressed non-HTML content. - Or perhaps the
ob_gzhandler could be given an argument telling it to be conservative or
not?
- Oh, and please:
Could someone take a look at this bug which I really think is serious:
http://www.php.net/bugs.php?id=12631
As written, it's currently not possible to send proper Content-Length
headers along with gz-encoded PHP-output because it's not possible to
get the correct output-length information when using the gzhandler.
When Content-Lengh headers are not sent, then Apache is not capable of
using keep-alive == worse performance.
There are lines like this in zlib.c:
#if 0
} else {
char lenbuf[64];
sprintf(lenbuf,Content-Length: %d,Z_STRLEN_P(return_value));
sapi_add_header(lenbuf,strlen(lenbuf), 1);
#endif
What does #if 0 actually mean?
If it's too hard to change the output buffering system to return proper
content lengths, maybe it would be an idea to be able to tell
ob_end_flush() that you want a Content-Length header to be sent along?
(It seems that ob_gzhandler knows the correct Content-Length but is
unable to pass that information along to the output buffering system.)
The output buffering system knows how many bytes were returned, but it
doesn't really matter, as all it does with the returned bytes, is print
them out (the output buffering system itself is not programmable).
So, to summarize:
- Output compression should probably check that the content type is text/*,
and not perform compression otherwise
- We can look into sending the content length header from the output
compression callback
Can anybody think of good reasons not to send the content-length header in
case we're performing output buffering?
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Output Compression Issues
At 15:37 16-08-01, Troels Arvin wrote: On Thu, 16 Aug 2001 14:26:09 +0200, Zeev Suraski [EMAIL PROTECTED] wrote: Can anybody think of good reasons not to send the content-length header in case we're performing output buffering? I meant in case we're performing output compression :I Personally: No. - However, the docs for the output handling system seems to indicate that output buffering filters may be nested. I could imagine that this will pose troubles if Content-Length headers are sent along in each output buffering module(?): http://www.php.net/manual/en/function.ob-start.php Quoting: Output buffers are stackable, that is, you may call ob_start() while another ob_start() is active. Just make sure that you call ob_end_flush() the appropriate number of times. If multiple output callback functions are active, output is being filtered sequentially through each of them in nesting order. Yeah, I know :) However, the way it works, you're already pretty much screwed if you do anything with the compressed buffer anyway. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [[PHP-DEV] script type=... support (fwd)]
At 20:01 16-08-01, Chris Gardner wrote: actually, i think both TYPE and LANGUAGE are required for validation purposes. it really needs to support SCRIPT LANGUAGE=php TYPE=application/x-httpd-php but, as cynic put it best, i think it's a wonderful idea, but i don't know if i count . . . . Blah, you all count :) We need to look at what's the best way to support this though. HTML (or XHTML) is very loose as to which entry appears first, and to whatever other entries appear within the tag. The current scanner is not... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Output Compression Issues
At 21:27 16-08-01, Thies C. Arntzen wrote: On 16 Aug 2001 15:26:09 +0300, Zeev Suraski wrote: - Output compression should probably check that the content type is text/*, and not perform compression otherwise that means adding another sapi call - but i think it would make sense. Yep. - We can look into sending the content length header from the output compression callback if ithe output is not send as chunks we should do so - the original code for that (10 lines) was added by me and taken out by you a few days later when you added the chunking support. Ah, good point. That's exactly what I meant if somebody can think about good reasons not to do it :) Chunking is quite important, and there's no way we can know in advance how many bytes we're going to end up having. Unless we add in another output buffer. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Bug #12767 Updated: Apache compile with php4.0.6
At 21:22 16-08-01, Mike Hepworth wrote: The snapshot gives me the following error on the php make command: Making all in Zend /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I ../main -I../TSRM -g -prefer-non-pic -static -c zend_language_parser.c /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I ../main -I../TSRM -g -prefer-non-pic -static -c zend_language_scanner.c zend_language_scanner.c, line 2697.7: 1506-282 (S) The type of the parameters must be specified in a prototype. make: The error code from the last command is 1. Ick. What compiler is that? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Bug #12767 Updated: Apache compile with php4.0.6
Can you try the latest CVS? Zeev At 21:22 16-08-01, Mike Hepworth wrote: The snapshot gives me the following error on the php make command: Making all in Zend /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I ../main -I../TSRM -g -prefer-non-pic -static -c zend_language_parser.c /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I ../main -I../TSRM -g -prefer-non-pic -static -c zend_language_scanner.c zend_language_scanner.c, line 2697.7: 1506-282 (S) The type of the parameters must be specified in a prototype. make: The error code from the last command is 1. I tried both the latest version, and the second to latest version.. Thanks, Mike Hepworth Stop. make: The error code from the last command is 1. Bug Database [EMAIL PROTECTED] 08/15/01 10:28AM ID: 12767 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Old Bug Type: *Compile Issues Bug Type: Compile Failure Operating System: AIX 4.3.3.0 PHP Version: 4.0.6 New Comment: Could you please try the latest CVS snapshot from http://snaps.php.net/ since this should have been fixed already. --Jani Previous Comments: [2001-08-15 11:12:56] [EMAIL PROTECTED] Whenever I try to compile Apache server 1.3.20 including the libphp4.a module, make crashes with a code 8. It compiles just fine if I don't include the php directive. It is complaining about .alloc symbol. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=12767edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: PHP-4.0.7RC1
At 12:00 17-08-01, Hellekin O. Wolf wrote: At 21:15 16/08/2001 +0300, Zeev Suraski wrote: What is the default error_reporting ? (When no value has been defined ?) The default error reporting is E_ALL ~E_NOTICE - or, in other words, all types of errors and warnings, except for notices. Zeev *** Will that be a difference between 4.0.7 and 4.1 ? I mean, would 4.1 take E_ALL as a default ? It hasn't been decided yet, but my guess is that it won't change. It may be a good idea to add it into the php.ini-recommended, though. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1
At 16:21 17-08-01, Cynic wrote: I vote for E_ALL as default in 4.1. NB I thought it was agreed that the same code will be released as 4.0.7 and 4.1.0 with the difference being php.ini settings. Was it a misperception on my part? Defaults and ini settings (the binary will also reflect the new default php.ini settings). The reasons I'm not sure about whether E_NOTICE should be in or not: - The consequences of turning it on are extremely far reaching - it requires you to go over each and every line of your code, until the very last one, and check it, on the logical level (i.e., try to think about every possible path of execution). - It's almost always harmless, especially after we change the default value of register_globals to off. I'm very non decisive about my opinion on this one. I know that in 1997 when these warnings were added to the language in the first place, they were E_WARNING's. Rasmus and others said that these warnings were too excessive, and introduced the NOTICE (or STRICT as it was called back then) error level, which was off by default, basically telling people it's ok to write code that way. This happened about 4 years ago, at the early days of PHP 3.0. Weighting the gain (it's there, but it's not overwhelming) and weighting the mess (it's there alright :), it very difficult to come up with a firm decision. I consider E_NOTICE as a basic element of good programming practices. Unlike register_globals, which simply begs for security bugs to occur, though, E_NOTICE is more of an application-level, code-cleanliness kind of suggestion. That's why I think that adding it to the php.ini-recommended is a good first step. While we're at it, I think that we should also take another recommendation from the advisory that brought this mess upon us - and turn URL fopens off by default. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1
At 17:05 17-08-01, Cynic wrote: I'd do this: 4.0.7: php.ini-standard basically today's php.ini-dist php.ini-recommendedbasically today's php.ini-optimized + the proposed security related changes what this is exactly I don't know. perhaps only register_globals off This already exists today (except -standard is still called -dist, as there's no real reason to change it). We may try to encourage people to read php.ini-recommended at the and of the build process, because I fear nobody's looking at it today. 4.1.0: php.ini-standard php.ini-recommended as contained in 4.0.7 + anything else you think should be there (it can be more strict than 4.0.7's rec.) php.ini-compat php.ini-standard as contained in 4.0.7 I'm not sure that we can just move to do -recommended version, 4.1.0 or not. The nature of recommendations is that some people accept them, and some do not :) None of the things in the php.ini-recommended file is a clear-cut must-have, and some people will prefer doing without them. We'll have to think about each change separately. Remember that we only use the version change to catch people's attention. It doesn't mean that we can suddenly make PHP much more 'hostile' :) And while I'm at it: can the Powers That Be consider switching the default setting for display_startup_errors to On in either of the ini files? I believe (my experience indicates it) that this would help to lower the confusion in some cases quite a bit: a message instead of just a 500 can change one's day. There's a good reason for this default setting. A clear message will not only change your day, but also the guy who's trying to hack your site's day :) For example, with display_startup_errors set to on, a request can be easily made that will expose the full path of any scripts on your site. It may make good sense to set it on in the -recommended version, as it's safe in conjunction with display_errors=0 and log_errors=1. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1
At 17:43 17-08-01, Hellekin O. Wolf wrote: *** I understood that 4.0.7 / 4.1.0 would be a question of what we want next. 4.1.0 will. We're not changing any defaults in 4.0.7... If E_ALL brings better code, why not encourage that ? Democracy is good as long as it's evolving. If we encourage a default lax behavior, lax coders we'll have. If we encourage tighter programming, even the novice can cope with it and learn faster, and make less mistakes, etc. Is that too optimistic ? Or am I forgetting the existing code base ? I think it's a bit too optimistic, not to mention the existing code base :) I think that as $HTTP_*_VARS disappear, lots of people will have to change that (Search/Replace + delete the corresponding global calls) anyway in order to use the new $_* arrays in future versions. There's a fundamental difference - setting E_NOTICE on means you have to audit *all* of your code, and in some cases, think about every possible execution path, just to see if you have a problem. While the HTTP_*_VARS is an easy SR issue, and even setting register_globals off affects only the form-interface part of the application and is usually also an issue of SR (slower, but still SR), there's no way to fix all notices in a quick way. Even if you find the problems (which is very time consuming), fixing them can't be done using SR, and it sometimes even requires changes to the logic. It's not that While we're at it type of action, it has considerable additional implications. It's probably better to bother people once for good instead of once every version. The purpose of 4.0.* vs .4.1.* should be clear for all : it's a new step and you have to make it. First off, nobody *has* to do anything. They can always use an old version, or if we screw up too badly, switch to something else (I think the register_globals thing alone will take at least a year to catch, especially considering we're not eliminating the ability to turn it on). We're walking on a fine line here, between keeping PHP's ease of use and cleanliness. PHP is *definitely* not the cleanest language around, and it's not meant to be, either. That's why not every action that would result in a 'cleaner' language is automatically applied. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1
At 19:16 17-08-01, Stanislav Malyshev wrote:
ZS I consider E_NOTICE as a basic element of good programming
ZS practices. Unlike register_globals, which simply begs for
ZS security bugs to
Actually, I fail to see why it is so. Let's see two code snippets:
if($arr['foo']) { ... do something ... }
if(isset($arr['foo']) $arr['foo']!=false) { ... do something ... }
Both have the same function, but the first generates E_NOTICE. Why the
first is bad programming practice? How many PHP users would really prefer
the second over the first?
This is one case in which there's no added value to E_NOTICE - in your
example, you explicitly don't care whether the variable exists or
not. There are many cases in which there is an added value in
E_NOTICE. For example:
for ($i=0; $i100; $i++) {
$sum += sth()
}
print The total some is $total;
True, a dumb programming error (it can get more complex), but an E_NOTICE
would have caught in a second. I think that in the post register_globals
era it'll usually not help uncover security bugs, but it improves code
cleanliness.
ZS kind of suggestion. That's why I think that adding it to the
ZS php.ini-recommended is a good first step.
However, it would make average PHP code to output tens of warnig, which
would be annoying and would hardly be useful in many cases.
I agree. I'm saying that it's a difficult call.
ZS While we're at it, I think that we should also take another
ZS recommendation from the advisory that brought this mess upon us
ZS - and turn URL fopens off by default.
Well, generally I personally would even go further and make two functions
- one for file-only fopen (about 90% of fopen usage?) and another which
would open everything and the kitchen://sink. Or make some switch, etc. -
configuration option doesn't seem to me fit here, it's not per-server but
per-script property if you want URL fopens or not.
You can set any INI entries using ini_set() for a particular script. I
think adding new functions is messy - too many functions in PHP support
opening URLs (because they're built on top of fopen-wrappers).
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1
At 19:35 17-08-01, Cynic wrote: This will happily run in E_ALL ~ E_NOTICE whether $x == 'foo' or not. Attacker can then inject $secure in the query string, and it'll apply whether or not $x == 'foo'. This will be caught with error_reporting E_ALL. That's just a specific case of the register_globals problem. We're already phasing register_globals out... In the post register_globals era, the likelihood that E_NOTICE's will be hiding a security bug is much, much lower. However, there are quite a few other situations in which E_NOTICE's are emitted, which are perfectly ok. It has to do with coding style, not security. Yes, average PHP code is full of security or other holes. E_NOTICE's only sometimes imply a security hole or a bug. Very often, they imply absolutely nothing. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1
At 19:54 17-08-01, Stanislav Malyshev wrote: I know. That's shaving with an axe - I can do it, but that's wrong thing to do. User should not be encouraged to fiddle with ini_set unless it is absolutely necessary. I disagree. ini_set() is kinda like inspector Gadget's hat, you can find a shaver there if you want to. We can have a wrapper function, url_fopens_enable() which would in turn call ini_set(), but generally I think it's a bad idea to add these redundant functions. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: PHP-4.0.7RC1
At 03:51 18-08-01, Richard Lynch wrote: Relying on initialization by the system instead of doing it by hand is bad. What if somebody then includes your file into something else, but has used that variable, but their final value is usually 0, except when it's not... Then, your code works for a while and then inexplicably breaks. Always initialize variables. In that example, you would break the outer code if you initialize the variable... The right solution here is separation using scopes (functions or classes). I think that include()'ing logic into the global scope is not a very good idea unless they're integrated parts of the application. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] about domxml api-change in 4.0.7
At 00:54 19-08-01, Markus Fischer wrote: On Sat, Aug 18, 2001 at 11:07:08PM +0200, Jani Taskinen wrote : Changes in experimental extensions don't require NEWS entries. The NEWS file is already too hard to read. With all those changes mentioned in it, it will become totally useless. -1 A news entry won't hurt that much it will probably aid ... wether EXP or not, domxml is stuff used by many people. We shouldn't be that strict just because its marked EXP after all.. I'm with Markus here... It's quite easy to skip non interesting entries. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zend-Engine2
At 19:37 19-08-01, Markus Fischer wrote: print_r( $a-b()-e()[0]); The last line gives parse error. So, I guess no yet supported? There are no plans to support this kind of dereferencing (arrays are still native types). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zend-Engine2
At 19:48 19-08-01, Markus Fischer wrote: On Sun, Aug 19, 2001 at 07:40:06PM +0300, Zeev Suraski wrote : At 19:37 19-08-01, Markus Fischer wrote: print_r( $a-b()-e()[0]); The last line gives parse error. So, I guess no yet supported? There are no plans to support this kind of dereferencing (arrays are still native types). Oh ... sadly. I thought I read something about this in the draft. Then again, could be having to less sleep when reading it :| Is it like 'implementing this would be not trivial for the advantage gained' or is it like 'no one has yet considered about this syntax ? The former more than the latter. It also makes less conceptual sense. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora and CVSWeb problems
At 22:31 19-08-01, Rasmus Lerdorf wrote: Maybe Chora puts out an XML content type header, or something, that makes IE think this is XML (as it is not). I can't see the source, as IE just denies to show the source in such cases saying The XML source file is unavailable for viwing). Please ask, if more information is needed IE is a completely useless web browser. That's why 75% of our users and like 90% of the Web uses it, eh? :) It does not honour mime types and simply uses the file extension and/or any client-side file type associations. Chora is doing the right thing. On that com.xml URL you posted it is sending a text/plain Content-Type header. The fact that IE choosed to pass text/plain to an internal XML parser is just one more reason you should never use IE for web browsing. You never know what the thing is going to do. I would not suggest changing Chora in any way with this respect. 'Hadin Yikov Et Hahar'. I wish I knew how to translate that :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora and CVSWeb problems
At 23:14 19-08-01, Rasmus Lerdorf wrote: That doesn't mean that the lack of proper mime type handling doesn't make it a useless browser. People use all sorts of useless stuff every day. As much as this is appetizing to start a nice browser war, I'll control myself. I think an English teacher could argue with that last sentence of yours, though :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/ircg README.txt
At 23:04 20-08-01, John Donagher wrote: Processing payments on the internet is very special? No wonder so many businesses went under in the last few months. I think as long as PHP is a viable language for ecommerce development and hosting companies these extensions (Cybercash,pfpro,CCVS) make a lot of sense to have as part of the distribution. I'm not sure I've ever seen a clear argument as to why they don't. Yep, I agree. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Netscape cookies rather than RFC2109 or RFC2965?
At 23:16 20-08-01, Rodent of Unusual Size wrote: Is there any particular reason why setcookie() uses the long- deprecated Netscape cookie syntax? Downwards compatibility... Would anyone object to my enhancing it to at least allow another argument specifying the syntax (Netscape Set-Cookie, RFC2109 Set-Cookie, or RFC2965 Set-Cookie2)? I think that's fine, but it'll be coming after a long list of optional arguments :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/ircg README.txt
At 23:29 20-08-01, Sterling Hughes wrote: I see no reason to put them in at the language level -- PEAR seems a suitable place for the extensions (once pear is setup). They're not really used that commonly (from what I can see). Also, these extensions are not the only way to process payments with PHP, plenty of sites do it different ways (I processed payments with PHP before these extensions existed). I think these discussions are kind of idle until the PEAR framework is ready. The fact PHP comes with a rich variety of extensions is, in my opinion, one of the key reasons to its success. It doesn't mean that this system cannot be redesigned in a way in which the extensions would ship separately, but we have to make sure it will not make installing extensions any more complicated or annoying than it is today. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] pif
At 23:14 21-08-01, [EMAIL PROTECTED] wrote: What about using the pif_ prefix for php's internal functions, analogously to zif? This makes them more clear than the simple lack of PHP_API macro. This sentence does not compute :) Which functions are you talking about, and how does PHPAPI relate to them? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] object to string convertion patch
At 19:53 22-08-01, Andrei Zmievski wrote: On Wed, 22 Aug 2001, Jeremy Bettis wrote: I changed php (current CVS) to add another magic method to Objects, __toString(). Whenever an object needs to be converted to a string, then it will first try to call __toString() and if it can't, then it will just return Object like now. Good luck trying to get this in. I implemented this once, and it was even in for several mini versions. But it causes inconsistencies, and it was thus removed (I don't remember what the inconsistencies were, look up the archives...) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] object to string convertion patch
At 20:08 22-08-01, Jeremy Bettis wrote: My implementation does not have these inconsistencies (I looked in the archives). The only wierd thing is print_r and dump_var. I think the inconsistency that was there was that my implementation was for displaying purposes only. If you call to_string() in convert_to_string(), then it may be consistent (I'm not sure, I haven't thought about it thoroughly). There was a reason on why we didn't switch to this as well, though. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] EXT_SKEL for Win32
At 21:42 22-08-01, Chris Gardner wrote: i was noticing a slight problem with the whole EXT_SKEL shell script. it works great for getting a new package up and running, but only if your' doing all your using basically the gcc compiler. well, i've been trying to create an extension library for php, and i am mainly using visual c++ 6 sp 3 on win2k. i can run the EXT_SKEL in my cygwin prompt, and it makes the files, fixes the build scripts, and the configure options, etc. but, it doesn't fix the win32 projects to add the new library. has anyone else looked at this, or thied to look at this? if nobody else has burned this bridge before, let me know, i'll come up with something you guys can use. I think the guys who worked on ext_skel were mostly UNIX oriented. At any rate, no work has been done to automate Windows builds - so if you can contribute in this area, it would be cool! Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] pif
How about phf_, for PHP Helper Function? I see a point in differentiating language level API functions (e.g. like output buffering) and module-specific helper functions (e.g., like php_mysql_do_connect()). Zeev At 22:57 22-08-01, Jeroen van Wolffelaar wrote: I'm against that. Usually underscore-prefixed symbols are used by system libraries and OS and we don't need to go in that direction. I'm also against using pif_, because it's not an internal function that you are naming, but rather, a helper one. I don't really have an opinion on this matter, I just wanted to know what to do. So you are suggesting to simply stick with php_ prefix and not doing anything else? Then I'll comply with that. In math.c, I saw that use of underscore as first letter, so that is not according to how it should be done, I assume. Thanks for clearing this up, Jeroen -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] pif
At 23:09 22-08-01, Andrei Zmievski wrote: On Wed, 22 Aug 2001, Zeev Suraski wrote: How about phf_, for PHP Helper Function? I see a point in differentiating language level API functions (e.g. like output buffering) and module-specific helper functions (e.g., like php_mysql_do_connect()). Explain what the point is, then. I would assume that functions like php_mysql_do_connect() are scoped statically, so it shouldn't be a big deal that they have php_ prefix. It's not about possible symbol clashes... When debugging (or when reading code), it helps to know what's a part of the API and what isn't. It also makes different types of prefix-based searching (e.g., gdb's completion, or emacs' search feature) a bit easier. Is it a big deal? No, but it can be useful and has no real drawbacks. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] pif
At 23:18 22-08-01, Andrei Zmievski wrote: Is it a big deal? No, but it can be useful and has no real drawbacks. Okay. But I'll be forced to pronounce phf as FF, so FF_mysql_connect.. :) Ok, one real drawback then ;) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Branching ext/standard?
At 23:37 22-08-01, [EMAIL PROTECTED] wrote: Hi, I've got an experimental beginning of the new rand functions ready. I think it's good if others can comment on it before it is finished, because the course can be changed now quite easily, but when it's all done, I don't feel much about doing that... Do you need the branch the whole directory? We usually (read: always) don't use branches for development, i.e., we don't use branches that are planned to eventually merge in. That's because CVS's branch handling leaves a lot to be desired... It may be ok in this case, where the chances of somebody else committing something that would clash with your changes are very slim, but I think you're better off branching just the file or couple of files which you're modifying. So, should I branch ext/standard under the name 'EXPERIMENTAL', or 'RAND_CHANGE', or something else? EXPERIMENTAL is way too general to be good for such a purpose... I'd try and use a fairly descriptive name, which is unlikely to be used again in the future. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Branching ext/standard?
At 23:48 22-08-01, Jeroen van Wolffelaar wrote: It involves basic_func*, *math*, *rand* and *array* files (* are wildcards, not exclamation markings) files. And of course Makefile too. And probably some others too. That makes quite a significant portion of that directory. It is way much easier to branch the whole dir... Currently it only compiles as non-ZTS, Linux stand-alone executable, and not much else, definitely not windows, ZTS, and as module. This will remain so for quite a time, I guess. That means that the main branch will be broken for those situations for quite a time, and I don't think that's a good idea. If it's such a far reaching change, I suggest you simply send the diff the php-dev. It should be enough to be a basis for a discussion on the proposed changes. If we decide to go through with it, it should be committed to the main branch, and fixed so that it would work everywhere (or find a working solution to keep the tree in a working state). Branching away for long periods in the hope of merging back in is not a good idea. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Branching ext/standard?
At 00:03 23-08-01, Jeroen van Wolffelaar wrote: Simply committing at once with: rewrite everything that has to do with rand won't be any useful. 80% of the diff is the moving of code, and only 20% the real change. You also don't see what changed. Just as bad as mixing WS fixes with real fixes. I don't think you would get too many comments if you commit to a branch either. What I would do in your case is: (a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or whatever) (b) Commit your move-around changes (c) Commit the real changes (can be done immediately after (b), as long as it's separate) (d) Cross your fingers :) If we like it, the tree will be fixed quite quickly. If we don't, we can revert easily. I usually don't encourage people to commit changes that break the tree, but as we're not anywhere near a new release (that is, 4.0.7 already branched) having the tree broken for a few hours or even a couple of days under the 'less-mainstream' configurations is not a complete disaster... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Branching ext/standard?
At 00:15 23-08-01, Jeroen van Wolffelaar wrote: What I would do in your case is: (a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or whatever) (b) Commit your move-around changes (c) Commit the real changes (can be done immediately after (b), as long as it's separate) The real changes are not ready... and I didn't want to start with it until I know the move-around is okay, since I don't like to work for nothing. I'll commit the move-around changes then, but it will be broken, maybe even normal build, because it is EXPERMENTAL, and I didn't do much testing, it is simply not ready, it's about the idea. Sigh. Ok then. Commit the broken changes to a branched ext/standard, but let's set a dead line to branching it back in, or killing it :) I think that 2 or 3 days should be enough to call the shots... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] concatenating strings
Look at add_string_to_string(). At 04:14 24-08-01, Peter Bowen wrote: I am writing an extension, and trying to figure out how to append to an existing string. I have a pointer to a zval that is a string, and a pointer to another string, along with the other string's length. I have looked for a ZEND_STRCAT macro, or something similar, but don't see anything. What is the proper/best way to handle this? Thanks. Peter -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] concatenating strings
At 00:06 25-08-01, Peter Bowen wrote: I am getting a SIGSEGV with this function. I am probably just missing something. I was hoping for a function with the prototype strcatl(zval **z, char *s, int l); strcat(zval **z, char *s); Lacking those, I tried zval **data; /* call to zend_hash_find to set data */ zval *tmp; MAKE_STD_ZVAL(tmp); ZVAL_STRINGL(tmp, s, l, 1); add_string_to_string(*data, *data, tmp); What am I missing? Nothing I can see off hand. Where is it crashing? BTW, apparently add_string_to_string() will crash if the first string is empty (in the places it's being used in right now, the first string cannot be empty so this case is not checked). Any chance your first string is empty? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended
At 16:48 25-08-01, Jani Taskinen wrote: Better question is, do we really want to do this? This doesn't fix anything. It only breaks things. Second, this will make writing portable scripts harder. Yet another ini setting to be checked for.. The only good way of doing this rand() - mt_rand() change would have been my way (tm) which was rejected. ie. using the mt_* always. I think that what Jeroen's doing is a good idea. We're dealing with this issue in a too techie manner, and forget that most people just want a random number when they call rand(). I don't think it's too much to ask :) If rand() gives them pseudo random numbers, or predictable random numbers, then it's (usually) not what they're looking for. I guess it's not impossible that someone would actually rely on the fact that given the same seed, you get the same predictable series of random numbers, but it's fairly poor coding, and I don't think it's being used too often (far less often than plain random numbers are, anyway). If somebody wants to get a predictable series, let him ask for it explicitly. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Anybody tested the Apache module recently?
I think that was some breakage I was responsible for (I committed a fix
about 30 minutes later, only apparently I never actually finished editing
the commit message, so it never left my machine).
It should be fixed now. Please let me know if it isn't.
Zeev
At 02:43 26-08-01, Rasmus Lerdorf wrote:
It seems to have completely broken as of a CVS update of a few minutes
ago. Most of the time I get no output, but sometimes I get a very very
long row of ZZ's or sometimes I get
ZZZ?Ì?*Z?Ì?*Z
Repeatedly loading a phpinfo() tends to toggle back and forth. Single
stepping through things looks normal. zif_phpinfo() is getting called and
everything looks fine. So it is something lower level. Output bufferring
changes messing things up?
relevant php.ini settings:
output_buffering= Off
output_handler =
implicit_flush = Off
zlib.output_compression = Off
Same thing happens on a simple echo Hello World script.
An strace on that shows:
{sin_family=AF_INET, sin_port=htons(42216),
sin_addr=inet_addr(127.0.0.1)}}, [16]) = 3
rt_sigaction(SIGUSR1, {SIG_IGN}, {0x8074490, [], SA_INTERRUPT|0x400},
8) = 0
getsockname(3, {sin_family=AF_INET, sin_port=htons(80),
sin_addr=inet_addr(127.0.0.1)}}, [16]) = 0
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
alarm(300) = 0
read(3, GET /t.php HTTP/1.0\r\nConnection:..., 4096) = 334
rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
time(NULL) = 998782781
alarm(300) = 300
alarm(0)= 300
stat64(/home/rasmus/phpweb/t.php, {st_mode=S_IFREG|0664, st_size=30,
...}) = 0
alarm(300) = 0
umask(077) = 022
umask(022) = 077
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0
rt_sigaction(SIGPROF, {0x402102b0, [PROF], SA_RESTART|0x400},
{0x402102b0, [PROF], SA_RESTART|0x400}, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
getcwd(/usr/local/home/rasmus/phpweb, 4095) = 30
chdir(/home/rasmus/phpweb)= 0
open(/home/rasmus/phpweb/t.php, O_RDONLY) = 4
getcwd(/usr/local/home/rasmus/phpweb, 4095) = 30
lstat64(/home, {st_mode=S_IFLNK|0777, st_size=15, ...}) = 0
readlink(/home, /usr/local/home, 4095) = 15
lstat64(/usr, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64(/usr/local, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat64(/usr/local/home, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
lstat64(/usr/local/home/rasmus, {st_mode=S_IFDIR|0777, st_size=12288,
...}) = 0
lstat64(/usr/local/home/rasmus/phpweb, {st_mode=S_IFDIR|0755,
st_size=4096, ...}) = 0
lstat64(/usr/local/home/rasmus/phpweb/t.php, {st_mode=S_IFREG|0664,
st_size=30, ...}) = 0
ioctl(4, TCGETS, 0xbfffe110)= -1 ENOTTY (Inappropriate ioctl
for device)
fstat64(4, {st_mode=S_IFREG|0664, st_size=30, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x40018000
read(4, ?php\n\techo \Hello World\;\n?\n, 8192) = 30
read(4, , 4096) = 0
read(4, , 8192) = 0
ioctl(4, TCGETS, 0xbfffd0d0)= -1 ENOTTY (Inappropriate ioctl
for device)
close(4)= 0
munmap(0x40018000, 4096)= 0
chdir(/usr/local/home/rasmus/phpweb) = 0
alarm(300) = 300
alarm(0)= 300
writev(3, [{HTTP/1.1 200 OK\r\nDate: Sat, 25 A..., 173},
{ZZZ\204\314\217*\0\0\0\0\0..., 4096}], 2) = 4269
rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0
setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
umask(022) = 022
alarm(0)= 0
time(NULL) = 998782781
write(17, 127.0.0.1 - - [25/Aug/2001:16:39..., 74) = 74
alarm(30) = 0
shutdown(3, 1 /* send */) = 0
select(4, [3], NULL, NULL, {2, 0}) = 1 (in [3], left {2, 0})
read(3, , 512)= 0
close(3)= 0
alarm(0)= 30
rt_sigaction(SIGUSR1, {0x8074490, [], SA_INTERRUPT|0x400}, {SIG_IGN},
8) = 0
alarm(0)
Rolling back to my libphp4.so build on Aug.13 built with exactly the same
./configure flags makes it work again.
Those flags are
#! /bin/sh
#
# Created by configure
'./configure' \
'--with-mysql=/usr' \
'--with-gd=/home/rasmus/gd-2.0.1' \
'--with-freetype-dir=/usr' \
'--enable-gd-native-ttf' \
'--enable-gd-imgstrttf' \
'--with-jpeg-dir=/usr' \
'--with-png-dir=/usr' \
'--with-xpm-dir=/usr/X11R6' \
'--enable-exif' \
'--with-pdflib=/usr/local' \
'--enable-inline-optimization' \
'--with-xml' \
'--with-calendar' \
'--enable-wddx' \
'--enable-sockets' \
'--with-db3' \
'--with-snmp' \
'--with-openssl' \
'--enable-debug' \
'--with-config-file-path=/etc
Re: [PHP-DEV] Anybody tested the Apache module recently?
My fault :I I'm working on it. At 02:54 26-08-01, Rasmus Lerdorf wrote: It should be fixed now. Please let me know if it isn't. Well, as of right now, it is still broken. Or am I waiting for a commit? -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Crash in var_dump and print_r
It looks like domxml is responsible here. The hash table that's sent to it contains a NULL value, which should be a valid zval *... Zeev At 13:04 26-08-01, Joey Smith wrote: This may be due to the way domxml is doing things, but the test script in bug #10936 still creates a crash, and the backtrace points to zend_print_zval_r_ex...see attachment 1. Attachment 2 show that var_dump() gives more or less the same result. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
