On Wed, Mar 29, 2017 at 6:39 PM, Stan Krupoderov <pashel...@gmail.com> 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?
I would imagine.... it would be good for some engineering time to be allocated (if its feasible) to backport a small number of critical things like Athens fix to Pharo 5. We don't want to show we abandon it completely. Did it get a spring update? But resources are limited and Pharo 7 will have a completely new development process with git, which may need some priority care to iron out any issue arising out of its public use. > > 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? This would always be the same to move your code from a Pharo 5 image to a Pharo 6 image, unrelated to the VM. > > 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? Which specific issues? Do you have reproducible cases? > > On Wed, Mar 29, 2017 at 1:05 PM, Esteban Lorenzano <esteba...@gmail.com> > wrote: >> >> >> > On 29 Mar 2017, at 11:39, Peter Uhnak <i.uh...@gmail.com> 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, One thing I never quite get is this fluid alpha/beta/release status. So Pharo 6 is alpha now? and releases is two/three weeks? Thats a fairly narrow beta window ;) (but anyway I'm overall happy with the process & progress) >> >> >> >> 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... Not always feasible, but in reality you may get better support using the bleeding edge. Sure occasionally something blows up, but when that happens generally you can personally hang back a few builds. The bleeding edge is where most of the "Pharo" devs work, and if you can show a problem that affect where they are working, it is sometimes dealt with quite quickly. Now Pharo 5 I think may be a special case. The change to Spur and UFFI were *really*big* changes. So perhaps some problem remained to be ironed out. Pharo 6 has had another 12 months with Spur and UFFI. (but personally I don't remember major problems near Pharo 5 release) >> > >> > Also I was under the impression that newer VM should work with older >> > images, with the only exception being Cog/Spur change. I think this still remains Squeak policy. Pharo's policy is to push ahead more, and with limited resources that means we can't carry too much baggage. cheers -ben >> > 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 <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) >> >>> >> >> >> >> >> > >> >> > > > > -- > Regards, > Stanislav S. Krupoderov
