[Vm-dev] VM Automated builds update

[Guillermo Polito]

On Wed, Mar 16, 2011 at 8:14 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> 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.
>

Sorry, I don't agree ;).  It's not easy to replace people, and I don't like
that idea, hehe.  I can't find an Igor Stasenko everyday everywhere!

Cheers,
Guille


> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110316/71a4c0b9/attachment.htm