Re: [PHP-DEV] Req #51295: busyTimeout method for SQLite3
Hi, I checked around PDO (which I don't use at all, but the source is usually a good documentation). The timeout can be changed for SQLite and SQLite3 PDO drivers with: $pdo-setAttribute(PDO::ATTR_TIMEOUT, value_in_seconds) I see that PDO::ATTR_TIMEOUT is not documented on http://php.net/manual/en/pdo.setattribute.php - it might be a good idea to fix this :) Mark Le dimanche 14 mars 2010 à 09:57 +0200, Jess Portnoy a écrit : Hello Mark, Note that while indeed sqlite3_busy_timeout() is not extended by the SQLite3 and PDO_SQLITE extensions, it is called internally in ext/pdo_sqlite/sqlite_driver.c. I think it is a good idea to extend it but also, that if you do, it should probably also be done for PDO_SQLITE as it may be useful there as well. May the source be with you, Best regards, Jess Portnoy Mark Karpeles wrote: Hello, I've been encountering a problem with SELECT queries and SQLite3 as load was growing on my system. From times to times I was getting this error: Warning: SQLite3Stmt::execute(): Unable to execute statement: database is locked After searching on google I saw I should call sqlite3_busy_timeout() and found out that there was no way to call it from the SQLite3 extension (which is new to PHP 5.3.x). Here's a patch that will add this method to the SQLite3 class: http://bugs.php.net/51295 https://ookoo.org/svn/snip/php_5_3-sqlite3-busytimeout-method.patch Any comment welcome. Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Req #51295: busyTimeout method for SQLite3
Hi Mark, I agree but I'm not the maintainer for PDO_SQLITE, I just happen to know it somewhat and thought it can be useful to you as reference. I am CCing Wez Furlong who I believe is the lead for it. May the source be with you, Best regards, Jess Portnoy Mark Karpeles wrote: Hi, I checked around PDO (which I don't use at all, but the source is usually a good documentation). The timeout can be changed for SQLite and SQLite3 PDO drivers with: $pdo-setAttribute(PDO::ATTR_TIMEOUT, value_in_seconds) I see that PDO::ATTR_TIMEOUT is not documented on http://php.net/manual/en/pdo.setattribute.php - it might be a good idea to fix this :) Mark Le dimanche 14 mars 2010 à 09:57 +0200, Jess Portnoy a écrit : Hello Mark, Note that while indeed sqlite3_busy_timeout() is not extended by the SQLite3 and PDO_SQLITE extensions, it is called internally in ext/pdo_sqlite/sqlite_driver.c. I think it is a good idea to extend it but also, that if you do, it should probably also be done for PDO_SQLITE as it may be useful there as well. May the source be with you, Best regards, Jess Portnoy Mark Karpeles wrote: Hello, I've been encountering a problem with SELECT queries and SQLite3 as load was growing on my system. From times to times I was getting this error: Warning: SQLite3Stmt::execute(): Unable to execute statement: database is locked After searching on google I saw I should call sqlite3_busy_timeout() and found out that there was no way to call it from the SQLite3 extension (which is new to PHP 5.3.x). Here's a patch that will add this method to the SQLite3 class: http://bugs.php.net/51295 https://ookoo.org/svn/snip/php_5_3-sqlite3-busytimeout-method.patch Any comment welcome. Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)
2010-03-13 19:33, Rasmus Lerdorf skrev: No, not ok. We will call the next release whatever we like. People who have written books or articles about PHP 6 inferring they knew what the final state of PHP 6 would be were misguided. We never got to the point of a final feature set much less a release date. I think I made it clear I have no sympathy for the people responsible for those books. However, I have lots of sympathy for the *readers* of those books! And the readers of the PHP manual. And the readers of Andrei's slides and of various articles on the net. And I have lots of sympathy for everyone who will see such resources show up when they google for a solution to a problem. Maybe my words sounded a bit critical and unappreciative. That was not my intention. I have tons of respect for all of you who make PHP such a wonderful language to use and teach. I am not qualified to suggest specifics about the technical route forward and have therefore carefully avoided anything that looks like casting a vote about 5.4. If, however, skipping version 6 will lead to less confusion and reduce the amount of education needed about the changes in the language, why not chose the easier path? Or to put this differently: Of course the core contributors are at liberty to call the next major version 6, but I think there is wisdom in going straight to 7. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)
2010-03-13 19:50, Alain Williams skrev: I occasionally teach PHP courses and mention up coming features, but always with the caveat: nothing is set in stone until it hits the streets. Your students are not the problem. Nor are mine. But just because there exist educators who know their job and students that carefully listen to them does not mean that there also are students who are taught by less knowledgeable tutors or people who are (being) self taught. A ton of information might fix the problem at hand, but if going straight to version 7 reduces that need to a few kilograms, why not chose the easier path? -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)
2010-03-13 23:05, Marco Tabini skrev: But, really, who cares about a name while there isn't even a spec? The name should be the last thing that needs to be considered—literally, so that the trolls don't have an opportunity to flood the market with opportunistic titles until the new version is well defined and ready to go. Calling it “trunk” at this point ought to be more than enough, IMO. I am OK with calling it trunk, with a few caveats: 1. Keep calling it trunk on your blogs and tweets and talks as well, and specifically state that version numbering is undecided. 2. Some habits form from day one. This is why I started this discussion knowing very well that there was not a spec. The name that gets used informally on this list will very soon trickle into blogs and tweets. A decision about the version number - or a firm decision to keep calling it trunk and enforcing that decision - must come quickly. Yes, even before there is a spec! -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)
No, not ok. We will call the next release whatever we like. People who have written books or articles about PHP 6 inferring they knew what the final state of PHP 6 would be were misguided. We never got to the point of a final feature set much less a release date. +1 There is going to be plenty of time (IMHO) between now and when PHP6 could be ready to start re-educating people so that it becomes less of a problem. As for people who bought books on PHP6 well they should go back to the publisher and ask for a refund. If people have been writing code to be PHP6 ready then more fool them, since its madness to try and write for a version of software which is in constant flux. Anyone that I have discussed this with over the last year have pretty much universally written code for PHP 5.3 in the hope that the migration to PHP6 would be made more simple. Marco -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
If Unicode were the solution, the PHP project was on the right page with 6.0. Sure there remained work to do, but... How long did it take to realize UTF16 wasn't the end of the story? UCS-4 is the minimum to solve this, and we all agree that 32 bits aren't storing a single char in the western world, no way, no how. The UTF-8 solution is probably the right answer... you maintain 95% of char *UTF behavior, and you gain international character representation. The only Unicode OS I can think of offhand is NT, and of course they hit the UCS-4 problem early. They found this out 15+ years ago. Sure it doesn't appear as atomic, one Xword per char, but the existing library frameworks contain most of the string processing that is required. There is no 16-bit network transmission API that I can think of, you are still devolving to UTF-8 for client results. To move forward with accepting -and preferring- UTF-8 as the representation of characters throughout PHP, recognizing UTF-8 for char-length representations, and so forth, would do wonders to move forwards. And 8-bit octet data can be set aside in the same data structures. It is the straightforward answer, which is probably why Linux did not repeat Windows NT decision, and adopted utf-8. Hi, UTF8 is good for text that contains mostly ASCII chars and the occasional Unicode international chars. It's also generally ok for storing and passing strings between apps. However, it's a really poor representation of a string in memory as a code point can vary between 1 and 4 bytes. Doing simple calculations like $string[$x] means you need to walk and interpret the string from the start until you count to the codepoint you needed. UTF8 also takes 4 bytes for representing characters in the higher bit planes, as quite a lot of bits are lost for every char in order to describe how long the code point is, and when it ends and so on. This means memory-wise it may not be of big benefit to asian countries. Since the western world, as you put it, wouldn't want to waste 4 bytes for characters they use that fit in 1 byte, we could opt to store the encoding of a string as a byte enumerating all possible encodings supported by PHP (I believe they're less than 255..), so the string functions know how to operate and convert between them. This means you can use Unicode only when you need it, which reduces the impact of using full 4 bytes per code point, as you can still use Latin-1 1-byte encoding and freely mix it with Unicode, and still produce UTF8 output in the end, for the web (the final output encoding to UTF8 from *anything* is cheap). Another alternative is doing what JavaScript does. JavaScript uses 2-byte encoding for Unicode, and when a code point needs more than 2 bytes, it's encoded in 4 bytes. JavaScript will count that codepoint as 2 chars, although it's technically one codepoint. It's awkward, but since PHP is a web language, consistency with JavaScript may even be beneficial. It also solves the $string[$x] problem as you no longer need to walk the array, you just blindly report the 2 bytes at address string points + 2 * $x. With this approach, all characters in the BMP will report correct offsets with char index and substr functions as they fit in 2 bytes. Workarounds and helper functions can be introduced for handling 4 byte codepoints for the other planes. It of course makes certain operations harder, such as character ranges between two 4-byte codepoints in regex will produce unexpected results, and regex will see these chars: [2bytes2bytes-2bytes2bytes] i.e.: [a b-c d] and not this: [4bytes-4bytes] Still, having variable-width encoding UTF8 or UTF16 doesn't cut it for general use to me as in tests it shows drastic slowdown when the script needs to do heavy string processing. I'd rather have it take more RAM for Unicode strings while being fast, and use Latin-1 when what I need is Latin-1. Regards, Stan Vassilev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] moving forward
Hi, I would like to ask everyone that wants to see some new feature in the next bigger PHP update to create an RFC on the wiki. I have to check why the register link [1] disappeared from the login page (anyone with a php.net svn account can just login without registering). Ideally we will simply cherry pick the features for the next release from the old todo list [2] as well as mature RFC's. Personally I also think that we should make sure that we do not spend months in this planning stage. If we do not yet feel ready to do the big leap to a new major version number, since we cannot play the lets drop some BC card in every release, then we can of course just bump the minor version number for the next release. Even if we do not solve unicode with the next release we already have plenty of good proposals on the table. But focusing development again on a single branch and the willingness to review our approach to unicode I think we can move forward again either way. So I am suggesting that we should aim to have a solid release plan (schedule and feature set) done no later than end of April. Personally I would like us to be able to look towards the first alpha for this new version in Q4 2010 or Q1 2011, but that is of course something that is up for debate. Obviously if we give ourselves a more or less specific timeframe it also limits the number of features we can deliver. But I think we should really become a bit more disciplined in this regard and maybe even work towards a semi regular cycle for new releases. I really like how PostgreSQL is doing things in this regard. Of course they still slip the dates at times, but so it goes (but they do not slip a few years .. just a couple of months). The important bit is that with regular releases contributors feel more like they will actually see the solution to their itch scratching released before they move on to other itched to scratch. It also means that if a feature doesnt make it into the release plan for the next release, developers will at least have a rough idea for the timeframe when they will have another chance to get a given feature into PHP. Plus it will make it easier for others (like distributions and app developers) to work with us. Most importantly it will spare us running into the situation we had with PHP 6 and 5.3 in the future where because we had time finishing up something we just end up piling features up for years making the release process a nightmare. I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence. But again, I really do hope that we can however wrap up the debate up by end of April. regards, Lukas Kahwe Smith m...@pooteeweet.org [1] http://wiki.php.net/rfc?do=register [2] http://wiki.php.net/todo/php60 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Req #51295: busyTimeout method for SQLite3
I'm sure that the docs team will add this to the manual if you ask them politely. Specifically, PDO_SQLITE defaults to a 60 second busy timeout. This can be changed by setting PDO::ATTR_TIMEOUT. The value is specified in seconds. ISTR that this option can also be specified for some of the other database drivers to affect the network timeout when processing a query. --Wez. On Mar 14, 2010, at 4:17 AM, Jess Portnoy wrote: Hi Mark, I agree but I'm not the maintainer for PDO_SQLITE, I just happen to know it somewhat and thought it can be useful to you as reference. I am CCing Wez Furlong who I believe is the lead for it. May the source be with you, Best regards, Jess Portnoy Mark Karpeles wrote: Hi, I checked around PDO (which I don't use at all, but the source is usually a good documentation). The timeout can be changed for SQLite and SQLite3 PDO drivers with: $pdo-setAttribute(PDO::ATTR_TIMEOUT, value_in_seconds) I see that PDO::ATTR_TIMEOUT is not documented on http://php.net/manual/en/pdo.setattribute.php - it might be a good idea to fix this :) Mark Le dimanche 14 mars 2010 à 09:57 +0200, Jess Portnoy a écrit : Hello Mark, Note that while indeed sqlite3_busy_timeout() is not extended by the SQLite3 and PDO_SQLITE extensions, it is called internally in ext/pdo_sqlite/sqlite_driver.c. I think it is a good idea to extend it but also, that if you do, it should probably also be done for PDO_SQLITE as it may be useful there as well. May the source be with you, Best regards, Jess Portnoy Mark Karpeles wrote: Hello, I've been encountering a problem with SELECT queries and SQLite3 as load was growing on my system. From times to times I was getting this error: Warning: SQLite3Stmt::execute(): Unable to execute statement: database is locked After searching on google I saw I should call sqlite3_busy_timeout() and found out that there was no way to call it from the SQLite3 extension (which is new to PHP 5.3.x). Here's a patch that will add this method to the SQLite3 class: http://bugs.php.net/51295 https://ookoo.org/svn/snip/php_5_3-sqlite3-busytimeout-method.patch Any comment welcome. Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
hi, On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev sv_for...@fmethod.com wrote: UTF8 is good for text that contains mostly ASCII chars and the occasional Unicode international chars. It's also generally ok for storing and passing strings between apps. That's not completely correct. UTF-8 is used out there for almost unicode only applications as well. I'd to say it is a matter of what the projects are written for. See below. Still, having variable-width encoding UTF8 or UTF16 doesn't cut it for general use to me as in tests it shows drastic slowdown when the script needs to do heavy string processing. I'd rather have it take more RAM for Unicode strings while being fast, and use Latin-1 when what I need is Latin-1. The problem I have with UTF-16 is that it does not fit well with PHP usage. While you are right about the performence vs memory usage, it is sadly a small part of the problem. If you take a look at the current implementation (trunk, which uses UTF-16), we have to convert to UTF-8 almost everywhere as long as we deal with external APIs (file systems or other libs). The win we may have from using UTF-16 is almost completely lost by the conversions cost. That obviously does not apply for scripts using only core PHP features (no file access, no extension usage, etc.), but these scripts are barely real worlds use cases. Please not that I'm not voting against UTF-16 or for UTF-8, but I would like to have a real evaluation this time, unlike what has been done for trunk a couple of years ago. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev sv_for...@fmethod.com wrote: UTF8 also takes 4 bytes for representing characters in the higher bit planes, as quite a lot of bits are lost for every char in order to describe how long the code point is, and when it ends and so on. This means memory-wise it may not be of big benefit to asian countries. I remember Brian Aker saying that they chose to work internally with UTF-8 for Drizzle. His explanation of it was that asian countries have so much english content mixed in that on average even for them UTF-8 still had a lower footprint than UTF-16/32. I do not know where the stats came from, but if it holds any truth it is worth considering. Cheers, Jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementing fdopen in PHP
Dennis Hotson wrote: Hi all, It's my first post, so go easy on me. :-) I'm trying to implement PHP support for github's erlang RPC server called ernie. So basically I've been porting the following ruby code to PHP: http://github.com/mojombo/ernie/blob/master/lib/ernie.rb The problem I'm having is on line 127-128: input = IO.new(3) I believe this is equivalent to fdopen() in C, but there doesn't appear to be any way to do this in PHP. So basically, I'm a bit stuck and looking for advice on how to proceed. Should I implement this in core PHP or as an extension? What's the best way to get a function like this into PHP? Regards, Dennis Hotson You perform a fdopen() in C where you have a low level file descriptor and make it a stdio on. In php there's only one kind of file descriptor, and all file functions work with them. Creating a fdopen call is useless, since it needs a previous descriptor to work from, and all descriptors are equal. Where's that file descriptor coming from? Since it's an RPC server I suspect you will create it somehow with fsockopen. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
On Sun, Mar 14, 2010 at 3:23 PM, Jordi Boggiano j.boggi...@seld.be wrote: On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev sv_for...@fmethod.com wrote: UTF8 also takes 4 bytes for representing characters in the higher bit planes, as quite a lot of bits are lost for every char in order to describe how long the code point is, and when it ends and so on. This means memory-wise it may not be of big benefit to asian countries. I remember Brian Aker saying that they chose to work internally with UTF-8 for Drizzle. His explanation of it was that asian countries have so much english content mixed in that on average even for them UTF-8 still had a lower footprint than UTF-16/32. I do not know where the stats came from, but if it holds any truth it is worth considering. The idea behind his reasonning was to about optimizing the 90% of the cases while being fast enough for the last 10% (could have been other numbers, but that's the idea). For what I remember about our discussions, he also mentioned fast UTF-8 capable string processing implementation (as fast as what UTF-16 could be). I like this the 90/10 approach especially as it actually matches what we have in PHP. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
On Sun, Mar 14, 2010 at 11:23 PM, Jordi Boggiano j.boggi...@seld.be wrote: On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev sv_for...@fmethod.com wrote: UTF8 also takes 4 bytes for representing characters in the higher bit planes, as quite a lot of bits are lost for every char in order to describe how long the code point is, and when it ends and so on. This means memory-wise it may not be of big benefit to asian countries. I remember Brian Aker saying that they chose to work internally with UTF-8 for Drizzle. His explanation of it was that asian countries have so much english content mixed in that on average even for them UTF-8 still had a lower footprint than UTF-16/32. I do not know where the stats came from, but if it holds any truth it is worth considering. This is true, as most of the text data that are interchanged in the Internet should be represented in HTML, in which such characters and alphabetic tags always appear alternatively. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementing fdopen in PHP
Hi, Le dimanche 14 mars 2010 à 15:30 +0100, Keisial a écrit : Creating a fdopen call is useless, since it needs a previous descriptor to work from, and all descriptors are equal. Where's that file descriptor coming from? When you spawn a new program, you can pass it additionnal descriptors on top of stdin/stdout/stderr. For example look at proc_open(). You can pass more than 3 descriptors, and communicate if the program is able to use them. An alternative on linux is to $fp = fopen(/proc/self/fd/3,r+) Mark -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementing fdopen in PHP
On Sun, Mar 14, 2010 at 3:39 PM, M. karpe...@ookoo.org wrote: Hi, Le dimanche 14 mars 2010 à 15:30 +0100, Keisial a écrit : Creating a fdopen call is useless, since it needs a previous descriptor to work from, and all descriptors are equal. Where's that file descriptor coming from? When you spawn a new program, you can pass it additionnal descriptors on top of stdin/stdout/stderr. For example look at proc_open(). You can pass more than 3 descriptors, and communicate if the program is able to use them. An alternative on linux is to $fp = fopen(/proc/self/fd/3,r+) That's what proc_open does and allows. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Where are we ACTUALLY on Unicode?
Hi, I used to work a job where we used UTF-16 for embedded applications. Our company chose UTF-16 over UTF-8 because it was byte-aligned and therefore faster / more effecient to process than UTF-8. However theres no reason why UTF-8 has to be drastically slower. The truch is, even we could have used UTF-8 there. And I don't buy the whole byte size / memory thing either. Even in our restricted embedded environments, that was never a consideration anyway. Because a well written program won't bloat memory by holding too many strings. That's what MYSQL is for. Apple uses UTF-16 for CFString, NSString data. But elsewhere (and on the web!) most people uses UTF-8. Pretty much. You should implement UTF-8, with a view to still allow adding UTF-16 support later on. That is to say, the encoding should be wrapped, and switchable underneath. Of course all that is easier said than done with PHP. But thats the right way to do it. On Sun, Mar 14, 2010 at 2:23 PM, Jordi Boggiano j.boggi...@seld.be wrote: On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev sv_for...@fmethod.com wrote: UTF8 also takes 4 bytes for representing characters in the higher bit planes, as quite a lot of bits are lost for every char in order to describe how long the code point is, and when it ends and so on. This means memory-wise it may not be of big benefit to asian countries. I remember Brian Aker saying that they chose to work internally with UTF-8 for Drizzle. His explanation of it was that asian countries have so much english content mixed in that on average even for them UTF-8 still had a lower footprint than UTF-16/32. I do not know where the stats came from, but if it holds any truth it is worth considering. Cheers, Jordi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On 3/13/10 11:57 AM, Derick Rethans wrote: I am also in favour for getting back to one branch for new development. And that branch should be trunk. However, I am a little bit reluctant to just kill all Unicode support. I don't think we can get around the fact that propr Unicode support is going to be even more important in the future than it already is today. However, we can also not get around the fact that the current state of Unicode-in-PHP isn't the most ideal situation. I do however think that most of the current approaches of adding Unicode support into PHP 6 (current trunk) have the proper ideas behind that, but I do think that in some cases we went slightly overboard of supporting Unicode everywhere with the new unicode type. For example, we don't really need to have this for variable or function names or support every encoding for writing scripts in. (We do need to *support* Unicode there, but not with the unicode string type.) Another example is that we perhaps don't have to support every encoding out there. So I would suggest the following things to do: - get rid of Jani's play branch - move trunk to branches/FIRST_UNICODE_IDEA - put 5.2 in security fix only mode - pht 5.3 in bug fix only mode - start adding new features (traits, Ilia's scalar typehint patch, output buffering things) to the new trunk cloned from 5.3. - in the meanwhile, start working on patching in back Unicode support, but in small steps. Exactly which things, and how we'd have to find out. But I do think it needs to be a *core* language feature, and not simply solved by extensions. We also need to make sure everybody understands that Unicode isn't just about encodings, or charsets and that thre are differences between that. Education is going to be important (and adding Unicode back in small bits would certainly help there). As I now have plenty of time to work on things, I'd be happy to act as RM, and wouldn't mind working on roadmaps and sorting out what good bits we have/had, and which things we don't want to port back into the new trunk. Depending on how things go, this could become 5.4 or 6 or something else. FWIW, +1 Clearly, the current implementation is too difficult for people to work with. I still think that the major principles it was built on apply, but if people want to do a more lightweight approach that still uses those principles, I'm not going to be in the way. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: moving forward
On 2010-03-14, Lukas Kahwe Smith m...@pooteeweet.org wrote: Hi, I would like to ask everyone that wants to see some new feature in the next bigger PHP update to create an RFC on the wiki. I have to check why the register link [1] disappeared from the login page (anyone with a php.net svn account can just login without registering). Ideally we will simply cherry pick the features for the next release from the old todo list [2] as well as mature RFC's. +1. RFCs still seem to be a good way to work out new features while we still need to improve the way we handle it and particularly make developers who already have an account still write RFCs (and create an experimental branch) instead of committing directly to trunk. Personally I also think that we should make sure that we do not spend months in this planning stage. If we do not yet feel ready to do the big leap to a new major version number, since we cannot play the lets drop some BC card in every release, then we can of course just bump the minor version number for the next release. Even if we do not solve unicode with the next release we already have plenty of good proposals on the table. But focusing development again on a single branch and the willingness to review our approach to unicode I think we can move forward again either way. So I am suggesting that we should aim to have a solid release plan (schedule and feature set) done no later than end of April. Personally I would like us to be able to look towards the first alpha for this new version in Q4 2010 or Q1 2011, but that is of course something that is up for debate. Obviously if we give ourselves a more or less specific timeframe it also limits the number of features we can deliver. But I think we should really become a bit more disciplined in this regard and maybe even work towards a semi regular cycle for new releases. I really like how PostgreSQL is doing things in this regard. Of course they still slip the dates at times, but so it goes (but they do not slip a few years .. just a couple of months). The important bit is that with regular releases contributors feel more like they will actually see the solution to their itch scratching released before they move on to other itched to scratch. It also means that if a feature doesnt make it into the release plan for the next release, developers will at least have a rough idea for the timeframe when they will have another chance to get a given feature into PHP. Plus it will make it easier for others (like distributions and app developers) to work with us. Most importantly it will spare us running into the situation we had with PHP 6 and 5.3 in the future where because we had time finishing up something we just end up piling features up for years making the release process a nightmare. I agree that we should try to get releases out more regularly, also we should still have a little bit of flexibiltiy (particularly in the first releases). I hope we can reduce some of the issues that we had with 5.3. I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence. Yes experimental branching shouldn't be a problem. I persoanlly would prefer if we just create php-src/experimental/ or php-src/developer/name/branch for this purpuse to not clutter branches/ with a million names. But again, I really do hope that we can however wrap up the debate up by end of April. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: moving forward
On Mar 14, 2010, at 12:58 PM, David Soria Parra wrote: I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence. Yes experimental branching shouldn't be a problem. I persoanlly would prefer if we just create php-src/experimental/ or php-src/developer/name/branch for this purpuse to not clutter branches/ with a million names. I'd actually like to bring up the question of going to DVCS for PHP. I know I was a vocal advocate against it before, but I've learned a bit since then. Anyone care to discuss? -- Gwynne smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Re: moving forward
(g)it would be better for cherrypicking and handling multiple development branches, but it the developers cant use it propery, the its PITA. Tyrael On Sun, Mar 14, 2010 at 8:09 PM, Gwynne Raskind gwy...@darkrainfall.org wrote: On Mar 14, 2010, at 12:58 PM, David Soria Parra wrote: I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence. Yes experimental branching shouldn't be a problem. I persoanlly would prefer if we just create php-src/experimental/ or php-src/developer/name/branch for this purpuse to not clutter branches/ with a million names. I'd actually like to bring up the question of going to DVCS for PHP. I know I was a vocal advocate against it before, but I've learned a bit since then. Anyone care to discuss? -- Gwynne -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: moving forward
On 14.03.2010, at 20:42, Ferenc Kovacs wrote: (g)it would be better for cherrypicking and handling multiple development branches, but it the developers cant use it propery, the its PITA. Tyrael On Sun, Mar 14, 2010 at 8:09 PM, Gwynne Raskind gwy...@darkrainfall.org wrote: On Mar 14, 2010, at 12:58 PM, David Soria Parra wrote: I would also like to bring up another point. Since we are now on SVN (and there are nice bridges to DVCS for those that want to use them), we can now also more easily enable developers to work on complex or risky features in a branch instead of trunk. So for example if we feel like it will take us too long to come up with a unicode plan, then I would suggest to leave it out the next release and simply have the people that have an idea for an approach create a branch and work things out there. This way normal development in trunk can commence. Yes experimental branching shouldn't be a problem. I persoanlly would prefer if we just create php-src/experimental/ or php-src/developer/name/branch for this purpuse to not clutter branches/ with a million names. I'd actually like to bring up the question of going to DVCS for PHP. I know I was a vocal advocate against it before, but I've learned a bit since then. Anyone care to discuss? Oh no .. another dangerous topic. Again we have been there even before the switch. The idea is to keep the centralized repo on svn, because the masses know how it works, the tools are widely available and we have plenty of experience among us in how to keep svn running. I see little incentive to move the _central_ repo to a DVCS. Are the bridges to git, mercurial, bzaar etc really so bad that this topic is worth discussing (no sarcasm, honest question)? regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug # 50755
I have attached patches for bug # 50755 on bugs.php.net. These also cleanup to PDO DBLIB code to have less of a memory footprint and to prepare for other feature additions such as multiple rowset support. I have compiled and tested on x86. Can someone review and provide feedback. Thank you. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: moving forward
Oh no .. another dangerous topic. Again we have been there even before the switch. The idea is to keep the centralized repo on svn, because the masses know how it works, the tools are widely available and we have plenty of experience among us in how to keep svn running. I see little incentive to move the _central_ repo to a DVCS. Are the bridges to git, mercurial, bzaar etc really so bad that this topic is worth discussing (no sarcasm, honest question)? I only have experience with git. The problem with something like git-svn is that your git branch becomes an island. I can't share that branch with anyone else. So all I really get is git syntax within an svn environment. I have no problem working with svn and actually prefer it for projects that use a compiler. For PHP apps, git is great because nothing has to be built. Bouncing between git branches means I have to recompile PHP every time (or set up some system of symlinks). -- Herman Radtke hermanrad...@gmail.com | http://hermanradtke.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: moving forward
I'd actually like to bring up the question of going to DVCS for PHP. I know I was a vocal advocate against it before, but I've learned a bit since then. Anyone care to discuss? Isn't it already available? http://github.com/php/php-src Marco -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)
Keryx Web wrote: Summary: A. There seem to be universal agreement that the up until last week branch of PHP called trunk was going to be PHP 6 is a dead end and not the way into the future. (I'll call this PHP 6.old from now on. is this the case?
Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)
2010-03-14 23:27, rich gray skrev: is this the case? I have not seen anyone speak up and say anything else. Of course that does not mean that every single line of code will be scrapped or that every idea has been abandoned. But it seems to me there is universal agreement about scrapping it as a whole. -- Keryx Web (Lars Gunther) http://keryx.se/ http://twitter.com/itpastorn/ http://itpastorn.blogspot.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6
On Sat, Mar 13, 2010 at 7:35 PM, Pierre Joye pierre@gmail.com wrote: On Sat, Mar 13, 2010 at 10:07 AM, Chen Ze surfc...@gmail.com wrote: I think unicode should only care for string handling. Formatting numbers should not be the thing that unicode cares. Unicode is a standard for text, not for text or number formatting. That's a totally wrong statement. Please read Unicode specs, there are clear references to formatting as well as many other areas. It is impossible to split the unicode scripts from the way we process or use them (output, formatting, sorting, searching, conversions, etc.). sorry, I am wrong. I was thinking number formatting, collation as a independent standard even many implementation(for example intl) are based on the unicode. But I still think we should implement unicode string handling and something like number formatting as independent interface. For internal unicode type for function name, class name or something others, since there is other mail talking about that, I will give my point there. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- aka Surf Chen http://chenze.name/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementing fdopen in PHP
On Mon, Mar 15, 2010 at 1:41 AM, Pierre Joye pierre@gmail.com wrote: When you spawn a new program, you can pass it additionnal descriptors on top of stdin/stdout/stderr. For example look at proc_open(). You can pass more than 3 descriptors, and communicate if the program is able to use them. An alternative on linux is to $fp = fopen(/proc/self/fd/3,r+) That's what proc_open does and allows. So in my case, the erlang server is doing the equivalent of proc_open() to call my PHP program. My PHP program needs a way to access these 'extra' file descriptors. I'm fine with using fopen(/proc/self/fd/3,r) for now, but something like fdopen() would be more appropriate IMHO so that it will work on platforms other than linux. Slightly off topic, but another useful application of fdopen() is for hot swapping a running program. http://nathanwiegand.com/wp/2010/02/hot-swapping-binaries/ I realise this is probably not a priority for PHP, but I actually enjoy writing network servers in PHP and this would be a pretty awesome feature. Regards, Dennis Hotson (PS. Sorry for the dupe Pierre, I forgot to reply to the list.)
Re: [PHP-DEV] Re: moving forward
On Mon, Mar 15, 2010 at 6:25 AM, Herman Radtke hermanrad...@gmail.com wrote: Oh no .. another dangerous topic. Again we have been there even before the switch. The idea is to keep the centralized repo on svn, because the masses know how it works, the tools are widely available and we have plenty of experience among us in how to keep svn running. I see little incentive to move the _central_ repo to a DVCS. Are the bridges to git, mercurial, bzaar etc really so bad that this topic is worth discussing (no sarcasm, honest question)? I only have experience with git. The problem with something like git-svn is that your git branch becomes an island. I can't share that branch with anyone else. So all I really get is git syntax within an svn environment. There are a number of ways to share your branches with others. At least you can do it by pushing your local changesets to some remote repository. I've actually been experimenting with modified PHP core with some language features added by forking the mirror on github.com [1]. I've never felt any inconvenience there. I really appreciate those who set up the mirror. I have no problem working with svn and actually prefer it for projects that use a compiler. For PHP apps, git is great because nothing has to be built. Bouncing between git branches means I have to recompile PHP every time (or set up some system of symlinks). I guess you can have several local repositories that have different branches checked out at the same time... [1] http://github.com/moriyoshi/php-src/ Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: moving forward
There are a number of ways to share your branches with others. At least you can do it by pushing your local changesets to some remote repository. I've actually been experimenting with modified PHP core with some language features added by forking the mirror on github.com [1]. I've never felt any inconvenience there. I really appreciate those who set up the mirror. Yes, this is possible, but in my experience branch sharing quickly falls apart in practice. If I make some change to foo.c, push it to your branch and then later on do a rebase to update from svn I just rewrote history. The commit hash you have for foo.c is now different than mine. Now sure you can also rebase, but what if you are away? I am stuck until you return. Or what if you have a commit to foo.c that is made after my commit, but updating from svn creates a conflict you need to resolve? You then again rewrite history and now I have to sync back up. And good luck if one of us cherry-picks. I think git svn does a great job for individuals working solo on a project, but for me it starts to become too tedious when groups of people are passing around branches. Or maybe I am just doing it all wrong? -- Herman Radtke hermanrad...@gmail.com | http://hermanradtke.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
