Vm-dev June 2020

vm-dev@lists.squeakfoundation.org

23 participants
106 discussions

[OpenSmalltalk/opensmalltalk-vm] Latest commit segfaults win64x64.squeak.cog.spur (#498)
by Marcel Taeumel 20 Oct '20

20 Oct '20

ee89a4dad04442463252b6a368a8ba373288a774 Trying to load a 64-bit image, the VM segfaults in gcc3x-cointerp.c line 2809 `memset(theStackMemory, 0, stackPagesBytes);` Other win64x64 targets might be affected. I tested both a custom build and bintray version: https://bintray.com/opensmalltalk/vm/download_file?file_path=squeak.cog.spu… -- 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/498

3 4

[OpenSmalltalk/opensmalltalk-vm] Bump minimal supported Windows version to Windows 8 (0x0602). (#499)
by Marcel Taeumel 19 Oct '20

19 Oct '20

Also fixes a minor issue in MSVC Makefile for 64x64, which tried 0x0801 for Windows 8 and 0x1001 for Windows 10. The latter would actually be 0x0A00. See https://docs.microsoft.com/de-de/cpp/porting/modifying-winver-and-win32-win… Also in the Makefile for 64x64, define both _WIN32 and _WIN64. See https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros Also in the Makefile for 64x64, define both WIN32 and WIN64 because those can be used to identify the Windows platform in application code such as in processors/IA32/bochs. I am not aware of any #ifdef WIN64 at the moment. Most code uses #ifdef _WIN64 to check for that. Note that, having defined both _WIN32 and _WIN64, code for 32-bit and 64-bit must always begin with #ifdef _WIN64 and only then #elif _WIN32. I think that the MSVC compiler defines _WIN32 and _WIN64 automatically. Yet, now it is documented in the Makefile. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/499 -- Commit Summary -- * Bump minimal supported Windows version to Windows 8 (0x0602). -- File Changes -- M build.win32x86/common/Makefile.msvc.tools (7) M build.win32x86/common/Makefile.tools (9) M build.win64x64/common/Makefile.msvc.tools (8) M build.win64x64/common/Makefile.tools (7) M platforms/win32/vm/sqWin32.h (41) M platforms/win32/vm/sqWin32Main.c (77) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/499.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/499.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/499

4 8

[OpenSmalltalk/opensmalltalk-vm] unix: use dlopen's lookup mechanism when not specifying a path (#497)
by Tom Beckmann 19 Oct '20

19 Oct '20

This allows FFI modules to be specified in the same manner as you would when linking to them (-lGL --> GL, instead of /usr/lib/x86_64-linux-gnu/libGL.so as was required before this change, unless you manually placed /usr/lib/x86_64-linux-gnu in your LD_LIBRARY_PATH). I don't know whether this will have unintended consequences for some use cases, since a lot of different systems end up calling this function. I tested the change for a while on Ubuntu 20.04 with no odd behavior occurring (but instead finally being able to load FFI modules without providing an absolute path or changing my LD_LIBRARY_PATH manually). Some more insights on why this was necessary: We have a long list of different ways of resolving a module. Among those is looking through the directories in the LD_LIBRARY_PATH envvar, which however only contains those directories I manually added, not all that ldconfig would consider. In our list of directories, we were already passing an empty string once, which would do nothing unless an absolute path was given, since we only proceed to look up a library if the given path is a valid directory. Providing `dlopen` with just a library name, without any path information, however, allows it to look through all directories as configured in ldconfig. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/497 -- Commit Summary -- * unix: use dlopen's lookup mechanism when not specifying a path -- File Changes -- M platforms/unix/vm/sqUnixExternalPrims.c (17) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/497.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/497.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/497

3 9

[OpenSmalltalk/opensmalltalk-vm] Customization for Pharo & About Dialog (#388)
by Pablo Tesone 19 Oct '20

19 Oct '20

- We added customization for Pharo to allow a different menu to be used. - We modified the default action of help menu to open an URL (only for Pharo) - We added a Info.plist property with the string value of the URL (only for Pharo) - And also the about dialog was not receiving the close event, we have fixed that. It was related with the filtering of events for SDL. @demarey You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/388 -- Commit Summary -- * Adding a custom Menu for Pharo VMs * Adding a optional URL for the help, only fr Pharo * Handling correctly the events of the about window * Making the about window property as weak. -- File Changes -- M build.macos32x86/common/Makefile.app (8) M build.macos32x86/pharo.cog.spur.lowcode/Makefile (3) M build.macos32x86/pharo.cog.spur.minheadless/Makefile (2) M build.macos32x86/pharo.cog.spur/Makefile (1) M build.macos32x86/pharo.cog.spur/plugins.ext (2) M build.macos32x86/pharo.cog.v3/Makefile (2) M build.macos32x86/pharo.sista.spur/Makefile (2) M build.macos32x86/pharo.stack.spur.lowcode/Makefile (2) M build.macos32x86/pharo.stack.spur/Makefile (2) M build.macos64x64/common/Makefile.app (8) M build.macos64x64/pharo.cog.spur.lowcode/Makefile (1) M build.macos64x64/pharo.cog.spur/Makefile (1) M build.macos64x64/pharo.sista.spur/Makefile (1) M build.macos64x64/pharo.stack.spur.lowcode/Makefile (1) M build.macos64x64/pharo.stack.spur/Makefile (1) A platforms/iOS/vm/English.lproj/Pharo-MainMenu-opengl.xib (1261) A platforms/iOS/vm/English.lproj/Pharo-MainMenu.xib (1261) M platforms/iOS/vm/OSX/Pharo-Info.plist (2) M platforms/iOS/vm/OSX/SqueakOSXApplication.m (30) M platforms/iOS/vm/OSX/sqSqueakOSXApplication+events.m (16) M platforms/iOS/vm/OSX/sqSqueakOSXApplication.h (5) M platforms/iOS/vm/OSX/sqSqueakOSXApplication.m (1) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/388.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/388.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/388

7 12

[OpenSmalltalk/opensmalltalk-vm] Removes support for NO_VIRTUAL_MEMORY on win32 platform (#504)
by Marcel Taeumel 19 Oct '20

19 Oct '20

You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/504 -- Commit Summary -- * Removes support for NO_VIRTUAL_MEMORY on win32 platform -- File Changes -- M platforms/win32/vm/sqWin32.h (1) M platforms/win32/vm/sqWin32Alloc.c (4) M platforms/win32/vm/sqWin32Alloc.h (3) M platforms/win32/vm/sqWin32Main.c (15) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/504.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/504.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/504

3 2

[OpenSmalltalk/opensmalltalk-vm] DO NOT INTEGRATE - FOR DISCUSSION ONLY Minimalistic headless x64 msvc2017 (#312)
by Ben Coman 11 Sep '20

11 Sep '20

Ronie submitted a pull request that fixes the build with cygwin for win32 ( https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/311 ) and I'm curious if any of my changes here are still applicable. @ronsaldo could you comment on these... You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/312 -- Commit Summary -- * Fix function call declarations and return types (x64-msvc2017) * Fix unresolved external symbol 'alloca' (x64-msvc2017) * Workaround _controlfp() does not support _MCW_PC or _MCW_IC on x64. Expert review required. * Add architecture define _M_IX86 to ABI (x86-msvc2017) * Workaround hang allocating initial memory (x64-msvc2017). Expert review required. * Better 32bit CMakeLists.txt for SqueakFFIPrims (x86-msvc2017) -- File Changes -- M CMakeLists.txt (43) M platforms/Cross/plugins/IA32ABI/ia32abicc.c (2) M platforms/Cross/plugins/IA32ABI/x64win64abicc.c (3) M platforms/Cross/plugins/IA32ABI/xabicc.c (2) M platforms/minheadless/common/sqMain.c (1) M platforms/minheadless/windows/sqPlatformSpecific-Win32.c (9) M platforms/minheadless/windows/sqPlatformSpecific-Win32.h (2) M platforms/minheadless/windows/sqWin32Main.c (1) M platforms/minheadless/windows/sqWin32SpurAlloc.c (9) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/312.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/312.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/312

5 12

[OpenSmalltalk/opensmalltalk-vm] Build on FreeBSD (#483)
by Jochen Raßler 11 Sep '20

11 Sep '20

I'm trying to build the squeak.cog.spur vm on FreeBSD 12.1 Steps I took so far: - build.linux64x64 - squeak.cog.spur - adding to mvm ``` case $(uname -s) in OpenBSD) CFLAGS="$CFLAGS -I/usr/local/include" LIBS="$LIBS -lexecinfo" LDFLAGS="$LDFLAGS -L/usr/local/lib" ;; FreeBSD) CFLAGS="$CFLAGS -I/usr/local/include" LIBS="$LIBS -lexecinfo -liconv" LDFLAGS="$LDFLAGS -L/usr/local/lib" ;; esac ``` to fix linking issue with libiconv - changed vm-sound-ALSA/sqUnixSoundALSA.c `static char devname[MAX_NAME_LEN]` to `static char a_devname[MAX_NAME_LEN]` and changed all occurences of devname to a_devname to fix a name resoltuion issue with /usr/include/stdlib Now I'm stuck with plugins/SqueakSSL/sqUnixOpenSSL.inc line 75 ``` /oscog/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.inc:75:18: error: variable has incomplete type 'struct in6_addr' struct in6_addr addr = { 0 }; // placeholder, longest of in_addr and in6_addr ``` Compiler is clang 8. Can you give me a hint how to move on? -- 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/483

5 6

[OpenSmalltalk/opensmalltalk-vm] Win32 event generation mixes up timeGetTime() and GetMessageTime() (#509)
by Christoph Thiede 11 Sep '20

11 Sep '20

I'm just starting to get familiar with this repository, and I found out something interesting: On Windows, the timestamps of DND (drag and drop) events received from the VM differ by loads from the timestamps of mouse move events. For example, I recorded some event sequences where the former were circa `7140`, and the latter, just recorded a few seconds later, were `21276406`. In other cases, the difference I measured was about 57 seconds, not sure whether cause or coincidence. Looking into `sqWin32Window.c`, this may be caused by the fact that `recordDragDropEvent()` calls `ioMicroMSecs()` which calls `timeGetTime()` from `timeapi.h` and trims the result to fit into a `SmallInteger`. On the contrary, `recordMouseEvent()`, and so `recordMouseDown()`, `recordKeyboardEvent()`, and others called from `MainWndProcW()`, use `GetMessageTime()` from `winuser.h` as time stamp which is not truncated, too. Do we indeed need to use two different approaches, two different APIs here? This is very impractical for me as I cannot compare the timestamp of events from different sources. Would it be possible to decide for one API and one byte count? Looking forward to your feedback! ## Related sources - Besides the SmallInteger truncation, lags between timestamps from both different APIs appear to be a known problem: [StackOverflow - Lag between GetTickCount() and timeGetTime() changes between executions of my test program](https://stackoverflow.com/questions/48813245/lag-between-gettickco… - A similar issue already has been reported on the squeak-vm list here: [[squeak-vm] [win32] Morphic event timeStamp bug ](http://forum.world.st/win32-Morphic-event-timeStamp-bug-td4824244.html) -- 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/509

3 5

[OpenSmalltalk/opensmalltalk-vm] MUSL deltas (mostly harmless) (#450)
by Ken Dickey 10 Sep '20

10 Sep '20

I have built and tested aarch64 builds on Raspbery Pi 3B / Arch Linux / MUSL+Busybox Chromebook Two / Linux / libc The mvm "-O1" seems to work in both cases -- no need to go to "-O0" Please ignore the spurious sqSCCSVersion.h -- I don't know how to elide this. The getwd() -> getcwd() in sqUnixSecurityPlugin.c should likewise be harmless [no getwd() in MUSL] Not a time concern. I don't know of anyone asking for this. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/450 -- Commit Summary -- * MUSL for AlpineLinux * MUSL for AlpineLinux -- File Changes -- M build.linux64ARMv8/squeak.stack.spur/build.debug/mvm (7) M build.linux64ARMv8/squeak.stack.spur/build/mvm (10) M platforms/Cross/plugins/sqPluginsSCCSVersion.h (8) M platforms/Cross/vm/sqSCCSVersion.h (14) M platforms/Cross/vm/sqVirtualMachine.c (5) M platforms/unix/plugins/SecurityPlugin/sqUnixSecurity.c (3) M platforms/unix/vm/sqUnixMain.c (5) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/450.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/450.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/450

6 28

[OpenSmalltalk/opensmalltalk-vm] Be explicit about which test image version - move to CI config (#331)
by Ben Coman 10 Sep '20

10 Sep '20

First try to see what Travis thinks about these changes. You can view, comment on, or merge this pull request online at: https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/331 -- Commit Summary -- * Be explicit about which test image version - move to CI config -- File Changes -- M .travis.yml (91) M scripts/ci/travis_test.sh (6) M tests/smalltalkCI.sh (25) -- Patch Links -- https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/331.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/331.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/331

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2020