Vm-dev April 2019

vm-dev@lists.squeakfoundation.org

23 participants
69 discussions

Separating launcher from VM binaries
by K K Subbu 18 Apr '19

18 Apr '19

Hi, In working with Squeak images of different formats and word sizes, I find myself struggling with a bunch of scripts - run, squeak, squeak64, cog, cog64, spur, spur64 etc and having to update the run script whenever a new format comes out. There should be simpler way ..... It would be nice to separate the main programs - launcher(squeak) and ckformat - from the VMs that read specific image formats. VMs could be generated with base format built into the name or path e.g. lib/$VER/$BASE/ostvm or lib/$BASE/$VER/ostvm The main launcher (squeak) will probe and launch a matching VM with something like: lib/$VER/$(ckformat $IMAGE)/$VMNAME $ARG without having to find out the exact format number. This will enable multiple format VMs to co-exist in a machine without having to change PATH settings etc. Regards .. Subbu

3 2

[OpenSmalltalk/opensmalltalk-vm] 12babd: Enrich plugin/app bundle creation on MacOS, allowi...
by Eliot Miranda 18 Apr '19

18 Apr '19

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 12babd0ff7629cda4d19ed9ed03723fae8f7a667 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/12babd0ff7629cda4d… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2019-04-17 (Wed, 17 Apr 2019) Changed paths: M build.macos32x86/common/Makefile.app M build.macos32x86/common/Makefile.plugin M build.macos64x64/common/Makefile.app M build.macos64x64/common/Makefile.plugin Log Message: ----------- Enrich plugin/app bundle creation on MacOS, allowing plugins to specify support dylibs which end up in the Foo.app/Contents/Frameworks directory. [ci skip] Plugin makefiles (e.g. platforms/iOS/plugins/FooPlugin/Makefile) optionally define a set of support dylibs via defining a DYLIBS variable. The makefiles do the rest. Remember to remove any .cstemp directories before signing to avoid codesign getting stuck.

1 0

tracking WebAssembly
by Ben Coman 14 Apr '19

14 Apr '19

Found some recent WebAssembly articles that may impact issues previously raised as impediments to Smalltalk-on-WebAssembly. Do these indicate anything useful for the possibility of running Squeak/Pharo on WebAssembly... Calls between JavaScript and WebAssembly are finally fast https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-… WebAssembly architecture for Go https://docs.google.com/document/d/131vjr4DH6JFnb-blm_uRdaC0_Nv3OUwjEY5qVCx… >From WebAssembly Illustrated... https://takenobu-hs.github.io/downloads/WebAssembly_illustrated.pdf * Slide 16 - If Slang could directly output WebAssembly bytecode, I presume the Interpreter lookup table could be modeled as a "call_indirect #n" of functions compiled to a WebAssembly "Table" * Slide 39-40 - I wonder if the Host environment being able to mutate the Table means by default a newly downloaded Smalltalk program would be running as an Interpreter, but you could a browser plugin for the JIT that updated Table for JIT'd methods. * Slides 48-51 - Alternatively, I wonder if a "form" of JITing could be dynamically creating a WebAssembly bytecode module that is then immediately loaded and the function called, and a new module loaded for each new JIT output. "Platform-independent JIT" is mentioned at https://webassembly.org/docs/future-features/ WebAssembly GC proposal including a tagging scheme for unboxed small scalars https://github.com/WebAssembly/gc/blob/master/proposals/gc/Overview.md Garbage Collection (proposal) https://github.com/WebAssembly/gc cheers -ben

4 7

VM Loaded?
by Ron Teitelbaum 13 Apr '19

13 Apr '19

Hi All, When processing the command line I ran into an interesting problem. When running normally everything processes fine but if I'm also running Immunet which is scanning the VM for viruses as it starts up a quick command line can run into something that is not properly loaded and crash. If I shut down the virus protection it runs fine, if I start the application first and then process the command line it runs fine. Is there something I can check in the image to know that the image is fully loaded before processing the command line arguments? Thanks! All the best, Ron Teitelbaum

2 3

[OpenSmalltalk/opensmalltalk-vm] GIT_DIR environment variable is no longer set in git hooks (#389)
by Nicolas Cellier 12 Apr '19

12 Apr '19

With git 2.19 and later I have an error when discarding changes on a modified file (checkout). The error occurs while executing the .git/hooks/post-checkout and it says: > cp: '.git/hooks/post-checkout' and '.git/hooks/post-checkout' are the same file The problem is that GIT_DIR env var is no more set... Thus this codes erroneously think that we are not ran as hook: is_run_as_hook() { test -n "$GIT_DIR" } It seems that the GIT_DIR change was un-intentional, but the fact that GIT_DIR was set also was un-intentional... See https://public-inbox.org/git/20180826004150.GA31168@sigill.intra.peff.net/t/ We now must find a way to recognize whether we are ran from a hook or not... I have asked on SO if ever it can help https://stackoverflow.com/questions/55627720/how-to-recognize-if-git-hook-s… -- 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/389

1 1

[OpenSmalltalk/opensmalltalk-vm] Initial port of the B3DAccelerator plugin, plus extra Metal and rendering clean up (#382)
by Ronie Salgado 12 Apr '19

12 Apr '19

This is the branch with the port of the B3DAccelerator plugin to Metal. Most the examples in Balloon3D are working with this new plugin, after forcing it by modifying: B3DSceneMorph >> accelerationEnabled "Return true if hardware acceleration is enabled" "self accelerationSuspended ifTrue:[^false]. ^self valueOfProperty: #accelerationEnabled ifAbsent:[false]" ^ true Shaders are now compiled in runtime, from source code which is embedded in a C-string. In addition to these changes, in the last commit I did some refactoring of the Metal VM code. I am copying the message of that commit: - I introduced a hack to select the type of rendering view in runtime. - I am compiling by again the old core graphics based renderer, but this is only used when the -core-graphics option is passed in the command line. - I added dummy headless view, that does not render and stubs most of the event. - I added the -metal, -opengl, and -core-graphics command line options for selecting the rendering backend. - I am testing the Metal implementation by compiling the shader library. If the shader library compilation fails, then Metal will not be used, and instead OpenGL will be used as a fallback, by default. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/382 -- Commit Summary -- * I am starting to reimplement the B3DAcceleratorPlugin using Metal. So far I managed to get a black screen by using the extra layers mechanism, * Creating the depth-stencil buffer, and clearing the screen. * I am starting to render a bit. * I am starting to implement the lighting model in the metal based B3DAcceleratorPlugin. * Add a -1 offset to the B3D indices going to Metal. * Merge branch 'Cog' into feature/metal_b3d * I implemented the Squeak3D lighting model above metal. * Merge branch 'Cog' into feature/metal_b3d * Merge branch 'Cog' into feature/metal_b3d * I introduced a hack to select the type of rendering view in runtime. -- File Changes -- M .clang_complete (3) M build.macos32x86/common/Makefile.app (4) M build.macos32x86/common/Makefile.flags (2) M build.macos64x64/common/Makefile.flags (2) M build.macos64x64/common/Makefile.vm (2) M platforms/Cross/plugins/B3DAcceleratorPlugin/B3DAcceleratorPlugin.h (90) A platforms/iOS/plugins/B3DAcceleratorPlugin/B3DMetalShaders.metal (230) M platforms/iOS/plugins/B3DAcceleratorPlugin/Makefile (12) M platforms/iOS/plugins/B3DAcceleratorPlugin/sqMacOpenGL.m (5) A platforms/iOS/plugins/B3DAcceleratorPlugin/sqMetalRenderer.h (131) A platforms/iOS/plugins/B3DAcceleratorPlugin/sqMetalRenderer.m (1179) A platforms/iOS/plugins/B3DAcceleratorPlugin/sqMetalStructures.h (121) M platforms/iOS/vm/Common/main.m (22) M platforms/iOS/vm/English.lproj/MainMenu.xib (6) M platforms/iOS/vm/OSX/SqViewBitmapConversion.m (263) A platforms/iOS/vm/OSX/SqViewBitmapConversion.m.inc (271) M platforms/iOS/vm/OSX/SqViewClut.m (115) A platforms/iOS/vm/OSX/SqViewClut.m.inc (91) M platforms/iOS/vm/OSX/SqueakMainShaders.metal (32) D platforms/iOS/vm/OSX/SqueakMainShaders.metal.inc (822) M platforms/iOS/vm/OSX/SqueakOSXAppDelegate.m (12) M platforms/iOS/vm/OSX/sqSqueakOSXApplication.m (34) M platforms/iOS/vm/OSX/sqSqueakOSXCGView.h (4) A platforms/iOS/vm/OSX/sqSqueakOSXHeadlessView.h (69) A platforms/iOS/vm/OSX/sqSqueakOSXHeadlessView.m (350) M platforms/iOS/vm/OSX/sqSqueakOSXMetalView.h (9) M platforms/iOS/vm/OSX/sqSqueakOSXMetalView.m (206) M platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.h (2) M platforms/iOS/vm/OSX/sqSqueakOSXOpenGLView.m (4) A platforms/iOS/vm/OSX/sqSqueakOSXViewFactory.h (22) A platforms/iOS/vm/OSX/sqSqueakOSXViewFactory.m (72) D scripts/build-metal-shaders.sh (29) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/382.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/382.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/382

3 8

[OpenSmalltalk/opensmalltalk-vm] 1d9c8b: Minor tidyups to Mac Makefiles and related. [ci skip]
by Eliot Miranda 11 Apr '19

11 Apr '19

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 1d9c8bcfd3214c52e8a449840b2cd1c448b33d18 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1d9c8bcfd3214c52e8… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2019-04-11 (Thu, 11 Apr 2019) Changed paths: M build.macos32x86/common/Makefile.lib.extra M build.macos32x86/pharo.cog.spur/plugins.ext M build.macos64x64/common/Makefile.app.squeak Log Message: ----------- Minor tidyups to Mac Makefiles and related. [ci skip]

1 0

Build failed: opensmalltalk-vm 1.0.1735
by AppVeyor 11 Apr '19

11 Apr '19

1 0

Pharo on ARM
by ken.dickey＠whidbey.com 11 Apr '19

11 Apr '19

Greetings, The 32 bit ARM VMs work for v6 & v7. The 64 bit VM is for v8/AArch64 on Linux. This is only the interpreter VM (no COG JIT), so is pretty slow currently. Also the UFFI is not yet working on 64 bit. I am working on this but am a bit slow at it. I would suggest the 32 bit VM for now as the UI is faster. I don't know if the 64 bit ARM VM is built by default. I can help with advice if you run into problems building from sources. -KenD [ken dot dickey at whidbey dot com]

3 2

Build failed: opensmalltalk-vm 1.0.1734
by AppVeyor 11 Apr '19

11 Apr '19

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev April 2019