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

Tobias Pape Das.Linux at gmx.de
Sat Jul 8 07:52:23 UTC 2017


Hi all
> On 19.06.2017, at 20:35, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> 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.

I also think this. 
But the necessity burdened upon us by the os'es to decide for or agains High-DPI at a point of program execution where typically not even the Interpreter has been started means that when we don't make a cut where vm and image both know that the high-dpi capa is there, we'll never have high-dpi vms since adoption won't happen. 

Best regards
	-Tobias


More information about the Vm-dev mailing list