[Hudson] Cog Unix build

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Hudson] Cog Unix build

Marcus Denker-4
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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Hudson] Cog Unix build

EstebanLM
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.
>
>


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Hudson] Cog Unix build

Marcus Denker-4
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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Hudson] Cog Unix build

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Hudson] Cog Unix build

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Hudson] Cog Unix build

Miguel Cobá
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




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Hudson] Cog Unix build

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Hudson] Cog Unix build

laurent laffont
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:
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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Hudson] Cog Unix build

Sven Van Caekenberghe
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [Hudson] Cog Unix build

Tudor Girba
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."





Loading...