|Anonymous | Login||08-09-2020 00:04 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Advanced Details [ Jump to Notes ]||[ View Simple ] [ Issue History ] [ Print ]|
|ID||Category||Severity||Reproducibility||Date Submitted||Last Update|
|0001028||[Squeak] Multilingual||crash||always||04-01-05 04:08||07-15-06 12:17|
|ETA||none||Fixed in Version||3.9||Product Version||3.8|
|Summary||0001028: m17n: attempting to read a jpeg fails because a MultiByteFileStream is not the thing to use|
In a 3.8-6599 image, open a file list and select a jpeg (probably same issue with any iamge format we support) and then try to open it as an image. Boom.
I'm not at all sure why a MultiByteFileStream would be used to open an image file - or indeed any other binary format files - since they are bytes not characters and certainly not unicode characters.
The problem also suggests the class has some problems since the code where it fails is a typical [self atEnd] whileFalse:[ self next .......] loop and 'self next' is nil. The #atEnd is intended to guarantee that the next is NOT nil. Bad class, naughty class, no biscuit.
Temporarily 'fixing' #concreteStream to return the old answer makes image loading work as before.
|Steps To Reproduce|
|Attached Files||38loadJPEGDebug.log [^] (3,115 bytes) 04-01-05 21:28|
(0001331 - 657 - 723 - 723 - 723 - 723 - 723)
I cannot reproduce the problem in 3.8 gamma 6599. I can create SketchMorphs from the jpeg files on my computer by using the vanilla file list.
There are even more than one send of #binary in the path, so the stream shouldn't do any conversion and treats the bytes as uninterpreted bytes.
And, in the general principle is that we should move toward the direction to remove StandardFileStream and CrLfFileStream. All file IO should be done in one class and it is probably going to be MultiByteFileStream.
In regards to [self atEnd] whileFalse: [...] pattern, you are right. Testing with nil is more sensible thing to do. Which method is it?
(0001332 - 255 - 255 - 255 - 255 - 255 - 255)
|I'm sort of amazed that so many people are trying to fix the problem by reverting #concreteStream. In my view, it was so obvious that we would like to remove the other file stream classes eventually, but it must not be the case at all for other people...|
(0001335 - 682 - 706 - 706 - 706 - 706 - 706)
On both RISC OS and OSX, open a filelist, select a jpeg and use the 'open' button. Debug log attached.
I wasn't trying to solve the problem by demanding a return to StandardFileStream as such, merely pointing out that we can be sure something is not quite right with MBFS since SFS doesn't fail on this operation. I would prefer to see a radical cleanup of the file stuff anyway but that is an issue for another day.
There's nothing wrong at all with the [self atEnd] whileFalse:[ self next .......] loop so long as the object actually obeys the rules. In this case it appears that MBFS will answer false to #atEnd and yet return nil from #next which is a serious violation
(0005934 - 31 - 31 - 31 - 31 - 31 - 31)
|loading a jpg works in 3.9#4044|
|04-01-05 04:08||tim||New Issue|
|04-01-05 04:09||tim||Status||new => assigned|
|04-01-05 04:09||tim||Assigned To||=> ohshima|
|04-01-05 05:00||ohshima||Note Added: 0001331|
|04-01-05 05:03||ohshima||Note Added: 0001332|
|04-01-05 05:03||ohshima||Status||assigned => acknowledged|
|04-01-05 05:03||ohshima||Description Updated|
|04-01-05 21:27||tim||Note Added: 0001335|
|04-01-05 21:28||tim||File Added: 38loadJPEGDebug.log|
|11-08-05 03:08||tim||Relationship added||related to 0002160|
|07-15-06 12:17||MarcusDenker||Status||acknowledged => closed|
|07-15-06 12:17||MarcusDenker||Note Added: 0005934|
|07-15-06 12:17||MarcusDenker||Resolution||open => fixed|
|07-15-06 12:17||MarcusDenker||Fixed in Version||=> 3.9|
| Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
60 total queries executed.|
40 unique queries executed.