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
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.
Excerpts from Bernardo Ezequiel Contreras's message of 2015-03-06 20:24:05 +0100:
that is interesting. where can i read more about the multi-user access? how are users defined? greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin Bähr working in china http://societyserver.org/mbaehr/
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
On Fri, Mar 06, 2015 at 11:07:44PM +0100, Stephan Eggermont wrote:
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.
A blast from the past, on Glorp's license: http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-June/078620.html Says Glorp is LGPL(S), under which the "code is intended to be usable as a library, without the intention to restrict the license of the program that uses it." The new Glorp site doesn't talk about license though. The Common Lisp world also has had an LLGPL for a very long time now. http://www.cliko.net/LLGPL Pierce
I think that the author of voss should reply. Stef Le 6/3/15 23:07, Stephan Eggermont a écrit :
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
On Sat, Mar 7, 2015 at 6:07 AM, Stephan Eggermont <stephan@stack.nl> wrote:
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
Actually just reading LGPL3 [1] , this seems less onerous for us than I remember. I think there are two concerns: 1. That distributing an Application with Pharo and VOSS together would somehow taint Pharo with the LGPL, but consider that if you simply load VOSS into Pharo, without any Application making use of VOSS then distributing that Image would seem to fall under Section 5 "Combined libraries", and be specifically excluded from the LGPL. 2. That the Application would be tainted by the LGPL. In our case where we don't have a shared library mechanism, Section 4.d.0 would seem to apply. So with your Application you would need to provide a mechanism you upgrade the VOSS library, plus instructions to do so per Section 4.e. This might be achieved by: a. Leaving the compiler in the distributed Image such that new versions of VOSS can be loaded via standard mechanisms - maybe just from the command line. b. Loading VOSS via Fuel over the top of the existing version in image. [1] https://www.gnu.org/licenses/lgpl.html cheers -ben
VOSS seems quite an interesting and useful technology. Is know for sure that it could be ported without disturbing Pharo opensourceness / freeness? Is anyone doing work to port it? On Sat, Mar 7, 2015 at 10:45 AM, Ben Coman <btc@openinworld.com> wrote:
On Sat, Mar 7, 2015 at 6:07 AM, Stephan Eggermont <stephan@stack.nl> wrote:
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
Actually just reading LGPL3 [1] , this seems less onerous for us than I remember. I think there are two concerns:
1. That distributing an Application with Pharo and VOSS together would somehow taint Pharo with the LGPL, but consider that if you simply load VOSS into Pharo, without any Application making use of VOSS then distributing that Image would seem to fall under Section 5 "Combined libraries", and be specifically excluded from the LGPL.
2. That the Application would be tainted by the LGPL. In our case where we don't have a shared library mechanism, Section 4.d.0 would seem to apply.
So with your Application you would need to provide a mechanism you upgrade the VOSS library, plus instructions to do so per Section 4.e. This might be achieved by: a. Leaving the compiler in the distributed Image such that new versions of VOSS can be loaded via standard mechanisms - maybe just from the command line. b. Loading VOSS via Fuel over the top of the existing version in image.
[1] https://www.gnu.org/licenses/lgpl.html
cheers -ben
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
participants (8)
-
Ben Coman -
Bernardo Ezequiel Contreras -
Laura Risani -
Martin Bähr -
Paul DeBruicker -
Pierce Ng -
Stephan Eggermont -
stepharo