[Hudson] Cog Unix build
Locked
 
|
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. > > |
|
|
In reply to this post by Marcus Denker-4
On Feb 12, 2011, at 9:43 AM, Esteban Lorenzano wrote: > really cool! > Next week I will prepare scripts for doing same with cocoa cog and cocoa stack vms, if you agree :) > Yes! We will get a mac mini from INRIA for the mac build and tests. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
|
|
On 12 February 2011 18:50, Marcus Denker <[hidden email]> wrote:
> > On Feb 12, 2011, at 9:43 AM, Esteban Lorenzano wrote: > >> really cool! >> Next week I will prepare scripts for doing same with cocoa cog and cocoa stack vms, if you agree :) >> > Yes! We will get a mac mini from INRIA for the mac build and tests. > Yes, tomorrow i will meet the guys to discuss it. > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Best regards, Igor Stasenko AKA sig. |
|
|
In reply to this post by Marcus Denker-4
On 12 February 2011 18:38, Marcus Denker <[hidden email]> 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 <[hidden email]> 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 |
|
|
In reply to this post by Igor Stasenko
****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 |
|
|
In reply to this post by Igor Stasenko
Waouh, not a week without incredible news :) Thank you ! Laurent On Sat, Feb 12, 2011 at 11:19 PM, Igor Stasenko <[hidden email]> wrote:
|
Re: [Hudson] Cog Unix build
|
|
In reply to this post by Igor Stasenko
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." |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |