<br><br><div class="gmail_quote">On Tue, Jul 8, 2008 at 12:08 AM, Klaus D. Witzel &lt;<a href="mailto:klaus.witzel@cobss.com">klaus.witzel@cobss.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Tue, 08 Jul 2008 07:19:45 +0200, Andreas Raab wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Craig Latta wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 &nbsp;&gt; ...do the bootstrap: Instantiate the first process, its first context,<br>
&nbsp;&gt; the first message. Run it in the simulator to set up the remaining<br>
&nbsp;&gt; parts of the kernel image (Delay, ProcessorScheduler etc).<br>
 &nbsp; &nbsp; &nbsp;I guess I found that last sentence easier said than done. :)<br>
</blockquote>
<br>
It doesn&#39;t strike me as particularly difficiult but then I haven&#39;t tried it yet. What problems were you running into?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 &nbsp; &nbsp; I don&#39;t even think the global lookup issue is all that hard. (I advocate having no system dictionary; keep each class literal in the name slot of the class itself, and have a means of traversing the class tree from a well-known starting point. Scanning through memory for the class and pool literals you want is straightforward.)<br>

</blockquote>
<br>
Actually, true *globals* (which for the bootstrap means only classes) are trivial to deal with: Since the skeleton is created first you have the oops for all the globals right there and then, so setting up a mapping that the compiler uses for these globals is utterly trivial. It&#39;s class and pool variables that are tricky<br>

</blockquote>
<br></div>
I suggest that vars are the same as in the &quot;blueprint&quot; classes (thank you Michael for mentioning that term elsewhere :) so, the methods can be compiled against ordinary classes which serve as blueprint.<br>
<br>
And globals can be in a single Sharedpool for the time of creating the image from first principles (see my patch to SharedPool&gt;&gt;#bindingOf:). Having said that, globals could alternately be treated as if they where class variables of Object blueprint. Both variants can avoid having a Smalltalk global dictionary.<div class="Ih2E3d">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
because even Dictionary&gt;&gt;at: may not exist in the image that you&#39;re trying to compile so doing the lookup directly in there would be quite tricky. It would be doable if one assumed a particular organization of the classes (i.e., the n-th iVar is the dictionary of class vars) and then interpreted it externally but it seems like an unnecessary complication for an initial bootstrap.<br>

</blockquote>
<br></div>
Even when doing the blueprint trick, what remains to be done is simulating additions to the method dictionary.</blockquote><div><br>In the image (not in the simulator) create proxy objects for the selectors in the simulator heap that answer the identity hashs of the objects in the simulator hash. &nbsp;Create a method dictionary in the image populated with the proxy objects. &nbsp;The order of the objects in the image method dictionary is the correct order for the method dictionary in the simulator.<br>
<br>In general if you want to perform a computation on objects in the simulator heap before you&#39;ve bootstrapped the code to perform the computation, create proxy objects in the image and run the computation on them. &nbsp;Right?<br>
<br><br></div></div>