February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] thinking about a community model of funding

by StÃ©phane Ducasse

Ok now I understand your remark about my strange picture :) > Maybe we should follow the banner approach like wikipedia and wikileaks :) >> >> http://forum.world.st/file/n3260101/PharoBoardAppeal.png > > haha.. who is that gray alien between two humans? :)

Feb. 4, 2011

Re: [Pharo-project] About FileSystem

by StÃ©phane Ducasse

thanks dale. I really like the idea of your validation tool. >> >> >> MetacelloToolBox descriptionForValidationReasonCode: #noVersionSpecified >> >> I got a DNU at:at: > > Ah yes, the at:at: problem .. I have had a fix for that in 1.0-beta.28.3 for awhile but got busy and neglected to push out a new version ... too many things going on:( > > The description for #noVersionSpecified is: > > 'no version defined for the project reference or package. The version specified in the > baseline or the latest version of the project or package in the repository will be used.' > > and the description for #packageNameMismatch is: > > 'the name in the packageSpec does not match the name of the mcz file.' > > You haven't provided the baseline spec or the spec for 1.0.1, but it looks like you must have used the name: > > Filesystem > > in the baseline, while you are using the name > > FileSystem > > (with a capital S) in the 1.0.2 spec and in the 1.0.1 spec. Perhaps you have renamed the package from Filesystem... to FileSystem...? > > #noVersionSpecified is a criticalWarning, because a version spec should have explicit versions specified for all packages and projects, otherwise you don't have a complete specification. As the 1.0.2 spec stands the latest mz file in the repository will be loaded. > > I'll try to push out 1.0-beta.28.3 this weekend:) > > Dale > >

Feb. 4, 2011

Re: [Pharo-project] [COTDC] MCFileRepositoryInspector

by StÃ©phane Ducasse

Ok after some investigations.... I'm a monticello tool composed of three panes to browse repositories and the packages they contain. You get an instance of me when you click on a repository and press open. My left pane presents the packages, my right one their versions and the bottom one the commit log of the selected package versions. Stef On Feb 4, 2011, at 7:57 PM, laurent laffont wrote: > ** 1st Comment Of The Day Contest - One Day One Comment ** > Rules: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > > The first round is for: MCFileRepositoryInspector > > GO GO !! > > Laurent Laffont - @lolgzs > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/

Feb. 4, 2011

Re: [Pharo-project] About FS: sad reality.

by StÃ©phane Ducasse

>> > Maybe the code base is indeed not good enough, not finished (yet). I think that it is good (may be a bit over engineered -- not sure that having visitors is really necessary) but I think that it is good except that it frustates me immensely that I cannot understand it fast. So I stopped. > Maybe some important abstractions and even functionalities are (still) missing. > > A couple of lines of comments (like a class comment stating the purpose), the usual Smalltalk conventions and some unit tests should be the minimum indeed. > > Anyway, things are improving a lot in Pharo, so that is good. > > It is just that it is an enormeous amount of work to write open source code, publish it, support and document it, you know that too. Yes > > Sven > > >

Feb. 4, 2011

Re: [Pharo-project] love CI

by Michael Haupt

Hi Marcus, On 4 February 2011 15:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > ... that we do not do what we teach. typically, most of the software one comes across does not look like one would have written it. When it comes to teaching, and that is true for any language with a reasonable amount of API, this is inevitable as well. If you had written the complete software base that you use in teaching yourself, then "we do not do what we teach" would be painfully correct, but in fact, the phrase should be "we do not use software that was written like we teach" - and that is probably OK since the people that wrote it most likely did not attend your courses. The incident you mention happens to us as well - a lot. We encourage students to improve the system, push their changes to the Inbox and start discussions on the mailing list. Not all of them do, but some, and that is already a success. > We tell them how to program, but they look at the code in front of them and > see something completely different. So there is some clash with only > two possible solutions: Change what you Teach or Change what you Do. The world isn't black and white; that's a fairly pessimistic way of putting things. :-) May I add another solution: encourage people to try and push the principles they learn into existing code and thereby apply that knowledge. Most of the software out there is not as cosy as the perfect teaching environment, but people who understand the ideas of "good code" and "good design" can make a change. Best, Michael

Feb. 4, 2011

Re: [Pharo-project] [COTDC] MCFileRepositoryInspector

by laurent laffont

On Fri, Feb 4, 2011 at 7:57 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > ** 1st Comment Of The Day Contest - One Day One Comment ** > Rules: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > > The first round is for: MCFileRepositoryInspector > > GO GO !! > I build a GUI to browse all packages of a file based repository. For example, you can browse packages of PharoInbox with: (MCFileRepositoryInspector repository: (MCHttpRepository location: 'http://www.squeaksource.com/PharoInbox' user: '' password: '') workingCopy: nil) show. Laurent > > Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ >

Feb. 4, 2011

Re: [Pharo-project] The Comment Game - MMORPG for real

by StÃ©phane Ducasse

:) Social commenting Stef On Feb 4, 2011, at 6:13 PM, laurent laffont wrote: > I propose a little game. > > Each day (not Sunday) I will take a not commented class in PharoCore (in development - 1.3) and tell it on this list. The game is to propose a comment and at the end of the day the best comment will be integrated with the name of his author. > > One day - One comment. > > Ready ? > > Laurent Laffont - @lolgzs > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/

Feb. 4, 2011

Re: [Pharo-project] About FS: sad reality.

by Sven Van Caekenberghe

On 04 Feb 2011, at 19:45, StÃ©phane Ducasse wrote: > sven, I know. Still I think that I read a lot of code in a lot of languages and even more in Smalltalk > and if I cannot find my way with anObject because it was too complex to write aStringOrReference then I should stop and > this is what I'm doing. I stopped. I started to read fileMan and rio again not to integrate them but to have a look. > In addition I'm not in the mood to get a sensitive abstraction dictated by 'oh we should not change it because it should run in squeak'. > > I feel the pain of Monticello without comments and I do not want that for files. I will not crawl to comment it even if people like the design > because I have something else to do about my time. > > I also think that there are funny ideas. Why I cannot create an empty file or why a workingDirection isWorkingDirection is false and why > workingDirection does not return a reference instead of a path......and a lot more. > So > first comment > second test in black box (because most of the tests cannot be used to understand the public api and this is why I was trapped all the time) > third refactor > > but it will not be me. > > Stef Maybe the code base is indeed not good enough, not finished (yet). Maybe some important abstractions and even functionalities are (still) missing. A couple of lines of comments (like a class comment stating the purpose), the usual Smalltalk conventions and some unit tests should be the minimum indeed. Anyway, things are improving a lot in Pharo, so that is good. It is just that it is an enormeous amount of work to write open source code, publish it, support and document it, you know that too. Sven

Feb. 4, 2011

[Pharo-project] [COTDC] MCFileRepositoryInspector

by laurent laffont

** 1st Comment Of The Day Contest - One Day One Comment ** Rules: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). The first round is for: MCFileRepositoryInspector GO GO !! Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/

Feb. 4, 2011

Re: [Pharo-project] About FS: sad reality.

by StÃ©phane Ducasse

sven, I know. Still I think that I read a lot of code in a lot of languages and even more in Smalltalk and if I cannot find my way with anObject because it was too complex to write aStringOrReference then I should stop and this is what I'm doing. I stopped. I started to read fileMan and rio again not to integrate them but to have a look. In addition I'm not in the mood to get a sensitive abstraction dictated by 'oh we should not change it because it should run in squeak'. I feel the pain of Monticello without comments and I do not want that for files. I will not crawl to comment it even if people like the design because I have something else to do about my time. I also think that there are funny ideas. Why I cannot create an empty file or why a workingDirection isWorkingDirection is false and why workingDirection does not return a reference instead of a path......and a lot more. So first comment second test in black box (because most of the tests cannot be used to understand the public api and this is why I was trapped all the time) third refactor but it will not be me. Stef >> Hi guys >> >> I'm sorry but I stopped working on FS. I cannot guess what is private or not, what is the interface of this code. >> I spent my time guessing and guessing wrong. So I stop. Simple. >> In addition I will veto the integration of this code in this state to be added into pharo (sad I started to write an help but >> it is probably full of mistakes). I HATE undocumented code that tell me eveyr minutes that I'm a fucking idiot. >> Too bad I'm not smart enough. Now without decent comments (I mean more than a line in class comment when there is one) we cannot accept code. >> Sad but true. Good luck if you want to use it and improve it. >> >> Stef > > Stef, > > Your quest for more comments is a good and a valid one, no question about it. > And I don't want to defend FS, I only know it from Lukas' blog post and it seemed better than what we have now. > > But the quality of a good design is certainly not just comments. > It is perfectly possible to have code with lots of comments that is still bad. > And if you take away all comments from a good design, it can still be a good design. > Good abstractions, good names, separations of concerns, .. all those things that we all value are important. > Using proper language idioms and conventions is another good idea. > Many good programmers are a bit reluctant to write comments, and they usually value elegant code that speaks for itself. > > I have certainly seen lots of really good code in the image that has little to no comments. > And I have seen lots of comments that make me sick. > > It also seems pretty hard for someone who is not the original author to write comments. > And a prerequisite to writing comments is that you understand and like the system that you are commenting. > If you are struggling with something, that does not seem like a good state of mind to improve the comments. > > Sven > > PS: the public/private distinction is a bit hard in Smalltalk, but the conventions seem to be method categories with 'private' in them, no ? > > >

Feb. 4, 2011