You contribute some patches first to internals and after that's been
done a few times we give out an SVN account.
Scott
On 12 Mar 2010, at 19:01, "Arunas Ivanauskas" > wrote:
Fixing bugs, developing the PHP runtime, can contribute ~10h/w
--
PHP Internals - PHP Runtime Development Mailing L
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 Mar 12, 2010, at 9:28 PM, Chris Trahey wrote:
> The old class is still there, think of it as if the inserted (overloading)
> class extends the base (overloaded) class and any classes the were extending
> the base now extend the inserted class. So as far as the runtime, it's
> run-of-the-meill in
On Fri, Mar 12, 2010 at 9:52 PM, Pierre Joye wrote
> On Sat, Mar 13, 2010 at 12:27 AM, Stanislav Malyshev wrote:
>> Hi!
>> It is possible, but that means instead of 2 trees of files you'd have these
>> trees distributed inside test files in a myriad of small if()s:
>> if(version == X) { test thi
Fixing bugs, developing the PHP runtime, can contribute ~10h/w
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
The old class is still there, think of it as if the inserted (overloading)
class extends the base (overloaded) class and any classes the were extending
the base now extend the inserted class. So as far as the runtime, it's
run-of-the-meill inheritance. Methods that are not re-implimented in the
ins
Hi,
On Sat, Mar 13, 2010 at 2:50 AM, 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 a
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 frameworks & libraries. In
fact, this idea came from my current
On Fri, Mar 12, 2010 at 22:18, Eric Stewart wrote:
> On Fri, Mar 12, 2010 at 6:37 AM, Jani Taskinen wrote:
>
>> On 03/12/2010 12:29 PM, Hannes Magnusson wrote:
>>
>>> On Fri, Mar 12, 2010 at 11:18, Jani Taskinen
>>> wrote:
>>>
Having tests in multiple branches is PITA. Hasn't anyone conside
On Fri, Mar 12, 2010 at 06:53:49PM -0500, Eric Stewart wrote:
>
> If I'm given the choice of those differences being in one file or in three
> different files (5.2, 5.3, 6.0)? I choose one file. Even if that files is
> more complex. It's still one file. One commit. One place to look for
> problems
On Sat, Mar 13, 2010 at 12:27 AM, Stanislav Malyshev wrote:
> Hi!
>
>> It is always possible to write a test for both versions (except
>> namespace). However it requires a radical change on how we test
>> things.
>> Instead of testing the output of given script, we will have to add
>> logics in a
On Fri, Mar 12, 2010 at 6:27 PM, Stanislav Malyshev wrote:
> Hi!
>
>
> It is always possible to write a test for both versions (except
>> namespace). However it requires a radical change on how we test
>> things.
>> Instead of testing the output of given script, we will have to add
>> logics in
Hi!
It is always possible to write a test for both versions (except
namespace). However it requires a radical change on how we test
things.
Instead of testing the output of given script, we will have to add
logics in a test, something similar to the classic xUnit frameworks.
For example, we will
On Sat, Mar 13, 2010 at 12:04 AM, Eric Stewart wrote:
> I think specific examples (ie: a link to a 5.2 test and the corresponding
> 5.3 test) which are currently impossible to merge would be most beneficial
> at this point.
>
> I'll search for some this evening. If anyone knows of one or two off
Hi!
I think specific examples (ie: a link to a 5.2 test and the corresponding
5.3 test) which are currently impossible to merge would be most beneficial
at this point.
Do a diff between two test dirs (you can use engine tests, php main
tests, etc.), get a list of different files and diff them
Hi!
What tests are you really talking about here? I thought we have
regression tests in there which test that stuff does not change between
Yes, we have those. But we also have other tests, which are different
between versions.
should not be any need for any updates given the tests aren't
On Fri, Mar 12, 2010 at 5:39 PM, Pierre Joye wrote:
> On Fri, Mar 12, 2010 at 11:33 PM, Jani Taskinen
> wrote:
> > 13.3.2010 0:18, Stanislav Malyshev wrote:
> >>
> >> Hi!
> >>
> >>> There are going to be some technical challenges. Some (maybe a lot) of
> >>> test
> >>> will need updates or rewri
On Fri, Mar 12, 2010 at 11:33 PM, Jani Taskinen wrote:
> 13.3.2010 0:18, Stanislav Malyshev wrote:
>>
>> Hi!
>>
>>> There are going to be some technical challenges. Some (maybe a lot) of
>>> test
>>> will need updates or rewriting. run-tests.php may need more improvements
>>> than what is already
13.3.2010 0:18, Stanislav Malyshev wrote:
Hi!
There are going to be some technical challenges. Some (maybe a lot) of
test
will need updates or rewriting. run-tests.php may need more improvements
than what is already planned. Knowing this, I would still rather update
run-tests.php and fix the te
Hi!
There are going to be some technical challenges. Some (maybe a lot) of test
will need updates or rewriting. run-tests.php may need more improvements
than what is already planned. Knowing this, I would still rather update
run-tests.php and fix the tests, then continue to applying tests to
dif
On Fri, Mar 12, 2010 at 4:55 PM, Stanislav Malyshev wrote:
> Hi!
>
>
> That's easy to say - but how exactly you're going to test
>>> functionality of, say. ext/intl without testing the underlying ICU
>>> library?
>>>
>>
>> Well, here's the way I see it:
>>
>> Extensions (including ext/intl) decl
Hi!
That's easy to say - but how exactly you're going to test
functionality of, say. ext/intl without testing the underlying ICU
library?
Well, here's the way I see it:
Extensions (including ext/intl) declare their API and tests are made
againt this API. No more and no less.
It's all sounds
On Fri, Mar 12, 2010 at 6:37 AM, Jani Taskinen wrote:
> On 03/12/2010 12:29 PM, Hannes Magnusson wrote:
>
>> 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
On Fri, Mar 12, 2010 at 8:39 PM, Alexey Zakhlestin wrote:
>
> On 12.03.2010, at 22:23, Pierre Joye wrote:
>
>> On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin
>> wrote:
>>>
>>> On 12.03.2010, at 22:06, Pierre Joye wrote:
>>>
Many tests fail because they are written for a given platform,
On 12.03.2010, at 22:23, Pierre Joye wrote:
> On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin wrote:
>>
>> On 12.03.2010, at 22:06, Pierre Joye wrote:
>>
>>> Many tests fail because they are written for a given platform, or even
>>> worst (from a portability point of view), only for a given
On 12.03.2010, at 22:20, Stanislav Malyshev wrote:
> Hi!
>
>> Well, these tests should just be removed/rewritten.
>> Php-tests should test php, not libraries
>
> That's easy to say - but how exactly you're going to test functionality of,
> say. ext/intl without testing the underlying ICU libra
On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin wrote:
>
> On 12.03.2010, at 22:06, Pierre Joye wrote:
>
>> Many tests fail because they are written for a given platform, or even
>> worst (from a portability point of view), only for a given
>> configuration (library version, system version,etc.
Hi!
Well, these tests should just be removed/rewritten.
Php-tests should test php, not libraries
That's easy to say - but how exactly you're going to test functionality
of, say. ext/intl without testing the underlying ICU library?
--
Stanislav Malyshev, Zend Software Architect
s...@zend.com
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
On 12.03.2010, at 22:06, Pierre Joye wrote:
> Many tests fail because they are written for a given platform, or even
> worst (from a portability point of view), only for a given
> configuration (library version, system version,etc.). And that's not
> about windows vs other, tests can work on a De
On Fri, Mar 12, 2010 at 7:14 PM, Jani Taskinen wrote:
> On 03/12/2010 08:08 PM, Stanislav Malyshev wrote:
>>
>> Hi!
>>
>>> 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 S
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!
That's why we'd need to add some section to select the minimum version
required to run the test.
How minimum version would help? If 5.2 requires one test, 5.3 another
and trunk another - you either have to have 3 tests or declare that only
thing you're testing is trunk (which is obviousl
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 03/12/2010 04:15 PM, Ulf Wendel wrote:
For a transition period there's likely to be more work and the number of
test failures is likely to go up. That is nothing to really worry about
as long as you manage to educate users that it is not a quality defect
of PHP as such but a temporary matter o
On 03/12/2010 08:08 PM, Stanislav Malyshev wrote:
Hi!
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
Yes, but: some tests are versi
Hi!
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
Yes, but: some tests are version-dependant, some are not. And since we
have this
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
where did that mail come from?
imho it should have been addressed to the mailing list directly.
I agree that he was short-tempered, but I think that the progress worth it.
Tyrael
On Fri, Mar 12, 2010 at 3:43 PM, Pierre Joye wrote:
> On Fri, Mar 12, 2010 at 3:38 PM, Lukas Kahwe Smith
> 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 helpful in moving the pr
On Fri, Mar 12, 2010 at 3:38 PM, Lukas Kahwe Smith wrote:
> imho jani's commit access should be revoked until we have sorted out our
> release plan for the future, because he has shown that he has no patience to
> respect other people's opinions and so we can alleviate him of doing stupid
> th
Jani Taskinen schrieb:
What you risk is that not each and every test is prepared for being run
with every version - although, maybe, in theory it should be. This is
It should not be theory for regression tests? If new release does not
pass the old tests but the old versions still do, then it's
On 03/12/2010 01:48 PM, Ulf Wendel wrote:
Jani Taskinen schrieb:
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 again
On 12.03.2010 12:37, Jani Taskinen wrote:
>> Some tests however are not supposed to work in earlier releases, so we
>> need to either add a new
>> ==SKIP-VERSION==
>> 5.2, 5.1, 5.0
>
> Perhaps something like required min version is better.
Imo you need both >V.E.R,
signature.asc
Description: Op
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
Jani Taskinen schrieb:
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
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 03/12/2010 12:29 PM, Hannes Magnusson wrote:
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 s
Hannes Magnusson wrote:
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 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
68 matches
Mail list logo
