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

Re: [Pharo-project] Debugging with morphic

by Alexandre Bergel

I was just wondering how you guys debug your morphic programming. There is probably something wrong in the way I do. I cannot imagine people have been doing some morphic for so long without having a simple way to debug it. Cheers, Alexandre On 14 Feb 2009, at 18:26, Gary Chambers wrote: > I'm sure I can come up with something... you obvioulsy want some > kind of > debugger if an error occurs. > The taskbar works effectively synchronously with the display and > should > handle self inflicted errors. > Other display errors *should* get managed by the #errorOnDraw thing, > but not > always it would seem. > > Regards, Gary > > ----- Original Message ----- > From: "Alexandre Bergel" <Alexandre.Bergel(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 14, 2009 4:53 PM > Subject: [Pharo-project] Debugging with morphic > > >> Hi All (and especially the Pinesoft crew), >> >> When an error is triggered by a displayOn: method, the bottom bar is >> being filled with debugger windows. It then become hardly debuggable. >> Ideally, the system should not display a window if an error is >> triggered in the displayOn. >> >> Do you have any recommandation/conviention/enhancement to prevent the >> image to hang when an error is signaled in a displayOn. This is >> really >> annoying. >> >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 14, 2009

Re: [Pharo-project] Fwd: A question about hardcoded class names

by Lukas Renggli

The class CUCastingExample in the following Pharo image <http://scg.unibe.ch/Research/DSL/diesel-languageaspects.zip> contains some language experiments along these lines. For example the keyword "this" starts the lookup of in the class the method is defined in. Similar receivers of message sends can be casted to any superclass using #cast:. Lukas On Sat, Feb 14, 2009 at 6:43 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2009/2/14 Keith Hodges <keith_hodges(a)yahoo.co.uk>: >> StÃ©phane Ducasse wrote: >>> Hi guys >>> >>> some days ago with alex we wanted to identify the methods containing a >>> reference to their class (Lint does it too). >>> Now we thought that replacing them with self class is not equivalent >>> since we could imagine >>> >> st/x uses >> >> here class >>> that hardcoding the class name make sure that subclass cannot redefine >>> methods. >>> Now this is a bit against Smalltalk late bindinness and probably most >>> of the time an newbie error. >>> >> I doubt it. >> >> isAbstract >> >> self class = here class. >> > If i understood, st/x > > here class > > is equivalent to squeak > > thisContext method methodClass > > right? > >> Keith >>> But I wanted to know what was your experiment to that regards. >>> >>> Stef >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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] [ANN] 10234 SmallLint cleaning

by Igor Stasenko

2009/2/14 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > addressed or tagged as addressed > > Issue 523: [SmallLint] Undeclared variables > This check is similar to the "References an undeclared variable" > check, but it looks for variables that > are not defined in the class or in the undeclared dictionary. You > probably had to work hard to get > your code in this state. > > PasteUpMorph>>#makeNewDrawing:at: > Project>>#storeSegmentNoFile not sure about the rest methods, but these two showing that people worked hard to get code in this state. or maybe its my brain is too small to fit such amount of code in attempt to understand it. > CollectionRootTest>>#nonEmpty > ScriptLoader>>#update10196 > ScriptLoader>>#update10074 > > Issue 525: useless boolean checks on Morphic extras > MorphicExtras Check for a =, ==, ~=, or ~~ message being sent to true/ > false or with true/false as the argument. > SqueakPage>>#write > URLMorph>>#mouseUp: > ClockMorph>>#addCustomMenuItems:hand: > ClockMorph>>#step > ClockMorph>>#toggleShowingSeconds > ClockMorph>>#toggleShowing24hr > MorphObjectOut>>#doesNotUnderstand: > SketchEditorMorph>>#verifyState: > SketchEditorMorph>>#deliverPainting:evt: > FlapTab>>#inboard > FlapTab>>#flapShowing > FlapTab>>#tabSelected > ReferenceMorph>>#isHighlighted > SimpleSliderMorph>>#truncate > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 14, 2009

Re: [Pharo-project] Sends unknown message to global

by Lukas Renggli

> I do not know > It would be good if lukas could improve the quality of the report of > SmallLint. If you select the rule and click on browse, it lists all the occurences and also highlights the offending code. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 14, 2009

Re: [Pharo-project] Sends unknown message to global

by StÃ©phane Ducasse

I do not know It would be good if lukas could improve the quality of the report of SmallLint. Sometimes I have to think to spot the problem stef On Feb 14, 2009, at 5:31 PM, Gary Chambers wrote: > What is the unknown message for > UITheme..#newColorPresenterIn:for:getColor:setColor:help: > ? Looks ok here. > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 14, 2009 1:23 PM > Subject: [Pharo-project] Sends unknown message to global > > >> same here: would be good to define bugfix entries for each of them. >> >> Stef >> >> TTSampleStringMorph>>#initializeToStandAlone >> Character>>#storeBinaryOn: >> EFontBDFFontReaderForRanges >>>> #override:with:ranges:transcodingTable:additionalRange: >> InstallerMonticello>>#unloadCleanUp >> ServerDirectory>>#createDirectory: >> ServerDirectory>>#deleteDirectory: >> CompiledMethod>>#searchImageForHomeMethod >> SMSimpleInstaller>>#fileIntoChangeSetNamed:fromStream: >> UITheme>>#newColorPresenterIn:for:getColor:setColor:help: >> SystemDictionary>>#unbindExternalPrimitives >> UIMonticello>>#installFileNamed:fromURL: >> TabSorterMorph>>#acceptSort >> MCPackageLoader>>#useChangeSetNamed:during: >> InstallerFile>>#basicView >> InstallerFile>>#basicBrowse >> URI>>#mimeType >> StrikeFont>>#readEFontBDFFromFile:name:rangeFrom:to: >> StrikeFont>>#readEFontBDFForJapaneseFromFile:name:overrideWith: >> StrikeFont>>#readEFontBDFForKoreanFromFile:name:overrideWith: >> StrikeFont>>#readEFontBDFFromFile:name:ranges: >> Morph>>#showActions >> OBTreeFanTests>>#makeTreeFanStructure >> MczInstaller>>#useNewChangeSetDuring: >> TranslatedReceiverFinder class>>#makeJapaneseTranslationFile >> SARInstaller class>>#newChanges: >> SARInstaller class>>#currentChangeSet >> Transcripter class>>#startTranscriptProcess >> RxParser class>>#doHandlingMessageNotUnderstood: >> NaturalLanguageTranslator class>>#default >> Utilities class>>#authorNamePerSe >> >> >> _______________________________________________ >> 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

[Pharo-project] [ANN] 10234 SmallLint cleaning

by StÃ©phane Ducasse

addressed or tagged as addressed Issue 523: [SmallLint] Undeclared variables This check is similar to the "References an undeclared variable" check, but it looks for variables that are not defined in the class or in the undeclared dictionary. You probably had to work hard to get your code in this state. PasteUpMorph>>#makeNewDrawing:at: Project>>#storeSegmentNoFile CollectionRootTest>>#nonEmpty ScriptLoader>>#update10196 ScriptLoader>>#update10074 Issue 525: useless boolean checks on Morphic extras MorphicExtras Check for a =, ==, ~=, or ~~ message being sent to true/ false or with true/false as the argument. SqueakPage>>#write URLMorph>>#mouseUp: ClockMorph>>#addCustomMenuItems:hand: ClockMorph>>#step ClockMorph>>#toggleShowingSeconds ClockMorph>>#toggleShowing24hr MorphObjectOut>>#doesNotUnderstand: SketchEditorMorph>>#verifyState: SketchEditorMorph>>#deliverPainting:evt: FlapTab>>#inboard FlapTab>>#flapShowing FlapTab>>#tabSelected ReferenceMorph>>#isHighlighted SimpleSliderMorph>>#truncate

Feb. 14, 2009

Re: [Pharo-project] Fwd: A question about hardcoded class names

by Igor Stasenko

2009/2/14 Keith Hodges <keith_hodges(a)yahoo.co.uk>: > StÃ©phane Ducasse wrote: >> Hi guys >> >> some days ago with alex we wanted to identify the methods containing a >> reference to their class (Lint does it too). >> Now we thought that replacing them with self class is not equivalent >> since we could imagine >> > st/x uses > > here class >> that hardcoding the class name make sure that subclass cannot redefine >> methods. >> Now this is a bit against Smalltalk late bindinness and probably most >> of the time an newbie error. >> > I doubt it. > > isAbstract > > self class = here class. > If i understood, st/x here class is equivalent to squeak thisContext method methodClass right? > Keith >> But I wanted to know what was your experiment to that regards. >> >> Stef >> >> >> >> >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 14, 2009

Re: [Pharo-project] Fwd: A question about hardcoded class names

by StÃ©phane Ducasse

Yes this is what I thought so we will have to go over them one by one and tag them Stef On Feb 14, 2009, at 5:19 PM, Lukas Renggli wrote: >> Now we thought that replacing them with self class is not equivalent >> since we could imagine >> that hardcoding the class name make sure that subclass cannot >> redefine >> methods. > > No, in many cases this is not equivalent. In my opinion the rule could > avoid many false positives if it would only trigger if there are no > subclasses. Of course we would then also get more false negatives. > >> But I wanted to know what was your experiment to that regards. > > Two typical false positives I encountered: > > 1. Factory or builder methods on the class side usually refer to a > wide variety of classes. Sometimes such methods also refer to the > receiving class, however since you want to make the method also work > when called on subclasses you have to hardcode the receiving class. > > 2. When collecting pragmas you usually write something along: > > PRErrorView>>renderOptionsOn: html > (Pragma allNamed: #option: from: self class to: PRErrorView) > do: [ :each | ... ] > > Given that PRErrorView has the subclasses PRForbiddenView and > PRNotFoundView, there are cases where "self class" is not equal to > PRErrorView. And the point of the above code is to find all pragmas, > up to PRErrorView. > > Cheers, > 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

Re: [Pharo-project] Fwd: A question about hardcoded class names

by Keith Hodges

StÃ©phane Ducasse wrote: > Hi guys > > some days ago with alex we wanted to identify the methods containing a > reference to their class (Lint does it too). > Now we thought that replacing them with self class is not equivalent > since we could imagine > st/x uses here class > that hardcoding the class name make sure that subclass cannot redefine > methods. > Now this is a bit against Smalltalk late bindinness and probably most > of the time an newbie error. > I doubt it. isAbstract self class = here class. Keith > But I wanted to know what was your experiment to that regards. > > Stef > > > > > > _______________________________________________ > 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] unnecessary =, == :)

by Igor Stasenko

Sometimes i using ivars , which going to hold boolean value only , but i leave it to be initialized later so, a value of variable could be nil, true, false. Accessor, however alway returns a boolean, but depending of default value it could look like: ^ myvar == true or ^ myvar == false 2009/2/14 Gary Chambers <gazzaguru2(a)btinternet.com>: > SystemWindow>>#mouseDown: (actually needed, on first call that property will > almost certainly be nil, set later in the method). > > Regards, Gary > > > ----- Original Message ----- > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 14, 2009 5:12 PM > Subject: Re: [Pharo-project] unnecessary =, == :) > > > PluggableTextMorph>>#accept (sadly required defence against text setters > that don't return a boolean) > SystemWindow>>#mouseDown: (removed offending line, now obsolete, apparently) > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 14, 2009 3:23 PM > Subject: [Pharo-project] unnecessary =, == :) > > >> Check for a =, ==, ~=, or ~~ message being sent to true/false or with >> true/false as the argument. Many times these can be eliminated since >> their receivers are already booleans. For example, "anObject isFoo == >> false" could be replaced with "anObject isFoo not" if isFoo always >> returns a boolean. Sometimes variables might refer to true, false, and >> something else, but this is considered bad style since the variable >> has multiple types. >> >> Project>>#setChangeSet: >> Project>>#isolationSet >> Project>>#compileAll:from: >> Project>>#writeFileNamed:fromDirectory:toServer: >> Project>>#isolationHead >> PNGReadWriter>>#debugging >> ClockMorph>>#addCustomMenuItems:hand: >> ClockMorph>>#step >> ClockMorph>>#toggleShowingSeconds >> ClockMorph>>#toggleShowing24hr >> WorldState>>#interCyclePause: >> Integer>>#quo: >> Integer>>#digitSubtract: >> SimpleServiceEntry>>#useLineAfter >> MorphicUIManager>>#interactiveParserFor: >> OBPluggableListMorph>>#mouseUp: >> PianoRollScoreMorph>>#addCustomMenuItems:hand: >> SystemDictionary>>#abandonSources >> SystemDictionary>>#internalizeSources >> SystemDictionary>>#internalizeChangeLog >> SetTest>>#testRemoveIfAbsent >> SimpleButtonDelayedMenuMorph>>#mouseUp: >> Installer>>#validate >> Installer>>#logErrorDuring: >> SketchEditorMorph>>#verifyState: >> SketchEditorMorph>>#deliverPainting:evt: >> SketchMorph>>#useInterpolation: >> Slider>>#descending >> JoystickMorph>>#autoCenterString >> JoystickMorph>>#button1 >> JoystickMorph>>#button2 >> SARInstaller>>#errorNoSuchMember: >> MessageSet>>#growable >> HandMorph>>#handleEvent: >> HandMorph>>#fullDrawOn: >> ImageSegment>>#declareAndPossiblyRename: >> PluggableListMorphPlus>>#wantsDroppedMorph:event: >> SUnitTest>>#testRanOnlyOnce >> BitmapFillStyle>>#isTiled >> InstallerMonticello>>#mcDetectFileBlock >> FTPClient>>#login >> Object>>#mustBeBooleanIn: >> Object>>#'~=' >> Decompiler>>#pushConstant: >> TextMorphForEditView>>#acceptOnCR >> HostSystemMenusMenuItem>>#shift >> FlapTab>>#inboard >> FlapTab>>#flapShowing >> FlapTab>>#tabSelected >> PluggableTreeMorph>>#wantsDroppedNode:on: >> DisplayScreen>>#deferUpdates: >> OBSystemBrowser>>#defaultBackgroundColor >> SmalltalkImage>>#setPlatformPreferences >> SmalltalkImage>>#snapshot:andQuit:embedded: >> URLMorph>>#mouseUp: >> MultiNewParagraph>>#multiComposeLinesFrom:to:delta:into:priorLines:atY: >> Collection>>#reject: >> TextDiffBuilder>>#hasMultipleMatches >> TrueTest>>#testNot >> TrueTest>>#testInMemory >> TrueTest>>#testAND >> MCFileBasedRepository>>#possiblyNewerVersionsOfAnyOf: >> Process>>#terminate >> ProtoObjectTest>>#testIsNil >> SqueakPage>>#write >> ColorPickerMorph>>#putUpFor:near: >> FalseTest>>#testAnd >> FalseTest>>#testOR >> FalseTest>>#testNot >> FalseTest>>#testAND >> UpdatingStringMorph>>#growable >> UpdatingStringMorph>>#autoAcceptOnFocusLoss >> LanguageEditor>>#selectedTranslationsAt:put: >> Socket>>#setOption:value: >> MultiCompositionScanner>>#setFont >> PositionableStream>>#unCommand >> HTTPSocket>>#logToTranscript >> Number>>#odd >> OBHierarchyBrowser>>#defaultBackgroundColor >> MorphExtension>>#isDefault >> MorphExtension>>#sortedPropertyNames >> MorphExtension>>#printOn: >> MorphExtension>>#hasProperty: >> ObjectOut>>#doesNotUnderstand: >> PluggableTextMorph>>#hasEditingConflicts >> PluggableTextMorph>>#accept >> SimpleSliderMorph>>#truncate >> OBProtocolBrowser>>#defaultBackgroundColor >> SystemWindow>>#mustNotClose >> SystemWindow>>#mouseDown: >> RBReadBeforeWrittenTester>>#read >> RBReadBeforeWrittenTester>>#processBlock: >> RBReadBeforeWrittenTester>>#processStatementNode: >> RBReadBeforeWrittenTester>>#processIfTrueIfFalse: >> GradientFillStyle>>#isRadialFill >> RefactoryTyper>>#typeFor: >> CompiledMethodTest>>#testValueWithReceiverArguments >> OBLazyListMorph>>#handleMouseMove: >> BlockContextTest>>#testSupplyAnswerThroughNestedBlocks >> BlockContextTest>>#testSupplyAnswerUsingTraditionalMatchOfQuestion >> BlockContextTest>>#testSupplySameAnswerToAllQuestions >> BlockContextTest>>#testSupplyAnswerUsingOnlySubstringOfQuestion >> BlockContextTest>>#testSupplySpecificAnswerToQuestion >> BlockContextTest>>#testSupplyAnswerUsingRegexMatchOfQuestion >> ImageMorph>>#isOpaque: >> ProjectSwikiServer>>#acceptsUploads >> PolygonMorph>>#rotateTestFlip: >> PolygonMorph>>#beStraightSegments >> PolygonMorph>>#beSmoothCurve >> BitBlt>>#drawFrom:to:withFirstPoint: >> FileList>>#getSelectedDirectory >> FileList>>#getSelectedFile >> RBParser>>#patchLiteralMessage >> OBMultipleSelectionColumn>>#listSelectionAt:put: >> ServerDirectory>>#upLoadProject:members:retry: >> MorphObjectOut>>#doesNotUnderstand: >> HaloMorph>>#addHandles >> ThumbnailImageMorph>>#togglePopupFeature >> ThumbnailImageMorph>>#handlesMouseDown: >> ThumbnailImageMorph>>#popupFeatureString >> ContextPart>>#jump:if: >> MCWorkingCopy>>#merge: >> FileDoesNotExistException>>#readOnly >> RBLiteralNodeTest>>#testValue >> Prefer... >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Feb. 14, 2009