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:
hi Mike,
On Mon, Apr 12, 2010 at 8:37 AM, Michael Wallner m...@iworks.at 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 |
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 17:27, Frederic Hardy
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 to
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:
hi,
On Mon, Apr 12, 2010 at 10:25 AM, Pierre Joye paj...@php.net wrote:
pajoye Mon, 12 Apr 2010 08:25:50 +
Revision: http://svn.php.net/viewvc?view=revisionrevision=297865
Log:
- [doc] add stream_set_read_buffer, equivalent of stream_set_write_buffer
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 told
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 prefer
On Sun, Apr 11, 2010 at 5:42 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Sun, Apr 11, 2010 at 3:43 PM, Frederik Banke frede...@tigermedia.dkwrote:
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:
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 some
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 without this
2010/4/12 Johannes Schlüter johan...@php.net:
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 der...@php.net:
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
On 12 April 2010 13:42, Gregory greg...@gregory.net 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
hi Rasmus,
On Sun, Apr 11, 2010 at 9:24 PM, Rasmus Lerdorf ras...@lerdorf.com 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
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, that is not
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
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 now:
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
to use a
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 s...@zend.com 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 s...@zend.com 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
25 matches
Mail list logo
