RE: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) /zend_compile.c zend_highlight.c zend_language_parser.yzend_language_scanner.l /tests heredoc_001.phpt heredoc_002.phptheredoc_003.phpt he
On Tue, 12 Feb 2008, Andi Gutmans wrote: It's really hard to remember this stuff. Maybe we should make the system actually validate the messages when they are committed and reject the commit when tags are missing. For commits where a certain tag isn't relevant we could have an explicit way to skip it e.g. [DOC-NONE]. At least that way it's in the back (and front) of people's mind :) Uh, no thanks. I am perfectly caple of remembering if I need to use a tag or not and am not looking for somebody to hold my hands. The question is more *what* tag to use... @doc would definitely help. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Math functions (new parameter parsing)
On 13.02.2008 05:31, David Coallier wrote: As long as it's in 5_3 I believe there'll be no problems. I did the same for a few string.c functions. As long as the behavior itself doesn't change, I'd say good work :) Agree, it's ok in 5_3. We need to convert all the functions to use new param parsing API anyway. Some more tests would not hurt though =) -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Math functions (new parameter parsing)
On Feb 13, 2008 3:08 AM, Felipe Pena [EMAIL PROTECTED] wrote: Em Qua, 2008-02-13 às 01:31 +0100, Pierre Joye escreveu: Hi! On Feb 13, 2008 1:04 AM, Felipe Pena [EMAIL PROTECTED] wrote: Hi all, I made a patch for 5_3 where all functions in ext/standard/math.c use the new parameter parsing. (As was done in HEAD) I think it got lost between you and the list :) If anyone think it good, let me know, and then i'll commit it. Several tests break with the patch. Hence, i'll fix them also, if agreed. :) How do they fail? I worry a bit about BC here. There are two cases. In most part of it: 003+ Warning: acos() expects exactly 1 parameter, 2 given ... 003- Warning: Wrong parameter count for acos() ... Ok, any branch. And breaking BC: 010+ 011+ Warning: acos() expects parameter 1 to be double, string given ... 012+ NULL 010- float(1.570796327) 014+ 015+ Notice: A non well formed numeric value encountered ... I tend to think to do not break such things in 5.x. But 5.3 sounds like a good opportunity to add a notice about the bad inputs. I can't test the patch right now but does it change the result or only raises a notice? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Math functions (new parameter parsing)
On Feb 13, 2008 11:05 AM, Felipe Pena [EMAIL PROTECTED] wrote: Em Qua, 2008-02-13 às 09:47 +0100, Pierre Joye escreveu: I can't test the patch right now but does it change the result or only raises a notice? It changes the result when a string is given, and issue notice when the string starts with numeric. var_dump(acos(nonsense)); Warning: acos() expects parameter 1 to be double, string given ... NULL That's a BC but it seems to be sane to do it. It is amazing that the current version returns acos(0) (obvious but still amazing :). var_dump(acos(1000ABC)); Notice: A non well formed numeric value encountered ... float(NAN) No BC here, as far as I can tell. It returns the same result as before. Thanks for your great work! :) -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] final keyword
Em Qua, 2008-02-13 às 10:59 +0100, Sebastian Schneider escreveu:
By the way, when declared final the value couldn't be changed, anyways -
however it MUST be read-only.
I made a ***simple*** (or wrong!) patch months ago for read-only
property as you described.
http://felipe.ath.cx/diff/readonly.patch
e.g.
class foo {
private readonly $foo = array(1, 2, 3);
}
But i agree with early discussions, and with Marcus' implementation:
http://marc.info/?l=php-internalsw=2r=1s=readonlyq=b
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Math functions (new parameter parsing)
On Wed, 2008-02-13 at 08:05 -0200, Felipe Pena wrote: Em Qua, 2008-02-13 às 09:47 +0100, Pierre Joye escreveu: I can't test the patch right now but does it change the result or only raises a notice? It changes the result when a string is given, and issue notice when the string starts with numeric. var_dump(acos(nonsense)); Warning: acos() expects parameter 1 to be double, string given ... NULL var_dump(acos(1000ABC)); Notice: A non well formed numeric value encountered ... float(NAN) # php -n -derror_reporting=E_ALL -r 'var_dump(acos(ABC));' float(1.5707963267949) # php -n -derror_reporting=E_ALL -r 'var_dump(acos(100ABC));' float(NAN) That's with PHP 5.2.5. I rather like the idea of these functions not doing magical conversion like this. -- Patches/Donations: http://pecl.php.net/~jani/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Math functions (new parameter parsing)
Felipe Pena wrote: Hi all, I made a patch for 5_3 where all functions in ext/standard/math.c use the new parameter parsing. (As was done in HEAD) If anyone think it good, let me know, and then i'll commit it. Several tests break with the patch. Hence, i'll fix them also, if agreed. :) Felipe - Great work!! I'll wait for the patch to go in and then re-run the tests that I'm still trying to debug to see if they pass. Zoe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] final keyword
actually, the method SHOULD NOT be named get_status but getStatus :P
(sorry for that, but couldn't help myself - feel free to get even ;) )
By the way, when declared final the value couldn't be changed, anyways -
however it MUST be read-only.
But using a method like the one you suggested is just working around a
common code pattern which is available in other wide-spread languages
like Java, and others.
So finally, const should work with arrays or final with all class
members including attributes.
Cheers
Sebastian schrieb:
Plus as it is a constant it's value cannot be changed in the context of the
object.
However you could implement a method for this, e.g. get_status(); which then
returns an array. But the final keyword would be more comfortable
Sebastian Schneider [EMAIL PROTECTED] schrieb im Newsbeitrag
news:[EMAIL PROTECTED]
Sebastian Bergmann schrieb:
Sebastian Schneider schrieb:
public static final $bar = foobar's world;
We have the const keyword for that.
But doesn't work with arrays, e.g.
public class Result {
const DECISION_PERMIT = 0;
const DECISION_DENY = 1;
const DECISION_INDETERMINATE = 2;
const DECISION_NOT_APPLICABLE = 3;
const DECISIONS = array( 'Permit', 'Deny', 'Indeterminate',
NotApplicable' );
//
}
thus you need to work around with private/protected statics, which
seems to be incoherent to me.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Math functions (new parameter parsing)
Hello Felipe, nice work. The others already talked about the implications. And given what I can only chime in. Since so far people think it is a ok for 5.3 I wonder if we should not continue with moving towards the new parameter parsing API. In the end the best would be to get rid of the old one. Anyway thanks for the work. marcus Wednesday, February 13, 2008, 1:04:05 AM, you wrote: Hi all, I made a patch for 5_3 where all functions in ext/standard/math.c use the new parameter parsing. (As was done in HEAD) If anyone think it good, let me know, and then i'll commit it. Several tests break with the patch. Hence, i'll fix them also, if agreed. :) -- Regards, Felipe Pena. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] final keyword
Hello Felipe,
I do not like readonly, instead I would prefer a version where read and
write have separate visibility. And actually your idea seems to prevent a
second write to the value, using NULL as for detection means. Now what
happens is that a) a property that has a default value will become a const,
yet with some trickery (array conversion, ArrayObject) allowing to be
ignored. And b) when set to NULL you can do another write until you do a non
NULL write. All that said, here is my idea again:
class Foo {
private : public $bar = baz;
This does:
a) not introduce a new keyword
b) have write access private and read access public
c) is compatible with all we have right now
d) could be limited to public on the read side
(ze2-readable_properties-20060514d.diff.txt).
I even had a patch in may 2006 (ze2-readable_properties-20060516.diff.txt)
that implements the new visibility promulgate (which i thought of as a funny
solution to public read).
marcus
Wednesday, February 13, 2008, 11:18:17 AM, you wrote:
Em Qua, 2008-02-13 às 10:59 +0100, Sebastian Schneider escreveu:
By the way, when declared final the value couldn't be changed, anyways -
however it MUST be read-only.
I made a ***simple*** (or wrong!) patch months ago for read-only
property as you described.
http://felipe.ath.cx/diff/readonly.patch
e.g.
class foo {
private readonly $foo = array(1, 2, 3);
}
But i agree with early discussions, and with Marcus' implementation:
http://marc.info/?l=php-internalsw=2r=1s=readonlyq=b
Best regards,
MarcusIndex: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.316.2.8.2.2
diff -u -p -d -r1.316.2.8.2.2 zend_compile.h
--- Zend/zend_compile.h 11 May 2006 21:07:39 - 1.316.2.8.2.2
+++ Zend/zend_compile.h 16 May 2006 21:38:41 -
@@ -139,6 +139,10 @@ typedef struct _zend_try_catch_element {
/* deprecation flag */
#define ZEND_ACC_DEPRECATED 0x4
+/* property handling control */
+#define ZEND_ACC_READ_ONLY 0x08
+#define ZEND_ACC_PUB_READ 0x10
+
char *zend_visibility_string(zend_uint fn_flags);
Index: Zend/zend_language_parser.y
===
RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.160.2.4.2.1
diff -u -p -d -r1.160.2.4.2.1 zend_language_parser.y
--- Zend/zend_language_parser.y 11 May 2006 21:07:39 - 1.160.2.4.2.1
+++ Zend/zend_language_parser.y 16 May 2006 21:38:41 -
@@ -115,7 +115,7 @@
%token T_THROW
%token T_USE
%token T_GLOBAL
-%right T_STATIC T_ABSTRACT T_FINAL T_PRIVATE T_PROTECTED T_PUBLIC
+%right T_STATIC T_ABSTRACT T_FINAL T_PRIVATE T_PROTECTED T_PUBLIC T_PROMULGATE
%token T_VAR
%token T_UNSET
%token T_ISSET
@@ -500,8 +500,9 @@ method_body:
;
variable_modifiers:
- non_empty_member_modifiers { $$ = $1; }
- | T_VAR {
Z_LVAL($$.u.constant) = ZEND_ACC_PUBLIC; }
+ non_empty_member_modifiers { $$ =
$1; }
+ | non_empty_member_modifiers T_PROMULGATE { $$ = $1;
Z_LVAL($$.u.constant) |= ZEND_ACC_PUB_READ; }
+ | T_VAR
{ Z_LVAL($$.u.constant) = ZEND_ACC_PUBLIC; }
;
method_modifiers:
Index: Zend/zend_language_scanner.l
===
RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
retrieving revision 1.131.2.11
diff -u -p -d -r1.131.2.11 zend_language_scanner.l
--- Zend/zend_language_scanner.l13 Apr 2006 13:48:28 -
1.131.2.11
+++ Zend/zend_language_scanner.l16 May 2006 21:38:42 -
@@ -1063,6 +1063,10 @@ NEWLINE (\r|\n|\r\n)
return T_PUBLIC;
}
+ST_IN_SCRIPTINGpromulgate {
+ return T_PROMULGATE;
+}
+
ST_IN_SCRIPTINGunset {
return T_UNSET;
}
Index: Zend/zend_object_handlers.c
===
RCS file: /repository/ZendEngine2/zend_object_handlers.c,v
retrieving revision 1.135.2.6.2.2
diff -u -p -d -r1.135.2.6.2.2 zend_object_handlers.c
--- Zend/zend_object_handlers.c 10 May 2006 21:12:48 - 1.135.2.6.2.2
+++ Zend/zend_object_handlers.c 16 May 2006 21:38:42 -
@@ -144,20 +144,26 @@ static zval *zend_std_call_issetter(zval
return retval;
}
-static int zend_verify_property_access(zend_property_info *property_info,
zend_class_entry *ce TSRMLS_DC)
+static int zend_verify_property_access(zend_property_info *property_info,
zend_class_entry *ce, int read_write TSRMLS_DC)
{
+ if (!read_write (property_info-flags ZEND_ACC_READ_ONLY)) {
+ return 0;
+ }
switch (property_info-flags ZEND_ACC_PPP_MASK) {
case ZEND_ACC_PUBLIC:
return 1;
case
Re: [PHP-DEV] final keyword
Hey you guys,
but the construct
private : public $bar = 'foo';
addresses actually another - fairly similar - issue.
whereas I believe it's sufficient just extending the const
or final keyword, which introduces not a new language construct and
thus affects really nothing but issue.
Your syntax would be kind of helpful when addressing security related
codes, which need to encapsulate variables.
Anyway, it would be better to use getters/setters to abstract from the
actual implementation, where you can react more precise on the read
request (not knowing you called the method, however).
Cheerio,
Sebastian
Marcus Boerger schrieb:
Hello Felipe,
I do not like readonly, instead I would prefer a version where read and
write have separate visibility. And actually your idea seems to prevent a
second write to the value, using NULL as for detection means. Now what
happens is that a) a property that has a default value will become a const,
yet with some trickery (array conversion, ArrayObject) allowing to be
ignored. And b) when set to NULL you can do another write until you do a non
NULL write. All that said, here is my idea again:
class Foo {
private : public $bar = baz;
This does:
a) not introduce a new keyword
b) have write access private and read access public
c) is compatible with all we have right now
d) could be limited to public on the read side
(ze2-readable_properties-20060514d.diff.txt).
I even had a patch in may 2006 (ze2-readable_properties-20060516.diff.txt)
that implements the new visibility promulgate (which i thought of as a funny
solution to public read).
marcus
Wednesday, February 13, 2008, 11:18:17 AM, you wrote:
Em Qua, 2008-02-13 às 10:59 +0100, Sebastian Schneider escreveu:
By the way, when declared final the value couldn't be changed, anyways -
however it MUST be read-only.
I made a ***simple*** (or wrong!) patch months ago for read-only
property as you described.
http://felipe.ath.cx/diff/readonly.patch
e.g.
class foo {
private readonly $foo = array(1, 2, 3);
}
But i agree with early discussions, and with Marcus' implementation:
http://marc.info/?l=php-internalsw=2r=1s=readonlyq=b
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Hello Jani,
it is a queestion of how easy i can accomplish things. In fact I do not
want to set variables in the ini file first. I want PHP to generate them
for me automatically.
marcus
Monday, February 11, 2008, 12:06:38 PM, you wrote:
On Mon, 2008-02-11 at 10:32 +0100, Marcus Boerger wrote:
Hello Derick,
exactly why I spent the time working on this. The ability to load the
correct stuff while developing. The sapi stuff might be a better solution
for sapi specific stuff as then you do not need to pass several ini files.
marcus
Exactly how is that different from what currently is there already:
php_version = 50300
extension_dir = /some/path/${php_version}/
--Jani
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Hello Pierre,
Monday, February 11, 2008, 10:31:17 PM, you wrote:
Hi Marcus,
Nice addition, it is really handy and it'll help to solve the php.iniS mess :)
On Feb 9, 2008 3:33 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
attached is a patch against 5.3 that brings three feature
additions to INI parsing.
1) Ternary support for values
setting = ${value?1:2}
Sounds overkilled. Not like one will edit php.ini every day. I find
the classic if elseif endif clearer.
Yeah, and you can actually accomplish this with IF/ELSE.
If ${value} evaluates to true then setting becomes 1 otherwise 2.
This cannot be nested and only works for values, not for setting names.
2) if-elif-else-endif support
[IF ${value} == 1]
setting = 1
[ELIF ${value} == 2]
setting = 2
[ELSE]
setting = 3
[ENDIF]
Perfect if ELSEIF instead of ELIF (which I can't write correctly
anyway, ELSEIF comes automatically).
Fine with me
This can be nested. Alternatively we could use apache style syntax that
looks more like XML. The reason I used square brackets is that this is the
smallest change to normal INI files.
3) Add more values to INI parsing, namely:
${php.version} = 50300
${php.debug} = 0
${php.zts} = 0
${php.sapi} = CLI
Any comments?
I like it.
Thanks for your work!
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: BC break in DirectoryIterator by fix of #44018
Hello Gregory,
It is fixed now.
marcus
Monday, February 11, 2008, 6:57:09 AM, you wrote:
Gregory Beaver wrote:
Hi Marcus,
FYI, this change:
http://cvs.php.net/viewvc.cgi/php-src/ext/spl/spl_directory.c?view=diffr1=1.146r2=1.147
breaks about 20 tests in phar, it's a potentially serious BC break. I
understand the reasoning behind it, but you may find other users up in
arms. The main problem is that this line:
flags = SPL_FILE_DIR_KEY_AS_PATHNAME|SPL_FILE_DIR_CURRENT_AS_SELF;
Important correction: the offending line is actually:
flags = 0;
in the previous if() {} block.
returns the DirectoryIterator object as current instead of an
SplFileInfo as it used to return. If you instead use:
flags = SPL_FILE_DIR_KEY_AS_PATHNAME|SPL_FILE_DIR_CURRENT_AS_FILEINFO;
this will at least keep the current behavior of a SplFileInfo class
being returned.
Perhaps the better course of action would be to correct the
documentation rather than the behavior? People upgrading from 5.2.5 to
5.2.6 will have a nasty shock if they relied upon the default
constructor parameters, and even if it is reverted in 5.2.x and kept in
5.3.x, the same problem holds.
In other words, the best fix for this is to change the default value of
$flags in the documentation of the constructor, not to change the
behavior to match faulty docs. This is especially true since the value
of the constant CURRENT_AS_FILEINFO was (incorrectly) set to 0 in the
SPL module startup instead of the expected value - technically, the
documentation (which says $flags = 0) is really saying $flags =
CURRENT_AS_FILEINFO|KEY_AS_PATHNAME because it wasn't until this commit
(http://cvs.php.net/viewvc.cgi/php-src/ext/spl/spl_directory.c?r1=1.146r2=1.147)
that you changed those values to non-zero. The fact that the constant
was changed to the actual expected/documented value does not change the
fact that it's not a good reason to break BC.
Greg
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] QA reports
Hi - I always assumed that it was intentional that the test results were sent to [EMAIL PROTECTED] (and I have a mail filter set up to deal with them). After some discussion on IRC it appears that they should be going to [EMAIL PROTECTED] This would be much better as they currently tend to drown and discussion on [EMAIL PROTECTED] I think fixing this is a one line change to qaweb/buildtest-process.php, I'm happy to make that if there is agreement. Please let me know if it isn't as simple as this. Thanks, Zoe -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Conditional INI support
Hello Andi, Pierre,
Monday, February 11, 2008, 7:49:04 PM, you wrote:
Hi Marcus,
In general I think conditional INI support can benefit many of our
users. We just need to make sure that we cover the most common needs and
also that we keep it very basic and simple so that we don't boil the
ocean and maintain two languages. So it's a balance we need to meet.
Right
It would be very helpful that as part of the feedback loop you write
something a bit more detailed about this feature and what is and isn't
supported. I imagine most people on this list would have a hard time to
figure that out from the patch. This includes:
- What operators are supported in conditionals
, =, , =, ==, !=, , || all use atoi
[${left} ${right}] - atoi(${left}) atoi(${right})
=== and !== are string comparisons
[${left} === ${right}] - !strcmp(${lect}, ${right})
Instead of === and !== I could have introduced functions like strcmp but I
wanted to keep it as simple as possible for the lexer as well as the user.
The only thing I might want to add is !. But that would be unary and
increase complexity.
- Are there any functions like empty() or is the ternary operator the
proposed solution for that?
None, though instead of empty() you can do: ${var}===
- Is it possible to get to environment variables from this? If so how is
it namespaced? How about registry on Windows?
Anything the ini allows today is possible, no changes, values are evaluated
just as in assignments of the ini file.
- What happens when you use a variable which is not set?
- Do you propose a solution for concatenation of two values or is this
outside the scope?
afaik th eini allows that already
- Can each [IF] include multiple conditionals i.e. $(value) 1 AND
$(value) 5 or just one condition with the expectation that people will
use nesting.
Nesting is supported as well as braces. So the following works:
[(${a} ${b}) (${c} ${d})]
A few specific feedbacks:
- Ternary operator's syntax is a bit weird. My preference would be not
to have such an operator and require using [if ..] so that it's very
clear what's pre-processed even if it requires a bit more works. We
don't want the INI files to become too cryptic. Also the syntax would be
better formed as ${value}?1:2 but again I think it's better not to have
it.
That seems the common response her. I'll drop it.
- I would prefer to see [ELSEIF] instead of [ELIF] to be consistent with
PHP. It would look weird for the same solution to have two approaches to
this.
Both of you guys say the same for the same reasons., so I changed that
as well.
Also I reduced the number of added values to 'php.zts' and 'php.debug'.
Maybe we can add those two as consts (Pierre?).
regards
marcus
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 09, 2008 6:33 AM
To: PHP Internals List
Subject: [PHP-DEV] [RFC] Conditional INI support
Hello PHPlers,
attached is a patch against 5.3 that brings three feature additions
to INI parsing.
1) Ternary support for values
setting = ${value?1:2}
If ${value} evaluates to true then setting becomes 1 otherwise 2.
This cannot be nested and only works for values, not for setting
names.
2) if-elif-else-endif support
[IF ${value} == 1]
setting = 1
[ELIF ${value} == 2]
setting = 2
[ELSE]
setting = 3
[ENDIF]
This can be nested. Alternatively we could use apache style syntax
that
looks more like XML. The reason I used square brackets is that this is
the smallest change to normal INI files.
3) Add more values to INI parsing, namely:
${php.version} = 50300
${php.debug} = 0
${php.zts} = 0
${php.sapi} = CLI
Any comments?
Best regards,
Marcus
Best regards,
MarcusIndex: main/php_ini.c
===
RCS file: /repository/php-src/main/php_ini.c,v
retrieving revision 1.136.2.4.2.15.2.7
diff -u -p -d -r1.136.2.4.2.15.2.7 php_ini.c
--- main/php_ini.c 3 Feb 2008 14:35:59 - 1.136.2.4.2.15.2.7
+++ main/php_ini.c 13 Feb 2008 16:20:26 -
@@ -20,6 +20,7 @@
#include php.h
#include ext/standard/info.h
+#include ext/standard/basic_functions.h
#include zend_ini.h
#include zend_ini_scanner.h
#include php_ini.h
@@ -328,6 +329,32 @@ static void php_load_zend_extension_cb(v
}
/* }}} */
+PHPAPI void php_ini_add_config_stringl(const char* name, int name_size, const
char *value, int value_len TSRMLS_DC) /* {{{*/
+{
+ zval tmp;
+ ZVAL_STRINGL(tmp, zend_strndup(value, value_len), value_len, 0);
+ Z_SET_REFCOUNT(tmp, 0);
+ Z_UNSET_ISREF(tmp);
+ zend_hash_update(configuration_hash, name, name_size, (void *) tmp,
sizeof(zval), NULL);
+} /* }}} */
+
+PHPAPI void php_ini_add_config_string(const char* name, int name_size, const
char *value TSRMLS_DC) /* {{{*/
+{
+ php_ini_add_config_stringl(name, name_size, value, strlen(value)
TSRMLS_CC);
+} /* }}} */
+
+PHPAPI
[PHP-DEV] [RFC] prepend_include_path()/append_include_path()
Hi everyone, the following patch[1] adds the functions append_include_path() and prepend_include_path(). These function are there to make include path adjustments easier than it is. Especially append_include_path() is what is done most of the time. The current patch is in a bit hacky state, as I have my doubts whether storing the include paths as a string is a good idea. I want to gain some feedback for this addition first before I invest more work on it. [1] http://lars.schokokeks.org/php/include_path_modifiers-1.diff cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: QA reports
Hi, On Wed, 2008-02-13 at 16:00 +, zoe wrote: I think fixing this is a one line change to qaweb/buildtest-process.php, I'm happy to make that if there is agreement. Please let me know if it isn't as simple as this. As somebody said on IRC, too: Please also change run-tests.php for advising people to use that list for sending in reports, too. (Whereas general test-related discussion stuff should go to qa@) Thanks, johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] build failure on windows PHP_5_2
Edward Z. Yang wrote: Steph Fox wrote: Rob's download page is at http://ctindustries.net/libxml/ if anyone needs to update their libxml copy locally. Just a quick note: the new files don't seem to work properly with 5.2.5 unless you update ext/libxml/config.w32 to the branch version; apparently the wrong lib is used 5.2.5. I don't know if renaming libxml2_a_dll.lib to libxml2_a.lib would fix this. You'd be better off just using the new config.w32 file that corresponds to the update. Rob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] final keyword
Guys,
I think we are over-engineering and over-complicating here. Reminds me of all
the ugly workarounds in C++.
If this is really what you need then just declare it private/protected and
create accessor methods (getters/setters).
I don't think it makes sense to introduce additional complexities both to the
grammar and the visibility logic for something very few people are going to get
their heads around...
Andi
-Original Message-
From: Sebastian Schneider [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 13, 2008 4:13 AM
To: Marcus Boerger
Cc: Felipe Pena; internals@lists.php.net
Subject: Re: [PHP-DEV] final keyword
Hey you guys,
but the construct
private : public $bar = 'foo';
addresses actually another - fairly similar - issue.
whereas I believe it's sufficient just extending the const
or final keyword, which introduces not a new language construct and
thus affects really nothing but issue.
Your syntax would be kind of helpful when addressing security related
codes, which need to encapsulate variables.
Anyway, it would be better to use getters/setters to abstract from the
actual implementation, where you can react more precise on the read
request (not knowing you called the method, however).
Cheerio,
Sebastian
Marcus Boerger schrieb:
Hello Felipe,
I do not like readonly, instead I would prefer a version where read
and
write have separate visibility. And actually your idea seems to
prevent a
second write to the value, using NULL as for detection means. Now
what
happens is that a) a property that has a default value will become a
const,
yet with some trickery (array conversion, ArrayObject) allowing to be
ignored. And b) when set to NULL you can do another write until you
do a non
NULL write. All that said, here is my idea again:
class Foo {
private : public $bar = baz;
This does:
a) not introduce a new keyword
b) have write access private and read access public
c) is compatible with all we have right now
d) could be limited to public on the read side
(ze2-readable_properties-20060514d.diff.txt).
I even had a patch in may 2006 (ze2-readable_properties-
20060516.diff.txt)
that implements the new visibility promulgate (which i thought of as
a funny
solution to public read).
marcus
Wednesday, February 13, 2008, 11:18:17 AM, you wrote:
Em Qua, 2008-02-13 às 10:59 +0100, Sebastian Schneider escreveu:
By the way, when declared final the value couldn't be changed,
anyways -
however it MUST be read-only.
I made a ***simple*** (or wrong!) patch months ago for read-only
property as you described.
http://felipe.ath.cx/diff/readonly.patch
e.g.
class foo {
private readonly $foo = array(1, 2, 3);
}
But i agree with early discussions, and with Marcus' implementation:
http://marc.info/?l=php-internalsw=2r=1s=readonlyq=b
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
matching GET/POST. I think this should be cleaned up so that _REQUEST
behavior would conform its use case.
Attached is the patch that implements request_order .ini value. Comments?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
Index: php.ini-dist
===
RCS file: /repository/php-src/php.ini-dist,v
retrieving revision 1.231.2.10.2.22.2.2
diff -u -r1.231.2.10.2.22.2.2 php.ini-dist
--- php.ini-dist11 Feb 2008 00:01:11 - 1.231.2.10.2.22.2.2
+++ php.ini-dist13 Feb 2008 20:57:20 -
@@ -413,6 +413,12 @@
; values override older values.
variables_order = EGPCS
+; This directive describes the order in which PHP registers GET, POST and
Cookie
+; variables into the _REQUEST array. Registration is done from left to right,
+; newer values override older values.
+; If this directive is not set, variables_order is used for _REQUEST contents.
+; request_order = GP
+
; Whether or not to register the EGPCS variables as global variables. You may
; want to turn this off if you don't want to clutter your scripts' global scope
; with user data. This makes most sense when coupled with track_vars - in
which
Index: php.ini-recommended
===
RCS file: /repository/php-src/php.ini-recommended,v
retrieving revision 1.179.2.11.2.23.2.2
diff -u -r1.179.2.11.2.23.2.2 php.ini-recommended
--- php.ini-recommended 11 Feb 2008 00:01:11 - 1.179.2.11.2.23.2.2
+++ php.ini-recommended 13 Feb 2008 20:57:20 -
@@ -464,6 +464,12 @@
; values override older values.
variables_order = GPCS
+; This directive describes the order in which PHP registers GET, POST and
Cookie
+; variables into the _REQUEST array. Registration is done from left to right,
+; newer values override older values.
+; If this directive is not set, variables_order is used for _REQUEST contents.
+request_order = GP
+
; Whether or not to register the EGPCS variables as global variables. You may
; want to turn this off if you don't want to clutter your scripts' global scope
; with user data. This makes most sense when coupled with track_vars - in
which
Index: main/main.c
===
RCS file: /repository/php-src/main/main.c,v
retrieving revision 1.640.2.23.2.57.2.8
diff -u -r1.640.2.23.2.57.2.8 main.c
--- main/main.c 4 Feb 2008 20:39:21 - 1.640.2.23.2.57.2.8
+++ main/main.c 13 Feb 2008 20:57:20 -
@@ -436,6 +436,7 @@
STD_PHP_INI_ENTRY(user_dir, NULL,
PHP_INI_SYSTEM, OnUpdateString, user_dir,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(variables_order,EGPCS,
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateStringUnempty,
variables_order,php_core_globals, core_globals)
+ STD_PHP_INI_ENTRY(request_order, NULL,
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateString, request_order,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(error_append_string,NULL,
PHP_INI_ALL,OnUpdateString, error_append_string,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(error_prepend_string, NULL,
PHP_INI_ALL,OnUpdateString, error_prepend_string,
php_core_globals, core_globals)
Index: main/php_globals.h
===
RCS file: /repository/php-src/main/php_globals.h,v
retrieving revision 1.98.2.1.2.7.2.2
diff -u -r1.98.2.1.2.7.2.2 php_globals.h
--- main/php_globals.h 31 Dec 2007 07:17:17 - 1.98.2.1.2.7.2.2
+++ main/php_globals.h 13 Feb 2008 20:57:20 -
@@ -164,6 +164,8 @@
char *user_ini_filename;
long user_ini_cache_ttl;
+
+ char *request_order;
};
Index: main/php_variables.c
===
RCS file: /repository/php-src/main/php_variables.c,v
retrieving revision 1.104.2.10.2.11.2.3
diff -u -r1.104.2.10.2.11.2.3 php_variables.c
--- main/php_variables.c31 Dec 2007 07:17:17 -
1.104.2.10.2.11.2.3
+++ main/php_variables.c13 Feb 2008 20:57:20 -
@@ -835,7 +835,13 @@
array_init(form_variables);
INIT_PZVAL(form_variables);
- for (p = PG(variables_order); p *p; p++) {
+ if(PG(request_order) != NULL) {
+ p = PG(request_order);
+ } else {
+ p = PG(variables_order);
+ }
+
+ for (; p *p; p++) {
switch (*p) {
case 'g':
case 'G':
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Re: [PHP-DEV] _REQUEST and variable_order
Yes... I didn't seem to see a default: + STD_PHP_INI_ENTRY(request_order, NULL, PHP_INI_SYSTEM|PHP_INI_PERDIR,OnUpdateString, request_order, php_core_globals, core_globals) Which means that without this setting, nothing ends up in request. The NULL means variable_order is used. php.ini-dist - it should mention the default (still commented out, just like the rest) as GPC too. Setting this as GPC gives wrong idea - recommended setting is GP, as C is useful only in very rare situations for special applications. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, 13 Feb 2008, Stanislav Malyshev wrote: matching GET/POST. I think this should be cleaned up so that _REQUEST behavior would conform its use case. Attached is the patch that implements request_order .ini value. Comments? Yes... I didn't seem to see a default: + STD_PHP_INI_ENTRY(request_order, NULL, PHP_INI_SYSTEM|PHP_INI_PERDIR,OnUpdateString, request_order, php_core_globals, core_globals) Which means that without this setting, nothing ends up in request. The default should be what it is now (GPC). The same is true for php.ini-dist - it should mention the default (still commented out, just like the rest) as GPC too. regards, -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] final keyword
On 13.02.2008, at 21:52, Andi Gutmans wrote: Guys, I think we are over-engineering and over-complicating here. Reminds me of all the ugly workarounds in C++. If this is really what you need then just declare it private/ protected and create accessor methods (getters/setters). I don't think it makes sense to introduce additional complexities both to the grammar and the visibility logic for something very few people are going to get their heads around... Thats exactly what I was thinking when I read this proposal and ensuing discussion. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
On Wed, 13 Feb 2008, Stanislav Malyshev wrote: Yes... I didn't seem to see a default: + STD_PHP_INI_ENTRY(request_order, NULL, PHP_INI_SYSTEM|PHP_INI_PERDIR,OnUpdateString, request_order, php_core_globals, core_globals) Which means that without this setting, nothing ends up in request. The NULL means variable_order is used. php.ini-dist - it should mention the default (still commented out, just like the rest) as GPC too. Setting this as GPC gives wrong idea - recommended setting is GP, as C is useful only in very rare situations for special applications. Yes, that's why php.ini-recommended should have GP. However, php.ini-dist documents *the default* - which should be GPC, like it is right now. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] _REQUEST and variable_order
Yes, that's why php.ini-recommended should have GP. However, php.ini-dist documents *the default* - which should be GPC, like it is right now. The default is NULL, which means using variables_order - just as before. I don't see a lot of reason to change it to GPC - it would be neither old compatible way (using variables_order) nor new recommended way (using request_order=GP). -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
Pierre Joye wrote:
On Feb 13, 2008 4:47 PM, Lars Strojny [EMAIL PROTECTED] wrote:
Hi everyone,
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.
I don't think we need two new functions for:
set_include_path('/some/path' . DIRECTORY_SEPARATOR . get_include_path());
set_include_path(. get_include_path() . DIRECTORY_SEPARATOR . '/some/path' );
Gotcha, it needs to be PATH_SEPARATOR, no?
- Markus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
Hi Lars,
On Feb 13, 2008 4:47 PM, Lars Strojny [EMAIL PROTECTED] wrote:
Hi everyone,
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.
I don't think we need two new functions for:
set_include_path('/some/path' . DIRECTORY_SEPARATOR . get_include_path());
set_include_path(. get_include_path() . DIRECTORY_SEPARATOR . '/some/path' );
Thanks for your work anyway! :)
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
On Feb 13, 2008 11:06 PM, Markus Fischer [EMAIL PROTECTED] wrote:
Pierre Joye wrote:
On Feb 13, 2008 4:47 PM, Lars Strojny [EMAIL PROTECTED] wrote:
Hi everyone,
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.
I don't think we need two new functions for:
set_include_path('/some/path' . DIRECTORY_SEPARATOR . get_include_path());
set_include_path(. get_include_path() . DIRECTORY_SEPARATOR .
'/some/path' );
Gotcha, it needs to be PATH_SEPARATOR, no?
That would be a reason to have these functions (yes, path_separator is
required) ;-)
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
Hi Pierre,
Am Mittwoch, den 13.02.2008, 23:01 +0100 schrieb Pierre Joye:
[...]
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.
[...]
I don't think we need two new functions for:
Sure?
set_include_path('/some/path' . DIRECTORY_SEPARATOR . get_include_path());
See: prepend_include_path('/some/path');
set_include_path(. get_include_path() . DIRECTORY_SEPARATOR . '/some/path'
);
See: append_include_path('/some/path');
Think about reading the code. What's easier to grasp for you?
Introducing this functions is meant to make a) code better readable, b)
easier to write the code, as most of the time, include path adjustments
are include path appends, so the roundtrip
set_include_path(get_include_path() ...) is not suboptimal.
On the other hand, introducing this functions will not very likely
introduce a lot of new bugs, so the maintenance overhead is lower than
the value this functions bring (of course this is my POV, as I wrote
that patch :-)). And, for the record, I promise to provide fixes for
each the related bug (everyone heard that?).
cu, Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
Hi Pierre, Am Mittwoch, den 13.02.2008, 23:12 +0100 schrieb Pierre Joye: [...] That would be a reason to have these functions (yes, path_separator is required) ;-) So you agree? Thanks :) cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
I think Lars has a point ... maybe set_include_path() could
be given a second parameter instead to mitigate the need for seperate funcs?:
set_include_path('foo', INCPATH_OVERRIDE); // default
set_include_path('foo', INCPATH_APPEND);
set_include_path('foo', INCPATH_PREPEND);
Strojny schreef:
Hi Pierre,
Am Mittwoch, den 13.02.2008, 23:01 +0100 schrieb Pierre Joye:
[...]
the following patch[1] adds the functions append_include_path() and
prepend_include_path(). These function are there to make include path
adjustments easier than it is. Especially append_include_path() is what
is done most of the time.
[...]
I don't think we need two new functions for:
Sure?
set_include_path('/some/path' . DIRECTORY_SEPARATOR . get_include_path());
See: prepend_include_path('/some/path');
set_include_path(. get_include_path() . DIRECTORY_SEPARATOR . '/some/path' );
See: append_include_path('/some/path');
Think about reading the code. What's easier to grasp for you?
Introducing this functions is meant to make a) code better readable, b)
easier to write the code, as most of the time, include path adjustments
are include path appends, so the roundtrip
set_include_path(get_include_path() ...) is not suboptimal.
On the other hand, introducing this functions will not very likely
introduce a lot of new bugs, so the maintenance overhead is lower than
the value this functions bring (of course this is my POV, as I wrote
that patch :-)). And, for the record, I promise to provide fixes for
each the related bug (everyone heard that?).
cu, Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [HOST=] and [PATH=] cgi-only?
Hi! Do I understand correctly that current [HOST=] and [PATH=] functionality for PHP works only for CGI/FCGI sapi? Is there any reason for other SAPIs not to do it (except for the obvious - lack of implementation :)? I know there's .htacess for Apache, etc. but there may be setups that might prefer to deal with php.ini... -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] prepend_include_path()/append_include_path()
Lars Strojny wrote: Hi everyone, the following patch[1] adds the functions append_include_path() and prepend_include_path(). These function are there to make include path adjustments easier than it is. Especially append_include_path() is what is done most of the time. The current patch is in a bit hacky state, as I have my doubts whether storing the include paths as a string is a good idea. I want to gain some feedback for this addition first before I invest more work on it. [1] http://lars.schokokeks.org/php/include_path_modifiers-1.diff -1 from me, it doesn't reduce code size, and speed is not a huge issue since it is likely to be called once per script, maximum. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] prepend_include_path()/append_include_path()
On Feb 14, 2008 12:05 AM, Lars Strojny [EMAIL PROTECTED] wrote: Hi Pierre, Am Mittwoch, den 13.02.2008, 23:12 +0100 schrieb Pierre Joye: [...] That would be a reason to have these functions (yes, path_separator is required) ;-) So you agree? Thanks :) I don't, it was a joke :) -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [HOST=] and [PATH=] cgi-only?
Hi! We first discussed about fastcgi as a first step but the goal is to support this syntax in all SAPI (well, cli makes little sense). It was thought as a replacement for htscanner (see pecl) but without its limitation. Ok, that makes sense, thanks. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
Steph Fox wrote: 1) Distribution woes need to end. With the work Greg's been doing lately on PHP_Archive/Phar, that's very close to being attainable now in the physical 'getting PECL'd extensions out to people' sense, but unless people are running CLI or CGI or have access to their own php.ini they still can't do much with those extensions. So we have to seriously consider how to recommend extensions to hosts, other than by shipping them with the PHP core. Steph, Greg In interests of clarity for all, can you explain what you anticipate will change for PECL with Phar/Pyrus for Windows and non-Windows? Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] [RFC] An Idea for PDO 2
Lester Caine wrote: Perhaps if PDO actually added some value there there would not be a problem, but we still need something sensible wrapping it to make cross database SQL work so why do I need to bother changing the internals of what I have been working with for years just to 'fix half of the problem' with a solution at is still showing a significant decrease in performance over native drivers managed transparently in ADOdb. You miss the unstated implication that PDO V2 will offer par or better performance, and potentially more functionality. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Hi Chris, On Feb 14, 2008 3:30 AM, Christopher Jones [EMAIL PROTECTED] wrote: Pierre Joye wrote: Hi Chris, On Feb 14, 2008 2:48 AM, Christopher Jones [EMAIL PROTECTED] wrote: Pierre Joye wrote: The targets were these/this companies(y) pushing CLA in php.net when it is not necessary to contribute. It has been proven already since months on a nearly daily basis. For example: http://blogs.oracle.com/opal/discuss/msgReader$268 My understanding is that because of its collaborative nature, contributing to PDO V2 has new and very different implications. You mean its collaborative and restrictive nature? No - its collaborative nature. Arguments using past contributions to show the ad-hoc development model is feasible are (unfortunately) not tenable Again, please see my other posts. Since my last post, nothing has been brought to the list to clarify the situation. Important questions like who is asking a CLA That has already been stated. This is not an us and them situation since each party has different requirements. who will contribute and what will be brought on board? That has also been stated: expertise and person-power. I think you are taking for a brain dead or some stupid PR out there. Please answer the questions, don't give me buzz words to make a point. The fine points will depend on the community, a term that includes data access providers (I'm using that name since not all are actual vendors), and the model the community chooses to accept. Why did they not take contact with us? We did. It just took a very long time. Think of it as a normal is this idea possible chat that took place in very, very, very slow motion. There is no discussion, there is no chat. You (as group) simply refuse to answer the most obvious questions. Tell us the names of these entities, companies or persons, who are going to contribute and what are actually their requirements. What will they bring (saying expertise is not something I can buy)? I don't understand what is so hard to understand that it is a minimum to get before we can even discuss the CLA introduction. Let alone the fact that they don't consider us as good enough as discussions partner. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Pierre Joye wrote: Hi Chris, On Feb 14, 2008 2:48 AM, Christopher Jones [EMAIL PROTECTED] wrote: Pierre Joye wrote: The targets were these/this companies(y) pushing CLA in php.net when it is not necessary to contribute. It has been proven already since months on a nearly daily basis. For example: http://blogs.oracle.com/opal/discuss/msgReader$268 My understanding is that because of its collaborative nature, contributing to PDO V2 has new and very different implications. You mean its collaborative and restrictive nature? No - its collaborative nature. Arguments using past contributions to show the ad-hoc development model is feasible are (unfortunately) not tenable Again, please see my other posts. Since my last post, nothing has been brought to the list to clarify the situation. Important questions like who is asking a CLA That has already been stated. This is not an us and them situation since each party has different requirements. who will contribute and what will be brought on board? That has also been stated: expertise and person-power. The fine points will depend on the community, a term that includes data access providers (I'm using that name since not all are actual vendors), and the model the community chooses to accept. Why did they not take contact with us? We did. It just took a very long time. Think of it as a normal is this idea possible chat that took place in very, very, very slow motion. Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
Tell us the names of these entities, companies or persons, who are going to contribute and what are actually their requirements. What will they bring (saying expertise is not something I can buy)? I don't understand what is so hard to understand that it is a minimum to get before we can even discuss the CLA introduction. Let alone the fact that they don't consider us as good enough as discussions partner. Pierre does have a point here. We don't know who we're dealing with, what they can/could offer, or what they want or need in order to offer it.. and nobody's really tried to communicate with php.net apart from those already in the php.net inner circle. I believe there's more room for give and take than Pierre (and others) would be prepared to acknowledge ATM, but if nobody's even prepared to talk with php.net about the issues from their own perspective(s) how can we be expected to work together to find a good solution? In fairness it seems the corporate side all came together to exchange views about how to restrict stuff and haven't reached their own 'group conclusion' yet, but from this end the only message that can sanely be given at present is 'do the best you can without restrictions, because we have good reasons for disliking them'. - Steph Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- 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] Splitting the subject: the PECL/PHP relationship
Christopher Jones wrote: Steph Fox wrote: 1) Distribution woes need to end. With the work Greg's been doing lately on PHP_Archive/Phar, that's very close to being attainable now in the physical 'getting PECL'd extensions out to people' sense, but unless people are running CLI or CGI or have access to their own php.ini they still can't do much with those extensions. So we have to seriously consider how to recommend extensions to hosts, other than by shipping them with the PHP core. Steph, Greg In interests of clarity for all, can you explain what you anticipate will change for PECL with Phar/Pyrus for Windows and non-Windows? That's a great question. I have not written any support yet for pecl in pyrus, as I would like it to be far better. For instance, should pecl4win start building package versions instead of just from CVS, then we could easily install on windows directly from pecl4win. One change that is planned for unix (and not yet implemented) is a concrete build directory, a place where source files are extracted. As you know, currently the pear installer simply extracts to a temporary directory, and builds, then erases the files. This is great when the build succeeds, but when it fails, it makes debugging completely impossible. It also makes patching much more difficult. I have said many times in less formal settings that I expect far more input on how pecl will work with pyrus than we have been getting for the PEAR installer. So, let me say it formally: Pyrus will be far more pecl-friendly, but I will need real input from internals developers to make the thing truly useful. Now that I'm getting better versed in how internals/pecl works, I will also be much better equipped to respond to suggestions than I was a year ago even, so I'm confident we'll get something very nice. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Splitting the subject: the PECL/PHP relationship
Hi Chris, In interests of clarity for all, can you explain what you anticipate will change for PECL with Phar/Pyrus for Windows and non-Windows? From my PoV as a Windows user, the primary case for optimisim is based on the fact that local PEAR installs recently started working properly on Windows via the PEAR installer. I take that as a welcome sign of maturity in the original installer script. Secondary is that Greg's Phar format's coming along really well - it's possible to run the same phar created with the extension + default stub in any PHP setting, CLI or web. You don't need to have anything installed other than PHP itself, and you don't need to unpack a phar to run the application contained within it. The PHP_Archive-based phars we've been seeing for the PEAR installer have similar qualities, but I suspect the whole PEAR inter-dependency thing is a big turnoff for many - so phar's been an invisible good idea for a long while. That's not necessarily a bad thing, it means it's had time to evolve. It would be nice (Greg may not agree here) to have the PECL installer script completely independent of PEAR classes - at present it throws a hissy fit if Tar_Archive isn't installed, for example, which is reasonable enough for a PEAR installation but a complete pain in the butt if you just wanted to pick up runkit. There's no good reason I know of not to slip tar extraction functionality directly into the phar stub. PHP's built-in getopt() is cross-platform from 5.3 on, albeit less than perfect, so we can probably just about get away without Console_Getopt now. Unless I'm missing something major, we don't need to know a whole lot about the clientside environment for PECL either - just the platform, PHP version, extension_dir() and the path to a writable temp directory. So it should be possible to drop the PEAR association and simply drop something like pecl.phar into the top-level PHP directory in releases and snaps; you'd type php pecl.phar to open the application and direct commands thereafter, or stick it in htdocs and type http://localhost/pecl.phar if you'd prefer your installation via a form. If you're building PHP fresh out of CVS you can check out the whole of PECL anyway. The situation with the PHP_Archive-based phar currently used for the PEAR installer is that the installer script in it offers PECL release src packages and installs them on demand, though I gather this is still a little rough around the edges. The equivalent binary download for Windows isn't in place at all, but AFAICS there's no real reason it couldn't be made to work, so long as there's a sane form of tagging somewhere along the line so that a specific PHP version would be offered appropriate PECL binaries. (I would imagine this might require *release* binaries to be made available via pecl.php.net - leaving pecl4win for snapshots - but that's just a wild thought at present.) If you can tag individual packages you can also tag groups, so it's not too big a leap from 'appropriate binary release' to 'appropriate selection of binaries'. The only thing that can't reasonably be automated is updating the PHP INI file to load them - and that's not because it's technically difficult. Basically I think the technology is pretty much in place, between the PEAR channels and phar, to make pecl installs a trivial matter across all platforms. It's mostly a case of getting the PECL infrastructure to work with it, which is a much tougher task because it needs the PHP core/PECL community to agree to that in principle, figure out the best approach and then help make it happen. - Steph Chris -- Christopher Jones, Oracle Email: [EMAIL PROTECTED]Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ Free PHP Book: http://tinyurl.com/f8jad -- 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] Re: [PDO] Re: [PHP-DEV] [RFC] An Idea for PDO 2
On 14.02.2008, at 04:04, Steph Fox wrote: Tell us the names of these entities, companies or persons, who are going to contribute and what are actually their requirements. What will they bring (saying expertise is not something I can buy)? I don't understand what is so hard to understand that it is a minimum to get before we can even discuss the CLA introduction. Let alone the fact that they don't consider us as good enough as discussions partner. Pierre does have a point here. We don't know who we're dealing with, what they can/could offer, or what they want or need in order to offer it.. and nobody's really tried to communicate with php.net apart from those already in the php.net inner circle. Right, we know Wez, we know Andi, we know you. We know more and more of the guys working on tests, we know know at least the emails of some of the guys working on the currently CLA'ed IBM PDO drivers. I have seen some Microsoft guys at some conferences. But I have never talked to one in the context of PDO development. We also do not know who will be coming from inside Oracle to work with us if we go the CLA way. We do not know who will come from inside IBM to work with us etc. OSS is a collaborative process that is not about some manager allocating some ressources here and there. People usually make personal commitments here and maybe this is the bigger culture clash than the CLA. What is being proposed is to turn part of PHP into something that is managed by a manager and the budget he gets allocated by a manager above him. People do not commit access for saying what company they work for. People get commit access once they have send enough patches that are top notch, that php.net decides they can trust them. This is the model of trust we have gone by. So if we are going to change this to start trusting a managerial process, the least we can ask is to have some interaction with the people that will most likely be involved there, even if there is a good chance that things might be shuffled around by the time we get to see code. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
