Thanks to both. Indeed, you were right. I was following Igor's slides for Deep Smalltalk and he was using version 1.3

Now, I have a couple of questions:

1) Who commits to the blessed Cog repo?

2) The guy that does 1) also takes care of updating ConfigurationOfCog ?

So, what I want to know is , if I always download the latest from git, and the late version of ConfigurationOfCog, the VM should "compile and works", shouldn't it ? REALLY having the platform code in sync with ConfigurationOfCog is something what I would love to have. So far seems to work :)

Cheers

Mariano

On Wed, Mar 30, 2011 at 3:26 AM, Igor Stasenko siguctua@gmail.com wrote:

On 29 March 2011 23:28, Mariano Martinez Peck marianopeck@gmail.com wrote:

...

I started once again having bad luck compiling VMs....I did

git clone git://gitorious.org/cogvm/blessed.git

then I download a PharoCore1.3 fresh and I evaluated:

Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfCog'; load. (ConfigurationOfCog project version: '1.3') load

Use LoadVMMaker.st which is in codegen-scripts directory. It should load 1.5 version.

...

Gofer new squeaksource: 'VMMaker'; package: 'CMakeVMMaker'; load.

Then I moved the image to /blessed/image

Then I evaluated: CogMacOSConfig generateWithSources

And finally, cmake .

And I have this error:

In file included from

/Users/mariano/bin/blessed/platforms/unix/vm/sqUnixThreads.c:18:

...

/Users/mariano/bin/blessed/platforms/Cross/vm/sq.h:182: warning: ignoring

#pragma auto_inline off

...

/Users/mariano/bin/blessed/platforms/Cross/vm/sq.h:184: warning: ignoring

#pragma auto_inline on

...

Linking CXX executable CogVM.app/Contents/MacOS/CogVM Undefined symbols: "_ifValidWriteBackStackPointersSaveTo", referenced from: _reportStackState in sqMacMain.c.o _reportStackState in sqMacMain.c.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [CogVM.app/Contents/MacOS/CogVM] Error 1 make[1]: *** [CMakeFiles/CogVM.dir/all] Error 2 make: *** [all] Error 2

any hints?

thanks

Mariano

-- Best regards, Igor Stasenko AKA sig.

On 30 March 2011 10:31, Mariano Martinez Peck marianopeck@gmail.com wrote:

Thanks to both. Indeed, you were right. I was following Igor's slides for Deep Smalltalk and he was using version 1.3

Now, I have a couple of questions:

1. Who commits to the blessed Cog repo?

Right now is me, Esteban and Eliot (via SVN).

2. The guy that does 1) also takes care of updating ConfigurationOfCog ?

ConfigurationOfCog contains exact versions of all packages needed to load. So, if you change something and upload new package version, you also have to create a new configuration which corresponds to new version(s) of packages.

So, what I want to know is , if I always download the latest from git, and the late version of ConfigurationOfCog, the VM should "compile and works", shouldn't it ? REALLY having the platform code in sync with ConfigurationOfCog is something what I would love to have. So far seems to work :)

Cheers

Mariano

On Wed, Mar 30, 2011 at 3:56 PM, stephane ducasse < stephane.ducasse@gmail.com> wrote:

but why (ConfigurationOfCog project version: '1.3') load does not work?

because it has versions of VMMaker that doesnt match with the latest in git. So, if today you load the latest from git, and using 1.3, you cannot compile

Stef

On Mar 30, 2011, at 2:01 PM, Igor Stasenko wrote:

...

On 30 March 2011 10:31, Mariano Martinez Peck marianopeck@gmail.com

wrote:

...

...

Thanks to both. Indeed, you were right. I was following Igor's slides

for Deep Smalltalk and he was using version 1.3

...

...

Now, I have a couple of questions:

1. Who commits to the blessed Cog repo?

Right now is me, Esteban and Eliot (via SVN).

...

2. The guy that does 1) also takes care of updating ConfigurationOfCog ?

ConfigurationOfCog contains exact versions of all packages needed to load. So, if you change something and upload new package version, you also have to create a new configuration which corresponds to new version(s) of packages.

...

So, what I want to know is , if I always download the latest from git,

and the late version of ConfigurationOfCog, the VM should "compile and works", shouldn't it ?

...

...

REALLY having the platform code in sync with ConfigurationOfCog is

something what I would love to have. So far seems to work :)

...

...

Cheers

Mariano

-- Best regards, Igor Stasenko AKA sig.

On 30 March 2011 16:00, Mariano Martinez Peck marianopeck@gmail.com wrote:

On Wed, Mar 30, 2011 at 3:59 PM, Mariano Martinez Peck marianopeck@gmail.com wrote:

...

On Wed, Mar 30, 2011 at 3:56 PM, stephane ducasse stephane.ducasse@gmail.com wrote:

...

but why (ConfigurationOfCog project version: '1.3') load does not work?

because it has versions of VMMaker that doesnt match with the latest in git. So, if today you load the latest from git, and using 1.3, you cannot compile

What I mean is that there could have been changes in the "platform" code, which is in git, and that the VMMaker expect those changes. If you load the last platform code from git, it has those changes. But if you load an old version of VMMaker, then it expects "older" platform code.

Exactly. And LoadVMMaker.st script placed there exactly for eliminating the problems when you unable to determine which VMMaker version works with given sources snapshot.

This is a link between git snapshot and sources which stored outside of it (in SqS/VMMaker or elsewhere). And by having this link, we can reproduce an image and then generate source files, so we don't need to put a generated sources under source-control anymore.

On 30 March 2011 16:51, Mariano Martinez Peck marianopeck@gmail.com wrote:

On Wed, Mar 30, 2011 at 4:19 PM, Igor Stasenko siguctua@gmail.com wrote:

...

On 30 March 2011 16:00, Mariano Martinez Peck marianopeck@gmail.com wrote:

...

On Wed, Mar 30, 2011 at 3:59 PM, Mariano Martinez Peck marianopeck@gmail.com wrote:

...

On Wed, Mar 30, 2011 at 3:56 PM, stephane ducasse stephane.ducasse@gmail.com wrote:

...

but why (ConfigurationOfCog project version: '1.3') load does not work?

because it has versions of VMMaker that doesnt match with the latest in git. So, if today you load the latest from git, and using 1.3, you cannot compile

What I mean is that there could have been changes in the "platform" code, which is in git, and that the VMMaker expect those changes. If you load the last platform code from git, it has those changes. But if you load an old version of VMMaker, then it expects "older" platform code.

Exactly. And LoadVMMaker.st script placed there exactly for eliminating the problems when you unable to determine which VMMaker version works with given sources snapshot.

WOW. That's awesome. I didn't know about that.

Heh.. i were talking about that from very starting ;)

Last thing...instead of havign to load an specific version of CMake by hand....why not integrate such package under ConfigurationOfCog ?

Because i not quite handy with Metacello. I using metacello as a trained monkey. :) I just took what was already there and modified it a bit to make sure it loads without errors into pharo images.

if you don't want  to put it in the default group, no problem, but at lesat you can define a new group like 'VMakerWithCmake' so that we can do:

((Smalltalk at: #ConfigurationOfCog) project     version: '1.5') load: 'VMakerWithCmake'.

and that's all :)

So, if you know how to do that, please do. And i will happily integrate it.

I'd like to note to everyone:

- an automated build process works, but its not perfect. (but its much better than we had before ;)

So, a criticism and help or ideas how to improve it is welcome.

Another idea is to put in the #description of each version of ConfigurationOfCog, which is the expected version of git to work. I used to do this wtih SVN and ConfogurationOfVMMaker. this way we can map from the other side ;) even more...in the description you can directlty put which sohuld be the git command.

Well, that will be unnecessary, because multiple git snapshots may work with same configuration. (You may fix or change some platform code, which not requires any changes on VMMaker side).

This means that my scheme keeps correspondence in direction source => VMMaker

in that way for each source snapshot you know which version of VMMaker you should use. But not in reverse order.

cheers

Mariano

...

This is a link between git snapshot and sources which stored outside of it (in SqS/VMMaker or elsewhere). And by having this link, we can reproduce an image and then generate source files, so we don't need to put a generated sources under source-control anymore.

-- Best regards, Igor Stasenko AKA sig.

On 30 March 2011 20:11, Mariano Martinez Peck marianopeck@gmail.com wrote:

...

...

((Smalltalk at: #ConfigurationOfCog) project     version: '1.5') load: 'VMakerWithCmake'.

and that's all :)

So, if you know how to do that, please do. And i will happily integrate it.

Find the ConfigurationOfCog attached. As an example, I've created the version 1.6 and baseline 1.4

Notice that in the baseline I added:

spec repository: 'http://www.squeaksource.com/VMMaker';               package: 'CMakeVMMaker' with: [spec requires: #('Cog') ] .

and in the version I added:

package: 'CMakeVMMaker' with: 'CMakeVMMaker-IgorStasenko.51'.

So...for new versions, the only thing you will need to do is to set that version, just the same you do with the rest.

So..this:

Gofer new     squeaksource: 'MetacelloRepository';     package: 'ConfigurationOfCog';     load.

((Smalltalk at: #ConfigurationOfCog) project     version: '1.5') load.

((MCHttpRepository     location: 'http://www.squeaksource.com/VMMaker' user: '' password: '') versionFromFileNamed: 'CMakeVMMaker-IgorStasenko.51.mcz') load.

now is reduced to:

Gofer new     squeaksource: 'MetacelloRepository';     package: 'ConfigurationOfCog';     load.

((Smalltalk at: #ConfigurationOfCog) project     version: '1.5') load.

Nice. Thanks.

...

I'd like to note to everyone:

- an automated build process works, but its not perfect. (but its much better than we had before ;)

So, a criticism and help or ideas how to improve it is welcome.

...

Another idea is to put in the #description of each version of ConfigurationOfCog, which is the expected version of git to work. I used to do this wtih SVN and ConfogurationOfVMMaker. this way we can map from the other side ;) even more...in the description you can directlty put which sohuld be the git command.

Well, that will be unnecessary, because multiple git snapshots may work with same configuration.

The same the other way arround ;) The same VMMaker version can work with different git snapshos

...

(You may fix or change some platform code, which not requires any changes on VMMaker side).

or vice-versa

...

This means that my scheme keeps correspondence in direction source => VMMaker

but why not adding  VMMaker -> source also ?

how you suppose to do that? In configs then you need to put an array of git commits which working with your config? Or what?

And then i will be forced to commit sources to git, while configuration of it to load is not there yet (because only after commit i can get an url to these sources and then put it into config and finally upload new config to squeaksource).

It looks a bit complicated, isnt? And extra manual work..

...

in that way for each source snapshot you know which version of VMMaker you should use. But not in reverse order.

So..you don't like it ? ;) no problem :)

On Thu, Mar 31, 2011 at 9:30 AM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:

On Wed, Mar 30, 2011 at 11:52 PM, Igor Stasenko siguctua@gmail.comwrote:

...

On 30 March 2011 20:11, Mariano Martinez Peck marianopeck@gmail.com wrote:

...

...

...

((Smalltalk at: #ConfigurationOfCog) project version: '1.5') load: 'VMakerWithCmake'.

and that's all :)

So, if you know how to do that, please do. And i will happily integrate it.

Find the ConfigurationOfCog attached. As an example, I've created the version 1.6 and baseline 1.4

Notice that in the baseline I added:

spec repository: 'http://www.squeaksource.com/VMMaker'; package: 'CMakeVMMaker' with: [spec requires: #('Cog') ] .

and in the version I added:

package: 'CMakeVMMaker' with: 'CMakeVMMaker-IgorStasenko.51'.

So...for new versions, the only thing you will need to do is to set that version, just the same you do with the rest.

So..this:

Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfCog'; load.

((Smalltalk at: #ConfigurationOfCog) project version: '1.5') load.

((MCHttpRepository location: 'http://www.squeaksource.com/VMMaker'

user:

...

'' password: '') versionFromFileNamed: 'CMakeVMMaker-IgorStasenko.51.mcz') load.

now is reduced to:

Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfCog'; load.

((Smalltalk at: #ConfigurationOfCog) project version: '1.5') load.

Nice. Thanks.

...

...

I'd like to note to everyone:

• an automated build process works, but its not perfect. (but its

much better than we had before ;)

So, a criticism and help or ideas how to improve it is welcome.

...

Another idea is to put in the #description of each version of ConfigurationOfCog, which is the expected version of git to work. I

used

...

...

...

to do this wtih SVN and ConfogurationOfVMMaker. this way we can map from the other side ;) even more...in the description you can directlty put which sohuld be

the

...

...

...

git command.

Well, that will be unnecessary, because multiple git snapshots may work with same configuration.

The same the other way arround ;) The same VMMaker version can work with different git snapshos

...

(You may fix or change some platform code, which not requires any changes on VMMaker side).

or vice-versa

...

This means that my scheme keeps correspondence in direction source => VMMaker

but why not adding VMMaker -> source also ?

how you suppose to do that? In configs then you need to put an array of git commits which working with your config? Or what?

And then i will be forced to commit sources to git, while configuration of it to load is not there yet (because only after commit i can get an url to these sources and then put it into config and finally upload new config to squeaksource).

It looks a bit complicated, isnt? And extra manual work..

Yes, maybe. My thught was this procedure:

1. You commit on Git, and it you get version XXX. This changes on Git needs

changes on VMMaker so: 2) You create a new version of ConfigurationOfCog. Let's say YYY. In that moment, that version is blessed with #development and in the descript you put something like saying that it should work with Git versions > XXX. Example:

versionYYY: spec <version: 'YYY' imports: #('1.4-baseline') >

spec for: #common do: [
    spec blessing: #development.
    spec description: 'Should be used with Git version > XXX'.
    spec
        package: 'FFI-Pools' with: 'FFI-Pools-eem.3';
        package: 'SharedPool-Speech' with: 'SharedPool-Speech-dtl.2';
        package: 'Balloon-Engine-Pools' with:

'Balloon-Engine-Pools-JB.2'; package: 'Qwaq-VMProfiling-Plugins' with: 'Qwaq-VMProfiling-Plugins-JB.5'; package: 'Sound' with: 'Sound-StephaneDucasse.62'; package: 'VMMaker-oscog' with: 'VMMaker-oscog-IgorStasenko.54'; package: 'Alien-Core' with: 'Alien-Core-IgorStasenko.68'; package: 'Cog' with: 'Cog-eem.44'; package: 'CMakeVMMaker' with: 'CMakeVMMaker-IgorStasenko.51.mcz'. ].

3. when there is a new commit ZZZ in git that requires a new version of

VMMaker, then you: 3.a) close the previous version (you put blessing:#version) 3.b) change the description so that it closes the range.

Example:

versionYYY: spec <version: 'YYY' imports: #('1.4-baseline') >

spec for: #common do: [
    spec blessing: #release.
    spec description: 'Should be used with Git  version > XXX nad < ZZZ

'. spec package: 'FFI-Pools' with: 'FFI-Pools-eem.3'; package: 'SharedPool-Speech' with: 'SharedPool-Speech-dtl.2'; package: 'Balloon-Engine-Pools' with: 'Balloon-Engine-Pools-JB.2'; package: 'Qwaq-VMProfiling-Plugins' with: 'Qwaq-VMProfiling-Plugins-JB.5'; package: 'Sound' with: 'Sound-StephaneDucasse.62'; package: 'VMMaker-oscog' with: 'VMMaker-oscog-IgorStasenko.54'; package: 'Alien-Core' with: 'Alien-Core-IgorStasenko.68'; package: 'Cog' with: 'Cog-eem.44'; package: 'CMakeVMMaker' with: 'CMakeVMMaker-IgorStasenko.51.mcz'. ].

And then of course, you create the new version if ConfigurationOfCog, let's say NNN

versionNNN: spec <version: 'NNN' imports: #('1.4-baseline') >

spec for: #common do: [
    spec blessing: #development.
    spec description: 'Should be used with Git  version > ZZZ '.
    spec
        package: 'FFI-Pools' with: 'FFI-Pools-eem.3';
        package: 'SharedPool-Speech' with: 'SharedPool-Speech-dtl.2';
        package: 'Balloon-Engine-Pools' with:

'Balloon-Engine-Pools-JB.2'; package: 'Qwaq-VMProfiling-Plugins' with: 'Qwaq-VMProfiling-Plugins-JB.5'; package: 'Sound' with: 'Sound-StephaneDucasse.62'; package: 'VMMaker-oscog' with: 'VMMaker-oscog-IgorStasenko.54'; package: 'Alien-Core' with: 'Alien-Core-IgorStasenko.68'; package: 'Cog' with: 'Cog-eem.44'; package: 'CMakeVMMaker' with: 'CMakeVMMaker-IgorStasenko.51.mcz'. ].

and like that....

What do you think? If you really understand it, it is not hard. It seems quite easy for me and it gives us even more traceability.

Cheers

Mariano

...

...

...

in that way for each source snapshot you know which version of VMMaker you should use. But not in reverse order.

-- Best regards, Igor Stasenko AKA sig.