[PHP-DEV] Re: dahlia.dasmoped.net daily run output
these are still being sent to [EMAIL PROTECTED] (perhaps the mail configuration needs to get updated?) jim On Wed, Oct 09, 2002 at 03:06:27AM +0200, Charlie Root wrote: Removing stale files from /var/preserve: Cleaning out old system announcements: Removing stale files from /var/rwho: Backup passwd and group files: Verifying group file syntax: Backing up mail aliases: Disk status: Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 102785471318 874308 8%/ /dev/ad1s4 56047780 50020263 154369597%/mnt/data /dev/ad0s4e 56462940 51615248 33065899%/mnt/data/movies /dev/ad0s2e 20638150 11335860 765123860%/usr /dev/ad0s3e51393426538 446282 6%/var /dev/ad1s2 15240936 13806733 21492998%/mnt/data/movies/eps procfs 44 0 100%/proc Last dump(s) done (Dump '' file systems): UUCP status: Network interface status: Name Mtu Network AddressIpkts IerrsOpkts Oerrs Coll sis0 1500 Link#100:07:95:03:e5:f8 1553 0 2987 0 0 sis0 1500 192.168.1 192.168.1.5 1551 - 2981 - - sis0 1500 fe80:1::207 fe80:1::207:95ff:0 -0 - - rl0 1500 Link#200:50:bf:05:7e:a2 5541003 0 5521626 0 61854 rl0 1500 192.168.2 192.168.2.50 - 107 - - rl0 1500 fe80:2::250 fe80:2::250:bfff:0 -0 - - lp0* 1500 Link#3 0 00 0 0 faith 1500 Link#4 0 00 0 0 lo0 16384 Link#5207191 0 207191 0 0 lo0 16384 localhost ::1922 - 922 - - lo0 16384 fe80:5::1 fe80:5::10 -0 - - lo0 16384 your-net localhost 206249 - 206249 - - ppp0* 1500 Link#6 0 00 0 0 sl0* 552 Link#7 0 00 0 0 tun0 1492 Link#8 5541086 0 5521115 0 0 tun0 1492 fe80:8::207 fe80:8::207:95ff:0 -0 - - tun0 1492 217.82.221pD952DDA0.dip.t 193059 - 252377 - - vmnet 1500 Link#900:bd:40:60:00:010 0 51 0 0 vmnet 1500 192.168.0 192.168.0.1 20 - 87 - - vmnet 1500 fe80:9::2bd fe80:9::2bd:40ff:0 -0 - - Local system status: 3:01AM up 1 day, 9:49, 8 users, load averages: 0.06, 0.05, 0.01 Mail in local queue: Mail queue is empty Mail in submit queue: mailq: illegal option -- A mailq: fatal: usage: mailq [options] Security check: (output mailed separately) Checking for rejected mail hosts: Checking for denied zone transfers (AXFR and IXFR): -- End of daily output -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: sticky perms in CVS?
Wez Furlong [EMAIL PROTECTED] wrote: Am I the only one who is getting their files chmod'ed to read-only every time I do a CVS commit? In particular, main/user_streams.c keeps doing this which is quite annoying - is there some setting on the server side that affects this? (and do we want it switched on?) this happens when someone does a 'cvs watch on'. i'm not sure how (or if) this can be disabled on the server. i've fixed things for now. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: REPOST: PHP 4.2.3 Released
Stefan Esser [EMAIL PROTECTED] wrote: Showed up fine before That is strange because I did not receive it over the list and it is not in the php-dev web archive. http://news.php.net/article.php?group=php.devarticle=88018 jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Problems with PHP.net MX
In article [EMAIL PROTECTED] you wrote: Are there any problems with PHP.net MX? I should host a MX Backup if it is needed. It looks I dont receive my mails anymore, well it takes few hours. (4h...). mail handling is being transitioned to a different machine (and the machine that used to be handling it has had a spotty uptime record the last few days). there may be some more hiccups during this transition. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Problems with PHP.net MX
[EMAIL PROTECTED] wrote: Will we lose the mail or not? That is my _only_ mail right now, that would be so bad :-/ except for a small handful of messages that already bounced because of a little slip-up during the transition, all the messages should make it through, possibly with some delays. (and clearly it is not your only mail -- your php.net address must be forwarding somewhere.) i would further point out that subscribing to php mailing lists using your php.net address only compounds any possible problems or delays. you can post from a non-subscriber address, so there's no compelling reason not to directly subscribe to the mailing lists with whatever address your php.net address ultimately forwards to. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
Yasuo Ohgaki [EMAIL PROTECTED] wrote: Marcus B?rger wrote: We already had some discussion on some IF statements in ini files already. I guess we might call to another mail thread here and hope we find a volunteer. I will not invent any work here since that would be totally useless. I think having a IF in php.ini is good idea. it's too bad we don't have an implementation of a complete programming language laying around. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Sorry! Re: [PHP-DEV] Fwd: REJECTED: 5.1.0.14.2.20020607225328.03df2740@127.0.0.1
Richard S. Blake [EMAIL PROTECTED] wrote: sorry abt that .. an overzealous SPAM filter triggered on your three exclamation points . in your SUBJECT should be fixed now :-S you should further fix your spam system to bounce to the SMTP envelope sender instead of whatever broken thing it is doing now. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] oo != php
Dan Hardiker [EMAIL PROTECTED] wrote: Unless Im missing the mark - for which I appologise. The PHP Group as a whole seems to have mixed feelings on this issue - could there be some form of concensus so that I (and many others on this list) can work out if the requested extra functionality is either ruled out, in for PHP version x, or undecided and under continued debate. I think all sides have made their opinions crystal clear. 'The PHP Group' does not control the vision for what will go into php version x. people actually willing to pitch in and do the work do. 'The PHP Group' has absolutely zero leverage to get anybody to do any work. i think people who think that 'The PHP Group' is some grand leadership council that is plotting the technical direction of the php project would be sorely disappointed if they were to read all of the mail traded over [EMAIL PROTECTED] over the last year. the vast majority of it is dealing with sysadmin stuff, and there was some discussion around adopting smarty as a subproject within the php project (and how we want to handle future projects that ask for that consideration). i can't remember the last time we've had a technical discussion of any real substance on [EMAIL PROTECTED] we've basically moved all of those discussions here. i think the resistance that people think they feel with regard to things like making more php have more oo features has more to do with some developers not willing to be told what features to implement than a notion of those features being a terrible idea. (some of us may think some are a bad idea, but working code can be very persuasive. lots of arguing and handwaving isn't.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Snapshots not build correctly..
Andi Gutmans [EMAIL PROTECTED] wrote: At 09:25 PM 6/5/2002 +0300, Jani Taskinen wrote: On Wed, 5 Jun 2002, Andi Gutmans wrote: At 11:35 PM 6/4/2002 +0300, Jani Taskinen wrote: The source snapshots don't have the bison/flex generated files anymore..why is that? genfiles was broken but I fixed it in HEAD. Is this still not the case? I have no idea how the snapshots are generated..but latest I downloaded yesterday did not have those files. They are probably not generated with makedist then. Anyone know how they are created? ./buildconf --copy (andi, the whole thing is in /local/bin/update-snapshots on va1.php.net. you can do whatever needs to be done to fix it there.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bidirectional Pipe
Kim Saunders [EMAIL PROTECTED] wrote: * am I correct that there isn't a way to do this in PHP at the moment? nope. http://php.net/proc_open jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] one of the php.net machines is down
one of the php.net machines (the one that handles php.net mail, bugs.php.net, hosts.php.net, and various other services) is currently down. we're waiting on word from the folks hosting the machine to find out what's up. hopefully things will be back up and running soon, but it could take until monday to get things sorted out, so please be patient. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RE: [Gallery-users] can't create albums (fwd)
James E. Flemer [EMAIL PROTECTED] wrote: Perhaps this broke it: (it looks like the most recent change to mkdir()) http://cvs.php.net/diff.php/php4/ext/standard/file.c?r1=1.203r2=1.204ty=u I am looking into it. passing a pointer to a mode_t (mode) to zend_parse_parameters(), which uses it as a pointer to long, is probably the cause of the problem. mode should be declared as a long in the function, and cast to a mode_t when passed to VCWD_MKDIR. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] config.w32.h...registry configuration
Zeev Suraski [EMAIL PROTECTED] wrote: We could add it. I just hope people wouldn't start demanding control structures in there to start selectively loading other files... let's just hope that by then, someone realizes we already have a scanner and parser that handles such a language close at hand. :) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: mirrors.inc/countries.inc - Where is it?
Alexander Skwar [EMAIL PROTECTED] wrote: Could somebody please tell me where I can find those files in CVS? I did a checkout of phpweb and then looked for *mirror* and *countr*, but couldn't find it. Is it in a different module? they're generated files, not under cvs control. they just define some arrays -- you can view the files directly at http://www.php.net/include/countries.inc and http://www.php.net/include/mirrors.inc. questions about the php.net sites should generally be directed to the php-mirrors list. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS Account Request
Andrew Heebner [EMAIL PROTECTED] wrote: Would like to contribute and help with existing PEAR modules you need to fill out the form at http://www.php.net/cvs-php.php jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: snaps.php.net
Marko Karppinen [EMAIL PROTECTED] wrote: Even though no sane person can dispute the fact that the frantic pace of PHP3 development warrants fresh snapshot of the venerable scripting environment every three hours, many people feel that the development and especially QA efforts on the 4.2 branch would greatly benefit from snapshot availability. snapshots of the 4.2 branch are now available as php4-STABLE-* from snaps.php.net. snapshots of php3 are no longer available. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bugs: try newer version (?)
James E. Flemer [EMAIL PROTECTED] wrote: Sorry for the confusion. I was not implying in any way that _existing_ bugs be automatically marked as Try Newer Version, I was suggesting that perhaphs _new_ bugs be marked that way if they are submitted with a (very) old release. That seems to be what happens now, but it is done by hand. the bug reporting form already does not allow you to report bugs against versions prior to 4.1.2. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] specifying smtp server on win32 via 5th mail() parameter
as suggested at http://bugs.php.net/10629, the patch below would allow
win32 users to specify the smtp server to use as the 5th parameter to
the mail() function. (the 'pass random options to my sendmail program'
parameter on unix systems.)
any thoughts? (maybe it's better to just use ini_set()?)
jim
Index: ext/standard/mail.c
===
RCS file: /repository/php4/ext/standard/mail.c,v
retrieving revision 1.51
diff -u -r1.51 mail.c
--- ext/standard/mail.c 16 Mar 2002 15:50:20 - 1.51
+++ ext/standard/mail.c 28 Apr 2002 23:27:56 -
-121,7 +121,7
if (!sendmail_path) {
#ifdef PHP_WIN32
/* handle old style win smtp sending */
- if (TSendMail(INI_STR(SMTP), tsm_err, headers, subject, to,
message) != SUCCESS){
+ if (TSendMail(extra_cmd ? extra_cmd : INI_STR(SMTP), tsm_err,
+headers, subject, to, message) != SUCCESS){
php_error(E_WARNING, %s() %s,
get_active_function_name(TSRMLS_C), GetSMErrorText(tsm_err));
return 0;
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] some php.net maintenance this weekend.
i'll be shifting around some of the php.net services this weekend (particularly handling of php.net mail addresses, and bugs.php.net), so don't be alarmed if you're unable to reach some of the php.net sites for a few hours while the dns switches over. (in theory, there won't be any interruption in php.net mail, and i'll try to avoid it for the web services, too. but theory and practice don't always march to the same drummer. :) the mailing lists and cvs shouldn't be impacted at all. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php-dev was stuck.
in setting up php-dev to reject most types of attachments, particularly text/html, (like php-general does), i accidently caused the php-dev traffic to get stuck. everything sent in the last day should start trickling through in the next few hours. (including what will no doubt be at least a few is the mailing list broken? emails -- never send those! just send an email to [EMAIL PROTECTED]) sorry about the inconvenience. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: The PHP Platform
Ken Egervari [EMAIL PROTECTED] wrote: [ ... ] because it really only solves the needs of HTML developers that need some dynamic functionality to their sites. [ ... ] what's wrong with that? more generally, why do you expect the developers of php to provide the tools that you want, instead of the ones that they want? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: The PHP Platform
Ken Egervari [EMAIL PROTECTED] wrote: I actually find your post rather immature as well assuming that I just want free custom tools. I think you need yourself need think to think about software reuse and improving productivity. It's an important software issue now as it was 20 years ago and I don't see PHP making any leaps towards that. I'm merely stating that it should start to play catchup now, especially with PHP 5 being in development. i didn't assume you wanted free custom tools. i guess i overstated my point a bit. let me try to rephrase: why should we work on your grand vision for php's future, instead of the one that we are already collectively following? keep in mind that the following are tremendously lousy reasons: 1. sun and microsoft are doing it. 2. people who aren't already using php won't use php if we don't. 3. people already using php won't use php anymore if we don't. i think you need to learn more about how an open source community functions. how it sets priorities, how it communicates, and how it achieves progress. your we-must-do-this sort of diktat is a futile approach. as to my own feelings of the value of reuse and improving productivity, perhaps i see more value in reusing the components available in the java and .net platforms through technologies like soap, ext/java, and ext/dotnet, rather than cloning them in php. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: The PHP Platform
Ken Egervari [EMAIL PROTECTED] wrote: Usually that if it ain't broke, don't fix it attritude is just the thing to make a technology less and less useful and eventually it'll be antiquated. Eseentially, it is already is. Don't get me wrong, just because it's out of date doesn't mean it still isn't useful. I just think that even in an opensource community, there would be leaders and people looking towards the future. so, should we gather the cardinals and elect you pope now? Like I said, I think its time PHP started moving forward and developed a new vision for itself and the community. yes! the new build system that sascha introduced wasn't a move forward. stig (and the large cast of others) working on building the pear infrastructure aren't moving forward. rasmus is standing firm as he looks at integrating the gd library more tightly into php. andi (and others) are blocking progress with all that work on the new zend engine. i wish derick and jani would stop building things like the build tracker at qa.php.net to make the qa process go smoother. i wish yasuo would stop working on the postgresql and session extensions and just give it a rest. that crazy andrei, creating things like the aggregate and overload extensions -- he needs to stop holding us back! don't get me started about wez and all that damn streams stuff! (do i need to continue?) people *are* looking forward. they're leading with code. what do you think we're doing here? waiting around for someone to tell us what to do? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php4 /sapi/apache config.m4 /sapi/apache2filter config.m4
Jani Taskinen [EMAIL PROTECTED] wrote: sniper Fri Apr 12 18:59:07 2002 EDT Modified files: /php4/sapi/apache config.m4 /php4/sapi/apache2filterconfig.m4 Log: - Added checks to prevent building the DSO with wrong configure option. woohoo! but what about --with-apache? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Let's fork GD!
Rasmus Lerdorf [EMAIL PROTECTED] wrote: I propose that we roll the GD library into PHP, apply the various outstanding patches and default to building from the bundled library much like we do with MySQL. I think GD is a popular enough extension for PHP that it would be extremely cool to have decent truecolor GD2 support available for everyone. And we could go in and fix a couple of really annoying aspects as well as give the various graphics nuts a bit of a playground to come up with cool stuff. +1. big +1. what would be nice is to also clean up some parts of the api. specifically, all the duplication that came about to load different image and font formats. it would be really nice to hide all of those behind a simplified interface that either sniffed out the file type automatically, or allowed it to be specified as a parameter. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: modified base64
Marcus Boerger [EMAIL PROTECTED] wrote: After (v)spprintf i have another modified function here: base64url_(en|de)code I sometimes transmit binary data or thinks like session ids over http. when using base64 the problem is in the chars '+', '/' and '='. So i changed base64 to use '-', '_' and '!' instead. interesting thought, but then that isn't base64 encoding. you forgot rfc1341: http://www.fourmilab.ch/webtools/base64/rfc1341.html jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ext/standard/dl.c: DL_ERROR()
is DL_ERROR() something that is normally defined? the patch to add Mac OS X support changed the GET_DL_ERROR() macro to call this instead of dlerror(), which broke the build for me on debian/unstable. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] should ZEND_FETCH_RESOURCE return false or null on failure?
http://bugs.php.net/15153 shows the resulting fun from this distinction. yes, the user should be checking the result of opendir(). unfortunately, the examples in the documentation didn't. (which i've fixed now.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.1.3?
i know that 4.2.0 is due in a few weeks, but would it be worth kicking out a 4.1.3 that has support for the recent apache 2 release? (or just pushing up the 4.2.0 release? is there anything holding back the release besides some arbitrary timeline?) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c basic_functions.h
Andi Gutmans [EMAIL PROTECTED] wrote: I don't think having a function which outputs an uploaded file is useful. So please only implement one which returns the file. wouldn't it be most useful to have a function that just *opens* the uploaded file, so people can use fpassthru() or fread() or fgets() or fgetss()? (or even just make it so that when safe mode is on, it is smart enough to allow opening files that were uploaded without doing the uid check?) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c basic_functions.h
okay, so then what is the point of adding a new function to read an uploaded file? it sounds like the original justification was completely off-base. the original patch said: I created function `read_uploaded_file()`, i think it is useful at to work with uploaded file in safe_mode and open_basedir, because if i need only file content and safe_mode=on or open_basedir is set, i can not read file, i must move it, read and delete then. (http://news.php.net/article.php?group=php.devarticle=81624) i hear from you and stefan that this is wrong. so what's the point of this new function? and if this isn't entirely wrong, i think we would be better off fixing safe_mode and open_basedir to allow opening uploaded files rather than adding a special function for this. jim On Sat, Mar 23, 2002 at 09:45:28AM -0800, Rasmus Lerdorf wrote: That's already the case though. On 23 Mar 2002, Jim Winstead wrote: Andi Gutmans [EMAIL PROTECTED] wrote: I don't think having a function which outputs an uploaded file is useful. So please only implement one which returns the file. wouldn't it be most useful to have a function that just *opens* the uploaded file, so people can use fpassthru() or fread() or fgets() or fgetss()? (or even just make it so that when safe mode is on, it is smart enough to allow opening files that were uploaded without doing the uid check?) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c basic_functions.h
Andrew Sitnikov [EMAIL PROTECTED] wrote: RL Yup, as far as I can see it is a completely useless function other than RL the fact that it reads an entire file into a string. This is actually RL something we should add, but it should be a generic load_file() or RL str_file() or some other such function. RL -Rasmus Probably you have not understood a problem, if is used open_basedir or safe_mode you have no any possibility to read a file until you move it in directory which you may read it. but this is where you are (at least partially) wrong. if safe_mode is set, you are still able to open an uploaded file. however, from a brief code inspection, it looks to me like you may not be able to open it if open_basedir is set. assuming i've read things correctly, this is a arguably a bug, not a reason to introduce a new function. (it also looks to me like safe_mode_include_dir and open_basedir may not get along nicely.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RELEASE_PROCESS text file
we should either ditch this file, or update it to reflect the current process. (i'd almost prefer we just replace it with an entirely new document, perhaps based on derick's email[1], so we can have the document not be GPL'd, which is just silly.) one way i'd amend the process, relating to the use of cvs tags: the current 4.2.0 (4.2.x?) branch was tagged as 'PHP_4_2_0'. this means that the actual 4.2.0 release will need to use some other tag. the way i'd like to see it done is for the branch tag to look something like BRANCH_PHP_4_2 (yes, with 'BRANCH_' in the name. it makes it drop-dead easy to tell what is a branch, and what is a release tag) with release tags of the form PHP_4_2_0_RC1, PHP_4_2_0, PHP_4_2_1_RC1, etc. (all lowercase would be fine, too, and would match most of the existing tags.) i really don't want to stir up the versioning debate again. if we're doing three-digit branches and patch-level releases, adjust the suggested tag names accordingly. i think the whole release process could be tightened up, to boot -- i don't see why there needs to be any delay between branching for the release and kicking out the first release candidate. i don't think it significantly changes the odds that the first release candidate will be the only release candidate (which are near zero, in either case), but i think that having a downloadable tarball is always going to attract more testers. jim [1] http://marc.theaimsgroup.com/?l=php-devm=101545438113053w=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] getting the path to the php executable
On Mon, Mar 18, 2002 at 05:56:02AM +0100, Marcus B?rger wrote: At 05:11 18.03.2002, you wrote: is there a way to get the path of the current php executable for the cli and cgi sapi implementations? this would be nice so that run-tests.php could run its subprocesses with the same executable that it was run with (so you could run the tests with a particular php executable without having to make sure it is the one that the code inside run-tests.php picks up). In CLI you can pass that information from command line $ /t/php-cvs/php -r 'echo $argv[1];' -- `(pwd)` /home/marcus this is not what i was looking for. i'm looking for the equivalent to perl's $^X (or $EXECUTABLE_NAME for people that like to 'use English'). (this would be the '/t/php-cvs/php' from your example.) if that is a needed feature we better implement a useful solution. But is it really necessary? i don't expect that would be a widely-used feature, but for the specific case i've outlined (running tests using the same php binary from the run-tests.php script), it would be useful. i'm sure there are more instances in which it would be useful information. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: README.SUBMMITING_PATCH
Zeev Suraski [EMAIL PROTECTED] wrote: Maybe a small online interface for proposing patches (and not losing them) would bring some order to this mess, but then again, it may be an overkill. someone was preparing a patch for the bug databases so it could handle file attachments. i don't know what happened with it. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 1 byte overflow in wordwrap
Wez Furlong [EMAIL PROTECTED] wrote: I'll see if I can force it to happen in isolation. are you passing a fourth parameter to wordwrap? the easiest way to track it down would be to insert some debugging statements in the wordwrap() function to print out the text being wrapped, the newtextlen that gets calculated, and then value of newtextlen at the end of the function. (this code is all new since 4.1.x, so this particular bug likely does not exist in those versions. the old implementation has an entirely different set of bugs. :) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 1 byte overflow in wordwrap
On Mon, Mar 18, 2002 at 12:34:12AM +, Wez Furlong wrote:
debug(wordwrap: char= . ord($char) . cut= . $cut);
you must be using a multi-character linebreak (probably \r\n).
otherwise the allocation that is being overflown would not be made
('cause it is in the multi-character-line-ending or forced cut path).
what line length are you wrapping to?
jim
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] getting the path to the php executable
is there a way to get the path of the current php executable for the cli and cgi sapi implementations? this would be nice so that run-tests.php could run its subprocesses with the same executable that it was run with (so you could run the tests with a particular php executable without having to make sure it is the one that the code inside run-tests.php picks up). jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main network.c
Yasuo Ohgaki [EMAIL PROTECTED] wrote: Feel free to shoot me showing including stddef.h confirms ANSI C standard :) the gnu c library documentation indicates that stddef.h and ptrdiff_t are part of the ansi c standard. http://www.aquaphoenix.com/ref/gnu_c_library/libc_483.html jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] setup.stub files
do these files serve any purpose any more, or are they just leftover remnants from the old setup script? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] odbc_execute's file-opening hack
torben's checkin to the documentation reminded me -- why is this gross hack in there, instead of just allowing open filehandles to be passed? the special treatment of strings that begin and end with single quotes just seems like a huge 'wtf?' sort of feature. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Have you seen the PHP audit project?
David Eriksson [EMAIL PROTECTED] wrote: I just read about the PHP audit project on NewsForge. More info here: http://phpaudit.42-networks.com/ Their patch looked great to me, although I didn't browse through all of it... :-) it's unfortunate that they're auditing 4.1.2, instead of the CVS HEAD (or the 4.2 branch). there are definitely parts of that patch that will not apply. a lot has changed since 4.1 branched a zillion years ago. but it is very nice to see someone taking on the task of tightening things up. it is a little annoying to read things in their mailing list archive like One probably exploitable buffer overflow has been fixed, as well as a format string vulnerability. thanks for the heads up, guys. it would be nice if they were feeding us these patches in manageable chunks. one giant patch is unlikely to be accepted quickly. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ||=
Andi Gutmans [EMAIL PROTECTED] wrote: For some reason this doesn't exist in other languages like C++ and Java. I don't object to adding this as long as their is no good reason why those languages didn't support these. What do other people think? i think, given that php's || and operators always return a boolean value, people are going to be confused and disappointed with ||= and = when coming from languages (like perl) that implement them as returning false or the value that was true. that is, the perl idiom: $value ||= $some_default_value; wouldn't behave as someone familiar with the perl behavior would expect, just like: $value = $user_value || $some_default_value; doesn't. (that said, i've always been +1 on making the behavior of || and be like perl does it. it is far more useful than merely returning the boolean value of the expression.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: CVS history file?
Sean R. Bright [EMAIL PROTECTED] wrote: Just wondering if I am wrong (that is, I didn't use cvs history before and I am mistaken) or somehow the history file is truncated/corrupted/removed/etc. the cvs history file is being rotated (it had grown to enormous proportions over the life of the project). i don't know how to get the info you're looking for. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Zend License
Eric Thelin [EMAIL PROTECTED] wrote: I read a few months ago that the zend engine was changing its license to a BSD-style license. But I have heard nothing about it since and the license file still states that it is released under the QPL. So my question is when will this change take place. I know some of some resistance to using PHP until this change takes place. Has a specific license been chosen? Wouldn't it be simplest to just release it under the PHP License. check Zend/LICENSE in the 4.2 and HEAD branches. (the license is basically the same as the PHP license, which is also a BSD-style license.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard image.c php-master-web/fetch mirrors.php
Markus Fischer [EMAIL PROTECTED] wrote:
Index: php-master-web/fetch/mirrors.php
diff -u php-master-web/fetch/mirrors.php:1.1 php-master-web/fetch/mirrors.php:1.2
--- php-master-web/fetch/mirrors.php:1.1 Fri Sep 21 15:01:08 2001
+++ php-master-web/fetch/mirrors.php Thu Mar 7 19:57:07 2002
@@ -7,7 +7,7 @@
// Connect and generate the list from the DB
if (@mysql_connect(localhost,nobody,)) {
if (@mysql_select_db(php3)) {
-$res = @mysql_query(SELECT * FROM mirrors ORDER BY cc);
+$res = @mysql_query(SELECT mirrors.*,country.name AS cname FROM mirrors LEFT
JOIN country ON mirrors.cc = country.id ORDER BY country.name,hostname);
if ($res) {
echo ?php\n\$MIRRORS = array(\n;
while ($row = @mysql_fetch_array($res)) {
Was it intended to let this slip through ?
funny. that was actually something i checked in. i guess the logging
scripts got confused with the simultaneous checkins.
jim
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New Build System Committed to HEAD
Marcus Börger [EMAIL PROTECTED] wrote: Very nice new build system much faster the only thing what's left on that is .o in all .cvsignore cvs ignores .o files by default, it isn't necessary to list them in the .cvsignore file. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: New function (repost from php-cvs)
Marcus Boerger [EMAIL PROTECTED] wrote: what about a new function called strnlen str*n*len which will return the length of a string with a given maximum to avoid problems with strings not zero terminated. why not just use memchr()? jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / loginfo
Sebastian Bergmann [EMAIL PROTECTED] wrote: Are php-cvs subscribers automagically subscribed to the new list? no. (an announcement will be going out shortly.) What about TSRM? it's still going to php-cvs. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zend checkins now going to zend-engine-cvs@lists.php.net
checkins to the Zend Engine related modules (Zend, ZendEngine2, ZendAPI) are now going to the [EMAIL PROTECTED] mailing list (and php.zend-engine.cvs newsgroup on news.php.net). you can subscribe to the list at http://www.php.net/mailing-lists.php or by sending a blank email to [EMAIL PROTECTED] jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: patch upload in bugs
Robin Ericsson [EMAIL PROTECTED] wrote: The current bugsystem is not very patch friendly. And as I see it browsing through the bugs, patches are often simply ignored without even tell the submitter what they can do to fix it up. patches to add this to the bug system would be greatly welcomed. jim (is this answer too cute? :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 4.2.0 CLI
In php.dev Edin Kadribasic [EMAIL PROTECTED] wrote: 1. If you compile CGI binary and then issue 'make install' it will be installed in $PREFIX/bin, then CLI will be put in the same place overwriting it. Any suggestions on what to do in this situation? imho, the cgi binary should get called php.cgi. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Apache2 and PHP CVS from today
August [EMAIL PROTECTED] wrote: As far as I know httpd2 still allows static modules. yes, but the --with-apache option for php4 tries to compile a static version of php4 for apache 1.x. maybe someone will create a --with-apache2 option that allows compiling a static version of php4 for apache 2.x. until that happens, the only way to compile php4 with apache2 is to use --with-apxs2, which compiles php4 as a dso. the fact that --with-apache does not work with apache 2.x is not a bug. the --with-apache option is specific to the sapi module for apache 1.x. the sapi module for apache 2.x is a different beast altogether. (in the meantime, it would be nice if someone made it so that the --with-apxs and --with-apache options errored out if someone tried to use them in conjunction with apache 2.x.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FWD: possible bug in date() function
Yasuo Ohgaki [EMAIL PROTECTED] wrote: Chris Newbill wrote: Ehh...from manual n - month without leading zeros; i.e. 1 to 12 So yeah it would print 2th. Cause today is the 10th. The format does not make sense much, though. sure it does. the 'bug' reporter had a bogus date format. $date = date(H:i D, nS M Y,$buffer['Last_access']); 'nS' means 'month'.'daysuffix'. (so on february 10, you would get '2th'.) they really wanted 'jS'. the documentation wasn't clear that 'S' pertained to the day of the month. i've checked in a clarification. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.0 Bug Summary Report
Edin Kadribasic [EMAIL PROTECTED] wrote: Could someone please remove duplicate bug reports from the summary. There are dozen reports saying scripts run from CGI output #!/usr/local/bin/php line, an issue which is solved in the current CVS. i added 'Duplicate' to the list of statuses that are excluded from the bug summary. (and yes, the way that status is currently used is confusing.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Case sensitivity: Conclusion(?)
Yasuo Ohgaki [EMAIL PROTECTED] wrote: I guess the original reason why PHP has case insensitive class/function names is consistency with HTML standard. If so, XHTML _is_ case sensitive, we should go for case sensitive names. although only rasmus can say for sure, i'd say you are assuming way more thought went into the original decision than actually did. case-insensitive function names are easier for developers. personally, i don't think any of the arguments for making function names case-sensitive hold water. (it also happens to allow a sidestepping of one of the coding standard battles -- studlyCaps or LeadingCaps or nocaps?) while i want to commend you for your cleverness in using the bug database voting system to collect opinions about this issue, i think it may be worth making clear that any such voting is not likely to be considered binding by anyone. (democracy is an extremely poor way to design software.) jim (who only has a passing relationship with his shift key, so who really cares what he thinks, anyway. :) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug system feature request
you might want to add these suggestions to this related feature request: http://bugs.php.net/bug.php?id=14815 jim -- PHP Development Mailing List http://www.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] new bug viewing/editing form
as threatened after i implemented bug voting, i've redesign the bug viewing/editing form. thanks to some of the fine folks from the php-qa list, it's already been tested against most common browsers, and enough people complained about the netscape 4 rendering that i applied some tweaks that have made it more tolerable. unless i hear some loud screams, i'll go ahead and commit this in a day or two. (the rest of this mail is the same as what i posted to php-qa a few days ago, for the benefit of php-dev folks.) you can see the new look here: http://bugs.php.net/~jimw/bugs/bug.php?id=14841 (that's just a test bug i opened which you can feel free to add comments to and otherwise mess with. don't worry, this version is hardcoded to just send the mails to me for now.) screenshots from mozilla 0.9.7 on linux, so you have some idea of how it is supposed to look: viewing a bug: http://bugs.php.net/~jimw/view.png adding a comment: http://bugs.php.net/~jimw/add-comment.png (oh, did i forget to mention anyone can add comments to a bug? :) changing the bug (developer, logged in): http://bugs.php.net/~jimw/developer-logged-in.png changing the bug (developer, not logged in): http://bugs.php.net/~jimw/developer-not-logged-in.png changing the bug (submitter, logged in): http://bugs.php.net/~jimw/user-logged-in.png changing the bug (submitter, not logged in): http://bugs.php.net/~jimw/user-not-logged-in.png the success page from any submission (modulo different text): http://bugs.php.net/~jimw/updated.png i also tweaked the submission form just slightly to change how error messages were displayed. you can see a sample here: http://bugs.php.net/~jimw/incomplete-bug.png let me know what you think, or if what you see doesn't roughly approximate what it is that i see. (i know that opera's fieldsets don't look as cool as mozilla's, so the voting form looks less pretty on opera.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: new bug viewing/editing form
Manuel Lemos [EMAIL PROTECTED] wrote: Jim Winstead wrote: as threatened after i implemented bug voting, i've redesign the bug Congratulations! Voting is an excellent idea that will help developers to sort out the priorities of what bugs should be fixed first. Just a couple of comments: the voting has been there for a week or so, actually. it is just hard to notice on the current page because wide comments cause it to get pushed way off to the right. - Voting does not work on Opera 5.05 for Linux. When you submit the vote, it fails with the message missing parameter score. it's a bug in opera. http://bugs.php.net/~jimw/bugs/opera-broken.php but because of the order of the fields on the new page, this bug doesn't get triggered there. - Assuming that the number of votes may influence in the priority that developers will give to fix each bug, it seems easy to mislead developers because somebody that realizes that may submit a bunch of votes just to make it outstand in the pending bug queue. I suggest that you adopt an authentication scheme like bugzilla, that requires submitters to subscribe confirming the subscriptions by e-mail. This way, multiple votes from the same subscriber would only count as one. i really, really do not want to force people to register and deal with all that. if abuse of the voting system becomes a problem, we'll figure out a way to deal with it at that time. (the voting does track the ip of submissions, so that is one easy filter that can be applied.) i have my doubts that the voting will really prove all that useful in cajoling developers to work on specific bugs. i suspect it will be more useful in getting users to notice bugs that have already been reported. (and it is a safety valve for preventing 'me too!' comments now that anyone will be able to add a comment to a bug.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: new bug viewing/editing form
Manuel Lemos [EMAIL PROTECTED] wrote: Jim Winstead wrote: - Voting does not work on Opera 5.05 for Linux. When you submit the vote, it fails with the message missing parameter score. it's a bug in opera. http://bugs.php.net/~jimw/bugs/opera-broken.php but because of the order of the fields on the new page, this bug doesn't get triggered there. What do you mean? I just noticed that it still causes the problem above. i mean there is a bug in opera that causes voting to fail on the existing bug viewing/voting/editing page (where the voting stuff is in a box that is floated to the right of the bug header). in my testing, the bug in opera is no longer triggered by the new version of this page (where the voting form is below the bug header). regardless of whether the new version triggers this bug in opera or not, it remains a bug in opera. i'm not going to spend any more of my time figuring out how to work around it. i really, really do not want to force people to register and deal with all that. if abuse of the voting system becomes a problem, we'll figure out a way to deal with it at that time. (the voting does track the ip of submissions, so that is one easy filter that can be applied.) hummm... I was able to vote on the same bug several times in a row and it counted. Are you sure that IP filter is working? there is no filter. the ip is only being tracked at this time. Anyway, that is easy to work around, especially because the source of the page is available, and who intends to fool the system will always find a easy way to do it. of course. that's why i am sticking with the path of least resistance. if the existing bug-voting system proves to not be useful (because of people stuffing the ballot box, or not voting, or whatever), we can always change it (slightly or dramatically). but until that happens, i see very little reason to change it. i have my doubts that the voting will really prove all that useful in cajoling developers to work on specific bugs. i suspect it will be more I think it will help the QA time to concentrate on bugs that seem more urgent, if the vote system can work reliably. my doubts come from a long time of watching developers of php work on what they want to work on, without a great deal of concern for what it is that users want. i don't see any reason to believe requiring people to register to vote on bugs will change that situation. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard basic_functions.c math.c php_math.h /ext/standard/tests/math pow.phpt
Sebastian Bergmann [EMAIL PROTECTED] wrote: jim winstead wrote: jimwFri Jan 4 22:45:11 2002 EDT Modified files: /php4/ext/standard basic_functions.c math.c php_math.h /php4/ext/standard/tests/math pow.phpt Log: Fixed pow(), and added finite(), isinf(), and isnan(). Also fixed pow() tests. This breaks the Windows build: bleah. looks like these functions need a configure check (and to be disabled on win32), or given an alternate implementation. i'll give it another look tomorrow. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard string.c /ext/standard/tests/strings wordwrap.phpt
Andi Gutmans [EMAIL PROTECTED] wrote: If you need to use something like strncat()/strncpy() you should use strlcpy()/strlcat(). We changed to these functions a couple of years ago. in the case of wordwrap(), it is only copying part of the source string, so strlcat() wouldn't do the job. i figured it'd be more confusing to mix calls to strncat() and strlcat() in the same function than to just use strncat() consistently. the destination buffer is verifiably large enough to handle all of the strncat() calls. (now, i did think of keeping track of the current position in the destination buffer and using memcpy(), but it seemed like overkill. the size of the new buffer could be calculated more intelligently, too, by taking into account the requested line length and size of the original text to figure out the maximum number of breaks that will be inserted. but that's all optimization. i was mainly out to fix the segfault.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard string.c /ext/standard/tests/strings wordwrap.phpt
On Sat, Jan 05, 2002 at 08:22:24PM +0200, Andi Gutmans wrote: You're missing the point. In order to minimize the amount of API misuse of the str*cat() family of functions we decided only to use the ones I mentioned, everywhere. I am sure that you're code is correct but all places should use strlcat()/strlcpy() if they are using the str* family of functions. in all due respect, i think you're missing my point. wordwrap() copies chunks from the middle of the source string to the end of the destination string. neither strlcpy() nor strlcat() is useful in this situation, because all they take is the length of the destination buffer, not a length of characters to copy from the source. char *source = this is my string; strncpy(dest, source+5, 5); // copy 'is my' to dest. i guess you could use strlcat() if you kept track of the current end position of the destination string and then lied about the size of the destination string so only the right number of characters were copied from the source, but that seems a rather obtuse way to do it. in any case, i'm working on a memcpy()-based rewrite. i don't know that it is really useful for wordwrap() to be binary-safe, but that will be one of the side-effects. :) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard string.c /ext/standard/tests/strings wordwrap.phpt
the test using the old code finally finished. it took almost 14 minutes.
(the new code takes 0.8 seconds. i'd say it's an improvement.)
jim
On Sat, Jan 05, 2002 at 11:02:51PM +0200, Andi Gutmans wrote:
Nice!
At 08:46 PM 1/5/2002 +, jim winstead wrote:
jimwSat Jan 5 15:46:45 2002 EDT
Modified files:
/php4/ext/standard string.c
/php4/ext/standard/tests/stringswordwrap.phpt
Log:
New memcpy()-based wordwrap() implementation. The simple case
(single-character break, no forced break) appears to be about 60%
faster, and there's simply no comparison for non-simple cases with
non-trivial amounts of text. The old algorithm was O(n^2) (with an
unfortunately large constant factor) because of the use of strncat(),
the new one is O(n). Added some more tests, too.
@ - Made wordwrap() significantly faster. (Jim)
# test case: $t = join('',file('ChangeLog')); $w =
wordwrap($t,10,\n,1);
# new code completes in less than a second. i'm still waiting for the
# old code to finish.
--
PHP Development Mailing List http://www.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 #14879 Updated: ereg_replace incorrectly functioning
On Sun, Jan 06, 2002 at 01:14:23AM +0100, Markus Fischer wrote: On Sun, Jan 06, 2002 at 12:05:45AM -, [EMAIL PROTECTED] wrote : ereg_replace is behaving as designed, more or less. the behavior of an empty first parameter is undefined (although with the bundled regular expression engine, it will leave the string unchanged and display an error message). To me its quite defined. You get REG_EMPTY warning and the return value is false (at leat, since 4.0.6). it depends on the regex library used. the bundled one returns REG_EMPTY, various system regex libraries may behave as the bug reporter saw. if we want to define one, we should be checking it ourselves. (i suppose it may be defined by POSIX. in any case, we leave it up to the regex library used to interpret the pattern as it sees fit to do. preg_replace() obviously has a more well-defined behavior, since there's only one implementation of the PCRE library. and as i pointed out in my comment to the bug, it behaves as the bug report says ereg_replace does on that system.) jim -- PHP Development Mailing List http://www.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] adding finite(), isnan(), isinf()
these are the standard C library names. are people going to insist they be phpified? is_finite() is_nan(), is_infinite()? jim -- PHP Development Mailing List http://www.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] ext/standard/type.{ch}
this appears to be a set of rather orphaned functions. nobody includes the header, and nobody calls the functions. any objections to me moving the is_*() and other type-related functions in there (out of the mondo-cluttered basic_functions.c)? i'm also going to split the guts of is_numeric() out into a helper function. actually, this may even be a useful part of the zend api, as a complement to is_numeric_string. ZVAL_IS_NUMERIC()? jim -- PHP Development Mailing List http://www.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] speaking of PHP 5
if anyone is stumped for ideas for features for php 5, it may be worth trawling through the 428 open feature requests at bugs.php.net. (that's more than a third of the total open bugs for php4. there's an obvious opportunity to beef up those bug-closing stats!) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: PHP 5
Andi Gutmans [EMAIL PROTECTED] wrote: The Zend Engine 2 has made lots of progress. is there an up-to-date summary of the changes beyond the original ze2 proposal? example scripts that show the new features? Unrelated, I'm still waiting to hear exactly what mechanism the PEAR guys implemented for PECL. I know that if it's not a really cool easy to use mechanism I would prefer to wait until we write one. One of the main strengths of PHP is that everything is bundled together and is easy to setup. We shouldn't make it much harder on people. Although we're planning on only move the unimportant extensions out of PHP I still think it should be extremely easy to get a list of available extensions (maybe even a part of the ./configure process) and to easily download/configure/install them. having everything bundled is a strength for people who install from source, but it really doesn't do much to help people who haved installed from a distribution or are in a shared-hosting situation. those are the places where something like perl's cpan really shines (and where the pear/pecl stuff presumably will too). i'd really love to see the existing pear/pecl stuff brought out into the open more, even if it is not fully baked. i think the fact that it is relatively hidden makes it extremely difficult for people to know where things are headed, how close (or far) they are, and how to help. (and 'unimportant' is a dangerous word. obviously that depends on the situation.) jim -- PHP Development Mailing List http://www.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: Moving extensions to PECL
On Tue, Jan 01, 2002 at 04:05:18PM +0100, Martin Jansen wrote: On 31 Dec 2001 19:18:59 -, Jim Winstead wrote: Jon Parise [EMAIL PROTECTED] wrote: Are there any well-founded objections to this (either in practice or principle)? no objections, but one thing that should be considered is what happens to the documentation for these extensions The documentation of the extensions can be easily merged in the peardoc repository. Right now there is no automated build for the manual, but you promised to help us with that in 2002, no? :-) yes, yes, i'll get to it. but i don't see how moving the documentation from the phpdoc repository to the peardoc repository improves the situation at all. (in fact, it will make it slightly worse. the pear website is not mirrored, and i don't think it is even mirrorable.) i was thinking more along the lines of something that allowed the documentation for an extension to be managed on its own, just like we're allowing the extension itself to be. and then some additional mechanism that allows the documentation for extensions to be plugged into the main documentation. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Built-in SOAP based Web Services support (was Re: PHP 5)
Manuel Lemos [EMAIL PROTECTED] wrote: One thing that I think it is really vital to prevent PHP to leak even more users to other languages is to have built-in support for consuming Web services. http://aspn.activestate.com/ASPN/WebServices/SWSAPI/phptut yes, that's not built-in. but dealing with xml in c is a grotty, not-very-fun task. so not fun that i wouldn't hold my breath waiting for a built-in implementation to materialize because someone decided to knock one together. like the xmlrpc implementation now included with php4, i suspect you'll have to wait for some corporate interest to decide they need a high-performance soap implementation for php before one shows up. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Moving extensions to PECL
Jon Parise [EMAIL PROTECTED] wrote: Are there any well-founded objections to this (either in practice or principle)? no objections, but one thing that should be considered is what happens to the documentation for these extensions when they are no longer a part of the core distribution. (and i won't claim to have any answers to that.) jim -- PHP Development Mailing List http://www.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: Moving extensions to PECL
On Mon, Dec 31, 2001 at 08:12:25PM -, James Moore wrote: The QA Teams job needs to be made as easy as possible, at the moment those people still working activly on QA a lot have a very hard time balancing time between testing for new bugs, localising and fixing bugs as well as making sure releases are up to scratch and new bugs arnt introduced. Anything to make their job easier is a big plus. right. i think that moving extensions out of the core will make things easier on both ends -- new releases of the core can go out without having to wait on lesser-used extensions to be tested (or go out with buggy lesser-used extensions), and new releases of those extensions can be made on their own schedule. someone fixed a major bug in pear/PECL/cybermut? run the regression tests and do a release. no more waiting three months for a release of the core to be put together. look at the current situation with the mnogosearch extension -- 4.1.0 and 4.1.1 don't support the latest mnogosearch api. it will probably be at least three months before a distribution of php that does is released. if mnogosearch were a part of PECL, a new version could be released and usable with the existing core distribution whenever its developers thought it was ready. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: CVS Account Request: bradmssw
Brad House [EMAIL PROTECTED] wrote: I have written an extension to php for the MCVE engine. It can be loaded as a module or compiled into the code base, and would like to have it distributed with PHP. I would need commit access in order to maintain the module. The product, MCVE is a credit card processing engine similar in purpose to RedHat's CCVS or CyberCash's ICVerify. Though RedHat's CCVS has been discontinued. And MCVE is the only replacement product for Linux/UNIX systems. would this sort of thing go into pear/PECL or php4/ext these days? (i guess brad wants php4/ext, but i'm looking for other opinions.) jim -- PHP Development Mailing List http://www.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] change to cvs access control
in the continuing effort to make things a little easier for those of us who have to deal with administering things for the php project, i've rejiggered the way the cvs access control works a little bit. nobody should have lost access to anything they had access to before, but if you find yourself getting the old 'insufficient karma' message, just drop a note to [EMAIL PROTECTED] and we'll sort things out post-haste. apologies in advance for any inconvenience. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: news.php.net seems to be down
Colin Viebrock [EMAIL PROTECTED] wrote: I can't get to it either through the web, or through NNTP. that machine appears to be having some performance problems. i've been planning to move the news server to our second machine at pair, but i'm waiting for them to resolve some networking issues with those machines. (which makes the network performance roughly inversely proportional to what it should be. i get better connection speeds from my home machine than from the second machine on the same local network. :) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug-updates
Derick Rethans [EMAIL PROTECTED] wrote: Any idea why bug postings / updates are not longer posted to this list? they were being held up by the spam protection. they should make it through now (and the ones sent in the last few days should start showing up soon). jim -- PHP Development Mailing List http://www.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] [ADMIN] spam protection for lists.php.net lists
as some of you may have noticed over the last few days, a new method of spam protection has been implemented on lists.php.net. if you post to one of the lists.php.net lists (via mail or the news server at news.php.net) from a mail address that is not subscribed to the mailing list, you will receive an email with information on how to confirm that you are a real person trying to send mail to the list, and not just some drive-by spammer. once you have responded to the confirmation, your original message to the list will be let through to the list, and your email address will be stored as one that is allowed to post so that future postings from you to any of the lists.php.net lists will be passed through without requiring confirmation. note that this means it is no longer possible to post to the list using an invalid smtp sender (or using an invalid email address in the 'From' header of a post via the news server). if you encounter problems posting to the list, feel free to drop a note to the list administrators at [EMAIL PROTECTED] jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: PHP 4.0.1 released?! (RE: [PHP-CVS] cvs: php4(PHP_4_0_7) / configure.in /main php_version.h )
Mårten gustafsson [EMAIL PROTECTED] wrote: Shouldn?t this be announced somewhere? i suspect that zeev is giving the mirrors some time to catch up (and perhaps putting together the win32 version of the release) before sending the announcement. be patient. jim -- PHP Development Mailing List http://www.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 #14305 Updated: type-o on web site
In php.doc Mike Robinson [EMAIL PROTECTED] wrote: I found the comments by [EMAIL PROTECTED] quite sad and pathetic. Good thing that crap like this rolls off us like water off a duck eh? i wouldn't be so sure. i think one thing that drives people away from open-source projects is the long-term accumulation of negative vibes, since the positive ones are relatively few and far between. (no, i'm not fishing for praise. just be sure to drop someone a quick note of thanks next time they help you out with something, or do something that benefits you. i know that i neglect to do this as often as i should, too.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] PHP 4.1.0RC4
since news about 4.1.0 leaked out to the php-general list, wouldn't it make sense to call this one 4.1.1? (or 4.1.0pl1? :) jim Zeev Suraski [EMAIL PROTECTED] wrote: I plan to roll it quite soon. I'm still waiting for people to ack that the problem they complained about is gone... Zeev At 20:36 29/11/2001, Zak Greant wrote: Hello QAers, If anyone missed the thread on the PHP Dev list, it looks like we will be testing another RC of PHP 4.1.0. There is no word on when the RC will be rolled yet - I expect that Zeev (or someone) will send a message to the list when the RC is ready. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Karma Request
Sean R. Bright [EMAIL PROTECTED] wrote: I think I am out of karma or something, I tried to commit a fix and received the following error: cvs [server aborted]: commit requires write access to the repository this isn't a karma problem. it appears that the cvs server is/was having some sort of problem dealing with the 'writers' file (that tells it who has write access in general). i've switched to just using a 'readers' file to lock the 'cvsread' account to read-only mode, and hopefully that will avoid the problem. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Fwd: Adoption of Metabase (was Re: [PEAR-DEV] Re: Comparing ADODB with PEAR ]
Manuel Lemos [EMAIL PROTECTED] wrote: It seems that the newsgroup message approval mechanism is not working when you post to more than one newsgroup. care to explain what you mean? your post showed up on both lists just fine, as far as i can tell. http://news.php.net/article.php?group=php.devarticle=70755 http://news.php.net/article.php?group=php.pear.devarticle=2959 jim -- PHP Development Mailing List http://www.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] CVS Account Request: jim
this is just a test. don't mind me. -- PHP Development Mailing List http://www.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] MFB
to make the cvs history easier to read, it is preferable to make the change in HEAD and do a MFH then make the change on a branch and do an MFB. (probably not a huge deal, since it doesn't happen often, but i thought i'd throw it out there. maybe it should be added as a suggestion to the CVS-RULES document.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #13748 Updated: Exec() and System() broken
On Sat, Oct 20, 2001 at 12:36:03AM +0200, Jeroen van Wolffelaar wrote: Why isn't php.net redirecting after a POST? That's a common solution, and also makes sure you can have a logic-only php script, since you're redirecting to a page-with-layout. it does redirect now. there was a bug when the feature was introduced (trying to redirect after html had been sent) that may have confused some people. looks like it is fixed now. (jani did the work, so direct the kudos to him.) jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] [PATCH] fix gethostbyname() to return false when hostname not resolved
here's a patch to fix bug #13423. think anyone is relying on the
current (vastly lame, imho) behavior?
jim
Index: ext/standard/dns.c
===
RCS file: /repository/php4/ext/standard/dns.c,v
retrieving revision 1.35
diff -u -r1.35 dns.c
--- ext/standard/dns.c 19 Sep 2001 18:08:15 - 1.35
+++ ext/standard/dns.c 25 Sep 2001 20:54:06 -
@@ -135,6 +135,7 @@
PHP_FUNCTION(gethostbyname)
{
zval **arg;
+ char *host;
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, arg) == FAILURE) {
ZEND_WRONG_PARAM_COUNT();
@@ -142,7 +143,12 @@
convert_to_string_ex(arg);
- RETVAL_STRING(php_gethostbyname(Z_STRVAL_PP(arg)), 0);
+ if ((host = php_gethostbyname(Z_STRVAL_PP(arg {
+ RETVAL_STRING(host, 0);
+ }
+ else {
+ RETURN_FALSE;
+ }
}
/* }}} */
@@ -186,7 +192,7 @@
hp = gethostbyname(name);
if (!hp || !hp-h_addr_list) {
- return estrdup(name);
+ return NULL;
}
memcpy(in.s_addr, *(hp-h_addr_list), sizeof(in.s_addr));
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PATCH] fix gethostbyname() to return false when hostname not resolved
it will send you to the right place once the site updates from cvs. jim On Tue, Sep 25, 2001 at 02:21:13PM -0700, Rasmus Lerdorf wrote: Yes, but that's not where http://bugs.php.net/search.php sends you when you put a bug id number in the form. On Tue, 25 Sep 2001, Jim Winstead wrote: On Tue, Sep 25, 2001 at 02:00:56PM -0700, Rasmus Lerdorf wrote: here's a patch to fix bug #13423. think anyone is relying on the current (vastly lame, imho) behavior? Did you break the bug system somehow? I am having no luck looking up individual bugs, including this one. http://bugs.php.net/search.php?id=13423 doesn't work. try http://bugs.php.net/?id=13423. jim -- PHP Development Mailing List http://www.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] [RFC] Versioning rules for PHP/Zend/PEAR/Extensions
On Tue, Sep 25, 2001 at 03:00:05AM +0200, Zeev Suraski wrote: First, you forget that for the vast majority of end users, treating RC's as releases is going to be nightmarish. RC's are a reality check before release, and so far, we haven't had a single RC that was release worthy. Just imagine how much headaches we solved employing this approach. you are misrepresenting what i said. in what i am saying, something with a number is not automatically release quality, is not automatically listed alongside other releases, and is in absolutely no way different from what we currently tag with a version number that happens to contain the string 'RC' in it. (yes, we haven't had a 'pl' since 4.0.4. of course, that's just because it was decided the memlimit fix for 4.0.6 didn't merit a 'pl' designation. my point was simply that instead of ever making use of that middle digit in our release numbers, we just sometimes tack on a extra digit at the end, and that seems silly to me.) and i do question, a little bit, how successful our new release strategy is when we only seem to be able to muster a new release every three months. but maybe that's a pace we're happy with. and of course, that has way more to do with a great many more issues than how we number the releases. :) jim -- PHP Development Mailing List http://www.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] news.php.net is back.
On Wed, Jul 04, 2001 at 11:53:48PM -0400, Colin Viebrock wrote: (the server software will be released soonish. keep an eye on http://news.php.net/ for an announcement.) (to be clear, the code i was talking about there was the actual nntp server. the web interface is already in cvs as php-news-web.) Looks good ... although clicking on the rss link produces: Warning: Cannot add header information - headers already sent by (output started at /usr/local/www/news.php.net/nntp.inc:14) in /usr/local/www/news.php.net/group.php on line 19 .. and then the XML data. oops, i fixed that. Can we build this into the main website somehow (a link, I suppose, and interface integration)? well, the web interface was really just proof of concept. i didn't spend much time trying to make it pretty. without searching, i don't think the web interface is a big improvement on the archives available at marc.theaimsgroup.com. jim -- PHP Development Mailing List http://www.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: SV: [PHP-DEV] The new design
(cc'ed [EMAIL PROTECTED] please continue this discussion there.) In article [EMAIL PROTECTED], "Zeev Suraski" [EMAIL PROTECTED] wrote: I generally like the new design, but this statement appears to be trying to fix the symptom, instead of the problem itself. If so many people miss the quick search, and since this paragraph will be gone with time, the right solution should most probably be restoring the Quick Search link to the front page... but i don't believe the problem is people in general finding the quickref -- it's people who are used to it being there on the main page. the reason i don't mind seeing it gone from the main page is that i think having two search-like boxes on the same page that behave differently is confusing. but maybe the 'search' box in the header should really be a quickref box. that seems more likely to pull up what most people want. if someone wants to do an actual search for a function name on other pages, they'd then have to go to the search page and search from there. (as for the page listing all the functions, it's still there at http://www.php.net/quickref.php.) jim -- PHP Development Mailing List http://www.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] Rsync and CVS
this is one of the things on my to-do list. i'll try to get to it in the next few days. (it will get generated into the rsync repository, for what its worth. generated stuff no longer goes into cvs) jim In article 002001c0a5e4$8f868c20$[EMAIL PROTECTED], [EMAIL PROTECTED] wrote: A question about phpweb and cvs/rsync: I'd (still :) like to find the best way to make the annotated manual work on mirrors. The way it works now is okay, but a bit of a hassle to setup and keep up to date. It would seem best if we could have a script on www.php.net update some datafiles, and have those files put into the rsync/cvs repository, for mirrors to fetch as part of their normal update cycle. I was thinking of /manual/usernotes/TOPIC.txt, where TOPIC is the subject in question. The contents of those files would just be a serialize array, exactly as would be returned by the DB. My local setup actually does that, but loading those files requires a semi-backdoor into www.php.net, which I'm a bit uncomfortable about. I know, installing a DB on the mirror and loading it with a dump of the master is another option, but rsync'd files is just *simpler*. Thanks, Simon -- PHP Development Mailing List http://www.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] phpMyAdmin and arg_separator = amp;
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Hi there, I just came across something very odd: After setting arg_separator = "amp;" in my php.ini Tobias Ratschiller's phpMyAdmin no longer works correctly. The start page loads correctly, every page thereafter dies with an SQL error. things break because someone was dumb and used the "arg_separator" that used to be used to handle parsing the incoming request to also handle the parsing that the session-id adding stuff does, and then changed the documentation for arg_separator without regard to the existing behavior. so the get parsing is now expecting to use amp; to separate arguments when you set arg_separator that way. there should be two config variables for this. jim -- PHP Development Mailing List http://www.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 #253 Updated: Feep request: Per-server logging directives.
no idea. i'm just cleaning house in the bug database. i may have added the 'in case zeev still wants to do this' to the wrong report. there was a similar report about setting a config option per directory where it was mentioned that it would be nice to do this for environments other than apache and the config overhaul would handle this. maybe it does. i haven't kept up to date on that sort of thing. close it if you think it is fixed. jim On Sat, Feb 10, 2001 at 08:23:32PM +0200, Zeev Suraski wrote: Shouldn't this work with the new INI infrastructure...? At 19:21 10/2/2001, [EMAIL PROTECTED] wrote: ID: 253 Updated by: jimw Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Assigned To: jim Comments: just changing version to 4.0 in case zeev still wants to do this. :) Previous Comments: --- [1998-04-07 13:05:47] [EMAIL PROTECTED] It would be nice (perhaps in 3.1?) if the logging levels and other related information were setable per-server rather than only globally -- I.e. On my main server, I want errors not to be displayed, and logged to the error log, but on my development site, I'd like errors to be displayed but not logged, so that I don't constantly have to be looking at the error log during debugging. (I'm dropping this in the bug database so that we'll at least have some record of it so, just perhaps, we can poke at it in the future.) --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=253edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #2328 Updated: I would like animated gif support within php.
i wasn't aware that gd supported animated gifs (and a quick glance in the manual didn't show any functions that seemed to be relevant). if i'm mistaken, someone can close this bug. jim On Sat, Feb 10, 2001 at 07:05:39PM -, James Moore wrote: whats wrong with gd? Although current version doesnt support it there are lots of patched versions avalible. James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 10 February 2001 18:46 To: [EMAIL PROTECTED] Subject: [PHP-DEV] PHP 4.0 Bug #2328 Updated: I would like animated gif support within php. ID: 2328 Updated by: jimw Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Assigned To: Comments: refiled against 4.0. Previous Comments: -- - [1999-09-19 22:51:11] [EMAIL PROTECTED] c lib avaliable at http://phil.ipal.org/freeware/angif/ btw, rasmus told me to mail here -- - ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=2328edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] changing the bug emails slightly
unless someone hollers, i'm going to change the bug reports slightly -- i'm going to remove the "PHP 4.0" from the front, make it look like "Re: Bug #1234" instead of "Bug #1234 Updated", and try be a little creative with message-ids and in-reply-to/references headers so that they get threaded properly. let me know if this seems objectionable, or if there's anything else you want to see done while i'm poking around in the bug tracking code. jim -- PHP Development Mailing List http://www.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.net\version4\downloads directory gone! How to build on win32 without?
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: The version4\download directory used to contain some of the files that are referred to in the version4\win32build.php instructions. Though one of the files (number.tar.gz) can still be found in the base download directory, it appears that the bindlib_w32 has now vanished. Makes building on win32 kinda hard. I hope whoever deleted it can put it back or at least update the win32build instructions so that we can continue to use that platform. bindlib is now in extra/bindlib_w32.zip. the win32build.php instructions have been updated. (this may take 15 minutes or so to propogate to www.php.net.) as someone else pointed out, number.tar.gz shouldn't be required anymore. jim -- PHP Development Mailing List http://www.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] emulating db extension on top of dba?
has anyone explored emulating the old db extension on top of the dba extension? because of the better control of which dbm library actually gets used, it seems to me that something like this could make upgrading from php3 easier for some people (like hosting providers, where just upgrading every script to use the dba interface simply isn't feasible). jim -- PHP Development Mailing List http://www.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 manual
In article 002001c08038$1e3b71b0$2c1e140a@barney, [EMAIL PROTECTED] wrote: Why isn't phpweb/manual/en in CVS? because it is generated. all of the generated manual files will be moving out of cvs soon. use rsync as documented in README.mirror. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
