<br><br><div class="gmail_quote">On Thu, Dec 23, 2010 at 2:05 AM, Mariano Martinez Peck <span dir="ltr"><<a href="mailto:marianopeck@gmail.com">marianopeck@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><br><div class="gmail_quote">On Wed, Dec 22, 2010 at 10:34 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>Hi Mariano,<div><br></div><div> indeed it's a bug. Your fix (objectMemory is: rcvr instanceOf: <span style="background-color:rgb(255, 255, 51)">(self splObj: ClassBlockClosure)</span> compactClassIndex: ClassBlockClosureCompactIndex) is the correct one. </div>
</blockquote><div><br>Thanks Eliot. But with that fix, the buytecode primitives are still failing and not calling the primitive, but commonSend. So:<br><br>1) is this the expected behavior .. or<br></div></div></blockquote>
<div><br></div><div>No. The intension is for the value and value: bytecodes to directly invoke closure value.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div>2) to fix that is not as I did it in my last fix but in some other place that you will fix?<br></div></div></blockquote><div><br></div><div>I'll try and fix once I can concentrate on Cog (I'm still focussed on Teleplace work until the week following xmas).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>
<br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div> There are a few other places where this needs to be done also. I'll roll out new code soon.</div>
</blockquote><div><br>Ok. Please let me know. I have some changes for better support of SmallIntegers as methods. I can provide them if you want.<br></div></div></blockquote><div><br></div><div>Please email me the change sets.</div>
<div><br></div><div>thanks!</div><div>Eliot</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div><br>Cheers<br><br>mariano<br>
</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div><br></div><div>best</div><div>Eliot<br><br><div class="gmail_quote">On Wed, Dec 22, 2010 at 12:03 PM, Mariano Martinez Peck <span dir="ltr"><<a href="mailto:marianopeck@gmail.com" target="_blank">marianopeck@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"> <br>Hi Eliot. If I compile a StackVM, and I just press the left arrow in a code pane of a OB windows, in a pharo image, I get an asser that fails:<br>
(oop & 1) 19202<br><br>Sorry I bother with these asserts, but I am trying to solve the crashes I have and I think starting for the asserts is a good idea.<br>
<br>The assert that fails is in primitiveClosureValue() the part:<br><br>blockClosure = longAt(GIV(stackPointer) + (GIV(argumentCount) * BytesPerWord));<br> /* begin quickFetchInteger:ofObject: */<br> oop = longAt((blockClosure + BaseHeaderSize) + (ClosureNumArgsIndex << ShiftForWord));<br>
assert((oop & 1));<br> numArgs = (oop >> 1);<br> if (!(GIV(argumentCount) == numArgs)) {<br> /* begin primitiveFail */<br> if (GIV(primFailCode) == 0) {<br> GIV(primFailCode) = 1;<br>
}<br> return;<br> } <br><br><br>numArgs results to be a large number (using #printNum: was 718613205), and if I try to do a #printOop: I got a " 0x55aa55aa0x55aa55aa is not on the heap" <br>
<br>Now, of course, the "if (!(GIV(argumentCount) == numArgs)) " fails.<br><br>What it is funny is that I did a #printOop: of blockClosure instVar, and this is what I get: 0x1f59b578: a(n) Association<br><br>Association? WTF ? so...I guess something weird is happening. I continue debugging it..and I noticed that:<br>
<br>- Several classes were called in addition to Association,like Character. These seems to be compact classes and implement #value and #value: ;)<br>- Both, #bytecodePrimValue and #bytecodePrimValueWithArg were not calling #primitiveClosureValue. So, "isBlock" was false...<br>
<br>I tried modifying #bytecodePrimValueWithArg and #bytecodePrimValue this line:<br><br>isBlock := objectMemory is: rcvr instanceOf: <span style="background-color:rgb(255, 255, 51)">ClassBlockClosure</span> compactClassIndex: ClassBlockClosureCompactIndex.<br>
<br>to this one:<br><br>isBlock := objectMemory is: rcvr instanceOf: <span style="background-color:rgb(255, 255, 51)">(self splObj: ClassBlockClosure)</span> compactClassIndex: ClassBlockClosureCompactIndex.<br><br>
WIth this change, at least, the assert doesn't fail anymore. I made progress (maybe). But still, for normal closures, "isBlock" seems to be false. So.....all block values are being managed as a normal send ????<br>
<br>Now, I don't understand why ClassBlockClosureCompactIndex is 0. I think this may be the problem. Why it is not 12? (in Pharo Smalltalk compactClassesArray at: 12 ->>> BlockClosure.)<br>I notice that ObjectMemory >> initializeCompactClassIndices does:<br>
<br> ClassBlockClosureCompactIndex := 0 "12". "Prospective. Currently TranslatedMethod class"<br><br><br>Notice that this ZERO changes the sematic of #is: oop instanceOf: classOop compactClassIndex: compactClassIndex<br>
called from the #bytecodePrimValue and bytecodePrimValueWithArg<br><br>Finally, I changed the mentioned line to this:<br><br>isBlock := objectMemory is: rcvr instanceOf:<span style="background-color:rgb(255, 255, 102)"> (self splObj: ClassBlockClosure) compactClassIndex: 12.</span><br>
<br>and finally, with block closures, it is calling the primitive, and for Association it doesn't fail the assert. ahh and the image doesn't crash ;)<br><br>I don't know if this is a bug, if my solution was ok, nor it impact. Please let me know.<br>
<br>Cheers<br><br>Mariano<br><br><br><br><br>
<br></blockquote></div><br></div>
<br></blockquote></div><br>
<br></blockquote></div><br>