[Pharo-project] issue 2512 - PNG Tests failure
http://code.google.com/p/pharo/issues/detail?id=2512 the following tests fail: PNGReadWriterTest>>testPngEncodingColors32 PNGReadWriterTest>>testPngDecodingColors32 They were both green in Pharo 1.0. Also the current implementation of PNGReadWriterTest class has been file in into the last Squeak trunk image and they are green. So the last modifications on the the PNG package cause those methods fail. Cheers, Fabrizio
Hmmm, weren't these the tests that failed in 1.0 if you ran all the tests in one go? I know they were in the neighbourhood anyway, since I spent some time trying to chase them down, and recognise those method names from then. Maybe Torsten knows a bit more about them, since he was the one that put me on the trail... -- Cheers, Peter 2010/6/5 Fabrizio Perin <fabrizio.perin@gmail.com>
http://code.google.com/p/pharo/issues/detail?id=2512
the following tests fail:
PNGReadWriterTest>>testPngEncodingColors32 PNGReadWriterTest>>testPngDecodingColors32
They were both green in Pharo 1.0. Also the current implementation of PNGReadWriterTest class has been file in into the last Squeak trunk image and they are green. So the last modifications on the the PNG package cause those methods fail.
Cheers,
Fabrizio
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
No, we have other tests that fail only when running all tests -- those that test finalization. The PNG tests fail reliably in 1.1. Unfortunately we were unable to narrow down the cause. There appears to be an off by one error somewhere in encoding (or decoding) the Color black. - on On Jun 5, 2010, at 18:39, Peter Hugosson-Miller wrote:
Hmmm, weren't these the tests that failed in 1.0 if you ran all the tests in one go? I know they were in the neighbourhood anyway, since I spent some time trying to chase them down, and recognise those method names from then.
Maybe Torsten knows a bit more about them, since he was the one that put me on the trail...
-- Cheers, Peter
2010/6/5 Fabrizio Perin <fabrizio.perin@gmail.com> http://code.google.com/p/pharo/issues/detail?id=2512
the following tests fail:
PNGReadWriterTest>>testPngEncodingColors32 PNGReadWriterTest>>testPngDecodingColors32
They were both green in Pharo 1.0. Also the current implementation of PNGReadWriterTest class has been file in into the last Squeak trunk image and they are green. So the last modifications on the the PNG package cause those methods fail.
Cheers,
Fabrizio
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 05.06.2010 20:10, Oscar Nierstrasz wrote:
No, we have other tests that fail only when running all tests -- those that test finalization.
The PNG tests fail reliably in 1.1. Unfortunately we were unable to narrow down the cause.
There appears to be an off by one error somewhere in encoding (or decoding) the Color black.
- on Related to: http://code.google.com/p/pharo/issues/detail?id=2486 perhaps? Essentially, 32 bit transparent black used to be 0(r) 0(g) (1)b (0)a instead of 0(r) 0(g) 0(b) 0(a). Which, was wrong. (And caused trouble when using transparent black as one of the colors in a bitblt operation)
Cheers, Henry
On 06.06.2010 03:18, Henrik Sperre Johansen wrote:
On 05.06.2010 20:10, Oscar Nierstrasz wrote:
No, we have other tests that fail only when running all tests -- those that test finalization.
The PNG tests fail reliably in 1.1. Unfortunately we were unable to narrow down the cause.
There appears to be an off by one error somewhere in encoding (or decoding) the Color black.
- on Related to: http://code.google.com/p/pharo/issues/detail?id=2486 perhaps? Essentially, 32 bit transparent black used to be 0(r) 0(g) (1)b (0)a instead of 0(r) 0(g) 0(b) 0(a). Which, was wrong. (And caused trouble when using transparent black as one of the colors in a bitblt operation)
Cheers, Henry or (1)a 0(r) 0(g) (0)b instead of 0(a) 0(r) 0(g) 0(b) / (0)a 0(r) 0(g) (1)b instead of 0(a) 0(r) 0(g) 0(b) Can't exactly remember the byte order. The important point is there used to be a special case where transparent black was given a 32bit pixel-value of 1 rather than 0.
Cheers, Henry
do you have an idea how to fix that? On Jun 6, 2010, at 3:36 AM, Henrik Sperre Johansen wrote:
On 06.06.2010 03:18, Henrik Sperre Johansen wrote:
On 05.06.2010 20:10, Oscar Nierstrasz wrote:
No, we have other tests that fail only when running all tests -- those that test finalization.
The PNG tests fail reliably in 1.1. Unfortunately we were unable to narrow down the cause.
There appears to be an off by one error somewhere in encoding (or decoding) the Color black.
- on Related to: http://code.google.com/p/pharo/issues/detail?id=2486 perhaps? Essentially, 32 bit transparent black used to be 0(r) 0(g) (1)b (0)a instead of 0(r) 0(g) 0(b) 0(a). Which, was wrong. (And caused trouble when using transparent black as one of the colors in a bitblt operation)
Cheers, Henry or (1)a 0(r) 0(g) (0)b instead of 0(a) 0(r) 0(g) 0(b) / (0)a 0(r) 0(g) (1)b instead of 0(a) 0(r) 0(g) 0(b) Can't exactly remember the byte order. The important point is there used to be a special case where transparent black was given a 32bit pixel-value of 1 rather than 0.
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Recreate PNGReadWriterTest>>coloredFiles32, which was generated from the old pixel value of black. SLICE-Issue-2512-PNGTestsBasedOnFaultyBlack in Inbox. Cheers, Henry On 06.06.2010 20:04, Stéphane Ducasse wrote:
do you have an idea how to fix that?
On Jun 6, 2010, at 3:36 AM, Henrik Sperre Johansen wrote:
On 06.06.2010 03:18, Henrik Sperre Johansen wrote:
On 05.06.2010 20:10, Oscar Nierstrasz wrote:
No, we have other tests that fail only when running all tests -- those that test finalization.
The PNG tests fail reliably in 1.1. Unfortunately we were unable to narrow down the cause.
There appears to be an off by one error somewhere in encoding (or decoding) the Color black.
- on Related to: http://code.google.com/p/pharo/issues/detail?id=2486 perhaps? Essentially, 32 bit transparent black used to be 0(r) 0(g) (1)b (0)a instead of 0(r) 0(g) 0(b) 0(a). Which, was wrong. (And caused trouble when using transparent black as one of the colors in a bitblt operation)
Cheers, Henry or (1)a 0(r) 0(g) (0)b instead of 0(a) 0(r) 0(g) 0(b) / (0)a 0(r) 0(g) (1)b instead of 0(a) 0(r) 0(g) 0(b) Can't exactly remember the byte order. The important point is there used to be a special case where transparent black was given a 32bit pixel-value of 1 rather than 0.
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thanks henrik. in the next integration. Stef On Jun 6, 2010, at 10:42 PM, Henrik Sperre Johansen wrote:
Recreate PNGReadWriterTest>>coloredFiles32, which was generated from the old pixel value of black.
SLICE-Issue-2512-PNGTestsBasedOnFaultyBlack in Inbox.
Cheers, Henry
On 06.06.2010 20:04, Stéphane Ducasse wrote:
do you have an idea how to fix that?
On Jun 6, 2010, at 3:36 AM, Henrik Sperre Johansen wrote:
On 06.06.2010 03:18, Henrik Sperre Johansen wrote:
On 05.06.2010 20:10, Oscar Nierstrasz wrote:
No, we have other tests that fail only when running all tests -- those that test finalization.
The PNG tests fail reliably in 1.1. Unfortunately we were unable to narrow down the cause.
There appears to be an off by one error somewhere in encoding (or decoding) the Color black.
- on Related to: http://code.google.com/p/pharo/issues/detail?id=2486 perhaps? Essentially, 32 bit transparent black used to be 0(r) 0(g) (1)b (0)a instead of 0(r) 0(g) 0(b) 0(a). Which, was wrong. (And caused trouble when using transparent black as one of the colors in a bitblt operation)
Cheers, Henry or (1)a 0(r) 0(g) (0)b instead of 0(a) 0(r) 0(g) 0(b) / (0)a 0(r) 0(g) (1)b instead of 0(a) 0(r) 0(g) 0(b) Can't exactly remember the byte order. The important point is there used to be a special case where transparent black was given a 32bit pixel-value of 1 rather than 0.
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Fabrizio Perin -
Henrik Sperre Johansen -
Oscar Nierstrasz -
Peter Hugosson-Miller -
Stéphane Ducasse