Hi, To use Smalltalk sketch scripts for additional unit tests, I need to file in these script files. I found FileStream>>fileIn: does the job. Is it the proper way to do it? Thanks Hilaire -- Dr. Geo http://drgeo.eu
I think so On Sat, Apr 21, 2018 at 10:34 AM, Hilaire <hilaire@drgeo.eu> wrote:
Hi,
To use Smalltalk sketch scripts for additional unit tests, I need to file in these script files.
I found FileStream>>fileIn: does the job. Is it the proper way to do it?
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
On 21 Apr 2018, at 10:34, Hilaire <hilaire@drgeo.eu> wrote:
Hi,
To use Smalltalk sketch scripts for additional unit tests, I need to file in these script files.
I found FileStream>>fileIn: does the job. Is it the proper way to do it?
The whole of FileStream is deprecated in P7, use [Abstract]FileReference>>#fileIn:
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
Not in my working P7 image. Is it a recent change? Hilaire Le 21/04/2018 à 13:01, Sven Van Caekenberghe a écrit :
The whole of FileStream is deprecated in P7, use [Abstract]FileReference>>#fileIn:
-- Dr. Geo http://drgeo.eu
On 21 Apr 2018, at 13:18, Hilaire <hilaire@drgeo.eu> wrote:
Not in my working P7 image. Is it a recent change?
Yes, relatively recent, weeks I guess, maybe a month, at least since half March. FileSystem (part of the image for ages), File and new streams (most also long part of the image) are the replacements. BTW, I meant [Abstract]FileReference>>#fileIn which is a unary selector.
Hilaire
Le 21/04/2018 à 13:01, Sven Van Caekenberghe a écrit :
The whole of FileStream is deprecated in P7, use [Abstract]FileReference>>#fileIn:
-- Dr. Geo http://drgeo.eu
A migration guide will be more than welcome, because the API, and likely the logic, is different. Thanks Hilaire Le 21/04/2018 à 13:37, Sven Van Caekenberghe a écrit :
Yes, relatively recent, weeks I guess, maybe a month, at least since half March.
FileSystem (part of the image for ages), File and new streams (most also long part of the image) are the replacements.
BTW, I meant [Abstract]FileReference>>#fileIn which is a unary selector.
-- Dr. Geo http://drgeo.eu
For example when rewritting this methods, to read afterward PNG image I have error: image format no recognized. getFile: aFilename "   ^ FileStream readOnlyFileNamed: (self fullname: aFilename)"    ^ (self fullname: aFilename) asFileReference binaryReadStream Le 22/04/2018 à 16:46, Hilaire a écrit :
A migration guide will be more than welcome, because the API, and likely the logic, is different.
Thanks
Hilaire
Le 21/04/2018 à 13:37, Sven Van Caekenberghe a écrit :
Yes, relatively recent, weeks I guess, maybe a month, at least since half March.
FileSystem (part of the image for ages), File and new streams (most also long part of the image) are the replacements.
BTW, I meant [Abstract]FileReference>>#fileIn which is a unary selector.
-- Dr. Geo http://drgeo.eu
On 22 Apr 2018, at 16:55, Hilaire <hilaire@drgeo.eu> wrote:
For example when rewritting this methods, to read afterward PNG image I have error: image format no recognized.
getFile: aFilename " ^ FileStream readOnlyFileNamed: (self fullname: aFilename)" ^ (self fullname: aFilename) asFileReference binaryReadStream
Yes that is an open issue that I have not yet committed to pharo7 dev https://pharo.manuscript.com/f/cases/21611/Adapt-ImageReadWriter-hierarchy-t... but I got it fixed in some image somewhere, it just needs cleanup and packaging.
Le 22/04/2018 à 16:46, Hilaire a écrit :
A migration guide will be more than welcome, because the API, and likely the logic, is different.
Thanks
Hilaire
Le 21/04/2018 à 13:37, Sven Van Caekenberghe a écrit :
Yes, relatively recent, weeks I guess, maybe a month, at least since half March.
FileSystem (part of the image for ages), File and new streams (most also long part of the image) are the replacements.
BTW, I meant [Abstract]FileReference>>#fileIn which is a unary selector.
-- Dr. Geo http://drgeo.eu
On 22 Apr 2018, at 16:46, Hilaire <hilaire@drgeo.eu> wrote:
A migration guide will be more than welcome, because the API, and likely the logic, is different.
It is not hard at all, just start from FileSystem (i.e. FileReference, FileLocator, etc, ..) and open your streams from there and you are good. I guess the FileSystem from the Deep into Pharo book is a good start.
From a user perspective, the changes are not that big. If something is not clear, you can always ask.
Thanks
Hilaire
Le 21/04/2018 à 13:37, Sven Van Caekenberghe a écrit :
Yes, relatively recent, weeks I guess, maybe a month, at least since half March.
FileSystem (part of the image for ages), File and new streams (most also long part of the image) are the replacements.
BTW, I meant [Abstract]FileReference>>#fileIn which is a unary selector.
-- Dr. Geo http://drgeo.eu
That's a plan! I realized from my code I was already using a mix of the new and old world. It will be nice to get rid of the antic one to reduce the confusion when manipulating file. Thanks Le 22/04/2018 à 20:12, Sven Van Caekenberghe a écrit :
It is not hard at all, just start from FileSystem (i.e. FileReference, FileLocator, etc, ..) and open your streams from there and you are good. I guess the FileSystem from the Deep into Pharo book is a good start.
From a user perspective, the changes are not that big. If something is not clear, you can always ask.
-- Dr. Geo http://drgeo.eu
Hi, I think the more proper API to use is CodeImporter evaluateFileNamed: '/path/to/my/file.st'. Check CodeImporter class side for more options (streams, strings...). CodeImporter is there for already 3/4 years I think. The idea is that filing in is not a file responsibility. Guille On Mon, Apr 23, 2018 at 10:35 PM, Hilaire <hilaire@drgeo.eu> wrote:
That's a plan!
I realized from my code I was already using a mix of the new and old world. It will be nice to get rid of the antic one to reduce the confusion when manipulating file.
Thanks
Le 22/04/2018 à 20:12, Sven Van Caekenberghe a écrit :
It is not hard at all, just start from FileSystem (i.e. FileReference, FileLocator, etc, ..) and open your streams from there and you are good. I guess the FileSystem from the Deep into Pharo book is a good start.
From a user perspective, the changes are not that big. If something is not clear, you can always ask.
-- Dr. Geo http://drgeo.eu
-- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
On 24 Apr 2018, at 11:52, Guillermo Polito <guillermopolito@gmail.com> wrote:
Hi,
I think the more proper API to use is
CodeImporter evaluateFileNamed: '/path/to/my/file.st'.
Check CodeImporter class side for more options (streams, strings...).
CodeImporter is there for already 3/4 years I think. The idea is that filing in is not a file responsibility.
Yeah, but then you should change it to no longer use the deprecated FileStream ;-) See CodeImporter class>>#fileNamed:
Guille
On Mon, Apr 23, 2018 at 10:35 PM, Hilaire <hilaire@drgeo.eu> wrote: That's a plan!
I realized from my code I was already using a mix of the new and old world. It will be nice to get rid of the antic one to reduce the confusion when manipulating file.
Thanks
Le 22/04/2018 à 20:12, Sven Van Caekenberghe a écrit : It is not hard at all, just start from FileSystem (i.e. FileReference, FileLocator, etc, ..) and open your streams from there and you are good. I guess the FileSystem from the Deep into Pharo book is a good start.
From a user perspective, the changes are not that big. If something is not clear, you can always ask.
-- Dr. Geo http://drgeo.eu
--
Guille Polito Research Engineer
Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr
Web: http://guillep.github.io Phone: +33 06 52 70 66 13
participants (4)
-
Guillermo Polito -
Hilaire -
Stephane Ducasse -
Sven Van Caekenberghe