Squeakfoundation June 2003

squeakfoundation@lists.squeakfoundation.org

30 participants
59 discussions

RE: [Squeakfoundation]Harvester status for Marcus Denker
by Brent Vukmer 12 Jun '03

12 Jun '03

> I went ahead and added Marcus to the current list of > harvesters, to make > it official: Congratulations Marcus! It's really cool to see harvesting momentum building -- a lot of which is due to your whirlwind activity.

1 0

Harvester status for Marcus Denker
by Daniel Vainsencher 12 Jun '03

12 Jun '03

I think Marcus has done more useful harvesting work in the last couple of days than most of us in N weeks. I'd say that Marcus can and should be trusted to approve stuff, except for one thing - I haven't seen him post critical comments on any of the code he's reviewed, and for anyone that's going to be able to get stuff into the image where we all have to live with it, I want to know that he can be point out where code is lacking. Except for the selection aspect, this is also important because posting these public comments is the way knowledge is transmitted about good/bad practice, and not just to the author of the specific code. What does everybody think? Daniel

5 6

Just let me know if I lose my time and yours
by Stephane Ducasse 11 Jun '03

11 Jun '03

Hi guides and others I can tell you that the last email of Andreas makes me think a lot. I'm a respectable researcher, I have a lot of cool ideas and write a lot of smart papers, I have lot of fun programming in Smalltalk, organizing ESUG, I have kids, and a nice social life. But I do not need KCP, really I do not need it. I do it because I feel it important. Now if you think that I'm over cleaning, over refactoring, if you think that I'm creating too much classes and that Squeak should stay the way it is, please let me now immediately because I ***really*** have something else to do for my evenings. I have enough to do. Really! You may think that I'm over exaggerating, in such a case consider that this over exaggeration is the clear sign that I have something else to do. Stef From: Stephane Ducasse <ducasse(a)iam.unibe.ch> Date: Wed Jun 11, 2003 10:14:15 PM Europe/Zurich To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> Cc: Roel Wuyts <wuyts(a)iam.unibe.ch>, Alexandre Bergel <bergel(a)iam.unibe.ch> Subject: Re: [KCP] SystemDictionary cleaning: Comments and design Come one andreas Image abandoneSources Does not tell you something? Please tell me that I'm wrong and stupid to lose my time cleaning Squeak and I stop. Seriously. No joke. I have something else that hearing that. Stef On Wednesday, June 11, 2003, at 09:18 PM, Andreas Raab wrote: > Stef, > >>> Look for instance at Utilities class comment. It >>> says: 'methods that don't naturally attach to anything else'. These >>> methods are functions and you won't create instances of the new >>> classes, they are just more or less function-holders. There is no >>> complicated interdependency of classes and methods to understand. It >>> is only a question of 'listing' these functions. >> >> If this is what **you** believe... > > And me too. If there is a recognizable concept for a number of methods > which > make sense to think about them as "attached to" a common class (system > navigation for example) then I'm all for it. But in many other cases we > merely have utility functions and forcing "arbitrary concepts" will > only > make things more complex - mostly you will start moving around the > methods > for the mere purpose of putting them NOT into a specific place which > means > you'll have much more confusion in the long term. > > For example, consider a method like #abandonSources. I don't see any > easy > place where this method should live and if you would forcefully "clean > up" > SystemDictionary then all you know is that you do NOT want it there - > but > you've got no good concept yet where to stick it otherwise. Let's > consider > someone says "let's put this into FileDirectory" because it does > something > with files. Now, any code has to be rewritten against file directory. > Except > that at some later point someone might say "oh, it really belongs into > FileStream" and then any code has to be rewritten against that place. > And so > on. In the long-term, there are always going to be some utility methods > which cannot be cleanly attached to some class or other and then it's > really > more about "listing" them. > > The bottom line of this is really: a) Think *very* carefully about the > classes (concepts) you want to introduce for utility methods. b) > Provide a > (couple of) generic places where utility methods can live. Right now > we have > two such places - SystemDictionary which holds most of the "environment > related" utility methods and Utilities which holds most of the rest. > Introducing a hundred new classes all of which have one or two methods > just > so that they are NOT in some place isn't very good design either. IMO > at > least. > > Cheers, > - Andreas

1 0

Re: [Squeakfoundation] Harvesting review policies (and a lil' love from the BFAV)
by Daniel Vainsencher 11 Jun '03

11 Jun '03

Brent Vukmer <bvukmer(a)blackboard.com> wrote: > I immediately think of integrating SLint services into the > BugFixArchiveViewer, which seems like it would provide the biggest > immediate gain... Do you guys agree? That sounds definitely worth doing. > Can SLint be run on a changeset file? Unfortunately not. I've looked at the code a little, but it passes around class names, that are then looked up in Smalltalk, making it difficult to replace. What we could do is run it on the changed code after installing the changeset. This will also require a little integration - something that creates a SelectorEnvironment from the cs and then runs a SmalllintChecker on them. > Daniel, would it be easy for you to make SLint a separate package? I > *could* create a dependency on the Refactoring Browser .. But that seems > a bit heavyweight to me. As you see above, packaging is not our biggest problem. I'll see about doing the above, and then we'll think more. Daniel

1 0

RE: [Squeakfoundation] Harvesting rules (was Re: Harvester status for Marcus Denker)
by Brent Vukmer 10 Jun '03

10 Jun '03

> > Anyway, a good start on getting a policy going might be to create a > standalone tool which operates on a changeset, which would check for > things like class comments being in place for newly defined > classes. It > could also run some subset of SLint tests (whichever rules we > agree on), > so SLint would be a prerequisite of the tool. (One issue I ran into > with SLint is that it would be nice if it could just be run on the > changed code, not the entire method. That might not be simple to > implement, I realize.) > > Plus the tool could have a few simple checks to make my life as the > update-stream manager easier, such as making sure the changeset name > isn't too long, doesn't have funny characters in it, etc. (Simply > forcing it to be a changeset is even of some value... for example I'm > about to incorporate Michael's network rewrite, but that's a > SAR file, > so I have to incorporate the 10 or so changesets/fileins separately, > some of which could probably be combined, etc. Not a huge > problem but > still it's a bit of extra work for me.) > > Then the idea would be that any submission must pass through the tool > before it is [approved]. The harvesters could use the tool at first, > but eventually people submitting things would want to run submissions > through the tool themselves. > Doug, it's like you're reading my mind. The one thing I would add to your list, is that this tool should register with the FileList. If this tool existed, and registered with the FileList, it would automagically be available in the BugFixArchiveViewer.

1 0

Harvesting review policies (and a lil' love from the BFAV)
by Brent Vukmer 10 Jun '03

10 Jun '03

> > So for example, if Brent had responded and said "Hey, I can > add those policy rules right inside the BugFixArchiveViewer! > Easily accessible!" then I would have been more interested! ;-) Heh. Hint, hint. Goran are you thinking of just a "harvester review-quality guidelines" window? That would be easy to add, obviously, if you guys send me the text you want. Or are you thinking of new services to be plugged into BugFixArchiveViewer? I immediately think of integrating SLint services into the BugFixArchiveViewer, which seems like it would provide the biggest immediate gain... Do you guys agree? Can SLint be run on a changeset file? If so, the very easiest way to provide that integration would be: (A) Daniel makes SLint a separate package on SqueakMap (B) Some cheerful Squeaker enhances SLint so that it registers with the FileList (C) I make the BugFixArchiveViewer load script aware of the new dependency on SLint (D) Slint services are magically provided in BugFixArchiveViewer via the FileList Future "plugin" functionality for the BugFixArchiveViewer will be easiest to add in the form of services that can be registered with FileList, BTW. Daniel, would it be easy for you to make SLint a separate package? I *could* create a dependency on the Refactoring Browser .. But that seems a bit heavyweight to me.

1 0

RE: [Squeakfoundation]Harvester status for Marcus Denker
by Brent Vukmer 10 Jun '03

10 Jun '03

> > > Well, it would be interesting to write down the policy > somewhere - at > > least the non obvious and the mandatory stuff. I am not > saying "Swiki" > > because I am a bit tired of simply creating more and more > pages on the > > Swikis, but if no other smarter way is found then sure, why not. > What's wrong with the Swiki? > > Daniel I think the main issue with the Swiki is that there is not yet a tool that allows us to easily and quickly edit the Swiki from within Squeak.

3 3

Re: [Squeakfoundation]Harvester status for Marcus Denker
by Daniel Vainsencher 10 Jun '03

10 Jun '03

[what is important to review] I find myself surprised, not completely unpleasently, at how different our tendencies are on this. I say this is a little good, because it's a more complete picture of what we should be doing than any one of us would have. But it's mostly bad, because IMO, having each of us checking what we feel like stinks. A. It sends out a really confused message as to what code should be like (you need a class comment, except if dvf is checking it, in which case just make sure you're not adding anything to Object! ;-) B. It's not a way to improve the quality of the code. Let's face it, if three of the harvesters don't have the same standards, why the heck should we assume that Ted does have (and if does, who's does he have? Mine? Doug's?) We need a policy. It doesn't have to be complicated, but it needs to keep the image clean, systematically, not by chance. We need to balance this with keeping things fun, sure, so we'll have to be smart about it, but we need to deal with this. If we are warm and fluffy on this one, we can stop the cleanup projects right now, because quality will go down, not up, no matter how hard they work. If we agree on this, here are some things I think we could do - * Find a good online reference for writing good Smalltalk code, ideally, something like Kents "Best Smalltalk practices". * All of us read it, read all code before approving stuff, and point people at the manual when said stuff stinks. * Require use of SLint. It's easy to install, there's a "SmallLint Tutorial" on SM. * Maybe make class comments mandatory, and implement some automated check for this, so I don't forget it. What do you think? Other ideas? Daniel Doug Way <dway(a)riskmetrics.com> wrote: > goran.krampe(a)bluefish.se wrote: > > >Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > > > > > >>Except for one thing - I haven't seen him post critical comments on any of the > >>code he's reviewed, and for anyone that's going to be able to get stuff > >>into the image where we all have to live with it, I want to know that he > >>can be point out where code is lacking. > >> > >> > > True, although I have to admit that I don't often have comments about > the source code that I'm reviewing. More often I have a comment about > some aspect of what the change does. (such as my extra comments about > the BoundsInHaloFix2 changeset) > > I guess I usually just give the source code (diffs) a quick look-over to > make sure that nothing jumps out at me as being ugly. As far as judging > source code, another factor is who wrote it... typically I will have a > level of trust that somone like Ted Kaehler or Ned Konz won't need to > have their code heavily scrutinized, but I may look more closely at the > code of someone I don't know. (However, external testing is another > matter... that's equally important for all submissions.) > > >Personally I have found that the > >code I have reviewed from others generally is good - but class comments > >and method comments tend to lack IMHO. > > > >I really want the quality of comments to be higher in the official > >classes. I would personally never let classes in without class comments. > > > > > > This is probably a good rule of thumb. New classes should certainly > include class comments before we approve them. It's harder to have any > simple rule about method comments... most methods do not need comments > and should not have them, but some methods do need comments. > > >>Except for the selection aspect, this is also important because posting > >>these public comments is the way knowledge is transmitted about good/bad > >>practice, and not just to the author of the specific code. > >> > >>What does everybody think? > >> > >> > > > >I definitely think Marcus should be a Harvester - if he likes to be one. > >:-) > > > > I agree. (Oh wait, I see he's already approving items anyway... :-) ) > > - Doug Way > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

4 3

Re: [Squeakfoundation]Harvester status for Marcus Denker
by Daniel Vainsencher 10 Jun '03

10 Jun '03

Meaningfull tests for every class are a good goal, and the test server will make them much more meaningful. OTOH, I don't think checking for a class comment is a good use for a test, it's too wasteful. What I think we should do to improve these things is use SLint rules, and have the test server run those too (in some future release, it's not important to do this right now - most important is to start running tests regularly). Daniel Marcus Denker <marcus(a)ira.uka.de> wrote: > There's actually a test in the Tests-package for that: I've done > a Abstract testing-class called "ClassTestCase". > If you inherit from this one instead of TestCase (and name the test > "<name of the class>Test", you get an error if the class-comment is empty. > > (and you get 3 more tests: testNew, testUnCategorizedMethods, testRecompileAll) > > There are not yet tests for every class in the system, but as soon as the > testserver is running, I'l add more. > > Marcus > > -- > Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Re: [Squeakfoundation]Harvester status for Marcus Denker
by Daniel Vainsencher 10 Jun '03

10 Jun '03

goran.krampe(a)bluefish.se wrote: > I am not sure we have such different standards - but I still agree that > we need a policy. [snip] > What did you mean with "read all code" - you mean instead of simply > "trusting" someone? I always read all code I review, regardless of > author. Exactly - and we should make that policy, instead of something each harvester might or might not choose to do. > Well, it would be interesting to write down the policy somewhere - at > least the non obvious and the mandatory stuff. I am not saying "Swiki" > because I am a bit tired of simply creating more and more pages on the > Swikis, but if no other smarter way is found then sure, why not. What's wrong with the Swiki? Daniel

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation June 2003