- Pharo-users - lists.pharo.org

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

by Tudor Girba

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] gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Peter UhnÃ¡k

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 > >

June 18, 2015

gtInspectorPresentation:, TreeModel, pragmas, visitors and polluting protocols

by Peter UhnÃ¡k

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

June 18, 2015

Re: [Pharo-users] Grapher bug?

by Alexandre Bergel

You pointed out indeed a default in Grapher. We will fix this in the futureâ¦ Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jun 17, 2015, at 6:06 PM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > > I know ;-) > I just wanted to avoid creating new big collections > > #Luc > > 2015-06-17 21:12 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: > Hi! > > Wellâ¦ Building the list of coordinate is not a big deal :-) > { 5 . 1 . 2 . 5 } withIndexCollect: [ :v :index | v @ index ] > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Jun 17, 2015, at 7:04 AM, Luc Fabresse <luc.fabresse(a)gmail.com <mailto:luc.fabresse@gmail.com>> wrote: >> >> Hi Alex, >> >> Thanks for your answer. >> I misunderstood RTStackedDataSet. >> To me, it does not do what the doc says ;-) >> >> I want to do exactly that: >> >> c := RTGrapher new. >> ds := RTDataSet new. >> ds dotShape color: Color red. >> ds points: {5@1 . 1@2 . 20@3 . 5@4 }. >> ds x: [ :e | e y ]. >> ds y: [ :e | e x ]. >> c add: ds. >> c axisX noDecimal. >> c axisY noDecimal. >> c build. >> c view inspect. >> >> But I would like to not write by hand (or compute) the X values in the data set which are the indexes of the element. >> >> Thanks, >> >> #Luc >> >> 2015-06-16 22:39 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: >> Hi Luc! >> >> This is something that is not really intuitive in Roassal. I am not sure whether this is a bug, but until now, we usually disable the labels on the X-axis. >> >> So, your script should be >> -=-=-=-=-=-=-=-=-=-=-=-= >> b := RTGrapher new. >> ds := RTStackedDataSet new. >> ds dotShape color: Color red. >> ds points: #(5 1 20 5). >> ds y: #yourself. >> b add: ds. >> b axisX noLabel; noTick. >> b axisY noDecimal. >> b >> -=-=-=-=-=-=-=-=-=-=-=-= >> <Screen Shot 2015-06-16 at 5.37.44 PM.png> >> >> If you need ticks and labels, you can simply do: >> -=-=-=-=-=-=-=-=-=-= >> b := RTGrapher new. >> ds := RTStackedDataSet new. >> ds barShape width: 10. >> ds barChartWithBarCenteredTitle: #yourself. >> ds points: #(5 1 20 5). >> ds y: #yourself. >> b add: ds. >> b axisX noLabel; noTick. >> b axisY noDecimal. >> >> b >> -=-=-=-=-=-=-=-=-=-= >> <Screen Shot 2015-06-16 at 5.39.28 PM.png> >> >> I hope this solves your problem. >> >> Cheers, >> Alexandre >> >> >>> On Jun 15, 2015, at 6:20 PM, Luc Fabresse <luc.fabresse(a)gmail.com <mailto:luc.fabresse@gmail.com>> wrote: >>> >>> Hi, >>> >>> The doc here [1] says: "Data points may be stacked, meaning that the index of the point in the collection is its X value." >>> >>> When I use the same example as in the doc but with labels and ticks: >>> >>> b := RTGrapher new. >>> ds := RTStackedDataSet new. >>> ds dotShape color: Color red. >>> ds points: #(5 1 20 5). >>> ds y: #yourself. >>> b add: ds. >>> b axisX noDecimal. >>> b axisY noDecimal. >>> b build. >>> b view inspect >>> >>> it seems that y values are not aligned on x ones (i.e. I would expect the first red point to be 1@5). Is it a bug or did I misunderstood something? >>> >>> >>> <Screen Shot 2015-06-15 at 23.18.36.png> >>> >>> >>> [1] https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/020… <https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/020…>Grapher.html >>> >>> >>> Thanks, >>> >>> #Luc >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > >

June 17, 2015

Re: [Pharo-users] Woden-Roassal pharo5 inspector bugs

by Natalia Tymchuk

Are there any news? > On 06 May 2015, at 13:00, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Apparently moose will soon move to Pharo 5. Maybe next week or so. > > Alexandre > > > >> Le 6 mai 2015 Ã 04:34, Lusa Nicolas <nicolas.lusa(a)usi.ch> a Ã©crit : >> >> Hi, >> >> thanks for the quick answer, I'll switch back to pharo4 for the moment. >> >> Cheers, >> Nicolas >> >> >

June 17, 2015

Re: [Pharo-users] Grapher bug?

by Luc Fabresse

I know ;-) I just wanted to avoid creating new big collections #Luc 2015-06-17 21:12 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > Wellâ¦ Building the list of coordinate is not a big deal :-) > { 5 . 1 . 2 . 5 } withIndexCollect: [ :v :index | v @ index ] > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Jun 17, 2015, at 7:04 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > Hi Alex, > > Thanks for your answer. > I misunderstood RTStackedDataSet. > To me, it does not do what the doc says ;-) > > I want to do exactly that: > > c := RTGrapher new. > ds := RTDataSet new. > ds dotShape color: Color red. > ds points: {5@1 . 1@2 . 20@3 . 5@4 }. > ds x: [ :e | e y ]. > ds y: [ :e | e x ]. > c add: ds. > c axisX noDecimal. > c axisY noDecimal. > c build. > c view inspect. > > But I would like to not write by hand (or compute) the X values in the > data set which are the indexes of the element. > > Thanks, > > #Luc > > 2015-06-16 22:39 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > >> Hi Luc! >> >> This is something that is not really intuitive in Roassal. I am not sure >> whether this is a bug, but until now, we usually disable the labels on the >> X-axis. >> >> So, your script should be >> -=-=-=-=-=-=-=-=-=-=-=-= >> b := RTGrapher new. >> ds := RTStackedDataSet new. >> ds dotShape color: Color red. >> ds points: #(5 1 20 5). >> ds y: #yourself. >> b add: ds. >> b axisX noLabel; noTick. >> b axisY noDecimal. >> b >> -=-=-=-=-=-=-=-=-=-=-=-= >> <Screen Shot 2015-06-16 at 5.37.44 PM.png> >> >> If you need ticks and labels, you can simply do: >> -=-=-=-=-=-=-=-=-=-= >> b := RTGrapher new. >> ds := RTStackedDataSet new. >> ds barShape width: 10. >> ds barChartWithBarCenteredTitle: #yourself. >> ds points: #(5 1 20 5). >> ds y: #yourself. >> b add: ds. >> b axisX noLabel; noTick. >> b axisY noDecimal. >> >> b >> -=-=-=-=-=-=-=-=-=-= >> <Screen Shot 2015-06-16 at 5.39.28 PM.png> >> >> I hope this solves your problem. >> >> Cheers, >> Alexandre >> >> >> On Jun 15, 2015, at 6:20 PM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: >> >> Hi, >> >> The doc here [1] says: "Data points may be stacked, meaning that the >> index of the point in the collection is its X value." >> >> When I use the same example as in the doc but with labels and ticks: >> >> b := RTGrapher new. >> ds := RTStackedDataSet new. >> ds dotShape color: Color red. >> ds points: #(5 1 20 5). >> ds y: #yourself. >> b add: ds. >> b axisX noDecimal. >> b axisY noDecimal. >> b build. >> b view inspect >> >> it seems that y values are not aligned on x ones (i.e. I would expect the >> first red point to be 1@5). Is it a bug or did I misunderstood something? >> >> >> <Screen Shot 2015-06-15 at 23.18.36.png> >> >> >> [1] >> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/020… >> Grapher.html >> >> >> Thanks, >> >> #Luc >> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > >

June 17, 2015

Re: [Pharo-users] What would be the first code snippet you would show

by Sven Van Caekenberghe

Here are some more https://medium.com/concerning-pharo/elegant-pharo-code-bb590f0856d0 Maybe for teaching, the example should somehow be familiar, recognisable. On the other hand, that might be confusing and lead to too many comparisons. > On 17 Jun 2015, at 21:53, stepharo <stepharo(a)free.fr> wrote: > > Hi > > For the mooc I have a lecture called Pharo Syntax in a nutshell and I would love to get a couple of simple examples > that show the syntax but are not totally boring. > > I thought about something like > > > ZnClient new > url: 'http://localhost:8080/books/1'; > formAt: 'author' put: 'SquareBracketAssociates'; > formAt: 'title' put: 'Pharo For The Enterprise'; > put > > > > Stef >

June 17, 2015

What would be the first code snippet you would show

by stepharo

Hi For the mooc I have a lecture called Pharo Syntax in a nutshell and I would love to get a couple of simple examples that show the syntax but are not totally boring. I thought about something like ZnClient new url: 'http://localhost:8080/books/1'; formAt: 'author' put: 'SquareBracketAssociates'; formAt: 'title' put: 'Pharo For The Enterprise'; put Stef

June 17, 2015

Re: [Pharo-users] Grapher bug?

by Alexandre Bergel

Hi! Wellâ¦ Building the list of coordinate is not a big deal :-) { 5 . 1 . 2 . 5 } withIndexCollect: [ :v :index | v @ index ] Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jun 17, 2015, at 7:04 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > Hi Alex, > > Thanks for your answer. > I misunderstood RTStackedDataSet. > To me, it does not do what the doc says ;-) > > I want to do exactly that: > > c := RTGrapher new. > ds := RTDataSet new. > ds dotShape color: Color red. > ds points: {5@1 . 1@2 . 20@3 . 5@4 }. > ds x: [ :e | e y ]. > ds y: [ :e | e x ]. > c add: ds. > c axisX noDecimal. > c axisY noDecimal. > c build. > c view inspect. > > But I would like to not write by hand (or compute) the X values in the data set which are the indexes of the element. > > Thanks, > > #Luc > > 2015-06-16 22:39 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: > Hi Luc! > > This is something that is not really intuitive in Roassal. I am not sure whether this is a bug, but until now, we usually disable the labels on the X-axis. > > So, your script should be > -=-=-=-=-=-=-=-=-=-=-=-= > b := RTGrapher new. > ds := RTStackedDataSet new. > ds dotShape color: Color red. > ds points: #(5 1 20 5). > ds y: #yourself. > b add: ds. > b axisX noLabel; noTick. > b axisY noDecimal. > b > -=-=-=-=-=-=-=-=-=-=-=-= > <Screen Shot 2015-06-16 at 5.37.44 PM.png> > > If you need ticks and labels, you can simply do: > -=-=-=-=-=-=-=-=-=-= > b := RTGrapher new. > ds := RTStackedDataSet new. > ds barShape width: 10. > ds barChartWithBarCenteredTitle: #yourself. > ds points: #(5 1 20 5). > ds y: #yourself. > b add: ds. > b axisX noLabel; noTick. > b axisY noDecimal. > > b > -=-=-=-=-=-=-=-=-=-= > <Screen Shot 2015-06-16 at 5.39.28 PM.png> > > I hope this solves your problem. > > Cheers, > Alexandre > > >> On Jun 15, 2015, at 6:20 PM, Luc Fabresse <luc.fabresse(a)gmail.com <mailto:luc.fabresse@gmail.com>> wrote: >> >> Hi, >> >> The doc here [1] says: "Data points may be stacked, meaning that the index of the point in the collection is its X value." >> >> When I use the same example as in the doc but with labels and ticks: >> >> b := RTGrapher new. >> ds := RTStackedDataSet new. >> ds dotShape color: Color red. >> ds points: #(5 1 20 5). >> ds y: #yourself. >> b add: ds. >> b axisX noDecimal. >> b axisY noDecimal. >> b build. >> b view inspect >> >> it seems that y values are not aligned on x ones (i.e. I would expect the first red point to be 1@5). Is it a bug or did I misunderstood something? >> >> >> <Screen Shot 2015-06-15 at 23.18.36.png> >> >> >> [1] https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/020… <https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/020…>Grapher.html >> >> >> Thanks, >> >> #Luc > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

June 17, 2015

Environment-independent styler?

by Martin Dias

Hello, Suppose that you want to show the diff between the source code of two methods. In the case that both methods are in the same class, and that such class is present in the system, then no problem: In a DiffModel, one can set a context to the smalltalk syntax styler and get a nice output. DiffModel new leftText: (Point >> #x) sourceCode; rightText: (Point >> #y) sourceCode; contextClass: Point; openWithSpec. [image: Inline image 1] But what happens in the case that the class does not exist in the system? If one doesn't set any context to the styler, then the string will be shown all in black, which is not nice. A partial solution could be to set Object as a context, then the styler will color the code, but instance variables are in red: DiffModel new leftText: (Point >> #x) sourceCode; rightText: (Point >> #y) sourceCode; contextClass: Object; openWithSpec. [image: Inline image 2] Which is also not nice. In my opinion, there should be a styler that just colors the code following the syntax, without checking if the variables or classes are present in the system. It would be an environment-independent styler. What do you recommend to implement this? I guess it should be easy to subclass SHTextStylerST80 and override some methods to do not check anything in the environment. What's your opinion? Thanks, Martin

June 17, 2015