I downloaded squeak 5.3 image fresh from the site (32-bit) and tried to run it in this vm on a Rpi Zero W. Crash.dmp outputs```
Segmentation fault Mon Apr 20 21:39:41 2020
/home/pi/squeak/lib/squeak/5.0-202003021730/squeak
Squeak VM version: 5.0-202003021730 Tue Mar 3 09:42:45 UTC 2020 gcc 4.9.2 [Production Spur VM]
Built from: CoInterpreter VMMaker.oscog-nice.2712 uuid: da64ef0b-fb0a-4770-ac16-f9b448234615 Mar 3 2020
With: StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
Revision: 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
Build host: Linux travis-job-97835d24-79f4-41d1-b7e9-c81bd8bf7149 4.4.0-104-generic #127~14.04.1-Ubuntu SMP Mon Dec 11 12:44:15 UTC 2017 armv7l GNU/Linux
plugin path: ./../lib/squeak/5.0-202003021730 [default: /home/pi/squeak/lib/squeak/5.0-202003021730/]
C stack backtrace & registers:
r0 0x021b79d8 r1 0x00000002 r2 0x01000d34 r3 0x00000000
r4 0x00216288 r5 0x00000000 r6 0xbeec682c r7 0x0379170b
r8 0x001e7414 r9 0x0021e268 r10 0x00000000 fp 0xbeec489c
ip 0x00224250 sp 0xbeec4810 lr 0x000748b4 pc 0x0007055c
*[0x0]
/lib/arm-linux-gnueabihf/libc.so.6(vsprintf+0x80)[0xb6cee228]
Smalltalk stack dump:
0xbeec6860 I SmalltalkImage>setGCParameters 0x233a9d0: a(n) SmalltalkImage
0xbeec6888 I SmalltalkImage>snapshot:andQuit:withExitCode:embedded: 0x233a9d0: a(n) SmalltalkImage
0x47d16d0 s SmalltalkImage>snapshot:andQuit:embedded:
0x47d26f8 s SmalltalkImage>snapshot:andQuit:
0x47d27b8 s [] in ReleaseBuilder class>saveAndQuit
0x47d2890 s WorldState>runStepMethodsIn:
0x47d2920 s PasteUpMorph>runStepMethods
0x47d29f0 s WorldState>doOneCycleNowFor:
0x47d2a50 s WorldState>doOneCycleFor:
0x47d2ac0 s PasteUpMorph>doOneCycle
0x47d2b20 s [] in MorphicProject>spawnNewProcess
0x47d2b80 s [] in BlockClosure>newProcess
Most recent primitives
basicNew
size
at:
basicNew:
decompress:fromByteArray:at:
beCursorWithMask:
vmParameterAt:
fractionPart
truncated
stack page bytes 4096 available headroom 2788 minimum unused headroom 3740
(Segmentation fault)
Segmentation fault Mon Apr 20 21:41:26 2020
/home/pi/squeak/lib/squeak/5.0-202003021730/squeak
Squeak VM version: 5.0-202003021730 Tue Mar 3 09:42:45 UTC 2020 gcc 4.9.2 [Production Spur VM]
Built from: CoInterpreter VMMaker.oscog-nice.2712 uuid: da64ef0b-fb0a-4770-ac16-f9b448234615 Mar 3 2020
With: StackToRegisterMappingCogit VMMaker.oscog-eem.2719 uuid: e40f3e94-3a54-411b-9613-5d19114ea131 Mar 3 2020
Revision: 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
Build host: Linux travis-job-97835d24-79f4-41d1-b7e9-c81bd8bf7149 4.4.0-104-generic #127~14.04.1-Ubuntu SMP Mon Dec 11 12:44:15 UTC 2017 armv7l GNU/Linux
plugin path: ./../lib/squeak/5.0-202003021730 [default: /home/pi/squeak/lib/squeak/5.0-202003021730/]
C stack backtrace & registers:
r0 0x00000000 r1 0x00000dcd r2 0x00216288 r3 0x00b04c70
r4 0x00216288 r5 0x00000000 r6 0xbeaf382c r7 0x00224250
r8 0x001e7414 r9 0x00000000 r10 0x00216288 fp 0xbeaf189c
ip 0x00224250 sp 0xbeaf17e0 lr 0x0006ae84 pc 0x0004c4bc
*[0x0]
/lib/arm-linux-gnueabihf/libc.so.6(vsprintf+0x80)[0xb6c6e228]
Smalltalk stack dump:
0xbeaf3860 I SmalltalkImage>setGCParameters 0xe3a9d0: a(n) SmalltalkImage
0xbeaf3888 I SmalltalkImage>snapshot:andQuit:withExitCode:embedded: 0xe3a9d0: a(n) SmalltalkImage
0x32d16d0 s SmalltalkImage>snapshot:andQuit:embedded:
0x32d26f8 s SmalltalkImage>snapshot:andQuit:
0x32d27b8 s [] in ReleaseBuilder class>saveAndQuit
0x32d2890 s WorldState>runStepMethodsIn:
0x32d2920 s PasteUpMorph>runStepMethods
0x32d29f0 s WorldState>doOneCycleNowFor:
0x32d2a50 s WorldState>doOneCycleFor:
0x32d2ac0 s PasteUpMorph>doOneCycle
0x32d2b20 s [] in MorphicProject>spawnNewProcess
0x32d2b80 s [] in BlockClosure>newProcess
Most recent primitives
basicNew
size
at:
basicNew:
decompress:fromByteArray:at:
beCursorWithMask:
vmParameterAt:
fractionPart
truncated
stack page bytes 4096 available headroom 2788 minimum unused headroom 3740
(Segmentation fault)
```
--
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/487
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.patchhttps://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
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.patchhttps://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
- 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.patchhttps://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
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.patchhttps://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
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
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
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.patchhttps://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