Hi,
I have a bunch of "beginner"(?) questions: 1. How to ensure that my local "stable" build from "stable" sources corresponds to the "stable" vm binary published on squeak.org? For example some time ago I build from the stable tag 201807260206 (= commit d1f3fb1c76ad72155d3becc8f9bed7d70e9485a9) which resulted in a VM which somehow had some weird and hard to understand issues with numbers corresponding in blaming the running smalltalk implementation in my case cuis: https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/issues/145 2. How to build the VM for a platform which has the dietlibc or a different implementation of the standard C library? I once tried to build it on alpine linux so to get a minimal and small baseimage of it running to be able to use it in within Docker containers without waiting 30 minutes for the build, because of added sizes and complexities when relying on a more "standard" base linux system (*cough* ubuntu *cough*). 3. What is now the supposed "best practice" of adding functionality to squeak? Say I want to add to it support for password hashing using libsodium and the library blocks the VM when trying to do more elaborate calls, so an async call would be much less of a pain from the user perspective. So async calling in a FFI library of that code or moving that into a VM plugin so it's much wider supported? 4. How to specialized VMs for special use cases? Like for example I would want to build the VM for some architectures where there is no binary around and which don't like or support any JIT implementation. How do I correctly select the VM, configure and build it and also can ensure that it works? That's probably already too much to be answered in one mail. Thanks, Philip _______________________________________________ VM-beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners |
Hi Philip, On Sat, Jan 12, 2019 at 1:56 PM Philip Bernhart <[hidden email]> wrote: Hi, Derive the version info from the VM via -version (Squeak) or --version (Pharo). This should give you something like: 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] CoInterpreter VMMaker.oscog-eem.2461 uuid: b3cd33f5-6309-43a1-b669-7a1805111f34 Oct 20 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2464 uuid: 0b1fa0a3-a781-4fd5-b1cf-1809796ccbbf Oct 20 2018 VM: 201810190412 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Oct 18 21:12:21 2018 CommitHash: 15341b5 Plugins: 201810190412 https://github.com/OpenSmalltalk/opensmalltalk-vm.git then in your clone of opensmalltalk-vm checkout the commit (CommitHash field above): Aeolus.oscogvm.reference$ git checkout 15341b5 Note: checking out '15341b5'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at 15341b5... CogVm source as per VMMaker.oscog-eem.2464 then make sure your development tools match the Compiler version info (first line in the version info above) and build. You can then return to the tip via $ git pull origin Cog 2. How to build the VM for a platform which has the dietlibc or a 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 - copy a directory tree from the most similar platform - submit your build tree via a pull request 3. What is now the supposed "best practice" of adding functionality 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. 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. NetNameResolver class>>#primStartLookupOfName: NetNameResolver class>>#primAddressLookupResult NetNameResolver class>>#primAbortLookup 4. How to specialized VMs for special use cases? Like for example 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. That's probably already too much to be answered in one mail. Cheers, and welcome! _,,,^..^,,,_ best, Eliot _______________________________________________ VM-beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners |
Hi Eliot,
Eliot Miranda <[hidden email]> writes: > 3. What is now the supposed "best practice" of adding functionality >> to squeak? Say I want to add to it support for password hashing >> using libsodium and the library blocks the VM when trying >> to do more elaborate calls, so an async call would be much less >> of a pain from the user perspective. So async calling in a >> FFI library of that code or moving that into a VM plugin so >> it's much wider supported? >> > > 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. > > 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. > > NetNameResolver class>>#primStartLookupOfName: > NetNameResolver class>>#primAddressLookupResult > NetNameResolver class>>#primAbortLookup That's what I implemented doing threads on the C end. But I'm still waiting for ThreadedFFI. What is the current status? Some mouthwatering insights? Or the answert to the all encompassing question of "is it worth it?". Cheers, Philip _______________________________________________ VM-beginners mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/vm-beginners |
Free forum by Nabble | Edit this page |