# alpha3 or forever hold your peace - Thread: https://externals.io/message/41790 - Original archive: https://news-web.php.net/php.internals/41790 - Started by Lukas Kahwe Smith on 2008-11-10T07:41:08+00:00 - Messages: 27 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/41790.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 --- ## #41790 — Lukas Kahwe Smith — 2008-11-10T07:41:08+00:00 URL: https://externals.io/message/41790#41790 Hi, I just wanted to ask everybody to skim over the changes for PHP 5.3 we have in CVS (especially bigger stuff like the addition/removal of an extension etc.). Please bring up any areas you are concerned about that we might have forgotten. However I am not interested in people bringing up a debate again on namespace syntax or resolution orders (I hope to have the final behavior in CVS ASAP). This is just an attempt to ensure we do not forget something. regards, Lukas Kahwe Smith mls@pooteeweet.org PS: I know this might sound like an invitation for a flame war, it isnt. Please keep replies as technical as possible. Thanks! --- ## #41791 — Lester Caine — 2008-11-10T08:22:42+00:00 URL: https://externals.io/message/41790#41791 · In reply to: #41790 Lukas Kahwe Smith wrote: > I just wanted to ask everybody to skim over the changes for PHP 5.3 we > have in CVS (especially bigger stuff like the addition/removal of an > extension etc.). Please bring up any areas you are concerned about that > we might have forgotten. However I am not interested in people bringing > up a debate again on namespace syntax or resolution orders (I hope to > have the final behavior in CVS ASAP). This is just an attempt to ensure > we do not forget something. There is still the problems with windows builds of PHP5.3. I've not been able to test anything on new builds since php_interbase is not being compiled. I've not checked what the other dozen or so extensions missing compared with PHP5.2.x are - which is running fine. Despite numerous requests as to why the PHP5.2.x code will not compile in 5.3 we seem to be no further forward. The Linux builds do seem to be OK, but my main testbed is the windows stuff. ( Please - No comments about "Not needing xxx to test!" - My initial test suit runs everything against the database - no database it fails ) -- 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 --- ## #41793 — Alexey Zakhlestin — 2008-11-10T09:32:46+00:00 URL: https://externals.io/message/41790#41793 · In reply to: #41790 > Hi, > > I just wanted to ask everybody to skim over the changes for PHP 5.3 we have > in CVS (especially bigger stuff like the addition/removal of an extension > etc.). Please bring up any areas you are concerned about that we might have > forgotten. However I am not interested in people bringing up a debate again > on namespace syntax or resolution orders (I hope to have the final behavior > in CVS ASAP). This is just an attempt to ensure we do not forget something. > > regards, > Lukas Kahwe Smith > mls@pooteeweet.org > > PS: I know this might sound like an invitation for a flame war, it isnt. > Please keep replies as technical as possible. Thanks! 1) We have broken streams, currently: http://bugs.php.net/bug.php?id=46049 2) We still need someone to do upgrades to new parameter-parsing api in a) ext/mysql and ext/mysqli (I believe these are in works and will be committed soon) b) ext/interbase (any volunteers?) -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #41797 — Lester Caine — 2008-11-10T10:18:20+00:00 URL: https://externals.io/message/41790#41797 · In reply to: #41793 Alexey Zakhlestin wrote: > 2) We still need someone to do upgrades to new parameter-parsing api in > b) ext/interbase (any volunteers?) Where will I find some help on actually what needs doing? I presume that the Linux build has not been updated although I'm not actually seeing a problem at present. Perhaps I've simply got that wrong as well :( -- 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 --- ## #41796 — Pierre Joye — 2008-11-10T10:27:10+00:00 URL: https://externals.io/message/41790#41796 · In reply to: #41791 > Lukas Kahwe Smith wrote: > There is still the problems with windows builds of PHP5.3. I've not been > able to test anything on new builds since php_interbase is not being > compiled. I've not checked what the other dozen or so extensions missing > compared with PHP5.2.x are - which is running fine. You know why ibase is missing (see the firebird-php archive as well). And I would like to know which other "dozen of extensions" are missing. > Despite numerous requests as to why the PHP5.2.x code will not compile in > 5.3 we seem to be no further forward. The Linux builds do seem to be OK, but > my main testbed is the windows stuff. This sentence makes no sense. And we already explained hundred of times what was used in 5.2 is not usable anymore (security, reliability, can't be updated, no src, etc.). Please check the archives if you need a detailed explanation. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #41798 — Jani Taskinen — 2008-11-10T10:41:44+00:00 URL: https://externals.io/message/41790#41798 · In reply to: #41790 Lukas Kahwe Smith wrote: > Hi, > > I just wanted to ask everybody to skim over the changes for PHP 5.3 we > have in CVS (especially bigger stuff like the addition/removal of an > extension etc.). Please bring up any areas you are concerned about that > we might have forgotten. However I am not interested in people bringing > up a debate again on namespace syntax or resolution orders (I hope to > have the final behavior in CVS ASAP). This is just an attempt to ensure 1. Change ext/phar to be disabled by default 2. Change ext/ereg to be disabled by default (scheduled to be removed in PHP 6, iirc?) 3. Remove ext/mhash (replaced by ext/hash) --Jani --- ## #41799 — Lester Caine — 2008-11-10T10:42:18+00:00 URL: https://externals.io/message/41790#41799 · In reply to: #41796 Pierre Joye wrote: > > > […] > > > […] > > You know why ibase is missing (see the firebird-php archive as well). > And I would like to know which other "dozen of extensions" are > missing. Pierre there are some 44 extensions in the 5.2.x snapshot and only 30 odd in the 5.3.x snapshot - I don't have time to go through every one to check their status. Is that information available somewhere? > > […] > > This sentence makes no sense. And we already explained hundred of > times what was used in 5.2 is not usable anymore (security, > reliability, can't be updated, no src, etc.). Please check the > archives if you need a detailed explanation. This only seems to be a problem with windows builds? Although the other branch of this thread has brought up something that I simply was not aware of. It may well have been thoroughly discussed and documented, but if that is the current problem, then we can deal with it - if someone how knows what changes are needed can point us in the right direction ... -- 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 --- ## #41801 — Lukas Kahwe Smith — 2008-11-10T10:50:15+00:00 URL: https://externals.io/message/41790#41801 · In reply to: #41799 > Pierre Joye wrote: > > […] > Pierre there are some 44 extensions in the 5.2.x snapshot and only > 30 odd in the 5.3.x snapshot - I don't have time to go through every > one to check their status. Is that information available somewhere? This is why I asked to check the NEWS file: http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=log&pathrev=PHP_5_3 That file should list all intentional changes. If something is changed which is not listed there, it either needs to be listed or fixed. > > […] > This only seems to be a problem with windows builds? > Although the other branch of this thread has brought up something > that I simply was not aware of. It may well have been thoroughly > discussed and documented, but if that is the current problem, then > we can deal with it - if someone how knows what changes are needed > can point us in the right direction ... I just talked to Pierre and he said he is in contact with people from Firebird to get this resolved. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #41802 — Alexey Zakhlestin — 2008-11-10T10:55:34+00:00 URL: https://externals.io/message/41790#41802 · In reply to: #41797 > Alexey Zakhlestin wrote: > > […] > > Where will I find some help on actually what needs doing? I presume that the > Linux build has not been updated although I'm not actually seeing a problem > at present. Perhaps I've simply got that wrong as well :( Simple instruction is here: http://marc.info/?l=php-internals&m=121391697512351&w=2 -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #41803 — Lukas Kahwe Smith — 2008-11-10T10:56:33+00:00 URL: https://externals.io/message/41790#41803 · In reply to: #41798 > 2. Change ext/ereg to be disabled by default (scheduled to be > removed in PHP 6, iirc?) IIRC we are not yet in agreement on the removal. AFAIK its already an extension in PHP6, but I am not sure if we wanted to continue with the proposal that Andrei (IIRC) made to remove it. If we are doing to remove it we should add E_DEPRECATED. > 3. Remove ext/mhash (replaced by ext/hash) So what was the deal here? ext/hash automatically provides the ext/ mhash functions if the extension is not compiled in. So the main reason to keep ext/mhash is just to allow if extension mhash exists .. ? I think this is easy enough for people to fix by replacing this check with an `function_exists()` check. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #41804 — Marcus Boerger — 2008-11-10T10:58:39+00:00 URL: https://externals.io/message/41790#41804 · In reply to: #41798 Hello Jani, Monday, November 10, 2008, 11:41:44 AM, you wrote: > Lukas Kahwe Smith wrote: > > […] > 1. Change ext/phar to be disabled by default We are not disabling thois because Jani doesn't like it. > 2. Change ext/ereg to be disabled by default (scheduled to be removed in > PHP 6, iirc?) Do we already have plans on how and when to move this to pecl? > 3. Remove ext/mhash (replaced by ext/hash) Yep, should be dropped. > --Jani Best regards, Marcus --- ## #41805 — Jani Taskinen — 2008-11-10T11:04:01+00:00 URL: https://externals.io/message/41790#41805 · In reply to: #41803 Lukas Kahwe Smith wrote: > > > > > […] > > IIRC we are not yet in agreement on the removal. AFAIK its already an > extension in PHP6, but I am not sure if we wanted to continue with the You don't follow the CVS a lot, do you? revision 1.2.2.2 date: 2007/10/05 15:00:05; author: jani; state: Exp; lines: +56 -0 MFH:- Moved the old regex functions to own extension: ereg > proposal that Andrei (IIRC) made to remove it. If we are doing to remove > it we should add E_DEPRECATED. > > > […] > > So what was the deal here? ext/hash automatically provides the ext/mhash > functions if the extension is not compiled in. So the main reason to > keep ext/mhash is just to allow if extension mhash exists .. ? I think > this is easy enough for people to fix by replacing this check with an > `function_exists()` check. Exactly. --Jani --- ## #41808 — Jani Taskinen — 2008-11-10T11:06:30+00:00 URL: https://externals.io/message/41790#41808 · In reply to: #41804 Marcus Boerger wrote: > Hello Jani, > > Monday, November 10, 2008, 11:41:44 AM, you wrote: > > > […] > > > […] > We are not disabling thois because Jani doesn't like it. Eh? It wasn't supposed to be enabled everywhere from the beginning! Only for the RC stage. Search the mailing list. It's not about me not liking it or not, it's about general usefulness. --Jani --- ## #41809 — Lester Caine — 2008-11-10T11:15:09+00:00 URL: https://externals.io/message/41790#41809 · In reply to: #41801 Lukas Kahwe Smith wrote: > > […] > > This is why I asked to check the NEWS file: > http://cvs.php.net/viewvc.cgi/php-src/NEWS?view=log&pathrev=PHP_5_3 > > That file should list all intentional changes. If something is changed > which is not listed there, it either needs to be listed or fixed. OK - one of the missing things here is the windows builds of the pecl code. This used to be provided as a separate zip in the old snapshot system, and so it made little difference if a package was core or pecl. Is there a current windows snapshot of the pecl library, and a matching PECL-5.3.0 to go with the alpha builds anywhere? ( A couple of the packages I'm missing are in the pecl pack on 5.2.x which is why there was a little confusion on what was available ) -- 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 --- ## #41810 — Jani Taskinen — 2008-11-10T11:27:42+00:00 URL: https://externals.io/message/41790#41810 · In reply to: #41798 Jani Taskinen wrote: > Lukas Kahwe Smith wrote: > > […] > > 1. Change ext/phar to be disabled by default > 2. Change ext/ereg to be disabled by default (scheduled to be removed in > PHP 6, iirc?) > 3. Remove ext/mhash (replaced by ext/hash) I forgot this one: 4. Output buffering rewrite MFH: http://bugs.php.net/bug.php?id=42641&edit=1 --Jani --- ## #41811 — Lukas Kahwe Smith — 2008-11-10T11:48:38+00:00 URL: https://externals.io/message/41790#41811 · In reply to: #41805 > Lukas Kahwe Smith wrote: > > […] > > You don't follow the CVS a lot, do you? I do, but sometimes I miss a commit. > revision 1.2.2.2 > date: 2007/10/05 15:00:05; author: jani; state: Exp; lines: +56 -0 > MFH:- Moved the old regex functions to own extension: ereg Ok, so its already an extension in PHP 5.3, that does not mean that we have scheduled its removal in PHP 6. Personally I am fine with removing ereg, but then again I have always refrained from using ereg. Its going to be a bit of a pain, but IIRC ereg is not going to play well in our brave new unicode world unless someone does considerable work on ereg .. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #41812 — Lukas Kahwe Smith — 2008-11-10T11:52:16+00:00 URL: https://externals.io/message/41790#41812 · In reply to: #41810 > 4. Output buffering rewrite MFH: http://bugs.php.net/bug.php?id=42641&edit=1 If there is a significant show of hands of people that feel that the code in HEAD is so much easier to maintain, that suddenly they feel more inclined than before to actually care about bugs in output buffering and that they will take care of any BC issues that pop up, Johannes and I might reconsider our decision to not MFH OB. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #41814 — Lukas Kahwe Smith — 2008-11-10T11:55:44+00:00 URL: https://externals.io/message/41790#41814 · In reply to: #41808 > Marcus Boerger wrote: > > […] > > Eh? It wasn't supposed to be enabled everywhere from the beginning! > Only for the RC stage. Search the mailing list. It's not about me > not liking it or not, it's about general usefulness. No, this is just your selective interpretation of the situation. We decided to enable it by default because if we felt its important to be enabled by default. We left ourselves the option of not enabling it by default (or even removing it) in case we find issues that make it unfit to be enabled by default (or bundled). So far it seems that Greg/Marcus/Steph have been quick to react to any issues that have popped up. Checking the pecl and php bug tracker seems to validate this. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #41815 — johannes@php.net — 2008-11-10T12:08:31+00:00 URL: https://externals.io/message/41790#41815 · In reply to: #41798 > 1. Change ext/phar to be disabled by default Is that the only case? We have a few new extensions, fileinfo is enabled by default at the moment, hash is, sqlite3 is, ... So the question is: What's the purpose of bundling extensions and what's the risk? - In general I think the reason to bundle stuff is to make it available as "default" stuff, so enabling by default makes sense. But then we also have to enable more stuff without external dependencies (mbstring, mysqlnd [1]) and we should consider enabling by default stuff where header and libs are on most systems (like zlib) ... but then again we get a really big beast as default config. So, what's the right line? > 2. Change ext/ereg to be disabled by default (scheduled to be removed in > PHP 6, iirc?) kind of related to the previous thing, we should at least deprecate it, removing has benefits as it's often insecure to use ereg (barely anyone is aware of \0-Byte problems ...) > 3. Remove ext/mhash (replaced by ext/hash) isn't mhash just a compatibility wrapper on top of hash? Kicking that out is bad for getting people to migrate to 5.3. johannes [1] Disclaimer: I'm paid by Sun/MySQL --- ## #41819 — Lester Caine — 2008-11-10T12:21:54+00:00 URL: https://externals.io/message/41790#41819 · In reply to: #41809 Lester Caine wrote: > Lukas Kahwe Smith wrote: > > […] > > OK - one of the missing things here is the windows builds of the pecl > code. This used to be provided as a separate zip in the old snapshot > system, and so it made little difference if a package was core or pecl. > Is there a current windows snapshot of the pecl library, and a matching > PECL-5.3.0 to go with the alpha builds anywhere? > > ( A couple of the packages I'm missing are in the pecl pack on 5.2.x > which is why there was a little confusion on what was available ) OK going on from this. Current windows alpha does not have php_dba.dll php_gmp.dll php_mcrypt.dll php_pspell.dll php_snmp.dll And I presume php_zip.dll has moved to pecl as it's now available there, but none of them are appearing in the notes. -- 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 --- ## #41822 — Pierre Joye — 2008-11-10T12:42:05+00:00 URL: https://externals.io/message/41790#41822 · In reply to: #41819 > Current windows alpha does not have > php_mcrypt.dll mcrypt is present (builtin) > php_dba.dll > php_gmp.dll They will be in the next release. > php_pspell.dll > php_snmp.dll snmp and pspell are likely to do not be present in the next release and maybe not in the final release (windows only). The underlying libraries are not portable enough to be used on windows and the versions used before have critical issues (security or crashes). > And I presume php_zip.dll has moved to pecl as it's now available there, but > none of them are appearing in the notes. zip is present too (builtin) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #41823 — konference@kukulich.net — 2008-11-10T14:28:55+00:00 URL: https://externals.io/message/41790#41823 · In reply to: #41822 Pierre Joye napsal(a): > > […] > > snmp and pspell are likely to do not be present in the next release > and maybe not in the final release (windows only). The underlying > libraries are not portable enough to be used on windows and the > versions used before have critical issues (security or crashes). Would it be better to have these extension with some issues (current state) than not to have them at all? Regards Jaroslav Hanslik --- ## #41825 — Kalle Sommer Nielsen — 2008-11-10T14:51:19+00:00 URL: https://externals.io/message/41790#41825 · In reply to: #41823 2008/11/10 Jaroslav Hanslík : > Pierre Joye napsal(a): > > > […] > > > Would it be better to have these extension with some issues (current state) > than not to have them at all? As from what I could understand from Pierre, then SNMP is dead on Windows and have been for a very long time (for example it doesn't even compile). I don't remember about pspell, but I think it would make more sense to maybe include something like enchant for spelling though. -- Kalle Sommer Nielsen --- ## #41827 — Sean Coates — 2008-11-10T14:58:46+00:00 URL: https://externals.io/message/41790#41827 · In reply to: #41790 > Please bring up any areas you are concerned about that we might have > forgotten. PHP_5_3 as of this morning does not contain that patch that makes ArrayObject behave like an array (reset()). Here's a test for that (I don't have php-src karma) if anyone would care to commit it. Passes on 5.2.6, but fails on 5.3alpha3-dev S --TEST-- Ensure that ArrayObject acts like an array --SKIPIF-- --FILE-- --EXPECT-- bar1bar --- ## #41828 — Pierre Joye — 2008-11-10T15:06:16+00:00 URL: https://externals.io/message/41790#41828 · In reply to: #41825 On Mon, Nov 10, 2008 at 3:51 PM, Kalle Sommer Nielsen wrote: > 2008/11/10 Jaroslav Hanslík : > > […] > > As from what I could understand from Pierre, then SNMP is dead on > Windows and have been for a very long time (for example it doesn't > even compile). > > I don't remember about pspell, but I think it would make more sense to > maybe include something like enchant for spelling though. Enchant works but not using pspell (for the same reason than ext/pspell does not), it works with almost any other spelling system, on all platforms. But that's not the problem neither the solution as enchant is not part of the core. pspell and netsmnp libraries are not portable and can't be built on windows. We don't feel like releasing packages with critical security issues is a good thing to do. If we do not find a solution by the time of 5.3-final, we can always provide an extra package with these packages but with a (very) strong warning about using them in production environment. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- Next page: https://externals.io/message/41790.md?page=2