<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 25, 2016 at 12:25 PM, Bert Freudenberg <span dir="ltr">&lt;<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">No, it&#39;s a only problem in the specific image I was using, not in the actual release image:<div><br></div><div>0 class</div><div>==&gt; SmallInteger</div><div><br></div><div>1 class</div><div>==&gt; nil</div><div><br></div><div>All odd SmallInts answer nil when asked for their class ... I&#39;ll show this to Eliot later (we&#39;re all in Prague for ESUG right now).</div></div></blockquote><div><br></div><div>Yep, Eliot recognized the issue immediately. In Spur, all classes are held in a table indexed by the class&#39;s identity hash. SqueakJS doesn&#39;t need that table (it uses direct class pointers) so it generates it when storing the image. This worked fine, except that the SmallInteger class needs to be put in two slots of the class table: 1 (which is its hash) and 3. I fixed this in SqueakJS now so all is good.</div><div><br></div><div>This has to do with the special class lookup for immediate objects. For them, Spur simply masks the tag bits, and uses the value as index into the class table. In 32 bits we have two tag bits, but both 2r01 and 2r11 are used for SmallIntegers. Character uses 2r10, which is why Character&#39;s hash has to be 2. All regular objects use tag bits 2r00.</div><div><br></div><div>- Bert -</div></div></div></div>