Smalltalk › Squeak › Squeak - Dev

Problem with #applyTransitions in Language Translator

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

강진오

Problem with #applyTransitions in Language Translator

Hi.

I have a problem with my language translator.

When I press [apply] button on my language translator,

My Squeak was lacked and got a lot of memory and CPU.

I restarted and executed that action with new process.

Even though the priority of it was the lowest (10),

It started to make my Squeak to be slow.

I suspended it and traced the stack.

It was the loop of:

StrikeFont>>widthOf:

FixedFaceFont>>widthOf:

StrikeFont>>widthOf:

FixedFaceFont>>widthOf:

StrikeFont>>widthOf:

FixedFaceFont>>widthOf:

StrikeFont>>widthOf:

FixedFaceFont>>widthOf:

…

There was limit to view all stack trace,

So I created new process that trace suspended stack trace.

But I couldn’t find the root.

What happened to my Squeak?

Chris Muller-3

Re: Problem with #applyTransitions in Language Translator

There appears to be a corruption in Squeak's font structure for
special-characters.

The #fallbackFont of the StrikeFont refers back to the original
StrikeFont, leading to endless recursion and locking up your image.
This script identifies the fonts with wrong pointers:

StrikeFont allInstances select: [ : e | (e fallbackFont respondsTo:
#baseFont) and: [ e fallbackFont baseFont == e ] ]

StrikeFont>>#widthOf: aCharacter -- if the aCharacter is a special
character it will ask the #fallbackFont for widthOf: aCharacter, which
turns around and asks it's #baseFont, which happens to be the original
StrikeFont.

The problem occurs when the fallbackFont is not already set. So this
appears to be a bug with StrikeFont>>#fallbackFont.

Do any of the font experts know a proper fix?

2012/2/20 강진오 <[hidden email]>:

> Hi.
>
> I have a problem with my language translator.
>
> When I press [apply] button on my language translator,
>
> My Squeak was lacked and got a lot of memory and CPU.
>
> I restarted and executed that action with new process.
>
> Even though the priority of it was the lowest (10),
>
> It started to make my Squeak to be slow.
>
> I suspended it and traced the stack.
>
> It was the loop of:
>
> StrikeFont>>widthOf:
>
> FixedFaceFont>>widthOf:
>
> StrikeFont>>widthOf:
>
> FixedFaceFont>>widthOf:
>
> StrikeFont>>widthOf:
>
> FixedFaceFont>>widthOf:
>
> StrikeFont>>widthOf:
>
> FixedFaceFont>>widthOf:
>
> …
>
> There was limit to view all stack trace,
>
> So I created new process that trace suspended stack trace.
>
> But I couldn’t find the root.
>
> What happened to my Squeak?
>
>
>
>

Karl Ramberg

Re: Problem with #applyTransitions in Language Translator

On Wed, Feb 22, 2012 at 4:47 AM, Chris Muller <[hidden email]> wrote:

> There appears to be a corruption in Squeak's font structure for
> special-characters.
>
> The #fallbackFont of the StrikeFont refers back to the original
> StrikeFont, leading to endless recursion and locking up your image.
> This script identifies the fonts with wrong pointers:
>
> StrikeFont allInstances select: [ : e | (e fallbackFont respondsTo:
> #baseFont) and: [ e fallbackFont baseFont == e ] ]
>
> StrikeFont>>#widthOf: aCharacter -- if the aCharacter is a special
> character it will ask the #fallbackFont for widthOf: aCharacter, which
> turns around and asks it's #baseFont, which happens to be the original
> StrikeFont.
>
> The problem occurs when the fallbackFont is not already set. So this
> appears to be a bug with StrikeFont>>#fallbackFont.
>
> Do any of the font experts know a proper fix?
>
>

We have a fix for this issue in the Etoys.image.

I just copy paste from a mail...,

Karl

----- Method: FixedFaceFont>>fontSize: (in category 'accessing') -----
fontSize: aNumber
+ |font|
+ font := (StrikeFont familyName: baseFont familyName size: aNumber)
shallowCopy.
+ font fallbackFont: nil.
+ self baseFont: font!
- self baseFont: (StrikeFont familyName: baseFont familyName size:
aNumber) copy!

I

>
> 2012/2/20 강진오 <[hidden email]>:
>> Hi.
>>
>> I have a problem with my language translator.
>>
>> When I press [apply] button on my language translator,
>>
>> My Squeak was lacked and got a lot of memory and CPU.
>>
>> I restarted and executed that action with new process.
>>
>> Even though the priority of it was the lowest (10),
>>
>> It started to make my Squeak to be slow.
>>
>> I suspended it and traced the stack.
>>
>> It was the loop of:
>>
>> StrikeFont>>widthOf:
>>
>> FixedFaceFont>>widthOf:
>>
>> StrikeFont>>widthOf:
>>
>> FixedFaceFont>>widthOf:
>>
>> StrikeFont>>widthOf:
>>
>> FixedFaceFont>>widthOf:
>>
>> StrikeFont>>widthOf:
>>
>> FixedFaceFont>>widthOf:
>>
>> …
>>
>> There was limit to view all stack trace,
>>
>> So I created new process that trace suspended stack trace.
>>
>> But I couldn’t find the root.
>>
>> What happened to my Squeak?
>>
>>
>>
>>
>

강진오

Re: Problem with #applyTransitions in Language Translator

In reply to this post by Chris Muller-3

Thank you, but I already solved the problem and learned everything you said before I send the mail. I simply solved the problem by fixing the font. It seems that the mail was in queue and was sent after I solved it.

2012. 2. 22. 오후 12:47에 "Chris Muller" <[hidden email]>님이 작성:
&

There appears to be a corruption in Squeak's font structure for
special-characters.

The #fallbackFont of the StrikeFont refers back to the original
StrikeFont, leading to endless recursion and locking up your image.
This script identifies the fonts with wrong pointers:

StrikeFont allInstances select: [ : e | (e fallbackFont respondsTo:
#baseFont) and: [ e fallbackFont baseFont == e ] ]

StrikeFont>>#widthOf: aCharacter -- if the aCharacter is a special
character it will ask the #fallbackFont for widthOf: aCharacter, which
turns around and asks it's #baseFont, which happens to be the original
StrikeFont.

The problem occurs when the fallbackFont is not already set. So this
appears to be a bug with StrikeFont>>#fallbackFont.

Do any of the font experts know a proper fix?

2012/2/20 강진오 <[hidden email]>:
> Hi.
>
> I have a problem with my language translator.
>
> When I press [apply] button on my language translator,
>
> My Squeak was lacked and got a lot of memory and CPU.
>
> I restarted and executed that action with new process.
>
> Even though the priority of it was the lowest (10),
>
> It started to make my Squeak to be slow.
>
> I suspended it and traced the stack.
>
> It was the loop of:
>
> StrikeFont>>widthOf:
>
> FixedFaceFont>>widthOf:
>
> StrikeFont>>widthOf:
>
> FixedFaceFont>>widthOf:
>
> StrikeFont>>widthOf:
>
> FixedFaceFont>>widthOf:
>
> StrikeFont>>widthOf:
>
> FixedFaceFont>>widthOf:
>
> …
>
> There was limit to view all stack trace,
>
> So I created new process that trace suspended stack trace.
>
> But I couldn’t find the root.
>
> What happened to my Squeak?
>
>
>
>