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

Re: [Pharo-project] about getting more SmallLint rules

by StÃ©phane Ducasse

lukas would it be possible to get the name of the selector which is sent but not implemented in addition to the methods that contain it. BTW the messages sent but not implemented list is so large that I get ... at the end of the stream printed in the window :) Stef On Feb 14, 2009, at 1:59 PM, Lukas Renggli wrote: >> Do you do it right now? how? > > http://lukas-renggli.ch/blog/ignoring-lint-rules > > It is a bit ugly and clutters the code. However this also has the > advantage that it pushes people to fix or rewrite their code. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 14, 2009

[Pharo-project] undeclared variables

by StÃ©phane Ducasse

Hi all It would be good to fix such problems in their respective packages. Stef Checks for references to a variable in the Undeclared dictionary. If you remove a variable from a class that is accessed by a method, you will create an undeclared variable reference for those methods that accessed the variable. OBEnhancementColumn>>#selection: Project>>#finalEnterActions OBClosableDefinitionPanel>>#commands OBTextMorphEditorWithShout>>#correctFrom:to:with: OBCollaboratorsSearchNode>>#classes MCPackageManager>>#modifiedTimeStamp UITheme>>#sounds: UITheme>>#sounds InstallerCruft>>#user InstallerCruft>>#createRBforBug: InstallerCruft>>#user: OBEnrichedDefinitionPanel>>#selectReferencingCodeNodes: OBEnrichedDefinitionPanel>>#accept:notifying: OBMethodInvocationSearchNode>>#classes PasteUpMorph>>#scriptorForTextualScript:ofPlayer: Installer>>#installMCcs:from: Installer>>#printOn: OBEnrichedMethodInvocationNode>>#source OBEnrichedMethodInvocationNode>>#modelMethod OBEnrichedMethodInvocationNode>>#invokingClasses OBTreeColumnTests>>#test09JumpToE2 OBTreeColumnTests>>#test12JumpToD3 OBTreeColumnTests>>#test10JumpToD1 OBTreeColumnTests>>#test01AllInOneColumn OBTreeColumnTests>>#test17JumpToG1 OBTreeColumnTests>>#test06JumpToC2 OBTreeColumnTests>>#test19JumpToA1 OBTreeColumnTests>>#test02AllInOneColumn OBTreeColumnTests>>#test04JumpToB2 OBTreeColumnTests>>#test14JumpToF1 OBTreeColumnTests>>#test08JumpToE1 OBTreeColumnTests>>#test07JumpToC1 OBTreeColumnTests>>#test11JumpToD2 OBTreeColumnTests>>#test13JumpToD4 OBTreeColumnTests>>#test03NodeWithBothTreeChildrenAndDefaultChildren OBTreeColumnTests>>#test05JumpToB1 OBTreeColumnTests>>#test18JumpToG2 OBTreeColumnTests>>#columnPanelABCDEFGH OBTreeColumnTests>>#test16JumpToH1 OBTreeColumnTests>>#test15JumpToF2 OBEnrichedMethodNode>>#source OBEnrichedMethodNode>>#updateModelMethod OBEnrichedClassNode>>#formatter DictionaryTest>>#flattenOnStream OBEnhPackageNodeTest>>#testPackage OBEnhPackageNodeTest>>#testTemplate OBEnhPackageNodeTest>>#setUp OBPosition>>#asTreePosition Refactoring class>>#initializeRefactoringOptions OBEnrichedMessageNode class>>#on:inMethod:inClass:

Feb. 14, 2009

Re: [Pharo-project] about getting more SmallLint rules

by Adrian Lienhard

On Feb 14, 2009, at 13:54 , StÃ©phane Ducasse wrote: > TX!!!! > I think that we should be more aggressive with the tools we have. > I'm currently going over the 25000 issues raised by SmallLint and > entering issues in the bugtracker. wow, great! > I think that we will need to add annotations so that smallLint does > not get warning us > when we know that this is not a problem yes, this is very important. We do that with pragmas (see Lukas' mail). Lint rules are part of the conventional tests and the rule is that these must be green. There are cases where Lint complains but you know it is ok. If we couldn't annotate these methods as ok, the whole thing would not work. In the long term, I think it would be really cool if we manage to get the Pharo core Lint-clean! Adrian > > > Do you do it right now? how? > > > On Feb 14, 2009, at 1:30 PM, Lukas Renggli wrote: > >> I've added such a rule in the latest Refactoring-Core. >> >> Cheers, >> Lukas >> >> On Sat, Feb 14, 2009 at 9:06 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> lukas >>> >>> I would love to have a rule to check the uses of PopUpMenu, >>> FillInTheBlank and friends :) >>> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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

Feb. 14, 2009

Re: [Pharo-project] about getting more SmallLint rules

by Lukas Renggli

> Do you do it right now? how? http://lukas-renggli.ch/blog/ignoring-lint-rules It is a bit ugly and clutters the code. However this also has the advantage that it pushes people to fix or rewrite their code. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 14, 2009

[Pharo-project] Fwd: Clean protocol from kernel extension

by StÃ©phane Ducasse

Begin forwarded message: > From: pharo-project-owner(a)lists.gforge.inria.fr > Date: February 14, 2009 1:34:01 PM CEST > To: stephane.ducasse(a)free.fr > Subject: Clean protocol from kernel extension > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > pharo-project-owner(a)lists.gforge.inria.fr. > > > From: stephane ducasse <stephane.ducasse(a)free.fr> > Date: February 14, 2009 1:33:55 PM CEST > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Subject: Clean protocol from kernel extension > > > I added some information around this protocol (cleanUp and > freeSomeSpace). I like the idea. > should take the time to look deeply at it. > > http://code.google.com/p/pharo/issues/detail?id=204&q=extension&colspec=ID%… > > Stef > > > >

Feb. 14, 2009

Re: [Pharo-project] Distributed versioning ... MonticelloHub?

by StÃ©phane Ducasse

But geert you can help if you want there are simple things to do such as writing tests or trying to fix some issues on the bugtracker. In any case you are welcome and if you do something you will get feedback Stef On Feb 14, 2009, at 10:15 AM, Geert wrote: > > > StÃ©phane Ducasse-2 wrote: >> >> what is cruelly needed is a build integration server. Keith is >> working on >> Bob and he needs help. >> >> Now what is needed is that people go also over the code of keith to >> minimize overrides and other things, else we will have again such >> discussion and people will get frustrated and think we are assholes >> (which >> is not the case) :). In pharo we really want to avoid overrides and >> extensions for the sake of them. So this means that we should >> integrate >> changes. I'm planning to go over kernel extensions today. following >> the >> mail and analysis we did with damien in october (argh) >> >> Stef >> > > I reckon you guys are all doing a great job! I just feel like I am > way too > inexperienced to go over the code you guys write. I am actually > more a > Myers-Briggs (ENFP) visionary type of person and I am looking > forward to be > able to use Pharo Smalltalk as a platform to bring some of my ideas > come to > live :P Maybe that's why I am thinking more in terms of high level > infrastructure and architecture? Anyway, I will be following this > project > closely and I will try to get up to speed ASAP so I will ask less > silly > questions here :) > -- > View this message in context: http://n2.nabble.com/Distributed-versioning-...-MonticelloHub--tp2319149p23… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 14, 2009

Re: [Pharo-project] about getting more SmallLint rules

by StÃ©phane Ducasse

TX!!!! I think that we should be more aggressive with the tools we have. I'm currently going over the 25000 issues raised by SmallLint and entering issues in the bugtracker. I think that we will need to add annotations so that smallLint does not get warning us when we know that this is not a problem Do you do it right now? how? On Feb 14, 2009, at 1:30 PM, Lukas Renggli wrote: > I've added such a rule in the latest Refactoring-Core. > > Cheers, > Lukas > > On Sat, Feb 14, 2009 at 9:06 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> lukas >> >> I would love to have a rule to check the uses of PopUpMenu, >> FillInTheBlank and friends :) >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 14, 2009

Re: [Pharo-project] [squeak-dev] Which HTML and XML parsers to use?

by StÃ©phane Ducasse

Mike should we add an issue to merge all that so that we get less bugs around Yaxo Stef > 2009/2/12, Michael Rueger <m.rueger(a)acm.org>: >> On Thu, Feb 12, 2009 at 7:46 PM, Philippe Marschall >> <philippe.marschall(a)gmail.com> wrote: >> >> >>> XML: >>> http://www.squeaksource.com/XMLSupport.html >>> (need's image patches, they are AFAIK in 3.10) >> >> Hmm, which image patches? I wasn't aware of any need for patches. > > 6750stringAndCharFixes-mir.zip > > String class>>findFirstInString:inSet:startingAt: > > http://bugs.squeak.org/view.php?id=32 > http://bugs.squeak.org/view.php?id=33 > http://bugs.squeak.org/view.php?id=34 > http://bugs.squeak.org/view.php?id=547 > http://bugs.squeak.org/view.php?id=888 > http://bugs.squeak.org/view.php?id=928 > http://bugs.squeak.org/view.php?id=3082 > http://bugs.squeak.org/view.php?id=3083 > http://bugs.squeak.org/view.php?id=6746 > > Cheers > Philippe > >

Feb. 14, 2009

Re: [Pharo-project] about getting more SmallLint rules

by Lukas Renggli

I've added such a rule in the latest Refactoring-Core. Cheers, Lukas On Sat, Feb 14, 2009 at 9:06 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > lukas > > I would love to have a rule to check the uses of PopUpMenu, > FillInTheBlank and friends :) > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 14, 2009

Re: [Pharo-project] SqMondrian

by Tudor Girba

Hi Alex, I guess this mail was supposed to go to moose-dev, too :). > I was wondering why is there a method originFor: in FormsBuilder. In > VW there is none. Why the builder should know about the bounds of the > element to display? I always though the shape was in charge of it. The method's name is wrong. The *For: methods take a Figure as an argument. In our case it should be originOf: because it computes the origin of a shape inside the context of the form. > Something else, both in Squeak and VW we have the following method: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > FormsBuilder>>at: aX and: aY > "Utility method that makes other methods easier to read." > > ^self components > select: [:component | component gridX = aX and: [component gridY = > aY]] > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Is there a reason to not store the components in a matrix ? One reason > that I see, is that one could have a large compound contains only few > elements in it. But still, I find that strange. You could store it in a matrix. Cheers, Doru > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Problem solving should be concentrated on describing the problem in a way that is relevant for the solution."

Feb. 14, 2009