Re: [Pharo-dev] [Vm-dev] vm crash when using rairedTo: with fractions

2017-08-15 Thread Ben Coman 
On Mon, Aug 14, 2017 at 4:49 PM, Tim Mackinnon  wrote:

> Is there a way for this to get back into 6.1 - so we can shoot for a
> stable 6.x version that will last us for a year while 7.x is under
> development?
>
> I’m not familiar with how point release are handled in Pharo, and I get
> the impression that this is going to be a slightly rockier year as there
> have been some pretty revolutionary changes made to get us here.
>
> As its a vm change does this mean we get 6.2 queued up somehow?
>

We don't (yet) have a massive-cyber-corp backer, so with limited resources
there are only limited point releases - usually only one, half-way to
two-thirds through the year.  But we already got 6.1, so I'm not sure
affects things.

Now the first rule is that fixes must go into the current dev branch and
then backported.  So get it into Pharo 7 and queue it up for (maybe) 6.2.

cheers -ben


>
> Tim
>
> > On 13 Aug 2017, at 20:12, Stephane Ducasse 
> wrote:
> >
> > Tx eliot.
> >
> >
> > On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda 
> wrote:
> >> Hi Andrei,
> >>
> >> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <
> chisvasileand...@gmail.com>
> >> wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> I was executing this code  '(2009/2000) ** (3958333/10)' 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: 10' 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
> >
>
>
>

Re: [Pharo-dev] [Vm-dev] vm crash when using rairedTo: with fractions

2017-08-14 Thread Stephane Ducasse 
I like your answer nicolas.
If this is really important for any business or any dev around let us know
we can just tag it and we will port it for 6.2.

Stef


On Mon, Aug 14, 2017 at 11:29 AM, Nicolas Cellier
 wrote:
> Hi Tim,
> I'd say: is this a showstopper?
> How often do you raise a Fraction to the power of another Fraction with
> large denominator (> 1)?
> Or is it used indirectly by some kind of Framework?
>
> If yes then open a pharo bug entry and mark for 6.x, else just wait 7.x...
>
> Nicolas
>
>
> 2017-08-14 10:49 GMT+02:00 Tim Mackinnon :
>>
>> Is there a way for this to get back into 6.1 - so we can shoot for a
>> stable 6.x version that will last us for a year while 7.x is under
>> development?
>>
>> I’m not familiar with how point release are handled in Pharo, and I get
>> the impression that this is going to be a slightly rockier year as there
>> have been some pretty revolutionary changes made to get us here.
>>
>> As its a vm change does this mean we get 6.2 queued up somehow?
>>
>> Tim
>>
>> > On 13 Aug 2017, at 20:12, Stephane Ducasse 
>> > wrote:
>> >
>> > Tx eliot.
>> >
>> >
>> > On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda
>> >  wrote:
>> >> Hi Andrei,
>> >>
>> >> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis
>> >> 
>> >> wrote:
>> >>>
>> >>>
>> >>> Hi,
>> >>>
>> >>> I was executing this code  '(2009/2000) ** (3958333/10)' 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: 10' 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
>> >
>>
>>
>

Re: [Pharo-dev] [Vm-dev] vm crash when using rairedTo: with fractions

2017-08-14 Thread Tim Mackinnon 
It’s a fair point - I guess if enough things crop up, then a 6.2 release gets 
contemplated.

Tim

> On 14 Aug 2017, at 10:29, Nicolas Cellier 
>  wrote:
> 
> Hi Tim,
> I'd say: is this a showstopper?
> How often do you raise a Fraction to the power of another Fraction with large 
> denominator (> 1)?
> Or is it used indirectly by some kind of Framework?
> 
> If yes then open a pharo bug entry and mark for 6.x, else just wait 7.x...
> 
> Nicolas
> 
> 2017-08-14 10:49 GMT+02:00 Tim Mackinnon  >:
> Is there a way for this to get back into 6.1 - so we can shoot for a stable 
> 6.x version that will last us for a year while 7.x is under development?
> 
> I’m not familiar with how point release are handled in Pharo, and I get the 
> impression that this is going to be a slightly rockier year as there have 
> been some pretty revolutionary changes made to get us here.
> 
> As its a vm change does this mean we get 6.2 queued up somehow?
> 
> Tim
> 
> > On 13 Aug 2017, at 20:12, Stephane Ducasse  > > wrote:
> >
> > Tx eliot.
> >
> >
> > On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda  > > wrote:
> >> Hi Andrei,
> >>
> >> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis  >> >
> >> wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> I was executing this code  '(2009/2000) ** (3958333/10)' 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: 10' 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
> >
> 
> 
>

Re: [Pharo-dev] [Vm-dev] vm crash when using rairedTo: with fractions

2017-08-14 Thread Nicolas Cellier 
Hi Tim,
I'd say: is this a showstopper?
How often do you raise a Fraction to the power of another Fraction with
large denominator (> 1)?
Or is it used indirectly by some kind of Framework?

If yes then open a pharo bug entry and mark for 6.x, else just wait 7.x...

Nicolas

2017-08-14 10:49 GMT+02:00 Tim Mackinnon :

> Is there a way for this to get back into 6.1 - so we can shoot for a
> stable 6.x version that will last us for a year while 7.x is under
> development?
>
> I’m not familiar with how point release are handled in Pharo, and I get
> the impression that this is going to be a slightly rockier year as there
> have been some pretty revolutionary changes made to get us here.
>
> As its a vm change does this mean we get 6.2 queued up somehow?
>
> Tim
>
> > On 13 Aug 2017, at 20:12, Stephane Ducasse 
> wrote:
> >
> > Tx eliot.
> >
> >
> > On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda 
> wrote:
> >> Hi Andrei,
> >>
> >> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis <
> chisvasileand...@gmail.com>
> >> wrote:
> >>>
> >>>
> >>> Hi,
> >>>
> >>> I was executing this code  '(2009/2000) ** (3958333/10)' 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: 10' 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
> >
>
>
>

Re: [Pharo-dev] [Vm-dev] vm crash when using rairedTo: with fractions

2017-08-14 Thread Tim Mackinnon 
Is there a way for this to get back into 6.1 - so we can shoot for a stable 6.x 
version that will last us for a year while 7.x is under development?

I’m not familiar with how point release are handled in Pharo, and I get the 
impression that this is going to be a slightly rockier year as there have been 
some pretty revolutionary changes made to get us here.

As its a vm change does this mean we get 6.2 queued up somehow?

Tim

> On 13 Aug 2017, at 20:12, Stephane Ducasse  wrote:
> 
> Tx eliot.
> 
> 
> On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda  
> wrote:
>> Hi Andrei,
>> 
>> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis 
>> wrote:
>>> 
>>> 
>>> Hi,
>>> 
>>> I was executing this code  '(2009/2000) ** (3958333/10)' 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: 10' 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
>

Re: [Pharo-dev] [Vm-dev] vm crash when using rairedTo: with fractions

2017-08-13 Thread Stephane Ducasse 
Tx eliot.


On Fri, Aug 11, 2017 at 12:55 AM, Eliot Miranda  wrote:
> Hi Andrei,
>
> On Thu, Aug 10, 2017 at 3:02 AM, Andrei Chis 
> wrote:
>>
>>
>> Hi,
>>
>> I was executing this code  '(2009/2000) ** (3958333/10)' 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: 10' 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