Re: [PHP-DEV] Req #51295: busyTimeout method for SQLite3

2010-03-14 Thread Mark Karpeles
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, ) I see that PDO::ATTR_TIMEOUT is not documented on http://php.net/manual/en/pdo.setattr

Re: [PHP-DEV] Req #51295: busyTimeout method for SQLite3

2010-03-14 Thread Jess Portnoy
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 check

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

2010-03-14 Thread Keryx Web
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 rele

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

2010-03-14 Thread Keryx Web
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

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

2010-03-14 Thread Keryx Web
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 we

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

2010-03-14 Thread Marco
> 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 b

Re: [PHP-DEV] Where are we ACTUALLY on Unicode?

2010-03-14 Thread Stan Vassilev
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 wester

[PHP-DEV] moving forward

2010-03-14 Thread Lukas Kahwe Smith
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 simpl

Re: [PHP-DEV] Req #51295: busyTimeout method for SQLite3

2010-03-14 Thread Wez Furlong
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 t

Re: [PHP-DEV] Where are we ACTUALLY on Unicode?

2010-03-14 Thread Pierre Joye
hi, On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev 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

Re: [PHP-DEV] Where are we ACTUALLY on Unicode?

2010-03-14 Thread Jordi Boggiano
On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev 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

Re: [PHP-DEV] Implementing fdopen in PHP

2010-03-14 Thread Keisial
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

Re: [PHP-DEV] Where are we ACTUALLY on Unicode?

2010-03-14 Thread Pierre Joye
On Sun, Mar 14, 2010 at 3:23 PM, Jordi Boggiano wrote: > On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev 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, an

Re: [PHP-DEV] Where are we ACTUALLY on Unicode?

2010-03-14 Thread Moriyoshi Koizumi
On Sun, Mar 14, 2010 at 11:23 PM, Jordi Boggiano wrote: > On Sun, Mar 14, 2010 at 12:03 PM, Stan Vassilev 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, a

Re: [PHP-DEV] Implementing fdopen in PHP

2010-03-14 Thread M.
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 desc

Re: [PHP-DEV] Implementing fdopen in PHP

2010-03-14 Thread Pierre Joye
On Sun, Mar 14, 2010 at 3:39 PM, M. 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 y

Re: [PHP-DEV] Where are we ACTUALLY on Unicode?

2010-03-14 Thread dreamcat four
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 use

Re: [PHP-DEV] PHP 6

2010-03-14 Thread Andrei Zmievski
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 goi

[PHP-DEV] Re: moving forward

2010-03-14 Thread David Soria Parra
On 2010-03-14, Lukas Kahwe Smith 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 ju

Re: [PHP-DEV] Re: moving forward

2010-03-14 Thread Gwynne Raskind
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 >> br

Re: [PHP-DEV] Re: moving forward

2010-03-14 Thread Ferenc Kovacs
(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 wrote: > On Mar 14, 2010, at 12:58 PM, David Soria Parra wrote: >>> I would also like to bring up an

Re: [PHP-DEV] Re: moving forward

2010-03-14 Thread Lukas Kahwe Smith
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 > wrote: >> On Mar 14, 2010, at 12:58

[PHP-DEV] Bug # 50755

2010-03-14 Thread Stanley Sufficool
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. --

Re: [PHP-DEV] Re: moving forward

2010-03-14 Thread Herman Radtke
> 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 ince

Re: [PHP-DEV] Re: moving forward

2010-03-14 Thread Marco
> 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 M

Re: [PHP-DEV] Next major version must be 7 (Lessons learned from the ECMAScript committee)

2010-03-14 Thread rich gray
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 Thread Keryx Web
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 a

Re: [PHP-DEV] PHP 6

2010-03-14 Thread Chen Ze
On Sat, Mar 13, 2010 at 7:35 PM, Pierre Joye wrote: > On Sat, Mar 13, 2010 at 10:07 AM, Chen Ze 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. >

Re: [PHP-DEV] Implementing fdopen in PHP

2010-03-14 Thread Dennis Hotson
On Mon, Mar 15, 2010 at 1:41 AM, Pierre Joye 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.

Re: [PHP-DEV] Re: moving forward

2010-03-14 Thread Moriyoshi Koizumi
On Mon, Mar 15, 2010 at 6:25 AM, Herman Radtke 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 >> experi

Re: [PHP-DEV] Re: moving forward

2010-03-14 Thread Herman Radtke
> 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 neve

Re: [PHP-DEV] Where are we ACTUALLY on Unicode?

2010-03-14 Thread Alexey Zakhlestin
On 14.03.2010, at 17:43, dreamcat four wrote: > 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

Re: [PHP-DEV] Re: moving forward

2010-03-14 Thread Larry Garfield
On Monday 15 March 2010 12:56:07 am Herman Radtke wrote: > > 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 fea