- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 2705 in pharo: Collection enh for Cog

by pharo＠googlecode.com

Comment #4 on issue 2705 by stephane.ducasse: Collection enh for Cog http://code.google.com/p/pharo/issues/detail?id=2705 Thanks for your feedback. may be should just integrate + copyUpThrough: anElement + "Answer all elements up to and including anObject. If there + is no such object, answer a copy of the receiver." + + ^self first: (self indexOf: anElement ifAbsent: [^ self copy])

Dec. 15, 2010

Re: [Pharo-project] [Progress Report] Zinc HTTP Components

by StÃ©phane Ducasse

Sven our objectives is that any package published in the metacello repositories (once metacello 1.0 is released) should get treated by the pharo hudson server. Eventually we want to have also the VM automatically generated. I should learn how to set more projects :) Stef >> As usual, test results, code critics, and ready made images are available here: >> >> http://hudson.lukas-renggli.ch/job/Zinc/ > > I must say that I am quite addicted to your Hudson server, almost every time I check in I go look at the page to see how it rebuilds. > > It is really useful to have an integration server like that, and I can image it must be real fun for the (core) Pharo team as integration is one of their main issues. And it is instructive to so see all the Smalltalk scripting going on. > > Sven > >

Dec. 15, 2010

Re: [Pharo-project] Lecture on software quality

by StÃ©phane Ducasse

excellent! Thanks a lot for all this good work and energy. Could you sign the pharo license? Stef On Dec 15, 2010, at 10:25 PM, Alexandre Bergel wrote: > Dear Friends and Colleagues, > > I would like to share with you the results we obtained in the lecture Romain and I organized at the University of Chile. The lecture is about Software Quality, and the students had to improve some Pharo applications as a mandatory activity. The lecture is now over, after 3 months of intense work. > > Here are the results we had: > - Monticello: some cycles between packages have been removed (http://code.google.com/p/pharo/issues/detail?id=3440) > - XMLParser: 252 new green tests, 78 are still red, we are working on it. XML-Tests-Conformance-JAAyer.2 in the XMLSupport squeaksource repository > - Polymorph: 24 tests are added (http://code.google.com/p/pharo/issues/detail?id=3441) Tests-Polymorph-AlexandreBergel.10 in the inBox. > - Merlin: cleaning + 26 tests are added. Currently being added to Merlin and Moose > > We sincerely thank all the external tutors for their support, the Pharo integration crew, and all the students. > The students made a tremendous job: after two weeks of Smalltalk training, they produced code enhancement, bug fixes, participated in the Pharo Sprint, have written tests that are now either part of Pharo or included into widely used tools. > > I hope you will be able to see some of them in Scotland. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > >

Dec. 15, 2010

Re: [Pharo-project] Issue 3440 in pharo: Cycle in Monticello removed

by pharo＠googlecode.com

Comment #1 on issue 3440 by alexandre.bergel: Cycle in Monticello removed http://code.google.com/p/pharo/issues/detail?id=3440 Thanks Felipe Valverde!

Dec. 15, 2010

[Pharo-project] Lecture on software quality

by Alexandre Bergel

Dear Friends and Colleagues, I would like to share with you the results we obtained in the lecture Romain and I organized at the University of Chile. The lecture is about Software Quality, and the students had to improve some Pharo applications as a mandatory activity. The lecture is now over, after 3 months of intense work. Here are the results we had: - Monticello: some cycles between packages have been removed (http://code.google.com/p/pharo/issues/detail?id=3440) - XMLParser: 252 new green tests, 78 are still red, we are working on it. XML-Tests-Conformance-JAAyer.2 in the XMLSupport squeaksource repository - Polymorph: 24 tests are added (http://code.google.com/p/pharo/issues/detail?id=3441) Tests-Polymorph-AlexandreBergel.10 in the inBox. - Merlin: cleaning + 26 tests are added. Currently being added to Merlin and Moose We sincerely thank all the external tutors for their support, the Pharo integration crew, and all the students. The students made a tremendous job: after two weeks of Smalltalk training, they produced code enhancement, bug fixes, participated in the Pharo Sprint, have written tests that are now either part of Pharo or included into widely used tools. I hope you will be able to see some of them in Scotland. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 15, 2010

[Pharo-project] Issue 3441 in pharo: Tests for Polymorph

by pharo＠googlecode.com

Status: Accepted Owner: alexandre.bergel CC: stephane.ducasse Labels: Difficulty-Easy New issue 3441 by alexandre.bergel: Tests for Polymorph http://code.google.com/p/pharo/issues/detail?id=3441 Tests-Polymorph-AlexandreBergel.10 in the inBox. It contains 24 tests. Result of CC68S lecture. Thanks Luis Gregorio Silvestre Quiroga!

Dec. 15, 2010

[Pharo-project] Issue 3440 in pharo: Cycle in Monticello removed

by pharo＠googlecode.com

Status: Accepted Owner: alexandre.bergel CC: stephane.ducasse Labels: Difficulty-Easy New issue 3440 by alexandre.bergel: Cycle in Monticello removed http://code.google.com/p/pharo/issues/detail?id=3440 A cycle is due to a dependency of Monticello-Chunk Format to Monticello-Storing. Monticello-FelipeValverde.472 in the inBox fixes this. DSM was used for this. Result of the CC68S lecture

Dec. 15, 2010

Re: [Pharo-project] TextLint question

by Alexandre Bergel

Just to end this thread on a positive note: TextLint is really amazing and incredibly useful. Cheers, Alexandre On 15 Dec 2010, at 15:53, Lukas Renggli wrote: > Yes, but unfortunately that's not easy to do with Glamour, AFAIK. > > Lukas > > On 15 December 2010 18:00, Alexandre Bergel <alexandre(a)bergel.eu> wrote: >> A cheap solution is to adjust the indexes according to the number of backslash key and non-backslash key that one press. >> >> Alexandre >> >> >> On 15 Dec 2010, at 13:35, Fabrizio Perin wrote: >> >>> Hi Alex, >>> well the text index is calculated when you run the rules so of course if you touch the text than the indexes are not precise anymore. When you accept the text is saved and the rules are recalculated so also the positions of the errors are calculated again. >>> >>> Unfortunately i don't have a nice solution for this problem. One way could be: >>> - when you save instead running the rules you just save the modified document. >>> - than all the indexes of all the errors are update with the difference in size between the old and the new document. >>> >>> I don't know if this is going to be faster than simply re-run the rules. Anyway I will give it a try and i will let you know. >>> >>> Cheers, >>> >>> Fabrizio >>> >>> >>> 2010/12/15 Alexandre Bergel <alexandre(a)bergel.eu> >>> hi! >>> >>> I am now using TextLint over my submissions. Each time I modify the text, the rest of the errors have a wrong text index. It makes it difficult to use. >>> I do an accept, to save my .tex and run the rules again, but it takes time... >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 15, 2010

Re: [Pharo-project] TextLint question

by Lukas Renggli

Yes, but unfortunately that's not easy to do with Glamour, AFAIK. Lukas On 15 December 2010 18:00, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > A cheap solution is to adjust the indexes according to the number of backslash key and non-backslash key that one press. > > Alexandre > > > On 15 Dec 2010, at 13:35, Fabrizio Perin wrote: > >> Hi Alex, >> well the text index is calculated when you run the rules so of course if you touch the text than the indexes are not precise anymore. When you accept the text is saved and the rules are recalculated so also the positions of the errors are calculated again. >> >> Unfortunately i don't have a nice solution for this problem. One way could be: >> - when you save instead running the rules you just save the modified document. >> - than all the indexes of all the errors are update with the difference in size between the old and the new document. >> >> I don't know if this is going to be faster than simply re-run the rules. Anyway I will give it a try and i will let you know. >> >> Cheers, >> >> Fabrizio >> >> >> 2010/12/15 Alexandre Bergel <alexandre(a)bergel.eu> >> hi! >> >> I am now using TextLint over my submissions. Each time I modify the text, the rest of the errors have a wrong text index. It makes it difficult to use. >> I do an accept, to save my .tex and run the rules again, but it takes time... >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel Â http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > -- Lukas Renggli www.lukas-renggli.ch

Dec. 15, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Igor Stasenko

On 15 December 2010 19:30, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Dec 15, 2010 at 5:23 AM, Peter van Rooijen <peter(a)vanrooijen.com> > wrote: >> >> On Fri, 10 Dec 2010 21:11:47 +0100, Eliot Miranda >> <eliot.miranda(a)gmail.com> wrote: >> >> Note that not writing source to the changes file has ancilliary benefits; >> change recovery is now not polluted with package loads and the changes >> file >> does not grow as packages are added, only as one's changes are made. >> Unloading a package doesn't leave garbage in the changes files. >> >> There are downsides. Â Deploying a development image means deploying all >> the >> associated parcel source files as well, and for this a >> platform-independent >> Filename abstraction really helps. >>> >>> Thanks for the explanation. I wonder how the previous versions of a >>> method can be found using parcels. >> >> I hacked a dreadful implementation of overrides in vw3.0 and I don't think >> things are much better now. Â But >> inÂ http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg17714.ht… >> I sketched how I think it should be done: >> Maintain a global package load order (a stack of loaded packages, removing >> interior elements on unload). >> Maintain a dictionary from method reference to set of package/method pairs >> for each method that is overridden. >> When a package is removed search overrides and compute the overridden >> methods to be reinstalled, computing the uppermost method depending on the >> new package order. >> So to answer your question, one finds the previous versions directly in >> the overrides dictionary, and sorts the results according to the current >> package load order. >> >> Wasn't Levente asking about "regular" replacing of methods? >> >> I thought his question was about that; if the source is not in >> >> the changes file but in a parcel source file, then when I save >> >> a new version of a method and want to look for the old one, >> >> that will not be in the changes file. > > No. Â Anything you write goes on the changes files including new method > definitions, doits, reorganizations, method removals class removals etc. > >> >> When I build up a new image >> >> from parcels, the load script copies all the sources to the >> >> changes file, so I have easy access to the history. > > Why bother? Â A published parcel is an immutable versioned artifact. Â It > doesn't change over time, so, like a release sources file, one can always > rely on its contents. +1 Instead of putting all methods and classes from package into .changes it could be just a simple doit, like: MC load: 'blahblah.mcz' It could be somewhat different during merge. > HTH > Eliot -- Best regards, Igor Stasenko AKA sig.

Dec. 15, 2010