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
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] 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] 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] 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-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
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] [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
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 :)
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] 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] 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
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] 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
[PHP-DEV] RE: [PHP-DOC] diff style bug update headers
Makes it much easier to see the difference. Good idea. +1 .mike -Original Message- From: Gabor Hojtsy [mailto:[EMAIL PROTECTED]] Sent: February 3, 2002 1:04 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [PHP-DOC] diff style bug update headers Hi! I would like to propose a diff like bug update header style, so to use ID: 15357 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Documentation problem Operating System: Win XP PHP Version: 4.1.0 Instead of: ID: 15357 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Documentation problem Operating System: Win XP PHP Version: 4.1.0 IMHO all we can read the diff style easier, and the reporters would also understand what was changed for a first look. The web interface to bugs are getting easier to use, why not improve the mails sent out too ;) I'll make the changes if we will come to a decision. Goba -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Shootout
August Zajonc continues with ... I continue to see these stupid trivial benchmarks as useful. The benchmark code is pre-alpha and incomplete as the author states expressly. 'Useful' does not imply reliable, factual, or scientific. In my view, what I've seen and read is neither useful, nor harbours any of the other qualities, mentioned above, that reasonable people might consider important. IMHO, the benchmarks are bogus from the get go, and this discussion is moot. Hopefully at the end of this dicussion that may be the case, or at least we'll all be up on how important various compile flags are. Please ask support questions on the friendly helpful php-general list. Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Re: Shootout
Zeev Suraski writes: Well, I think that benchmarking PHP like that out of any context is *bound* to result in many people getting the wrong ideas. So, a big disclaimer reading This may not necessarily have any real world meaning was due. You betcha, wrong ideas I was about to activate the Omega-13. ;) Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Bug #14707 Updated: A very serious PHP bug that can turn down almost any web server !!!
Is the snark really necessary? It accomplishes what? Mike Robinson [EMAIL PROTECTED] writes: ID: 14707 Updated by: daniel Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Any OS, any PHP version PHP Version: 4.1.0 New Comment: here's another discovery: while(true) mail([EMAIL PROTECTED], this is a mailbomb, blub); Previous Comments: [2001-12-26 19:06:19] [EMAIL PROTECTED] I forgot to /bogus [2001-12-26 19:04:23] [EMAIL PROTECTED] well, DoS is nothing new. thanks for re-descovering it. this is not a PHP bug (same problem applies to virtually any language: C, Python, Perl ..). it's a general security issue. you might solve it by limiting the amount of connections for an IP. Kind Regards, Daniel Lorch -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Bug #14036: Segfault when using multipart form
I suspect so; I cannot reproduce this problem with 4.0.6 running on a 2.2.19 Linux box, nor with snapshot php4-200111030900 running on a stock RH-7.2 box. Well, file uploads do work in general in PHP 4.0.6 or the whole world would be screaming. So there is something specific to your test case or your system that is causing this. -Rasmus As i reported in my bug report, i can reproduce this problem with 4.0.6 and current cvs. Hans Rakers -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Re: [PHP-QA] PHP 4.0.6RC1 ready for testing
Well, this looks like my problem, not php's. Unbeknownst to me redhat-7.1 has switched to freetype2. For some strange reason, they left a copy of freetype.h in /usr/include/freetype and when I compiled gd-1.8.3gif from source, I pointed it to that older header file. PHP comes along and looks for freetype.h in /usr/include/freetype2. Its a mess. Its strange though that a snapshot from May 6 worked. It shouldn't have on this system. :) Regards Mike Robinson Andi Gutmans wrote: Can you try and revert those changes and see if it helps? Maybe you can find the cause of the problem? Andi At 10:11 PM 5/16/2001 -0400, Mike Robinson wrote: Andi wrote: I rolled 4.0.6RC1. It is ready for testing. http://www.php.net/~andi/php-4.0.6RC1.tar.gz Please everyone take sometime to make sure this is release worthy :) Hmm. I can't get freetype2 support hooked up. It worked fine in a snapshot from about a week ago. (php4-200105060945) In that snapshot, png support was successful without having to specify --with-png-dir=/usr, thats no longer the case. This is with gd-1.8.3gif installed from source, and the stock freetype2 rpms on redhat-7.1. There were some changes about a week ago to php4/ext/gd/config.m4 involving freetype dir tests (amongst others). Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Re: [PHP-QA] PHP 4.0.6RC1 ready for testing
I reverted the changes in that file, removed config.cache, made clean, make make install, and it stilll messed up. It seems to compile and install fine, then apache fails to load php, something about an undefined reference to TT_FACE..., so it seems to be messing up on the ttf stuff. I'll have a closer look at things when I get home from work. Regards Mike Robinson Andi Gutmans wrote: Can you try and revert those changes and see if it helps? Maybe you can find the cause of the problem? Andi At 10:11 PM 5/16/2001 -0400, Mike Robinson wrote: Andi wrote: I rolled 4.0.6RC1. It is ready for testing. http://www.php.net/~andi/php-4.0.6RC1.tar.gz Please everyone take sometime to make sure this is release worthy :) Hmm. I can't get freetype2 support hooked up. It worked fine in a snapshot from about a week ago. (php4-200105060945) In that snapshot, png support was successful without having to specify --with-png-dir=/usr, thats no longer the case. This is with gd-1.8.3gif installed from source, and the stock freetype2 rpms on redhat-7.1. There were some changes about a week ago to php4/ext/gd/config.m4 involving freetype dir tests (amongst others). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Re: [PHP-QA] PHP 4.0.6RC1 ready for testing
-Original Message- From: Zak Greant [mailto:[EMAIL PROTECTED]] Sent: May 15, 2001 3:27 PM To: [EMAIL PROTECTED]; Andi Gutmans; [EMAIL PROTECTED] Subject: [PHP-DEV] Re: [PHP-QA] PHP 4.0.6RC1 ready for testing Andi wrote: I rolled 4.0.6RC1. It is ready for testing. http://www.php.net/~andi/php-4.0.6RC1.tar.gz Please everyone take sometime to make sure this is release worthy :) Hurray! :) Successful build on Mandrake 7.1 Basic scripts run w/o issues The gd support in 4.0.6RC1 got a little broken. Building snapshot php4-200105060945 against a copy of gd-1.8.3 with gif support hacked in, php builds fine and phpinfo() shows: GD Support enabled GD Version 1.6.2 or higher FreeType Support enabled FreeType Linkage with TTF library T1Lib Support enabled GIF Support enabled JPG Support enabled PNG Support enabled WBMP Support enabled RC1, phpinfo() shows: GD Support enabled GD Version 1.6.2 or higher T1Lib Support enabled GIF Support enabled JPG Support enabled WBMP Support enabled so somewhere along the line freetype and png stuff got dropped. I'll investigate more shortly. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Re: [PHP-QA] PHP 4.0.6RC1 ready for testing
Andi wrote: I rolled 4.0.6RC1. It is ready for testing. http://www.php.net/~andi/php-4.0.6RC1.tar.gz Please everyone take sometime to make sure this is release worthy :) Hmm. I can't get freetype2 support hooked up. It worked fine in a snapshot from about a week ago. (php4-200105060945) In that snapshot, png support was successful without having to specify --with-png-dir=/usr, thats no longer the case. This is with gd-1.8.3gif installed from source, and the stock freetype2 rpms on redhat-7.1. There were some changes about a week ago to php4/ext/gd/config.m4 involving freetype dir tests (amongst others). Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] default location of php.ini changed?
Sorry if this has already been dealt with, but I just got bit on the ass pretty hard and there's nothing in the bug db about it... the default location for php.ini has been /usr/local/lib for as long as I can recall. An install of a snapshot from this morning puts the default location as /usr/local/etc Was this intended? Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] php.ini location
[Andi Gutmans [EMAIL PROTECTED]] Hi, The default location of php.ini in the current CVS seems to be /usr/local/etc. Didn't we say we're saving this one for 4.1.x? I just got bitten by this and I bet there will be a huge amount of people who will too. I'll change it back. - Stig Phew. : Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP Search
This is the php-dev list. Try the php-general list. http://www.php.net/manual/en/ref.mnogo.php http://www.htdig.org/ -Original Message- From: Manesh [mailto:[EMAIL PROTECTED]] Sent: April 23, 2001 7:57 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] PHP Search i need to search on my site, and on the web, like a radio button or sommingthing -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0 Bug #10100 Updated: php.php has wierd logo!!!!!! Have you been Hacked?
Sorry about the address, or lack thereof. When I run phpinfo(); A wierd logo in the right top corner with a guy that has walrus teeth shows up. Actually, they look like french fries, or pencils maybe. What a hoot! .mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
I'd like to see Midgard do for PHP what Zope has done for Python in the way of increasing the level of penetration of the language. What exactly has zope done for Python? Nothing. The measurement of python's increased penetration as a result of zope can be expressed simply as 'zilch'. This won't happen unless it's easy to install a version of Midgard on top of a standard version of PHP. To suggest that the success of PHP relies on its ability to accommodate apps like midgard is like saying the success of html is directly dependent on, gulp, Dreamweaver. I love PHP, but generally I find the lack of applications such as Midgard a major disincentive to using it. I won't continue using it for long if this continues to be the case. It's already pretty tempting to drop it in favour of Java or Python. There's tons of stuff out there that can mimic midgard, opensource and otherwise. None of them require the level of integration midgard currently enjoys. At best, Midgard belongs in PEAR. It most definitely, IMHO, does not belong in the PHP source. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] ImageMagick module for PHP
Rasmus Lerdorf writes: Because it didn't work, and the ImageMagick library is absolutely horrible. Have a look at the Imlib2 extension. -Rasmus I surprised imlib2 hasn't made it into the php source. It is quite nice. Perhaps its time it graduated. :) .mike On Wed, 21 Mar 2001, [iso-8859-1] Ragnar Kjrstad wrote: Hi I see there is a Image Magick module for php3 but not php4. Why was it removed? Is there any work in progress for reimplementing it? (we need it badly, and will considder joining the development) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0 Bug #9778 Updated: error when compiling with gd
Any ideas of what's the problem? Leave the '/lib' part off the dir-path for some of the items in the configure line: --with-xpm-dir=/usr/X11R6/lib Try --with-xpm-dir=/usr/X11R6 .mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0 Bug #9778 Updated: error when compiling with gd
Man you are FAST! : -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: March 16, 2001 1:56 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] PHP 4.0 Bug #9778 Updated: error when compiling with gd ID: 9778 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Compile Problem Assigned To: Comments: 1. Delete config.cache 2. Remove those /lib parts from the configure options. 3. After configure, 'make clean ; make ; make install' --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] 4.0.5RC1 packaged
Zeev Suraski wrote: http://www.php.net/distributions/RCs/php-4.0.5RC1.tar.gz Do your thing :) Zeev On a stock Redhat-7.0 box, apache-1.3.19/mod_ssl-2.8.1/openssl-0.9.6 all from source: ./configure \ --disable-debug \ --disable-inline \ --with-apxs=/usr/local/apache/bin/apxs \ --enable-exif \ --with-zlib \ --with-mysql=/usr/local/mysql \ (3.23.29a-gamma) --with-pgsql \ (7.0.2) --with-t1lib \ (1.0.1) --with-jpeg-dir=/usr/local \ --with-tiff-dir=/usr/local \ --with-xpm-dir=/usr/X11R6 \ --with-gd=/usr/local \(1.8.3 with gif hacked in) --enable-gd-native-ttf \ --with-mcrypt=/usr/local \ (2.4.9) --with-mhash=/usr/local \ (0.8.3) --enable-ftp \ --enable-wddx \ --enable-sockets \ --enable-sysvshm \ --enable-sysvsem \ --enable-bcmath \ --enable-ctype \ --enable-trans-sid \ --with-pdflib=/usr/local \ (3.0.2) --with-imap=/usr/local \ (imap2000) --with-curl=/usr/local \ (7.4.1) --with-bz2=/usr \ --with-pspell=/usr/local \ (-.11.2) --with-msql=/usr/local/Hughes \ (2.0.11) --with-swf=/usr/local \ --with-iodbc=/usr/local \ (2.50.3) --with-zziplib=/usr/local \ (0.10.6) --with-mnogosearch=/usr/local/mnogosearch \ (3.1.11) --with-sablot \ (-0.51) --with-pfpro=/usr/local (latest beta) ... builds and installs without any trouble. A runthrough of some rudimentary scripting involving functions from most of the extensions shows no problems. If I can additional info please lmk. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] --enable-tiny
Andi Gutmans wrote: I think you're right :) Andi At 05:19 AM 1/27/2001 -0800, jeremy brand wrote: Am I missing something? Can't you just do --without-mysql? In general, if the option is --with-???, use --without-??? to exclude it. If the options is --enable-???, then use --disable-??? to disable it. Jeremy How about --enable-kitchen-sink (or some other name) which builds everything it can find, and --enable-tiny-cgi and --enable-tiny-dso, which builds stripped out php without having to specify anything. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Undefined Versioned Symbol
Go to http://bugs.php.net and read #7711,8774, and 8721. Regards Mike Robinson -Original Message- From: Mark Olbert [mailto:[EMAIL PROTECTED]] Sent: Friday, January 19, 2001 3:24 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Undefined Versioned Symbol I've been having problems getting php-4.0.4 to compile on my linux system; the make keeps breaking when libphp.so is being linked with an undefined versioned symbol name __ns_name_unpack@@GLIBC_2.1 error. I've rebuilt and reinstalled glibc2.1.3, and every library I know of that php depends on, but that didn't solve the problem. I saw a post in the php bug database about the exact same problem which the poster solved by creating a shared version of libbind (which is not supported in the isc.org release of bind). This lead me to run objdump on both libbind.a and libresolv.so.2. Here's what I found: objdump -x /lib/libresolv.so.2 | grep __ns_name: 4424 g F .text 011a __ns_name_unpack 4044 g F .text 01db __ns_name_ntop objdump -x /usr/lib/libbind.a | grep __ns_name: [...snip...] 03e4 g F .text 0105 __ns_name_unpack 0684 g F .text 0063 __ns_name_uncompress 06e8 g F .text 0057 __ns_name_compress g F .text 01ae __ns_name_ntop [...snip...] If I'm reading this correctly (I'm not experienced in programming under linux), this looks like both libresolv.so.2 (a shared library, part of glibc) and libbind.a (a static library, part of bind) are exporting __ns_name_unpack and __ns_name_ntop. Somehow, this does not strike me as a good thing for programs like php, which link against both libraries. Is this potentially the source of my make problem? And, if so, what can I do about it? - Mark [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
