Hi Chris,

On Nov 10, 2018, at 3:05 PM, Chris Muller asqueaker@gmail.com wrote:

Hi Eliot, sorry for my ignorance -- I'm trying to understand if we are headed for a compatibility glitch between older images and newer VM's, or between older VM's and newer images.

Only compatibility between older images and newer VMs matter. One should not expect to be able to run a new image on an older VM (since a new image may depend on a new feature absent in older VMs). One should expect to be able to run any (compatible) older image on a newer VM. I think there should be no compatibility glitch because by default the new VM maps mouse wheel events to ctrl+shift+option+meta+arrow key, which correctly scrolls and avoids confusion with ctrl-arrow.

The old 5.0-201807260206 VM works fine even without any image changes. Is it possible to do the fix it solely in the VM?

But the old vm doesn’t respond to horizontal wheel events right? Hence it dissent work just fine at all.

Best, Chris

...

On Fri, Nov 9, 2018 at 10:46 PM commits@source.squeak.org wrote:

Eliot Miranda uploaded a new version of System to project The Trunk: http://source.squeak.org/trunk/System-eem.1046.mcz

==================== Summary ====================

Name: System-eem.1046 Author: eem Time: 9 November 2018, 8:46:04.222224 pm UUID: 98d1a376-957e-40fd-ba0f-9e4893defad2 Ancestors: System-eem.1045

Add accessors for the sendMouseWheelEvents flag that instructs the VM to send mouse wheel events as mouse wheel events, not keynboard arrow keys. Needs an up-to-date VM (and on WIndows needs the VM code to be written).

Fix a typo

=============== Diff against System-eem.1045 ===============

Item was changed: ----- Method: SmalltalkImage>>processHasThreadIdInstVar: (in category 'system attributes') ----- processHasThreadIdInstVar: aBoolean "The threaded VM needs to know if the 4th inst var of Process is threadId which it uses to control process-to-thread binding. This flag persists across snapshots, stored in the image header."

•   aBoolean ifTrue: [self assert: (Process instVarNames at: 4) = 'threadId'].
  

•   aBoolean ifTrue: [self assert: (Process instVarNames at: 4) ='threadId'].
   self vmParameterAt: 48 put: ((self vmParameterAt: 48) bitClear: 1) + (aBoolean ifTrue: [1] ifFalse: [0])!
  
  

Item was added:

• ----- Method: SmalltalkImage>>sendMouseWheelEvents (in category 'system attributes') -----
• sendMouseWheelEvents

•   "The Cog VM can be instructed to deliver mouse wheel events as mouse wheel events.
  

•    By default mouse wheel events are mapped to arrow events.
  

•    This flag persists across snapshots, stored in the image header."
  

•   ^(self vmParameterAt: 48) anyMask: 32!
  
  

Item was added:

• ----- Method: SmalltalkImage>>sendMouseWheelEvents: (in category 'system attributes') -----
• sendMouseWheelEvents: aBoolean

•   "The Cog VM can be instructed to deliver mouse wheel events as mouse wheel events.
  

•    By default mouse wheel events are mapped to arrow events.
  

•    This flag persists across snapshots, stored in the image header."
  

•   self vmParameterAt: 48 put: ((self vmParameterAt: 48) bitClear: 32) + (aBoolean ifTrue: [32] ifFalse: [0])!
  
  
  

Hi Edgar,

On Nov 11, 2018, at 2:16 AM, Edgar J. De Cleene edgardec2005@gmail.com wrote:

Exist a way of open a old Stack or Cog .image with CogSpur64 ? This is a must as with Mohave the only working VM is CogSpur64 .

No. The routes are to - migrate your application to Spur 32-bit and then automatically convert the image to Spur 64-bit - migrate your application to Spur 64-bit

Since there is little difficulty migrating most code from V3 to Spur this should be straight-forward. Only a few things are not supported: - Spur refuses to support stable object enumeration via nextObject; one must use allObjects (& the image segment loading primitive effectively answers an array of the loaded objects), so no support for determining an object’s age - floats are no longer represented by Float, which is now an abstract class, so one must test via isFloat, not foo class == Float - Characters are immediate These are pretty minor incompatibilities and provide substantial performance benefits (Spur has a much more efficient GC, and supports a larger heap in 32-bits; Float arithmetic in 64-bits is usually faster and takes less space; WideString access is much faster)

What are your concerns? Are you worried that the code will not port? Is building an image from packages difficult? etc...

Edgar @morplenauta

...

On 11/11/2018, 05:20, "Eliot Miranda" eliot.miranda@gmail.com wrote:

One should expect to be able to run any (compatible) older image on a newer VM. I think there should be no compatibility glitch because by default the new VM maps mouse wheel events to ctrl+shift+option+meta+arrow key, which correctly scrolls and avoids confusion with ctrl-arrow.