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" <jc@logicarts.com> Subject: VOSS Porting Tips 001 Date: 24 Feb 2015 11:30:37 GMT+1 To: 'Stéphane Ducasse' <stephane.ducasse@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