> On 29 Mar 2017, at 12:39, Stan Krupoderov <[email protected]> wrote: > > Hi Esteban, > > > we moved the paradigm a couple of years ago: each Pharo version comes with > > his own VM version > Thanks for clarification. I see your point. Will it be always the same way or > it should be changed once VM and Pharo 6 are stabilized?
always like that, is the idea. > > How update scenario should be handled in this case on the user side? > Will it be File-out and File-in for all user changes? you save your project, then you load it… as always. 99% of things should work without any problem. > > And unfortunately this doesn't add clarity on why Pharo 5 is so unstable out > of the box and if > there any plans to fix existing issues in Pharo 5. Do you have any thoughts > on this matter? > Can we help with this? Pharo 5 is not unstable. There is however a problem with Athens and UFFI in Pharo5 that makes that part unstable. There was also a FT2 (important) problem but it was fixed. Anyway, this Athens problems are very hard to fix and we preview to fix that in Pharo 6, not in Pharo 5. Pharo 6 is two/three weeks of release, btw. Esteban > > On Wed, Mar 29, 2017 at 1:05 PM, Esteban Lorenzano <[email protected] > <mailto:[email protected]>> wrote: > > > On 29 Mar 2017, at 11:39, Peter Uhnak <[email protected] > > <mailto:[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] > >>> <mailto:[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) > >>> > >> > >> > > > > > > > > -- > Regards, > Stanislav S. Krupoderov
