<div dir="ltr">Hi Henry,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 16, 2017 at 6:33 PM, henry <span dir="ltr"><<a href="mailto:henry@callistohouse.club" target="_blank">henry@callistohouse.club</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>That is good news, that it is due to this code doing funniness than a VM issue. This code trying to bring asynchrony within a synchronous environment brings new issues.</div>
<div>
<br>
</div>
<div>What do you think that right solution is to the issue of a call expected to be immediate, change out to go eventual until the arguments resolve? </div></blockquote><div><br></div><div>I'm not informed enough to know. One could implement mustBeBoolean in the ERef hierarchy and resolve the promise before going on. One could rely on the mustBeBooleanMagic: if one wanted a fully lazy system. I don't know the trade-offs between the two. I do know that while the miustBeBooleanMagic: solution is cool and fun it is extremely slow. So if performance is an issue use the first approach.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>How can it be structured correctly on the stack without generic functions? I think with the double
dispatch of an eventual but I have not spend much time in this particular area. </div></blockquote><div><br></div><div>Yes that's an issue There is already a problem with #==. It needs to be symmetric for correctness.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Preventing the vm from crashing would be a good interim step but even here I am not sure how to go about crafting a solution. </div></blockquote><div><br></div><div>Well, the issue is simply that the wrong pc is chosen for the continuation after the mustBeBoolean. I'm sure the right answer is straight-forward to obtain.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>Thank you for investigating this.<br></div></blockquote><div><br></div><div>You're welcome.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div>
<div>
<br>
</div>
<div class="m_5600713812245111431protonmail_signature_block">- HH</div><div class="HOEnZb"><div class="h5">
<div>
<br>
<div>
<div>
<br>
</div>On Wed, Aug 16, 2017 at 20:46, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:</div>
<blockquote class="m_5600713812245111431protonmail_quote" type="cite">
<div dir="ltr">Hi Henry, Hi Marcus,
<div class="gmail_extra">
<br>
<div class="gmail_quote">On Sun, Aug 13, 2017 at 5:08 AM, henry <span dir="ltr"><<a href="mailto:henry@callistohouse.club" target="_blank">henry@callistohouse.club</a>></span> wrote:
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)">
<div>Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers
<br>
</div>
<div>
<br>
</div>
<div><a href="http://www.squeaksource.com/TurquoiseTesting.html" target="_blank">http://www.squeaksource.com/Tu<wbr>rquoiseTesting.html</a>
<br>
</div>
<div>
<br>
</div>
<div class="m_5600713812245111431gmail-m_7806948026423193907protonmail_signature_block">
<div class="m_5600713812245111431gmail-m_7806948026423193907protonmail_signature_block-user">- HH</div>
</div>
</blockquote>
<div>
<br>
</div>
<div>I took a look at this and I think you've found a bug in the mustBeBooleanMagic: code. What's happening is a mustBeBoolean in Integer>>* due to evaluating</div>
<div> 10 * 42 eventual</div>
<div>in RefsTest>><wbr>testFailureArithmeticPrimitive<wbr>sWithPromiseArgument</div>
<div>
<br>
</div>
<div>Since 42 eventual is a NearERef the SmallInteger>>* primitive fails and does ^super * anInteger (where anInteger is the NearERef). So that evaluates Integer>>*</div>
<div>
<br>
</div>
<div>Integer>>* aNumber</div>
<div><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>"Refer to the comment in Number * " </div>
<div><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>aNumber isInteger ifTrue:</div>
<div><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>[^ self digitMultiply: aNumber </div>
<div><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>neg: self negative ~~ aNumber negative].</div>
<div><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>^ aNumber adaptToInteger: self andSend: #*</div>
<div>
<br>
</div>
<div>aNumber, being a NearERef, answers a PromiseERef for the isInteger send, and this provokes a mustBeBoolean for the isInteger ifTrue: [...</div>
<div>
<br>
</div>
<div>After the mustBeBooleanMagic: the stack looks wrong. The activation of Integer>>*, which is about to do</div>
<div> ^ aNumber adaptToInteger: self andSend: #*</div>
<div>does not have enough items on the stack. Instead of containing</div>
<div> a NearERef (for 42)</div>
<div> 10</div>
<div> #*</div>
<div>it contains</div>
<div> a PromiseERef (for 42 eventual isInteger)</div>
</div>
<br>and the send of #adaptToInteger:andSend: ends up taking more form the stack than the VM can handle and it crashes. The bug appears to be with the use of sendNode irInstruction nextBytecodeOffsetAfterJump in Object>>mustBeBooleanMagic: <wbr>since
execution should resume at bytecode 55 below, but does so at bytecode 57
<br clear="all">
<br>
<div class="gmail_extra">41 <10> pushTemp: 0</div>
<div class="gmail_extra">42 <D0> send: isInteger</div>
<div class="gmail_extra">43 <AC 09> jumpFalse: 54</div>
<div class="gmail_extra">45 <70> self</div>
<div class="gmail_extra">46 <10> pushTemp: 0</div>
<div class="gmail_extra">47 <70> self</div>
<div class="gmail_extra">48 <D1> send: negative</div>
<div class="gmail_extra">49 <10> pushTemp: 0</div>
<div class="gmail_extra">50 <D1> send: negative</div>
<div class="gmail_extra">51 <E2> send: ~~</div>
<div class="gmail_extra">52 <F3> send: digitMultiply:neg:</div>
<div class="gmail_extra">53 <7C> returnTop</div>
<div class="gmail_extra">54 <10> pushTemp: 0</div>
<div class="gmail_extra">55 <70> self</div>
<div class="gmail_extra">56 <24> pushConstant: #*</div>
<div class="gmail_extra">57 <F5> send: adaptToInteger:andSend:</div>
<div class="gmail_extra">58 <7C> returnTop</div>
<div class="gmail_extra">
<br>
</div>
<div class="gmail_extra">So the positioning of the context's pc must be before any argument marshaling for the next send, not simply the send itself.</div>
<div class="gmail_extra">
<br>
</div>
<div class="gmail_extra">Put a breakpoint at the end of Object>>mustBeBooleanMagic: and add initlaPC and resumePC temporaries at the beginning and capture them via</div>
<div class="gmail_extra"> initialPC := context pc.</div>
<div class="gmail_extra">at the beginning and then</div>
<div class="gmail_extra">
<div class="gmail_extra"><span class="m_5600713812245111431gmail-Apple-tab-span" style="white-space:pre-wrap"> </span>context pc: (resumePC := sendNode irInstruction nextBytecodeOffsetAfterJump)</div>
</div>
<div class="gmail_extra">to see what I'm seeing.</div>
<div class="gmail_extra">
<br>
</div>
<div class="gmail_extra">
<br>
</div>
<div class="gmail_extra">Phew. Glad it's not a VM bug :-)</div>
<div class="gmail_extra">
<br>
</div>
<div class="gmail_extra">HTH</div>
<div class="m_5600713812245111431gmail_signature">
<div dir="ltr">
<div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div><div><br></div></span>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>