[Pharo-project] something in 1.1 broke ImageSegment
Hi folks. I was just running ImageSegment tests in 11196 and it is broken: 3 failing tests and 5 error. Most of them seems related to the same thing. I have a Syntax Error. Probaly it is due to some stuff integrated in the latests updates to 1.1. Then problem seems when writing the segment to disk and then when loading... I attach an screenshot. Does someone has an idea what can be the problem or how to fix it ? To reproduce, just run the tests ImageSegmentTest, ImageSegmentTestExport and ImageSegmentTestSwap Thanks!!! Mariano
Screenshot missing Laurent Laffont 2010/2/7 Mariano Martinez Peck <marianopeck@gmail.com>
Hi folks. I was just running ImageSegment tests in 11196 and it is broken: 3 failing tests and 5 error. Most of them seems related to the same thing.
I have a Syntax Error. Probaly it is due to some stuff integrated in the latests updates to 1.1. Then problem seems when writing the segment to disk and then when loading...
I attach an screenshot. Does someone has an idea what can be the problem or how to fix it ?
To reproduce, just run the tests ImageSegmentTest, ImageSegmentTestExport and ImageSegmentTestSwap
Thanks!!!
Mariano
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thank you very much Laurent. 2010/2/7 laurent laffont <laurent.laffont@gmail.com>
Screenshot missing
Laurent Laffont
2010/2/7 Mariano Martinez Peck <marianopeck@gmail.com>
Hi folks. I was just running ImageSegment tests in 11196 and it is broken: 3 failing tests and 5 error. Most of them seems related to the same thing.
I have a Syntax Error. Probaly it is due to some stuff integrated in the latests updates to 1.1. Then problem seems when writing the segment to disk and then when loading...
I attach an screenshot. Does someone has an idea what can be the problem or how to fix it ?
To reproduce, just run the tests ImageSegmentTest, ImageSegmentTestExport and ImageSegmentTestSwap
Thanks!!!
Mariano
_______________________________________________ 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 07.02.2010 23:11, Mariano Martinez Peck wrote:
Thank you very much Laurent.
2010/2/7 laurent laffont <laurent.laffont@gmail.com <mailto:laurent.laffont@gmail.com>>
Screenshot missing
Laurent Laffont
2010/2/7 Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>>
Hi folks. I was just running ImageSegment tests in 11196 and it is broken: 3 failing tests and 5 error. Most of them seems related to the same thing.
I have a Syntax Error. Probaly it is due to some stuff integrated in the latests updates to 1.1. Then problem seems when writing the segment to disk and then when loading...
I attach an screenshot. Does someone has an idea what can be the problem or how to fix it ?
To reproduce, just run the tests ImageSegmentTest, ImageSegmentTestExport and ImageSegmentTestSwap
Thanks!!!
Mariano
I believe its due to stream positioning when crossing buffer boundries in basicChunk, I have to debug a bit further for a solution though, sorry... Cheers, Henry
2010/2/8 Henrik Sperre Johansen <henrik.s.johansen@veloxit.no>
On 07.02.2010 23:11, Mariano Martinez Peck wrote:
Thank you very much Laurent.
2010/2/7 laurent laffont <laurent.laffont@gmail.com>
Screenshot missing
Laurent Laffont
2010/2/7 Mariano Martinez Peck <marianopeck@gmail.com>
Hi folks. I was just running ImageSegment tests in 11196 and it is broken: 3 failing tests and 5 error. Most of them seems related to the same thing.
I have a Syntax Error. Probaly it is due to some stuff integrated in the latests updates to 1.1. Then problem seems when writing the segment to disk and then when loading...
I attach an screenshot. Does someone has an idea what can be the problem or how to fix it ?
To reproduce, just run the tests ImageSegmentTest, ImageSegmentTestExport and ImageSegmentTestSwap
Thanks!!!
Mariano
I believe its due to stream positioning when crossing buffer boundries in basicChunk,
Hi Henrik! Are you talking about http://code.google.com/p/pharo/issues/detail?id=1880 ??
I have to debug a bit further for a solution though, sorry...
Don't problem. We have time :) If you have a solution please let me know. I really have no idea at all how to fix it.
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 08.02.2010 09:21, Mariano Martinez Peck wrote:
2010/2/8 Henrik Sperre Johansen <henrik.s.johansen@veloxit.no <mailto:henrik.s.johansen@veloxit.no>>
On 07.02.2010 23:11, Mariano Martinez Peck wrote:
Thank you very much Laurent.
2010/2/7 laurent laffont <laurent.laffont@gmail.com <mailto:laurent.laffont@gmail.com>>
Screenshot missing
Laurent Laffont
2010/2/7 Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>>
Hi folks. I was just running ImageSegment tests in 11196 and it is broken: 3 failing tests and 5 error. Most of them seems related to the same thing.
I have a Syntax Error. Probaly it is due to some stuff integrated in the latests updates to 1.1. Then problem seems when writing the segment to disk and then when loading...
I attach an screenshot. Does someone has an idea what can be the problem or how to fix it ?
To reproduce, just run the tests ImageSegmentTest, ImageSegmentTestExport and ImageSegmentTestSwap
Thanks!!!
Mariano
I believe its due to stream positioning when crossing buffer boundries in basicChunk,
Hi Henrik! Are you talking about http://code.google.com/p/pharo/issues/detail?id=1880 ??
Yes.
I have to debug a bit further for a solution though, sorry...
Don't problem. We have time :) If you have a solution please let me know. I really have no idea at all how to fix it.
A temporary fix is to revert by doing nil ifNil: [] instead of self basicChunk ifNil: [] in MultiByteFileStream >> nextChunk. Reading it in will be 2x as slow again though ;) Cheers, Henry
I have to debug a bit further for a solution though, sorry...
Don't problem. We have time :) If you have a solution please let me know. I really have no idea at all how to fix it.
A temporary fix is to revert by doing nil ifNil: [] instead of self basicChunk ifNil: [] in MultiByteFileStream >> nextChunk. Reading it in will be 2x as slow again though ;)
I wanted to run ImageSegment tests before commiting as I have been cleaning and organizing them a bit better. With this little workaround I can at least test them and see that I didn't break anything. I will commit my slice although they are not totally working because of this. For this problem I created the issue: http://code.google.com/p/pharo/issues/detail?id=1941 Thanks Mariano
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, 8 Feb 2010, Henrik Sperre Johansen wrote:
On 07.02.2010 23:11, Mariano Martinez Peck wrote:
Thank you very much Laurent.
2010/2/7 laurent laffont <laurent.laffont@gmail.com <mailto:laurent.laffont@gmail.com>>
Screenshot missing
Laurent Laffont
2010/2/7 Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>>
Hi folks. I was just running ImageSegment tests in 11196 and it is broken: 3 failing tests and 5 error. Most of them seems related to the same thing.
I have a Syntax Error. Probaly it is due to some stuff integrated in the latests updates to 1.1. Then problem seems when writing the segment to disk and then when loading...
I attach an screenshot. Does someone has an idea what can be the problem or how to fix it ?
To reproduce, just run the tests ImageSegmentTest, ImageSegmentTestExport and ImageSegmentTestSwap
Thanks!!!
Mariano
I believe its due to stream positioning when crossing buffer boundries in basicChunk, I have to debug a bit further for a solution though, sorry...
It seems to be an easy one, though I didn't try the fix, just reviewed the code. So the cause of the issue is in MultiByteFileStream >> #basicChunk, which doesn't care about readLimit. When readLimit is less than "collection size", the end of the returned chunk may be the end of a previous chunk. This method has at least two other flaws (These probably won't hurt anyone in the near future, though both can be avoided): 1. if read buffering is disabled it will raise an error 2. it assumes that the encoding of the stream is ascii compatible Levente
Cheers, Henry
Den 09.02.2010 06:14, skrev Levente Uzonyi:
On Mon, 8 Feb 2010, Henrik Sperre Johansen wrote:
I believe its due to stream positioning when crossing buffer boundries in basicChunk, I have to debug a bit further for a solution though, sorry...
It seems to be an easy one, though I didn't try the fix, just reviewed the code. So the cause of the issue is in MultiByteFileStream >> #basicChunk, which doesn't care about readLimit. When readLimit is less than "collection size", the end of the returned chunk may be the end of a previous chunk.
Thanks Levente, in my original-author-blindness, I couldn't see past that position was apparently set wrong compared to the original approach. When you say it like that, it's obvious :)
This method has at least two other flaws (These probably won't hurt anyone in the near future, though both can be avoided): 1. if read buffering is disabled it will raise an error
Yes, this should be fixed. I assume a collection ifNil: [^nil] is enough?
2. it assumes that the encoding of the stream is ascii compatible
Yes, that was a tradeoff. (Which I hoped was a clear implication from the method comment) Only Converter with this characteristic currently existing (afaict) is QuotedPrintable, I doubt that or another format will ever be used for storage of code. The method you wrote in Squeak doesn't have this limitiation, on the other hand that does little for encodings other than utf8 (which, of course, could be successfully argued to be the important case). This way, you also avoid a Stream creation/String copy in the common case, as well as not let encodings in addition to streams contain special logic to read in code chunks.
Levente
Cheers, Henry
On Tue, 9 Feb 2010, Henrik Johansen wrote:
Den 09.02.2010 06:14, skrev Levente Uzonyi:
On Mon, 8 Feb 2010, Henrik Sperre Johansen wrote:
I believe its due to stream positioning when crossing buffer boundries in basicChunk, I have to debug a bit further for a solution though, sorry...
It seems to be an easy one, though I didn't try the fix, just reviewed the code. So the cause of the issue is in MultiByteFileStream >> #basicChunk, which doesn't care about readLimit. When readLimit is less than "collection size", the end of the returned chunk may be the end of a previous chunk.
Thanks Levente, in my original-author-blindness, I couldn't see past that position was apparently set wrong compared to the original approach. When you say it like that, it's obvious :)
This method has at least two other flaws (These probably won't hurt anyone in the near future, though both can be avoided): 1. if read buffering is disabled it will raise an error
Yes, this should be fixed. I assume a collection ifNil: [^nil] is enough?
Yes.
2. it assumes that the encoding of the stream is ascii compatible
Yes, that was a tradeoff. (Which I hoped was a clear implication from the method comment) Only Converter with this characteristic currently existing (afaict) is QuotedPrintable, I doubt that or another format will ever be used for storage of code.
This method fails if the encoding is utf16 (which is unlikely), since ! is encoded as 00 21 (in hex) so !! will be 00 21 00 21. #basicChunk will recognize these as two chunk endings instead of an escaped chunk terminator.
The method you wrote in Squeak doesn't have this limitiation, on the other hand that does little for encodings other than utf8 (which, of course, could be successfully argued to be the important case).
Currently two encodings are used for fileIn/Out: utf8 and macroman, these are both ascii compatible. Macroman is only supported for reading, writing is always done as utf8. Other encodings' performance can be easily enhanced in Squeak if necessary (but that's very unlikely).
This way, you also avoid a Stream creation/String copy in the common
This could be added to Squeak, but I found that it doesn't make much (measureable) difference. Levente
case, as well as not let encodings in addition to streams contain special logic to read in code chunks.
Levente
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Henrik Johansen -
Henrik Sperre Johansen
-
laurent laffont -
Levente Uzonyi -
Mariano Martinez Peck