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

[Tobias Pape]

> On 13.06.2017, at 16:06, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> 
> 
> 
>> On Jun 13, 2017, at 4:38 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
>> 
>> 
>> Any objections I merge this into Cog?
> 
> Provided the changes are optional so that the default behaviour is unchanged then no objections from me.

That's a stretch… So here's the thing:

- Opting in to highdpi ist typically necessary very early in a process startup
  (at least when you want to stay platform-independend)
- For our vm that means, the image cannot simply use a primitive to say, hey I'm high-dpi ready 
  in order to change that later.
- We _can_ typically control the behavior via vm-specific files (Info.plist/ .exe.manifest)
- So, to avoid surprises because the image may not yet react to highdpi or dpi changes, 
  the default vms should come with high-dpi off.
- but When we add the code soon-ish, we could switch-on by default for the next image format change that would
  nevertheless need a new vm. This would be *drummroll* sista.

So what I propose is:
- Trunk receives code updates to handle high-dpi changes very soon (i got stuff in the pipeline but not yet fully ready)
- Cog remains low-dpi (except people opt *in* the _vm_ via files)
- Sista becomes high-dpi-aware (except people opt *out* the _vm_ via files)

This would need only few changes to the code base.

Eliot, what's newspeak's stance on high-dpi?

Best regards
	-Tobias



> 
>> 
>> Adds High-dpi for windows and mac.
>> 
>> Best regards
>>   -Tobias
>> 
>> 
>>> On 13.06.2017, at 10:50, GitHub <noreply at github.com> wrote:
>>> 
>> […]
>>> Log Message:
>>> -----------
>>> Merge remote-tracking branch 'origin/Cog' into krono/highdpi-v2
>>> 
>>> * origin/Cog: (61 commits)
>>> CogVM source as per VMMaker.oscog-eem.2242
>>> CogVm source as per VMMaker.oscog-eem.2241
>>> CogVM source as per VMMaker.oscog-eem.2240
>>> CogVM source as per VMMaker.oscog-eem.2237
>>> Fix regression in recent system attribute 1002 (OS Version) change on Mac OS X. Answering e.g. 10.10.5 breaks everyting that uses Smalltalk osVerison asNumber. So answer e.g. 1010.5 insteads so that Smalltalk osVerison asNumber = 1010. Typical image code looks like Smalltalk osVerison asNumber >= 1000 to identify Mac OS X over MacOS 9 et al.
>>> cosmetic: fix weird alignment
>>> Fail primitiveFileOpenNew with PrimErrInappropriate if file already exists
>>> added a flag pointer parameter to sqFileOpenNew() for failure being caused by the file already existing
>>> Make recent FilePlugin changes MSVC compatible
>>> Fix plugin compilation for Win64 PharoVM
>>> Fix int */sqInt * mismatch for Win64 FilePlugin
>>> Regenerate Unix OS ProcessPlugin from oscog-dtl.56
>>> CogVM source as per VMMaker.oscog-eem.2232
>>> Use the NSProcessInfo API to get an accurate OS verison string on Mac OS X.
>>> CogVM source as per VMMaker.oscog-eem.2229
>>> CogVm source as per VMMaker.oscog-eem.2228
>>> Make pharo deploy work for both WIN64 stack and cog
>>> Build Win64 squeak.cog.spur FFI & Alien plugins
>>> Add Win64 pharo.cog.spur configuration
>>> Win32OSProcessPlugin MUST be regenerated from latest source
>>> ...
>>> 
>>> 
>>> Compare: https://github.com/OpenSmalltalk/opensmalltalk-vm/compare/4181d8e8872f...8044775ccbb1
>> 
>>