Hi guys
if some of you are interested to drive porting VOSS to Pharo, let me know
John sent me the code and I can give it to you.
There is a dual license
- LGPL
- commercial
Now I do not know the prices for business.
Stef
Begin forwarded message:
From: "John Clapperton" <j...@logicarts.com>
Subject: VOSS Porting Tips 001
Date: 24 Feb 2015 11:30:37 GMT+1
To: 'Stéphane Ducasse' <stephane.duca...@inria.fr>
Hi Stephane,
I strongly recommend first installing VOSS in VA Smalltalk and working
through the tutorial to get the feel of it; then single-step in the debugger
through the essential functionality to see how it works, in particular the
way messages sent to VORef proxies are forwarded to virtual objects
instantiated in the virtual space's VOCache after loading from disk.
The public face of a virtual space is an instance of VOManager, which knows
the file pathname etc, and which references an instance of VOStorageManager,
which is wrapped in a mutual exclusion VOSMShell, so that only one Smalltalk
process is allowed in at a time.
Inside the VOStorageManager is an instance of VOCache (subclass of
VOOrderedDictionary, subclass of Dictionary), which contains all the virtual
objects (in that virtual space) currently instantiated in the image.
VORef has three instance variables 'voManager id association '. Any message
sent to a VORef which is not understood by it (i.e. most of them, it's a
proxy) is forwarded to the VORef's VOManager, where it waits for exclusive
access to the VOStorageManager.
In there, it (the process) looks for that object's id in the VOCache (if not
there it's loaded from disk), the object's fixed length (21 bytes)
descriptor record in the sparse index file myspace.vot is locked (against
other images on other machines), and its VOCacheAssociation is locked into
the process's current VOTransaction (which contains a VOOrderedSet of
VORefs) against access by other processes in that image, and is assigned to
the VORef's 'association' instance variable.
The process then returns out of the VOStorageManager, out of the mutual
exclusion shell, and back in the context of the VOManager the instantiated
virtual object (referenced by the locked VOCacheAssociation's 'value'
instvar) is told to perform the message, and whatever that returns is
returned to the original sender (if it returns self, then the VORef is
returned to the sender).
I seem to have got rather deep rather quickly there; let me know which bits
you want to know about first.
Probably the most Pharo-specific part of the porting will be the new base
image Collection subclasses. The VOSS Btree collections
(VOLargeOrderedCollection and subclasses) are pretty well self-contained.
I realise this morning that you weren't asking whether there was a non-VA
implementation, you just meant is it available in chunk format, rather than
VA library (.dat) format - yes it's attached hereto. But nevertheless, I
strongly recommend having a working version to examine throughout the
porting.
The current version of VAST is 8.6.1, and VOSS 3.150.14 will object to that
when you try to run it, expecting VA 8.6. I've looked at the VA86 to VA861
migration notes, and as far as I can see it's only the version checking code
(in VODEVUUU module) which needs to be tweaked. I'll do that and upload to
voss.logicarts.com
Regards,
John
