[Pharo-dev] [Vm-dev] VMMaker in Pharo [Was: Squeak and Tonel]
David T. Lewis
lewis at mail.msen.com
Wed Feb 20 08:18:46 EST 2019
On Wed, Feb 20, 2019 at 09:23:55AM +0100, Tudor Girba wrote:
> 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?
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:
"If true use FileSystem, otherwise use traditional FileDirectory. See senders
for methods with file system dependencies."
^ Smalltalk hasClassNamed: #FileReference
"If true use FileMan for directory and file access. See senders for methods with file
^ 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.
* Personally I like the FileMan approach in Cuis best, but that is
another topic entirely ;-)
More information about the Pharo-dev