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 m
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_time
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 wor
From Andrei Zmievski last year
"In PHP 6, everything by default will be Unicode," such as default string
types, said PHP core developer Andrei Zmievski during a keynote presentation at the 2009
Zend/PHP conference in San Jose, Calif. The PHP 6 platform also will feature the ability
to us
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:
This is a good use of the decorator pattern. Let's say you don't like the
way Zend_Form_Element filters form names. You can decorate it with a Your
own class which overrides this, and whenever you add a new element to your
form, decorate it with this class.
On Sat, Mar 13, 2010 at 10:10 AM, Richar
On 13 Mar 2010, at 22:55, Sebastian Bergmann wrote:
> Stefan Marr wrote:
>> Is that wise and well-considered or something the community might
>> regret in the long run?
>
> The books in question have not been written by community members
> (because those know better). I think there are so many
On Mar 13, 2010, at 1:56 PM, Lukas Kahwe Smith wrote:
>
> On 13.03.2010, at 22:52, Stefan Marr wrote:
>
>>
>> On 13 Mar 2010, at 22:43, Sebastian Bergmann wrote:
>>
>>> Rasmus Lerdorf wrote:
No, not ok. We will call the next release whatever we like. People who
have written books
Lukas Kahwe Smith wrote:
> Nobody needs to be punished
My choice of words was bad, sorry.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development Mailing
Hey Sebastian—
On 2010-03-13, at 4:55 PM, Sebastian Bergmann wrote:
> Stefan Marr wrote:
>> Is that wise and well-considered or something the community might
>> regret in the long run?
>
> The books in question have not been written by community members
> (because those know better). I think th
On 13.03.2010, at 22:52, Stefan Marr wrote:
>
> On 13 Mar 2010, at 22:43, Sebastian Bergmann wrote:
>
>> Rasmus Lerdorf wrote:
>>> 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
Stefan Marr wrote:
> Is that wise and well-considered or something the community might
> regret in the long run?
The books in question have not been written by community members
(because those know better). I think there are so many PHP 6 books on
the market because greedy publishers want to r
On 13 Mar 2010, at 22:43, Sebastian Bergmann wrote:
> Rasmus Lerdorf wrote:
>> 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
Rasmus Lerdorf wrote:
> 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.
hi,
On Sat, Mar 13, 2010 at 7:13 PM, Rasmus Lerdorf wrote:
>> - get rid of Jani's play branch
>
> I don't think Jani has messed up anything in that branch yet, so that
> could be the new trunk. It's just cloned from 5.3 exactly like you are
> proposing.
Not exactly, there are commits done in 5
On Sat, Mar 13, 2010 at 11:57 AM, Derick Rethans wrote:
> On Thu, 11 Mar 2010, Rasmus Lerdorf wrote:
>
> > So I think Lukas and others are right, let's move the PHP 6 trunk to a
> > branch since we are still going to need a bunch of code from it and
> > move development to trunk and start explori
On Sat, Mar 13, 2010 at 10:33:59AM -0800, Rasmus Lerdorf wrote:
> 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 fin
On 03/13/2010 08:55 AM, Keryx Web wrote:
> Hi again
>
> Trying to drive home this message I am starting a new thread.
>
> Mini-summary: The next *major* edition of PHP must be 7, not 6.
>
> Summary:
>
> A. There seem to be universal agreement that the up until last week
> branch of PHP called t
On Sat, Mar 13, 2010 at 11:57 AM, Derick Rethans wrote:
>
> 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 o
On 03/13/2010 08:57 AM, Derick Rethans wrote:
> On Thu, 11 Mar 2010, Rasmus Lerdorf wrote:
>
>> So I think Lukas and others are right, let's move the PHP 6 trunk to a
>> branch since we are still going to need a bunch of code from it and
>> move development to trunk and start exploring lighter a
On 13.03.2010, at 17:57, Derick Rethans wrote:
> 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 wi
It seems to me that you could transparently sub-class any framework's base
classes with an autoloader implementation... without needing to alter the code
that consumes them. You could also "inject" the code as part of your build &
test automation. Perhaps you could even make due with an AOP exte
On Sun, Mar 14, 2010 at 1:57 AM, Derick Rethans wrote:
> - 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 exten
Hi,
On Sat, 2010-03-13 at 11:57 -0500, Derick Rethans wrote:
> 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 (tra
On Sat, 13 Mar 2010, Moriyoshi Koizumi wrote:
> Huh? mbstring has been capable of handling lots of encodings other
> than UTF-8 since it was introduced.
I meant to say that mbstring does string manipulation functions, not
full unicode support.
Derick
--
http://derickrethans.nl | http://xdebug
On Thu, 11 Mar 2010, Rasmus Lerdorf wrote:
> So I think Lukas and others are right, let's move the PHP 6 trunk to a
> branch since we are still going to need a bunch of code from it and
> move development to trunk and start exploring lighter and more
> approachable ways to attack Unicode. We h
Hi again
Trying to drive home this message I am starting a new thread.
Mini-summary: The next *major* edition of PHP must be 7, not 6.
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 i
Arunas Ivanauskas wrote:
Fixing bugs, developing the PHP runtime, can contribute ~10h/w
Hi Arunas,
It would be great to have your help.
There is some information on getting started in
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/README.SUBMITTING_PATCH?view=markup
Chris
--
Email:
On Sat, Mar 13, 2010 at 4:41 PM, Moriyoshi Koizumi wrote:
> Surprisingly, It can be done quite easily with the current object
> handler infrastructure.
I don't think It is about how easy it can be done using only object
but about opening the pandora box while trying to figure out higher
prioritie
It looks like I stripped off too much. Attached is the right one.
Moriyoshi
On Sun, Mar 14, 2010 at 12:41 AM, Moriyoshi Koizumi wrote:
> Surprisingly, It can be done quite easily with the current object
> handler infrastructure.
>
> Moriyoshi
>
> On Sun, Mar 14, 2010 at 12:08 AM, Pierre Joye wr
Surprisingly, It can be done quite easily with the current object
handler infrastructure.
Moriyoshi
On Sun, Mar 14, 2010 at 12:08 AM, Pierre Joye wrote:
> On Sat, Mar 13, 2010 at 3:13 PM, Moriyoshi Koizumi wrote:
>
>> I don't totally agree with what is being said here, but I guess we
>> don't h
On 13 March 2010 01:50, Chris Trahey wrote:
> Perhaps a new concept in class-based OO programming, I'm not sure.
>
> Depending on your perspective you could call it ancestor overloading (or
> upstream overloading) or class underloading.
>
>
> We are increasingly developing with the aid of framewor
On Sat, Mar 13, 2010 at 3:13 PM, Moriyoshi Koizumi wrote:
> I don't totally agree with what is being said here, but I guess we
> don't have to make Unicode a first-class value. Once operator
> overloading is supported, Unicode strings can be represented as
> objects, like Python does although I
On Sat, Mar 13, 2010 at 6:07 PM, 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.
>
> Back to the days we don't have unicode, the number forma
On Sat, Mar 13, 2010 at 8:09 PM, Lester Caine wrote:
> Handling unicode CONTENT is not the problem here. People nowadays expect to
> be able to use their own language to write code, and create functions using
> words that they recognize. In databases, table and field names are now
> expected to su
On Sat, Mar 13, 2010 at 14:59, Keryx Web wrote:
> To all:
>
> I note that my question is still unanswered.
>
Ask again in a year. We simply do not know.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2010-03-12 18:36, Tomas Kuliavas skrev:
Keryx Web rašė:
2. If so, what will happen to array access in strings that are de
facto Unicode? Will the more clunky mb_substr() be the only option?
What will happen to array access in unicode strings, if code wants to
access them in bytes? Will some ba
On Sat, Mar 13, 2010 at 12:09 PM, Lester Caine wrote:
> It was my understanding that PHP6 was intended to provide international
> users with something that they could use in their own native language?
> Unicode titled files with unicode titled classes and functions.
Please get your facts straight
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.
That's a totally wrong statement. Please read Unicode spec
Chen Ze wrote:
On Sat, Mar 13, 2010 at 2:34 AM, Derick Rethans wrote:
On Fri, 12 Mar 2010, Hannes Magnusson wrote:
On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi wrote:
I'd love to see my brand-new mbstring implementation in the release.
Dropping mbstring completely won't be any good beca
On Sat, Mar 13, 2010 at 2:34 AM, Derick Rethans wrote:
> On Fri, 12 Mar 2010, Hannes Magnusson wrote:
>
>> On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi wrote:
>> > I'd love to see my brand-new mbstring implementation in the release.
>> > Dropping mbstring completely won't be any good because
41 matches
Mail list logo
