Everything

php

Home » Project » Newsgroups » php.internals » php 5.2.0 »

php 5.2.0

php.internals

Lukas Smith

20 years ago

Hi,

I updated my phptodo wiki for the next planned release. Ilia also send
me a bunch of items that I threw on there:
http://oss.backendmedia.com/PhP52

If you want me to be your personal secretary let me know what items you
are missing from the list, what items should be assigned to specific
people and finally what items are completed.

regards,
Lukas

Ilia A.

20 years ago

Heh, Lukas preempted by e-mail a bit, but the bottom line is that the
next release in the 5.X series is going to be 5.2.0. Being a minor
version release we have a greater amount of freedom then the one we
normally get for patch level releases and that's exactly what we need
for some of the changed being planned. Basically for the next week, I
would like to assemble a list of changes (using Lukas' wiki) that we
wish to integrate into this release and then make a new branch. Once
that is the final list will be published and we will start on a 3
month release cycle, where the 1st month is allotted towards making
the big changes and the remaining 2 months to get things stable. So,
if you have changes you'd like to see in 5.2 (don't go too wild
now ;-) ), reply to this e-mail.


On 2-May-06, at 6:07 AM, Lukas Smith wrote:

> Hi,
>
> I updated my phptodo wiki for the next planned release. Ilia also
> send me a bunch of items that I threw on there:
> http://oss.backendmedia.com/PhP52
>
> If you want me to be your personal secretary let me know what items
> you are missing from the list, what items should be assigned to
> specific people and finally what items are completed.
>
> regards,
> Lukas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

Ron Korving

20 years ago

Well, I'm in no position to ask anyone for anything, but... here goes anyway
;)

APC is a good caching mechanism, but is lacking in optimization features,
where for example (to my knowledge anyway) Zend Optimizer is doing a good
job. Since it looks like APC is going to be included in PHP 6 by default,
maybe it's getting more and more interesting to invest time in optimization
algorithms to enhance APC? I think it's probably the one area in which the
most performance gain for users can be achieved.

- Ron


"Ilia Alshanetsky" <ilia@prohost.org> wrote in message
news:B1DAA5C9-7F01-4E68-9205-3FE1CD2C8D65@prohost.org...

Rasmus Lerdorf

20 years ago

Ron Korving wrote:

> Well, I'm in no position to ask anyone for anything, but... here goes anyway
> ;)
>
> APC is a good caching mechanism, but is lacking in optimization features,
> where for example (to my knowledge anyway) Zend Optimizer is doing a good
> job. Since it looks like APC is going to be included in PHP 6 by default,
> maybe it's getting more and more interesting to invest time in optimization
> algorithms to enhance APC? I think it's probably the one area in which the
> most performance gain for users can be achieved.

Not sure what this has to do with PHP 5.2.0, but yes, improving the
optimizer has been on the todo for a while.  Volunteers are welcome.

-Rasmus

Sebastian Bergmann

20 years ago

Rasmus Lerdorf wrote:

> Not sure what this has to do with PHP 5.2.0, but yes, improving the
> optimizer has been on the todo for a while.  Volunteers are welcome.

Sounds like an idea for a SoC project, or is it already too late for
that?

--
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Rasmus Lerdorf

20 years ago

Sebastian Bergmann wrote:

> Rasmus Lerdorf wrote:
>> Not sure what this has to do with PHP 5.2.0, but yes, improving the
>> optimizer has been on the todo for a while.  Volunteers are welcome.
>
>  Sounds like an idea for a SoC project, or is it already too late for
>  that?

It's on the list.  No takers yet.

Ilia A.

20 years ago

While adding an optimizer to APC is definitely a good thing, but
ultimately APC is an external tool, we want to make the language
itself to become faster. There are series of things that became a bit
slower since 4.4, some have been resolved, others are still pending.
These are the things 5.2 will attempt to address.


On 2-May-06, at 1:44 PM, Ron Korving wrote:

> Well, I'm in no position to ask anyone for anything, but... here
> goes anyway
> ;)
>
> APC is a good caching mechanism, but is lacking in optimization
> features,
> where for example (to my knowledge anyway) Zend Optimizer is doing
> a good
> job. Since it looks like APC is going to be included in PHP 6 by
> default,
> maybe it's getting more and more interesting to invest time in
> optimization
> algorithms to enhance APC? I think it's probably the one area in
> which the
> most performance gain for users can be achieved.
>

Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

Dmitry Stogov

20 years ago

Hi Illia,

I am planning to make several performance related changes those will brake
binary compatibility with 5.1.
May be we need PHP_5_2 CVS branch to allow critical fixes for 5.1?

Thanks. Dmitry.

Rasmus Lerdorf

20 years ago

Dmitry Stogov wrote:

> I am planning to make several performance related changes those will brake
> binary compatibility with 5.1.
> May be we need PHP_5_2 CVS branch to allow critical fixes for 5.1?

Do you have more details on this?  Just want to avoid duplicate work.
Gopal has done some work on fixing cache line problems in the executor
which shows some promise.

-Rasmus

Dmitry Stogov

20 years ago

Hi Rasmus,

I am planning:

- some startup/shutdown sequence optimizations

- FastCGI SAPI optimization (it does linear search in environment)

- may be ZE memory mamangement optimization

Could you point me into  Gopal 's patch?
Seems I missed it, but I like review it before commit.

Thanks. Dmitry.

Andi Gutmans

20 years ago

Mainly around the memory manager at this point but we might also
start looking at some executor optimizations. Best for Gopal to send
us patches when we get to that point. Not sure what CPU he's testing
on but it's important to do so on several for these kind of
optimizations. We can do that.

Andi

At 12:00 AM 5/3/2006, Rasmus Lerdorf wrote:

Andreas Korthaus

20 years ago

Hi!

Ilia Alshanetsky wrote:

> So, if you have
> changes you'd like to see in 5.2 (don't go too wild now ;-) ), reply to
> this e-mail.

Some issues not yet in the wiki, which have been discussed on this list
some time ago:

1. date extension
with OO interface and classname "Date" (don't forget about the
PEAR::Date fun ;-))
For the OO interface, AFAIR most people prefered something like:
http://cvs.php.net/viewcvs.cgi/pecl/date/docs/examples/sample1.php?view=markup
to something like: http://www.zend.com/zend/week/date-timezone.txt

2. late static binding (keyword "this"?)
When using static classes and inheritance, you can't use parent
methodes/members today

But perhaps that's something for 6.0...

Another idea for a future PHP version:

pecl_http extension implements some really useful features:
http://dev.iworks.at/ext-http/http-functions.html.gz

Perhaps some day, when it's ready... it could implement the 5 functions
from ext/http too, and replace that extension without any BC-issues...


best regards
Andreas

Pierre Joye

20 years ago

On Tue, 02 May 2006 21:25:41 +0200
akorthaus@web.de (Andreas Korthaus) wrote:

> But perhaps that's something for 6.0...

That's all php 6.0 yes, maybe not http...

-- Pierre

Ilia A.

20 years ago

On 2-May-06, at 3:25 PM, Andreas Korthaus wrote:

> Hi!
>
> Ilia Alshanetsky wrote:
>> So, if you have changes you'd like to see in 5.2 (don't go too
>> wild now ;-) ), reply to this e-mail.
>
> Some issues not yet in the wiki, which have been discussed on this
> list some time ago:
>
> 1. date extension
> with OO interface and classname "Date" (don't forget about the
> PEAR::Date fun ;-))
> For the OO interface, AFAIR most people prefered something like:
> http://cvs.php.net/viewcvs.cgi/pecl/date/docs/examples/sample1.php?
> view=markup
> to something like: http://www.zend.com/zend/week/date-timezone.txt
>

That is on the list.

> 2. late static binding (keyword "this"?)
> When using static classes and inheritance, you can't use parent
> methodes/members today
>

Too big for PHP 5.2 IMHO

> But perhaps that's something for 6.0...
>
> Another idea for a future PHP version:
>
> pecl_http extension implements some really useful features:
> http://dev.iworks.at/ext-http/http-functions.html.gz
>
> Perhaps some day, when it's ready... it could implement the 5
> functions from ext/http too, and replace that extension without any
> BC-issues...

I'd prefer to wait with addition of new extensions until PHP 6,
unless there is a majority consensus that we absolutely must have
this extension in PHP core.


Ilia Alshanetsky
Advanced Internet Designs Inc.
ilia@prohost.org

Evert Pot

20 years ago

Hi People,

I'm not sure this is the right place to make a feature request, but here
goes..

I noticed some upgrades/ideas in the streams system lately.. Is there
any chance at all this can be migrated to an OOP system?

Here's the kind of think i would really like to see (java does it the
same way, more or less)

2 base stream interfaces
Writer
Reader

Which are implemented by:
FileWriter
FileReader
SocketWriter
SocketReader
StringWriter
StringReader

The Java IO library uses the decorator pattern to add functionality to
those base classes:

BufferedReader
BufferedWriter
HTMLFilterWriter

Since we are getting a new filter system, this could also be based on
this stream system....

This would allow be to write new base-classes for transports and make
use of all the existing filter-classes.
Also, this could be unified with XMLReader and XMLWriter and the SPL
file classes.

This implementation is just a suggestion (and I really like the
flexibility of the Java IO system).. I'm just really missing a proper
unified stream system..

Great work has already been done to centralize systems because of the
introduction of the Traversable interface and its descendants.. but more
and more often I find myself rewriting PHP extensions in PHP, because
there's no unified (abstracted) API..

I'm already pretty far in implementing this in PHP, and I would be more
than happy to PEAR it (if people are interested).. but I feel like a
system like this belongs at the core to prevent every new subsystem from
figuring out a new API...

I hope I made my point, I'll be more than happy to eloborate or help
writing specs for this system, my C skills are mediocre though..

Oh, and thanks for your great work.. PHP is the reason I can pay my rent
and I know there's a lot of people like me =)

Evert

Ilia Alshanetsky wrote:

Marcus Börger

20 years ago

Hello Evert,

Wednesday, May 3, 2006, 12:09:17 AM, you wrote:

> Hi People,

> I'm not sure this is the right place to make a feature request, but here
> goes..

> I noticed some upgrades/ideas in the streams system lately.. Is there
> any chance at all this can be migrated to an OOP system?

> Here's the kind of think i would really like to see (java does it the
> same way, more or less)

> 2 base stream interfaces
> Writer
> Reader

> Which are implemented by:
> FileWriter
> FileReader
> SocketWriter
> SocketReader
> StringWriter
> StringReader

> The Java IO library uses the decorator pattern to add functionality to
> those base classes:

> BufferedReader
> BufferedWriter
> HTMLFilterWriter

> Since we are getting a new filter system, this could also be based on
> this stream system....

> This would allow be to write new base-classes for transports and make
> use of all the existing filter-classes.
> Also, this could be unified with XMLReader and XMLWriter and the SPL
> file classes.

XMLReader/XMLWriter have nothing to do with our streams implementation
though they can leverage them. In fact they follow libxml2's api which
is inspired by C#'s xmlTextReader. Adding functions to that doesn't make
sense at all they are just wrappers that make the libraries api available
to PHP. SPL could be the start of such a thing but right now in no way is
limited to streams stuff. Again it can leverage streams of course and
that at any level.

> This implementation is just a suggestion (and I really like the
> flexibility of the Java IO system).. I'm just really missing a proper
> unified stream system..

Flexibility of the cost that it takes a decend programmer years to
understand what plays together in what sense...definitively the
opposit of php's kiss approach.

> Great work has already been done to centralize systems because of the
> introduction of the Traversable interface and its descendants.. but more
> and more often I find myself rewriting PHP extensions in PHP, because
> there's no unified (abstracted) API..

Traversable is a tag necessary to the engine and does not define any API.
The corresponding API is being defined by the two interfaces Iterator and
IteratorAggregate. None of those has anything to do with reading streams.
All that occurs is that SPL gives you a class (SplFileObject) that
simplifies reading files line by line wchih is based on Iterator, giving
it a semantical meaning.

> I'm already pretty far in implementing this in PHP, and I would be more
> than happy to PEAR it (if people are interested).. but I feel like a
> system like this belongs at the core to prevent every new subsystem from
> figuring out a new API...

If you go with such classes be sure to follow established naming conventions
and do not name them simply 'BufferedReader' or even worse 'Reader'.

> I hope I made my point, I'll be more than happy to eloborate or help
> writing specs for this system, my C skills are mediocre though..

Streams stuff belongs here. You don't want to wait forever when reading
giles do you? However having a pear like, working set of classes interfaces
would be a nice starting point. So your work would be of help of course.

> Oh, and thanks for your great work.. PHP is the reason I can pay my rent
> and I know there's a lot of people like me =)

> Evert

> Ilia Alshanetsky wrote:
>> Heh, Lukas preempted by e-mail a bit, but the bottom line is that the
>> next release in the 5.X series is going to be 5.2.0. Being a minor
>> version release we have a greater amount of freedom then the one we
>> normally get for patch level releases and that's exactly what we need
>> for some of the changed being planned. Basically for the next week, I
>> would like to assemble a list of changes (using Lukas' wiki) that we
>> wish to integrate into this release and then make a new branch. Once
>> that is the final list will be published and we will start on a 3
>> month release cycle, where the 1st month is allotted towards making
>> the big changes and the remaining 2 months to get things stable. So,
>> if you have changes you'd like to see in 5.2 (don't go too wild now
>> ;-) ), reply to this e-mail.
>>
>>
>> On 2-May-06, at 6:07 AM, Lukas Smith wrote:
>>
>>> Hi,
>>>
>>> I updated my phptodo wiki for the next planned release. Ilia also
>>> send me a bunch of items that I threw on there:
>>> http://oss.backendmedia.com/PhP52
>>>
>>> If you want me to be your personal secretary let me know what items
>>> you are missing from the list, what items should be assigned to
>>> specific people and finally what items are completed.
>>>
>>> regards,
>>> Lukas
>>>
>>> --PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>>
>> Ilia Alshanetsky
>> Advanced Internet Designs Inc.
>> ilia@prohost.org
>>
>> --PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>

Best regards,
Marcus

Evert Pot

20 years ago

Hi Marcus,

Thanks for your quick response. First I need to say I'm not really
trying to compare this with the PHP streams wrappers.. the streams
wrappers do a lot more than just streaming bytes, they even know about
files and directories...

Marcus Boerger wrote:

> XMLReader/XMLWriter have nothing to do with our streams implementation
> though they can leverage them. In fact they follow libxml2's api which
> is inspired by C#'s xmlTextReader. Adding functions to that doesn't make
> sense at all they are just wrappers that make the libraries api available
> to PHP. SPL could be the start of such a thing but right now in no way is
> limited to streams stuff. Again it can leverage streams of course and
> that at any level.
>
>
>

If XMLReader/XMLWriter would work with this streams API, it would allow
me to pass it through filters before writing/reading from a base stream
object.. Because everything implements those interfaces, the
XMLReader/XMLWriter doesnt have to know exactly what it is being fed
(either a base-stream or a stream decorated by 1 or more filters)

>> This implementation is just a suggestion (and I really like the
>> flexibility of the Java IO system).. I'm just really missing a proper
>> unified stream system..
>>
>
> Flexibility of the cost that it takes a decend programmer years to
> understand what plays together in what sense...definitively the
> opposit of php's kiss approach.
>
>

I definitely agree on this one.. the api that a developer would use now
wouldnt have to change and should not become more complicated.. but
there are also power users..

The eventual API doenst have to look that difficult.. I'm thinking of
something like :

$file = new FileReader('filename'); // to read just bytes
$file = new HTMLFilterReader(new FileReader('filename')) to filter the html

Writing to a file would work in the exact same way..

>> Great work has already been done to centralize systems because of the
>> introduction of the Traversable interface and its descendants.. but more
>> and more often I find myself rewriting PHP extensions in PHP, because
>> there's no unified (abstracted) API..
>>
>
> Traversable is a tag necessary to the engine and does not define any API.
> The corresponding API is being defined by the two interfaces Iterator and
> IteratorAggregate. None of those has anything to do with reading streams.
> All that occurs is that SPL gives you a class (SplFileObject) that
> simplifies reading files line by line wchih is based on Iterator, giving
> it a semantical meaning.
>
>

The point i tried to make was, because of traversable and its
descendants, we now can now do a simple thing like :

if ($var instanceof Traversable) echo('And we know we can iterate over
this object, regardless of the class..');

in the same manner:

if ($var instanceof Writer) echo('Now we know we can call the write()
method');

>> I'm already pretty far in implementing this in PHP, and I would be more
>> than happy to PEAR it (if people are interested).. but I feel like a
>> system like this belongs at the core to prevent every new subsystem from
>> figuring out a new API...
>>
>
> If you go with such classes be sure to follow established naming conventions
> and do not name them simply 'BufferedReader' or even worse 'Reader'.
>
>

I used simple names to easily illustrate what i wanted to do.. Java uses
the same conventions since Java 1.1.

>> I hope I made my point, I'll be more than happy to eloborate or help
>> writing specs for this system, my C skills are mediocre though..
>>
>
> Streams stuff belongs here. You don't want to wait forever when reading
> giles do you? However having a pear like, working set of classes interfaces
> would be a nice starting point. So your work would be of help of course.
>
>

I'll be happy to put it in PEAR, although this doesn't give me the power
I would love to have.

Thanks again,
Evert

Sebastian Bergmann

20 years ago

Ilia Alshanetsky wrote:

> So, if you have changes you'd like to see in 5.2, reply to this e-mail.

I have a small feature request that brought up earlier. Back then, Sara
mentioned that she would be interested in implementing this:

What I need is a userspace streams filter that acts as a default filter
through which require/include read their files. I cannot change the
include/require calls but instead have to set up a filter for the
standard ones.

Thanks,
Sebastian

--
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Andi Gutmans

20 years ago

Any reason why sqlite (pdo & ext/) can't be compiled without the
bundled sqlite. Requiring the use of the bundled sqlite can cause
symbol conflicts when another Apache module is linked with the system version?
If there's no reason, anyone who volunteers to fix it?

Thx.

At 03:07 AM 5/2/2006, Lukas Smith wrote:

Pierre Joye

20 years ago

On Tue, 02 May 2006 10:22:14 -0700
andi@zend.com (Andi Gutmans) wrote:

> Any reason why sqlite (pdo & ext/) can't be compiled without the
> bundled sqlite.

You can build using an extern sqlite. However you need 3.2.7, I just
noticed that today. I have nothing against requiring it, but it should
be detected and noticed in the changelog. Also a "minor" release is
maybe not the right time to bump the required version.

As a sidenote, you also need to install sqlite3 in a standard path.
There is actually no way to tell pdo-sqlite which sqlite to use.

--
Pierre

Did I help you? Please donate
http://blog.thepimp.net/index.php/1998/04/12/57-please-donate

Pierre Joye

20 years ago

On Tue, 2 May 2006 22:21:14 +0200
pierre.php@gmail.com (Pierre) wrote:

> On Tue, 02 May 2006 10:22:14 -0700
> andi@zend.com (Andi Gutmans) wrote:
>
> > Any reason why sqlite (pdo & ext/) can't be compiled without the
> > bundled sqlite.

While testing, I also confirm that ext/sqlite with --with-sqlite=/usr
is also broken. For some unknown reason, it tries to get files and
definitions from ext/sqlite/libsqlite/src/.

--
Pierre

Did I help you? Please donate
http://blog.thepimp.net/index.php/1998/04/12/57-please-donate

Wez Furlong

20 years ago

It should already work out-of-the-box if you pass in the prefix to
your sqlite install.

--Wez.

On 5/2/06, Andi Gutmans <andi@zend.com> wrote: