VM-beginners May 2014

vm-beginners@lists.squeakfoundation.org

2 participants
6 discussions

CMakeVMMakerSqueak ready for initial testing.
by gettimothy 23 May '14

23 May '14

Hi All I have set up my home computer/domain with svn for initial testing of the CMakeVMMakerSqueak stuff. svn co http://www.svn.menmachinesmaterials.com/Cog/Cog/ svn co http://www.svn.menmachinesmaterials.com/Cog/mcz The Cog branch is a co of Eliot's work from today. The mcz's are the code I have ported; upon acceptance I can move them up to squeak's site. cd Cog/image ./buildsqueakcmakeimage.sh -h (will get you usage. The script is a consolidation of Eliot's buildsqueakX.sh scripts) I have put in a README.buildsqueakcmakeimage.sh that may be of help. 1. Cog stuff is as follows (These will require you manually loading the CMakeVMMakerSqueak-tty-x.mcz from monticello for now. it will be automated should you choose to roll this live) ./buildsqueakcmakeimage.sh -c 4.5 (think "cog" for -c) sets up just like Eliot's buildsqueak45image.sh but includes the CMakeVMMaker currently at gemstone and adds a Workspace with some configurations) ./buildsqueakcmakeimage.sh -c 4.6 (same as above, but for 4.6 during my testing, this broke sometimes) Running the script will create a cogVMMaker directory. For now, copy the .mcz files from the svn co ..mcz... you did to the package_cache in cogVMMaker/Squeak-xyz.app/Contents/Resources/package_cache/ While you are in the neigborhood, cd to cogVMMaker/Squeak-xyz.app/Contents/Reources/oscogvm/ and do a ls. You should see some cmake_*build directories there. This is a parallel tree to the standard GNU stuff from which you will be running "source build.sh" to kick off the CMake builds. cd into cogVMMaker/Squeak-xyz.app/ there should be a squeakCogVMMaker.sh to run that will launch your new pre-configured image. launch Monticello and load the latest CMakeVMMakerSqueak-tty There should be a workspace titled CMakeVMMakerSqueak with some configurations scripts. Discussion of the code follows 2. below. 2. The StandardInterpreter stuff I did as a personal thing as I think I would have appreciated it as a newbie. For CMakeVMMakerSqueak, you can ignore it. for those interested. ./buildsqueakcmakeimage.sh -s 4.5 (think "standard" for -s) downloads and configures a Standard Interpreter VMMaker running on Squeak4.5 per the Wiki at http://wiki.squeak.org/squeak/6177 ./buildsqueakcmakeimage.sh -s 4.6 same as above, but on 4.6 (may be broken) ./buildsqueakcmakeimage.sh -b (think "both" for -b_ does 4.5 above plus the cog stuff explained below. once the script runs, change directory to the standardVMMaker/Squeak---.app/ and run the squeakStandardVMMaker.sh to launch the pre-configured image. There should be a workspace with instructions from there Like I say, the goal is to get a newbie up and running quickly. Please suggest changes improvements if you are interested. 3. Discussion of the CMMakeVMMakerSqueak classes. Due to the layout of the Pharo stuff in CMMakeVMMaker, I was not able to create a Squeak-only subclass tree of the configurations. Also, I realized late in the game that there are some false-starts in the pharo design involving the inconsistent use of Traits and Builders. This inconsistency is realized in the Squeak code as well. Regarding the traits, you will see some stupid stuff in SqueakStackUnixConfig (CMakeVMMakerSqueak-Unix category) where including the trait in the subclasses results in super calls to where the code is. Regarding the builders, you will see that if you start with the Unix stuff, a builder exists (and can be) utilized to power the configs. As the coding progressed, it became apparent that the builders are not necessary as the configs can be invoked directly. Ok, that's the yuck, lets get you rolling with this stuff. Running the pre-configred image you will see a CMakeVMMkaerSqueak workspace. Classes that end in Builder are builders and classes that end in Config are Platform Configurations Find your platform (unix, windows, mac, vax, pdp11...) under CMakeVMMakerSqueak-Platform and (usally) the first config is an "abstract" class (things get stupid in unix land due to the traits, but its not too embarassing). Under those top classes are concrete configs. Of note in them are the defaultExternalPlugins and defaultInternalPlugins methods. If you look at them you can see you can specify what you need/want. (it gets more flexible with other methods in subclasses, but its a good starting point) Pick the config you want (SqueakStackUnixDebugConfig in the examples below) and run one of two things: generate or generateWithSources. SqueakStackUnixDebugConfig generate will (very quickly) put the cmake config files in the Contents/Resources/oscogvm/cmake_*build directory corresponding to your platform (look for the buildDirName method on your superclass) you then cd to that directory and invoke the build.sh script and you should compile against the sources from the svn checkout. SqueakStackUnixDebugConfig generateWithSources invoked VMMaker to generate the sources before generating the CMake files as above. Finally, there are Builders that do the above, and frankly , I don't think we need them. For example in CMakeVMMakerSqueak-Builder SqueakStackVMBuilder buildSlackwareUnix64w32LibsNoGL you see the wrapper code that invokes the appropriate Config class. buildSlackwareUnix64w32LibsNoGL SqueakStackUnix64w32CompatLibsSlackwareNoGLConfig new addExternalPlugins: #( SqueakSSLPlugin ); addInternalPlugins: #( UnixOSProcessPlugin ); generateSources; generate. That should get things started. Other classes of interest are the CMakeVMMkaersqueak generators: CMakeVMGeneratorForSqueak and CMakePluginGeneratorForSqueak these are essentially a compatiblility layer for the generators I will leave my computer running tonight (I usually turn it off when I am away from it) My brain is a bit fried, so in-depth questions and discussions may have to wait until tomorrow. cheers. tty

1 0

Is B2DPlugin C code only?
by gettimothy 17 May '14

17 May '14

Hi All, I have checked high and low and cannot find B2DPlugin in Smalltalk, but it is in a lot of repositories. Is there such a thing as plugins without an internal smalltalk class? thx. tty

1 0

Progress report on CMakeVMMaker for Squeak
by gettimothy 11 May '14

11 May '14

Hi All. My work plan is to get a StackInterpreter running on Linux32 then Cog then the various permutations of Cog (MT, etc) I took a lazy day getting sources generated for SqueakStackVM and will be working on the 'generate' thing tomorrow. Hopefully I have some CMakeLists.text in place tomorrow. SqueakStackVMBuilder>>buildUnix32 SqueakStackUnixConfig new " internalPlugins: CMakePluginsArrayFactory minimalInternalPlugins;" internalPlugins: CMakePluginsArrayFactory unix32DefaultInternalPlugins; externalPlugins: CMakePluginsArrayFactory unix32DefaultExternalPlugins; generateSources; <---------GOT THROUGH HERE TODAY. generate. <---------I AM HERE TOMORROW. Cheers, tty

1 0

preferred methodology for handling Pharo'isms on Squeak?
by gettimothy 10 May '14

10 May '14

Hi All. Is there a preferred methodology for handling Pharo-isms on Squeak? I know Seaside has Grease which does some of that, but I don't thing we want Grease for CMakeVMMaker (or do we). Specifically, the Pharo team has abstracted out some stuff in SmalltalkImage (vm, platform..) that does not exist in Squeak. If there is an existing mechanism for bridging this gap, I will use it. In the meantime, I will be DTSTTCW. cordially, tty

2 1

CMMaker.oscog to fork or not to fork, that! is the question
by gettimothy 07 May '14

07 May '14

Hi Eliot and David and Tim. Tomorrow I start the actual Smalltalk coding of the CMake stuff for Squeak. (My shell script that I thought would take 1 day took 5. sigh) While I am leaning towards a fork of the CMMakeVMaker work on Pharo, I will defer to you folks on that decision. Below are notes I had made a week ago about why I was leaning that way. -----begin notes I made a week or so ago---- For development purposes I am leaning towards creating a CMakeVMMaker.oscog clone of the existing CMakeVMMaker and incrementally adding platform/interpreter configurations starting with the Stack Interpreter. Much of the work will be cut-n-paste modifications of the existing work in CMakeVMMaker done by the pharo team as that is the guts of the pharo system. The Pharo environment (very clean, btw) has three layers to it (from top down they are). 1. PharoVMMaker 2. CMakeVMMaker 3. Source Tree and scripts from github. What is very interesting about pharo is that given 3) a git checkout, you can download, run and configure a new pharo image using a shell script provided with the git source. Launching the resulting generator.image you are presented a workspace with scripts invoking 1) PharoVMMaker which is a "wrapper" or "interface" to 2) CMakeVMMaker. This generates the sources and CMake files and from there you go to the build directory and build I like this approach and will be emulating it, but I do not think it is integrate the Squeak infrastructure into the existing package; here is why. 1. Squeak source tree from svn is a superset of the tree from git with a slight difference in naming for the default build. Where Squeak has unixbuild, nssprucogbuild, etc, pharo just has build. This "probably" has implications for the CMMake script generation that will not suffice for supporting the standard interpreter nor for the other flavors Eliot is developing. 2. If I attempt to merge the two approaches (git and svn, pharo build tree and squeak build tree) it will clutter the very clean work-flow pharo has. 3. As I develop this, I would like the squeak community to test-drive what I do. It is not appropriate for me to muddy the existing CMakeVMMaker with dev work 4. Assuming I can actually do this thing, I do not think a merge of the two projects would be too difficult ---end notes I made a week or so ago--- Please let me know your decision. cordially, tty :

1 0

Has anybody done a successful Standard Interpreter build in Squeak 4.6?
by gettimothy 06 May '14

06 May '14

Howdy all. I am finishing up a "cmakify.sh" script that builds on the existing Cog/image/build*.sh scripts from http://www.squeakvm.org/svn/squeak/branches/Cog It works fine except the VMMakerTool for the old VMMaker (not VMMaker.oscog) running on 4.6 barfs whereas it works perfectly on 4.5. I am thinking it is not worth pursuing as 4.6 isn't being developed yet, but if by chance somebody has done a by-hand build of the old Standard Intepreter using the old VMMaker (Not VMMaker.oscog) on 4.6 I will investigate. thx. tty.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

VM-beginners May 2014