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

Re: [Pharo-project] [ANN] OCompletion improves the accuracy of eCompletion

by Damien Cassou

Hi Romain, On Tue, May 12, 2009 at 10:07 AM, Romain Robbes <romain.robbes(a)lu.unisi.ch> wrote: > To install it on Squeak or Pharo, simply execute the following line in > your image: > > Installer squeaksource project: 'OCompletion'; install: 'OCLoader' thank you very much, this is great news. Could you please create a package on Universes? How-to: http://wiki.squeak.org/squeak/5899 Does it work on OB (see ECompletionOmniBrowser)? and what about the workspace ? Does it work with traits too (see ECompletionTraits)? Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 13, 2009

Re: [Pharo-project] fastDragWindowsForMorphic locks up UI

by Henrik Johansen

Object setHaltOnce Mariano Martinez Peck skrev: > > > On Wed, May 13, 2009 at 12:17 PM, Henrik Johansen > <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> > wrote: > > I can only guess, but... maybe put a self haltOnce in the code where > it's about to happen (in this case top of window drag routine), then > step until image locks? > Voila, you know the offending part :D > > (haltOnce instead of halt might not be necessary in this specific > case, > but it's truely a gift from god in debugging UI process in my > experience ) > > > Wow I wasn't aware of self haltOnce. The comment in the method says > "Halt unless we have already done it once." But, already when ? since > when ? when is it restarted ? never ? > > > > Cheers, > Henry > > Rob Rothwell skrev: > > How did you even go about debugging this when it went all > non-responsive?! > > > > Rob > > > > On Wed, May 13, 2009 at 8:06 AM, Gary Chambers > > <gazzaguru2(a)btinternet.com <mailto:gazzaguru2@btinternet.com> > <mailto:gazzaguru2@btinternet.com > <mailto:gazzaguru2@btinternet.com>>> wrote: > > > > Have a go with the proposed fix... > > http://code.google.com/p/pharo/issues/detail?id=809 > > > > Regards, Gary > > > > ----- Original Message ----- > > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr > <mailto:stephane.ducasse@inria.fr> > > <mailto:stephane.ducasse@inria.fr > <mailto:stephane.ducasse@inria.fr>>> > > To: <Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > > <mailto:Pharo-project@lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr>>> > > Sent: Tuesday, May 12, 2009 6:12 PM > > Subject: Re: [Pharo-project] fastDragWindowsForMorphic locks > up UI > > > > > > > Tx! > > > > > > On May 12, 2009, at 4:51 PM, Steve Wirts wrote: > > > > > >> I've experienced this also > > >> > > >> 2009/5/12 Rob Rothwell <r.j.rothwell(a)gmail.com > <mailto:r.j.rothwell@gmail.com> > > <mailto:r.j.rothwell@gmail.com <mailto:r.j.rothwell@gmail.com>>> > > >> Can someone confirm that fastDragWindowForMorphic locks > up the > > UI in > > >> 10303 as soon as you try to move a window? > > >> > > >> I'll log an issue if it's not just me... > > >> > > >> Rob > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > > <mailto:Pharo-project@lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto:Pharo-project@lists.gforge.inria.fr> > > <mailto:Pharo-project@lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto:Pharo-project@lists.gforge.inria.fr> > > <mailto:Pharo-project@lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto:Pharo-project@lists.gforge.inria.fr> > > <mailto:Pharo-project@lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto:Pharo-project@lists.gforge.inria.fr> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > *Robert Nyiredy* > tittel tittlesen > > > Evjebakken 19 > N-1346 Gjettum > NORWAY > > Direct: +47 40 64 32 32 > Phone: +47 67 52 09 50 > Fax: +47 67 52 09 51 > > www.lilleaker.com <http://www.lilleaker.com> > <http://www.lilleaker.com/> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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 -- *Robert Nyiredy* tittel tittlesen Evjebakken 19 N-1346 Gjettum NORWAY Direct: +47 40 64 32 32 Phone: +47 67 52 09 50 Fax: +47 67 52 09 51 www.lilleaker.com <http://www.lilleaker.com/>

May 13, 2009

Re: [Pharo-project] fastDragWindowsForMorphic locks up UI

by Mariano Martinez Peck

On Wed, May 13, 2009 at 12:17 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > I can only guess, but... maybe put a self haltOnce in the code where > it's about to happen (in this case top of window drag routine), then > step until image locks? > Voila, you know the offending part :D > > (haltOnce instead of halt might not be necessary in this specific case, > but it's truely a gift from god in debugging UI process in my experience ) > Wow I wasn't aware of self haltOnce. The comment in the method says "Halt unless we have already done it once." But, already when ? since when ? when is it restarted ? never ? > > Cheers, > Henry > > Rob Rothwell skrev: > > How did you even go about debugging this when it went all > non-responsive?! > > > > Rob > > > > On Wed, May 13, 2009 at 8:06 AM, Gary Chambers > > <gazzaguru2(a)btinternet.com <mailto:gazzaguru2@btinternet.com>> wrote: > > > > Have a go with the proposed fix... > > http://code.google.com/p/pharo/issues/detail?id=809 > > > > Regards, Gary > > > > ----- Original Message ----- > > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr > > <mailto:stephane.ducasse@inria.fr>> > > To: <Pharo-project(a)lists.gforge.inria.fr > > <mailto:Pharo-project@lists.gforge.inria.fr>> > > Sent: Tuesday, May 12, 2009 6:12 PM > > Subject: Re: [Pharo-project] fastDragWindowsForMorphic locks up UI > > > > > > > Tx! > > > > > > On May 12, 2009, at 4:51 PM, Steve Wirts wrote: > > > > > >> I've experienced this also > > >> > > >> 2009/5/12 Rob Rothwell <r.j.rothwell(a)gmail.com > > <mailto:r.j.rothwell@gmail.com>> > > >> Can someone confirm that fastDragWindowForMorphic locks up the > > UI in > > >> 10303 as soon as you try to move a window? > > >> > > >> I'll log an issue if it's not just me... > > >> > > >> Rob > > >> > > >> _______________________________________________ > > >> Pharo-project mailing list > > >> Pharo-project(a)lists.gforge.inria.fr > > <mailto:Pharo-project@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 > > <mailto:Pharo-project@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 > > <mailto:Pharo-project@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 > > <mailto:Pharo-project@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 > > -- > *Robert Nyiredy* > tittel tittlesen > > > Evjebakken 19 > N-1346 Gjettum > NORWAY > > Direct: +47 40 64 32 32 > Phone: +47 67 52 09 50 > Fax: +47 67 52 09 51 > > www.lilleaker.com <http://www.lilleaker.com/> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 13, 2009

Re: [Pharo-project] Standardisation of Interfaces within Pharo/Squeak ...

by Damien Cassou

2009/5/11 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> And i can't close that window "World->System->About" at 1024x768 >> resolution .... hmmm .... > > Yes. Me too. I have to do ctrl + w. or just ENTER or SPACE -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 13, 2009

Re: [Pharo-project] Questions about the debugger

by Damien Cassou

2009/5/11 Hernan Wilkinson <hernan.wilkinson(a)gmail.com>: > Â Also, what does the class OTToolset do? The DevToolSet delegates to it the > messages when installed, but the pharo image does not have it install. OTToolSet is an OB-based debugger. It was not installed in the last Pharo because of a problem but will be in the future. Sorry, I can't help you for the other questions -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 13, 2009

Re: [Pharo-project] fastDragWindowsForMorphic locks up UI

by Henrik Johansen

I can only guess, but... maybe put a self haltOnce in the code where it's about to happen (in this case top of window drag routine), then step until image locks? Voila, you know the offending part :D (haltOnce instead of halt might not be necessary in this specific case, but it's truely a gift from god in debugging UI process in my experience ) Cheers, Henry Rob Rothwell skrev: > How did you even go about debugging this when it went all non-responsive?! > > Rob > > On Wed, May 13, 2009 at 8:06 AM, Gary Chambers > <gazzaguru2(a)btinternet.com <mailto:gazzaguru2@btinternet.com>> wrote: > > Have a go with the proposed fix... > http://code.google.com/p/pharo/issues/detail?id=809 > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr > <mailto:stephane.ducasse@inria.fr>> > To: <Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr>> > Sent: Tuesday, May 12, 2009 6:12 PM > Subject: Re: [Pharo-project] fastDragWindowsForMorphic locks up UI > > > > Tx! > > > > On May 12, 2009, at 4:51 PM, Steve Wirts wrote: > > > >> I've experienced this also > >> > >> 2009/5/12 Rob Rothwell <r.j.rothwell(a)gmail.com > <mailto:r.j.rothwell@gmail.com>> > >> Can someone confirm that fastDragWindowForMorphic locks up the > UI in > >> 10303 as soon as you try to move a window? > >> > >> I'll log an issue if it's not just me... > >> > >> Rob > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto:Pharo-project@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 > <mailto:Pharo-project@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 > <mailto:Pharo-project@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 -- *Robert Nyiredy* tittel tittlesen Evjebakken 19 N-1346 Gjettum NORWAY Direct: +47 40 64 32 32 Phone: +47 67 52 09 50 Fax: +47 67 52 09 51 www.lilleaker.com <http://www.lilleaker.com/>

May 13, 2009

Re: [Pharo-project] fastDragWindowsForMorphic locks up UI

by Rob Rothwell

How did you even go about debugging this when it went all non-responsive?! Rob On Wed, May 13, 2009 at 8:06 AM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > Have a go with the proposed fix... > http://code.google.com/p/pharo/issues/detail?id=809 > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, May 12, 2009 6:12 PM > Subject: Re: [Pharo-project] fastDragWindowsForMorphic locks up UI > > > > Tx! > > > > On May 12, 2009, at 4:51 PM, Steve Wirts wrote: > > > >> I've experienced this also > >> > >> 2009/5/12 Rob Rothwell <r.j.rothwell(a)gmail.com> > >> Can someone confirm that fastDragWindowForMorphic locks up the UI in > >> 10303 as soon as you try to move a window? > >> > >> I'll log an issue if it's not just me... > >> > >> Rob > >> > >> _______________________________________________ > >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 13, 2009

[Pharo-project] StringTest>>testUnescapePercentsWithTextEncoding is broken

by Oscar Nierstrasz

While checking if tests for the Squeak by Example book still work under Pharo, I discovered that StringTest>>testUnescapePercentsWithTextEncoding is broken. Trying to track this down, I saw that Michael Rueger changed the last line of ShiftJISTextConverter>>nextFromStream: from ^ self toUnicode: result to: ^ self byteToUnicode: result which seems to break the test. I can't say that I understand what is going on here, but shouldn't we roll back this change? Else rewrite the test ... - on

May 13, 2009

Re: [Pharo-project] fastDragWindowsForMorphic locks up UI

by Gary Chambers

Have a go with the proposed fix... http://code.google.com/p/pharo/issues/detail?id=809 Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, May 12, 2009 6:12 PM Subject: Re: [Pharo-project] fastDragWindowsForMorphic locks up UI > Tx! > > On May 12, 2009, at 4:51 PM, Steve Wirts wrote: > >> I've experienced this also >> >> 2009/5/12 Rob Rothwell <r.j.rothwell(a)gmail.com> >> Can someone confirm that fastDragWindowForMorphic locks up the UI in >> 10303 as soon as you try to move a window? >> >> I'll log an issue if it's not just me... >> >> Rob >> >> _______________________________________________ >> 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

May 13, 2009

[Pharo-project] Preference to settings refactoring: #annotationPanes case

by Alain Plantec

http://code.google.com/p/pharo/issues/detail?id=810 Alain ---------------------------------------------- annotationPanes : "if true, a thin horizontal pane is used in browsers" We have 3 implementations : Old browser and MC implementation in Pharo-core and OB one in Pharo-dev. Pharo-core Old browser implementation: It first relies on the #annotation related methods. (changed: #annotation, Browser>>annotation, ChangeList>>annotation, CodeHolder>>annotation). CodeHolder>>wantsAnnotationPane is the only user of the annotationPanes preference. CodeHolder>>addOptionalAnnotationsTo: window at: fractions plus: verticalOffset is the only user of wantsAnnotationPane. It has two senders: Browser>>openAsMorphMessageEditing: and CodeHolder>>addLowerPanesTo: window at: nominalFractions with: editString. method source with #annotation gives more interesting results such as: CodeHolder>>refreshAnnotation "If the receiver has an annotation pane that does not bear unaccepted edits, refresh it" (aPane := self dependents detect: [:m | (m inheritsFromAnyIn: #('PluggableTextView' 'PluggableTextMorph' )) and: [m getTextSelector == #annotation]] ifNone: []) ifNotNil: [:aPane | aPane hasUnacceptedEdits ifFalse: [aPane update: #annotation]] other "cool" pieces of code: PluggableTextMorph>>accept .... ok := self acceptTextInModel. ok == true ifTrue: [self setText: self getText. self hasUnacceptedEdits: false. (model dependents detect: [:dep | (dep isKindOf: PluggableTextMorph) and: [dep getTextSelector == #annotation]] ifNone: []) ifNotNilDo: [:aPane | model changed: #annotation]]. ... PluggableTextMorph>>cancel self setText: self getText. self setSelection: self getSelection. getTextSelector == #annotation ifFalse: [(aPane := model dependents detect: [:dep | (dep isKindOf: PluggableTextMorph) and: [dep getTextSelector == #annotation]] ifNone: []) ifNotNil: [:aPane | model changed: #annotation]] The displayed annotation is set only when a browser or message list is opened. Then, displayed information concerns only the method on which the browser is opened or only the method FROM which sender/implementor message list is opened. The annotation is never updated even a new method is selected. Pharo-core MC implementation: MCSnapshotBrowser, MCPatchBrowser, MCMergeBrowser: display (well) annotation when a method is selected. The method author initials, the date and the time of change and the category are displayed. Note that the height of the pane is sometime too thin, depending on the height of the font. When a vertical scrollbar is shown, the pane is always too thin. The implementation relies on #annotations and #annotations: methods. #annotations implementations MCCodeTool>>annotations (subclassresponsibility) ok MCConflict>>annotations ok MCPatchBrowser>>annotations ok MCSnapshotBrowser>>annotations ok MCDefinition>>annotations and MCPatchOperation>>annotations make use of Preferences class>>defaultAnnotationRequests. Preferences class>>defaultAnnotationRequests ^ Parameters at: #MethodAnnotations ifAbsent: [self setDefaultAnnotationInfo "Preferences annotationInfo"] #annotations: implementations MCDefinition>>annotations: and MCPatchOperation>>annotations: are the same MCDefinition>>annotations: requests "Answer a string for an annotation pane, trying to fulfill the annotation requests. These might include anything that Preferences defaultAnnotationRequests might return. Which includes anything in Preferences annotationInfo To edit these, use:" "Preferences editAnnotations" ^ String streamContents: [:s | self printAnnotations: requests on: s] MCSnapshotBrowser>>annotations: stuff self changed: #annotations The displayed data is given by Preferences annotationInfo which is supposed to be adaptable with the help of a specific tool opened with Preferences editAnnotations. The annotation is well updated each time a new method is selected. I didn't succeed in making Preferences editAnnotations work. Found the implementation clean except the Preferences annotationInfo/editAnnotations part. Pharo-dev OB implementation Relies on a OBAnnotationPanel for the view and on the OBSelectionChanged announcement for the annotation update. It works well. The implementation is simple and clean (The only bad point I've found is that, as for the Pharo-core MC implementation, the height of the panel is fixed whereas it should be dynamically computed from current code font height) action: Would remove the annotationPanes preference from pharo-core and make an OBBrowser specific setting. Why: because old browser implementation is really confusing and dirty and because it do not give useful feedback to the user. Would also remove MC implementation because it is not used by default and I think that MC user do not care about it. If people want to keep it, then it should not relies on a specific setting. Anyway, the Preferences annotationInfo/editAnnotations part should be removed. Consequence: Clean/remove all annotation related code from Pharo-core. Ask OB maintainers to add an OB specific settings as follow: OBCodeBrowser class>>showAnnotationPanel <setting> ^ ShowAnnotationPanel ifNil: [ShowAnnotationPanel := (SettingManager newSetting: 'Show annotation panel') default: true; parent: #obBrowsing; description: 'If true, a thin horizontal panel is used in browsers. The annotation panel is used to display useful informations about the selected method'] I will propose a .cs for the cleaning of Pharo-core when I will know what to do with MC implementation (keep, remove, ok to keep with cleaning?). Then I will propose a .cs to OB maintainers for Pharo-dev. Alain -------------------------------------

May 13, 2009