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

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

by Michael Rueger

Marcus Denker wrote: > On Nov 29, 2009, at 6:15 PM, Schwab,Wilhelm K wrote: > >> What is the source of the change log size limit? >> > > 32MB. Would it be possible with the current compiled method format to make the source pointer a first class object? A looong time ago I did that in VW and used it to keep most of the sources in package files, reducing the size of the change log by quite a bit. It would allow to have the source point to some remote location. Michael

Nov. 29, 2009

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

by Marcus Denker

On Nov 29, 2009, at 6:15 PM, Schwab,Wilhelm K wrote: > However, for "independent" read "redundant." Take away the redundancy, and there is a single point of failure. That keeps surfacing as a good idea, and I fear the backlash once the redundancy gets removed in the name of saving space. > but if you want redunancy, provide a service that does that. One thing. And than reuse it. A log of course would provide redundancy. That's the definition. The only difference is that it would *only be a log*, and nothing else. > What is the source of the change log size limit? > 32MB. Marcus

Nov. 29, 2009

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

by Schwab,Wilhelm K

However, for "independent" read "redundant." Take away the redundancy, and there is a single point of failure. That keeps surfacing as a good idea, and I fear the backlash once the redundancy gets removed in the name of saving space. What is the source of the change log size limit? -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Marcus Denker Sent: Sunday, November 29, 2009 8:55 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Method versioning in Pharo images On Nov 29, 2009, at 2:48 PM, Schwab,Wilhelm K wrote: > One thing that I like about the split (image, changes, sources) approach is that the changes seldom go bad, providing a lot of protection against lost work. > But having a log of commited methods and doits is independend of where the source is saved, and especially independend of a source repository. Of course, you want keep the changelog.... but only for that: a log. Marcus > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Marcus Denker > Sent: Sunday, November 29, 2009 3:26 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Method versioning in Pharo images > > > 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 > > _______________________________________________ > 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 _______________________________________________ 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

Re: [Pharo-project] pharo and db support

by Johan Brichau

In our experience, Magma took around 250ms, regardless if the query had a large or small set of results. Using GOODS, our application appears to run as fast as if the object collections were kept in-image only (response times of 10ms for our queries). Maybe it will run slower for very large object collections but since we will not run into that problem, it's not an issue in our case. There's some differences regarding transactions support which we had to cope with, but it all seems to run just fine right now. and thanks for having suggested it! ;-) On 29 Nov 2009, at 13:26, Niko Schwarz wrote: > Glad to hear it :). Is it really faster than Magma in your experience? > > Cheers, > > Niko > > On Sun, Nov 29, 2009 at 11:11 AM, Johan Brichau > <johan.brichau(a)uclouvain.be> wrote: >> We are using GOODS for a while now and it runs pretty well. I have >> added it to the wikipage. >> >> On 26 Nov 2009, at 17:39, Tudor Girba wrote: >> >>> Hi, >>> >>> I would like to collect a list of the solutions to link Pharo with >>> existing databases. I am interested in both relational and in object >>> databases. >>> >>> Is there a list somewhere? If not and if you know/use/develop/ >>> such a >>> solution, it would be great if we could put it together by >>> collecting >>> some data about these: >>> >>> - Pharo project and version >>> - Supported database vendor and version >>> - Maturity: prototype/production ready/ >>> - Projects that use this one >>> - Current development status and maintenance support (if any) >>> - Website >>> - Others >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "If you interrupt the barber while he is cutting your hair, >>> you will end up with a messy haircut." >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> ---------------------------- >> Johan Brichau >> johan.brichau(a)uclouvain.be >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41 076 235 8683 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Nov. 29, 2009

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

by Jorge Ressia

Hi, I am currently working with Diego Kogan on the Continuous Integration Server for pharo. We will be working heavily the comming two weeks in order to finish the implementation of the basic requirements. Our case studies will be Moose and Seaside. We expect ot have a running version for mid december. Cheers, Jorge On Sun, Nov 29, 2009 at 7:53 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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 > > > _______________________________________________ > 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

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

by Marcus Denker

On Nov 29, 2009, at 2:48 PM, Schwab,Wilhelm K wrote: > One thing that I like about the split (image, changes, sources) approach is that the changes seldom go bad, providing a lot of protection against lost work. > But having a log of commited methods and doits is independend of where the source is saved, and especially independend of a source repository. Of course, you want keep the changelog.... but only for that: a log. Marcus > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Marcus Denker > Sent: Sunday, November 29, 2009 3:26 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Method versioning in Pharo images > > > 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 > > _______________________________________________ > 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

Nov. 29, 2009

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

by Schwab,Wilhelm K

One thing that I like about the split (image, changes, sources) approach is that the changes seldom go bad, providing a lot of protection against lost work. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Marcus Denker Sent: Sunday, November 29, 2009 3:26 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Method versioning in Pharo images 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 _______________________________________________ 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

Re: [Pharo-project] pharo and db support

by Niko Schwarz

Glad to hear it :). Is it really faster than Magma in your experience? Cheers, Niko On Sun, Nov 29, 2009 at 11:11 AM, Johan Brichau <johan.brichau(a)uclouvain.be> wrote: > We are using GOODS for a while now and it runs pretty well. I have > added it to the wikipage. > > On 26 Nov 2009, at 17:39, Tudor Girba wrote: > >> Hi, >> >> I would like to collect a list of the solutions to link Pharo with >> existing databases. I am interested in both relational and in object >> databases. >> >> Is there a list somewhere? If not and if you know/use/develop/ such a >> solution, it would be great if we could put it together by collecting >> some data about these: >> >> - Pharo project and version >> - Supported database vendor and version >> - Maturity: prototype/production ready/ >> - Projects that use this one >> - Current development status and maintenance support (if any) >> - Website >> - Others >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "If you interrupt the barber while he is cutting your hair, >> you will end up with a messy haircut." >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Nov. 29, 2009

Re: [Pharo-project] pharo and db support

by Johan Brichau

We are using GOODS for a while now and it runs pretty well. I have added it to the wikipage. On 26 Nov 2009, at 17:39, Tudor Girba wrote: > Hi, > > I would like to collect a list of the solutions to link Pharo with > existing databases. I am interested in both relational and in object > databases. > > Is there a list somewhere? If not and if you know/use/develop/ such a > solution, it would be great if we could put it together by collecting > some data about these: > > - Pharo project and version > - Supported database vendor and version > - Maturity: prototype/production ready/ > - Projects that use this one > - Current development status and maintenance support (if any) > - Website > - Others > > Cheers, > Doru > > -- > www.tudorgirba.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Nov. 29, 2009

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

by Michael Rueger

Marcus Denker wrote: > What I would want to have is a server with all old code that than is > queried by the image... Almost a year ago I did some work on a database, but then it got stuck on the back burner. What would be helpful in the future would be to have unique ids for every method, class version etc. I think Craig did this in Spoon. Michael

Nov. 29, 2009