A plain ./mvm build on MacOS 10.13.4 (in any of the build.macos64x64/pharo.* directories) fails with this error:
> utils-prng.c:207:27: error: use of unknown builtin '__builtin_shuffle' [-Wimplicit-function-declaration]
> randdata.vb = __builtin_shuffle (randdata.vb, bswap_shufflemask);
> ^
> utils-prng.c:207:25: error: assigning to 'uint8x16' (vector of 16 'uint8_t' values) from incompatible type 'int'
> randdata.vb = __builtin_shuffle (randdata.vb, bswap_shufflemask);
> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
It's trying to build the tests for pixman. There is a patch for this bug here: https://bugs.freedesktop.org/show_bug.cgi?id=104886
But when I apply the patch, the patched utils-prng.c file gets overwritten with the old version by something in the build or configure step, so the patch disappears and the build error returns.
--
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/258
Hello,
I have a small issue when building (cross-compile) the Smalltalk VM on an ARM(v6) embedded linux system (Nano Pi neno and Raspberry Pi Zero) that uses Musl as default libc implementation.
The problem is that the code and the configure script does not have official support for Musl, so I created a patch file that adds support to Musl, you can find the [patch here](https://github.com/lxsang/antix/blob/master/sm_vm_musl.patch).
With this patch, i am able to cross-compile on the ARM toolchain for my system; with 4 plugins:
```
FilePlugin \
SqueakSSL \
SqueakFFIPrims \
SocketPlugin
```
You can find the build [script here](https://github.com/lxsang/antix/blob/master/packages/smalltalk-nano-p…
For now, i can live with this dirty trick, but i would be verry happy if the mainline VM has official support to Musl.
That's why i create this issue.
Thanks
--
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/304
I have more and more algorithms depending on highBit and the code is fast yet but not enough (appears in tally espcially in Spur64)...
The primitive could use the Count Leading Zero instructions available on most uproc via gcc builtin_clz or MSVC __lzcnt, 32 and 64 bits variants.
Something like this pseudo code:
leadingZeroCount := builtin_clz( taggedIntegerReceiver );
if (clz == 0) return primitiveFail();
else {
highBit := WordSize * 8 "CHAR_BIT" - numTagBits - leadingZeroCount;
return makeSmallInteger( highBit );
}
This primitive should be jitted of course (easy, just need to add an instruction).
Primitive fallback code would aggregate < 0 failure test case + code of highBitOfPositiveReceiver if primitive is absent (no need for two messages, in most case the primitive will be here and fast enough).
Is a primitive number mandatory for being jitted?
If yes, how to reserve/allocate one?
--
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/418
Currently it is only possible to maximize Squeak by using the button in the MainDockingBar (it is not possible by using the green button on the window what is slightly unexpected but ok).
The fullscreen I get is a Squeak that looks like a typical Mac fullscreen but has several drawbacks:
* it is not a new desktop with only the app, but consumes the current desktop
* if you change desktop you get strange behaviour with the dock appearing
* if you use a second monitor and have a Squeak in fullscreen on your first you get a black background stretched over the whole second monitor
The expected behaviour for fullscreen would be a native Mac OS fullscreen.
(@ronsaldo someone mentioned to me that is due to the new metalshaders)
--
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/407
Tim Johnson reported a problem with 32b Linux builds:
http://forum.world.st/Linux-Squeak-VM-X11-keyboard-changes-td5099584.html
Pressing ctrl-d now acts like debugIt instead of doIt like in the 64b. Ctrl-p also stopping working.
I did a bisection of all versions in https://bintray.com/opensmalltalk/vm/cog/ and narrowed down the problem to
good squeak.cog.spur_linux32x86_201811272342.tar.gz
bad squeak.cog.spur_linux32x86_201812301551.tar.gz
The error is consistent on both 18231 and the oldest 18221 released image for 32b VM but does not appear with 64b VMs.
--
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/396
On Linux Mint Sylvia, I could not play sounds (e.g. ``SampledSound beep``). This occurred in the newest SWA VM build of Squeak.
Underlying problem seems to be that the Linux sound libraries for PulseAudio are not linked correctly.
(Maybe this is the same as #118)
With @krono I found this workaround:
``
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.1.0 LD_LIBRARY_PATH=/home/user/Dokumente/SWA2018.app/Contents/Linux-i686/bin/../lib/squeak/5.0-201810071412:/lib/x86_64-linux-gnu:/lib:/usr/lib/x86_64-linux-gnu:/usr/lib: /home/user/Dokumente/SWA2018.app/Contents/Linux-i686/bin/../lib/squeak/5.0-201810071412/squeak -vm-sound-pulse /home/user/Dokumente/SWA2018.app/Contents/Resources/SWA2018.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/360
on /build.linux32x86/pharo.cog.spur/build I run ./mvm and get
make[3]: *** No rule to make target '/usr/lib/i386-linux-gnu/libssl.so', needed by 'libgit2.so.0.25.1'. Stop.
I worked around it by running sudo ln -s /lib/i386-linux-gnu/libssl.so.1.0.0 /usr/lib/i386-linux-gnu/libssl.so but shouldn't be necessary as libssl is downloaded and built by the script.
The same happens with libcrypto
--
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/210
Seems to be something strange with the B3DAcceleratorPlugin on 32-bit macos. The pharo libB3DAcceleratorPlugin.dylib fails to link missing:
createOpenGLTextureLayerHandle
destroyOpenGLTextureLayerHandle
getMainWindowOpenGLContext
setOpenGLTextureLayerContent
The Squeak one links, but apparently against Metal, which isn't going to work since Metal is 64-bit only (or so I've been told).
--
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/385