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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Screenshot missing
Laurent Laffont 2010/2/7 Mariano Martinez Peck <[hidden email]> 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. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Thank you very much Laurent.
2010/2/7 laurent laffont <[hidden email]> Screenshot missing _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Picture 9.png (134K) Download Attachment |
Thank you very much Laurent.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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
2010/2/8 Henrik Sperre Johansen <[hidden email]>
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.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On 08.02.2010 09:21, Mariano Martinez Peck wrote:
Yes. 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Henrik Sperre Johansen
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 <[hidden email] >> <mailto:[hidden email]>> >> >> Screenshot missing >> >> Laurent Laffont >> >> >> 2010/2/7 Mariano Martinez Peck <[hidden email] >> <mailto:[hidden email]>> >> >> 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 > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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. > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |