Re: [PHP-DEV] ext/aspell
[] While new comers may not know of pspell, people who have compiled PHP before with it will, infact that is what they'll expect when configuring their PHP. Since we cannot remove the old pspell option like we seem to agree to do for --with-aspell it is cleaner IMHO to simply add that little bit of text that will tell people new to php that --with-pspell also applies to GNU Aspell. Perpaps, a year down the road when we feel confortable to say that GNU marketing(tm) has made pspell absolete we can make this change. Then why not make --with-pspell cause an error saying: use --with-gnu-aspell? And then move --with-pspell to /dev/null at it's time. Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Feature request -- feedback welcomed.
Uhm... 4.3.0 will not ship with Zend 2.0, that will b ethe honour of PHP 5.0.0. But one can compile Zend 2.0 into PHP 4 - i think Zeev posted an HowTo some weeks ago. Regards Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unexpected for-loop operation
This is exactly, what the code should do; in Zend/zend_operators.c there is an
special function for this to do (increment_string), so i assume this is the
expected result.
Sascha
I know there is a better way to do that, and this code is silly, but
still...
Try running these two loops in PHP 4.2.3.
for($i = 'A'; $i = 'Y'; $i++){
echo $i ;
}
for($i = 'A'; $i = 'Z'; $i++){
echo $i ;
}
Notice the difference in output. Is this the expected result?
Vlad
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thread Reading
I totally agree to you - and i still can't catch up the point what the current discussion is about. Sascha The underlying effect is minimal, no noticable change. The effect of having the option there is mind blowing for IRC based support staff who are dealing with (for want of a better word), idiots. For those of you who dont have time, or the capability to test it out for yourself, please take the following exampes: http://www.dapond.net/code/backtrace.php http://www.dapond.net/code/backtrace.phps http://www.dapond.net/code/backtrace.phps?HIGHLIGHT_FORMAT=default http://www.dapond.net/code/backtrace.phps?HIGHLIGHT_FORMAT=lineno (note the default setting for a .phps without arguments) This doesnt demonstrate the use of the show_source (or other aliased) function, but I assure you - it works similarly with an optional parameter, defaulting to current behaviour. I still await a good reason for this not to become part of the standard distribution, and any list of adverse side affects this poses. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] include_ini and include_ini_dir
Am Donnerstag, 12. September 2002 18:20 schrieb David Viner: Hmm... in the apache world, the srm.conf and access.conf were deprecated, but the Include directive in the configuration file is still maintained. That is, by default, people use a single apache configuration file. However, for specialized cases, like Brian's, people have the ability to use multiple files if they want the extra work of multiple configuration files. I think in apache, include is still very usefull, since scripts adding customers automatically to the server config or give the admin/customer ability to change some settings via web-interfaces, should not have to rewrite the whole httpd.conf. Does this apply to PHP, too? Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] highlight_file modification
hi [...] I believe the default should be its current behaviour (for backward compatability, and to prevent unexpected change)... but I do think there should be an ini option so that .phps files can have this functionality. [...] +1 on that. [...] Having line numbers on a .phps file would enable us to support users MUCH better just by asking them to rename the file from .php to .phps and give us the URL. We then say your missing a ; on line 52. Much easier than trying to navigate them to the if halfway down the screen. +1, too. If you can think of an alternative way to enable / disable the modifications suggested other than using a php.ini entry... ;) [...] wouldn't it be better to let the viewer decide, if line numbers should appear or not. This wouldn't break BC and also would not be needed to be enabled on any server. Maybe we could use a GET Param on this (only for the .phps's) like: http://localhost/test.phps?linenumbers=0 http://localhost/test.phps?linenumbers=1 in which we would default linenumbers to zero. Best regards Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] highlight_file modification
http://www.dapond.net/code/bleh.html This still doesn't implement the .phps?linenumbers (since that's gonna have to do with the server module/cgi binary code) and also since nobody's (yet) given input as to what variable name would be sufficient. at least SG(request_info).query_string contains the full (unparsed) query string at this moment. show_line_numbers? Headers/footers will also have to go in the server module/cgi code to implement XHTML/1.1 for the output, since I can't think of a way to figure out whether zend_highlight() was called from the apache_php_module_main function (or, simply to tell whether or not it was called from anywhere other than highlight_file/highlight_string). Ignoring the use of show_source(file) currently the apache, cgi, cli, pi3web and servlet sapis are able to produce highlited source. None of these SAPIs will send correct HTML, since HTML and BODY are missing. I think, in a web-server environment, they should do so, shouldn't they? But what about the CLI? I could imagine, one uses this to parse PHP-Code into printable form. Anyway - after walking through all these SAPIs - one way to figure out, whether zend_highlight was called from highlight_file/highlight_string or not is: Adding a flag to the zend_syntax_highlighter_ini-structure, initializing it to FALSE in php_get_highlight_struct (All SAPIs and the PHP-Function highlight_file etc. use this way to create it; i wonder why zend_highlight doesn't get this structure itself?). By setting this flag to TRUE, you can omit sending a header from the PHP-Functions. I know, this is a kludge, but at least it's an option. Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
