What is VOSS?
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 > Now I do not know the prices for business. > > Stef > > > Begin forwarded message: > > From: "John Clapperton" < > jc@ > > > Subject: VOSS Porting Tips 001 > Date: 24 Feb 2015 11:30:37 GMT+1 > To: 'Stéphane Ducasse' < > stephane.ducasse@ > > > > 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 -- View this message in context: http://forum.world.st/Porting-Voss-to-Pharo-tp4810019p4810088.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
