<div dir="ltr"><div><br></div><div>Thank you for your notes Richard, it's really interesting to see not so well-known projects.<br></div><div>I would love to have more people sharing their wisdom and knocking down more myths.</div><div><br></div><div>Cheers,</div><div><br></div><div>Hernán</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El dom., 27 ene. 2019 a las 1:17, Richard O'Keefe via Glass (<<a href="mailto:glass@lists.gemtalksystems.com">glass@lists.gemtalksystems.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">I have my own Smalltalk system implemented as a batch compiler via C.</div><div class="gmail_default" style="font-family:monospace,monospace">This was originally just going to be a baseline for a student wanting</div><div class="gmail_default" style="font-family:monospace,monospace">to work on JIT, but he went elsewhere and I found the system surprisingly</div><div class="gmail_default" style="font-family:monospace,monospace">useful. I also wanted something that hewed closely to the ANSI Smalltalk</div><div class="gmail_default" style="font-family:monospace,monospace">standard, but could diverge in other matters (like not having dynamic code</div><div class="gmail_default" style="font-family:monospace,monospace">modification).</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace"><div style="font-family:Arial,Helvetica,sans-serif">- All Smalltalk bytecode sets are stack-based VM. (?)</div><div style="font-family:Arial,Helvetica,sans-serif"><br></div><div style="font-family:Arial,Helvetica,sans-serif">My system has no bytecodes. Smalltalk=>C=>native code.</div><div style="font-family:Arial,Helvetica,sans-serif"><br></div><span style="font-family:Arial,Helvetica,sans-serif">- Bytecodes are always fixed-size. (?)</span></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">False back in the Blue Book. Why does it matter anyway?</div><div class="gmail_default"><font face="monospace, monospace"><br></font><span style="font-family:Arial,Helvetica,sans-serif">- Most of the time spent by a VM is in the instruction interpreter. (actually it's in the GC right?)</span></div><div class="gmail_default"><br></div><div class="gmail_default">There is no interpreter in my system, and many modern systems use a JIT.</div><div class="gmail_default">That or they generate Javascript or JVM instructions or .NET or something,</div><div class="gmail_default">and then _that_ gets turned into native code.</div><div class="gmail_default"><br style="font-family:Arial,Helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">- You cannot serialize objects containing blocks. (IIRC one can use MessageSends)</span></div><div class="gmail_default"><br></div><div class="gmail_default">True in my system but that's because blocks contain pointers to native code and may</div><div class="gmail_default">contain pointers into the C stack. I have plans to work around this, but it has not been</div><div class="gmail_default">a priority. Something I don't ever plan to deal with is objects containing references to</div><div class="gmail_default">external objects (memory-mapped segments, file descriptors, sockets, ...) and it is not</div><div class="gmail_default">at all clear to me what the semantics should be.</div><div class="gmail_default"><br>BinaryObjectStorage in VisualWorks has no trouble with blocks.</div><div class="gmail_default"><br></div><div class="gmail_default">I meant to try this in Pharo 7.0. The image I just installed via the launcher has</div><div class="gmail_default">no DataStream, ReferenceStream, or SmartRefStream, but the class comment</div><div class="gmail_default">for MCDataStream begins</div><div class="gmail_default"><div class="gmail_default">"This is the save-to-disk facility.</div><div class="gmail_default"> A DataStream can store one or more objects in a persistent form.</div><div class="gmail_default"><br></div><div class="gmail_default"> To handle objects with sharing and cycles, you must use a ReferenceStream</div><div class="gmail_default"> instead of a DataStream. (Or SmartRefStream.) ReferenceStream is typically</div><div class="gmail_default"> faster and produces smaller files because it doesn't repeatedly write the same Symbols."<br></div><div class="gmail_default"><br></div><div class="gmail_default">This was also the case back to Pharo 2.0. What *is* the persistence scheme in Pharo these days?</div><div class="gmail_default"><br></div></div><div class="gmail_default"><span style="font-family:Arial,Helvetica,sans-serif">- Image cannot be bootstrapped. (This is possible in ST/X and now in Pharo I think).</span></div><div class="gmail_default"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div class="gmail_default"><span style="font-family:Arial,Helvetica,sans-serif">There are no images in my system.</span></div><div class="gmail_default"><br></div><div class="gmail_default"><div style="font-family:Arial,Helvetica,sans-serif">- All Smalltalks includes UI classes. (GemStone doesn't have AFAIK).</div><div style="font-family:Arial,Helvetica,sans-serif"><br></div><div style="font-family:Arial,Helvetica,sans-serif">It depends on what you mean by "include". Gnu Smalltalk *has* UI classes but they<br></div><div style="font-family:Arial,Helvetica,sans-serif">are not loaded by default.</div><div style="font-family:Arial,Helvetica,sans-serif"><br></div><div style="font-family:Arial,Helvetica,sans-serif">- All implementations uses direct pointers, (GST?)<br></div><div style="font-family:Arial,Helvetica,sans-serif"><br></div><div style="font-family:Arial,Helvetica,sans-serif">True in my case, but that's because I'm lazy and using the Boehm collector.</div><div style="font-family:Arial,Helvetica,sans-serif"><br></div><div style="font-family:Arial,Helvetica,sans-serif">- All implementations uses green threads. (VAST? MT?)<br></div><br class="gmail-m_-8583559370375361513m_-9196348779412515654gmail-Apple-interchange-newline"></div><div class="gmail_default">False in my case. A Process is a POSIX (red) thread and no green threads exist.</div><div class="gmail_default">This meant having to keep the interface fairly lean, but honestly wasn't that hard,</div><div class="gmail_default">since the Boehm collector handled the hard stuff.</div><div class="gmail_default"><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail-m_-8583559370375361513gmail-m_-9196348779412515654gmail_attr">On Tue, 22 Jan 2019 at 13:27, Hernán Morales Durand <<a href="mailto:hernan.morales@gmail.com" target="_blank">hernan.morales@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Done.</div><div><br></div><div>I have some possible myths, but I'd like to confirm or reject:<br></div><div><br></div><div>- All Smalltalk bytecode sets are stack-based VM. (?)</div>- Bytecodes are always fixed-size. (?)<br>- Most of the time spent by a VM is in the instruction interpreter. (actually it's in the GC right?)<br>- You cannot serialize objects containing blocks. (IIRC one can use MessageSends)<br>- Image cannot be bootstrapped. (This is possible in ST/X and now in Pharo I think).<br><div>- All Smalltalks includes UI classes. (GemStone doesn't have AFAIK).</div><div>- All implementations uses direct pointers, (GST?)<br></div><div>- All implementations uses green threads. (VAST? MT?)<br></div><div><br></div><div>I'm sure people in this list will have a lot more myths heard from Conferences, Forums, Videos, Talks, etc. Like the guy who said Smalltalk was dead. So if you did something which could be ignored publicly, please don't hesitate to reply or ping me to get added as collaborator.</div><div><br></div><div>Cheers,</div><div><br></div><div>Hernán<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail-m_-8583559370375361513gmail-m_-9196348779412515654gmail-m_-6688743472379916966gmail_attr">El dom., 20 ene. 2019 a las 22:41, Eliot Miranda (<<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Hernán,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail-m_-8583559370375361513gmail-m_-9196348779412515654gmail-m_-6688743472379916966gmail-m_8573492409851342107gmail_attr">On Sun, Jan 20, 2019 at 2:31 PM Hernán Morales Durand <<a href="mailto:hernan.morales@gmail.com" target="_blank">hernan.morales@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>Hi there,</div><div><br></div><div>I just created a GitHub repo to collect myths around Smalltalk-based technologies: Pharo, Squeak, VW, VAST, Smalltalk/X, GNU/ST, etc. in the spirit of the Falsehoods lists [1-4].</div><div><br></div><div>This is just a draft now but please feel free to add falsehoods based on your own experiences. Examples are greatly appreciated.</div></div></blockquote><div><br></div><div>You want pull requests? If not, would you give me write permission? I'd love to add to the "Smalltalk is obsolete" section...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div><a href="https://github.com/hernanmd/falsehoods_smalltalk" target="_blank">https://github.com/hernanmd/falsehoods_smalltalk</a></div><div><br></div><div>Cheers,</div><div><br></div><div>Hernán</div><div><br></div><div>[1] <a href="https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time" target="_blank">https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time</a><br><div>[2] <a href="https://chiselapp.com/user/ttmrichter/repository/gng/doc/trunk/output/falsehoods.html" target="_blank">https://chiselapp.com/user/ttmrichter/repository/gng/doc/trunk/output/falsehoods.html</a></div><div>[3] <a href="https://github.com/googlei18n/libphonenumber/blob/master/FALSEHOODS.md" target="_blank">https://github.com/googlei18n/libphonenumber/blob/master/FALSEHOODS.md</a><br></div><div>[4] <a href="https://meta-package-manager.readthedocs.io/en/develop/falsehoods.html" target="_blank">https://meta-package-manager.readthedocs.io/en/develop/falsehoods.html</a></div><div><br></div></div></div>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail-m_-8583559370375361513gmail-m_-9196348779412515654gmail-m_-6688743472379916966gmail-m_8573492409851342107gmail_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>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Glass mailing list<br>
<a href="mailto:Glass@lists.gemtalksystems.com" target="_blank">Glass@lists.gemtalksystems.com</a><br>
<a href="http://lists.gemtalksystems.com/mailman/listinfo/glass" rel="noreferrer" target="_blank">http://lists.gemtalksystems.com/mailman/listinfo/glass</a><br>
</blockquote></div>