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
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 par
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
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 th
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/readonl
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
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. :)
Felip
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() exp
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 j
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
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 becom
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 wrot
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
>> ad
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=diff&r1=1.146&r2=1.147
>>
>> breaks about 20 tests in phar, it's a
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 th
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
ad
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;
a
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 complexitie
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: [EMAI
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:
+ STD_PHP
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 thin
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
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 c
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_pat
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()
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 a
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 wh
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
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
Hi Stan,
On Feb 14, 2008 1:52 AM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote:
> 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 implementa
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 Archi
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
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 becaus
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.
> >
> >
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
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 bas
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 dis
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
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
Wi
Christopher Jones wrote:
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
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
49 matches
Mail list logo
