Smalltalk › Pharo › Pharo Smalltalk Developers

the new "fixed" compactor VM has FT broken...

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

21 messages Options

Peter Uhnak

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)

EstebanLM

Re: the new "fixed" compactor VM has FT broken...

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 <[hidden email]> 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 Uhnak

Re: the new "fixed" compactor VM has FT broken...

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 <[hidden email]> 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)
> >
>
>

EstebanLM

Re: the new "fixed" compactor VM has FT broken...

> On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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)
>>>
>>
>>
>

Stanislav Krupoderov

Re: the new "fixed" compactor VM has FT broken...

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 <[hidden email]> wrote:

> On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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

EstebanLM

Re: the new "fixed" compactor VM has FT broken...

On 29 Mar 2017, at 12:39, Stan Krupoderov <[hidden email]> 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 <[hidden email]> wrote:

> On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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

Peter Uhnak

Re: the new "fixed" compactor VM has FT broken...

In reply to this post by EstebanLM

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 <[hidden email]> 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)
> >>>
> >>
> >>
> >
>
>

Ben Coman

Re: the new "fixed" compactor VM has FT broken...

In reply to this post by Stanislav Krupoderov

On Wed, Mar 29, 2017 at 6:39 PM, Stan Krupoderov <[hidden email]> 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 <[hidden email]>
> wrote:
>>
>>
>> > On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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

philippeback

Re: the new "fixed" compactor VM has FT broken...

In reply to this post by EstebanLM

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 <[hidden email]> wrote:

> On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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)
>>>
>>
>>
>

EstebanLM

Re: the new "fixed" compactor VM has FT broken...

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, [hidden email] 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 <[hidden email]> wrote:

> On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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)
>>>
>>
>>
>

EstebanLM

Re: the new "fixed" compactor VM has FT broken...

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 <[hidden email]> 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, [hidden email] 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 <[hidden email]> wrote:

> On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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)
>>>
>>
>>
>

philippeback

Re: the new "fixed" compactor VM has FT broken...

In reply to this post by EstebanLM

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 <[hidden email]> 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, [hidden email] 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 <[hidden email]> wrote:

> On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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 Uhnak

Re: the new "fixed" compactor VM has FT broken...

In reply to this post by EstebanLM

On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <[hidden email]> 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: '-_-').

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, [hidden email] 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 <[hidden email]> wrote:

> On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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)
>>>
>>
>>
>

Stephane Ducasse-3

Re: the new "fixed" compactor VM has FT broken...

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 <[hidden email]> wrote:

On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <[hidden email]> 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, [hidden email] 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 <[hidden email]> wrote:

> On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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)
>>>
>>
>>
>

Stephane Ducasse-3

Re: the new "fixed" compactor VM has FT broken...

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 <[hidden email]> 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 <[hidden email]> wrote:

On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <[hidden email]> 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, [hidden email] 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 <[hidden email]> wrote:

> On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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)
>>>
>>
>>
>

EstebanLM

Re: the new "fixed" compactor VM has FT broken...

Hi Peter,

I think I fixed the problem, can you try latest vm?

Esteban

On 31 Mar 2017, at 14:55, Stephane Ducasse <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:

On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <[hidden email]> 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, [hidden email] 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 <[hidden email]> wrote:

> On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email]> 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 <[hidden email]> 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 Uhnak

Re: the new "fixed" compactor VM has FT broken...

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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> wrote:
> >
> >
> > On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <[hidden email] <mailto:[hidden email]>> 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, [hidden email] <mailto:[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> wrote:
> >>
> >> > On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> 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 Uhnak

Re: the new "fixed" compactor VM has FT broken...

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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> wrote:
> > >
> > >
> > > On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <[hidden email] <mailto:[hidden email]>> 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, [hidden email] <mailto:[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> wrote:
> > >>
> > >> > On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> 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 Uhnak

Re: the new "fixed" compactor VM has FT broken...

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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> wrote:
> > > >
> > > >
> > > > On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <[hidden email] <mailto:[hidden email]>> 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, [hidden email] <mailto:[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> wrote:
> > > >>
> > > >> > On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> 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 Uhnak

Re: the new "fixed" compactor VM has FT broken...

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 <[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> wrote:
> > > > >
> > > > >
> > > > > On Wed, Mar 29, 2017 at 3:03 PM, Esteban Lorenzano <[hidden email] <mailto:[hidden email]>> 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, [hidden email] <mailto:[hidden email]> 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 <[hidden email] <mailto:[hidden email]>> wrote:
> > > > >>
> > > > >> > On 29 Mar 2017, at 11:39, Peter Uhnak <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>> 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)
> > > > >> >>>
> > > > >> >>
> > > > >> >>
> > > > >> >
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > >
> > > >

crash.dmp (14K) Download Attachment