VM-beginners April 2014

vm-beginners@lists.squeakfoundation.org

6 participants
10 discussions

Maturity of the pharo CMake build process?
by gettimothy 24 Apr '14

24 Apr '14

Hi Folks, I am now working with the CMakeVMMaker on Pharo and am curious as to the maturity of the code before I tackle some build issues I am having with it. Please note that I am NOT looking for an answer to this specific build issue--I can trace that down and fix it just fine. I merely need a sense of the community's sense of the tools robustness so I can keep that in mind as future issues come up. I am currently using the source tree from git clone git://gitorious.org/cogvm/blessed.git and running the generator.image in the blessed/image directory that is downloaded via the newImage.sh script. It seems to run really well except I am getting what looks like a basic error [ 95%] Building C object CMakeFiles/CogVM.dir/home/wm/usr/src/smalltalk/blessed/platforms/unix/vm/sqUnixMain.c.o In file included from /home/wm/usr/src/smalltalk/blessed/platforms/unix/vm/sqUnixMain.c:41:0: /home/wm/usr/src/smalltalk/blessed/platforms/Cross/vm/sqSCCSVersion.h:17:54: fatal error: vmVersionInfo.h: No such file or directory #include "vmVersionInfo.h" // defines REVISION_STRING when running this script: CogUnixConfig new addExternalPlugins: #( FT2Plugin ); addInternalPlugins: #( UnixOSProcessPlugin ); "generateForDebug;" generateSources; generate. That missing #include threw up a red-flag for me (which I have not investigated) that made me question the tools maturity. FWIW, I *really* like the approach of this tool. Having the configurations in their own objects makes perfect sense to me and it is nice to not have to deal with #IFNDEF foo #DEF bar #UNLESS oops #THEN hack #ENDIF stuff. The blessed/image/newImage.sh is a nice feature as well. thanks for your time. tty

3 3

CMakeMaker--whaddya think?
by gettimothy 16 Apr '14

16 Apr '14

Hi all. Unless I am talked out of it , I am going to generate the CMMake "stuff" from Smalltalk classes similar to the way that VMMaker generates source code. My reasons are: 1. source control is Monticello. (and if you generate the source tree, the pharo folks can use that to pipe into git--so that sorta-kinda-syncs things up a bit) 2. modification and maintenance is in Squeak. 3. it should be fun. 4. Modular (looking at the CMake generators, it just begs for OOP approach) 5. Each plugin is responsible for its own CMakeLists.txt (i.e. cmake configuration file) .... whaddya think? Also, if you are ok with the idea, what do you want it named? Do you want some classes added to VMMaker or do you want something elsewhere? p.s. I am suffering from a bit of Spring Fever and took the weekend and Monday and most of today off. I am still studying CMaker before I even look at the existing project for Interpreter and I will probably not look at the existing Interpreter CMake project until I go through the exercise of writing my own from scratch (unless I fall flat on my face, then I will take a peek (: )

1 0

FileHandleTest>>#testTruncate Pharo test case for FilePlugin/ CogVM on 64bit linux
by Markus Fritsche 11 Apr '14

11 Apr '14

(resend because I hit send before I confirmed the subscription) Hello, not sure if this is the right place or not. The above test fails for me. The assert fails since the result of handle size is 5, not 3 as expected. I tested on 32 bit Windows, 32 bit Linux (ext4) and 64 bit Linux (btrfs), and only the 64 bit version fails. I am using Ubuntu 13.10 and 14.04 64 bits (12.04 32 bits). I am not sure if this is architecture or file system related yet. Best regards, Markus

1 2

SqueakSSL same test failures with default config...
by gettimothy 10 Apr '14

10 Apr '14

Howdy. I had backed up my ssh_config file with the standard values, so I did a quick reconfigure, stopped and started the sshd daemon and same results on the tests as my previous post--so my conjecture in the previous post is incorrect. Interesting output on the terminal when I run the tests: 4147410568:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: CERTIFICATE 4147410568:error:140AD009:SSL routines:SSL_CTX_use_certificate_file:PEM lib:ssl_rsa.c:491: 4147410568:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: ANY PRIVATE KEY 4147410568:error:140B0009:SSL routines:SSL_CTX_use_PrivateKey_file:PEM lib:ssl_rsa.c:669: 4147410568:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1353: Oh well, back to it.

1 0

SqueakSSL +OK Gpop ready for requests from 72.250.235.130 dc2mb105720703oab
by gettimothy 10 Apr '14

10 Apr '14

Okeydokey In the mvm file in unixbuild/bld/ I thought I would try adding the library directly and it allowed the thing to compile. LIBS="-lpthread -lssl -lcrypto"\ David, getting the thing to work on production could be as easy as adding those to doo-hickeys. Running the image and checking built-in modules shows the plugin. Running the tests shows the module being loaded: SqueakSSL * VMMaker.oscog-eem.667 (i) (woot!) Throwing a breakpoint in testGooglePopStream gives the response in the Subject line: +OK Gpop ready for requests from 72.250.235.130 dc2mb105720703oab (SqueakSSLTest selector: #testGooglePopStream) run. Testrunner shows 14 run, 3 passes, 0 expected failures, 6 failures, 5 errors, 0 unexpected passes. HOWEVER, I just recently upgraded my openssl packages and modified my ssl_config per this post: http://alien.slackbook.org/blog/securing-remote-root-access/ which means I have an odd port, and am limited to protocol 2 so it could be stuff like that messing up the tests (my bet it is) I am going to do attempt a rebuild using the 64bit libraries in /lib64 and see what happens, plus debug the errors above. If anybody has not fudgelated their ssl configuration and has the means to test, please give it a go. cheers. tty

1 0

SqueakSSL and libtool
by gettimothy 09 Apr '14

09 Apr '14

Howdy all. Building SqueakSSL compiles just fine, but fails at the libtool stage when compiled as an internal plugin. (formatted for easier reading below. I replace full path with [......] where it helps clean up things) /bin/sh [......]/debugCogSqueakSSL/unixbuild/bld/libtool --mode=link gcc -m32 -g -Og -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 -DCOGMTVM=0 -DDEBUGVM=0 -DLSB_FIRST=1 -Wl,-z,now -export-dynamic -o squeak vm/vm.a AsynchFilePlugin/AsynchFilePlugin.a B2DPlugin/B2DPlugin.a BitBltPlugin/BitBltPlugin.a FilePlugin/FilePlugin.a SocketPlugin/SocketPlugin.a SqueakSSL/SqueakSSL.a MiscPrimitivePlugin/MiscPrimitivePlugin.a disabledPlugins.o version.o -lutil -ldl -lpthread -lm -lnsl -lpthread vm/vm.a gcc -m32 -g -Og -msse2 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DNDEBUG -DITIMER_HEARTBEAT=1 -DCOGMTVM=0 -DDEBUGVM=0 -DLSB_FIRST=1 -Wl,-z -Wl,now -o squeak disabledPlugins.o version.o -Wl,--export-dynamic vm/vm.a AsynchFilePlugin/AsynchFilePlugin.a B2DPlugin/B2DPlugin.a BitBltPlugin/BitBltPlugin.a FilePlugin/FilePlugin.a SocketPlugin/SocketPlugin.a SqueakSSL/SqueakSSL.a MiscPrimitivePlugin/MiscPrimitivePlugin.a -lutil -ldl -lpthread -lm -lnsl -lpthread vm/vm.a SqueakSSL/SqueakSSL.a(sqUnixOpenSSL.o): In function `sqCopyBioSSL': [......]/debugCogSqueakSSL/platforms/unix/plugins/SqueakSSL/sqUnixOpenSSL.c:37: undefined reference to `BIO_ctrl_pending' (more errors omitted for brevity. all of them are unresolved references to stuff in /usr/include/openssl/ssl.h . these errors do not happen at compile time, only libtool ing ) Here is what I think is going on with SqueakSSL on linux. SqueakSSL is normally built as an external plugin. My guess external plugins are loaded and linked at load time. Since the thing compiles fine, we don't find the link error and we just get a primitive fail. However, when I moved it from plugins.ext to plugins.int, I get the link failure above. Since discovering this, I have tried two things 1. compile on my pure 64 bit partition...this failed for obvious reasons--we don't have 64 bit Cog yet (: but hey...a guy can hope! 2. I installed openssl compat32 libs alongside the 64 bit versions...as show below. 2.a I made some changes that I kinda-sorta-hoped would work in some strings in the script that had the substring "/lib64 " but that did not work. bash-4.2$ ls lib/*ssl* lib/libssl.so.0 lib/libssl.so.0.9.8 lib/libssl.so.1 lib/libssl.so.1.0.0 bash-4.2$ ls lib64/*ssl* lib64/libssl.so.0 lib64/libssl.so.0.9.8 lib64/libssl.so.1 lib64/libssl.so.1.0.0 I will have to think about this a bit, but I just wanted to post this update in case I am missing something glaringly obvious thx. tty

2 1

Quick update ons SqueakSSL plugin debugging
by gettimothy 07 Apr '14

07 Apr '14

Hi all, quick update no need to respond. <rant>Preface, man, I DO NOT MISS the edit/compile/debug dev loop at all. Give me a vm and a debugger baby....</rant> I *think* its related to two issues. 1. An include issue in the plugin. 2. Library path issue when loading attempting to load the plugin(s) I was unable to build the plugin for StackVMInterpreter due to includes going kablooie for /usr/include/openssl/ssl.h and err.h. So, I downloaded the Cog source tree from Jenkins and decided to poke around with that to see what the problem was. That eliminated the build include error--my guess is a misconfigure .mvm file,but I don't want to deal with that now. Cog from Jenkins builds--including the SqueakSSL plugin. When I run Squeak6 image with the new vm and run the tests, I get this error: ioLoadModule(/home/wm/usr/local/cogVM32/lib/squeak/4.0-2862/SqueakSSL): /home/wm/usr/local/cogVM32/lib/squeak/4.0-2862/SqueakSSL: undefined symbol: X509_NAME_get_text_by_NID That X509 is in x509.h . It is also #included in "openssl/ssl.h" so there "could be" some of that include magic going on.... However... 2 is more interesting at the moment because it looks like the LD_LIBRARY_PATH or something is hosed. Check out the bottom tryLoadModule below... /home/wm/usr/src/smalltalk/Squeak-vm-unix-4.7.0-Cog-2889-unofficial-src/platforms/unix/vm/sqUnixExternalPrims.c 237 tryLoadModule(,SqueakSSL) dude /home/wm/usr/src/smalltalk/Squeak-vm-unix-4.7.0-Cog-2889-unofficial-src/platforms/unix/vm/sqUnixExternalPrims.c 237 tryLoadModule(/usr/lib/,SqueakSSL) dude /home/wm/usr/src/smalltalk/Squeak-vm-unix-4.7.0-Cog-2889-unofficial-src/platforms/unix/vm/sqUnixExternalPrims.c 237 tryLoadModule(/home/wm/usr/local/cogVM32/lib/squeak/4.0-2862/SqueakSSL/.libs/,SqueakSSL) <---WHATS THAT .libs? FWIW, I install to /home/wm/usr/local/cogVM32...tomorrow, I will try a standard install path and see what happens. Anyway, that's the update. I will poke at it some more tomorrow. cordially, tty.

1 0

Re: [Vm-dev] VM Maker: VMMaker.oscog-eem.662.mcz
by gettimothy 04 Apr '14

04 Apr '14

David, is http://build.squeak.org/job/CogVM/546/ a daily build based off the work Eliot is doing each time he uploads an update? How are the Jenkins build above and http://squeakvm.org/svn/squeak/branches/Cog/ related? thx. tty

1 0

Techniques for debuggin plugins
by gettimothy 03 Apr '14

03 Apr '14

Howdy all. I will be debugging the SqueakSSL plugin on Linux tomorrow or so and am planning on using DDD to connect to a running process and see what I can see. Is this the approach you folks would use? or are there better methods for approaching this. thx. tty

2 1

Re: [Vm-dev] Re: [Pharo-users] 64 bit version
by gettimothy 02 Apr '14

02 Apr '14

Hi Phil. The only native64 vm I have running is the old (no block closures) standard interpreter. It powers either a 32 bit image or a 64 bit image. For an overview of my understanding of the subject, read the rest of this comment. This is my state of understanding--expect mistakes. First some base assumptions. 1. I have a tri-boot 64 bit machine that boots to either a) dos 7, b) Slackware Linux 64 with 32 bit compat libs or c) Slackware Linux 64 (no 32 bit libs) 2. I currently must run Squeak on b) Slackware Linux 64 with 32 bit compat libs 3. So, my reference point is only on the linux side since that is where I work. my goal is a native 64 bit application on c). There are (at least) 3 flavors of the VM building tools. 1. The Standard Interpreter that Daniel T. Lewis maintains 2. Cog (This tool includes infrastructure to build Cog, StackInterpreter, Newspeak and Spur (don't know this yet) etc.it is the cutting edge environment ) 3. Cog ala Pharo I am only working with 1 and 2. I may get to 3 for completeness sake when I get fluent at this stuff. 1. The Standard Interpreter uses VMMaker as its code generator and CMAKE as its configure/build tool. 2. Cog uses VMMaker.oscog as its simulation base, code generator and seems to be transitioning to a GNU Make environment. 2.a . An SVN repository exists with generated code for cog, stackinterpreter, newspeak....this does not seem to be kept in sync with 2 but I am not sure. I forget why I came to that conclusion. 3. The Pharo team uses VMMaker-oscog (note the 'dash' vs the 'dot' in 2) When referring to VM/ObectMemory pairs, I use the following terminology 1. standardVM32 (32 bit runtime vm [requires compat libs on my platform] powering a 32 bit image) 2. standardVM32x64 (32 bit runtime vm [requires compat libs on my platform] powering a 64 bit image) 3. standardVM64x32 (64 bit native runtime vm powering a 32 bit image) 4. standardVM64x64 (64 bit native runtime vm powering a 64 bit image) 5. stackVM32 6. stackVM64 7 stackVM64x64 8. cogVM32 (what we all know and love) 9 cogVM64 (not implemented yet) 10. cogVM64x64 (a gleam in some enterprising coders eye) 11. cogSpur....??? .. 99. cogQ (cog running on quantum bits platform j.k. (: I have successfully build from first principles 1. standardVM64x32 , 2. standardVM64x64 , 3. stackVM32 (both SVN source and generated code using VMMaker.oscog), 4. cogVM32 (from SVN source only. I have had issues generating source from VMMaker.oscog) Now, 1 and 2 are not my doing. This is all because CMake somehow detects my platform and generates a pure 64 bit VM without me having to do a thing. 2 has two "idioms" for obtaining a 64 bit image--download from Jenkins one or roll your own using a tool Daniel devised named SystemTracer. My next goal is StackVM64, however, I am taking a detour to learn plugins before I tackle that. I also have to overcome the generate Cog Sources hurdle for this plugin work. When I do get to working on a StackVM64, I am curious as to a couple of things. 1. Why does the CMAKE build a native 64 bit application and the GNU Make not? 2. Is a first step to emulate in the GNU Make what Cmake does? 3. Is the above a "real" 64 bit app in that it makes use of the full register size? or is it something else. 4. ...? Anyway that is my thinking to date. cheers. tty ---- On Tue, 01 Apr 2014 21:24:30 -0700 <phil(a)highoctane.be> wrote ---- How would that work? Would this be a 32 bit Object memory and engine compiled in 64bit mode? How is the code amended to make that possible? Is there a source tree somewhere? There are "int"s all over the place, so, how do we handle this? For the Slang part it appears doable. For the support code, especially Windows, it looks harder. TIA Phil Le 2 avr. 2014 01:07, "Clément Bera" <bera.clement(a)gmail.com> a écrit : Hey, For 64 bits Spur is a big step forward. For Christmas you should have at least the stack VM in 64bits. The JIT may take a bit longer to port. Esteban and Eliot will work on that starting from May. There's also the solution to compile the VM in 64bits with a 32bits runtime (I think FFI does not work, but the VM works in 64bits environment, as gettimothy posted on vm-dev). 2014-03-29 13:18 GMT-07:00 Pharo4Stef <pharo4Stef(a)free.fr>: On 29 Mar 2014, at 21:16, Roelof Wobben <r.wobben(a)home.nl> wrote: > Pharo4Stef schreef op 29-3-2014 21:07: >> >> >>> Pity. >> >> You know there is no magic powder. We are already really grateful that eliot is pushing the vm work. >> Esteban will help on the 64 bits and clement probably too or spur and new bytecodes plus language side optimisations. If we could pay 3 full time engineers in the future… but this is not the case. >> > > I know that and it's not that i think the developer do a bad job. > It's more a expresiion of my feeling. Ok then I share the same feeling :) > > Roelof >

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

VM-beginners April 2014