November 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Continuous Integration Server for Pharo?

by StÃ©phane Ducasse

Hi bart we use some scripts (developed at netstyle) and ESUG will support hernan student to develop one. I know that Jorge started also and should work with them. So we should join forces. The idea is that the server should be able to load metacello configuration. Jorge/Hernan/Simon - what is the status - how could we join forces? Stef On Nov 28, 2009, at 1:23 PM, Bart Gauquie wrote: > Dear all, > > I come from a Java world and there we use for instance : http://hudson-ci.org/ to do a continuous integration build. Which means all latest code gets updated, all test ran & if build successful, the code is tagged (so you can take the code again from a successful build). It also provides a nice GUI, and lets you inspect previous builds, the results from that build, ... . > > In Pharo, I did not directly find an alternative, and therefor, also as an exercise, I tried to build one myself. > The primitive, but working result so far is: http://www.squeaksource.com/BuildBot. > > This project depends on BBProjectDescription, which defines class BBBuildProjectDescription with defines: > â¢ BBBuildProjectDescription>>allProjectPackageNames > â¢ BBBuildProjectDescription>>installLatestWithDependencies > â¢ BBBuildProjectDescription>>buildsClassToPutVersionsOn > What buildbot then does is using a BBBuildProjectDescription , checkout all latest code, run the tests for all these packages & , if successfull, take the buildsClassToPutVersionsOn and add a new method on it, describing the exact package numbers : > for instance: > BuildBotMockProjectBuilds class >> packagesForBuild20091127102654 > ^#(('TODO' -> 'TODO-BKBAG.5.mcz') ('BuildBtMockProject' -> 'BuildBtMockProject-BartGauquie.7.mcz') ). > > Using this information I can easily install this exact version. Furthermore creating a release is then just creating for instance a class BuildBotMockProjectReleases with: > BuildBotMockProjectReleasesclass >> release_1_0 > ^BuildBotMockProjectBuilds packagesForBuild20091127102654 > > I am in fact 'tagging' a group packages that belong together and work together. So I can rollout this exact versions of the packages to some image automatically. > > > However, > Today I noticed that there already existed a project: http://www.squeaksource.com/TestServerSimple which more or less does the same thing. The only thing it does not do, or I did not find it, is to version the build, so that you can restore a project again ; a project which is consisting of a number of packages which are compatible and for which all tests ran. Is there a way to do that in TestServerSimple? > > Furthermore, are there any other projects that do a similar thing I'm not aware of? Is there any default way in Pharo to build a project which consists of multiple packages that each have different versions? > > I've seen MetaCello & Gofer as some other way 2 load groups of packages, but no integration into some kind of ci tool. > > This kind of automated ci server seems 2 me an essential tool in Pharo. > > Thanks for any pointers / ideas ! > > Kind Regards, > > Bart > > -- > imagination is more important than knowledge - Albert Einstein > Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein > Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein > The true sign of intelligence is not knowledge but imagination. - Albert Einstein > Gravitation is not responsible for people falling in love. - Albert Einstein > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 29, 2009

[Pharo-project] [update 1.1] #11065

by Marcus Denker

11065 ----- Issue 1512: clean Preferences a little changeset removes (and fixes senders if necessary): SecurityManager removeSelector: #signFile:directory:! Preferences class removeSelector: #browseThemes! Preferences class removeSelector: #checkForUnsavedProjects! Preferences class removeSelector: #defaultValueTableForCurrentRelease! Preferences class removeSelector: #enableLocalSave! Preferences class removeSelector: #expandedPublishing! Preferences class removeSelector: #offerThemesMenu! Preferences class removeSelector: #outOfTheBox! Preferences class removeSelector: #passwordsOnPublish! Preferences class removeSelector: #personal! Preferences class removeSelector: #projectViewsInWindows! Preferences class removeSelector: #projectZoom! Preferences class removeSelector: #signProjectFiles! Preferences class removeSelector: #themeChoiceButtonOfColor:font:! PreferenceBrowserMorph removeSelector: #themeButton! PreferenceBrowser removeSelector: #themeSelected! CodeLoader class removeSelector: #signFile:renameAs:key:dsa:! CodeLoader class removeSelector: #signFiles:in:key:! CodeLoader class removeSelector: #signFiles:key:! CodeLoader class removeSelector: #signFilesFrom:to:key:! as postcript, does: Preferences removePreference: #colorWhenPrettyPrinting. Preferences removePreference: #confirmFirstUseOfStyle. Preferences removePreference: #showSharedFlaps. Preferences removePreference: #checkForUnsavedProjects. Preferences removePreference: #signProjectFiles. Preferences removePreference: #showFlapsWhenPublishing. Preferences removePreference: #passwordsOnPublish. Preferences removePreference: #expandedPublishing. Preferences removePreference: #enableLocalSave.

Nov. 29, 2009

Re: [Pharo-project] Method versioning in Pharo images

by Marcus Denker

On Nov 29, 2009, at 1:27 AM, csrabak(a)bol.com.br wrote: > >> What I would want to have is a server with all old code that than >> is queried by the image... > > Marcus, let me ask to put in this wish list we could have then a > versioning system similar to RCS/CVS and family where you name (in > fact you number and give then alias names, but I digress. . .) the > versions and can put comments documenting the code changes for the > non obvious things in code. Yes... we do have MC, but those compressed .zip snapshots are not really good as a history model to query (the information is there, but you need to anpack all zips...) One important thing that needs to be done is to move on from having multiple mechanism in parallel (sources + changes, MC) to one. > > An escape hatch for the .changes limit would be to serialize all the > versioning information in a .versions file. yes, but it would be very large. Marcus

Nov. 29, 2009

[Pharo-project] [update 1.1] #11064

by Marcus Denker

11064 ----- Issue 1514: remove #isPlayfieldLike Issue 1517: clean TheWorldMainDockingBar a little Issue 1516: clean Project a little... Issue 1515: use SharedQue2 everywhere Issue 1513: add asDictionary Issue 1504: remove PasteUpMorph>>reportLocalAddress Issue 1511: clean a little: SystemDictionary Issue 1506: clean Object a bit.... Marcus

Nov. 29, 2009

Re: [Pharo-project] Method versioning in Pharo images

by csrabak＠bol.com.br

Em 28/11/2009 21:19, Marcus Denker < denker(a)acm.org > escreveu: > On Nov 28, 2009, at 9:42 PM, csrabak(a)bol.com.br wrote: > > > I would like to know if the past history of the method's versions > >has been lost by design or accident. > > In the core image for example it is possible only for the method > > Object>>at: an entry "yo 6/29/2004 11:39". > > Are we considering the implementation of Pharo as a clean slate > > and we'll start from some epoch date? > We had to make new .sources for 1.0... and even if not: the problem > is that the .changes can only be 32MB, and that is reached fast. In > 3.9, we even had to condense changes in the middle of the release > cycle. (This is what you get from never moving on from outdated > technology....) I see. Then is an enviromental imposition ;-) > What I would want to have is a server with all old code that than > is queried by the image... Marcus, let me ask to put in this wish list we could have then a versioning system similar to RCS/CVS and family where you name (in fact you number and give then alias names, but I digress. . .) the versions and can put comments documenting the code changes for the non obvious things in code. An escape hatch for the .changes limit would be to serialize all the versioning information in a .versions file. -- Cesar Rabak

Nov. 29, 2009

Re: [Pharo-project] Method versioning in Pharo images

by Marcus Denker

On Nov 28, 2009, at 9:42 PM, csrabak(a)bol.com.br wrote: > I would like to know if the past history of the method's versions has been lost by design or accident. > > In the core image for example it is possible only for the method Object>>at: an entry "yo 6/29/2004 11:39". > > Are we considering the implementation of Pharo as a clean slate and we'll start from some epoch date? We had to make new .sources for 1.0... and even if not: the problem is that the .changes can only be 32MB, and that is reached fast. In 3.9, we even had to condense changes in the middle of the release cycle. (This is what you get from never moving on from outdated technology....) What I would want to have is a server with all old code that than is queried by the image... Marcus

Nov. 28, 2009

[Pharo-project] Method versioning in Pharo images

by csrabak＠bol.com.br

I would like to know if the past history of the method's versions has been lost by design or accident. In the core image for example it is possible only for the method Object>>at: an entry "yo 6/29/2004 11:39". Are we considering the implementation of Pharo as a clean slate and we'll start from some epoch date? -- Cesar Rabak

Nov. 28, 2009

Re: [Pharo-project] gofer can handle ftp?

by Esteban Lorenzano

Btw, it should be nice if metacello could handle ftp too :( On 2009-11-28 10:10:39 -0300, Esteban Lorenzano <estebanlm(a)gmail.com> said: > Hi, > I'm using it, at Smallworks we use an ftp as repository, not a full > squeaksource :) > Thanks for your point, I will use it... but should be cool to have a > convenience method for that. > > Cheers, > Esteban > > On 2009-11-28 10:02:50 -0300, Lukas Renggli > <renggli(a)gmail.com> said: > >>> I wonder if Gofer can handle ftp besides http. >> >> You can specify any repository type by using the #repository: accessor >> and instantiate your own MCFtpRepository. There are no convenience >> accessors, because I have personally never seen anybody using anything >> else than MCHttpRepository. >> >> Lukas

Nov. 28, 2009

Re: [Pharo-project] gofer can handle ftp?

by Esteban Lorenzano

Hi, I'm using it, at Smallworks we use an ftp as repository, not a full squeaksource :) Thanks for your point, I will use it... but should be cool to have a convenience method for that. Cheers, Esteban On 2009-11-28 10:02:50 -0300, Lukas Renggli <renggli(a)gmail.com> said: >> I wonder if Gofer can handle ftp besides http. > > You can specify any repository type by using the #repository: accessor > and instantiate your own MCFtpRepository. There are no convenience > accessors, because I have personally never seen anybody using anything > else than MCHttpRepository. > > Lukas

Nov. 28, 2009

Re: [Pharo-project] gofer can handle ftp?

by Lukas Renggli

> I wonder if Gofer can handle ftp besides http. You can specify any repository type by using the #repository: accessor and instantiate your own MCFtpRepository. There are no convenience accessors, because I have personally never seen anybody using anything else than MCHttpRepository. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 28, 2009