Hi,
Finally, with a lot of work, mana, power cards and jedi tricks, we made the pharo vm builds work again :) This builds are up-to-date with latest sources from Eliot's cog and adds pharo branding (AFAIK, this is the first time we are going to release something like that :) You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ Enjoy, Esteban & Igor |
On 2013-02-15, at 18:25, Esteban Lorenzano <[hidden email]> wrote: > Hi, > > Finally, with a lot of work, mana, power cards and jedi tricks, we made the pharo vm builds work again :) coool! I hope you kept trace of all the things you have to modify! > This builds are up-to-date with latest sources from Eliot's cog and adds pharo branding (AFAIK, this is the first time we are going to release something like that :) > > You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ I made it upload to the gforge again, so the latest builds we be there as well: http://pharo.gforge.inria.fr/ci/vm/pharo/ |
In reply to this post by EstebanLM
Cool! Downloaded the OSX one. Works!
Phil 2013/2/15 Esteban Lorenzano <[hidden email]>: > Hi, > > Finally, with a lot of work, mana, power cards and jedi tricks, we made the > pharo vm builds work again :) > > This builds are up-to-date with latest sources from Eliot's cog and adds > pharo branding (AFAIK, this is the first time we are going to release > something like that :) > > You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ > > Enjoy, > Esteban & Igor > |
Things you should know:
- all VMs including: OSProcess plugin SSL Plugin (bundled with ssl library for win32) NB Plugin Freetype (bundled with freetype library for win32 & mac) bundled with Cairo library (win32 & mac) linux VMs don't needs to be bundled, since you can install those libs from their corresponding distros. -- Best regards, Igor Stasenko. |
In reply to this post by EstebanLM
On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <[hidden email]> wrote:
Very good! So now we need to step by step.. -> use the build in the one-click -> link the VM zips on pharo-project.org -> replace the VM we use for running jobs on jenkins with this. And of course: -> test those builds on all three architectures automatically with a test image (e.g. current 2.0 with all failing tests removed) The idea is that this image should not change frequently (the only variable is the VM) -> only when this is green the zip is updated in the archive Marcus
|
In reply to this post by Igor Stasenko
thanks igor and esteban.
Stef On Feb 16, 2013, at 12:36 AM, Igor Stasenko <[hidden email]> wrote: > Things you should know: > > - all VMs including: > OSProcess plugin > SSL Plugin (bundled with ssl library for win32) > NB Plugin > Freetype (bundled with freetype library for win32 & mac) > bundled with Cairo library (win32 & mac) > > linux VMs don't needs to be bundled, since you can install those libs > from their corresponding distros. > > -- > Best regards, > Igor Stasenko. > |
In reply to this post by Marcus Denker-4
On 16 February 2013 10:24, Marcus Denker <[hidden email]> wrote:
> > On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <[hidden email]> wrote: > > Hi, > > Finally, with a lot of work, mana, power cards and jedi tricks, we made the > pharo vm builds work again :) > > This builds are up-to-date with latest sources from Eliot's cog and adds > pharo branding (AFAIK, this is the first time we are going to release > something like that :) > > You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ > > > Very good! > > So now we need to step by step.. > -> use the build in the one-click > -> link the VM zips on pharo-project.org > -> replace the VM we use for running jobs on jenkins with this. > > And of course: > -> test those builds on all three architectures automatically with a test > image (e.g. current 2.0 with all failing tests removed) > The idea is that this image should not change frequently (the > only variable is the VM) > -> only when this is green the zip is updated in the archive > yes. we should test new artifacts. > Marcus -- Best regards, Igor Stasenko. |
In reply to this post by Marcus Denker-4
Marcus Denker wrote:
> On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <[hidden email]> wrote: > > >> Hi, >> >> Finally, with a lot of work, mana, power cards and jedi tricks, we made the pharo vm builds work again :) >> >> This builds are up-to-date with latest sources from Eliot's cog and adds pharo branding (AFAIK, this is the first time we are going to release something like that :) >> >> You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ >> >> > > Very good! > > So now we need to step by step.. > -> use the build in the one-click > -> link the VM zips on pharo-project.org > -> replace the VM we use for running jobs on jenkins with this. > > And of course: > -> test those builds on all three architectures automatically with a test image (e.g. current 2.0 with all failing tests removed) > The idea is that this image should not change frequently (the only variable is the VM) > 1.3, 1.4, 1.4 Summer, 2.0, 2.x or some subset, like the last release of each major version. While you may not want a very old release to fail a VM, at least the compatibility would be on record. > -> only when this is green the zip is updated in the archive > > |
On Feb 16, 2013, at 1:57 PM, Ben Coman <[hidden email]> wrote: > Marcus Denker wrote: >> On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <[hidden email]> wrote: >> >> >>> Hi, >>> >>> Finally, with a lot of work, mana, power cards and jedi tricks, we made the pharo vm builds work again :) >>> >>> This builds are up-to-date with latest sources from Eliot's cog and adds pharo branding (AFAIK, this is the first time we are going to release something like that :) >>> >>> You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ >>> >>> >> >> Very good! >> >> So now we need to step by step.. >> -> use the build in the one-click >> -> link the VM zips on pharo-project.org >> -> replace the VM we use for running jobs on jenkins with this. >> >> And of course: >> -> test those builds on all three architectures automatically with a test image (e.g. current 2.0 with all failing tests removed) >> The idea is that this image should not change frequently (the only variable is the VM) >> > Could the CI test new VMs against all previous "release" images eg Pharo 1.3, 1.4, 1.4 Summer, 2.0, 2.x > or some subset, like the last release of each major version. While you may not want a very old release to fail a VM, at least the compatibility would be on record. One idea we had was to give up the "all VMs need to run all images", because this makes it very hard to move… Marcus |
In reply to this post by Ben Coman
I was looking in the image/ folder with the newImage.sh script as I
wanted to understand what was happening in there. So, this requires something like $PHAROVM to exist and be set to something proper (added to my .profile) Then, there is still ci.lille... in there, to be removed. Next, I wanted to make sense of the script itself. I commented out the part where the pregenerated image got downloaded as I wanted to see things work from zero and not merely a prebuilt image. So, I commented out the prebuilt part. # ---------------------------------------------------------------------------- # echo -e "${YELLOW}LOADING PREBUILT IMAGE" $NO_COLOR # echo " $PREBUILT_IMAGE_URL" # wget $WGET_CERTCHECK "$PREBUILT_IMAGE_URL" --output-document="image.zip" && \ # unzip image.zip && \ # rm image.zip && \ # openImage "$PWD/generator.image" "$PWD/ImageConfiguration.st" && exit 1 And then, I got: [PhilMac:~/Documents/Smalltalk/2-MyWorkspaces/workspacePharoVMFebruary2013/buildarea/cog/image philippeback$] ./newImage.sh FETCHING FRESH IMAGE https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo-1.4.zip --2013-02-16 14:10:11-- https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo-1.4.zip Which failed. The right URL is: URL="https://ci.inria.fr/pharo/view/Pharo-1.4/job/Pharo-1.4/lastSuccessfulBuild/artifact/" Also, it seems that the original contents of PharoVM do not contain the .sources, and this generates a UI message one has to click, which is annoying. Phil 2013/2/16 Ben Coman <[hidden email]>: > Marcus Denker wrote: >> >> On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <[hidden email]> >> wrote: >> >> >>> >>> Hi, >>> >>> Finally, with a lot of work, mana, power cards and jedi tricks, we made >>> the pharo vm builds work again :) >>> >>> This builds are up-to-date with latest sources from Eliot's cog and adds >>> pharo branding (AFAIK, this is the first time we are going to release >>> something like that :) >>> >>> You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ >>> >>> >> >> >> Very good! >> >> So now we need to step by step.. >> -> use the build in the one-click >> -> link the VM zips on pharo-project.org >> -> replace the VM we use for running jobs on jenkins with this. >> >> And of course: >> -> test those builds on all three architectures automatically with >> a test image (e.g. current 2.0 with all failing tests removed) >> The idea is that this image should not change frequently (the >> only variable is the VM) >> > > Could the CI test new VMs against all previous "release" images eg Pharo > 1.3, 1.4, 1.4 Summer, 2.0, 2.x > or some subset, like the last release of each major version. While you may > not want a very old release to fail a VM, at least the compatibility would > be on record. > >> -> only when this is green the zip is updated in the archive >> >> > > > |
In reply to this post by Marcus Denker-4
Well, this is the script from hell...
newImage.sh doesn't executes the last line: # ---------------------------------------------------------------------------- # try to open the image... set -e openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" because openImage exits the script... Question: can't we run all of this headless? Phil 2013/2/16 Marcus Denker <[hidden email]>: > > On Feb 16, 2013, at 1:57 PM, Ben Coman <[hidden email]> wrote: > >> Marcus Denker wrote: >>> On Feb 15, 2013, at 6:26 PM, Esteban Lorenzano <[hidden email]> wrote: >>> >>> >>>> Hi, >>>> >>>> Finally, with a lot of work, mana, power cards and jedi tricks, we made the pharo vm builds work again :) >>>> >>>> This builds are up-to-date with latest sources from Eliot's cog and adds pharo branding (AFAIK, this is the first time we are going to release something like that :) >>>> >>>> You can download it here: https://ci.inria.fr/pharo/view/VM/job/PharoVM/ >>>> >>>> >>> >>> Very good! >>> >>> So now we need to step by step.. >>> -> use the build in the one-click >>> -> link the VM zips on pharo-project.org >>> -> replace the VM we use for running jobs on jenkins with this. >>> >>> And of course: >>> -> test those builds on all three architectures automatically with a test image (e.g. current 2.0 with all failing tests removed) >>> The idea is that this image should not change frequently (the only variable is the VM) >>> >> Could the CI test new VMs against all previous "release" images eg Pharo 1.3, 1.4, 1.4 Summer, 2.0, 2.x >> or some subset, like the last release of each major version. While you may not want a very old release to fail a VM, at least the compatibility would be on record. > > One idea we had was to give up the "all VMs need to run all images", because this makes it very hard to move… > > Marcus > > > |
In reply to this post by philippeback
On 2013-02-16, at 14:25, "[hidden email]" <[hidden email]> wrote: > I was looking in the image/ folder with the newImage.sh script as I > wanted to understand what was happening in there. > > So, this requires something like $PHAROVM to exist and be set to > something proper (added to my .profile) > Then, there is still ci.lille... in there, to be removed. > > Next, I wanted to make sense of the script itself. > > I commented out the part where the pregenerated image got downloaded > as I wanted to see things work from zero and not merely a prebuilt > image. > > So, I commented out the prebuilt part. > > # ---------------------------------------------------------------------------- > # echo -e "${YELLOW}LOADING PREBUILT IMAGE" $NO_COLOR > # echo " $PREBUILT_IMAGE_URL" > > # wget $WGET_CERTCHECK "$PREBUILT_IMAGE_URL" --output-document="image.zip" && \ > # unzip image.zip && \ > # rm image.zip && \ > # openImage "$PWD/generator.image" "$PWD/ImageConfiguration.st" && exit 1 > > And then, I got: > > [PhilMac:~/Documents/Smalltalk/2-MyWorkspaces/workspacePharoVMFebruary2013/buildarea/cog/image > philippeback$] ./newImage.sh > FETCHING FRESH IMAGE > https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo-1.4.zip > --2013-02-16 14:10:11-- > https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo-1.4.zip > > Which failed. > > The right URL is: > URL="https://ci.inria.fr/pharo/view/Pharo-1.4/job/Pharo-1.4/lastSuccessfulBuild/artifact/" > > Also, it seems that the original contents of PharoVM do not contain > the .sources, and this generates a UI message one has to click, which > is annoying. > => use the urls from our file server and the new build scripts I didn't forgot to update the descriptions since we were out of builds for a while: #get a vm: wget http://files.pharo.org/script/ciPharoVM.sh bash ciPharoVM.sh #get an image: wget http://files.pharo.org/script/ciPharo14.sh bash ciPharo14.sh => to see what the scripts do run bash ciPharoVM.sh --help bash ciPharo14 --help => to run an image headlessly do ./vm.sh Pharo.image => you'll find a complete lists of images under http://files.pharo.org/image/14 I hope that helps? |
In reply to this post by philippeback
On 2013-02-16, at 14:30, "[hidden email]" <[hidden email]> wrote: > Well, this is the script from hell... > > newImage.sh doesn't executes the last line: > > # ---------------------------------------------------------------------------- > # try to open the image... > set -e > openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" > rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; > openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" > > > because openImage exits the script... > > Question: can't we run all of this headless? yes please ;) I guess I never fully tested it under unix/win and nobody really used it besides me. => run everything in headless mode => use the zeroconf scripts |
In reply to this post by Camillo Bruni-3
sure does.
2013/2/16 Camillo Bruni <[hidden email]>: > > On 2013-02-16, at 14:25, "[hidden email]" <[hidden email]> wrote: > >> I was looking in the image/ folder with the newImage.sh script as I >> wanted to understand what was happening in there. >> >> So, this requires something like $PHAROVM to exist and be set to >> something proper (added to my .profile) >> Then, there is still ci.lille... in there, to be removed. >> >> Next, I wanted to make sense of the script itself. >> >> I commented out the part where the pregenerated image got downloaded >> as I wanted to see things work from zero and not merely a prebuilt >> image. >> >> So, I commented out the prebuilt part. >> >> # ---------------------------------------------------------------------------- >> # echo -e "${YELLOW}LOADING PREBUILT IMAGE" $NO_COLOR >> # echo " $PREBUILT_IMAGE_URL" >> >> # wget $WGET_CERTCHECK "$PREBUILT_IMAGE_URL" --output-document="image.zip" && \ >> # unzip image.zip && \ >> # rm image.zip && \ >> # openImage "$PWD/generator.image" "$PWD/ImageConfiguration.st" && exit 1 >> >> And then, I got: >> >> [PhilMac:~/Documents/Smalltalk/2-MyWorkspaces/workspacePharoVMFebruary2013/buildarea/cog/image >> philippeback$] ./newImage.sh >> FETCHING FRESH IMAGE >> https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo-1.4.zip >> --2013-02-16 14:10:11-- >> https://ci.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact/Pharo-1.4.zip >> >> Which failed. >> >> The right URL is: >> URL="https://ci.inria.fr/pharo/view/Pharo-1.4/job/Pharo-1.4/lastSuccessfulBuild/artifact/" >> >> Also, it seems that the original contents of PharoVM do not contain >> the .sources, and this generates a UI message one has to click, which >> is annoying. >> > > => use the urls from our file server and the new build scripts > > I didn't forgot to update the descriptions since we were out of builds for a while: > > #get a vm: > > wget http://files.pharo.org/script/ciPharoVM.sh > bash ciPharoVM.sh > > #get an image: > > wget http://files.pharo.org/script/ciPharo14.sh > bash ciPharo14.sh > > > => to see what the scripts do run > bash ciPharoVM.sh --help > bash ciPharo14 --help > > => to run an image headlessly do > > ./vm.sh Pharo.image > > => you'll find a complete lists of images under http://files.pharo.org/image/14 > > I hope that helps? > > > |
In reply to this post by Camillo Bruni-3
ZeroConf runs already in another place. It is nice!
2013/2/16 Camillo Bruni <[hidden email]>: > > On 2013-02-16, at 14:30, "[hidden email]" <[hidden email]> wrote: > >> Well, this is the script from hell... >> >> newImage.sh doesn't executes the last line: >> >> # ---------------------------------------------------------------------------- >> # try to open the image... >> set -e >> openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" >> rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; >> openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" >> >> >> because openImage exits the script... >> >> Question: can't we run all of this headless? > > > yes please ;) I guess I never fully tested it under unix/win and nobody really used it > besides me. > > => run everything in headless mode > => use the zeroconf scripts > > > |
In reply to this post by Camillo Bruni-3
Still, when doing a cmake . and make in the build/ folder, I do get a
CogVM.app in results. Shouldn't I get a Pharo.app? Where is this occuring? Phil 2013/2/16 Camillo Bruni <[hidden email]>: > > On 2013-02-16, at 14:30, "[hidden email]" <[hidden email]> wrote: > >> Well, this is the script from hell... >> >> newImage.sh doesn't executes the last line: >> >> # ---------------------------------------------------------------------------- >> # try to open the image... >> set -e >> openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" >> rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; >> openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" >> >> >> because openImage exits the script... >> >> Question: can't we run all of this headless? > > > yes please ;) I guess I never fully tested it under unix/win and nobody really used it > besides me. > > => run everything in headless mode > => use the zeroconf scripts > > > |
In reply to this post by Camillo Bruni-3
And inside the app, there is a CogVM executable, not a pharo one.
Confused I am. Phil 2013/2/16 Camillo Bruni <[hidden email]>: > > On 2013-02-16, at 14:30, "[hidden email]" <[hidden email]> wrote: > >> Well, this is the script from hell... >> >> newImage.sh doesn't executes the last line: >> >> # ---------------------------------------------------------------------------- >> # try to open the image... >> set -e >> openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" >> rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; >> openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" >> >> >> because openImage exits the script... >> >> Question: can't we run all of this headless? > > > yes please ;) I guess I never fully tested it under unix/win and nobody really used it > besides me. > > => run everything in headless mode > => use the zeroconf scripts > > > |
You use the wrong configuration in VMMaker (thanks to the strange naming conventions
this happens way too easily) :/ I think you can just use Pharo.*Config instead of Cog.*Config? On 2013-02-16, at 15:18, "[hidden email]" <[hidden email]> wrote: > And inside the app, there is a CogVM executable, not a pharo one. > > Confused I am. > > Phil > > 2013/2/16 Camillo Bruni <[hidden email]>: >> >> On 2013-02-16, at 14:30, "[hidden email]" <[hidden email]> wrote: >> >>> Well, this is the script from hell... >>> >>> newImage.sh doesn't executes the last line: >>> >>> # ---------------------------------------------------------------------------- >>> # try to open the image... >>> set -e >>> openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" >>> rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; >>> openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" >>> >>> >>> because openImage exits the script... >>> >>> Question: can't we run all of this headless? >> >> >> yes please ;) I guess I never fully tested it under unix/win and nobody really used it >> besides me. >> >> => run everything in headless mode >> => use the zeroconf scripts >> >> >> > |
All right, this wasn't in the workspace being initialized with the .st
file in the image folder. Code is generated, cmake works, but make fails. vmVersionInfo.h appears to be missing. Was there when doing the Cog thing. I'll dig. Phil 2013/2/16 Camillo Bruni <[hidden email]>: > You use the wrong configuration in VMMaker (thanks to the strange naming conventions > this happens way too easily) :/ > > I think you can just use Pharo.*Config instead of Cog.*Config? > > On 2013-02-16, at 15:18, "[hidden email]" <[hidden email]> wrote: > >> And inside the app, there is a CogVM executable, not a pharo one. >> >> Confused I am. >> >> Phil >> >> 2013/2/16 Camillo Bruni <[hidden email]>: >>> >>> On 2013-02-16, at 14:30, "[hidden email]" <[hidden email]> wrote: >>> >>>> Well, this is the script from hell... >>>> >>>> newImage.sh doesn't executes the last line: >>>> >>>> # ---------------------------------------------------------------------------- >>>> # try to open the image... >>>> set -e >>>> openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" >>>> rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; >>>> openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" >>>> >>>> >>>> because openImage exits the script... >>>> >>>> Question: can't we run all of this headless? >>> >>> >>> yes please ;) I guess I never fully tested it under unix/win and nobody really used it >>> besides me. >>> >>> => run everything in headless mode >>> => use the zeroconf scripts >>> >>> >>> >> > > |
In reply to this post by Camillo Bruni-3
Forget that, that file is the only one which is *already* in the
build/ folder from the cog.tar, which I trashed when restarting the procedure. One more gotcha... Phil 2013/2/16 Camillo Bruni <[hidden email]>: > You use the wrong configuration in VMMaker (thanks to the strange naming conventions > this happens way too easily) :/ > > I think you can just use Pharo.*Config instead of Cog.*Config? > > On 2013-02-16, at 15:18, "[hidden email]" <[hidden email]> wrote: > >> And inside the app, there is a CogVM executable, not a pharo one. >> >> Confused I am. >> >> Phil >> >> 2013/2/16 Camillo Bruni <[hidden email]>: >>> >>> On 2013-02-16, at 14:30, "[hidden email]" <[hidden email]> wrote: >>> >>>> Well, this is the script from hell... >>>> >>>> newImage.sh doesn't executes the last line: >>>> >>>> # ---------------------------------------------------------------------------- >>>> # try to open the image... >>>> set -e >>>> openImage "$PWD/$VERSION.image" "$PWD/../codegen-scripts/LoadVMMaker.st" >>>> rm -rf "$PWD/$VERSION.image" "$PWD/$VERSION.changes"; >>>> openImage "$PWD/$generator.image" "$PWD/ImageConfiguration.st" >>>> >>>> >>>> because openImage exits the script... >>>> >>>> Question: can't we run all of this headless? >>> >>> >>> yes please ;) I guess I never fully tested it under unix/win and nobody really used it >>> besides me. >>> >>> => run everything in headless mode >>> => use the zeroconf scripts >>> >>> >>> >> > > |
Free forum by Nabble | Edit this page |