it seems fedora had never bison 1.x
http://koji.fedoraproject.org/koji/packageinfo?packageID=1084
Am 02.09.2011 01:23, schrieb Pierre Joye:
> It would be nice to get at least a little bit of the context before going in
> any kind of arguing.
>
> For one the failing test happening after my commit
And same on windows. There is even an automatic mode (cl adapts itself
automatically based on the number of available cores)
On Sep 1, 2011 9:20 PM, "Johannes Schlüter" wrote:
> On Thu, 2011-09-01 at 21:09 +0200, Sebastian Bergmann wrote:
>> Is this
>>
>> http://jlebar.com/2011/9/1/Building_faster
It would be nice to get at least a little bit of the context before going in
any kind of arguing.
For one the failing test happening after my commit was my mistake. It has
nothing to do with the bison versions but me having committed a wrong
expectf expression. However, the 1.x support was the rea
On Thu, Sep 1, 2011 at 10:54 PM, Hannes Magnusson
wrote:
> On Thu, Sep 1, 2011 at 20:58, Pierre Joye wrote:
>> Please show me one system relying on it? 13 years old...
>>
>
> Your own test box before Rasmus pointed it out to you when you where
> changing the tests.
>
> Forcing people to upgrade
On Thu, Sep 1, 2011 at 20:58, Pierre Joye wrote:
> Please show me one system relying on it? 13 years old...
>
Your own test box before Rasmus pointed it out to you when you where
changing the tests.
Forcing people to upgrade this kind of software between bugfix
releases doesn't give us anything
Hi:
On Tue, Aug 30, 2011 at 10:55:48PM -0700, Rasmus Lerdorf wrote:
>
> http://codepad.org/ZV8imUuc
I see Rasmus is only getting one mysqli failure. I'm getting several.
The diff, out and exp files can be found here:
http://www.analysisandsolutions.com/php/mysqli.test.failures.tbz
I didn't mod
$x = null;
get_class($x) returns get_class($this) as of 5.3.
I don't recall seeing a discussion of this on the list and
I can't find anything about this change in the archives.
The documentation is currently self-contradictory...
Under "Return Values":
Returns the name of the class of which objec
On Thu, 2011-09-01 at 21:09 +0200, Sebastian Bergmann wrote:
> Is this
>
>http://jlebar.com/2011/9/1/Building_faster_by_parallelizing_more.html
>
> relevant to us?
What about trying it out?
(but well, no our build system works differently, on a 64 way machine I
can easily compile 64 files
Is this
http://jlebar.com/2011/9/1/Building_faster_by_parallelizing_more.html
relevant to us?
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development
Please show me one system relying on it? 13 years old...
Even if the plan is to drop it in 5.4+ for now.
And yes the diff in the messages make testing harder as it should be. Other
would have noticed it already as many tests fail because of that.
On Sep 1, 2011 8:44 PM, "Hannes Magnusson"
wrote
Thats not something you do in a bugfix release.
Is different error messages really the only reason you want to drop 1.x?
Seems like a bad reason.
Why are we testing error messages from a 3rd party software anyway?
-Hannes
On Thu, Sep 1, 2011 at 19:14, Pierre Joye wrote:
> I will simply drop 1.4
On Thu, Sep 1, 2011 at 17:37, Felipe Pena wrote:
> 2011/9/1 Kalle Sommer Nielsen :
>> Hi
>>
>> 2011/9/1 Hannes Magnusson :
>>> Create a magical "run-me-first" file which run-tests will execute
>>> first, and if it fails it will skip all the tests in that directory..
>>> should be relatively easy t
I will simply drop 1.4 support by Monday if there is no opposition.
Cheers,
On Thu, Sep 1, 2011 at 11:22 AM, Pierre Joye wrote:
> Hi,
>
> It would help a lot to test the parser if we drop bison 1.x support.
> It won't change anything in the parser rules or in the code base but
> only the way we
2011/9/1 Kalle Sommer Nielsen :
> Hi
>
> 2011/9/1 Hannes Magnusson :
>> Create a magical "run-me-first" file which run-tests will execute
>> first, and if it fails it will skip all the tests in that directory..
>> should be relatively easy to implement.
>>
>> Being able to run the tests for two dir
Hi
2011/9/1 Hannes Magnusson :
> Create a magical "run-me-first" file which run-tests will execute
> first, and if it fails it will skip all the tests in that directory..
> should be relatively easy to implement.
>
> Being able to run the tests for two directories in parallel however..
> that woul
On Thu, 2011-09-01 at 16:17 +0200, Hannes Magnusson wrote:
> Create a magical "run-me-first" file which run-tests will execute
> first, and if it fails it will skip all the tests in that directory..
> should be relatively easy to implement.
See patch at
http://schlueters.de/~johannes/php/run-tests
2011/9/1 Hannes Magnusson :
> 2011/9/1 Johannes Schlüter :
>> On Thu, 2011-09-01 at 17:53 +0400, Alexey Shein wrote:
>>> Great addition.
>>> While you're at it, could you also add an option to print a list of
>>> skipped tests (maybe above XFAIL section), that's also currently can't
>>> be done wit
2011/9/1 Johannes Schlüter :
> On Thu, 2011-09-01 at 17:53 +0400, Alexey Shein wrote:
>> Great addition.
>> While you're at it, could you also add an option to print a list of
>> skipped tests (maybe above XFAIL section), that's also currently can't
>> be done with other options in run-tests.php.
>
On Thu, 2011-09-01 at 17:53 +0400, Alexey Shein wrote:
> Great addition.
> While you're at it, could you also add an option to print a list of
> skipped tests (maybe above XFAIL section), that's also currently can't
> be done with other options in run-tests.php.
> It could also be useful because so
On Thu, Sep 1, 2011 at 15:53, Alexey Shein wrote:
> 2011/9/1 Ferenc Kovacs :
>> On Thu, Sep 1, 2011 at 1:35 PM, Hannes Magnusson wrote:
>>> Throw qa and internals@ into the loop to.
>>>
>>> I'd also like to move the XFAIL section (printed out in the end) above
>>> the FAIL section.
>>> We have bu
Hi
Ok, it's committed
chregu
On 01.09.11 13:10, Rob Richards wrote:
> imo new behavior in 5.3
>
> Rob
>
> On Sep 1, 2011, at 1:35 AM, Christian Stocker
> wrote:
>
>> Hi
>>
>> It's about the two tests in
>>
>> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/simplexml/tests/008.php
2011/9/1 Ferenc Kovacs :
> On Thu, Sep 1, 2011 at 1:35 PM, Hannes Magnusson wrote:
>> Throw qa and internals@ into the loop to.
>>
>> I'd also like to move the XFAIL section (printed out in the end) above
>> the FAIL section.
>> We have bucketloads of xfailed tests, I actually have to scroll up to
On Thu, Sep 1, 2011 at 1:35 PM, Hannes Magnusson wrote:
> Throw qa and internals@ into the loop to.
>
> I'd also like to move the XFAIL section (printed out in the end) above
> the FAIL section.
> We have bucketloads of xfailed tests, I actually have to scroll up to
> see the failed tests which is
Hi,
On Thu, 2011-09-01 at 13:35 +0200, Hannes Magnusson wrote:
> Throw qa and internals@ into the loop to.
>
> I'd also like to move the XFAIL section (printed out in the end) above
> the FAIL section.
> We have bucketloads of xfailed tests, I actually have to scroll up to
> see the failed tests
Throw qa and internals@ into the loop to.
I'd also like to move the XFAIL section (printed out in the end) above
the FAIL section.
We have bucketloads of xfailed tests, I actually have to scroll up to
see the failed tests which is really annoying and silly.
Anyone have strong opinion on the print
imo new behavior in 5.3
Rob
On Sep 1, 2011, at 1:35 AM, Christian Stocker wrote:
> Hi
>
> It's about the two tests in
>
> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/simplexml/tests/008.phpt
> and
> http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/simplexml/tests/bug4
Hi,
It would help a lot to test the parser if we drop bison 1.x support.
It won't change anything in the parser rules or in the code base but
only the way we test it. Bison version 1.x has different messages than
2.x (formats and contents). It causes some tests to fail because of
these different m
Hi everyone,
I'm trying to help out cleaning up failing tests in my spare time and
I've noticed two related to the sessions ext:
http://qa.php.net/reports/viewreports.php?version=5.4.0beta1-dev&test=%2Fext%2Fsession%2Ftests%2Frfc1867_invalid_settings.phpt
http://qa.php.net/reports/viewreports.ph
hi,
That must be due to my changes. They were failing due to different
version of the parser tool (win and nux). Let me check them again with
another version.
On Thu, Sep 1, 2011 at 6:50 AM, Rasmus Lerdorf wrote:
> Pierre, your changes today caused 2 new test failures:
>
> Bug #51709 (Can't use
29 matches
Mail list logo
