On Mon, Nov 08, 2010 at 12:31:35PM +0100, Bert Freudenberg wrote:
On 08.11.2010, at 04:55, David T. Lewis wrote:
On Sun, Nov 07, 2010 at 07:29:56PM -0800, Andreas Raab wrote:
On 11/7/2010 12:27 PM, David T. Lewis wrote:
The above is just my $.02 to get the discussion started. What do others think?
I don't really have any skin in the game since this is a Unix specific issue (i.e., the "squeakvm" dependency) that doesn't really apply on Mac or Windows. That said, I'll add my $.02 by saying that in our Linux production systems we do exactly what you were proposing, i.e., we have fallback VMs installed side-by-side with the latest and symlink the desired VM. That makes it very easy to switch the default *and* allows you to be explicit where you want to (i.e., by executing from the linked-to location).
Well that is Bert's suggestion exactly, and it is consistent with John's point of view as well, so it sounds like this is the right thing to do.
Dave
So we would ship two VMs. One is the old interpreter. The other is cog, or the stack interpreter, depending on the machine's architecture.
The two new ones should be in one source archive, IMHO.
Yes it should be exactly as you say, but I think we should be cautious about setting expectations. It may take a while to get this accomplished, and in the December time frame the important thing is to deliver solid working Cog and interpreter VMs. If we can merge all the code bases etc that is great, but let's not make it a precondition for the December VM and Squeak 4.2 release cycle. We have all seen what happens when a release team gets caught up in unrealistic development objectives, so let's not go there ;)
At build time either cog or stack VM would be selected depending on the machine's architecture. What should the name be for those binaries? Just use "squeakvm-cog" even if it's the Stack VM because it can run the same images?
Someone recently submitted a magic file with good names (Subbu? I can't find the link). I think the names were squeak-cog, squeak-stack, squeak-interp or somthing similar. In any case, "interp" can refer to the traditional interpreter, "stack" can refer to the portable stack interpreter positioned as a replacement for "interp", and "cog" can refer to the high performance VM.
Would we drop development on the old interpreter? If plugins were compatible between it and the newer VMs (are they?) it should not be much effort to keep it alive.
It's no real trouble to keep it alive and I intend to do so.
The plugins should definitely be identical. The C code generator should also be the same (I'm currently fumbling my ameteurish way through adoption of Eliot's enhancements into VMMaker trunk, but it's obvious that the end result should be the same). Hopefully we will get the old interpreter merged with Eliot's version (more work than I might have expected) but even if we can't do that short term, maintaining the old interpreter is easy and I'm quite happy to continue doing so as needed. Likewise for VMMakerTool, some folks may not need to use it but it is little or no work to maintain it, and I use it myself on a regular basis so keeping it alive is no problem.
What about 64 bit images? We don't need extra sources for those VMs, since it's just a build flag. But we need a naming scheme for these too.
This is something that is only in the trunk VMMaker. I am assuming that it would be good to merge this with the Cog VMMaker, although it is a fair amount of work with no direct benefit to the Cog VM so I should defer to Eliot on this. The changes are straightforward, but a lot of code gets touched and this is an example of something that may take some time and effort to merge.
Dave