Re: [PHP-DEV] Moderate PHP-DEV
Sascha Schumann wrote: if even that description doesn't work, then nothing would work, not even changing the name. Well, it is obvious that some folks don't read that description and simply move forward, because php-dev sounds about right. They are PHP developers and so a list called php-dev makes absolute sense to them. - Sascha A couple thoughts Aside from renaming the php-dev list, we should remove the 'PHP and Zend Engine internals lists' from the regular mailing list page, put them in a 'developers' section (name isn't important) that describes cvs access, dev email lists, how to build (ie. win32 libraries), etc. That way it is completely removed from the regular stuff that normal php users will gravitate towards. It would help to clarify what is for the php community at large, and what is for the community of developers that work on php itself. Then another item that might be considered if it is not already done, allowing posts only from those that have cvs access. A second conditional list of allowed posters can be added that are people who do not have cvs access, but we want to allow to post. Otherwise, the list can be readable by all. A post rejected message could tell them to try a different email list, but if they really feel the email is for the dev list, send it to [EMAIL PROTECTED] and it will be reviewed by someone when they get the time. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phptinterface_doubled.phpt interface_implemented.phpt interface_instantiate.phptinterface_member.phpt interface_method.phpt interface_method_final.phptinterface_method_private.phpt interface_must_be_implemented.phpt
Andrei Zmievski wrote:
On Wed, 12 Mar 2003, Sebastian Bergmann wrote:
I have seen extended interfaces quite often in the Java world.
IIRC, the following code currently runs without problems and it should
stay that way, if it does not harm us in any way:
?php
interface Foo {}
interface Bar extends Foo {}
class FooBar implements Bar {}
?
I wasn't talking about interfaces extending interfaces - that is
perfectly fine. I was saying that class blah extends interface and
class blah implements interface is confusing.
-Andrei http://www.gravitonic.com/
A class extending an interface seems just weird to me. classes should
only extend classes, and implement interfaces. interfaces can extend
interfaces. I haven't been following the interfaces stuff (I'm going to
have to backtrack and read it all, very happy if this stuff will do what
I want), but I would hope we have some capability of implementing
multiple interfaces in a class somehow.
interface JAZ {}
interface FOO {}
interface BAR extends FOO {}
class foo implements FOO {}
class foobar extends foo implements (BAR,JAZ) {}
Shane
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phptinterface_doubled.phpt interface_implemented.phpt interface_instantiate.phptinterface_member.phpt interface_method.phpt interface_method_final.phptinterface_method_private.phpt interface_must_be_implemented.phpt
Marcus Börger wrote: At 20:20 12.03.2003, Andrei Zmievski wrote: On Wed, 12 Mar 2003, Marcus Börger wrote: This works even though i do not like extends FOO. Why? Both C# and Java (AFAIR) allow interfaces to extend other interfaces. Because of the second part of the answer. It is a little bit strange that an interface can extend and implement an interface but a class can only implement interfaces. Also it is a bit weired that i can implement multiple interface but extend only one. An interface should not implement an interface, only classes should implement interfaces. 'implement' infers that actual executable code is provided that implements an interface. Again, I haven't followed the interface stuff, and sorry for writting without reading the background, but I'm working off the assumption that interfaces are kind of like IDL. ok: interface extends interface class extends class implements interface not ok: interfaces implements interface class extends interface Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $GLOBALS broken?
It's a patch to ze2 that was done over the weekend, there is a new ini
setting that if you turn it on will fix the problem, just cannot
remember what it was right now...
Shane
Sebastian Bergmann wrote:
Notice: Undefined variable: GLOBALS in E:\test.php on line 7
1 ?php
2 function foo() {
3 $GLOBALS['foo'] = 'bar';
4 }
5
6 function bar() {
7 echo $GLOBALS['foo'];
8 }
9
10 foo();
11 bar();
12 ?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $GLOBALS broken?
Shane Caraveo wrote:
It's a patch to ze2
Actually, it may not have been to ze2 itself.
that was done over the weekend, there is a new ini
setting that if you turn it on will fix the problem, just cannot
remember what it was right now...
Shane
Sebastian Bergmann wrote:
Notice: Undefined variable: GLOBALS in E:\test.php on line 7
1 ?php
2 function foo() {
3 $GLOBALS['foo'] = 'bar';
4 }
5
6 function bar() {
7 echo $GLOBALS['foo'];
8 }
9
10 foo();
11 bar();
12 ?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tie'ing variables
So I'm not clear on how I am should expect this to work. A simple script: error_reporting(2047); print_r($_ENV); is now completely broken unless you turn on register_long_arrays. If that is expected behaviour, register_long_arrays must be on by default. Shane Zeev Suraski wrote: I wanted to do this for some time, but until recently, it wasn't very feasible, because the order of registration could be designated by the user (gpc_order, variables_order, etc.). Now that register_globals is off by default, and that we have the auto-globals, it's much more feasible. I implemented this optimization in CVS, so far only for $_ENV and $_SERVER. This alone pushed nearly-empty-page req/sec pages from about 285 to about 400 on my Windows box. I'll look into fixing the other ones later. Pre-requisites for this optimization to kick in: 1. register_globals being off 2. register_long_arrays (HTTP_*_VARS) being off If you want to benchmark w/ vs. w/o, you can disable the optimization by initializing cb to 0 in php_startup_auto_globals() and jit_initialization to 0 in php_hash_environment(), both in main/php_variables.c. Zeev At 18:26 01/03/2003, Sterling Hughes wrote: Hi, Analyzing PHP's routines a bit, it seems that the slowest part of a generic request is populating the special arrays, $_ENV, $_GET, etc. I was wondering if it might be possible to tie these arrays to a function (if you don't understand that, look at Perl for a definition). One could populate them as an overloaded object, and then array accesses would work - I guess. But I would prefer a cleaner mechanism. This would prevent a costly overhead for elements that don't really need to be there, and yield only a slight performance cost when accessing overloaded elements in these arrays. -Sterling -- The computer programmer is a creator of universes for which he alone is responsible. Universes of virtually unlimited complexity can be created in the form of computer programs. - Joseph Weizenbaum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] magic_quotes on the environment?
Even though magic_quotes_gpc is documented to addslashes to get/post/cookie, it also does it to the environment. This probably doesn't effect linux as much as windows, where all paths get escaped if magic_quotes_gpc is on. I find this rather anoying since I am trying to build environments for process execution (executing php again) and nothing was working due to magic_quotes_gpc (ie. I was not escaping env vars I was creating, then php would unescape the data prior to executing). I'm not convinced that escaping environment data is the correct thing to do in the first place, and I would like to change php to not escape env vars if magic_quotes_gpc is on. Any opinions on this? Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] magic_quotes on the environment?
Rasmus Lerdorf wrote: I'm not convinced that escaping environment data is the correct thing to do in the first place, and I would like to change php to not escape env vars if magic_quotes_gpc is on. Any opinions on this? This changed somewhere along the line then. Originally magic quotes only touched GPC data. I never noticed it also did it to the environment and I'd consider that to be a bug. -Rasmus Hmm, actually, *any* variable passed through php_register_variable() will get escaped if magic_quotes_gpc is on, irregardless of what array it is getting registered into, so this effects _ENV, _SERVER and _FILES in addition to _GET,_POST and _COOKIE. I also don't know if any other stuff happens to use php_register_variable that may not want escaping. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Piping to the PHP binary
4.3.1 works fine. Shane Dan Hardiker wrote: Hey all, echo ?php echo \hi\; ? | /path/to/php That works on php v4.2.x but Ive got 3 machines on v4.3.x and none of them seem to respond to the piping of the php config. v4.2.x Response [13:56:[EMAIL PROTECTED]:~$ echo ?php echo 'hi'; ? | /usr/local/bin/php X-Powered-By: PHP/4.2.3 Content-type: text/html hi[13:56:[EMAIL PROTECTED]:~$ v4.3.x Response [13:58:[EMAIL PROTECTED]:~$ echo ?php echo 'hi'; ? | /usr/local/bin/php Status: 404 Content-type: text/html X-Powered-By: PHP/4.3.2-dev No input file specified. [13:59:[EMAIL PROTECTED]:~$ Anyone else with the same results on a v4.3.x cgi-binary? Is this modified behavoir limited to me, or expected? I tried asking php-general@ but no response. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation
Rasmus Lerdorf wrote: So, I am just starting out down the path to figure out why PHP 4.3 has gotten so much slower than 4.2. strace -c provides the first clue. A straight ./configure --enable-inline-optimization make command-line build for 4.2, 4.3 and 5.0 run on a simple hello world script reveals that we have gone from 219 system calls in 4.2 to 233 in 4.3 to 236 in 5.0. This is a bad trend and we really need to make an effort to reverse this. 4.2 Hello World from command-line: CGI, right? Part of this may be from the path_info handling I've added. There is a stat call in there to determine if the path provided by the webserver includes path_info also, if it does have path_info (stat failed), it walks up the path doing a stat to determine the script filename and path_info correctly. the ini setting cgi.fix_pathinfo turns this on or off. It also uses a handfull putenv and getenv calls in straightening things out. I'm sure this adds some of that, but I don't think it would add as much an increase as you are seeing, unless you're using some long path_info paths. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation
Rasmus Lerdorf wrote: On Sun, 23 Feb 2003, Shane Caraveo wrote: CGI, right? Part of this may be from the path_info handling I've added. The extra realpath() and fstat() calls are not cgi specific, so if what you added only affects cgi, then that isn't the big problem. -Rasmus ok, it's only in CGI. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [WARNING] Release process for 4.3.2 starts RSN..
I wanted to run through all the cgi stuff in detail again for 432, but likely wont have the time by the 26th to do that. Shane Jani Taskinen wrote: To get this thing started, I'm going to roll PHP 4.3.2-pre1 on Wednesday, 26th Feb, around 3pm EEST. And I'll announce it on php-general too, to get some more people testing it before we start with any RCs. Following is collection of bugs marked as critical and verified which should be looked into and dealt with. If not fixed, then please, PLEASE add some comment why they won't ever be fixed and bogus the out. Critical: http://bugs.php.net/bug.php?id=20190edit=1 . Random mem corruption: zend_get_executed_filename() mismatch http://bugs.php.net/bug.php?id=21820edit=1 . bc break in parser: $arr[val] vs $arr['val'] http://bugs.php.net/bug.php?id=22372edit=1 . Don't forget to bump the PHP API number for 4.3.2 release Verified bugs (Scripting Engine related): http://bugs.php.net/bug.php?id=15209edit=1 . register_shutdown_function() broke between 4.0.x to 4.1.x - Zeev: Either close as bogus saying it's intended behaviour or finally get around and FIX IT. ([EMAIL PROTECTED] has a patch?) http://bugs.php.net/bug.php?id=21513edit=1 . shutdown functions not executed if timed out [win32 only] http://bugs.php.net/bug.php?id=15438edit=1 . include_once fails when comparing output to a value http://bugs.php.net/bug.php?id=17997edit=1 . got wanning when combing switch reference http://bugs.php.net/bug.php?id=20548edit=1 . Decrement ($x[$y]--) doesn't work on uninitiated variable http://bugs.php.net/bug.php?id=21478edit=1 . Zend/zend_alloc.c :: shutdown_memory_manager produces segfault http://bugs.php.net/bug.php?id=22367edit=1 . undefined variable has a value . RFC: Just bogus with Don't do this. ? http://bugs.php.net/bug.php?id=21918edit=1 . strange behaviour of mixed type in array-keys . See #21788 http://bugs.php.net/bug.php?id=21788edit=1 . array_multisort() changes array keys unexpectedly given numeric strings as keys . See #21918 Last two are related to each other, afaics, and need some discussion what we should do about it or if nothing. Also related to these is http://bugs.php.net/bug.php?id=8325. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] proc_open() patch
The attached patch adds 2 optional parameters to proc_open(). The
first, cwd, and the second is an array for executing with a custom
environment. I've tested this on w2k and osx. Comments, fixes,
changes, and testing on Linux, would be appreciated.
Shane
Index: ext/standard/proc_open.c
===
RCS file: /repository/php4/ext/standard/proc_open.c,v
retrieving revision 1.3
diff -u -d -u -r1.3 proc_open.c
--- ext/standard/proc_open.c24 Jan 2003 16:45:34 - 1.3
+++ ext/standard/proc_open.c10 Feb 2003 07:31:43 -
@@ -56,6 +56,111 @@
static int le_proc_open;
+/* {{{ _php_array_to_envp */
+static char *_php_array_to_envp(zval *environment, int is_persistent TSRMLS_DC)
+{
+ zval **element;
+ char *envp, *p;
+#ifndef PHP_WIN32
+ char **myenvp, **ep;
+#endif
+ char *string_key, *data;
+ uint string_length, cnt, l, sizeenv=0, el_len;
+ ulong num_key;
+ HashTable *target_hash;
+ HashPosition pos;
+
+ if (!environment) return NULL;
+ cnt = zend_hash_num_elements(Z_ARRVAL_P(environment));
+ if (cnt 1) return NULL;
+
+ target_hash = HASH_OF(environment);
+ if (!target_hash) return NULL;
+
+ /* first, we have to get the size of all the elements in the hash */
+ for (zend_hash_internal_pointer_reset_ex(target_hash, pos);
+zend_hash_get_current_data_ex(target_hash, (void **) element, pos)
+== SUCCESS;
+zend_hash_move_forward_ex(target_hash, pos)) {
+
+ convert_to_string_ex(element);
+ el_len = Z_STRLEN_PP(element);
+ if (el_len == 0) continue;
+ sizeenv += el_len+1;
+ switch (zend_hash_get_current_key_ex(target_hash, string_key,
+string_length, num_key, 0, pos)) {
+ case HASH_KEY_IS_STRING:
+ if (string_length == 0) continue;
+ sizeenv += string_length+1;
+ }
+ }
+
+#ifndef PHP_WIN32
+ ep = myenvp = (char **) calloc(cnt+1,sizeof(char *));
+#endif
+ p = envp = (char *) calloc(sizeenv+4,1);
+
+ for (zend_hash_internal_pointer_reset_ex(target_hash, pos);
+zend_hash_get_current_data_ex(target_hash, (void **) element, pos)
+== SUCCESS;
+zend_hash_move_forward_ex(target_hash, pos)) {
+
+ convert_to_string_ex(element);
+ el_len = Z_STRLEN_PP(element);
+ if (el_len == 0) continue;
+ data = Z_STRVAL_PP(element);
+ switch (zend_hash_get_current_key_ex(target_hash, string_key,
+string_length, num_key, 0, pos)) {
+ case HASH_KEY_IS_STRING:
+ if (string_length == 0) continue;
+ l = string_length + el_len + 1;
+ memcpy(p, string_key, string_length);
+ strcat(p, =);
+ strcat(p, data);
+ if (PG(magic_quotes_gpc)) {
+ php_stripslashes(p,l TSRMLS_CC);
+ }
+#ifndef PHP_WIN32
+ *ep = p;
+ ++ep;
+#endif
+ p += l;
+ break;
+ case HASH_KEY_IS_LONG:
+ memcpy(p,data,el_len);
+ if (PG(magic_quotes_gpc)) {
+ php_stripslashes(p,el_len TSRMLS_CC);
+ }
+#ifndef PHP_WIN32
+ *ep = p;
+ ++ep;
+#endif
+ p += el_len + 1;
+ break;
+ case HASH_KEY_NON_EXISTANT:
+ break;
+ }
+ }
+
+ assert(p-envp = sizeenv);
+ zend_hash_internal_pointer_reset_ex(target_hash, pos);
+#ifdef PHP_WIN32
+ return envp;
+#else
+ return (char *)myenvp;
+#endif
+}
+/* }}} */
+
+/* {{{ _php_free_envp */
+static void _php_free_envp(char *envp)
+{
+ if (envp) {
+#ifndef PHP_WIN32
+ free(*envp);
+#endif
+ free(envp);
+ }
+}
+/* }}} */
+
+
static void proc_open_rsrc_dtor(zend_rsrc_list_entry *rsrc TSRMLS_DC)
{
struct php_process_handle *proc = (struct php_process_handle*)rsrc-ptr;
@@ -98,7 +203,7 @@
#else
FG(pclose_ret) = -1;
#endif
-
+ _php_free_envp(proc-envp);
pefree(proc-command, proc-is_persistent);
pefree(proc, proc-is_persistent);
@@ -166,8 +271,6 @@
}
/* }}} */
-
-
PHP_MINIT_FUNCTION(proc_open)
{
le_proc_open = zend_register_list_destructors_ex(proc_open_rsrc_dtor, NULL,
process, module_number
Re: [PHP-DEV] [PATCH] sapi/nsapi/nsapi.c
Excelent, The CGI vars are correct. One less sapi module to deal with :) Shane Uwe Schindler wrote: The variables you explain are surely there. But a lot of scripts depend on other headers, which the client sent. The SAPI module only creates Variables for a subset of them (HTTP_USER_AGENT). But not for all like the other SAPI modules. So with this patch you get for example the missing HTTP_HOST-Header (HTTP/1.1) because the patch creates for every variable in the request a HTTP_XXX-Variable. So you can see all headers the client have sent. This is the way the other SAPI modules (APACHE) and the normal CGI environment works. Without it about 50% of the currently available PHP scripts do not run correctly. You can try it with: http://www.emarcon.net/test.php which runs the patched Version. Yo will see all headers sent by your client not only the ones explained below and HTTP_USER_AGENT and HTTP_ACCEPT_* Greetings from Germany, Uwe At 15:52 02.02.2003 -0800, you wrote: Hi Uwe, I haven't looked at the patch, but I am wondering if the nsapi sapi module creates variables for php that conform to the cgi spec. Can you try the following url against a phpinfo(); script: http://localhost/info.php/test/path?query=string You should get: PATH_INFO=/test/path PATH_TRANSLATED=/your_web_document_root/test/path QUERY_STRING=query=string SCRIPT_NAME=/info.php PHP_SELF=/info.php If you do not, then the sapi module is not conformant to cgi spec, and still needs some work. Shane Uwe Schindler wrote: I submit a patch for the NSAPI SAPI module and hope that it fixes a lot of problems I have (and others as seen in the bug database). As a lot of variables which are needed by a lot of PHP scripts which use $_SERVER[...] are not transferred correctly to the PHP script that runs in iPlanet Webserver (4 or 6). An example are the Host and X-Forwarded headers. This is so, because the transferred variables are static in the SAPI module. The new nsapi.c file now transfers _ALL_ variables from rc-rq-headers to php_register_variable(HTTP_+headername_uppercase, ...). Also missing variables like SERVER_SOFTWARE are added. A lot of customers complain about memory leaks in this module. I hope they are also fixed by freeing the by nsapi allocated strings (the return value of session_dns and http_uri2url). The patch should work with Netscape/iPlanet Servers from version 3 on (I used no newer API calls). If you are interested I could eventually create a patch for supporting the virtual servers in SunONE/iPlanet Web Server 6, because some vars only get the default-hostname not the real virtual server name (for example $_SERVER[SERVER_URL] which is often used in scripts to refer together with $_SERVER[PHP_SELF]). But this mut be done with #ifdefs because some new functions are in the nsapi since version 6. A good fix would be also to map $_SERVER[SERVER_URL] to http://$SERVER[HTTP_HOST];, because in iPlanet-Servers the Host variable is everytime available (if not in original HTTP-headers it is defined to be the default hostname). Greetings, Uwe - Uwe Schindler Addr 1: Bamberger Str. 24a, D-96049 Bamberg Addr 2: Drausnickstr. 153, D-91052 Erlangen http://www.thetaphi.de - http:///www.schindlers-software.de eMails: [EMAIL PROTECTED] (private); [EMAIL PROTECTED] (company) Tel./Fax: +49 700 PCLATEIN (+49 700 72528346) Schindlers Software - Home of Schindlers PC-LATEIN 3.10 DIE Software zum Lateinlernen! - Uwe Schindler Addr 1: Bamberger Str. 24a, D-96049 Bamberg Addr 2: Drausnickstr. 153, D-91052 Erlangen http://www.thetaphi.de - http:///www.schindlers-software.de eMails: [EMAIL PROTECTED] (private); [EMAIL PROTECTED] (company) Tel./Fax: +49 700 PCLATEIN (+49 700 72528346) Schindlers Software - Home of Schindlers PC-LATEIN 3.10 DIE Software zum Lateinlernen! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()
Derick Rethans wrote: On Wed, 29 Jan 2003, Sara Golemon wrote: I've got an implementation put together, the patch for which can be viewed at: http://169.229.139.97/test/str_ireplace.diff.txt After some comments on IRC, here's an alternate version to the above patch. This second approach avoids creating php_memnstri by simply searching through a copy of haystack which is strtolowered against a strtolowered version of needle (no need to copy that part). http://169.229.139.97/test/str_ireplace.diff-2.txt Should be quicker and cleaner at the cost of a small malloc in the estrndup call. I still don;t see no real use for this function, you can easily do this with eregi_replace() or preg_replace(). Derick I may be wrong since I haven't profiled this, but my understanding is that str_replace is much faster than doing either of the regex replacements. For that reason alone, there is a use for it. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature Request #5919 case-insensitive version of str_replace()
Ilia A. wrote: I may be wrong since I haven't profiled this, but my understanding is that str_replace is much faster than doing either of the regex replacements. For that reason alone, there is a use for it. Normally it would be quite faster, however once case sensitivity is added to the mix I believe the speed difference would be minimal. I've done some benchmarks and the speed difference between str_replace() and preg_replace() is only about 1/2 second in across 10 executions (5 replaces per instance). Another .6 of a second is added when preg_replace() is used with 'i' flag which makes it case insensitive. I have not benchmarked the stri_replace code but I imagine it would be in the same ballpark, meaning that we are adding a fairly large chunk of code for performance benefit of a 1 microsecond (1 millionth of a second) per instance. Ilia What's the benchmark code? How is the benchmark difference on large text (ie. 100K of text) vs. small text (1K or smaller)? Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21659 [Com]: sprintf
Ilia A. wrote: On January 15, 2003 10:27 am, Adam Wright wrote: Last ditch effort of NotAPHPBug? ;) This too may not be a correct solution all the time. Consider 75th duplicate report of an invalid or even a resolved bug report. It may have been a bug at some point, but certainly is not anymore. It is bogus, because the user chose not to search in the bug database for similar reports before posting their report. Surely you can agree that such a report is bogus. Your definition of bogus is very broad. Personally I think bogus was a bad idea in the first place. Anyway, in the situation above, it's a duplicate, not a bogus. Marking it a duplicate informes the user (for the 75th time) that the bug was already reported, and even if that bug is fixed, it then points the user to the fix as well. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP in 2003 (leading to PHP 5)
Roadmap: 1. Switch to ZE2 by default 2. Establish PECL CA authority and binary package/release process (particularly important for win32) 3. Bundle PHP-Soap (and stop the bleeding of PHP users) 3a. Collect underpants 4. ? 5. Profit #3 doesn't belong in a general roadmap. What does fit in, that also covers #3, is having all extensions moved out to pecl, and a build/release system that can build distribution packages based on the last stable release of extensions in pecl. With that (for example only), different distribution packages can be built when php releases occure, such as 'php core' which would contain the 'most important' stable extensions, 'php stable' which would contain all stable extensions, and 'php bleeding' which could be a package with the latest development snapshot at time of release. With this also extensions now can take on a life of their own, releasing at different times than php, and visaverse. I think this would make releasing new versions of php much more manageable. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug # 21261 -- PHP_SELF not set correctly with sapi/CGI
Sara Golemon wrote: It looks like the correct behavior was broken with patch 1.199 to php/sapi/cgi/cgi_main.c Because there are a number of modifications in this patch and I don't want to go messing it up any further I'll ask the original patch submitter (shane) to take a look and reconsider the argv0 hack that was removed with this patch. ((Assuming that is indeed the source of the problem)) -Pollita the argv0 hack is bad since it doesn't fix the bug, just masks it on servers that provide that. There is an off-by-one bug somewhere in init_request_info(), if I can get the httpd.conf info I requested in the bug, I can figure out what is happening and fix it correctly. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] CLI and CGI defaults
But --enable-cli is now a useless switch, because: * if you don't specify it, cli is built * if you specify it, cli is built * if you don't specify it, cli is not installed * if you specify it, cli is not installed Only --disable-cgi (--enable-cli still makes no difference) will install cli on make install. That is the correct behaviour. --enable-cli is a default, thus you do not have to define it to build cli. 'make install-cli' is used to install cli rather than cgi. I don't see the confusion in that. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Robin Thellend wrote: On Wed, 18 Dec 2002, Derick Rethans wrote: [...] I didn't say that it should be changed from php to php-cgi, as I do think that would be bad. Derick Why don't you just add a simple check in the CLI code to exec() the CGI binary if it is called as a CGI? if(getenv(GATEWAY_INTERFACE) != NULL) execv(/path/to/php-cgi, argv); Lets not compound one bad idea with another. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Plain and simple, and it is the ONLY way that 4.3 can be released. There is no way in hell I would support the release of PHP with the cli binary replacing the cgi binary. Change it back to the way it was in 4.2.x since there is no time to properly fix the problem. Leave it marked experimental with a big note that the binary name may change in a later release. Andrei Zmievski wrote: What was the consensus on CGI vs. CLI naming or merging issue? Or was there a consensus at all? I full plan to go ahead with 4.3.0 release before the end of the year, so those interested in doing anything about this issue better get their butts in gear. -Andrei http://www.gravitonic.com/ This isn't right. This isn't even wrong. -- Wolfgang Pauli -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
I would agree that this is a big problem. Shane Andrei Zmievski wrote: On Wed, 18 Dec 2002, Sascha Schumann wrote: The next point release after 4.2.0 was 4.2.1. There are too many major changes in 4.3 vs. 4.2 to call it a 'point release'. Semantics. Especially, there are still significant backwards compatibility bugs, such as http://bugs.php.net/bug.php?id=20441 Does everyone agree that it's a BC bug? If so, who is going to fix it? -Andrei http://www.gravitonic.com/ * if you hold a unix shell to your ear, do you hear the c? * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Andrei Zmievski wrote: On Wed, 18 Dec 2002, Andi Gutmans wrote: I doubt this will happen fast enough. We should just release the way we released 4.2.x, which as far as I know was php for CGI and php-cli for CLI or am I a bit behind things? :) Derick and I hashed it out on IRC and we have a proposal: We should keep 4.2.x behavior with some modifications. CLI and CGI should always be built unless disabled, and the executables should go into sapi/cli/php and sapi/cgi/php, respectively. In addition, 'install' target should be modified to detect whether the user is trying to install either one of these SAPIs, output a warning message regarding the potential naming problem, and stop. Let the user install CLI and CGI manually, basically. I really hope we can come to an agreement on this. I can agree to, and live with, this to some extent. The changes I would want on this would be... * On win32, cli remains php-cli.exe. Windows users can rename the executable if they feel it's necessary. * On other platforms, the cgi *is* installed by 'make install' by default. To install cli something like, 'make install-cli', or 'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the second option would be more usefull for installing both, using both without [DIR] on one results in a configure error). A note regarding what was installed and where should be added to the output resulting from an install. * Binaries are combined into a single binary in a later release. I'd be happy to do this in January. * Documentation is added in regards to this issue. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
No. At the most, if anything, CLI should output an error message:
if(getenv(GATEWAY_INTERFACE) != NULL) {
printf(This is the PHP CLI binary, please configure your server to
use the correct PHP CGI binary.);
exit(1);
}
Xavier Spriet wrote:
Great.
In that case, in order to make things a little smoother for users, could
a little workaround like the one offered by Robin be considered ?
On Wed, 2002-12-18 at 17:21, Andrei Zmievski wrote:
On Wed, 18 Dec 2002, Philip Olson wrote:
So every tutorial and documentation on this would have to
say this right?
Ask your sysadmin what the CGI and CLI versions of your
PHP are called, they could be anything as there is no
standard. For the purpose of this (tutorial|documentation),
we'll call CLI php-cli and CGI php-cgi.
Same goes for all cgi scripts, they'll work some places but
not others... And various RPM's would have different naming
schemes depending on the maintainers preference.
The merging of CLI and CGI will still happen, but in 4.3.1.
-Andrei http://www.gravitonic.com/
* Marriage is not a word. It's a sentence. Life-long sentence. *
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
Edin Kadribasic wrote:
* On other platforms, the cgi *is* installed by 'make install' by
default. To install cli something like, 'make install-cli', or
'configure --install-cli=[DIR] --install-cgi=[DIR]' can be used (the
second option would be more usefull for installing both, using both
without [DIR] on one results in a configure error). A note regarding
what was installed and where should be added to the output resulting
from an install.
I really don't understand why insist on cgi being installed on make
install to ${PREFIX}/bin? The solution outlined by Andrei and Derick is
much better IMHO because it will alert users of the issue and because
installing a cgi into a webserver requires manual action anyway.
It's realy very logical. It leaves the default installation the way
most people will expect it to behave, which is as it has been for years
now. Having the options allow people to modify that behaviour to the
way they want it to work. It's very flexable for all interests.
* Binaries are combined into a single binary in a later release. I'd be
happy to do this in January.
-1 for reasons i stated in my reply to Andrei.
None of the reasons I have seen listed against this are insurmountable.
The *only* reason I have seen (ie. remember at this moment) that
comes close to convincing me otherwise is the one that you stated:
In practice this would mean that one would be unable to run php
command line scripts from within webserver environment, through system()
call from other cgi/php scripts etc.
The problem is that cli was started as a seperate binary and no thought
was put into having things work as a single binary. I'm not convinced
that there isn't a way around the system() issue yet...but you may have
a point. It could be done by using a flag in that instance (php -f
script.php for instance) but that is not optimal.
Shane
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. But either way, the fact that it was changed months ago is meaningless. It never made it to a release, and it shouldn't make it to a release, and that's the important thing in my opinion. Zeev I on the other hand do recall complaining about this issue, into the typical php-dev vacume. My strong suggestion at the time was to move things back to one binary, which i still beleive is the best solution, exactly for the ease of use issues that Zeev brings up. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Simply because calling the command line interface should be easy - as easy as calling awk or perl or whatever. Every server api module like cgi must be installed, so the name does not matter there. But having long names for command line utils is a bad idea. marcus Well, fortunately I never have time for qa, handling bugs, etc. etc. so I wont have to deal with the backlash that this name change **WILL** cause. I feel sorry for those who have the time to deal with it, as that will be about all they will deal with, rather than handling more important bugs and issues. Basicly, the namechange goes against several years of history in php, tons of documentation, general community knowledge, etc., and top it off with the fact that in reality, probably less than 1 percent of users use php as a command line language. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Jani Taskinen wrote: On Mon, 9 Dec 2002, Shane Caraveo wrote: Simply because calling the command line interface should be easy - as easy as calling awk or perl or whatever. Every server api module like cgi must be installed, so the name does not matter there. But having long names for command line utils is a bad idea. marcus Well, fortunately I never have time for qa, handling bugs, etc. etc. so I wont have to deal with the backlash that this name change **WILL** cause. I feel sorry for those who have the time to deal with it, as that will be about all they will deal with, rather than handling more important bugs and issues. Basicly, the namechange goes against several Don't worry, we'll make some quick-resolve for it too. We didn't get overwhelmed by that register_globals issue either. (like some people thought we would :) years of history in php, tons of documentation, general community knowledge, etc., and top it off with the fact that in reality, probably less than 1 percent of users use php as a command line language. It's evolution. :) And we do hope that the amount of people using PHP on command line increases. Besides, having the php-cgi binary makes it very clear what it is about. But naming the CLI binary php-cli definately does not. I'm actually a bit uncertain why we actually have separate binaries. (or I've forgot why they were separated..anyone?) --Jani evolution doesn't cut it. It would have been simple enough to combine cli into the cgi binary and be done with it, and I suggested as much that it should be done a very long time ago. I don't recall any major reasons why it wasn't done, other than that cli has been experimental. evolution would have been to fix the executable we have had, rather than creating multiple executables that do essentialy the same thing, and this issue would have been avoided altogether. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sapi/fastcgi
works fine for me without exiting, under mod_fastcgi on win32 and osx and my iis/fastcgi. There was a problem with exiting after each request on windows, but I fixed that a couple weeks ago. Shane Harald Radi wrote: i wasn't able to run it succesfully on windows. i can compile it and the binary actually works, but it exits after each request instead of keep running. but this is on my todo list for the christmas holidays, so stay tuned :) harald -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 5:29 PM To: Harald Radi Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: sapi/fastcgi HR as neither of them works you can remove both :) What do you mean neither works? I have Zeus/PHP/FastCGI install with PHP 4.2.3 running here, seems working. Am I missing something? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sapi/fastcgi
sapi/fastcgi should be deprecated. Sebastian Bergmann wrote: What happens to sapi/fastcgi, now that we have FastCGI support in sapi/cgi? IMHO, it should be removed for PHP 4.3.0 already. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /sapi/cgi cgi_main.c
Zeev Suraski wrote: How does this patch possibly fix something in this magnitude? It doesn't appear to do anything crucial at all, or do these variables have some far-reaching indirect effect? Zeev Well, the one patch refered to in this thread was only a minor fix over the previous patches I applied yesterday. I did send out emails regarding and describing this problem (http://marc.theaimsgroup.com/?l=php-devm=103834043816376w=2) with no response so aparently no one cares until after I fix the problem ;) The basics in case you don't want to read my long email... When was this broken? A very long time ago, possibly/probably the entire 4 series. Are there bug reports? Yes, some inapropriately marked bogus. Does the patch present potential problems? Sure, it's a significant patch that changes the way the cgi module works, but at least, minus any bugs, it works, which is much better than not having the patch at all. I have tested this on win32 and osx, as cgi and fastcgi, under apache 1.3/2.0 and IIS, which is probably the most testing CGI has gotten in a very long time. Should it go in 4.3? I strongly think so. It would be sad and ironic to have yet another release with cgi that doesn't work at all (given that PHP is *the* Web language). I think it's worth an extra release cycle and extra QA to have this in. Could the patch be better written? Sure, I don't claim to be a supreme C developer. There are memory allocations in there I'd like to get rid of at a later time, and I think the 'backwards broken compatibility' should be removed. Now the long part. So, why did this have to happen? First, PATH_INFO was being used for PHP_SELF, which prior to the fix, apache set to the php binary. The cgi module used SCRIPT_FILENAME if DISCARD_PATH was set, and again, this would be set to the php binary by apache, so php would parse itself and not the script desired. Third, none of the CGI variables (as defined in CGI spec) were ever correct. This broke using PATH_INFO in applications (one example being the pres2 system). These variables are the primary targets of the patch since they are required for proper execution of php as CGI. However, since other variables were also wrong (SCRIPT_NAME and PATH_TRANSLATED) rather than just fixing what PHP absolutely needed to operate right, I fixed them all. Then, additionaly, using the mod_cgi cgi_script directive (using bang lines in php) was broken, thus the small patch to fopen_wrappers.c. This stuff has been broken for a very long time, since before 4.2 if I remember right. In the last month, I've seen at least two non-php people attempt to set up php cgi and give up due to these bugs. I didn't realy clue in to how broken it was until I saw that, then tried it myself on my shiny new mac. The self-parsing of the php binary did not occure on IIS because IIS sends the script name as an argument when executing php, and that would override the environment variables, but PATH_INFO was still broken. There are bugs in the bug database that this fixes also, one example: http://bugs.php.net/bug.php?id=19378 There are also bugs marked as bogus that probably were not, one example: http://bugs.php.net/bug.php?id=10075. (CGI and PATH_INFO aparently is not understood in this instance) Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4.3 broken CGI behaviour
Hello, I just commited patches to fix CGI running under Apache. This also fixes issues with incorrect CGI environment variables that are received under ScriptAlias based CGI or mod_fastcgi. My previous email describing this is at http://marc.theaimsgroup.com/?l=php-devm=103834043816376w=2 Essentialy, I think that these patches should be put into 4.3, due to the extreme broken behaviour that 4.3 currently has in CGI mode. However, since i'm not involved in release management, I'll leave the decision to do that to those who are. Regards, Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error during buildconf..
Is this just starting? How long since your last configured? I just added two new m4 files, but they shouldn't get used unless you --enable-fastcgi, did you do that? Shane Magnus Määttä wrote: On Mon, 2 Dec 2002 04:39:34 +0200 (EET) Jani Taskinen [EMAIL PROTECTED] wrote: I get this with PHP_4_3_0 branch (with Linux): /usr/bin/autoheader: Symbol `size_t' is not covered by /usr/share/autoconf/acconfig.h ./acconfig.h I get the same result and this too (in both HEAD and 4.3 branch): /usr/bin/autoheader-2.13: Symbol `uint' is not covered by /usr/share/autoconf/acconfig.h /usr/bin/autoheader-2.13: Symbol `ulong' is not covered by /usr/share/autoconf/acconfig.h The same problem is on Tru64. And main/php_config.h.in is not created. (this does not happen with HEAD) And not in HEAD either for me. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error during buildconf..
Jani Taskinen wrote: On Mon, 2 Dec 2002, Jani Taskinen wrote: I get this with PHP_4_3_0 branch (with Linux): /usr/bin/autoheader: Symbol `ssize_t' is not covered by /usr/share/autoconf/acconfig.h ./acconfig.h And main/php_config.h.in is not created. (this does not happen with HEAD) Forgot to test after noticing this..the build does not work at all now. (of course, as php_config.h.in is missing, php_config.h ends up being an empty file..) Well, I can't recreate the problem in either 43 or HEAD. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /sapi/cgi cgi_main.c
It's not a matter of php cgi just having a couple bugs, it was
completely broken. If we don't put it in 4.3, pull the cgi module out
entirely because it's useless. Yet another point of view also, since no
one has seriously complained about it's brokeness, it can't realy effect
many people either if it is in 4.3.
Shane
Andi Gutmans wrote:
Are you sure we should have this stuff in the branch of 4.3? Are these
bugs which didn't exist in 4.2.3?
If they did exist I'm -1. If they didn't exist then that's life and the
patch should stay in but people familiar with CGI should review it
carefully.
Andi
At 02:21 AM 12/2/2002 +, Shane Caraveo wrote:
shane Sun Dec 1 21:21:01 2002 EDT
Modified files: (Branch: PHP_4_3)
/php4/sapi/cgi cgi_main.c
Log:
MFH
Index: php4/sapi/cgi/cgi_main.c
diff -u php4/sapi/cgi/cgi_main.c:1.190.2.6
php4/sapi/cgi/cgi_main.c:1.190.2.7
--- php4/sapi/cgi/cgi_main.c:1.190.2.6 Sun Dec 1 18:27:14 2002
+++ php4/sapi/cgi/cgi_main.cSun Dec 1 21:21:01 2002
@@ -369,6 +369,7 @@
} else {
snprintf(buf,len-1,%s=, name);
}
+
#if PHP_FASTCGI
/* when php is started by mod_fastcgi, no regular environment
is provided to PHP. It is always sent to PHP at the start
@@ -597,8 +598,10 @@
struct stat st;
char *env_script_name =
sapi_cgibin_getenv(SCRIPT_NAME,0 TSRMLS_CC);
char *env_path_info =
sapi_cgibin_getenv(PATH_INFO,0 TSRMLS_CC);
+ char *env_redirect_url =
sapi_cgibin_getenv(REDIRECT_URL,0 TSRMLS_CC);
if (env_path_info) env_path_info =
estrdup(env_path_info);
- if (sapi_cgibin_getenv(REDIRECT_URL,0
TSRMLS_CC) ||
+
+ if (env_redirect_url ||
(env_script_name env_path_info
strcmp(env_path_info,env_script_name)==0)) {
/*
@@ -611,6 +614,8 @@
*/
_sapi_cgibin_putenv(SCRIPT_FILENAME,env_path_translated TSRMLS_CC);
_sapi_cgibin_putenv(PATH_INFO,NULL
TSRMLS_CC);
+ if (env_redirect_url)
+ _sapi_cgibin_putenv(SCRIPT_NAME,env_redirect_url TSRMLS_CC);
}
if (stat( env_path_translated, st ) == -1 ) {
@@ -620,7 +625,7 @@
while( (ptr = strrchr(pt,'/')) || (ptr
= strrchr(pt,'\\')) ) {
*ptr = 0;
- if ( lstat(pt, st) == 0
S_ISREG(st.st_mode) ) {
+ if ( stat(pt, st) == 0
S_ISREG(st.st_mode) ) {
/*
* okay, we found the
base script!
* work out how many
chars we had to strip off;
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++
Is there any reason the ifdef __cplusplus doesn't work? There shouldn't be any need for extra processing or config options. J Smith wrote: How about adding something like this to skeleton.c: /* __begin_extern_c__ */ /* __end_extern_c__ */ And having the sed script in ext_skel replace them with the proper extern C stuff? That way there's no need for skeleton.cpp and just a few changes need to be made in skeleton.c. J Sascha Schumann wrote: On Fri, 29 Nov 2002, J Smith wrote: Attached is a patch to ext_skel that adds an optional argument (--cpp) that will create a PHP extension in C++ rather than C. Also attached is skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few modifications for using C++. I could've just made some changes to skeleton.c and done some sed work in the ext_skel script, but I think it's clearer to have them separated into two files. I'm reluctant to duplicate the contents of the .c file for maintenance reason. Cannot you just put the C++ specific code into a /* Remove this part, if this is not a C++ extension */ #ifdef __cplusplus #endif section? - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Changes to ext_skel for C++
J Smith wrote:
Attached is a patch to ext_skel that adds an optional argument (--cpp) that
will create a PHP extension in C++ rather than C. Also attached is
skeleton.cpp, which basically mirrors ext/skeleton/skeleton.c with a few
modifications for using C++. I could've just made some changes to
skeleton.c and done some sed work in the ext_skel script, but I think it's
clearer to have them separated into two files.
The ext_skel patch is based on the current HEAD.
Comments?
J
skeleton.h also needs to be dealt with. If you do not, visual studio
will export symbols as c++ symbols and the extension will not work.
Simple solution is to have
#ifdef __cplusplus
extern C {
#endif
at the top of skeleton.h, and close it at the bottom.
Shane
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] C++ extensions and ext_skel
I think that would be quite cool, save me from having to do it manualy. Shane J Smith wrote: A couple of times a month, I get questions about from people looking to use C++ with PHP. Apparently, a lot of people end up reading some post I made to php.dev or something a year or so ago about C++, and although it worked at the time, the procedure I describe has become stale. I messed around a bit with ext_skel and ext/skeleton today and added an option to ext_skel (--cpp) that creates a basic C++ extension rather than the standard C extension. The C++ extension is pretty much the same as the standard C extension, with the exception of some extern C linkage, modifications to config.m4 and Makefile.in and a small C++ class thrown in for fun. Would this be worth adding to PHP proper? I have patches available for 4.2.3, but if it's worthy, I can whip it up for 4.3 or whatever. It'll save me some email bandwidth if it could be used. J -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] apache/cgi problems with path_info and discard-path
I ran into a problem with path_info using apache2/mod_fastcgi, so I configured apache to use php as regular cgi, and have the same exact problems. There are basicly two problems, first, --discard-path causes PHP to parse itself rather than the script, so I think discard-path is basicly a bad idea. You cannot use --discard-path with apache and cgi. The second is that (after compiling without --discard-path) path_info does not work: works: http://localhost/info.php fails with 500 error: http://localhost/info.php/test My apache config is: ScriptAlias /php/ /path/to/php/bin/ AddType application/x-httpd-php .php Action application/x-httpd-php /php/php-cgi What happens is that php tries to parse the file /info.php/test rather than /info.php. Basicly, mod_cgi and mod_fastcgi do not provide the correct information for several environment variables to php when configured this way. path_info, path_translated, script_name and script_filename are all wrong. According to CGI specs (linked to from apache docs), with the url http://localhost/info.php/test?a=b I *should* get: PATH_INFO=/test PATH_TRANSLATED=/docroot/test SCRIPT_NAME=/info.php REQUEST_URI=/info.php/test?a=b SCRIPT_FILENAME=/docroot/info.php QUERY_STRING=a=b REQUEST_URI and SCRIPT_FILENAME are not part of CGI spec, but are apache specific. What I *really* get is: PATH_INFO=/info.php/test PATH_TRANSLATED=/docroot/info.php/test SCRIPT_NAME=/php/php-cgi (from the Action setting I suppose) REQUEST_URI=/info.php/test?a=b SCRIPT_FILENAME=/path/to/php/bin/php-cgi (Action setting translated) QUERY_STRING=a=b Further, PATH_INFO should always be empty if no extra path info is used in the request (ie. http://localhost/info.php). PHP_SELF is also quite wrong since it is basicly PATH_INFO. Now, if I set up PHP to use the CGI handler in this way: Options +ExecCGI AddHandler cgi-script .php And add a bang line to my script: #!/path/to/php-cgi I get the correct settings (well, I did that with perl and it gets the correct stuff, so php should as well). However having to do this is evil, since PHP apps typically do not have the bang line, we keep changing the executable names, people install php to different locations, and so forth. I also beleive this is the same reason path_info has never worked in cgi under IIS. So, unless anyone has a better idea, or my apache config is extremely wrong, I'm going to rip apart the whole file handling situation in php-cgi and fix it to work right, and provide the correct CGI spec'd values. This will involve parsing the above variables, figuring out what the right settings are, doing at least one stat() call (more if extra path_info is used), and modifying the environment prior to calling php_request_startup. This will also fix my fastcgi problem as they are the same. I already have part of the patch done that fix path_info and path_translated. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
I am completely +1 to the concept of taking error codes out of the PHP core and replacing them with an XML document, period. I had wanted to avoid this whole thread, but decided to read this one message, and ouch. While I'm all for internationalization in general, I'm realy not all for using xml wherever possible just because it can be. There are existing techniques and libraries designed for this, find one and use it. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
John Coggeshall wrote: I am definitely -1 for this idea. XML is a buzzword, it is good in some cases not so good in others, definitely not a one size fits all solution. In PHP's case it would add decency on an XML parser, make life of developers adding, modifying, removing error messages difficult and just like the documentation will seriously lag behind the primary (English) localization. As I mentioned via Shane's comments... XML isn't really the crux of the matter here, I'm more interested in the concept than implementation. I'm interested in hearing what libraries and techniques Shane has in mind. cats or gettext comes to mind. man catgets google search: internationalization cats gettext seems to be ported more (it's on osx by default, cats isn't). Some defines can be created so that php does not have to be compiled with support for it: PHP_I18N(Some English Phrase Here) It can be configurable via (ugh) php.ini, or LANG from the environment. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error Codes, Langs, etc
Sascha Schumann wrote: cats or gettext comes to mind. Neither are usable, though, because PHP would need to support multiple concurrent message catalogues on a per-thread base. gettext/catgets associate exactly one language with each process through the use of environment variables, so that they cannot be used in a multi-threaded server. A mechanism based on the bundled cdb, for example, would be superior in terms of speed, thread-safeness, and portability. Why? The error messages are for the developer, not the masses. But generaly I agree with using something else. More the point is that stuff exists, techniques exist, no need to reinvent the wheel. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Windows Threads
John Coggeshall wrote: Shane (and everyone else): Why don't we move PHP into a separate executable. Design a thin ISAPI DLL which purely passes the data which the ISAPI DLL exposes between the IIS process and the PHP process (or process-pool for added reliability). The resulting page is processed in the application server and returned to the ISAPI DLL where it is output. Shane and I have already been looking into a similar solution for the UNIX version of PHP. In fact, if you ask'd him I think he's already got something working in this respect using FastCGI. This is exactly what fastcgi does. Incidently, Shane weren't you involved in the Windows port of PHP? :) Yes, I am to blame. I think this solution will be *way* easier than trying to fix every single bug in PHP so that it is utterly thread-safe and crash-free. That's the idea. Part of the issue is that the external libraries PHP uses can't be promised to be thread-safe. An thus why I did the isapi fastcgi plugin. www.fastcgi.com Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Windows Threads
Nick Loman wrote: Well, that's cool then! Why not simply include all this stuff with PHP rather than supporting the flawed ISAPI that it currently is packaged with? 4.3 the windows cgi binary is compiled with fastcgi support. I'm going to be testing the fastcgi on osx this week once I get things building correctly, so that should allow easy building of the cgi/fcgi binary on osx and linux. fastcgi itself is not php specific, and is supported from fastcgi.com. It's not the isapi plugin itself that is at fault, and likely not too much of the core is a problem, it is the state of thread safety in the extensions and third party libraries that are used in php. It's also a lack of good mt testing facilities. And for those who dont care about isapi, face it, you'll have the same exact problems with apache 2 mpm. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] prototypes for getters and setters.
Anyway before I get carried away and actually test this :) - anybody got any thoughts. Regards Alan What's wrong with how overload does this? SHane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] prototypes for getters and setters.
Alan Knowles wrote: Shane Caraveo wrote: Anyway before I get carried away and actually test this :) - anybody got any thoughts. Regards Alan What's wrong with how overload does this? it has a slight downside in clarity of code - eg. where is that method.. But it (overload) also does not introduce new syntax, requires no changes to the engine, is genericly overrideable in extensions, etc. etc. etc. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] run-tests.php
Ok - so unless Shane disagrees and gets physical, /me jumps around screaming after hiking up a large mountain carrying 2 40lb. boulders...physical enough? :) run-tests.php should be in 4.3 and will have a totally different code-base than the version for php 4.4/5.0. I don't expect we'll be done with the new test stuff in time for 4.3unless 4.3 takes *way too long* to get out. My personal goal with this is to have at least some kind of automated thread based testing for 5, and some way to test through sapi modules. The problem with that is, that you guys can't keep up with code changes, but only feature changes. The features addressed in the patch, are IMO important though. I'm more concerned about getting the architecture of the test system flexible enough to have different test modes (as John has described on this thread). If the layout is right, features should not be hard to backport into the new stuff. But we can also try to keep up with the new features as we go along to lessen any issues that may arise. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PATCH] run-tests.php
This would make a simpler test, which would not need to rely on more advanced features like OO, which may change in their functionality once ZE2 comes around, as Marcus had pointed out. Since at this point we could have people running both ZE1 and ZE2 use the test, I think relying on OO is dangerous. My reasoning is that considering the simplicity of the testing 'engine', we do not need to add the OO layer of obfuscation. Now, I am not a big fan of OO, so my opinion on the matter maybe somewhat skewed in that regard, non Ilia The basics of php OO, which is all that will get used, doesn't change enough between ze1 and ze2 to warrent any worry about it. If it does become an issue then we'll deal with it, but I find that highly unlikely. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: run-tests.php errors/warnings
The tests can only be performed using the cgi/cli sapis since they require a command line PHP binary. So, this is a non-issue. If we must display error messages then I would prefer using display_errors=1 instead of log_errors=1. Ilia I'm working with another person on a web version of the test script, and on a multithreaded test script. Purpose is to test multithread support, and hopefully start finding the issues, under IIS and Apache 2. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-DOC] Apache 2 installation instructions
I did more work and testing with fastcgi and apache 2, and have php 4.3 running under apache 2. Since it's out of process, no multithread issues which are one of the major issues. I didn't write docs, but there are some in sapi/cgi/README.fastcgi Shane As far as I can see, we should not not put into the PHP documentation that Apache 2 is not production ready, but PHP is not production ready for Apache 2. This is of course shows us in a negative manner, but we need to make our users be aware of the fact that PHP should not be used for production in Apache 2 (as long as this is the case). Goba -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Work is beginning on cURL and PHP again
Sterling Hughes wrote: On Mon, 2002-10-21 at 22:15, Jon Parise wrote: On Mon, Oct 21, 2002 at 10:12:55PM +0200, Sterling Hughes wrote: * Autogenerating much of the interface between cURL and PHP, allowing PHP to support multiple versions of the underlying cURL library By what mechanism do you plan on implementing this? Well, currently i plan on using a Perl script to read the curl.h definition file, and generate the code for all options that don't meet the following criterium: What, you can't write a simple parser in php? Off with his head! ;) Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Work is beginning on cURL and PHP again
Sterling Hughes wrote: On Tue, 2002-10-22 at 01:38, Alan Knowles wrote: Non blocking connections would be nice... - On the generating stuff - why do you want to generate the code on the users system? - all the re2c stuff in CVS is 'pre-genereated' It would be nice to have extension generator that could be built upon, that didnt involve re-reading all those perl/awk manuals, just to add features to it. :) Any idea if finding 'generic' bits in the php-gtk generator is possible? Well, the reason for the generator, is it will build an extension that mimics the current version of cURL installed which will allow the cURL extension to support multiple versions of the library without a lot of maintanence and stuff :) -Sterling Actually, the pre-generated stuff should be done, it will make windows life easier. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] short_open_tag
Brad LaFountain wrote: It would be very bad for php if short tags were disabled. I 100% agree with andi. There are ways of dealing with xml and php without pissing off the WHOLE php user world. I don't even use long tags EVER, nor will I want to start. - Brad Damn, that comes from a SOAP developer too ;) Just wait till he starts embeding php in xsl :) Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Xerces?
Xalan and Xerces have both java and c versions. Markus Fischer wrote: Since Xalan is written java, won't ext/java do that work anyway? On Wed, Oct 16, 2002 at 02:56:50PM -0700, Alex Black wrote : Hi all, I have done limited looking but as far as I can tell Xerces is not supported by PHP. A) hopefully I am wrong and just didn't look hard enough. B) If not, any validating parsers that are supported that do DTD validation? It looks like there's an experimental Xalan ext out there, but no Xerces. I have a vague memory of the XML setup being generalized to allow (x) parsers, did that happen, etc? In any case, if there aren't any validating parsers supported by PHP... There should be :) Please respond to the binarycloud-dev list also... Thanks, _alex -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php_variables patch
I'm working on getting mod_fastcgi/apache2/php4.3 to work together
smoothly. One thing mod_fastcgi does is, when it starts the fastcgi
processes (php in this instance) very little environment is given to the
process. The environment is sent via the fastcgi protocol for each
request. To deal with this a hacky overwriting of the environment was
done on every request. Other than being a hack, it was also a memory
leak. I've fixed that by introducing a way for me to override the
php_import_environment_variables function in PHP. This should introduce
no side effects for anyone, but I want to pass the patch by dev before
commiting. I've finished my patches to cgi_main.c, but those patches
require this.
Shane
Index: php_variables.c
===
RCS file: /repository/php4/main/php_variables.c,v
retrieving revision 1.44
diff -u -d -u -r1.44 php_variables.c
--- php_variables.c 8 Sep 2002 00:27:05 - 1.44
+++ php_variables.c 13 Oct 2002 07:26:09 -
-28,6 +28,9
#include zend_globals.h
+/* for systems that need to override reading of environment variables */
+void _php_import_environment_variables(zval *array_ptr TSRMLS_DC);
+PHPAPI void (*php_import_environment_variables)(zval *array_ptr
TSRMLS_DC) = _php_import_environment_variables;
PHPAPI void php_register_variable(char *var, char *strval, zval
*track_vars_array TSRMLS_DC)
{
-318,8 +321,7
}
}
-
-void php_import_environment_variables(zval *array_ptr TSRMLS_DC)
+void _php_import_environment_variables(zval *array_ptr TSRMLS_DC)
{
char **env, *p, *t;
Index: php_variables.h
===
RCS file: /repository/php4/main/php_variables.h,v
retrieving revision 1.13
diff -u -d -u -r1.13 php_variables.h
--- php_variables.h 11 Dec 2001 15:31:05 - 1.13
+++ php_variables.h 13 Oct 2002 07:26:09 -
-31,7 +31,7
#define PARSE_STRING 3
void php_treat_data(int arg, char *str, zval* destArray TSRMLS_DC);
-PHPAPI void php_import_environment_variables(zval *array_ptr TSRMLS_DC);
+extern PHPAPI void (*php_import_environment_variables)(zval *array_ptr
TSRMLS_DC);
PHPAPI void php_register_variable(char *var, char *val, pval
*track_vars_array TSRMLS_DC);
/* binary-safe version */
PHPAPI void php_register_variable_safe(char *var, char *val, int
val_len, pval *track_vars_array TSRMLS_DC);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php_variables patch
Actually, I'm not sure when I'll be able to return to this so I'll just commit it since this is all working, and people can complain later if they want. Shane --- I'm working on getting mod_fastcgi/apache2/php4.3 to work together smoothly. One thing mod_fastcgi does is, when it starts the fastcgi processes (php in this instance) very little environment is given to the process. The environment is sent via the fastcgi protocol for each request. To deal with this a hacky overwriting of the environment was done on every request. Other than being a hack, it was also a memory leak. I've fixed that by introducing a way for me to override the php_import_environment_variables function in PHP. This should introduce no side effects for anyone, but I want to pass the patch by dev before commiting. I've finished my patches to cgi_main.c, but those patches require this. Shane Index: php_variables.c === RCS file: /repository/php4/main/php_variables.c,v -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
re: [PHP-DEV] sapi/fhttpd + other sapi/cgi related things..
Seems I got unsubscribed and missed this email. sapi/fastgi is lacking in code that exists already in sapi/cgi, so I combined them several months ago. The idea is to depricate sapi/fastcgi in favor of the combined cgi/fastcgi module. libfcgi code from fastcgi.com is full of calls to exit() making it a bad thing since you generaly want to clean up if there is an error. I've done the work on the windows side to remove that issue, so that is why there is a libfcgi directory under sapi/cgi. The build system for linux needs to introduce a --with-fastcgi or even better, --without-fastcgi, which will set the define PHP_FASTCGI for the sapi/cgi compile, and include the libfci library as needed. Shane List: php-dev Subject: [PHP-DEV] sapi/fhttpd + other sapi/cgi related things.. From: Jani Taskinen [EMAIL PROTECTED] Date: 2002-10-12 6:31:04 [Download message RAW] While trying to make Andrei happy and come up with --disable-cgi option, I noticed that there is really nice little mess in there.. First of all, status of fhttpd...last version of it was released in 17-May-99..also last real updates to this code seem to have happened in PHP3. Can we get rid of this (most likely not even working) piece of code? Second issue, why is the fastcgi related files all over the place? :) There is sapi/fastcgi/ directory which has the config.m4 file and some other stuff. Then there is also some files under sapi/cgi/libfcgi/ which don't seem to be used anywhere? Why aren't those under sapi/fastcgi/ ?? --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.3 fastcgi
I'd like to make sure fastcgi is well supported in 4.3. I spent some time over the weekend working on this and have some patches that I'll try to get into the tree in the next day or so. I haven't commited them yet as I am having problems getting it to work with apache2-win32/mod_fastcgi (a mod_fastcgi configuration issue I'm trying to figure out). I don't have the time however to do any testing on linux with this, and linux also needs build changes (more on this below). Some months ago I integrated the fastcgi sapi module into the cgi module for a couple reasons. One was the lack of support for a bunch of stuff in the fastcgi module which the cgi module already had. I felt that rather than maintaining the same code/features in two different modules, that a single module would be better. Another reason was that I wanted one executable rather than multiple executables (I still see php-cli and php-cgi seperation as a downside). There is also a somewhat customized libfcgi under sapi/cgi directory. This primarily contains bug fixes for win32, and changes to make the library a better fit for PHP (ie. not calling exit on errors). The build system needs updating to support building this on Linux systems. I'm thinking that --with-cgi-fastcgi would build the cgi/fastcgi module, and --with-fastcgi would build the seperate fastcgi sapi module. --with-cgi-fastcgi should be default when building the php-cgi module, and a --without-cgi-fastcgi available to turn it off. Another option, --libfcgi=path to use a library different that the one included in the source tree. One of the items in my uncommited patch is to integrate the last changes that happened in the fastcgi sapi module, which is support for running PHP as a fastcgi socket server. One difference between the to is the way that is initated: php-fastcgi address:port php-cgi -b address:port If anyone sees any issue with getting this into 4.3 please let me know. A future feature (after 4.3) I want to implement for fastcgi is a multithreaded fastcgi socket server. This would allow for more configurability in how php is used (single process/request, single process/multiple requests), and provide a way to run out-of-process multithreaded php. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ODBC and PHP
Hmm, is there no way to make the functions work with both odbc versions? Have an odbc_set_version(int) function that can set the version of odbc to use. The default can be version 3. This way, with the addition of a single function call, scripts can provide BC. Shane Dan Kalowsky wrote: To Whom It May Concern, I've been working for the last few months (delayed often, but mostly the last few weeks) on what I've been tenatively calling ODBC2. Basically this is what I'd like to see PHP v 5 have as it's default ODBC system. Some general notes about it: - It will break BC. I have tried to conform and keep things the same, but I'm not making any promises to keep BC at this time. - It will support ODBC v 3.0 and greater only. With the needs of many DBs to include larger typesets (like TEXT, NTEXT, IMAGE, etc) and UNICODE, I see this as being a necessity. Some implementation notes: - So far my testing is being done using iODBC, unixODBC, and Windows ODBC drivers. I have no way of checking any of the others... help on this front would be appriciated. Some of the features already added to it: - Ability to control the ODBC environment handles before and after a connection is created. - Ability to specify a CURSOR for use in statements. - More strongly enforced safe_mode restrictions. - The ability to connect to data sources without being defined locally. - A user can force the PHP system to create a new connection now. - An attempt to make the ODBC API look more like the MySQL/PostgreSQL APIs feature setwise. - An option for the user to turn on which can allow dynamic sizing of a result set text field (currently it's static). - Use of the default_user, default_db, and default_passwd in the php.ini. - Hopefully more detailed error messages. - Native support for returning results from functions, and SQL based constructs (outside of SELECT statements). If you have any specific functionality you would like to see, please send it to me, and I will see what I can do about adding this in. I would like to add this into the current PHP system, to allow users to start playing with and testing as well. Well probably just as soon as I finish some more of the odbc2_exec/odbc2_execute() cleanups. This code is not optimized in any way, shape, or form. It's not even believed to work with a lot of systems. Because of this, I would like to hear back commentary back on any suggested recourse from those who've done this already. Hopefully this will prove to be a useful change, and people will be happy :) As always send your comments to me. --- Dan Kalowsky I'll walk a thousand miles just http://www.deadmime.org/~dank to slip this skin. [EMAIL PROTECTED] - Streets of Philadelphia, [EMAIL PROTECTED] Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ODBC and PHP
Ok, then I would be for ODBC 3 for PHP 5 as the standard. An ODBC 2 extension can be shuttled out to PECL for those who may need it. But for BC issues, there is still the nameing convention. I would personaly prefer that the odbc functions stay odbc_*, rather than to start iterating through odbc2...odbc3 and so forth. Don't know an easy solution right now. Shane Dan Kalowsky wrote: On Tue, 10 Sep 2002, Shane Caraveo wrote: Hmm, is there no way to make the functions work with both odbc versions? Have an odbc_set_version(int) function that can set the version of odbc to use. The default can be version 3. This way, with the addition of a single function call, scripts can provide BC. This is a tricky question really. Theoretically, yes it should be possible to allow this. You may run into issues with some of the result sets, but the connections should still be the same. You couldn't really do it with a function like odbc_set_version, as my understanding of ODBC states you must declare which version type you are using at compile time. If you have some documentation stating otherwise, I'd be interested in reading it. The reality is, I don't know. All ODBC3 drivers should be able to utilize the deprecated functionality just fine, but the mapping is an unknown and dependent upon vendor implementation. Going the other way, of course, is not going to work. But I don't see a reason to keep such BC at this point. The problem with the current system can be seen with bugs in the result sets. The one area specifically mentioned above. Users are still going to ask Why doesn't my select work? while using NTEXT or something non-compliant. The CURSOR type cannot be changed with the current system. This in itself leads to a slower implementation, a (unnecessarily) larger memory footprint, and in DB2 systems a memory leak. Hey at least I haven't gone as drastic as I originally thought, and asked to drop support specific for things like DB2, Solid, Empress, etc, and only support multi-driver systems (unixODBC, i-ODBC, and Windows ODBC). :) Although I still think that would make the most sense and be the easiest to support on our end of things. --- Dan Kalowsky I'll walk a thousand miles just http://www.deadmime.org/~dank to slip this skin. [EMAIL PROTECTED] - Streets of Philadelphia, [EMAIL PROTECTED] Bruce Springsteen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sockets extension...pecl it
Dan Kalowsky wrote: Because the user can see how active such functionality is by looking at the CVS logs, and doing a search on php-dev conversations. Sorry, but that's a copout. It expects way to much of the user. If it's going to remain experimental, OR the api is going to continue to change in incompatible ways, it shouldn't be part of the standard PHP distribution. We have a means to distribute extensions outside of PHP now, IMO experimental extensions should not be allowed into the core PHP distribuation any longer. PECL it. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mbstring
Jim Winstead wrote: Yasuo Ohgaki [EMAIL PROTECTED] wrote: Marcus B?rger wrote: We already had some discussion on some IF statements in ini files already. I guess we might call to another mail thread here and hope we find a volunteer. I will not invent any work here since that would be totally useless. I think having a IF in php.ini is good idea. it's too bad we don't have an implementation of a complete programming language laying around. jim Yeah, sure would be usefull, then we could just get rid of ini, and use the language... Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ISAPI Crash Debugging Notes
Either way - starting threads from an ISAPI filter/extension is completely forbidden (or at least strongly discouraged) so even if there is some bug in there, starting our own thread is not an option. Can you give me the data I mentioned in the previous letter? Zeev It's not forbidden or even discouraged, in fact, it's quite the oposite. The sdk comes with examples of creating worker threads in isapi modules, and I've done that plenty. I have had it in the back of my head to port over some of the isapi work I've done in the fastcgi extension to the php isapi module since it uses a couple techniques suggested by MS for performance (such as creating worker threads and async read/write). Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.3 and PHP 5
Rasmus Lerdorf wrote: But how do you propose we come up with perfect Apache 2.0 support? FastCGI :) If we limit it to the pre-fork mpm, we can probably get quite close to perfect stability, but for any of the threaded mpms we are completely at the mercy of the threadsafetyness of all the various third party libraries on all the various platforms that PHP runs on. There is simply no way to ensure that PHP against Apache 2.0 with a threaded mpm will be production quality. The best we can do is pick a small set of extensions and a small set of platforms and say that with the limited set of extensions, against a specific set of versions of addon libraries on a specific version of that OS, yes, it should be production quality - maybe. -Rasmus Sounds like windows now ;) Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1
It took us a long time to get php-dev moving on the new version because most of them were still using PHP 3 for their production sites. The fact that you guys are so strongly in favor of putting this cool feature into ZE1 proves that not putting it in could give ZE2 a big boost of momentum. Everyone feels very strongly about this feature. (On a side note, at least that makes me happy that people liked this revolutionary/negligible performance impact patch :) I think we need this new momentum. A new version of the engine is very important if we want PHP to compete with the latest technologies. If PHP doesn't get moving on its next version I'm afraid it won't be able to maintain its current position in the market. The only person I have seen thinking of what he'd like to get done for PHP 5 is Wez. By the way, the only personal gain I have in getting ZE2 out of there is that it's my code and that PHP will do much better. I think that PHP is going to loose out big time if things don't start gaining some momentum. Backporting is definitely a momentum breaker *especially* as everyone really really wants to backport it badly. That's exactly my point. If you guys want it so badly then work for it! :) Andi One difference between now and the 2-3-4 transition was that then there was a much smaller development group, and one that was invested in and focused on the new versions. Decisions were made primarily by a small group, so even our arguments could be thrashed out fairly quickly. This is not so true today. It's a much larger group of developers, more focused on features needed to do their stuff, rather than the language itself. I don't think that is a bad thing, PHP can use ever more features, but I think PHP has gotten big enough that a smaller group needs to sit down and outline a roadmap and proceedures that will help move towards the goals outlined by the roadmap. The roadmap can't of course prevent someone from implementing stuff not in the roadmap, but at least it would give PHP development a more visible and focused direction than it has now, and what must be done for each version. I suggest a smaller group, because by experience, talking about this stuff in large groups, such as php-dev, leads to never ending cycles of discussion and argument that lead nowhere. The larger group can comment on the roadmap, providing possibly valuable feedback, but it cannot provide the focus necessary to drive development in a targeted direction. Personally, I would trash 4.3, and focus on the next major version including ze2. Do it now, get it over with. Having this non-descript 4.3 between now and ze2 is somewhat distracting. There can be minor point releases to backport bug fixes, etc. Modules can be independently released via PECL if necessary. Afterthought, the only important language item I can think of for 4.3 that shouldn't wait is getting pear in there. I'm sure someone will dissagree. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Streams: FTP/HTTP wrapper gurus wanted
Wez, I haven't looked into the streams stuff much, but have had it in the back of my head a lot. Does the streams implementation support 'filters' on streams? With this, whatever gets written to a stream would go through a filter prior to going across the wire. Reason I ask is that this would be a perfect fit for protocols like DIME. Shane Wez Furlong wrote: Hi Sterling, I'm not sure :-) I'm 50/50 on integrating curl, because I know that it supports more features than the current wrappers, but I'm not sure if it supports a rich enough API to do the things that the streams API supports. So, I need your opinion: Does libcurl allow you to have progress notification callbacks, so that scripts/extensions can act on notifications such as mime type, file size, and overall progress? (I know it can print out a progress bar, but we need something a little bit more useful than that :-) Can we wrap a curl handle up into a stream without too much trouble? Is libcurl thread-safe? The other stuff should be relatively easy (like HEAD requests and so on), but if those two things look too hard, I'd be tempted to spend the effort on improving the streams code instead of trying to force libcurl to fit into streams. Last time I looked, I didn't like the look of libcurl, but it's been a while, so things might be better now. Opinions please! :-) --Wez. On 08/11/02, Sterling Hughes [EMAIL PROTECTED] wrote: Wez, This seems like an ideal time to me to start working on the bundling of cURL into PHP, no? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpthreads - hints anyone...
Alan Knowles wrote: Ok, had a play with this updated copy on http://docs.akbkhome.com/threads.tgz added a few of pthreads calls to TSRM.c did most of the testing without this abstraction layer - just to see if I could get it to work. used php_exectute_script, rather than getting clever and copying the function/class hashtables. results: It worked (with a few caveats - that are just a matter of getting to know threading better)... some of the issues: -if the child thread finishes before the main one - then the main one needs to wait somehow.. Do you mean the other way around? ** FIX = probably need to keep a count of threads that are running and block at MSHUTDOWN on the main thread if stuff is still going. The thread variable needs to be a resource, or tracked somehow, by the parent thread. Each parent thread needs to wait for child threads before ending. -the child thread needs to have the modules functions loaded before it starts running really - otherwise you get intermitant 'functions not available' if you dont dl() the module in the child thread. Fixed by loading in ini file. ** FIX = I need to look at the pthreads equivalant for tsrm_wait_event(thread.start_event,TSRM_INFINITE); will be.. this should make sure that the main thread doesnt do anything while the main thread is starting up.. I'm writing up rough equivelents to this, using pthread_cond_* functions. It will need work by someone using linux. - php_request_shutdown(NULL); calls the MSHUTDOWN for all modules - a good example of where this cause trouble is the ext/standard/string.c MSHUTDOWN, which has a static mutex that is freed. (and would be freed twice when the main thread finishes) - hence php_request_shutdown(), probably doesnt want to be called on a thread completion.. ** FIX = not sure? - does this need fixing or should we just ignore php_request_shutdown.. This is because you are dl'ing the module. When you do that, *unfortunately*, the module is unloaded per request. In the module shutdown, we should wait for all threads that were started to shutdown. But the use of a global mutex should not be necessary once things are more developed. Loading from ini will fix this. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpthreads - hints anyone...
Andi Gutmans wrote: By the way, if we do end up making this kind of thing mainstream we should probably use APR (or another library) for thread abstraction. I wouldn't want to do all of that work over. Andi That would be nice, but not sure how realistic at this point. Idealy, we would be using APR throughout PHP. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpthreads - hints anyone...
I've cleaned things up a bit, removed code from tsrm and added it to a new file, and commited to pecl. This way those interested can start playing with and developing the module. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpthreads - hints anyone...
Andi Gutmans wrote: At 12:40 PM 8/3/2002 -0700, Shane Caraveo wrote: Andi Gutmans wrote: By the way, if we do end up making this kind of thing mainstream we should probably use APR (or another library) for thread abstraction. I wouldn't want to do all of that work over. Andi That would be nice, but not sure how realistic at this point. Idealy, we would be using APR throughout PHP. I'm not saying we should change all of PHP right now but if you're going to add thread function abstractions then we might as well use APR. Andi Well, the thread abstractions by themselves are fairly light weight, whereas going to apr requires more effort. ie., a single file with a few abstractions is not dependent on a whole library of stuff. I do think APR would be ideal, especially since php is used so much with apache in the first place, but for a few simple functions I don't see it making sence to do it right now. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpthreads - hints anyone...
Andi Gutmans wrote: I still think that if you're going to implement such a thread extension it shouldn't try and copy it's parents data-structures. It'd be very slow and prone to errors. Andi, Currently only the thread_include function that Alan wrote works. I have idea's for doing the other thing without having to copy stuff, and without using mutexes in the engine. Basicly, the idea is to recompile the file, but rather than start execution as normal, call into a function within the file. This gets us a middle ground that makes starting the thread easy, while allowing a function to be the target of the thread start function (which I *realy* prefere). I'm also thinking that it might be possible to set up a 'shared' interpreter on it's own thread that doesn't run anything, but is just used to store zval's for the other threads. When a thread_set/get is called, it actually comunicates with this extra thread to set/get the shared vars. Since you know the engine much better than me ;), what do you think of these idea's? Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpthreads - hints anyone...
Alan Knowles wrote: Ok, had a slight play with it again.. I did eventually find the perl code for threading although without an lxr server it's pretty much impossible to decipher all the macros they use.. It's not about looking at the perl code, that will tell you nothing unless you know perl internals. It's about the way the interpreter works, some of the architecture, that is simular to PHP. In PHP, threads are isolated, kind of like seperate processes, but in threads. Everything in PHP works that way, so in creating threads for php scripts, you have to have a seperate interpreter. Then you have to create a bridge between the threads for shared variables. shmop comes close to what is needed, but not close enough. The code for this stuff is pretty simple at the moment.. - so i'ts down the bottom.. You're much closer to what needs to happen now. But you cannot simply point to the memory for another thread. Doing that will cause problems like you are running into. You actually have to copy a bunch of stuff so each thread is completely independent. I've worked up some code in TSRM to abstract native thread calls, and have started on an extension, but probably won't have it complete until this weekend some time. What you've done now is fairly simular, but pthread specific. Given time, I might have enough done to email a diff containing my work tomorrow night if you want to take a look. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phpthreads - hints anyone...
Alan Knowles wrote: Im looking at adding threading to php, (for the cgi/cli stuff).. The story so far: I've created an extension which diverts all zend_execute calls into the extension - phpthreads_execute. this function is a copy of zend_execute with a few modifications - to copy restore things like EG(active_symbol_table); - to malloc lock and unlock the execute loop and release on each opcode. Ouch. While it's an interesting way to deal with the issue, I think this will be way too slow, and maintenance will be hard (keeping up with changes in the real zend_execute, and zend engine in general). As in a couple other responses, the way this needs to be implemented has been hashed out, largely based on how the same problem is solved in Perl (there is a remarkable amount of simularity between PHP and Perl at some levels). If you're interested, lets talk. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FEATURE REQUEST: symlinks under NT
Shell Shortcuts could be used to implement symlink like behaviour, and it would be compatible on more systems, but it would be a bigger pain to implement in PHP. As far as the directory junctions, this is how MS describes them: # NTFS Directory Junctions. These are NTFS directories that can be resolved to any local namespace. Directory junctions provide a very powerful tool for system administrators, but are not generally deployed—they can only be created with the Linkd.exe tool in the Windows 2000 Resource Kit. Because NTFS directory junctions can be used to make the storage namespace span volumes, they may present new subtleties for application developers. A key phrase here, 'local namespace'. Basicly, they ARE symlinks for directories. http://www.winnetmag.com/Articles/Index.cfm?ArticleID=8321 http://www.microsoft.com/windows2000/techinfo/howitworks/fileandprint/stordev.asp http://www.sysinternals.com/ntw2k/source/misc.shtml#junction And if someone was really wanting symlinks for files, Reparse Points could be used to implement a file system filter that implements them. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Komodo (PHP) Intergrated Development Environment Problems
Hi Jason, PHP-DEV isn't the proper forum for asking questions about commercial products. Email us on the komodo-discuss email list, email list info at http://aspn.activestate.com/ASPN/Downloads/Komodo Regards, Shane Caraveo Jason McCormack wrote: Hi All, Has anyone out there had any luck getting Komodo 1.2.6 to debug PHP? I have been banging my head against the wall with no luck. I went through the docs they supply - no luck. I compiled PHP as a module for Apache 1.13.22 on Mandrake 8.1. Any help would be greatly appreciated. Thanks, Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] flock on windows
Just a question and comment since I've been looking into php's flock on windows. First, the documentation states 'When using a multithreaded server API like ISAPI you may not be able to rely on flock() to protect files against other PHP scripts running in parallel threads of the same server instance!'. PHP's implementation on windows uses LockFileEx. I have found *NO* documentation, news postings, etc. etc. on LockFileEx anywhere supporting that statement in the PHP documentation. What documentation does say is that locks are not inherited by spawned child processes (A good thing). So I would be interested in the source of our documentation, or pointers to any documentation on the subject, if anyone knows. Second, LockFileEx is not supported on win9x, we could be using a simple LockFile call for those platforms. There is no way to do a blocking lock call with LockFile, but at least it would supply win9x with partial flock support. At the least, documentation should state that flock is not supported on win9x/ME/CE. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PECL != Siberia
It's a tough one :) Well, being able to build like on unix shouldn't be too hard to do, just have to call nmake on the dsp, but that wont work for the vast majority of users. Someone needs to provide prebuilt extensions that can be downloaded via pear, and unfortunately, I don't see any way other than having a build per version of PHP. So the built extensions would have to have a filename like: extname-phpversion-extversion.zip. Another idea would be to have the extensions built for windows on the server side, and cached if one was already built. Shane Stig S. Bakken wrote: You tell me :) We currently have no nice way of bootstrapping PEAR on Windows like we have on Unix (with make install-pear-installer and go-pear). What would be the most sensible way of giving Windows users something ala go-pear? - Stig On Sun, 2002-06-09 at 18:49, Shane Caraveo wrote: Hmm, what is happening for win32? Stig S. Bakken wrote: With the latest PEAR installer (version 0.90), PECL extensions are now built and installed during pear install/upgrade on Unix systems. First: upgrade PEAR to 0.9 with pear upgrade PEAR. If you have the xmms libraries and php_gtk installed, you can see it in action by doing simply pear install xmms. The output is like this: -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PECL != Siberia
Hmm, what is happening for win32? Stig S. Bakken wrote: With the latest PEAR installer (version 0.90), PECL extensions are now built and installed during pear install/upgrade on Unix systems. First: upgrade PEAR to 0.9 with pear upgrade PEAR. If you have the xmms libraries and php_gtk installed, you can see it in action by doing simply pear install xmms. The output is like this: -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
I indeed like to see some proof that it is used so widely. You state that XML is widely used, but I really think that this is only true for a small part of the people who work with PHP. This does not mean I don't see value in XML, it's certainly usefull... but that doesn't warrant bundling it and enforcing it for users who don't want or need it. xml is already bundled. We're idea was more about moving from xpat to libxml2. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision
Making PHP work a certain way because a specific platform doesn't have the different items should not be a deciding factor. wrong. It's absolutely a major factor. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision
Markus Fischer wrote: On Sun, Jun 02, 2002 at 04:21:48PM +0200, Sebastian Bergmann wrote : Jani Taskinen wrote: I'm not that familiar with Java..so it would be nice to hear what Java offers that PHP doesn't? And coming back to the original topic of this thread: perfect support for XML and all related technologies. Working with Java and XML is a charm. And too complicated to understand for the majority users of PHP too. Note that not everyone is as clever as you :) We don't have to make everything in PHP understandable by everyone. If someone needs to use XML, they need to learn something about it. If someone needs to use an SQL database, they need to learn SQL to some extent. I could go on. It's not about the technology being complex, it's about PHP making it easy to use that technology, but there is always a learning curve that people must go through to use the technology effectively. If we don't advance PHP's capability with a technology because the 'majority of users' wont understand the technology right away, then PHP is doomed to being a tool that does some neat things, but not a tool that is powerful enough to fullfill advanced needs. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP's vision (was: libxml bundling)
The PHP project does not exist to create the perfect incarnation of a computer language on the planet, for CS majors to drool over and utter 'Wow!' at. It exists as a quick, powerful platform for creating web sites, in use by hundreds of thousands of people around the world. For some, I believe, somewhere along the lines this was forgotten.. Zeev I think PHP can be both powerful and easy to use, and I think I have an example of that in my own experience. I've got code I wrote on PHP 2 years ago, that has gone through a couple face lifts and modifications to keep it compatible with new syntax, and occasionaly take advantage of new features. But you look at the code and it is still 'newbie' code because I haven't spent the time to rewrite from scratch. The point I'm trying to make is that PHP remains extremely easy to learn and use while it has gotten far more powerful over the years. I think there is still more room for more powerful and advanced constructs in the language without making the language perl. I also think there is still a lot of room for making PHP even easier to use, especially for new users. This is the way I've always seen PHP, and the way I think it should remain. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] libxml bundling
[EMAIL PROTECTED] wrote: On Sat, 1 Jun 2002, Yasuo Ohgaki wrote: [...] I wish it became a default module, too. Sure, lets enable everything by default then. ODBC is very important too, and of course also encryption, so we need mcrypt and mhash, or the very important FTP and PGSQL extensions. No seriously, I don't think we should enable more things by default. I even don't see any reason to enable the mbstring module, as only the japanese/koreans / other multibyte language really need this. Enabling things by default tend to annoy sysadmins who want full control of their install. I see xml and unicode as critical technologies for PHP in it's role as a web based scripting language, as critical as html itself. If people cannot seperate that from the issue of embeding a bit more code in PHP distributions, and recognize that xml is as critical to the future of PHP as the web itself, well, there's no convincing. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling / PECL
I think the solution would be to allow PECL to optionally fetch the libraries an extension depends on, quite like FreeBSD ports. It is exactly as much work as bundling them altogether, of course, but at least we avoid the impact on our distribution size. mk Actually, this is quite an interesting idea. So, here's food for thought. For situations like this, perhaps we can 'bundle' libraries in PECL. The make system could examine the system for the library, if it is not installed, or is not the required version, it could ask the user if they want to have it downloaded/built/installed automaticly. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
lot I'd be a +1. If it'd add 1 MB to our .tar.gz I would be against. THe normal source distribution is almost 2 MB... In that case I'm against :) Andi xpat is 300K. If Brad can get it down to 500K, and we replace xpat, then we realy are not growing all that much. I'm for doing this since soap (in addition to other things) would greatly benefit from having this bundled. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bundling libxml2 / bundling locations
In regards to download size, I took a look at other languages: perl 6mb source python 6mb source activeperl 8.5mb binary activepython 7mb source, binaries are larger activetcl 8.5mb I don't think the increase of a half mb in php source size is that big a deal, esp. for something as important as xml. The only downside in increasing the size is the bandwidth requirements for php.net. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV][RESENT] [PATCH] Allow constants / expressions to be passed by reference]
Ahh yes, I've been bitten by this limitation a few times, quite
agravating. I would definitly like to have this work.
Shane
phpsurf wrote:
the problem is that if you define some function :
function someFunc(myParam) {
...
}
then you can call :
someFunc($someVar);
but not :
define(MY_CONSTANT, 0);
someFunc(MY_CONSTANT);
the goal is not to pass a constant by reference, but to be allowed to
(exceptionnaly) pass a constant as a parameter to a function that was
designed to receive parameters by reference.
and this could also let people define default values for params and still
have them passed by reference ...
-Original Message-
From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
Sent: mercredi 29 mai 2002 17:26
To: Stig S. Bakken; Jason T. Greene
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] [RESENT] [PATCH]
Allow constants / expressions to be passed by reference]
I don't see any reason to allow passing non-variables by reference.
It is semantically incorrect.
Andi
At 09:40 29/05/2002 +0200, Stig S. Bakken wrote:
If this patch doesn't break anything, and it doesn't give us any
difficulties with ZE2 or major design issues, I'm +1.
- Stig
On Tue, 2002-05-28 at 21:12, Jason T. Greene wrote:
Due to this patch being sent during the msession discussion,
it has not
been noticed, so I am resending.
-Jason
From: Jason Greene [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: [PHP-DEV] [PATCH] Allow constants / expressions to be passed
by reference
Date: 25 May 2002 02:18:52 -0500
Problem
---
There are some scenarios where a function requires the
ability to modify
parameters that may also be optional. Optional parameters work well,
except in the scenario where all of the pass by reference
parameters can
be optional. ex the socket_select() function. Since select is
argument-result, all three arrays that are taken as input
must be passed
by reference, yet any can be excluded. So for example if you were
calling socket_select with a read socket array, a write socket array,
yet no exception array (quite common), you are currently forced to do
something like the following:
$wfds = array($sock1, $sock2);
$rfds = array($sock3, $sock4);
$null = NULL;
socket_select($rfds, $wfds, $null);
I have ran into this problem before several times while developing in
user space. (Especially when passing around semi-complex data
structures)
Proposed Solution
--
Allow all expressions to be passed by reference. This will allow
something like the following
function normalize($element_tree, $node_mapping, $max_depth){
//Code
}
normalize($my_tree, NULL, 25000);
Patch
--
I have attached a patch against ZE2 that accomplishes this.
Thanks,
-Jason
Index: zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.285
diff -u -r1.285 zend_compile.c
--- zend_compile.c23 Apr 2002 18:06:53 - 1.285
+++ zend_compile.c25 May 2002 06:45:21 -
@@ -1271,7 +1271,7 @@
op = ZEND_SEND_REF;
break;
default:
- zend_error(E_COMPILE_ERROR, Only
variables can be passed by reference);
+ op = ZEND_SEND_VAR;
break;
}
}
Index: zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.341
diff -u -r1.341 zend_execute.c
--- zend_execute.c8 May 2002 18:43:19 - 1.341
+++ zend_execute.c25 May 2002 06:45:25 -
@@ -2292,10 +2292,6 @@
NEXT_OPCODE();
}
case ZEND_SEND_VAL:
- if
(EX(opline)-extended_value==ZEND_DO_FCALL_BY_NAME
-
ARG_SHOULD_BE_SENT_BY_REF(EX(opline)-op2.u.opline_num, EX(fbc),
EX(fbc)-common.arg_types)) {
- zend_error(E_ERROR,
Cannot pass parameter %d by reference, EX(opline)-op2.u.opline_num);
- }
{
zval *valptr;
zval *value;
@@ -2329,7 +2325,8 @@
zend_ptr_stack_push(EG(argument_stack), varptr);
NEXT_OPCODE();
}
- zend_error(E_ERROR, Only
variables can be passed by reference);
+ /* Should only occur with an
uninitialized variable */
+ goto send_by_var
Re: [PHP-DEV] PECL vs. CORE .... from a users perspective
Michael Dransfield wrote: 1: I assume that for the ext's that are dropped from core and added to PECL, the extension line will be dropped from the ini file and users will need to use some kind of 'use EXT::Extension' command. Will there be a way to override which extensions will need to use this command? No, nothing will change from a configuration point, at least not in the near future. You will simply have to do an additional step when installing PHP to install extensions that are not part of the primary distribution. It would be something along the line of 'pear install extension_name'. 2: Will the ini configuration setting disable_functions still apply to PECL (and maybe PEAR, since there a lot of NET functions there) functions? Yes. 'Where' the extension is distributed from makes no difference in how it works. I have noticed the SOAP development discussions and see that they are looking to co-develop the PEAR and C extensions. They are relying on including a code snippet at the top of every page using soap functions. Nothings being relied on right now, just idea's are being floated. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PECL vs. CORE .... was msession
I would like reinstatement of msession into the main tree, and if you oppose I would like a serious discussion to take place on the developer list. If you support it, I need you to sound in on the discussion. Well, I feel like 80%, if not more, of the extensions should move to PECL, leaving only the bare essential extensions, and only those that are cross-platform. There are 111 extensions in the main php distribution, it's gotten way out of hand. If it were my choice the following would happen: Move to PECL: all non-cross-platform extensions all 'product' specific extensions (cybercash, midgard, etc.) legacy db extensions all extensions marked EXPERIMENTAL any undocumented extensions exceptions would be made for 'major' technologies like ODBC and COM, and those extensions required to install other extensions (zlib, xmlrpc, etc.). Binary distributions would contain certain extensions from PECL, for example the win32api extension, which realy shouldn't be in the primary distribution, but should be in the win32 binary distribution. Getting a new extension into the core should be very hard, and essentialy reviewed by the release manager and the major active developers. My opinion on this is nothing personal towards you, and I do think the move to PECL was handled incorrectly, but I'm not convinced it should be in the core distribution. I've spent lots of hours coding things I feel are very important, but that does not equal being important to a core distribution of a given project. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PECL vs. CORE .... was msession
Experimental extensions are not finished, likely undocumented, prone to change, prone to bugs, etc. They shouldn't be in core at all. core should be entirly stable. If it's an important enough extension it will be recognized as such, and mirrored to core after it is stable. Shane Vlad Krupin wrote: +1. Except EXPERIMENTAL ones. If an extension belongs in the CORE, it makes no sense to stuff it in PECL and then move back to core once EXPERIMENTAL status is dropped. Vlad Shane Caraveo wrote: I would like reinstatement of msession into the main tree, and if you oppose I would like a serious discussion to take place on the developer list. If you support it, I need you to sound in on the discussion. Well, I feel like 80%, if not more, of the extensions should move to PECL, leaving only the bare essential extensions, and only those that are cross-platform. There are 111 extensions in the main php distribution, it's gotten way out of hand. If it were my choice the following would happen: Move to PECL: all non-cross-platform extensions all 'product' specific extensions (cybercash, midgard, etc.) legacy db extensions all extensions marked EXPERIMENTAL any undocumented extensions exceptions would be made for 'major' technologies like ODBC and COM, and those extensions required to install other extensions (zlib, xmlrpc, etc.). Binary distributions would contain certain extensions from PECL, for example the win32api extension, which realy shouldn't be in the primary distribution, but should be in the win32 binary distribution. Getting a new extension into the core should be very hard, and essentialy reviewed by the release manager and the major active developers. My opinion on this is nothing personal towards you, and I do think the move to PECL was handled incorrectly, but I'm not convinced it should be in the core distribution. I've spent lots of hours coding things I feel are very important, but that does not equal being important to a core distribution of a given project. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL
Markus Wolff wrote: Am Thu, 23 May 2002 17:12:34 +0200 schrieb Lukas Smith [EMAIL PROTECTED]: So feature-wise is PHP on par with SOAP::Lite? From what I have heard people seemed to have talked quite favourably about SOAP::Lite. I assume documentation-wise PHP lags behind. I have no knowledge of Perl which is why I have no clue what features are/aren´t included in SOAP::Lite. Maybe Shane knows more about it? Regards, Markus SOAP::Lite has the same problem, in fact with simple stuff we've done at work it's proven to be less interoperable that PEAR::SOAP when it comes to dealing with .Net. Python is also very lacking in the SOAP arena. None of the scripting languages do realy well with WSDL, esp. when it comes to XML Schema. Deitrich's NuSOAP probably does better with WSDL/Schema than PEAR::SOAP, but I haven't tried to stress it to find out. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL
I would be happy to lead the effort on the soap front. I've spoken a bit with Brad about combining our efforts but got sidetracked over the last couple weeks so haven't followed up on that. I'm also not sure whether Deitrich is tied to NuSphere with his work, it'd be nice if we could get him to work on this also (I'm sure he's lurking here ;). There have been a couple others contacting me about working on the soap stuff as well. Shane Rasmus Lerdorf wrote: pear/SOAP seems to work pretty well. There are few people out there that know more about SOAP than Shane and I am quite comfortable having him spearheading this effort. We can easily set up a php-soap mailing list if enough people are interested. -Rasmus On Thu, 23 May 2002, Lukas Smith wrote: Yeah, I keep seeing PHP SOAP and XMLRPC being announce packages everywhere. But incompatible API's will not benefit PHP much and the efforts are simply redundant. I think it would make sense to create such a mailinglist. As I am still fairly busy with working on a merge of Metabase and PEAR DB called MDB (blatant plug :-) ) I can't spend as much time as I would wish on this topic. For now I will try to order the feedback I get and put together a little static page with the content. Basically I will take every package I find and list it there and put any comments people send regarding that package underneath. Best regards, Lukas Smith [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL
I would say go for it, but I want to hear from some others first to know that I wont be talking to myself on an email list ;) Shane Rasmus Lerdorf wrote: So do we want a [EMAIL PROTECTED] mailing list? I can set it up if you say the word. -Rasmus On Thu, 23 May 2002, Shane Caraveo wrote: I would be happy to lead the effort on the soap front. I've spoken a bit with Brad about combining our efforts but got sidetracked over the last couple weeks so haven't followed up on that. I'm also not sure whether Deitrich is tied to NuSphere with his work, it'd be nice if we could get him to work on this also (I'm sure he's lurking here ;). There have been a couple others contacting me about working on the soap stuff as well. Shane Rasmus Lerdorf wrote: pear/SOAP seems to work pretty well. There are few people out there that know more about SOAP than Shane and I am quite comfortable having him spearheading this effort. We can easily set up a php-soap mailing list if enough people are interested. -Rasmus On Thu, 23 May 2002, Lukas Smith wrote: Yeah, I keep seeing PHP SOAP and XMLRPC being announce packages everywhere. But incompatible API's will not benefit PHP much and the efforts are simply redundant. I think it would make sense to create such a mailinglist. As I am still fairly busy with working on a merge of Metabase and PEAR DB called MDB (blatant plug :-) ) I can't spend as much time as I would wish on this topic. For now I will try to order the feedback I get and put together a little static page with the content. Basically I will take every package I find and list it there and put any comments people send regarding that package underneath. Best regards, Lukas Smith [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL
Ugh, can't stand 'web services'. But anyway, I think this information needs to go into regular documentation on php.net and pear.php.net first, then if there is realy a need for it expand into an additional site. Shane Lukas Smith wrote: It sounds to me like something like webservices.php.net would be in order. I don't have a huge deal of time to really push this forward. I will provide a simple list to start and that will just be a static page for now and that people can expand as things go on (dunno how permissions for php.net subdomains is handled). It would however be great if someone steps up and dedicates some long term time to this and makes this THE resource for webservices for php. This would be a great opportunity for a php novice to gain some fame because a large chunk would be just compiling links and comments. But in the long run it will obviously be a great opportunity to become really knowledgeable in webservices in php. But I don't know how the process of setting up something like webservices.php.net would go. Best regards, Lukas Smith [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL
Unless some work has been done on it, I found it very lacking. Many things are hardcoded in C that would make it hardly interoperable with other implementations. Shane In fact, xmlrpc-epi also supports SOAP: ---[SNIP]--- As of Sept. 27, 2001, experimental support for SOAP v 1.1 has been added to the library. This support is implemented transparently to the application such that a single API can be used for manipulation of values, yet both SOAP and XML-RPC can be read or written. ---[/SNIP]--- However, I did not yet have the possibility to try it out so I don´t know whether things like WSDL and UDDI are supported. Also, the last file release is from September 26th - doesn´t look like a very active project. Regards, Markus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PEAR-DEV] SOAP, XMLRPC and WSDL
So this is what I propose... setup [EMAIL PROTECTED] for further conversation. As a starting point PEAR::SOAP is a script wrapper around a C level extension. It's available in absence of the C extension, and for additional features that don't make sence to implement in C, or for fast extendability. Brad's C extension is far more advanced than what is in xmlrpc-epi so I would go for using it. Move Brad's extension into PECL or the main PHP distribution (???) Get everyone involved/interested to go through the features of PEAR::SOAP and ext/soap, and lets come up with a common API for both to use. Getting them using the same API will allow for the wrapping of the C classes and other things like test harness and the interop scripts in PEAR::SOAP to work with ext/soap. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] soap email list
Everyone who subscribes, please send an email to the list so we know. Thanks, Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enabling ext/zlib by default
Stig S. Bakken wrote: On Tue, 2002-05-21 at 08:13, Sebastian Bergmann wrote: I think we should make '--with-zlib' the default, and add '--disable-zlib', for the PHP 4.3.0 release, since the PEAR Installer relies on it. It's not supposed to, I've added nocompress options everywhere needed, so it should work just fine without zlib: Hmm, I couldn't make the pear command work on windows until I loaded the zlib extension. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] DIME support class added
I added Net_DIME today to PEAR, it's a rough implementation of DIME. It's quite unfinished/undocumented and not all the spec is in place on it, but I thought I'd mention it since there's a few things I'd like to do it it, and if anyone wants to jump in that would be very cool. I haven't tested it with other DIME implementations yet so I'm not entirely sure it's working right, but if not it should be very close. Eventualy I think rewriting it into C. It could possibly be implemented directly into PHP's POST parsing so DIME requests could be handled transparently. I'd also like to integrate it with the streams stuff, but I still haven't looked at that so I don't know if or what needs to be done to do that. More info on DIME at http://www.gotdotnet.com/team/xml_wsspecs/dime/default.aspx Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
