On Wed, Feb 20, 2019 at 09:23:55AM +0100, Tudor Girba wrote:
Hi,
I have seen that code, and the issue I wanted to address is to have the decision about which dialect a piece of code is ran on in one single place. This should make it easier to find statically.
Indeed, this will not necessarily be guaranteed to work when moving from one version of Pharo to another. But, that problem can be addressed by tracing releases in a reproducible fashion. And in the VMMaker case, the scenario is about a development environment not a production system. So, it should be reasonable to point developers to a working configuration that pairs the Pharo/Squeak version and the VMMaker version.
What do you think?
Cheers, Doru
Hi Doru and Eliiot,
The approach that I have been using to address this in OSProcess is to put the compatibility methods in one place, in the 'compatibility' category in class OSProcess. This allows support for the different file system interfaces in Cuis, Pharo and Squeak.
For example, one of the compatibility methods is:
OSProcess class>>directoryExists: path "Answer true if a directory of the given name exists. The given name may be either a full path name or a local directory within this directory."
^ self useFileMan ifTrue: [((Smalltalk at: #DirectoryEntry) perform: #withPathName: with: path) exists] ifFalse: [self useFileSystem ifTrue: [ (path perform: #asFileReference) exists ] ifFalse: [ (Smalltalk at: #FileDirectory) default directoryExists: path ]]
And the tests for Cuis/Pharo/Squeak are in these two methods:
OSProcess class>>useFileSystem "If true use FileSystem, otherwise use traditional FileDirectory. See senders for methods with file system dependencies."
^ Smalltalk hasClassNamed: #FileReference
OSProcess class>>useFileMan "If true use FileMan for directory and file access. See senders for methods with file system dependencies."
^ Smalltalk hasClassNamed: #FileIOAccessor
This is ugly but it does work, and I been able to maintain OSProcess and CommandShell for the Squeak diaspora over a number of years in this manner. It also means that I do not need to worry if Squeak moves to FileMan(*) or FileSystem at some point in the future.
I don't think that VMMaker should have a hard dependency on OSProcess, but as a practical matter you probably have OSProcess loaded in the VM development image anyway, so you could try using these methods directly and see how ugly things get.
HTH, Dave
* Personally I like the FileMan approach in Cuis best, but that is another topic entirely ;-)