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

Re: [Pharo-project] Dev images with or without tests?

by Tudor Girba

I vote for their presence for all the reasons you mentioned. Cheers, Doru On 5 Jan 2010, at 22:11, Mariano Martinez Peck wrote: > Ok, that's the big questions. Until now, the Dev image only > cointained the tests of the PharoCore image. Actually, it also > included the tests fro those projects where the test were in the > same package (for example, RoelTyer). Now, with the new Metacello > infrastructure, you will be able to take a PharoCore and evaluate: > > (ConfigurationOfPharo project version: '10496') load (which it > will load the defualt stuff, in this case, all the stuff for a dev > image) > > or > > (ConfigurationOfPharo project version: '10496') load: > 'StandardDevImageWithTests' > > which will loads not only all the packages, but also ALL the test of > all packages (all packages that have tests). > > So, my question is, should the test be included in the default dev > image? > > I think that yes, because of the following: > > 1) Tests are useful for documentation > 2) It encourages people to run the tests before committing something > (that may break something) > 3) You can see the state of the image you are using. > 4) Because they are not bad > 5) Because if you don't want to load the test, just add a simple > 'StandardDevImageWithoutTests' after the load. > 6) I don't think they take a lot of size in an image. In addition, > it is a DEV image, not production. In production is logic that you > don't want the tests and that may be even done with something > similar to ScriptLoader >> cleanUpForProduction > > So..what do you think ? > > Cheers > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Beauty is where we see it."

Jan. 5, 2010

[Pharo-project] Dev images with or without tests?

by Mariano Martinez Peck

Ok, that's the big questions. Until now, the Dev image only cointained the tests of the PharoCore image. Actually, it also included the tests fro those projects where the test were in the same package (for example, RoelTyer). Now, with the new Metacello infrastructure, you will be able to take a PharoCore and evaluate: (ConfigurationOfPharo project version: '10496') load (which it will load the defualt stuff, in this case, all the stuff for a dev image) or (ConfigurationOfPharo project version: '10496') load: 'StandardDevImageWithTests' which will loads not only all the packages, but also ALL the test of all packages (all packages that have tests). So, my question is, should the test be included in the default dev image? I think that yes, because of the following: 1) Tests are useful for documentation 2) It encourages people to run the tests before committing something (that may break something) 3) You can see the state of the image you are using. 4) Because they are not bad 5) Because if you don't want to load the test, just add a simple 'StandardDevImageWithoutTests' after the load. 6) I don't think they take a lot of size in an image. In addition, it is a DEV image, not production. In production is logic that you don't want the tests and that may be even done with something similar to ScriptLoader >> cleanUpForProduction So..what do you think ? Cheers Mariano

Jan. 5, 2010

Re: [Pharo-project] About documentation

by Michael Roberts

yes please, i'll do some doc edits... cheers, Mike On Tue, Jan 5, 2010 at 7:54 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > yes you can remove them > > On Jan 5, 2010, at 8:41 PM, Simon Denier wrote: > >> >> On 5 janv. 2010, at 20:09, StÃ©phane Ducasse wrote: >> >>> It means that people can edit page, leave note and that a person/group of person with a password >>> can edit/delete.... >>> since you get an rss feed you can monitor the complete book. >> >> >> One of the interest I see in such a project is that it can be of great help for future chapters. I can see an editor creating a chapter with basic stuff, for example about Morphic and Announcements, just to track small scripts and knowledge, before one takes over to write a full chapter (ok, maybe I'm dreaming, but that would be great for the yet-to-come "Morphic tutorial for pro applications") >> >> With respect to the previous thread about documentation, it is obvious that such a book complement comments and do not replace them. >> >> >> I wonder, is there a way to hide/delete comments which got "deprecated" after a while? >> >> >>> Stef >>> >>> On Jan 5, 2010, at 7:46 PM, Simon Denier wrote: >>> >>>> >>>> On 5 janv. 2010, at 19:14, StÃ©phane Ducasse wrote: >>>> >>>>> Hi guys >>>>> >>>>> I discussed with lukas and we could get the same infrastructure than for the seaside book >>>>> http://book.seaside.st >>>>> Â Â - editable but with editor control. >>>>> Â Â - able to generate latex >>>>> >>>>> Now I want to know if some of you want to control that because I cannot. >>>> >>>> What does 'control' mean in this case? >>>> >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> 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 >

Jan. 5, 2010

Re: [Pharo-project] What about killing PharoWeb images?

by StÃ©phane Ducasse

this is true that the data are really surprising to me. So I was wrong about the uses scenario. So some people really like to use web on advanced bleeding edge software :) > It doesn't take me much time to build PharoWeb images currently > because Seaside 2.8 is quite stable. However, you may be right when > you say that it is not Pharo's job to build Seaside images. Damien I think that I would prefer you get your little time pushing pharo-dev :) > Download counts can be seen on GForge website: > https://gforge.inria.fr/frs/?group_id=1299. I also provide some > not-up-to-date graphics: > http://damiencassou.dabbledb.com/publish/dev-imagesdownloads. These > statistics show that web images are downloaded by nearly as much > people as the dev images. stef

Jan. 5, 2010

Re: [Pharo-project] Beginner question :) search and replace in String

by Ramon Leon

On 1/4/2010 5:02 PM, Adrian Kuhn wrote: > Levente Uzonyi<leves@...> writes: > That is, if you *really* want to mimic the entire bandwidth of natural language, > you should also mimic the tendency of natural languages to introduce > abbreviations for common concepts. This is an *essential* part of any natural > language. IMHO, abbreviations are evil and have no place in Smalltalk and is not an essential part of natural *spoken* language. If one can't read one's code out loud in plain words, then something is wrong with the code. Abbreviations make no sense at all in the era of code completion and intellisense. -- Ramon Leon http://onsmalltalk.com

Jan. 5, 2010

[Pharo-project] [update 1.1] #11137

by StÃ©phane Ducasse

11137 ----- - Issue 1737: DNU when opening halo HaloMorph initialize - Issue 207: ImageSegment discoverActiveClasses strange error - Issue 1204: ByteString(Object)>>error:Improper store into indexable object - Issue 1744: WordSize - Issue 1740: remove createMethod:header: from arrayedCollection

Jan. 5, 2010

Re: [Pharo-project] What about killing PharoWeb images?

by Damien Cassou

2010/1/5 Mariano Martinez Peck <marianopeck(a)gmail.com>: > 3) Don't create PharoWeb images any more but gives the user the possibilities to use Seaside + Pharo. > 3) For me it is the best solution. We can do, the following things: > > 3.a) Put in www.pharo-project.org/download a text among these lines: > 3.b)Â Using this way, we encourage people to use the Metacello configuration for Seaside and that's the most important thing because we can give feedback on it, fix issues, etc. And this is also shared for example with Gemstone. They will give feedback on us and us on them. We will probable make even simpler the move for applications from Pharo to Gemstone. > 3.c) Those beta testers that said that they would test Web images, can just install Seaside exactly the same way a final user will do (use the metacello configuration). So...we are also testing that. > > 3.d) Not now, but maybe in a future we can even use the Esteban Lorenzano's Loader for Metacello. That would be even simpler. They will be able to take a PharoDev image and just evaluate:Â Loader load:'Seaside 2.8.4' and wala! Lukas is right when he said that PharoWeb used to have Aida in. I stopped installing Aida inside PharoWeb images because it was kind of a pain to make Seaside and Aida work happily together. It doesn't take me much time to build PharoWeb images currently because Seaside 2.8 is quite stable. However, you may be right when you say that it is not Pharo's job to build Seaside images. Download counts can be seen on GForge website: https://gforge.inria.fr/frs/?group_id=1299. I also provide some not-up-to-date graphics: http://damiencassou.dabbledb.com/publish/dev-imagesdownloads. These statistics show that web images are downloaded by nearly as much people as the dev images. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Jan. 5, 2010

Re: [Pharo-project] What about killing PharoWeb images?

by Tudor Girba

I too believe that is the best choice at this moment. Cheers, Doru On 5 Jan 2010, at 20:15, StÃ©phane Ducasse wrote: > Let us be pragmatic and focused. > > I would say that I would prefer to have one single pharo-dev image > than a middle pharo-dev image and a pharo-web. > We can focus on pharo-dev > And let lukas ship a one-click seaside image. > > With the time the pharo-dev will support easy configuration to load > seaside > aida > and a lot more so we will just offer one good image and let people > decide. > so I would focus on our customers first :) > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Reasonable is what we are accustomed with."

Jan. 5, 2010

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

by StÃ©phane Ducasse

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

Jan. 5, 2010

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

by Yanni Chiu

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

Jan. 5, 2010