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
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
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
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
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.
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
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. :)
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
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
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
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
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
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
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
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
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
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
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
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;
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
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:
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.
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:
+
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
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
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
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
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
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
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
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:
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
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
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
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 :)
--
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
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
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
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
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.
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
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
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
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
44 matches
Mail list logo
