[PHP-DEV] Re: PHP_SESSION_* constant values
Someone actually just pointed out to me that if(-1) returns true. In that case, I suppose my suggestion doesn't quite work. The reason I suggest this is that I suspect people will constantly be looking up what the constants are called. On 12-01-28 11:17 AM, Justin Martin wrote: Hello everyone, For the result of session_status(), the corresponding constants for the sessions state are - PHP_SESSION_DISABLED = 0 - PHP_SESSION_NONE = 1 - PHP_SESSION_ACTIVE = 2 I'd like to suggest we change these values to - PHP_SESSION_DISABLED = -1 - PHP_SESSION_NONE = 0 - PHP_SESSION_ACTIVE = 1 This way, one can do if(session_status()) to check if there is an active session, rather than having to compare the result to a constant. Any objections? Thanks, Justin Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP_SESSION_* constant values
Hello everyone, For the result of session_status(), the corresponding constants for the sessions state are - PHP_SESSION_DISABLED = 0 - PHP_SESSION_NONE = 1 - PHP_SESSION_ACTIVE = 2 I'd like to suggest we change these values to - PHP_SESSION_DISABLED = -1 - PHP_SESSION_NONE = 0 - PHP_SESSION_ACTIVE = 1 This way, one can do if(session_status()) to check if there is an active session, rather than having to compare the result to a constant. Any objections? Thanks, Justin Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Change bug tracker "bogus" to "not-bug"?
Hello, With some frequency, I find bugs which are not "bogus", so much as they are reported based on a misunderstanding. Usually this happens for documentation problems, where someone has misunderstood what the documentation says, or hasn't read the documentation thoroughly enough. I'd like to propose simply changing the term "bogus" to "not-bug". This would more politely and clearly indicate the nature of the way the bug is being closed, in addition to the comment that one ordinarily leaves. Those I've spoken to in php.doc agree. Any objections? Thank you, Justin Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] chroot function availability disqualifiers
Hello everyone, As a bit of proactive documentation, I'm trying to determine exactly what the disqualifying conditions are for chroot's availability in PHP. So far as I can tell, from ext/standard/dir.c, chroot is only compiled in #if defined(HAVE_CHROOT) && !defined(ZTS) && ENABLE_CHROOT_FUNC HAVE_CHROOT seems to always be set to 1 by php_config.h, so far as I can tell. ZTS, as I understand it, indicates whether PHP is being compiled threadsafe, and ENABLE_CHROOT_FUNC seems to be related to the deprecated(?) --enable-chroot-func switch. Could someone with a better understanding of the compile process illuminate me as to all of the reasons why chroot might not be available? Thanks, Justin Martin, a.k.a. FrozenFire -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Update to Zend Highlighter
Just a friendly prodding. Was this ever added? Thanks, Justin Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Closures and __FUNCTION__
I suppose it's an issue of cloning. Perhaps there's some difference
between a cloned closure and a referenced closure?
Thanks,
Justin Martin
Peter Danenberg wrote:
>> First, we define $foo and load it with NULL so that it is available for
>> referencing.
>
> It turns out loading $foo is superfluous; I can get away with just:
>
> $foo = function($foo) use (&$foo) {
>$foo();
> }
>
>> Next, in terms of program logic, we create a closure with a lexical
>> ('use') variable of a reference to $foo, which is then assigned to
>> $foo. Thus, the reference to $foo in the closure declaration now
>> points to the closure itself.
>
> That much is clear; but why $foo is all of the sudden bound within the
> closure when I use by reference (&$foo) as opposed to use by value
> ($foo) is mysterious.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Closures and __FUNCTION__
Well, it's a rather simple bit of logic.
First, we define $foo and load it with NULL so that it is available for
referencing. Next, in terms of program logic, we create a closure with a
lexical ('use') variable of a reference to $foo, which is then assigned
to $foo. Thus, the reference to $foo in the closure declaration now
points to the closure itself.
Recursion is always complicated :P
Thanks,
Justin Martin
Peter Danenberg wrote:
> Quoth Justin Martin on Pungenday, the 30th of Discord:
>> Apparently it works as such:
>>
>> $foo = NULL;
>> $foo = function($foo) use (&$foo) {
>> ...
>> }
>>
>> Still rather hackish, but better than globals I suppose?
>
> Heh; amazing. I'm not going to pretend to comprehend this hack; but
> I'll use it, nonetheless.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Closures and __FUNCTION__
In addendum I'd like to correct the syntax that I had someone in IRC test.
Apparently it works as such:
$foo = NULL;
$foo = function($foo) use (&$foo) {
...
}
Still rather hackish, but better than globals I suppose?
Thanks,
Justin Martin
Justin Martin wrote:
> Hi Peter,
>
> If I recall correctly, you can use the 'use' keyword.
>
> $factorial = function($foo) use ($factorial) {
> $factorial($foo);
> }
>
> $factorial('Hello World!');
>
> I'm still having issues compiling 5.3 on my system, so I haven't tested
> this.
>
> Thanks,
> Justin Martin
>
> Peter Danenberg wrote:
>> The original anonymous functions patch[1] contained support for
>> __FUNCTION__ as a recursion mechanism in closures, such that I should
>> be able to do something like this:
>>
>> $factorial = function($n) {
>> if ($n == 1)
>> return 1;
>> else
>> return $n * call_user_func(__FUNCTION__, $n - 1);
>>
>>
>> };
>>
>> print $factorial(3); // => 6
>>
>>
>> It fails with a warning, though:
>>
>> Warning: call_user_func() expects parameter 1 to be a valid
>> callback, function '{closure}' not found or invalid function name
>>
>> Is there another recursion mechanism for closures besides something
>> like the $GLOBALS['factorial'] hack?
>>
>> Footnotes:
>> [1] http://marc.info/?l=php-internals&m=119995982228453&w=2
>>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Closures and __FUNCTION__
Hi Peter,
If I recall correctly, you can use the 'use' keyword.
$factorial = function($foo) use ($factorial) {
$factorial($foo);
}
$factorial('Hello World!');
I'm still having issues compiling 5.3 on my system, so I haven't tested
this.
Thanks,
Justin Martin
Peter Danenberg wrote:
> The original anonymous functions patch[1] contained support for
> __FUNCTION__ as a recursion mechanism in closures, such that I should
> be able to do something like this:
>
> $factorial = function($n) {
> if ($n == 1)
> return 1;
> else
> return $n * call_user_func(__FUNCTION__, $n - 1);
>
>
> };
>
> print $factorial(3); // => 6
>
>
> It fails with a warning, though:
>
> Warning: call_user_func() expects parameter 1 to be a valid
> callback, function '{closure}' not found or invalid function name
>
> Is there another recursion mechanism for closures besides something
> like the $GLOBALS['factorial'] hack?
>
> Footnotes:
> [1] http://marc.info/?l=php-internals&m=119995982228453&w=2
>
--
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...
>
> or
>
> 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 Cummings:
>>
>>> On Thu, 2009-04-02 at 09:13 -0700, Chris Stockton wrote:
>>>
On Thu, Apr 2, 2009 at 8:02 AM, Robert
Cummings wrote:
> Wrap the whole highlighted block in a div with a class:
>
>
>
>
> 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:
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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
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 : >> 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 (...). My >> proposition would be for a "class" attribute to be set instead of the >> style attribute, based on the value of $inline (> class="phpcomment">...). > > 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: > ... > > Instead of before giving: > ... > > 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
[PHP-DEV] Update to Zend Highlighter
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.
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 (...). My
proposition would be for a "class" attribute to be set instead of the
style attribute, based on the value of $inline (...).
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
Index: Zend/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
--- Zend/zend_highlight.c 31 Dec 2008 11:15:32 - 1.49.2.3.2.2.2.6
+++ Zend/zend_highlight.c 2 Apr 2009 03:33:35 -
@@ -95,7 +95,7 @@
char *next_color;
zend_printf("");
- zend_printf("\n", last_color);
+ zend_printf("\n", last_color);
/* highlight stuff coming back from zendlex() */
token.type = 0;
while ((token_type=lex_scan(&token TSRMLS_CC))) {
@@ -139,7 +139,7 @@
}
last_color = next_color;
if (last_color != syntax_highlighter_ini->highlight_html) {
-zend_printf("", last_color);
+zend_printf("", last_color);
}
}
switch (token_type) {
@@ -177,7 +177,7 @@
zend_printf("");
}
if (syntax_highlighter_ini->highlight_comment != syntax_highlighter_ini->highlight_html) {
-zend_printf("", syntax_highlighter_ini->highlight_comment);
+zend_printf("", syntax_highlighter_ini->highlight_comment);
}
}
zend_html_puts(LANG_SCNG(yy_text), (LANG_SCNG(yy_limit) - LANG_SCNG(yy_text)) TSRMLS_CC);
Index: Zend/zend_highlight.h
===
RCS file: /repository/ZendEngine2/zend_highlight.h,v
retrieving revision 1.25.2.1.2.1.2.2
diff -u -r1.25.2.1.2.1.2.2 zend_highlight.h
--- Zend/zend_highlight.h 31 Dec 2008 11:15:32 - 1.25.2.1.2.1.2.2
+++ Zend/zend_highlight.h 2 Apr 2009 03:33:35 -
@@ -22,12 +22,12 @@
#ifndef ZEND_HIGHLIGHT_H
#define ZEND_HIGHLIGHT_H
-#define HL_COMMENT_COLOR "#FF8000"/* orange */
-#define HL_DEFAULT_COLOR "#BB"/* blue */
-#define HL_HTML_COLOR"#00"/* black */
-#define HL_STRING_COLOR "#DD"/* red */
-#define HL_BG_COLOR "#FF"/* white */
-#define HL_KEYWORD_COLOR "#007700"/* green */
+#define HL_COMMENT_COLOR "phpcomment"
+#define HL_DEFAULT_COLOR "phpdefault"
+#define HL_HTML_COLOR"phphtml"
+#define HL_STRING_COLOR "phpstring"
+#define HL_BG_COLOR "phpbackground"
+#define HL_KEYWORD_COLOR "phpkeyword"
typedef struct _zend_syntax_highlighter_ini {
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Suggestion for get_headers
Justin Martin wrote: Hi there, I have a suggestion regarding get_headers, however I do not have a knowledge of C with which to provide a patch. The function get_headers is, as most will know, used to retrieve headers generated by an HTTP request. The primary parameter to this, "string $url", is provided unencoded. Due to this, any request with special characters (i.e. a space), will return 400 BAD REQUEST. My suggestion to remedy this, would be to internally apply the function "urlencode" to the $url parameter. This would automatically encode any provided URL, while remaining transparent. Any comments? Thanks, Justin Martin Hi again, Just noticed a discrepancy in my suggestion. I hadn't taken into account that urlencode would encode everything, including parts of the domain name. A solution would have to be used to avoid this. Thanks, Justin Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Suggestion for get_headers
Hi there, I have a suggestion regarding get_headers, however I do not have a knowledge of C with which to provide a patch. The function get_headers is, as most will know, used to retrieve headers generated by an HTTP request. The primary parameter to this, "string $url", is provided unencoded. Due to this, any request with special characters (i.e. a space), will return 400 BAD REQUEST. My suggestion to remedy this, would be to internally apply the function "urlencode" to the $url parameter. This would automatically encode any provided URL, while remaining transparent. Any comments? Thanks, Justin Martin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] w32api extension
Pierre Joye wrote: Hi Justin, ... It has been moved out of php-src because the extension was not maintained. It is in PECL's cvs but has no release (still not maintained): http://cvs.php.net/viewvc.cgi/pecl/w32api/ FFI is much more powerful yes. But it has been developed independently of w32api. Cheers, Yes, I understand it is not being maintained, however I was wondering if there was any interest in "bringing it up to speed", i.e. rewrite it to work with newer versions of PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] w32api extension
Hello there, Just wondering if there is any interest in bringing w32api up to speed. The docs say it was moved to PECL as of 5.1.0, however is this not the case. Rumor has it that it was to be replaced by ffi, however again, this is not the case (ffi is in alpha and probably dead). Anyone shed some light on this issue? Regards, Justin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
