Porting Voss to Pharo

> On 06/03/15 16:16, stepharo wrote:
>> 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
>
> What does LGPL mean for VOSS? At FOSDEM I talked with Bradley Kuhn of
> the FSF. It is something that has been on their to do list for a while
> now. In the 'strict' interpretation it is as viral as GPL for smalltalk
> code.
>
> Stephan
>
>
>
>

> 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" <[hidden email]>
> Subject: VOSS Porting Tips 001
> Date: 24 Feb 2015 11:30:37 GMT+1
> To: 'Stéphane Ducasse' <[hidden email]>
>
> 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
>
>
>