Re: [PHP-DEV] function registration patch
On Tuesday, March 18, 2003, at 03:07 PM, Sterling Hughes wrote: PS: or, *gasp* drop case-sensitivity. For which I'm an enormous +1. :) Aw, and steal enormous hours from consultants like me who make mad dollars from running grep -i misbehaving function? How cruel. :-) -Bop -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] argc/argv problem
I have problems accessing argc/argv in current cli. But before you say i chanaged that ini stuff - i have already revised my patch (and tested it when i've made the patch). So i guess it must have to do somthing with the new superglobals optimisation? marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function registration patch
If the memory manager is usable at this point (I think it is) then you should use do_alloca() and free_alloca() instead of malloc()/free(). Andi At 04:54 PM 3/18/2003 -0500, Andrei Zmievski wrote: Currently when registering functions, the unmodified function name is used as the key for the function table. This leads to problems when an extension class has a constructor that is not all lowercased. For example: function_entry php_gtk_button_functions[] = { PHP_FE(GtkButton, NULL), ... }; Then when using something like: ... parent::GtkButton(); ... It fails because it uses 'gtkbutton' as the key to search the function table. The attached patch fixes that by lowercasing the key (function name) when registering functions. I know that some may say, just use lowercase class name for the constructor in the function entry list, but that messes with nice class/function names again. -Andrei http://www.gravitonic.com/ * It said 'Winmodem' on the box, but I still feel like I lost. * -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: [PHP-DEV] RPC Extension
--- Brad LaFountain [EMAIL PROTECTED] wrote: Date: Sun, 16 Mar 2003 14:06:46 -0800 (PST) From: Brad LaFountain [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-DEV] RPC Extension I was just playing with the RPC extension. Don't you think that the rpc layer should pass along TSRMLS_CC to all of the callbacks? rpc_call(rpc_string, void *, zval *, int, zval *** TSRMLS_CC); - Brad __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Fwd: [PHP-DEV] __call for the namespaces
--- Brad LaFountain [EMAIL PROTECTED] wrote: Date: Mon, 17 Mar 2003 05:42:37 -0800 (PST) From: Brad LaFountain [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-DEV] __call for the namespaces This idea spawned from playing with ext/rpc and the ability to declare class types on the fly Since zend_namespaces is really _zend_class_entry I think it would be cool to implement __call at the namespace level. namespace java { function __call($classname) { // this will be called every time a new java::$classname() is called // and $classname isn't defined eval( class $classname { } ); // and it can return the new class return new $classname(); } } This doesn't seem like it would be too hard to implement and it will allow me to do stuff like... ? $j = new java::java.util.Stack(); // $j could be of ns java:util and class Stack $s = new soap::myObject(http://server/some.wsdl;); // $s could be the namespace defined in the wsdl and of class myObject ? ps: ? namespace test { class test1 { function doSomething() { eval( class test2 { } ); } } } $test1 = new test::test1(); $test1-doSomething(); ? results in... bFatal error/b: Internal Zend error - Missing class information for in b c:\php\php5\Release_TSDbg\name.php(7) : eval()'d code/b on line b2/bbr / - Brad __ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP-4.3.2 Apache2
Le lun 17/03/2003 à 20:14, Mike Robinson a écrit : FWIW, I'v been doing some light testing here, and writing some ab stuff to put some load on it, but at first blush apache 2.0.44 and 4.3.2RC1 seems terribly sluggish, particularly with the gd stuff. This could very well be my fault. 4.3.2RC1 with apache-1.3.27 rocks. Up to now I have been concentrating on testing every combination of PHP extensions, and every combination of Apache modules (I even bumped into apache's maximum module limit and had to increase it to 96). I also have three Apache versions on my system: - Apache 1.27 + mod_php as a module - Apache 2.0.44 + apache2filter as a module - Apache 1.3.27 + mod_perl (static), + mod_php as a module I finally got everything running together, and stable at last. The next step is adding apache2handler to that setup, and benchmarking the 4 Apache+PHP combinations. Jean-Michel -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SAPI/CGI segfaults on shutdown
php4ts_debug.dll!_efree() Line 225 + 0x3 C php4ts_debug.dll!shutdown_scanner() Line 139 + 0x2eC php4ts_debug.dll!zend_deactivate() Line 765 + 0x9 C php4ts_debug.dll!php_request_shutdown() Line 1129 + 0x9C php.exe!main() Line 1544 + 0x8 C php.exe!mainCRTStartup() Line 338 + 0x11 C kernel32.dll!77e8ca90() -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php