# 5.3 todos - Thread: https://externals.io/message/43000 - Original archive: https://news-web.php.net/php.internals/43000 - Started by Lukas Kahwe Smith on 2009-02-11T17:07:12+00:00 - Messages: 30 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/43000.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #43000 — Lukas Kahwe Smith — 2009-02-11T17:07:12+00:00 URL: https://externals.io/message/43000#43000 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 --- ## #43004 — Hannes Magnusson — 2009-02-11T19:13:11+00:00 URL: https://externals.io/message/43000#43004 > 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. --- ## #43005 — Steph Fox — 2009-02-11T19:20:45+00:00 URL: https://externals.io/message/43000#43005 · In reply to: #43004 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. > > […] > > 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 --- ## #43006 — Steph Fox — 2009-02-11T19:26:35+00:00 URL: https://externals.io/message/43000#43006 · In reply to: #43005 > 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 --- ## #43007 — Vesselin Kenashkov — 2009-02-11T19:31:29+00:00 URL: https://externals.io/message/43000#43007 · In reply to: #43006 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 > > […] > > 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 --- ## #43008 — Steph Fox — 2009-02-11T19:44:23+00:00 URL: https://externals.io/message/43000#43008 · In reply to: #43007 > 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 --- ## #43009 — Pierre Joye — 2009-02-11T19:46:29+00:00 URL: https://externals.io/message/43000#43009 · In reply to: #43008 > > […] > > 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 --- ## #43010 — Steph Fox — 2009-02-11T19:55:33+00:00 URL: https://externals.io/message/43000#43010 · In reply to: #43009 > 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 --- ## #43012 — Hannes Magnusson — 2009-02-11T22:20:30+00:00 URL: https://externals.io/message/43000#43012 · In reply to: #43010 > 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 --- ## #43014 — Lukas Kahwe Smith — 2009-02-11T22:40:11+00:00 URL: https://externals.io/message/43000#43014 · In reply to: #43012 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 --- ## #43015 — Daniel Convissor — 2009-02-12T03:29:14+00:00 URL: https://externals.io/message/43000#43015 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 --- ## #43016 — Lester Caine — 2009-02-12T08:39:27+00:00 URL: https://externals.io/message/43000#43016 · In reply to: #43014 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 --- ## #43017 — Steph Fox — 2009-02-12T16:37:09+00:00 URL: https://externals.io/message/43000#43017 · In reply to: #43012 > 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 --- ## #43018 — Steph Fox — 2009-02-12T16:42:41+00:00 URL: https://externals.io/message/43000#43018 · In reply to: #43014 > 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 --- ## #43019 — Steph Fox — 2009-02-12T16:45:38+00:00 URL: https://externals.io/message/43000#43019 · In reply to: #43015 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 --- ## #43020 — Steph Fox — 2009-02-12T16:46:31+00:00 URL: https://externals.io/message/43000#43020 · In reply to: #43016 > 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 --- ## #43022 — Daniel Convissor — 2009-02-12T17:00:24+00:00 URL: https://externals.io/message/43000#43022 · In reply to: #43019 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
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
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 --- ## #43023 — Steph Fox — 2009-02-12T17:06:38+00:00 URL: https://externals.io/message/43000#43023 · In reply to: #43022 > 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 --- ## #43024 — Leon KUKOVEC — 2009-02-12T17:17:33+00:00 URL: https://externals.io/message/43000#43024 · In reply to: #43022 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 --- ## #43025 — Daniel Convissor — 2009-02-12T18:43:25+00:00 URL: https://externals.io/message/43000#43025 · In reply to: #43023 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 --- ## #43026 — shire — 2009-02-12T19:02:06+00:00 URL: https://externals.io/message/43000#43026 · In reply to: #43000 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 --- ## #43028 — Arnaud Le Blanc — 2009-02-12T20:59:58+00:00 URL: https://externals.io/message/43000#43028 · In reply to: #43000 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 --- ## #43029 — Lukas Kahwe Smith — 2009-02-12T21:08:59+00:00 URL: https://externals.io/message/43000#43029 · In reply to: #43028 > > > […] > > 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? > > […] > > 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 --- ## #43030 — Lukas Kahwe Smith — 2009-02-12T21:14:00+00:00 URL: https://externals.io/message/43000#43030 · In reply to: #43024 > 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 --- ## #43039 — Matt Wilmas — 2009-02-14T01:05:29+00:00 URL: https://externals.io/message/43000#43039 · In reply to: #43000 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 --- Next page: https://externals.io/message/43000.md?page=2