> So why not avoiding this by adding it as methods of the scalar variable
> instead, aka autoboxing.
> This would allow the new api to be closer to what people are used to from
> other languages, needs far less typing and IDE autocomplete of available
> functions pr type with "->".
I would also
On Feb 20, 2013, at 11:19 , Sebastian Krebs wrote:
> 2013/2/20 Klaus Ufo
>
>> Hi there !
>>
>> We all know that the current PHP API has flaws. Maybe we could use
>> namespaces to build a new coherent PHP API ? Like :
>>
>> - \arr
>> - \num
>> - \str
>>
>> and so on. Advantages :
>>
>> - no
On Wed, Feb 20, 2013 at 3:23 PM, Wim Godden wrote:
> I agree that in most cases, that's a good thing. But it's also how we ended
> up with a thing called the Y2k problem : stuff running forever.
>
> Disclaimer : I've been developing with PHP since 1997, so I'm very fond of
> the language. "If it
Michael Shadle wrote:
I'm aware people complain about PHP flaws, but having misc global core
functions for strings, arrays and other data types is a new one.
I am still a purest at heart and don't see the need for namespacing in general.
I am thinking it provides some lower level memory space
2013/2/20 Klaus Ufo
> Hi there !
>
> We all know that the current PHP API has flaws. Maybe we could use
> namespaces to build a new coherent PHP API ? Like :
>
> - \arr
> - \num
> - \str
>
> and so on. Advantages :
>
> - no more global functions
>
Just to throw that in: Even if you pack them int
Hello,
On Wed, Feb 20, 2013 at 9:22 AM, Klaus Ufo wrote:
> Hi there !
>
> We all know that the current PHP API has flaws. Maybe we could use namespaces
> to build a new coherent PHP API ? Like :
>
> - \arr
> - \num
> - \str
>
> and so on. Advantages :
>
> - no more global functions
I actually l
On 02/19/2013 11:22 PM, Klaus Ufo wrote:
> Hi there !
>
> We all know that the current PHP API has flaws. Maybe we could use namespaces
> to build a new coherent PHP API ? Like :
>
> - \arr
> - \num
> - \str
>
> and so on. Advantages :
>
> - no more global functions
> - separation of concerns
On 02/19/2013 11:22 PM, Klaus Ufo wrote:
Hi there !
We all know that the current PHP API has flaws. Maybe we could use namespaces
to build a new coherent PHP API ? Like :
- \arr
- \num
- \str
and so on. Advantages :
- no more global functions
- separation of concerns
- backward compatibili
Hi there !
We all know that the current PHP API has flaws. Maybe we could use namespaces
to build a new coherent PHP API ? Like :
- \arr
- \num
- \str
and so on. Advantages :
- no more global functions
- separation of concerns
- backward compatibility
- work can be done progressively
- easy to
ck Rethans
> >> Cc: PHP Developers Mailing List
> >> Subject: Re: [PHP-DEV] PHP 6
> >>
> >> We need to focus on Unicode more than what some says, whether this
> >> means descoping the Unicode release or not. However, this means that
> > the
> &g
t;> Cc: PHP Developers Mailing List
>>> Subject: Re: [PHP-DEV] PHP 6
>>>
>>> We need to focus on Unicode more than what some says, whether this
>>> means descoping the Unicode release or not. However, this means that
>> the
>>> development f
On 18.03.2010, at 06:55, Andi Gutmans wrote:
>> -Original Message-
>> From: Olivier Hill [mailto:olivier.h...@gmail.com]
>> Sent: Saturday, March 13, 2010 10:15 AM
>> To: Derick Rethans
>> Cc: PHP Developers Mailing List
>> Subject: Re: [PHP-DEV] PHP
Andi Gutmans wrote:
We need to focus on Unicode more than what some says, whether this
means descoping the Unicode release or not. However, this means that
the
development focus needs to be towards new features AND Unicode, not
having the new feature branch, and the siberia branch with Unicode
> -Original Message-
> From: Olivier Hill [mailto:olivier.h...@gmail.com]
> Sent: Saturday, March 13, 2010 10:15 AM
> To: Derick Rethans
> Cc: PHP Developers Mailing List
> Subject: Re: [PHP-DEV] PHP 6
>
> We need to focus on Unicode more than what some sa
On Wed, Mar 17, 2010 at 12:23 AM, Geoffrey Sneddon
wrote:
>
> On 12 Mar 2010, at 20:15, Philip Olson wrote:
>
>>
>> On Mar 12, 2010, at 10:46 AM, Stanislav Malyshev wrote:
>>
>>> Hi!
>>>
Yeah.
We tried it, and it simply didn't pan out (performance, bc, lost
interest, ..).
>>>
>>> I
On 12 Mar 2010, at 20:15, Philip Olson wrote:
On Mar 12, 2010, at 10:46 AM, Stanislav Malyshev wrote:
Hi!
Yeah.
We tried it, and it simply didn't pan out (performance, bc, lost
interest, ..).
I think it is a bit premature to declare the death of Unicode in
PHP. Yes, we know there are
On 2010-03-13, Lukas Kahwe Smith wrote:
> +1
>
> As for the exact features to merge, lets first start with formulating a plan
> about what we want to see in the next release. I also think it makes sense to
> base the number and scope if the features on a rough idea of when we want to
> see this
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.
>
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
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 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
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
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 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 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
Huh? mbstring has been capable of handling lots of encodings other
than UTF-8 since it was introduced.
We might often find it annoying that Unicode is handled transparently
through I/O functions when the internal encoding is different from the
outside encoding. It just seems you didn't ever make
On Fri, Mar 12, 2010 at 19:46, Stanislav Malyshev wrote:
> Hi!
>
>> Yeah.
>> We tried it, and it simply didn't pan out (performance, bc, lost interest,
>> ..).
>
> I think it is a bit premature to declare the death of Unicode in PHP. Yes,
> we know there are problems, and yes, it was harder that i
On Mar 12, 2010, at 10:46 AM, Stanislav Malyshev wrote:
> Hi!
>
>> Yeah.
>> We tried it, and it simply didn't pan out (performance, bc, lost interest,
>> ..).
>
> I think it is a bit premature to declare the death of Unicode in PHP. Yes, we
> know there are problems, and yes, it was harder th
Hi!
Yeah.
We tried it, and it simply didn't pan out (performance, bc, lost interest, ..).
I think it is a bit premature to declare the death of Unicode in PHP.
Yes, we know there are problems, and yes, it was harder that initially
thought, so we may want to take a step back and rethink it. A
On Fri, Mar 12, 2010 at 19:29, Stanislav Malyshev wrote:
> Hi!
>
>> Thats actually one of the ideas we had on IRC.
>> That mbstring patch and more ext/intl features should be enough to
>> solve "the unicode problem".
>
> That depends on your definition of "unicode problem". Original definition
> A
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 lots of
> > applications rely on it, but I don't really want t
Hi!
Thats actually one of the ideas we had on IRC.
That mbstring patch and more ext/intl features should be enough to
solve "the unicode problem".
That depends on your definition of "unicode problem". Original
definition AFAIK was that you shouldn't care about the encodings anymore
and all U
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 lots of
> applications rely on it, but I don't really want to maintain the funky
> library bundled with it.
Thats
Is that new implementation in trunk already? Is it (or will it be)
backwards compatible with the current one?
--Jani
On 03/12/2010 06:38 PM, 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 lot
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 backwards incompatible binary be the
only
On Mar 12, 2010, at 5:33 AM, Pierre Joye wrote:
>> Having tests in multiple branches is PITA. Hasn't anyone considered that the
>> best way would be to move all tests into their own repository
>> (directory..whatever :) in SVN..? Considering they are supposed to be used
>> for testing against regre
Christopher Jones wrote:
Lester Caine wrote:
Currently maintaining the 5.2 branch is essential until such time as
all extensions are available in official builds of PHP on windows!
Forcing projects to change their development platforms simply to
support a blinkered set of rules on PHP is not
On Fri, Mar 12, 2010 at 5:12 PM, Christopher Jones
wrote:
>
>
> Lester Caine wrote:
>
>> Currently maintaining the 5.2 branch is essential until such time as all
>> extensions are available in official builds of PHP on windows! Forcing
>> projects to change their development platforms simply to su
On Fri, Mar 12, 2010 at 5:12 PM, Christopher Jones
wrote:
> Nobody is arguing against maintaining 5.2 for the near-mid future.
> If you want Windows binaries, start building . . . .
You should replace the
"PECL extensions for Windows is being worked on. The interface on the
pecl website will mo
I'd love to see my brand-new mbstring implementation in the release.
Dropping mbstring completely won't be any good because lots of
applications rely on it, but I don't really want to maintain the funky
library bundled with it.
Moriyoshi
On Fri, Mar 12, 2010 at 2:22 AM, Rasmus Lerdorf wrote:
> A
On Fri, Mar 12, 2010 at 9:35 AM, Lester Caine wrote:
> Ferenc Kovacs wrote:
>>
>> if you mentioned windows builds, whats the current status of
>> http://pecl4win.php.net/ ?
>
> Also only available for PHP5.2 ;)
I mean when will be avaiable, the current situation sucks for the
developers who prefer
Lester Caine wrote:
Currently maintaining the 5.2 branch is essential until such time as all
extensions are available in official builds of PHP on windows! Forcing
projects to change their development platforms simply to support a
blinkered set of rules on PHP is not helpful in moving the pr
On 03/11/2010 11:41 PM, Christopher Jones wrote:
Ilia Alshanetsky wrote:
> +1. I think we need we need to make "HEAD" a common use branch where
> most of the developers trees are at and current HEAD iteration is just
> not it.
I'm +1. Jani's recent 5.3 changes should be reverted, PHP_5_4
rebr
On Fri, Mar 12, 2010 at 2:04 AM, Pierre Joye wrote:
> hi,
>
> On Thu, Mar 11, 2010 at 6:22 PM, Rasmus Lerdorf wrote:
>> Ah, Jani went a little crazy today in his typical style to force a
>> decision. The real decision is not whether to have a version 5.4 or
>> not
Jani is passionate, and that's
On 03/12/2010 01:40 PM, Keryx Web wrote:
If the next update is quite big and breaks backwards compatibility in
some ways, go directly to 7.
Yes, I hope others get over the version-fobia too. :)
We can't call the new (soon to be?) trunk PHP 6. Calling it 5.4 is not
working either considering th
2010-03-11 18:22, Rasmus Lerdorf skrev:
Ah, Jani went a little crazy today in his typical style to force a
decision. The real decision is not whether to have a version 5.4 or
not, it is all about solving the Unicode problem. The current effort
has obviously stalled. We need to figure out how t
On Fri, Mar 12, 2010 at 11:18 AM, Jani Taskinen wrote:
> Having tests in multiple branches is PITA. Hasn't anyone considered that the
> best way would be to move all tests into their own repository
> (directory..whatever :) in SVN..? Considering they are supposed to be used
> for testing against r
On Fri, Mar 12, 2010 at 11:18, Jani Taskinen wrote:
> Having tests in multiple branches is PITA. Hasn't anyone considered that the
> best way would be to move all tests into their own repository
> (directory..whatever :) in SVN..? Considering they are supposed to be used
> for testing against regr
Having tests in multiple branches is PITA. Hasn't anyone considered that
the best way would be to move all tests into their own repository
(directory..whatever :) in SVN..? Considering they are supposed to be
used for testing against regressions and BC breaks, they should always
be runnable usi
hi,
On Thu, Mar 11, 2010 at 6:22 PM, Rasmus Lerdorf wrote:
> Ah, Jani went a little crazy today in his typical style to force a
> decision. The real decision is not whether to have a version 5.4 or
> not
It is really annoying that no matter who says it, Jani keeps doing
whatever he wants. That'
Ferenc Kovacs wrote:
if you mentioned windows builds, whats the current status of
http://pecl4win.php.net/ ?
Also only available for PHP5.2 ;)
( If you must top post TRIM :( )
--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electr
if you mentioned windows builds, whats the current status of
http://pecl4win.php.net/ ?
Tyrael
On Fri, Mar 12, 2010 at 6:54 AM, Lester Caine wrote:
> Rafael Dohms wrote:
>>
>> 2010/3/11 Johannes Schlüter:
>>
>>>
>>> On the other hand merging tests to5.2 and 5.3 means that we can find new
>>> BC
Rafael Dohms wrote:
2010/3/11 Johannes Schlüter:
On the other hand merging tests to5.2 and 5.3 means that we can find new
BC breaks we had overseen and either fix them or document them properly.
So I won't "waste" too much time but not forget about 5.2.
As much as I agree with the push for
2010/3/11 Johannes Schlüter :
>
> On the other hand merging tests to5.2 and 5.3 means that we can find new
> BC breaks we had overseen and either fix them or document them properly.
>
> So I won't "waste" too much time but not forget about 5.2.
>
> johannes
>
>
As much as I agree with the push f
Ilia Alshanetsky wrote:
> Even though the 5.2 code base is fairly mature, it is far from being bug
> free. Unit tests are often a good way to identify corner cases that may
> not be handled properly even in the stable branches, so more tests IMHO
> is a good thing. Until the decision is made to
On Thu, 2010-03-11 at 17:44 -0500, Ilia Alshanetsky wrote:
> Even though the 5.2 code base is fairly mature, it is far from being bug
> free. Unit tests are often a good way to identify corner cases that may
> not be handled properly even in the stable branches, so more tests IMHO
> is a good thing
Stanislav Malyshev wrote:
> Hi!
>
>> I'd also like to see us start a slow deprioritization of 5.2 work.
>> Instead effort should go into making 5.3 the prefered stable branch.
>> One specific example is that Test Fest 2010 tests shouldn't be merged
>> to 5.2.
>
> I agree with you on 5.3 in gener
Even though the 5.2 code base is fairly mature, it is far from being bug
free. Unit tests are often a good way to identify corner cases that may
not be handled properly even in the stable branches, so more tests IMHO
is a good thing. Until the decision is made to discontinue the 5.2
branch, which s
Hi!
I'd also like to see us start a slow deprioritization of 5.2 work.
Instead effort should go into making 5.3 the prefered stable branch.
One specific example is that Test Fest 2010 tests shouldn't be merged
to 5.2.
I agree with you on 5.3 in general but I think having more tests in 5.2
wou
Eric Stewart wrote:
> Focusing TestFest on 5.3 was not how I had envisioned TestFest 2010, I was
> operating under the assumption we would be committing all applicable tests
> to 5.2, 5.3 and 6.0 as was done last year. Focusing strictly on 5.3
> certainly makes my job (and others working on Tes
On Thu, Mar 11, 2010 at 4:41 PM, Christopher Jones <
christopher.jo...@oracle.com> wrote:
>
>
> Ilia Alshanetsky wrote:
> > +1. I think we need we need to make "HEAD" a common use branch where
> > most of the developers trees are at and current HEAD iteration is just
> > not it.
>
> I'm +1. Jani'
On Thu, Mar 11, 2010 at 10:24 PM, Ilia Alshanetsky wrote:
> +1. I think we need we need to make "HEAD" a common use branch where
> most of the developers trees are at and current HEAD iteration is just
> not it.
That's my oppinion as well. Trunk should be a common development
branch. Once we deci
Ilia Alshanetsky wrote:
> +1. I think we need we need to make "HEAD" a common use branch where
> most of the developers trees are at and current HEAD iteration is just
> not it.
I'm +1. Jani's recent 5.3 changes should be reverted, PHP_5_4
rebranched again, and then the fixes/features merged t
+1. I think we need we need to make "HEAD" a common use branch where
most of the developers trees are at and current HEAD iteration is just
not it.
On 10-03-11 12:22 PM, Rasmus Lerdorf wrote:
> Ah, Jani went a little crazy today in his typical style to force a
> decision. The real decision is not
On 03/11/2010 12:20 PM, Jani Taskinen wrote:
> The main focus should be that we actually start working. And not wait
> for someone to do something miraculous on their own. I'm just sick and
> tired of the cloak and dagger style and secret meetings and committees.
> So please, do the talking openly
On 11.03.2010, at 21:20, Jani Taskinen wrote:
> The main focus should be that we actually start working. And not wait for
> someone to do something miraculous on their own. I'm just sick and tired of
> the cloak and dagger style and secret meetings and committees. So please, do
> the talking o
11.3.2010 19:54, Johannes Schlüter wrote:
On Thu, 2010-03-11 at 18:46 +0100, Lukas Kahwe Smith wrote:
+1 for moving trunk to a branch and moving 5.3 to trunk.
not moving 5.3 to trunk but a 5.3 copy (branched of), 5.3 should be
stable stuff (fixes) only. Guess you meant to say that, but better
11.3.2010 19:22, 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 have a few alre
On 11.03.2010, at 18:54, Johannes Schlüter wrote:
> On Thu, 2010-03-11 at 18:46 +0100, Lukas Kahwe Smith wrote:
>> +1 for moving trunk to a branch and moving 5.3 to trunk.
>
> not moving 5.3 to trunk but a 5.3 copy (branched of), 5.3 should be
> stable stuff (fixes) only. Guess you meant to say
On Thu, 2010-03-11 at 18:46 +0100, Lukas Kahwe Smith wrote:
> +1 for moving trunk to a branch and moving 5.3 to trunk.
not moving 5.3 to trunk but a 5.3 copy (branched of), 5.3 should be
stable stuff (fixes) only. Guess you meant to say that, but better to be
clear.
johannes
--
PHP Internals -
On 11.03.2010, at 18:22, Rasmus Lerdorf wrote:
> Ah, Jani went a little crazy today in his typical style to force a
> decision. The real decision is not whether to have a version 5.4 or
> not, it is all about solving the Unicode problem. The current effort
> has obviously stalled. We need to f
Ah, Jani went a little crazy today in his typical style to force a
decision. The real decision is not whether to have a version 5.4 or
not, it is all about solving the Unicode problem. The current effort
has obviously stalled. We need to figure out how to get development
back on track in a way t
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (110 total -- which includes 47 feature requests)
===[Apache related]===
47061 Open User not logged under Apache
===[
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (109 total -- which includes 47 feature requests)
===[Apache related]===
47061 Open User not logged under Apache
===[
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (108 total -- which includes 47 feature requests)
===[Apache related]===
47061 Open User not logged under Apache
===[
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (108 total -- which includes 47 feature requests)
===[Apache related]===
47061 Open User not logged under Apache
===[
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (109 total -- which includes 47 feature requests)
===[Apache related]===
47061 Open User not logged under Apache
===[
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (108 total -- which includes 47 feature requests)
===[Apache related]===
47061 Open User not logged under Apache
===[
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (107 total -- which includes 47 feature requests)
===[*General Issues]==
50189 Open [PATCH] - unicode byte order difference between SPARC and x86
===
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (108 total -- which includes 47 feature requests)
===[*General Issues]==
50189 Open [PATCH] - unicode byte order difference between SPARC and x86
===
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (107 total -- which includes 46 feature requests)
===[*General Issues]==
50189 Open [PATCH] - unicode byte order difference between SPARC and x86
===
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (106 total -- which includes 46 feature requests)
===[*General Issues]==
50189 Open [PATCH] - unicode byte order difference between SPARC and x86
===
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (107 total -- which includes 46 feature requests)
===[*General Issues]==
50189 Open [PATCH] - unicode byte order difference between SPARC and x86
===
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (108 total -- which includes 46 feature requests)
===[*General Issues]==
50189 Open [PATCH] - unicode byte order difference between SPARC and x86
===
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (107 total -- which includes 46 feature requests)
===[*General Issues]==
50189 Open [PATCH] - unicode byte order difference between SPARC and x86
===
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (106 total -- which includes 45 feature requests)
===[*General Issues]==
50189 Open [PATCH] - unicode byte order difference between SPARC and x86
===
PHP 6 Bug Database summary - http://bugs.php.net/
Num Status Summary (108 total -- which includes 45 feature requests)
===[*General Issues]==
50189 Open [PATCH] - unicode byte order difference between SPARC and x86
===
1 - 100 of 314 matches
Mail list logo
