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
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
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
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
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
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
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,
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:
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
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
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
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
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
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
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
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:
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
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
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
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,
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
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
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
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
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
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_*
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
27 matches
Mail list logo
