add Pharo-2.0 as environment

[dalehenrich]

need to get Metacello scripting api working there first

[dalehenrich]

tests won't be passing until bug in Pharo-2.0 fixed to allow progress on Metacello port, but I can get the infrastructure in place

[dalehenrich]

need to add new Cog vm for Pharo-2.0 then undo commit

[dalehenrich]

need to fix FileTree issue 52

[dalehenrich]

newest Cog vm added

[dalehenrich]

Pharo-2.0 implementation poised... FileTree issue 52

[dalehenrich]

for Pharo-2.0 need to use FileSystem instead of FileTree ... have to scrub the scripts ...

[dalehenrich]

clean builds ... time to merge issue_12 back into the master

[frankshearar]

I just took this branch for a spin and you can see the results here. Progress! New error!

./build.sh: line 198:  2254 Killed
exec "$PHARO_VM" $PHARO_PARAM "$OUTPUT_IMAGE" "$OUTPUT_SCRIPT

It looks at first glance like a kill-cos-it-took-too-long?

[dalehenrich]

Actually it turns out that phar2.0 shouldn't be run in the background (talked to Cami and Esteban during ESUG), but there are other issues with 2.0 that should be cleaned up by the end of next week, so I'll wait til then to try again:)

[dalehenrich]

In order to stay sane, I think that I will have to create a branch for pharo2.0 ... need a new vm (and who know s how often one will be needed) a bunch of the scripts have to change ... better off isolating all of this stuff in a separate branch ... then I can simplify a bunch of the scripts where FileSystem/FileDirectory stuff already filtered in

[dalehenrich]

Metacello port to Pharo2.0 stalled again ...

[dalehenrich]

@demary, check out this green Pharo-2.0 test!

We are very close! Good effort!

[dalehenrich]

all platforms green, including Pharo2.0 ... call this one closed

[dalehenrich]

see https://github.com/dalehenrich/metacello-work/pull/161 ... we need a set of FileSystem/FileDirectory compat methods that can be used in scripts to do file/directory manipulations in a platform independent manner ...

[frankshearar]

This problem would show up like this?

===============================================================================
Notice: Errors in script loaded from /home/travis/dalehenrich-builderCI-1554a6e/builds/travisCI/travisCI.st
===============================================================================
==== Startup Error: MessageNotUnderstood: receiver of "default" is nil
UndefinedObject(Object)>>doesNotUnderstand: #default

[frankshearar]

Camillo Bruni wrote a shim that makes FileSystem expose a FileDirectory compatible API...

[dalehenrich]

I'm aware of Cami's (@dh83) shim class, but I need to be careful about limiting dependencies like that for builderCI ... the Pharo folks have gone to a lot of effort to eliminate FileDirectory from the image, but if all of a sudden builderCI re-introduces FileDirectory then tests against Pharo-2.0 won't fail if code inadvertantly references FileDirectory ... Consequently I've had to invent my own FileDirectory shims for each of my cross-platform projects ...

[camillobruni]

The compatibility package should not be used in any production environment. It's sole purpose is to easy migration in 2.0 from FileDirectory code to FileSystem code. BTW you should check what Sven did in Zinc, since he had to write a little compatibility layer himself.

[dalehenrich]

I did and came to the conclusion that I didn't want a dependency on Zinc's compatibility layer either ...

FileTree has it's own compat layer ...

Christophe and I created a set of compatibility methods in the MetacelloPlatform class for Metacello, but builderCI also needs a compatibility layer ... we started by using the MetacelloPlatform api, but the file manipulation code in a builderCI script can be hit before Metacello is loaded ...

So we will have to copy the methods from MetacelloPlatform and create a builderCI platform class ...

[dalehenrich]

Done for a bit ...