Re: [Pharo-users] [Pharo-dev] TestAsserter>>assertCollection:hasSameElements:

[jtuc...@objektfabrik.de]

Hi Sven,


Am 25.10.15 um 11:45 schrieb Sven Van Caekenberghe:

On 25 Oct 2015, at 11:37, jtuc...@objektfabrik.de wrote:

Sorry guys, but today is my destructive day...


I think most of the assert:whatever: methods are a waste of time and energy and 
just pollute SUnit with lots of methods that are named with misleading or at 
best debatable names.

Examples:

assert:equals:  it's just more typing than #= with no additional outcome

I disagree: it does make a real difference, it gives a much better error 
message, like 'got $A but expected $X', instead of 'something failed'.


I really love the code you write and admire your tools. So I am glad I 
didn't respond to your comment right away. Peter's comment on this 
thread helped me understand what you were talking about ;-) Because this 
kind of comment is the least expected reaction I could possibly get. 
OTOH it seems like a good explanation for why SUnit is being misused the 
way it is.
What you basically are saying is that people had no better idea to get 
better error descriptions than to add more and more useless and misnamed 
assertion methods. I know you are a really good developer so I guess you 
are saying this because we are lazy people by design, not because you 
think the way to achieve the goal is a good approach, right?



assertCollection:hasSameElements:
So, let's start by asking what the question really means. Does it mean that one 
collection is a subset of the other? What about ordering then? Does it mean 
both contain the same elements at the same position or just the fact that if 
they both were Sets contained the exact same elements. The question itself is 
not exact, so how could an answer possibly be?

I agree: it helps little. It is much clearer to write something like, for 
example,

self assert: result asOrderedCollection asSortedCollection equals: (1 to: 10) 
asOrderedCollection

because then you are very explicit about the test.


are you trying to be sarcastic or do you really agree? If your example 
is a way of showing me that the code needed to be absolutely explicit 
about what you want is hard to read, then it sure is a good one. But it 
is not an excuse for badly named methods that save typing...
I didn't say it is a bad thing to provide shorter method names for 
complex facts. I said it is a bad thing to name them wrong or 
misleadingly. Because this will lead to frustration. If you name a 
method with the word "Collection" in it and implement it in a way that 
is only valid for Sets, this is a clear misnomer, isn't it?


There's nothing wrong in writing your own extensions for SUnit, but not 
every method that you think is handy is a good candidate for the base 
framework, even if it's just the Pharo-fork of it.


More as a response to Peter's comment...


Joachim


--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] Would smart variable ordering improve performance?

[Eliot Miranda]

Hi Alexandre,

On Fri, Oct 23, 2015 at 2:18 PM, Alexandre Bergel 
wrote:

> Hi!
>
> It is known that increasing data locality is a good way to benefit from
> CPU caches. There has been some effort from the IBM’s JVM crew that aligns
> some frequently accessed variables at a particular offset to improve
> accesses. Would this approach works in Pharo?
>
> Other similar situation: will the expression “Object new yourself” be
> faster if the object (i.e., result of Object new) is physically close to
> the class Object in memory?
>

Clément and I have discussed this issue.  It's one significant advantage
that a conventional procedural language has over an OO one.  Compare some
rendering pipeline that in its OO version has to traverse deep object
structure to dig out parameters as opposed to some array based
implementation where the parameters are extracted out into separate arrays
and hence the traversal is much simpler.

I doubt that some minor rearrangement or alignment of structure would make
any difference.  But imagine an adaptive optimizer for data structure that
could make the same transformation, automatically and invisibly to the
programmer.  Such a general purpose optimizer would be far more powerful.
That's the kind of solution we think will be tried and that we would try if
we encountered such performance issues and we had time to address it.

But I think this is beyond the current state of the art and it feels like a
PhD topic.  I do remember Yoshiki saying that some plugin was doing
something similar, but I could be mistaken.


> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>


-- 
_,,,^..^,,,_
best, Eliot

Re: [Pharo-users] Is GitFileTree broken on Pharo 5 ?

[Dimitris Chloupis]

the output is

* master

nothing confidential all i did was create a new repo in github and just git
clone it to my hard disk as I have done with all my other gitfiletree
projects.

On Sun, Oct 25, 2015 at 11:29 PM Thierry Goubier 
wrote:

> Le 25/10/2015 22:04, Dimitris Chloupis a écrit :
> > because I just downloaded a fresh pharo 5 image and installed
> > gitfiletree from catalog browser and i try to add a newly initialised
> > git repo and i am getting this
>
> Well, normally no since I'm using it on Pharo5. But I may have missed
> the last round of updates (haven't rebuilt since two or three days ago).
>
> Can you give me the output of
>
> $ git branch
>
> in your repository, if there is nothing confidential? The error
> indicates that GitFileTree doesn't find a current/active branch.
>
> Thierry
>
>
> > Array(Object)>>errorSubscriptBounds: Array(Object)>>at:
> > MCFileTreeGitRepository>>currentBranch MCFileTreeGitRepository>>branch
> > MCFileTreeGitRepository>>description [ :ea | ea description ] in
> > MCWorkingCopyBrowser>>repositoryList in Block: [ :ea | ea description ]
> > Array(SequenceableCollection)>>collect:
> > MCWorkingCopyBrowser>>repositoryList PluggableIconListMorph>>getList
> > PluggableIconListMorph(PluggableListMorph)>>getListSize
> > LazyMorphListMorph(LazyListMorph)>>getListSize
> > LazyMorphListMorph>>listChanged
> > PluggableIconListMorph(PluggableListMorph)>>updateList
> > PluggableIconListMorph(PluggableListMorph)>>update: [ :aDependent |
> > aDependent update: aParameter ] in
> > MCWorkingCopyBrowser(Object)>>changed: in Block: [ :aDependent |
> > aDependent update: aParameter ] DependentsArray>>do:
> > MCWorkingCopyBrowser(Object)>>changed:
> > MCWorkingCopyBrowser>>repositoryListChanged
> > MCWorkingCopyBrowser>>editRepository
> > MCWorkingCopyBrowser(Object)>>perform:orSendTo: [ | selArgCount | "show
> > cursor in case item opens a new MVC window" (selArgCount := selector
> > numArgs) = 0 ifTrue: [ target perform: selector ] ifFalse: [ selArgCount
> > = arguments size ifTrue: [ target perform: selector withArguments:
> > arguments ] ifFalse: [ target perform: selector withArguments:
> > (arguments copyWith: evt) ] ]. self changed ] in
> > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ |
> > selArgCount |... BlockClosure>>ensure:
> > CursorWithMask(Cursor)>>showWhile:
> > ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent:
> > ToggleMenuItemMorph(MenuItemMorph)>>mouseUp:
> > ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp:
> > MouseButtonEvent>>sentTo: ToggleMenuItemMorph(Morph)>>handleEvent:
> > MorphicEventDispatcher>>dispatchDefault:with:
> > MorphicEventDispatcher>>handleMouseUp:
>
>
>

[Pharo-users] Little Meeting at Pittsburg

[stepharo]

Hi

Guillermo, Andrei, Guido and me are attending OOPSLA so we could have a 
small

Pharo meeting.
What about wednesday evening?

Stef

Re: [Pharo-users] Is GitFileTree broken on Pharo 5 ?

[Thierry Goubier]

Le 25/10/2015 22:04, Dimitris Chloupis a écrit :

because I just downloaded a fresh pharo 5 image and installed
gitfiletree from catalog browser and i try to add a newly initialised
git repo and i am getting this


Well, normally no since I'm using it on Pharo5. But I may have missed 
the last round of updates (haven't rebuilt since two or three days ago).


Can you give me the output of

$ git branch

in your repository, if there is nothing confidential? The error 
indicates that GitFileTree doesn't find a current/active branch.


Thierry



Array(Object)>>errorSubscriptBounds: Array(Object)>>at:
MCFileTreeGitRepository>>currentBranch MCFileTreeGitRepository>>branch
MCFileTreeGitRepository>>description [ :ea | ea description ] in
MCWorkingCopyBrowser>>repositoryList in Block: [ :ea | ea description ]
Array(SequenceableCollection)>>collect:
MCWorkingCopyBrowser>>repositoryList PluggableIconListMorph>>getList
PluggableIconListMorph(PluggableListMorph)>>getListSize
LazyMorphListMorph(LazyListMorph)>>getListSize
LazyMorphListMorph>>listChanged
PluggableIconListMorph(PluggableListMorph)>>updateList
PluggableIconListMorph(PluggableListMorph)>>update: [ :aDependent |
aDependent update: aParameter ] in
MCWorkingCopyBrowser(Object)>>changed: in Block: [ :aDependent |
aDependent update: aParameter ] DependentsArray>>do:
MCWorkingCopyBrowser(Object)>>changed:
MCWorkingCopyBrowser>>repositoryListChanged
MCWorkingCopyBrowser>>editRepository
MCWorkingCopyBrowser(Object)>>perform:orSendTo: [ | selArgCount | "show
cursor in case item opens a new MVC window" (selArgCount := selector
numArgs) = 0 ifTrue: [ target perform: selector ] ifFalse: [ selArgCount
= arguments size ifTrue: [ target perform: selector withArguments:
arguments ] ifFalse: [ target perform: selector withArguments:
(arguments copyWith: evt) ] ]. self changed ] in
ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ |
selArgCount |... BlockClosure>>ensure:
CursorWithMask(Cursor)>>showWhile:
ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent:
ToggleMenuItemMorph(MenuItemMorph)>>mouseUp:
ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp:
MouseButtonEvent>>sentTo: ToggleMenuItemMorph(Morph)>>handleEvent:
MorphicEventDispatcher>>dispatchDefault:with:
MorphicEventDispatcher>>handleMouseUp:

[Pharo-users] Is GitFileTree broken on Pharo 5 ?

[Dimitris Chloupis]

because I just downloaded a fresh pharo 5 image and installed gitfiletree
from catalog browser and i try to add a newly initialised git repo and i am
getting this

Array(Object)>>errorSubscriptBounds: Array(Object)>>at:
MCFileTreeGitRepository>>currentBranch MCFileTreeGitRepository>>branch
MCFileTreeGitRepository>>description [ :ea | ea description ] in
MCWorkingCopyBrowser>>repositoryList in Block: [ :ea | ea description ]
Array(SequenceableCollection)>>collect:
MCWorkingCopyBrowser>>repositoryList PluggableIconListMorph>>getList
PluggableIconListMorph(PluggableListMorph)>>getListSize
LazyMorphListMorph(LazyListMorph)>>getListSize
LazyMorphListMorph>>listChanged
PluggableIconListMorph(PluggableListMorph)>>updateList
PluggableIconListMorph(PluggableListMorph)>>update: [ :aDependent |
aDependent update: aParameter ] in MCWorkingCopyBrowser(Object)>>changed:
in Block: [ :aDependent | aDependent update: aParameter ]
DependentsArray>>do: MCWorkingCopyBrowser(Object)>>changed:
MCWorkingCopyBrowser>>repositoryListChanged
MCWorkingCopyBrowser>>editRepository
MCWorkingCopyBrowser(Object)>>perform:orSendTo: [ | selArgCount | "show
cursor in case item opens a new MVC window" (selArgCount := selector
numArgs) = 0 ifTrue: [ target perform: selector ] ifFalse: [ selArgCount =
arguments size ifTrue: [ target perform: selector withArguments: arguments
] ifFalse: [ target perform: selector withArguments: (arguments copyWith:
evt) ] ]. self changed ] in
ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent: in Block: [ |
selArgCount |... BlockClosure>>ensure: CursorWithMask(Cursor)>>showWhile:
ToggleMenuItemMorph(MenuItemMorph)>>invokeWithEvent:
ToggleMenuItemMorph(MenuItemMorph)>>mouseUp:
ToggleMenuItemMorph(MenuItemMorph)>>handleMouseUp:
MouseButtonEvent>>sentTo: ToggleMenuItemMorph(Morph)>>handleEvent:
MorphicEventDispatcher>>dispatchDefault:with:
MorphicEventDispatcher>>handleMouseUp:

Re: [Pharo-users] [ANN] Working with Pharo on the Raspberry Pi

[Thierry Goubier]

Le 25/10/2015 21:47, Torsten Bergmann a écrit :

I wrote a small article on Medium on how to setup the Pi
with a touch screen and Pharo:

https://medium.com/@astares/pharo-pi-9eef257b6a21#.gw72pe7uy

Hope one or the other might be interested.

Have fun
T.



Cool and interesting :)

Thierry

[Pharo-users] [ANN] Working with Pharo on the Raspberry Pi

[Torsten Bergmann]

I wrote a small article on Medium on how to setup the Pi
with a touch screen and Pharo:

https://medium.com/@astares/pharo-pi-9eef257b6a21#.gw72pe7uy

Hope one or the other might be interested.

Have fun
T.

Re: [Pharo-users] A stopwatch tool with calendar support

[Jimmie Houchin]

This is one of the things I love about Pharo and over time hope to see 
more of.


I would love to see apps in Pharo which are equal and better to native 
OS apps. I would love to see the day that a high percentage of what we 
want to do can be done from within our Pharo environment. Thus leaving 
the OS simply as a layer between Pharo and the hardware. A necessary 
tool, expedient for the time. At least until we have a PharoOS.


This would allow us to have a very portable computing experience. And we 
would care if we are on Linux, Windows, or MacOS. Somewhat similar to 
the way you have window managers or graphical toolkits in Linux. Maybe 
even get to the place I can put this on top of a nice NetBSD and have 
very few requirements outside of the main OS and Pharo.


Just a dream of mine. One that I plan to contribute to.

Jimmie

On 10/25/2015 12:31 PM, Dimitris Chloupis wrote:
yes obviously there are tons of non pharo tools out there . But since 
I find coding fun and I rather create something I can control and 
extend hence my interest in a pharo implementation.


I was just wondering if there is anything remotely similar, seems 
Pomodoro is a simple timer but other than that, cant say I find 
anything more. Ok I will proceed and make it a installable tool via 
Catalog Browser from inside Pharo, will keep you posted :)


On Sun, Oct 25, 2015 at 5:36 PM Peter Uhnák > wrote:


I use regular Spreadsheet for this... although my problem is that
if I quickly switch between tasks or if I drown in some big
problem I forget to update it...

But having it in pharo would be interesting.

P

On Sun, Oct 25, 2015 at 12:33 PM, Dimitris Chloupis
mailto:kilon.al...@gmail.com>> wrote:

So my story goes a bit like this, I keep track of the time I
spend doing 3d graphics practice and I keep calendar to make
sure I spend at least 30 hours per week practicing 3d graphics.

But I was bored doing it with pencil and paper and a stopwatch
and I thought it would be way cooler to make a tool in Pharo
that is able to do this. Basically just a stopwatch that
records on the calendar my times.

Took very little time to find how to do this ,  it was as
simple as

watch := Stopwatch new. watch activate. watch end. watch
duration . watch suspend. ​ label := LabelMorph new. [[label
contents: watch asString]repeat]fork. ​ label openInWindow.



I plan to make this part of my Ephestos project and I was
wondering if anyone would want this as a separate tool or
there is already something doing similar thing around.

Re: [Pharo-users] Problem to connect Seaside and Pharo

[Sven Van Caekenberghe]

You have to do (Do it) the #initialize as well, like

MyExample initialize.

Or browse the method and highlight the body and evaluate it (Do it).

> On 25 Oct 2015, at 20:00, Justine STIENNE  wrote:
> 
> Oh sorry it was not for this conversation. I tried to do what you said, but 
> it doesn't work again.
> 
> Justine
> 
> 2015-10-25 19:55 GMT+01:00 Justine STIENNE :
> The installation is ok ! :-) But i cant open the file bak that you give me :-/
> 
> 2015-10-25 18:53 GMT+01:00 Sven Van Caekenberghe :
> Hi,
> 
> > On 25 Oct 2015, at 18:46, Justine STIENNE  wrote:
> >
> > Hello,
> >
> > I have a problem to connect Seaside and Pharo. I explain :
> >
> > ZnZincServerAdaptor is running. When I open localhost:8080, it works. When 
> > I want to configure a new entry, I can't find the class that I made on 
> > Pharo. I have put the method canBeRoot with true as return value on a class 
> > but I can't find it. Can you help me ?
> >
> > Thanks in advance,
> > Justine
> 
> #canBeRoot is just an indication, it has no real effect on its own.
> 
> Traditionally, WAComponent subclasses register themselves explicitly using 
> #initialize on the class side, like this:
> 
> initialize
>   WAAdmin register: self asApplicationAt: self handlerName
> 
> Look for the senders of #register:asApplicationAt: to see what I mean.
> 
> Sven
> 
> 
> 

Re: [Pharo-users] Problem to connect Seaside and Pharo

[Justine STIENNE]

Oh sorry it was not for this conversation. I tried to do what you said, but
it doesn't work again.

Justine

2015-10-25 19:55 GMT+01:00 Justine STIENNE :

> The installation is ok ! :-) But i cant open the file bak that you give me
> :-/
>
> 2015-10-25 18:53 GMT+01:00 Sven Van Caekenberghe :
>
>> Hi,
>>
>> > On 25 Oct 2015, at 18:46, Justine STIENNE 
>> wrote:
>> >
>> > Hello,
>> >
>> > I have a problem to connect Seaside and Pharo. I explain :
>> >
>> > ZnZincServerAdaptor is running. When I open localhost:8080, it works.
>> When I want to configure a new entry, I can't find the class that I made on
>> Pharo. I have put the method canBeRoot with true as return value on a class
>> but I can't find it. Can you help me ?
>> >
>> > Thanks in advance,
>> > Justine
>>
>> #canBeRoot is just an indication, it has no real effect on its own.
>>
>> Traditionally, WAComponent subclasses register themselves explicitly
>> using #initialize on the class side, like this:
>>
>> initialize
>>   WAAdmin register: self asApplicationAt: self handlerName
>>
>> Look for the senders of #register:asApplicationAt: to see what I mean.
>>
>> Sven
>>
>>
>

Re: [Pharo-users] Problem to connect Seaside and Pharo

[Justine STIENNE]

The installation is ok ! :-) But i cant open the file bak that you give me
:-/

2015-10-25 18:53 GMT+01:00 Sven Van Caekenberghe :

> Hi,
>
> > On 25 Oct 2015, at 18:46, Justine STIENNE 
> wrote:
> >
> > Hello,
> >
> > I have a problem to connect Seaside and Pharo. I explain :
> >
> > ZnZincServerAdaptor is running. When I open localhost:8080, it works.
> When I want to configure a new entry, I can't find the class that I made on
> Pharo. I have put the method canBeRoot with true as return value on a class
> but I can't find it. Can you help me ?
> >
> > Thanks in advance,
> > Justine
>
> #canBeRoot is just an indication, it has no real effect on its own.
>
> Traditionally, WAComponent subclasses register themselves explicitly using
> #initialize on the class side, like this:
>
> initialize
>   WAAdmin register: self asApplicationAt: self handlerName
>
> Look for the senders of #register:asApplicationAt: to see what I mean.
>
> Sven
>
>

Re: [Pharo-users] Problem to connect Seaside and Pharo

[Sven Van Caekenberghe]

Hi,

> On 25 Oct 2015, at 18:46, Justine STIENNE  wrote:
> 
> Hello,
> 
> I have a problem to connect Seaside and Pharo. I explain :
> 
> ZnZincServerAdaptor is running. When I open localhost:8080, it works. When I 
> want to configure a new entry, I can't find the class that I made on Pharo. I 
> have put the method canBeRoot with true as return value on a class but I 
> can't find it. Can you help me ?
> 
> Thanks in advance,
> Justine

#canBeRoot is just an indication, it has no real effect on its own.

Traditionally, WAComponent subclasses register themselves explicitly using 
#initialize on the class side, like this:

initialize
  WAAdmin register: self asApplicationAt: self handlerName

Look for the senders of #register:asApplicationAt: to see what I mean.

Sven
 

[Pharo-users] Problem to connect Seaside and Pharo

[Justine STIENNE]

Hello,

I have a problem to connect Seaside and Pharo. I explain :

ZnZincServerAdaptor is running. When I open localhost:8080, it works. When
I want to configure a new entry, I can't find the class that I made on
Pharo. I have put the method canBeRoot with true as return value on a class
but I can't find it. Can you help me ?

Thanks in advance,
Justine

Re: [Pharo-users] A stopwatch tool with calendar support

[Dimitris Chloupis]

yes obviously there are tons of non pharo tools out there . But since I
find coding fun and I rather create something I can control and extend
hence my interest in a pharo implementation.

I was just wondering if there is anything remotely similar, seems Pomodoro
is a simple timer but other than that, cant say I find anything more. Ok I
will proceed and make it a installable tool via Catalog Browser from inside
Pharo, will keep you posted :)

On Sun, Oct 25, 2015 at 5:36 PM Peter Uhnák  wrote:

> I use regular Spreadsheet for this... although my problem is that if I
> quickly switch between tasks or if I drown in some big problem I forget to
> update it...
>
> But having it in pharo would be interesting.
>
> P
>
> On Sun, Oct 25, 2015 at 12:33 PM, Dimitris Chloupis  > wrote:
>
>> So my story goes a bit like this, I keep track of the time I spend doing
>> 3d graphics practice and I keep calendar to make sure I spend at least 30
>> hours per week practicing 3d graphics.
>>
>> But I was bored doing it with pencil and paper and a stopwatch and I
>> thought it would be way cooler to make a tool in Pharo that is able to do
>> this. Basically just a stopwatch that records on the calendar my times.
>>
>> Took very little time to find how to do this ,  it was as simple as
>>
>> watch := Stopwatch new. watch activate. watch end. watch duration . watch
>> suspend. ​ label := LabelMorph new. [[label contents: watch
>> asString]repeat]fork. ​ label openInWindow.
>>
>>
>>
>> I plan to make this part of my Ephestos project and I was wondering if
>> anyone would want this as a separate tool or there is already something
>> doing similar thing around.
>>
>
>

Re: [Pharo-users] Exploring a data matrix with sunburst

[Nicolai Hess]

2015-10-25 13:55 GMT+01:00 Offray Vladimir Luna Cárdenas 
:

> Anyone?
>
>
No idea, maybe you can implement a new builder, based on the code of
sunbirst but with a different usage of the
data.


>
> On 23/10/15 20:54, Offray Vladimir Luna Cárdenas wrote:
>
>> Hi,
>>
>> I'm trying to make a visualization for medicine information and the idea
>> is to visualize it following a similar pattern to what is shown at [1], but
>> in this case, each arc is a medicine and each layer inside the arc is a
>> published property information of that medicine. Because of that, seems
>> that the best approach is to use a matrix, containing in the rows the
>> properties for each medicine and in the columns the medicine.
>>
>> [1]
>> http://www.theguardian.com/world/interactive/2012/may/08/gay-rights-united-states
>>
>> I can produce such matrix with dummy data, but when I try to explore it
>> using sunburst I'm not getting the proper visualization (look the
>> attachment). That's because sunburst uses hierarchy and recursion to pass
>> from the inner circles to the outer ones. So my question is: how can I use
>> sunburst to explore a matrix, being the inner circles the first row, the
>> second, the second row and so on.
>>
>> Thanks,
>>
>> Offray
>>
>
>
>

Re: [Pharo-users] A stopwatch tool with calendar support

[Peter Uhnák]

I use regular Spreadsheet for this... although my problem is that if I
quickly switch between tasks or if I drown in some big problem I forget to
update it...

But having it in pharo would be interesting.

P

On Sun, Oct 25, 2015 at 12:33 PM, Dimitris Chloupis 
wrote:

> So my story goes a bit like this, I keep track of the time I spend doing
> 3d graphics practice and I keep calendar to make sure I spend at least 30
> hours per week practicing 3d graphics.
>
> But I was bored doing it with pencil and paper and a stopwatch and I
> thought it would be way cooler to make a tool in Pharo that is able to do
> this. Basically just a stopwatch that records on the calendar my times.
>
> Took very little time to find how to do this ,  it was as simple as
>
> watch := Stopwatch new. watch activate. watch end. watch duration . watch
> suspend. ​ label := LabelMorph new. [[label contents: watch
> asString]repeat]fork. ​ label openInWindow.
>
>
>
> I plan to make this part of my Ephestos project and I was wondering if
> anyone would want this as a separate tool or there is already something
> doing similar thing around.
>

Re: [Pharo-users] [Pharo-dev] TestAsserter>>assertCollection:hasSameElements:

[Peter Uhnák]

>
> > assert:equals:  it's just more typing than #= with no additional outcome
>

I also disagree, but that may be also because maybe we write tests for
different purpse.
If you write tests just to test your code, then whatever... I don't do that
so I can't comment on that.

However if you do TDD, then tests are to provide feedback, and from that
perspective you want to see immediately what is the difference. If I see
that the assertion failed I have to start digging to find out what is the
difference, which is extra work and bad from feedback perspective. If I
instead immediately see what I need to see it allows me to faster deduce
the source of the problem and resolve it.

And this is actually quite generic idea... imagine that you are filling a
web form and when you click "submit" the website tells you "the form is
invalid" and nothing else; that is not helpful at all.
If it instead tells you "The date must be in format MM/DD/" and
highlights the incriminating field that I immediately can see the problem
and can fix it quickly.

So the different #assert:whatever: provide context for the assertion to be
able to get more valuable feedback.

It is a world of difference.

 > assertCollection:hasSameElements:

> > So, let's start by asking what the question really means. Does it mean
> that one collection is a subset of the other? What about ordering then?
> Does it mean both contain the same elements at the same position or just
> the fact that if they both were Sets contained the exact same elements. The
> question itself is not exact, so how could an answer possibly be?
>

There is no question about this method, since this is implemented in code
there is nothing ambiguous. This method effectively converts both arguments
to sets and compares them like that.
The question is whether such thing is useful for non-sets, and there are
definitely cases where such assertion is not appropriate (when you want to
ensure that there are specific items or specific positions), that's why I
suggested asserts specifically for that.


> self assert: result asOrderedCollection asSortedCollection equals: (1 to:
> 10) asOrderedCollection
>

This is what I usually do now (although I convert to Array, not
OrderedCollection, because the expected one is usually created by hand with
#() or {} ).

> Just a few weeks ago, we discussed something similar about the equality
> of two Collections. Endless discussions where people try convince others
> that their definition of equality and/or sameness is correct with no
> outcome.
>

I don't see a problem with that because collections truly can have
different equalities based on the context and their purpose. And while you
can call this rat poison, it effectively tells what kind of behavior you
expect from the collections, which seems ok.


> > So we could start by providing an abstract superclass for comparing
> collections based on more than just #= and #==. Then we can add subclasses
> for that which have a real intention revealing name like
> CollectionHasExactlyTheSameElementsAsAnotherAtTheSamePosition.
>

well this one specifically is quite regular array comparison, questions are
more about the other cases (without order, etc...). And I don't see why new
class instead of a selector somehow solves this.


>
> please keep these highly fragile
>
why is it fragile?


> and debatable things
>

that's why I initiated this debate in the first place.

 Peter

Re: [Pharo-users] Exploring a data matrix with sunburst

[Offray Vladimir Luna Cárdenas]

Anyone?

On 23/10/15 20:54, Offray Vladimir Luna Cárdenas wrote:

Hi,

I'm trying to make a visualization for medicine information and the 
idea is to visualize it following a similar pattern to what is shown 
at [1], but in this case, each arc is a medicine and each layer inside 
the arc is a published property information of that medicine. Because 
of that, seems that the best approach is to use a matrix, containing 
in the rows the properties for each medicine and in the columns the 
medicine.


[1] 
http://www.theguardian.com/world/interactive/2012/may/08/gay-rights-united-states


I can produce such matrix with dummy data, but when I try to explore 
it using sunburst I'm not getting the proper visualization (look the 
attachment). That's because sunburst uses hierarchy and recursion to 
pass from the inner circles to the outer ones. So my question is: how 
can I use sunburst to explore a matrix, being the inner circles the 
first row, the second, the second row and so on.


Thanks,

Offray

[Pharo-users] A stopwatch tool with calendar support

[Dimitris Chloupis]

So my story goes a bit like this, I keep track of the time I spend doing 3d
graphics practice and I keep calendar to make sure I spend at least 30
hours per week practicing 3d graphics.

But I was bored doing it with pencil and paper and a stopwatch and I
thought it would be way cooler to make a tool in Pharo that is able to do
this. Basically just a stopwatch that records on the calendar my times.

Took very little time to find how to do this ,  it was as simple as

watch := Stopwatch new. watch activate. watch end. watch duration . watch
suspend. ​ label := LabelMorph new. [[label contents: watch
asString]repeat]fork. ​ label openInWindow.



I plan to make this part of my Ephestos project and I was wondering if
anyone would want this as a separate tool or there is already something
doing similar thing around.

Re: [Pharo-users] [Pharo-dev] TestAsserter>>assertCollection:hasSameElements:

[Sven Van Caekenberghe]

> On 25 Oct 2015, at 11:37, jtuc...@objektfabrik.de wrote:
> 
> Sorry guys, but today is my destructive day...
> 
> 
> I think most of the assert:whatever: methods are a waste of time and energy 
> and just pollute SUnit with lots of methods that are named with misleading or 
> at best debatable names.
> 
> Examples: 
> 
> assert:equals:  it's just more typing than #= with no additional outcome

I disagree: it does make a real difference, it gives a much better error 
message, like 'got $A but expected $X', instead of 'something failed'.

> assertCollection:hasSameElements: 
> So, let's start by asking what the question really means. Does it mean that 
> one collection is a subset of the other? What about ordering then? Does it 
> mean both contain the same elements at the same position or just the fact 
> that if they both were Sets contained the exact same elements. The question 
> itself is not exact, so how could an answer possibly be?

I agree: it helps little. It is much clearer to write something like, for 
example,

self assert: result asOrderedCollection asSortedCollection equals: (1 to: 10) 
asOrderedCollection

because then you are very explicit about the test.

> Just a few weeks ago, we discussed something similar about the equality of 
> two Collections. Endless discussions where people try convince others that 
> their definition of equality and/or sameness is correct with no outcome.
> 
> To me, something like assertCollection:hasSameElements: means asking for 
> trouble, because each and every definition of what that may mean is 
> debatable. It's unwanted syntactic sugar (actually it's more like rat poison 
> than sugar).
> 
> So what we really need to do is find ways for SUnit to formulate exactly what 
> we mean and use these as helpers in the execution of a simple assert:. And 
> that is not by adding new variants of assert:
> Adding more and more methods to TestAsserter only makes the frustration with 
> such problems increase and people hat SUnit more and more.
> 
> So we need an extensible set of objects that, say, compare two collections 
> and return true or false. These can be used in an assertion but also in 
> domain code. We don't need more and more variations of assert:
> 
> So we could start by providing an abstract superclass for comparing 
> collections based on more than just #= and #==. Then we can add subclasses 
> for that which have a real intention revealing name like 
> CollectionHasExactlyTheSameElementsAsAnotherAtTheSamePosition.
> 
> Thinking about it, I even think that it really is a stupid idea. Because 
> chances are you need such a functionality in your domain code anyways (you'd 
> hardly need a test for it otherwise), so you most likely implement the very 
> same thing for exactly your purposes in your project. And since we always 
> write such a beast with lots of tests, we have a reliable and debate-free way 
> of what we really want SUnit to test for if we use that object or method in 
> our tests in a simple assert:
> 
> All I am saying is: please keep these highly fragile and debatable things out 
> of SUnit. It will cause  debates and frustration rather than improve people's 
> opinion of SUNit and Unit testing. It is counter-productive and will do harm 
> of all kinds.
> 
> Don't mistake the fact that some static languages had to add lots of assert: 
> variations due to their static typing limitation with an anticipation that 
> this might be a good idea. It's not.
> 
> Okay, I told you this is my destructive day, so you may shoot now ;-)
> 
> 
> Joachim
> 
> 
> 
> 
> 
> Am 24.10.15 um 22:14 schrieb Christophe Demarey:
>> Hi Peter,
>> 
>> Le 24 oct. 2015 à 20:36, Peter Uhnák a écrit :
>> 
>>> bump? :)
>>> 
>>> On Tue, Sep 29, 2015 at 12:57 AM, Peter Uhnák  wrote:
>>> How practical it is to do set-based comparison in 
>>> TestAsserter>>assertCollection:hasSameElements: ?
>>> 
>>> For example #(1 1 2) has same elements as #(1 2) which may make sense for 
>>> sets, but not for bags.
>>> 
>>> The main reason I was using it is that in tests the expected collection may 
>>> be created by hand,
>>> which means it is very often an array #(...), { ... }, while models very 
>>> often return OrderedCollections (at least in my case).
>> 
>> 
>> I introduced #assertCollection:hasSameElements:  for this reason.
>> The problem with using sets is that I do not expect that  #(1 1 2) has same 
>> elements as #(1 2)
>> 
>>> 
>>> So my question is --- how to compare collections irrespective of type, and 
>>> possibly of order?
>>> 
>>> A) always convert the actual collection toanArray
>>> 
>>> B) change difference: behavior for non-sets (ton of work with catastrophic 
>>> consequences)
>>> 
>>> C) extend TAssertable with new methods like 
>>> 
>>> #assertElementsOf: actualCollection equals: expectedCollection
>>> #assertUnorderedElementsOf: actualCollection equals: expectedCollection
>> 
>> This solution has my preference
>> 
>>> C.a) directly in Pharo/SUnit
>> 
>> yes

Re: [Pharo-users] [Pharo-dev] TestAsserter>>assertCollection:hasSameElements:

[jtuc...@objektfabrik.de]

Sorry guys, but today is my destructive day...


I think most of the assert:whatever: methods are a waste of time and 
energy and just pollute SUnit with lots of methods that are named with 
misleading or at best debatable names.


Examples:

assert:equals:  it's just more typing than #= with no additional outcome

assertCollection:hasSameElements:
So, let's start by asking what the question really means. Does it mean 
that one collection is a subset of the other? What about ordering then? 
Does it mean both contain the same elements at the same position or just 
the fact that if they both were Sets contained the exact same elements. 
The question itself is not exact, so how could an answer possibly be?


Just a few weeks ago, we discussed something similar about the equality 
of two Collections. Endless discussions where people try convince others 
that their definition of equality and/or sameness is correct with no 
outcome.


To me, something like assertCollection:hasSameElements: means asking for 
trouble, because each and every definition of what that may mean is 
debatable. It's unwanted syntactic sugar (actually it's more like rat 
poison than sugar).


So what we really need to do is find ways for SUnit to formulate exactly 
what we mean and use these as helpers in the execution of a simple 
assert:. And that is not by adding new variants of assert:
Adding more and more methods to TestAsserter only makes the frustration 
with such problems increase and people hat SUnit more and more.


So we need an extensible set of objects that, say, compare two 
collections and return true or false. These can be used in an assertion 
but also in domain code. We don't need more and more variations of assert:


So we could start by providing an abstract superclass for comparing 
collections based on more than just #= and #==. Then we can add 
subclasses for that which have a real intention revealing name like 
CollectionHasExactlyTheSameElementsAsAnotherAtTheSamePosition.


Thinking about it, I even think that it really is a stupid idea. Because 
chances are you need such a functionality in your domain code anyways 
(you'd hardly need a test for it otherwise), so you most likely 
implement the very same thing for exactly your purposes in your project. 
And since we always write such a beast with lots of tests, we have a 
reliable and debate-free way of what we really want SUnit to test for if 
we use that object or method in our tests in a simple assert:


All I am saying is: please keep these highly fragile and debatable 
things out of SUnit. It will cause  debates and frustration rather than 
improve people's opinion of SUNit and Unit testing. It is 
counter-productive and will do harm of all kinds.


Don't mistake the fact that some static languages had to add lots of 
assert: variations due to their static typing limitation with an 
anticipation that this might be a good idea. It's not.


Okay, I told you this is my destructive day, so you may shoot now ;-)


Joachim





Am 24.10.15 um 22:14 schrieb Christophe Demarey:

Hi Peter,

Le 24 oct. 2015 à 20:36, Peter Uhnák a écrit :


bump? :)

On Tue, Sep 29, 2015 at 12:57 AM, Peter Uhnák > wrote:


How practical it is to do set-based comparison
in TestAsserter>>assertCollection:hasSameElements: ?

For example #(1 1 2) has same elements as #(1 2) which may make
sense for sets, but not for bags.

The main reason I was using it is that in tests the expected
collection may be created by hand,
which means it is very often an array #(...), { ... }, while
models very often return OrderedCollections (at least in my case).




I introduced #assertCollection:hasSameElements:  for this reason.
The problem with using sets is that I do not expect that  #(1 1 2) has 
same elements as #(1 2)




So my question is --- how to compare collections irrespective of
type, and possibly of order?

A) always convert the actual collection toanArray

B) change difference: behavior for non-sets (ton of work with
catastrophic consequences)

C) extend TAssertable with new methods like

#assertElementsOf: actualCollection equals: expectedCollection
#assertUnorderedElementsOf: actualCollection equals:
expectedCollection



This solution has my preference


C.a) directly in Pharo/SUnit



yes, for me, it is a very basic assertion that should be available as 
default.



C.b) in independend SUnit-Extensions repository/project
C.c) just in my project

D) stop discussing non-problems

Thanks,
Peter




Christophe



--
---
Objektfabrik Joachim Tuchel  mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

Re: [Pharo-users] How to programatically select an item in a Spec TreeModel ?

[Thierry Goubier]

Le 24/10/2015 13:20, Ferlicot D. Cyril a écrit :

Le 24/10/2015 08:11, Peter Uhnák a écrit :

 Waiting for the FT-based rewrite is the thing to do.


If by waiting you mean doing FT-based rewrite, then sure. :)

Unless Cyril is going to do the rewrite himself.

P


Hi,

Create a FTTree should be my next work :)
I already begun a FTTree with one sublevel but this is only a first
shot. I think it's possible to do cleaner and faster.


With the FT core code, I'm having success mapping the tree to an array 
(i.e. providing an #at: anIndex) for the tree. But then, need to 
optimise #at: (or the FT code iterating over the tree with #at:).


Note that the widget should not have a knowledge of the tree depth (or 
the depth of an item of the tree). Otherwise the code becomes very 
complex (i.e. PluggableTreeMorph and MorphTreeMorph), for no good reason 
at all.


Enjoy your design ;)

Thierry