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 les...@lsces.co.uk wrote:
Rafael Dohms wrote:
2010/3/11 Johannes Schlüterjohan...@php.net:
On the other hand merging tests to5.2 and 5.3 means 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
hi,
On Thu, Mar 11, 2010 at 6:22 PM, Rasmus Lerdorf ras...@lerdorf.com 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
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
On Fri, Mar 12, 2010 at 11:18, Jani Taskinen jani.taski...@iki.fi 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
On Fri, Mar 12, 2010 at 11:18 AM, Jani Taskinen jani.taski...@iki.fi 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
Hannes Magnusson wrote:
On Fri, Mar 12, 2010 at 11:18, Jani Taskinenjani.taski...@iki.fi 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
On 03/12/2010 12:29 PM, Hannes Magnusson wrote:
On Fri, Mar 12, 2010 at 11:18, Jani Taskinenjani.taski...@iki.fi 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..?
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
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
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
On Fri, Mar 12, 2010 at 2:04 AM, Pierre Joye pierre@gmail.com wrote:
hi,
On Thu, Mar 11, 2010 at 6:22 PM, Rasmus Lerdorf ras...@lerdorf.com 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
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
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, V.E.R for version stuff, since you have
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
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
On Fri, Mar 12, 2010 at 3:38 PM, Lukas Kahwe Smith m...@pooteeweet.org 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
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
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 pierre@gmail.com wrote:
On Fri, Mar 12, 2010 at 3:38 PM, Lukas
On Fri, Mar 12, 2010 at 9:35 AM, Lester Caine les...@lsces.co.uk 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
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
On Fri, Mar 12, 2010 at 5:12 PM, Christopher Jones
christopher.jo...@oracle.com 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 Fri, Mar 12, 2010 at 5:12 PM, Christopher Jones
christopher.jo...@oracle.com 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
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 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 regressions
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
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
On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi m...@mozo.jp 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
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
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
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
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
On Fri, 12 Mar 2010, Hannes Magnusson wrote:
On Fri, Mar 12, 2010 at 17:38, Moriyoshi Koizumi m...@mozo.jp 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
On Fri, Mar 12, 2010 at 19:29, Stanislav Malyshev s...@zend.com 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
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.
On Fri, Mar 12, 2010 at 7:14 PM, Jani Taskinen jani.taski...@iki.fi 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 :)
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
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 that
On Fri, Mar 12, 2010 at 19:46, Stanislav Malyshev s...@zend.com 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
On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin indey...@gmail.com 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
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 library?
On 12.03.2010, at 22:23, Pierre Joye wrote:
On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin indey...@gmail.com 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
On Fri, Mar 12, 2010 at 8:39 PM, Alexey Zakhlestin indey...@gmail.com wrote:
On 12.03.2010, at 22:23, Pierre Joye wrote:
On Fri, Mar 12, 2010 at 8:10 PM, Alexey Zakhlestin indey...@gmail.com
wrote:
On 12.03.2010, at 22:06, Pierre Joye wrote:
Many tests fail because they are written for a
On Fri, Mar 12, 2010 at 6:37 AM, Jani Taskinen jani.taski...@iki.fi wrote:
On 03/12/2010 12:29 PM, Hannes Magnusson wrote:
On Fri, Mar 12, 2010 at 11:18, Jani Taskinenjani.taski...@iki.fi
wrote:
Having tests in multiple branches is PITA. Hasn't anyone considered that
the
best way would
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
On Fri, Mar 12, 2010 at 4:55 PM, Stanislav Malyshev s...@zend.com 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) declare
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
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
On Fri, Mar 12, 2010 at 11:33 PM, Jani Taskinen jani.taski...@sci.fi 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
On Fri, Mar 12, 2010 at 5:39 PM, Pierre Joye pierre@gmail.com wrote:
On Fri, Mar 12, 2010 at 11:33 PM, Jani Taskinen jani.taski...@sci.fi
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
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
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
On Sat, Mar 13, 2010 at 12:04 AM, Eric Stewart ericleestew...@gmail.com 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
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
On Fri, Mar 12, 2010 at 6:27 PM, Stanislav Malyshev s...@zend.com 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
On Sat, Mar 13, 2010 at 12:27 AM, Stanislav Malyshev s...@zend.com 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
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 Fri, Mar 12, 2010 at 22:18, Eric Stewart ericleestew...@gmail.com wrote:
On Fri, Mar 12, 2010 at 6:37 AM, Jani Taskinen jani.taski...@iki.fi wrote:
On 03/12/2010 12:29 PM, Hannes Magnusson wrote:
On Fri, Mar 12, 2010 at 11:18, Jani Taskinenjani.taski...@iki.fi
wrote:
Having tests in
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
Hi,
On Sat, Mar 13, 2010 at 2:50 AM, Chris Trahey christra...@gmail.com 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
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
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
On Fri, Mar 12, 2010 at 9:52 PM, Pierre Joye pierre@gmail.com wrote
On Sat, Mar 13, 2010 at 12:27 AM, Stanislav Malyshev s...@zend.com 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:
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
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
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 arunas.ivanaus...@gmail.com
wrote:
Fixing bugs, developing the PHP runtime, can contribute ~10h/w
--
PHP Internals - PHP
66 matches
Mail list logo
