RE: [PHP-DEV] Possible problem in the parser
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 13 March 2003 19:33 To: Ford, Mike [LSS] Cc: 'Andrey Hristov'; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] Possible problem in the parser At 14:58 13.03.2003, Ford, Mike [LSS] wrote: Just to make this completely clear, in left-associative PHP b = a==1? 4:a==2? 5:6; is equivalent to b = (a==1? 4:a==2)? 5:6; NO it is not equal. Either '==' has higher precedence OR '?:' has. See one of my previous mails where i showed where the error is. Yes, it is -- believe me, I've researched this extensively. It is NOT about precedence, but associativity. If you want me to be totally completist about this: Starting from: b = a==1? 4:a==2? 5:6; precedence rules make this equivalent to: b = (a==1)? 4:(a==2)? 5:6; but this is still ambiguous -- which ?: phrase do you evaluate first? Associativity provides the answer: in PHP, where ?: is left associative (i.e. the left most ?: is evaluated first), the result is equivalent to: b = ((a==1)? 4:(a==2))? 5:6; On the other hand, in c, where ?: is right associative, the equivalent is: b = (a==1)? 4:((a==2)? 5:6); which, apart from the additional (unnecessary) parentheses around the == comparisons, is exactly what I said before. QED Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Possible problem in the parser
-Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED] Sent: 14 March 2003 14:50 You are right that it doesn't behave the same as C. However, personally although it might have been better for it to work like C I don't think it's a good idea to change it now. First of all it would break backwards compatibility in a way which would be hard for people to find where the bug is and how to fix it. Secondly, not meaning to insult anyone here, but I think people who write such code without using parentheses should improve their coding style :) Oh, I totally agree. My original response was to a query as to whether the PHP behaviour was a bug -- so I simply pointed out (in some detail!) that, although different from c, it *did* conform to the precedence and associativity documented in the PHP manual. Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Possible problem in the parser
-Original Message- From: Andrey Hristov [mailto:[EMAIL PROTECTED] Sent: 12 March 2003 17:26 On Wed, 12 Mar 2003, Andrey Hristov wrote: Few minutes ago I found the following behaviour somehow wierd for me : Known bug, the associativity of the ternary operator has been broken since ages in the engine. It's on the won't be fixed sheet, because of BC concerns. That's a bit hard -- it's different from c, certainly (left associative instead of right), but that's a valid choice (even if it was originally accidental!) and calling it broken is a bit harsh. Is it documented somewhere? Yes -- at http://www.php.net/manual/en/language.operators.php#language.operators.prece dence). Just to make this completely clear, in left-associative PHP b = a==1? 4:a==2? 5:6; is equivalent to b = (a==1? 4:a==2)? 5:6; yielding 5 if a==1 or a==2, else 6. But in right-associative c, it's equivalent to: b = a==1? 4:(a==2? 5:6); yielding 4 if a==1, 5 if a==2, else 6. Since this *is* documented behaviour, I don't see how it can be called particularly unexpected. (Weird, maybe, if you're used to the c behaviour, but not unexpected!) Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mssql.convertdatetime, mssql.longdatetime
Jochen Daum wrote: Hi ! I need to fetch a datetime column from sql server with milliseconds. Someone posted a patch a while ago: Doesn't look like that patch made it, but a ton of work has been done on that file since. How do I find out, if this patch has been incorporated into Version 4.3? http://cvs.php.net/co.php/php4/ext/mssql/php_mssql.c?login=2r=1.107 Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Jumadi
You could charge $100 per php licence too. :P Regards Mike Robinson Jani Taskinen wrote: Just make this one moderated. (but allow anyone with CVS access to post freely :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: str_ireplace vs. stri_replace
Jon Parise writes: Get rid of stri_replace() and/or str_ireplace() and just add a fourth optional parameter to str_replace() to control case-sensitivity. Yup. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: mgf
Occasional contributions to documentation; responding to / closing bug reports when I can. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?
Rasmus Lerdorf wrote: Perception and warm fuzzies is an extremely important part of a large open source project that relies heavily on a large number of volunteers. Messing with that is playing with fire. You've hit it bang on. [noise] The clinical name for the 'fire' in this case is cycle of alienation, and in any environment that relies on volunteers, this 'cycle' is almost impossible to avoid. I've been amazed over the 4+ years since I jumped onto the list how well this group has been able to circumvent the problems that normally plague projects of this size and scope. FWIW, the number one cause of the cycle is information sharing amongst a smaller subgroup formed from the main group, usually without their knowledge. In most cases, the result is fatal. The few groups I've seen actually emerge from an active cycle are irreparably damaged. [/noise] Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: sprintf)
-Original Message- From: Derick Rethans [mailto:[EMAIL PROTECTED]] Sent: 15 January 2003 15:17 To: [EMAIL PROTECTED] Cc: PHP Quality Assurance Team Mailing List; PHP Developers Mailing List Subject: [PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: sprintf) On 15 Jan 2003 [EMAIL PROTECTED] wrote: Why has this bug been marked as Bogus when it's a Duplicate? It seems to be increasingly common for this to happen -- when did it become standard policy to set duplicate report to Bogus? Two exactly the same bugs were posted one minute after eachother from persons on the same domain. (Grits teeth) But it's still a duplicate report! It was in this case. And even if it is policy to set duplicate report to Bogus, that policy should be prominently documented, so that people don't get in a huff about bugs being dismissed as not a bug when their duplicate report is set to Bogus (which has happened more than once already!). People who dont understand the implicit meaning of the statii shouldn't touch the reports in the bug system. I'll write them down again: I'm not talking about touching them in the bug system, I'm talking about understanding them as a bog standard user. bogus: submitted twice after each other, or by the same person on the same topic; it's not a bug, but a support question. The reason should always be noted in the comments That's very confusing - there's really two different stauses in that definition, which I think is the crux of the problem. The first definition really needs a new status such as Repeat, which is otherwise treated like Bogus. But this definition is interesting, because I think some responders are not respecting the by the same person part. dupli: almost the same bug, both bugs are found 'duplicate' later on and have both useful information Yes, fair enough. I just get the feeling that, lately, the balance has tipped too far towards labelling repeat reports Bogus -- personally, I think responders should be a little less Bogus-happy, and err on the side of Duplicatifying if there's any doubt in the matter. Also, when marking a repeat as Bogus, not calling it a duplicate in the explanation would be useful -- saying something more like repeat of #xxx or Identical to #xxx would be better. verif: a member of the QA has verified the bug to be a real one analy: the cause of the bug is known, or a solution is known for it but not yet implemented assig: don't touch this one, somebody is working on this. open: just submitted, or nobody knows what to do with it (after feedback) feedb: Waiting for more feedback from the user suspe: at some point in the future we'll look at it again, currently we are waiting on an external thing to be fixed first close: the bug has been solved (fixed in cvs) wontf: we are not going to fix this issue because criti: critical bug, should be fixed ASAP no fe: No feedback from the user was added since we asked it two weeks ago H'mmm, interesting -- I don't think I've ever seen that list before -- certainly not linked from anywhere obvious such as http://bugs.php.net/, or http://bugs.php.net/search.php. Perhaps a what happens to bug reports sort of link would be useful on the bugs front page, to complement How to report a bug? Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP4 + PHP5
From: James Cox wrote: Mike Robinson [EMAIL PROTECTED] wrote: I'm wondering if it will be possible to build and use both PHP4 and PHP5 as apache modules on the same webserver, similar to the way we could use both PHP3 and PHP4. [snip] the patch for naming everything php5 and not php4 is done, i am just finishing the patch to enable versioning properly. Excellent. Way to go James. This'll be so handy. I was a little concerned about the application-type directives in httpd.conf and how that would work. I'm assuming PHP5 will use _only_ ZE2 once it's forked? Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP4 + PHP5
Hiya, I'm wondering if it will be possible to build and use both PHP4 and PHP5 as apache modules on the same webserver, similar to the way we could use both PHP3 and PHP4. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] size of session vars
-Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: 10 January 2003 11:11 Lately, when people start asking php-general questions on php-dev people give them the answer and add but you should have asked on the php-general list. Having received a good answer from php-dev gives them incentive to mail us again :) I suggest we keep to the standard polite reply that they should please mail php-general without giving them the answers. If you really, really want to be helpful and give an answer, couldn't you CC php-general into the standard polite reply, and then go answer that when it shows up? Or maybe the standard protocol for the standard polite reply should be to CC it to php-general? Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] ZE2 + php 4.4.0
Tularis wrote: btw, has anyone tested this combo with mysql 4 yet? Yup, mysql-4.0.7-gamma. Works fine for me, except phpMyAdmin has some minir problems that I haven't bothered tracking down yet. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Happy New Year!
To All, Congratulations to all of you on a fine year for PHP, and continued success in the future. Peace to you and yours, and a Happy New Year. :) Best Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP Look Back 2002
Derick Rethans wrote: We are almost at the end of 2002, and it seemed appropriate to look back on the development issues of the past year. So starts the first PHP Look Back! You can find it @ http://www.derickrethans.nl/20021230.php, and if you have any comments,feel free to post them with the link at the bottom of the page. Awesome and classy. Much like your contribution to PHP. Thanks, and all the best to you in '03. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] option to start in PHP mode
Andrei Zmievski wrote: We've talked about this in the past, but let's bring it up again. It is a bit awkward to use CLI when it requires those ?php and ? tags. We should probably have a command-line option that tells the parser to start in PHP mode instead of HTML/text. Any thoughts on this? FWIW, almost without fail every time I write a new CLI script I forget to put the start/stop tags in and I get an error the first time I run it. So from an 'intuitive' point of view, [ and notwithstanding the value of my opinion :P ], the switch sounds like a good idea to me. Best Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.3.0 released
Sander Steffann writes: Hi All, There is a weird line in here too: * PHP Manual: Using PHP from the command line http://www.php.net/manual/en/features.commandline.php It's this one: By default when executing make, both the CGI and CLI are built and placed as sapi/cgi/php and sapi/cgi/php respectfully The second path is wrong, and respectfully should be respectively. Shouldn't that be 'sapi/cgi/php and sapi/cli/php respectively'? ^^^ Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.3.0 released
Ari Pollak wrote: On Fri, Dec 27, 2002 at 07:41:50PM -0500, Mike Robinson wrote: Shouldn't that be 'sapi/cgi/php and sapi/cli/php respectively'? The second path is wrong, and respectfully should be respectively. Duh. I guess I should lay off the egg nog eh? :P Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe Mode Off
You don't... for that would be a profoundly stupid feature, defeating the point of safe mode. And I suspect [EMAIL PROTECTED] would be a better place for this question --- Original Message --- From:Shashwat Nagpal [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date:Sat, 21 Dec 2002 14:37:58 +0530 Subject: [PHP-DEV] Safe Mode Off how can i turn safe_mode on or off from within the script... -- 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] T_PAAMAYIM_NEKUDOTAYIM
Just so you know, not so long ago a google search for T_PAAMAYIM_NEKUDOTAYIM used to turn up just 1 matching result. :P Regards Mike Robinson Pierre-Alain Joye wrote: On Tue, 17 Dec 2002 00:17:47 +0100 Pierre-Alain Joye [EMAIL PROTECTED] wrote: On Mon, 16 Dec 2002 23:56:03 +0100 Bertrand Mansion [EMAIL PROTECTED] wrote: will return 'Undefined variable: this'... The syntax foo::bar() should be used for every method callable directly(ex: a factory), without an instance of the parent object. ^^ without an instance of the object itself. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: #20972 [Opn-Csd]: make fails during gd.c
Ilia A. wrote: This is a different bug (xpm) caused by a bug in the external GD library, this particular bug has been solved in the CVS. Unless you've patched your GD with gif write support you have nothing to gain from not using the bundled library, which offers more functionality and is more stable. The problem with free/gd_free is likely due to you having 2 sets of the GD library on your computer. This confuses the check, because the headers do not correspond with the library itself. Is the xpm fix going to make it into 4.3 then? Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
-Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: 11 December 2002 12:15 Guys, fact is that it doesn't matter that much what this binary is called. We can call it bhb for all practical purposes (not that I'm suggesting that). People will get used to whatever it's named. If it were me (which, of course, it isn't, but...), I'd leave the cgi as php and call the command-line version phpc. (Well, actually, if it were *just* me, I'd leave them both as php -- even on Windows -- and just make sure I had them in appropriate directories, but I'm extremely aware that real-world users are often not up to that kind of subtlety.) What I absolutely would *not* do is rename the cgi version to php-cgi whilst *simultaneously* introducing a new php with a different purpose. If I were going to do this, I'd want to do it in steps: 1 - cgi to php-cgi + introduce php-cli (so any installations still looking for php get a straight file not found); 2 - php-cli to php. As I'm pretty sure this isn't going to fly, let's go back to my first para...!! Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PHP-QA] Test results (fwd)
There are other problems with gd, specifically with the xpm stuff. RC3 barfs compiling against external gd libs. Incorporating the changes found in: http://cvs.php.net/co.php/php4/ext/gd/php_gd.h?login=2r=1.49 and http://cvs.php.net/co.php/php4/ext/gd/gd.c?login=2r=1.239 fixes the problem, which didn't occur in RC2. Regards Mike Robinson Marcus Börger writes: When you use gd and jpeg configure.m4 from gd will check first for existance of the library file and second for one of its functions. So i guess there is somethink wrong with the #ifdefs in gd.c or in generating them in config.m4. This is all i can say now but perhaps i can take a look into it tomorrow.after sleeping :-) This is you rline: checking for jpeg_read_header in -ljpeg... yes -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Wez Furlong writes: On Sun, 8 Dec 2002, Mike Robinson wrote: Sorry. There's just no way this should happen. But it has happened, and it's going stay this way. Now, if you don't have anything positive to contribute, please stop stirring up threads like this (again) without first understanding the issues behind them. It just wastes time, which is better spent developing, bug fixing, documenting - doing just about anything else is more productive. You are correct in your assumption that I have difficulty understanding the issues behind this change. After asking several times for an explanation, and after having gone over the archives to find some related discussion (and asking for pointers to that as well), I came to conclusion that this change is totally wrong. This change has nothing to do with fixing anything. It's breaking BC in a huge way, at the historical level, for the sake of a minor convenience for a very small group of users. Throwing lame excuses at it, like it's evolution, doesn't cut it with me. I'm still at the same place. This is just wrong. It has nothing to do with stirring anything up. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Marcus Börger wrote: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. Well no offence, but renaming the CGI executable is just plain wrong. The CLI executable should be named php-cli.exe. This seems like such a nobrainer. Am I missing something? Clue me in. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Christoph Grottolo wrote: It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). This is the way it should stay. I'm trying to find the archive of the discussion that lead to this being changed. I'm having a huge problem getting my head around why the name of the CGI executable has to be changed at all. Any pointers or enlightenment would be welcomed. :) Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Marcus Börger wrote: At 22:08 08.12.2002, Mike Robinson wrote: Christoph Grottolo wrote: It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). This is the way it should stay. I'm trying to find the archive of the discussion that lead to this being changed. I'm having a huge problem getting my head around why the name of the CGI executable has to be changed at all. Any pointers or enlightenment would be welcomed. :) Regards Mike Robinson Just because you only need to type the name of the CGI sapi once: In other word one single time until we decide the name changes. But you will use a command line interface hopefully very often. I for one do and i am not going to type php-cli.exe because it is way much to long. Every system on the planet that uses php.exe as their CGI executable, and I suggest there are quite a few, will have a broken setup with a stock install of php-4.3.0, because typing php-cli.exe at the command line is too long. And you expect putting huge notes and warnings in the news file and installer will prevent this from happening. The reason against renaming CGI and using its old name for the CLI now would have lead us to register_globals=ON for eternity. Totally different. Apples and oranges. That was a security-related change, and IMHO, the amount of trouble _that_ change caused far outweighed the meagre benefits achieved. This change is going to break a lot of setups for the sake of cli users saving a few keystrokes. Sorry. There's just no way this should happen. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false
Marcus Börger wrote: From my point of view accessing a file should result in an error if the file cannot be opened or in case of GetImageSize() a file operation cannot be executed. For example i would expect GetImageSize() to show an error if the information cannot be retrieved due to file corruptions. I agree. Absolutely. Masking bona fide file operation errors would be a huge mistake, IMHO. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Redirect on Error
Sterling Hughes writes: you're missing alot. Its not inbox size, when you get multi-lingual error messages you have more than one problem. 1) Support. [snip] 2) Implementation. [snip] 3) Everything else is in english. [snip] There are other problems too, but these are the biggies. Can't imagine what this'll do to the workload for the QA folks. I can appreciate the motive for multi-language error messages, but its asking for trouble on a huge scale. If english is good enough for programmers and air traffic controllers all over the world, its good enough for PHP error messages. :) These things should really come about via necessity. I very rarely see the question how can i catch parse errors on my production site, if you really need, you can turn off display_errors, and that should do it. Yup. When used with the logging stuff [syslog,logfile], it works quite well. The fact is, you shouldn't be needing code to catch a parse error, if you do, there is something wrong with the way you program, not with php. Bingo. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
In Real Life [Patent Pending], if you cripple your production site in the middle of the night then go to bed, you won't have to worry about any of this because you'd be unemployed in the morning. I agree with Derick's assessment. I always have the option of turning display errors off (which is the recommendation for production sites) and cranking stuff out to syslog or some file I can monitor. Throwing a 500 document is ugly, and so 90's. :) Being competitive does not mean 'being like the other guys', a path PHP has carefully and rightfully avoided. Regards Mike Robinson Ivan Ristic writes: Edin Kadribasic wrote: On Thursday 21 November 2002 08:04, Derick Rethans wrote: I still think that an included file just should fail hard and I just dont like this kind of obfucsication. I agree with this 100%. It is IMHO a complete waste of time trying to handle parse errors gracefully. Most solutions proposed in this thread are either server specific or would have an impact on normal php operation (would require output buffering, etc.). And in the real life you sometimes must change things live on the server, in the middle of the night. If you make a mistake then, and we all do, you will go to sleep without realising that the app/web site no longer works properly. I use logwatch for this at the moment, but that is, IMHO, a very, very, clumsy solution. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Mailparse extension
Is this going to be production stable in 4.3.0? Cheers, Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Just a little question
-Original Message-
From: Hacook [mailto:[EMAIL PROTECTED]]
Sent: 19 November 2002 09:48
I have a chain charachter that look like this :
*text*text*text*text*textetc
I would like to cut off the FIRST star but not the others
My chain is REALLY long.
I made that script :
$maxi=strlen($resultats)-2;
$nb = 0;
while ($nb=$maxi) {
$results2 = $results2.$results[1+$nb];
$nb = $nb+1;
}
where $results is the chain
It works perfectly but it takes over 5 minutes !
Do you have any idea on how to make it faster ?
(a) wrong list -- you want [EMAIL PROTECTED]
(b) $results2 = substr($results, 1);
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] 4.2.3 mbstring patch?
-Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: 19 November 2002 10:19 Andrei Zmievski wrote: On Thu, 14 Nov 2002, lowbwtom wrote: Will there be a patch to fix the mbstring bug in 4.2.3? Any idea when? (specifically to fix the missing 4 characters in array posts) (BTW, I don't use array, since [] are illegal chars) Uh -- is this referring to form element name= attributes? Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory persistence with apache question
Unfortunately I can't ask my clients to upgrade to a CVS version - v1.3.2 isn't available yet :-( But more generally wouldn't it be nice if PHP could GUARANTEE that memory resources are recovered on script termination ? Lot's of scripts are written without proper consideration for memory - and ISPs suffer because of it. I use apache that forks children so I can sidestep the issue with MaxRequestsPerChild (at a performance hit for other clients)... What it I was using a threading model in apache 2.0 ? Mike On Mon, 2002-11-18 at 22:52, Marcus Börger wrote: Problems that could arise: The sytem tries to open images and does not unset the variables...and such. I guess when everything is working you cannot do anything against. If you want to investigate more you would need a debug version from php to verify if all memory is freed. But this is the post from the developer who is assigned to the bug on Sourceforge: Date: 2002-10-23 17:59 Sender: bharat Logged In: YES user_id=42211 This is fixed in v1.3.2 marcus At 04:33 19.11.2002, Mike Leddy wrote: Hello, I administer a linux 2.4.19/apache 1.3.26/php 4.1.2 server in an ISP. Recently some clients started using a gallery php script: http://gallery.sf.net that causes excessive memory utilization on the server: http://sourceforge.net/tracker/index.php?func=detailaid=498028group_id=7130atid=107130 So here goes the question: In what situations will memory allocated to a script remain with the apache process after the script has terminated ? I always thought that memory allocated would be released on script termination - Am I wrong in this assumption ? Could it be that the heap in the apache process stays at the maximally used level ? Thanks for any pointers or how I should approach resolving this problem. (I am already using 'MaxRequestsPerChild 5' in apache as a stopgap measure) Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- Atenciosamente Mike Leddy, Systems Administrator, Braslink Network Inc., Miami, FL. Tel +1 305 279 3232 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Memory persistence with apache question
Hello, I administer a linux 2.4.19/apache 1.3.26/php 4.1.2 server in an ISP. Recently some clients started using a gallery php script: http://gallery.sf.net that causes excessive memory utilization on the server: http://sourceforge.net/tracker/index.php?func=detailaid=498028group_id=7130atid=107130 So here goes the question: In what situations will memory allocated to a script remain with the apache process after the script has terminated ? I always thought that memory allocated would be released on script termination - Am I wrong in this assumption ? Could it be that the heap in the apache process stays at the maximally used level ? Thanks for any pointers or how I should approach resolving this problem. (I am already using 'MaxRequestsPerChild 5' in apache as a stopgap measure) Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] GD 2.0.6 make errors
Its up to 2.0.6 now. :) Boutell has gone GD crazy all of a sudden. Regards Mike Robinson -Original Message- From: Pierre-Alain Joye [mailto:paj;pearfr.org] Sent: Thursday, November 14, 2002 11:55 AM To: Clay Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] GD 2.0.6 make errors On Thu, 14 Nov 2002 11:51:30 -0500 Clay [EMAIL PROTECTED] wrote: Gcc 3.2 Solaris 9 2.0.1 works fine. Any ideas? Anyone compile 2.0.6 yet on any platform? do you mean 2.04 official gd ? pa -- 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] GD 2.0.6 make errors
Jani Taskinen writes:
This was actually fixed long time ago in CVS..
I use 2.0.4 with the gif stuff hacked in, and current CVS from
about 5 minutes ago segfaults when using the gif stuff. Might be
a problem with the gd lib I'm using... backtrace as follows
(couldn't get a core file).
Regards
Mike Robinson
Starting program: /usr/local/apache/bin/httpd -X
Program received signal SIGSEGV, Segmentation fault.
0x40599842 in compress (init_bits=3, outfile=0x81614fc, im=0x8166c00) at
gd_lzw_out.c:534
534 if ( HashTabOf (i) == fcode ) {
(gdb) bt
#0 0x40599842 in compress (init_bits=3, outfile=0x81614fc,
im=0x8166c00) at gd_lzw_out.c:534
#1 0x405996c5 in GIFEncode (fp=0x81614fc, GWidth=365, GHeight=599,
GInterlace=0, Background=0,
Transparent=-1, BitsPerPixel=1, Red=0x8166c10, Green=0x8167010,
Blue=0x8167410, im=0x8166c00)
at gd_lzw_out.c:349
#2 0x40599139 in gdImageLzwCtx (im=0x8166c00, out=0x81614fc) at
gd_lzw_out.c:67
#3 0x4059807b in gdImageGifCtx (im=0x8166c00, out=0x81614fc) at
gd_gif_out.c:23
#4 0x4014d413 in _php_image_output_ctx (ht=1, return_value=0x81612dc,
this_ptr=0x0, return_value_used=0,
image_type=1, tn=0x402c77de GIF, func_p=0x4059805a
gdImageGifCtx)
at /usr/local/src/phpcvs/php4/ext/gd/gd_ctx.c:98
#5 0x40150987 in zif_imagegif (ht=1, return_value=0x81612dc,
this_ptr=0x0, return_value_used=0)
at /usr/local/src/phpcvs/php4/ext/gd/gd.c:1642
#6 0x4023e336 in execute (op_array=0x81512e4) at
/usr/local/src/phpcvs/php4/Zend/zend_execute.c:1595
#7 0x40231c15 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/src/phpcvs/php4/Zend/zend.c:840
#8 0x4020d20c in php_execute_script (primary_file=0xb6c0) at
/usr/local/src/phpcvs/php4/main/main.c:1560
#9 0x40241efe in apache_php_module_main (r=0x8144f1c,
display_source_mode=0)
at /usr/local/src/phpcvs/php4/sapi/apache/sapi_apache.c:55
#10 0x402428c5 in send_php (r=0x8144f1c, display_source_mode=0,
filename=0x0)
at /usr/local/src/phpcvs/php4/sapi/apache/mod_php4.c:556
#11 0x40242a5a in send_parsed_php (r=0x8144f1c) at
/usr/local/src/phpcvs/php4/sapi/apache/mod_php4.c:571
#12 0x080542c0 in ap_invoke_handler ()
#13 0x0806876a in process_request_internal ()
#14 0x080687ca in ap_process_request ()
#15 0x0805fb8e in child_main ()
#16 0x0805fd54 in make_child ()
#17 0x0805febb in startup_children ()
#18 0x080604e8 in standalone_main ()
#19 0x08060d20 in main ()
#20 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] GD 2.0.6 make errors
Derick Rethans wrote: It clearly crashes in the gid stuff... most likely the zlib version against which gd was build does not match the zlib against PHP was linked. But I really dont think you should be asking for support, as this is a hacked up GD. Nope, not asking for support. Just mentioning the segfault. Thanks for taking it easy on me though. :) Best Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] strpos() suggestion
Why couldn't you just strrev() the string and then strpos() for it? Mike --- Original Message --- From:Monte Ohrt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date:13 Nov 2002 16:02:54 -0600 Subject: [PHP-DEV] strpos() suggestion Hi, I had a little problem to solve today, and couldn't find any easy way to do it without some extra steps slicing things up. What I wanted to do is take an arbitrary point in a string, and find the position of the first '[' on the left of it, and the first ']' on the right of it. Finding the ']' was easy, I use strpos() to find the first occurance of ']' after my given point. Finding '[' however is not so easy. strrpos() was my first guess, but it does not work like strpos() at all. There is no optional third parameter, and on an unrelated note it only works with a single character, not a string. inconsistant ;-) My best solution was to slice the string at my point, then get the position of '[' with strrpos(). I'm not sure of the most intuitive way to solve this. One way would be to add a feature to strpos(); if you supply a negative third parameter, it gives you the position of the first occurance to the _left_ of that point. I'm not sure if the number should represent the position from the end or beginning of the string. Another way, add a third parameter to strrpos() to start at a given point from the end of the string. I'd try submitting a patch, but I'm not sure of which way would be best, and my C is a bit rusty, I'd probably do more damage than help ;-) Thoughts? Monte -- 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] [RFC] php-cli: option to ignore php.ini
Good idea. This is useful. Thanks. :) Regards Mike Robinson -Original Message- From: Marcus Börger [mailto:marcus.boerger;t-online.de] Sent: Tuesday, November 12, 2002 4:05 PM To: Wez Furlong Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] [RFC] php-cli: option to ignore php.ini Implemented: [marcus@zaphod php4-HEAD]$ php -r 'var_dump(get_cfg_var(cfg_file_path));var_dump(php_ini_scann ed_files());' string(20) /home/marcus/php.ini bool(false) [marcus@zaphod php4-HEAD]$ php -n -r 'var_dump(get_cfg_var(cfg_file_path));var_dump(php_ini_scann ed_files());' bool(false) bool(false) [marcus@zaphod php4-HEAD]$ php -c x -n -r 'var_dump(get_cfg_var(cfg_file_path));var_dump(php_ini_scann ed_files());' You cannot use both -n and -c switch. Use -h for help. marcus At 13:31 11.11.2002, Wez Furlong wrote: What are your opinions for having some option to prevent the loading/parsing of php.ini for the CLI version of PHP? -n No Ini File - skips parsing php.ini on startup At the moment, I'm using -c DOESNOTEXIST to achieve the same result, but this is a bit hacky. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] mbstring and 4.3.0
Jani Taskinen writes: I must (still) agree. +1 for making it disabled for now.. (people who need it, already know to use --enable-mbstring with 4.2.3) Exactly. It should remain off by default until it's solid. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Bug in PHP
Markus Fischer writes: You can use PHP as CGI on Win32/IIS platform which proves to be far more stable or use Apache instead of IIS. The combination you're using is known to have serious problems and is not recommended. Is this documented anywhere? Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] ODBTP, a possible solution for MS-SQL and other databases
Robert Twitty writes: So far 3 people have shown interest in ODBTP, however, it is the weekend. I am currently working on packaging it in a tar.gz file. If the response is low I will only release it to those who have shown an interest, and if it becomes higher than I will release it to the list. It is very important to me that the people who acquire it actually will use it and provide feedback within a reasonable time period. I do not want to feel like I put it in a black hole. Keep in mind some of the folks are in the throws of a fairly intense release cycle. I'd be interested in seeing more about this extension. It sounds like it could be useful. What kind of license would this stuff be released under? Best Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Unsigned Problems Revisited
-Original Message- From: Andi Gutmans [mailto:andi;zend.com] Sent: 30 October 2002 19:26 I think you guys have convinced me that having only isn't too bad (Jason will kill me now). Does anyone here on php-dev have any additional thoughts? Well, although I think it's a good idea to add the missing shift operator, I'd be a bit worried about the potential for confusion caused by having and operators that are not opposites of each other -- particularly with people trying to use as a shift on the grounds that it ought to exist and wondering why the rest of their script had apparently disappeared down a black hole! Whilst I don't want to start another lengthy discussion that ends up going round the mulberry bush umpteen times, should we be considering whether this is a case where PHP should strike out on its own and use a slightly different operator for this? Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Unsigned Problems Revisited
Jason T. Greene writes: Ok, I hereby volunteer to update the documentation to clearly explain shifting (with examples). Excellent! That way, I can't stop losing sleep wondering what the heck someone would need this stuff for. :) Best Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Re: [PHP-DOC] Apache 2 installation instructions
Derick Rethans writes: On Tue, 29 Oct 2002, Gabor Hojtsy wrote: As far as I can see, we should not not put into the PHP documentation that Apache 2 is not production ready, but PHP is not production ready for Apache 2. But it's incorrect :). By saying Do not use Apache 2 and PHP in a production environment you don't blame any of the two projects. I agree with Derick's approach. There's no need to cast dispersions on either Apache2 or PHP. Simply stating _clearly_ that the combination of PHP4 and Apache2 should not be used in a production environment is sufficient. No need to play the blame-game. :) Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] I hope this is the last email about this :)
-Original Message- From: Zeev Suraski [mailto:zeev;zend.com] Sent: 28 October 2002 02:06 Thank you for the detailed explanation, I'm sure everybody understands it now. Let's go for the voting phase. I vote we keep PHP-CLI with implicit_flush on by default. +1 Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] hebrew patch for jewish calendar
I received the attachment... you sure it's his mailer playing up? ;-) Mike --- Original Message --- From:Derick Rethans [EMAIL PROTECTED] To: moshe doron [EMAIL PROTECTED] Date:Mon, 28 Oct 2002 14:37:05 +0100 (CET) Subject: Re: [PHP-DEV] hebrew patch for jewish calendar On Mon, 28 Oct 2002, moshe doron wrote: i did it (1.txt) Still no attachment but everything inline. Your mailer is apparently so braindead to include it inline. I want to bet it's Outlook... Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] I hope this is the last email about this :)
Zeev Suraski writes: I vote we keep PHP-CLI with implicit_flush on by default. Ditto. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] I hope this is the last email about this :) (was
-Original Message- From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net] Sent: 24 October 2002 09:01 To: [EMAIL PROTECTED]; Melvyn Sopacua Are you going to insist most scripts need inefficient auto flushing? For CLI, yes. Have you ever used other programming languages? Yes -- over 40 at last count! (Even written the odd compiler in my time!) I don't get it, but this is the 3rd vote. Too few still and reasoning is too weak. BTW, if anyone would like to vote for inefficient/mostly useless auto flushing. Please add your vote to this article. http://news.php.net/article.php?group=php.devarticle=89995 I would, but I can't see any way of replying/voting on the page that URL takes me to...! Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] I hope this is the last email about this :) (was RFC:
-Original Message-
From: Yasuo Ohgaki [mailto:yohgaki;ohgaki.net]
Sent: 24 October 2002 07:42
To: [EMAIL PROTECTED]; Alan Knowles
Alan Knowles wrote:
Im +1 for reverting the patch - (for what it's worth)
This makes 2+ for having auto flushing :)
Add one more -- or even more, as I 'd say I'm +1 for this!
BTW, real language (i.e. not shell) don't flush. Please let me
know if there is real language that do automatic flushing by
default.
But PHP-CLI *is* a shell-scripting language, and therefore should behave
like one. Other flavours of PHP aren't, and shouldn't. QED.
In addition, is it too difficult to write this kind of code?
function prompt($prefix) {
echo $prefix;
flush();
}
I think this kind of code will be taught at the first
class of programming course. (I could be wrong,
since I don't know where people learned programming ;)
At university: learned half-a-dozen languages; *all* of them flushed streams
open on TTY either after every character, or (at line-end or when input
requested from same device). I've been programming now for over 25 years,
and this is *still* the behaviour I expect by default when programming
command-line-executable scripts or programs.
Let's guess something interesting.
How much % of scripts actually needs automatic flushing?
My guess is less than 1%. What is yours?
For PHP-CLI: more than 90%.
For PHP CGI or SAPI: much less than 1%.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php_value vs. php_admin_value
-Original Message- From: Rasmus Lerdorf [mailto:rasmus;php.net] Sent: 21 October 2002 05:49 admin directives can only be used in the httpd.conf file. Non-admins can be used in both httpd.conf and .htaccess. ie. directives that end-users should not be able to change themselves should be admin ones. But the documentation is still not sufficiently clear on how to decide when to use php_ directives and when to use php_admin_. When I first came to do a setup using these, I had a number of questions, and whilst I think I can make an intelligent guess at some of the answers, I'm still not absolutely sure. The documentation should, clearly and unambiguously, answer all of these: * How do I decide when to use php_admin_* and when php_*? Is it based on the PHP_INI_* settings? - If so which one(s)? - If not, what is it based on? * Can I use php_admin_* to set options have the PHP_INI_USER attribute (or PHP_INI_ALL)? - If so does that stop them from subsequently being altered in other contexts (specifically in user scripts?). Even after running a number of tests, I'm just not sufficiently sure of the answers to suggest specific improvements -- but if someone in the know could write a paragraph or two to answer the above questions, it would be a major improvement. (Shall I file a Documentation problem bug report?) Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Forked ext/gd by default
Rasmus Lerdorf writes: Whoa, pigs are flying over the skating rink in hell. Those aren't pigs. That's the Unisys Legal Department. It's a common mistake. :) Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Bug count..
Jani Taskinen wrote: Heh..just take a look in the database for bugs and them tell me how to get that data out of it. :) SQL should do the trick. :) Regards Mike Robinson (Sorry, couldn't resist...) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)
Michael Mauch wrote:
[snip]
en_US.ISO-8859-1 for example?
Yup, thats what its set to.
Hmm. Strange. What does
php -r 'echo strtoupper(äöü),\n;'
yield on your system? And what system is it, btw?
It outputs äöü. Stock RedHat-8.0 box, kernel-2.4.18 glibc-2.2.93.
We could use a test like strtopper(äöü)==ÄÖÜ to check if
the system is able to handle these characters correctly. If
not, the test could be skipped.
Adding to ext/xml/tests/007.phpt:
if (strtoupper(äöü)!=ÄÖÜ) {
print skip\n;
}
fixes this for me.
Regards
Mike Robinson
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)
Michael Mauch wrote:
I doubt that the C library does anything useful with
non-ASCII characters while you are in a C or POSIX
locale, so expat or PHP can't do much to correct that.
So is your locale something other than C or POSIX?
en_US.ISO-8859-1 for example?
Yup, thats what its set to.
Perhaps ext/xml/tests/007.phpt could check whether it is able
to successfully use strtoupper() on $xmldata - and if not,
just skip that test?
I have no problem with this test failing. It actually provides
useful information. I'm not one to second-guess the intentions
of the author of this test ('sniper' I think).
Thanks for the crash course on LOCALE. :)
Regards
Mike Robinson
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)
Yes I can reproduce this in 4.3.0pre1 and in CVS from
yesterday. Exact same output in ext/xml/tests/007.log as below
in both cases.
Mike
-Original Message-
From: Derick Rethans [mailto:derick;php.net]
Sent: Saturday, October 19, 2002 1:03 PM
To: PHP Developers Mailing List
Subject: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)
Hello,
somehow the test below fails for some people, but I couldn't
reproduce
it. Anybody else?
Derick
FAIL xml_parse_into_struct/umlauts in tags [ext/xml/tests/007.phpt]
EXPECTED OUTPUT
string(3) ÄÖÜ
array(1) {
[ÜÄß]=
string(3) Üäß
}
string(3) ÄÖÜ
array(1) {
[0]=
array(5) {
[tag]=
string(3) ÄÖÜ
[type]=
string(8) complete
[level]=
int(1)
[attributes]=
array(1) {
[ÜÄß]=
string(3) Üäß
}
[value]=
string(3) ÄÖÜ
}
}
ACTUAL OUTPUT
string(3) äöü
array(1) {
[üäß]=
string(3) Üäß
}
string(3) äöü
array(1) {
[0]=
array(5) {
[tag]=
string(3) äöü
[type]=
string(8) complete
[level]=
int(1)
[attributes]=
array(1) {
[üäß]=
string(3) Üäß
}
[value]=
string(3) ÄÖÜ
}
}
FAILED
--
PHP Quality Assurance 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] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)
I don't think that's it, since it's [supposed to be] on be default. Setting the option in the test changes nothing anyways. The test is new since 4.2.3, so i couldn't go back and see when it started failing. (Its interesting to note that in 4.2.3 though, _all_ my xml tests failed). Unfortunately, XML has not been a 'buzzword' for me, :) , so I'm not really up on this stuff. Mike Saturday, October 19, 2002, 7:35:05 PM, Derick Rethans wrote: On Sat, 19 Oct 2002, Mike Robinson wrote: Yes I can reproduce this in 4.3.0pre1 and in CVS from yesterday. Exact same output in ext/xml/tests/007.log as below in both cases. Do you also know _why_ it fails and how we can fix either the test or the code? Couldn't possibly have anything to do with XML_OPTION_CASE_FOLDING being disabled? http://no.php.net/manual/en/function.xml-parser-set-option.php -- Kjartan [EMAIL PROTECTED] (http://natrak.net/) :: If you wish to be loved, show more of your faults than your virtues. - Edward Bulwer-Lytton -- 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] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)
Sorry, that test _is_ in 4.2.3, and it failed there as well with the same problem, it just didn't output anything during make test. -Original Message- From: Mike Robinson [mailto:mike;mgrobinson.com] Sent: Saturday, October 19, 2002 2:40 PM To: 'Kjartan Mannes'; 'PHP Developers Mailing List' Cc: 'Derick Rethans' Subject: RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd) I don't think that's it, since it's [supposed to be] on be default. Setting the option in the test changes nothing anyways. The test is new since 4.2.3, so i couldn't go back and see when it started failing. (Its interesting to note that in 4.2.3 though, _all_ my xml tests failed). Unfortunately, XML has not been a 'buzzword' for me, :) , so I'm not really up on this stuff. Mike Saturday, October 19, 2002, 7:35:05 PM, Derick Rethans wrote: On Sat, 19 Oct 2002, Mike Robinson wrote: Yes I can reproduce this in 4.3.0pre1 and in CVS from yesterday. Exact same output in ext/xml/tests/007.log as below in both cases. Do you also know _why_ it fails and how we can fix either the test or the code? Couldn't possibly have anything to do with XML_OPTION_CASE_FOLDING being disabled? http://no.php.net/manual/en/function.xml-parser-set-option.php -- Kjartan [EMAIL PROTECTED] (http://natrak.net/) :: If you wish to be loved, show more of your faults than your virtues. - Edward Bulwer-Lytton -- 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] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)
Michael Mauch writes: Are your locale settings ok? Yeah, they're fine, for my locale. But I'm not in Germany, though I'm told the beer there is awesome. :) Mike % locale LANG=de_DE.ISO-8859-15 LC_CTYPE=de_DE LC_NUMERIC=de_DE.ISO-8859-15 LC_TIME=de_DE.ISO-8859-15 LC_COLLATE=C LC_MONETARY=de_DE.ISO-8859-15 LC_MESSAGES=de_DE.ISO-8859-15 LC_ALL= % php ./run-tests.php ext/xml/tests/007.phpt = CWD : /usr/local/src/php-cvs/php4 PHP : sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.0-dev PHP_OS : Linux INI actual : /usr/local/lib/php.ini More .INIs : Extra dirs : = Running selected tests. PASS xml_parse_into_struct/umlauts in tags [ext/xml/tests/007.phpt] % LC_ALL=C php ./run-tests.php ext/xml/tests/007.phpt = CWD : /usr/local/src/php-cvs/php4 PHP : sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.0-dev PHP_OS : Linux INI actual : /usr/local/lib/php.ini More .INIs : Extra dirs : = Running selected tests. FAIL xml_parse_into_struct/umlauts in tags [ext/xml/tests/007.phpt] Regards... Michael -- 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] 4.3.0-pre1 printf weirdness
Yup, I just grabbed a checkout and its fixed. That was a weird one. Regards Mike Robinson Derick Rethans wrote: Hello, I could reproduce this with pre1, but latest CVS works fine again. Can you try? Derick On Thu, 17 Oct 2002, Mike Robinson wrote: ?php printf(%01.2f,-2999/100); echo br; printf(%01.2f,-3000/100); echo br; printf(%01.2f,-3000/100); echo br; printf(%01.2f,-3000/100); echo br; printf(%01.2f,-3001/100); echo br; printf(%01.2f,-3000/100); ? 4.2.3 output: -29.99 -30.00 -30.00 -30.00 -30.01 -30.00 4.3.0pre1 output: -29.99 296.14 0.00 0.00 -30.01 296.14 If I comment out one or more of the printf()'s that use -3000/100, but not all of them, I can get the returned output of the others to change to all sorts of neat things (just never -30.00). At one point one of them output 3245234172.00. This is on a stock redhat8 box. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- -- - Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.3.0-pre1 printf weirdness
?php printf(%01.2f,-2999/100); echo br; printf(%01.2f,-3000/100); echo br; printf(%01.2f,-3000/100); echo br; printf(%01.2f,-3000/100); echo br; printf(%01.2f,-3001/100); echo br; printf(%01.2f,-3000/100); ? 4.2.3 output: -29.99 -30.00 -30.00 -30.00 -30.01 -30.00 4.3.0pre1 output: -29.99 296.14 0.00 0.00 -30.01 296.14 If I comment out one or more of the printf()'s that use -3000/100, but not all of them, I can get the returned output of the others to change to all sorts of neat things (just never -30.00). At one point one of them output 3245234172.00. This is on a stock redhat8 box. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
I would have no problem - as a user - with the removal of short_tags IF ?php=$var? was allowed!! Because the ?= short cut is the only reason I use ? at all! Just to add fuel to the fire ;-) Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] short_open_tag
-Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: 17 October 2002 06:16 [snip] Even if we never change the default, ?php echo ?xml ..?;? works always w/o patch. [snip] We may even have XML processor that processes PHP code in XML documents in the future. i.e. PHP interpreter is invoked from XML processor. ... in which case your php echo statement above won't parse properly. Since the definition of an XML PI block is effectively: ?tagname any text except the sequence ? ? -- without any reference to the syntax of what's inside the block -- a true XML parser will think the ?php block ends at the first ?, the one *inside* *the* *quotes*. A proper XML conformant block would have to do something like: ?php echo ?xml ..?.;? Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] nl2br is broken in PHP4.3.0pre1
Derick Rethans writes: Hey, this is already fixed in CVS. thanks, Derick Have you decided yet on the release cycle for 4.3? Are we any closer to branching 4.3.0 or are we going to do 4.3.0pr2 for further testing, or? :) Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] New function file_put()
Christian Schneider writes: On a side note: I think the file_get_contents() function should be renamed to file_get() as it is useful enough to deserve a shorter name. Conversely, your new function should be named file_put_contents() for consistency. :) Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] short_open_tag
Dan Hardiker writes Im -1 on changing the default before v5 but +1 on it being done in the long run. This sounds like the best approach. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Streams Problems
?php $fp = fopen(http://www.slashdot.org/slashdot.rdf;,'r'); ? In 4.2.3 this works as expected. It redirects to http://slashdot.org/slashdot.rdf (note the 'www.' is gone). In 4.3.0pr1 this results in: Warning: fopen(http://www.slashdot.org/slashdot.rdf) [function.fopen]: failed to create stream: HTTP request failed! HTTP/1.1 301 Moved Permanently in /home/www/htdocs/test/fopen/slash.php on line 2 Regards Mike Robinson -Original Message- From: Wez Furlong [mailto:[EMAIL PROTECTED]] Sent: Saturday, October 12, 2002 1:40 PM To: Mike Robinson Cc: [EMAIL PROTECTED]; 'Wez Furlong' Subject: RE: [PHP-DEV] Streams Problems Works for me using latest CVS. ?php $fp = fopen(http://site.that.redirects;, r); fpassthru($fp); var_dump(stream_get_meta_data($fp)); ? The var_dump shows that PHP is following the redirects. There used to be a bug like that, but it's been fixed for a couple of weeks now. How about posting a script that reproduces the problem, and the error output? --Wez. On 10/12/02, Mike Robinson [EMAIL PROTECTED] wrote: Im not sure if this is related, but using fopen or fsockopen to retrieve a document that sends a redirect header (in this case a 302 Moved Permanently trying to pull the slashdot headlines rdf/xml file) fails. Worked fine in 4.2.3. This is the case with 4.3.0pr1 and CVS for a little while now. -- 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] Streams Problems
Im not sure if this is related, but using fopen or fsockopen
to retrieve a document that sends a redirect header (in this
case a 302 Moved Permanently trying to pull the slashdot
headlines rdf/xml file) fails. Worked fine in 4.2.3. This is
the case with 4.3.0pr1 and CVS for a little while now.
Regards
Mike Robinson
-Original Message-
From: Ilia A. [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 11, 2002 10:11 PM
To: [EMAIL PROTECTED]; Wez Furlong
Subject: [PHP-DEV] Streams Problems
There are 3 streams related problems I've come across today
while using CVS
code. First it seems that sending of binary data in excess of
8k causes some
of the data not to be sent. This can be easily replicated
with the following
test code:
?php
$test_binary_file = file_get_contents(file_name);
$length = strlen($test_binary_file);
$fs = fsockopen(host, port);
$written = fwrite($fs, $test_binary_file)
fclose($fs);
?
According to fwrite() output all the data has been written,
since $length
equals to $written. However, using a network monitoring tool,
Ethereal I was
able to see that only about 8k worth of data was sent. This
was confirmed by
another script that set on the receiving end.
Another problem I've come across is about reading from
sockets that do no
terminate connection. Using the following script I've connected to a
webserver, in php 4.2.3 the script returns immediately after
the last byte
has been read. In CVS the script wait about 10 seconds after
all the data has
been read before finally terminating (timing out?). The
example script is
below:
?php
$fp = fsockopen(host, 80);
fwrite($fp, GET / HTTP/1.1\r\nHost: host\r\n\r\n);
while ( ($data = fgets($fp, 1024)) ) {
echo $data;
}
flose($fp);
?
The third problem is coredump that is fairly easily replicate
with the script
below:
?php
$fp = fsockopen(localhost, 80);
fputs($fp, GET / HTTP/1.0\r\n\r\n);
fgets($fp, 10);
?
Ilia
--
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-DEV] Re: session_register warnings
Now I'm not really anyone special - just another user, as it were, but I do use the session module on a daily basis as part of my job. FWIW, I agree with Sascha on this one. A user should be able to work with a session variable in global scope all the time, or not at all. Not some mish-mash of both. As it stands at the moment (with register_globals off), variables can be pulled into a session from global scope, but they cannot be pulled out again from global scope - you have to use the $_SESSION array. I find this counter intuative... if I can put them into a session that way, why can't I pull them out again that way? Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] bundled gd
p.s. is development on the original libgd officially stopped and/or propertiary so there is no public CVS of its latest version? Dunno, ask the authors. That won't do any good. Requests for info seem to go the same route as patches and suggestions - /dev/null. A shame really. The upshot is, with the crew on the PHP team doing the fork, the library is bound to get a LOT better. :) Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] bundled gd
http://downloads.rhyme.com.au/gd/ Newer GD libs with gif support have been around for quite a while. Compiling PHP against these works fine. Regards Mike Robinson -Original Message- From: Tit Black Petric [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 8:52 PM To: Joye Pierre-Alain Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] bundled gd imho, GIF format is dead, still used but dead ;) Providing read functions is enough. I prefer to see a mng support in futur versions (http://www.libmng.com/) backwards compatibility is still backwards compatibility.. either you support it full, or you dont support it at all. as for having an uncompressed gif writer.. that would cause a lot of people to use other alternatives, like png. still thinking this readonly thing sucks (not that i'dd ever probablly use gif writing.. i guess its just that having something once for free means you're going to have it forever, or atleast it should) black -- 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] ext/aspell
I like the alias option as well.
The aspell/pspell packages seem to be the exception to the
gnu names don't change rule. These two packages have been
a bit of a moving target in terms of both naming and
[inter]dependencies and BC has been an issue a couple of
times.
I apologize in advance, because .02 CDN isn't worth much
these days.
Mike Robinson
-Original Message-
From: Melvyn Sopacua [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 07, 2002 1:50 PM
To: Vlad Krupin
Cc: DJ Anubis; PHP-DEV; Jan Lehnardt
Subject: Re: [PHP-DEV] ext/aspell
The config option just makes it easier to find, especially
when you delete
aspell from the tree.
You would basically try to accomplish, that:
./configure --help | grep aspell
yields something and possibly hint to pspell.
How that is done is insignificant. But adding
--with-gnu-aspell would allow
to move it to that name
at some point in time, since GNU packages generally don't
change names :-)
my 2.20173 eurocents :)
At 10:20 10/7/2002 -0700, Vlad Krupin wrote:
The new and improved GNU aspell happpens to be almost 100%
source-compatible with pspell, in fact, no changes to php source are
necessary to use it. I am against creating a yet-another
config option.
We've got a few of those already.
I have no problem with nuking aspell and placing a dummy
entry in the
docs
(akin to www.php.net/delete) telling people to use pspell,
because, as far
as PHP is concerned, it's the same thing, if that's ok with
everyone else.
But I don't see a good reason for an alias where you don't need one.
just my 2 kopecks :)
Vlad
Melvyn Sopacua wrote:
Agreed, but there's one problem:
The pspell as you know and love it, is now named GNU Aspell 0.52.
The pspell extension must be used, to build with GNU Aspell
- the API
has been kept as an 'alias' for this purpose.
So I vote for:
--with-aspell - /dev/null
--with-gnu-aspell - AC_ARG_WITH alias for --with-pspell - nothing
more.
No seperate directory, nor renaming or aliasing of functions.
At 13:51 10/7/2002 +0200, DJ Anubis wrote:
Le Lundi 7 Octobre 2002 13:39, Jan Lehnardt a écrit :
Hey there hard working folks,
aspell was replaced by pspell long ago, hence I
like to remove
aspell from the main source tree to either PECL or
/dev/null. Any
objections?
Comments are highly welcome.
Hi,
You're right. aspell is a survival of an antiquated
tradition. pspell
is
much
better. So /dev/null sounds a great place for antiques ;-)
DJ Anubis
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Met vriendelijke groeten / With kind regards,
Webmaster IDG.nl
Melvyn Sopacua
@Logan I spent a minute looking at my own code by
accident. @Logan
I was thinking What the hell is this guy doing?
--
Vlad Krupin
Software Engineer
echospace.com
/MELVYN
void wakeup() {
for(unsigned int cuppajava;drink();cuppajava++);
}
--
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] insalling php - 4.2.3 with apache - 2.0.40 on freeBSD 4.6
Rasmus Lerdorf wrote: There are no known holes in the latest Apache 1.3.x. In fact it is by far the most stable version of Apache out there. I still consider Apache 2.0.x to be beta quality and in that sense you are not using the latest and best software. What's really odd about this (not trolling here) is that the ASF reads like a who's who of the php dev team. I have to wonder how the hell Apache2 ever went gold with such shabby support for php (and mod_perl, mod_python, and others for that matter.) If you want to use Apache 2.0.x right now, please use the latest unstable snapshot of PHP from snaps.php.net. But again, this is not the reccomended combination of software right now. Let the floodgates open. Redhat-8.0 installs Apache 2.0.40 (which redhat refers to as httpd-2.0.40) together with php-4.2.2. A casual upgrade to RH8 is going to bite a lot of people right on the posterior. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] patch to restrict database access for ext/pgsql
From: Jon Parise Isn't it generally better (where better means more secure, efficient, and easily maintained) to handle database access control using PostgreSQL's native access mappings? I would think so, and IMHO, that's where pgsql access control belongs, with pgsql. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Patches and Extensions and Such
I for one have no use for line numbers in a phps file. I do have use for being able to copy/paste out of phps files, which would stop working with line numbers there. Some folks use phps files to distribute snippets and stuff. Can't this be option, default off (current behaviour)? Regards Mike Robinson -Original Message- From: Rick Widmer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 4:20 PM To: Jani Taskinen; Devon O'Dell Cc: Yasuo Ohgaki; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Patches and Extensions and Such At 10:12 PM 9/18/02 +0300, Jani Taskinen wrote: I was just thinking that .phps support is there to just show source of some php file. I don't think it's really any BC problem to always have line numbering on for them. And have an optional parameter to the PHP function to show those numbers if wanted. I agree! Has ANYONE given a good reason why .phps should not ALWAYS have line numbers turned on. ?HIGHLIGHT_FORMAT is a hassle and likeley to be forgotten when you need it most. People who don't use .phps have no business in making this decision. You are free to disable it on your system and ignore it. I don't understand what's the big deal about this thing anyway? It's nice new feature. It sure is! Rick -- 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] Patches and Extensions and Such
Instead of? Why is it that everyone else not only has to change the way they do things but break everything done the old way? How much plainer does a BC issue have to be? One man's feature is another man's bug. You guys wanted a valid reason, I gave one. There's probably more. :) Did I miss the part in this thread about why this can't be an option? .mike -Original Message- From: Rick Widmer [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 5:48 PM To: [EMAIL PROTECTED] Subject: RE: [PHP-DEV] Patches and Extensions and Such At 04:44 PM 9/18/02 -0400, you wrote: I for one have no use for line numbers in a phps file. I do have use for being able to copy/paste out of phps files, which would stop working with line numbers there. Some folks use phps files to distribute snippets and stuff. Can't this be option, default off (current behaviour)? cp xxx.php xxx.txt instead of cp xxx.php xxx.phps will provide this functionality, without all the fancy coloroing and such. I still think if .phps is going to add all the other eye-candy it does line numbers are a good idea. Rick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] sockets extension
Dan Kalowsky writes: Not to continue a flame war, but this is Open Source, and it is done on free time. Open Source is a philosophy. It shouldn't be an excuse. Nothing prevents us from treating people with patience and courtesy. Except of course bad manners and bad attitude. Because you the user feels you'd like to use such functionality it's not typically a concern for the developers. Often times this functionality is added to make their own lives easier, or to try an experiment with something. Take a look at the iD software policy: it'll be ready when it's ready. Thats all there is to it :) Like so. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php-4.2.3 - Thanks+Kudos
I would like to express my sincere appreciation to the php dev team, the qa team, the php-doc magicians, and as always the countless others for their extraordinary continuing efforts in making php4 the best. Awesome work from incredibly awesome people. My humble thanks. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.3 release.
Would the select name=fields['tech_id'][] syntax work? That should give an identical array, if I'm seeing what you're doing right. Mike - Original Message - From: [EMAIL PROTECTED] To: Xavier Spriet [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, September 04, 2002 6:47 PM Subject: Re: [PHP-DEV] PHP 4.2.3 release. Hey, did this ever work at all? AFAIK you can only use [] _once_ to denote it's an array. Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.2.3 release.
Beat me to it! :-) - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: Xavier Spriet [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, September 04, 2002 6:50 PM Subject: Re: [PHP-DEV] PHP 4.2.3 release. This is not a bug. Your syntax is wrong. It should be: fields[tech_id][] -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Problem with http://php.net
Cross-dressing. Vibrators. Oh my. Breadsticks in the nose anyone? .mike -Original Message- From: Dan Hardiker [mailto:[EMAIL PROTECTED]] Sent: Monday, September 02, 2002 9:22 AM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Problem with http://php.net P.S. Offtopic sorry funny things are allowed as off topic posts :) Derick Such as Derick's cross dressing tendancies? heh :P [sorry, couldnt resist] -- Dan Hardiker [[EMAIL PROTECTED]] ADAM Software Systems Engineer First Creative Ltd -- 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] mbstring
James Cox wrote: I vote to remove mbstring as a default module. +1 Let us STOP burdening default builds with crap that is unlikely to be used. Amen. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] segfault on adding empty heredoc to string
No problems with 4.2.2 as apache-1.3.26 dso on RH-7.2 Regards Mike Robinson -Original Message- From: Lukas Schroeder [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 01, 2002 1:50 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] segfault on adding empty heredoc to string hi, i can crash my php here by using these lines: ?php $a = ''; $a .= EOF EOF; ? can anyone second this? regards, -lukas #0 0x403218b5 in _zval_dtor (zvalue=0xbfffe214, __zend_filename=0x4038dc80 /home/azzit/src/cvs/php4/php4/Zend/zend_operators.c, __zend_lineno=1057) at /home/azzit/src/cvs/php4/php4/Zend/zend_variables.c:43 #1 0x4031f15f in concat_function (result=0x8296a0c, op1=0x8296a0c, op2=0xbfffe214) at /home/azzit/src/cvs/php4/php4/Zend/zend_operators.c:1057 #2 0x40333fc0 in execute (op_array=0x829674c) at /home/azzit/src/cvs/php4/php4/Zend/zend_execute.c:1165 #3 0x403239e4 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/azzit/src/cvs/php4/php4/Zend/zend.c:810 -- 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] Re: cgi and mod_php
I'm sure PHP 4.3.0 builds the CLI as well as any other SAPI you specify, doesn't it? - Original Message - From: George Schlossnagle [EMAIL PROTECTED] To: Daniel Lorch [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, August 28, 2002 9:54 PM Subject: Re: [PHP-DEV] Re: cgi and mod_php I think the point isn't that it's not scriptable, but that it would be nice if there was a 'canned' way of doing it. I use the apache sapi and the cli, and it would be nice to be able to build them with a single make. Clearly there are ways to build them both (easily), but it should be easy for a basic user to have it build multiple targets. This is especially true with the cli, as there are abundant reasons to have it and one of the web-centric sapi's cohabitating on a system. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 4.3 and PHP 5
Title: RE: [PHP-DEV] PHP 4.3 and PHP 5 Wez Furlong wrote: o Bundle Brads php-soap extension, and market PHP 5 as being Web Service Enabled. This will stop the bleeding of the PHP users Manuel Lemos will be pleased. :P Mike Robinson IT/Developer - Torstar Media Group Television Phone: 416.945.8786 Fax: 416.869.4566 Email: [EMAIL PROTECTED] To find out more about what we can do for you, please visit us at: http://www.tmgtv.ca/ and http://www.thestar.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: [PHP-QA] Congratulations.
Title: RE: [PHP-DEV] Re: [PHP-QA] Congratulations. Congratulations Derick. Most deserving recognition for a terrific job. I will add to that my humble thanks. Mike Robinson IT/Developer - Torstar Media Group Television Phone: 416.945.8786 Fax: 416.869.4566 Email: [EMAIL PROTECTED] To find out more about what we can do for you, please visit us at: http://www.tmgtv.ca/ and http://www.thestar.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php-bugs subject lines
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 25 July 2002 09:15 To: Marko Karppinen I like this idea, but I would propose to let the line always begin with Bug #bugnr (for sorting and stuff). Is there any need to bother with Bug when it's on the php-bugs list? Couldn't subject lines just start with the bug number, so: #12345 Bogused: etc etc... Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] bug 16037 help? zend/thread-safety problem
I've been investigating the source around this bug: http://bugs.php.net/bug.php?id=16037 ...and can't quite wrap my head around how to fix it. The implication of the bug is that for Apache 2.x platforms using threading (or Apache 1.3.x on windows, which uses threading), you'll probably get random parse errors if two threads compile the same script at once. The problem seems to be the non-thread-safe use of some variable that's used when interpolating variables in strings, but I'm much better at Java threading then the Zend TS...() macros so I can't figure out where it is. By rooting around cvs.php.net, I was able to see that Zeev was in zend_language_parser most recently putting in some thread-safety changes, but there is definitely still a problem. Does anyone have interest in working with me to fix this bug? I'm highly motivated to fix it, but I need help. I see a few options if someone has the time: 1) I could test a new build (I can reproduce the bug at will) 2) I could compile and test a new build (haven't built win32 before, but I have VC6, so I can give it a shot) 3) I can patch it if someone could help me with the control-flow and threading macros Or, perhaps there is simply a better way? Any and all help is appreciated - -Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Release plans for 4.2.2 / 4.3
Title: Release plans for 4.2.2 / 4.3 Are there any tentative release plans for 4.2.2 or 4.3? Mike Robinson IT/Developer - Torstar Media Group Television Phone: 416.945.8786 Fax: 416.869.4566 Email: [EMAIL PROTECTED] To find out more about what we can do for you, please visit us at: http://www.tmgtv.ca/ and http://www.thestar.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: cvs: php4 /ext/mbstring config.m4
Title: RE: [PHP-DEV] Re: cvs: php4 /ext/mbstring config.m4 Edin Kadribasic writes: Sent: Monday, July 15, 2002 12:05 PM To: [EMAIL PROTECTED]; Jani Taskinen; Yasuo Ohgaki Subject: Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring config.m4 I asked to php-dev and nobody objects enabling mbstirng by default. This allow some modules (extif, mailparse(?), for example) to use multibyte feature. No objections here. Frankly, I don't think mbstring should be enabled by default. If a user wants mbstring support, is it too much to ask to have them add --enable-mbstring to their config line? Once we go down this road, turning it off by default is a huge wtf. IMHO that is. Regards Mike Robinson IT/Developer - Torstar Media Group Television Phone: 416.945.8786 Fax: 416.869.4566 Email: [EMAIL PROTECTED] To find out more about what we can do for you, please visit us at: http://www.tmgtv.ca/ and http://www.thestar.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] serial port communication
It's something I need to look into for a project I'm putting together at work. I just haven't got the time at the moment to do it, sadly -- Mike -- Zac Hillier [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... On the 20th May Mike Hall posted a message about communication with serial ports. I'm trying to research using php with a multi port serial card, can anyone tell me if this progressed, else is there anywhere I can look for further information? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] serial port communication
As far as I know, nobody has looked at this before. So you'd be starting from scratch. - Original Message - From: Zac Hillier [EMAIL PROTECTED] To: Mike Hall [EMAIL PROTECTED] Sent: Tuesday, July 02, 2002 9:40 AM Subject: Re: [PHP-DEV] serial port communication Thanks for the reply, any idea where I could find more information? Zac - Original Message - From: Mike Hall [EMAIL PROTECTED] To: Zac Hillier [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 02, 2002 9:42 AM Subject: Re: [PHP-DEV] serial port communication It's something I need to look into for a project I'm putting together at work. I just haven't got the time at the moment to do it, sadly -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Seeking Comments - Regarding header()
Chris Shiflett wrote: I have a few sites where I deliberately violate the HTTP spec in this way to get around a bug in IE (I know, shame on me). I've been using relative URLs in a Location header for years with no crashes that I know of. There must be something unique in your configuration. Have you mentioned this to the Apache guys? I've seen this before too, but only on Windows. I've never noticed the problem on Linux, Solaris, or BSD. I had it on FreeBSD. It was particularly bad under SSL, but happened without too. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Switching zlib.output_compression, bug #16109
I would venture that this is a bug in Netscape, not a bug in PHP and
therefore not PHP's responsibility to fix.
Netscape is reporting to PHP that it accepts zipped content, when it clearly
doesn't accept zipped images.
Mike
- Original Message -
From: Stefan Roehrich [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 24, 2002 3:23 PM
Subject: [PHP-DEV] Switching zlib.output_compression, bug #16109
Hello!
There has been a bug report (#16109) about a bug in Netscape 4.79,
which doesn't display images if Content-Encoding: gzip is used. After
thinking about a browser detection config flag for zlib.output
compression, at LinuxTag we discussed, that a more general solution
would be better, that means switching off output compression for
images and let it be possible to switch it off (or force it on) during
script execution.
So I implemented it this way:
The headers for output compression are sent late, not in the zlib
request init, but in the SAPI send_headers call, I think this is the
latest possible time I can add it, so that it's possible to switch it
off before that time. If you send a header(Content-Type: image/xxx)
output compression is switched off, you can also switch it off via
ini_set('zlib.output_compression', 'Off') (or force it on, if you use
this call with 'On' after the image header was sent, but this only
works, if it was globally enabled, you can't switch it on during
script execution if the default says 'Off' (you need the output
buffering, you also can't change the buffer size)).
If output compression was disabled during the script, the compression
handler simply does noething and no headers are added (so you can
switch the setting only before the headers are sent).
Because I'm no SAPI expert and I don't know, if there are some other
effects, if I add the header in the send_headers call, I haven't
commited it yet, see the attached patch. If nobody objects, I'll
commit it in a few days.
Stefan
--
Stefan Röhrich [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.roehri.ch/~sr/
--
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] Switching zlib.output_compression, bug #16109
I simply don't use output compression for images
- Original Message -
From: Jaime Bozza [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: 'Stefan Roehrich' [EMAIL PROTECTED]; 'Mike Hall'
[EMAIL PROTECTED]
Sent: Monday, June 24, 2002 4:11 PM
Subject: RE: [PHP-DEV] Switching zlib.output_compression, bug #16109
While this is, in fact, a Netscape-specific bug, it's a pain in that
there is no current easy workaround to disable zlib.output_compression
from the script. Right now (tested with 4.1.2, so I can't say how it
works in 4.2.x or above) if I have:
ini_set('zlib.output_compression', 'Off');
in my script, it's ignored and still sends out the compressed data. If
you don't like the browser detection on images, at least allow the
ability to be able to turn off zlib.output_compression from the script.
Jaime Bozza
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Switching zlib.output_compression, bug #16109
ob_start('ob_gzhandler');
Shouldn't this be on php-general by now? ;-)
let me get this straight.. you can turn off output_buffering = on inside
php?
then whats the problem with zlib, just make it output_buffer, and AFTER
that
check the ini value, weather to compress that data or not.. so it could be
turned off runtime, or am i wrong?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Switching zlib.output_compression, bug #16109
Well write your own callback function for ob_start then! ;-)
Perhaps. :) But it seems you're missing the point. Read here:
http://www.php.net/manual/en/function.session-start.php
Specifically, the second note:
Note: Use of zlib.output_compression is recommended rather than
ob_gzhandler
zlib.output_compression != ob_start('ob_gzhandler')
Which brings us back to the original point. How does one go about
enabling/disabling zlib.output_compression from within a script?
ini_set('zlib...', 'On|Off') does not work.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seeking Comments - Regarding header()
On Fri, Jun 21, 2002 at 09:50:01AM +0100, Mike Hall wrote : The HTTP/1.1 spec says that anything sent as a location header must be an absolute URI. Apache will sometimes segfault if you don't. Eh ?! If it is really apache which crashes, the apache group would surely be interested to know about this, don't you think ? Do you have a sample which reproduces this crash? You could hardly describe it as a bug if Apache crashes because you're sending Headers that violate the spec, surely? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Seeking Comments - Regarding header()
On Fri, Jun 21, 2002 at 10:48:33AM +0100, Mike Hall wrote : You could hardly describe it as a bug if Apache crashes because you're sending Headers that violate the spec, surely? Hmm ... I'm not sure. I don't think apache should crash. but then how can you be sure it's apache who crashes and not php? If it's an apache crash it maybe can be missused too (though not remotely). Well, if you send relative URLs in a Location: header, it causes intermittent sig11's in Apache. Don't know if that is mod_php causing them, or apache. But it does happen. I had that problem on GG.COM .. took me weeks to track it down to relative location headers. --Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
