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
Hi everyone,
Sorry for this newbie question but I'm unclear as to where I can the Smalltalk/Slang source code for the VM and the associated Slang to C translator.
Thank you for your help!
--
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/423
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
Building from the latest sources on the Cog branch, I see the attached image when loading various images using various OSX builds. I have tried the 64-bit Pharo, Squeak and newspeak builds with their associated images. I see some variation of the attached image below. If I rollback the source to the 201901172323 tag, I am able to build and load an image and see the window as expected.
<img width="811" alt="Screen Shot 2019-04-23 at 6 47 51 PM" src="https://user-images.githubusercontent.com/32800969/56627814-3fea6280-65fc-1…">
--
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/392
It seems that after ba7bb9557 a seqfault was introduced to the 64bit Linux VM. With no image file the VM happily produces output. When providing an image file it immediately segfaults regardless of whether a display is provided or whether it runs headless.
--
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/433
There is code that transforms the presumably latin-1 key value into approximately MacRoman encoding in platforms/win32/vm/sqWin32Window.c
I let the archeologists debate if this code dates from Jurassic period or more distant paleozoic era, all I know is that we pay for what we don't buy...
Thus I propose to entirely remove that piece of code and disentangle a bit the spaghetti keyboard handling.
We indeed do not need this extra level of complexity anymore, images do not use macRoman encoding for a long time
On the contrary, images have to undo the translation by sending `macToSqueak` message in various subclasses of `KeyboardInputInterpreter`.
For the transition period, old images running on new VMs, or new images running on old VMs, might encounter a few hickups while interpreting non ASCII characters in case of exotic `KeyboardInputInterpreter`. That won't be the case of main `UTF32InputInterpreter` since it mostly uses the utf32 code passed through `eventBuffer sixth` position rather than keyValue passed thru `eventBuffer third`, except for some CTRL+key for which the keyValue is more-than-often < 128, and thus unaffcted by the proposed change.
--
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/401