This is due to a macOS bug in 64bits libm! (Hard to believe, isn't it?)
I've opened a ticket https://bugreport.apple.com/web/?problemID=48021471
> Area:
> Something not on this list
>
> Summary: ldexp incorrectly rounds gradual underflow for some specific values.
>
> Steps to Reproduce:
> #include <math.h>
> #include <stdio.h>
> int main() {
> int exp=-54; double y=ldexp(11.0,exp); /* y is binary 1.011*2^-51 */
> double u=ldexp(1.0,-1074); /* u is the minimal denormalized IEEE754 double */
> double v=ldexp(y,-1023); /* v is binary 1.011*2^-1074 and should round to u */
> printf("u=%g v=%g\n",u,v);
> return 0;
> }
>
> Expected Results:
> v should be rounded to 1.0*2^-1074 (round to nearest, tie to even default rule)
> Thus we should have u == v.
>
> Actual Results:
> v is rounded upward to binary 10.0*2^-1074 = 1.0*2^-1073
> output is u=4.94066e-324 v=9.88131e-324
>
> Note 1: this fails for 4 different values of exp -54,-53,+968,+969
> (replace exponent -1023 by -1074-3-exp, that is -1023,-1024,-2045,-2046)
> Note 2: this did not happen previously with 32bits libm version.
> Note 3: this sounds a bit like this bug https://stackoverflow.com/questions/32150888/should-ldexp-round-correctly
>
> Version/Build:
> macOS HighSierra 10.13.16
>
> Configuration:
> compiled with
> clang --version
> Apple LLVM version 10.0.0 (clang-1000.11.45.5)
> Target: x86_64-apple-darwin17.7.0
> Thread model: posix
> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> Xcode Version 10.1 (10B61)
>
>
--
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/383
hi all,
I'm curious about the exposure that new issue tickets gets, versus a mail to the vm-dev.
If you are reading this, could you follow the link to github and tag this comment with an emoji.
cheers -ben
--
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/346
If I execute this code:
```Smalltalk
ZnClient new url: 'https://google.com'; get.
```
I get a result.
If I execute this code:
```Smalltalk
ZnClient new url: 'https://github.com'; get.
```
I get this error: Error: SSL Exception: connect failed [code:-5]
I tried with both stable and latest vm. (The stable is from august 2017 I think)
I sent a mail on the Pharo dev ML and we are at least two having this problem with Windows 7 when it's working with Windows 10.
Here are the details and the stack:
```
Image
-----
E:\Pharo\images\Pharo 7.0 (development version)-22\Pharo 7.0
(development version)-22.image
Pharo7.0alpha
Build information:
Pharo-7.0+alpha.build.749.sha.039a4b6f0d61ba99778349c4cff2c4e8d5ff9227
(32 Bit)
Unnamed
Virtual Machine
---------------
C:\Users\JeCisC\Documents\Pharo\vms\70-x86\Pharo.exe
CoInterpreter VMMaker.oscog-eem.2359 uuid:
b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2359 uuid:
b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018
VM: 201803161038 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Date: Fri Mar 16 11:38:09 2018 +0100 $ Plugins: 201803161038
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Win32 built on Mar 16 2018 11:02:19 GMT Compiler: 6.4.0
VMMaker versionString VM: 201803161038
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Fri Mar 16
11:38:09 2018 +0100 $ Plugins: 201803161038
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
CoInterpreter VMMaker.oscog-eem.2359 uuid:
b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018
StackToRegisterMappingCogit VMMaker.oscog-eem.2359 uuid:
b3273e3e-dd9d-4819-a928-7034e1cf412c Mar 16 2018
Operating System/Hardware
-------------------------
Win32 6.1 IX86
Operating System Details
------------------------
Operating System: Windows 7 Professional N (Build 7601 Service Pack 1)
SP major version: 1
SP minor version: 0
Suite mask: 100
Product type: 1
==============================================================
ZdcSecureSocketStream(Object)>>error:
ZdcSecureSocketStream>>sslException:code:
ZdcSecureSocketStream>>connect
ZnClient>>setupTLSTo:
ZnClient>>newConnectionTo:
ZnClient>>getConnectionAndExecute
ZnClient>>executeWithRedirectsRemaining:
[ self executeWithRedirectsRemaining: self maxNumberOfRedirects ] in
ZnClient>>executeWithRetriesRemaining: in Block: [ self
executeWithRedirectsRemaining: self maxNumb...etc...
BlockClosure>>on:do:
ZnClient>>executeWithRetriesRemaining:
[ self executeWithRetriesRemaining: self numberOfRetries ] in [ [ self
executeWithRetriesRemaining: self numberOfRetries ]
on: Error
do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ self
executeWithRetriesRemaining: self numberOfR...etc...
BlockClosure>>on:do:
[ [ self executeWithRetriesRemaining: self numberOfRetries ]
on: Error
do: self ifFailBlock ] in ZnClient>>executeWithTimeout in Block: [ [
self executeWithRetriesRemaining: self numberO...etc...
[ ^ block value ] in ZnClient>>withTimeoutDo: in Block: [ ^ block value ]
[ activeProcess psValueAt: index put: anObject.
aBlock value ] in ZnConnectionTimeout(DynamicVariable)>>value:during: in
Block: [ activeProcess psValueAt: index put: anObject....
BlockClosure>>ensure:
ZnConnectionTimeout(DynamicVariable)>>value:during:
ZnConnectionTimeout class(DynamicVariable class)>>value:during:
ZnClient>>withTimeoutDo:
ZnClient>>executeWithTimeout
[ result := self executeWithTimeout ] in ZnClient>>execute in Block: [
result := self executeWithTimeout ]
[ ^ block value ] in ZnClient>>withProgressDo: in Block: [ ^ block value ]
[ activeProcess psValueAt: index put: anObject.
aBlock value ] in ZnSignalProgress(DynamicVariable)>>value:during: in
Block: [ activeProcess psValueAt: index put: anObject....
BlockClosure>>ensure:
ZnSignalProgress(DynamicVariable)>>value:during:
ZnSignalProgress class(DynamicVariable class)>>value:during:
ZnClient>>withProgressDo:
ZnClient>>execute
ZnClient>>get
UndefinedObject>>DoIt
```
--
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/236
*I have copied the below issue from https://github.com/hpi-swa/smalltalkCI/issues/366.*
Hi!
Time to time, the Pharo VM crashes, without any apparent reasons.
For example, in https://travis-ci.org/ObjectProfile/Roassal2/jobs/365943067
```
VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $
Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
C stack backtrace & registers:
eax 0x1e750080 ebx 0x00000100 ecx 0x00000020 edx 0x00000002
edi 0x00000020 esi 0x00000020 ebp 0xbff09c58 esp 0xbff09c58
eip 0x000e848d
0 Pharo 0x000e848d fetchByteofObject + 9
1 Pharo 0x00149400 reportStackState + 819
2 Pharo 0x001497a2 sigsegv + 191
3 libsystem_platform.dylib 0xa1742e5b _sigtramp + 43
```
And a bit below:
```
Smalltalk
Smalltalk stack dump:
0xbff11ce8 I SessionManager>snapshot:andQuit: 0x6b496a8: a(n) SessionManager
0xbff11d18 I [] in SmalltalkImage>snapshot:andQuit: 0x5517fa0: a(n) SmalltalkImage
0xbff11d3c I CurrentExecutionEnvironment class>activate:for: 0x5af3520: a(n) CurrentExecutionEnvironment class
0xbff11d64 I DefaultExecutionEnvironment(ExecutionEnvironment)>beActiveDuring: 0x5e2bc70: a(n) DefaultExecutionEnvironment
0xbff11d88 I DefaultExecutionEnvironment class>beActiveDuring: 0x5b1d8a8: a(n) DefaultExecutionEnvironment class
0xbff11dac I SmalltalkImage>snapshot:andQuit: 0x5517fa0: a(n) SmalltalkImage
```
It seems to happens randomly
/cc @bergel
--
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/252
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
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