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
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
A problem with FFI is that if a callout segfaults, all of memory
including that of the Image is suspect, and execution of the Image terminates.
Occasionally I hunt around hoping to find technology to mitigate that problem.
Maybe this time in I found something... Memory Protection Keys [1]
Perhaps these could ensure Image memory safe when an FFI callout segfaults.
IIUC the main problem with protecting Image memory on every FFI callout
is the time it would take update the flags on every page of Image memory.
Would being able to change the protection of a massive number of pages
with one syscall make it feasible to wrap them around FFI callouts?
This may be useful at least where the FFI use is more about reuse of
existing functionality than about performance.
Or at least useful while someone is learning/experimenting with FFI for
the first time or while becoming familiar with some external library.
Further info at [2] & [3].
cheers -ben
[1] https://lwn.net/Articles/643797/
[2] http://man7.org/linux/man-pages/man7/pkeys.7.html
[3] https://lwn.net/Articles/689395/
I finally got around to solve the "not a git repository" issue with my previous pull request. For the analysis see below. Please review and try it out before merging.
When the script is run as a hook, the environment variable `GIT_DIR` is set to `.git` (path relative to the working tree) for regular repositories. This affects the behavior of `rev-parse`. When the script is run from the working tree and the checkout commands towards the bottom are executed, the script actually invokes itself as the post-checkout script. During that inner invocation, the script would `cd` to `.git/hooks`, and because of the GIT_DIR variable, `rev-parse` would then look for the git repository in `.git/hooks/.git`. This failed, of course.
The second error message "unrecognized input" came from `git apply` when it was fed with empty input (because there were no uncommitted changes to either *Version.h file).
Since GIT_DIR caused the trouble, why not use it to detect whether the script is run as a hook...
You can view, comment on, or merge this pull request online at:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/227
-- Commit Summary --
* Second attempt to improve updateSCCSVersions
* Eschew --git-path because it was only added in Git 2.5
* Properly handle staged changes to the version headers
* whitespace
-- File Changes --
M scripts/updateSCCSVersions (40)
-- Patch Links --
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/227.patchhttps://github.com/OpenSmalltalk/opensmalltalk-vm/pull/227.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/227
- allow spaces in paths (added quotes)
- support cases where the repository is not in a .git directory at the top of the working tree
- do not hardcode the directory level of this script
- avoid stashing the whole working tree when only two well-known files need to be updated
- touch should suffice to make a file different from its index version (i. e., eligible for checkout)
Please review for compatibility and pick those parts of the changes that you like.
You can view, comment on, or merge this pull request online at:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/213
-- Commit Summary --
* make updateSCCSVersions work in more situations
-- File Changes --
M scripts/updateSCCSVersions (26)
-- Patch Links --
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/213.patchhttps://github.com/OpenSmalltalk/opensmalltalk-vm/pull/213.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/213
wow time flies, its been 18 months since Ronie announced his
Minheadless VM branch...
[1] http://forum.world.st/Minheadless-VM-flavour-status-update-td4928091.html
I've been meaning this whole time to try it out. Recently in my
meandering thoughts on FreeRTOS port, I guessed Minheadless might make
a good starting basis to experiment with.
So a quick test on Ubuntu16.04.3(Windows10-WSL)...
Long ago I'd already done...
git clone git@github.com:OpenSmalltalk/opensmalltalk-vm.git
so I now did...
cd opensmalltalk-vm
git remote add ronie git@github.com:ronsaldo/opensmalltalk-vm.git
git fetch ronie
git checkout MinimalisticHeadless
./scripts/updateSCCSVersions
cd build.minheadless.cmake/x64/pharo.stack.spur/
./mvm
VM=`pwd`/release/dist/pharo
ls $VM
==> confirmed it exists
cd ~/pharo
wget http://files.pharo.org/image/70/latest-minimal-64.zip
unzip latest-minimal-64.zip
sudo $VM Pharo7.0-metacello-64bit-65cff7b.image eval "19 + 23"
==> 42 yay
Particularly interesting from [1] is "using the same CMake scripts for
building on the three platforms: Windows, Linux and OS X."
So I thought I'd also give it a try under Windows10-VisualStudio2017.
I hardly used VS before, so I'll detail what I did as a reminder for
myself (and also in case someone might be able to help if I get
stuck).
Under a windows cmd.exe prompt (having installed git and cloned
opensmalltalk-vm a long time ago)
cd opensmalltalk-vm
git remote add ronie git@github.com:ronsaldo/opensmalltalk-vm.git
git fetch ronie
git checkout -b MinimalisticHeadless ronie/MinimalisticHeadless
I watched video [2] about CMake integration with Visual Studio 10.
and checked the VS workloads configuration specified [2@1:13]
using [3].
There is a CMakeLists.txt file in the git root folder, so..
started VS > File > Open > Folder...
C:\Repos\OpenSmalltalk\opensmalltalk-vm
The CMake command run ([2]@2:13) was...
C:\...\cmake.exe -G "Ninja"
-DCMAKE_INSTALL_PREFIX:PATH="C:\Users\Ben\CMakeBuilds\...\x86-Debug"
-DCMAKE_CXX_COMPILER="C:/.../MSVC/14.14.26428/bin/HostX86/x86/cl.exe"
-DCMAKE_C_COMPILER="C:/.../MSVC/14.14.26428/bin/HostX86/x86/cl.exe"
-DCMAKE_BUILD_TYPE="Debug"
-DCMAKE_MAKE_PROGRAM="C:\...\CMAKE\Ninja\ninja.exe"
"C:\Repos\OpenSmalltalk\opensmalltalk-vm"
I changed the cmake configuration [2@2:27] to "x64-Debug".
For debug target [2@3:00] I chose "pharo.exe"
Hey, thats pretty cool [2@4:05] that switching between targets changes
the highlighting of #ifdef code.
I had a moment when I was missing the "Debug and Launch Settings" menu
item [2@4:40-4:55] and mentioned at [4], but maybe there was some
clash with previously experimenting with git cloning opensmalltalk-vm
from inside VS.
After closing VS and reopening my cmd.exe git'd opensmalltalk-vm it
showed up, but I didn't change any settings there.
Then (with x64-Debug & pharo.exe selected)
I went Cmake > Build All
==> 10 Errors, 9 Warnings, which I'll discuss in a followup post.
cheers -ben
[2] https://blogs.msdn.microsoft.com/vcblog/2016/10/05/cmake-support-in-visual-…
[3] https://docs.microsoft.com/en-us/visualstudio/install/modify-visual-studio
[4] https://blogs.msdn.microsoft.com/vcblog/2016/12/20/cmake-support-in-visual-…
[5] https://developercommunity.visualstudio.com/content/problem/234808/cmake-de…