On Nov 9, 2013, at 7:52 PM, Usman Bhatti <[email protected]> wrote:

> 
> 
> 
> On Sat, Nov 9, 2013 at 2:40 AM, Stéphane Ducasse <[email protected]> 
> wrote:
> Hi usman
> 
> I'm wondering if the change we did is good. 
> Too late right now to think. 
> 
> So far the change is not integrated so we can still think over it.
>  
> I'm wondering if this is important to know that we are deleting a non 
> existing file.
> 
> Yes

why?
Usman my question was if my change made sense. May be nobody care that when we 
are deleting a
file it should exist.

Else I understand your point. In any case open a bug entry.


Stef

> it is because now Pharo throws an exception if we do that. Try this in the 
> latest 3.0 image:
> Display writeJPEGfileNamed: 'display.jpeg' progressive: true
> 
> I proposed a solution by changing delete to ensureDelete but the change was 
> rejected because it is advised to backup the deleted file before replacing 
> it. However, the other image types are overwritten without any error 
> checking. For example ImageReadWrite:
> 
> putForm: aForm onFileNamed: fileName 
>       "Store the given form on a file of the given name."
>       | writer |
>       writer := self on: (FileStream newFileNamed: fileName) binary.
>       Cursor write showWhile: [ writer nextPutImage: aForm ].
>       writer close
> 
> So, we can retain the same policy for PluginBasedJPEGReadWriter.
> 
> usman
>  
> 
> Stef
> 
> > Hello,
> >
> > Due to the changes in Pharo 3.0, I cannot write jpeg files on the disk. 
> > This happens because when writing a jpeg file, we delete any precedent 
> > version of the file to be exported. However, now DiskStore>>delete: throws 
> > an exception when the file to be deleted is not present
> >
> > delete: path
> >       | pathString encodedPathString |
> >
> >       (self exists: path)
> >               ifFalse: [ ^ FileDoesNotExist signalWith: path ].
> >
> >       ...
> >
> > Hence, we need to fix PluginBasedJPEGReadWriter>>putForm: quality: 
> > progressiveJPEG: onFileNamed:  to not delete files not present.
> >
> > To reproduce the problem:
> > Display writeJPEGfileNamed: 'display.jpeg' progressive: true
> >
> > If confirmed, I'll open a bug report and propose a slice because correction 
> > is quite simple ;)
> >
> >
> > regards,
> > Usman
> 
> 
> 

Reply via email to