June 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Stephan Eggermont

Wake up before posting childrenFor: anObject | col name | ^ApplicationTreeModelAdapter sharedInstance childrenFor: anObject ApplicationTreeModelAdapter>>childrenFor: anObject ^mapping at: anObject ApplicationTreeModelAdapter>>register: aOneParameterBlock at: aClass mapping at: aClass put: aOneParameterBlock ApplicationTreeModelAdapter>>childrenFor: anObject ^(mapping at: anObject class) value: anObject DMMindMap class>>registerChildren ApplicationTreeModelAdapter sharedInstance register: [:parent| ^OrderedCollection new] at: self

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Stephan Eggermont

childrenFor: anObject | col name | ^ApplicationTreeModelAdapter sharedInstance childrenFor: anObject ApplicationTreeModelAdapter>>childrenFor: anObject ^mapping at: anObject ApplicationTreeModelAdapter>>register: aOneParameterBlock at: aClass mappaing at: aClass put: aOneParameterBlock ApplicationTreeModelAdapter>>childrenFor: anObject ^(mapping at: anObject class) with: anObject DMMindMap class>>registerChildren ApplicationTreeModelAdapter sharedInstance register: [:parent| ^OrderedCollection new] at: self

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Christophe Demarey

Why not try to use TreeNodeModel to define different kind of nodes? On each node you can redefine the way to get children, the icon, etc. Then you give these nodes as the tree roots. Le 18 juin 2015 Ã 10:10, Peter UhnÃ¡k a Ã©crit : > > > I don't fully understand the TreeModel example, what would your tool do with all the men/displayBlock/childrenBlock ... - methods? > > > Ah, I should've explained what TreeModel is; it is a Spec UI widget to display tree-like structures: > > > â > > So the way this works is that I give the TreeModel some root object (DCFsm) and then blocks that describes some behavior. > So in childrenBlock: [ :parent | ... ] the block is expected to return child elements for the parent. > In displayBlock: you pass a block that returns the label that you will see.. e.g. [ :anObject | anObject name , ' (' , anObject class name , ')' ] > iconBlock: returns the icon for the object and so on and so forth. > > So the way I have implemented it right now is something like > > ~~~~~~~~~~~~~~~~~ > childrenFor: anObject > | col name | > name := anObject class asString asSymbol. > col := OrderedCollection new. > name = #DMMindMap > ifTrue: [ ^ col ]. > (anObject isKindOf: DCDiagram) > ifTrue: [ col addAll: anObject elements ]. > (anObject isKindOf: DCNamedElement) > ifTrue: [ > name = #BormParticipant > ifTrue: [ col addAll: anObject nodes ]. > name = #BormActivity | (name = #BormState) > ifTrue: [ col addAll: anObject outgoing ]. > name = #BormActivity > ifTrue: [ col addAll: anObject sent ]. > name = #BormCommunication > ifTrue: [ col addAll: anObject dataFlows ]. > name = #BormCommunication > ifTrue: [ > anObject hasConstraint > ifTrue: [ col add: anObject constraint ] ]. > name = #BormTransition > ifTrue: [ > anObject hasConstraint > ifTrue: [ col add: anObject constraint ] ] ]. > ^ col > ~~~~~~~~~~~~~~~~~ > > Which is unreadable, unmaintainable and nonextensible. All the #Borm* symbols actually refer to classes of a completely independent package and repository which doesn't even need to be loaded in the system. > > I think what Peter means is: the object oriented way to handle different types is by dispatching on each type (~ double dispatch, ~ visiting). You could need this for different aspects of your application. In the end, the same core mechanism will be implemented multiple times. Sadly, minor semantics/structural differences will make it hard to abstract this out. > > Yes, double-dispatch seems like the apt solution, however it would lead to NxM number of classes (as mentioned before). But the more I think about it the more I feel that I will not get any better than that. > > Peter

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Nicolai Hess

2015-06-18 8:37 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > The worry is caused by the fact that I do not want to pollute the > protocol; this is not just about GTInspector, but also about other classes > such as the TreeModel. > > So, imagine following hierarchy; there are some "base" classes and then > unlimited number of packages, each with their own hierarchy. > > > â > Now I could either have long switch (if/else/isKindOf:/isMemberOf:) in > TreeModel to specify icon, label, children and so forth for each of those > elements which is a) mess, and b) doesn't actually work because not all > packages might be loaded (this is what I have now, and instead of classes I > use symbols... and it's steaming mess). > Alternatively I could somehow use visitor, which would mean that I would > have visitor for each behavior: ChildrenVisitor, IconVisitor, ...; and then > there would be a method for each object. IconVisitor>>bormStateVisitor: ... > There is already visible name conflict (the visitor would have to add the > package name to the method which would mean special methods also on the > object's side) plus the methods themselves are related to the packages, so > basically I would have to have "FsmIconVisitor", "BormIconVisitor", etc. > Which is NxM visitors (number of behaviors x number of packages)... and > that's a lot of code. At this moment this seems like the "best" way, but to > me it feels like a very bad way to do this. > > Not sure if I made it any clearer though. :) > much clearer now, thank you. (First I thought you want a tool to inspect things like "instances of TreeModels") > > Peter > > On Thu, Jun 18, 2015 at 8:12 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi Peter, >> >> I am not sure I understand. >> >> Is the worry caused by the fact that when there are multiple gtInspector* >> methods then the API would get polluted? >> >> Cheers, >> Doru >> >> >> >> On Thu, Jun 18, 2015 at 7:35 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >>> Also the problem with visitor here is that I would need X number of >>> visitors for each method (GtInspectorVisitor, DisplayBlockVisitor, ...) not >>> to mention that I would need to have the implementation split among >>> multiple packages, so it is effectively NxM visitors. >>> >>> Peter >>> >>> On Thu, Jun 18, 2015 at 7:23 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I would like to describe some additional behavior for objects when they >>>> are interacting with another objects. >>>> >>>> The prime example is GTInspector; by default to add presentation you >>>> implement a method with "gtInspectorPresentationOrder:". This is fine if >>>> there is just one method like this, but when the object can serve multiple >>>> purposes it can quite mess up the protocol (in my opinion). >>>> >>>> Example of that could be (Spec) TreeModel; there are many methods like >>>> menu:, displayBlock:, childrenBlock: etc. that should be different based on >>>> the particular object. >>>> >>>> However having a method for each of those cases in the observed method >>>> is just a mess. So how could one approach this? >>>> >>>> The first thing that comes to my mind is a visitor. That might possibly >>>> work for code that I've written, but not for spotter/inspector as they work >>>> directly on the target object. >>>> >>>> Thanks, >>>> Peter >>>> >>>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

June 18, 2015

Re: [Pharo-users] Monticello / OS deadlock ?

by Thierry Goubier

2015-06-18 10:32 GMT+02:00 Jose San Leandro <jose.sanleandro(a)osoco.es>: > Hi, > > So far it works perfect. I'll let you know if it happens again. > Thanks. > > Thank you very much! > You're welcome. Just a question: which version of the vm are you using? Or which zeroconf scripts are you using to download Pharo? I made some changes related to OSProcess in the latest vm (and they have been integrated); if, say, you're using the normal Pharo4 vm, then it would mean that your problem was solved by changing the way GitFileTree uses OSProcess. Thierry > > 2015-06-11 23:28 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Hi Jose, >> >> I have pushed a new version of GitFileTree (the development version for >> Pharo4) with a complete rewrite of the underlying OSProcess use. Could you >> test to see if it solves your deadlocks? >> >> It should also be a tad faster. >> >> Regards, >> >> Thierry >> >> >> Le 03/06/2015 17:03, Jose San Leandro a Ã©crit : >> >>> Unfortunately it doesn't fix it, or at least I get the same sympthoms. >>> >>> >> >> >

June 18, 2015

Re: [Pharo-users] Monticello / OS deadlock ?

by Jose San Leandro

Hi, So far it works perfect. I'll let you know if it happens again. Thank you very much! 2015-06-11 23:28 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Jose, > > I have pushed a new version of GitFileTree (the development version for > Pharo4) with a complete rewrite of the underlying OSProcess use. Could you > test to see if it solves your deadlocks? > > It should also be a tad faster. > > Regards, > > Thierry > > > Le 03/06/2015 17:03, Jose San Leandro a Ã©crit : > >> Unfortunately it doesn't fix it, or at least I get the same sympthoms. >> >> > >

June 18, 2015

Woden not loading anymore

by Lusa Nicolas

Hi, it was a while that I wasn't updating the woden version that I am using in my project, so today I thought to give it a try and see if there was something new. And now I am not able to load woden anymore, what I get is the following error message: Error: Name not found: WithOpenGLAndExamples I am trying to load it into a fresh Pharo 4 image, but no way, it doesn't load. Here are the version and repository I am referring to when trying to load it: version: #jenkins; repository: 'http://smalltalkhub.com/mc/ronsaldo/Woden/main'. Does anyone know what's going on? Cheers, Nicolas

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Peter UhnÃ¡k

And gmail didn't add the image correctly it seems... â On Thu, Jun 18, 2015 at 10:10 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> > I don't fully understand the TreeModel example, what would your tool do >> with all the men/displayBlock/childrenBlock ... - methods? >> > > > Ah, I should've explained what TreeModel is; it is a Spec UI widget to > display tree-like structures: > > > â > > So the way this works is that I give the TreeModel some root object > (DCFsm) and then blocks that describes some behavior. > So in childrenBlock: [ :parent | ... ] the block is expected to return > child elements for the parent. > In displayBlock: you pass a block that returns the label that you will > see.. e.g. [ :anObject | anObject name , ' (' , anObject class name , ')' ] > iconBlock: returns the icon for the object and so on and so forth. > > So the way I have implemented it right now is something like > > ~~~~~~~~~~~~~~~~~ > childrenFor: anObject > | col name | > name := anObject class asString asSymbol. > col := OrderedCollection new. > name = #DMMindMap > ifTrue: [ ^ col ]. > (anObject isKindOf: DCDiagram) > ifTrue: [ col addAll: anObject elements ]. > (anObject isKindOf: DCNamedElement) > ifTrue: [ > name = #BormParticipant > ifTrue: [ col addAll: anObject nodes ]. > name = #BormActivity | (name = #BormState) > ifTrue: [ col addAll: anObject outgoing ]. > name = #BormActivity > ifTrue: [ col addAll: anObject sent ]. > name = #BormCommunication > ifTrue: [ col addAll: anObject dataFlows ]. > name = #BormCommunication > ifTrue: [ > anObject hasConstraint > ifTrue: [ col add: anObject constraint ] ]. > name = #BormTransition > ifTrue: [ > anObject hasConstraint > ifTrue: [ col add: anObject constraint ] ] ]. > ^ col > ~~~~~~~~~~~~~~~~~ > > Which is unreadable, unmaintainable and nonextensible. All the #Borm* > symbols actually refer to classes of a completely independent package and > repository which doesn't even need to be loaded in the system. > > I think what Peter means is: the object oriented way to handle different >> types is by dispatching on each type (~ double dispatch, ~ visiting). You >> could need this for different aspects of your application. In the end, the >> same core mechanism will be implemented multiple times. Sadly, minor >> semantics/structural differences will make it hard to abstract this out. > > > Yes, double-dispatch seems like the apt solution, however it would lead to > NxM number of classes (as mentioned before). But the more I think about it > the more I feel that I will not get any better than that. > > Peter >

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Peter UhnÃ¡k

> > > > I don't fully understand the TreeModel example, what would your tool do > with all the men/displayBlock/childrenBlock ... - methods? > Ah, I should've explained what TreeModel is; it is a Spec UI widget to display tree-like structures: â So the way this works is that I give the TreeModel some root object (DCFsm) and then blocks that describes some behavior. So in childrenBlock: [ :parent | ... ] the block is expected to return child elements for the parent. In displayBlock: you pass a block that returns the label that you will see.. e.g. [ :anObject | anObject name , ' (' , anObject class name , ')' ] iconBlock: returns the icon for the object and so on and so forth. So the way I have implemented it right now is something like ~~~~~~~~~~~~~~~~~ childrenFor: anObject | col name | name := anObject class asString asSymbol. col := OrderedCollection new. name = #DMMindMap ifTrue: [ ^ col ]. (anObject isKindOf: DCDiagram) ifTrue: [ col addAll: anObject elements ]. (anObject isKindOf: DCNamedElement) ifTrue: [ name = #BormParticipant ifTrue: [ col addAll: anObject nodes ]. name = #BormActivity | (name = #BormState) ifTrue: [ col addAll: anObject outgoing ]. name = #BormActivity ifTrue: [ col addAll: anObject sent ]. name = #BormCommunication ifTrue: [ col addAll: anObject dataFlows ]. name = #BormCommunication ifTrue: [ anObject hasConstraint ifTrue: [ col add: anObject constraint ] ]. name = #BormTransition ifTrue: [ anObject hasConstraint ifTrue: [ col add: anObject constraint ] ] ]. ^ col ~~~~~~~~~~~~~~~~~ Which is unreadable, unmaintainable and nonextensible. All the #Borm* symbols actually refer to classes of a completely independent package and repository which doesn't even need to be loaded in the system. I think what Peter means is: the object oriented way to handle different > types is by dispatching on each type (~ double dispatch, ~ visiting). You > could need this for different aspects of your application. In the end, the > same core mechanism will be implemented multiple times. Sadly, minor > semantics/structural differences will make it hard to abstract this out. Yes, double-dispatch seems like the apt solution, however it would lead to NxM number of classes (as mentioned before). But the more I think about it the more I feel that I will not get any better than that. Peter

June 18, 2015

Re: [Pharo-users] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Sven Van Caekenberghe

I think what Peter means is: the object oriented way to handle different types is by dispatching on each type (~ double dispatch, ~ visiting). You could need this for different aspects of your application. In the end, the same core mechanism will be implemented multiple times. Sadly, minor semantics/structural differences will make it hard to abstract this out. > On 18 Jun 2015, at 09:15, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-06-18 7:23 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > I would like to describe some additional behavior for objects when they are interacting with another objects. > > The prime example is GTInspector; by default to add presentation you implement a method with "gtInspectorPresentationOrder:". This is fine if there is just one method like this, but when the object can serve multiple purposes it can quite mess up the protocol (in my opinion). > > Example of that could be (Spec) TreeModel; there are many methods like menu:, displayBlock:, childrenBlock: etc. that should be different based on the particular object. > > Do you mean another kind of inspector, not GT-Inspector, but something that uses the same pattern (methods with pragmas) to implement/realize different panes? > > I don't fully understand the TreeModel example, what would your tool do with all the men/displayBlock/childrenBlock ... - methods? > > > > However having a method for each of those cases in the observed method is just a mess. So how could one approach this? > > The first thing that comes to my mind is a visitor. That might possibly work for code that I've written, but not for spotter/inspector as they work directly on the target object. > > Thanks, > Peter > >

June 18, 2015