Now I understand that people may not be motivated to port when
commercial costs are not clear and impact of the LGPL on
the system.
Stef
Le 6/3/15 16:16, stepharo a écrit :
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
