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 <[hidden email]> 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 > > > |
In reply to this post by HilaireFernandes
> On 21 Apr 2018, at 10:34, Hilaire <[hidden email]> 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: |
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 <[hidden email]> 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 |
In reply to this post by HilaireFernandes
> On 22 Apr 2018, at 16:46, Hilaire <[hidden email]> 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 > > > |
In reply to this post by HilaireFernandes
> On 22 Apr 2018, at 16:55, Hilaire <[hidden email]> 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-to-need-only-pure-binary-streams 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 > > > |
In reply to this post by Sven Van Caekenberghe-2
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 <[hidden email]> wrote: That's a plan!
|
> On 24 Apr 2018, at 11:52, Guillermo Polito <[hidden email]> 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 <[hidden email]> 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 |
Free forum by Nabble | Edit this page |