Vm-dev April 2020

vm-dev@lists.squeakfoundation.org

28 participants
227 discussions

[OpenSmalltalk/opensmalltalk-vm] Simplify gitignore build directories [skip ci] (#351)
by Ben Coman 10 Sep '20

10 Sep '20

I noticed that modified Makefiles weren't being pickup up by `git status`. It was too tedious trying to fix the existing definitions, so I've condensed them down to 4 lines from 34. I'm reasonably sure the result is the same, but if I've missed something its low impact, so maybe just integrate first to let everyone suck-n-see. Doing a `git status` before each `git commit` will let you confirm that its working. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/351 -- Commit Summary -- * Simplify gitignore build directories -- File Changes -- M .gitignore (43) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/351.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/351.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/351

2 2

[OpenSmalltalk/opensmalltalk-vm] third-party: Stop building/using vulnerable software (#386)
by Holger Freyther 10 Sep '20

10 Sep '20

You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/386 -- Commit Summary -- * third-party: Stop building/using vulnerable software -- File Changes -- M third-party/libgit2.spec (10) M third-party/libpng.spec (6) M third-party/libssh2.spec (6) M third-party/openssl.spec (6) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/386.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/386.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/386

7 13

[OpenSmalltalk/opensmalltalk-vm] fix libgit2 makefile (#390)
by maenu 10 Sep '20

10 Sep '20

I am using MacPort's CMake which works fine, except that it needs a path argument for the libgit2 makefile. Can somebody check if this is compatible with their CMakes? You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/390 -- Commit Summary -- * fix libgit2 makefile -- File Changes -- M build.macos64x64/third-party/Makefile.libgit2 (2) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/390.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/390.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/390

2 2

[OpenSmalltalk/opensmalltalk-vm] primitives 54 and 554 for timesTwoPower: answer incorrect result on 64bits macOS VM (#383)
by Nicolas Cellier 20 Jul '20

20 Jul '20

This is due to a macOS bug in 64bits libm! (Hard to believe, isn't it?) I've opened a ticket https://bugreport.apple.com/web/?problemID=48021471 > Area: > Something not on this list > > Summary: ldexp incorrectly rounds gradual underflow for some specific values. > > Steps to Reproduce: > #include <math.h> > #include <stdio.h> > int main() { > int exp=-54; double y=ldexp(11.0,exp); /* y is binary 1.011*2^-51 */ > double u=ldexp(1.0,-1074); /* u is the minimal denormalized IEEE754 double */ > double v=ldexp(y,-1023); /* v is binary 1.011*2^-1074 and should round to u */ > printf("u=%g v=%g\n",u,v); > return 0; > } > > Expected Results: > v should be rounded to 1.0*2^-1074 (round to nearest, tie to even default rule) > Thus we should have u == v. > > Actual Results: > v is rounded upward to binary 10.0*2^-1074 = 1.0*2^-1073 > output is u=4.94066e-324 v=9.88131e-324 > > Note 1: this fails for 4 different values of exp -54,-53,+968,+969 > (replace exponent -1023 by -1074-3-exp, that is -1023,-1024,-2045,-2046) > Note 2: this did not happen previously with 32bits libm version. > Note 3: this sounds a bit like this bug https://stackoverflow.com/questions/32150888/should-ldexp-round-correctly > > Version/Build: > macOS HighSierra 10.13.16 > > Configuration: > compiled with > clang --version > Apple LLVM version 10.0.0 (clang-1000.11.45.5) > Target: x86_64-apple-darwin17.7.0 > Thread model: posix > InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > Xcode Version 10.1 (10B61) > > -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/383

5 6

Support an updated image format number for Sista
by David T. Lewis 20 Jul '20

20 Jul '20

Hi Eliot, This is a belated follow up on earlier private discussion during a Squeak board meeting a few months ago, in which we agreed that identifying "Sista in use" in the image format number would be a useful thing to do. I previously added the documentation for this in ImageFormat-dtl.39.mcz (as well as the updated ckformat.c program to match). Attached here is a change set that can be loaded into a VMMaker image to add VM support for setting and reading the updated image format numbers. Here I used a primitive to initially set or clear the "sista bit". There are other ways this could be done, but this at least gets us started with a working implementation. By way of explanation, I am copying below both the change set preamble and the earlier ImageFormat commit notice: === Change Set: VMM-Sista-bit-dtl Date: 12 January 2020 Author: David T. Lewis Let the image inform the interpreter that alternate bytecodes either are or are not in use, and remember that setting when writing or reading the image format number in a shapshot file header. Provide primitiveMultipleBytecodesActive to allow the setting to be updated from the image. Expected usage is that the image can call this primitive after recompiling with Systa bytecodes, or after reverting back. Note that an alternative implemenation would be to use a VM parameter. The primitive was chosen here because it can perform parameter checking and does not require coordinated update the the VM parameter usage. Expected usage is that this feature will remain unused for some grace period (perhaps a few months) during which an updated VM can be widely circulated. After that period, images using Sista bytecodes may be safely saved with the updated image format number indicating that multiple bytecodes are in use. This change set includes helper methods in SmalltalkImage for testing or setting the multipleBytecodeSetsActive setting in the VM. Note the change set postscript which is necessary for initializing a class variable prior to code generation. === Name: ImageFormat-dtl.37 Author: dtl Time: 20 July 2019, 5:23:59.004 pm UUID: 52b464d5-0bf7-4326-bde3-4f18ad70b239 Ancestors: ImageFormat-dtl.36 Identify extended bytecodes for Sista in the image format number. Bit 10 identifies an image that contains extended bytecodes. Thus a 32 bit Spur image is 6521, with Sista it is 7033, and a 64 bit Spur image is 68021, with Sista it is 68533. It is expected that additional bytecode sets can be identified by an additional field in the image header, probably 32 bits containing two 16 bit fields, if both zero then Sista. Per discussion with Eliot and Bert in a Squeak oversight board meeting 2019-05-15. Dave

4 10

[OpenSmalltalk/opensmalltalk-vm] OpenSSL 1.0.2 end of support from 1 Jan 2020 (#455)
by Pierce Ng 22 Jun '20

22 Jun '20

As per https://www.openssl.org/policies/releasestrat.html. My fork has an [update3p branch](https://github.com/PierceNg/opensmalltalk-vm/tree/pierce_update3p) that builds with OpenSSL 1.1.1d and also related minor fixes for one or some of the Pharo mvm. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/455

3 7

64 bit FFI (was: porting Croquet to Squeak6.0 alpha...)
by Bert Freudenberg 09 Jun '20

09 Jun '20

I'd suggest to get OpenGL working outside of Croquet first: http://www.squeaksource.com/CroquetGL.html Step 1: Verify this works in 32 bits. (assuming you are doing this on Linux, you can run 32 bit Squeak side-by-side with the 64 bit one) Step 2: Make it work in 64 bits. The second step requires that you understand how FFI works, and how it handles e.g. pointers and integer sizes. I am assuming we do have a working 64 bit FFI, at least for x86_64 machines. E.g. the OGLUnix>>glExtGetProcAddress: method returns a pointer. On a 32 bit system, that fits into a 'ulong' which is 32 bits. On a 64 bit system, a pointer is 64 bits wide so it would not fit into a 32 bit word. Now I don't know how many bits 'ulong' has in our 64 bit FFI, but that declaration may have to change. Etc. pp. If you have questions about FFI then those are best directed at the vm-dev list since it is dealing with VM-level interfaces. CC'ing, please follow up there. - Bert - On Wed, Mar 11, 2020 at 2:54 PM gettimothy via Squeak-dev < squeak-dev(a)lists.squeakfoundation.org> wrote: > Okey dokey, > > Poking along, there is a stray glyph in OGLUnix openGLLibraryName after > > openGLLibraryName > ^Smalltalk osVersion = 'linux' > ifTrue: ['libGL.so.1'] > ifFalse: ['GL'] > > I removed it in my install and got past that error. > > Working exclusively with Croquet(Master)... > > > > My next error is in OGLUnixX11LE(OpenGL)>>glMatrixMode: > > glMatrixMode: mode > "This method was automatically generated." > "void glMatrixMode(GLenum mode);" > <apicall: void 'glMatrixMode' (ulong) module: '#openGLLibraryName'> > ^self externalCallFailed > > The <apicall:...> fails > > How to think about this? > > Is Croquet behind OpenGL latest? > Would teaching myself OpenGL programming be of use to the Croquet project? > > cheers, > > tty > > >

7 13

[OpenSmalltalk/opensmalltalk-vm] POWER (ppc64le) port. (#493)
by kgardas 03 Jun '20

03 Jun '20

It would be great if there is also ppc64le/power platform supported. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/493

9 27

Re: [Vm-dev] [Pharo-dev] Pony for Pharo VM
by Shaping 13 May '20

13 May '20

Just to get in the right frame of mind, consider that because of the Blub Paradox (http://www.paulgraham.com/avg.html) you are going to have a hard time convincing people to "change to this language because of Feature X" just by saying so. You need to dig deeper. The Pony compiler and runtime need to be studied. I’m not trying to convince; I’m presenting facts, observations, and resources for study of the problem and its solution. Hardware constraints now are intensely multicore, and everyone knows this. The changing programming paradigm in apparent. Hardware structure is forcing that change. Convincing yourself will not be difficult when you have the facts. You likely do already, at least on the problem-side. The issue is not whether to use Pony. I don’t like Pony, the language; it’s okay, even very good, but it’s not Smalltalk. I like Smalltalk, who concurrency model is painfully lame. I like Orca because it works on many cores (as many as 64, currently) without a synchronization step for GC, and has wonderful concurrency abilities. Pony and Orca were co-designed. The deferred reference counts managed by Orca run on the messages between the actors (send/receive tracing). GCs happen in Pony/Orca when each actor finishes its response to the last received message, and goes idle. The actor then GCs all objects no longer referenced by other actors. The runtime scheduler takes this time needed for each actor’s GCing into account. No actor waits to GC objects. An actor’s allocated objects’ ref counts are checked at idle-time, and unreferenced objects are GCed in an ongoing, fluid way, in small, high-frequency bursts, with very small, predictable tail latencies, as a result. That’s very interesting if you need smoothly running apps (graphics), design/program real-time control systems, or process data at high rates, as in financial applications at banks and exchanges. The issue is how most efficiently to use Orca, which happens to be working in Pony. Pony is in production in two internal, speed-demanding, banking apps and in Wallaroo Labs’ high-rate streaming product. Pony is a convenient way to study and use a working implementation of Orca. Ergo, use Pony, even if we only study it as a good example of how to use Orca. Some tweaks (probably a lot of them) could allow use of dynamic types. We could roll our own implementation of Orca for the current Pharo VM, but that seems like more work than tweaking a working Pony compiler and runtime. I’m not sure about that. You know the VM better than I. (I was beginning my study of the Pharo/OpenSmalltalkVM when I found Pony.) Now I I took a quick look to see what I could learn about Pony and the main interesting thing is its "Reference Capabilities". Indeed, it seems Pony's purpose is the POC for that research. I watched two videos... [1] Øredev 2017 - Joe McIlvain - Pony - A Language for Provably Safe Lockless Concurrency https://www.youtube.com/watch?v=9NH4bVfbvYI [2] Sophia Drossopoulou - Pony for Safe, Fast, concurrent programs - Codemesh 2017 https://www.youtube.com/watch?v=e_bES30tFqI So my "quick" assessment is to consider Reference Capabilities not a Type System but a Meta-type System. Yes, ref-caps control sharing of both mutable and immutable objects. [2] says "They are not a property of an object, but define how I can look at an object." To summarize the videos... [1]@29:15... [2]@13:40... [2]@24:40... [2]@28:30... So you say... > I want to use the Pony concurrency model at the Smalltalk level. That’s the gist of it. > Otherwise, I want a Smalltalk, not a statically compiled language. I believe you have the wrong end of the the stick promoting that the VM needs to be redeveloped using Pony to get the Reference Capabilities at the Smalltalk level. See my recent response to Ken in vm-dev. After you Ahead-Of-Time compile the VM, the compiler is left behind. The features of the compiler don't automatically flow through to Smalltalk level. Yes. JIT and AOT are needed. Adjustments need to be made for dynamic typing, but such adjustments need not violate invariants needed to provide the ref-cap concurrency guarantees. A third option could be to extend to the existing "Immutability capability" of the VM. Ref-caps control access to both immutable and mutable objects. Pony ascertains at compile time that only one actor at a time can hold a reference to a mutable object at runtime. The six Reference Capabilities might be stored in the Spur Object Header using a re-purposed Immutability bit plus the two free "green" bits. https://clementbera.wordpress.com/2014/01/16/spurs-new-object-format/ We can’t use a single big system heap, and also use the actor model and many cores productively. The big heap must go. That’s the crux of what we need to learn at this juncture. I’m not sure everyone is getting this. I don’t need to convince you; you can do that for yourself. We don’t currently have a better choice of programming model or memory management, if we want maximum speed, and are paying attention to hard constraints. Multicore hardware is here to stay. If you know a way to use your multicore CPUs more efficiently than by use of actor-based programming and Orca memory management, please share your facts. Everyone needs to understand the big-heap problem in order to commit to fine-grain, actor-based (and therefore state-machine-based) programming. We won’t realize productive multicore programming without an actor model. We still need new tools to help, as mentioned, lest our state-machine programming be tedious and painful, causing us to default to old coding habits, and not make the needed state-machines. I’m working on one of those tools. Orca manages memory as fast as possible in an actor-based program/runtime, without any synchronization. The big-heap problem has been solved for the statically typed case in Pony. The lack of discipline/tools for building state-machines remains a broad problem. Such new tools are therefore essential during the change of programming model. I suggest studying the current Pony/Orca solution (see the Orca paper linked below), to see how it can be tweaked to accommodate dynamic types. I’ve not studied the Pony compiler and runtime enough to be certain, but they may be closer to what we need, even if the first rough implementation of a Smalltalk-with-Orca must be AOT, instead of JIT. We want both ultimately. We should do first whichever is easiest to implement and test in small steps. "Reference Capabilities for Dynamic Languages" could be a strong PhD project. It’s a good idea. Is this needed to make a Smalltalk that works with Orca? I don’t think so. Orca matters more than Pony. But both can be useful to us. Studying the Orca paper and its implementation in the Pony compiler and runtime is the easiest way to understand the constraints imposed by the current static type system in Pony—and how to change them to accommodate dynamic types. Everyone, please read and study https://www.ponylang.io/media/papers/orca_gc_and_type_system_co-design_for_… if you are interested in building a VM/runtime that guarantees no data-races, and fully uses all your machine’s cores, with the least programming effort. Then study Pony: https://www.ponylang.io/ And ask questions on Pony Zulip: https://ponylang.zulipchat.com/ (BTW, Zulip seems easier to use than Discord and e-mail. Has anyone considered using it for the Pharo/Squeak lists?) Shaping On Fri, 10 Apr 2020 at 17:56, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: > > Hi Ken. > > Not to discourage people, but I have not seen cases where a "strong > type system would be able to scale for _real_ Smalltalk applications. > > You’re right. It doesn't. I'm not suggesting that. > > The type safety is not for app-level Smalltalk development. It's for building the VM only. > > The six ref-cap ideas for sharing data reliably between actors are not hard to grasp, but they take some getting used to, and involve some mental load. I don't want that much (concurrency-related or any other) implementation detail in the domain layer, much in the same vein as: I don’t use Forth because I don’t want to see stack acrobatics (ROTs and DUPs, etc.) amidst domain-level state-changes (FirePhotonTorpedo). It’s distracting. It dilutes focus on the domain work/layer, and tends to cause mistakes there. > > > > The programmer’s domain logic and the concurrency-integrity provided by the ref-caps are different layers of thought and structure. The ref-caps are, however, mixed freely with domain logic in current Pony code. I think that’s a mistake. But that’s how it is now. I think of this layer mixing as an intermediate design stage of Pony. I want to abstract-out some or all ref-caps as the VM is built. > > Pony language is not the remarkable thing here. I see it as a better C or better Rust. It’s very good (as Algol-60-ish-looking crap-syntaxes go), but that’s not what this is about. It’s about the actor programming, the concurrency model, and the guarantees given by use of the ref-caps. We would still obviously need to respect the Pony compiler’s determination of where ref-cap use is correct or not. Your Pony program won’t compile if you don’t use the ref-caps correctly, and you don’t get the guarantees or a running program without the compile. Much easier, therefore, might be to go the other way by changing Pony to support dynamic types without violating the invariants that allow the ref-caps (under the hood, abstracted out) to make the concurrency guarantees. Work Smalltalk dynamism into Pony, instead of building a Smalltalk VM with Pony.

2 10

[OpenSmalltalk/opensmalltalk-vm] No sound on Linux (#489)
by contrapunctus-1 09 May '20

09 May '20

Apologies if this should have been a part of #360. Running e.g. `AbstractSound bachFugue play` resulted in no sound. Other sound-playing applications on the system were working fine. The VM said `sound: /dev/dsp: No such file or directory` `--help` mentioned the following - ``` vm-sound-ALSA tryLoading cogspur/lib/squeak/5.0-202003021730/vm-sound-ALSA.so: dlopen: cogspur/lib/squeak/5.0-202003021730/vm-sound-ALSA.so: undefined symbol: snd_mixer_selem_is_active vm-sound-ALSA tryLoading /home/anon/git/Cuis-Smalltalk/cogspur/lib/squeak/5.0-202003021730/vm-sound-ALSA.so: dlopen: /home/anon/git/Cuis-Smalltalk/cogspur/lib/squeak/5.0-202003021730/vm-sound-ALSA.so: undefined symbol: snd_mixer_selem_is_active ``` Running with -vm-sound-pulse gave no errors but I still got no sound. OS - `Linux 5.5.0-1-686 #1 SMP Debian 5.5.13-2 (2020-03-30) i686 GNU/Linux` ``` $ cogspur/squeak --version 5.0-202003021730 Tue Mar 3 08:28:29 UTC 2020 gcc 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-nice.2712 uuid: da64ef0b-fb0a-4770-ac16-f9b448234615 Mar 3 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020 VM: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Mar 2 18:30:55 2020 CommitHash: 6a0bc96 Plugins: 202003021730 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Linux travis-job-56ef6ed6-a99c-4420-b3aa-37bf991d063a 4.15.0-1028-gcp #29~16.04.1-Ubuntu SMP Tue Feb 12 16:31:10 UTC 2019 i686 i686 i686 GNU/Linux plugin path: cogspur/lib/squeak/5.0-202003021730 [default: /home/anon/git/Cuis-Smalltalk/cogspur/lib/squeak/5.0-202003021730/] ``` Cuis5.0-4112-32.image -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/489

8 12

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev April 2020