<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Philip,</div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 12, 2019 at 1:56 PM Philip Bernhart <<a href="mailto:philip.bernhart@posteo.de">philip.bernhart@posteo.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I have a bunch of "beginner"(?) questions:<br>
<br>
1. How to ensure that my local "stable" build from "stable"<br>
sources corresponds to the "stable" vm binary published<br>
on <a href="http://squeak.org" rel="noreferrer" target="_blank">squeak.org</a>? For example some time ago I build from the<br>
stable tag 201807260206 (= commit<br>
d1f3fb1c76ad72155d3becc8f9bed7d70e9485a9) which resulted in a<br>
VM which somehow had some weird and hard to understand issues<br>
with numbers corresponding in blaming the running smalltalk<br>
implementation in my case cuis:<br>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/145" rel="noreferrer" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/145</a></blockquote><div><br></div><div>Derive the version info from the VM via -version (Squeak) or --version (Pharo). This should give you something like:</div><div><br></div><div><div>5.0 64 bit Mac OS X built on Oct 20 2018 08:16:09 UTC Compiler: 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur 64-bit VM]</div><div>CoInterpreter VMMaker.oscog-eem.2461 uuid: b3cd33f5-6309-43a1-b669-7a1805111f34 Oct 20 2018</div><div>StackToRegisterMappingCogit VMMaker.oscog-eem.2464 uuid: 0b1fa0a3-a781-4fd5-b1cf-1809796ccbbf Oct 20 2018</div><div>VM: 201810190412 <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm.git">https://github.com/OpenSmalltalk/opensmalltalk-vm.git</a></div><div>Date: Thu Oct 18 21:12:21 2018 CommitHash: 15341b5</div><div>Plugins: 201810190412 <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm.git">https://github.com/OpenSmalltalk/opensmalltalk-vm.git</a></div></div><div><br></div><div>then in your clone of opensmalltalk-vm checkout the commit (CommitHash field above):</div><div><br></div><div><div><font face="monospace, monospace">Aeolus.oscogvm.reference$ git checkout 15341b5</font></div><div><font face="monospace, monospace">Note: checking out '15341b5'.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">You are in 'detached HEAD' state. You can look around, make experimental</font></div><div><font face="monospace, monospace">changes and commit them, and you can discard any commits you make in this</font></div><div><font face="monospace, monospace">state without impacting any branches by performing another checkout.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">If you want to create a new branch to retain commits you create, you may</font></div><div><font face="monospace, monospace">do so (now or later) by using -b with the checkout command again. Example:</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace"> git checkout -b <new-branch-name></font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">HEAD is now at 15341b5... CogVm source as per VMMaker.oscog-eem.2464</font></div></div><div><br></div><div>then make sure your development tools match the Compiler version info (first line in the version info above) and build.</div><div><br></div><div>You can then return to the tip via $ git pull origin Cog</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">2. How to build the VM for a platform which has the dietlibc or a<br>
different implementation of the standard C library?<br>
I once tried to build it on alpine linux so to get<br>
a minimal and small baseimage of it running to be able to use<br>
it in within Docker containers without waiting 30 minutes for<br>
the build, because of added sizes and complexities when relying<br>
on a more "standard" base linux system (*cough* ubuntu *cough*).<br></blockquote><div><br></div><div>I don't understand what its special about the libc. What are the issues here? The convention we use is to create a build directory for the particular host (e.g. build.macos64x64 is Mac OS X, 64-bit using x86_64), and populate it with build directories for the dialects and configurations you want (e.g. pharo.cog.spur, squeak.stack.spur). So if you want to add a configuration it should be easy to </div><div>- copy a directory tree from the most similar platform</div><div>- submit your build tree via a pull request</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">3. What is now the supposed "best practice" of adding functionality<br>
to squeak? Say I want to add to it support for password hashing<br>
using libsodium and the library blocks the VM when trying<br>
to do more elaborate calls, so an async call would be much less<br>
of a pain from the user perspective. So async calling in a<br>
FFI library of that code or moving that into a VM plugin so<br>
it's much wider supported?<br></blockquote><div><br></div><div>Ah. Now that is a long topic. How much time do you have before you urgently need a solution? The right way is to use the ThreadedFFI but this is still in prototype form. It is something I will put energy into this year but the solution won't be ready for months, and that's being optimistic. And we really need to gather a team together around the threaded FFI to share the effort and maintain energy and focus.</div><div><br></div><div>A "quick hack" is exemplified by the style used in the Windows SocketPlugin support; see platforms/win32/plugins/SocketPlugin/sqWin32NewNet.c. The support code manages a set of hidden threads to do lookups and there is a pair pf primitives, one to submit a non-blocking lookup request, and another to reap the request. See e.g.</div><div><br></div><div>NetNameResolver class>>#primStartLookupOfName:<br></div><div>NetNameResolver class>>#primAddressLookupResult<br></div><div>NetNameResolver class>>#primAbortLookup<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">4. How to specialized VMs for special use cases? Like for example<br>
I would want to build the VM for some architectures where there<br>
is no binary around and which don't like or support any JIT<br>
implementation. How do I correctly select the VM, configure and<br>
build it and also can ensure that it works?<br></blockquote><div><br></div><div>Look at the <dialect>.stack.<memorymanager> builds, for example build.linux64ARMv8/squeak.stack.spur builds a StackInterpreter, which has no JIT, for 64-bit Linux on ARMv8. We don't yet have a JIT back end of 64-bit ARM.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">That's probably already too much to be answered in one mail.<br></blockquote><div><br></div><div>Cheers, and welcome!</div><div><br></div></div><div dir="ltr" class="gmail_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></div></div></div></div></div></div></div>