Good catch Philip,
@all, any objections to port ext/zlib code from
FIRST_UNICODE_IMPLEMENTATION to trunk?
Cheers,
Mike
Am 10.04.2010 02:23, schrieb Philip Olson:
On Feb 24, 2009, at 6:33 AM, Michael Wallner wrote:
Philip Olson wrote:
On 10 Jun 2008, at 23:35, Michael Wallner wrote:
Phi
hi Mike,
On Mon, Apr 12, 2010 at 8:37 AM, Michael Wallner wrote:
> Good catch Philip,
>
> @all, any objections to port ext/zlib code from FIRST_UNICODE_IMPLEMENTATION
> to trunk?
None from here.
Thanks for your work!
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.
On Mon, 22 Mar 2010, Felix De Vliegher wrote:
> On 17-mrt-2010, at 19:09, Derick Rethans wrote:
>
> > On Wed, 17 Mar 2010, Felix De Vliegher wrote:
> >
> >> On 17-mrt-2010, at 17:52, Derick Rethans wrote:
> >>
> >>> On Wed, 17 Mar 2010, Felix De Vliegher wrote:
> >>>
> On 17-mrt-2010, at
On Tue, 23 Mar 2010, Antony Dovgal wrote:
> Derick (and other people) asked me to create an RFC for FPM describing
> what it is and why do we need it. Quite.. ahem.. laconic version of
> such RFC can be found here: http://wiki.php.net/rfc/fpm
>
> I'm open for your questions.
Can you merge it t
Hi!
Just had a look over the RFC, and from what I gathered was that only the
issue of aliasing/renaming seems slightly controversional. Would it be
possible to commit traits without this feature for now?
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: h
hi,
On Mon, Apr 12, 2010 at 10:25 AM, Pierre Joye wrote:
> pajoye Mon, 12 Apr 2010 08:25:50 +
>
> Revision: http://svn.php.net/viewvc?view=revision&revision=297865
>
> Log:
> - [doc] add stream_set_read_buffer, equivalent of stream_set_write_buffer for
> rea
On 12.04.2010, at 10:34, Derick Rethans wrote:
> Hi!
>
> Just had a look over the RFC, and from what I gathered was that only the
> issue of aliasing/renaming seems slightly controversional. Would it be
> possible to commit traits without this feature for now?
Stefan recently got karma and t
On Tue, 30 Mar 2010, Jérôme Loyet wrote:
> As dreamcast4 advises me in the previous FPM conversation, I just
> wrote the RFC for the FPM INI syntax.
>
> It can be read here: http://wiki.php.net/rfc/fpm/ini_syntax
>
> Tell me what you think.
That seems to be extremely complicated. I definitely p
On Sun, Apr 11, 2010 at 5:42 PM, Ferenc Kovacs wrote:
>
>
> On Sun, Apr 11, 2010 at 3:43 PM, Frederik Banke wrote:
>
>> Hi
>>
>> I have a problem with my php, once in a while an apache process will hang.
>> In apache's /server-status it looks like:
>> *11-1*111941/3/588*W* 0.20213490179.30.2227.0
On Sat, 16 Jan 2010, Raphael Geissert wrote:
> > use_embedded_timezonedb.patch
> > Like with the SQLite note above we prefer to have the same behavior
> > over all platforms by using a common time database.
>
> Same here, updating the tz data on PHP everytime would be a pain. And yes,
> at s
On 12 Apr 2010, at 10:39, Lukas Kahwe Smith wrote:
> On 12.04.2010, at 10:34, Derick Rethans wrote:
>> Hi!
>>
>> Just had a look over the RFC, and from what I gathered was that only the
>> issue of aliasing/renaming seems slightly controversional. Would it be
>> possible to commit traits withou
2010/4/12 Johannes Schlüter :
> Hi,
>
> On Mon, 2010-04-12 at 08:25 +, Pierre Joye wrote:
>> - switch (ZEND_NUM_ARGS()) {
>> - case 2:
>> - if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rl",
>> &arg1, &arg2) == FAILURE) {
>> - RETURN_FALSE;
>> -
2010/4/12 Derick Rethans :
> On Tue, 30 Mar 2010, Jérôme Loyet wrote:
>
>> As dreamcast4 advises me in the previous FPM conversation, I just
>> wrote the RFC for the FPM INI syntax.
>>
>> It can be read here: http://wiki.php.net/rfc/fpm/ini_syntax
>>
>> Tell me what you think.
>
> That seems to be
Okay, so it seems to me based on the discussion, that if we implement
named parameters the following way, it should work well:
1) Allow named parameters in function calls, using the syntax func($a,
$b, 'var1' => $value, $var2 => $value2), similar to array() definition.
2) Do not allow non-nam
On 12 April 2010 13:42, Gregory wrote:
> PS: Also, what do you guys think of an additional (optional) possibility:
>
> function myFunc($a, $b, ...$options) // sort of like Java
>
> and this way $options can be filled, so people don't have to keep using
> func_get_args to get all the arguments.
If
hi Rasmus,
On Sun, Apr 11, 2010 at 9:24 PM, Rasmus Lerdorf wrote:
> A few people, well ok, Lukas mainly, seem to be confused about our
> current process, or lack of it. I think it is pretty simple, and it is
> what we used for years.
I'm pretty sure there are more people willing to change, to k
Hi,
I was only loosely following the discussion about this topic, so please
flame me if I got this wrong;)
I tend use the array-alternative alot which fits my purposes nicely
except for default-values. If named-parameters are introduced in this
proposed way, I don't see any advantages other
On Mon Apr 12 05:16 AM, Stefan Marr wrote:
>
> On 12 Apr 2010, at 10:39, Lukas Kahwe Smith wrote:
> > On 12.04.2010, at 10:34, Derick Rethans wrote:
> >> Hi!
> >>
> But just as a quick response, without aliasing, there would be no way
> to use a conflicting method from a trait.
> On first sight,
I may be getting mixed-up between declared and named parameters (which
would allow for out-of-order and skipping parameters) vs. undeclared
and named additional parameters (extra junk supplied - with names -
outside of any documentation).
Either way, anything that I've not declared in the prototyp
Lars Schultz wrote:
> As I am using it now:
> function foo($x,$y,$options=array()){
> if ( !isset($options['opt1']) ) $options['opt1'] = 'foo';
> if ( !isset($options['opt2']) ) $options['opt2'] = 'bar';
> /* 1 */
> }
One little trick you can use to make things a bit more elegant right
On 12 Apr 2010, at 16:11, Jonathan Bond-Caron wrote:
> On Mon Apr 12 05:16 AM, Stefan Marr wrote:
>>
>> On 12 Apr 2010, at 10:39, Lukas Kahwe Smith wrote:
>>> On 12.04.2010, at 10:34, Derick Rethans wrote:
Hi!
>> But just as a quick response, without aliasing, there would be no way
>
Hi!
Proposed new syntax of this case:
function foo($x,$y){
$options = func_get_args();
if ( !isset($options['opt1']) ) $options['opt1'] = 'foo';
if ( !isset($options['opt2']) ) $options['opt2'] = 'bar';
/* 1 */
}
I think the idea is to do:
function foo($x,$y, $opt1 = 'foo', $opt2 = 'bar'){
}
On Tue, Apr 13, 2010 at 1:10 AM, Stanislav Malyshev wrote:
> Hi!
>
>> Proposed new syntax of this case:
>>
>> function foo($x,$y){
>> $options = func_get_args();
>> if ( !isset($options['opt1']) ) $options['opt1'] = 'foo';
>> if ( !isset($options['opt2']) ) $options['opt2'] = 'bar';
>> /* 1 */
>>
Hi!
I think the idea is to do:
function foo($x,$y, $opt1 = 'foo', $opt2 = 'bar'){
}
foo(1,2);
foo(1,2,'opt1'=>'no-foo');
That's the idea if we can't do (1, opt1 = 'foo') or?
I think that's the idea in general, now how it looks like - be it 'opt1'
=> 'no-foo' or opt1: 'no-foo' - that's the
On Tue, Apr 13, 2010 at 1:28 AM, Stanislav Malyshev wrote:
> I think that's the idea in general, now how it looks like - be it 'opt1' =>
> 'no-foo' or opt1: 'no-foo' - that's the decision we need to take. I
> personally still don't have the favorite, but in every case we still have
> the full par
25 matches
Mail list logo
