5.3 todos - Externals

17 years ago by Lukas Kahwe Smith — view source — reply

unread

Hi,

It seems aside from some smaller commits, the last minute closure
change has gone through without issues.
Our todo list however doesnt have that many checked off items:
http://wiki.php.net/todo/php53#next_release_beta2rc1

To me the biggest issue is the UPGRADING README. So please approach
Steph if you want to help.

The following items remain open:

write UPGRADING README file (Steph)
add more tests for fileinfo (Felix/Derick)
make all extensions use php implementation of getenv (Pierre)
reorganize the bundled php.ini files to production/development
recommendations (Eric/Nathan)
re-enable phar for big endian systems (Scott)

The following remain open and it does not seem someone is actively
working in it:

Fix static build of extension when static is the default and –enable-
snapshot-build is used
Improve the build script to ease the parsing of the output and QA
ob_flush() should fail to flush unerasable buffers
tokenizer misses last single-line comment
ob_start(): inconsistent behaviour with undefined callbacks
pcntl_signal needs declare(ticks) which is deprecated since 5.3
opendir() fails on Windows directories with parent directory
unaccessible
Bus error during build of phar.php
PDO: persistent connection leak
memory leak in the re2c
fix memleak in zend_object_handlers.c
PHP_5_3 missed merge from PHP_5_2 for write_func callback

Other issues recently raised on the list

reflection/arginfo overlap issue
Throwing E_DEPRECATED on startup
casting doubles to ints

I have send out an email to several larger OSS projects that are on
the primary-qa-tests@lists.php.net mailinglist. BTW: please subscribe
any key projects you know that are not yet on this list:
http://pooteeweet.org/blog/1439

Again, I will be offline 99% of the time starting this Saturday until
March 5th. I hope that while I am gone we will have another release
that covers the above mentioned issues and ideally that would be RC1
(unless bigger issues are uncovered that require larger changes).
Until then please let me know if you are taking over any of the above
items so that I can update the wiki. Speaking of wiki, Pierre also has
admin rights on the wiki and of course root access to the box.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

17 years ago by shire — view source — reply

unread

Lukas Kahwe Smith wrote:

The following remain open and it does not seem someone is actively
working in it:

PHP_5_3 missed merge from PHP_5_2 for write_func callback

Seeing as I have an interest in this getting in 5_3, I'll work up a patch for this unless someone wants to speak up that they've got it. I don't have Karma to Zend though, so I'll need someone to commit for me. ;-)

-shire

17 years ago by Andi Gutmans — view source — reply

unread

-----Original Message-----
From: shire [mailto:shire@tekrat.com]
Sent: Thursday, February 12, 2009 11:02 AM
To: Lukas Kahwe Smith
Cc: PHP Internals List
Subject: Re: [PHP-DEV] 5.3 todos

Seeing as I have an interest in this getting in 5_3, I'll work up a
patch for
this unless someone wants to speak up that they've got it. I don't
have Karma
to Zend though, so I'll need someone to commit for me. ;-)

You can send me the patch.

Andi

17 years ago by Hannes Magnusson — view source — reply

unread

-----Original Message-----
From: shire [mailto:shire@tekrat.com]
Sent: Thursday, February 12, 2009 11:02 AM
To: Lukas Kahwe Smith
Cc: PHP Internals List
Subject: Re: [PHP-DEV] 5.3 todos

Seeing as I have an interest in this getting in 5_3, I'll work up a
patch for
this unless someone wants to speak up that they've got it. I don't
have Karma
to Zend though, so I'll need someone to commit for me. ;-)

You can send me the patch.

And you are?
CTO of some company? Claiming you wrote PHP?
Why should the PHP community give a damn? There were way more people
involved then you.
Some of them even got fired few days ago.

I have a great interest in the patch as well, and I have zend karma
too. Who are you to judge if the patch makes sense or not? I am pretty
damn sure I have done more fore PHP then you have in the past few
months. Let the fudge community take care of his patch.

-Hannes

My co-workers say I swear to much, they told me to use "fudge" and
"frick" more... :)
Andi: I love you and all, but you have not been around for a good
while. Let OSS be OSS. Don't try to treat us as your employees.

17 years ago by Andi Gutmans — view source — reply

unread

-----Original Message-----
From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com]
Sent: Saturday, February 14, 2009 6:04 PM
To: Andi Gutmans
Cc: shire; Lukas Kahwe Smith; PHP Internals List
Subject: Re: [PHP-DEV] 5.3 todos

And you are?
CTO of some company? Claiming you wrote PHP?
Why should the PHP community give a damn? There were way more people
involved then you.
Some of them even got fired few days ago.

I have a great interest in the patch as well, and I have zend karma
too. Who are you to judge if the patch makes sense or not? I am pretty
damn sure I have done more fore PHP then you have in the past few
months. Let the fudge community take care of his patch.

Just to set the record straight Hannes and I already communicated on
this and we are good.
I guess I should have been a bit more verbose because what I meant was
that I'd commit it but it seems that was misunderstood and caused
somewhat of an overreaction :)

Andi

17 years ago by Marcus Boerger — view source — reply

unread

Hello shire,

Thursday, February 12, 2009, 8:02:06 PM, you wrote:

Lukas Kahwe Smith wrote:

The following remain open and it does not seem someone is actively
working in it:

PHP_5_3 missed merge from PHP_5_2 for write_func callback

Seeing as I have an interest in this getting in 5_3, I'll work up a
patch for this unless someone wants to speak up that they've got it. I
don't have Karma to Zend though, so I'll need someone to commit for me. ;-)

He there, thanks for looking into this (I sadly really cannot find much
more time these days than allows me to occasionally read PHP mails).
Thus I gave you karma now. If you want I can of course review your patch.

Best regards & thanks
Marcus

17 years ago by shire — view source — reply

unread

Marcus Boerger wrote:

Hello shire,

Thursday, February 12, 2009, 8:02:06 PM, you wrote:

Lukas Kahwe Smith wrote:

The following remain open and it does not seem someone is actively
working in it:

PHP_5_3 missed merge from PHP_5_2 for write_func callback

Seeing as I have an interest in this getting in 5_3, I'll work up a
patch for this unless someone wants to speak up that they've got it. I
don't have Karma to Zend though, so I'll need someone to commit for me. ;-)

He there, thanks for looking into this (I sadly really cannot find much
more time these days than allows me to occasionally read PHP mails).
Thus I gave you karma now. If you want I can of course review your patch.

Thanks Marcus! The patch should be in CVS now (via Dmitry) let me know if you or anyone else see any issues.

-shire

17 years ago by Arnaud Le Blanc — view source — reply

unread

Hi,

pcntl_signal needs declare(ticks) which is deprecated since 5.3

I marked this as a documentation issue. This has been discussed when it
was decided to deprecate ticks. Although it would be great to keep
ticks, at least for use with signals, nobody said to be able to make
ticks safer (or crash-free).

http://bugs.php.net/bug.php?id=46171 - stream_bucket_new()

The entry reports that it is not possible to create a new bucket in a
user space stream filter while the stream is closing. The reason is that
the filter method is called inside of php_stream_free() and at this
point the stream resource is not valid (and stream_bucket_new() takes
the stream resource as argument). I can't see a way to fix this.

Regards,

Arnaud

17 years ago by Lukas Kahwe Smith — view source — reply

unread

pcntl_signal needs declare(ticks) which is deprecated since 5.3

I marked this as a documentation issue. This has been discussed when
it
was decided to deprecate ticks. Although it would be great to keep
ticks, at least for use with signals, nobody said to be able to make
ticks safer (or crash-free).

You assigned the ticket to yourself. Can you collaborate with the doc
team to get this fixed in the docs?

http://bugs.php.net/bug.php?id=46171 - stream_bucket_new()

The entry reports that it is not possible to create a new bucket in a
user space stream filter while the stream is closing. The reason is
that
the filter method is called inside of php_stream_free() and at this
point the stream resource is not valid (and stream_bucket_new() takes
the stream resource as argument). I can't see a way to fix this.

If you feel comfortable making the call, I guess it should be wontfix
and maybe a note in the docs?

Thx for getting back to us with this analysis!

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

17 years ago by Matt Wilmas — view source — reply

unread

Hi Lukas!

Just wanted to send a quick message about some things I'll try to do. :-)
Guess I'm a little late to "return," heh -- and I'm finishing a new system
build now and have to migrate stuff over :-/, but I'll get to these PHP
things soon as I can, on whatever system...

----- Original Message -----
From: "Lukas Kahwe Smith"
Sent: Wednesday, February 11, 2009

Hi,
[...]
The following remain open and it does not seem someone is actively
working in it:
[...]

tokenizer misses last single-line comment

This is a pretty simple fix, AFAICT. Besides the tokenizer thing, I believe
the Warning about unterminated /* ... comments is still missing because of
the same re2c issue(s). I'd take care of both.

Other issues recently raised on the list
[...]

casting doubles to ints

I'll send a possible DVAL_TO_LVAL, etc. solution (consistent/reliable
overflow across platforms) for consideration as soon as I whip up and test
it... There's also a couple other inconsistencies and behavior changes with
the existing code that I don't think have been mentioned.

On a related note, and concerning the int-operand bitwise operators (where I
first brought up the casting changes) and %, I'll have a possible update for
them on 32-bit systems, to hopefully mostly eliminate overflow issues with
them, regardless of DVAL_TO_LVAL method. See also Bug #46579 (% integer
overflow - no error message).

Will also try to fix some other small Bugs... Thought there was one I was
going to mention, but can't remember ATM. #45184 (algorithm to limit random
numbers to a certain range is flawed) seems like it might be another I can
look at (assigned to Pierre), though I may be missing something. Well, I'll
do what little bit I can besides what I mentioned here!

Again, I will be offline 99% of the time starting this Saturday until
March 5th.
[...]
regards,
Lukas Kahwe Smith

Have a good trip/vacation. :-D

Matt

17 years ago by Hannes Magnusson — view source — reply

unread

In the last two upgrading guides, we've repeated much of what is already in
the NEWS file or in the release notes. This makes me wonder what the point
is of having an upgrading guide...?

Think about the online manual. In 2 years from now people should still
be able to read the upgrading guide and it should still make sense
without needing to hunt down random release announcements or outdated
NEWS files.

The upgrade which gets committed to php-src will be taken, word by
word, and ported to Docbook and made available at
http://php.net/migration53 (just like /migration52 and
/migration51..).

Is this entirely necessary? (I can see a case for listing new classes in the
global namespace.)

Unless you want duplicated work, one file to php-src and one for the docs, yes.

17 years ago by Steph Fox — view source — reply

unread

Hi Hannes,

Think about the online manual. In 2 years from now people should still
be able to read the upgrading guide and it should still make sense
without needing to hunt down random release announcements or outdated
NEWS files.

The upgrade which gets committed to php-src will be taken, word by
word, and ported to Docbook and made available at
http://php.net/migration53 (just like /migration52 and
/migration51..).

But this was actually an add-on after I put the initial 5.1 upgrading guide
together. A 200-line document became a 500-line document overnight, and
voila - nobody reads the thing.

Is this entirely necessary? (I can see a case for listing new classes in
the
global namespace.)

Unless you want duplicated work, one file to php-src and one for the docs,
yes.

I'd like to know why you can't just take release info from the release notes
for the manual. Duplicating the release notes seems a bit pointless.

Steph

17 years ago by Steph Fox — view source — reply

unread

But this was actually an add-on after I put the initial 5.1 upgrading
guide
together. A 200-line document became a 500-line document overnight, and
voila - nobody reads the thing.

Actually I'm wrong - that was 5.2. The 5.1 upgrade guide appears to be
as-was.

So again, why are we listing new extensions, functions and class constants?

Steph

17 years ago by Vesselin Kenashkov — view source — reply

unread

IMHO listing new functions is useful - there could be a name collision with
a function in users code (I know it is improbable, because the functions are
named extname_funcname, but still possible)

But this was actually an add-on after I put the initial 5.1 upgrading

guide
together. A 200-line document became a 500-line document overnight, and
voila - nobody reads the thing.

Actually I'm wrong - that was 5.2. The 5.1 upgrade guide appears to be
as-was.

So again, why are we listing new extensions, functions and class constants?

Steph

--

--
Vesselin Kenashkov
developer at
www.webstudiobulgaria.com

17 years ago by Steph Fox — view source — reply

unread

IMHO listing new functions is useful - there could be a name collision
with
a function in users code (I know it is improbable, because the functions
are
named extname_funcname, but still possible)

Improbable indeed. The nearest we ever came to that was with the Date class
(because PEAR already had a Date class - nobody else complained, mind.)
Maybe it would be best to list any new core PHP functions and mention
prefixes used by any new extensions.

The 5.2 guide lists 'new optional parameters' too. I honestly don't see how
the existence of a new optional parameter can possibly impact existing code;
ergo, it has no place in an upgrade guide.

Steph

17 years ago by Pierre Joye — view source — reply

unread

IMHO listing new functions is useful - there could be a name collision
with
a function in users code (I know it is improbable, because the functions
are
named extname_funcname, but still possible)

Improbable indeed. The nearest we ever came to that was with the Date class
(because PEAR already had a Date class - nobody else complained, mind.)
Maybe it would be best to list any new core PHP functions and mention
prefixes used by any new extensions.

The 5.2 guide lists 'new optional parameters' too. I honestly don't see how
the existence of a new optional parameter can possibly impact existing code;
ergo, it has no place in an upgrade guide.

An upgrade is not only about problems, it is also about solutions. A
kind of tutorial on how to use all the changes in a given release in
your applications. It often helps to clean codes, remove work 'round,
etc. An upgrade guide is often the document many will read, and not
the NEWS file, which is not that useful in the current format.

So yes, we should keep as much info as we can in the guide, include
listing of new functions, constants or classes.

Cheers,

Pierre

http://blog.thepimp.net | http://www.libgd.org

17 years ago by Steph Fox — view source — reply

unread

An upgrade is not only about problems, it is also about solutions.

You need a problem before providing a solution. Really.

A
kind of tutorial on how to use all the changes in a given release in
your applications. It often helps to clean codes, remove work 'round,
etc. An upgrade guide is often the document many will read, and not
the NEWS file, which is not that useful in the current format.

They won't read it if it's too darn long :)

Please go back to the original discussion about the purpose of this guide.
It was aimed primarily at sysadmins. If we turn it into a prettier version
of NEWS or release notes, all it means is we still need an upgrade file for
sysadmins. So in response to Hannes' earlier question, yes I think these
should be two separate documents - one for end users in the manual, one for
sysadmins in the src. And no I don't mind writing both, I just want to be
very clear about their purpose.

Steph

17 years ago by Hannes Magnusson — view source — reply

unread

Please go back to the original discussion about the purpose of this guide.
It was aimed primarily at sysadmins. If we turn it into a prettier version

Then I guess I need to read the archives.
I can't imagine why a system admin would give a damn about new
language features, object model, reference changes, pdo, new error
levels or how to check if a class inherits another class.

Maybe listing every single new constant is a bit excessive, but we do
at the very very very least need to link to the page that lists them
then.

-Hannes

17 years ago by Lukas Kahwe Smith — view source — reply

unread

Hey Steph,

Personally I think we should list all changes. For certain changes we
should devote some explanations (like E_DEPRECATED). For the most part
I see this document as a place where we provide an overview of things
which then gives them the right key word to look in the documentation.
Also like in the case of E_DEPRECATED we should briefly explain the
reasoning and how people should adapt their php.ini files .. so in
that sense all longer text should be about migration issues, where are
documentation is more about documenting the behavior in each version.

I expect some people to skim this document, others to read it to the
letter, others will just grep it if they run into issues. Thinking
about it, we should somehow try and make sure that any likely error
message that people will see in their error logs after upgrading will
get them a hit when they search for it in this document.

So in summary, I feel the key point for this document is:

a single document that lists all changes
contains pointers that enables someone to look up more details in
the documentation
enables people who get new "strange" error messages to find pointers
towards the documentation
some lengthier migration related explanations that go beyond what we
want to provide in the documentation

regards,
Lukas

17 years ago by Lester Caine — view source — reply

unread

Lukas Kahwe Smith wrote:

Hey Steph,

Personally I think we should list all changes. For certain changes we
should devote some explanations (like E_DEPRECATED). For the most part I
see this document as a place where we provide an overview of things
which then gives them the right key word to look in the documentation.
Also like in the case of E_DEPRECATED we should briefly explain the
reasoning and how people should adapt their php.ini files .. so in that
sense all longer text should be about migration issues, where are
documentation is more about documenting the behavior in each version.

I expect some people to skim this document, others to read it to the
letter, others will just grep it if they run into issues. Thinking about
it, we should somehow try and make sure that any likely error message
that people will see in their error logs after upgrading will get them a
hit when they search for it in this document.

So in summary, I feel the key point for this document is:

a single document that lists all changes

contains pointers that enables someone to look up more details in the
documentation

enables people who get new "strange" error messages to find pointers
towards the documentation

some lengthier migration related explanations that go beyond what we
want to provide in the documentation

That sounds about right ...
BUT perhaps some of the more complex explanations should have their own
document. If it 'requires more explanation than we want to provide in
the documentation' that does seem to suggest that a development perhaps
DOES need better doumentation?

--
Lester Caine - G8HFL

Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

17 years ago by Steph Fox — view source — reply

unread

BUT perhaps some of the more complex explanations should have their own
document. If it 'requires more explanation than we want to provide in
the documentation' that does seem to suggest that a development perhaps
DOES need better doumentation?

In the manual, really. But - quite.

Steph

17 years ago by Steph Fox — view source — reply

unread

So in summary, I feel the key point for this document is:

a single document that lists all changes

contains pointers that enables someone to look up more details in the
documentation

enables people who get new "strange" error messages to find pointers
towards the documentation

some lengthier migration related explanations that go beyond what we
want to provide in the documentation

Right. That isn't what ever happened before 5.2. Up til then it was simply
somewhere you could look to get an overview of changes that would affect
existing code. Hence the name of the file.

See, I knew we were looking at completely different things..!

How's about a short, sane version in the src and an extended
bells-and-whistles version for the manual? With a link provided in the src
version to the extended version.

Steph

17 years ago by Steph Fox — view source — reply

unread

Then I guess I need to read the archives.
I can't imagine why a system admin would give a damn about new
language features, object model, reference changes, pdo, new error
levels or how to check if a class inherits another class.

They'd need to know that there had been major changes in the language and
they couldn't just upgrade willy-nilly without warning the affected
developers about changes that could break existing code, which the file
addresses. They'd need to know too that (for example) 8 core extensions are
no longer in the core, and that some new ones are. They might need to know
about error reporting level changes, depending on the setup. They'd need to
know about new core .ini directives and those affecting new extensions in
the core. They'd probably want to know about streams changes (any).

Maybe listing every single new constant is a bit excessive, but we do
at the very very very least need to link to the page that lists them
then.

That's not a problem. Lead me to your docs :)

Steph

17 years ago by Daniel Convissor — view source — reply

unread

Hi Steph:

In the last two upgrading guides, we've repeated much of what is already
in the NEWS file or in the release notes. This makes me wonder what the
point is of having an upgrading guide...?

Because the guide is in the manual. The manual is the difinitive source
on how to use PHP.

The initial idea was to have some way to tell users in general (and
sysadmins in particular) which existing code might break in the new PHP
version, and how to work around those issues. It should be a relatively
short file if we stick with this, but what we actually have (now and for
the last two releases) is 500-plus lines of text that ...

Sure, the guide be better structured. But it should contain everything.

Thanks,

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

17 years ago by Steph Fox — view source — reply

unread

Hi Dan,

Because the guide is in the manual. The manual is the difinitive source
on how to use PHP.

The guide was only added directly into the manual quite recently. This is
exactly what I'm trying to say; its purpose has shifted since it became part
of the manual and it's lost whatever usefulness it had in the src as a
result.

Sure, the guide be better structured. But it should contain everything.

It's nothing to do with structure. "Everything" makes for a very long file,
full stop.

Steph

17 years ago by Daniel Convissor — view source — reply

unread

Hi Steph:

It's nothing to do with structure. "Everything" makes for a very long
file, full stop.

It doesn't matter that the XML file is long. Each section is broken up
into a separate page in the manual.

You want the upgrade guide to contain just the things that will cause
difficulties upgrading. That's cool. Put such info in one <section> and
it will be churned out as one web page in the manual. Name it clearly.
Then anyone can easily find and read the info you want in one URI.

The rest of the information can be put into other <section>s so folks who
want more in depth coverage can have it too.

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

17 years ago by Steph Fox — view source — reply

unread

It doesn't matter that the XML file is long. Each section is broken up
into a separate page in the manual.

I'm talking about the UPGRADE file in the source, which is plain text.

Have you ever tried to read it?

Steph

17 years ago by Daniel Convissor — view source — reply

unread

Hi Steph:

I'm talking about the UPGRADE file in the source, which is plain text.

AH! Pardon the misunderstanding. Yeah, it seems that file should be
short and sweet then point folks to the manual.

Thanks,

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

17 years ago by Leon KUKOVEC — view source — reply

unread

Hi all,

A while back I published a patch for PHP 5.2 and SNMP. Anyone had time
to review it
and if so, any comments? Could this patch be considered as a PHP 5.3 TODO item?

Anything I need to do to accept the patch?

Thanks.

--
Best Regards,
Leon

17 years ago by Lukas Kahwe Smith — view source — reply

unread

Hi all,

A while back I published a patch for PHP 5.2 and SNMP. Anyone had time
to review it
and if so, any comments? Could this patch be considered as a PHP 5.3
TODO item?

Anything I need to do to accept the patch?

Err did you open a bug ticket for this with the patch attached (or
with an url to the patch).

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

5.3 todos View as Markdown

Cheers,

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL