Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] 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
Reporter tim View Status public  
Assigned To ohshima
Priority high Resolution fixed  
Status closed   Product Version 3.8
Summary 0001028: m17n: attempting to read a jpeg fails because a MultiByteFileStream is not the thing to use
Description 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.
Additional Information
Attached Files  38loadJPEGDebug.log [^] (3,115 bytes) 04-01-05 21:28

- Relationships
related to 0002160closed ohshima File out a morph then trying to reload it fails because of a wrong file stream class 

- Notes
(0001331 - 657 - 723 - 723 - 723 - 723 - 723)
ohshima
04-01-05 05:00

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)
ohshima
04-01-05 05:03

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)
tim
04-01-05 21:27

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)
MarcusDenker
07-15-06 12:17

loading a jpg works in 3.9#4044
 

- Issue History
Date Modified Username Field Change
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.
Powered by Mantis Bugtracker