Re: [PHP-DEV] A php's patch for support xhtml
[Alexander Wagner [EMAIL PROTECTED]] Stig Sæther Bakken wrote: 1.Add a mime/type application/x-httpd-php-xhtml to mark xhtml mode. 2.disable short-tags and asp-tags in xhtml mode. 3.add php ... /php instead ? ... ? and php-v eval=/ instead ?= ? 4.ignore '![CDATA[' and ']]' in script block. Since XHTML is XML, ?php ... ? is the proper way of embedding PHP in XHTML files. +1 But this resolves only points 3 and 4. What about the first two? IIRC there was nothing done about PHP producing parse errors on ?xml and other PIs with short-tags enabled? XHTML is spreading and newbies might soon run into problems with short-tags, since these are activated on most ISPs I know of. Deactivating them via .htaccess is a little too difficult for most newbies. Will newbies really use XHTML? Anyway, people have been embedding PHP in WML and other XML formats without visible problems for a while now. IF we are to add another Apache type mapping for this, it should be application/x-httpd-php-xml. IMHO it adds complexity to PHP without really solving any problems that could not be configured around. How about an instruction like good old ?php_track_vars?, which, when placed at the top of the script, would deactivate short-tags? Or is this possible via ini_set()? This approach has been abandoned AFAIR. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] A php's patch for support xhtml
[Andy Yu [EMAIL PROTECTED]] Hi. I don't think that php support xhtml well now, throught php-4.0.6 support script language=php tag. I modify some php source, mainly about sapi_apache zend language scanner. So that the xhtml file which comprises php code will be well xml formed. 1.Add a mime/type application/x-httpd-php-xhtml to mark xhtml mode. 2.disable short-tags and asp-tags in xhtml mode. 3.add php ... /php instead ? ... ? and php-v eval=/ instead ?= ? 4.ignore '![CDATA[' and ']]' in script block. Since XHTML is XML, ?php ... ? is the proper way of embedding PHP in XHTML files. IMHO we have more than enough start/end tags already. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity
Whoa. Once again I'm on that train of thought that eliminates the difference between classes and namespaces. +1 from me. - Stig [Zeev Suraski [EMAIL PROTECTED]] :: is taken, but why not do it the C++ way? It also uses :: for both classes and namespaces. Zeev At 21:35 30-09-01, Stig Sæther Bakken wrote: [Andi Gutmans [EMAIL PROTECTED]] Hey, I just started playing around with the parser to support the namespaces syntax Stig laid out in his RFC. I think I've thought of an ambiguity (with constants) which makes me wonder how feasible the proposed syntax is. Consider the following expression: $test?FOO:BAR:BARBARA Would this mean that the person meant $test?(FOO):(BAR:BARBARA) or $test?(FOO:BAR):BARBARA? Okay, is there another character we can use? Doesn't look that way. Maybe we need to use two characters then? Since both :: and - are taken, // is the best suggestion I can come up with. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] namespaces ambiguity
[Andi Gutmans [EMAIL PROTECTED]] At 09:35 PM 9/30/2001 +0200, Stig Sæther Bakken wrote: [Andi Gutmans [EMAIL PROTECTED]] Hey, I just started playing around with the parser to support the namespaces syntax Stig laid out in his RFC. I think I've thought of an ambiguity (with constants) which makes me wonder how feasible the proposed syntax is. Consider the following expression: $test?FOO:BAR:BARBARA Would this mean that the person meant $test?(FOO):(BAR:BARBARA) or $test?(FOO:BAR):BARBARA? Okay, is there another character we can use? Doesn't look that way. Maybe we need to use two characters then? Since both :: and - are taken, // is the best suggestion I can come up with. // can't be used because of comments. D-oh! :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity
[Zak Greant [EMAIL PROTECTED]] On September 30, 2001 06:15 pm, Wez Furlong wrote: What about . then (Java/Delphi)? --Wez. Wouldn't that conflict with the concatenation operator? Unless I am mistaken, it looks like only the following single symbols are available: % * | \ (outside of quotes at least) Uhm, % and * are taken for modulo and multiplication. So how do these look: HTML\Table - looks too 1980 HTML|Table - hmm, weird I still think Zeev's suggestion (HTML::Table) is very good, if it doesn't impose too much runtime overhead. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity
[Zeev Suraski [EMAIL PROTECTED]] At 17:16 01-10-01, Chuck Hagenbuch wrote: Quoting Andrei Zmievski [EMAIL PROTECTED]: sigh I step away from the computer for the weekend, and such an interesting discussion ensues. For the record, I'd vote for either unifying classes and namespaces (I like that approach) As do I... Andi, Zeev - are there technical problems with this? We're working according to the RFC - namespaces and classes are separate entities. Yes, but it seems the RFC has gotten some Comments, it may be time for a revised version. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] why does exit() print its argument?
[Zeev Suraski [EMAIL PROTECTED]] The WTF factor is generally higher with magical stuff like that. It's not too far fetched to realize a situation where a 'WTF?' will be flown into the air, just because the error message happened to be 1, or 20... shell_exit() is not a very good name. That's why I haven't failed to mention, every time I mentioned it, that a better name would be better. We can have exit_with_status(), silent_exit(), etc. exit_with_status() is good. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Benedicte Bakken born
[Thies C. Arntzen [EMAIL PROTECTED]] On Sat, Sep 29, 2001 at 06:00:24AM +0200, Stig Sæther Bakken wrote: Hi guys, I'm proud to announce that our second daughter, Benedicte, was born tonight 2001-09-29 at 0300 MEST. Technical data: 3380 grams, 50 centimeters, 4 days ahead of schedule. Mother and baby are in good shape. congrats! (I'm taking 6 months leave to be with my family now.) you're kidding, aren't you? No I'm not kidding. In Norway you have to bleed taxes through your years and nose, but it does have some advantages, such as government-paid leave when you get a baby, or being flown to a _good_ hospital in Germany for some surgery ;-). Usually, most of the leave period is reserved for the mother, but under some circumstances the father can take all the leave. This time this included us. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] namespaces ambiguity
[Andi Gutmans [EMAIL PROTECTED]] Hey, I just started playing around with the parser to support the namespaces syntax Stig laid out in his RFC. I think I've thought of an ambiguity (with constants) which makes me wonder how feasible the proposed syntax is. Consider the following expression: $test?FOO:BAR:BARBARA Would this mean that the person meant $test?(FOO):(BAR:BARBARA) or $test?(FOO:BAR):BARBARA? Okay, is there another character we can use? Doesn't look that way. Maybe we need to use two characters then? Since both :: and - are taken, // is the best suggestion I can come up with. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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/cpdf cpdf.c /ext/dba...
[Jeroen van Wolffelaar [EMAIL PROTECTED]] jeroenTue Sep 25 18:48:46 2001 EDT Modified files: /php4/ext/cpdfcpdf.c /php4/ext/dba dba.c dba_db2.c dba_db3.c dba_dbm.c dba_gdbm.c Jeroen, Please don't fix things like this if you have no way to ensure that everything compiles _and_ works. Rather leave it up to each extension's maintainer to run the script, at least we're reasonably sure new bugs are not introduced. There are probably better ways to spend your energy than creating work for others like you did with this patch. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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
[Andi Gutmans [EMAIL PROTECTED]] At 12:01 PM 9/26/2001 -0400, Joao Prado Maia wrote: On Wed, 26 Sep 2001, Andi Gutmans wrote: I think the key still lies in creating a repository for C extensions where each extension can have its own release cycle. That is also true, but we still need a reliable way to check for the version of specific extensions. Having just bumped into an inconsistency between GD 1.6.2 and GD 2.01 output, this would help a lot. However, the problem is already out there and to create code that is truly portable I couldn't rely on even this new (if it ever comes to life) feature. This sort of thing really complicates writing portable code. not just for different platforms but also for different versions of extensions. Just a repository wouldn't help much from the programmer's perspective IMHO, if the current situation continues. I agree completely. We need a way to check what version each extension is. We have broken BC quite a bit in 4.0.7 so maybe we should add this to 4.0.7 so that we can get this whole external C extension thing going ASAP? Yes, definitely. But what do you think about the versioning scheme Jani proposed? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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
[Andi Gutmans [EMAIL PROTECTED]] At 09:12 PM 9/25/2001 +0200, Stig Sæther Bakken wrote: But just to get back to release frequency, I do think we release too seldom. There's a lot of process in place now, with a QA branch and all. I think this process is good, but it's congesting. At this point we're almost ready to start the 4.0.8 release before 4.0.7 is through the needle's eye. There's simply too much weight. For every extension we shake off, it the release process gets lighter, and some ISP sysadmins may even get their hair back. I disagree. It does seem annoying that when we finally release 4.0.7, 4.0.8 is pretty much ready for its own QA round but I thought about this a lot and I think it's better than the alternatives. It allows us to release a more stable version and it's not such a big deal because 4.0.8 will take a long time to finish QA anyway. Most people I talk to *don't* like having to upgrade every month or two. Even three month releases is relatively tight for them so I think the amount of releases we are doing right now is pretty good. Okay, I can agree that given the current situation, three months is a reasonable release frequency. What I'm after is not really having a new PHP release every two weeks. Often I'm waiting for a new release because of a new/changed/bugfixed extension that comes with it, and in these cases it's frustrating having to wait for three months. The start of this thread was a versioning scheme, and that's still what this is all about, because it's required to solve the problem I'm describing above. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: 403 on www.php.net (fwd)
[[EMAIL PROTECTED]] Derick Rethans [EMAIL PROTECTED] wrote: I get a 403 (Permission denied) on bugs and www.php.net from home... any idea's? Works fine from my work location. you didn't happen to have something that hit lstats.php every minute, did you? i blocked a machine within chello.nl that was doing that. Hehe, that's Bugstah, an IRC robot that updates the subject of #php.bugs with the number of open bugs. It's a sobering experience, btw. :-P - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Re: Undefining user functions/classes at runtime?
Andrei is writing an extension that does this (explicitly per class). - Stig [Harald Radi [EMAIL PROTECTED]] something like the current oo api mechanism would be useful for userland too and would possible solve markus' problem too. if you call a member on an object there could be an __invoke() method that handles all calls of unknown functions. thus $obj-foo(bar); will end in $obj-__invoke(foo, bar); if the member foo() doesn't exist. -harald. -Original Message- From: Markus Fischer [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 23, 2001 8:24 PM To: Jeroen van Wolffelaar Cc: PHP Developers Mailing List; [EMAIL PROTECTED] Subject: [Zend Engine 2] Re: Undefining user functions/classes at runtime? On Sun, Sep 23, 2001 at 08:03:59PM +0200, Jeroen van Wolffelaar wrote : Is it currently possible to undefine user functions or classes at runtime? Although not a newbie ;) I'm unsure if its possible right now. No, you can't do that in PHP-userland (in the C code it can be done, see implementation of create_function). And IMHO that should remain so. If not, will this be support (ZE2) ? I hope not. Can you give an example where you think it will be useful? I'm currently writing an application which is only a dumb client stub (php-gtk) which receives its code via xml-rpc and executes it. The problem I have is that I can't refetch the same code again because I redefinition errors of all kind. - Markus -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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
[Andrei Zmievski [EMAIL PROTECTED]] On Mon, 24 Sep 2001, Jani Taskinen wrote: 2. General rules for PHP, Zend and PEAR/C-extensions v.m.b (e.g. 4.0.8) v = Functions removed, function behaviour changed, API changes, major parts rewritten. (BC might be broken) m = New functionality added. Only backwards compatible API changes. (100% BC) b = Bug fixes. No new functions added. No API changes. (100% BC) Left out if zero (0). It's going to be pretty tough to not add any functionality while also fixing bugs. Maybe 'b' could be incremented for bug fixes and minor functionality enhancements and 'm' for more extensive new functionality and API changes? I think we should be flexible to make this practical, the core of the idea is that you should not get any surprises when upgrading just b, and no API surprises when upgrading m. There's a question about whether the API should be defined as the source API, or also the runtime API, for extensions. I think the API should cover both. 3. Stable/development branches [OPTIONAL] -- Even minor number: stable (x.2.x) branch. Odd minor number : development (x.3.x) branch. (this is not needed for PHP. Our stable branch can be the release branch and the development branch is just the HEAD) Correct. 5. New PHP/Zend API function version_compare() -- proto int version_compare(string version1, string version2 [, string operator]) This function knows this: 4.0.5 4.0.6RC2 4.1.4 4.2-RC1 and returns: -1 version1version2 0 version1 === version2 1 version1version2 We already have such versions, they are called strnatcmp() and natsort(). Huh? Does strnatcmp() know the that 2.0RC4 is newer than 2.0b2? :-) Extensions can use the same function internally to check the Zend / PHP versions. How do we check PEAR versions, will PEAR class have a standard function that returns version? We'll need to add something like that. Either a function, a standard method or when ZE2 comes a static class variable. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Fw: Bumping PHP to support 8byte integers
[Jeroen van Wolffelaar [EMAIL PROTECTED]] Hi, For a scripting language, integers should IMHO be bounded by a number that will reasonally not be bound by numbers that will be used in normal scripts. That is currently not the case, 4 bytes are insufficient IMHO. Why not make sure PHP uses 8 bytes at least? Or are there platforms not supporting 8byte integers? I believe most popular do... (at least linux on i586 and i686, windows and Solaris (I tested SunOS 5.6)) For implementation, I think that we should introduce p_int and p_float typedefs for php-integer and php-float anyway, and changing THAT isn't a problem. About preformance/memory, I think that's not an issue. Making strings unicode will be much more heavy for PHP... Does anyone have experience with moving a large system from 4-byte to 8-byte integers? What are other languages doing? My gut (the ultimate risk management tool) thinks it's dangerous to start messing with internal types without knowing exactly what the consequences are, preferably with some experience (own or others) to back it up. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: Undefining user functions/classes at runtime?
[Jeroen van Wolffelaar [EMAIL PROTECTED]] Is it currently possible to undefine user functions or classes at runtime? Although not a newbie ;) I'm unsure if its possible right now. No, you can't do that in PHP-userland (in the C code it can be done, see implementation of create_function). And IMHO that should remain so. If not, will this be support (ZE2) ? I hope not. Can you give an example where you think it will be useful? By the way, I think you can achieve something like this if you really want to with Advices, IMHO another needless feature. Advices can not be used for something like this (undefining classes). - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: Undefining user functions/classes at runtime?
[Markus Fischer [EMAIL PROTECTED]] On Sun, Sep 23, 2001 at 10:07:29PM +0200, Stig Sæther Bakken wrote : [Jeroen van Wolffelaar [EMAIL PROTECTED]] Is it currently possible to undefine user functions or classes at runtime? Although not a newbie ;) I'm unsure if its possible right now. No, you can't do that in PHP-userland (in the C code it can be done, see implementation of create_function). And IMHO that should remain so. If not, will this be support (ZE2) ? I hope not. Can you give an example where you think it will be useful? By the way, I think you can achieve something like this if you really want to with Advices, IMHO another needless feature. Advices can not be used for something like this (undefining classes). Thats great. This could also solve the 'undefine a function' problem. I'll just not use them and always instanciate classes. Uhm, either you didn't notice that I wrote advices can NOT be used..., or I didn't notice you pulling my leg. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Bumping PHP to support 8byte integers
[Jeroen van Wolffelaar [EMAIL PROTECTED]] In PHP performance is IMHO a bit less important than in DBMS's. If you're after performance you shouldn't use a scripting language anyway :). Sorry for starting, but this is just nonsense. First of all, today PHP is a scripting language only by categorization, technically it is no more so than Java. Second, performance is important for PHP. 4.0 beats lots of competition because of its performance. We shouldn't even think of jeopardizing that. When I hear this kind of reasoning from people who suggest core changes, I stop listening. Please tell me you were kidding. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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/msession CREDITS Makefile Makefile.inREADME config.m4 libs.mk msession.c msession.php php_msession.hreqclient.h
[Sebastian Bergmann [EMAIL PROTECTED]] Mark L. Woodward wrote: mlwmohawk Wed Sep 19 09:14:23 2001 EDT Added files: /php4/ext/msession CREDITS Makefile Makefile.in README config.m4 libs.mk msession.c msession.php php_msession.h reqclient.h Log: Added What is this extension about? I can't remember a discussion on this extension and I am bewildered by 'I am still a newbee at PHP hacking so I am scared to death I will break something, and I (regretfully) have not invested the time to make all this stuff automatic. In the config.m4 file you will need to specify the include and library directories for Phoenix. The setting in config.m4 is probably wrong.' (quote from ext/msession/README) and the fact that the source is licensed under the GPL. Mark is an ex-colleague of mine, I'm the one who encouraged him to contribute this extension. It's a high-performance session management system that can be used in clusters (many redundant web servers). The performance numbers I've seen so far are very impressive. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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 3.0 Bug Summary Report
What's up? Did the 4.0 bug summary report grow too big for the list again? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Versioning (resent AGAIN due to lack of replies)
[Jani Taskinen [EMAIL PROTECTED]]
On Sun, 16 Sep 2001, Sterling Hughes wrote:
+1, perhaps from an api perspective we could have something like:
$vn = php_get_version(GD);
or if the argument is empty, return the main php version:
$phpVer = php_get_version();
-Sterling
We could just add an optional argument to phpversion() ?
This will work as per discussion with Stig (on IRC) and
using the (yet to be written) function version_compare() to
do the checking.
There should be an entry in _zend_module_entry struct for
the version string (of the extension) ?
We can do better than that. When the Zend module API changes, the
change may or may not affect specific extensions. I propose changing
zend_module_entry thusly:
struct _zend_module_entry {
unsigned int zend_api;
unsigned char zend_debug;
unsigned char zts;
char *name;
zend_function_entry *functions;
int (*module_startup_func)(INIT_FUNC_ARGS);
int (*module_shutdown_func)(SHUTDOWN_FUNC_ARGS);
int (*request_startup_func)(INIT_FUNC_ARGS);
int (*request_shutdown_func)(SHUTDOWN_FUNC_ARGS);
void (*info_func)(ZEND_MODULE_INFO_FUNC_ARGS);
int (*global_startup_func)(void);
int (*global_shutdown_func)(void);
int globals_id;
int module_started;
unsigned char type;
void *handle;
int module_number;
};
The most critical members (zend_api, zend_debug and zts) are moved to
the beginning of the struct, so all future code can rely at what
position in the struct they can be found.
I've been playing with the idea of having a
(int)(*zend_api_mismatch_handler)(int) function pointer immediately
after zts to allow extensions to say yeah I know about that API
change, but it's not affecting this extension, but I'm not yet 100%
sure it would help. I'll think some more about it after some
breakfast and two cups of coffee. ;-)
- Stig
--
Stig Sæther Bakken [EMAIL PROTECTED]
Fast Search Transfer ASA, Trondheim, Norway
--
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] Versioning (resent AGAIN due to lack of replies)
[[EMAIL PROTECTED] (Stig Sæther Bakken)]
[Jani Taskinen [EMAIL PROTECTED]]
On Sun, 16 Sep 2001, Sterling Hughes wrote:
+1, perhaps from an api perspective we could have something like:
$vn = php_get_version(GD);
or if the argument is empty, return the main php version:
$phpVer = php_get_version();
-Sterling
We could just add an optional argument to phpversion() ?
This will work as per discussion with Stig (on IRC) and
using the (yet to be written) function version_compare() to
do the checking.
There should be an entry in _zend_module_entry struct for
the version string (of the extension) ?
We can do better than that. When the Zend module API changes, the
change may or may not affect specific extensions. I propose changing
zend_module_entry thusly:
struct _zend_module_entry {
unsigned int zend_api;
unsigned char zend_debug;
unsigned char zts;
Whoops, I forgot:
char *module_version;
(This would be a string like 1.0b4, according to the versioning
scheme we decide on.)
char *name;
zend_function_entry *functions;
int (*module_startup_func)(INIT_FUNC_ARGS);
int (*module_shutdown_func)(SHUTDOWN_FUNC_ARGS);
int (*request_startup_func)(INIT_FUNC_ARGS);
int (*request_shutdown_func)(SHUTDOWN_FUNC_ARGS);
void (*info_func)(ZEND_MODULE_INFO_FUNC_ARGS);
int (*global_startup_func)(void);
int (*global_shutdown_func)(void);
int globals_id;
int module_started;
unsigned char type;
void *handle;
int module_number;
};
The most critical members (zend_api, zend_debug and zts) are moved to
the beginning of the struct, so all future code can rely at what
position in the struct they can be found.
I've been playing with the idea of having a
(int)(*zend_api_mismatch_handler)(int) function pointer immediately
after zts to allow extensions to say yeah I know about that API
change, but it's not affecting this extension, but I'm not yet 100%
sure it would help. I'll think some more about it after some
breakfast and two cups of coffee. ;-)
- Stig
--
Stig Sæther Bakken [EMAIL PROTECTED]
Fast Search Transfer ASA, Trondheim, Norway
--
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]
--
Stig Sæther Bakken [EMAIL PROTECTED]
Fast Search Transfer ASA, Trondheim, Norway
--
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] Versioning, again (was: RE: [Zend Engine 2] Re: PHP is not case sensitive?)
[Jani Taskinen [EMAIL PROTECTED]] [this is more php-dev stuff, thus moved there] Warning: This is yet another beaten up issue but as it still hasn't been fixed, we need to find a solution to fix it. Problems: Viability, BBC, WTFF, old extensions used with new PHP version. Proposals: My proposal is that first we come up with a versioning scheme with which everybody can agree on. Then we can release this scheme to 'public' and hopefully not have to discuss/fight about this again. Examples: http://java.sun.com/products/jdk/1.2/docs/guide/versioning/spec/VersioningSpecification.html http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html http://www.zenspider.com/ZSS/Definitions/Versions.html (the last one is something that I'd like to see for PHP) Also, to make NEWS file more useful than it is now I (again) propose that it is reorganized like this: Categories: ! Important note * Changed + Added - Removed Reasoning: There has to be clear document that describes when and why a version number changes. If someone doesn't understand WHY this document is needed they should read the rest of this email. :) --Jani p.s. Rest can be safely ignored. It is just there to show what happens everytime this issue raises it's ugly head and shouts: BOO!.. Take a look at http://cvs.php.net/co.php/pearweb/sql/design.txt. There's a versioning section at the end there, intended for PEAR. Anything we can use? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Woah
[Zeev Suraski [EMAIL PROTECTED]] At 09:13 08-09-01, Andrei Zmievski wrote: At 05:33 AM 9/8/01 +0300, Zeev Suraski wrote: That's unfortunate. IMHO, it should be phased out. I'm against it. _() has been around forever as part of gettext package and people who expect to find it in PHP will be pretty disappointed. Disappointment isn't exactly the metrics here. People who migrate from other languages will be disappointed not to find all sorts of things they're used to from their old languages, but it has never been a reason to obscure PHP. _() has no room in PHP's naming convention. There's a small downwards compatibility issue (it's not advertised very promptly), so we should deprecate it just like we deprecate and have deprecated other functions in the past. Hey, let's just leave it, please. There's a zillion people who use this now, it's what they expect if they have used gettext before. It's been here for 2.5 years, it hasn't bothered anyone until now, and I don't think removing it would be anything less than counter- productive. Removing it would only make people alias _ to gettext themselves, net result being i18n'ed code running slower. It's not like we're going to add more single-character aliases, so I don't buy the feature creep argument either. L_A! (leave _ alone!) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] About the Rand Merge: apologoy how further?
there, visible for everybody, without polluting the php-dev ML. I really appreciate it if people who have an opinion on this, give their vote. There's also room for extra comments. Thanks in advance, Jeroen van Wolffelaar -- 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] -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Better shell scripting
What if we introduced a -p option to PHP that starts the Zend parser in PHP mode? For any other files (include/require), it starts in HTML mode though. - Stig [[EMAIL PROTECTED]] Yeah, I agree. However, it might make things a bit muddled for people using it as cgi? How would PHP tell if the following was PHP code or if its supposed to be echoed to the web browser? I would rather see a -shell option which does what you describe. Mike (long-time listener, first-time poster ;) Original Message On 9/7/01, 11:27:30 AM, Edin Kadribasic wrote regarding Re: [PHP-DEV] patch to make for better shell scripting: Almost forgot. IMO -q swich should make starting ?php optional so instead of writing: #!/usr/bin/php -q ?php print Hello, world!\n; ? I could simply say: #!/usr/bin/php -q print Hello, world!\n; Edin -- 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] -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Reverting Rand Changes
[Sterling Hughes [EMAIL PROTECTED]] Hey all, Just giving notice, I'll be reverting the recent rand changes tomorrow (well, technically later today) First of all, I think you should direct this to Jeroen first, not the rest of us. Second, I think the treatment Jeroen has gotten here lately gives him the right to fix his changes before you or anyone else reverts them (they're here now, give him a chance). Finally, if the changes _are_ going to be reverted, give Jeroen some respect and let him do it. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Freshmeat.net needs to know who is responsible.
[Stephen Graham [EMAIL PROTECTED]] Howdy, I am writing on behalf of freshmeat.net. PHP is listed there, yet I do not have a contact e-mail for the person responsible for the freshmeat.net project listing. As I am sure you can see, this makes it VERY diffcult to contact the correct person when something goes wrong (which is why I am contacting you guys/gals). Could the relevant person please send me an e-mail so that I can get in contact with them and clear up the problem we have with their freshmeat.net posting. If I do not hear anything in 3 days I am afraid I will have to remove PHP from the freshmeat.net archive (and I am sure no-one wants that : ) Hi, Please use [EMAIL PROTECTED] for administrative stuff, or [EMAIL PROTECTED] for technical stuff. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] python dictionary-like % (percent) substitution in php (was: Good idea in % (percent) substitutions in string)
I like this idea, it should be fairly straightforward to put on top of the existing [s]printf implementation. - Stig [--- ] I have seen that in php there isn't nothing similar to dictionary substitution in python. (a dictionary is an array with string keys, like hash in perl) This change consist in adding two functions (a stay for array): aprintf(string format, array dict) -- like printf, print the result saprintf(string format, array dict) -- like sprintf, return the result It works like this (written in php-like language): format - my name is %(name)s and i'm %(age)s dict - array( name=tom, age= eighteen ); (in php, unlike python, is possible to make an array with both string and number indices, so the format can be also %(2)s,...) aprintf(format,dict) -- print my name is tom and i'm eighteen saprintf(format,dict) -- return my name is tom and i'm eighteen in python, these substitutions are very useful, especially in cgi programming, for making templates from text files, in php could be useful in, for example, language customisation, or message formatting, etc... An example: if ($lang == it) define(MESSAGE,il %(animal)s %(color)s sta %(action)s %(target)s); else define(MESSAGE,the %(color)s %(animal)s is %(action)s); aprintf(MESSAGE,array(animal=cobra,color=green,action=eating,target =mouse)); // if the %(target)s isn't found, is ignored. (the s terminator could be substituted with other letters, like d for numbers, etc...) This approach has several advantages over something like this: the $color $animal is $action because in this phrase, variables are substituted when the parser execute it, and in this case: the %(color)s %(animal)s is %(action)s parameters are substituted only when the phrase is parsed with a specialized function like aprintf I think that this is a good idea and could save a lot of time when the program need to be as modular as possible. Federico Marani [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] -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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 basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Walter Franzini [EMAIL PROTECTED]] [sorry, my English is bad] Zeev Suraski [EMAIL PROTECTED] writes: [...] Why? Whatever extension you use on your box, put them in the php.ini. dl() is never a better option. Zeev An example not solvable using php.ini: At SysNet, we access dbms only with odbc_* functions using (for different apps on the same server) solid and IBMdb2. We compile ext/odbc/php_odbc.c as solid.so and ibmdb2.so and load the right module using dl (). Using php.ini is not feasible because this lead to multiple function definition. I think a similar situation may arise with multiple xslt backend, they must export the same API but could provide different features (or bugs) so you must use xslt1 for app1 and xslt2 for app2. Please don't drop dl () :-) Shane Caraveo did some work on the ODBC module to solve this once, by using macros for all potentially clashing symbols in the ext/odbc source. It's not there anymore though, and that's mostly my fault. I guess we could go back to that model. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] String search
[Bob Irwin [EMAIL PROTECTED]] G'day, This is a probably an easy one. How would one identify predefined characters in a string? For example, I have the string, 'bob@pnc. com.au' If I had the space on my 'illegal characters list', how would I go about having the script identify it? This is a question for php-general, not php-dev. But anyway, take a look at the strspn and strcspn functions. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Returning a string from an executed script?
[Rasmus Lerdorf [EMAIL PROTECTED]] Mostly a Zend question I guess, but I am playing with having PHP handle other phases of the Apache request_rec and currently have working code that lets a PHP script get run during the uri translation hook. This is a nice one to start with because it can really open up some cool things that can otherwise only be done through an ErrorDocument handler, and even then you are somewhat limited in what you can do there. What I am not sure of is how to communicate the new translated uri back to the calling handler function in mod_php4.c. Right now I have: php_admin_value uri_handler /full/path/uri.php And I have some code that takes that uri_handler script filename and trickles it down to a call to: zend_execute_scripts(ZEND_REQUIRE TSRMLS_CC, 1, primary_file); Where primary_file is: primary_file.type = ZEND_HANDLE_FILENAME; primary_file.handle.fd = 0; primary_file.filename = uri_handler; primary_file.opened_path = NULL; primary_file.free_filename = 0; That all seems to work fine and the PHP executes at the required stage during the request handling. But what should uri.php look like? I think something like this would be nice: ? return '/foo'.$REQUEST_URI; ? Obviously a simple handler, but it would take a request like http://php.net/blah.php and actually cause http://php.net/foo/blah.php to be opened up during the content parsing request_rec phase. I don't see a way to currently do such a return and get at the returned value after the call to zend_execute_scripts(). Any suggestions? Print a header and catch it from the Apache module, or use apache_note()? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: [phpweb] [NON-critical] Change-notes warning:
[Markus Fischer [EMAIL PROTECTED]] On Wed, Aug 29, 2001 at 08:12:53PM +0200, [EMAIL PROTECTED] wrote : And how is the user(developer) supposed to retrieve the actual error then ? $php_errmsg (or whatever) or error_handler? He isn't. It is not a file. If wanted, the user can use file_exists to check wether the file didn't exist, or was not of type 'file'. This error isn't a side-effect, it is (almost) the main purpose of the function. Am I the only one wo finds the current way good? For me, the manual is just wrong and the manual should be fixed. Not some code which worked that way so long (and not bad at all). We can't encourage people to use E_ALL and at the same time have silly errors like this one. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] MFH'ing PEAR changes
[Zeev Suraski [EMAIL PROTECTED]] At 11:08 28-08-01, Stig S. Bakken wrote: Any objections against me MHF'ing some non-critical stuff in php4/pear? It's so long between each PHP release now that the PEAR stuff that comes with PHP is usually outdated by the day of the release. :-P I don't think PEAR gets thoroughly tested during the RC cycle (am I wrong?), so I think it should be fine. I've not seen any reports from the QA team on PEAR stuff, either it's not tested, or it's working perfect. :-) I think we should go with RC2 soon. The flow of patches is pretty slow right now. Yes, please. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] API Thoughts?
[Sterling Hughes [EMAIL PROTECTED]]
On Sun, 26 Aug 2001, Chuck Hagenbuch wrote:
Quoting Sterling Hughes [EMAIL PROTECTED]:
Jep -- I'm writing PEAR OO wrappers for every ADT that I implement
in a functional manner. I'm think for the OO wrappers, seperate
class names wouldn't be horrible, something like:
$tree = new AVLTree;
Please stick to the naming conventions, which would make this:
$tree = new ADT_Tree_AVL();
... or something similar. Also, you could easily have a factory method:
$tree = ADT::factory('tree_avl');
or:
$tree = ADT_Tree::factory('avl');
The above are imho pretty ugly, and this is meant as more of a language
level feature, I'm thinking of using PEAR as more of a method of
distribution than a mindset. I'd prefer to code the OO wrapper in
PHP -- it stops me from having to be aware of changes to the Zend OO
model and writing code that works with both the functional interface
and the OO interface (some form of automatic handling of this would
be a very cool/useful feature for Zend, imho).
The current way I have it organized is as follows:
php4/pear/ADT.php
php4/pear/ADT/LList.php
php4/pear/ADT/Stack.php
php4/pear/ADT/Queue.php
php4/pear/ADT/AVLtree.php
php4/pear/ADT/BTree.php
php4/pear/ADT/RBTree.php
php4/pear/ADT/Heap.php
php4/pear/ADT/Set.php
then you could do something like:
?php
require_once('ADT/Queue.php');
$sounds = new Queue;
$sounds-push(Bing);
$sounds-push(Bamm);
$sounds-push(Booom);
while ($sounds-count() 0) {
echo $sounds-shift();
}
?
Which I think works quite nicely :)
PEAR's naming conventions applies to classes written in C too. :-)
The way you have your files organized above, the classes should be
named ADT_Queue and so on.
- Stig
--
Stig Sæther Bakken [EMAIL PROTECTED]
Fast Search Transfer ASA, Trondheim, Norway
--
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] Linux Today Article
[Kristian Koehntopp [EMAIL PROTECTED]] And finally, what is services to you? How will they relate to PHP and what do we as developers need to do to enable them? To me, services means online transactions, be it web search, stock alerts or credit card payments, and the full range of variations you can get within each of these. It is also something that the customer does not host himself. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Karma request
[Marc Boeren [EMAIL PROTECTED]] I would like to add myself as maintainer of dbx to the EXTENSIONS file, but my karma is not sufficient to do this myself... So if somebody could do this for me, or upgrade my karma, that would be nice :) Fixed. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Linux Today Article
[Kristian Koehntopp [EMAIL PROTECTED]] On Thu, Aug 16, 2001 at 02:24:27AM +0300, Zeev Suraski wrote: I've rambled a bit, but my feeling is that the Linux Today Article is premature. PHP can (and likely will) support the features mentioned in the article, but the real question is, are these really the features that are going to be used? Very nice non-PC statement! :) A programming language is not only a tool and a framework, it also is a set of people sharing a common vision and working together - a community. What Microsoft provided with .net is not so much a product - yet. It is a vision, though, and a plan where they want to go in the next few years. So to compete here, PHP need not only be superior in technical checklist items, it also has to provide a kind of development roadmap, a plan where it wants to be in 3 and in 5 years, and what services it will provide to developers then. That is the PHP vision that the language and the system needs to stand the marketing onslaught by Microsoft. Note how other communities, notably Perl, provided such a vision in the past (e.g. the mythical Perl compiler), and continue to provide such visions now (e.g. Perl 6 and flexible scanners to turn Perl into the one language to parse all syntaxes). Larry provides even more - with his speeches and interviews he even provides a kind of philosophy behind Perl, a greater concept to explain not only how, but also why things have been done the way they have been done. As you can see in the case of Perl, the vision need not be final, useful or even true, it just needs to be cool, and believable. It is being used as a tool to bind the community tigther together, to provide hope and a sense of direction. To come back to PHP: What is the place of PHP in 3 and in 5 years, what are the next big projects tackled in the development of PHP, and what is the larger idea behind PHP - what does the language _want_ to become, and what audience will it cater. If you can answer these questions for your developing audience, these answers will have a large influence on the qualification and quantity of audience you have. Very nicely put, Kristian. A lot of people in the PHP community have visions, but we have not yet managed to put something together that people can look forward to. IMHO people like Zeev, Andi and Rasmus are the natural channels for such visions, but we're not quite there yet. But for a vision to form we need to find a common ground for a few things. The LinuxToday article kept rambling about PHP not being a platform, which is true, it is but one of the components in such a platform. But it doesn't mean we can go on not having this platform in mind. Thinking services _is_ important today, it's what most big online companies have to do, Microsoft knows this, and they help creating the wave they've started riding now. There's quite a few service platforms for PHP out there today, but their needs from the language should be made more visible, so we can foster the development (and maybe even consolidation) of systems such as PEAR, binarycloud and so on. I'm not rambling on the engine2 mailing list about namespaces, advices and whatnot because my mind is going, it's because I see these features as powerful enablers for PHP going in this direction. - Stoig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
[Jeroen van Wolffelaar [EMAIL PROTECTED]] Hi, About a month ago there was a discussion on the Engine 2 mailing list, about a possible RFC-proces for the more imporant PHP-issues. In the end, there was some consensus that it would be good if such a system exists. I'm simply writing to get some comments, to hear what the general opinion is. If that is not negative, I think it should be tried to set it up. About the details, there needs to be discussion of course, but it would be more efficient to discuss those things after a proposal has been made, in stead of construct such a proposal by discussion. Joey Smith and Zak Great supported the idea on the list, but the discussion went dead. Below I quote some of their mails. Hi, I think one of the problems with this is that even if php-dev comes up with a system for determining which feature it wants to see in PHP, we still depend on Zeev, Andi or someone else @ Zend to implement them. An RFC system would be a support for Zend's decision-making. At the end of the day, due to the licensing issues, php-dev is not the body governing the language, it has an advisory role only. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] fileperms(), fileinode(), filesize(), is_readable(), etc.
[Sterling Hughes [EMAIL PROTECTED]] As an issue for PHP 5 (or PHP 4.1 for that matter), perhaps we should remove these functions and just stick with stat() and lstat() calls? This would remove a bunch of functions which aren't really that necessary (I'm probably just being a minimalist, but I figured I'd bring it up :) Hey, let's not become C, I think they're just right. Usually when I stat a file, I only need one attribute. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Setting up RFC
[Sterling Hughes [EMAIL PROTECTED]] On Wed, 15 Aug 2001, Zeev Suraski wrote: At 10:23 15-08-01, Stig Sæther Bakken wrote: [Hi, I think one of the problems with this is that even if php-dev comes up with a system for determining which feature it wants to see in PHP, we still depend on Zeev, Andi or someone else @ Zend to implement them. An RFC system would be a support for Zend's decision-making. At the end of the day, due to the licensing issues, php-dev is not the body governing the language, it has an advisory role only. Generally, I agree with you, except it's not because of licensing issues (will we end up with a load of features suddenly getting into PHP if/when the engine license changes?). Many other projects behave that way. With a language definition, vox populi, vox Dei doesn't tend to work very well. Yes, the difference is, this creates a situation where the PHP Development team does not have control of the core language, Zend Technologies Ltd. does. Whether this is a issue with a basis in principle or a basis in practicality is up to debate, however, the problem remains. Zend having control of the language has nothing to do with vox Populi, vox Dei (translated the voice of the People, the voice of the Gods), its more of a matter of *who* has control -- Zend Technologies or the PHP Developers. Historical note: we had, ahem, feature discussions in 3.0 before Zend existed, so it doesn't have only to do with the fact that Zend is a commercial company. An important issue here is that for us, control of the language also means writing code. Granted, there's reduced motivation for people willing to dive into the Zend code, since their contributions would become the property of Zend, but so far Andi Zeev are probably the only members of the community who understand the code well enough to implement stuff like ticks and namespaces. So there's really no point in broadening the control of the language until Zend has a license that makes people like Sascha willing to put a lot of their time into the Zend code. Kristian thinks a dual GPL/QPL license would be a good idea for Zend (it apparently works for Troll Tech), but that's _definitely_ for another thread. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Extra parameters for strtoupper(), strtolower()
[J Smith [EMAIL PROTECTED]] string strtoupper(string string [, int start [, int length]]) string strtolower(string string [, int start [, int length]]) The additional parameters would work in much the same fashion as substr(). I've implemented it in the latest cvs just for the hell of it. Am I the only one who thinks this is even remotely useful? It isn't a big thing, but it's a lot easier to have this available than to chop up a string with substr() and then capitalize what you want. A pretty useless feature, I guess. Obviously, I'm pretty bored right now. If it's useful to you, it will be useful to others. Go for it. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] use indent instead of fixing whitespace by hand?
[Thies C. Arntzen [EMAIL PROTECTED]] guys, it's really time to setup our own indent(1L) profile and simply run everything in php4/ thru it. i'll spend some time playing with it (while i'm on vacation) unless: does anybody see a reason *not* to swicht to indent (manybe even intergrated into out CVS) once we have a satisfying settings for it? please speak up now - i really don't want to waste my time on it if somebody has a good technical reason why this (running php-sources thru indent) won't work. Aye aye captain! I'm not 100% sure we'll get indent to do what we want, but we should find out and see if it can be done. I have started making an indent config file for PEAR, but that is indenting PHP code, so it's kinda different. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] PHP4.0.6, php_iconv bugs
[Piotr Pawlow [EMAIL PROTECTED]] Hello, I have noticed that php_iconv sometimes fails to convert the string due to invalid sequence of characters on input, and there is no way to find out where the bad sequence is. I think there should be an optional parameter added to iconv() function, a variable passed by reference. If used, iconv would in case of an error return partially converted string, and set this variable to character index at which the conversion failed. Also, php_iconv makes a wrong assumption that the longest sequence representing one char is as long as sizeof(ucs4_t). For example, unicode combined characters can easily be longer, the same applies to encodings like 'JAVA' (\u). Did you test the same thing with another program using iconv? I've encountered the same problem in iconv when I tried to convert an ISO-8859-1 string containing ~ to Shift_JIS. Shift_JIS actually does not define the tilde character, so iconv bailed out and returned an empty string (the solution is using codepage 932 instead when people ask for Shift_JIS. Bleh.) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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 / NEWS /ext/standard info.c /main main.c
[Zeev Suraski [EMAIL PROTECTED]] At 20:27 08-08-01, Andrei Zmievski wrote: On Wed, 08 Aug 2001, Zeev Suraski wrote: Good question, open for debate... Generally I consider GPC as a group of data which cannot be trusted, since it's coming from the user. But I'm not sure. Perhaps we need a different name, $_USER? Anyway, I'm just thinking out loud - it's interesting to see what others think about this... I'd prefer $_USER over $_FORM any day. Today's Wednesday, which qualifies :) I tend to lean towards changing it from $_FORM too. Andi suggested $_CLIENT. Let's hear some feedback: - Keep it as $_FORM - $_USER - $_CLIENT - Be extra careful - $_UNTRUSTED - $_INPUT Of these I think $_INPUT bears the least confusion. To me, $_USER sounds like something session-related, $_CLIENT sounds like something to do with user-agent. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PEAR-DEV] DB : affectedRows() on an UPDATE query ?
[Manuel Lemos [EMAIL PROTECTED]] Ok, but it is fair to say that it is not supported in all PEAR-DB backends even if it is just a limitation of PHP Interbase API. Maybe sometime later somebody adds a ibase_affected_rows() function, but PHP scripts can't assume that the function exists because the PHP version that is installed may not have such function yet. I suggest that somebody apply that patch and PHP scripts that use function_exists() function to figure if PHP Interbase API can figure the number of affected rows. Jouni Ahto has said he'll commit the ibase_affected_rows() patch and other patches soon when he gets some time. We'll add it to PEAR DB then, and return not capable if the function does not exist. Hopefully we'll have it by PHP 4.0.7. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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 basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] At 17:55 07-08-01, Stig Sæther Bakken wrote: Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? It's not much of a challenge really. If we decide it should be done, it can be done... Ok, so it's just a matter of minit_done and rinit_done properties for each module? Let's go for that, and either keep dl() or replace it with php_load_extension() (the difference being that the latter knows what file extension to use on your platform). - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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 basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] At 19:40 06/08/2001, Andrei Zmievski wrote: On Mon, 06 Aug 2001, Zeev Suraski wrote: At 07:10 06/08/2001, Sterling Hughes wrote: What if you use 50 different shared extensions, for different scripts on the same box? Should you load them all in each time? I don't think so... Other than your phobia, there's no real reason not to do it :) No performance hit at all? Nothing measurable. That was actually measured (changing PHP to initialize extensions just-in-time, in case they're actually being used) - and it turned out it wasn't giving any noticeable performance gain. If there were a thousand extensions, we may have to rethink it - but the good solution would probably be JIT initialization. Now we're talking! I assume it is not straightforward, what are the technical challenges in doing JIT module initialization? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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 basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] By the way, if it's really important, we can look into supporting it. The way it was before - it worked in most cases (assuming you never tried to use a class before you dl() the corresponding extension), but could result in crashes in other cases. I don't think it's very important, though. dl() should most probably be deprecated from the language, as it's not supported in thread safe mode, it's slow and insecure. It also creates a host of interesting bugs/buglets that are difficult to hunt and fix. Other than that - it's great :) Uhm, are you suggesting we take away the possibility of loading extensions at run-time? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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 basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c
[Zeev Suraski [EMAIL PROTECTED]] Please don't just say it's useful, please say why :) dl() has absolutely nothing over loading in php.ini, and has many drawbacks. Please allow me to coin a new term: Zeev-ism. Zeev-isms are of the form users don't need X or 95.6% of the scripts out there don't need Y. ;-) The fact is that a lot of people (typically ISP users) don't have access to php.ini or .htaccess. If these people need a third party extension, or one that was not built in their ISP's version of PHP, they either have to get their ISP to include it (and if the ISP is big enough and the client small enough, they won't care), or use dl(). If their ISP hasn't disabled that function, in which case they're screwed anyway of course. I do get kinda worried when you pop out a statement like we're probably going to deprecate dl() anyway, being able to load extensions at run-time sort of is one of PEAR's foundations. Let's try to fix these problems rather than cripping PHP. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Portability concerns
[Phil Driscoll [EMAIL PROTECTED]] I was going to send a post on this topic yesterday, but then I deleted it, but maybe it is worth airing incase it prompts someone whose brain is working better than mine was yesterday to rifine the idea. My thought was that it may be possible to get rid of some of the portability issues by implementing a new function php_portability() which takes TRUE or FALSE arguments to turn it on or off. The idea is that when switched on, it could modify the behaviour of certain functions dependent on the php.ini settings - e.g. addslashes or stripslashes would do nothing if magic_quotes were on in php.ini and do its normal job if they were off. Sadly the above example is complicated by having magic_quotes_gpc and magic_quotes_runtime, so it may not be possible to sort out. The other reason I didn't post yesterday, was that I could not then think of any other functions for which this kind of behaviour would work :) With such a php_portability() function, it would be _even_ harder to write portable library code (because you need to handle both settings). Two wrongs won't make this one right. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Tests: naming
[[EMAIL PROTECTED]] Hi, I assume that tests are named 001,002, etc, for historical reasons only? I believe that a test named 'trim.phpt', is better than 010.phpt? You can call them whatever.phpt, the reason they're numbered is to define the order they are checked in. Maybe naming them 03trim.phpt would be a good compromise? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Portability concerns
[Phil Driscoll [EMAIL PROTECTED]] On Saturday 04 August 2001 08:49, Stig Sæther Bakken wrote: [Phil Driscoll [EMAIL PROTECTED]] With such a php_portability() function, it would be _even_ harder to write portable library code (because you need to handle both settings). Two wrongs won't make this one right. :-) Please explain! Say PHP had a function to put it in portable mode changing the behaviour of a few functions. Then for example PEAR classes would have to deal with running both with and without this mode, since the user can enable or disable it at will. So this would in fact add complexity to the process of writing portable PHP code. I think André is right that it's better to educate users (for example by telling them to disable magic_quotes :-). - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: mt_* functions
[[EMAIL PROTECTED]] Hi, Currently, the rand_functions all have mt_ clones, which use a in-PHP-implementation (Mersenne-Twister) rather than an external implementation. This is IMHO a bit strange way of chosing between implementation. My suggestion is to make it only one familiy of functions, the implementation of which is determined by an ini-entry. (rand = system vs. rand = mt, or something like that, default: mt). The functionality is the same (*), and IMO it's a per-system-decision wether you want to use the mt-algorithms or the system ones. (usually mt, unless your system has a real good / very special one) For backwards compatibility, mt_* can be aliased to their normal equivalents. Please don't. Ini settings that change semantics are a bother, and people should be able to choose their random function. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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 / configure.in
[Andrei Zmievski [EMAIL PROTECTED]] On Thu, 02 Aug 2001, Jani Taskinen wrote: Some things seem to be tested many times in same configure run. I would be against removing config.cache on every configure run. Many people configure PHP multiple times a day during development and this slows it down. We should rather see what problems caching presents us with and try to resolve them. Absolutely. There's a reason for config.cache's existence. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] include_path with .
[Stig S. Bakken [EMAIL PROTECTED]] Hi, I would like to suggest that we change how . in the include_path is treated to being relative to the file doing an include, instead of relative to the main script file. There was some mention of this a few weeks ago, and it's a problem for PEAR users using ISPs that won't let them change their include_path. [Andi Gutmans [EMAIL PROTECTED]] I have already commited a change that if I file isn't found in the include_path then PHP will check for the file in the running scripts' cwd. Ah, in the cwd of __FILE__ then (which is what I meant), not $PATH_TRANSLATED? - Stig -- 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 /sapi/cgi cgi_main.c
Yes I think it should. - Stig [Shane Caraveo [EMAIL PROTECTED]] Can this be put into the 4.0.6 tree? - Original Message - From: Shane Caraveo [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, May 22, 2001 4:05 PM Subject: [PHP-CVS] cvs: php4 /sapi/cgi cgi_main.c shane Tue May 22 16:05:09 2001 EDT Modified files: /php4/sapi/cgi cgi_main.c Log: The -c commandline option was not working at all, need to set the path override before calling on the module startup. -- 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] -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PEAR-CVS] cvs: pear /Net_Ping Ping.php package.xml
[Andre Langhorst [EMAIL PROTECTED]] Tomas V.V.Cox wrote: On Tuesday 22 May 2001 19:58, you wrote: But please say somewhere that the class is experimental, so users won't use it and pear developers can help on improve it. The experimental dir is a quite good way of saying this for me. +1 No. We have a naming/filesystem scheme and we have a versioning scheme. Version information should not be reflected by the filesystem. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] language specification project
[[EMAIL PROTECTED]] Hi, About the language specification project: The goal I see for this project is coming out with a document that is useful for users. Something that they could hold in their hands, and from reading it, they'd know whether something is supposed to work or not. Now, I'm sure that it's possible that during the course of the project we'll find inconsistencies in the implementation that need to be fixed, but as a guideline the spec should describe the implementation. We really don't need the kind of stuff that were with C++, with 80% conformance and 99% conformance and all that headache. -- I agree, in part. I think however we should document the syntax as it ought to be, ie, some of the stuff is not yet realized like what sascha was reffering to as far as the zend-cvs discussion (which I didn't really follow too well). Or, obviously, bugs should not be at all considered in the specification itself. (discussed mid-november 2000) This project seems rather dead to me. Though, I think it should be continued. Some work was alread been done. I would like to try to reanimate it. I think, like Sacha I think, that a spec should be quite exact and precise. Zend was made without a proper specification, something they try to hammer all first-year students at my university you should NEVER do that. It is very annoying to have to specify all quirks, I think it is most practical to document it the way it should be, and then note whereever it goes wrong. Most of these 'where it goes wrong's are in fact quirks, that normal users shouldn't meet, and if they do, it works so strange, it can't be documented in a easy way. (what do you think of this one: $a[5] = 'abc'; $foo = $a[5]; $b = $a; // should copy the array $a[5] = 'boe'; echo $b[5]; // boe... Array elements that have a reference are not copyd, but a reference is made... bah! ) And the target shouldn't be the user at first. Then, IMO the next step would be to make zend comply to the specs, finally making version 4.1 as some people seem to want. And THEN you can publish the spec. With the current quirky behaviour, PHP won't be seen as a well and neatly specified and LOGIC language, but rather as some potpourri (mixup) of other languages. But before I start, I want to know your opinions nowadays... And, I really need (=want) to know whether Zend WILL go comply to the new spec. About what the spec exactly will be: I, and anyone who wants, just make it based on their own views. First of course the framework should be made ready, so concurrent work can be done more easily. I think adapting a bit to the structure of the phpdoc documentation isn't such a bad idea. Regulary it is posted to phpdev, and then you can flame it, or whatever. And then some decission needs to be made, consensus seems hard, but hey, lets add the rule that if consensus isn't reached I'll decide ;) (by the way, I came onto this trying to document the language properly, but that is really hard to do... if you want it to have as exact as possible) (BTW2: zend-cvs discussion? where are the archives? and is there web-cvs for zend somewhere?) SUMMARY: - spec framework made (sacha?, myself?) - spec made, as how it should work, so close as possible to PHP, but in case of quirks, just a logic behaviour. (Anyone who wants. Myself included) WITH notes where zend does something strange. - extensive discussion on phpdev - zend adapted - spec published along with new version of PHP/zend I think the important thing is just to have the language specified and thoroughly documented, with BNF and all. Let quirks be quriks for now, a specification process should not fix them, but put them all on the radar for future fixing. There's always someone who relies on a quirk. If you mix the spec/doc and fixing processes you're in deep shit, that's something the first-year university students should learn, too. ;-) Anyway, this is a process Zeev Andi would have to be deeply involved in, even though I think it's best to have the actual writing done by someone else, to have an extra audit point to come up with the questions implementors sometimes forget. On the other hand, Zeev and Andi may not want to prioritize their time on this, since a real language specification would clear the path for alternate parser implementations. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Fork() in php?
[Manuel Lemos [EMAIL PROTECTED]] Hello Zeev, On 12-May-01 14:14:10, you wrote: At 04:05 12/5/2001, Wez Furlong wrote: I know that there might be some bad interactions with apache if you fork, but if you allow PHP to spot that it forked and call _exit() instead of returning into the SAPI, you should be OK? Not really, the parent has to somehow call wait() on the child, otherwise you'd get zombie processes... Generally, implementing that sort of stuff within the Apache framework is a bit of asking for trouble :I Anyway, PHP really lacks of real multi-threading capabilities. Things like database connection pooling, (non-HTTP) server request handling, and GUI event processing could be properly implemented in PHP with multi-threading capabilities like the way it is done in Java, Perl, Python, etc. but can't be done right in PHP because it lacks multi-threading support. Any plans to add multi-threading capabilities to PHP? There are no plans for adding MT to PHP itself, but you do have a poor man's cooperative multi-threading through ticks. So now we have a poor man's objects and a poor man's multitasking. What does that say about us? :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] copyright question for ext_skel generated source
[Thomas Fromm [EMAIL PROTECTED]] hi, i want to build in php extension support into the kdevelop applikation wizards, to generate a basic source Makefile construct alike this generated by ext_skel. At the top of the .c and .h files is an header which showed an copyright of this generated source to the php group. if i use these generated source, and put in there my own stuff and modify them, then its not allowed to put these source under a different licence, isn't it? (normally is generated source licence free, so this confuse me a little bit) can i have the permission, to create these basefiles with the application wizard of kdevelop? IMHO it's ok to use the skeleton files and change the license, even to a commercial closed-source one. I don't know about others' HO though. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Fork() in php?
[Jason Greene [EMAIL PROTECTED]] I was thinking about MT in php, but the platform differences would be a nightmare. We could abstract it like perl does, though even their implementation has problems. I would like to start with process control features (fork(), signals, waitpid() etc), but I am not sure where everything should go. Should there be a /ext/process? Should signals be in a separate extension? Let me know what you guys think. -Jason IMHO this type of functionality should only be available in a dedicated SAPI module, at least now. There are a lot of worms waiting to come out of this can, so put the can in a bucket first. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Fork() in php?
[Richard Heyes [EMAIL PROTECTED]] There are no plans for adding MT to PHP itself, but you do have a poor man's cooperative multi-threading through ticks. Are these documented anywhere? Uhm, it seems not. Me fix. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug in building standalone DSO modules
[Alexander Bokovoy [EMAIL PROTECTED]] On Sun, May 20, 2001 at 01:34:49AM -0400, Stig Sæther Bakken wrote: [Petr Cech [EMAIL PROTECTED]] Hi, I've been strugling for some time with the possibility of building some extension not inside of ext/ dir, but using phpize to just add some module later. Strangely, it didn't work - mostly. configure was created, Makefiles, config.h ... Just great, but the resulting .so did not. But only in some modules. And I fond also why: Modules don't #include config.h generated by the ./configure - including this right at the top fixes the problems. So, putting in every module and having phpize generate -DHAVE_CONFIG_H would make it really painless for everyone to build his favorite extension #ifdef HAVE_CONFIG_H #include config.h #endif phpize will add HAVE_CONFIG_H as of 4.0.6. I've tested PHP 4.0.6 RC1 and found that: 1. configure defines DEFS=-DHAVE_CONFIG_H 2. After running ./configure this definition goes into config.status 3. config_vars.mk still has empty DEFS line (DEFS - ) As result, HAVE_CONFIG_H is underfined. It's not part of 4.0.6RC1, but on the head of the PHP_4_0_6 branch. I added it to CPPFLAGS instead of DEFS. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] CGI output performance
[Sascha Schumann [EMAIL PROTECTED]] Hi, while looking at the strace output of readfile() in a CGI context, I noticed that the CGI code (a) uses stdio and (b) that it only outputs chunks with a maximum size of 16KB. The effect is clearly visible (reproducible, both tests were run with a warmed-up cache): $ time ./php-mmap-fwrite ./script /dev/null 2.75user 0.47system 0:03.22elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (244391major+65minor)pagefaults 0swaps $ time ./php-mmap-write ./script /dev/null 0.03user 0.01system 0:00.04elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (284major+64minor)pagefaults 0swaps E.g. using write() is about 80 times faster on Linux than the limited fwrite() version. fwrite() was probably chosen because it is a standardized function and is expected to work everywhere. So, what we would need to do is to add a check whether write() works on the system before using it. Are there any objections to such a change? Since the change is local to the CGI SAPI, I see no problems with it. Using fwrite in conjunction with mmap is just wasteful anyway. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug in building standalone DSO modules
[Petr Cech [EMAIL PROTECTED]] Hi, I've been strugling for some time with the possibility of building some extension not inside of ext/ dir, but using phpize to just add some module later. Strangely, it didn't work - mostly. configure was created, Makefiles, config.h ... Just great, but the resulting .so did not. But only in some modules. And I fond also why: Modules don't #include config.h generated by the ./configure - including this right at the top fixes the problems. So, putting in every module and having phpize generate -DHAVE_CONFIG_H would make it really painless for everyone to build his favorite extension #ifdef HAVE_CONFIG_H #include config.h #endif phpize will add HAVE_CONFIG_H as of 4.0.6. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] bug or feature?
Zeev/Andi,
Right now you can replace the object returned by new Foo by
assigning $this in the Foo constructor, like this:
class Foo extends PEAR
{
function Foo()
{
if (!init_foo_resource()) {
$this = $this-raiseError(could not initialize foo resource);
return;
}
}
}
This is a cool feature, and doing what the example above does would be
very nice, but PEAR coders still have the decency not to. The
alternative is to have dumb constructors that don't do anything that
may go wrong, and use a second method call for the rest. That's twice
the number of lines!
Anyway, I'd like to see $this assignment in constructor:
1. dismissed as a bug
2. documented as a feature, or
3. subject to discussion resulting in (1) or (2)
- Stig
--
Stig Sæther Bakken [EMAIL PROTECTED]
Fast Search Transfer ASA, Trondheim, Norway
--
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] Latest commit -- depreciation of call_user_method()
[Jani Taskinen [EMAIL PROTECTED]] On Thu, 17 May 2001, Rasmus Lerdorf wrote: I don't agree. Have you noticed the thread about domxml currently running in php-dev@? Wouldn't that justify a 4.1? What would? No, I don't think a single extension should affect the PHP version number to that extent. But I do think we should be moving towards versioning the extensions individually. Could you explain how having separate version numbers for extensions would help at all? As long as the extensions are distributed with the main PHP package, that is. It doesn't help of course. As long as these extensions are in there, I think changing any of their API's is a justification for 4.x release. Again, this is how it's always been done. A single extension has never caused a minor version bump, and I don't see it happening (the only extension I could see remotely justifying that would be ext/standard, which is part of the core anyway...) It is becoming painfully obvious what kind of release nightmare PHP is cornering itself into. The only way out of this mess is to split PHP into smaller projects with their own release cycles, which is what I wanted to do with 4.1 in the first place. Until we do that, we're stuck with our Cathedral, and will continue having RC/QA periods of at least four weeks on micro releases. So MNSHO is that 4.1 should be the split, and nothing but. We can release 4.2 just a couple of months after to address the other things people have signed up for 4.1 now. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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 or feature?
I disagree with your conclusion here. If a side-effect is useful enough and people want to use it, why not document it de-bastardize it? The fact that other OO languages implement this should be a hint that it shouldn't be impossible to do in a different OO model. Why care more about forward compatibility than using what we have? And if assignments to self would be impossible to implement in another OO model, this would be only one of many compat breakers. - Stig [Zeev Suraski [EMAIL PROTECTED]] Guys, This isn't up for a vote... It's a side effect of implementation, and other implementations may invalidate it. We can't document it as a feature, because it may bite us big time in the future. Zeev At 19:21 18/5/2001, Sebastian Bergmann wrote: Kristian Köhntopp wrote: Assignments to self (to $this) are a very useful features and common in other OO languages as well. I'd vote for keeping the feature, document it as such and making it legal. +1 -- sebastian bergmann[EMAIL PROTECTED] http://www.sebastian-bergmann.de bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- 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] -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: AW: AW: [PHP-DEV] arrays
Acknowledged. But IMO the arrays will be either clearly continous or clearly associative/non-continous in 99.2% of the cases (Zeev statistics applied). I think it's fine to keep treating an array as non-continous if there has ever been holes or string keys in it. - Stig [Zeev Suraski [EMAIL PROTECTED]] It doesn't necessarily mean having to scrap the whole idea, just that we'd actually have to count elements, instead of just flagging. I'll try to think if there are any problems with this approach. Zeev At 02:57 15/5/2001, Andrei Zmievski wrote: At 02:51 AM 5/15/01 +0300, Zeev Suraski wrote: Ok, if we humor ourselves with this feature... What kind of behavior would you expect if a key gets deleted, and there are no longer associative members in the array? Good point... any time savings on the extension side would be negated if the engine had to check whether the array is fully associative on each operation. -Andrei -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Latest commit -- depreciation of call_user_method()
[Zeev Suraski [EMAIL PROTECTED]] One comment; Why? :) We've been in that discussion before. In my opinion, we should probably rethink our whole deprecation approach. Yes, I know that people don't like the burden of maintaining downwards compatibility. I sure as hell don't. But PHP's huge popularity boost put the development team in a position where it has *a lot* of responsibility; Doing the wrong thing will reflect badly on PHP and its acceptance as a stable solution (not segfault wise, but development wise). On the other hand, I really don't like the bloat either. So, what should be done? In my opinion, the approach of adding E_NOTICE notifications to functions doesn't cut it; It won't significantly improve the situation. I think we should go in a different path (or an 'extended' path) - IMHO, the best approach would be adding some sort of a 'LEAN_AND_MEAN' mode to PHP's build. When built in this mode, bloat code will be #define'd away, or displayed as 'deprecated' in a similar manner to the way warn_not_available works. That gives everyone almost everything - people who care about the bloat (like me) will build it in LEAN_AND_MEAN mode, hosting companies or legacy sites, who care most about having their code go on working with minimum hassle - won't mind the added bloat. If kept closely documented, people who care enough about the bloat will be able to go through the checklist, make sure their sites are compatible with it, and turn this mode on. The only drawback I see to this approach is that the code itself remains and 'bloats' the various files. We can probably overcome this problem by separating legacy code to separate files. I second this. Although we do have some minor bloat :) here and there, I don't think we should go out of our way to break people's scripts. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Latest commit -- depreciation of call_user_method()
[Jani Taskinen [EMAIL PROTECTED]] On Wed, 16 May 2001, Zeev Suraski wrote: Also bare in mind that a very large percentage of the developers don't *want* to be forced to change their code, and consider it to be a Who's forcing anybody to update anyway? misfeature in the language if it breaks downwards compatibility in between releases, regardless of whether they get a clear notification about it or not. It seems like everybody just ignores my emails..oh well. So I can rant again. :-p Have you ever heard that you can also change that number in the middle? 4.0.6 This one^ It can be something else than an ellipse called zero..it can even be a number 1!!! Whoa! Never thougth about that?! And maybe, just MAYBE then these people (who you seem to think of as complete idiots) would READ the NEWS file? Or e.g. RELEASE_NOTES ? Or is that number in the middle reserved for something special? Something the 'group' only know of and don't want to tell us lower class people? Maybe the 'group' could take their thumbs out of their asses and start DOING something? And maybe they could start listening to new ideas for once and a while. Or is the 'group' nowadays only Zeev/Andi ? It would be really nice to hear from the other members of the 'group' also as it really seems like the only ones speaking for it are Zeev/Andi.. Or could someone please define the function of this mysterious 'group' ? (And please, someone else than Zeev/Andi.. :) Hey Jani, you can attribute yourself as the PHP Whipping Boy now if you like. I think you just got enough points. :-) I completely agree that we should start using the minor version. It's like we're afraid to touch it because that would imply too big changes or something. Seeing how huge our process between micro versions has become, it's just getting weirder. I think we should take a good look at the 4.1 TODO and split into a 4.1 and 4.2 TODO, and have 4.1 out sooner, maybe even as the next release after 4.0.6. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: AW: AW: [PHP-DEV] arrays
[Zeev Suraski [EMAIL PROTECTED]] At 13:34 16/5/2001, Stig Sæther Bakken wrote: Acknowledged. But IMO the arrays will be either clearly continous or clearly associative/non-continous in 99.2% of the cases (Zeev statistics applied). I never claim to be accurate, I usually say 99% :) I don't either, my random generator just has a higher resolution. :-) I think it's fine to keep treating an array as non-continous if there has ever been holes or string keys in it. I actually think that arrays with both numeric and associative indices are quite common. Lots of apps I've seen use them, as well as some of PHP's internal functions. You're probably right. But the question is really how often arrays change between being continous and associative/mixed/non-continous? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] removing ereg functions
[Brian Moon [EMAIL PROTECTED]] No, sorry, I think you misunderstood my question. I would just like to see a --disable-ereg option for configure. I would never dream of removing ereg from PHP as a supported function set. It would break Phorum and lots of stuff I have written. I understand your reaction now Rasmus. Sorry for the confusion. If you write a regular expression implementation in PHP that we can use as a fall-back in PEAR code if both preg and ereg are disabled, I'll think about it. In general I'm against new options simply because of the interop nightmare we've spun ourselves into. :-P - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] removing ereg functions
I have to say that I'm more in favor of removing --without-pcre-regex than adding --disable-ereg, especially now that Apache is starting to bundle PCRE. And I don't think the bloat argument holds water, it sounds to me like more of a warm-fuzzy-feeling issue than a real performance/maintainability issue. - Stig [Cynic [EMAIL PROTECTED]] yes, PCRE is part of Apache-2.0 On Wed, 16 May 2001 -0400, [EMAIL PROTECTED] wrote: Rasmus Lerdorf wrote: But, that all makes sense and tells me that it is not worth pursuing. Is the regex lib bundled with apache always as part of the core or just included with certain modules? It is part of the core. As Apache 2.0, I believe PCRE is also a part of the Apache core? -Sterling -- 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] -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: AW: [PHP-DEV] arrays
Any XML-RPC implementation would benefit from seeing easily whether a value is a continous pure numeric array, associative array or a mix. It should be a trivial fix, and the performance difference is negligible. - Stig [Zeev Suraski [EMAIL PROTECTED]] Why do you need it? Nobody ever needed it until now. It'll slightly slow down each and every hash update all over PHP, so unless it's really necessary, we should do without it... Zeev At 19:40 13/5/2001, Harald Radi wrote: thanks, but wouldn't it desireable to have such a flag ? it wouldn't be a big effort, would it ? -Ursprungliche Nachricht- Von: Andrei Zmievski [mailto:[EMAIL PROTECTED]] Gesendet: Sonntag, 13. Mai 2001 18:34 An: Harald Radi; [EMAIL PROTECTED] Betreff: Re: [PHP-DEV] arrays At 06:01 PM 5/13/01 +0200, Harald Radi wrote: hi, is there a simple way to determine if a pval of type IS_ARRAY contains non-interger indices (associative array) ? something like a flag in the pval structure that indicates that add_assoc_* was called on it. Nope, you pretty much have to walk through it and call zend_hash_get_current_key_type() until you find string key or encounter the end of the array. -Andrei -- 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] -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] stat/fstat
[Zeev Suraski [EMAIL PROTECTED]] Hey, I just got around to writing a PHP script that uses stat(), and was quite surprised to find that instead of using string indices, it uses hardcoded/obscure numeric indices, e.g.: Array ( [0] = 2050 [1] = 1114462 [2] = 16877 [3] = 2 [4] = 503 [5] = 513 [6] = 11065 [7] = 1024 [8] = 989532201 [9] = 989532201 [10] = 989532201 [11] = 4096 [12] = 2 ) Is there any reason for this? If not, I'd like to add meaningful names as well (I guess it's way too late to remove the numeric indices) Why not have both numerical and descriptive indices? Backwards compatible, slightly bloatish, but not really a problem. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] documentation
[Harald Radi [EMAIL PROTECTED]] hi, how should classes be documented ? since they are not really a function they only have a return value together with new and function/function seems to be illogical. is there also a way to document members and attributes ? is there a list of tags that are available ? There's an example on how to document a classes in phpdoc/en/pear/pear.xml. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Dynamic Update of DNS ??
[Stig Venaas [EMAIL PROTECTED]] On Mon, May 07, 2001 at 06:54:53PM +0200, Vincen Pujol wrote: Hi, Sorry for the crossposting but I don't know where to find a solution for this. I need to be able to update dynamically entries in a DNS (Bind 9). My DNS supports dynamic updates but how to do dynamic updates in my DNS server from a PHP Script ?? Might be interesting to add such a thing to PHP as a PEAR extension maybe, but you could use a separate program for that, and just execute it from PHP. Another possibility is to use my LDAP back-end for BIND rather than dynamic updates. The effect is mostly the same. BIND will look up the data in LDAP every time (lose some performance, normally not a problem), and you can modify the data at any time from for instance PHP by accessing the LDAP server. If anyone wants to look at the LDAP back-end, see http://www/dns/bind/bind-sdb/. If you look at ^^^ I guess this will take most people to somewhere else than they expect. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zend API changes
[Björn Schotte [EMAIL PROTECTED]] * Zeev Suraski wrote: There's a good starting point already, people are more than welcome to extend it. I don't understand why people should work in their spare-time on a tool which is published under the Zend Licence (which is similar to QPL). As we know of QPL, all developer's seem to be equal, but some seem to be more equal. As you know from Daniel Grossmann, I'm not the only one who has this opinion. Although I would not use the same tone, I completely understand why some people feel this way. Since the Zend engine is not pure open-source, IMHO Zend Ltd. have a bigger obligation to the PHP community to document all of the API than if Zend carried, say, a BSD license (because then it'd be more natural for the community to chip in). - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zend API changes
[Zeev Suraski [EMAIL PROTECTED]] At 21:05 4/5/2001, Hartmut Holzgraefe wrote: PS: about the welcome thing above ... - you should know that i have put a lot of work into the manual (both english and german) and the function tables Hartmut, I wasn't trying to understate your work on the manual; I told you personally that the function reference mechanism that you build was very impressive and useful. I wasn't being sarcastic when I invited you (and anyone else) to help document the Zend API. I know I won't be getting around to doing it in the near future, so if nobody else does it, it'll simply remain undone. - afair there was someone who started to write a 'extension building manual' or something about a year ago and it was you , Zeev, who told him that this was useless effort as this was already beeing taken care off (without pointing him to this project or inviting him to join it) correct me if i'm wrong as i do not have found this posting in my archives yet You're not wrong; It's been done and published (http://www.zend.com/apidoc/), and is the base for additional work that I invited people to improve on. Hey, are the sources for this manual available somewhere? CVS maybe? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] connection_timeout() and PHP 3
[Jani Taskinen [EMAIL PROTECTED]] On Fri, 4 May 2001, Hartmut Holzgraefe wrote: Jani Taskinen wrote: On Thu, 3 May 2001, Zak Greant wrote: Does anyone know if connection_timeout will be disappearing from PHP 3? Put it this way: Does anyone know when PHP 3 will disappear? :) IMHO it will die together with the FAT filesystem ? So it's dead already? :) Anyway, why do we still give it out? On downloads page that is.. IMNSHO, it should disappear. If not, gimme some reasons why not. Some people who are fanatic about the GPL and the issues RMS has with the PHP 4 license still use PHP 3. IMHO we should offer it for download, but be less active in supporting it. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] extension/module versioning
[[EMAIL PROTECTED]]
dev team,
what are the chances of having a function call for every extension that
returns the version? this would be extremely useful for determining
whether the correct version is installed, rather than checking to see
if the function_exists().
eg.
$version_id = xml_version();
or
$version_id = ibase_version();
thanks for your attention,
I second this, although I really think a constant or maybe _one_
function for checking any extension's version would be best.
Also, I think we need some guidelines for version numbering, so
different extensions don't have vastly different ideas of what it
means when the major version changes.
Here's a suggestion from PEAR:
-- snip --
We encourage maintainers to use one of the following version numbering
schemes:
MMDD( = year, MM = month, DD = day)
V[{a,b}N] (V = version) [ alpha or beta release N ]
V.R[{a,b}N] (R = release)
V.R.P[{a,b}N] (P = patchlevel)
PEAR tools follow these rules to compare versions:
For MMDD, V, R, P and N, a higher number indicates a more recent
release. Any beta of a release is considered newer than an alpha of
the same release.
When comparing V with V.N, V.N is considered newer if the version part
of V.N is greather than or equal to the version part of V. The same
logic applies to V.N.P vs. V.N.
Releases with lots of known bugs, potential API changes etc. are
typically alpha releases. Beta releases are when the risk of API
changes is minimal and you believe most bugs are found.
Between patchlevels, there should be no or very limited, and
compatible, API changes. Between releases, API changes should be
compatible. Between versions it's ok to break the API.
An API consists of names of classes, functions, documented globals,
which parameters are accepted by functions/methods and their
semantics/behaviour.
-- snip --
IMHO it's a simple scheme that should be easy to understand for
extension developers and users.
- Stig
--
Stig Sæther Bakken [EMAIL PROTECTED]
Fast Search Transfer ASA, Trondheim, Norway
--
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] default location of php.ini changed?
[Zeev Suraski [EMAIL PROTECTED]] At 20:54 6/5/2001, Mike Robinson wrote: 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? No it wasn't; Guys, wasn't this changed back? Uhm, I'm still testing this patch on my laptop (I added a --with-layout option that is PHP by default, but you can set it to GNU to get the new defaults). Sorry for being a bit slow, I'm spending most of my spare time transforming the jungle outside my house to something more lawn-ish these days. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Classes function names
[Zeev Suraski [EMAIL PROTECTED]] I think that there are two ways to look at the issue that John raised. One, is a cosmetic change, that would add a bit of bloat to classes, and retain another name in them. Allowing access to it using some specialized function (get_beautiful_class_name() or something like that). The other, is a more fundamental change, and it is to change PHP to be case dependant. PHP 4.0 follows the standard set by PHP/FI 2.0 (or earlier), and maintains case sensitivity for variable names, but not function names or class names. IMHO, there's very little reason for this inconsistency, and PHP would have been better off with full case sensitivity across class names, function names and variable names. It would also improve performance fairly significantly. IMHO, in a compatibility breaking upgrade, we should look into defaulting to case sensitivity, while allowing case insensitivity as a non-default option. Ouch. What about making case sensitivity an option that is disabled by default in 4.1, and changing the default for 4.2. IMHO changing this default alone is enough to warrant the 4.1 - 4.2 transition. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Release process
[Zeev Suraski [EMAIL PROTECTED]] In an effort to stop a long going ping-pong again, let's concentrate on figuring out what was wrong with the old release, and trying to improve it in the future. I'll start by saying that generally, overall, the last release was pretty good. Ok, so COM didn't work, but only a very small number of people is actually affected by this. Overall, the QA process *worked*. To get to fix the bugs in the QA process, we need to look at the exceptions to the rule, i.e., the things that didn't work out right. The first and obvious example then, would be the COM module. I believe that the main difference in the COM module patches, when compared to other patches, is that it was mainly to implement new functionality, or to rewrite code in a better way. We should probably have a guideline that new code/code rewrite patches should not be submitted to RC branches. Another issue was the inability of people to deliver patches on time. I.e., there were quite a few patches that were important to put in the release (i.e., fixed bugs) but came in after 'the last RC' was announced. That's one of the reasons we had so many 'last RCs' in this RC round. Whether there's a good solution here is not very clear; My guess is that there isn't. The question is whether we should be more aggressive about dates (i.e., if you didn't submit your patch on time, it's your problem) or not. There's no good answer here IMHO, comments welcome... Those were the two main broken things about the last release. Let's concentrate on fixing them instead of rethinking the whole architecture, because it *worked*. We need to fix either the scope (bugs that need to be fixed) or the release date, and stick to that. Tradition is to move the release date. If we move both at once, we're in trouble and chances are it will delay the release even more. So, if the showstoppers are identified before rolling the first RC, we can either fix them first, or roll the first RC and fix them all before rolling the second (depending on the general activity on the main trunk, IMHO it would be better to do two RCs). We'll always have the problem of I need to MFH this, pretty please, but I think that started working well at the end of the 4.0.5 QA. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Release process
[Andi Gutmans [EMAIL PROTECTED]] At 05:52 AM 5/3/2001 -0400, Stig Sæther Bakken wrote: We'll always have the problem of I need to MFH this, pretty please, but I think that started working well at the end of the 4.0.5 QA. :-) I actually also think that on a whole 4.0.5's release process was pretty good and a big improvement on anything we had in the past. That brings me to more current events. I'd like to roll an RC1 for 4.0.6 pretty soon (Saturday?). I think the only fix which really needs to make it in (unless I forgot something) is the libtool detection patch. So we'll use a codename for it that will the third noun on page 5 of sunday's morning paper in Trondheim (as was agreed by lack of protest a few weeks ago ;-). - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Release process
[Oyvind Moll [EMAIL PROTECTED]] * Stig Sæther Bakken [EMAIL PROTECTED] | | sunday's morning paper in Trondheim That won't be much of a name. (...or has Adresseavisa started printing a Sunday edition?) That was of course supposed to be saturday. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] MySQL related
[Hien Duy Nguyen [EMAIL PROTECTED]] From: [EMAIL PROTECTED] Operating system: RH7.1 PHP version: 4.0 Latest CVS (03/05/2001) PHP Bug Type: MySQL related Bug description: can't make connection to Mysql DB Warning: MySQL Connection Failed: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111) in /home/hdn/public_html/test.html on line 11 Couldn't connect to MySQL Mysql server is up and running, I can connect to it with shell command. The MySQL client that comes with PHP has a different default mysql socket configured than the RedHat-installed MySQL. Run as root: echo 'ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock' /etc/rc.d/rc.local eval `tail -1 /etc/rc.d/rc.local` - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] using @php.net address.
[PHP development @echospace [EMAIL PROTECTED]] This might be a dumb question, but I couldn't figure it out myself. Apparently I had [EMAIL PROTECTED] address for a while, but I never used it. How do I set it up to forward mail to my account - [EMAIL PROTECTED] (that's the one I use to mail and read the list)? The mail is forwarded to the address listed in the cvsusers file (http://cvs.php.net/viewcvs.cgi/CVSROOT/cvsuser). Drop a mail to [EMAIL PROTECTED] if you want it changed. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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.6
[Cynic [EMAIL PROTECTED]] recode is GPL'd IIRC and thus (your mileage may vary) not very usable, doesn't build on win32 systems, and the author has no interest in changing that. libiconv is pretty good too. I don't know if it builds on Win32 though. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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 -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zend Optimizer
[Scott Wolf [EMAIL PROTECTED]] What is the highest version of php that the optimizer supports. I have gone all through the zend web page and can not find any references to 4.0.5 or 4.0.6. Are they currently supported, or do we need to wait for update to be made? Well, first 4.0.5 and 4.0.6 need to be released, don't you think? :-) I'm pretty sure Zend will make a 4.0.5 version of their products available on the same day 4.0.5 is released. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] sprintf and strings with NULL byte
[[EMAIL PROTECTED]] On Wed, 25 Apr 2001, [EMAIL PROTECTED] wrote: Oh, and I went and fixed this anyway. That's cool. I'd just split that php_formatted_print() function into two parts. One that does the argument handling and one that just does the work like we have done with so many other functions. Yes, we can do that. But does php_formatted_print() have feature parity with glibc printf()? Well, no, because it is now binary-clean! ;) Do you need exact 1:1 parity? It does most of the things that glibc printf() does. glibc printf doesn't have %b :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] Timeout Function:
[Jason Sims [EMAIL PROTECTED]] Personally, I think having an alarm (timeout) function is a really good idea. Setting a timer, and then being able to jump from whatever you are doing if it is taking too long is something that has helped me do some really neat stuff in C and Perl... and I was a little dissapointed when I learned PHP didn't have. Although I've been able to solve my current problem with fsockopen(), I think an alarm function would be nice to have for other things. Perl is open-source, right? Probably the best way to implement this in PHP would be to look at how Perl is doing it and go from there. It's not that simple in PHP. Perl is a standalone environment, so you can use signals to your heart's delight. But PHP is usually one with Apache, and signals are not easily shared. I suggest implementing a timeout using ticks on the C level. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] unix install paths changed
[Zeev Suraski [EMAIL PROTECTED]] At 17:47 23/4/2001, Stig Sæther Bakken wrote: [Sebastian Bergmann [EMAIL PROTECTED]] Zeev Suraski wrote: This broke the Win32 build, and when I went to fix it, I couldn't find the letter with the diffs for this change. Any idea why it wasn't sent? Or is it just me that didn't get it? Same here. I didn't recieve a cvs commit mail, but something broke the Win32 build. There's a bunch of constants that just need to be defined in Win32. Most of them don't have any meaning in Win32... Other than that, apparently you changed at least one #define name, so php_ini.c no longer compiles (other than the fact there's no build_defs file in Win32). Did you get this diff email? Nope. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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] unix install paths changed
[Zeev Suraski [EMAIL PROTECTED]]
At 04:25 22/4/2001, Stig Sther Bakken wrote:
default php.ini path: now using --sysconfdir option, defaults to
/usr/local/etc ("configure --sysconfdir=/usr/local/lib" for old behaviour)
While I completely sympathize with the motivation, I think this has a
very high WTF rating. I wouldn't do that on a 0.0.1 change...
Do you mean only the php.ini path or all of them?
- Stig
--
Stig Sther Bakken [EMAIL PROTECTED]
Fast Search Transfer ASA, Trondheim, Norway
--
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] unix install paths changed
Hi,
In an attempt to conform more to GNU-ish standards, I've changed some
default install paths.
default php.ini path: now using --sysconfdir option, defaults to
/usr/local/etc ("configure --sysconfdir=/usr/local/lib" for old behaviour)
PEAR install directory: now using --datadir option, defaults to
/usr/local/share/php/pear ("configure --datadir=/usr/local/lib/php"
for old behaviour)
Extension install directory: now using --libdir option, defaults to
/usr/local/lib/php. Also, the name of the "version directory" has
changed. A non-debug non-zts build will only use the date, zts
enabled appends "-zts", and debug enabled appends "-debug" (after
zts). Full path example: /usr/local/lib/php/20001222-debug/mysql.so
- Stig
--
Stig Sther Bakken [EMAIL PROTECTED]
Fast Search Transfer ASA, Trondheim, Norway
--
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] request
[Andrei Zmievski [EMAIL PROTECTED]] On Sat, 21 Apr 2001, Chuck Hagenbuch wrote: This could result in really confusing and unpredictable behavior if "the first encountered definition" changed under any circumstances. I'd vote for making any name conflicts an error. You could have two classes both defining an innocent method toString(), for example, and with your suggestion, inheriting from those classes would cause a hard error? Why would "first encountered" definition change? Okay, what about this one: If two inherited classes define the same method, the inheriting class has to redefine it. This way the inheriting class can be explicit in how to combine or override the inherited methods. We'd need a way of referring to any inherited class's methods though. - Stig -- Stig Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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]
