Vm-dev March 2019

vm-dev@lists.squeakfoundation.org

27 participants
98 discussions

[OpenSmalltalk/opensmalltalk-vm] fix event memory leak (#373)
by maenu 28 Jun '19

28 Jun '19

Fixes a memory leak in the macOS event loop, see discussion on mailing list http://lists.squeakfoundation.org/pipermail/vm-dev/2019-February/030595.html You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/373 -- Commit Summary -- * fix event memory leak -- File Changes -- M platforms/iOS/vm/OSX/sqSqueakOSXApplication+events.m (18) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/373.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/373.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/373

5 16

Image crashing on startup, apparently during GC
by Damien Pollet 03 Jun '19

03 Jun '19

Hi, I have a Pharo image that crashes the VM on startup. The crash report below seems to incriminate GC. Should I make it available somewhere online? What's most convenient? Process: Pharo [64892] Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo.Pharo Version: 5.0.201708271955 (5.0.201708271955) Code Type: X86-64 (Native) Parent Process: ??? [64888] Responsible: Pharo [64892] User ID: 501 Date/Time: 2018-03-19 20:27:03.906 +0100 OS Version: Mac OS X 10.13.3 (17D102) Report Version: 12 Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154 Time Awake Since Boot: 28000 seconds Time Since Wake: 6500 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 Exception Note: EXC_CORPSE_NOTIFY VM Regions Near 0x12b67c0b0: VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] rw-/rwx SM=PRV --> STACK GUARD 0000700005613000-0000700005614000 [ 4K] ---/rwx SM=NUL stack guard for thread 1 Application Specific Information: abort() called Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 5 ??? 000000000000000000 0 + 0 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + 45 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 10 org.pharo.Pharo 0x0000000104e5c7f6 enterSmalltalkExecutiveImplementation + 152 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 12 org.pharo.Pharo 0x0000000104ed9cc1 -[sqSqueakMainApplication runSqueak] + 394 13 com.apple.Foundation 0x00007fff2e6d696c __NSFirePerformWithOrder + 360 14 com.apple.CoreFoundation 0x00007fff2c579127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 15 com.apple.CoreFoundation 0x00007fff2c57904f __CFRunLoopDoObservers + 527 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + 1240 17 com.apple.CoreFoundation 0x00007fff2c55af43 CFRunLoopRunSpecific + 483 18 com.apple.HIToolbox 0x00007fff2b872e26 RunCurrentEventLoopInMode + 286 19 com.apple.HIToolbox 0x00007fff2b872a9f ReceiveNextEventCommon + 366 20 com.apple.HIToolbox 0x00007fff2b872914 _BlockUntilNextEventMatchingListInModeWithFilter + 64 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + 2085 22 com.apple.AppKit 0x00007fff2a2d3b4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication run] + 764 24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain + 804 -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

5 8

[OpenSmalltalk/opensmalltalk-vm] WASM Compile Target? (#387)
by Eric Gade 01 May '19

01 May '19

Hello all! As some of you might be aware, there has been a lot of progress in the web-world in developing [WebAssembly](https://webassembly.org/). Many environments and languages can now compile to the wasm binary format. Projects are doing things like [putting full Python interpreters and environments in the browser](https://github.com/iodide-project/pyodide), etc. There is even a nascent movement to come up with a consistent [system interface standard](https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembl… for WebAssembly, allowing developers to run wasm code on any platform -- not just the web. My question is this: what would it take to get the opensmalltalk-vm to compile to WebAssembly and has anyone involved with it considered the option so far? There would be a great many advantages to running a Smalltalk in the browser this way. -- 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/387

7 10

Where are PR build results stored
by Stephan Eggermont 25 Apr '19

25 Apr '19

This week I was able to triangulate when the fullscreen bug on OS-X was introduced, but I was not able to verify whether Pablo’s proposed fix resolved the problem for me as I don’t have a local VM build set up (and that would be a customized one anyway) and I don’t know where PR builds are kept Stephan

2 3

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

[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

tempVectors use case and current issues
by Denis Kudriashov 08 Apr '19

08 Apr '19

Hi. I found interesting case where tempVectors can be used in remote scenarios. The store into remote temp can be really remote (not just about outer context). I played with following example: | temp | temp := 10. remote evaluate: [temp := temp + 1]. temp. For the moment forget about remote thing and look into it as a normal local case: temp var here is managed indirectly through tempVector. You can see it using expression after first assignment: thisContext at: 1 "=>#(10)" So the value in fact is stored in the array instance and read from it. But because of optimization it happens out of the array control. No #at: and #at:put: messages are sent during this code. VM magically changes the state of this array (there are special bytecodes for this). Now my remote use case. Imagine that vm actually sends #at: and #at:put: messages to tempVector. Then remoting engine can transfer temp vector (as part of context) as a proxy. So on remote side the block [temp := temp + 1] will actually ask the sender (client) for the value and for the storage. So all block semantics will be supported. Temp in remote outer context will be modified. I think it would be super cool if such transparency would be possible. I played with this example using Seamless in Pharo. It already works in the way I described but due to VM optimization it does not provide expected behavior. And worse than that it actually corrupts transferred proxy because in place of array the proxy instance is materialized. This leads us to the issue with safety of tempVector operations. Following example shows how we can affect the state of tempVector using reflection: | temp | temp := 10. (thisContext at: 1) at: 1 put: 50. [temp := temp + 1] value. temp. "==>51" It is cool that we can do it. But there is no any safety check in the VM level over tempVector object: | temp | temp := 10. thisContext at: 1 put: Object new. [temp := temp + 1] value. temp. It breaks with DNU: #+ is sent to nil. Temp became nil. | temp | temp := 10. thisContext at: 1 put: #() copy. [temp := temp + 1] value. temp. Sometimes it breaks with same error. Sometimes it returns random number. I guess in these cases VM breaks memory boundary of tempVector. And two exotic cases: | temp | temp := 10. (thisContext at: 1) beReadOnlyObject. [temp := temp + 1] value. temp. It silently return 11. It does not break read only protection. But no error is signalled. | temp | temp := 10. (thisContext at: 1) become: #() copy. [temp := temp + 1] value. temp. It returns #(). (In Pharo #() + 1 = #() ). I use become to check how forwarding is working in that case. (it works fine when array has correct size) How we can improve this behavior? How it would effect performance? My proposal is to send real messages to tempVector when it is not an array instance. Then image will decide what to do. Best regards, Denis

5 10

[OpenSmalltalk/opensmalltalk-vm] Add support for retina displays (#378)
by Adrian Sieber 30 Mar '19

30 Mar '19

I just installed Pharo & Squeak and my first impression is rather bad. Nothing screams ancient / unmaintained / not production ready / shitty like no support for retina displays. It has been 6 years since retina displays were released and they should really be supported by now. This has been listed on https://github.com/pharo-project/pharo-workingRoadmaps/blob/master/Pharo7/R… for quite a few years, but apparently nothing has happened yet. From a user standpoint, this should be of really high priority in my opinion. Sorry for popping up here and criticising. Just wanted to provide my experience. -- 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/378

4 12

Errored: zecke/opensmalltalk-vm#25 (fixes/security - 929b31d)
by Travis CI 29 Mar '19

29 Mar '19

Build Update for zecke/opensmalltalk-vm ------------------------------------- Build: #25 Status: Errored Duration: 35 mins and 29 secs Commit: 929b31d (fixes/security) Author: Holger Hans Peter Freyther Message: wip.. View the changeset: https://github.com/zecke/opensmalltalk-vm/compare/4e9b6c6de51e...929b31da40… View the full build log and details: https://travis-ci.org/zecke/opensmalltalk-vm/builds/512919462?utm_medium=no… -- You can unsubscribe from build emails from the zecke/opensmalltalk-vm repository going to https://travis-ci.org/account/preferences/unsubscribe?repository=9904287&ut…. Or unsubscribe from *all* email updating your settings at https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notificati…. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.

1 0

Build completed: opensmalltalk-vm 1.0.1729
by AppVeyor 28 Mar '19

28 Mar '19

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev March 2019