[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] 5afa7a: Fix travis tests for squeak after app rename

Eliot Miranda eliot.miranda at gmail.com
Mon Jun 19 18:35:03 UTC 2017


Hi Ben,


> On Jun 19, 2017, at 9:01 AM, Ben Coman <btc at openinworld.com> wrote:
> 
> 
> 
>> On Fri, Jun 16, 2017 at 2:05 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> 
>> So please, let's make sure that the VM continues to function unchanged for existing images.
> 
> Is it too gratuitous to bump the image version to define existing images?
> Or not practical anyway?

IMO this is something that one does only on a major release such as the Squeak 4.x to 5.0 and Pharo 5 to Pharo 6 V3 to Spur transition.  The VM should strive to be backward compatible, whereas images are forwards compatible.  This allows the VM to be upgraded to fix bugs & add new functionality.  And this policy is achievable in practice.  IME, both VisualWorks' HPS and Cog and the Squeak interpreter VM (& I'm sure other Smalltalk VMs) have always provided this approach.


I don't see the providing of a setting to enable high dpi as a good reason for changing the VM version mid-stream, with all the inconvenience for users that this implies:

For users, they have to maintain two VMs and the ability to launch them plus being able to tell which is which; easier for users of Pharo launcher, but not something to be complicated unnecessarily.

For VM maintainers dropping backwards compatibility implies adding another VM to maintain and back port fixes to.  It's already costly to maintain the V3/Spur VMs (e.g. adding the allocated bytes accounting for Spur requires a guard clause to avoid impacting the V3 vm).  So we have to keep the matrix to a minimum.

I'm happy to expand the matrix for experiments that look like offering my a large future payoff such as Sista and Lowcode (& indeed Spur) and to continue to support older versions for as long as we as a community think make sense.  But we should avoid doing this wherever possible.  Resources dictate.

> cheers -ben 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170619/42e764ed/attachment.html>


More information about the Vm-dev mailing list