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

[Peter Uhnák]

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. :)

Peter

On Thu, Jun 18, 2015 at 8:12 AM, Tudor Girba  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  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  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"
>

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

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

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

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

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

[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

Re: [Pharo-users] Grapher bug?

[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  wrote:
> 
> 
> I know ;-)
> I just wanted to avoid creating new big collections 
> 
> #Luc
> 
> 2015-06-17 21:12 GMT+02:00 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 > > 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 > >:
>> 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
>> -=-=-=-=-=-=-=-=-=-=-=-=
>> 
>> 
>> 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
>> -=-=-=-=-=-=-=-=-=-=
>> 
>> 
>> I hope this solves your problem.
>> 
>> Cheers,
>> Alexandre
>> 
>> 
>>> On Jun 15, 2015, at 6:20 PM, Luc Fabresse >> > 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?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> [1] 
>>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/0202-
>>>  
>>> Grapher.html
>>> 
>>> 
>>> Thanks,
>>> 
>>> #Luc
>> 
>> -- 
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu 
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>> 
>> 
>> 
>> 
> 
> 

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

[Natalia Tymchuk]

Are there any news?

> On 06 May 2015, at 13:00, Alexandre Bergel  wrote:
> 
> Apparently moose will soon move to Pharo 5. Maybe next week or so. 
> 
> Alexandre 
> 
> 
> 
>> Le 6 mai 2015 à 04:34, Lusa Nicolas  a écrit :
>> 
>> Hi,
>> 
>> thanks for the quick answer, I'll switch back to pharo4 for the moment.
>> 
>> Cheers,
>> Nicolas
>> 
>> 
> 

Re: [Pharo-users] Grapher bug?

[Luc Fabresse]

I know ;-)
I just wanted to avoid creating new big collections

#Luc

2015-06-17 21:12 GMT+02:00 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  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 :
>
>> 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
>> -=-=-=-=-=-=-=-=-=-=-=-=
>> 
>>
>> 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
>> -=-=-=-=-=-=-=-=-=-=
>> 
>>
>> I hope this solves your problem.
>>
>> Cheers,
>> Alexandre
>>
>>
>> On Jun 15, 2015, at 6:20 PM, Luc Fabresse  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?
>>
>>
>> 
>>
>>
>> [1]
>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/0202-
>> Grapher.html
>>
>>
>> Thanks,
>>
>> #Luc
>>
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>
>

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

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

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

[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

Re: [Pharo-users] Grapher bug?

[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  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  >:
> 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
> -=-=-=-=-=-=-=-=-=-=-=-=
> 
> 
> 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
> -=-=-=-=-=-=-=-=-=-=
> 
> 
> I hope this solves your problem.
> 
> Cheers,
> Alexandre
> 
> 
>> On Jun 15, 2015, at 6:20 PM, Luc Fabresse > > 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?
>> 
>> 
>> 
>> 
>> 
>> [1] 
>> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/0202-
>>  
>> Grapher.html
>> 
>> 
>> Thanks,
>> 
>> #Luc
> 
> -- 
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu 
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> 
> 
> 
> 

[Pharo-users] Environment-independent styler?

[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

Re: [Pharo-users] Ring Vs Ficus

[Martin Dias]

Uppp, I just see this email. Since Abdelghani visits RMoD, I've
discussed with him in person about this topic.

Ring-Ficus is an alternative implementation to Ring (as it is in the Pharo
image). Like Ring, Ficus-Ring provides models that represent system's code
entities, and they are also polymorphic with them. For example, RFiClass
shares the API of Class (partially) . The main differences are:
- closed-universe approach: a Ring-Ficus code entity will always answers a
Ring-Ficus code entity (in Ring it is not always like that)
- efficient for importing and querying whole Pharo environments: for
example, you can import all Pharo 40xxx code entities and query them, e.g.
find all the implementors or senders of a selector at each version.

Martin




On Sat, Jun 6, 2015 at 3:34 PM, stepharo  wrote:

>  Hi abdelghani
>
> Welcome to this list :)
>
>   Hi Guys,
>
>  I believe the Ring metamodel has been proposed 4 or 5 years earlier.
>  Is it acctually in use in the current pharo tools? which ones?
>
>
> Ring should be improved (probably with stubs) to support that we can
> create a method and that it does not create
> automatically the class of the method.
>
> Ring proposed strategy to query the code of a method (the one currently
> being in the image), or the method represented in the past or another one.
> and we should have a look at it.
>
>   I have been told that Martin has develloped a different model : Ficus
>
>
> Martin explained to me that ficus is built on two parts: one that describe
> the model and they other the "body " of an entity (data)
> and such data can be shared between multiple versions.
>
>   What are the limitations that Martin tried to fixed?
> What can be further unhanced?
>
>  Thanks.
>
>  Abdou.
>
>
>

Re: [Pharo-users] Grapher bug?

[Luc Fabresse]

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 :

> 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
> -=-=-=-=-=-=-=-=-=-=-=-=
>
> 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
> -=-=-=-=-=-=-=-=-=-=
>
> I hope this solves your problem.
>
> Cheers,
> Alexandre
>
>
> On Jun 15, 2015, at 6:20 PM, Luc Fabresse  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?
>
>
> 
>
>
> [1]
> https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Grapher/0202-
> Grapher.html
>
>
> Thanks,
>
> #Luc
>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>