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.hphp_variables.c php_variables.h
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. Derick -- Stop mad cowboy disease! - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- 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
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist php.ini-recommended /ext/zlib zlib.c
At 11:06 12.08.2002, Stefan Roehrich wrote: On 2002-08-11 02:32:50, Yasuo Ohgaki wrote: Log: Changed my mind. Let users decided whether users want larger chunk size or not. Changed zlib.output_compression behavior. If larger chunk is preferred, enable output_buffering also. (Marcus, Yasuo) The NEWS entry got truncated, can you fix this? What's the benefit of the new behaviour? I think the old one was a rather good default, because compression of small chunks doesn't make sense and you could change the size via zlib.output_compression. Stefan Yasuo, Zeev and me had a short discussion about internals and all the behaviour on the weekend. In short the old behavior was that we had zli.output_compression defaulting to 4K inputchunks (resulting normally in 1K output chunks) and a double buffer getting the input from zlib with a buffer size of 40K resulting in 40 output chunks. We will drop the double buffer again and my favorite would be changing zlibs default to 16K (resulting in 4K output chunks). But we must document this stuff If Zeev and Yasuo agree i will change the above later on today. Questions leeft: Maybe we should also change the default for output_buffering from 40K to 4K. Maybe we should change all default from 40K to 4K or use the value normally used for output_buffering (40K or 4K) as default size for other buffers. 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 / php.ini-dist php.ini-recommended /ext/zlib zlib.c
On 2002-08-12 11:34:40, Marcus Börger wrote: We will drop the double buffer again and my favorite would be changing zlibs default to 16K (resulting in 4K output chunks). But we must document this stuff Yes, and provide useful defaults, I think there are some sites which have switched zlib.output_compression on, but left output_buffering the default value. Stefan -- Stefan Röhrich [EMAIL PROTECTED], [EMAIL PROTECTED] http://www.roehri.ch/~sr/ -- 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
Just to correct myself: it was a missconfigured ini. marcus At 09:58 09.08.2002, Marcus Börger wrote: [and again to correct list] Oh your fast, i havent't finsished all tests and therefor not comitted it. The next step of the patch is available at: http://marcus-boerger.de/php/ext/output-buffer.patch Yesturday i had some weird behaviour on shared apache module but i wasn't able to test it because currently my testmachine does not want to load the module (seems like i have to reinstall whole apache/php stuff on that machine). marcus At 08:14 09.08.2002, you wrote: yohgaki Fri Aug 9 02:14:33 2002 EDT Modified files: /php4 php.ini-dist php.ini-recommended Log: Added note for output_handler usage. (with Marcus and Adam's fix) Index: php4/php.ini-dist diff -u php4/php.ini-dist:1.138 php4/php.ini-dist:1.139 --- php4/php.ini-dist:1.138 Sun Jul 28 13:25:55 2002 +++ php4/php.ini-dist Fri Aug 9 02:14:32 2002 -89,9 +89,15 output_buffering = Off ; You can redirect all of the output of your scripts to a function. For -; example, if you set output_handler to ob_gzhandler, output will be -; transparently compressed for browsers that support gzip or deflate encoding. -; Setting an output handler automatically turns on output buffering. +; example, if you set output_handler to mb_output_handler, character +; encoding will be transparently converted to the specified encoding. +; Setting any output handler automatically turns on output buffering. +; NOTE: People who wrote portable scripts should not depend on this ini +; directive. Instead, explicitly set the output handler using ob_start(). +; Using this ini directive may cause problems unless you know what script +: is doing. +; NOTE: You cannot use both mb_output_handler with ob_inconv_handler +; and you cannot use both ob_gzhandler and zlib.output_compression. output_handler = ; The unserialize callback function will called (with the undefind class' Index: php4/php.ini-recommended diff -u php4/php.ini-recommended:1.91 php4/php.ini-recommended:1.92 --- php4/php.ini-recommended:1.91 Sun Jul 28 13:25:55 2002 +++ php4/php.ini-recommendedFri Aug 9 02:14:33 2002 -102,9 +102,15 output_buffering = 4096 ; You can redirect all of the output of your scripts to a function. For -; example, if you set output_handler to ob_gzhandler, output will be -; transparently compressed for browsers that support gzip or deflate encoding. -; Setting an output handler automatically turns on output buffering. +; example, if you set output_handler to mb_output_handler, character +; encoding will be transparently converted to the specified encoding. +; Setting any output handler automatically turns on output buffering. +; NOTE: People who wrote portable scripts should not depend on this ini +; directive. Instead, explicitly set the output handler using ob_start(). +; Using this ini directive may cause problems unless you know what script +: is doing. +; NOTE: You cannot use both mb_output_handler with ob_inconv_handler +; and you cannot use both ob_gzhandler and zlib.output_compression. output_handler = ; Transparent output compression using the zlib library -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- 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
Rasmus Lerdorf wrote: But what problem are you trying to solve? Me? None. I just wanted to show a possible third way. There have been a lot of changes lately that adds more obstacles for the new user. Most of the books out there and all sorts of tutorials show short-tag examples. Blame the authors, then :) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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/tokenizer
Markus Fischer wrote: It is not publicly exposed with ZEND_API(). I can't test right now, but maybe just need to modify the zend_compile.h file and prepend the prototype definition with ZEND_API ? Yes, prefixing the prototype with ZEND_API did the trick. Andi, Zeev, is this change okay with you? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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/tokenizer
At 09:21 AM 2/10/2002 +0100, Sebastian Bergmann wrote: Markus Fischer wrote: It is not publicly exposed with ZEND_API(). I can't test right now, but maybe just need to modify the zend_compile.h file and prepend the prototype definition with ZEND_API ? Yes, prefixing the prototype with ZEND_API did the trick. Andi, Zeev, is this change okay with you? Yeah, no problem. Andi -- 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/tokenizer
On Sat, Feb 09, 2002 at 08:00:28AM +0100, Sebastian Bergmann wrote : Sebastian Bergmann wrote: tokenizer.c C:\home\php\php4\ext\tokenizer\tokenizer.c(328): error C2198: 'lex_scan': Not enough parameters C:\home\php\php4\ext\tokenizer\tokenizer.c(344): error C2065: 'tsrm_ls': Undeclared identifier C:\home\php\php4\ext\tokenizer\tokenizer.c(483): error C2198: 'zend_save_lexical_state': Not enough parameters C:\home\php\php4\ext\tokenizer\tokenizer.c(485): error C2198: 'zend_prepare_string_for_scanning': Not enough parameters C:\home\php\php4\ext\tokenizer\tokenizer.c(491): error C2198: 'zend_restore_lexical_state': Not enough parameters The patch below leaves only one error and one warning: C:\home\php\php4\ext\tokenizer\tokenizer.c(328): error C2065: 'tsrm_ls': Undeclared identifier Adding a TSRMLS_FETCH() call doesn't cure this :-( C:\home\php\php4\ext\tokenizer\tokenizer.c(328): warning C4022: 'lex_scan': Incorrect pointer type for parameter 2 You don't need (and shouldn't) call TSRMLS_FETCH() here. Declaring tokenizer() having a TSRMLS_DC and passing TSRMLS_CC when calling it should be sufficient. - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- 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/tokenizer
Markus Fischer wrote:
You don't need (and shouldn't) call TSRMLS_FETCH() here.
Declaring tokenizer() having a TSRMLS_DC and passing
TSRMLS_CC when calling it should be sufficient.
Stupid me, of course. The patch below fixes all compiler errors and
warnings. However, I now get a linkage error due to an unresolved
external symbol: _lex_scan.
Index: tokenizer.c
===
RCS file: /repository/php4/ext/tokenizer/tokenizer.c,v
retrieving revision 1.1
diff -u -2 -b -w -B -r1.1 tokenizer.c
--- tokenizer.c 8 Feb 2002 18:49:40 - 1.1
+++ tokenizer.c 9 Feb 2002 09:23:29 -
@@ -316,5 +316,5 @@
/* }}} */
-static void tokenize(zval *return_value)
+static void tokenize(zval *return_value TSRMLS_DC)
{
zval token;
@@ -326,5 +326,5 @@
ZVAL_NULL(token);
- while ((token_type = lex_scan(token CLS_CC))) {
+ while ((token_type = lex_scan(token TSRMLS_CC))) {
destroy = 1;
switch (token_type) {
@@ -481,13 +481,13 @@
ZVAL_STRINGL(source_z, source, source_len, 0);
- zend_save_lexical_state(original_lex_state CLS_CC);
+ zend_save_lexical_state(original_lex_state TSRMLS_CC);
- if (zend_prepare_string_for_scanning(source_z, ) == FAILURE) {
+ if (zend_prepare_string_for_scanning(source_z, TSRMLS_CC) ==
FAILURE
) {
RETURN_EMPTY_STRING();
}
- tokenize(return_value);
+ tokenize(return_value TSRMLS_CC);
- zend_restore_lexical_state(original_lex_state CLS_CC);
+ zend_restore_lexical_state(original_lex_state TSRMLS_CC);
}
/* }}} */
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
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/tokenizer
On Sat, Feb 09, 2002 at 10:33:35AM +0100, Sebastian Bergmann wrote : Markus Fischer wrote: You don't need (and shouldn't) call TSRMLS_FETCH() here. Declaring tokenizer() having a TSRMLS_DC and passing TSRMLS_CC when calling it should be sufficient. Stupid me, of course. The patch below fixes all compiler errors and warnings. However, I now get a linkage error due to an unresolved external symbol: _lex_scan. It is not publicly exposed with ZEND_API(). I can't test right now, but maybe just need to modify the zend_compile.h file and prepend the prototype definition with ZEND_API ? - Markus -- 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/tokenizer
Markus Fischer wrote: It is not publicly exposed with ZEND_API(). I can't test right now, but maybe just need to modify the zend_compile.h file and prepend the prototype definition with ZEND_API ? My desktop PC went *poof* today, in lack of a better word. I don't have a build environment on my notebook, so it may be a week or so until I can test again. Dunno, if I find the time to setup a build environment. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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/tokenizer
Sebastian Bergmann wrote:
tokenizer.c
C:\home\php\php4\ext\tokenizer\tokenizer.c(328): error C2198:
'lex_scan': Not enough parameters
C:\home\php\php4\ext\tokenizer\tokenizer.c(344): error C2065:
'tsrm_ls': Undeclared identifier
C:\home\php\php4\ext\tokenizer\tokenizer.c(483): error C2198:
'zend_save_lexical_state': Not enough parameters
C:\home\php\php4\ext\tokenizer\tokenizer.c(485): error C2198:
'zend_prepare_string_for_scanning': Not enough parameters
C:\home\php\php4\ext\tokenizer\tokenizer.c(491): error C2198:
'zend_restore_lexical_state': Not enough parameters
The patch below leaves only one error and one warning:
C:\home\php\php4\ext\tokenizer\tokenizer.c(328): error C2065:
'tsrm_ls': Undeclared identifier
Adding a TSRMLS_FETCH() call doesn't cure this :-(
C:\home\php\php4\ext\tokenizer\tokenizer.c(328): warning C4022:
'lex_scan': Incorrect pointer type for parameter 2
Index: tokenizer.c
===
RCS file: /repository/php4/ext/tokenizer/tokenizer.c,v
retrieving revision 1.1
diff -u -2 -b -w -B -r1.1 tokenizer.c
--- tokenizer.c 8 Feb 2002 18:49:40 - 1.1
+++ tokenizer.c 8 Feb 2002 22:35:42 -
@@ -326,5 +326,5 @@
ZVAL_NULL(token);
- while ((token_type = lex_scan(token CLS_CC))) {
+ while ((token_type = lex_scan(token TSRMLS_CC))) {
destroy = 1;
switch (token_type) {
@@ -481,7 +481,7 @@
ZVAL_STRINGL(source_z, source, source_len, 0);
- zend_save_lexical_state(original_lex_state CLS_CC);
+ zend_save_lexical_state(original_lex_state TSRMLS_CC);
- if (zend_prepare_string_for_scanning(source_z, ) == FAILURE) {
+ if (zend_prepare_string_for_scanning(source_z, TSRMLS_CC) ==
FAILURE
) {
RETURN_EMPTY_STRING();
}
@@ -489,5 +489,5 @@
tokenize(return_value);
- zend_restore_lexical_state(original_lex_state CLS_CC);
+ zend_restore_lexical_state(original_lex_state TSRMLS_CC);
}
/* }}} */
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
--
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
At 16:48 25-08-01, Jani Taskinen wrote: Better question is, do we really want to do this? This doesn't fix anything. It only breaks things. Second, this will make writing portable scripts harder. Yet another ini setting to be checked for.. The only good way of doing this rand() - mt_rand() change would have been my way (tm) which was rejected. ie. using the mt_* always. I think that what Jeroen's doing is a good idea. We're dealing with this issue in a too techie manner, and forget that most people just want a random number when they call rand(). I don't think it's too much to ask :) If rand() gives them pseudo random numbers, or predictable random numbers, then it's (usually) not what they're looking for. I guess it's not impossible that someone would actually rely on the fact that given the same seed, you get the same predictable series of random numbers, but it's fairly poor coding, and I don't think it's being used too often (far less often than plain random numbers are, anyway). If somebody wants to get a predictable series, let him ask for it explicitly. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
