Hi Timothy,

On Tue, May 27, 2014 at 5:01 AM, gettimothy gettimothy@zoho.com wrote:

Hi Eliot

...

a and ast are prefixes for assert. There are three VM configurations.

Debug and Assert include assert code, with the Assert VMs being optimized with -O1 (asserts are slow to evaluate and a little optimization can really help). Debug VMs are entirely unoptimized (and hence crawl). >The third is production where asserts are eliminated by the preprocessor.

...

Obviously I should be consistent and withe ruse a or ast, not both (and

the same for d/bg). *I'm about to revise the whole build directory stricture anyway to make it much more consistent, but I've yet to find the time.*

If you have time to give me that naming convention, I will build that directory structure for you and send it to you as a tarball, complete with the existing files so it saves you some time there.

That's a fabulous offer. Thanks.

I was thinking the right way to do this is to a) have all the build directories at the same level (right now some the Cog builds are in Cog/macbuild et al but every other build is one or two levels down, e.g. unixbuild/bld nscogbuild/linuxbuild/bldt) b) have a consistent naming to ease the writing of scripts c) try and keep the hierarchy shallow to avoid lots of ../../../paths

But a) isn't possible given the current autoconf layout. On unix using autoconf one has to have an additional level to accomodate the production, assert and debug ("pad") builds.

So...

At the top level have a build.OS/WordSize/Processor directory, which means currently

build.win32x86 build.macosx32x86 build.linux32x86

If CMake makes it possible and convenient to create the three "pad" builds in build.linux32x86 then fine. e.g. on mac there's a CoreVM.xcode alongside a CoreMTVM.xcode and they create Assert.app AssertMT.app et al, and on cygwin the one makefile cygwinbuild/Makefile creates build buildmt builddbg et al. Otherwise I suppose one could add

build.linux32x86dbg build.linux32x86ast

or just buckle under and use

build.linux32x86/bulld build.linux32x86/build.assert etc

? But I much prefer the single directory and then issue different make commands to get the different versions: make make assert make debug

Then in each non-autoconf build directory have a lang/vmarch/mmarch directory, where lang is either squeak or newspeak, vmarch is either stack, cog or sista, and mmarch is either v3 (the current ObjectMemory) or spur. Hence:

squeak.stack.v3 squeak.stack.spur squeak.cog.v3 squeak.cog.spur squeak.sista.v3 squeak.sista.spur newspeak.stack.v3 newspeak.stack.spur newspeak.cog.v3 newspeak.cog.spur newspeak.sista.v3 newspeak.sista.spur

Then there would be a single HowToBuild in each top-level build dir explaining how to build on that platform.

...

The "t" suffix is for "threaded" and means that these VMs have the

threaded heartbeat, with the others using the problematic itimer heartbeat. Alas older linux kernels don't allow the threaded heartbeat, but once we're not interested in supporting older then 2.6.14 (IIRC) then they can be dropped.

Is 'mt' is that the same as 't' ?

No. mt stands for multi-threaded, the experimental non-blocking FFI VM.

Again on win32 under cygwin and on mac os x under xcode it is easy to keep the non-mt and mt builds at the same level, sharing a directory.

Hope this isn't entirely opaque.

Hi Eliot,

I have condensed your email into somewhat of a bullet points version. I do have one concern and that is newbie-end-user ease of use. I list my concerns and comments in italics among your points.

There are three VM configurations. Assert configurations include assert code with -01 optimization Debug configurations include assert code with no optimization. Production has asserts removed by the preprocessor.

a and ast are prefixes for assert. d and dbg are prefixes for debug. t suffix is for "threaded" and means that these VMs have the threaded heartbeat, with the others using the problematic itimer heartbeat. mt stands for multi-threaded, the experimental non-blocking FFI VM.

You much prefer a top level build.OS/WordSize/Processor directory with a HowToBuild file that handles make, make debug and make assert builds.

build.win32x86 build.macosx32x86 build.linux32x86 Sounds good.

I propose a build.linux32x86_64 to handle the special case of building agianst 32 bit compat libs on debian/slackware. Yes, it can be done in the x86 directory, but consider the newbie end user who wants to get up and running hacking vm's quickly.

I also propose a parallel cmake_build.OS/WordSizeProcessor tree to minimize confusion and traps while we get our heads around and learn the idiosyncracies of CMake.

cmake_build.win32x86 cmake_build.macosx32x86 cmake_build.linux32x86 cmake_build.linux32x86_64

I will also re-name the CMakeVMMakerSqueak XYZConf classes to SqueakBuildWin32x86Conf SqueakBuildMacOsX32x86Conf etc so there is a one-to-one corresponsdence between the default configuration and its directory. (Customizations can be subclassed off of these defaults and routed whereever by the developer if needed)

If CMake makes it possible and convenient to create the three "pad" builds in build.linux32x86 then fine. e.g. on mac there's a CoreVM.xcode alongside a CoreMTVM.xcode and they create Assert.app AssertMT.app et al on cygwin the one makefile cygwinbuild/Makefile creates build buildmt builddbg et al.

I don't know. The current pharo/squeak structure just specifies where the build directory is. Different configurations overwrite what is in the existing directory.

I Did a quick search, I ran into this: http://stackoverflow.com/questions/7724569/debug-vs-release-in-cmakeSo, I guess the answer is "yes" but it has not been implemented. I will try.

Then in each non-autoconf build directory have a lang/vmarch/mmarch directory lang is either squeak or newspeak, vmarch is either stack, cog or sista, and mmarch is either v3 (the current ObjectMemory) or spur. Hence: [squeak|newspeak][stack |cog | sista |][v3 | spur] [2!]x[3!]x[2!] = 24 directories squeak.stack.v3 squeak.stack.spur squeak.cog.v3 squeak.cog.spur squeak.sista.v3 squeak.sista.spur newspeak.stack.v3 newspeak.stack.spur newspeak.cog.v3 newspeak.cog.spur newspeak.sista.v3 newspeak.sista.spur

Then there would be a single HowToBuild in each top-level build dir explaining how to build on that platform.

Again on win32 under cygwin and on mac os x under xcode it is easy to keep the non-mt and mt builds at the same level, sharing a directory.

I am a bit confused here. Are these top-level directories at the same level as build.os.wordsize.platform? i.e:

build.linux32x86/ ... squeak.stack.v3 ...

or are they sub-directories of it? i.e

... build.linux32x86/squeak.stack.v3 ...

Cheers.

tty

Hi Eliot

>>The latter. Each top-level build directory corresponds to a host architecture (OS, processor, word size). Within each top-level build directory are all the variants of VMs that we can build. That fills out the 2d grid of os/processor vs VM variant.

Awesome.

Expect a skeleton for you to preview on my svn server later today.

I will then fill-in-the blanks.

Cordially,

t

Hi Timothy,

On Wed, May 28, 2014 at 10:39 AM, gettimothy gettimothy@zoho.com wrote:

Hi Eliot.

During my development, I would like to keep my existing top level oscogvm directory under Contents/Resources

Contents/Resources/oscogvm

For this new tree, I need something else.

Contents/Resources/???.

Do you have any preferences?

No preference. It's up to you. But I'm curious; why are you putting it in an app?

thx.

tty

Hello gettimothy,

If you want to integrate the Pharo build, here is the script I use to build the VM (I use this script since I built first the Pharo VM in 2012)

git clone --depth=1 https://github.com/pharo-project/pharo-vm.git cd pharo-vm cd image ./newImage.sh ./pharo generator.image eval 'PharoVMBuilder buildMacOSX32' cd ../build bash build.sh

Then the VM is in results folder.

newImage.sh creates a generator.image (Now we have that for the Cog branch as Eliot added it when I was visiting him in May). build.sh consists basically in calling cmake then make:

#!bash if [ ! -e vmVersionInfo.h ]; then ../codegen-scripts/extract-commit-info.sh fi cmake . make make install

Now your process is not as easy at it looks like. I know you are aware but compiling the VM requires people to install different softwares (typically git, cmake, wget, Xcode command line tools for me on Mac) and for the Pharo build, it requires CLang which is fine but I am not able to build from Eliot sources which requires gcc.

So I think your app should in addition check depending on the platform (windows, Linux, Mac OS X, RISC OS) if everything required to compile the VM is installed, and else install it automatically.

The best would be to try to compile the VM on a freshly installed computer so you can know if it installs everything that is needed.

Keep going with this great work :-)

Regards,

Clément

2014-05-28 23:34 GMT+02:00 gettimothy gettimothy@zoho.com:

...

...

No preference. It's up to you. But I'm curious; why are you putting it

in an app?

As I do one gnu-build tree, I am going to do its corresponding CMake tree.

The CMake configuration files are generated from Squeak.

It would be like GNU makefiles and autoconf files are generated from Squeak.

Process is like this:

1. have a directory structure.
2. Tell CMakeVMMakerSqueak to generate which creates the CMake

infrastructure within the specified directory. (Or generateWithSources to create VMMaker sources and CMake files) 3. from the command line, run the generated buils script 'build.sh' which 3.a (on pharo, does some git stuff) 3.b invokes cmake 3.c invokes make 4. get your results out of the oscogvm/results directory.

If everything is stable, the end user just does a svn co of the cmake branch they want and invokes the build.sh script. <---THIS is what Tim R. wants as the deliverable

I have another process in place for vm developers similar to your buildsqueaktrunk.sh scripts. I sent you those scripts last week. They set you up with either a standard VM build environment (complete with source tree set up relative to Squeak) or a CogVM build environment. The idea being to make it easy on newbie vm guys to get up and running.

Cheers

tty

Hi Nicolas

I was not aware of Clement's headless technique, so current implementation requires invoking SqueakCMakeVMMaker configs or builders from a live image.

Since we need the various configurations in place before going headless, I will focus on that first. (Also, I am not that bright and I need to keep things simple for my simple brain (: )

Also, on Squeak, I have stripped the build.sh to only run cmake and make without installing tools(?) first like the pharo build.sh does. Let's save that for another interation.

What would be totally-freaking awesome is to have something like Twitter Bootstrap has has where you select your platform, vm, plugins, etc then if a vm of that configuration is available you are given a download link. Or, if it does not exist already (think lazy initialization) then a job kicks off and it is created for you, then an email is sent with the download link. For that sort of thing (and others) the scripts are the way to go.

But, first things first.

Cordially,

tty

Hi Clement.

Although Eliot has not submitted to SVN on Squeak yet. I have implemented that functionality for squeak and emailed him a tarball with the scripts etc. (although I have not done the headless version that you demonstrate--that looks good)

Eliot has similar scripts in Cog/image directory that do some of the work you describe, but they are not as advanced.

Cheers,

tty

---- On Thu, 29 May 2014 01:01:40 -0700 Clément Bera&lt;bera.clement@gmail.com&gt; wrote ----

Hello gettimothy,

If you want to integrate the Pharo build, here is the script I use to build the VM (I use this script since I built first the Pharo VM in 2012)

git clone --depth=1 https://github.com/pharo-project/pharo-vm.git cd pharo-vm cd image ./newImage.sh

./pharo generator.image eval 'PharoVMBuilder buildMacOSX32'

cd ../build bash build.sh

Then the VM is in results folder.

newImage.sh creates a generator.image (Now we have that for the Cog branch as Eliot added it when I was visiting him in May). build.sh consists basically in calling cmake then make:

#!bash

if [ ! -e vmVersionInfo.h ]; then

../codegen-scripts/extract-commit-info.sh

fi

cmake .

make

make install

Now your process is not as easy at it looks like. I know you are aware but compiling the VM requires people to install different softwares (typically git, cmake, wget, Xcode command line tools for me on Mac) and for the Pharo build, it requires CLang which is fine but I am not able to build from Eliot sources which requires gcc.

So I think your app should in addition check depending on the platform (windows, Linux, Mac OS X, RISC OS) if everything required to compile the VM is installed, and else install it automatically.

The best would be to try to compile the VM on a freshly installed computer so you can know if it installs everything that is needed.

Keep going with this great work :-)

Regards,

Clément

2014-05-28 23:34 GMT+02:00 gettimothy &lt;gettimothy@zoho.com&gt;:

&gt;&gt;No preference. It's up to you. But I'm curious; why are you putting it in an app?

As I do one gnu-build tree, I am going to do its corresponding CMake tree.

The CMake configuration files are generated from Squeak.

It would be like GNU makefiles and autoconf files are generated from Squeak.

Process is like this:

1. have a directory structure. 2. Tell CMakeVMMakerSqueak to generate which creates the CMake infrastructure within the specified directory. (Or generateWithSources to create VMMaker sources and CMake files) 3. from the command line, run the generated buils script 'build.sh' which 3.a (on pharo, does some git stuff) 3.b invokes cmake 3.c invokes make 4. get your results out of the oscogvm/results directory.

If everything is stable, the end user just does a svn co of the cmake branch they want and invokes the build.sh script. &lt;---THIS is what Tim R. wants as the deliverable

I have another process in place for vm developers similar to your buildsqueaktrunk.sh scripts. I sent you those scripts last week. They set you up with either a standard VM build environment (complete with source tree set up relative to Squeak) or a CogVM build environment. The idea being to make it easy on newbie vm guys to get up and running.

Cheers

tty

&gt;&gt;Although Eliot has not submitted to SVN on Squeak yet. I have implemented that functionality for squeak and emailed him a tarball with the scripts etc.

&gt;Yes I did, yesterday evening. See rev 2932.

Awesome,

thx.

Hi Ben.

For the CMakeVMMakerSqueak, these names are in a Trait TCPlatformConfigForSqueak

A configuration is reponsible for providing it's directories/etc.

Changing those will be as easy as modifying a method in the Trait:

dirMacOSX32x86 ^'cmake_build.macosx32x86'

We can address this during a late refactoring pass after initial release.

I do agree with your ideas.

cheers.

tty