[Pharo-project] [Hudson] Cog Unix build
Hudson news ------------------ Cog Unix https://pharo-ic.lille.inria.fr/hudson/job/Cog%20Unix%201.3/ This is using Igor's non-interactive build. Hudson does the following: git clone git://gitorious.org/~abrabapupa/cogvm/sig-cog.git cd sig-cog/codegen-scripts sh ./buildImage.sh -nodisplay sh ./generate.sh -nodisplay ./CogUnix.st cd sig-cog/build cmake . make zip -r Cog.zip results/* Problems: - do not do a clone but update the checked out source when they are already there - the generated VM crashes shortly after image startup But nevertheless, another tiny step. What is nice is that this allows to trigger a build (and test) automatically when either a new monticello or git commit happens, leading to a much faster turnaround when doing changes to the VM. And of course the other important reason is that this allows people to set up their own auto-build from a git clone when doing VM experiments, very useful in a research and university setting. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
really cool! Next week I will prepare scripts for doing same with cocoa cog and cocoa stack vms, if you agree :) Cheers, Esteban El 12/02/2011, a las 2:38p.m., Marcus Denker escribió:
Hudson news ------------------
Cog Unix
https://pharo-ic.lille.inria.fr/hudson/job/Cog%20Unix%201.3/
This is using Igor's non-interactive build. Hudson does the following:
git clone git://gitorious.org/~abrabapupa/cogvm/sig-cog.git cd sig-cog/codegen-scripts sh ./buildImage.sh -nodisplay sh ./generate.sh -nodisplay ./CogUnix.st cd sig-cog/build cmake . make zip -r Cog.zip results/*
Problems: - do not do a clone but update the checked out source when they are already there - the generated VM crashes shortly after image startup
But nevertheless, another tiny step.
What is nice is that this allows to trigger a build (and test) automatically when either a new monticello or git commit happens, leading to a much faster turnaround when doing changes to the VM.
And of course the other important reason is that this allows people to set up their own auto-build from a git clone when doing VM experiments, very useful in a research and university setting.
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
On 12 February 2011 18:38, Marcus Denker <marcus.denker@inria.fr> wrote:
Hudson news ------------------
Cog Unix
    https://pharo-ic.lille.inria.fr/hudson/job/Cog%20Unix%201.3/
This is using Igor's non-interactive build. Hudson does the following:
git clone git://gitorious.org/~abrabapupa/cogvm/sig-cog.git cd sig-cog/codegen-scripts sh ./buildImage.sh -nodisplay sh ./generate.sh -nodisplay ./CogUnix.st
i changed the generate.sh to take the configuration class name. So now we should have multiple (sub)projects for building VM for each of the following configurations: sh ./generate.sh -headless CogUnixConfig sh ./generate.sh -headless StackInterpreterUnixConfig sh ./generate.sh -headless StackInterpreterDebugUnixConfig sh ./generate.sh -headless CogDebugUnixConfig
cd sig-cog/build cmake . make zip -r Cog.zip results/*
Problems:     - do not do a clone but update the checked out source when they are already there     - the generated VM crashes shortly after image startup
But nevertheless, another tiny step.
Yes. i found the issue. Now it runs!!! :) And i were able to run all tests in pharo 1.3 core image on StackVM: 7864 run, 7787 passes, 51 expected failures, 8 failures, 17 errors, 1 unexpected passes no more crashes! :)
What is nice is that this allows to trigger a build (and test) automatically when either a new monticello or git commit happens, leading to a much faster turnaround when doing changes to the VM.
Ideally, build should be triggered only when we commit something to git :) I should fix the codegen-scripts/LoadVMMaker.st to always use exact package version(s) for building image, not the latest one. So, then by checking-out some historical commit, one should be able to reproduce the same VM as we had, when committing it. And for testing if VMMaker could be loaded into latest development image, we can set up a separate project or use different scripts.
And of course the other important reason is that this allows people to set up their own auto-build from a git clone when doing VM experiments, very useful in a research and university setting.
    Marcus
-- Marcus Denker  -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
-- Best regards, Igor Stasenko AKA sig.
Markus, Igor, everyone, this is *excellent work*. It is really a tremendous leap forward. It is amazing how the different efforts (hudson, configuration, modern handling of VM sources, Cog VM, Pharo Core) of the community can converge to something as useful as we see here. Thanks to everyone involved in this step by step (as Stef says) continuous daily effort. The fruits are growing in the Pharo project tree! El sáb, 12-02-2011 a las 23:19 +0100, Igor Stasenko escribió:
On 12 February 2011 18:38, Marcus Denker <marcus.denker@inria.fr> wrote:
Hudson news ------------------
Cog Unix
https://pharo-ic.lille.inria.fr/hudson/job/Cog%20Unix%201.3/
This is using Igor's non-interactive build. Hudson does the following:
git clone git://gitorious.org/~abrabapupa/cogvm/sig-cog.git cd sig-cog/codegen-scripts sh ./buildImage.sh -nodisplay sh ./generate.sh -nodisplay ./CogUnix.st
i changed the generate.sh to take the configuration class name.
So now we should have multiple (sub)projects for building VM for each of the following configurations:
sh ./generate.sh -headless CogUnixConfig sh ./generate.sh -headless StackInterpreterUnixConfig sh ./generate.sh -headless StackInterpreterDebugUnixConfig sh ./generate.sh -headless CogDebugUnixConfig
cd sig-cog/build cmake . make zip -r Cog.zip results/*
Problems: - do not do a clone but update the checked out source when they are already there - the generated VM crashes shortly after image startup
But nevertheless, another tiny step.
Yes. i found the issue. Now it runs!!! :)
And i were able to run all tests in pharo 1.3 core image on StackVM:
7864 run, 7787 passes, 51 expected failures, 8 failures, 17 errors, 1 unexpected passes
no more crashes! :)
What is nice is that this allows to trigger a build (and test) automatically when either a new monticello or git commit happens, leading to a much faster turnaround when doing changes to the VM.
Ideally, build should be triggered only when we commit something to git :)
I should fix the codegen-scripts/LoadVMMaker.st to always use exact package version(s) for building image, not the latest one. So, then by checking-out some historical commit, one should be able to reproduce the same VM as we had, when committing it.
And for testing if VMMaker could be loaded into latest development image, we can set up a separate project or use different scripts.
And of course the other important reason is that this allows people to set up their own auto-build from a git clone when doing VM experiments, very useful in a research and university setting.
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
****EXCELLENT NEWS****
Yes. i found the issue. Now it runs!!! :)
And i were able to run all tests in pharo 1.3 core image on StackVM:
7864 run, 7787 passes, 51 expected failures, 8 failures, 17 errors, 1 unexpected passes
no more crashes! :)
really really great.
Ideally, build should be triggered only when we commit something to git :)
Yes! Yes! Yes!
So, then by checking-out some historical commit, one should be able to reproduce the same VM as we had, when committing it.
What we are doing is MUCH more than just a build system, we are building a system that will - increase our trust in the system - show credibility to the world - show that we can control risks even with an evolving system I think that this is important for people willing to invest in Smalltalk to see that virtual machines and the software is following adequate **engineered** practices. Thanks igor for all the energy you are putting on that. Soon we will start to have real fun at the image level. Stef
Waouh, not a week without incredible news :) Thank you ! Laurent On Sat, Feb 12, 2011 at 11:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 12 February 2011 18:38, Marcus Denker <marcus.denker@inria.fr> wrote:
Hudson news ------------------
Cog Unix
https://pharo-ic.lille.inria.fr/hudson/job/Cog%20Unix%201.3/
This is using Igor's non-interactive build. Hudson does the following:
git clone git://gitorious.org/~abrabapupa/cogvm/sig-cog.git cd sig-cog/codegen-scripts sh ./buildImage.sh -nodisplay sh ./generate.sh -nodisplay ./CogUnix.st
i changed the generate.sh to take the configuration class name.
So now we should have multiple (sub)projects for building VM for each of the following configurations:
sh ./generate.sh -headless CogUnixConfig sh ./generate.sh -headless StackInterpreterUnixConfig sh ./generate.sh -headless StackInterpreterDebugUnixConfig sh ./generate.sh -headless CogDebugUnixConfig
cd sig-cog/build cmake . make zip -r Cog.zip results/*
Problems: - do not do a clone but update the checked out source when they are already there - the generated VM crashes shortly after image startup
But nevertheless, another tiny step.
Yes. i found the issue. Now it runs!!! :)
And i were able to run all tests in pharo 1.3 core image on StackVM:
7864 run, 7787 passes, 51 expected failures, 8 failures, 17 errors, 1 unexpected passes
no more crashes! :)
What is nice is that this allows to trigger a build (and test) automatically when either a new monticello or git commit happens, leading to a much faster turnaround when doing changes to the VM.
Ideally, build should be triggered only when we commit something to git :)
I should fix the codegen-scripts/LoadVMMaker.st to always use exact package version(s) for building image, not the latest one. So, then by checking-out some historical commit, one should be able to reproduce the same VM as we had, when committing it.
And for testing if VMMaker could be loaded into latest development image, we can set up a separate project or use different scripts.
And of course the other important reason is that this allows people to set up their own auto-build from a git clone when doing VM experiments, very useful in a research and university setting.
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
-- Best regards, Igor Stasenko AKA sig.
On 12 Feb 2011, at 23:19, Igor Stasenko wrote:
Yes. i found the issue. Now it runs!!! :)
And i were able to run all tests in pharo 1.3 core image on StackVM:
7864 run, 7787 passes, 51 expected failures, 8 failures, 17 errors, 1 unexpected passes
no more crashes! :)
That is really great and very impressive as well ! Sven
Great job! Doru On 13 Feb 2011, at 09:56, Sven Van Caekenberghe wrote:
On 12 Feb 2011, at 23:19, Igor Stasenko wrote:
Yes. i found the issue. Now it runs!!! :)
And i were able to run all tests in pharo 1.3 core image on StackVM:
7864 run, 7787 passes, 51 expected failures, 8 failures, 17 errors, 1 unexpected passes
no more crashes! :)
That is really great and very impressive as well !
Sven
-- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."
participants (8)
-
Esteban Lorenzano -
Igor Stasenko -
laurent laffont -
Marcus Denker -
Miguel Cobá -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba