[PHP-DEV] Re: [PATCH] double to long conversion change
Hi Matt,
I tried to look into this issue once again, but I completely
misunderstand why do we need all this magic. Why do we need conversion
of positive double into negative long?
I would stay with single DVAL_TO_LVAL() definition and use it in places
instead of (long)Z_DVAL().
#define DVAL_TO_LVAL(d, l) \
if ((d) LONG_MAX) { \
(l) = LONG_MAX; \
} else if ((d) LONG_MIN) { \
(l) = LONG_MIN; \
} else {\
(l) = (long) (d); \
}
Or may be we need a second macro for conversion into unsigned long where
it needed?
#define DVAL_TO_ULONG(d, l) \
if ((d) ULONG_MAX) { \
(l) = ULONG_MAX; \
} else if ((d) 0) { \
(l) = 0; \
} else {\
(l) = (unsigned long) (d); \
}
It also possible to add notices in case of overflow detection.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi all,
Since noticing and reporting last year [1] different behavior when
casting out-of-range doubles to int after the DVAL_TO_LVAL() macro was
updated, I've wondered how to get the behavior I observed, and thought
could be relied on (that was wrong to think, since it was un- or
implementation-defined), back. And how to do so (what should be
expected?), while keeping in mind the reason for the change: consistent
behavior for tests. [2] Except that the current code does not give
consistent results, depending on which DVAL_TO_LVAL definition is used
on a platform. [3]
[1] http://marc.info/?l=php-internalsm=120799720922202w=2
[2] http://marc.info/?l=php-internalsm=123495655802226w=2
[3] http://marc.info/?l=php-internalsm=123496364812725w=2
So after I finally started to test my ideas for consistent/reliable
overflow across platforms a few days ago, I noticed that my workaround
technique quit working (0 instead of overflow) with doubles over 2^63,
without resorting to fmod(). That's on Windows, but I suspect the same
may happen on other systems that are limited to 64-bit integer
processing internally or something (32-bit platforms?). On 64-bit Linux
anyway, it looks like doubles 2^63 do rollover as expected (128-bit
internal processing?):
http://marc.info/?l=php-internalsm=123376495021789w=2
I wasn't sure how to rethink things after that... But of course with
doubles, precision has been lost long before 2^63 anyway, as far as
increments of 1 (it's 1024 at 2^63).
What I wound up with for now, is using 5.2's method on 64-bit platforms,
and on 32-bit, overflow behavior should be reliable up to 2^63 on
platforms that have zend_long64 type available (long long, __int64),
which I'm guessing is most (?), because of the unsigned long
involvement. Finally a fallback workaround for 32-bit platforms without
a 64-bit type.
I updated a few other places in the code where only a (long) cast was
used. And sort of unrelated, but I added an 'L' conversion specifier for
zend_parse_parameters() in case it would be useful for PHP functions
that want to limit values to LONG_MAX/LONG_MIN, without overflow, which
I thought the DVAL_TO_LVAL change was *trying* to do.
http://realplain.com/php/dval_to_lval.diff
http://realplain.com/php/dval_to_lval_5_3.diff
And here is an initial version of zend_dval_to_lval() (before 2^63 issue
and thinking of zend_long64 + unsigned long), where some configure
checks would set ZEND_DVAL_TO_LVAL_USE_* as needed.
http://realplain.com/php/dval_to_lval.txt
Any general feedback, comments, questions, suggestions? Hoping these
conversion issues could be sorted out for good in a nice, logical way.
:-) Unfortunately on Windows, I'm just guessing, rather than testing,
conversion results in different environments...
Thanks,
Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Returning NULL when arg parsing fails - was: Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/pcntl pcntl.c /ext/pcntl/tests pcntl_signal.phpt
Kalle Sommer Nielsen wrote:
Most of php-src uses validation check the other way around:
if (zend_parse_parameters(...) == FAILURE) {
...
}
But I still don't agree that we should change to return false if
parameter parsing fails, in most cases it generates a verbal warning
which no one want in first place with this new API which should make
people awake of their code is wrong. Ofcourse theres the quite option,
but still
The point raised on IRC was the opposite: try and unify the code so that
if parameter parsing fails returns NULL, which seems to be the standard.
And yes you're right, there are quite a lot of checks with
zend_parse_parameters(...) == FAILURE.
Attached is the result of a simple script counting both variants and the
numbers of RETURN_FALSE vs total number of matches. Not all are verified
and there could be false positives or missing matches, but approx a
patch would touch 42 files with 304 changes. So I don't think it's a
good idea to fix now, maybe something we might want to do for the next
major release.
About my next PDO changes, barring any objection I will use return false
to keep the behaviour consistent with the current one.
Cheers
--
Matteo Beccati
OpenX - http://www.openx.org
Total zend_parse_parameters() checks: 1838
Total using return: 1534
Total using RETURN_FALSE: 304
ext/bcmath/bcmath.c: 0 out of 10
ext/bz2/bz2.c: 2 out of 5
ext/calendar/cal_unix.c: 0 out of 2
ext/calendar/calendar.c: 13 out of 13
ext/calendar/easter.c: 0 out of 1
ext/com_dotnet/com_com.c: 3 out of 6
ext/com_dotnet/com_dotnet.c: 0 out of 1
ext/com_dotnet/com_persist.c: 0 out of 5
ext/com_dotnet/com_variant.c: 0 out of 7
ext/ctype/ctype.c: 0 out of 1
ext/curl/interface.c: 1 out of 10
ext/curl/multi.c: 0 out of 7
ext/date/php_date.c: 19 out of 19
ext/dba/dba.c: 1 out of 10
ext/dom/document.c: 0 out of 2
ext/dom/domimplementation.c: 0 out of 3
ext/dom/php_dom.c: 0 out of 1
ext/enchant/enchant.c: 18 out of 18
ext/ereg/ereg.c: 0 out of 4
ext/exif/exif.c: 0 out of 4
ext/fileinfo/fileinfo.c: 6 out of 7
ext/filter/filter.c: 1 out of 6
ext/ftp/php_ftp.c: 2 out of 33
ext/gd/gd.c: 12 out of 79
ext/gd/gd_ctx.c: 0 out of 2
ext/gettext/gettext.c: 0 out of 9
ext/gmp/gmp.c: 0 out of 33
ext/hash/hash.c: 0 out of 12
ext/hash/hash_md.c: 0 out of 2
ext/hash/hash_sha.c: 0 out of 2
ext/iconv/iconv.c: 9 out of 11
ext/imap/php_imap.c: 1 out of 59
ext/interbase/ibase_blobs.c: 8 out of 8
ext/interbase/ibase_events.c: 0 out of 2
ext/interbase/ibase_query.c: 0 out of 14
ext/interbase/ibase_service.c: 1 out of 1
ext/interbase/interbase.c: 3 out of 6
ext/intl/grapheme/grapheme_string.c: 8 out of 8
ext/intl/idn/idn.c: 0 out of 1
ext/intl/locale/locale_methods.c: 7 out of 7
ext/json/json.c: 0 out of 2
ext/ldap/ldap.c: 0 out of 1
ext/libxml/libxml.c: 0 out of 2
ext/mbstring/mbstring.c: 16 out of 37
ext/mbstring/php_mbregex.c: 5 out of 9
ext/mcrypt/mcrypt.c: 0 out of 12
ext/mssql/php_mssql.c: 0 out of 26
ext/mysql/php_mysql.c: 0 out of 40
ext/mysqli/mysqli.c: 0 out of 4
ext/mysqli/mysqli_api.c: 0 out of 1
ext/mysqli/mysqli_embedded.c: 0 out of 1
ext/mysqli/mysqli_nonapi.c: 0 out of 2
ext/mysqli/mysqli_report.c: 0 out of 1
ext/mysqli/mysqli_warning.c: 0 out of 1
ext/oci8/oci8.c: 0 out of 4
ext/oci8/oci8_interface.c: 0 out of 69
ext/oci8/oci8_statement.c: 0 out of 1
ext/odbc/birdstep.c: 0 out of 12
ext/odbc/php_odbc.c: 0 out of 39
ext/openssl/openssl.c: 1 out of 42
ext/pcntl/pcntl.c: 2 out of 16
ext/pcre/php_pcre.c: 2 out of 6
ext/pdo/pdo_dbh.c: 7 out of 8
ext/pdo/pdo_stmt.c: 9 out of 10
ext/pdo_pgsql/pgsql_driver.c: 2 out of 2
ext/pdo_sqlite/sqlite_driver.c: 2 out of 2
ext/pgsql/pgsql.c: 1 out of 60
ext/phar/func_interceptors.c: 0 out of 2
ext/phar/phar_object.c: 6 out of 36
ext/posix/posix.c: 16 out of 16
ext/pspell/pspell.c: 0 out of 17
ext/readline/readline.c: 2 out of 7
ext/recode/recode.c: 0 out of 2
ext/reflection/php_reflection.c: 0 out of 33
ext/session/session.c: 0 out of 12
ext/shmop/shmop.c: 0 out of 6
ext/simplexml/simplexml.c: 1 out of 13
ext/skeleton/skeleton.c: 0 out of 1
ext/snmp/snmp.c: 0 out of 9
ext/soap/soap.c: 0 out of 15
ext/sockets/sockets.c: 0 out of 25
ext/spl/php_spl.c: 3 out of 7
ext/spl/spl_array.c: 0 out of 11
ext/spl/spl_directory.c: 0 out of 12
ext/spl/spl_dllist.c: 0 out of 14
ext/spl/spl_fixedarray.c: 0 out of 10
ext/spl/spl_heap.c: 0 out of 13
ext/spl/spl_iterators.c: 2 out of 20
ext/spl/spl_observer.c: 0 out of 11
ext/sqlite/sqlite.c: 0 out of 51
ext/sqlite3/sqlite3.c: 0 out of 16
ext/standard/image.c: 1 out of 3
ext/standard/array.c: 8 out of 59
ext/standard/assert.c: 0 out of 2
ext/standard/base64.c: 0 out of 2
ext/standard/basic_functions.c: 11 out of 44
ext/standard/browscap.c: 0 out of 1
ext/standard/crc32.c: 0 out of 1
ext/standard/crypt.c: 0 out of 1
ext/standard/head.c: 0 out of 5
ext/standard/cyr_convert.c: 0 out of 1
ext/standard/datetime.c: 0 out of 1
ext/standard/dir.c: 2 out of 5
ext/standard/dl.c: 0 out of 1
ext/standard/dns.c: 0 out of 6
Re: [PHP-DEV] Returning NULL when arg parsing fails - was: Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/pcntl pcntl.c /ext/pcntl/tests pcntl_signal.phpt
2009/4/2 Matteo Beccati p...@beccati.com: The point raised on IRC was the opposite: try and unify the code so that if parameter parsing fails returns NULL, which seems to be the standard. Indeed. But its not worth breaking backwards compatibility. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
2009/4/2 Justin Martin frozenf...@thefrozenfire.com: My proposal is a very simple one, which would add a third parameter, which would be optional, which would select between inline styling, and external styling. The proposed syntax for highlight_file would be: +1 :) -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Returning NULL when arg parsing fails - was: Re: [PHP-CVS] cvs: php-src(PHP_5_3) /ext/pcntl pcntl.c /ext/pcntl/tests pcntl_signal.phpt
Hannes Magnusson ha scritto: 2009/4/2 Matteo Beccati p...@beccati.com: The point raised on IRC was the opposite: try and unify the code so that if parameter parsing fails returns NULL, which seems to be the standard. Indeed. But its not worth breaking backwards compatibility. Yep. And I agree. It's not just a handful of functions. Cheers -- Matteo Beccati OpenX - http://www.openx.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Removing the Zend API
2009/4/1 Johannes Schlüter johan...@schlueters.de: Hi, On Wed, 2009-04-01 at 16:16 +0100, Paul Biggar wrote: I think that to handle more complex cases we need the kind of information which makes it straightforward to easily generate code to make a seamless interface between C and the engine API. The only case I had thought of was to somehow mangle structs/pointers into resources. But I suppose we need lengths for strings. I expect (many?) more of these cases will come up. Well, as soon as any pointer exists you need manual work for a special case. And even when only using integers it's not fully fast-forward: There are cases where not the full integer range is allowed but just a few flags or some specific range. C programmers will know that, passing that 1:1 to PHP userland can be bad. Well, it depends what the pointer does of course. I dont know if we need to support the general case of 'anything goes with pointers'. Instead, I had been thinking that the pointer would be a pointer to a struct, in the manner of 'OO-in-C'. For simple cases http://pecl.php.net/package/ffi might be enough, for average cases there are just a few APIs (PHP_FUNCTION, zend_parse_parameters, RETURN_*) one has to know for a start for an extensions, Hartmut's CodeGen_PECL abstracts that using some XML and then there's PEAR's Inline_C as some weird approach. I'll take a look at these, thanks for the pointers. However, the main idea is not exactly what we use, just that we no longer use the Zend API. I'd be happy to have some simple toolkit for this, but I guess it's really hard to make some easy tool which really works in average cases not just in proof-of-concept cases. This might also be interesting for other projects like ProjectZero (PHP using a JVM) or pipp (using Parrot) Yes. This is one of the motivations. In theory, Project Zero (et al) would generate their own code from the library spec. AFAIK, they currently go through the Zend API, which I believe there not too happy about. Thanks, Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
Hi Justin 2009/4/2 Justin Martin frozenf...@thefrozenfire.com: Hello everyone, I'd like to propose a very small update, which would have no backwards-compatibility problems, and would bring PHP closer to standards compliance. inline styles are standards compliant, but I know what you mean, inline styles aren't always nice to work with ;) The update I'd like to propose is to the Zend Highlighter for PHP, specifically related to the highlight_file and highlight_string functions, as well as the php -s command. My proposal is a very simple one, which would add a third parameter, which would be optional, which would select between inline styling, and external styling. The proposed syntax for highlight_file would be: mixed highlight_file (string $filename [, bool $return= false [, bool $inline= true]]); Currently, syntax highlighting is done inline, by means of the style attribute of the span tag (span style=color: #FF.../span). My proposition would be for a class attribute to be set instead of the style attribute, based on the value of $inline (span class=phpcomment.../span). I have written a quick and easy patch for this [1], which instead of adding a new parameter to the highlight functions adds 6 new ini settings: highlight.inline_class (yes I know the name is weird, but thought it was better than highlight.use_classes or similar) highlight.class_(comment|default|keyword|html|string) Each of the highlight.class_* sets a default class to use, these are editable so they won't conflict with class names your style might have defined to something else, therefore making it more modular. A simple: $ php -d highlight.inline_class=1 -s -f file.php Will now give: span class=xxxspan class=yyy.../span/span Instead of before giving: span style=color: xxxspan style=color: yyy.../span/span I thought using ini settings was more in place with how the current API works so I went that way. The patch isn't perfect but it does its job, note that its written for PHP_5_3, but since we're in RC stage theres really no chance of it getting added. The issue this modification is intended to fix is that many developers who intend to provide syntax highlighting in their project end up rolling their own code for such. By providing external styling code rather than inline styling, it makes it possible to modify the style of all highlighted code, without modifying the code itself. It also provides the capability to extend the viewing experience with Javascript, such as code folding functionality. I've taken the liberty to produce a very quick and dirty patch, which is by no means complete, but provides a cursory example of what I intend. I'd like to clarify that this is the first time I've modified PHP's code, and I know very little C. The only modifications I've done for PHP in the past have been in the PHP-GTK branch, attempting to fix the documentation generator to work with the non-standard extension structure. If I've submitted my proposal poorly, I apologize. Please offer any comments you have. Thank you, Justin Martin aka FrozenFire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php [1] http://www.paste2.org/p/176166 -- Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
2009/4/2 Kalle Sommer Nielsen ka...@php.net:
Hi Justin
Attached a patch instead, hopefully this will work ;)
--
Kalle Sommer Nielsen
ka...@php.net
Index: ZendEngine2/zend_highlight.c
===
RCS file: /repository/ZendEngine2/zend_highlight.c,v
retrieving revision 1.49.2.3.2.2.2.6
diff -u -r1.49.2.3.2.2.2.6 zend_highlight.c
--- ZendEngine2/zend_highlight.c31 Dec 2008 11:15:32 -
1.49.2.3.2.2.2.6
+++ ZendEngine2/zend_highlight.c2 Apr 2009 11:29:45 -
@@ -90,34 +90,41 @@
ZEND_API void zend_highlight(zend_syntax_highlighter_ini
*syntax_highlighter_ini TSRMLS_DC)
{
zval token;
+ zend_bool inline_class = syntax_highlighter_ini-inline_class;
int token_type;
- char *last_color = syntax_highlighter_ini-highlight_html;
- char *next_color;
+ char *last_value = syntax_highlighter_ini-highlight_html;
+ char *next_value;
zend_printf(code);
- zend_printf(span style=\color: %s\\n, last_color);
+
+ if (inline_class) {
+ zend_printf(span class=\%s\\n, last_value);
+ } else {
+ zend_printf(span style=\color: %s;\\n, last_value);
+ }
+
/* highlight stuff coming back from zendlex() */
token.type = 0;
while ((token_type=lex_scan(token TSRMLS_CC))) {
switch (token_type) {
case T_INLINE_HTML:
- next_color =
syntax_highlighter_ini-highlight_html;
+ next_value =
syntax_highlighter_ini-highlight_html;
break;
case T_COMMENT:
case T_DOC_COMMENT:
- next_color =
syntax_highlighter_ini-highlight_comment;
+ next_value =
syntax_highlighter_ini-highlight_comment;
break;
case T_OPEN_TAG:
case T_OPEN_TAG_WITH_ECHO:
- next_color =
syntax_highlighter_ini-highlight_default;
+ next_value =
syntax_highlighter_ini-highlight_default;
break;
case T_CLOSE_TAG:
- next_color =
syntax_highlighter_ini-highlight_default;
+ next_value =
syntax_highlighter_ini-highlight_default;
break;
case '':
case T_ENCAPSED_AND_WHITESPACE:
case T_CONSTANT_ENCAPSED_STRING:
- next_color =
syntax_highlighter_ini-highlight_string;
+ next_value =
syntax_highlighter_ini-highlight_string;
break;
case T_WHITESPACE:
zend_html_puts(LANG_SCNG(yy_text),
LANG_SCNG(yy_leng) TSRMLS_CC); /* no color needed */
@@ -126,20 +133,24 @@
break;
default:
if (token.type == 0) {
- next_color =
syntax_highlighter_ini-highlight_keyword;
+ next_value =
syntax_highlighter_ini-highlight_keyword;
} else {
- next_color =
syntax_highlighter_ini-highlight_default;
+ next_value =
syntax_highlighter_ini-highlight_default;
}
break;
}
- if (last_color != next_color) {
- if (last_color !=
syntax_highlighter_ini-highlight_html) {
+ if (last_value != next_value) {
+ if (last_value !=
syntax_highlighter_ini-highlight_html) {
zend_printf(/span);
}
- last_color = next_color;
- if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(span style=\color: %s\,
last_color);
+ last_value = next_value;
+ if (last_value !=
syntax_highlighter_ini-highlight_html) {
+ if (inline_class) {
+ zend_printf(span class=\%s\,
last_value);
+ } else {
+ zend_printf(span style=\color:
%s;\, last_value);
+ }
}
}
switch (token_type) {
@@ -172,18 +183,22 @@
/* handler for trailing comments, see bug #42767 */
if (LANG_SCNG(yy_leng) LANG_SCNG(yy_text) LANG_SCNG(yy_limit)) {
- if (last_color !=
Re: [PHP-DEV] Update to Zend Highlighter
2009/4/2 Kalle Sommer Nielsen ka...@php.net: 2009/4/2 Kalle Sommer Nielsen ka...@php.net: Hi Justin Attached a patch instead, hopefully this will work ;) I really do like this idea :) Let's just commit it. I would however like ot see the naming stucture Justin used in the first example by prefixing the CSS classnames by php. This will greatly help the inclusion into other considering that comment and default are widely used (not sure about the other ones) for general purposes usage (see google codesearch for example). Cool work, do we go by adding 6 new ini settings and making sure they are prefixed by default? Also I guess we'll have to attach a css file with that? Inline css at the top of the generated highlighted block maybe? -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
On Thu, 2009-04-02 at 15:36 +0100, David Coallier wrote: Also I guess we'll have to attach a css file with that? Inline css at the top of the generated highlighted block maybe? I thought the purpose was to allow external styling? Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
David Coallier wrote: 2009/4/2 Kalle Sommer Nielsen ka...@php.net: 2009/4/2 Kalle Sommer Nielsen ka...@php.net: Hi Justin Attached a patch instead, hopefully this will work ;) I really do like this idea :) Let's just commit it. Hold your horses, lets not commit things hastily. I'm not a huge fan of adding 6 new INI settings and I think have another idea so we can avoid this and still offer more flexibility. I would however like ot see the naming stucture Justin used in the first example by prefixing the CSS classnames by php. This will greatly help the inclusion into other considering that comment and default are widely used (not sure about the other ones) for general purposes usage (see google codesearch for example). Cool work, do we go by adding 6 new ini settings and making sure they are prefixed by default? Also I guess we'll have to attach a css file with that? Inline css at the top of the generated highlighted block maybe? No, the user would be responsible for producing the CSS sheet that they want. Scott -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
Hi David 2009/4/2 David Coallier dav...@php.net: 2009/4/2 Kalle Sommer Nielsen ka...@php.net: 2009/4/2 Kalle Sommer Nielsen ka...@php.net: Hi Justin Attached a patch instead, hopefully this will work ;) I really do like this idea :) Let's just commit it. I would however like ot see the naming stucture Justin used in the first example by prefixing the CSS classnames by php. This will greatly help the inclusion into other considering that comment and default are widely used (not sure about the other ones) for general purposes usage (see google codesearch for example). We can just change the default values in zend_highlight.h to be prefixed php-xxx aswell as in the ini. Cool work, do we go by adding 6 new ini settings and making sure they are prefixed by default? Also I guess we'll have to attach a css file with that? Inline css at the top of the generated highlighted block maybe? If a user wants to use css classes for highlight, then he will have his own styling. I don't think we should attempt to fix it on php level if this feature is enabled by adding a style section. -- Slan, David -- Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
Hi Scott 2009/4/2 Scott MacVicar scott...@php.net: David Coallier wrote: 2009/4/2 Kalle Sommer Nielsen ka...@php.net: 2009/4/2 Kalle Sommer Nielsen ka...@php.net: Hi Justin Attached a patch instead, hopefully this will work ;) I really do like this idea :) Let's just commit it. Hold your horses, lets not commit things hastily. I'm not a huge fan of adding 6 new INI settings and I think have another idea so we can avoid this and still offer more flexibility. Sure 6 new INI settings sounds alot, but thinking about it theres already 6 to control the current (bg, default, comment, html, keyword string) and 5 of these new ones is to control classes if theres a class naming conflict then a user can customize. So only one setting is needed to enable this feature. But if you have a better way around this then I'm all ears :) I would however like ot see the naming stucture Justin used in the first example by prefixing the CSS classnames by php. This will greatly help the inclusion into other considering that comment and default are widely used (not sure about the other ones) for general purposes usage (see google codesearch for example). Cool work, do we go by adding 6 new ini settings and making sure they are prefixed by default? Also I guess we'll have to attach a css file with that? Inline css at the top of the generated highlighted block maybe? No, the user would be responsible for producing the CSS sheet that they want. Scott -- Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
On Thu, 2009-04-02 at 16:45 +0200, Kalle Sommer Nielsen wrote:
Hi Scott
2009/4/2 Scott MacVicar scott...@php.net:
David Coallier wrote:
2009/4/2 Kalle Sommer Nielsen ka...@php.net:
2009/4/2 Kalle Sommer Nielsen ka...@php.net:
Hi Justin
Attached a patch instead, hopefully this will work ;)
I really do like this idea :) Let's just commit it.
Hold your horses, lets not commit things hastily. I'm not a huge fan of
adding 6 new INI settings and I think have another idea so we can avoid
this and still offer more flexibility.
Sure 6 new INI settings sounds alot, but thinking about it theres
already 6 to control the current (bg, default, comment, html, keyword
string) and 5 of these new ones is to control classes if theres a
class naming conflict then a user can customize. So only one setting
is needed to enable this feature.
But if you have a better way around this then I'm all ears :)
Wrap the whole highlighted block in a div with a class:
div class=php-highlighted-code
/div
Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:
div.php-highlighted-code span.keyword { color: red; }
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] double to long conversion change
Hi Dmitry,
- Original Message -
From: Dmitry Stogov
Sent: Thursday, April 02, 2009
Hi Matt,
I tried to look into this issue once again, but I completely misunderstand
why do we need all this magic. Why do we need conversion of positive
double into negative long?
I don't really have any more information than what has been given in my
various earlier messages that I've referenced. :-) But it's no problem!
It's probably too much to keep track of, or try to find which message I said
something in, I know (I have to do that myself to refresh memory about some
parts). So feel free to ask for an explanation about anything. :-)
OK, regarding conversion of postive double into negative long (or it could
be positive if it rolls over again above ULONG_MAX, etc...): 1) for me,
the original issue I noticed, is preserving the least significant bits when
using bitwise AND on a large number (old ref again: [1]). Although now I
know the 5.2 behavior I was getting can't be relied on (= ULONG_MAX it's
probably OK however), that's what I'm trying to do -- make conversions
consistent and reliable. And 2) unsigned specifiers in sprintf() (%u, %x,
etc.) rely on this conversion (though it currently *won't work* in 5.3 on
64-bit non-Windows). See references in Bugs #30695 and #42868.
[1] http://marc.info/?l=php-internalsm=120799720922202w=2
The magic (different methods...?) is needed depending on what type of
conversion works on a platform. BTW, I wasn't satisfied with what I ended
up with for my patch (unsure about how some things would behave, some
guessing), so a few days ago I started to try coming up with something more
complete and precise depending on what works on a platform. Not done yet,
and will need to add some configure checks, etc. (new for me).
I would stay with single DVAL_TO_LVAL() definition and use it in places
instead of (long)Z_DVAL().
That (single DVAL_TO_LVAL()) is basically what 5.2 has now until you added
more definitions (from Zoe) ;-) (which behave differently [2]) for 5.3 in
Nov '07 for Bug #42868.
[2] http://marc.info/?l=php-internalsm=123496364812725w=2
#define DVAL_TO_LVAL(d, l) \
if ((d) LONG_MAX) { \
(l) = LONG_MAX; \
} else if ((d) LONG_MIN) { \
(l) = LONG_MIN; \
} else {\
(l) = (long) (d); \
}
That's close to 5.3's new version (depending which is used for a platform),
and *precisely* what was committed to zend_operators.c in Sep '04 (v1.195
Resolve undefined behavior (joe at redhat) [3]). After Bug #30695, it was
reverted in Nov: v1.203 Revert Joe's work around a bug in GCC patch as it
breaks too many things. [4]
[3]
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_operators.c?r1=1.194r2=1.195view=patch
[4]
http://cvs.php.net/viewvc.cgi/ZendEngine2/zend_operators.c?r1=1.202r2=1.203view=patch
- Matt
Or may be we need a second macro for conversion into unsigned long where
it needed?
#define DVAL_TO_ULONG(d, l) \
if ((d) ULONG_MAX) { \
(l) = ULONG_MAX; \
} else if ((d) 0) { \
(l) = 0; \
} else {\
(l) = (unsigned long) (d); \
}
It also possible to add notices in case of overflow detection.
Thanks. Dmitry.
Matt Wilmas wrote:
Hi all,
Since noticing and reporting last year [1] different behavior when
casting out-of-range doubles to int after the DVAL_TO_LVAL() macro was
updated, I've wondered how to get the behavior I observed, and thought
could be relied on (that was wrong to think, since it was un- or
implementation-defined), back. And how to do so (what should be
expected?), while keeping in mind the reason for the change: consistent
behavior for tests. [2] Except that the current code does not give
consistent results, depending on which DVAL_TO_LVAL definition is used on
a platform. [3]
[1] http://marc.info/?l=php-internalsm=120799720922202w=2
[2] http://marc.info/?l=php-internalsm=123495655802226w=2
[3] http://marc.info/?l=php-internalsm=123496364812725w=2
So after I finally started to test my ideas for consistent/reliable
overflow across platforms a few days ago, I noticed that my workaround
technique quit working (0 instead of overflow) with doubles over 2^63,
without resorting to fmod(). That's on Windows, but I suspect the same
may happen on other systems that are limited to 64-bit integer processing
internally or something (32-bit platforms?). On 64-bit Linux anyway, it
looks like doubles 2^63 do rollover as expected (128-bit internal
processing?): http://marc.info/?l=php-internalsm=123376495021789w=2
I wasn't sure how to rethink things after that... But of course with
doubles, precision has been lost long before 2^63 anyway, as far as
increments of 1 (it's 1024 at 2^63).
What I wound up with for now, is using 5.2's method on 64-bit platforms,
and on 32-bit, overflow behavior should be reliable up to 2^63 on
platforms that have zend_long64 type available (long long, __int64),
which I'm guessing is most (?), because of the unsigned long involvement.
Finally a fallback workaround
Re: [PHP-DEV] Update to Zend Highlighter
On Thu, Apr 2, 2009 at 8:02 AM, Robert Cummings rob...@interjinn.com wrote:
Wrap the whole highlighted block in a div with a class:
div class=php-highlighted-code
/div
Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:
div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the default names.
mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);
comment|default|keyword|html|string)
Array(
'div_wrapper' = 'xyz-cms-div-wrapper',
'default' = 'xyz-cms-default',
'etc' = 'xyz-cms-etc',
);
The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
Hi Chris
2009/4/2 Chris Stockton chrisstockto...@gmail.com:
On Thu, Apr 2, 2009 at 8:02 AM, Robert Cummings rob...@interjinn.com wrote:
Wrap the whole highlighted block in a div with a class:
div class=php-highlighted-code
/div
Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:
div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the default names.
mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);
comment|default|keyword|html|string)
Array(
'div_wrapper' = 'xyz-cms-div-wrapper',
'default' = 'xyz-cms-default',
'etc' = 'xyz-cms-etc',
);
The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.
I must honest, I don't really like this approach (passing an array
with class names), I think INI calls are better, or even better if we
wrap it all into a Highlight class which could make the API alot
easier not only for classes, but also inline colors and perhaps even
more options later on.
-Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
On Thu, 2009-04-02 at 09:13 -0700, Chris Stockton wrote:
On Thu, Apr 2, 2009 at 8:02 AM, Robert Cummings rob...@interjinn.com wrote:
Wrap the whole highlighted block in a div with a class:
div class=php-highlighted-code
/div
Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:
div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the default names.
mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);
comment|default|keyword|html|string)
Array(
'div_wrapper' = 'xyz-cms-div-wrapper',
'default' = 'xyz-cms-default',
'etc' = 'xyz-cms-etc',
);
The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.
To be honest I don't think it's necessary, and on further reflection I
don't think you even need to offer an INI setting to change the class
name since if you want different styling you can merely wrap the the
main div in your own div and use another hierarchical level:
div class=alt-highlighting
div class=php-highlighted-code
/div
/div
And the css:
div.alt-highlighting div.php-highlighted-code span.keyword
{
color: blue;
}
So being able to change the outer class name seems redundant.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] double to long conversion change
Hi Matt: On Sat, Mar 14, 2009 at 09:30:42AM -0500, Matt Wilmas wrote: But of course with doubles, precision has been lost long before 2^63 anyway, as far as increments of 1 (it's 1024 at 2^63). I just ran into these issues in PHP 5.2.8 on 64 bit Linux while running examples I'm using to improve our documentation surrounding bitwise operators, bindec() and decbin(). The integer float conversions start failing above 2^53, meaning 9007199254740993 is the first integer that doesn't work. As you noted, ints divisible by 1024 are fine. I can provide the test script to anyone who needs it. A bash script I put together makes it look like things work correctly in the shell. So it seems this is a PHP thing, not a Linux thing. Am I correct in believing your changes will take care of these issues? It seems you're looking to patch 5.3 and HEAD. Are there thoughts of applying this to 5.2? Thanks, --Dan Note: The guy who put the box together says everything on it is built against 64 bit libraries. -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
Why not allow a class prefix as an option to the function?
Eg:
'php-highlighted-' as the prefix would produce things like
'php-highlighted-keyword'.
That way there's no risk of collision and there's no need to
over-complicated things.
2009/4/2 Robert Cummings rob...@interjinn.com:
On Thu, 2009-04-02 at 09:13 -0700, Chris Stockton wrote:
On Thu, Apr 2, 2009 at 8:02 AM, Robert Cummings rob...@interjinn.com wrote:
Wrap the whole highlighted block in a div with a class:
div class=php-highlighted-code
/div
Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:
div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the default names.
mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);
comment|default|keyword|html|string)
Array(
'div_wrapper' = 'xyz-cms-div-wrapper',
'default' = 'xyz-cms-default',
'etc' = 'xyz-cms-etc',
);
The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.
To be honest I don't think it's necessary, and on further reflection I
don't think you even need to offer an INI setting to change the class
name since if you want different styling you can merely wrap the the
main div in your own div and use another hierarchical level:
div class=alt-highlighting
div class=php-highlighted-code
/div
/div
And the css:
div.alt-highlighting div.php-highlighted-code span.keyword
{
color: blue;
}
So being able to change the outer class name seems redundant.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
Hi, On Wed, 2009-04-01 at 20:47 -0700, Justin Martin wrote: The update I'd like to propose is to the Zend Highlighter for PHP, specifically related to the highlight_file and highlight_string functions, as well as the php -s command. I don't see the need for a rush (or in other words: 5.3 can happily live without it imo) and for the general consideration there's still my patch from 2005 using a ol to have line numbers and adding id's so lines can directly be accessed by an URL. http://schlueters.de/~johannes/php/zend_highlight_20050312_1.diff About ini settings: We should avoid adding them as much as possible, making this an ini setting gives you trouble in case the admin plays with them for some reason and you don't overwrite them in the script, on the other hand it's the only way to make it work with php -s and the apache sapi's application/x-httpd-php-source. So in summary: Let's think carefully about this before committing the first idea which comes to mind. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
On Thu, 2009-04-02 at 17:38 +0100, Lewis Wright wrote: Why not allow a class prefix as an option to the function? Eg: 'php-highlighted-' as the prefix would produce things like 'php-highlighted-keyword'. That way there's no risk of collision and there's no need to over-complicated things. It's repetitive and redundant. A single class in an encapsulating tag is sufficient to target every rule within the block. That's how CSS is supposed to work. Unfortunately, I'll grant that many people using CSS just make all their class definitions global, or worse, use IDs for nothing but CSS styling. Cheers, Rob. -- http://www.interjinn.com Application and Templating Framework for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
I'm really liking the INI idea, including setting the default class names for each element. However, I think it would be nice to have an optional parameter to the functions to allow call-specific settings for such things. This way, one can highlight their code in different ways, in different contexts. As well, although I realise we are already in RC, this can be added to subsequent versions of both 5_2 and 5_3. Since it's rather backwards-compatible, such shouldn't be an issue. Another thing I'd like to ask is, would anyone be interested in writing a more robust syntax highlighter? Currently, highlighting is restricted to only a handful of available colours. It would be nice to be able to have both general default style for code types (comment, keyword, etc), as well as token-specific styling. This way, a truly robust syntax highlighter is possible. It is probably a fairly large job, and certainly not one that would be just committed, but I believe it would be of benefit to developers. Thanks, Justin Kalle Sommer Nielsen wrote: Hi Justin 2009/4/2 Justin Martin frozenf...@thefrozenfire.com: Hello everyone, I'd like to propose a very small update, which would have no backwards-compatibility problems, and would bring PHP closer to standards compliance. inline styles are standards compliant, but I know what you mean, inline styles aren't always nice to work with ;) The update I'd like to propose is to the Zend Highlighter for PHP, specifically related to the highlight_file and highlight_string functions, as well as the php -s command. My proposal is a very simple one, which would add a third parameter, which would be optional, which would select between inline styling, and external styling. The proposed syntax for highlight_file would be: mixed highlight_file (string $filename [, bool $return= false [, bool $inline= true]]); Currently, syntax highlighting is done inline, by means of the style attribute of the span tag (span style=color: #FF.../span). My proposition would be for a class attribute to be set instead of the style attribute, based on the value of $inline (span class=phpcomment.../span). I have written a quick and easy patch for this [1], which instead of adding a new parameter to the highlight functions adds 6 new ini settings: highlight.inline_class (yes I know the name is weird, but thought it was better than highlight.use_classes or similar) highlight.class_(comment|default|keyword|html|string) Each of the highlight.class_* sets a default class to use, these are editable so they won't conflict with class names your style might have defined to something else, therefore making it more modular. A simple: $ php -d highlight.inline_class=1 -s -f file.php Will now give: span class=xxxspan class=yyy.../span/span Instead of before giving: span style=color: xxxspan style=color: yyy.../span/span I thought using ini settings was more in place with how the current API works so I went that way. The patch isn't perfect but it does its job, note that its written for PHP_5_3, but since we're in RC stage theres really no chance of it getting added. The issue this modification is intended to fix is that many developers who intend to provide syntax highlighting in their project end up rolling their own code for such. By providing external styling code rather than inline styling, it makes it possible to modify the style of all highlighted code, without modifying the code itself. It also provides the capability to extend the viewing experience with Javascript, such as code folding functionality. I've taken the liberty to produce a very quick and dirty patch, which is by no means complete, but provides a cursory example of what I intend. I'd like to clarify that this is the first time I've modified PHP's code, and I know very little C. The only modifications I've done for PHP in the past have been in the PHP-GTK branch, attempting to fix the documentation generator to work with the non-standard extension structure. If I've submitted my proposal poorly, I apologize. Please offer any comments you have. Thank you, Justin Martin aka FrozenFire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php [1] http://www.paste2.org/p/176166 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
Why not just re-use the same highlight.*, they can be colors or classes...
span class=%highlight.comment% or span style=color:
%highlight.comment
you switch this based on highlight.use_external_styles. You could also
add a: highlight.add_stylesheet
to add a default stylesheet created by PHP...
- Davey
Lewis Wright wrote:
Why not allow a class prefix as an option to the function?
Eg:
'php-highlighted-' as the prefix would produce things like
'php-highlighted-keyword'.
That way there's no risk of collision and there's no need to
over-complicated things.
2009/4/2 Robert Cummingsrob...@interjinn.com:
On Thu, 2009-04-02 at 09:13 -0700, Chris Stockton wrote:
On Thu, Apr 2, 2009 at 8:02 AM, Robert Cummingsrob...@interjinn.com wrote:
Wrap the whole highlighted block in a div with a class:
div class=php-highlighted-code
/div
Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:
div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the default names.
mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);
comment|default|keyword|html|string)
Array(
'div_wrapper' = 'xyz-cms-div-wrapper',
'default' = 'xyz-cms-default',
'etc' = 'xyz-cms-etc',
);
The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.
To be honest I don't think it's necessary, and on further reflection I
don't think you even need to offer an INI setting to change the class
name since if you want different styling you can merely wrap the the
main div in your own div and use another hierarchical level:
div class=alt-highlighting
div class=php-highlighted-code
/div
/div
And the css:
div.alt-highlighting div.php-highlighted-code span.keyword
{
color: blue;
}
So being able to change the outer class name seems redundant.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
I do like using the same INI setting name which depends on the
use_external_styles setting.
However, no stylesheet should be automatically included. The highlight
functions do not produce a whole page, except in the case of a .phps
(PHP Source file). It should be up to the user to manage how they want
their stylesheet included.
Thanks,
Justin
Davey Shafik wrote:
Why not just re-use the same highlight.*, they can be colors or classes...
span class=%highlight.comment% or span style=color:
%highlight.comment
you switch this based on highlight.use_external_styles. You could also
add a: highlight.add_stylesheet
to add a default stylesheet created by PHP...
- Davey
Lewis Wright wrote:
Why not allow a class prefix as an option to the function?
Eg:
'php-highlighted-' as the prefix would produce things like
'php-highlighted-keyword'.
That way there's no risk of collision and there's no need to
over-complicated things.
2009/4/2 Robert Cummingsrob...@interjinn.com:
On Thu, 2009-04-02 at 09:13 -0700, Chris Stockton wrote:
On Thu, Apr 2, 2009 at 8:02 AM, Robert
Cummingsrob...@interjinn.com wrote:
Wrap the whole highlighted block in a div with a class:
div class=php-highlighted-code
/div
Add one more INI setting to change that class. Let users leverage
hierarchical CSS rules:
div.php-highlighted-code span.keyword { color: red; }
I like that, and would further elaborate instead of INI changes etc,
allow a key-value pair array to be passed as a third argument. Perhaps
ini changes could be the default names.
mixed highlight_file (string $filename [, bool $return= false [, array
$class_names]]);
comment|default|keyword|html|string)
Array(
'div_wrapper' = 'xyz-cms-div-wrapper',
'default' = 'xyz-cms-default',
'etc' = 'xyz-cms-etc',
);
The good thing about this as well, is for some odd or logical reason
if your using highlighting multiple times, you can change the class
names of each highlight without something like ini_set.
To be honest I don't think it's necessary, and on further reflection I
don't think you even need to offer an INI setting to change the class
name since if you want different styling you can merely wrap the the
main div in your own div and use another hierarchical level:
div class=alt-highlighting
div class=php-highlighted-code
/div
/div
And the css:
div.alt-highlighting div.php-highlighted-code span.keyword
{
color: blue;
}
So being able to change the outer class name seems redundant.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
2009/4/2 Justin Martin frozenf...@thefrozenfire.com:
Hello everyone,
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Just as an update, I reviewed my previous patch and re did it (attached).
Instead of adding the highlight.class_* INI entries, this simply adds two:
* highlight.inline_styles (default 1), set to 0 to trigger the use of classes
* highlight.class_prefix (default ), set to a class prefix of choice
to prevent naming conflicts
I thought adding a class_prefix would be better than adding a yet
another class name on the code tag, prefixing should work out just
perfect.
--
Kalle Sommer Nielsen
ka...@php.net
Index: ZendEngine2/zend_highlight.c
===
RCS file: /repository/ZendEngine2/zend_highlight.c,v
retrieving revision 1.49.2.3.2.2.2.6
diff -u -r1.49.2.3.2.2.2.6 zend_highlight.c
--- ZendEngine2/zend_highlight.c31 Dec 2008 11:15:32 -
1.49.2.3.2.2.2.6
+++ ZendEngine2/zend_highlight.c2 Apr 2009 17:59:48 -
@@ -86,37 +86,47 @@
#endif /* ZEND_MULTIBYTE */
}
-
ZEND_API void zend_highlight(zend_syntax_highlighter_ini
*syntax_highlighter_ini TSRMLS_DC)
{
zval token;
int token_type;
+ zend_bool inline_styles = syntax_highlighter_ini-inline_style;
+ char *class_prefix = syntax_highlighter_ini-class_prefix;
char *last_color = syntax_highlighter_ini-highlight_html;
+ char *class = html;
char *next_color;
zend_printf(code);
- zend_printf(span style=\color: %s\\n, last_color);
+
+ if (inline_styles) {
+ zend_printf(span style=\color: %s\\n, last_color);
+ } else {
+ zend_printf(span class=\%s%s\, class_prefix, class);
+ }
+
/* highlight stuff coming back from zendlex() */
token.type = 0;
while ((token_type=lex_scan(token TSRMLS_CC))) {
switch (token_type) {
case T_INLINE_HTML:
+ class = html;
next_color =
syntax_highlighter_ini-highlight_html;
break;
case T_COMMENT:
case T_DOC_COMMENT:
+ class = comment;
next_color =
syntax_highlighter_ini-highlight_comment;
break;
case T_OPEN_TAG:
case T_OPEN_TAG_WITH_ECHO:
- next_color =
syntax_highlighter_ini-highlight_default;
- break;
case T_CLOSE_TAG:
+ class = default;
next_color =
syntax_highlighter_ini-highlight_default;
break;
case '':
case T_ENCAPSED_AND_WHITESPACE:
case T_CONSTANT_ENCAPSED_STRING:
+ class = string;
next_color =
syntax_highlighter_ini-highlight_string;
break;
case T_WHITESPACE:
@@ -125,7 +135,9 @@
continue;
break;
default:
+ class = default;
if (token.type == 0) {
+ class = keyword;
next_color =
syntax_highlighter_ini-highlight_keyword;
} else {
next_color =
syntax_highlighter_ini-highlight_default;
@@ -139,7 +151,11 @@
}
last_color = next_color;
if (last_color !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(span style=\color: %s\,
last_color);
+ if (inline_styles) {
+ zend_printf(span style=\color:
%s\, last_color);
+ } else {
+ zend_printf(span class=\%s%s\,
class_prefix, class);
+ }
}
}
switch (token_type) {
@@ -177,7 +193,11 @@
zend_printf(/span);
}
if (syntax_highlighter_ini-highlight_comment !=
syntax_highlighter_ini-highlight_html) {
- zend_printf(span style=\color: %s\,
syntax_highlighter_ini-highlight_comment);
+ if (inline_styles) {
+ zend_printf(span style=\color:
%s\, syntax_highlighter_ini-highlight_comment);
+ } else {
Re: [PHP-DEV] GSoC - XDebug profiling web front-end
On Apr 1, 2009, at 3:33 AM, Derick Rethans wrote: I don't know what the state is tbh, but there is now also webgrind at http://code.google.com/p/webgrind/ Webgrind works, but could use some refinement. It doesn't do tree graphs yet, for one. It also doesn't support uploading files to it. -T -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
