Re: [PHP-DEV] Separating Bug report emails to own list.. Re: Re[3]: [PHP-DEV] Suggestion:
-1 :) For the reasons mentioned every six months when this matter is raised. At 02:49 PM 2/8/2002 +0200, Zeev Suraski wrote: +1 At 04:06 AM 2/8/2002, Jani Taskinen wrote: Just wanted to let you know that I'm doing exactly that. Filtering that annoying noise to other folder. :) Which I unfortunately don't have time to read atm. And I actually have turned my coat on this issue and I'm in favor for separating the bug emails to own list. Two good reasons: - People who don't want to read them filter them out anyway - It makes php-dev easier to follow - The php-dev@ archive (e.g. in web) becomes easier to browse and search for discussions The php-bugs@ list should be a read-only list where anyone with cvs account should be subscribed (by default). It being read-only forces any replies to be send to php-dev@ where more intense discussion over the issues in the reports should take place anyway. --Jani On Thu, 7 Feb 2002, l0t3k wrote: Daniel, we've had that conversation before, and the consensus then (which makes sense), is that part of the price of being a developer is ensuring that bugs are resolved in a timely manner. to split the list would make it less likely that a bug gets reviewed (after all its more sexy to create features than to debug them). how that works in actual practice, i dont know. i review bug reports periodically, but i suppose others can just as well filter them out... Daniel Lorch [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi, Maybe a solution would be to split PHP-Dev into PHP-Bugs and keep PHP-Dev for *real* topics such as case sensitivity/PHP5 and other questions which are about PHP language design. This would keep the noise out of here. Comments? -- Daniel Lorch -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Separating Bug report emails to own list.. Re: Re[3]: [PHP-DEV] Suggestion:
At 03:04 PM 2/8/2002 +0200, Jani Taskinen wrote: Do you filter these? :) I didn't do that before, but now that I am doing it, it makes following php-dev@ a LOT easier. I do :) But I still think that people subscribed to php-dev@ need to not only enjoy upsides but also the downsides of receiving the bug reports in hope that more people will look at them. By the way, if you're filtering them then what do you care? It's no biggy to deal with another n mails if they are filtered. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Case sensitivity: Conclusion(?)
At 01:42 PM 2/8/2002 +0100, Stig S. Bakken wrote: On Fri, 2002-02-08 at 13:38, Yasuo Ohgaki wrote: Andi Gutmans wrote: At 09:20 PM 2/8/2002 +0900, Yasuo Ohgaki wrote: Andi Gutmans wrote: Name space BC problem is bad, since script may misbehave without proper error message where to fix. It's a bad BC problem since it's harder to fix/notice. In some cases, it seems works well while it's not. The question is how often does this breakage actually happen in real life and not theoretically on the mailing list. Then we have different priority for BC problems :( BC _with_ error is not as bad as BC _without_ error for me. Theoretically I agree but if BC _without_ error happens very rarely then I don't think it's that bad. In any case, we could always have an E_MIGRATION for people migrating. Great! I personally prefer to have E_DEBUG, E_INFO and clean up error level for functions. There about 2300 php_error/zend_error :) I'll happily contribute for it. E_INFO: Error like compatibility info (migration) E_DEBUG: Error useful for debugging script but not appropriate for production scripts. E_NOTICE Error that can be a bug in script but may be ingored. E_WARNING Error taht cannot be ignored. (Error must be handled) E_ERROR Fatal error. Good idea. E_DEBUG may be a good alternative to php_printf(). Heh. Fine tuning errors is probably a good idea. E_PEDANTIC? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Separating Bug report emails to own list.. Re: Re[3]: [PHP-DEV] Suggestion:
At 03:15 PM 2/8/2002 +0200, Zeev Suraski wrote: At 03:13 PM 2/8/2002, Andi Gutmans wrote: At 03:04 PM 2/8/2002 +0200, Jani Taskinen wrote: Do you filter these? :) I didn't do that before, but now that I am doing it, it makes following php-dev@ a LOT easier. I do :) But I still think that people subscribed to php-dev@ need to not only enjoy upsides but also the downsides of receiving the bug reports in hope that more people will look at them. I think that the only time this actually has any meaning is with people whose email software isn't bright enough to filter it. Otherwise, I'm pretty sure everyone filters it anyway. php-dev is full of people who aren't actually developing, but are just interested in watching the development trends. Forcing them to see the bugs isn't going to do anything in any level - either they'll ignore it, or filter it out, because they can't do anything about it anyway. We both know that just receiving the bug reports doesn't have any meaning if you're not willing to actually spend time working on them. I don't think it's that important (that's my last post on this thread :), but it does look kind of odd that instead of just separating the lists, we tell people 'filter them!' I believe that in the scenario where php-dev@ is sent bug reports as opposed to people having to subscribe separately to php-bugs@ the amount of people reading bug reports in the first case will be bigger than in the second. This is because I believe there is a % of people who would read bug reports if they received them but wouldn't actively subscribe to the bug reports list. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Case sensitivity: Conclusion(?)
At 02:20 PM 2/8/2002 +0100, Stig S. Bakken wrote: On Fri, 2002-02-08 at 14:14, Andi Gutmans wrote: At 01:42 PM 2/8/2002 +0100, Stig S. Bakken wrote: On Fri, 2002-02-08 at 13:38, Yasuo Ohgaki wrote: Andi Gutmans wrote: At 09:20 PM 2/8/2002 +0900, Yasuo Ohgaki wrote: Andi Gutmans wrote: Name space BC problem is bad, since script may misbehave without proper error message where to fix. It's a bad BC problem since it's harder to fix/notice. In some cases, it seems works well while it's not. The question is how often does this breakage actually happen in real life and not theoretically on the mailing list. Then we have different priority for BC problems :( BC _with_ error is not as bad as BC _without_ error for me. Theoretically I agree but if BC _without_ error happens very rarely then I don't think it's that bad. In any case, we could always have an E_MIGRATION for people migrating. Great! I personally prefer to have E_DEBUG, E_INFO and clean up error level for functions. There about 2300 php_error/zend_error :) I'll happily contribute for it. E_INFO: Error like compatibility info (migration) E_DEBUG: Error useful for debugging script but not appropriate for production scripts. E_NOTICE Error that can be a bug in script but may be ingored. E_WARNING Error taht cannot be ignored. (Error must be handled) E_ERROR Fatal error. Good idea. E_DEBUG may be a good alternative to php_printf(). Heh. Fine tuning errors is probably a good idea. E_PEDANTIC? A lot of errors that are E_NOTICE today would definitely be better off as E_PEDANTIC. Undefined array indexes come to mind. What else? E_INFO may be a bit vague (and probably attract a lot of misc errors). What about E_COMPAT for compatibility issues? E_PENDATIC, E_COMPAT, E_NOTICE, E_WARNING, E_ERROR Do you see E_PENDANTIC and E_NOTICE as much different? Can we differentiate between them? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Case sensitivity: Conclusion(?)
At 02:39 PM 2/8/2002 +0100, Stig S. Bakken wrote: On Fri, 2002-02-08 at 14:30, Andi Gutmans wrote: At 02:20 PM 2/8/2002 +0100, Stig S. Bakken wrote: On Fri, 2002-02-08 at 14:14, Andi Gutmans wrote: At 01:42 PM 2/8/2002 +0100, Stig S. Bakken wrote: On Fri, 2002-02-08 at 13:38, Yasuo Ohgaki wrote: Andi Gutmans wrote: At 09:20 PM 2/8/2002 +0900, Yasuo Ohgaki wrote: Andi Gutmans wrote: Name space BC problem is bad, since script may misbehave without proper error message where to fix. It's a bad BC problem since it's harder to fix/notice. In some cases, it seems works well while it's not. The question is how often does this breakage actually happen in real life and not theoretically on the mailing list. Then we have different priority for BC problems :( BC _with_ error is not as bad as BC _without_ error for me. Theoretically I agree but if BC _without_ error happens very rarely then I don't think it's that bad. In any case, we could always have an E_MIGRATION for people migrating. Great! I personally prefer to have E_DEBUG, E_INFO and clean up error level for functions. There about 2300 php_error/zend_error :) I'll happily contribute for it. E_INFO: Error like compatibility info (migration) E_DEBUG: Error useful for debugging script but not appropriate for production scripts. E_NOTICE Error that can be a bug in script but may be ingored. E_WARNING Error taht cannot be ignored. (Error must be handled) E_ERROR Fatal error. Good idea. E_DEBUG may be a good alternative to php_printf(). Heh. Fine tuning errors is probably a good idea. E_PEDANTIC? A lot of errors that are E_NOTICE today would definitely be better off as E_PEDANTIC. Undefined array indexes come to mind. What else? E_INFO may be a bit vague (and probably attract a lot of misc errors). What about E_COMPAT for compatibility issues? E_PENDATIC, E_COMPAT, E_NOTICE, E_WARNING, E_ERROR Do you see E_PENDANTIC and E_NOTICE as much different? Can we differentiate between them? Well, E_PENDANTIC is more specific, its use should be limited to really strict warnings, just like in C compilers. Just move those errors from E_NOTICE to E_PEDANTIC and leave the remaining E_NOTICEs as they are. Or are you saying you see less point in having E_NOTICE with E_PEDANTIC? Yeah that's what I meant but I think you're right. We can use E_PENDATIC for *really* pedantic messages. It'd be actually interesting to find all sorts of places which could do with this. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Separating Bug report emails to own list.. Re: Re[3]: [PHP-DEV] Suggestion:
At 02:16 PM 2/8/2002 +, James Cox wrote: Someone suggested having php-bugs set up, and anyone with the relevant karma would automatically be on it. if it was closed subscribtion/unsubscription, then when someone gives karma, they also subscribe the person to that list. Perhaps that's a solution, to seperate it. Yes, filters are good, we all use them... but it's the other places which that doesn't help, like the online archives. This is a good suggestion. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
At 07:58 AM 2/7/2002 +0100, Stig S. Bakken wrote: After careful consideration on the CS issue I must say I agree with John here. The _only_ case where I feel CS is a problem, is when dealing with other environments. But the price for changing this today is simply too high. It should have been done in PHP 3.0. We have other BC issues to soak our brains in. HOWEVER, I would like to suggest one compromise: storing class names (and maybe function names) exactly as they were spelled in the definition, and have get_class() etc. return that version instead of the lowercased one. This would at least make us able to expose interfaces with the intended case. -1 from me on case sensitivity in ZE2, +1 on storing pretty names I agree and I'll try and check if pretty names can be handled. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Refcount in var_dump()
At 06:52 AM 2/7/2002 +0100, Markus Fischer wrote: On Thu, Feb 07, 2002 at 07:21:07AM +0200, Andi Gutmans wrote : At 11:03 PM 2/6/2002 -0600, Jason Greene wrote: Would anyone object if I added refcount information to var_dump? me. I think it would really confuse people. I suggest adding another function. It should probably be only enabled in debug builds because the end user shouldn't be worrying about refcounts. It's an internal thing. Certain function only available in a debug build!? Please don't ... OK but please don't change var_dump. Add debug_dump_zval(). Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclusion(?)]
I very much agree with this Email and am -1. Andi At 11:01 PM 2/6/2002 +0800, John Lim wrote: Thanks for posting this request for comments, Yasuo. I think from a C developer's point of view, it makes perfect sense to have case-sensitivity. From a scripting point-of-view, I think it is a step backward. Studies by the Python group have shown that case-sensitivity is a serious barrier for beginners. I also think that a significant number of PHP users who do *not* program in C, C++ or languages which require case-sensitivity would be most unhappy. These people would definitely not visit php.dev or Zend2 lists, so I think opinions here are skewed (not twisted!) Backward compatibility is a headache also as many PHP libraries written by other people have weird case conventions, and not having a standard PHP coding style will mean our code will be a mess as we have to adhere to different coding styles. We have been trained in Javascript and C to spell the standard libraries in a standard way. But what is the correct spelling of OCIPLogon (or was that ociplogon, or was that ociPLogon)? Who knows and I think moany people would not want to care. I certainly don't. In the C library, I'm used to having all lowercase functions, but it will look wierd if PEAR DB follows one convention, PHP extensions follow another, and my code follows a different one. Without case-sensitivity, I can use a consistent code style for functions everywhere for OciPLogon (hah, another spelling variation!) I think PHP5 is a bit late in the game to change course so radically for so little benefit. This will stir up a hornets nest which would be better directed at fixing bugs, writing code, and finding happiness and peace. My PHP 5 cents worth. John Lim Perhaps someone could cc this to the Zend2 lists as I don't read it. Thanks. Thies C. Arntzen [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On Wed, Feb 06, 2002 at 07:40:18PM +0900, Yasuo Ohgaki wrote: Hi all, I'm posting this for those who are not subscribing Zend Engine 2 list. Many of developers seems to have case sensitivity for class/function names. However, we need vote for if PHP5 will have case sensitive class/function/constant names. If you have comments, please submit one. PS: We know we can cheat. Let's hope nobody cheat :) You can read Zend Engne 2 list archive at http://www.zend.com/lists.php besides the BC mess i'm all for it (make PHP5 case-sensite). tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: Re: [Zend Engine 2] Case sensitivity: Conclus ion(?)]
At 06:04 PM 2/6/2002 -0600, Jason Greene wrote: On Wed, 2002-02-06 at 10:13, Zeev Suraski wrote: While I agree with Marko's vote (I'm also very much against it), I derive my conclusion from a whole different perspective. Guys, we are not next to the drawing board right now. The specs were defined and the layout was laid years ago. At this point in time we're only supposed to change something like that if there's an overwhelming reason to do it, and none of the reasons mentioned falls into that category. The reasons to move to case sensitivity and the alternative ways we should handle them, in my opinion, are: - Speed. We can probably improve the typical case so that it's not any slower in runtime. - Interaction with external component systems - we can have case sensitivity implemented at the module level, especially with the Engine 2 infrastructure, and still remain case insensitive for regular PHP objects. - It's just right. Well, I can totally agree with that, but only if we were next to the drawing board, which we're not. You left off language consistency between variable names, and function names. We are already completely redesigning OO which is like standing at the drawing board. Engine 2 will not break scripts that badly (at least not in my opinion). The OO stuff is mainly adding new functionality. Changing function names will break scripts badly. There's a huge difference. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Refcount in var_dump()
At 11:03 PM 2/6/2002 -0600, Jason Greene wrote: Would anyone object if I added refcount information to var_dump? me. I think it would really confuse people. I suggest adding another function. It should probably be only enabled in debug builds because the end user shouldn't be worrying about refcounts. It's an internal thing. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tabs Vs Spaces (and other coding styles)
At 05:19 PM 2/5/2002 +, James Cox wrote: Guys, have we ever decided on this? in our code do we go for tabs or spaces? Is there a style guide anywhere on this? [4] When indenting, use the tab character. A tab is expected to represent four spaces. It is important to maintain consistency in indenture so that definitions, comments, and control structures line up correctly. From php4/CODING_STANDARDS I'm not sure how complete the standard is though. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.0 / PHP 5.0.0-alpha
At 12:39 PM 2/4/2002 +0100, Sebastian Bergmann wrote: 'lo there, what are the plans for the PHP 4.2.0 release? Shouldn't we branch PHP_4_2_0 from HEAD somewhen soon? NEWS already contains about 150 lines of changes since PHP 4.1.1. I think this is probably a good idea. What about Sascha's build patch? While we're at it: Andi mentioned some time ago that he'd like to release an alpha version of the Zend Engine 2 bundled with PHP as a tar-ball. Why not use the PHP_4_2_0 branch for that, once it's stable and QA'd, and release PHP 4.2.0 and a PHP 5.0.0-alpha based on the same /php4 branch, but with separate versions of the Zend Engine? My main interest in an alpha is to get more people to play around with the Zend Engine 2 because it needs lots of testing and feedback. However, I really want to get the object overloading stuff into the Zend Engine 2 before this happens (hopefully this week). It pretty much abstracts all object manipulation making it possible to write some cool object overloading extensions. Also, I think it'd be nice to have Andrei's 'is' patch in too. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.2.0 / PHP 5.0.0-alpha
At 08:56 PM 2/4/2002 +, James Cox wrote: Andi, with regard to the release of a v.5 [pre-]alpha, what are your thoughts on a developer vs public announcement? I think we need to think of a forum (possibly dev/qa/advanced mailing lists) which is big enough in order to give it a thorough test run and find lots of bugs. I wouldn't want this to be a complete public front page php.net announcement. There are also lots of stuff other developers have on their agenda for PHP 5 and I think once the most important features of the Engine 2 are ironed out we can afford to split off the PHP tree and do whatever damage needs to be done there. Also I hope that the improved object overloading will open up new ideas and possibilities for php-dev developers. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.0 / PHP 5.0.0-alpha
At 04:00 PM 2/4/2002 -0500, Dan Kalowsky wrote: On Mon, 4 Feb 2002, Andi Gutmans wrote: I think this is probably a good idea. What about Sascha's build patch? Sounds like an even better idea to me. A new build system for a new engine. And hopefully a whole lot of bug fixes :) I meant a new build system for an old engine :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.2.0 / PHP 5.0.0-alpha
At 09:04 PM 2/4/2002 +, James Cox wrote: I think we need to think of a forum (possibly dev/qa/advanced mailing lists) which is big enough in order to give it a thorough test run and find lots of bugs. I wouldn't want this to be a complete public front page php.net announcement. There are also lots of stuff other developers have on their agenda for PHP 5 and I think once the most important features of the Engine 2 are ironed out we can afford to split off the PHP tree and do whatever damage needs to be done there. Also I hope that the improved object overloading will open up new ideas and possibilities for php-dev developers. I agree -- i think php-qa and php-dev are sufficient for this particularly at this alpha stage. I'd probably involve a couple of more advanced German mailing lists. I think there is quite a strong and advanced movement there but I don't mind either way. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Safe Mode Filesystem Circumvention Problem (fwd)
We have always said that safe mode isn't very safe. I'm sure there are other ways of circumventing it. Unless a few people focus specifically on safe mode I don't think this will change. Andi At 12:26 AM 2/5/2002 -0500, James E. Flemer wrote: BTW I just noticed that this has been entered as bug #15375. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_subclass_of() patch
Sounds OK to me although it might be confusing with the name of this
function.
Andi
On Tue, 29 Jan 2002, Andrei Zmievski wrote:
Right now is_subclass_of() will return false if the object is exactly of
the class you are trying to test for. I propose the following patch:
--- zend_builtin_functions.c2002/01/06 15:21:09 1.107
+++ zend_builtin_functions.c2002/01/29 21:02:05
@@ -553,5 +553,5 @@
zend_str_tolower(lcname, (*class_name)-value.str.len);
- for (parent_ce = Z_OBJCE_PP(obj)-parent; parent_ce != NULL; parent_ce =
parent_ce-parent) {
+ for (parent_ce = Z_OBJCE_PP(obj); parent_ce != NULL; parent_ce =
parent_ce-parent) {
if (!strcmp(parent_ce-name, lcname)) {
efree(lcname);
This should make it easy to use is_subclass_of() as a generic is-a
function.
I can go ahead and apply it if there are not objections. Please copy me
on the replies.
-Andrei
When a man sits with a pretty girl for an hour, it seems like a minute.
But let him sit on a hot stove for a minute, and it's longer than any hour.
That's relativity.
-- Einstein, on relativity
--
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] PECL/PHPDoc
None of the PEAR guys ever answered my Email about PECL. Is there something which actually works? Andi On Wed, 30 Jan 2002, Sebastian Bergmann wrote: 'lo, could someone please fix, if possible, the PHPDoc extension from PECL so that it compiles in ZTS mode? Thanks, Sebastian -- 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 #15186 Updated: define/mysql_connect problem
Yasuo,
I don't quite understand. define() hasn't been changed in the Zend Engine
1. Can you please send me a reproducing script without pg_*() which
works on 4.0.6 and crashes on 4.2.0-dev?
Thanks,
Andi
On Fri, 25 Jan 2002, Yasuo Ohgaki wrote:
Hi Andi,
I think you are interested in this bug report :)
Accoding to this bug report, define() works like a macro somewhat
until 4.1.x.
[EMAIL PROTECTED] wrote
?php
define (DBCONN01,pg_connect(dbname=db01 user=username));
pg_exec(DBCONN01,select * from fugafuga);
?
it worked with 4.0.6. (I verified with 4.0.6 and it works!
It segfaults with 4.2.0-dev/ZE2 and 4.2.0-dev/ZE1)
I thought define() defines scaler constant in ZE1. (and array
in ZE2)
Is this intended behavior?
--
Yasuo Ohgaki
[EMAIL PROTECTED] wrote:
ID: 15186
Comment by: [EMAIL PROTECTED]
Old Reported By: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: MySQL related
Operating System: Linux
PHP Version: 4.1.1
New Comment:
The same probrem occur with PostgreSQL.
This script will hang.
?php
define (DBCONN01,pg_connect(dbname=db01 user=username));
define (DBCONN02,pg_connect(dbname=db02 user=username));
pg_exec(DBCONN01,select * from hogehoge);
pg_exec(DBCONN02,select * from fugafuga);
?
RedhatLinux6.2(en) + php4.1.1 + PostgreSQL7.1.3
Previous Comments:
[2002-01-23 15:20:50] [EMAIL PROTECTED]
Previous to version 4.1.1, using define() to define a handle to a MySQL
connection worked fine:
define(DB, mysql_connect(host,user,pass));
In PHP 4.1.1, if the above is done, then the script will hang for a
long time (for a minute or so) if other mysql connections are attempted
to be made.
i.e.:
function hang_mysql()
{
define(DB1, mysql_connect(host,user,pass));
define(DB2, mysql_connect(host,user,pass));
}
function doesnt_hang()
{
$db1 = mysql_connect(host,user,pass);
$db2 = mysql_connect(host,user,pass);
}
This wasn't a problem in PHP 4.0.6 and older versions.
Edit this bug report at http://bugs.php.net/?id=15186edit=1
--
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: RFE: $HTTP_POST_VARS = $_POST;
PHP 5 per-class constants can already except static arrays such as array(1, 2, 3) as their value. I'll put the issue of global constants on my TODO and believe PHP 5 will also support these for global constants. However, you won't be able to create a constant with a non-constant value such as $_GET as this goes against the whole idea of constant :) Andi On Thu, 24 Jan 2002, Robert Ames wrote: Thanks for your responses (again), it is an unfortunate situation that $HTTP_*_VARS must be retained for backwards compatibility until at least the hypothetical PHPv5.0 mark. Having also read in this group that define() does not support complicated constants, I'm guessing that it's not currently possible to force all predefined variables to be read only (although that seems like the best solution in the long run). Regarding the documenation- it is not clear, and is not emphasized that the arrays are disjoint. Note: Some of these arrays had old names, e.g. $HTTP_GET_VARS. These names still work, but we encourage users to switch to the new shorter, and auto-global versions. $HTTP_GET_VARS An associative array of variables passed to the current script via the HTTP GET method. $_GET An associative array of variables passed to the current script via the HTTP GET method. Automatically global in any scope. Introduced in PHP 4.1.0. ...this will be the last message I'll bother the lists with about this behaviour. I just wanted to make sure that you guys who are developing this stuff receive feedback about how this new behaviour is working out for people using the new versions of PHP. :^) I'm 100% in favor of treating these arrays as read-only, but it would be very nice if E_NOTICE's were thrown when builtin arrays are modified, or simply to treat them as unchangeable constants. Something to keep in mind if we ever get the ability to say: define( '_GET', $_GET ); ...which is interesting in itself... imagine: echo _GET['blah']; ...instead of: echo $_GET['blah']; ...since _GET/etc... are already auto-globals, and you don't want them to be used as left-hand-side values, it seems like they're very close to acting like constants already. Just a thought. ;^) Thanks a bunch! --Robert On Thu, 24 Jan 2002 16:01:24 -0600, Lars Torben Wilson wrote: On Thu, 2002-01-24 at 13:42, Rasmus Lerdorf wrote: I think the real answer here is to treat these as read-only arrays. ie. never use them on the left side of the '=' and you will never run into problems. Or if you do, be consistent and use the same array all the time. You are writing your code with the assumption that these two arrays are the same. Where does this assumption come from? Hopefully not the documentation. -Rasmus No, they are properly--if lightly--documented on the following pages: http://www.php.net/manual/en/language.variables.predefined.php http://www.php.net/release_4_1_0.php Robert, the $HTTP_*_VARS have, indeed, been deprecated, and this is noted in the manual. -- 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] FeatureRequest for PHP5
You can already use constant arrays such as array(1, 2, 3) as constants. Andi On Wed, 23 Jan 2002, Christian Dickmann wrote: Hi all, It would be great if it was possible to have CONSTANTS of types like as Arrays or Objects. This way one could have a Config-Constant and you wouldn't need to use $GLOBALS. Christian Dickmann -- 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] free_zval not working?
On Tue, 22 Jan 2002, Thies C. Arntzen wrote: On Tue, Jan 22, 2002 at 09:27:53AM +0100, Robin Ericsson wrote: I'm using this on php 4.0.6, it know it's old, but things will break if I upgrade :) This is the code: zval *z_return; MAKE_STD_ZVAL(z_return); php_char_to_str(retval, strlen(retval), '\n', br\n, 5, z_return); FREE_ZVAL(z_return); This code gives me: string.c(2122) : Freeing 0x08257CEC (134 bytes), script=nn.php which is the new string allocated inside php_char_to_str(), howcome this memory isn't freed with FREE_ZVAL? FREE_ZVAL only frees the zval and does not destroy (read =free) the attached data-structures. use zval_dtor for that. You should use zval_ptr_dtor() and not zval_dtor(). Andi -- 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] Re: [PHP-DEV] Re: Computer Science and PHP
On Sat, 19 Jan 2002, Alan Knowles wrote: This kind of bytes at a nerve when you are hunting for work and almost nobody mentions PHP here Anyway, A quick few ideas to throw in the pot.. - Press releases, for PHP5 pre-alpha, PHP-GTK's, (Derick - srm?) upcomming release etc. which could be made available - Then a PHP press team??, could be resposnible for getting it out to the Press in their local countries.. I'm would hope that there a few people out there who could help out on this.. Call for Volunteers... - Either writing 'IT Press Friendly' release announcements, or gathering IT Press contacts, and faxing + emailing + phone followup on releases... When Zend first started out we actually offered the other guys in the PHP Group to send out press releases on new versions from the group. We had a PR woman write the press-release and then sent it to the Group for fixing. If I remember correctly they felt that open source projects don't need press releases so it kind of came to a halt. I don't really share that feeling and think that even an open source project can get added exposure by press releases. I think if we can get enough press contacts (it probably shouldn't be too hard if a few people here know the right people) then it would definitely be a good thing. Press releases help because when IT people start seeing press releases all over it sinks in slowly. It shouldn't be too hard to have a couple of people taking care of this and having them send the press releases to php-dev for comments before they go out. Andi -- 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] BEGIN_EXTERN_C()
No good reason. If you need to add it in someplaces go ahead and send in a patch. Andi On 18 Jan 2002, Robin Ericsson wrote: Is there any reason that only parts of Zend is using BEGIN_EXTERN_C()? regards Robin -- 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] Preview of PHP 5
Hey, I'd like to get more people to play around with the Zend Engine 2. I think the only way of getting this done is by posting a package on www.php.net. I'm not sure if we should call it alpha or preview (it's both) but I don't think the name matters too much as long as we get people to try it. It'll also give us a reality check about how many people's scripts break by the new object model. It'd definitely help in pushing things forward. I know lots of people are waiting for the scripting engine improvements and I wouldn't want things to linger too much. I think if we can get enough people to play around with it we could have a final version of the Zend Engine 2 in Q2 2002. Andi -- 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] Preview of PHP 5
On Fri, 18 Jan 2002, Robinson, Mike wrote: Andi Gutmans wrote: I'd like to get more people to play around with the Zend Engine 2. I think the only way of getting this done is by posting a package on www.php.net. I think this is a good idea. I think 'alpha' would be better than 'preview'. I always thought the latter was for stuff that was post beta. I could be wrong though. :) I agree. I think alpha is better. Andi -- 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] Preview of PHP 5
On Fri, 18 Jan 2002, Jan Lehnardt wrote: Hi, On Fri, 18 Jan 2002 18:18:26 +0200 (IST) Andi Gutmans [EMAIL PROTECTED] wrote: I agree. I think alpha is better. what about pre-alpha to make things re-al-ly clear? Well the definition of alpha is before all features are in so I think it should be OK but I don't really care as long as the changes get a bigger audience. Andi -- 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 variable handling
You should use MAKE_STD_ZVAL(). In the past this macro allocated zval's in a faster way via a cache. It has been disabled right now but it very probably will be redone a bit and then re-enabled. Andi On Mon, 14 Jan 2002, brad lafountain wrote: Can someone explain the difference from MAKE_STD_ZVAL(val); and val = emalloc(sizeof(zval)); INIT_ZVAL(val); I'm sure that it has to do with deleting memory. Does MAKE_STD_ZVAL automatically delete your memory. If yes then when does it delete it? And if i use the second way then I would have to delete my own memory? - Brad __ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ -- 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: strtok bug
On Mon, 14 Jan 2002, Manuel Lemos wrote: Hello, Robert Mena wrote: Hi Manuel and all developers. I understand that the implementation of strtok was broken (non POSIX compliant) but since it has been like this for ages would be better to give a chance to developers worldwide (that has been using and relied on this broken implementation) to control the behaviour of such feature much the same way REGISTER_GLOBALS (or something) in recently 4.1.0. Imagine recoding 100+ distributed scripts to change this! The decision of having this fixed is great but not paying attention (like you always did in the past) with backwards compatibility is (IMHO) a mistake. My opinion precisely. The problem is that PHP developers that decided to break strtok did not seem to have thought of that so they did not ask any users if they were relying on the original behaviour. They would not need to poll anybody. Common sense can lead to the conclusion that if a function has a certain behaviour for 4 years, chances are that there must be enough people relying on it that changing the behaviour would break their code. It seems that the person that broke strtok came to PHP much earlier than that and did not cross his mind about existing users relying on the original behaviour. If making it POSIX compliance was a good idea, it would have been better to add a function to the POSIX extension named posix_strtok and whoever thinks that POSIX compliance was a good idea could use that and it would not require breaking the existing strtok function. The same goes for dirname function that was broken before PHP 4.0.3pl1 . Anyway, do not count on PHP developers to ever reconsider and provide any means to restore the original. Despite the change was only made 2 months ago, they are too proud and already state that they will not admit it was a mistake. Usually they don't like somebody from outside to tell them that there are better solutions, especially after the mistake is already made. So, I advise you to not expect anything from the PHP developers regarding fixing the mistakes. To solve your problem it is either more realistic to not upgrade to PHP 4.1 now (if ever) unless you have the time to replace the calls to strtok and dirname with something else that provides the original behaviour like those replacement functions that I wrote and made available here: http://phpclasses.UpperDesign.com/browse.html/package/404 Manuel, If you're going to continue with this sour attitude towards the PHP developers who are putting a huge effort into improving PHP then I suggest you unsubscribe from php-dev. I have no problem with constructive criticism and I'm sure mistakes have been made in the past but your attitude the past few years is just not constructive and just upsets a lot of developers who are extremely dedicated to PHP. Although I've been very quiet about it I have to agree with Zeev and Rasmus concerning your attitude. It's just not acceptable. I suggest you create your own PHP bickering mailing list and continue there Please don't reply to the list. I don't feel like making this a long thread which will just bother most people who want to concentrate on the development. I just suggest you rethink your attitude; and either stay in harmony or move someplace else. Andi -- 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] Build problem since introduction of cli
Hey, When building PHP not from the php4 directory (e.g. in php4/cgi doing a ../configure) the build dies. I can't send in the error message right now but hopefully whoever changed the build can try it. Andi -- 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] mkdir() , making 'mode' parameter optional
Sounds fine to me. Andi At 10:41 PM 1/10/2002 +0100, Markus Fischer wrote: Is there someone who would object modifying mkdir() so it only needs the dirname to create and mode is optonal and defaults to 0777 ? bool mkdir(string pathname[, int mode = 0777]); There're no BC impacts. - Markus -- Please always Cc to me when replying to me on the lists. -- 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]
Re: [PHP-DEV] mkdir() , making 'mode' parameter optional
At 05:31 AM 1/11/2002 +0100, Markus Fischer wrote: On Fri, Jan 11, 2002 at 05:22:54AM +0100, Markus Fischer wrote : In any case - a hardcoded 0777 isn't logical, apart from being less safe. It makes totally sense because it only relies on the umask() being set. Well, maybe I need to explain why 0777 _is_ logical (I thought people here know unix). It's the default value for the mkdir command, for perl, and for python because it makes sense to only rely on the umask() setting. So, why not have it too? Because PHP is none of the mentioned above ? Come on. I'm not discussing whether to add another INI switch (this is totally out of scope and belongs to something else, but not here). Anyone with decent objections? +2 :) Andi -- 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] consistent way to handle structs
On Fri, 11 Jan 2002, Markus Fischer wrote: On Fri, Jan 11, 2002 at 11:22:22AM +0100, Hartmut Holzgraefe wrote : Georg Richter wrote: is there (should be) a consistent way to pass or return a structure?! e.g.: a) Function mktime splits the structure in lot of parameters b) fstat returns a non assoc array c) dio_fstat (which seems to be identical to fstat) returns an assoc array assoc array IMHO especialy mktime() is a good example on how *not* to things as not everyone in the world is used to month-day-year dates :( I'm for (+1) assoc return values. I think the code which is used to handle it is more verbose then ( $day = $assoc['day']; and not $day = $arr[0]; or whatever) and it also helps debugging because you can just do a print_r() on the return type. If we start to agree on assoc params we should also think of new functions to more easily parse them to expected variable types zend_parse_parameters_hash(hashtable TSRMLS_CC, key1:type1, |optional_key2:type2, var1, var2); Ok, don't sue me, its just an idea how to simplify those kind of param-parsings. Zak and I were also discussing about such a way of parsing more optional argument after his recent mysql propose. Maybe Andrei has an idea too? Andrei had this in mind when he implemented the zend_parse_parameters() framework. I was very much against this because it will encourage people to write functions who's parameters are hashes. This would lead to a huge performance hit (both the building of the hash before it's sent and the fetching of the various sent fields) and therefore I think it's a very bad thing to introduce. As it'll be so easy to use it'll encourage passing parameters in hashes which is something we really wouldn't want. Andi -- 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] consistent way to handle structs
On Fri, 11 Jan 2002, Markus Fischer wrote: What other way do we have to specify arbitray optional parameters without an ordering? Teh disadvantage of optional parmeters is when you need to only set the last one, you'll have to define all preceding optional parameters too. How does the MySQL C API handle this? I think using array() is pretty sucky. Look at the following example and I'm sure you're planning on it getting much worse. mysql_connect(foo, array(bar = 1, hello = 2)); For functions like mysql_connect() the performance impact is negligible (methinks). I don't think it'll always be negligible. It might not always be a bad idea but I think that if we support this easy to use function we're going to see this kind of stuff pop-up in more places than the very few places which just can't do without. Andi -- 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] consistent way to handle structs
On Fri, 11 Jan 2002, Hartmut Holzgraefe wrote: Andi Gutmans wrote: ... it'll encourage passing parameters in hashes which is something we really wouldn't want. it is already common practice in userland so you are fighting a war that is already lost IMHO Facts say it's not lost yet because there are barely any C functions with this support :) Andi as soon as you have, say, more then five parameters things get confusing, especialy if people have different habbits regarding paramter ordering, see mktime -- 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] consistent way to handle structs
On Fri, 11 Jan 2002 [EMAIL PROTECTED] wrote:
** Reply to note from Markus Fischer [EMAIL PROTECTED] Fri, 11 Jan 2002
12:48:15 +0100
What other way do we have to specify arbitray optional parameters
without an ordering? Teh disadvantage of optional parmeters is when
you need to only set the last one, you'll have to define all
preceding optional parameters too.
Consider allowing this:
function foo( $one=1, $two=2, $three=3 ) {
echo $one $two, $three;
}
foo( ,,5 ); # prints: 1 2 5
No value between commas in the parm list says take the default.
Required params must be filled in, but not specifying a value for an
optional parm takes the default from the function header.
It still requires the parms to be in the correct order, but you can
pick and chose which optional parms you want non-default values for.
The disadvantage is having to have the right number of commas before
your values, but at least you don't have to list all the defaults. (and
prevent yourself from being able to change a default just by changing
the function itself.)
The idea is stolen from HP's MPE operating system which I was sorry to
see depreciated recently.
There are two ways I can think of which would be sufficient solutions. The
first is the one you mention and the second is ADA style ability to
mention which argument is supposed to go to which parameter, e.g., foo(2
= two, 3 = three, 4 = four).
I think the nicer solution would be the second one but I don't think it's
feasible to implement this without a very heavy price in performance (we
can't know at compile time like in ADA and therefore we'd need to do
logic/lookups/bookeeping at runtime).
The alternative solution of allowing foo(,,4) would work and can probably
be implemented easier (it might still lead to a tiny slow down but
probably negligable); however it does look kind of ugly and it'll be quite
confusing if there will be lots of commas.
We are probably best off leaving things the way they are and in the very
few cases where it is really needed to pass arrays. However, this should
really be the exception to the rule when there is no other alternative
because building the array and later on checking for values inside it is
much slower than regular parameter passing.
Andi
--
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] adding finite(), isnan(), isinf()
At 07:12 PM 1/4/2002 -0800, Jim Winstead wrote: these are the standard C library names. are people going to insist they be phpified? is_finite() is_nan(), is_infinite()? Yes I think they should be phpified. The fact that we have some historic problems doesn't mean we should fix it now. It should probably be something like math_is_finite(), math_is_nan() or we can do it without the math_. I think in general it's beneficial to have the name of the package in the beginning of the name though. Andi -- 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 string.c /ext/standard/tests/strings wordwrap.phpt
At 06:03 PM 1/5/2002 +, Jim Winstead wrote: Andi Gutmans [EMAIL PROTECTED] wrote: If you need to use something like strncat()/strncpy() you should use strlcpy()/strlcat(). We changed to these functions a couple of years ago. in the case of wordwrap(), it is only copying part of the source string, so strlcat() wouldn't do the job. i figured it'd be more confusing to mix calls to strncat() and strlcat() in the same function than to just use strncat() consistently. the destination buffer is verifiably large enough to handle all of the strncat() calls. You're missing the point. In order to minimize the amount of API misuse of the str*cat() family of functions we decided only to use the ones I mentioned, everywhere. I am sure that you're code is correct but all places should use strlcat()/strlcpy() if they are using the str* family of functions. (now, i did think of keeping track of the current position in the destination buffer and using memcpy(), but it seemed like overkill. the size of the new buffer could be calculated more intelligently, too, by taking into account the requested line length and size of the original text to figure out the maximum number of breaks that will be inserted. but that's all optimization. i was mainly out to fix the segfault.) memcpy() is always better but it sometimes isn't worth the gain like possibly in your case I didn't mean for you to rewrite it with memcpy() because I know it can be a bitch and isn't always worth it but I'd like to keep PHP consistent with the mentioned functions. Andi -- 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 string.c /ext/standard/tests/strings wordwrap.phpt
At 10:44 AM 1/5/2002 -0800, Jim Winstead wrote: On Sat, Jan 05, 2002 at 08:22:24PM +0200, Andi Gutmans wrote: You're missing the point. In order to minimize the amount of API misuse of the str*cat() family of functions we decided only to use the ones I mentioned, everywhere. I am sure that you're code is correct but all places should use strlcat()/strlcpy() if they are using the str* family of functions. in all due respect, i think you're missing my point. wordwrap() copies chunks from the middle of the source string to the end of the destination string. neither strlcpy() nor strlcat() is useful in this situation, because all they take is the length of the destination buffer, not a length of characters to copy from the source. char *source = this is my string; strncpy(dest, source+5, 5); // copy 'is my' to dest. Yes you are right. In this case you should use memcpy(). i guess you could use strlcat() if you kept track of the current end position of the destination string and then lied about the size of the destination string so only the right number of characters were copied from the source, but that seems a rather obtuse way to do it. Nah, it's not meant to be used that way. in any case, i'm working on a memcpy()-based rewrite. i don't know that it is really useful for wordwrap() to be binary-safe, but that will be one of the side-effects. :) Even better :) Andi -- 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] Advice wanted on function arguments
Just be aware that POST/GET/COOKIE data is always saved as a string. So if someone sends you 2 it'll be the string 2. If the arguments to your function won't originate from the above but are written by the developer then overloading will work well. If not you might want to consider splitting the function into two. Andi At 02:10 PM 1/5/2002 -0600, Brian Foddy wrote: In an external php module project (php-tuxedo), we have a group of about 7 php functions that, depending on how we design them, could take two different types of arguments. 1. A integer argument 2. A string argument. If the string argument is given, there is another routine that can convert it to the corresponding integer argument, but its not guarenteed to match. Using the integer argument is guarenteed to work; hence we really need to support the integer args. However, the majority of users will want to use the string argument because its more intuitive and they should provide the translation tables to allow strings to work. I'd like to come up with a solution flexible enough for both. And I have come up with three different solutions... 1. Create two different function names/entry points, one set for ints, one set for strings. 2. Overload the function arguments and check which type of arg is being passed. 3. Screw it and just accept the ints, and let the users nest a function (in their PHP code) to convert to strings if they want. Questions... 1. Any slick way to do solution 1, say with aliases or something? 2. How difficult / successful is it to test the arg type for solution 2. Let me re-stress, I'm talking about a PHP C code module, not PHP code. I can provide more detailed description if you need. Thoughts? Brian -- 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]
Re: [PHP-DEV] Proposed updates and extensions to the MySQL extension
At 10:37 AM 1/4/2002 +0100, Markus Fischer wrote: On Fri, Jan 04, 2002 at 09:24:33AM +, Phil Driscoll wrote : On Thursday 03 January 2002 11:08 pm, Zak Greant wrote: Why? Because not everyone wants to use *(#$ing objects in a simple script! No one will be forced to use the wrapper! :) Whilst this is true, and I know that you are thoughtful and conciencious enough to make sure that any new stuff available via OO would also be available via a procedural interface, I fear that this might be the start of a trend which would spoil PHP. If you are a web applications developer, there are plenty of mainstream options if you like OO. There are fewer if you prefer procedural code, and PHP is certainly the natural home for those of us in the latter camp. The further PHP moves into the OO camp, the less appealing it becomes for the procedural people. Once we have an OO interface to such a mainstream extension as mysql (probably *the* most important php extension?), it sends an important message to users and developers alike. Maybe you missed that ZE2 new major strength will better OOP support. So its a good idea to start getting users used to it because that is were ZE2 (namespaces, etc) will lead us to. I don't quite agree. I see PHP's future as a hybrid language which allows most developers to feel comfortable and allows them to use the programming paradigm of their choice. The ease of use which often is very much linked to the functional interfaces is one of the reasons for PHP's success. Although I think it is important to improve the OOP support I am still very much for keeping our functional support as strong as it has been up to today. We are still keeping the OOP support in the Zend Engine 2 at a level which is good for decent OOP developers but aren't going bezerq like OOP fanatics would like us to go :) Andi -- 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] Always building command line PHP
At 04:39 PM 1/3/2002 -0500, Jon Parise wrote: On Thu, Jan 03, 2002 at 04:26:38PM -0500, J Smith wrote: Just a little annoyance I guess. Nothing to get in knots over. But in the end, I would prefer separate php.ini files, maybe something like php-cli.ini for the default CLI file and and php.ini for the Apache/web server module default. If php-cli.ini doesn't exist, the CLI can always fall back on php.ini, which would be the default in any case. I agree that it's sometimes necessary to have different configuration files, but I don't consider it a necessity. It should still be possible to build a separate CGI executable with a different php.ini path for those sites that require it. I don't think it's necessary to alter the build process to make that the rule, though. Your suggestion of a separate php-cli.ini has merit, but who will the php binary know when it's being used for CLI purposes and not as a CGI? We could have the CLI version check for a PHP_INI environment variable and if it exists use that instead. Wrapping cli on your own with the right environment variable should be no problem for anyone. Andi -- 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] PECL (was PHP 5)
I think that if PECL ends up being very good and actually works very nicely and transparently, we would PECLize all extensions. At release time of a new version of PHP we'd create a huge .tar.gz with the latest STABLE versions of the extensions we decide should be in the release tar.gz (I hope saying the extensions we decide on is politically correct enough :). However, if PECL doesn't become everything we hoped for within the next few months (possible) I don't think it should stop PHP 5. We could always have 5.1. Anyway, that's not too important right now. We still haven't heard from anyone what work has been done on PECL. I think without a lot of work done by many of us here on php-dev it'll probably not gain enough momentum. I suggest we move PECL either to its own mailing list or to php-dev. I don't think it's a good idea to mix between it and the PEAR mailing list which is mostly about PEAR PHP code.. Concerning PHP 5, some time ago we talked about how we're going to handle the standardization of function names with the next major version. Do you guys want to revisit this issue or keep the status quo? Andi -- 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 5
Creating a CLI sapi module w/o all of the CGI crap is extremely easy. What might be more challenging is fixing the build so that it always builds the cli. Then again I don't really know because I don't know the whole build system too well. Andi -- 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: [PEAR-DEV] PECL (was PHP 5)
I suggest keeping it on php-dev. All of the build stuff has been done by php-dev in the past as build/PECL related discussions really are php-dev. It also means that php-dev won't be allowed to cut themselves out of what's happening with PECL and it won't lead to some php-dev ppl who don't subscribe to PECL to be surprised in a few months time :) Andi At 02:16 PM 1/2/2002 -0500, Jon Parise wrote: On Wed, Jan 02, 2002 at 08:09:10PM +0100, Martin Jansen wrote: I suggest we move PECL either to its own mailing list or to php-dev. +1 for it's own mailing list. Additionally we could perhaps set up an own CVS module for PECL. (Currently it resides in /pear/PECL.) Guys? I think I agree on both points ([EMAIL PROTECTED] and /PECL). -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] MOPS Benchmark
At 04:59 PM 1/1/2002 +0100, Sebastian Bergmann wrote: I don't mind PHP to be slower than Perl or Python that much. But what I would not mind would be the Zend Engine 2 beeing slower than the Zend Engine 1... That's pretty weird. I ran the same script and they are pretty much the same which makes sense because non of the code which is used in that script was changed between ZE1 and ZE2. In any case, pertaining things such as the OOP in ZE2 I wouldn't bench mark it at this time because it is work in progress and hasn't been optimized (I know that your test didn't involve it but I'm beating you to it :) Andi -- 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 5
Hey, The Zend Engine 2 has made lots of progress. I think we should have a discussion of what other things besides the scripting engine we'd like to change for PHP 5. I know there was talk on deprecating some stuff such as old-style function names, moving extensions to PECL etc.. I think it's a good time to start discussing some of these issues (hopefully we can keep things short :) Also, let's try and keep the scope to realistic changes which won't turn PHP upside down and which are doable within a relatively short period of time. I think it'd be really cool if we could get an alpha of PHP 5 out by Spring. Unrelated, I'm still waiting to hear exactly what mechanism the PEAR guys implemented for PECL. I know that if it's not a really cool easy to use mechanism I would prefer to wait until we write one. One of the main strengths of PHP is that everything is bundled together and is easy to setup. We shouldn't make it much harder on people. Although we're planning on only move the unimportant extensions out of PHP I still think it should be extremely easy to get a list of available extensions (maybe even a part of the ./configure process) and to easily download/configure/install them. Andi -- 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 5
At 05:56 PM 1/1/2002 +, Jim Winstead wrote: (and 'unimportant' is a dangerous word. obviously that depends on the situation.) I think it's obvious what I meant. Andi -- 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 5
At 07:24 PM 1/1/2002 +0100, Georg Richter wrote: Although we're planning on only move the unimportant extensions out of PHP I still think it should be extremely easy to get a list of available extensions (maybe even a part of the ./configure process) and to easily download/configure/install them. Please could you explain unimportant ?! Uhm it's what we've always talked about: Extensions which are not very widely used. (Why do people always need to get so picky about wording?) This can of course include extensions who'se author wants it to be outside of PHP because of the release cycle. If you need an example. MySQL is widely used. fribidi is not widely used. session is widely used. readline is not. We agreed in the past that there is a set of core extensions which we'd want to keep in PHP. We don't want to remove everything from PHP as this was always one of PHP's strengths. Anyway, I don't know why we are clinging to the unimportant part of what I wrote and not the important part which is how PECL actually uses it and what the vision for PECL is. Andi -- 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] SOAP and CORBA
At 12:44 AM 1/2/2002 +, Nick Loman wrote: Hello PHP developers, Interesting to think about what might make a nice foundation technology for all the exciting potential of PHP5. SOAP is obviously an important technology for websites in the future. But given that (I guess) most of us are not really that keen to follow in the nervous footsteps of Microsoft, and given that XML brings me out in a horrible rash, why don't we think about CORBA as a fundamental PHP technology? CORBA is now finally in a state where people can actually use it without running away screaming. There are now enough free implementations on enough platforms to enable mainstream PHP support. David Eriksson has done some nice stuff with Universe/Satellite, but I don't think PHP's CORBA support is currentl plug n' go enough to really be capitalised on (it currently relies on a fair amount of knowledge of CORBA). What would be fantastic is a situation where newbie PHP coders feel confident enough to use CORBA services exposed to the Internet (not many exist at the moment, the classic example is Random.org but this could change). If it was easy enough to start interacting with ORBs exposed to the 'Net, and it was easy enough for PHP developers to write their own net-facing ORBs, we could potentially be facing an interesting paradigm shift whereby PHP users are exposing their interesting objects (which may, e.g. provide access to databases, content) to the 'net. Much sexier than say RDF, no? If anyone would like to help me in my quest to make CORBA more mainstream (CORBA isn't really scary, at its most basic its just cross-platform remote procedure calls) I would love to work with you. All the best for 2002 everyone, We are going to try to improve the object overloading in ZE2 so I suggest not working on this before we see what we can come up with. Basically we are just trying to make it easier for people to overload objects from C and make it a bit more powerful. In the meanwhile you can still play around with different Corba implementations and choose how you're going to do it but I suggest waiting because it'll hopefully save you lots of headaches. Andi -- 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] Built-in SOAP based Web Services support (wasRe: PHP 5)
At 09:13 PM 1/1/2002 -0200, Manuel Lemos wrote: I already have some SOAP components written in this meta-language. If I work on something that would make it easier to provide and consume Web servers (and I have been doing some work), I will invest my time better on doing it with this meta-language rather than something that is PHP specific. It's a shame that if you have something good that you're not willing to share it with the PHP community. Andi -- 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] Moving extensions to PECL
Before we move stuff to PECL can you give us an overview of how this is supported? How do I get a list of extensions which are in PECL, download what I want and add them to my PHP tree for a static compile or build them dynamically? I assume you guys automated these things. Please can you give us an overview? Thanks, Andi At 01:38 PM 12/31/2001 -0500, Jon Parise wrote: I think the following standard extensions should be moved to PECL: ext/cybercash ext/icap ext/pfpro ext/yaz This is definitely not an inclusive list; it's just a start. I can't imagine a lot of people using these modules, so they seem like good candidates for removal from the base PHP distribution. Are there any well-founded objections to this (either in practice or principle)? -- Jon Parise ([EMAIL PROTECTED]) . Information Technology (2001) http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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]
Re: [PHP-DEV] References - good or bad
At 08:20 AM 12/29/2001 +0800, Alan Knowles wrote: Andi Gutmans wrote: As I mentioned on the ZE2 mailing list there general rule of thumb is: a) Objects should be passed by reference. b) Everything else including arrays should be used by value whenever possible semantically. In the ZE2 objects will join b). Is there a proposed sytnax to stop copy by reference (Or did i miss it in the ZE2 docs) old stuff $object_copy = $object; //(copy) $object_copy = $object; //(copy reference) new stuff? $object_copy = copy_object($object); //(copy) $object_copy = $object; //(copy reference) To copy around a reference you will just use it as a regular value. Like in your second example, i.e.: $same_object = $object; Basically you're just copying the object handle and not the object itself. In order to create a real copy (with a new object handle) you'll do: $new_object = $object-__clone(); Andi -- 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: is_array_multidimensional
At 09:06 PM 12/29/2001 +, Jim Winstead wrote: Derick Rethans [EMAIL PROTECTED] wrote: Log: - Added extra parameter to count() that recursively counts elements in an array and added is_array_multidimensional(). (patch by Vlad Bosinceanu [EMAIL PROTECTED]) do we really want to perpetuate this idea that a multidimensional array is special in some way? i often get the feeling that people just don't seem to get that what makes an array 'multidimensional' in php is that one array contains other arrays, and things like all the array sorting functions don't somehow treat them differently. I agree with Jim. Arrays can contain things. Things can also be other arrays. You can have an array which contains two other arrays and four integers. I don't think we should add these functions because they are wrong *especially* the is_array_multidimensional(). Of course, if there's a good reason to have them and we're all convinced that the reasons are good we could add them. Can you please roll back that patch and open up a discussion with examples of why this functionality is needed? It might even lead to a different solution. Andi -- 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] Fwd: [Zend Engine 2] Zend Engine 2 Examples
I sent this out to the engine 2 mailing list yesterday. I didn't want to receive too many bug reports at once so I decided to wait a day before I send it to php-dev (although most of you are probably on that list too). Please try and mess around with it. An example script of features is attached or can be downloaded from http://www.php.net/~andi/zend2.zip Please don't announce it anywhere else because I don't think it's ready for a wider audience. Andi Date: Fri, 28 Dec 2001 07:35:22 +0200 To: [EMAIL PROTECTED] From: Andi Gutmans [EMAIL PROTECTED] Subject: [Zend Engine 2] Zend Engine 2 Examples Hey, I'm attaching a script which tries to give short examples for most of the new object stuff in the Zend Engine 2. I think the Zend Engine 2 is at the stage where people can start playing around with it and in my opinion from looking over the examples script the new changes are really cool and allow for some much nicer development. There are some small quirks I know about, but in any case, let me know of any you find. I think this is a good time for people to start playing around with it. Just check out the ZendEngine2 CVS (instead of the Zend CVS) and rename it to Zend before doing ./buildconf and ./configure. A special note on destructors: I am still not sure how well they will work because it's not obvious that PHP will always be in a stable enough state to run them but I guess that's the same issue you'd have in C++ after a segfault. So this change really needs a lot of testing and we need to see when and when not destructors can work. Please play around a bit with the Zend Engine. I'm also interested in hearing how many changes you actually had to make to your scripts due to the fact that objects are now handles (i.e. how many scripts this actually broke). A big thanks to Stig who helped iron out the whole idea of nested classes and how we make them functional so that they can be used as namespaces for projects such as PEAR. I'm aware that I didn't explain the samples and some things aren't in the Zend Engine 2 document (especially the whole nested classes stuff) so if you have any questions, ask. Enjoy :) Andi zend2.php Description: Binary data -- 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: is_array_multidimensional
At 10:42 PM 12/29/2001 +0100, Stig Venaas wrote: On Sat, Dec 29, 2001 at 11:13:11PM +0200, Andi Gutmans wrote: I agree with Jim. Arrays can contain things. Things can also be other arrays. You can have an array which contains two other arrays and four integers. I don't think we should add these functions because they are wrong *especially* the is_array_multidimensional(). Agree Of course, if there's a good reason to have them and we're all convinced that the reasons are good we could add them. Can you please roll back that patch and open up a discussion with examples of why this functionality is needed? It might even lead to a different solution. One solution (not so sure I like it myself), could be a function that tells whether an array contains values of a given type. Then you could check if the array contained an array (or any other type). I've never had a use for such myself. Let's first try and understand the problem :) In what case does the user need these functions and how often does this happen to people. Once we understand the problem well we can think together of a good solution. Andi -- 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] References - good or bad
As I mentioned on the ZE2 mailing list there general rule of thumb is:
a) Objects should be passed by reference.
b) Everything else including arrays should be used by value whenever
possible semantically.
In the ZE2 objects will join b).
Basically what this means, as long as you're not changing the data passing
it by value will take the full advantage of reference counting.
Andi
At 10:28 AM 12/28/2001 -0600, Brian Moon wrote:
Ok, there has been some discussion on the ZE2 list about returning
references from functions and it has gotten me looking at references in
general. Phorum deals with some pretty large arrays and so far that has
made us faster than other BB's. I want to keep it that way.
First, the question: When is it a good idea to use references for
performance reasons?
Now, some things I tried (PHP 4.0.6):
$arr=array();
$arr=array_pad($arr, 1, md5(microtime()));
function test($arr){
$newvar=$arr;
return $newvar;
}
$newvar=test($arr);
This code takes 2.6MB of ram to run. Changing the function to any of these:
function test($arr){
$newvar=$arr;
return $newvar;
}
function test($arr){
$newvar=$arr;
return $newvar;
}
function test($arr){
$newvar=$arr;
return $newvar;
}
it now takes 4.4MB to run. That is not what I expected.
Now, this function:
function test($arr){
foreach($arr as $key = $var){
$newvar[$key]=$var;
}
return $newvar;
}
takes 4.4MB also. I would expect that. However, changing it to:
function test($arr){
foreach($arr as $key = $var){
$newvar[$key]=$arr[$key];
}
return $newvar;
}
It now takes 6.8MB of ram.
Last, this code:
$arr=array();
$arr=array_pad($arr, 1, md5(microtime()));
$arr2=$arr;
uses 2.6MB where:
$arr=array();
$arr=array_pad($arr, 1, md5(microtime()));
$arr2=$arr;
uses 3.5MB.
So, my conclusion is that references are bad in all cases on memory and
should only be used when you have to know you are using the same exact data
in two places, or a variable needs to be modified by a function. If this is
the case, shouldn't this be documented?
Am I missing something?
Brian Moon
--
dealnews.com, Inc.
Makers of dealnews dealmac
http://dealnews.com/ | http://dealmac.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 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] exit()
At 02:23 PM 12/26/2001 +0900, Yasuo Ohgaki wrote: Brian Moon wrote: +1 -1 As Derick pointed out, it still prints... Huh? What do you mean? Andi In stead of discussing about exit(), I *strongly* suggest to discuss regarding BC issues - which features may be changed - how changes may be introduced - where these BC changes will be announced - when these DB changes will be announced - what kind of procedure may be appropriate for BC changes As we already know, there were BC changes in past. Why not for future changes? - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, December 21, 2001 3:20 AM Subject: [PHP-DEV] exit() | Guys, | | I just read the whole thread about exit() now. Boy you guys write a lot :) | Unlike Zeev I think that overloading exit() is the best solution we have | right now. | Have exit(integer) exit with an exit status and exit(string) print the | error. I also very much liked the proposal of exit(string, integer) where | it would behave correctly with exit(foo), exit(5) and exit(foo, 5). | I think BC is an issue and I wouldn't want to break stuff during a 4.x | release. It's not as if people can't survive with the way it is today | (people have survived for a long time). If it doesn't change tomorrow | morning it's not like PHP will fall apart. | How about changing this for PHP 5? | | Andi | | P.S. - Just a small suggestion. When people write essays in E-mails please | see if they can't be shortened whilst still saying all you wanted to say. | It sometimes takes a long time to read all of these threads :) | | | -- | 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] | | | -- Yasuo Ohgaki -- 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]
[PHP-DEV] exit()
Guys, I just read the whole thread about exit() now. Boy you guys write a lot :) Unlike Zeev I think that overloading exit() is the best solution we have right now. Have exit(integer) exit with an exit status and exit(string) print the error. I also very much liked the proposal of exit(string, integer) where it would behave correctly with exit(foo), exit(5) and exit(foo, 5). I think BC is an issue and I wouldn't want to break stuff during a 4.x release. It's not as if people can't survive with the way it is today (people have survived for a long time). If it doesn't change tomorrow morning it's not like PHP will fall apart. How about changing this for PHP 5? Andi P.S. - Just a small suggestion. When people write essays in E-mails please see if they can't be shortened whilst still saying all you wanted to say. It sometimes takes a long time to read all of these threads :) -- 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 in 4.1.0; _SESSION
I guess this bug needs to be fixed somehow but I'd probably just not allow it to be defined as global. The whole reason for making it an auto-global was so that it'll be easy to use. People know (and will know) that $_SESSION is a global. I think your explicit marking of it as a global is not a good idea and doesn't really give you anything. Why not just add a comment if you really feel it is needed? Andi At 01:59 PM 12/21/2001 +0100, Andreas Aderhold wrote: Hi All, found a bug this one will cause a infinte loop in 4.1: ?php global $_SESSION; // this will cause a infinite loop session_start(); phpinfo() ? Te docs say that $_SESSION is auto-global in 4.1.0 but it does not say, that the explicit global declaration is not allowed. However I would like to use the explicit global declaration for improved code readbility. Andi -- www.binarycloud.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 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 Module Leaking
Does this web server spawn a new thread for each request? Or does it reuse
its threads?
Andi
At 12:22 PM 12/21/2001 -0600, Alex Leigh wrote:
I'm sure it's leaking, it'll readily consume a gig of memory and shows no
signs of slowing down. I originally was calling phpinfo(), but it also leaks
equally if I just have the php handler serve a page with no php in it.
So, yes, it leaks that amount every request and it never frees.
The code as I mentioned is a copy of the NSAPI module (nearly identical),
and it basically does:
if (php_request_startup(TSRMLS_C) == FAILURE) {
return FAILURE;
}
...
php_execute_script(file_handle TSRMLS_CC);
php_request_shutdown(NULL);
Alex
On 12/21/01 10:28 AM, Zeev Suraski [EMAIL PROTECTED] wrote:
Are you calling request_shutdown?
Also, are you sure it's actually leaking? Does it leak 200-400KB on each
and every request, or does this rate 'slow down' at some point?
Zeev
At 18:20 21/12/2001, Alex Leigh wrote:
All -
I have written a SAPI module for a new webserver continuity. The code is
basically the SAPI code for NSAPI, modified to work with continuity's API.
Continuity is threaded, based on the pthread libraries.
My problem is that each requests that is handled by PHP leaks about
200-400KB. I've gone over the code carefully, and I don't see that I am
doing (or more importantly, not doing) anything differently than any
of the
other SAPI modules.
I have tried php4-4.1.0, as well as the 12/17 cvs snapshot, on both Linux
and Solaris. I did not configure php with any options other than that to
include my sapi module --with-capi.
If someone could give me a reference to SAPI documentation (none of
which I
could find), or give me a lead on what my problem might be, I'd appreciate
it.
My SAPI code can be had at
http://www.ashpool.com/dist/php4-capi-v200-p1.tar.gz
--
Alex Leigh - www.tessier.com - [EMAIL PROTECTED]
The difference between theory and reality is that
in theory there is no difference.
--
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]
--
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 Module Leaking
Check out DllMain() in php4isapi.c.
Are you running the thread attach and thread detach code?
Andi
At 12:43 PM 12/21/2001 -0600, Alex Leigh wrote:
It can do both. In the testing configuration, it is not pooling but
destroying the threads. They are created as detached threads, which at least
on Solaris go away after they terminate; the ones that exit aren't building
up in the process (I verified this with pstack). I am not specifying an
explicit cleanup handler for the threads, if that makes any difference; they
are exiting normally by returning off the function called in
pthread_create().
Does this web server spawn a new thread for each request? Or does it reuse
its threads?
Andi
At 12:22 PM 12/21/2001 -0600, Alex Leigh wrote:
I'm sure it's leaking, it'll readily consume a gig of memory and shows no
signs of slowing down. I originally was calling phpinfo(), but it also
leaks
equally if I just have the php handler serve a page with no php in it.
So, yes, it leaks that amount every request and it never frees.
The code as I mentioned is a copy of the NSAPI module (nearly identical),
and it basically does:
if (php_request_startup(TSRMLS_C) == FAILURE) {
return FAILURE;
}
...
php_execute_script(file_handle TSRMLS_CC);
php_request_shutdown(NULL);
Alex
On 12/21/01 10:28 AM, Zeev Suraski [EMAIL PROTECTED] wrote:
Are you calling request_shutdown?
Also, are you sure it's actually leaking? Does it leak 200-400KB on each
and every request, or does this rate 'slow down' at some point?
Zeev
At 18:20 21/12/2001, Alex Leigh wrote:
All -
I have written a SAPI module for a new webserver continuity. The
code is
basically the SAPI code for NSAPI, modified to work with
continuity's API.
Continuity is threaded, based on the pthread libraries.
My problem is that each requests that is handled by PHP leaks about
200-400KB. I've gone over the code carefully, and I don't see that I am
doing (or more importantly, not doing) anything differently than any
of the
other SAPI modules.
I have tried php4-4.1.0, as well as the 12/17 cvs snapshot, on both
Linux
and Solaris. I did not configure php with any options other than that to
include my sapi module --with-capi.
If someone could give me a reference to SAPI documentation (none of
which I
could find), or give me a lead on what my problem might be, I'd
appreciate
it.
My SAPI code can be had at
http://www.ashpool.com/dist/php4-capi-v200-p1.tar.gz
--
Alex Leigh - www.tessier.com - [EMAIL PROTECTED]
The difference between theory and reality is that
in theory there is no difference.
--
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]
--
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]
Re: [PHP-DEV] PHP for Win32 without MySQL?
Your best bet is to remove all files which are related to MySQL from your project. (and not define HAVE_MYSQL) Andi At 11:16 AM 12/18/2001 -0500, Matt White wrote: Has anyone attempted to build a version of PHP on Win32 without MySQL? In config.w32.h there is the following couple of lines: /* set to enable mysql */ #define HAVE_MYSQL 1 ... and if you set this equal to 0, the compile progresses normally until you hit php_mysql.c. (VC++ gives up after a couple of hundred errors... mostly undeclared identifier errors, which are most likely caused by a header not being included somewhere along the way.) - Matt -- 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]
Re: [PHP-DEV] ext/adt - futher devel?!
At 12:06 AM 12/18/2001 +0100, Sterling Hughes wrote: Hi, as ext/adt hasn't experienced any updates for a while, I'd just like to know if further development ist planned. I've been pretty as of late -- I should have time during the holidays to play around with it a bit... Its about 5 hours of work till a alpha/beta -- 5 hours I'm not looking forward too ;) You've always been pretty :) Andi -- 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] Unbuffered fgetc needed for stdin
This usually depends on how you configured your tty. I think by default it is buffered by the OS until a newline so it's probably not PHP which needs changing but your settings. Andi At 12:30 PM 12/15/2001 -0800, August Zajonc wrote: I've really run into a wall trying to get single charachters from stdin. Something similar to the getchar macro or a real fgetc would be nice. The current behavior is that more than a signle charachter can be typed and fgetc only returns when it sees a \n. I'd like it to return immediatly after the first charachter. fscanf with a format string something like %c requires a \n before returning as well, though I suppose that is more understandable. various things like fread with length of 1 also don't work. This is missing functionality for which there is no workaround that would certainly make shell scripting easier. It should be relativly trivial to implement, either an unbuffered fgetc option or a new function or something. -AZ -- 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]
Re: [PHP-DEV] Re: Headers
At 01:31 PM 12/11/2001 -0500, Jon Parise wrote: On Tue, Dec 11, 2001 at 02:18:50PM +0100, Sebastian Bergmann wrote: http://www.sebastian-bergmann.de/header_changes.txt Quite some -Copyright (c) 1997, 1998, 1999, 2000 The PHP Group | +Copyright (c) 1997-2002 The PHP Group| As I understood it, it is apparently more correct to list the individual years than to use a range of dates. The following would be therefore be correct: Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002 The PHP Group I don't think it makes any difference and 1997-2002 is nicer. © IBM Corporation 1994-2001. All rights reserved. That's from the IBM web page. If it's good enough for them it's definitely good enough for us :) Andi -- 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] PHP XML
At 11:50 AM 12/8/2001 +0100, Stig S. Bakken wrote: Rasmus Lerdorf wrote: Guys, relax. No, this does not work. The only reason your example works is because min() is a built-in PHP function already. man now i am crushed... i knew it wouldn't work - that's why i never tried. i was so amazed when i tried that i must have been blind to the fact that i chose a bad example... has anyone every thought of adding such a thing? the dev team can surely appreciate it because #defined macros are all over the php source. You can use create_function() to do something like that. See http://php.net/create_function Or simply make a function. The point of macros in a language like C is that they are processed before compilation and a real function call is avoided. This does not apply to a non-compiled language like PHP so there is no reason not to simply create a PHP-level function if you want something like that. You mean a non-precompiled language like PHP. Technically speaking, PHP has been compiling for a while. I wouldn't call PHP a compiled language. It's basically still an interpreter like Perl Python. Andi -- 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: Re[4]: [PHP-DEV] [NEW EXTENSTION]: templates
At 05:07 PM 12/5/2001 +0200, Andrey Hristov wrote: I don't think that If I wrote an extension it will go into the public because the rights on it are owned by the university I study. It will never be GPLed if not rewritten after I get the degree. You can ask for permission to put it in the public domain. You'll find that your professor will most likely agree. Andi -- 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] more 1.3 vs 2.0 differences
I think it's fine if you work on these as the Apache 2 module is still experimental and it makes sense to keep the same interface as the 1.3 module where possible. Andi At 05:53 PM 12/5/2001 -0800, Doug MacEachern wrote: - apache_lookup_uri with the apache 2.0 module returns an array rather than a class. any objections to making it behave the the 1.3 based module? - the 2.0 getallheaders lets the authorization header through whereas 1.3 does: PG(safe_mode) !strncasecmp(tenv[i].key, authorization, 13) - the 2.0 module is missing the following functions: apachelog, apache_note, apache_setenv, apache_child_terminate. - and the PHP_MINFO_FUNCTION() doesn't do anything in the 2.0 module. i can work on these, unless there are reasons not to support them? -- 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]
[PHP-DEV] Constants
Hi, I'm trying to wrap up the class wide constants in ZE2. I implemented them so that class wide constants are case-sensitive. I think in general, although ZE1 allows you to define case-insensitive constants it's better for performance and for general esthetics. I have two issues I'd like to get some input on: a) There are almost no constants in PHP which are case-insensitive (which aren't user land defined with define()). Actually the only ones I could find are in the Zend Engine such as TRUE FALSE which makes sense. All PHP extensions which use REGISTER_LONG_CONSTANT() and friends use the CONST_CS (case-sensitive flag). I would like to change these macros to *always* register as case-sensitive. Unless I missed some extensions this shouldn't bite anyone as all extensions seem to use CONST_CS. Of course I won't change the special purpose constants such as TRUE FALSE which are today registered as case-insensitive. What do you guys think? b) REGISTER_MAIN_LONG_CONSTANT() and friends (notice the MAIN) are used to register constants which shouldn't be unloaded when the PHP extension is unloaded. I can't think of many cases where this is applicable. For example, if the pspell extension is unloaded I think all of its constants should be unloaded too. However, this extension is one example of an extension using the _MAIN_ macro. Can each of you check your extension and move to REGISTER_LONG_CONSTANT() unless there's a good reason not to? Thanks, Andi -- 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] Constants
At 01:03 PM 12/3/2001 -0600, Andrei Zmievski wrote: On Mon, 03 Dec 2001, Andi Gutmans wrote: Hi, I'm trying to wrap up the class wide constants in ZE2. I implemented them so that class wide constants are case-sensitive. I think in general, although ZE1 allows you to define case-insensitive constants it's better for performance and for general esthetics. I have two issues I'd like to get some input on: a) There are almost no constants in PHP which are case-insensitive (which aren't user land defined with define()). Actually the only ones I could find are in the Zend Engine such as TRUE FALSE which makes sense. All PHP extensions which use REGISTER_LONG_CONSTANT() and friends use the CONST_CS (case-sensitive flag). I would like to change these macros to *always* register as case-sensitive. Unless I missed some extensions this shouldn't bite anyone as all extensions seem to use CONST_CS. Of course I won't change the special purpose constants such as TRUE FALSE which are today registered as case-insensitive. What do you guys think? Makes sense. I'd also like to request that the engine be able to distinguish between FOO_BAR and Foo_BAR constants, for example. Personally I wouldn't write code which gives FOO_BAR and Foo_BAR two different meanings but I think you are right that it'd be better and I have an idea on how to do it which I'll lay out. We are only talking about global constants defined with define() as class constants are always case sensitive and they can distinguish what you mentioned above. There's one way I can think of in order to fix define(). It has advantages and disadvantages. The advantage is that all constant lookups will be much faster than they are today (no strtolower() and no memcmp()). The disadvantage is that defining constants will be much slower. What we would do is that instead of adding the name of the constant after an strtolower() into the constants hash we would do the following: - for case-sensitive constants: Add it with the exact same case as the definition. - for case-insensitive constants: Add all possible cases for the constant. That means that for a word of length L we'd add at most L*2 keys to the hash. This solution actually would work very well. It'd would fix the above problem and hash lookups would be faster. It would also be a step away from case-insensitive constants. It would of course make case-insensitive constant definitions much slower but as no C-extensions use them (especially after I nuke it) and only about 5 constants in Zend use them it should be fine (this is assuming that not many people use the third argument of define() which allows them to define case-insensitive constants). Andi -- 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: [Zend Engine 2] Re: [PHP-DEV] Constants
At 02:42 PM 12/3/2001 -0600, Andrei Zmievski wrote: On Mon, 03 Dec 2001, Andi Gutmans wrote: Personally I wouldn't write code which gives FOO_BAR and Foo_BAR two different meanings but I think you are right that it'd be better and I have an idea on how to do it which I'll lay out. We are only talking about global constants defined with define() as class constants are always case sensitive and they can distinguish what you mentioned above. That's fine for me. I want them for the keysym constants in PHP-GTK (like GDK_KEY_A and GDK_KEY_a). For now I hack around by using (GDK_KEY__A) for lowercase ones. Which sucks. Oh OK. There's one way I can think of in order to fix define(). It has advantages and disadvantages. The advantage is that all constant lookups will be much faster than they are today (no strtolower() and no memcmp()). The disadvantage is that defining constants will be much slower. What we would do is that instead of adding the name of the constant after an strtolower() into the constants hash we would do the following: - for case-sensitive constants: Add it with the exact same case as the definition. - for case-insensitive constants: Add all possible cases for the constant. That means that for a word of length L we'd add at most L*2 keys to the hash. This solution actually would work very well. It'd would fix the above problem and hash lookups would be faster. It would also be a step away from case-insensitive constants. It would of course make case-insensitive constant definitions much slower but as no C-extensions use them (especially after I nuke it) and only about 5 constants in Zend use them it should be fine (this is assuming that not many people use the third argument of define() which allows them to define case-insensitive constants). What about the idea of introducing case-insensitive hashes? Modifying hash function so that it hashes 'A' and 'a' into the same value. Because some of the keys are case-insensitive and some aren't. Case insensitive hashes don't work if you want to mix the keys. In any case, I think the solution above is a good one because there are only 5 constants in the Zend Engine which are case-insensitive. Andi -- 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: [Zend Engine 2] Re: [PHP-DEV] Constants
At 02:55 PM 12/3/2001 -0600, Andrei Zmievski wrote: On Mon, 03 Dec 2001, Andi Gutmans wrote: Because some of the keys are case-insensitive and some aren't. Case insensitive hashes don't work if you want to mix the keys. In any case, I think the solution above is a good one because there are only 5 constants in the Zend Engine which are case-insensitive. I realize that. Perhaps _ex() versions of hash functions could take a flag indicating which hash function to use. This may come in handy not just for constants, you know. I still don't understand why you think it's suitable. If I want to lookup a constant FOO_Bar. How would you know if the hash function you want to use is case-sensitive or not? In any case, you used to be able to specify a different hash function in hash_init() but it was never used and for performance reasons we inline'd the hash function. Andi -- 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] typo in Zend sources
Fixed. Thanks! Andi At 11:16 AM 11/30/2001 +0100, Derick Rethans wrote: Hello, configure spits out the following line: checking whether dlsym() requires a leading underscode in symbol names... no this should be underscore I think... Derick -- 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]
Re: [PHP-DEV] V_OPEN and memory
At 02:57 PM 11/28/2001 +0100, Thomas Wentzel wrote: What happened to V_OPEN/V_GETCWD/... I had them in 4.0.4pl1, but they are gone in 4.0.6 ??? They are now VCWD_OPEN() and VCWD_GETCWD(). The previous ones clashed with third party libraries. Andi -- 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] C++ in extension?
At 03:48 PM 11/28/2001 +0100, Lars Knudsen wrote: correction: it seams that using the 'string' from stdlib makes the difference. If I: #include string using namespace std; ... it doesnt work - but only if I *use* the string class strange. anyone got any Idea why? Possibly because you're not linking PHP with the C++ library? If you're using plain C++ you don't need to but if you're using C++ library functions including stuff from namespace std I think you're supposed to link with it. A good idea would also to do an nm on your extension and see if it has C++ stuff. Any function which is mangled weirdly is C++. Andi -- 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: Nested comments
At 11:31 AM 11/28/2001 -0800, Vlad Krupin wrote: Hartmut Holzgraefe wrote: Markus Fischer wrote: Although my vote doesn't count much here :-) I'm for it... ... but it would be a problem for 4.x I guess because this horribly breaks BC when/if there's a new 4.x release and people start using it. should be no problem to introduce it with 4.2 as we are breaking BC in lots of places anyway ... I do not have much against this particular proposal, but I have observed the tendency here (on this mailing list) to be something like that: Since we are breaking one thing, we might just as well let the hell break loose and break everything else, be it necessary or not. Often times the break early, break hard principle will not work all that well just because we are not breaking early anymore, and breaking things just to make a cute feature or two work might not be such a good idea. This is just an observation, don't flame me, but this attitude is starting to worry me a bit. I can see 4.2 being so different from 4.0.6 that we might not be able to call it 'php' anymore. Just something to watch out for, so we don't go overboard... Now, have a good day, everyone I agree. We should fix problems but people have to remember that no matter what there are lots and lots of users out there and the less we break things, even between major versions, the easier possible the transition will be for the users. Most PHP users out there aren't php-dev techies who like fixing their old code to work with new versions :) They prefer their old stuff to work. So sometimes we need to break stuff but it should always be done only if it really makes good sense and gives enough benefit. Andi -- 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] BC problem
Yep. As far as I remember it was reverted in 4.1.0
Andi
At 01:54 PM 11/28/2001 -0600, Brian Moon wrote:
This has already been discussed at great length in another thread. I
believe it was decided to put it all back like it was for now and decide on
a better solution later.
Brian.
- Original Message -
From: Markus Fischer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 28, 2001 11:05 AM
Subject: [PHP-DEV] BC problem
A small example which shows that BC seems to be broken for a
certain (but not uncommon) case:
cat include_me.php
?
if (!defined('I_AM_INCLUDED')) {
define('I_AM_INCLUDED', 1);
} else {
echo returningbr\n;
return;
}
function cant_be_redefined() {
}
?
cat include_it.php
?
echo 1br\n;
include 'include_me.php';
echo 2br\n;
include 'include_me.php';
echo 3br\n;
?
Now run include_it.php (it doesn't matter if its CGI or
module):
On PHP 4.0.4pl1 up to 4.0.6 this gives:
1br
2br
returningbr
3br
But now I get:
1br
2br
br /
Fatal error - Cannot redeclare cant_be_redefined()
(previously declared in include_me.php:9)
[I shortened the error message to be more readable]
If this is 'now the way it is' this should be mentioned
somewhere very clearly I think. Doesn't seem to be fixable in
some way? Couldn't find a reference to it e.g. in the NEWS
file.
I know that there should be used include_once() but
I'm talking about existing code writing that way which
definitely won't work without modifications.
- Markus
ps: thanks to Jan for verifying this!
--
Please always Cc to me when replying to me on the lists.
--
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]
--
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] BC problem
At 11:04 PM 11/28/2001 -0600, Brian Moon wrote: -snip- With 4.0.6 I get: 4.0.6 test With 4.1 RC3 I get: 4.1.0RC3br /br bFatal error/b: Cannot redeclare test() in b/home/brian/public_html/include.php/b on line b9/bbr with CVS I get: 4.2.0-devbr /br / bFatal error/b: Cannot redeclare test() (previously declared in /home/brian/public_html/include.php:8) in b/home/brian/public_html/include.php/b on line b9/bbr / Andi, Zeev, I thought we were going to back out that change? Did you check the 4.1.0 Zeev packaged? It was supposed to be backed out. I don't have time to check now. Andi -- 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: Nested comments
I don't think this should be changed and we should stick to the way it is
in C. (It is also not BC and even if I thought it's a good idea, which I
don't, I don't think it's worth it).
Andi
At 11:48 AM 11/27/2001 +0100, Anders Johannsen wrote:
This patch allows for nested 'C-style' comments, which can be useful
especially while debugging.
?php
/* comments
/* now /* nest */ */
/*/*/*/*
*/*/*/*/
*/
?
Since comments are handled purely lexical, there should be virtually no
performance hit.
The following two examples show how errors are handled:
1)
?php
/*
*/
*/
?
2)
?php
/*
/*
*/
?
Ad 1) This will yield a zend_error(E_COMPILE_ERROR,Invalid nesting of
comments) on the
last line. Unpatched, a parse error is the most likely result.
Ad 2) A zend_error(E_COMPILE_WARNING, unterminated comment starting line
%d, CG(comment_start_line)) is raised.
The attached patch is against latest CVS
Best regards,
Anders Johannsen
--
[EMAIL PROTECTED]
Index: zend_globals.h
===
RCS file: /repository/Zend/zend_globals.h,v
retrieving revision 1.80
diff -u -r1.80 zend_globals.h
--- zend_globals.h 2001/10/23 01:19:16 1.80
+++ zend_globals.h 2001/11/27 10:08:06
@@ -82,6 +82,7 @@
int comment_start_line;
char *heredoc;
int heredoc_len;
+unsigned int comment_nest_level;
zend_op_array *active_op_array;
Index: zend_language_scanner.l
===
RCS file: /repository/Zend/zend_language_scanner.l,v
retrieving revision 1.40
diff -u -r1.40 zend_language_scanner.l
--- zend_language_scanner.l 2001/09/22 00:06:27 1.40
+++ zend_language_scanner.l 2001/11/27 10:08:07
@@ -1,5 +1,4 @@
%{
-
/*
+--+
| Zend
Engine |
@@ -125,6 +124,7 @@
{
CG(heredoc) = NULL;
CG(heredoc_len)=0;
+ CG(comment_nest_level)=0;
}
@@ -1057,24 +1057,39 @@
}
}
+ST_IN_SCRIPTING*/ {
+ zend_error(E_COMPILE_ERROR,Invalid nesting of comments);
+}
+
ST_IN_SCRIPTING/* {
CG(comment_start_line) = CG(zend_lineno);
BEGIN(ST_COMMENT);
+CG(comment_nest_level) = 1;
yymore();
}
-
-ST_COMMENT[^*]+ {
+ST_COMMENT[^/*]+ {
yymore();
}
+ST_COMMENT/* {
+CG(comment_nest_level)++;
+yymore();
+}
+
ST_COMMENT*/ {
- HANDLE_NEWLINES(yytext, yyleng);
- BEGIN(ST_IN_SCRIPTING);
- return T_COMMENT;
+CG(comment_nest_level)--;
+
+if (CG(comment_nest_level) == 0) {
+HANDLE_NEWLINES(yytext, yyleng);
+ BEGIN(ST_IN_SCRIPTING);
+ return T_COMMENT;
+} else {
+ yymore();
+}
}
-ST_COMMENT* {
+ST_COMMENT*|/ {
yymore();
}
--
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]
Re: [PHP-DEV] Patch: Nested comments
At 07:56 PM 11/27/2001 +0100, Markus Fischer wrote:
On Tue, Nov 27, 2001 at 05:59:44PM -, James Moore wrote :
if(0) {
}
Doesn't prevent the code from between being parsed.
Andi, for ZE2 this is also no option? ZE2 definitely breaks
BC and neested comments are very useful. In C you have it
easy with #if 0 but .. hm?
It's not like I don't want to keep BC as much as possible for ZE2 too. Sure
that for important stuff BC is less important but I don't see nested
comments being very important to ppl. This is one of the only times it has
come up in the past few years so it must not be such a big deal to ppl.
If everyone *really* wants nested comments we could think of a solution. I
would still prefer a non-BC breaking alternative way.
Andi
--
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: Nested comments
At 10:17 PM 11/27/2001 +0100, Anders Johannsen wrote: On Tue, 2001-11-27 at 21:49, Stig Venaas wrote: On Tue, Nov 27, 2001 at 09:41:46PM +0100, Anders Johannsen wrote: The submitted patch does not break any existing code Perhaps I should have added: ... unless you have a really silly commenting style. Okay, it is a bit weird, but people do things like this. Wouldn't those scripts break? They would break, warning the user about an unterminated comment. However, I suspect that it will affect only very few people. I believe there are many silly (I don't consider it silly because it happens to the best of us) people out there and I believe that it will affect enough people for it not to be worth breaking it. Andi -- 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] CGI quick cleanup
At 09:33 AM 11/26/2001 +, Sam Liddicott wrote: -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: 24 November 2001 01:21 To: Sam Liddicott; Sam Liddicott; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] CGI quick cleanup The problem you are experiencing is due to the fast cache. Edit Zend/zend_fast_cache.h and change: # define ZEND_ENABLE_FAST_CACHE 1 to: # define ZEND_ENABLE_FAST_CACHE 0 I'm not sure what fast cache is, is lack of this likely to slow down the processing of enormous hashed arrays? I think it really depends on the exact memory allocation pattern of your program. I have a feeling that in your case it'll be much faster without the fast cache but you can benchmark it. Make sure you do a complete rebuild. Tomorrow I'll try and think of what the best way to fix it is. (3:20 AM here :) To go to bed late is to be up early (paraphrased from Shakespeare summit-or-other) :) Andi -- 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: 10% speedup patch in zend_hash_copy
It doesn't look like such a good idea to me. There are lots of things in PHP where you can get 10% speedup by copypasting stuff from one function to another. It makes the code completely unmaintainable and in real life situation usually, if at all, gives a negligible speedup. I've played around a lot with this kind of stuff and it is only worth it IMO if you can really prove it makes a difference. Also, note that results may very quite considerably from platform to platform. BTW, if you can prove it really makes a difference then the solution might be inlining those functions into hash_copy() and not going in the direction of unmaintainable code. But that is a big if anyway as I mentioned earlier. Andi At 05:29 PM 11/25/2001 +0100, Thies C. Arntzen wrote: hi - this litte patch makes zend_hash_copy around 10% faster by taking a shortcut zeev, andi - is this commitable or do you have any objections? tc -- 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: 10% speedup patch in zend_hash_copy
very = vary. I need to stop sending stuff off without proof reading :) Andi At 11:01 PM 11/25/2001 +0200, Andi Gutmans wrote: It doesn't look like such a good idea to me. There are lots of things in PHP where you can get 10% speedup by copypasting stuff from one function to another. It makes the code completely unmaintainable and in real life situation usually, if at all, gives a negligible speedup. I've played around a lot with this kind of stuff and it is only worth it IMO if you can really prove it makes a difference. Also, note that results may very quite considerably from platform to platform. BTW, if you can prove it really makes a difference then the solution might be inlining those functions into hash_copy() and not going in the direction of unmaintainable code. But that is a big if anyway as I mentioned earlier. Andi At 05:29 PM 11/25/2001 +0100, Thies C. Arntzen wrote: hi - this litte patch makes zend_hash_copy around 10% faster by taking a shortcut zeev, andi - is this commitable or do you have any objections? tc -- 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]
RE: [PHP-DEV] CGI quick cleanup
The problem you are experiencing is due to the fast cache.
Edit Zend/zend_fast_cache.h and change:
# define ZEND_ENABLE_FAST_CACHE 1
to:
# define ZEND_ENABLE_FAST_CACHE 0
Make sure you do a complete rebuild.
Tomorrow I'll try and think of what the best way to fix it is. (3:20 AM here :)
Andi
At 01:37 PM 11/23/2001 +, Sam Liddicott wrote:
Here's a sample script that does most of the sorts of stuff I was doing
apart from database work.
Note how long it takes to exit after finishing.
#! /usr/bin/php -q
?php
ini_Set(max_execution_time,0);
ini_Set(memory_limit,500M);
class thingy {
function thingy($c) {
if ($c0) $this-ref=new thingy($c-1);
}
}
$stash=array();
$max=50;
$start=time();
for($i=0;$i$max;$i++) {
$r=rand(0,300);
$stash[$r][]=new thingy(rand(0,10));
echo \rUse: .floor($i/$max*100).% ;
}
echo \n;
$mid=time();
$max=count($stash);
$c=0;
foreach(array_keys($stash) as $key) {
unset($stash[$key]);
$c++;
echo \rFree: .floor($c/$max*100).% ;
}
unset($stash);
echo \n;
$done=time();
print Use: .($mid-$start).\n;
print Free: .($done-$mid).\n;
?
--
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] CGI quick cleanup
The reason for this is most probably because during shutdown we decrement many reference counts and free each memory block separately. Theoretically we could just exit without doing any freeing of memory but we have to find a solution for freeing resources (maybe directly in the resource list and not via reference counting). If you can put together a short script which demonstrates the problem (without using external sources such as databases) then I will try and take a look at it and see if we need to improve the current code or go for a different approach. Also, I hope you're running in non-debug mode because debug slows down memory allocation/freeing significantly. Thanks, Andi At 10:35 AM 11/23/2001 +, Sam Liddicott wrote: I am using PHP for a system script to import TV listings to a database. It works well but creates 20,000 to 30,000 hash elements with various relationships and it *seems* to take exponentially longer for the script to actually stop running after it reaches the exit statement the more items there are. I also note that even though max execution time is set to zero and the script runs for a long time, I still get a max-execution error at 30 seconds after the script has been trying to exit (although the script runs for many minutes). 30 seconds is the timeout in the php.ini which I override with ini_set. I think this long shutdown time is PHP's per-page cleanup freeing all the objects, which is not so important if running as a CGI. Currently I am quitting with posix_kill(posix_getpid(),5) as it is pretty quick but I wondered if the per-page cleanup which is only important when running as an apache module could be disabled in cgi mode. Sam -- 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]
Re: [PHP-DEV] ?php= ? sytanx again
At 09:33 AM 11/15/2001 +0100, Stig S. Bakken wrote: Shane Caraveo wrote: Andi Gutmans wrote: Implementing this is not a problem but it seems that there is no consensus on adding it. I'm not sure what I think. I was very much against ?= but now it exists and is used by a lot of people it might be good to have ?php= but then again I can't make up my mind :) Andi When you cannot make up your mind, choose consistency. In this case, like it or not, the consistent thing to do is add it. It's odd and inconsistent to have %=, ?=, but not ?php=. I was also against ?= originally, but now that we do have it I agree that consistency (symmetry?) is better. Now all that is left is to decide :) I think we're at a deadlock. Who opposes this strongly? Andi -- 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= ? sytanx again
At 12:14 PM 11/16/2001 +0100, Marc Boeren wrote: It's odd and inconsistent to have %=, ?=, but not ?php=. I was also against ?= originally, but now that we do have it I agree that consistency (symmetry?) is better. Let's take this one step further (into absurdity ;-) and also add script language=php= %var; /script just for consistency, of course :) Blah. This will *never* be supported and I don't think it makes sense to include this in the discussion about ?=, ,%= and ?php= Now all that is left is to decide :) I think we're at a deadlock. Who opposes this strongly? Not me, I use ?php all the time... It seems that most people support ?php=. If no one comes up with a convincing argument against I will add ?php= later on today. BTW, I never liked the ?= syntax and opposed it at the time but I think today because many people seem to like it, it makes sense to have ?php= for consistency sake. Andi -- 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= ? sytanx again
At 05:42 AM 11/16/2001 -0800, Rasmus Lerdorf wrote: Now all that is left is to decide :) I think we're at a deadlock. Who opposes this strongly? I don't like it, but it is not strong opposition. To me it just doesn't read nicely at all: ?php=$a? compare with: ?$php=$a? or: ?php $php=$a? ?=$a? is maginally better because at least there is nothing to the left of the = sign to visually confuse matters. I see what you're saying and looking at it I agree that ?php= is actually worse than ?=. Maybe we should just stick to the status quo and whine about the fact that we introduced ?= to begin with :) Andi -- 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] XSLT Extension and paths
It probably doesn't use the virtual cwd stuff. Can you try and compile without thread-safety and see if it works? Andi At 02:40 PM 11/16/2001 +0100, Sebastian Bergmann wrote: Zak Greant wrote: How are you running PHP under Win - CGI, ISAPI, Apache Mod?? Apache 2.0.29-dev, PHP 4.2.0-dev build as CGI. What does getcwd() output? C:\Server\htdocs\ -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List 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]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Proposal for release process (Was: Re:[PHP-DEV]4.1.0)
At 01:36 AM 11/14/2001 +0100, Stig S. Bakken wrote: I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Yes, merging bug fixes into that branch would be more difficult. But certainly possible, _if_ we identify a need for small bugfix releases. The point is that for the person having a problem with a bug in 4.1.0, upgrading to 4.2.0 may be a problem because of all the other changes. In this case, a 4.1.1 release containing only that bug fix would make a lot of sense. I've been in this situation a few times myself, and it's not funny (X is broken in 4.0.1, 4.0.2 fixes X but breaks Y). Stig, I understood the point from the beginning and I have no problem in trying. I was just skeptical about how well it will work in real life. Andi -- 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] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
At 05:28 AM 11/12/2001 +0200, Jani Taskinen wrote: On Sun, 11 Nov 2001, Andi Gutmans wrote: I didn't quite understand what you mean :) I didn't get it first either. :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. The idea is NOT to go on for _months_ with the HEAD. The idea is to make it shorter by keeping the amount of testing smaller. And this is what the versioning stuff was aimed at too. Most people out there think that when a version number changes on the 'micro' part (4.1.x) it means that there are only bug fixes in this release and I can safely go ahead and update without fearing that something breaks. At the moment, you can't trust on this. It's definately NOT like all the other projects do. Zeev suggested at some point that we should drop the last number altogether. That indeed would make the current way of doing things more correct but would not really solve anything in the user end.. What I suggested: Only bug fixes go into the release branch. And all the nifty new features and big changes and BC breaking stuff go into the next release branch (HEAD). (ie. version 4.x+1.0 ) It's not very far from what we are doing right now. We have two branches, the release one and HEAD. But what I suggested was to keep the release branch and commit bug fixes into it and release bug-fix-only-releases from it. We can try and do this. I'm not quite sure it'll work in real life but I think it's it's worth a try. I agree that it is not much different than today but it requires someone who will take the job of screaming at ppl if they commit a bug fix to HEAD and not to the release branch. Also at some point we have to decide not to release bug fixes anymore for a certain version but I'm quite sure it'll come naturally with the release of the next more major version. Why would it be hard time doing it? It's not hard as long as certain rules are followed. It needs a bit more work and people who are dedicated for doing it. But the core developers ([EMAIL PROTECTED]) should first ratify all this stuff. :) Oh, I forgot..rules are bad..we're all volunteers..etc. crap. Why can't we improve this? It has worked for so long now.. and that is bull too. It might have worked and might work for a while but if we really want to make the quality better, we have to make some changes. All I meant by it has worked for so long is that it's not as if the situation has been horrible. It's been pretty decent but I am all for improvement. IMO opinion we need to appoint a couple of people so that when there is a concensus to branch and start the release process they will make sure it is pushed a bit. Look at the bug database: 803 open bug reports (feature requests, doc probs and website probs excluded) of which about 70% are not bugs but user errors and such. That still leaves us with over 200 reports that are real bugs. Some of them are in extensions which have been abandoned or the people who 'maintain' them don't simply care. But this is another story. (btw. in Scripting Engine related bugs there are 69 open reports.. :) Anything interesting? :) --Jani ..who's getting pretty tired at banging head on the wall.. I think we're actually getting somewhere. Andi -- 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] Proposal for release process (Was: Re: [PHP-DEV]4.1.0)
At 12:31 AM 11/11/2001 +0100, Stig S. Bakken wrote: Andi Gutmans wrote: Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi, If we trim down the PHP distribution to not contain as many goodies, chances are there won't be as many cries for head (no pun intended). The distinction between the second and third digit is basically documenting to the user the level of change in a release. I didn't quite understand what you mean :) All I said was that if you create a branch say 4.1.0 and you want to release 4.1.x from that branch later on whilst HEAD has already moved a couple of months you're going to have a hard time doing it. Andi -- 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.1.0
At 07:43 AM 11/10/2001 -0800, Rasmus Lerdorf wrote: I think the assumption that the PHP_4_0_7 branch is pretty stable and pretty much ready to go is the key here. How do you know? I think it is up to the QA team to tell us if this is the case. From what I can see, I don't think this is so. I think you are clinging to a couple of bug reports. We *always* have open bug reports when we make a release. I'm pretty sure that PHP_4_0_7 is stabler than HEAD because of some of the changes in file-upload and some other key places, so I don't think the fact that the branch has 1-2 bugs which HEAD doesn't have means that it is less stable. I think that if we can fix the 1-2 show stoppers that are still in the PHP_4_0_7 branch we should release ASAP. In my opinion the main issue is to get the $_POST[] change out to the public quickly. It is one of the only critical changes. We can start the 4.2.0 branch ASAP but judging from the past it'll take *at least* 2 months to get it stable. I don't want to have to wait that long to get a $_POST[] version out there. In any case, if people decide they want to go with HEAD we should branch right away and not the release linger. Andi -- 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] Proposal for release process (Was: Re: [PHP-DEV] 4.1.0)
Jani, I think in theory what you writes makes sense but it just doesn't work in the PHP project. (I'm talking about the minor versions coming out of branches). There are always cries to go with HEAD because it's got new goodies (I think it often makes sense) and then people don't want to release a second version out of a branch but want to use HEAD. All in all the release process in the past few years hasn't been that bad. I think the timing has been good and we haven't had *that* many screw-ups. What I do think we need is a couple of people who will push things forward once everyone decides that it is time to branch and start QA; so that things don't linger. Andi At 10:34 PM 11/10/2001 +0200, Jani Taskinen wrote: On Sat, 10 Nov 2001, Zeev Suraski wrote: Guys, We have a bit of a dilemma here. As you all know, the 4.0.7 branch, on which 4.1.0 is currently scheduled to be based on, has branched away a few months ago. Some people have expressed concern that releasing 4.1.0 based on that branch is not a good idea, because there have been so many changes in the HEAD branch, and synchronizing fixes and so on is going to be a headache. I have a bad feeling about this branch and I vote for dropping it and starting new from HEAD. There are several reasons for this: The change between 4.0.7 - 4.1.0 (and also sudden change of the release master from Zeev to Stig) has confused some people according the discussion on php-qa list a while ago. Many of them might have tested 4.0.7 RCs but not necessarily all have tested the 4.1.0 RCs. Not to forget the 11th of September.. I have no idea who have tested the latest RC. Does anyone have? After the latest RC there have been a LOT of fixes in the release branch and also several fixes in the HEAD (which weren't MFH'd) and there hasn't been any new RCs after those fixes were committed. How many people test the branch (from CVS) ? Has anyone kept any list of the test results and problems found ? Has anyone kept eye on fixes done which weren't merged to the branch ? Answer is: We don't KNOW. The thing is that the project has grown to be so big that we can not afford long periods of time between releases. Too much stuff gets in without testing. Too many NEW bugs are introduced and like it has been said many times before, not enough people really pay attention to fixing them. Developers simply ignore them and continue adding new stuff thus creating new possible bugs. Anyone think what I think? Release early, release often http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/x147.html This works very well for Linux, why wouldn't it work for PHP ? Our QA team is very small. It has actually gotten smaller during the last 6 months instead of getting bigger like it should have. Enough ranting, let's get into fixing this situation. I can't see any solutions that won't bite us but one solution that won't bite as so badly in the _long_run_, as if we delay it or release too early we're gonna get hurt. My proposal is this: - Release the current branch as 4.1.0 but clearly state that there will be 4.2.0 soon. Also start the 4.2.0 branch from HEAD now and the QA process on it with some things kept in mind: o Any serious problems found (by our best QA team: the real users) in 4.1 we fix them in 4.2 and announce that after 4.2 release we start following the versioning rules for real. o We continue releasing 4.2.x versions out of the 4.2 branch but with ONLY bug fixes in it. And we do this OFTEN. Any new stuff goes to HEAD. We should decide what amount of fixes or with what severity triggers the (short) QA process for the 4.2.x branch. o After there have been, let's say 5 big ones in HEAD, we start new branch, 4.3 and QA process moves there. The QA should not take so long with this. Security related fixes should trigger new release process immediately. o Any changes into extensions from now on should include the start of using the version numbers in extension. Also, if there are changes in many extensions or there are big changes in some extension we make another 4.2.x release. (compromise for Zeev's sake :) o Any big changes or changes that might possibly break things should be announced on the php-qa list and only after QA has tested that the changes don't break anything, they should be allowed into CVS. - We need to have ONE place where to keep the RC packages. And we need to have also Windows build of the RCs at this same place. Having the packages in someone's home directory is not very good idea. Better place would be at http://qa.php.net/ - We name persons for each branch who work together with QA team and make sure the releases are tested properly. ie. This person merges all fixes into the branch and keeps record how the testing goes on and decides when is the time to release. o List of succesful builds on different platforms
Re: [PHP-DEV] Fix for bug #11563
The patch looks OK if open_basedir is really supposed to stop people from stat()'ing files which aren't underneath the open_basedir path. Andi At 11:18 AM 11/4/2001 +0100, Martin Jansen wrote: In http://bugs.php.net/bug.php?id=11563 there is a patch for the reported bug. Is there anything speaking against applying this patch? - Martin -- 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]
Re: [PHP-DEV] dl() equivalent
At 08:43 AM 10/27/2001 +0200, Stig S. Bakken wrote: Hi, Back in the early 3.0 days, dl() used to load stuff into the process without removing it at the end of the request. Zeev, would not yanking modules back out at request shutdown eliminate some of the evilness of dl()? That is probably a possibility. But why not have the person add it to php.ini and not deal with any evilness? :) I think your proposal is probably a good solution for BC but I'd try to officially deprecate the function. Andi -- 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]
