October 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] ToolSet

by Michael Roberts

well, to be fair Pavel didn't ask a question. it was a statement that direct class referencing in this context was wrong. For specific problems or use cases, by all means use some indirection. I'm just not convinced about the generalisation. thanks, Mike

Oct. 29, 2008

Re: [Pharo-project] PopUpMenu

by StÃ©phane Ducasse

I mean that we should not have reference to PopUpMenu from everywhere and especially package that are more core than UI. Stef On Oct 29, 2008, at 5:06 PM, Matthew Fulmer wrote: > On Wed, Oct 29, 2008 at 08:12:31AM +0100, St?phane Ducasse wrote: >> I'm still looking for people to help cleaning the PopUpMenu plague. >> >> the idea would be to change PopUpMenu -> ToolBuilder >> but this is not the solution. >> the PopUpMenu should be converted into a Warning >> and lot of PopUpMenu should be removed. > > What do you mean by "PopUpMenu plague"? I assume you mean > refactoring Parser to send exceptions up the stack rather than > interacting itself, and moving all that interaction code > somewhere else (Where?). > > Is there anything else you mean? Does NewParser solve this > problem, at least partially? > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 29, 2008

Re: [Pharo-project] please do not update.

by StÃ©phane Ducasse

now this solved. Stef On Oct 29, 2008, at 2:20 PM, StÃ©phane Ducasse wrote: > I will have to cancel 10120 and may 10119 because of a huge mess. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 29, 2008

Re: [Pharo-project] ScriptingSystem ? ??

by StÃ©phane Ducasse

good! I will try to remove it. On Oct 29, 2008, at 12:26 PM, Pavel Krivanek wrote: >> From my KI experiences, it can be removed if we will use some more > reasonable location for standard forms dictionary. It is etoys > supporting class. > > On Wed, Oct 29, 2008 at 11:57 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> what is a scriptingSystem in morphic. >> To me it looks like a object knowing some stuff about the >> environment and >> mostly used by etoys. >> >> 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 >

Oct. 29, 2008

Re: [Pharo-project] Re: [Pkg] Installer: Installer-Core-AlexandreBergel.244.mcz

by David RÃ¶thlisberger

>> Are you updating loadSuperOB? Or shall I do it? > > I'm just right now in the process of doing it. ;) There is ScriptLoader-DavidRoethlisberger.594 in PharoInbox providing a working version of #loadSuperOB and also #loadOBAlpha, which load the latest version of the default OB package browser, but without Mondrian, visualizations, etc. David

Oct. 29, 2008

Re: [Pharo-project] ToolSet -> ToolRegistry

by Igor Stasenko

2008/10/29 Matthew Fulmer <tapplek(a)gmail.com>: > On Wed, Oct 29, 2008 at 04:20:55AM +0200, Igor Stasenko wrote: >> I'm implemented a new ToolRegistry class, which can work as >> replacement of ToolSet. >> >> It would require a 'bit' refactoring, to replace all references to >> 'ToolSet' with 'Smalltalk tools'. >> >> What i discovered during implementation, if we migrate to new class, a >> lot of stuff can be cleaned up. >> For instance, >> >> Smalltalk tools inspectorTypes >> >> holds a dictionary of Class name -> inspector class name >> so, one could simply register own inspector by including a line: >> >> Smalltalk tools inspectorTypes at: #MySpecialClass put: #MySpecialInspector >> >> in package/class initialization method, instead of overriding #inspect method. > > Actually, you are supposed to override inspectorClass, but yes, > that does sound more uniform. Does it support inheritance, so > that subclasses of MySpecialClass will use the nice inspector > too? > Yes, it supports inheritance in same way as old model (but it was not extensible). E.g. if you have ClassA and ClassAInspector, then ClassB which is subclass of ClassA will use ClassAInspector. This is not the only uniformity which provides new model. There are a number of classes, like UIManager which using classvar to hold their 'default' sole instance. Now with ToolsRegistry we can use a single storage for all such singletons. So, instead of: UIManager default or SystemBrowser default we can refactor to: Smalltalk tools uiManager and Smalltalk tools browser It is also more convenient from customization perspective: all preferences are gathered into single place, so you don't need to search throughout image to dig out where is some preference stored and how to change it, in case of need. Moreover, different packages can register own tools, or replace existing ones. > I don't see anything wrong with inspectorClass, except for the > fact that ObjectExplorer and Inspector don't share the same > inspection model, which means you see different things when > exploring vs inspecting a CompiledMethod > Yes, explorer using different model for displaying object(s). As i remember it is using a common #printOn: message to display objects. > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > 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.

Oct. 29, 2008

Re: [Pharo-project] RBParser

by Lukas Renggli

> As I've said to you Marcus, I've worked on the RBParser/RBScanner. I've > fixed these classes and now you can parse the entire image. At this moment > the refactoring is not yet finished but I've made some good progress. Good news. I was not aware that you were working on RBParser. Stef told me that you also improved the refactorings. I think you should commit and work on the public repository to get more attention. I guess there were many other changes going on in RB codebase in the meantime. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 29, 2008

Re: [Pharo-project] ToolSet -> ToolRegistry

by Matthew Fulmer

On Wed, Oct 29, 2008 at 04:20:55AM +0200, Igor Stasenko wrote: > I'm implemented a new ToolRegistry class, which can work as > replacement of ToolSet. > > It would require a 'bit' refactoring, to replace all references to > 'ToolSet' with 'Smalltalk tools'. > > What i discovered during implementation, if we migrate to new class, a > lot of stuff can be cleaned up. > For instance, > > Smalltalk tools inspectorTypes > > holds a dictionary of Class name -> inspector class name > so, one could simply register own inspector by including a line: > > Smalltalk tools inspectorTypes at: #MySpecialClass put: #MySpecialInspector > > in package/class initialization method, instead of overriding #inspect method. Actually, you are supposed to override inspectorClass, but yes, that does sound more uniform. Does it support inheritance, so that subclasses of MySpecialClass will use the nice inspector too? I don't see anything wrong with inspectorClass, except for the fact that ObjectExplorer and Inspector don't share the same inspection model, which means you see different things when exploring vs inspecting a CompiledMethod -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Oct. 29, 2008

[Pharo-project] PopUpMenu

by Matthew Fulmer

On Wed, Oct 29, 2008 at 08:12:31AM +0100, St?phane Ducasse wrote: > I'm still looking for people to help cleaning the PopUpMenu plague. > > the idea would be to change PopUpMenu -> ToolBuilder > but this is not the solution. > the PopUpMenu should be converted into a Warning > and lot of PopUpMenu should be removed. What do you mean by "PopUpMenu plague"? I assume you mean refactoring Parser to send exceptions up the stack rather than interacting itself, and moving all that interaction code somewhere else (Where?). Is there anything else you mean? Does NewParser solve this problem, at least partially? -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Oct. 29, 2008

[Pharo-project] please do not update.

by StÃ©phane Ducasse

I will have to cancel 10120 and may 10119 because of a huge mess. Stef

Oct. 29, 2008