RE: [PHP-DEV] Possible problem in the parser
At 13:01 14.03.2003, Ford, Mike [LSS] wrote: Just to make this completely clear, in left-associative PHP b = a==1? 4:a==2? 5:6; is equivalent to b = (a==1? 4:a==2)? 5:6; NO it is not equal. Either '==' has higher precedence OR '?:' has. See one of my previous mails where i showed where the error is. Yes, it is -- believe me, I've researched this extensively. It is NOT about precedence, but associativity. If you want me to be totally completist about this: Starting from: b = a==1? 4:a==2? 5:6; precedence rules make this equivalent to: b = (a==1)? 4:(a==2)? 5:6; but this is still ambiguous -- which ?: phrase do you evaluate first? Associativity provides the answer: in PHP, where ?: is left associative (i.e. the left most ?: is evaluated first), the result is equivalent to: b = ((a==1)? 4:(a==2))? 5:6; On the other hand, in c, where ?: is right associative, the equivalent is: b = (a==1)? 4:((a==2)? 5:6); which, apart from the additional (unnecessary) parentheses around the == comparisons, is exactly what I said before. QED Ok Mike, i did not took left association into accound becuase it is stupid. Since the whole thing is messy at the moment and there is no reason to keep BC for messy things which shouldn't be done anyway i suppose we make ir right associative. Andi? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Possible problem in the parser
At 14:58 13.03.2003, Ford, Mike [LSS] wrote: Just to make this completely clear, in left-associative PHP b = a==1? 4:a==2? 5:6; is equivalent to b = (a==1? 4:a==2)? 5:6; NO it is not equal. Either '==' has higher precedence OR '?:' has. See one of my previous mails where i showed where the error is. marcus -- 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.phpt interface_doubled.phpt interface_implemented.phpt interface_instantiate.phpt interface_member.phpt interface_method.phpt interface_method_final.phpt interface_method_private.phpt interface_must_be_implemented.phpt
At 14:53 12.03.2003, Andrei Zmievski wrote:
I have 2 questions:
1. Do the interface functions have to be explicitly specified as
abstract?
interface Foo {
function bar();
}
Because this runs fine for me with no errors.
They don't have to (currently) I weote the tests with abstract as i thought
this could be changed.
1. What is the difference between the following:
interface Foo {
}
class Boo extends Foo {
}
and
class Zoo implements Foo {
}
a class can only extend ONE class/interface but it can implement multiple
interfaces. If you ask me i would not allow extending interfaces at all.
regards
marcus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Need some ZE2 functions exported.
At 15:54 12.03.2003, l0t3k wrote: im trying to do some namespace related experimentation but im getting the Have a look at spl (http://marcus-boerger.de/php/ext/spl/) how that works without modyfing the engine. regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Possible problem in the parser
At 18:42 12.03.2003, Derick Rethans wrote:
On Wed, 12 Mar 2003, Andrey Hristov wrote:
Few minutes ago I found the following behaviour somehow wierd for me :
?php
$a = 1;
$b = $a==1? 4:$a==2? 5:6;
printf(a[%d]b[%d]\n, $a, $b);
?
Prints :
a[1]b[5]
Similar C program :
main()
{
int a,b;
a = 1;
b = a==1? 4:a==2? 5:6;
printf(a[%d]b[%d]\n, a, b);
}
Prints :
a[1]b[4]
-=-=-=-=-=-
I think that the behavior of the C program is the right
It's just a different operator precedence; it's not really wrong, just
different.
Where is the different precednece here? I can only find an error.
Lets support parantesis:
ALL BUT PHP) '==' has higher precedence than '?:'
((a==1) ? 4 : ((a==2) ? 5 : 6)) = (1) ? 4 : ((0) ? 5 : 6) = 1 ? 4 : 6 = 4
PHP?) '?:' has higher precedence than '=='
(a == (1 ? 4 : a) == (2 ? 5 : 6))
( a == (4) == (5))
Now what? Assume order left from to right: ( (a == (4)) == (5) = (0 == 5) = 0
Or right to left (which contradicts rest of PHP behavior): ( a == ((4) ==
(5))) = (a == 0) = 0
Result: This is (to say it in german mumpitz) wrong.
So lets fix it.
marcus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
At 18:50 12.03.2003, Steph wrote: php-dev-team might lose a few.. ...think f..ing hard..read.oh php-dev-team...thinkCOOL, they solve my problem, i'm getting better at it and finally a team member COOL what ever name we give this list draws attention to newbies as long as it contains the letters P, H and P again in this particular order. I think Shane got the solutionfollow up there marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
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. I guess this is the solution! Then another item that might be considered if it is not already done, allowing posts only from those that have cvs access. Hm, i don't know. I for one directly contacted rasmus as he was the developer mentioned in the sources in which i found and corrected errors when i started working here. However i guess not all of us started this way, did we? 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. That would be a minimum requirenment Otherwise, the list can be readable by all. Dito. 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 I already did this proposal but it was declined... , send it to [EMAIL PROTECTED] and it will be reviewed by someone when they get the time. Round robin list? Everyone in php-dev has to take care for some days? regards marcus -- 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.phpt interface_doubled.phpt interface_implemented.phpt interface_instantiate.phpt interface_member.phpt interface_method.phpt interface_method_final.phpt interface_method_private.phpt interface_must_be_implemented.phpt
At 19:57 12.03.2003, Shane Caraveo wrote:
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 {}
This works even though i do not like extends FOO.
class foobar extends foo implements (BAR,JAZ) {}
This doesn't - i hope - trying -
?php
interface a {}
interface b {}
class c implements (a,b) {}
/usr/src/php4-HEAD/-(4) : Parse error - parse error, unexpected '(',
expecting T_STRING or T_PAAMAYIM_NEKUDOTAYIM or T_NAMESPACE_NAME
You have to do
class foobar extends foo implements BAR,JAZ {}
marcus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Moderate PHP-DEV
At 20:00 12.03.2003, Weston Houghton wrote: This worries me somewhat. I do not have a CVS account. I do not actively develop and contribute to the PHP sourcecode right now, however my company uses php very very much. I would like to keep up to date on what is happening with the development team and figuring out what directions they are leaning and why. And if I want to contribute code down the road, I would like to be able to. So, I don't have a cvs account right now, and I don't need one, but if it were required to be on the list, then I would not be able to be on the list. I'd appreciate not having that requirement myself. Wes We must not loose contact to those delivering ideas and patches. But loosing all this noise is a good idea! So to you Wes, it is good to have readers like you! However we all spend to much time reading noise. regards marcus -- 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.phpt interface_doubled.phpt interface_implemented.phpt interface_instantiate.phpt interface_member.phpt interface_method.phpt interface_method_final.phpt interface_method_private.phpt interface_must_be_implemented.phpt
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. Hey these two words sound different and should have a clearly different meaning. I think we should disallow classes extending interfaces. Only 'implements' should be supported. As said already: yes. marcus -- 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.phpt interface_doubled.phpt interface_implemented.phpt interface_instantiate.phpt interface_member.phpt interface_method.phpt interface_method_final.phpt interface_method_private.phpt interface_must_be_implemented.phpt
At 21:12 12.03.2003, Shane Caraveo wrote: 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. We do not force classes to directly implement (supply code) for an interface method (and i do like that (now)). ok: interface extends interface class extends class implements interface not ok: interfaces implements interface class extends interface I would favor this: interface [ implements interface+ ] class [ extends class ] [ implements interface+ ] or less: interface [ extends interface+ ] class [ extends class ] [ implements interface+ ] I like the former more because it separates classes to extends and interfaces to implements and does not suggest MI. Howeve the latter has some more kind of logic since an interface extends other interfaces when they are inherited. (Maybe i'll change my mind after sleeping it over). i'm sure you know to write it correctly with the missing ',' :-)) marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] iterating objects with interfaces
At 19:05 10.03.2003, Marcus Börger wrote:
Standard PHP Library
Updated version allows:
class obj_array implements spl::array_read {
bla ...
}
$obj = new obj_array();
$value = $obj[$index];
marcus
--
--
Marcus Börger - Looking for all sorts of freelance work - just ask...
Did i help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0
--
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] iterating objects with interfaces
At 01:48 12.03.2003, Stephen Thorne wrote:
All this is starting to feel strangely pythonic.
How soon till
('pre'.($_GET['textArea']-strip_tags()).'/pre')-print(); ?
Very far of because i am working with objects and interfaces and have no
plan for other types as arrays and longs
marcus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] iterating objects with interfaces
At 15:51 10.03.2003, Brad LaFountain wrote: This IS pretty cool stuff. Just a comment about the namespace, as i see more of these things added as time goes on. since you are already adding the 'spl' namespace why are you prefixing the classes with the namespace still? This is the whole point of using namespaces. I feel it should be spl::foreach spl::forward spl::key Yes you're so rightit was a) to avoit '__' in methods and b) most ideas were developed before namespaces exists correctly. btw. what does 'spl' stand for? Standard PHP Library regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: iterating objects with interfaces
At 08:39 09.03.2003, l0t3k wrote: you're not campaigning for sainthood, are you ;-) LOL ive been reading python docs today, and their iterators and sequences are one of the things that make it so powerful yet simple because of their consistency throughout. This has nothing to do with perl. It is about common oo design pattern practice. And perl is one of the languages where such are implemented. what do you mean you didnt have to modify the engine ? did you mess with the opcode handlers ? Yes i hook on those two foreach() opcodes... l0t3k btw - im currently marooned on windoze until my mdk box is fixed, so could you post a tar.gz ? bz2 gives PowerArchiver the hiccups. /s/tar.bz2/tgz/ regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Question on startup
Can anybody answer this: Why do we have a sapi_deactivate(TSRMLS_C); call in php_module_startup()? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] iterating objects with interfaces
At 06:54 09.03.2003, Marcus Börger wrote: Hi, i've just done the first step for a new extension which shall make use of interfaces newly implemented in ZE2. SPL is updated and supports a complete set of iterator interfaces. After moving from Minit/shutdown to Rinit/shutdown i also have no more memleaks. The problem is here that we currently cannot have internal interfaces/functions and i didn't want to apply more changes to the engine. Interested? http://marcus-boerger.de/php/ext/spl/ regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces
At 08:10 08.03.2003, l0t3k wrote:
this may be a bit premature, but how do i inject the classes, functions and
constants in my extension into a namespace ?
l0t3k
See below :-)
marcus
/* {{{ register_namespace */
/* You will have to alloc the pns before the call */
void register_namespace(zend_namespace * pns, char *namespace_name TSRMLS_DC)
{
pns-name_length = strlen(namespace_name);
pns-name = namespace_name;
zend_hash_add(CG(global_namespace).class_table, pns-name,
pns-name_length+1, (void **)pns, sizeof(zend_namespace *), NULL);
zend_init_namespace(pns TSRMLS_CC);
}
/* }}} */
/* {{{ register_interface */
/* You will have to alloc the pce before the call and namespace_entry must
be valid */
void register_interface(zend_class_entry *pce, zend_namespace
*namespace_entry, char *class_name TSRMLS_DC)
{
pce-type = ZEND_USER_CLASS;
pce-name_length = strlen(class_name);
pce-name = class_name;
pce-parent = NULL;
pce-num_interfaces = 0;
zend_initialize_class_data(pce, 1 TSRMLS_CC);
/* entries changed by initialize */
pce-ce_flags = ZEND_ACC_ABSTRACT | ZEND_ACC_INTERFACE;
pce-ns = namespace_entry;
zend_hash_add(namespace_entry-class_table, class_name,
pce-name_length+1, pce, sizeof(zend_class_entry *), NULL);
}
/* }}} */
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces
At 03:36 09.03.2003, l0t3k wrote: You, sir, are a gentleman and a scholar ;-) i assume that given your familiarity and recent work with ZE2 that this will be merged ? i can live with a locally patched tree for the moment.. No plans on that yet. For now i am using this functionality for a new extension. i assume i ZE2 cleans all this up for me after MSHUTDOWN (i.e. i dont need to worry about doing so manually)? Currently i have many memleaks at shutdown but do not investigate them because i remeber i have heard of problems there and i am shure it would work. regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] iterating objects with interfaces
Hi, i've just done the first step for a new extension which shall make use of interfaces newly implemented in ZE2. currently the extension implements the namespace spl and the interfaces spl_foreach, spl_forward and spl_key. A class that implements these can be used in a foreach() call. This work without even modifying the engine, i simply hook on the necessary calls. References: The documentation of the interfaces and their usage: http://marcus-boerger.de/php/ext/spl/spl.phps The extension code: http://marcus-boerger.de/php/ext/spl/spl-20030309.tar.bz2 And a testfile to demonstrate it works (beside shutdown): http://marcus-boerger.de/php/ext/spl/tests/foreach.phpt Of corse i am curious about other meanings :-) Otherwise i wouldn`t have posted here, would i? regards marcus -- -- Marcus Börger - Looking for all sorts of freelance work - just ask... Did i help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0 -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Sqlite-php module in php-distribution?
At 10:32 07.03.2003, Björn Kalkbrenner wrote: Sqlite is something like dbm with sql92 language and more. I would much more appreciate a new submodule for the dbx module! regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Help: Sablotron and Shift-jis
At 00:40 07.03.2003, Michel Sahyoun wrote: Does anyone have an example of using XSLT with Sablotron to transform and XML document containing Shift-jis encoded characters? I keep getting the following error message: Illegal Character for Encoding 'Shift-jis' You could try: SJIS and Shift_JIS keep letter cases. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: INI defaults for CLI
At 02:45 03.03.2003, [EMAIL PROTECTED] wrote:
Nothing attached...
Try again...
Index: main/SAPI.h
===
RCS file: /repository/php4/main/SAPI.h,v
retrieving revision 1.100
diff -u -r1.100 SAPI.h
--- main/SAPI.h 20 Feb 2003 22:21:48 - 1.100
+++ main/SAPI.h 3 Mar 2003 00:13:21 -
@@ -241,6 +241,8 @@
int (*get_target_gid)(gid_t * TSRMLS_DC);
unsigned int (*input_filter)(int arg, char *var, char **val, unsigned int
val_len TSRMLS_DC);
+
+ void (*ini_defaults)(HashTable *configuration_hash);
};
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.117
diff -u -r1.117 php_ini.c
--- main/php_ini.c 28 Feb 2003 20:48:38 - 1.117
+++ main/php_ini.c 3 Mar 2003 00:13:21 -
@@ -276,6 +276,10 @@
return FAILURE;
}
+ if (sapi_module.ini_defaults) {
+ sapi_module.ini_defaults(configuration_hash);
+ }
+
zend_llist_init(extension_lists.engine, sizeof(char *), (llist_dtor_func_t)
free_estring, 1);
zend_llist_init(extension_lists.functions, sizeof(zval), (llist_dtor_func_t)
ZVAL_DESTRUCTOR, 1);
zend_llist_init(scanned_ini_list, sizeof(char *), (llist_dtor_func_t)
free_estring, 1);
Index: sapi/cli/php_cli.c
===
RCS file: /repository/php4/sapi/cli/php_cli.c,v
retrieving revision 1.71
diff -u -r1.71 php_cli.c
--- sapi/cli/php_cli.c 16 Feb 2003 01:23:11 - 1.71
+++ sapi/cli/php_cli.c 3 Mar 2003 00:13:21 -
@@ -277,6 +277,29 @@
}
+/* {{{ sapi_cli_ini_defaults */
+
+#define INI_DEFAULT(name,name_len,value)\
+ ZVAL_STRING(tmp, value, 0);\
+ zend_hash_update(configuration_hash, name, name_len, tmp, sizeof(zval),
(void**)entry);\
+ Z_STRVAL_P(entry) = zend_strndup(Z_STRVAL_P(entry), Z_STRLEN_P(entry))
+
+static void sapi_cli_ini_defaults(HashTable *configuration_hash)
+{
+ zval *tmp, *entry;
+
+ MAKE_STD_ZVAL(tmp);
+
+ INI_DEFAULT(register_argc_argv, 19, 1);
+/* INI_DEFAULT(register_long_arrays, 21, 1);*/
+ INI_DEFAULT(html_errors, 12, 1);
+ INI_DEFAULT(implicit_flush, 15, 1);
+ INI_DEFAULT(max_execution_time, 19, 0);
+
+ FREE_ZVAL(tmp);
+}
+/* }}} */
+
/* {{{ sapi_module_struct cli_sapi_module
*/
static sapi_module_struct cli_sapi_module = {
@@ -526,6 +549,7 @@
tsrm_startup(1, 1, 0, NULL);
#endif
+ cli_sapi_module.ini_defaults = sapi_cli_ini_defaults;
sapi_startup(cli_sapi_module);
#ifdef PHP_WIN32
@@ -576,10 +600,6 @@
/* Set some CLI defaults */
SG(options) |= SAPI_OPTION_NO_CHDIR;
- zend_alter_ini_entry(register_argc_argv, 19, 1, 1, PHP_INI_SYSTEM,
PHP_INI_STAGE_ACTIVATE);
- zend_alter_ini_entry(html_errors, 12, 0, 1, PHP_INI_SYSTEM,
PHP_INI_STAGE_ACTIVATE);
- zend_alter_ini_entry(implicit_flush, 15, 1, 1, PHP_INI_SYSTEM,
PHP_INI_STAGE_ACTIVATE);
- zend_alter_ini_entry(max_execution_time, 19, 0, 1, PHP_INI_SYSTEM,
PHP_INI_STAGE_ACTIVATE);
zend_uv.html_errors = 0; /* tell the engine we're in non-html mode */
--
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.ini-dist php.ini-recommended /ext/filepro filepro.c /ext/session session.c /main main.c php_globals.h php_variables.c php_variables.h
At 16:38 02.03.2003, Zeev Suraski wrote: Looks like for some reason, CLI registers $argv and $argc globals even though register_globals is off. Why's that? CLI overwrites register_argc_argv: zend_alter_ini_entry(register_argc_argv, 19, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); If i add register_long_arrays like this zend_alter_ini_entry(register_long_arrays, 21, 1, 1, PHP_INI_SYSTEM, PHP_INI_STAGE_ACTIVATE); all is fine. So the question is if we want $argc/$argv without register_long_arrays !? Anyway, if we want to keep this behavior, we probably should change the place where argv/argc are registered, and put it somewhere global, outside where _SERVER is created. Ifwhen _SERVER is created, it will attempt to copy them. Thoughts? That leads to $_COMMAND or $_CMD. To answer my question above: The above variable should be independant and its ini setting register_argc_argv should be independant from register_long_arrays. marcus -- 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.ini-dist php.ini-recommended /ext/filepro filepro.c /ext/session session.c /main main.c php_globals.h php_variables.c php_variables.h
Anyway, if we want to keep this behavior, we probably should change the place where argv/argc are registered, and put it somewhere global, outside where _SERVER is created. Ifwhen _SERVER is created, it will attempt to copy them. Thoughts? That leads to $_COMMAND or $_CMD. Didn't quite understand what you mean by that... I meant to have $_COMMAND['argc'] and $_COMMAND['argv'] and $_COMMAND['commandline'] as a place to store argc/argv and _SERVER only having a copy of them for BC. marcus -- 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.ini-dist php.ini-recommended /ext/filepro filepro.c /ext/session session.c /main main.c php_globals.h php_variables.c php_variables.h
At 18:49 02.03.2003, Derick Rethans wrote: On Sun, 2 Mar 2003, Zeev Suraski wrote: Looks like for some reason, CLI registers $argv and $argc globals even though register_globals is off. Why's that? Anyway, if we want to keep this behavior, we probably should change the place where argv/argc are registered, and put it somewhere global, outside where _SERVER is created. Ifwhen _SERVER is created, it will attempt to copy them. Thoughts? IMO they should not be registered when register_globals is off. That is why the test reads $_SERVER['argc'] and $_SERVER['argv'] when register globals is off. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] INI defaults for CLI
Hi, the current implementation does not allow to overwrite the hard coded INI defaults of CLI (See ToDo). The attached patch does allow it. However i am not sure if we want this. I mean the problem is that a user might copy/use his normal php.ini file and overwrite the cli defaults and gets unexpected behavior and then writes a bug... regards marcus -- -- Marcus Börger - Looking for all sorts of freelance work - just ask... Did i help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0 -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tie'ing variables
At 18:11 01.03.2003, Derick Rethans wrote: On Sat, 1 Mar 2003, Sterling Hughes wrote: 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. Why not just populate them when you need them? IE, if you access $_GET['foo'] it processes the GET data until it has processed upto foo in the data itself(and of course it adds the other ones that are before 'foo' in the GET data to the array too). With this you never process more data then you really need... And for a quick start it would be enogh to simply initialize these vars upon first access. If we can do this the rest might be easy - devide and conquer! marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ZE2 constructors
Hi Zeev,
according to the plans the following test file should PASS:
--TEST--
The new constructor/destructor is called
--SKIPIF--
?php if (version_compare(zend_version(), '2.0.0-dev', '')) die('skip
ZendEngine 2 needed'); ?
--FILE--
?php
class early {
function early() {
echo early::early\n;
}
function __construct() {
echo early::__construct\n;
}
function __destruct() {
echo early::__destruct\n;
}
}
class late {
function __construct() {
echo late::__construct\n;
}
function late() {
echo late::late\n;
}
function __destruct() {
echo late::__destruct\n;
}
}
$t = new early();
$t-early();
unset($t);
$t = new late();
$t-late();
//unset($t); delay to end of script
echo Done\n;
?
--EXPECTF--
early::__construct
early::early
early::__destruct
late::__construct
late::late
Done
late::__destruct
#
However it fails and this patch is needed which also fixees the last final
problem
mentioned already:
#
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.375
diff -u -r1.375 zend_compile.c
--- Zend/zend_compile.c 25 Feb 2003 10:03:26 - 1.375
+++ Zend/zend_compile.c 28 Feb 2003 19:14:52 -
@@ -916,6 +916,9 @@
((current_access_type-u.constant.value.lval
ZEND_ACC_PPP_MASK) != (new_modifier-u.constant.value.lval
ZEND_ACC_PPP_MASK))) {
zend_error(E_COMPILE_ERROR, Multiple access type
modifiers are not allowed);
}
+ if (((current_access_type-u.constant.value.lval |
new_modifier-u.constant.value.lval) (ZEND_ACC_ABSTRACT |
ZEND_ACC_FINAL)) == (ZEND_ACC_ABSTRACT | ZEND_ACC_FINAL)) {
+ zend_error(E_COMPILE_ERROR, Cannot use the final modifier
on an abstract class member);
+ }
if (((current_access_type-u.constant.value.lval |
new_modifier-u.constant.value.lval) (ZEND_ACC_PRIVATE | ZEND_ACC_FINAL))
== (ZEND_ACC_PRIVATE | ZEND_ACC_FINAL)) {
zend_error(E_COMPILE_ERROR, Cannot use the final modifier
on a private class member);
}
@@ -974,7 +977,7 @@
fn_flags |= ZEND_ACC_PUBLIC;
}
- if ((short_class_name_length == name_len)
(!memcmp(short_class_name, name, name_len))) {
+ if ((short_class_name_length == name_len)
(!memcmp(short_class_name, name, name_len))
!CG(active_class_entry)-constructor) {
CG(active_class_entry)-constructor =
(zend_function *) CG(active_op_array);
} else if ((function_name-u.constant.value.str.len ==
sizeof(ZEND_CONSTRUCTOR_FUNC_NAME)-1)
(!memcmp(function_name-u.constant.value.str.val,
ZEND_CONSTRUCTOR_FUNC_NAME, sizeof(ZEND_CONSTRUCTOR_FUNC_NAME {
CG(active_class_entry)-constructor =
(zend_function *) CG(active_op_array);
#
regards
marcus
--
--
Marcus Börger - Looking for all sorts of freelance work - just ask...
Did i help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0
--
Re: [PHP-DEV] Re: RFC: dba/inifile native interface
At 12:02 24.02.2003, Sascha Schumann wrote: I implemented the native interface - inifile_*() functions - in order to be able to work with group and name instead of the single key format that is necessary using the dba interface. Sounds to me like another issue which could have been easily solved by using a thin PHP layer. Yeah - and i also thought about accepting an array as a key in case of handler inifile. I think this would be much better for users and for c code maintainance, what do you think? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC: dba/inifile native interface
At 12:11 23.02.2003, Sascha Schumann wrote: On Sun, 23 Feb 2003, Marcus Börger wrote: After fixing hopefully last problems in the inifile handler i made up a patch which introduces a native interface to the inifile handler. I did this because the [group]name key format is not intuitive. Care to explain what it does? Does it feed all entries to the PHP INI system or is this is a custom layer wrapping the DBA API for storage of application settings? - Sascha You can use it to work with any ini file and has nothing to do with the PHP INI system. I implemented the native interface - inifile_*() functions - in order to be able to work with group and name instead of the single key format that is necessary using the dba interface. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why parent::construct not called?
At 16:46 23.02.2003, michel 'ziobudda' morelli wrote:
Hi, why if I have
class B extends A {
}
the only way to call in automatic the A::__construct() is to not write
the B::__construct() ?
Ok, this is the design of PHP. But why ?
You can do the following:
class base {
function __construct() {
echo base::__construct()\n;
}
function __destruct() {
echo base::__destruct()\n;
}
}
class derived extends base {
function __construct() {
parent::__construct();
echo derived::__construct()\n;
}
function __destruct() {
parent::__destruct();
echo derived::__destruct()\n;
}
}
See:
http://marcus-boerger.de/php/ext/ze2/ctor_dtor_inheritance.phpt.txt
regards
marcus
--
--
Marcus Börger - Looking for all sorts of freelance work - just ask...
Did i help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0
--
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Performance degradation
So, obviously these opens don't really affect the module version since they only happen on startup, but they still don't seem right. I understand ./php-cgi.ini, but .//php-cgi.ini and .//php.ini? Looks like a missing check there. I just recognized these yesturday, too and was thinking the same. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why parent::construct not called?
At 18:02 23.02.2003, michel 'ziobudda' morelli wrote:
Il dom, 2003-02-23 alle 17:32, Marcus Börger ha scritto:
You can do the following:
class derived extends base {
function __construct() {
parent::__construct();
echo derived::__construct()\n;
}
I know know.
What I want to know is why the base::__construct() is called (in
automatic) only when derived::__constuct() is missing.
I think that or the base::__construct() is always in automatic called or
it is never called (always in automatic).
In ZE2 each class has a constructor. That constructor can be overwritten
by writing a method named __construct. So far so good. Unlike other
languages, C++ for one, PHP does not call any inherited constructors
automatically, C++ calls the default constructor if not set explicitly. But
PHP inherits the constructor if it is not redeclared/overwritten. Therfor
if the base has a constructor and the derived has not the inherited (the
one from base) is called.
regards
marcus
--
--
Marcus Börger - Looking for all sorts of freelance work - just ask...
Did i help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0
--
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why parent::construct not called?
At 18:29 23.02.2003, Timm Friebe wrote: Well, because there might be situations in which I'd like to call the parent's constructor before my code in __construct, sometimes after it and in some situations, not call it at all. I hope you will never avoid initialising the base class or just call the base constructor after anything else is done in the dericed constructor. The problem is that when you so the behavior of the base class members (functions and properties) is not predictable. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/dba config.m4 dba.c dba_inifile.c php_inifile.h /ext/dba/libinifile .cvsignore inifile.c inifile.h /ext/dba/tests dba_inifile.phpt
At 18:20 22.02.2003, Marcus Boerger wrote: helly Sat Feb 22 12:20:06 2003 EDT Log: Added dba handler inifiles to support ini files. (Marcus) If someone wants to test this stuff: The layout of the inifile is: [ group ] name ws* = ws* value ws* The dba keyformat to use is: [ [ group ] ] [ name ] For example: dba_insert([Testgroup]Testvalue, Value, $f) will insert(append) Testvalue with value Value to group Testgroup. dba_delete([Testgroup]Testvalue, $f) will remove the Testvalue from the group Testgroup. dba_delete([Testgroup], $f) will remove the complete group Testgroup. Lines before any group line are possible, too. These are identified by the group [] for now. Maybe i will change this to . Some work is still to be done but in general it works pretty nice here. regards marcus -- -- Marcus Börger - Looking for all sorts of freelance work - just ask... Did i help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0 -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: dba/inifile native interface
After fixing hopefully last problems in the inifile handler i made up a patch which introduces a native interface to the inifile handler. I did this because the [group]name key format is not intuitive. The patch introduces following (self speaking) new functions: int inifile_open(string path, string mode) string|false inifile_get(int inifile [, string group], string name) bool inifile_set(int inifile [, string group], string name, mixed value) bool inifile_add(int inifile [, string group], string name, mixed value) bool inifile_del(int inifile [, string group], string name) and inifile_close() beeing an alias to dba_close() this interface is not meant to have first/nextkey but that would be easy to add if someone wants it. http://marcus-boerger.de/php/ext/dba_inifile.diff.txt regards marcus -- -- Marcus Börger - Looking for all sorts of freelance work - just ask... Did i help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0 -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/dba config.m4 dba.c dba_inifile.c php_inifile.h /ext/dba/libinifile .cvsignore inifile.c inifile.h /ext/dba/tests dba_inifile.phpt
At 03:49 23.02.2003, Jani Taskinen wrote: I kinda missed the point of this thing..any real life examples..? :) The [group]name format is only to be able to use dba for ini files. The trick is a keyname cannot start with [, thats all. However i just introduced the native interface, see: http://marcus-boerger.de/php/ext/dba_inifile.diff.txt Having this you can play around using the php.ini file for example :-) marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Jumadi
At 08:04 21.02.2003, Wojtek Meler wrote: On Thu, Feb 20, 2003 at 06:21:27PM +0100, Sebastian Bergmann wrote: Jani Taskinen wrote: Just make this one moderated. (but allow anyone with CVS access to post freely :) That sounds like a very good idea. great idea, that would stop this annoying CVS account request messages ;) Wojtek I have brought up the followong idea before but noone actually did something about my or other ideas. Why not simply have messages from non registered users reply with a mail repeating the list purpose again (php-dev for development of and the general list for use with php) and letting the user decide by click or replay to which it is to send. However the above automoderation would be even better if the list itself was moderated regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] MFH policy
At 17:38 19.02.2003, Marc Boeren wrote: Hi, What is the official MFH policy? Are all bugfixes MFH-ed? Normally, yes. Except when we're close to release (which we are not right now). How does this work? Add -r PHP_4_3 to the mfh-commit? Cheerio, Marc. If you check out with the PHP_4_3 tag this is sticky - so every commit goes to that branch. However you should use the other branch for the new apache sapi: PHP_4 So simply check out with that tag, apply your changes, compile, *test* and commit. regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CLI long options
Hi, the patch below allows long option names such as --version and --help what eases the use of php especially when used on the command line. And it fixes the problem with duplicate error messages if arguments to command line are erroneous. http://marcus-boerger/php/ext/cli-getopt.diff.txt -- -- Marcus Börger - Looking for all sorts of freelance work - just ask... Did i help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0 -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI long options
At 18:31 15.02.2003, Jani Taskinen wrote: Erm..that url doesn't look quite ok..? :) --Jani YES - It should have been: http://marcus-boerger.de/php/ext/cli-getopt.diff.txt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CLI long options
At 18:56 15.02.2003, Derick Rethans wrote: On Sat, 15 Feb 2003, Jani Taskinen wrote: On Sun, 16 Feb 2003, Moriyoshi Koizumi wrote: +1 from me if you are sure it doesn't break BC. +1 for MFH even if it doesn't break BC. :) +1 for this, but -1 for MFH, because Jani wants to break BC Derick That was my understanding, too. Anyhow i want to commit that first to HEAD and keep MFH as an option after option names are accepted. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build no longer working
Ensure that m4 --version actually outputs 1.4 and not 1.4o. Some rpms are mislabeled in that area. Otherwise, the only problem source comes from having a polluted installation where multiple autoconf/libtool versions are sprinkled through the whole system. Thanks for the help :-) The problem was that the libtool sources contained a file libtool.m4 of zero bytes in size. After adding a correct file to the sorce directory and building everything again it works now: Thanks to Jani Sascha regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why i believe we need final
At 22:05 23.01.2003, Marcus Börger wrote: The current OO implementation ( ... bla ... ) final ( ... bla ... ) I just updated the patch and it is getting a bit smaller due to latest engine changes. I also moved the check code from zend_language_parser.y into zend_compile.c (as suggested by...i think it was andi). http://marcus-boerger.de/php/ext/ze2/ze2-final-30214.diff.txt regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] build no longer working
I updated all m4,autoconf libtool AND now i can no longer build php Anybody help? using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.54 (ok) buildconf: Your version of autoconf likely contains buggy cache code. Running cvsclean for you. To avoid this, install autoconf-2.13 and automake-1.5. buildconf: automake version 1.5 (ok) buildconf: libtool version 1.4.3 (ok) rebuilding configure configure.in:830: warning: AC_PROG_LIBTOOL is m4_require'd but is not m4_defun'd configure.in:143: error: possibly undefined macro: AC_MSG_RESULT If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:292: error: possibly undefined macro: AC_DEFINE configure.in:1064: error: possibly undefined macro: AC_PROG_LIBTOOL configure:95991: error: possibly undefined macro: _LT_AC_TRY_DLOPEN_SELF rebuilding acconfig.h rebuilding main/php_config.h.in WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. configure.in:830: warning: AC_PROG_LIBTOOL is m4_require'd but is not m4_defun'd -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build no longer working
At 01:57 14.02.2003, Jani Taskinen wrote: On Fri, 14 Feb 2003, Marcus Börger wrote: AC_PROG_LIBTOOL is defined in libtool.m4, which should come from libtool installation. Most likely you've just got mixed up versions in your system. Easiest way to get it working is to remove _all_ the auto* tools and libtool. And compile all from sources. With same prefix.. --Jani Is it possible that i have a problem due to the order of build and install? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main spprintf.c
At 23:44 11.02.2003, Sascha Schumann wrote:
Markus,
here is a patch against the current CVS which
- trims +100 lines of code from spprintf.c
- introduces an overflow detection in STR_TO_DEC
Why then this comment? Did you forgot to remove it.
+/* XXX: Does not handle overflow. */
+#define STR_TO_DEC(str, num) do { \
- eliminates dead code (e.g. assert(foo); if (foo) {..})
- removes unused macros from the original code
- simplifies code (e.g. cc was completely dropped)
- improves run-time performance
The max_len feature is never used in our code base.
Nevertheless, cpu cycles were spent on each string
operation to check the current length against max_len which
is quite inefficient. Thus, I've moved the check to
vspprintf where it is applied only once per call.
- Sascha
Hey cool i just thought about doing that, too. You're really fast
Unfortunatley i haven't yet the time to try it out but it looks good.
Does it have any known problems?
marcus
p.s.: I asked about adding the cli manpage some days ago, can you help?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main spprintf.c
At 23:44 11.02.2003, Sascha Schumann wrote: Markus, here is a patch against the current CVS which If you commit that stuff, you should apply the changes to our snprintf.c, too. regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: uniqid default param
Hi, the current implementation of uniqid set the more entropy default true for CYGWIN and false for the rest. CYGWIN must use more entropy because it does not produce new values after usleep(1) necessarily. However usleep(1) should nowadays be very slow compared to whatever php_combined_lcg() needs to do. Shall more entropy be always true? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: uniqid default param
At 23:08 10.02.2003, Sascha Schumann wrote: No, some users might depend on the return format (think of database entries). That was one of the reasons i only changed it for CYGWIN. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Files Headers
From our files haeders: | available at through the world-wide-web at | Shouldn't the first 'at' be dropped? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: New CLI switches (was [PHP-DEV] Using CLI as a shell)
At 10:28 04.02.2003, Edin Kadribasic wrote:
First simply use php -h but i am also thinking about adding a man
page.
That is a bit too much text for 'php -h'. It should be moved to the
online manual. Adding a man page would be great too.
I wrote already i will do so...but haven't yet the time.
[snip]
find . -name '*.c' -o -name '*.h' | php -B '$l=0;' -R
'$f=count(file($argn)); echo $argn($n)\n;$l+=$f;' -E 'echo
Files: $argi,
Lines: $l\n;'
This appears to be equivelant of:
find . -name '*.c' -o -name '*.h' | php -r 'while (!feof(STDIN)) {
$q=count(file($n=trim(fgets(STDIN; echo $n($q)\n; $l+=$q;
$f++; } echo Files $f, Lines: $l\n;'
Am I correct in this assumption? If yes, could please try to point
out what are the advantages of -B -R -E and -F over using just -r?
Yes it is the same result. I never said you cannot do it otherwise.
The reason i implemented the switches is that it makes thinks easier.
And sometimes making things easier for users is better than knowing
as a developer that there is a solution.
regards
marcus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Using CLI as a shell
After adding -B, -F, -R and -E which will hopefully liked by the rest of development team so that the stuff need not to be removed. I (or better a friend of mine) had another idea. Here comes: Why not use CLI as a shell? I'd say adding a command line switch say -S which parses and executes every line that is entered. What do you think? regards marcus -- --- mailto:[EMAIL PROTECTED] -- We are animals among animals, all children of matter, save that we are the more disarmed. But since, unlike animals, we know that we must die, let us prepare for that moment by enjoying the life that has been given us by chance and for chance. Umberto Eco, The island of the day before - http://marcus-boerger.de - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Using CLI as a shell
At 19:37 03.02.2003, Derick Rethans wrote: On Mon, 3 Feb 2003, Marcus [iso-8859-1] Börger wrote: After adding -B, -F, -R and -E which will hopefully liked by the rest of development team so that the stuff need not to be removed. Perhaps start by explaining what they do? First simply use php -h but i am also thinking about adding a man page. Ok an example even though i do not know if it is a good one because you may find better solutions but it shows how it works. Type the following shell command at the php source directory: find . -name '*.c' -o -name '*.h' | php -B '$l=0;' -R '$f=count(file($argn)); echo $argn($n)\n;$l+=$f;' -E 'echo Files: $argi, Lines: $l\n;' This one uses find to search for all .c and .h files in the current directory. At startup it initialises $l to zero. For every line reported by find (every file) the statement in -R gets executed. That statement counts the lines in the current file and shows its name and linecount. After all files are processed the statement in -E show the result (line count of all files). I hope the above example points out the idea. I (or better a friend of mine) had another idea. Here comes: Why not use CLI as a shell? I'd say adding a command line switch say -S which parses and executes every line that is entered. What do you think? PHP is not a shell, and we have interactive mode for that already. I really don't see the use for this. Just an idea to think about There is a difference between interactive mode and this idea. The idea was to execute every single line. So if you type 'echo Hello\n; and press enter Hello should be displayed. regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problems with zand_API.c
I have problems with ze2 right now. Function zend_parse_method_parameters uses void * in .h file and zval ** in .c file. Since i have no karma there somebody else must fix this. gcc ... /usr/src/php4-HEAD/Zend/zend_API.c -o Zend/zend_API.o echo Zend/zend_API.lo /usr/src/php4-HEAD/Zend/zend_API.c:567: conflicting types for `zend_parse_method_parameters' /usr/src/php4-HEAD/Zend/zend_API.h:126: previous declaration of `zend_parse_method_parameters' /usr/src/php4-HEAD/Zend/zend_API.c: In function `zend_parse_method_parameters': /usr/src/php4-HEAD/Zend/zend_API.c:597: warning: second parameter of `va_start' not last named argument /usr/src/php4-HEAD/Zend/zend_API.c: In function `zend_parse_method_parameters_ex': /usr/src/php4-HEAD/Zend/zend_API.c:642: warning: second parameter of `va_start' not last named argument -- -- Marcus Börger - Looking for all sorts of freelance work - just ask... Did i help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0 --
[PHP-DEV] Another bugs.php.net question
The assigne bugs reminder mail does not contain links to the bug reports as normal mail from there do. Wouldn't it be nice if one could simply click on the bugs? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question on bug list
At 10:24 31.01.2003, Thomas Seifert wrote: On Fri, 31 Jan 2003 02:49:01 + [EMAIL PROTECTED] (Daniel Lorch) wrote: hi, Wouldn't it be nice if one could attach himself to a bug and receive an email on every new message to that bug? And then how am i informed about new bugs? Is there a mailing list for that? Currently i read the bug-summary-list.. [EMAIL PROTECTED] Empty mail to [EMAIL PROTECTED] should do it. This will send you EVERY message about any bug. What Marcus meant was to subscribe to ONE bug I think. I had two questions: One to assign to all NEW messages and one feature request to assign to selective bugs...I wanted to avoid reading all messages on any bug. Thats overkill... marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question on bug list
At 11:37 31.01.2003, Jani Taskinen wrote: On Fri, 31 Jan 2003, Marcus Börger wrote: I had two questions: One to assign to all NEW messages and one feature request to assign to selective bugs...I wanted to avoid reading all messages on any bug. Thats overkill... Get a mail client that can handle threading.. Yes and no - my idea was to make the handling a bit more comfortable. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: str_ireplace vs. stri_replace
FWIW: Given this mess, and the fact that any php-coded stri_replace can be overloaded, I think a new function is better. Also - it's in sync with the other stri* functions. Either change all with a case-insensativity paramenter, or keep the namingconventions that 'plague' these functions. Aggreed! The additional parameter solution is a pure developer friendly solution. The separate function is a user friendly solution. If we would like to make all happy then add the case-insensativity parameter to all str_ (not stri_) functions and add the additional function. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why i believe we need final
At 09:46 29.01.2003, Stanislav Malyshev wrote: MB Sure it cannot because insert cannot. The problem and the error you did MB above is that you split an operation into two. Your real operation is MB insert_with_password and that is different from insert. Again insert is an That's the whole point of OO - to allow overloading the same operation, so even classes that do not know about implementation details could use it. MB as a member and not as a base class. Maybe it is now a good thing to MB have a generalised container interface and declare insert in the container MB implementations final. Highly specialised containers would then inheritd I do not see why should container interface be final. MB A class that is derived from a concrete container may in some container MB implementations have final functions. For example whatever inherits a fifo Still have no explanation why anyone would need it. Just to disallow overriding because we can? I see no added value in that. MB If you have another insert implementation in a class than you MB missused inheritance. If the operation is different than your derived MB class is no for example no longer a fifo. Instead it uses a fifo. Implementation can be different and still be a fifo. That depends on overriding implementation. Again, I still have yet to see any example where the proposed 'final' plays substantial role and not just is there because 'maybe someone might want to use it'. Hey YOU are the example you are looking for. Think i earn money by designing class and data models and in that i know that i cannot modell the world and as a result i create modells which are no all-in-one devices suitable for everything (german: eier-legende-wollmilchsau) and even capable of beeing missused for that by inheritance. And at those points where i know of the simplications and restrictions and compromises i made i *may* decide a function to be final. If you want real life examples (and surely it seems you will never trust me) get yourself a book from scott meyers (going to my bookshelf) effective c++ and more effective C++ and read something about programmingand remeber C++ has no final it only has virtual and non virtual (and it also has abstract with default implementation (the other discussion where i said is possible and valuable to think about)). If you don't like C++ get you a theory book or any good book about another language(written by someone who has understood OOP). Sorry but i guess the discussion does not make any more sense. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Mandatory File Locking in PHP?
At 18:07 29.01.2003, George Schlossnagle wrote: Aside from this being on the wrong list (this should go to php-general), it's worth noting that mandatory locking support is pretty inconsistently implemented across most OSs. Why wrong list? I guess Ananth needs it somewhere forthe netware port of php... In dba extension i use that mechanism to hinder multiple php instances to update the same database file. Wez and me will move that code or whatever solution to the streams stuff. Inside dba i use flock compatibility routines. If you can show us how to do that on Netware or if you can use those mechanisms then both (streams and netware port) would benefit. marcus -- 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()
At 00:47 30.01.2003, Edin Kadribasic wrote: I don't even see the speed difference as an issue as much as (A) simplicity for the user who hasn't figured out regex yet, (B) consistency (we have 'i' versions of most other string functions, why not this one?) +1 for the reasons stated above. +1 (It is not so important if we know how to emulate this one. It's about our usesers..we should not leave the focus on the users.) marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Mandatory File Locking in PHP?
The real question is why you need mandatory locks and not advisory locks. If everyone is playing on the same team, advisory locks should provide all the semantics you need (and are very portable). Mandatory locks (on linux at least) require not only special mount options, but special perms to the file (g-x, g+s, I believe). That seems like a lot to require inside an extension. The dba solution so far is based on flock() and where not appropriate use fctnl(). I tried to have the lock stuff working on as many systems as possible. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Compiling php4activescript
Performing Custom Build Step on .\zend_language_parser.y 'bison' is not recognized as an internal or external command, operable program or batch file. Error executing c:\winnt\system32\cmd.exe. Obviously your ide tells you that you are bissin bison... Try searching for bison + win32 on the net. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why i believe we need final
At 15:52 27.01.2003, Stanislav Malyshev wrote:
MB Consider you defined a container (list, vector what ever) and want
MB to derive from it. Then there is *really*no* need to override methods
MB like insert or remove. You may want to have additional things like
MB insert_if or whatever. But for the container part insert must stay as
MB it is and that requires static binding.
Well, if there is *really no need*, why one would override it? Obviously,
if one overrides it, there's a need? I don't see why container writer
should care if anyone overrides the method. Could you bring a real example
where one needs non-overridable methods? Only thing I can think of are
various Java security classes (like class loaders, etc.) which if you
succeed to override various checking hooks may lead to trouble. But we
don't have such things in PHP...
For example, what if I want to create secure container, where insert can
be done only after you called password() function for the container with
right password? Your 'finalized' container would not allow me to do it.
Sure it cannot because insert cannot. The problem and the error you did
above is that you split an operation into two. Your real operation is
insert_with_password and that is different from insert. Again insert is an
invariant function for the container. But now you should have a container
as a member and not as a base class. Maybe it is now a good thing to
have a generalised container interface and declare insert in the container
implementations final. Highly specialised containers would then inheritd
the interface and use a member of a less specialised container:
class container_interface {
abstract function insert();
abstract function delete();
abstract function get();
}
class fifo extends container_interface {
final function insert($elem) { ... }
final function delete($elem) { ... }
final function get() { ... return ... }
}
class secure_container extends container_interface {
private $m_fifo;
function __construct()
{
$this-m_fifo = new fifo();
}
function insert($elem, $user, $passwd)
{
// check password match or emit error
$m_fifo-insert($elem);
}
...
}
MB And here comes final as it allows to emulate static binding with
MB dynamic binding. If you declare a function final it is invariant
MB against inhertance starting from that point in the inhertance tree. In
Could you explain what is invariant against inhertance? What should
happen if I define function with the same name in derived class - is this
a compile error?
a) invariant = invariant, the meaning is described in the above and former
mail (- it's about oo programming techniques (oh i remeber i wrote that in
last mail already)). Again invariant against inheritance means that you
have a function that is not to be overloaded since the operation is not
modified by inheritance.
A general container has an abstract insert operation or in full it has an
abstract interface which is outlined by a collection of abstract functions. A
concrete container consists of something that uses the inherited abstract
interface to implement a specific container (list, array, stack, fifo, ...).
A class that is derived from a concrete container may in some container
implementations have final functions. For example whatever inherits a fifo
must insert elements at the top and get elements from the top. And here
it is of no importance what you store in the derived classes.
If you have another insert implementation in a class than you missused
inheritance. If the operation is different than your derived class is no for
example no longer a fifo. Instead it uses a fifo. Back to oo design there
is a very important rule: is a = (public) inheritance differs from has a
= member (or something we do not have in php).
Remeber one of our earlier discussions: I liked information hiding but it
was diclined because it conflicts is a. So in other words you insisted on
pure inheritance. Now i just described one step beyond.
b) What should happen?
- In java you cannot redeclare a final function.
- In C++ a function is an invariant if it is *not* declare virtual. Here
you can
redeclare it at will (but hopefully you know what that means and avoid it).
Since we cannot have non virtual functions and discussing final here i am
(obviously) in favor of the java solution (in real life the above is one of
the few
points i dislike in c++).
regards
marcus
--
--
Marcus Börger - Looking for all sorts of freelance work - just ask...
Did i help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0
--
Re: [PHP-DEV] configure broken
At 06:14 28.01.2003, Sebastian Bergmann wrote: ./configure: line 30289: syntax error near unexpected token `fi' ./configure: line 30289: `fi' Should be fixed by now. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Why i believe we need final
The current OO implementation of ZE2 only allows dynamically binding of methods. That is all functions are inherited like if they were declared virtual in other languages. The thing we do not have is static binding of methods. First one could argue that we do not have a type system and On the other hand there is a need for static binding since it allows us to declare functions that are *invariant* against inheritance. That is especially usefull for things like a standard class library (what ADT might become hopefully) or even your own standard class collection. Consider you defined a container (list, vector what ever) and want to derive from it. Then there is *really*no* need to override methods like insert or remove. You may want to have additional things like insert_if or whatever. But for the container part insert must stay as it is and that requires static binding. And here comes final as it allows to emulate static binding with dynamic binding. If you declare a function final it is invariant against inhertance starting from that point in the inhertance tree. In other words it is even more powerfull than pure static binding and as a side effect it eliminates the problem that someone overrides erm redeclares a static bound function beeing inherited. A patch can be found here: http://marcus-boerger.de/php/ext/ze2/ regards marcus p.s.: It would be nice to reach a consensus here soon because i want to start another extension to the OO model - if you read between the lines you may guess but it'l have to wait... -- -- Marcus Börger - Looking for all sorts of freelance work - just ask... Did i help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0 -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] jpeg2000 in php 4.3
At 10:52 17.01.2003, Adam Wright wrote: Have regenerated the diffs in unified format as well as fixed a minor bug in the JP2 support. I've put together a small page at http://www.j2g.org/php-dev/ It contains the patch, test script and a couple of example images in both raw codestream and JP2 format. thanks again. I have reworked the patch a little bit and commited it to HEAD (what's to become PHP 5.0.0). Please send any further patches only against that version. For the 4.3.1 version i will add the necessary changes for jpc - the rest we may see - part of it is new functionality. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory allocation problems
At 11:38 16.01.2003, Edin Kadribasic wrote: I have a script that allocates a lot of memory (huge associative arrays). The problem is that this scripts bails out with fatal error (emalloc unable to allocate 44 bytes) when I hit the limit of physical ram in the machine. Swap never gets used. The machine has 1 GB of ram and 2 GB of swap space. I suppose you use some windows machine. I remember that all application have only 1GB of RAM for their own until you have a windows server version and that has an appropriate HAL and is configured to have more than 1gig. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] jpeg2000 in php 4.3
At 13:50 16.01.2003, Adam Wright wrote: I've completed a short patch which cleans up the JPEG 2000 raw codestream support (j2c, though I've renamed it jpeg2000 in the file for clarity) in getimagesize. It also adds JP2 support. I've put a context diff of it against 4.3.x-dev from this morning up at... I have just updated my HEAD version and did a few changes and it works very well. Small changes have been made to ext/standard/php_image.h with 99% of the work in ext/standard/image.c. I've tried to apply CODING_STANDARDS, but it's probable I've messed up somewhere so I'm happy to make any changes or regenerate the diffs in other formats. You did good coding and style (but we prefer unified diffs diff -u). If this gets applied, it might be worth adding something like the following to the documentation. It will be but it is to be discussed if it will go into 4.3.1: I'd say yes because the note in the manual. Note that JPEG 2000 and JP2 are capable of having components with differing bit depths. In this case, the value for bits is the highest bit depth encountered. Also, JP2 files can contain multiple JPEG 2000 codestreams. In this case, getimagesize returns the values for the first codestream it encounters in the root of the file. Yes such a note may be useful. Hope it's useful. adamw [EMAIL PROTECTED] PS - I looked around but couldn't find any patch submission guidelines. Is there a page people should read first? As said above diff -u is prefered. regards thanks marcus by the way:could you send me a 1 x 1 jp2 file, because i am not able to produce one my self? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tru64 make test with --enable-all
At 18:54 13.01.2003, you wrote: Hi! I can't include the results inline because they're to large. These are both compiling results and test results. So you can look at it here: http://novell.stoldgods.nu/~magnus/test_result.txt Ok i thought you overlooked the possibility to send the results by the script, but i did not work and produces an unaligned access as all the the other tests and sending mail also failed result Please enter your email address. (Your address will be mangled so that it will not go out on any mailinglist in plain text): [EMAIL PROTECTED] result Unaligned access pid=241268 php va=0x14007585c pc=0x12020d4e8 ra=0x12020d4dc inst=0xb401 result Warning: fsockopen() [http://www.php.net/function.fsockopen]: php_network_getaddresses: getaddrinfo failed: A non-recoverable error occured. in /php/php4/run-tests.php on line 462 result Warning: fsockopen() [http://www.php.net/function.fsockopen]: unable to connect to qa.php.net:80 in /php/php4/run-tests.php on line 462 Hm - is it possible for you to track down this unaligned access. I guess it is a problem with 32/64 bit types but the message is not helpful... marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function imagecreatefromjpeg pb
At 07:21 13.01.2003, WarmUp wrote: Hi, do someone can help me with the use of function imagecreatefromjpeg. Because, when i use it, PHP retrieve this error message : Warning: imagecreatefromjpeg: 'toto.jpg' is not a valid JPEG file in toto.php on line 10 could you send me one of your images? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] function imagecreatefromjpeg pb
At 22:59 13.01.2003, oversky wrote: Hi, here they are... i tested this with several types of pictures taken from internet or generated by photoshop, etc... thanks for your help... - Original Message - From: Marcus Börger [EMAIL PROTECTED] To: WarmUp [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 13, 2003 9:35 PM Subject: Re: [PHP-DEV] function imagecreatefromjpeg pb At 07:21 13.01.2003, WarmUp wrote: Hi, do someone can help me with the use of function imagecreatefromjpeg. Because, when i use it, PHP retrieve this error message : Warning: imagecreatefromjpeg: 'toto.jpg' is not a valid JPEG file in toto.php on line 10 could you send me one of your images? marcus Since your images are correct and the functions getimagesize/exif_read_data work fine with both php 4.3 and head for WinXP/Linux/Cygwin i suppose you contact the user list: [EMAIL PROTECTED] regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/overload .cvsignore CREDITS README config.m4 overload.c overload.dsp php_overload.h
At 10:45 11.01.2003, Sebastian Bergmann wrote: Marcus Börger wrote: yes - but this makes building HEAD + ZE1 + overload impossible Well, ZE1 should only be build with the PHP_4_3 branch now. Otherwise we won't get the momentum needed to push PHP 5 and ZendEngine 2 development. Then we should make HEAD builds against ZE1 impossible by configure. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] xml xinclude
At 15:35 08.01.2003, Pawel wrote: Hello, libxml (tested with 2.4.30) creates these additional nodes when parsing documents with xincludes: XML_XINCLUDE_START and XML_XINCLUDE_END. PHP has no support for these nodes and chokes when it encounters them, therefore walking the xml tree after issuing $doc-xinclude() fails. The only work-around I could come up with is: $doc = domxml_open_mem($doc-dump_mem()) which gets rid of the XML_XINCLUDE_START and XML_XINCLUDE_END nodes The problem comes up when you have entities in the xincluded document, which don't get substituted. This short patch substitutes any entity references you might have in the xincluded document. Why not check for XML_XINCLUDE_START and XML_XINCLUDE_END or the libxml version in configure and make the necessary changes to the .c file? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Should I fix this?
At 04:20 08.01.2003, Rickard Andersson wrote: BTW. I'm kinda new to contributing to large projects as this one. Should I checkout the latest CVS and patch agains that or should I use some other base for my alterations? Please check out HEAD (latest) and send a unified diff (diff -u) to this list. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Should I fix this?
At 01:43 07.01.2003, Rickard Andersson wrote: getimagesize() blindly trusts the width and height specified in the header of gifs. You can just hexedit the file and set the width and height to any value and getimagesize() will believe that is the true size of the image. Even worse - Internet Explorer ignores the width and height in the header and thus it is possible to, for instance, upload a much larger image in an upload form that uses getimagesize() than what is allowed. I believe getimagesize() should just skip the header and read the size from the beginning of the Image Block. The advantage is that this would retrieve the correct size even for gifs with multiple images. On the other hand the disadvantage is speed loss. I'd be glad to write a patch for image.c (function php_handle_gif()), but I though I should ask you guys first. I wouldn't want to do it in vain. As it is now I've got PHP code that checks this for me to prevent malicious users from uploading huge avatars in my forum software. Your scenario described above seems like a reason to accept the the speed loss. So send an unified patch and we will have a look on it. regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Should I fix this?
Marcus: could you specify the speed loss? If it's noticeable I would rather suggest to either introduce a new function or another parameter to getimagesize(), no matter what the default is (e.g. let getimagesize() get the real size and introduce something like getimagesize_fast()) or the other way around. Not before seeing the solution... I once thought about it, too. But i skipped the idea because i guessed i had to decompress the first block. At the time i was thinking about it we had the philosophy to exclude all patend related code... marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] building ext/dba on win32
At 21:06 07.01.2003, Dave Viner wrote: well.. from the win32build.zip file, I find in db.h this line: #define DB_VERSION_STRING Sleepycat Software: DB 2.4.14: (6/2/98) DB version 2 does not have the functions causing the error. And you cannot link DB 2 with --with-db3=... I suspect that this is the problem. I downloaded the latest berkeley db from sleepycat, but I still get an error. It is now version 4, so this might be the problem... I don't know what has changed from 3-4. But the error I now get is: D:\php\php4\ext\dba\dba_db3.c(90) : error C2198: 'function through pointer' : too few actual parameters You have to reconfigure. When you get this error you are linking DB 4.1.x against php-HEAD configured with --with-db3=... instead use --with-db4=... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Is exif_tagname() useful?
At 19:24 07.01.2003, Leon Atkinson wrote: The undocumented function exif_tagname() does lookups on the table tag_table_IFD which matches IDF0 tags to human-readable names. Considering exif_read_data() already uses this table, is there a reason to have this function around? Debugging? Currently there is now way to return only the index of a tag. Hence i made the string table public. Seems like i missed adding the documentation. But now the internals had changed already i need to rewrite the function to make all tables accessible. So documentation must wait until that is implememented. regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] building ext/dba on win32
At 20:11 07.01.2003, Dave Viner wrote: Hi, I'm having trouble building the dba extension on win32. I get these errors: D:\php\php4\ext\dba\dba_db3.c(89) : error C2039: 'set_errcall' : is not a member of '__db' D:\PHP\PHP-WIN32BUILD\INCLUDE\db.h(397) : see declaration of '__db' D:\php\php4\ext\dba\dba_db3.c(90) : error C2039: 'open' : is not a member of '__db' D:\PHP\PHP-WIN32BUILD\INCLUDE\db.h(397) : see declaration of '__db' according to sleepycat this should be available in all db 3 versions. from looking at cvs annotate, the lines causing these errors were added on 30 Dec 02 by helly. I looked at the latest win32build zip file on php.net, and I have the latest information. Has anyone else seen this error? Or know how I can fix this? I checked the current snaps build and it outputs the following: [c:\programme\php4\cli]php -v PHP 4.4.0-dev (cli) (built: Jan 7 2003 20:19:15) Copyright (c) 1997-2003 The PHP Group Zend Engine v1.4.0, Copyright (c) 1998-2003 Zend Technologies [c:\programme\php4\cli]php -r print_r(dba_handlers(1)); Array ( [cdb] = 0.75, $Revision: 1.6 $ [cdb_make] = 0.75, $Revision: 1.5 $ [db3] = Sleepycat Software: Berkeley DB 3.3.11: (July 12, 2001) [flatfile] = 1.0, $Revision: 1.8 $ ) Interesting here is the version: DB 3.3.11. What version of DB 3 do you try to link to? regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI [packaging issues]
At 06:55 06.01.2003, Jean-Michel Dault wrote: Le sam 04/01/2003 à 18:13, Marcus Börger a écrit : What might happen is that CLI becomes widely accepted and scripts calling php from shebang lines. Id so your above solution is a bad idea and i hope CLI will be... I'm CC'ing the maintainers of PHP for most distributions of Linux, so we can all be in sync. For those that don't know the issue, I'll resume it by saying that with PHP 4.3, there is a new CLI (command-line interface) that complements the CGI interface. The problem is, both files are named php. This will help a lot when coming from you. Here is the solution that I have been experimenting over the past few days, and that will be implemented in Mandrake Cooker (and soon 9.1): - There will be two RPMS: php-cli and php-cgi. - Both packages will provide php - Using the update-alternatives, each package will contain /usr/bin/php as a symlink to the respective binary. This lets us give a priority to which binary is called for a given symlink. php-cli will be given priority 20 (higher), php-cgi will be given priority 10 (lower) - If only one package is installed, /usr/bin/php will link to the right executable. - By default, php-cgi will be installed, in order to maintain backwards compatibility. - Users will be able to install the CLI using rpm -i php-cli - If both packages are installed, php-cli will be called since it's higher priority. - All packages that specifically require the command-line interface (there is none for the moment, but there will be in the future), will explicitely require php-cli. This setup means that we don't break the configuration of people that already have the php CGI interface, while, with one simple command, the new PHP command-line enthusiasts will be able to have their cake. This goes with the PHP source approach: By default, configure/make/make install compiles the CGI interface, and then you have to make install-cli to get the CLI. We just replace the make install-cli by urpmi/apt-get php-cli. Comments/Questions/Suggestions welcome. Jean-Michel Dault PHP/Apache packager Mandrake Linux From my point of view this is the best solution :-)) regards marcus aka helly -- -- Marcus Börger - Looking for all sorts of freelance work - just ask... Did i help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0 --
Re: [PHP-DEV] Zend 2 - how to test
At 12:47 05.01.2003, Stefano Corsi wrote: Hello. I have downloaded Zend2 and tried to compile it against php 4.3.0 with many errors during the linking phase and some corrections at main/* files. Which is the right version/checkout for php to compile against Zend2 and where is it possible to get it? Try checkout of both 4.3.1-dev and HEAD u have fixed several issues yesturday. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
At 22:41 03.01.2003, Jean-Michel Dault wrote: Hello all, Sorry to re-activate this topic, but I stumbled into an issue when packaging PHP 4.3 as an RPM for Mandrake. What happens when a user wants to install *both* php-cli and php-cgi? You cannot have two files with the same name, either in the same RPM, or in two different RPMS... This is not RPM specific, since it will create the same problem with apt, pkgtool, or others. But why would he want to? AFAIK Mandrake uses php as an apache module and CLI can be used on the commandline. If the user still wants to have CGI by a RPM then i would go for naming it to whatever name you like different from that of the executable in the CLI RPM. Since RPM can handle all installation problems everything is fine then. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI (compromise proposal)
At 21:57 04.01.2003, Jean-Michel Dault wrote: Le sam 04/01/2003 à 08:15, Marcus Börger a écrit : What happens when a user wants to install *both* php-cli and php-cgi? You cannot have two files with the same name, either in the same RPM, or in two different RPMS... This is not RPM specific, since it will create the same problem with apt, pkgtool, or others. But why would he want to? AFAIK Mandrake uses php as an apache module and CLI can be used on the commandline. If the user still wants to have CGI by a RPM then i would go for naming it to whatever name you like different from that of the executable in the CLI RPM. Since RPM can handle all installation problems everything is fine then. Concrete example from our demanding users: If someone wants to have Apache running PHP, but provide secure PHP in a chrooted environment for users home directories, they use cgiwrap, thus php-cgi. But if they use PEAR and php-gtk as well, they'll need the php-cli. Ok, good point. What you're suggesting is that, when both cgi and cli are installed, the cli version is called php, and the php-cgi is called something else. This creates these problems: - If someone used the cgi version before, it will no longer work, since the php-cli doesn't write the headers - If someone used the cgi version in command-line mode, and install the new cli version, some scripts will be broken, because of the way it does not change directories before executing the script. So the default behavior is to have php-cgi, and have some additional steps to have the CLI. In the source edition, you have to do make install-cli, in Mandrake, you'll have to do rpm -i php-cli. So what I'll do is the following: - The standard php binary will be the CGI version, will be called php-cgi, and have a priority of 20. - There will be an additional php-cli package, and will have a priority of 10. - I will use the update-alternatives method to provide a symbolic link to /usr/bin/php. If only one package is installed, calling PHP will call the right one. If both are installed, calling php will translate to php-cgi, which has the highest priority. Users who have both packages will still be able to chose if they give the proper binary name. Does this make sense to you? Since i favor CLI being called php i would prefer that solution. And IMO security through cgi and suexec and such is only a hack (even though a good one at current time). However i see the main problem and can live with both solutions because i will not install CGI where i need CLI and on those systems where i need CGI i can live without CLI for now. What might happen is that CLI becomes widely accepted and scripts calling php from shebang lines. Id so your above solution is a bad idea and i hope CLI will be... marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Look Back 2002
Have fun reading! Indeed a funny reading! The only thing i missed was the december diberauschendenscussion Quoting behaviour exposed. Reference: http://news.php.net/article.php?group=php.devarticle=%3CPine.LNX.4.50.0212281820140.1306-10%40eco.foo%3E Happy new year and hopefully an even better 2003 for all of us. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] option to start in PHP mode
At 10:46 28.12.2002, Andi Gutmans wrote: At 01:45 AM 12/28/2002 +0100, Marcus Börger wrote: At 22:40 27.12.2002, Andi Gutmans wrote: I don't think it's beneficial to PHP to have two modes especially as the cli more you're talking about would support ? followed by a ?php. So all you're saving is the opening tag. I think any PHP programmer can handle it. Let's keep things similar across the board. Andi I agree here, too. But when you still want that stuff we can expand CLI by a new switch that executes the script in eval() mode. This way we do not have the problem with the closing ? tags mentioned by Andi (i just thought about starting a RFC on this). Why don't we have the ? problem? You can also use ? in eval()'s. Anyway, Rasmus mentioned that a switch already exists although I don't think it's such a great idea due to the previously mentioned reasons. I think all PHP code should be consistent. Andi Oh i see: I didn't knew you could do ? in eval() and hence in -r. So we could simply allow the combination of -r and -f, shall we? marcus At 02:11 PM 12/27/2002 -0500, Andrei Zmievski wrote: We've talked about this in the past, but let's bring it up again. It is a bit awkward to use CLI when it requires those ?php and ? tags. We should probably have a command-line option that tells the parser to start in PHP mode instead of HTML/text. Any thoughts on this? -Andrei http://www.gravitonic.com/ * What were the first 15 billion years of the universe like for you? * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] option to start in PHP mode
At 22:40 27.12.2002, Andi Gutmans wrote: I don't think it's beneficial to PHP to have two modes especially as the cli more you're talking about would support ? followed by a ?php. So all you're saving is the opening tag. I think any PHP programmer can handle it. Let's keep things similar across the board. Andi I agree here, too. But when you still want that stuff we can expand CLI by a new switch that executes the script in eval() mode. This way we do not have the problem with the closing ? tags mentioned by Andi (i just thought about starting a RFC on this). marcus At 02:11 PM 12/27/2002 -0500, Andrei Zmievski wrote: We've talked about this in the past, but let's bring it up again. It is a bit awkward to use CLI when it requires those ?php and ? tags. We should probably have a command-line option that tells the parser to start in PHP mode instead of HTML/text. Any thoughts on this? -Andrei http://www.gravitonic.com/ * What were the first 15 billion years of the universe like for you? * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure
I have taken a short look at the code and i think Morioshi is correct.
zlib_ouput_compression doesn't seem work when zlib si compiled as a
shared module. But i will not have time for this until after x-mas.
marcus
At 09:11 23.12.2002, Moriyoshi Koizumi wrote:
As far as I've looked into this problem, absense of Content-Encoding
field in the response headers, apparently a side effect of the patch of
rev 1.138 for main/SAPI.c, results in un-inflated output on the clients.
Because the patch was designed only to work with statically linked zlib
module, it causes link failure on unix build and prevents part of the code
responsible for sending the required headers from being compiled properly
on Windows build (due to the lack of HAVE_ZLIB definition) in case the
extension is built as shared. This was confirmed by comparing the browser
outputs of the following two scripts.
?php /* script A (should give incorrect result) */
echo test;
?
?php /* script B (should be OK) */
Header(Content-Encoding: gzip);
Header(Vary: Accept-Encoding);
echo test;
?
Besides this patch doesn't seem to accomplish its purpose completely, as
there would be no way at all to stop output_compression once the output
buffer is flushed either intentionally or automatically.
?php /* script C */
echo str_repeat(abcd, 1023);
/* the next line actually switches off output compression */
ini_set('zlib.output_compression', 0);
?
?php /* script D */
echo str_repeat(abcd, 1024);
/* no way to stop output compression at this point */
ini_set('zlib.output_compression', 0);
?
Therefore I think the modified part should be reverted for now, unless
there is a better way to fulfill the requirement (see bug #16109).
BTW since when did I become a output guy ? :)
Moriyoshi
Wez Furlong [EMAIL PROTECTED] wrote:
This needs one of you output guys to resolve it.
Andrei mentioned something about making the final release before 1st
Jan, so if you can, please get your coding-butts in gear :)
--Wez.
On 22 Dec 2002 [EMAIL PROTECTED] wrote:
ID: 21139
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Output Control
Operating System: Windows
PHP Version: 4.3.0RC4
New Comment:
Verified on Windows, with Apache or Apache2.
-- HTTP response dump of the following script --
?php echo abcde; ?
-- Apache_1.3.27 --
HTTP/1.1 200 OK
Date: Sun, 22 Dec 2002 18:06:53 GMT
Server: Apache/1.3.27 (Win32) PHP/4.4.0-dev
X-Powered-By: PHP/4.4.0-dev
Connection: close
Content-Type: text/html
(correctly gzip-encoded content)
-- Apache_2.0.43 --
HTTP/1.1 200 OK
Date: Sun, 22 Dec 2002 18:06:15 GMT
Server: Apache/2.0.43 (Win32) PHP/4.4.0-dev
Last-Modified: Sun, 22 Dec 2002 17:59:26 GMT
ETag: 45a2-1b-e744bab1
Accept-Ranges: bytes
Content-Length: 27
Connection: close
Content-Type: application/x-httpd-php
br /
bWarning/b: (null)() [a
href='http://www.php.net/ref.outcontrol'ref.outcontrol/a]: Cannot
change zlib.output_compression - headers already sent in bUnknown/b
on line b0/bbr /
abcde
Previous Comments:
[2002-12-21 19:27:53] [EMAIL PROTECTED]
I can confirm this bug on Windows + Apache + zlib.output_compression in
.htaccess.
If zlib.output_compression is set to on from php.ini it works. It only
doesn't work if set from .htaccess.
[2002-12-21 17:48:30] [EMAIL PROTECTED]
I have just installed latest php 4.3 on linux and windows.
I use the same directory and therefore .htaccess files for
apache/mod_php on both platforms.
When i enable enable output compression with ini setting
php_value zlib.output_compression On
in .htaccess the linux version works as expected but the
windows version fails. Sometimes i receive errors with
access violations. Sometimes i can downlowd the result
but when rename the resulting file to .gz i can open it and
as you might expect it contains the correct result. And
sometime i see the encoding result presented in the browser
and then i cannot save and view it although the gzip header
seems correct.
marcus
--
Edit this bug report at http://bugs.php.net/?id=21139edit=1
--
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] RC4 + windows
At 01:32 22.12.2002, Edin Kadribasic wrote: On Sunday 22 December 2002 00:51, Marcus Börger wrote: Hi, i can no longer load mhash and domxml dll's under windows RC4. marcus Rememberd to copy .dlls from dlls folder to a folder in PATH like c:\winnt\system32? Edin After adding the dlls to my path it works. Did something change? I mean with later distributions it worked without adding the path. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RC4 + windows
Hi, i can no longer load mhash and domxml dll's under windows RC4. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 4.3 + gzip-encoding
Hi, i just have installed latest php 4.3 on linux and windows. I use the same directory and therefore .htaccess files for apache/mod_php on both platforms. When i enable enable output compression with php_value zlib.output_compression On in .htaccess the linux version works as expected but the windows version fails. Sometimes i receive errors with access violations. Sometimes i can downlowd the result but when rename the resulting file to .gz i can open it and as you might expect it contains the correct result. marcus -- Marcus Börger - Looking for all sorts of freelance work - just ask... Did i help you? Consider a gift: http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0 --
Re: [PHP-DEV] CLI php.exe on WIn32
At 18:27 20.12.2002, Frank M. Kromann wrote: Hi, The latest changes to the project files under WIn32, creates name conflict, by having php.exe created from two different projects in the same directory. I suggest that we move the cli version from ..\Release_TS to ..\Release_TS\cli And the same for Debug_TS and Release_inline_ts builds. - Frank Iirc we decided to put the CLI version in a subdirectory, we're not doing by latest changes? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
At 23:21 18.12.2002, 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. That would be a very bad thing. If we want this we should do it for 4.3.0 instead of having different installations every now and then. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
At 20:59 18.12.2002, 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
After reading through the whole thread i came to the conclusion that there
are two
parties. The first wants BC for all costs and the second wants
improovements. The
improovement party started the whole issue.
They wanted to overcome the necessary workarounds that allows CGI being
used as
a shell utility (mostly with shebang lines like with perl). To accomplish
this the best
way seemed to have a new executable handling this correctly (and different
than CGI).
This required the new executable CLI being called php to have it beeing a
replacement.
At this point it that was not considered being a problem for two reasons.
First CGI has
to be installed anyway and second noone thought about windows problems at that
time. So far the history as i see/remeber it.
Then the problem on windows was reported and the BC party got alarmed
claimed that
new things have to have new names and all BC has to be kept. (point)
From my point of view having CLI with a different name than php does not
make much
sense but it is far more better than merging the two. Merging would make
the code
allmost unreadable and would also slow down the code (where are those
saying speed
is everything?). And of cause merging is against the idea that we will have
different
behaviour from different executables for different tasks. (And edin already
showed an
example where merging will leed to errors).
And now to the ideas mentioned from several people here:
a) Merging CLI CGI read above.
b) Merging in 4.3.1 seems the worst thing we can do. It contradicts nearly
all thoughts
we have heared here just to have 4.3.0 out asap. But more important it
leeds to one
more different behaving version. And most important it contradicts one
rule: Only bug
fixes in such releases.
c) --install-cli[=dir] + --install-cgi[=dir]: Nice idea but we do not have
a real problem under
*nix. The problem is in windows. However i like the idea but think that
having defaults
for them is necessary (For me that would be --install-cli={$prefix]/bin and
CGI to something
differnet).
d) keeping CGI and CLI in their sapi directories before installation is a
good idea. It would
make handling easier and clearer. If there is no php in ./ i know what php
i get when
fetching it from a sapi directory.
e) having both using the name php will confuse the users way to much. And
we would
reach the opposite of what started the issue: less bugreports and questions.
f) Throwing an error or notice when missusing one of the two seems a good
idea to me
as long as this message can be disabled (See example shown by edin). And i
do not see
any problem with that. In fact that would be the best solution to introduce
such changes
because notes and hints in documents or readmes are being ignored by to
many users.
g) Calling CGI from CLI when CLI is used as CGI seems a good idea as long
as it can be
disabled at first sight. But it makes things more complicated and e) is the
better way.
h) None of the above solves the problem under windows: But i do not get it:
Even on
windows an executable can be called with its full path. So there is only a
little change
that has do be done on all platforms when renaming CGI executable to
php-cgi: Only
one configure line has to be changed. And those users being to lazy to read
installation
docs, news and change logs can be given hints by e).
i) We are late in release process.
After all this points we have to question ourselves: Do we want php
becoming a widely
accepted command line utility (which it is already for many users) even
when this will
cost use to mark some bug reports bogus or documentation problems? Isn't it
a fact
that sometimes evolution requires changes?
Just to make my conclusion clear: I favor CGI with the new name php-cgi +
c) d) e)
since BC is not everything.
marcus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] -+ [01]
At 13:14 19.12.2002, Sascha Schumann wrote: On Thu, 19 Dec 2002, Zeev Suraski wrote: Just to somewhat limit my agreement with that statement, I'd rephrase it so that it's clear that people's opinion does matter. Something along the lines of 'Too many people think that they're in a position to decide about PHP'. There is nothing funny about that statement. For example, if you are not going to do the work on merging the CLI/CGI code, just saying that you would like to see that happening has little to no effect. Conclusively, there is simply too much noise on the php-dev list by people who are not going to do any work, but somehow think they are entitled to actually waste other people's time with their opinions. - Sascha Ok, now your thoughts become clear and indeed make much sense. But how do we separate the noise from thoughts that metter and should be heared before doing any modification. Shall we hear them only when the initial mail is marked as RFC? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CGI and CLI
At 13:23 19.12.2002, Zeev Suraski wrote:
I think you forgot to take one fact into account - PHP 4.2.x already had
CLI/CGI binaries, both having the same name. Keeping 4.3 with the 4.2
behavior, and then merging the modules back in 4.3.1 is the best solution
as far as I can tell. Merging the modules does not have serious
compatibility-breaking drawbacks, and either way, these drawbacks, if any,
will be identical whether they happen in 4.3 or 4.3.1.
As i said: If merging then merging in 4.3.0. I do not see any reason not to
make
such changes in 4.3.0 besides the time of 4.3.0 release.
About 'BC at all costs', I'm a big advocate of BC, but describing this
issue as 'BC at all costs' is just plain wrong. The cost here is tiny,
it's a tiny price to pay for BC and simplicity.
Zeev
I used the phrase BC at all costs to over emphasize the following: Having
any name
other than php is really bad for CLI.
You are right to say the cost is tiny if the solution is merging. But i am
for instance
strongly against that.
I forgot to recall one more thing: CLI is EXPERIMENTAL in 4.2.x so keeping
CLI as
in 4.2.x is the least important thing in this whole issue.
At 14:14 19/12/2002, Marcus Börger wrote:
At 20:59 18.12.2002, 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
After reading through the whole thread i came to the conclusion that
there are two
parties. The first wants BC for all costs and the second wants
improovements. The
improovement party started the whole issue.
They wanted to overcome the necessary workarounds that allows CGI being
used as
a shell utility (mostly with shebang lines like with perl). To accomplish
this the best
way seemed to have a new executable handling this correctly (and
different than CGI).
This required the new executable CLI being called php to have it beeing a
replacement.
At this point it that was not considered being a problem for two reasons.
First CGI has
to be installed anyway and second noone thought about windows problems at
that
time. So far the history as i see/remeber it.
Then the problem on windows was reported and the BC party got alarmed
claimed that
new things have to have new names and all BC has to be kept. (point)
From my point of view having CLI with a different name than php does not
make much
sense but it is far more better than merging the two. Merging would make
the code
allmost unreadable and would also slow down the code (where are those
saying speed
is everything?). And of cause merging is against the idea that we will
have different
behaviour from different executables for different tasks. (And edin
already showed an
example where merging will leed to errors).
And now to the ideas mentioned from several people here:
a) Merging CLI CGI read above.
b) Merging in 4.3.1 seems the worst thing we can do. It contradicts
nearly all thoughts
we have heared here just to have 4.3.0 out asap. But more important it
leeds to one
more different behaving version. And most important it contradicts one
rule: Only bug
fixes in such releases.
c) --install-cli[=dir] + --install-cgi[=dir]: Nice idea but we do not
have a real problem under
*nix. The problem is in windows. However i like the idea but think that
having defaults
for them is necessary (For me that would be --install-cli={$prefix]/bin
and CGI to something
differnet).
d) keeping CGI and CLI in their sapi directories before installation is a
good idea. It would
make handling easier and clearer. If there is no php in ./ i know what
php i get when
fetching it from a sapi directory.
e) having both using the name php will confuse the users way to much. And
we would
reach the opposite of what started the issue: less bugreports and questions.
f) Throwing an error or notice when missusing one of the two seems a good
idea to me
as long as this message can be disabled (See example shown by edin). And
i do not see
any problem with that. In fact that would be the best solution to
introduce such changes
because notes and hints in documents or readmes are being ignored by to
many users.
g) Calling CGI from CLI when CLI is used as CGI seems a good idea as long
as it can be
disabled at first sight. But it makes things more complicated and e) is
the better way.
h) None of the above solves the problem under windows: But i do not get
it: Even on
windows an executable can be called with its full path. So there is only
a little change
that has do be done on all platforms when renaming CGI executable to
php-cgi: Only
one configure line has to be changed. And those users being to lazy to
read installation
docs, news and change logs can be given hints by e).
i) We are late in release process.
After all this points we have to question ourselves
Re: [PHP-DEV] CGI and CLI (compromise proposal)
At 15:33 19.12.2002, Edin Kadribasic wrote: After having consulted with Andrei, Derick and others on irc here is a proposal for a compromise: On Unix: 1. Both cgi and cli are built as 'php' in their respective sapi directories (pretty much as it is today except that cgi gets renamed back from php-cgi to just php). 2. Make install will *not* install cli if cgi build was selected (only cgi gets installed). 3. A new install target 'install-cli' is introduced so that make install-cli will overwrite whatever is in $(PREFIX)/bin/php. On Windows: 1. php.exe in the root of distribution is php cgi sapi. 2. New cli directory is included with php.exe (cli) in it. If this is an acceptable compromise I volunteer to do the changes required. Edin I am +1 with respect to latest -+ [01] discussion marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] -+ [01]
At 01:35 19.12.2002, Sascha Schumann wrote: On 18 Dec 2002, Xavier Spriet wrote: Well it's up to whoever has karma to make that decision. People can give their opinion obviously but shouldn't expect to actually make the decision. That's the problem with the current state of PHP development. Too many people think that their opinion actually matters. - Sascha What does that mean? Only a small group has the right to do anything and the others are only idiots who code for the silliness since only a small group takes advantage? We have feature requests and a lot of good programmers. I think every should have the right to say what she/he wants. -+ [01] is only a thing to clearly mark ones meaning. And from my point of view every meaning matters here. If not make php a closed source development. Until that is done we can go on as we did in the past. Here the meanings and let those being or feeling responsible do necessary changes. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
