<div dir="ltr">Hi Tty,<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 6, 2013 at 4:15 PM, gettimothy <span dir="ltr"><<a href="mailto:gettimothy@zoho.com" target="_blank">gettimothy@zoho.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <br><u></u><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif">
Please verify my assumption--I am starting to see the trees for the forest and don't want to waste time due to an incorrect assumption.<br><br>Per my reading on <a href="http://comp.lang.smalltalk.narkive.com/LZRWMe2V/the-history-of-vw-pragmas" target="_blank">pragmas</a> please verify that these:<br>
<blockquote style="border:1px solid rgb(204,204,204);padding:7px;background-color:rgb(245,245,245)"><div>StackInterpreterSimulatorLSB(StackInterpreter)>>mapStackPages<br> <inline: false><br> <var: #thePage type: #'StackPage *'><br>
<var: #theSP type: #'char *'><br> <var: #theFP type: #'char *'><br> <var: #callerFP type: #'char *'><br> <var: #theIPPtr type: #'char *'><br> 0 to: numStackPages - 1 do: <br>
</div></blockquote><br>are intended for whatever generates the C source code </div></div></blockquote><div><br></div><div>Yes, the var:type: pragmas decorate the generated C with the relevant type declarations. See also the various declareCVarsIn: which type inst vars etc. But the <inline: false> pragma tells the Slang C code generator not to inline mapStackPages into senders as it produces C. So for example, a <inline: true> pragma does /not/ cause the generated C function to be marked as __inline__.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif">
and that the assertion fail I am getting later in the method is in no way related to the updates Eliot has been recently making to<br><br><br><blockquote style="border:1px solid rgb(204,204,204);padding:7px;background-color:rgb(245,245,245)">
<div><br>Revision: 2820 <br>Author: eliot <br>Date: 2013-12-06 14:44:48 -0800 (Fri, 06 Dec 2013) <br>Log Message: <br>----------- <br>CogVM source as per VMMaker.oscog-eem.545. <br></div></blockquote><br></div></div>
</blockquote><div><br></div><div>That's hard to tell. I broke something serious sometime before VMMaker.oscog-eem.536/r2820 that caused the classic VMs to crash on start-up or soon there-after. It's fixed in r2820, but there may be other problems there-in. I can't prove a negate :-). But yes, hopefuly the assert failure should be unrelated. Are you sing the simulator successfully?</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif">
Thanks.<br><br>tty.<br><br>p.s. I am really enjoying this puzzle! <br>For an update, I have finished my overview of the Blue Book and am now taking notes in Tim Rowledge's Object Engine pdf.<br>Once that is done, I will be studying the StackInterpreter documentation and can hopefully start contributing soon.<br>
</div></div></blockquote><div><br></div><div>Good to hear. Enjoy!</div><div><br></div></div>-- <br>best,<div>Eliot</div>
</div></div>