Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems
Sorry, I wasn't disagreeing with you about that... just explaining another point. Adding some sort of directive sounds fine to me. The only problem or difficulty that I see is that we generate a lot of cache files for our site that are basically snippits of PHP code initializing variables and populating arrays of data to display in various places. No functions are created in these cache files, but we do from time to time need to include the files more than once. If we had to maintain server directives for each of these files or file locations, it would be less than optimal... Daniel - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: Brian Moon [EMAIL PROTECTED]; Edin Kadribasic [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, October 21, 2001 3:34 AM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems Yeah, ok, but that's what I'm getting at. What if we add a directive that makes all of the files on your site (or for that matter, in a certain directory) treat include as include_once? At 06:31 21-10-01, Daniel Beckham wrote: Intentionally? No, not really, but two seperate code files could include a single basic function library that both need seperately, but as soon as those two original code files are included into a main script of some sort, that basic function library is now being included twice. Daniel - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: Edin Kadribasic [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, October 20, 2001 8:42 PM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems At 19:11 19-10-01, Brian Moon wrote: - Even with no protection at all, function redefinitions will not be reported. That's kind of ugly. An E_NOTICE is raised at runtime. I know many people ignore these, but it is there. So basically, your existing code base will now be issuing tons of E_NOTICE's? How about if we introduce an implicit _once directive? Do you have cases in which you intentionally include the same file twice? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP 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] New zend_compile.c to solve all of the duplicate function problems
I'm sorry Stanislav, but I no longer wish to continue this conversation with you. You jumped into this entire discussion very late and you have been arguing with me and others here about stuff we *both* agree on. You obviously have had a horrible time understanding what I've been saying, whether it's because of my inability to effectively communicate what I'm thinking or it's because of your inablility to comprehend what someone else is saying. After reading several of your replies, I would think the later is what's going on. Thank you for your time, but it seems that Zeev already has several ideas of how to take care of this issue and we can leave the conversation of how to add namespaces, etc. to PHP for a later date and release schedule. Your ideas seem good, if only they had some context to what the conversation was originally about. Regards, Daniel Beckham - Original Message - From: Stanislav Malyshev [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: php-dev [EMAIL PROTECTED] Sent: Sunday, October 21, 2001 5:12 AM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems DB I do not know Java. In Perl, namespaces exist, so it's a DB completely different ballgame. But even still, it's not the DB responsibility of the user to know the inner workings of a DB module or package in Perl. If we talking about how to quick hack PHP engine so that it would suit this-minute needs of someone - it is not so interesting to me to discuss. If we talk about PHP strategy - it's already accepted that PHP needs namespaces, and there's a work in progress on it, so it's not completely different ballgame. DB function library from the user themselves. Why are you DB continuing this argument? Mostly because I have got tens of answers to this thread and only *one single answer* on my package proposal. So if this thread is the place where my voice is heard - I will use it :) -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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] New zend_compile.c to solve all of the duplicate function problems
- Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Stanislav Malyshev [EMAIL PROTECTED] Cc: Daniel Beckham [EMAIL PROTECTED]; php-dev [EMAIL PROTECTED] Sent: Sunday, October 21, 2001 5:21 AM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems I think we can relax this thread now... Can we agree on this: 1. Stay with what we've been having until today, as in, revert the current patch. It should be a one liner. Yes, thank you. 2. Look into adding an implicit _once directive into PHP. I want some feedback on this, to see if it's really going to help, or whether both include() types are used simultaneously... To me this is a decent solution, but problematic as it puts a lot of work on the system administrator and gives the development team less flexibility when writing code. Developers will want to continue using include for speed and flexibility. 3. Discuss packaging extensions alongside the namespace plans. We can discuss that now, but I do agree with Stig as far as seeing them as closely related to ZE2 features, namely, the namespace features. I still hate 'use', though :) I absolutely love this idea. I think a proper implementation of namespaces is the best route for PHP in the long term. PHP can only benefit from this... the only negative is the amount of time we have to wait to be able to use it. =) Daniel -- 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] New zend_compile.c to solve all of the duplicate function problems
Intentionally? No, not really, but two seperate code files could include a single basic function library that both need seperately, but as soon as those two original code files are included into a main script of some sort, that basic function library is now being included twice. Daniel - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: Edin Kadribasic [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, October 20, 2001 8:42 PM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems At 19:11 19-10-01, Brian Moon wrote: - Even with no protection at all, function redefinitions will not be reported. That's kind of ugly. An E_NOTICE is raised at runtime. I know many people ignore these, but it is there. So basically, your existing code base will now be issuing tons of E_NOTICE's? How about if we introduce an implicit _once directive? Do you have cases in which you intentionally include the same file twice? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP 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] New zend_compile.c to solve all of the duplicate function problems
You asked me why twice, but I explained it in the email. Separating my last sentence to make it look like I think including files is a poor programming technique seems a little childish. So is asking Why over and over again when someone has already answered you. Lastly, I compared it to C because the developers write it in C and many aspects of it are modeled after C. Daniel - Original Message - From: Stanislav Malyshev [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: Brian Moon [EMAIL PROTECTED]; PHP Development [EMAIL PROTECTED] Sent: Friday, October 19, 2001 2:49 AM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems DB Essentially, to answer your question. include_once() is a very DB poor way to write modular code that will be used across DB different projects and across different developers. You are Why? DB placing the responsibility of not accidentally redefining DB function names on the user of the function library or code file DB and not on the file itself as it should be and as it is in other DB languages such as C. To put it shortly, it's a backwards way of PHP is not C. So PHP can not be such as C. You are placing responcibility of including a module onto the engine, and that is completely OK with me. I agree that it would be good to have more developed concept of a package and all the hoopla that is going with that - but until then, I see nothing wrong in include_once. DB including files and it's a poor programming technique. Why? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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] New zend_compile.c to solve all of the duplicate function problems
This is exactly what I was saying and a magic include_once token in the
file is a great idea. I was never making a case for leaving buggy code in
PHP, only that if you were going to change the behavior, you would also add
more flexible ways to do the job.
Daniel
- Original Message -
From: Rasmus Lerdorf [EMAIL PROTECTED]
To: Stanislav Malyshev [EMAIL PROTECTED]
Cc: Daniel Beckham [EMAIL PROTECTED]; Brian Moon
[EMAIL PROTECTED]; PHP Development [EMAIL PROTECTED]
Sent: Friday, October 19, 2001 3:15 AM
Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate
function problems
Stanislav, he does have a point in that it would be a good idea to be able
to create an include file which protected itself from multiple exclusion
instead of relying on the user to use the file correctly. That's what he
means by bad style. There could be cases where you created a system where
some files were designed to be included multiple times and others were
designed not to. Putting the responsibility on the user to figure out
which is which is not great. It would be nice if you could trigger the
include_once functionality from the file being included.
Almost like the call-time-pass-by-reference vs.
force-reference-in-func-declaration argument. Not quite the same, but I
think you see what I mean.
Since you can no longer do:
if(!defined(_FOO_INC)):
define('_FOO_INC',1);
...
endif;
to protect a file from multiple inclusion within the file itself, some
other mechanism would be nice. I wouldn't say this was crucial, but I
definitely see the case for it. Some sort of magical 'only_once' token at
the top of an included file which forces the include to act like an
include_once for that file might do it, or as Brian did, don't toss fatal
errors if the same function is redefined in the same file.
-Rasmus
On Fri, 19 Oct 2001, Stanislav Malyshev wrote:
DB Essentially, to answer your question. include_once() is a very
DB poor way to write modular code that will be used across
DB different projects and across different developers. You are
Why?
DB placing the responsibility of not accidentally redefining
DB function names on the user of the function library or code file
DB and not on the file itself as it should be and as it is in other
DB languages such as C. To put it shortly, it's a backwards way of
PHP is not C. So PHP can not be such as C. You are placing
responcibility of including a module onto the engine, and that is
completely OK with me. I agree that it would be good to have more
developed concept of a package and all the hoopla that is going with
that
- but until then, I see nothing wrong in include_once.
DB including files and it's a poor programming technique.
Why?
--
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] New zend_compile.c to solve all of the duplicate function problems
By all means, if you have a decent proposal that doesn't involve exclusively using include_once() or if/endif everywhere possible, we would love to hear it. Daniel - Original Message - From: Stanislav Malyshev [EMAIL PROTECTED] To: Rasmus Lerdorf [EMAIL PROTECTED] Cc: Daniel Beckham [EMAIL PROTECTED]; Brian Moon [EMAIL PROTECTED]; PHP Development [EMAIL PROTECTED] Sent: Friday, October 19, 2001 3:43 AM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems RL which is which is not great. It would be nice if you could trigger the RL include_once functionality from the file being included. I fear this won't sit well with how the engine works... But maybe you won't need this, in fact. I think that this should be done in more systematic way, so that if you include some code bunch, you are sure this and that is defined, without checking each thing by itself. Especially when we talk about functions and classes, which are not the same small change as variables and should be handled more systematically. There still be the cases when you do need such hacks, in one way or another, but I think that a systematic approach to the problem will do better than a hackish 'patch there, fiddle here' approach. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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] New zend_compile.c to solve all of the duplicate function problems
- Original Message - From: Stanislav Malyshev [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: Brian Moon [EMAIL PROTECTED]; PHP Development [EMAIL PROTECTED] Sent: Friday, October 19, 2001 2:45 AM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems A lot of languages don't have ifdefs (actually, most of them). A lot of languages do not allow to redefine functions. Still each of these languages allows to create code libraries. Obviously, your implied argument that this is needed to implement libraries is wrong. My argument is that some functionality similar to a C #ifdef and #ifndef is needed. Neither the include_once() nor the if/endif solutions provide that. If you want to do that Perl style with packages or C style with macros or whatever style, it's fine with me. My issue is that there is no PHP way to do this other than include_once() or an if/endif statement. Actually, even now it can be done properly, given: 1. Reusable code (variables) and definition code (function) reside in different files, just like you would do it in C 2. include and include_once is used properly I already pointed out why include_once() is bad. You place the responsiblity of knowing the inner workings of function libraries on the user themselves and not the library. This is poor programming. It would be much better if PHP could have a concept of a library package, which would solve a lot of did I already have this package, and if not, how I import it properly? questions. Making quick hacks to bend the language into compliance with some hacky way to solve the problem won't do any good in the long run, only bring more problems. I agree with you totally. But, if you truly believe that it needs to be more than a hacky solution, then drop this include_once() nonsense and let's think of a better way to do this. Unless of course, I'm mistaken and you are more worried about doing something hacky in the PHP source and don't care if the PHP developers themselves have to write hacky code? Daniel -- 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] New zend_compile.c to solve all of the duplicate function problems
The reason it works inside of an if/endif is because the code is never pre-compiled and only executed during run time. For large code libraries, like we have here at our office, this would cause a performance decrease. Daniel - Original Message - From: Edin Kadribasic [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: PHP Development [EMAIL PROTECTED] Sent: Friday, October 19, 2001 9:27 AM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems By all means, if you have a decent proposal that doesn't involve exclusively using include_once() or if/endif everywhere possible, we would love to hear it. I'm just curious: what's wrong with using if/endif where include_once isn't good enough? -- 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] New zend_compile.c to solve all of the duplicate function problems
Thanks.. I was wondering if anyone had any solid information about this. Daniel - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: Edin Kadribasic [EMAIL PROTECTED]; PHP Development [EMAIL PROTECTED] Sent: Friday, October 19, 2001 11:54 AM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems At 16:33 19-10-01, Daniel Beckham wrote: The reason it works inside of an if/endif is because the code is never pre-compiled and only executed during run time. For large code libraries, like we have here at our office, this would cause a performance decrease. The code is precompiled alright. It's just compiled into slightly worse intermediate code, because no compile-time binding can be done. I don't expect the difference to be more than a few percent away, and altogether, it may not be noticeable at all. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP 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] New zend_compile.c to solve all of the duplicate function problems
An earlier thread with the following subject makes some of our points: [PHP-DEV] Bug #13616 Updated: Compiler complains about function declaration after return is calle Essentially, to answer your question. include_once() is a very poor way to write modular code that will be used across different projects and across different developers. You are placing the responsibility of not accidentally redefining function names on the user of the function library or code file and not on the file itself as it should be and as it is in other languages such as C. To put it shortly, it's a backwards way of including files and it's a poor programming technique. Daniel - Original Message - From: Stanislav Malyshev [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: PHP Development [EMAIL PROTECTED] Sent: Thursday, October 18, 2001 10:14 AM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems BM See bug 13616. I see. I think you should really use include_once - I just do not see the reason why not to do it and why patch the code instead. Could you explain? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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] New zend_compile.c to solve all of the duplicate function problems
- Original Message - From: Stanislav Malyshev [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: PHP Development [EMAIL PROTECTED] Sent: Thursday, October 18, 2001 10:53 AM Subject: Re: [PHP-DEV] New zend_compile.c to solve all of the duplicate function problems BM And my fix will keep a function from being defined twice. It BM will simply also allow people who have become accustomed to BM using the language this way to keep doing it. I'm not sure that being allowed to use a language in a buggy way is a right thing to do... This would hide many double include errors, and would *not* restore the backwards compatibility - since code that didn't work then would work now with your patch. I don't think that's true. From what I can tell, if a different function in a different location in the same file or another file is encountered by the compiler, his patch with produce a fatal error. This fixes the problem where people were attempting to actually redefine a function name. Brian's patch allows the compiler to encounter the same function in the same file on the same line and only give a notice instead of a fatal error. It's not the most elegant solution, but then again, we have no #ifdef and #ifndef as you C coders do to allow us to properly create function libraries. If/else could be used to achieve similar results, but from what I understand, only under a serious performance penalty. Which, BTW, is very unacceptable. Daniel -- 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 pcntl function documentation (and other stuff)
- Original Message - From: Jason Greene [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 14, 2001 11:35 AM Subject: Re: PHP pcntl function documentation (and other stuff) The system and exec (IMHO) are written very badly in PHP and don't even come close to doing what execv will do. They are pretty much the same as using backticks but with a few variations. (Getting the exit code and the last line of output sent by the program.) They just aren't suited to the stuff that's done with fork and execv. Well they are very good at their purpose, which is to take care of all the intricacies of spawning another process. I think that I probably used harsher language then I really meant to when talking about exec and system. My main beef is that exec (and a few other PHP functions) use similar names as their (choose your language) counterparts, but don't make a very good attempt at actually emulating those counterparts. I personally think that exec would always have been better off emulating the exec (3) functions instead. But of course, fork() has been begged for, for eons. The fact that PHP is open source is a blessing and a curse. The blessing is that If you don't like how someone wrote a function like system() or exec() you can just roll your own. The curse is that there end up being three ways to do something and they could probably all be rolled into one for brevity and clarity. Sounds great. I will try and focus as much time as I can on getting docs before the release. Great.. I already have the pcntl_fork and pcntl_waitpid docs done... I'll probably also do the waitpid macros before I send you something. Daniel -- 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 pcntl function documentation (and other stuff)
One more question. Were you considering adding wait() to the list of functions supported? I know it's very similar as waitpid(), but it is simpler to use unless you are doing something more complex in nature. Daniel -- 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 pcntl function documentation (and other stuff)
I would say definitely yes to exec, vfork and wait4. Adding wait and wait3 isn't a huge priority, but it's worth putting them in there to round out the list of functions available. IMHO, if you are going for a one to one relationship between the system functions and the pcntl library, I wouldn't combine those together into something like wait_rusage(). Someone using the pcntl functions will just know that wait3 or wait4 will do exactly what they expect it to do without having to do much more than brush up on a manpage. Daniel - Original Message - From: Jason Greene [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 14, 2001 5:00 PM Subject: Re: PHP pcntl function documentation (and other stuff) Yes I was debating on whether or not to add that, but I wasn't sure what people were looking for. I was also debating on adding wait3 and wait4. so here are the functions that should be added pcntl_exec() pcntl_wait() pcntl_vfork() pcntl_wait3()??? pcntl_wait4()??? hmm.. maybee they should be combined to a pcntl_wait_rusage() What do you think? -Jason - Original Message - From: Daniel Beckham [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 14, 2001 1:55 PM Subject: Re: PHP pcntl function documentation (and other stuff) One more question. Were you considering adding wait() to the list of functions supported? I know it's very similar as waitpid(), but it is simpler to use unless you are doing something more complex in nature. Daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
Everyone loves to hate Perl don't they? Daniel - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Andrei Zmievski [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED]; Sterling Hughes [EMAIL PROTECTED]; [EMAIL PROTECTED]; Sæther Bakken @gecadsoftware.com [EMAIL PROTECTED] Sent: Wednesday, August 15, 2001 10:43 AM Subject: Re: [PHP-DEV] Setting up RFC Hi Andrei! On Wed, 15 Aug 2001, Andrei Zmievski wrote: On Wed, 15 Aug 2001, Zeev Suraski wrote: like. That's why the situation wouldn't change radically if/when the engine license changes, much like it wasn't any different *before* the engine license was even introduced, in the PHP 3.0 days. Having regulators over the 'kernel' of the project is certainly not very unique to the PHP, and had a significant role in bringing PHP to where it is today, and not where Perl is today, for example. You always compare PHP to Perl. How about Python? It's a well designed language that's pretty open for development.. Look at their PEPs system. maybe cause PHP it's better than Perl but not than Python? :) -- teodor -- 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] Bug #11904: ext/standard/string.c patch for nl2br()
If someone commits this change, please make sure you change his br to a br /. Not sure if that was on purpose or not... Daniel - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 05, 2001 7:56 AM Subject: [PHP-DEV] Bug #11904: ext/standard/string.c patch for nl2br() From: [EMAIL PROTECTED] Operating system: Linux 2.4.6 Slackware PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: ext/standard/string.c patch for nl2br() I suggest the following patch for string.c to fix the nl2br() function. Instead of replacing \n with br /\n, I think \nbr is better. For example, in a string, there might be a \r\n and when nl2br() is applied, it would become \rbr /\n. Having a \r by itself and not paired with a \n causes problems for me because most programs afaik expect either just a \n (unix systems) or \r\n (microsoft systems) and know how to deal with them. But when a \r is by itself, strange things sometimes happen and the file will print corrupted. But applying the patch below, \r\n would become \r\nbr which keeps the carriage return and newline pair intact and adds the break... unix and windows programs understand the file still and html renderers don't care about formatting. *** string.c.orig Thu Jul 5 08:41:46 2001 --- string.c Thu Jul 5 08:38:04 2001 *** *** 2511,2517 convert_to_string_ex(str); ! php_char_to_str((*str)-value.str.val,(*str)-value.str.len,'\n',br /\n,7,return_value); } /* }}} */ --- 2511,2517 convert_to_string_ex(str); ! php_char_to_str((*str)-value.str.val,(*str)-value.str.len,'\n',\nbr,5, return_value); } /* }}} */ -- Edit Bug report at: http://bugs.php.net/?id=11904edit=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] -- 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] foreach behavior and error suppression (@foo)
There are several open feature requests in the bug system to allow the use of @ to suppress warnings when using a non array with foreach. What's the status of this? Is this a hell no!, not possible with the current state of the code or a when we get around to it? Thanks, Daniel -- 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] foreach behavior and error suppression (@foo)
Yes, it would be nice for foreach to be a little more forgiving even if it is far in the future. Daniel - Original Message - From: Zak Greant [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED]; php-dev [EMAIL PROTECTED] Sent: Monday, July 02, 2001 4:18 PM Subject: Re: [PHP-DEV] foreach behavior and error suppression (@foo) Perhaps we want to roll this request into the list of proposed changes for PHP 5? --zak - Original Message - From: Daniel Beckham [EMAIL PROTECTED] To: php-dev [EMAIL PROTECTED] Sent: Monday, July 02, 2001 3:16 PM Subject: [PHP-DEV] foreach behavior and error suppression (@foo) There are several open feature requests in the bug system to allow the use of @ to suppress warnings when using a non array with foreach. What's the status of this? Is this a hell no!, not possible with the current state of the code or a when we get around to it? Thanks, Daniel -- 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] foreach behavior and error suppression (@foo)
I know this will be also shot down, but at least I tried. What about the possiblity of foreach simply acting on the variable as if it was list($var) or array($var)? It seems that it wouldn't break any existing behavior, but would only make foreach more flexible. Daniel - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: php-dev [EMAIL PROTECTED] Sent: Monday, July 02, 2001 4:19 PM Subject: Re: [PHP-DEV] foreach behavior and error suppression (@foo) If the question is about @foreach(...) ... Then the answer is somewhere between 'hell no!' and 'not possible with the current state of the code'. foreach is a statement, whereas @ is an operator that works on expressions... At 00:16 3/7/2001, Daniel Beckham wrote: There are several open feature requests in the bug system to allow the use of @ to suppress warnings when using a non array with foreach. What's the status of this? Is this a hell no!, not possible with the current state of the code or a when we get around to it? Thanks, Daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP 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] switch, equality and preg_match
Someone poke me when you decide what to do and I'll change the return type
in the preg_match docs.
Daniel
- Original Message -
From: Brian Moon [EMAIL PROTECTED]
To: chrism [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, July 01, 2001 3:16 AM
Subject: Re: [PHP-DEV] switch, equality and preg_match
Here is your culprit:
RETVAL_LONG(matched);
The declaration in the docs says the function returns an int. However,
the
text of the doc says that the function returns True or False.
Changing your call to:
$match = (bool)preg_false(); /* prints alpha always */
gives you the results you want.
Andrei, you are listed as the author on this file. What needs to change?
The return type? That would make the most sense to me.
Brian Moon
--
dealnews.com, Inc.
Makers of dealnews, dealmac
http://dealnews.com/ | http://dealmac.com/
- Original Message -
From: chrism [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, June 30, 2001 7:02 PM
Subject: [PHP-DEV] switch, equality and preg_match
I encountered a problem where the result of a preg_match was FALSE.
This was fed into a switch statement - and I believe PHP executed the
the wrong case section.
I've tracked this down to preg_match not really returning FALSE
combined with SWITCH executing the first case statement always on either
a numeric 0 or BOOLEAN TRUE.
As a consequence of auto type conversion, you can't mix
STRING/NUMERIC/BOOLEAN within a switch. And with the preg_match issue,
you can't assume all input into your switch will be of one TYPE
(BOOLEAN).
Aside from changing functions to return real booleans
1. Should type conversion be turned off inside switch() ?
2. If 0 == FALSE then why 0 == ANYTHING ?
Chris
?
/* auto type conversion is the root of my switch problem */
if (0 == ONE) echo one\n; /* TRUE */
if (1 == TWO) echo two\n; /* FALSE */
if (TRUE == THREE) echo three\n; /* TRUE */
if (FALSE == FOUR) echo four\n; /* FALSE */
if (TRUE == 0) echo hopefully not\n;
function preg_false() {
return(preg_match(/no/, dXiuehXX));
}
/* note the difference between FALSE and preg_false() */
// $match = TRUE; /* prints alpha always */
// $match = 0; /* prints alpha always */
// $match = FALSE; /* prints gamma section */
$match = preg_false(); /* prints alpha always */
if(is_bool($match) == TRUE) echo match is boolean\n;
switch($match) {
case ALPHA:
echo hmm.. alpha\n;
break;
case BETA:
echo hmm.. beta\n;
break;
case 0:
echo hmm.. gamma\n;
break;
case TRUE:
echo hmm.. TRUE\n;
break;
case FALSE:
echo hmm.. FALSE\n;
break;
}
?
--
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] Re: Bug #11675 Updated: zzip_open() has a wrong arg count and doesn't validate arg2 correctly
I'll take a closer look at the docs tonight and make any necessary
corrections. I recently finished those docs and thought they reflected the
current version in cvs.
Daniel
- Original Message -
From: [EMAIL PROTECTED]
To: Bug Database [EMAIL PROTECTED]
Sent: Tuesday, June 26, 2001 9:55 AM
Subject: [PHP-DEV] Re: Bug #11675 Updated: zzip_open() has a wrong arg count
and doesn't validate arg2 correctly
My bug report was for 4.0.6. If it is corrected in cvs, fine. The
online documentation doesn't match 4.0.6 and I think you should at least
make note of it.
thanks
/Robin
On 26 Jun 2001, Bug Database wrote:
Date: 26 Jun 2001 14:44:18 -
From: Bug Database [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Bug #11675 Updated: zzip_open() has a wrong arg count and
doesn't validate arg2 correctly
ID: 11675
Updated by: danbeck
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: ZZiplib Related
Operating system:
PHP Version: 4.0.6
Assigned To:
Comments:
Please see the Zip section of the online manual for details:
http://php.net/manual/en/ref.zip.php
Previous Comments:
--
-
[2001-06-26 05:58:30] [EMAIL PROTECTED]
In the CVS the zziplib has been changed a bit:
@ Renamed the ZZiplib extension to the Zip extension, function
@ names have also changed accordingly, functionality, has stayed
@ constant. (Sterling)
zzip_open() is now zip_entry_open() and doesn't have this bug in it.
--Jani
--
-
[2001-06-25 16:14:31] [EMAIL PROTECTED]
Fix:
--- ../../php-4.0.6/ext/zziplib/zziplib.c Thu May 24 07:42:14 2001
+++ ext/zziplib/zziplib.c Mon Jun 25 14:31:59 2001
@@ -234,13 +234,13 @@
ZZIP_DIR *archive_p = NULL;
php_zzip_dirent *entry = NULL;
- if (ZEND_NUM_ARGS() != 2 ||
+ if (ZEND_NUM_ARGS() != 3 ||
zend_get_parameters_ex(3, zzip_dp, zzip_ent, mode) ==
FAILURE) {
WRONG_PARAM_COUNT;
}
ZEND_FETCH_RESOURCE(archive_p, ZZIP_DIR *, zzip_dp, -1, ZZIP
Directory, le_zzip_dir);
- ZEND_FETCH_RESOURCE(entry, php_zzip_dirent *, zzip_dp, -1, ZZIP
Entry, le_zzip_entry);
+ ZEND_FETCH_RESOURCE(entry, php_zzip_dirent *, zzip_ent, -1,
ZZIP Entry, le_zzip_entry);
entry-fp = zzip_file_open(archive_p, entry-dirent.d_name,
O_RDONLY|O_BINARY);
After this is fixed, the correct usage seems to be:
?php
$zzip = zzip_opendir(foo.zip);
if($zzip)
{
while ($zzip_entry = zzip_readdir($zzip))
{
echo zzip_entry_name: . zzip_entry_name($zzip_entry) . n;
echo zzip_entry_filesize: . zzip_entry_filesize($zzip_entry) .
n;
if(zzip_open($zzip, $zzip_entry, r))
{
$buf = zzip_read($zzip_entry, zzip_entry_filesize($zzip_entry));
zzip_close($zzip_entry);
echo read: . strlen($buf) . bytesn;
}
}
zzip_closedir($zzip);
}
?
--
-
[2001-06-25 16:09:44] [EMAIL PROTECTED]
See patch at: http://pfft.net/robin/pub/zzip.patch
Then, correct use seems to be:
$zzip = zzip_opendir(foo.zip);
if($zzip)
{
while ($zzip_entry = zzip_readdir($zzip))
{
echo zzip_entry_name: . zzip_entry_name($zzip_entry) . n;
echo zzip_entry_filesize: . zzip_entry_filesize($zzip_entry) .
n;
if(zzip_open($zzip, $zzip_entry, r))
{
$buf = zzip_read($zzip_entry, zzip_entry_filesize($zzip_entry));
zzip_close($zzip_entry);
echo read: . strlen($buf) . bytesn;
}
}
zzip_closedir($zzip);
}
--
-
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=11675edit=2
--
Robin Thellend [EMAIL PROTECTED]
PFFT! http://pfft.net
--
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: Bug #11675 Updated: zzip_open() has a wrong arg count and doesn't validate arg2 correctly
Hmm.. right after sending that last message, I realized what was going on.
The 4.0.6 version had been branched off the main trunk for quite some time
while it was going through the release process. During that time, Sterling
Hughes, the zip extension author, made a large number of changes and since
the documentation itself is very recent, it reflects the current state of
the Zip extension in cvs. (4.0.7-dev)
I will make a note in the docs that this extension is marked as
'EXPERIMENTAL' and that the current documentation is only good for 4.0.7 and
later. I apologize for the confusion, I should have noted this when I first
commited the docs to cvs.
BTW, you might be interested to know that the 4.0.6 incarnation of the
extension had a problem with segfaulting when reading multiple entries from
a zip file. Your mileage may vary.
Regards,
Daniel Beckham
- Original Message -
From: [EMAIL PROTECTED]
To: Bug Database [EMAIL PROTECTED]
Sent: Tuesday, June 26, 2001 9:55 AM
Subject: [PHP-DEV] Re: Bug #11675 Updated: zzip_open() has a wrong arg count
and doesn't validate arg2 correctly
My bug report was for 4.0.6. If it is corrected in cvs, fine. The
online documentation doesn't match 4.0.6 and I think you should at least
make note of it.
thanks
/Robin
On 26 Jun 2001, Bug Database wrote:
Date: 26 Jun 2001 14:44:18 -
From: Bug Database [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Bug #11675 Updated: zzip_open() has a wrong arg count and
doesn't validate arg2 correctly
ID: 11675
Updated by: danbeck
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: ZZiplib Related
Operating system:
PHP Version: 4.0.6
Assigned To:
Comments:
Please see the Zip section of the online manual for details:
http://php.net/manual/en/ref.zip.php
Previous Comments:
--
-
[2001-06-26 05:58:30] [EMAIL PROTECTED]
In the CVS the zziplib has been changed a bit:
@ Renamed the ZZiplib extension to the Zip extension, function
@ names have also changed accordingly, functionality, has stayed
@ constant. (Sterling)
zzip_open() is now zip_entry_open() and doesn't have this bug in it.
--Jani
--
-
[2001-06-25 16:14:31] [EMAIL PROTECTED]
Fix:
--- ../../php-4.0.6/ext/zziplib/zziplib.c Thu May 24 07:42:14 2001
+++ ext/zziplib/zziplib.c Mon Jun 25 14:31:59 2001
@@ -234,13 +234,13 @@
ZZIP_DIR *archive_p = NULL;
php_zzip_dirent *entry = NULL;
- if (ZEND_NUM_ARGS() != 2 ||
+ if (ZEND_NUM_ARGS() != 3 ||
zend_get_parameters_ex(3, zzip_dp, zzip_ent, mode) ==
FAILURE) {
WRONG_PARAM_COUNT;
}
ZEND_FETCH_RESOURCE(archive_p, ZZIP_DIR *, zzip_dp, -1, ZZIP
Directory, le_zzip_dir);
- ZEND_FETCH_RESOURCE(entry, php_zzip_dirent *, zzip_dp, -1, ZZIP
Entry, le_zzip_entry);
+ ZEND_FETCH_RESOURCE(entry, php_zzip_dirent *, zzip_ent, -1,
ZZIP Entry, le_zzip_entry);
entry-fp = zzip_file_open(archive_p, entry-dirent.d_name,
O_RDONLY|O_BINARY);
After this is fixed, the correct usage seems to be:
?php
$zzip = zzip_opendir(foo.zip);
if($zzip)
{
while ($zzip_entry = zzip_readdir($zzip))
{
echo zzip_entry_name: . zzip_entry_name($zzip_entry) . n;
echo zzip_entry_filesize: . zzip_entry_filesize($zzip_entry) .
n;
if(zzip_open($zzip, $zzip_entry, r))
{
$buf = zzip_read($zzip_entry, zzip_entry_filesize($zzip_entry));
zzip_close($zzip_entry);
echo read: . strlen($buf) . bytesn;
}
}
zzip_closedir($zzip);
}
?
--
-
[2001-06-25 16:09:44] [EMAIL PROTECTED]
See patch at: http://pfft.net/robin/pub/zzip.patch
Then, correct use seems to be:
$zzip = zzip_opendir(foo.zip);
if($zzip)
{
while ($zzip_entry = zzip_readdir($zzip))
{
echo zzip_entry_name: . zzip_entry_name($zzip_entry) . n;
echo zzip_entry_filesize: . zzip_entry_filesize($zzip_entry) .
n;
if(zzip_open($zzip, $zzip_entry, r))
{
$buf = zzip_read($zzip_entry, zzip_entry_filesize($zzip_entry));
zzip_close($zzip_entry);
echo read: . strlen($buf) . bytesn;
}
}
zzip_closedir($zzip);
}
--
-
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=11675edit=2
--
Robin Thellend [EMAIL PROTECTED]
PFFT! http://pfft.net
--
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
Re: [PHP-DEV] Bug #11611 Updated: nl2br() outputting invalid br tags
The point of this is... br / is complaint with existing html standards and the new xhtml standard. While br is *not* compliant with new XHTML standards. Why make the programmers go back and make changes for no reason? Or for reasons like It's pointless to output br / tags in HTML 4 code.? Daniel - Original Message - From: [EMAIL PROTECTED] To: Lenar Lõhmus [EMAIL PROTECTED] Cc: Matt McClanahan [EMAIL PROTECTED]; PHP Developers Mailing List [EMAIL PROTECTED] Sent: Sunday, June 24, 2001 4:13 PM Subject: Re: [PHP-DEV] Bug #11611 Updated: nl2br() outputting invalid br tags On Sun, 24 Jun 2001, [iso-8859-15] Lenar Lõhmus wrote: Yes, agree, but this change has happend not much time ago, and I think it's one's responsibility to maintain the behavior what it used to be. Even more if the old syntax was generating standard compliant code (and HTML4 is a standard). This syntax is perfectly html 4.01 (transistional) compliant. (Try requesting this link through validator.w3.org: http://defiant.jdimedia.nl:7480/php-hacking/php11611.php (only works during night hours in GMT) Still, we must evolve, so a syntax like nl2br(string text [boolean html4]) would give the most up to date behaviour of this function, giving somebody an option to get the old behaviour when it's really neccessary. It is never neccesary, unless Microsoft (or any other) wrote a browser that is not adhering to the standards. And ... you don't know a browser where br / dowsn't work? But there might be one ... one's own specific implementation where creator haven't thought up possibility that br might be br / one day. Since it is not neccessary for HTML to recognize / in the end of single tag then we can't really blame him. Browsers should ignore things which they don't recognise: (from http://www.w3.org/TR/1999/REC-html401-19991224/html40.txt, paragraph 7.2) Note. As of the 24 December version of HTML 4.01, the HTML Working Group commits to the following policy: * Any changes to future HTML 4 DTDs will not invalidate documents that conform to the DTDs of the present specification. The HTML Working Group reserves the right to correct known bugs. * Software conforming to the DTDs of the present specification may ignore features of future HTML 4 DTDs that it does not recognize. This was also the case with earlier versions of HTML. regards, Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - -- 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-DOC] Re: [PHP-DEV] Bug #11645 Updated: tempnam( ) does not use TMP environment variable
It's not so much that we can not go and view the open documentation bugs, but that due to the very tiny number of documenation bugs that are submitted, looking at it on a daily basis is a waste of time. I imagine that, the reason it hasn't happened yet is due to technical issues, but it's a very valid point. It would be best if the documenation bugs submitted were cc'ed to this list. Daniel - Original Message - From: Jani Taskinen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 24, 2001 7:19 PM Subject: [PHP-DOC] Re: [PHP-DEV] Bug #11645 Updated: tempnam( ) does not use TMP environment variable You don't have to follow php-dev to catch these, just point your browser to this URL: http://www.php.net/bugs.php?cmd=Display+Bugsstatus=Openbug_type=Documentat ion+problemby=Any --Jani On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote: This is documentation problem. = This brings me to another point, since not-so-long-ago there is a phpdoc/TODO file, and we would greatly appreciate it that an entry is added whenever there is a substantial change to PHP which should be documented. Of course, it'd even better if you instead update the docs yourself ;-). Updating the TODO will increase the likelyhood that the documentation will be updated soon. If you don't have Karma to phpdoc, get it, or simply mail [EMAIL PROTECTED] This also applies to documenation problems like this one. They should IMO at least be cross-posted to phpdoc@, so the phpdoc ppl don't need to follow phpdev. Jeroen -- 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 #11611 Updated: nl2br() outputting invalid br tags
The short of it is that in HTML 4, it doesn't matter if you have a br /,
BR, br, Br or bR, but in XHTML, you *must* have properly formed xml
tags. br / or br/br is the only way to validly write a "br" tag in
xml.
So.. if the nl2br did not output br / you would not be able to use nl2br
in XHTML pages. Instead of limiting the function to HTML 4 pages
only.. it's now usable for HTML 4 and XHTML.
Adding an optional flag would make everyone using XHTML have to change their
code for nothing, since it doesn't actually matter for HTML 4.
Sorry if that wasn't actually the "short of it". =)
Daniel
- Original Message -
From: "lenar" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, June 22, 2001 8:18 AM
Subject: Re: [PHP-DEV] Bug #11611 Updated: nl2br() outputting invalid br
tags
Shouldn't there be an optional flag to nl2br to change the behavior of
function to what it used to be.
Just there's no point in br / like tags when the rest of your code is just
generating HTML compliant output,
not XHTML.
Ok, somebody can always use something like str_replace("\n", "br", $text)
to get the old functionality.
lenar.
[EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
ID: 11611
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Bogus
Bug Type: Strings related
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Could this be even more bogus? :)
Previous Comments:
--
-
[2001-06-22 04:39:51] [EMAIL PROTECTED]
It's XHTML compliant
--
-
[2001-06-21 22:13:10] [EMAIL PROTECTED]
put this into a test php file:
?php
$temp = "this isnna testn";
printf("%s", nl2br($temp));
?
and you should get this as output from your webserver:
this isbr /
br /
a testbr /
I have confirmed this to be also an issue in the 4.0.6 release candidates,
but I do not know when this all of a sudden became an issue. I'd like to
know why it's creating br / tags instead of br tags :)
--
-
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=11611edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
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] List messages are being delayed?
Ah, thank you for the response. I was afraid it might have been something to do with my end. From what I can tell, you are hosting this on your own connection at home/work? Is there no one in the community that is willing to host the server for you guys? Daniel - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: phpdoc [EMAIL PROTECTED]; Bug Database [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 8:44 AM Subject: Re: [PHP-DEV] List messages are being delayed? For some reason, it seems that messages sent to the lists aren't being delivered for over 5 hours or more. I only just got a message that I sent today at 11:30AM. Although, they do show up on the news server pretty quickly. Is anyone else experiencing this? Sure, the lists will be somewhat slow. The bandwidth needed to deliver all these is right on the limit of what I can provide. At peak times the box falls behind, but then it catches up as things slow down. And sometimes I need the bandwidth and I will just unplug the list server for a while as my connection is pretty much useless when the box is plugged in. This is a temporary situation just to get the lists working again. An alternative will need to be found quickly. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] List messages are being delayed?
For some reason, it seems that messages sent to the lists aren't being delivered for over 5 hours or more. I only just got a message that I sent today at 11:30AM. Although, they do show up on the news server pretty quickly. Is anyone else experiencing this? Daniel -- 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] PATCH: support added for 'html_error' configuration setting in php.ini-dist
A co-worker of mine recently found an undocumented configuration setting in the php source that turns off the HTML tags in PHP error messages. If someone will commit this patch, I'll add it to the phpdoc tree also. Regards, Daniel Index: php.ini-dist === RCS file: /repository/php4/php.ini-dist,v retrieving revision 1.83 diff -u -r1.83 php.ini-dist --- php.ini-dist11 Jun 2001 15:43:50 - 1.83 +++ php.ini-dist19 Jun 2001 19:46:54 - @@ -234,6 +234,9 @@ ; Warn if the + operator is used with strings. warn_plus_overloading = Off +; Turn off HTML tags in error messages. +;html_errors = Off + ; ; Data Handling ; -- 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 #11075: bad operation of nl2br function
No, this does not break existing browsers. The problem is that nl2br has been around for a long time. Once you understand what nl2br does, you never need to view the function's documenation again. All the sudden, someone sees the br / output, they think bug! and report it. They never think to view the documentation again since it's such a trivial function. Personally, I think people should pay more attention to web standards... if they did, they would know it's XHTML. Daniel - Original Message - From: Brian Tanner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 24, 2001 4:02 AM Subject: RE: [PHP-DEV] Bug #11075: bad operation of nl2br function Ok, I've seen this bug reported too many times to sit idly by. :) The br / has the / so that the html is XHTML compliant. (if memory serves) My question -- is this breaking anything for anyone? Is br / in any way detrimental to browsers anywhere? Brian Tanner Project Manager Zaam Internet Solutions -- 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] Bug #11063 Updated: $var = function_returning_array(args)[0]; doesn't work
This syntax comes from using slices in Perl. It's a great feature, but as you say, unlikely to see the light of day in PHP. e.g. my ($user, $uid, $gid) = split(/:/, $line_from_passwd_file)[0,2,3]; Great feature. =) Daniel - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 23, 2001 4:33 PM Subject: [PHP-DEV] Bug #11063 Updated: $var = function_returning_array(args)[0]; doesn't work ID: 11063 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Suspended Old-Bug Type: Scripting Engine problem Bug Type: Feature/Change Request Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: This syntax does not make sense at all (to me). It is not present in any language AFAIK. A function simply returns an array, and if you want to do something with that, do it later. However, it is a valid feature request, but I don't think it wil be implemented in short time. Changed type to Feature Request and status to Suspended. Derick Previous Comments: -- - [2001-05-23 16:35:48] [EMAIL PROTECTED] $var = function_returning_array(args)[0]; gives an error but $var = function_returning_array(args); $var=$var[0]; works fine. I think that either should work. -- - ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11063edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- 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 #11008 Updated: exit() should return an exit status if passed, not send to stdout
Can we go ahead and change this behavior then? Is there really a reason to echo the status to standard out? Daniel - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 21, 2001 6:59 PM Subject: [PHP-DEV] Bug #11008 Updated: exit() should return an exit status if passed, not send to stdout ID: 11008 Updated by: bbonev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating system: PHP Version: 4.0 Latest CVS (2001-05-21) Assigned To: Comments: indeed it does both: if php; then echo yes; fi ? exit(0) ? X-Powered-By: PHP/4.0.5 Content-type: text/html 0yes if php; then echo yes; fi ? exit(1) ? X-Powered-By: PHP/4.0.5 Content-type: text/html 1 i don't see a real reason for the echoed exit status though Previous Comments: -- - [2001-05-21 21:34:23] [EMAIL PROTECTED] Working with a shell script here. I hoped that exit() would work like perl and return the passed status as and exist status. As it stands now, it sends it to stdout. This is unexpected. It would be much more useful if exit() could be used to enable the use of PHP in shell scripts by returning the passed value as an exit status. -- - ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11008edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- 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 #9859 Updated: mail() doesn't send cc or bcc as in the manual instructions
Does it even need to force you to use one over the other? Can it not simply
accept both forms?
Daniel
- Original Message -
From: [EMAIL PROTECTED]
To: Bug Database [EMAIL PROTECTED]
Sent: Monday, May 21, 2001 3:28 AM
Subject: [PHP-DEV] Re: Bug #9859 Updated: mail() doesn't send cc or bcc as
in the manual instructions
Whichever is decided, \r\n or just \n, it should be uniform across
platforms so you don't have to re-write code when switching from linux to
windows or vice versa.
Or even from the cgi version to the isapi version.
[EMAIL PROTECTED]
At 03:06 AM 5/21/01 +, you wrote:
ID: 9859
Updated by: danbeck
Reported By: [EMAIL PROTECTED]
Status: Open
Old-Bug Type: Documentation problem
Bug Type: Mail related
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
I've corrected the Cc: and Bcc: problems in the mail() example, but I'm
reclassifying this as a Mail Function problem. Is it necessary for the
win32 version of the mail() function to require that you use \r\n?
If it is, I can add this information to the mail function docs.
Previous Comments:
---
[2001-03-20 02:42:22] [EMAIL PROTECTED]
script example:
---
--
?php
$returnvar=false;
$mailto=[EMAIL PROTECTED];
$mailsubject=cc test;
$mailmessage=message content;
$mailHeader=cc:[EMAIL PROTECTED];
$returnvar=mail($mailto,$mailsubject,$mailmessage,$mailHeader);
?
html
body
the mail was sent?
?php
echo brreturnvar= $returnvarbr;
?
/body
/html
---
--
The above does not send the carbon copy.
The pdf manual says:
---
---
$headers .= cc:[EMAIL PROTECTED]; // CC to
$headers .= bcc:[EMAIL PROTECTED], [EMAIL PROTECTED]; // BCCs
to
/* and now mail it */
mail($recipient, $subject, $message, $headers);
---
That does not work since Win32 sendmail.c looks for case sensitve Cc:
sendmail.c also does not look for bcc:
Also you must have rn not just n.
I think the problem is here in win32 sendmail.c :
if (headers (pos1 = strstr(headers, Cc:))) {
pos2 = strstr(pos1, rn);
tempMailTo = estrndup(pos1, pos2-pos1);
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=9859edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
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] Extention development in Perl
For People who Hate Perl, they it sure have attempted to emulate a lot of features and functions available to Perl programmers. Of course, most of Perl's features are stolen from bash, awk, sed, etc. =) Daniel - Original Message - From: "Hartmut Holzgraefe" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 12, 2001 3:27 AM Subject: Re: [PHP-DEV] Extention development in Perl Stig Sther Bakken wrote: ["Pieter Claassen" [EMAIL PROTECTED]] Is it possible to write PHP extentions in Perl [...] Why on earth would you want to do something like that? Why on earth woudl someone want to use COM or JAVA with PHP or even use PHP as a Java Servlet? I (although i do not like PERL personally) think this is just as valid. On the other hand i heard that PHP stands for "People Hate Perl" though ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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] Mailing List Suggestion
The subject lines of this mailing list are extremely long, mostly due to the bug reporting system. Is it really necessary to say PHP twice in the subject line? Also, I can't remember the last time I've seen a 3.0 Bug show up, so is it even necessary to give the version number? For that matter, if we see a bug number like #9098, can't we safely assume that it's Bug #9098 and not have to see "Bug" on the subject line? Possible alternatives to what is being used now are: [PHP-DEV] Bug #885 Updated: blah blah blah [PHP-DEV] Bug #885 U: blah blah blah [PHP-DEV] #885 U: blah blah blah [PHP-DEV] 4.0 #885 U: blah blah blah My point here is that the useful information in the subject is usually at the very end and often not seen in GUI email clients. Daniel -- 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] Suggestion for bug system
For the love of all things sane and normal, please don't model it after bugzilla. *shudder* Daniel - Original Message - From: "August Zajonc" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, April 08, 2001 12:52 PM Subject: Re: [PHP-DEV] Suggestion for bug system What about leveraging an existing bug system? There is Alexandria over at sourceforge which looks like it is still in development, and by enhancing it projects at sourceforge may also benefit. It sometimes seems that some of the best aspects of open source are not taken advantage of. A ton of systems get developed, but do not continue to evolve over the years... Good luck either way... -- 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 4.0 Bug #9940: php cgi crashes when using ob_start callback function
It appears that my bug report is a duplicate of 9805, but mine does include
a backtrace.
Daniel
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, March 22, 2001 2:51 PM
Subject: [PHP-DEV] PHP 4.0 Bug #9940: php cgi crashes when using ob_start
callback function
From: [EMAIL PROTECTED]
Operating system: linux 2.2.16
PHP version: 4.0 Latest CVS (22/03/2001)
PHP Bug Type: Reproduceable crash
Bug description: php cgi crashes when using ob_start callback function
The following script causes php to segfault when run in CGI mode. The
segfaults do not happen if you remove the output callback function parameter
of ob_start(). Please note that this does not happen when using
php4.0.4pl1.
#!/usr/local/bin/php -qe
?
function compress_output ($output) {
return($output);
}
ob_start("compress_output");
echo "test\n";
?
Here is a backtrace of the core file.
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
warning: core file may not match specified executable file.
Core was generated by `php4 -qe ./test.php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libpam.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /usr/lib/libz.so.1...done.
Reading symbols from /usr/lib/mysql/libmysqlclient.so.10...done.
Reading symbols from /usr/local/lib/libpng.so.2...done.
Reading symbols from /usr/lib/libbz2.so.1.0...done.
Reading symbols from /lib/libresolv.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
#0 chunk_free (ar_ptr=0x819ebd0, p=0x81d6020) at malloc.c:2985
2985malloc.c: No such file or directory.
(gdb) bt
#0 chunk_free (ar_ptr=0x819ebd0, p=0x81d6020) at malloc.c:2985
#1 0x40156d75 in __libc_free (mem=0x81d6028) at malloc.c:2959
#2 0x80e31f0 in _efree (ptr=0x81d604c, __zend_filename=0x814612f
"output.c", __zend_lineno=227,
__zend_orig_filename=0x0, __zend_orig_lineno=0) at zend_alloc.c:238
#3 0x80cdacc in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0
'\000') at output.c:227
#4 0x80cdb5f in php_end_ob_buffers (send_buffer=1 '\001') at output.c:250
#5 0x8060db7 in php_request_shutdown (dummy=0x0) at main.c:643
#6 0x805fc01 in main (argc=3, argv=0xbb24) at cgi_main.c:763
--
Edit Bug report at: http://bugs.php.net/?id=9940edit=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]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9794: array_keys resets the array pointer and can not be used when looping
Awesome. Are you planning to just fix the array_keys function, or will
there be a change as to how the array functions work with the array
pointers?
Thanks,
Daniel Beckham
- Original Message -
From: "Andrei Zmievski" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, March 16, 2001 11:18 AM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #9794: array_keys resets the array
pointer and can not be used when looping
I'll fix this problem soon. It's even in the TODO.
On Fri, 16 Mar 2001, [EMAIL PROTECTED] wrote:
From: [EMAIL PROTECTED]
Operating system: linux 2.2.16
PHP version: 4.0.4pl1
PHP Bug Type: Scripting Engine problem
Bug description: array_keys resets the array pointer and can not be
used when looping
The following code is broken:
$arr = array("a", "b", "c");
foreach ($arr as $a) {
echo "$aBR\n";
echo max(array_keys($arr));
}
It stops after the first array element because array_keys resets the
array pointer. (Or at least it's moved to the end...)
This is sort of a (repectful) complaint that I have about PHP and they
way it's been written. Arrays are systematically prostituted by the array
functions because each one of them sees fit to reset the array pointer
instead of just working off of a copy, or at the very least, returning the
array pointer to it's previous state.
Is there some reason that the array pointer can't be returned to it's
previous state after the array functions are finished with it?
--
Edit Bug report at: http://bugs.php.net/?id=9794edit=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]
-Andrei
* If Bill Gates had a nickel for every time Windows crashed.. Oh, wait.. *
--
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]
