> On 29 Mar 2017, at 11:39, Peter Uhnak <[email protected]> wrote:
> 
> On Wed, Mar 29, 2017 at 11:05:28AM +0200, Esteban Lorenzano wrote:
>> well…
>> 
>> Latest VM is intended to work with latest Pharo, not with older versions. 
>> Latest VM is *always* an experimental/unstable VM that needs to be 
>> considered… that, experimental and unstable. Otherwise there would not be 
>> point on having the distinction between stable/latest, isn’t?
>> 
> 
>> So, no, Latest VM (which can also be known as “alpha vm”) has not broken FT, 
>> it works fine in Pharo 6.0, which can also be know as “Pharo 6.0 Alpha”). 
>> 
>> BTW… That’s why in zeroconf you cannot download a “latest vm for Pharo 5”. 
>> 
>> Of course, you can live at the edge, but that doesn’t means something is 
>> broken when something fails if premises are not fulfilled :) 
> 
> Well considering VM for Pharo 5 never worked for me properly, whether it was 
> crashing on BitBlt/Cairo, FT, or who knows what, I don't really have a choice 
> but to use the latest. If there is a better way then I am all ears, 
> constantly dealing with crashing VM when I need to get work done is extremely 
> frustrating...
> 
> Also I was under the impression that newer VM should work with older images, 
> with the only exception being Cog/Spur change. Or should I have six different 
> VMs and Pharo Launcher with six different VM configurations?

we moved the paradigm a couple of years ago: each Pharo version comes with his 
own VM version (Other smalltalks do that too). 
Being infinite backward compatible is a lot of pain :)

so yes, PharoLauncher needs to adapt to it… I added that requirement for 
PharoLauncher: you ship with latest stable but you can always download newers 
or olders (this is not yet implemented, is just a requirement I added… well, 
couple of years ago when we changed the way we wanted VMs to work). 

Esteban

> 
> Peter
> 
>> 
>> Said that… I had no problems with Latest VM + Pharo 6.0 (and they may 
>> happen, since this is all alfa :P)
>> 
>> I don’t know if “workarounding the VM” (by renaming libfreetype) will work, 
>> but if that works, ONCE we move latest vm to stable status we can consider 
>> backporting it to Pharo 5. 
>> 
>> Esteban
>> 
>>> On 29 Mar 2017, at 10:37, Peter Uhnak <[email protected]> wrote:
>>> 
>>> The new "fixed" compactor VM has broken FT...
>>> 
>>> So any text drawn on Athens canvas results in red cross...
>>> 
>>> Error in...
>>> 
>>> CairoFontFace class>>primFtFace:loadFlags:
>>> 
>>> 'Unable to find function address'
>>> 
>>> Apparently because someone renamed libfreetype-6.dll to libfreetype.dll
>>> 
>>> (Windows VM latest, Pharo 5)
>>> 
>> 
>> 
> 


Reply via email to