Andi Gutmans wrote:
We need to focus on Unicode more than what some says, whether this
means descoping the Unicode release or not. However, this means that
the
development focus needs to be towards new features AND Unicode, not
having the new feature branch, and the siberia branch with Unicode
Etienne Kneuss wrote:
Hello,
On Wed, Mar 17, 2010 at 3:40 PM, mathieu.suen
wrote:
Ionut G. Stan wrote:
Hi,
This is interesting and it appears the following change makes the snippet
work as expected:
public function &__get($name);
I think is that the $this->anArray['bar']
Hi,
now that a new trunk is about to be created some comments about 5.3:
PHP_5_3 is a stable branch. This means mostly bug fixes. Small features
(like array_seek) can be added. There won't be a strict rule about what
is "small", common sense and asking applies. That part will become
stricter once
On 18.03.2010, at 06:55, Andi Gutmans wrote:
>> -Original Message-
>> From: Olivier Hill [mailto:olivier.h...@gmail.com]
>> Sent: Saturday, March 13, 2010 10:15 AM
>> To: Derick Rethans
>> Cc: PHP Developers Mailing List
>> Subject: Re: [PHP-DEV] PHP 6
>>
>> We need to focus on Unicode m
On 18.03.2010, at 03:47, Stanley Sufficool wrote:
> On Mon, Mar 15, 2010 at 8:45 AM, Christopher Jones
> wrote:
>>
>>
>> Stanley Sufficool wrote:
>>> I have attached patches for bug # 50755 on bugs.php.net. These also
>>> cleanup to PDO DBLIB code to have less of a memory footprint and to
>>>
On Thu, 2010-03-18 at 09:19 +0100, Johannes Schlüter wrote:
> now that a new trunk is about to be created some comments about 5.3:
> PHP_5_3 is a stable branch. This means mostly bug fixes. Small features
> (like array_seek) can be added. There won't be a strict rule about what
> is "small", common
> I think there is a lot to say why is not working but just look at those
> 2 execution:
>
> 1st
> class A
> {
>
> public function __get($name)
> {
> $this->$name = array();
> return $this->$name;
> }
>
> public function te
Hello,
On Thu, Mar 18, 2010 at 8:49 AM, mathieu.suen
wrote:
> Etienne Kneuss wrote:
>>
>> Hello,
>>
>> On Wed, Mar 17, 2010 at 3:40 PM, mathieu.suen
>> wrote:
>>
>>>
>>> Ionut G. Stan wrote:
>>>
Hi,
This is interesting and it appears the following change makes the
snippe
On Thu, Mar 18, 2010 at 10:16 AM, Lukas Kahwe Smith wrote:
>
> On 18.03.2010, at 03:47, Stanley Sufficool wrote:
>
>> On Mon, Mar 15, 2010 at 8:45 AM, Christopher Jones
>> wrote:
>>>
>>>
>>> Stanley Sufficool wrote:
I have attached patches for bug # 50755 on bugs.php.net. These also
cle
On 2010-03-18, Lukas Kahwe Smith wrote:
>
> On 18.03.2010, at 06:55, Andi Gutmans wrote:
>
>>> -Original Message-
>>> From: Olivier Hill [mailto:olivier.h...@gmail.com]
>>> Sent: Saturday, March 13, 2010 10:15 AM
>>> To: Derick Rethans
>>> Cc: PHP Developers Mailing List
>>> Subject: Re: [
Hello to the php developer community - :)
This is my first post so I hope I'm not too out of line coming here to ask a
question.
My question is - With PHP could a C extension be written that takes the
binary contents of a variable in memory and writes it to a file or a stream?
Like:
struct
On Thu, 18 Mar 2010, Ben DeMott wrote:
> I realize there are some limitations here - recursive structures,
> references, object references, pointer pointers - etc, I just don't
> know how PHP implements it's data structures well enough to know how
> hard retrieving simple arrays, integers, and
On Wed, 17 Mar 2010, Antony Dovgal wrote:
> On 03/16/2010 07:13 PM, Derick Rethans wrote:
> >> + merge php-fpm branch?
> >
> > Can't see why not. Is there an RFC for this?
>
> No, there are no RFCs on that.
> Just copy sapi/fpm to 5_4 and you've merged it.
There is no 5_4, but still, I think th
On Tue, 16 Mar 2010, Zeev Suraski wrote:
> At 17:58 16/03/2010, Derick Rethans wrote:
> > - Declare 5.2 security fixes only (Something for Ilia to declare).
> > - Declare 5.3 bug fixes only (and ini-mini features if so desired)
> > (Something for Johannes to declare).
> >
> > Once that's done, I
Peter Lind wrote:
On the contrary, it's quite obvious what's going on. In both examples
__get() returns an array as PHP would normally do it (i.e. NOT by
reference) which means that if you try to modify that you'll end up
modifying nothing much. However, in your second example, the point at
whic
Thanks for the response Derick,
So is the data structure thats being serialized remaining in some form
thats reflective of its binary encoding on the system.
Or is there some byte-encoding that goes on to generalize the binary structure?
I guess ... Does it find the values in memory of the distinc
On Thu, Mar 18, 2010 at 5:46 PM, Derick Rethans wrote:
> On Tue, 16 Mar 2010, Zeev Suraski wrote:
>
>> At 17:58 16/03/2010, Derick Rethans wrote:
>> > - Declare 5.2 security fixes only (Something for Ilia to declare).
>> > - Declare 5.3 bug fixes only (and ini-mini features if so desired)
>> > (
On Tue, 16 Mar 2010, Lukas Kahwe Smith wrote:
> On 16.03.2010, at 16:58, Derick Rethans wrote:
>
> other stuff:
> http://wiki.php.net/todo/php60
> http://wiki.php.net/todo/backlog
yeah, I know there is other stuff, I was just listing a few examples of
things I remembered. Both lists require som
On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans wrote:
>> As for unicode, I would like the next release to be planned
>> independently of finding a solution for unicode, but with the clear
>> option that it will be included if we find a good solution in time
>> (like I said I think it would be go
On Thu, 18 Mar 2010, Ben DeMott wrote:
> So is the data structure thats being serialized remaining in some form
> thats reflective of its binary encoding on the system. Or is there
> some byte-encoding that goes on to generalize the binary structure?
PHP only knows about binary text, and then n
On 2010-03-18, Pierre Joye wrote:
> On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans wrote:
>
>> I do agree that we need to do major releases more often, but just
>> setting a time already feels wrong. It's still open source, so it's
>> ready when it is ready. That of course should not mean that w
I'll keep it short and sweet Derick ! =]
http://opensource.dynamoid.com/ -> Is exactly what I was thinking of,
glad I asked so I am not re-inventing the wheel :)
I have a feeling I can get educated really fast on php data-type
internals by taking a look at the source.
Thanks again!
On Thu, Mar
Johannes Schlüter wrote:
> Hi,
>
> now that a new trunk is about to be created some comments about 5.3:
> PHP_5_3 is a stable branch. This means mostly bug fixes. Small features
> (like array_seek) can be added. There won't be a strict rule about what
> is "small", common sense and asking applies
Am 18.03.2010 19:10, schrieb Raphael Geissert:
> I was considering adding support for tokyo cabinets, would that still
> be acceptable for 5.3.x?
I think something like that should go into a PECL extension.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://seba
Sebastian Bergmann wrote:
> Am 18.03.2010 19:10, schrieb Raphael Geissert:
>> I was considering adding support for tokyo cabinets, would that still
>> be acceptable for 5.3.x?
>
> I think something like that should go into a PECL extension.
I would actually be happy if I could build support for
On 03/18/2010 09:44 PM, Raphael Geissert wrote:
> I would actually be happy if I could build support for dba handlers as
> separate extensions, but that doesn't seem to be the case. Correct me if I'm
> wrong.
>
> Here I'm talking about adding support for tokyo cabinets as a dba handler,
> not a
I propose that sort of a
unicode working group forms but much less formal than what I make it
sound like. I think the discussions can remain on internals@ and
hopefully alternative approaches will be documented as RFCs. But what
I mean with working group is a list of a handful of names who feel
On 18.03.2010, at 18:48, David Soria Parra wrote:
On 2010-03-18, Pierre Joye wrote:
On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans
wrote:
I do agree that we need to do major releases more often, but just
setting a time already feels wrong. It's still open source, so it's
ready when it
Antony Dovgal wrote:
Here I'm talking about adding support for tokyo cabinets as a dba handler,
not a complete interface to the multiple tokyo cabinet APIs.
Are you sure you want to add it to ext/dba?
dba is .. well.. dead, and it sound like a complete waste of time.
There is an item on the w
hi,
CCing Ilia and Johannes as Andrei "discussed with the RM offline", I
suppose it is Ilia, but Johannes is the 5.3 RM.
For the record, this fix is about using size_t in the SAPI to fix
issues with uploaded files > 2G.
While wondering what was the reasoning behind this commit, I came to
the con
Issue solved, the patch has been reverted by Andrei, thanks.
However the question about the bad new configure option remains.
On Thu, Mar 18, 2010 at 11:37 PM, Pierre Joye wrote:
> hi,
>
> CCing Ilia and Johannes as Andrei "discussed with the RM offline", I
> suppose it is Ilia, but Johannes is
On Thu, Mar 18, 2010 at 6:44 PM, Raphael Geissert wrote:
> Here I'm talking about adding support for tokyo cabinets as a dba handler,
> not a complete interface to the multiple tokyo cabinet APIs.
>
This is already in old-trunk:
http://svn.php.net/repository/php/php-src/branches/FIRST_UNICODE_IMP
On Thu, Mar 18, 2010 at 5:47 PM, mathieu.suen
wrote:
> Peter Lind wrote:
>>
>> On the contrary, it's quite obvious what's going on. In both examples
>> __get() returns an array as PHP would normally do it (i.e. NOT by
>> reference) which means that if you try to modify that you'll end up
>> modify
On Thu, Mar 18, 2010 at 4:50 PM, Lukas Kahwe Smith wrote:
>
> On 18.03.2010, at 18:48, David Soria Parra wrote:
>
> On 2010-03-18, Pierre Joye wrote:
>>
>>> On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans wrote:
>>>
>>> I do agree that we need to do major releases more often, but just
se
On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote:
> +1 For shorter release cycles. Shorter release cycles could also allow us
> to move major releases immediately to bug and security fixes only. I've
> never been a fan of seeing additional features added in minor releases.
> It's confus
Michael Maclean wrote:
> Antony Dovgal wrote:
>>> Here I'm talking about adding support for tokyo cabinets as a dba
>>> handler, not a complete interface to the multiple tokyo cabinet APIs.
>>
>> Are you sure you want to add it to ext/dba?
>> dba is .. well.. dead, and it sound like a complete wa
36 matches
Mail list logo
