On Wed, Mar 29, 2017 at 12:05:58PM +0200, Esteban Lorenzano wrote: > we moved the paradigm a couple of years ago: each Pharo version comes with > his own VM version (Other smalltalks do that too).
Ah, I didn't know that; that clarifies the situation to me, so I will not shut up about incompatibility. :) > Being infinite backward compatible is a lot of pain :) Yes, I certainly understand the value in that. > > 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). > Maybe a suggestion... could we have a PharoVM facade that would delegate to the appropriate VM? (And ideally a all-vms.zip), because Pharo Launcher is not the only way Pharo is launched, so having to always think about which pharo to launch is bit annoying; e.g. on linux I use a shell script, but a canonical solution would be nice. Peter > 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 <i.uh...@gmail.com> 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) > >>> > >> > >> > > > >
