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

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

by 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 <sven(a)stfx.eu>: > Hi, > > > On 25 Oct 2015, at 18:46, Justine STIENNE <justine.stienne(a)gmail.com> > 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 > >

Oct. 25, 2015

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

by Sven Van Caekenberghe

Hi, > On 25 Oct 2015, at 18:46, Justine STIENNE <justine.stienne(a)gmail.com> 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

Oct. 25, 2015

Problem to connect Seaside and Pharo

by 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

Oct. 25, 2015

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

by 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 <i.uhnak(a)gmail.com> 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 <kilon.alios(a)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. >> > >

Oct. 25, 2015

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

by Nicolai Hess

2015-10-25 13:55 GMT+01:00 Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net> : > 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-… >> >> 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 >> > > >

Oct. 25, 2015

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

by 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 <kilon.alios(a)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. >

Oct. 25, 2015

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

by 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/YYYY" 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

Oct. 25, 2015

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

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

Oct. 25, 2015

A stopwatch tool with calendar support

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

Oct. 25, 2015

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

by Sven Van Caekenberghe

> On 25 Oct 2015, at 11:37, jtuchel(a)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 <i.uhnak(a)gmail.com> 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:jtuchel@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 > >

Oct. 25, 2015