[Vm-dev] VM Automated builds update

[Igor Stasenko]

On 16 March 2011 09:44, Andrew Gaylard <ag at computer.org> wrote:
>
> On Wed, Mar 16, 2011 at 3:49 AM, David T. Lewis <lewis at mail.msen.com> wrote:
>>
>> On Tue, Mar 15, 2011 at 09:22:27PM +0100, Igor Stasenko wrote:
>>>
>>> On 15 March 2011 17:35, Levente Uzonyi <leves at elte.hu> wrote:
>>> >
>>> > On Tue, 15 Mar 2011, Igor Stasenko wrote:
>>> >
>>> >>
>>> >>>
>>> >>> The main functional differences between SqueakVM and StackVM are:
>>> >>> - StackVM requires 6505 images (maybe 6504, i'm not sure) while SqueakVM
>>> >>> can
>>> >>> execute 6502, 6504 and 6505 images.
>>> >>
>>> >> not a big deal. I think everyone aware that Cog using newer image
>>> >> version(s).
>>> >
>>> > Not a big deal, for you.
>>> >
>>> > Someone just mentioned, that they're using 3.10-4 VM on Solaris, so they
>>> > don't use newer image versions. We also have some Squeak 3.9 images deployed
>>> > and we're not planning to upgrade them yet. The latest Etoys and Cobalt
>>> > releases use the old image format.
>>> >
>>>
>>> Well, if people decided to stick with old images, it is their choice.
>>> And once they decide to migrate,
>>> then there is a way to do that. I see nothing complicated there.
>>>
>>> Either you stay with old MS-DOS, and run your application using DosBox , or
>>> you run it on x64 compiled using modern compiler. The choice is always yours :)
>>>
>>
>> For whatever it may be worth, I intend to continue supporting the traditional
>> interpreter VM to the best of my ability for the forseeable future. I also
>> intend to help as best I can to support Cog and hopefully to help merge
>> code bases and reduce redundancy where possible. Finally, I think that the
>> work Igor is doing for automated builds is very valuable.
>>
>> Let's be glad for the progress that is being made with new VMs and new
>> build processes, but please do not assume that this progress comes at
>> the expense of all that has come before. It just ain't so.
>
> Igor, sorry if my question triggered a mini-flamefest.  That wasn't my
> intention!  I was just wondering what the "general direction" of VM
> development currently is.  You answered it clearly.  Since we have an
> automated process that builds images from scratch, and since we
> never store what we can generate (sound familiar! :), it's not a big
> deal for us to migrate to a new format.
>

Right , that the idea. Different groups of people developing different things:

- VM
- kernel image
- 3rd party packages
- end-user applications

and in order to meet them all, all players in field should be mobile,
and all pieces of puzzle should be replaceable at any moment.
Then you can move forward and exploit the new features done by another party.

> Also, I'm really grateful for the work you've done to make builds
> repeatable and automated.  For years now, VM development has
> been plagued with "it works when *I* build it, so it must be fine"-type
> of issues.  Your efforts will go a long way to industrialise the VM
> development and bug-fixing process.
>
> Many thanks,
> - Andrew
>



-- 
Best regards,
Igor Stasenko AKA sig.