January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Interim build server update

by Simon Denier

On 7 janv. 2010, at 23:36, Michael Roberts wrote: > a simple test report for PharoCore 1.1 is now automatically published at > > http://pharo.gforge.inria.fr/experimental/ > > what do you think? > Sounds good (cant say 'looks', it's a bit crude on the look-likability :)) What is the next step? Hudson integration, test history, visualization? -- Simon

Jan. 8, 2010

Re: [Pharo-project] [ANN] Icons for Mac users

by StÃ©phane Ducasse

I was playing with adding a bit of shadow so that the icon stand out. may be people with better tools can produce something better. Stef

Jan. 8, 2010

Re: [Pharo-project] [ANN] Hudson continuous integration server support

by StÃ©phane Ducasse

this is getting cool :) Stef On Jan 8, 2010, at 7:19 AM, Lukas Renggli wrote: > H Yanni > > Thank you for the excellent instructions and for sharing this > information. I never thought of using Hudson to build Smalltalk images > before. Within a few hours I managed to convince Hudson to build some > Smalltalk images and run the tests. The setup is pretty ugly > (especially the dependencies), but it works reasonably well and the > result is as if I would build the images manually (I use the same > Gofer scripts) every night: > > http://hudson.lukas-renggli.ch > > Thank you! > > Lukas > > 2010/1/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> thanks this is good idea. >> Please continue to push it. >> >> Stef >> >> On Jan 5, 2010, at 8:59 PM, Yanni Chiu wrote: >> >>> I've created a project at: >>> >>> http://www.squeaksource.com/HudsonBuild.html >>> >>> You can automate a build through a shell script run by Hudson, and view the SUnit test results through Hudson. The first example runs the unit tests in the PharoCore image, and the second example loads Pier and runs its unit tests. >>> >>> The examples derive from Lukas' Gofer scripts, but you could set things up to use Metacello. >>> >>> The build scripts are attached to this message as a zip file. A howto.txt is included in the zip, and pasted below. >>> >>> -- >>> Yanni Chiu >>> >>> ========= >>> howto.txt >>> ========= >>> >>> ====== >>> PART A - Prepare image and adjust build scripts >>> ====== >>> >>> Unzip the build scripts >>> - choose a build home directory, and unzip the files there >>> - there should be an empty "images" directory >>> >>> Create an initial build image >>> - get a distribution image (e.g. http://www.pharo-project.org/pharo-download) >>> - put the image in the images directory >>> - start the image, and refresh Gofer using: >>> >>> <code> >>> Utilities updateFromServer. >>> [ Gofer gofer load ] >>> on: Error >>> do: [ :err | err retry ]. >>> Gofer gofer recompile. >>> </code> >>> >>> - this update should be part of the build script, but it was not working for me when it's run from a startup script. >>> - save the image as "core" >>> >>> Adjust build scripts >>> - edit the core.sh and pier.sh scripts, setting suitable values for: >>> SQUEAK_VM >>> IMAGES_HOME >>> SCRIPTS_HOME >>> - you may have to adjust the repository locations too >>> >>> These sample build scripts are just a starting point for creating your own build scripts for your project. The core.sh script does not actually load any packages, it just runs the test cases in the PharoCore image. The pier.sh script loads Seaside/Magritte/Pier into the core image, then runs the test cases. >>> >>> >>> ====== >>> PART B - Integrate with Hudson >>> ====== >>> >>> Download hudson.war from http://hudson-ci.org/ >>> >>> Start the Hudson server. >>> - run something like: >>> WARFILE=$HOME/apps/hudson/hudson.war >>> LOGFILE=hudson.log >>> nohup java -jar $WARFILE --httpPort=9090 > $LOGFILE 2>&1 & >>> - port 9090 is used to avoid conflict with Seaside on 8080 >>> - goto the Hudson dashboard at http://localhost:9090 >>> >>> Add new Hudson job >>> - from Hudson dashboard, select "New Job" >>> - fill in a job name, e.g. "Core" >>> - choose the "Build a free-style software project" radio button >>> - click on OK >>> >>> Configure the new job >>> - you should be sent to the job configuration screen, after the previous step >>> - in the "Build" section, click "Add build step", select "Execute shell" from dropdown menu >>> - in the Command textarea that appears, type the full path to the build script: e.g. /Users/yanni/work/public/Core/pier.sh >>> - in the "Post-build Actions" section, enable "Publish JUnit test result report" >>> - enter "test-reports/*.xml" into the text input labelled "Test report XMLs" that appears. >>> - save the configuration changes (i.e. click "Save"). >>> >>> Run the build job >>> - after saving the new job, you should already be in the new job's control screen. If not, you can navigate there from the dashboard. >>> - start a build by clicking on the "Build Now" link >>> >>> ===== >>> HINTS >>> ===== >>> >>> 1. Click on "Workspace" to see the "Wipe Out Workspace" link. If a PharoDebug.log file is generated, it will be more easy to spot, if the workspace was originally cleaned out. >>> >>> 2. Test your build script in a headful image beforehand. Any flaw will cause the build to stall, and you'll need to abort it (using the Hudson interface), then look at the PharoDebug.log to figure out what went wrong. >>> >>> 3. If the package-cache directory known to your build image still exists, then it will be used (and your packages will appear there, instead of in the Hudson workspace). If it does not exist, then a new package-cache directory will be created in the Hudson job workspace. >>> >>> 4. Monitor the package-cache in the Workspace, to get an idea of the progress of the build. The pier.sh build runs in a 3.5 minutes, building from a local file repository, on a MacBook. >>> >>> 5. Hudson timeout plugin - I've not tried this yet, but if you have a build script error, your build does not abort on its own (or, I've not waited long enough). >>> <Core.zip>_______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 8, 2010

Re: [Pharo-project] [ANN] Hudson continuous integration server support

by Lukas Renggli

> Lukas this is cool. Â the dependencies you mean the JRE dependencies? I > am looking to do the install soon. No, the dependencies between builds are the problem. In my case the dependencies are as followed: Core - unloads the tests and sets my settings > Development - loads RefactoringBrowser and OmniBrowser > Seaside 2.8 - loads Seaside 2.8, Magritte, Pier > Seaside 3.0 - loads Seaside 3.0 I followed the instructions given here <http://wiki.hudson-ci.org/display/HUDSON/Splitting+a+big+job+into+smaller+j…>. It is really cumbersome. I have to link the workspace of the depended builds into the workspace of the current build, otherwise I cannot access the previous builds to build something on top. I could do everything in one build (and use Mason for the dependency resolution), but then I'd loose the nice per-build reporting of Hudson. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 8, 2010

Re: [Pharo-project] [ANN] Hudson continuous integration server support

by Michael Roberts

Lukas this is cool. the dependencies you mean the JRE dependencies? I am looking to do the install soon. cheers, Mike On Fri, Jan 8, 2010 at 6:19 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > H Yanni > > Thank you for the excellent instructions and for sharing this > information. I never thought of using Hudson to build Smalltalk images > before. Within a few hours I managed to convince Hudson to build some > Smalltalk images and run the tests. The setup is pretty ugly > (especially the dependencies), but it works reasonably well and the > result is as if I would build the images manually (I use the same > Gofer scripts) every night: > > Â http://hudson.lukas-renggli.ch > > Thank you! > > Lukas > > 2010/1/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> thanks this is good idea. >> Please continue to push it. >> >> Stef >> >> On Jan 5, 2010, at 8:59 PM, Yanni Chiu wrote: >> >>> I've created a project at: >>> >>> Â Â http://www.squeaksource.com/HudsonBuild.html >>> >>> You can automate a build through a shell script run by Hudson, and view the SUnit test results through Hudson. The first example runs the unit tests in the PharoCore image, and the second example loads Pier and runs its unit tests. >>> >>> The examples derive from Lukas' Gofer scripts, but you could set things up to use Metacello. >>> >>> The build scripts are attached to this message as a zip file. A howto.txt is included in the zip, and pasted below. >>> >>> -- >>> Yanni Chiu >>> >>> ========= >>> howto.txt >>> ========= >>> >>> ====== >>> PART A - Prepare image and adjust build scripts >>> ====== >>> >>> Unzip the build scripts >>> - choose a build home directory, and unzip the files there >>> - there should be an empty "images" directory >>> >>> Create an initial build image >>> - get a distribution image (e.g. http://www.pharo-project.org/pharo-download) >>> - put the image in the images directory >>> - start the image, and refresh Gofer using: >>> >>> <code> >>> Utilities updateFromServer. >>> [ Gofer gofer load ] >>> Â Â Â Â on: Error >>> Â Â Â Â do: [ :err | err retry ]. >>> Gofer gofer recompile. >>> </code> >>> >>> - this update should be part of the build script, but it was not working for me when it's run from a startup script. >>> - save the image as "core" >>> >>> Adjust build scripts >>> - edit the core.sh and pier.sh scripts, setting suitable values for: >>> Â Â SQUEAK_VM >>> Â Â IMAGES_HOME >>> Â Â SCRIPTS_HOME >>> - you may have to adjust the repository locations too >>> >>> These sample build scripts are just a starting point for creating your own build scripts for your project. The core.sh script does not actually load any packages, it just runs the test cases in the PharoCore image. The pier.sh script loads Seaside/Magritte/Pier into the core image, then runs the test cases. >>> >>> >>> ====== >>> PART B - Integrate with Hudson >>> ====== >>> >>> Download hudson.war from http://hudson-ci.org/ >>> >>> Start the Hudson server. >>> - run something like: >>> Â Â WARFILE=$HOME/apps/hudson/hudson.war >>> Â Â LOGFILE=hudson.log >>> Â Â nohup java -jar $WARFILE --httpPort=9090 > $LOGFILE 2>&1 & >>> - port 9090 is used to avoid conflict with Seaside on 8080 >>> - goto the Hudson dashboard at http://localhost:9090 >>> >>> Add new Hudson job >>> - from Hudson dashboard, select "New Job" >>> - fill in a job name, e.g. "Core" >>> - choose the "Build a free-style software project" radio button >>> - click on OK >>> >>> Configure the new job >>> - you should be sent to the job configuration screen, after the previous step >>> - in the "Build" section, click "Add build step", select "Execute shell" from dropdown menu >>> - in the Command textarea that appears, type the full path to the build script: e.g. /Users/yanni/work/public/Core/pier.sh >>> - in the "Post-build Actions" section, enable "Publish JUnit test result report" >>> - enter "test-reports/*.xml" into the text input labelled "Test report XMLs" that appears. >>> - save the configuration changes (i.e. click "Save"). >>> >>> Run the build job >>> - after saving the new job, you should already be in the new job's control screen. If not, you can navigate there from the dashboard. >>> - start a build by clicking on the "Build Now" link >>> >>> ===== >>> HINTS >>> ===== >>> >>> 1. Click on "Workspace" to see the "Wipe Out Workspace" link. If a PharoDebug.log file is generated, it will be more easy to spot, if the workspace was originally cleaned out. >>> >>> 2. Test your build script in a headful image beforehand. Any flaw will cause the build to stall, and you'll need to abort it (using the Hudson interface), then look at the PharoDebug.log to figure out what went wrong. >>> >>> 3. If the package-cache directory known to your build image still exists, then it will be used (and your packages will appear there, instead of in the Hudson workspace). If it does not exist, then a new package-cache directory will be created in the Hudson job workspace. >>> >>> 4. Monitor the package-cache in the Workspace, to get an idea of the progress of the build. The pier.sh build runs in a 3.5 minutes, building from a local file repository, on a MacBook. >>> >>> 5. Hudson timeout plugin - I've not tried this yet, but if you have a build script error, your build does not abort on its own (or, I've not waited long enough). >>> <Core.zip>_______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 8, 2010

Re: [Pharo-project] Interim build server update

by Michael Roberts

good points, i will get more OS information into it. Realistically we will probably only run these on Linux, but if we really cared we could find a windows server (or pay on Amazon EC2) and report for multiple OS. We would need a Windows admin to volunteer ;-) cheers, Mike

Jan. 8, 2010

Re: [Pharo-project] Interim build server update

by StÃ©phane Ducasse

On Jan 7, 2010, at 11:36 PM, Michael Roberts wrote: > a simple test report for PharoCore 1.1 is now automatically published at > > http://pharo.gforge.inria.fr/experimental/ > > what do you think? I love the term automatically it sounds like faery :) > > I would propose to remove the google wiki test entries (for 1.1) and > point them here. yes > > cheers, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 8, 2010

Re: [Pharo-project] [ANN] Hudson continuous integration server support

by Lukas Renggli

H Yanni Thank you for the excellent instructions and for sharing this information. I never thought of using Hudson to build Smalltalk images before. Within a few hours I managed to convince Hudson to build some Smalltalk images and run the tests. The setup is pretty ugly (especially the dependencies), but it works reasonably well and the result is as if I would build the images manually (I use the same Gofer scripts) every night: http://hudson.lukas-renggli.ch Thank you! Lukas 2010/1/5 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > thanks this is good idea. > Please continue to push it. > > Stef > > On Jan 5, 2010, at 8:59 PM, Yanni Chiu wrote: > >> I've created a project at: >> >> Â Â http://www.squeaksource.com/HudsonBuild.html >> >> You can automate a build through a shell script run by Hudson, and view the SUnit test results through Hudson. The first example runs the unit tests in the PharoCore image, and the second example loads Pier and runs its unit tests. >> >> The examples derive from Lukas' Gofer scripts, but you could set things up to use Metacello. >> >> The build scripts are attached to this message as a zip file. A howto.txt is included in the zip, and pasted below. >> >> -- >> Yanni Chiu >> >> ========= >> howto.txt >> ========= >> >> ====== >> PART A - Prepare image and adjust build scripts >> ====== >> >> Unzip the build scripts >> - choose a build home directory, and unzip the files there >> - there should be an empty "images" directory >> >> Create an initial build image >> - get a distribution image (e.g. http://www.pharo-project.org/pharo-download) >> - put the image in the images directory >> - start the image, and refresh Gofer using: >> >> <code> >> Utilities updateFromServer. >> [ Gofer gofer load ] >> Â Â Â Â on: Error >> Â Â Â Â do: [ :err | err retry ]. >> Gofer gofer recompile. >> </code> >> >> - this update should be part of the build script, but it was not working for me when it's run from a startup script. >> - save the image as "core" >> >> Adjust build scripts >> - edit the core.sh and pier.sh scripts, setting suitable values for: >> Â Â SQUEAK_VM >> Â Â IMAGES_HOME >> Â Â SCRIPTS_HOME >> - you may have to adjust the repository locations too >> >> These sample build scripts are just a starting point for creating your own build scripts for your project. The core.sh script does not actually load any packages, it just runs the test cases in the PharoCore image. The pier.sh script loads Seaside/Magritte/Pier into the core image, then runs the test cases. >> >> >> ====== >> PART B - Integrate with Hudson >> ====== >> >> Download hudson.war from http://hudson-ci.org/ >> >> Start the Hudson server. >> - run something like: >> Â Â WARFILE=$HOME/apps/hudson/hudson.war >> Â Â LOGFILE=hudson.log >> Â Â nohup java -jar $WARFILE --httpPort=9090 > $LOGFILE 2>&1 & >> - port 9090 is used to avoid conflict with Seaside on 8080 >> - goto the Hudson dashboard at http://localhost:9090 >> >> Add new Hudson job >> - from Hudson dashboard, select "New Job" >> - fill in a job name, e.g. "Core" >> - choose the "Build a free-style software project" radio button >> - click on OK >> >> Configure the new job >> - you should be sent to the job configuration screen, after the previous step >> - in the "Build" section, click "Add build step", select "Execute shell" from dropdown menu >> - in the Command textarea that appears, type the full path to the build script: e.g. /Users/yanni/work/public/Core/pier.sh >> - in the "Post-build Actions" section, enable "Publish JUnit test result report" >> - enter "test-reports/*.xml" into the text input labelled "Test report XMLs" that appears. >> - save the configuration changes (i.e. click "Save"). >> >> Run the build job >> - after saving the new job, you should already be in the new job's control screen. If not, you can navigate there from the dashboard. >> - start a build by clicking on the "Build Now" link >> >> ===== >> HINTS >> ===== >> >> 1. Click on "Workspace" to see the "Wipe Out Workspace" link. If a PharoDebug.log file is generated, it will be more easy to spot, if the workspace was originally cleaned out. >> >> 2. Test your build script in a headful image beforehand. Any flaw will cause the build to stall, and you'll need to abort it (using the Hudson interface), then look at the PharoDebug.log to figure out what went wrong. >> >> 3. If the package-cache directory known to your build image still exists, then it will be used (and your packages will appear there, instead of in the Hudson workspace). If it does not exist, then a new package-cache directory will be created in the Hudson job workspace. >> >> 4. Monitor the package-cache in the Workspace, to get an idea of the progress of the build. The pier.sh build runs in a 3.5 minutes, building from a local file repository, on a MacBook. >> >> 5. Hudson timeout plugin - I've not tried this yet, but if you have a build script error, your build does not abort on its own (or, I've not waited long enough). >> <Core.zip>_______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 8, 2010

Re: [Pharo-project] Nanosecond-level profiling in Pharo?

by John McIntosh

I think Eliot wanted those in my vm work I think qwaq has them time to add them I think should it return a Long integer or a double On 1/7/10, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Some times I wanted smaller grain for running tests... but most of the > time millis are good enough :) > > On 2010-01-07 18:52:16 -0300, Alexandre Bergel > <alexandre(a)bergel.eu> said: > >> Hi! >> >> I am currently working on a new profiler for Pharo. The idea is to >> graphically renders a profiling using Mondrian. I hope to release it >> soon. >> When discussing with an expert in the field (Walter Binder), the >> question about time grain was raised. I am partly based on >> MessageTally, which has a millisecond grain. Anyone is aware of a >> finer grain? At the level of nanosecond? Does it makes sense since >> there is no JIT (yet)? >> >> Cheers, >> Alexandre > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Jan. 8, 2010

Re: [Pharo-project] [ANN] Metacello configurations for Pharo.

by Dale Henrichs

----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | ps: There is another version about some tests...sorry, those are the | OB | tests (BogusTestCase) and I don't know why it depends on soemthing I | don't | know what it is...if someone can help me :) The package BogusInfo is required for OB-Tests-Standard (it's an Umbrella package that loads Bogus and BogusExt which contain the mock classes used by the tests)...I've update ConfigurationOfOmniBrowser with the information for BogusInfo which should fix the problem ... a load of just the 'Core Tests' into a 10502 dev image worked without complaint. Dale

Jan. 8, 2010