vm crash when using rairedTo: with fractions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

vm crash when using rairedTo: with fractions

Andrei Chis
 
Hi,

I was executing this code  '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10.
Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.

Cheers,
Andrei


0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger
0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger
0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri
enderer
0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm
0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class
0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager
0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vm crash when using rairedTo: with fractions

Nicolas Cellier
 
Hi Andrei,
indeed, the method does not scale well...

If the result is an exact Fraction, then it will answer the Fraction.
Else if not exact, it will be converted to a Float.

The problem is that it will try to answer nearest Float with a rather naive algorithm.
Moreover, computing the nthRoot: first, then raising the result to the power of numerator will cumulate rounding errors.
So trying to get a very accurate nthRoot: first in case of Float result is not a good strategy anyway.

Why the VM crashes exactly is another problem and remains to see, we'd prefer an Exception.

As a workaround, I suggest sending asFloat to the receiver and/or operand.


2017-08-10 12:02 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi,

I was executing this code  '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10.
Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.

Cheers,
Andrei


0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger
0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger
0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri
enderer
0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm
0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class
0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager
0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vm crash when using rairedTo: with fractions

Andrei Chis
 
Hi Nicolas,

Thanks for the info. Indeed sending #asFloat to the operand leads to a correct behaviour. 

Just then is there a need for this special use case for handling Fractions if it can lead to such problematic behaviour? Would the logarithmic way ((aNumber * self ln) exp) not be enough? On this example the computation takes a few minutes before crashing the image. 


Cheers,
Andrei

On Thu, Aug 10, 2017 at 9:27 PM, Nicolas Cellier <[hidden email]> wrote:
 
Hi Andrei,
indeed, the method does not scale well...

If the result is an exact Fraction, then it will answer the Fraction.
Else if not exact, it will be converted to a Float.

The problem is that it will try to answer nearest Float with a rather naive algorithm.
Moreover, computing the nthRoot: first, then raising the result to the power of numerator will cumulate rounding errors.
So trying to get a very accurate nthRoot: first in case of Float result is not a good strategy anyway.

Why the VM crashes exactly is another problem and remains to see, we'd prefer an Exception.

As a workaround, I suggest sending asFloat to the receiver and/or operand.


2017-08-10 12:02 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi,

I was executing this code  '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10.
Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.

Cheers,
Andrei


0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger
0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger
0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri
enderer
0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm
0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class
0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager
0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vm crash when using rairedTo: with fractions

Nicolas Cellier
 


2017-08-10 22:19 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi Nicolas,

Thanks for the info. Indeed sending #asFloat to the operand leads to a correct behaviour. 

Just then is there a need for this special use case for handling Fractions if it can lead to such problematic behaviour? Would the logarithmic way ((aNumber * self ln) exp) not be enough? On this example the computation takes a few minutes before crashing the image. 


Having (1/1000 raisedTo: 2/3) = (1/100)  is a nice thing and we want to keep it.
But once we detect that we can't have an exact result, we should adopt a more efficient strategy.

There are corner cases where we want to avoid overflow/underflow in intermediate values, such as (1<<2000 + 1) raisedTo: 1/200 or ((1<<2000 + 1) reciprocal raisedTo: 1/200, so we must not convert asFloat too soon.
But since ln already handles those edge cases (at least in Squeak, I have to check Pharo), ((aNumber * self ln) exp) is a good approximation (a few ulp off, depending on the quality of underlying libm).

Nicolas


Cheers,
Andrei

On Thu, Aug 10, 2017 at 9:27 PM, Nicolas Cellier <[hidden email]> wrote:
 
Hi Andrei,
indeed, the method does not scale well...

If the result is an exact Fraction, then it will answer the Fraction.
Else if not exact, it will be converted to a Float.

The problem is that it will try to answer nearest Float with a rather naive algorithm.
Moreover, computing the nthRoot: first, then raising the result to the power of numerator will cumulate rounding errors.
So trying to get a very accurate nthRoot: first in case of Float result is not a good strategy anyway.

Why the VM crashes exactly is another problem and remains to see, we'd prefer an Exception.

As a workaround, I suggest sending asFloat to the receiver and/or operand.


2017-08-10 12:02 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi,

I was executing this code  '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10.
Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.

Cheers,
Andrei


0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger
0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger
0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri
enderer
0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm
0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class
0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager
0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vm crash when using rairedTo: with fractions

Eliot Miranda-2
In reply to this post by Andrei Chis
 
Hi Andrei,

On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <[hidden email]> wrote:
 
Hi,

I was executing this code  '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10.
Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.

The plugin is now fixed; see VMMaker.oscog-eem.2262.  I'll generate code soon (am debugging something you're familiar with that takes several hours to run and don't want to generate sources while it's running).  But I'm glad you've found a better way!  This case creates 600k byte large integers and takes forever to run :-)


Cheers,
Andrei


0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger
0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger
0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri
enderer
0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm
0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class
0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager
0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure




--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vm crash when using rairedTo: with fractions

Andrei Chis
 


On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda <[hidden email]> wrote:
 
Hi Andrei,

On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <[hidden email]> wrote:
 
Hi,

I was executing this code  '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10.
Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.

The plugin is now fixed; see VMMaker.oscog-eem.2262.  I'll generate code soon (am debugging something you're familiar with that takes several hours to run and don't want to generate sources while it's running).  But I'm glad you've found a better way!  This case creates 600k byte large integers and takes forever to run :-)

Nice! Thanks for the fix.

Cheers,
Andrei
 


Cheers,
Andrei


0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger
0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger
0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri
enderer
0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm
0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class
0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager
0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure




--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vm crash when using rairedTo: with fractions

Andrei Chis
In reply to this post by Nicolas Cellier
 


On Thu, Aug 10, 2017 at 10:42 PM, Nicolas Cellier <[hidden email]> wrote:
 


2017-08-10 22:19 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi Nicolas,

Thanks for the info. Indeed sending #asFloat to the operand leads to a correct behaviour. 

Just then is there a need for this special use case for handling Fractions if it can lead to such problematic behaviour? Would the logarithmic way ((aNumber * self ln) exp) not be enough? On this example the computation takes a few minutes before crashing the image. 


Having (1/1000 raisedTo: 2/3) = (1/100)  is a nice thing and we want to keep it.

Indeed, it's a nice to have feature.
 
But once we detect that we can't have an exact result, we should adopt a more efficient strategy.  

Do you know if the vm plugin fix from Eliot addresses also this or there should some more actions taken on the image side?
 

There are corner cases where we want to avoid overflow/underflow in intermediate values, such as (1<<2000 + 1) raisedTo: 1/200 or ((1<<2000 + 1) reciprocal raisedTo: 1/200, so we must not convert asFloat too soon.
But since ln already handles those edge cases (at least in Squeak, I have to check Pharo), ((aNumber * self ln) exp) is a good approximation (a few ulp off, depending on the quality of underlying libm). 

For now I switched to using ((aNumber * self ln) exp)  and it's working well.

Cheers,
Andrei


Nicolas


Cheers,
Andrei

On Thu, Aug 10, 2017 at 9:27 PM, Nicolas Cellier <[hidden email]> wrote:
 
Hi Andrei,
indeed, the method does not scale well...

If the result is an exact Fraction, then it will answer the Fraction.
Else if not exact, it will be converted to a Float.

The problem is that it will try to answer nearest Float with a rather naive algorithm.
Moreover, computing the nthRoot: first, then raising the result to the power of numerator will cumulate rounding errors.
So trying to get a very accurate nthRoot: first in case of Float result is not a good strategy anyway.

Why the VM crashes exactly is another problem and remains to see, we'd prefer an Exception.

As a workaround, I suggest sending asFloat to the receiver and/or operand.


2017-08-10 12:02 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi,

I was executing this code  '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10.
Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.

Cheers,
Andrei


0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger
0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger
0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri
enderer
0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm
0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class
0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager
0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure








Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vm crash when using rairedTo: with fractions

Nicolas Cellier
 


2017-08-13 12:13 GMT+02:00 Andrei Chis <[hidden email]>:
 


On Thu, Aug 10, 2017 at 10:42 PM, Nicolas Cellier <[hidden email]> wrote:
 


2017-08-10 22:19 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi Nicolas,

Thanks for the info. Indeed sending #asFloat to the operand leads to a correct behaviour. 

Just then is there a need for this special use case for handling Fractions if it can lead to such problematic behaviour? Would the logarithmic way ((aNumber * self ln) exp) not be enough? On this example the computation takes a few minutes before crashing the image. 


Having (1/1000 raisedTo: 2/3) = (1/100)  is a nice thing and we want to keep it.

Indeed, it's a nice to have feature.
 
But once we detect that we can't have an exact result, we should adopt a more efficient strategy.  

Do you know if the vm plugin fix from Eliot addresses also this or there should some more actions taken on the image side?
 

There are corner cases where we want to avoid overflow/underflow in intermediate values, such as (1<<2000 + 1) raisedTo: 1/200 or ((1<<2000 + 1) reciprocal raisedTo: 1/200, so we must not convert asFloat too soon.
But since ln already handles those edge cases (at least in Squeak, I have to check Pharo), ((aNumber * self ln) exp) is a good approximation (a few ulp off, depending on the quality of underlying libm). 

For now I switched to using ((aNumber * self ln) exp)  and it's working well.

Cheers,
Andrei


Hi Andrei,
an image side modification is necessary if we want to gain more efficiency.
The question is whether we want to have correctly rounded results or not for Integer>>nthRoot:.
If not, ((aNumber * self ln) exp) is OK (it can be a few ulp off as I told before).
For Fraction, there's no point in rounding some term correctly then spoiling by an inexact raisedTo: and an inexact /.
I started to look at it in Squeak (same code), then it will be time to port in Pharo.

Nicolas
 

Nicolas


Cheers,
Andrei

On Thu, Aug 10, 2017 at 9:27 PM, Nicolas Cellier <[hidden email]> wrote:
 
Hi Andrei,
indeed, the method does not scale well...

If the result is an exact Fraction, then it will answer the Fraction.
Else if not exact, it will be converted to a Float.

The problem is that it will try to answer nearest Float with a rather naive algorithm.
Moreover, computing the nthRoot: first, then raising the result to the power of numerator will cumulate rounding errors.
So trying to get a very accurate nthRoot: first in case of Float result is not a good strategy anyway.

Why the VM crashes exactly is another problem and remains to see, we'd prefer an Exception.

As a workaround, I suggest sending asFloat to the receiver and/or operand.


2017-08-10 12:02 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi,

I was executing this code  '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10.
Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.

Cheers,
Andrei


0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger
0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger
0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri
enderer
0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm
0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class
0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager
0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure










Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vm crash when using rairedTo: with fractions

Juan Vuletich-3
 
Is this enough?

Fraction >> nthRoot: aPositiveInteger
    "Answer the nth root of the receiver."

    | d n |
    n _ numerator nthRootTruncated: aPositiveInteger.
    (n raisedTo: aPositiveInteger) = numerator ifFalse: [
        ^self asFloat nthRoot: aPositiveInteger ].
    d _ denominator nthRootTruncated: aPositiveInteger.
    (d raisedTo: aPositiveInteger) = denominator ifFalse: [
        ^self asFloat nthRoot: aPositiveInteger ].
    ^n / d

Seems to work ok in Cuis.

Thanks,

On 8/13/2017 9:47 AM, Nicolas Cellier wrote:
 




2017-08-13 12:13 GMT+02:00 Andrei Chis <[hidden email]>:
 


On Thu, Aug 10, 2017 at 10:42 PM, Nicolas Cellier <[hidden email]> wrote:
 


2017-08-10 22:19 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi Nicolas,

Thanks for the info. Indeed sending #asFloat to the operand leads to a correct behaviour. 

Just then is there a need for this special use case for handling Fractions if it can lead to such problematic behaviour? Would the logarithmic way ((aNumber * self ln) exp) not be enough? On this example the computation takes a few minutes before crashing the image. 


Having (1/1000 raisedTo: 2/3) = (1/100)  is a nice thing and we want to keep it.

Indeed, it's a nice to have feature.
 
But once we detect that we can't have an exact result, we should adopt a more efficient strategy.  

Do you know if the vm plugin fix from Eliot addresses also this or there should some more actions taken on the image side?
 

There are corner cases where we want to avoid overflow/underflow in intermediate values, such as (1<<2000 + 1) raisedTo: 1/200 or ((1<<2000 + 1) reciprocal raisedTo: 1/200, so we must not convert asFloat too soon.
But since ln already handles those edge cases (at least in Squeak, I have to check Pharo), ((aNumber * self ln) exp) is a good approximation (a few ulp off, depending on the quality of underlying libm). 

For now I switched to using ((aNumber * self ln) exp)  and it's working well.

Cheers,
Andrei


Hi Andrei,
an image side modification is necessary if we want to gain more efficiency.
The question is whether we want to have correctly rounded results or not for Integer>>nthRoot:.
If not, ((aNumber * self ln) exp) is OK (it can be a few ulp off as I told before).
For Fraction, there's no point in rounding some term correctly then spoiling by an inexact raisedTo: and an inexact /.
I started to look at it in Squeak (same code), then it will be time to port in Pharo.

Nicolas
 

Nicolas


Cheers,
Andrei

On Thu, Aug 10, 2017 at 9:27 PM, Nicolas Cellier <[hidden email]> wrote:
 
Hi Andrei,
indeed, the method does not scale well...

If the result is an exact Fraction, then it will answer the Fraction.
Else if not exact, it will be converted to a Float.

The problem is that it will try to answer nearest Float with a rather naive algorithm.
Moreover, computing the nthRoot: first, then raising the result to the power of numerator will cumulate rounding errors.
So trying to get a very accurate nthRoot: first in case of Float result is not a good strategy anyway.

Why the VM crashes exactly is another problem and remains to see, we'd prefer an Exception.

As a workaround, I suggest sending asFloat to the receiver and/or operand.


2017-08-10 12:02 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi,

I was executing this code  '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10.
Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.

Cheers,
Andrei


0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger
0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger
0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri
enderer
0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm
0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class
0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager
0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure












-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
@JuanVuletich
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vm crash when using rairedTo: with fractions

Nicolas Cellier
In reply to this post by Nicolas Cellier
 
So, i've patched Squeak (I hope I made no mistake, I'm not Smalltalking much these days)
See http://source.squeak.org/trunk/Kernel-nice.1111.diff
I'm not willing to contribute to Pharo immediately because no time to play with a fragile infrastucture.
If you badly need the patch in Pharo, feel free to plagiarize.

Nicolas

2017-08-13 14:47 GMT+02:00 Nicolas Cellier <[hidden email]>:


2017-08-13 12:13 GMT+02:00 Andrei Chis <[hidden email]>:
 


On Thu, Aug 10, 2017 at 10:42 PM, Nicolas Cellier <[hidden email]> wrote:
 


2017-08-10 22:19 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi Nicolas,

Thanks for the info. Indeed sending #asFloat to the operand leads to a correct behaviour. 

Just then is there a need for this special use case for handling Fractions if it can lead to such problematic behaviour? Would the logarithmic way ((aNumber * self ln) exp) not be enough? On this example the computation takes a few minutes before crashing the image. 


Having (1/1000 raisedTo: 2/3) = (1/100)  is a nice thing and we want to keep it.

Indeed, it's a nice to have feature.
 
But once we detect that we can't have an exact result, we should adopt a more efficient strategy.  

Do you know if the vm plugin fix from Eliot addresses also this or there should some more actions taken on the image side?
 

There are corner cases where we want to avoid overflow/underflow in intermediate values, such as (1<<2000 + 1) raisedTo: 1/200 or ((1<<2000 + 1) reciprocal raisedTo: 1/200, so we must not convert asFloat too soon.
But since ln already handles those edge cases (at least in Squeak, I have to check Pharo), ((aNumber * self ln) exp) is a good approximation (a few ulp off, depending on the quality of underlying libm). 

For now I switched to using ((aNumber * self ln) exp)  and it's working well.

Cheers,
Andrei


Hi Andrei,
an image side modification is necessary if we want to gain more efficiency.
The question is whether we want to have correctly rounded results or not for Integer>>nthRoot:.
If not, ((aNumber * self ln) exp) is OK (it can be a few ulp off as I told before).
For Fraction, there's no point in rounding some term correctly then spoiling by an inexact raisedTo: and an inexact /.
I started to look at it in Squeak (same code), then it will be time to port in Pharo.

Nicolas
 

Nicolas


Cheers,
Andrei

On Thu, Aug 10, 2017 at 9:27 PM, Nicolas Cellier <[hidden email]> wrote:
 
Hi Andrei,
indeed, the method does not scale well...

If the result is an exact Fraction, then it will answer the Fraction.
Else if not exact, it will be converted to a Float.

The problem is that it will try to answer nearest Float with a rather naive algorithm.
Moreover, computing the nthRoot: first, then raising the result to the power of numerator will cumulate rounding errors.
So trying to get a very accurate nthRoot: first in case of Float result is not a good strategy anyway.

Why the VM crashes exactly is another problem and remains to see, we'd prefer an Exception.

As a workaround, I suggest sending asFloat to the receiver and/or operand.


2017-08-10 12:02 GMT+02:00 Andrei Chis <[hidden email]>:
 
Hi,

I was executing this code  '(2009/2000) ** (3958333/100000)' with the Pharo6.1 distribution and the vm crashed with she stack attached below. Tried it on both mac and windows 10.
Seems that #raisedTo: has a special case for fractions that ends up calling #nthRoot: like '2009 nthRoot: 100000' leading to the crash.

Cheers,
Andrei


0xaddeac M LargePositiveInteger(Integer)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddec8 M LargePositiveInteger(LargeInteger)>quo: 0x314093e8: a(n) LargePositiveInteger
0xaddee8 M LargePositiveInteger(Integer)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf04 M LargePositiveInteger(LargeInteger)>// 0x314093e8: a(n) LargePositiveInteger
0xaddf34 I LargePositiveInteger(Integer)>nthRootTruncated: 0x30cc8350: a(n) LargePositiveInteger
0xaddf5c I LargePositiveInteger(Integer)>nthRootRounded: 0x30cc8350: a(n) LargePositiveInteger
0xaddf88 I SmallInteger(Integer)>nthRoot: 0xfb3=2009
0xaddfb4 I Fraction>nthRoot: 0x4f9a940: a(n) Fraction
0xaddfd8 I Fraction(Number)>raisedTo: 0x4f9a940: a(n) Fraction
0xaddffc I Fraction(Number)>** 0x4f9a940: a(n) Fraction
0xade018 M UndefinedObject>DoIt 0x5fe5d00: a(n) UndefinedObject
0xade048 I OpalCompiler>evaluate 0x4f9a998: a(n) OpalCompiler
0xade074 I RubSmalltalkEditor>evaluate:andDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade09c I RubSmalltalkEditor>highlightEvaluateAndDo: 0x305e5878: a(n) RubSmalltalkEditor
0xade0b8 M GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>popupPrint 0x3062fdc8: a(n) GLMMorphicPharoScri
enderer
0xade0d8 I MorphicAlarm(MessageSend)>value 0x4f9ab20: a(n) MorphicAlarm
0xade0f4 M MorphicAlarm>value: 0x4f9ab20: a(n) MorphicAlarm
0xade114 M WorldState>triggerAlarmsBefore: 0x71bb5e0: a(n) WorldState
0xade140 M WorldState>runLocalStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade164 M WorldState>runStepMethodsIn: 0x71bb5e0: a(n) WorldState
0xade180 M WorldMorph>runStepMethods 0x6ab7778: a(n) WorldMorph
0xade198 M WorldState>doOneCycleNowFor: 0x71bb5e0: a(n) WorldState
0xade1b4 M WorldState>doOneCycleFor: 0x71bb5e0: a(n) WorldState
0xade1d0 M WorldMorph>doOneCycle 0x6ab7778: a(n) WorldMorph
0xade1e8 M WorldMorph class>doOneCycle 0x6a9f960: a(n) WorldMorph class
0xade200 M [] in MorphicUIManager>spawnNewProcess 0x2cc88718: a(n) MorphicUIManager
0xade220 I [] in BlockClosure>newProcess 0x2f178150: a(n) BlockClosure











Loading...