the new "fixed" compactor VM has FT broken...
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)
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 :) 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.uhnak@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)
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? 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.uhnak@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)
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@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⦠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 <i.uhnak@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)
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?
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? 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? On Wed, Mar 29, 2017 at 1:05 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@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⦠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 <i.uhnak@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
On 29 Mar 2017, at 12:39, Stan Krupoderov <pashelper@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?
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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@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⦠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 <i.uhnak@gmail.com <mailto:i.uhnak@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
On Wed, Mar 29, 2017 at 6:39 PM, Stan Krupoderov <pashelper@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 <estebanlm@gmail.com> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@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.uhnak@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
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.uhnak@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)
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job. That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point. Phil On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@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⦠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 <i.uhnak@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)
BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM. So, all this discussion is informative, but the mail that originates it can be reviewed :) Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@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⦠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 <i.uhnak@gmail.com <mailto:i.uhnak@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)
and I was seeing and changes to make Athens stable are easily backportable to Pharo 5.0 (is just two methods)⦠so I do not see why not doing it⦠of course, that will require a new stable vm for Pharo 5 Esteban
On 29 Mar 2017, at 15:03, Esteban Lorenzano <estebanlm@gmail.com> wrote:
BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM.
So, all this discussion is informative, but the mail that originates it can be reviewed :)
Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@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⦠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 <i.uhnak@gmail.com <mailto:i.uhnak@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)
I am using Pharo5 on a VM that indeed gives me nice FT fonts. No crash. Yay! Phil On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM.
So, all this discussion is informative, but the mail that originates it can be reviewed :)
Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@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⦠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 <i.uhnak@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)
On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM.
So, all this discussion is informative, but the mail that originates it can be reviewed :)
No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts... I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text v := RTView new. v add: (RTLabel new elementOn: '-_-'). v â Or running AthensSurfaceExamples class>>exampleDrawText In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this. Peter
Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@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⦠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 <i.uhnak@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)
Tx peter! I really really sorry for this state of affair. I would like to tell you that I thank you for all the feedback you sent. Please continue. I imagine what it is to get a system that blow up under your fingers. I'm always trying to work with the alpha version (because I attract bugs) I got some crashes playing with roassal - but I updated to the latest vm and trying. Can you sync with esteban so that he can access your setup? And yes we are burning esteban on this.... We should pay attention that our faery does not get too exhausted :). Stef On Fri, Mar 31, 2017 at 1:10 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM.
So, all this discussion is informative, but the mail that originates it can be reviewed :)
No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts...
I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text
v := RTView new. v add: (RTLabel new elementOn: '-_-'). v
â
Or running AthensSurfaceExamples class>>exampleDrawText
In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this.
Peter
Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@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⦠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 <i.uhnak@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)
Peter I took the latest mac VM and Moose 6.1 and I used your example then I played during 15 min with all the roassal examples and I cannot reproduce but I'm on mac. On Fri, Mar 31, 2017 at 2:23 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Tx peter! I really really sorry for this state of affair. I would like to tell you that I thank you for all the feedback you sent. Please continue. I imagine what it is to get a system that blow up under your fingers. I'm always trying to work with the alpha version (because I attract bugs) I got some crashes playing with roassal - but I updated to the latest vm and trying.
Can you sync with esteban so that he can access your setup? And yes we are burning esteban on this.... We should pay attention that our faery does not get too exhausted :).
Stef
On Fri, Mar 31, 2017 at 1:10 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM.
So, all this discussion is informative, but the mail that originates it can be reviewed :)
No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts...
I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text
v := RTView new. v add: (RTLabel new elementOn: '-_-'). v
â
Or running AthensSurfaceExamples class>>exampleDrawText
In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this.
Peter
Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com
wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@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⦠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 <i.uhnak@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)
Hi Peter, I think I fixed the problem, can you try latest vm? Esteban
On 31 Mar 2017, at 14:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Peter I took the latest mac VM and Moose 6.1 and I used your example then I played during 15 min with all the roassal examples and I cannot reproduce but I'm on mac.
On Fri, Mar 31, 2017 at 2:23 PM, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote: Tx peter! I really really sorry for this state of affair. I would like to tell you that I thank you for all the feedback you sent. Please continue. I imagine what it is to get a system that blow up under your fingers. I'm always trying to work with the alpha version (because I attract bugs) I got some crashes playing with roassal - but I updated to the latest vm and trying.
Can you sync with esteban so that he can access your setup? And yes we are burning esteban on this.... We should pay attention that our faery does not get too exhausted :).
Stef
On Fri, Mar 31, 2017 at 1:10 PM, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM.
So, all this discussion is informative, but the mail that originates it can be reviewed :)
No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts...
I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text
v := RTView new. v add: (RTLabel new elementOn: '-_-'). v
<fml.png> â
Or running AthensSurfaceExamples class>>exampleDrawText
<fml_squared.png>
In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this.
Peter
Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@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⦠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 <i.uhnak@gmail.com <mailto:i.uhnak@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)
Thank you Esteban! I've downloaded the latest VM and fonts on cairo now work. I believe this was the last VM crash I am aware of, so hopefully I will have a productive and stable year with Pharo 6. :) (I had some issues with dlls not loading on startup sometimes (mentioned in other thread SurfacePlugin.dll)... but this correlates with some other Windows issues...so I need more info myself). Thanks! Peter On Mon, Apr 03, 2017 at 12:12:08PM +0200, Esteban Lorenzano wrote:
Hi Peter,
I think I fixed the problem, can you try latest vm?
Esteban
On 31 Mar 2017, at 14:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Peter I took the latest mac VM and Moose 6.1 and I used your example then I played during 15 min with all the roassal examples and I cannot reproduce but I'm on mac.
On Fri, Mar 31, 2017 at 2:23 PM, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote: Tx peter! I really really sorry for this state of affair. I would like to tell you that I thank you for all the feedback you sent. Please continue. I imagine what it is to get a system that blow up under your fingers. I'm always trying to work with the alpha version (because I attract bugs) I got some crashes playing with roassal - but I updated to the latest vm and trying.
Can you sync with esteban so that he can access your setup? And yes we are burning esteban on this.... We should pay attention that our faery does not get too exhausted :).
Stef
On Fri, Mar 31, 2017 at 1:10 PM, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM.
So, all this discussion is informative, but the mail that originates it can be reviewed :)
No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts...
I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text
v := RTView new. v add: (RTLabel new elementOn: '-_-'). v
<fml.png> â
Or running AthensSurfaceExamples class>>exampleDrawText
<fml_squared.png>
In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this.
Peter
Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@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⦠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 <i.uhnak@gmail.com <mailto:i.uhnak@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)
Using the April 03 VM (the "latest" that was on Apr 03). The vm is way more stable (this is the first crash in two active days, which is record for me), so maybe the main cause of the problem has been fixed, but not all causes. I am also downloading latest (Apr 04) VM. There is no crash dump, but it crashed here: Unhandled exception at 0x00409287 in Pharo.exe: 0xC0000005: Access violation reading location 0x00000000. crash context: 00409258 ret 00409259 mov eax,dword ptr ds:[0059CD7Ch] 0040925E test al,3 00409260 jne 0040928B 00409262 mov ecx,dword ptr ds:[59CD40h] 00409268 lea edx,[ecx-1] 0040926B cmp eax,edx 0040926D jb 0040928B 0040926F cmp dword ptr ds:[59CD4Ch],eax 00409275 jb 0040928B 00409277 mov ecx,dword ptr ds:[5BE0D0h] 0040927D cmp dword ptr [eax-4],ecx 00409280 jb 0040928B 00409282 mov eax,dword ptr ds:[0059CD60h] --> 00409287 movzx eax,byte ptr [eax] 0040928A ret registers: EAX=00000000 EBX=00ADC994 ECX=10200000 EDX=00ADD240 ESI=00000000 EDI=00000000 EIP=00409287 ESP=00ADC044 EBP=00ADC964 EFL=00010202 Peter On Mon, Apr 03, 2017 at 03:27:53PM +0200, Peter Uhnak wrote:
Thank you Esteban!
I've downloaded the latest VM and fonts on cairo now work. I believe this was the last VM crash I am aware of, so hopefully I will have a productive and stable year with Pharo 6. :)
(I had some issues with dlls not loading on startup sometimes (mentioned in other thread SurfacePlugin.dll)... but this correlates with some other Windows issues...so I need more info myself).
Thanks!
Peter
On Mon, Apr 03, 2017 at 12:12:08PM +0200, Esteban Lorenzano wrote:
Hi Peter,
I think I fixed the problem, can you try latest vm?
Esteban
On 31 Mar 2017, at 14:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Peter I took the latest mac VM and Moose 6.1 and I used your example then I played during 15 min with all the roassal examples and I cannot reproduce but I'm on mac.
On Fri, Mar 31, 2017 at 2:23 PM, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote: Tx peter! I really really sorry for this state of affair. I would like to tell you that I thank you for all the feedback you sent. Please continue. I imagine what it is to get a system that blow up under your fingers. I'm always trying to work with the alpha version (because I attract bugs) I got some crashes playing with roassal - but I updated to the latest vm and trying.
Can you sync with esteban so that he can access your setup? And yes we are burning esteban on this.... We should pay attention that our faery does not get too exhausted :).
Stef
On Fri, Mar 31, 2017 at 1:10 PM, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM.
So, all this discussion is informative, but the mail that originates it can be reviewed :)
No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts...
I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text
v := RTView new. v add: (RTLabel new elementOn: '-_-'). v
<fml.png> â
Or running AthensSurfaceExamples class>>exampleDrawText
<fml_squared.png>
In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this.
Peter
Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@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⦠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 <i.uhnak@gmail.com <mailto:i.uhnak@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)
Can confirm that the latest (Apr 4) VM crashes too. I am not sure on what code this is crashing, but I am experiencing some odd behavior from metalinks, so maybe I broke something there (I was using metalinks a lot before the crash)... will investigate further. Peter On Wed, Apr 05, 2017 at 01:46:30PM +0200, Peter Uhnak wrote:
Using the April 03 VM (the "latest" that was on Apr 03). The vm is way more stable (this is the first crash in two active days, which is record for me), so maybe the main cause of the problem has been fixed, but not all causes. I am also downloading latest (Apr 04) VM.
There is no crash dump, but it crashed here:
Unhandled exception at 0x00409287 in Pharo.exe: 0xC0000005: Access violation reading location 0x00000000.
crash context:
00409258 ret 00409259 mov eax,dword ptr ds:[0059CD7Ch] 0040925E test al,3 00409260 jne 0040928B 00409262 mov ecx,dword ptr ds:[59CD40h] 00409268 lea edx,[ecx-1] 0040926B cmp eax,edx 0040926D jb 0040928B 0040926F cmp dword ptr ds:[59CD4Ch],eax 00409275 jb 0040928B 00409277 mov ecx,dword ptr ds:[5BE0D0h] 0040927D cmp dword ptr [eax-4],ecx 00409280 jb 0040928B 00409282 mov eax,dword ptr ds:[0059CD60h] --> 00409287 movzx eax,byte ptr [eax] 0040928A ret
registers: EAX=00000000 EBX=00ADC994 ECX=10200000 EDX=00ADD240 ESI=00000000 EDI=00000000 EIP=00409287 ESP=00ADC044 EBP=00ADC964 EFL=00010202
Peter
On Mon, Apr 03, 2017 at 03:27:53PM +0200, Peter Uhnak wrote:
Thank you Esteban!
I've downloaded the latest VM and fonts on cairo now work. I believe this was the last VM crash I am aware of, so hopefully I will have a productive and stable year with Pharo 6. :)
(I had some issues with dlls not loading on startup sometimes (mentioned in other thread SurfacePlugin.dll)... but this correlates with some other Windows issues...so I need more info myself).
Thanks!
Peter
On Mon, Apr 03, 2017 at 12:12:08PM +0200, Esteban Lorenzano wrote:
Hi Peter,
I think I fixed the problem, can you try latest vm?
Esteban
On 31 Mar 2017, at 14:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Peter I took the latest mac VM and Moose 6.1 and I used your example then I played during 15 min with all the roassal examples and I cannot reproduce but I'm on mac.
On Fri, Mar 31, 2017 at 2:23 PM, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote: Tx peter! I really really sorry for this state of affair. I would like to tell you that I thank you for all the feedback you sent. Please continue. I imagine what it is to get a system that blow up under your fingers. I'm always trying to work with the alpha version (because I attract bugs) I got some crashes playing with roassal - but I updated to the latest vm and trying.
Can you sync with esteban so that he can access your setup? And yes we are burning esteban on this.... We should pay attention that our faery does not get too exhausted :).
Stef
On Fri, Mar 31, 2017 at 1:10 PM, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM.
So, all this discussion is informative, but the mail that originates it can be reviewed :)
No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts...
I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text
v := RTView new. v add: (RTLabel new elementOn: '-_-'). v
<fml.png> â
Or running AthensSurfaceExamples class>>exampleDrawText
<fml_squared.png>
In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this.
Peter
Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@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⦠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 <i.uhnak@gmail.com <mailto:i.uhnak@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)
explicit call to garbage collect crashes the image (crash.dmp attached), so I think that in this case I somehow corrupted the image (with metalinks presumably) On Wed, Apr 05, 2017 at 03:39:39PM +0200, Peter Uhnak wrote:
Can confirm that the latest (Apr 4) VM crashes too.
I am not sure on what code this is crashing, but I am experiencing some odd behavior from metalinks, so maybe I broke something there (I was using metalinks a lot before the crash)... will investigate further.
Peter
On Wed, Apr 05, 2017 at 01:46:30PM +0200, Peter Uhnak wrote:
Using the April 03 VM (the "latest" that was on Apr 03). The vm is way more stable (this is the first crash in two active days, which is record for me), so maybe the main cause of the problem has been fixed, but not all causes. I am also downloading latest (Apr 04) VM.
There is no crash dump, but it crashed here:
Unhandled exception at 0x00409287 in Pharo.exe: 0xC0000005: Access violation reading location 0x00000000.
crash context:
00409258 ret 00409259 mov eax,dword ptr ds:[0059CD7Ch] 0040925E test al,3 00409260 jne 0040928B 00409262 mov ecx,dword ptr ds:[59CD40h] 00409268 lea edx,[ecx-1] 0040926B cmp eax,edx 0040926D jb 0040928B 0040926F cmp dword ptr ds:[59CD4Ch],eax 00409275 jb 0040928B 00409277 mov ecx,dword ptr ds:[5BE0D0h] 0040927D cmp dword ptr [eax-4],ecx 00409280 jb 0040928B 00409282 mov eax,dword ptr ds:[0059CD60h] --> 00409287 movzx eax,byte ptr [eax] 0040928A ret
registers: EAX=00000000 EBX=00ADC994 ECX=10200000 EDX=00ADD240 ESI=00000000 EDI=00000000 EIP=00409287 ESP=00ADC044 EBP=00ADC964 EFL=00010202
Peter
On Mon, Apr 03, 2017 at 03:27:53PM +0200, Peter Uhnak wrote:
Thank you Esteban!
I've downloaded the latest VM and fonts on cairo now work. I believe this was the last VM crash I am aware of, so hopefully I will have a productive and stable year with Pharo 6. :)
(I had some issues with dlls not loading on startup sometimes (mentioned in other thread SurfacePlugin.dll)... but this correlates with some other Windows issues...so I need more info myself).
Thanks!
Peter
On Mon, Apr 03, 2017 at 12:12:08PM +0200, Esteban Lorenzano wrote:
Hi Peter,
I think I fixed the problem, can you try latest vm?
Esteban
On 31 Mar 2017, at 14:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Peter I took the latest mac VM and Moose 6.1 and I used your example then I played during 15 min with all the roassal examples and I cannot reproduce but I'm on mac.
On Fri, Mar 31, 2017 at 2:23 PM, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote: Tx peter! I really really sorry for this state of affair. I would like to tell you that I thank you for all the feedback you sent. Please continue. I imagine what it is to get a system that blow up under your fingers. I'm always trying to work with the alpha version (because I attract bugs) I got some crashes playing with roassal - but I updated to the latest vm and trying.
Can you sync with esteban so that he can access your setup? And yes we are burning esteban on this.... We should pay attention that our faery does not get too exhausted :).
Stef
On Fri, Mar 31, 2017 at 1:10 PM, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM.
So, all this discussion is informative, but the mail that originates it can be reviewed :)
No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts...
I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text
v := RTView new. v add: (RTLabel new elementOn: '-_-'). v
<fml.png> â
Or running AthensSurfaceExamples class>>exampleDrawText
<fml_squared.png>
In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this.
Peter
Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@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⦠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 <i.uhnak@gmail.com <mailto:i.uhnak@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)
Or if you want yet another crash in fresh image and latest vm... (no crash.dmp of course) Unhandled exception at 0x0048B197 in Pharo.exe: 0xC0000005: Access violation reading location 0x00000075. registers EAX=0000003F EBX=00ADCA14 ECX=00000071 EDX=00ADD241 ESI=00372000 EDI=00000071 EIP=0048B197 ESP=00ADC0B4 EBP=00ADC11C EFL=00210206 0x00000075=00000000 disasm 0048B165 ret 0048B166 sub ebx,dword ptr [edi+108h] 0048B16C mov dword ptr [esi+8],ebx 0048B16F jmp 0048B134 0048B171 mov edx,57D40Bh 0048B176 jmp 0048B156 0048B178 push ebp 0048B179 push edi 0048B17A push esi 0048B17B push ebx 0048B17C mov edi,dword ptr [esp+14h] 0048B180 mov ebp,dword ptr [esp+18h] 0048B184 mov esi,dword ptr fs:[18h] 0048B18B mov eax,dword ptr [esp+1Ch] 0048B18F test eax,eax 0048B191 jle 0048B246 ---> 0048B197 mov edx,dword ptr [edi+4] <--- 0048B19A test edx,edx 0048B19C je 0048B246 0048B1A2 mov dword ptr [ebp],edx 0048B1A5 mov edx,dword ptr [edi] 0048B1A7 cmp edx,dword ptr [esi+4] 0048B1AA jae 0048B24A 0048B1B0 mov ecx,edi 0048B1B2 mov eax,1 0048B1B7 test byte ptr [esp+1Ch],1 0048B1BC jne 0048B228 0048B1BE cmp edi,edx 0048B1C0 setae bl 0048B1C3 mov ecx,ebx 0048B1C5 or bl,cl 0048B1C7 jne 0048B241 0048B1C9 test dl,3 0048B1CC jne 0048B241 0048B1CE mov ebx,dword ptr [edx+4] 0048B1D1 test ebx,ebx 0048B1D3 je 0048B241 0048B1D5 mov eax,2 0048B1DA mov dword ptr [ebp+eax*4-4],ebx 0048B1DE mov ebx,dword ptr [edx] 0048B1E0 mov ecx,edx 0048B1E2 cmp ebx,dword ptr [esi+4] 0048B1E5 jae 0048B241 0048B1E7 mov edx,ebx 0048B1E9 jmp 0048B228 0048B1EB mov ebx,dword ptr [edx+4] 0048B1EE test ebx,ebx 0048B1F0 je 0048B241 0048B1F2 add eax,1 0048B1F5 mov dword ptr [ebp+eax*4-4],ebx 0048B1F9 mov ecx,dword ptr [edx] 0048B1FB cmp ecx,dword ptr [esi+4] 0048B1FE jae 0048B241 0048B200 cmp edi,ecx 0048B202 setae bl 0048B205 cmp edx,ecx 0048B207 setae dl 0048B20A or bl,dl 0048B20C jne 0048B241 0048B20E test cl,3 0048B211 jne 0048B241 0048B213 mov ebx,dword ptr [ecx+4] 0048B216 test ebx,ebx 0048B218 je 0048B241 0048B21A add eax,1 0048B21D mov dword ptr [ebp+eax*4-4],ebx 0048B221 mov edx,dword ptr [ecx] 0048B223 cmp edx,dword ptr [esi+4] 0048B226 jae 0048B241 0048B228 cmp edi,edx 0048B22A setae bl 0048B22D cmp ecx,edx 0048B22F setae cl 0048B232 or bl,cl 0048B234 jne 0048B241 0048B236 test dl,3 0048B239 jne 0048B241 0048B23B cmp dword ptr [esp+1Ch],eax 0048B23F jne 0048B1EB 0048B241 pop ebx 0048B242 pop esi 0048B243 pop edi 0048B244 pop ebp 0048B245 ret On Wed, Apr 05, 2017 at 03:45:15PM +0200, Peter Uhnak wrote:
explicit call to garbage collect crashes the image (crash.dmp attached), so I think that in this case I somehow corrupted the image (with metalinks presumably)
On Wed, Apr 05, 2017 at 03:39:39PM +0200, Peter Uhnak wrote:
Can confirm that the latest (Apr 4) VM crashes too.
I am not sure on what code this is crashing, but I am experiencing some odd behavior from metalinks, so maybe I broke something there (I was using metalinks a lot before the crash)... will investigate further.
Peter
On Wed, Apr 05, 2017 at 01:46:30PM +0200, Peter Uhnak wrote:
Using the April 03 VM (the "latest" that was on Apr 03). The vm is way more stable (this is the first crash in two active days, which is record for me), so maybe the main cause of the problem has been fixed, but not all causes. I am also downloading latest (Apr 04) VM.
There is no crash dump, but it crashed here:
Unhandled exception at 0x00409287 in Pharo.exe: 0xC0000005: Access violation reading location 0x00000000.
crash context:
00409258 ret 00409259 mov eax,dword ptr ds:[0059CD7Ch] 0040925E test al,3 00409260 jne 0040928B 00409262 mov ecx,dword ptr ds:[59CD40h] 00409268 lea edx,[ecx-1] 0040926B cmp eax,edx 0040926D jb 0040928B 0040926F cmp dword ptr ds:[59CD4Ch],eax 00409275 jb 0040928B 00409277 mov ecx,dword ptr ds:[5BE0D0h] 0040927D cmp dword ptr [eax-4],ecx 00409280 jb 0040928B 00409282 mov eax,dword ptr ds:[0059CD60h] --> 00409287 movzx eax,byte ptr [eax] 0040928A ret
registers: EAX=00000000 EBX=00ADC994 ECX=10200000 EDX=00ADD240 ESI=00000000 EDI=00000000 EIP=00409287 ESP=00ADC044 EBP=00ADC964 EFL=00010202
Peter
On Mon, Apr 03, 2017 at 03:27:53PM +0200, Peter Uhnak wrote:
Thank you Esteban!
I've downloaded the latest VM and fonts on cairo now work. I believe this was the last VM crash I am aware of, so hopefully I will have a productive and stable year with Pharo 6. :)
(I had some issues with dlls not loading on startup sometimes (mentioned in other thread SurfacePlugin.dll)... but this correlates with some other Windows issues...so I need more info myself).
Thanks!
Peter
On Mon, Apr 03, 2017 at 12:12:08PM +0200, Esteban Lorenzano wrote:
Hi Peter,
I think I fixed the problem, can you try latest vm?
Esteban
On 31 Mar 2017, at 14:55, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Peter I took the latest mac VM and Moose 6.1 and I used your example then I played during 15 min with all the roassal examples and I cannot reproduce but I'm on mac.
On Fri, Mar 31, 2017 at 2:23 PM, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote: Tx peter! I really really sorry for this state of affair. I would like to tell you that I thank you for all the feedback you sent. Please continue. I imagine what it is to get a system that blow up under your fingers. I'm always trying to work with the alpha version (because I attract bugs) I got some crashes playing with roassal - but I updated to the latest vm and trying.
Can you sync with esteban so that he can access your setup? And yes we are burning esteban on this.... We should pay attention that our faery does not get too exhausted :).
Stef
On Fri, Mar 31, 2017 at 1:10 PM, Peter Uhnák <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: BTW⦠I just checked Latest VM with a Pharo 5.0 (50771), and FT2 DOES NOT CRASHES⦠and it looks working fine, just installed somethings, etc. so I cannot be sure it will remain like that, but I can tell you: FT2 fonts are working fine in Windows (tested in 7) and Pharo 5.0 *with* latest VM.
So, all this discussion is informative, but the mail that originates it can be reviewed :)
No, this is still broken, even in Pharo 6 (with the latest VM). Maybe it's yet another cairo issue? But it complains about FT fonts...
I did mention that it crashed on Athens canvas, so e.g. any Roassal presentation that contains text
v := RTView new. v add: (RTLabel new elementOn: '-_-'). v
<fml.png> â
Or running AthensSurfaceExamples class>>exampleDrawText
<fml_squared.png>
In the past 15 months there was not a single week when the VM would just work without crashing or failing, and seeing that Pharo 6/lastest VM one day before release still doesn't work makes me really question why I still put up with this.
Peter
Esteban
On 29 Mar 2017, at 14:43, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
We cannot work in 5.0 professionally with the VM released at the time. I am also using an intermediate VM thing to do the job.
That is a pain. And not helping me push more Pharo to sysadmin people because they cannot have a stable reference point.
Phil
On Wed, Mar 29, 2017 at 12:05 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:
On 29 Mar 2017, at 11:39, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@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⦠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 <i.uhnak@gmail.com <mailto:i.uhnak@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)
--------------------------------------------------------------------- Wed Apr 05 15:41:01 2017
Exception code: C0000005 Exception addr: 0041FCB4 Access violation (read access) at 2B31DCE0 EAX:02800000 EBX:00000001 ECX:2B31DCE0 EDX:0E804909 ESI:00000004 EDI:01004909 EBP:1C500420 ESP:00ADD080 EIP:0041FCB4 EFL:00210246 FP Control: 0000027F FP Status: 00000420 FP Tag: 0000FFFF
Crashed in the VM thread
Hardware information: Manufacturer: Unknown Model: Unknown Number of processors: 4 Page size: 4096
Memory Information (upon launch): Physical Memory Size: 4194303 kbytes Physical Memory Free: 4194303 kbytes Page File Size: 4194303 kbytes Page File Free: 4194303 kbytes Virtual Memory Size: 4194176 kbytes Virtual Memory Free: 4094764 kbytes Memory Load: 23 percent
Processor 0: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz Identifier: Intel64 Family 6 Model 94 Stepping 3 ~MHZ: 2712
Processor 1: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz Identifier: Intel64 Family 6 Model 94 Stepping 3 ~MHZ: 2712
Processor 2: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz Identifier: Intel64 Family 6 Model 94 Stepping 3 ~MHZ: 2712
Processor 3: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz Identifier: Intel64 Family 6 Model 94 Stepping 3 ~MHZ: 2712
Operating System: Windows 10 Home (Build 14393 )
SP major version: 0 SP minor version: 0 Suite mask: 300 Product type: 1
Display Information: Graphics adapter name: NVIDIA GeForce GTX 1060 6GB Primary monitor resolution: 1920 x 1200
Device: NVIDIA GeForce GTX 1060 6GB Memory Size: 0xFFF00000
Driver Versions: C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvd3dumx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2umx,C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_f37f8f12da8b10d7\nvwgf2umx:
VM Version: Cog Spur VM 5.0 (release) from Apr 4 2017 Compiler: gcc 5.4.0 Interpreter Build: CoInterpreter * VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 4 2017 Cogit Build: StackToRegisterMappingCogit * VMMaker.oscog-eem.2188 uuid: ff4ca601-cd05-4792-ab0d-dcdf19975239 Apr 4 2017 Source Version: VM: 201704041239 https://github.com/pharo-project/pharo-vm.git $ Date: Tue Apr 4 14:39:42 2017 +0200 $ Plugins: 201704041239 https://github.com/pharo-project/pharo-vm.git $
Current byte code: 210 Primitive index: 130
Loaded plugins: ZipPlugin * VMMaker.oscog-eem.2188 (i) JPEGReadWriter2Plugin * VMMaker.oscog-eem.2188 (i) B2DPlugin * VMMaker.oscog-eem.2188 (i) BitBltPlugin * VMMaker.oscog-eem.2188 (i) FT2Plugin Freetype-Plugin-EstebanLorenzano.70 (e) FilePlugin * VMMaker.oscog-eem.2188 (i) MiscPrimitivePlugin * VMMaker.oscog-eem.2188 (i) LargeIntegers v2.0 * VMMaker.oscog-eem.2188 (i) LocalePlugin * VMMaker.oscog-eem.2188 (i) SecurityPlugin * VMMaker.oscog-eem.2188 (i)
Module information: 00400000 - 00703000: C:\Applications\Pharo6VM\Pharo.exe 00b90000 - 00bb3000: C:\WINDOWS\SYSTEM32\WINMMBASE.dll 10000000 - 1002b000: C:\WINDOWS\System32\cbfsMntNtf6.dll 10100000 - 106c4c70: CogCode 553c0000 - 555bf000: C:\Users\uhnak\AppData\Local\Microsoft\OneDrive\17.3.6798.0207\FileSyncShell.dll 55650000 - 556d3000: C:\Windows\System32\PortableDeviceApi.dll 557d0000 - 557e2000: C:\WINDOWS\system32\mssprxy.dll 557f0000 - 55914000: C:\WINDOWS\system32\NetworkExplorer.dll 55920000 - 5593b000: C:\Windows\System32\DevDispItemProvider.dll 55940000 - 55998000: C:\Windows\System32\PlayToDevice.dll 559a0000 - 559e2000: C:\Windows\System32\dlnashext.dll 559f0000 - 55b76000: C:\Windows\System32\ActXPrxy.dll 55b80000 - 55c2f000: C:\WINDOWS\system32\Windows.Storage.Search.dll 55c30000 - 55d82000: C:\Windows\System32\uiautomationcore.dll 55d90000 - 55ec6000: C:\Windows\System32\Windows.Globalization.dll 56210000 - 5622a000: C:\WINDOWS\System32\davclnt.dll 56230000 - 562b5000: C:\WINDOWS\System32\StructuredQuery.dll 56350000 - 563b7000: C:\WINDOWS\SYSTEM32\msvcp110_win.dll 56430000 - 56442000: C:\WINDOWS\System32\ntlanman.dll 56450000 - 56493000: C:\Windows\System32\thumbcache.dll 56f60000 - 56fa3000: C:\WINDOWS\System32\WINSTA.dll 5c0e0000 - 5c10a000: C:\WINDOWS\SYSTEM32\RTWorkQ.DLL 5c5f0000 - 5c703000: C:\WINDOWS\SYSTEM32\MFPlat.DLL 5cf40000 - 5cf92000: C:\Windows\System32\Bcp47Langs.dll 5cfa0000 - 5d3dc000: C:\WINDOWS\system32\explorerframe.dll 5d930000 - 5d988000: C:\WINDOWS\System32\MMDevApi.dll 5da10000 - 5db23000: C:\WINDOWS\system32\dcomp.dll 5db30000 - 5db74000: C:\WINDOWS\system32\dataexchange.dll 5db80000 - 5ddb0000: C:\WINDOWS\system32\d3d11.dll 5df90000 - 5dfe4000: C:\WINDOWS\system32\OLEACC.dll 62d30000 - 62e1d000: C:\WINDOWS\SYSTEM32\DDRAW.dll 62f00000 - 62fe0000: C:\WINDOWS\SYSTEM32\OPENGL32.DLL 63940000 - 6394e000: C:\Applications\Pharo6VM\iconv.dll 646d0000 - 64838000: C:\WINDOWS\system32\DUI70.dll 64840000 - 64931000: C:\WINDOWS\system32\twinapi.appcore.dll 64b40000 - 64b54000: C:\Applications\Pharo6VM\libwinpthread-1.dll 669d0000 - 669db000: C:\WINDOWS\System32\DAVHLPR.dll 669e0000 - 66a05000: C:\WINDOWS\SYSTEM32\globinputhost.dll 66a10000 - 66a8b000: C:\WINDOWS\system32\DUser.dll 66b00000 - 66b06000: C:\WINDOWS\SYSTEM32\SHFolder.dll 66b50000 - 66b59000: C:\WINDOWS\System32\drprov.dll 67080000 - 6713b000: C:\Applications\Pharo6VM\libfreetype.dll 679c0000 - 67a81000: C:\WINDOWS\SYSTEM32\ntshrui.dll 69580000 - 69603000: C:\WINDOWS\system32\dxgi.dll 6a780000 - 6a7ad000: C:\Applications\Pharo6VM\FT2Plugin.DLL 6b7e0000 - 6b81f000: C:\WINDOWS\SYSTEM32\policymanager.dll 6b820000 - 6b845000: C:\WINDOWS\SYSTEM32\dinput.dll 6b990000 - 6ba11000: C:\WINDOWS\SYSTEM32\sxs.dll 6ba20000 - 6ba3c000: C:\WINDOWS\SYSTEM32\srvcli.dll 6ba50000 - 6ba75000: C:\WINDOWS\SYSTEM32\GLU32.dll 6c560000 - 6c56d000: C:\WINDOWS\SYSTEM32\LINKINFO.dll 6c940000 - 6caad000: C:\Applications\Pharo6VM\SDL2.dll 6d0c0000 - 6d0dd000: C:\Applications\Pharo6VM\libgcc_s_sjlj-1.dll 6e140000 - 6e161000: C:\WINDOWS\SYSTEM32\Cabinet.dll 6e810000 - 6e8fe000: C:\Users\uhnak\AppData\Local\Microsoft\OneDrive\17.3.6798.0207\MSVCR120.dll 6e940000 - 6eaae000: C:\WINDOWS\SYSTEM32\WindowsCodecs.dll 6f890000 - 6faf6000: C:\WINDOWS\SYSTEM32\WININET.dll 6ff50000 - 6ffc1000: C:\Users\uhnak\AppData\Local\Microsoft\OneDrive\17.3.6798.0207\MSVCP120.dll 6ffd0000 - 70062000: C:\WINDOWS\SYSTEM32\apphelp.dll 70340000 - 7038f000: C:\Users\uhnak\AppData\Local\Microsoft\OneDrive\17.3.6798.0207\Telemetry.dll 70390000 - 7059a000: C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.14393.953_none_89c2555adb023171\comctl32.dll 706c0000 - 706cf000: C:\WINDOWS\SYSTEM32\cscapi.dll 70760000 - 70778000: C:\Users\uhnak\AppData\Local\Microsoft\OneDrive\17.3.6798.0207\LoggingPlatform.DLL 707f0000 - 7080a000: C:\Windows\System32\USERENV.dll 70980000 - 70acf000: C:\WINDOWS\SYSTEM32\PROPSYS.dll 70e40000 - 70e4a000: C:\WINDOWS\SYSTEM32\Secur32.dll 70e50000 - 70e5b000: C:\WINDOWS\System32\netutils.dll 70ec0000 - 70ee2000: C:\WINDOWS\System32\DEVOBJ.dll 70f30000 - 70f38000: C:\WINDOWS\SYSTEM32\WSOCK32.dll 70f40000 - 70fe0000: C:\WINDOWS\SYSTEM32\WINHTTP.dll 71230000 - 71240000: C:\WINDOWS\System32\wkscli.dll 712b0000 - 712b7000: C:\WINDOWS\SYSTEM32\DCIMAN32.dll 71330000 - 713c4000: C:\WINDOWS\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.14393.447_none_5507ded2cb4f7f4c\COMCTL32.dll 71440000 - 71449000: C:\WINDOWS\SYSTEM32\atlthunk.dll 71450000 - 7146f000: C:\WINDOWS\system32\dwmapi.dll 720f0000 - 7210b000: C:\WINDOWS\system32\bcrypt.dll 73420000 - 73436000: C:\WINDOWS\SYSTEM32\MPR.dll 73440000 - 7347d000: C:\WINDOWS\SYSTEM32\edputil.dll 73670000 - 73694000: C:\WINDOWS\SYSTEM32\WINMM.DLL 736a0000 - 73715000: C:\WINDOWS\system32\uxtheme.dll 73e10000 - 73e18000: C:\WINDOWS\SYSTEM32\VERSION.dll 740a0000 - 740aa000: C:\WINDOWS\System32\CRYPTBASE.dll 740b0000 - 740ce000: C:\WINDOWS\System32\SspiCli.dll 740d0000 - 741b0000: C:\WINDOWS\System32\KERNEL32.DLL 741b0000 - 74244000: C:\WINDOWS\System32\OLEAUT32.dll 74250000 - 74385000: C:\WINDOWS\System32\MSCTF.dll 74390000 - 74396000: C:\WINDOWS\System32\PSAPI.DLL 743a0000 - 74485000: C:\WINDOWS\System32\COMDLG32.DLL 74490000 - 744d5000: C:\WINDOWS\System32\powrprof.dll 744e0000 - 7453a000: C:\WINDOWS\System32\bcryptPrimitives.dll 74540000 - 745a3000: C:\WINDOWS\System32\WS2_32.dll 745b0000 - 74751000: C:\WINDOWS\System32\KERNELBASE.dll 748d0000 - 74a4d000: C:\WINDOWS\System32\CRYPT32.dll 74ab0000 - 74b71000: C:\WINDOWS\System32\RPCRT4.dll 74b80000 - 74bb6000: C:\WINDOWS\System32\cfgmgr32.dll 74bc0000 - 74c37000: C:\WINDOWS\System32\ADVAPI32.dll 74c40000 - 74c9b000: C:\WINDOWS\System32\coml2.dll 74ca0000 - 74d28000: C:\WINDOWS\System32\shcore.dll 74d30000 - 74d55000: C:\WINDOWS\System32\IMM32.DLL 74d60000 - 74e1e000: C:\WINDOWS\System32\msvcrt.dll 74e20000 - 74e61000: C:\WINDOWS\System32\sechost.dll 74e70000 - 74fcf000: C:\WINDOWS\System32\USER32.dll 74fd0000 - 75014000: C:\WINDOWS\System32\WINTRUST.dll 75020000 - 7558e000: C:\WINDOWS\System32\windows.storage.dll 75590000 - 75670000: C:\WINDOWS\System32\ucrtbase.dll 75670000 - 7567e000: C:\WINDOWS\System32\MSASN1.dll 75680000 - 75891000: C:\WINDOWS\System32\combase.dll 758a0000 - 758af000: C:\WINDOWS\System32\profapi.dll 75980000 - 7598d000: C:\WINDOWS\System32\kernel.appcore.dll 75990000 - 759d6000: C:\WINDOWS\System32\SHLWAPI.dll 759e0000 - 75b3b000: C:\WINDOWS\System32\gdi32full.dll 75b40000 - 75bc4000: C:\WINDOWS\System32\clbcatq.dll 75bd0000 - 75cba000: C:\WINDOWS\System32\ole32.dll 75cc0000 - 75d3b000: C:\WINDOWS\System32\msvcp_win.dll 75d50000 - 7615b000: C:\WINDOWS\System32\SETUPAPI.dll 76160000 - 76175000: C:\WINDOWS\System32\win32u.dll 76180000 - 77559000: C:\WINDOWS\System32\SHELL32.dll 77560000 - 7758b000: C:\WINDOWS\System32\GDI32.dll 775f0000 - 77773000: C:\WINDOWS\SYSTEM32\ntdll.dll
Primitive trace: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: **StackOverflow** replaceFrom:to:with:startingAt: shallowCopy replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: instVarAt: instVarAt:put: instVarAt: instVarAt:put: instVarAt: instVarAt:put: replaceFrom:to:with:startingAt: compare:with:collated: instVarAt:put: replaceFrom:to:with:startingAt: compare:with:collated: instVarAt:put: replaceFrom:to:with:startingAt: compare:with:collated: instVarAt:put: species **StackOverflow** stringHash:initialHash: stringHash:initialHash: stringHash:initialHash: stringHash:initialHash: stringHash:initialHash: stringHash:initialHash: stringHash:initialHash: stringHash:initialHash: stringHash:initialHash: basicNew stringHash:initialHash: basicNew fullCheck basicNew basicNew basicNew basicNew basicNew **StackOverflow** basicNew stringHash:initialHash: basicNew push: stringHash:initialHash: stringHash:initialHash: findSubstring:in:startingAt:matchTable: **PrimitiveFailure** numArgs numArgs numArgs numArgs numArgs numArgs numArgs numArgs numArgs numArgs numArgs numArgs numArgs numArgs indexOfAscii:inString:startingAt: stringHash:initialHash: stringHash:initialHash: * * replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: isEmpty bitShift: bitShift: numTemps numTemps numTemps asBit asBit **StackOverflow** replaceFrom:to:with:startingAt: initialize newMethod:header: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: size at: at:put: basicNew with: replaceFrom:to:with:startingAt: at:put: at:put: at:put: objectAt:put: objectAt:put: objectAt:put: objectAt:put: withIndexDo: numTemps numTemps numTemps bitAnd: **PrimitiveFailure** bitAnd: **PrimitiveFailure** bitOr: **PrimitiveFailure** bitOr: new: objectAt: at:put: objectAt: at:put: objectAt: at:put: objectAt: at:put: class objectAt:put: stringHash:initialHash: objectAt:put: withArgs:executeMethod: basicAt: value: value **StackOverflow** basicIdentityHash basicSize species basicNew: basicAt: basicAt:put: species basicNew: basicReplaceFrom:to:with:startingAt: do: value: value: startIndexFor: startIndexFor: at: at: replaceFrom:to:with:startingAt: at: basicAt: at: at: expire at: at: primitiveGarbageCollect **FullGC**
Stack backtrace: [0041FCB4] ??? + 0x1fcb4 in Pharo.exe [03800000] ??? + 0x0 in (null)
Smalltalk stack dump: 0xae9060 I SmalltalkImage>garbageCollect 0x10bc6d90: a(n) SmalltalkImage 0xae9078 M UndefinedObject>DoIt 0x106c4c70: a(n) UndefinedObject 0xae90a8 I OpalCompiler>evaluate 0x103847f8: a(n) OpalCompiler 0xae90d4 I RubSmalltalkEditor>evaluate:andDo: 0x1029bd48: a(n) RubSmalltalkEditor 0xae90fc I RubSmalltalkEditor>highlightEvaluateAndDo: 0x1029bd48: a(n) RubSmalltalkEditor 0xae911c M [] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>actOnHighlightAndEvaluate: 0x102cd918: a(n) GLMMorphicPharoScriptRenderer 0xae9134 M RubEditingArea(RubAbstractTextArea)>handleEdit: 0x1029ae60: a(n) RubEditingArea 0xae9154 M [] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>actOnHighlightAndEvaluate: 0x102cd918: a(n) GLMMorphicPharoScriptRenderer 0xae9174 M WorldState>runStepMethodsIn: 0x118ed178: a(n) WorldState 0xae9190 M WorldMorph>runStepMethods 0x111c7e68: a(n) WorldMorph 0xae91a8 M WorldState>doOneCycleNowFor: 0x118ed178: a(n) WorldState 0xae91c4 M WorldState>doOneCycleFor: 0x118ed178: a(n) WorldState 0xae91e0 M WorldMorph>doOneCycle 0x111c7e68: a(n) WorldMorph 0xae91f8 M WorldMorph class>doOneCycle 0x111afdb8: a(n) WorldMorph class 0xae9210 M [] in FDMorphicUIManager(MorphicUIManager)>spawnNewProcess 0x1ef6ef88: a(n) FDMorphicUIManager 0xae9230 I [] in BlockClosure>newProcess 0x1efc4670: a(n) BlockClosure
participants (7)
-
Ben Coman -
Esteban Lorenzano -
Peter Uhnak -
Peter Uhnák
-
phil＠highoctane.be -
Stan Krupoderov -
Stephane Ducasse