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

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

by jtuchel＠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 <i.uhnak(a)gmail.com >> <mailto:i.uhnak@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

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

by 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

Oct. 25, 2015

Re: [Pharo-users] VM crash on Ubuntu 14.04

by Nicolai Hess

Can you provide the image file. What exactly runs in the image (does it depend on ROS or does it crash even without it). For what do you use Roassal in this environment. Can you reproduce the crash with a clean image (and maybe loading some package - without all of the ROS-stuff? (I just followed the installation guide for PhaROS, but I have no idea how to go from here to do anything to reproduce the crash). 2015-10-24 21:32 GMT+02:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > > Ben, thanks for replying but since no VM guys are following up on this, > apparently, it does not make much sense for me to go this way. > > Guys, am I to assume there is not help for me on this topic? > > > On Oct 23, 2015, at 11:03, Ben Coman <btc(a)openInWorld.com> wrote: > > > > On Thu, Oct 22, 2015 at 2:25 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> > wrote: > >> Hi all, > >> > >> I am having some unpleasant experiences on Ubuntu 14.04 (experimenting > with Live Robot Programming on PhaROS). The VM crashes after a random > amount of time (< 25 minutes), with no clear sequence of steps on how to > reproduce the crash. I am using Pharo 4 (Pharo 40622 as installed by > PhaROS) + Roassal which required an install of libcairo2:i386 . VM version > details below. > >> > >> There is no printout on stdout, and the debug.log does not contain > recent entries (timestamp is always some minutes before the actual crash > happens). > >> > >> Is this a known problem? If so, how can I fix it, and if not how can I > provide more debugging info? > >> > >> Thanks in advance! > > > > I'm not much help since I haven't done these myself, but just some > > ideas (maybe someone can add more details) > > * compile and run a debug vm > > * trace all function calls, http://tinyurl.com/gdb-trace-all > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University > of Chile > > >

Oct. 24, 2015

Re: [Pharo-users] fast subclassing/class creation in tests

by Robert Withers

Extend Pharo byte codes to support Newspeak namespaces. #justsayin --- robert > On Oct 24, 2015, at 6:22 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > You can wrap the subclassing and the \removeFromSystem with > SystemAnnouncer uniqueInstance suspendAllWhile: [ ] > > 2015-10-24 20:43 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> Hi, >> >> is it possible to do fast, non-system wide class subclassing in tests? >> >> Currently I would do something like >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> MyTest>>testSomething >> cls := SomeParent subclass: #Something. >> "... do some tests ..." >> cls removeFromSystem >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> This is for example what ClassTest is doing. >> >> However this is very slow, and even for small tests suite --- just ten (so far) test methods it takes over ten seconds to test it all, which is quite bad for TDD. >> >> My guess is that since it has to write to class to the environment and disk and then remove it it takes a while: >> >> ~~~~~~~~~~~~~ >> [ Object subclass: #Something ] timeToRun. "0:00:00:00.021" >> [ #Something asClass removeFromSystem ] timeToRun. "0:00:00:00.526" >> ~~~~~~~~~~~~~ >> >> is it possible to speed it up? Create classes that are fast to remove? >> >> Thanks, >> Peter >

Oct. 24, 2015

Re: [Pharo-users] fast subclassing/class creation in tests

by Nicolai Hess

You can wrap the subclassing and the \removeFromSystem with SystemAnnouncer uniqueInstance suspendAllWhile: [ ] 2015-10-24 20:43 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > is it possible to do fast, non-system wide class subclassing in tests? > > Currently I would do something like > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > MyTest>>testSomething > cls := SomeParent subclass: #Something. > "... do some tests ..." > cls removeFromSystem > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > This is for example what ClassTest is doing. > > However this is very slow, and even for small tests suite --- just ten (so > far) test methods it takes over ten seconds to test it all, which is quite > bad for TDD. > > My guess is that since it has to write to class to the environment and > disk and then remove it it takes a while: > > ~~~~~~~~~~~~~ > [ Object subclass: #Something ] timeToRun. "0:00:00:00.021" > [ #Something asClass removeFromSystem ] timeToRun. "0:00:00:00.526" > ~~~~~~~~~~~~~ > > is it possible to speed it up? Create classes that are fast to remove? > > Thanks, > Peter >

Oct. 24, 2015

Re: [Pharo-users] Pharo family update

by Adam

Wow, thanks for great feedback to everyone. I will try to modify drawings by your sugestions. Here is few questions: - Aida web framework is ready for Pharo? In Pharo Catalog it is labeled as unstable. - FFI by this: http://stackoverflow.com/questions/30322445/pharo-4-ffi-current-state-and-t… have more implementations - which one I should put into drawing? - Event framework is complete framework? I found EventRecorder and EventModel. Aren't events part of Morphic? Adam Dne So 24. ÅÃjna 2015 13:30:25, Ferlicot D. Cyril napsal(a): > Le 24/10/2015 09:27, stepharo a Ã©crit : > > Superb! Really nice > > Margritte -> Magritte > > Mondorian -> Mondrian > > > > to add > > > > Never heard about PharoLink but you should have Garage (a database > > generic API) > > > > You could add MongoTalk close to Voyage > > > > GLORP > > > > Relational > > Mapper > > > > Woden 3D > > Roassal3D > > > > Omnibrowser is deprecated > > > > I would put STON close to Fuel > > May be you should move closer the two spots: import/export and data > > > > Tide is not developed anymore so I would remove it > > Add Reef instead (Javascript-enabled Web components) > > > > About Graphics > > > > you should have > > > > Athens (Vector graphics API) > > Bloc (new generation Morphic) > > Brick (new generation widgets) > > Hi, > > I do not agree to add Reef, Bloc and Brick now if this map is for beginners. > If this map is for beginners that need a framework we should wait to have a > usable version with documentation. > I think Bloc and Brick are not finish yet (I think) and reef lack > documentation/tutorial. > > If a beginner see it on the map and test it he will have a bad first > impression. And first impression count. > > This project should be on a waiting list the time there are stable and > documented I think. But this is just my opinion.

Oct. 24, 2015

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

by 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

Oct. 24, 2015

Re: [Pharo-users] VM crash on Ubuntu 14.04

by Robert Withers

Posting to Pharos-dev or Vm Dev may find you more assistance. My suggestions would be: a) upgrade to Pharo 5 and b) run in gdb so we all can be better informed about the issue you are seeing. Is PhaROS doing low level calls? --- robert > On Oct 24, 2015, at 3:32 PM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > > Ben, thanks for replying but since no VM guys are following up on this, apparently, it does not make much sense for me to go this way. > > Guys, am I to assume there is not help for me on this topic? > >> On Oct 23, 2015, at 11:03, Ben Coman <btc(a)openInWorld.com> wrote: >> >> On Thu, Oct 22, 2015 at 2:25 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >>> Hi all, >>> >>> I am having some unpleasant experiences on Ubuntu 14.04 (experimenting with Live Robot Programming on PhaROS). The VM crashes after a random amount of time (< 25 minutes), with no clear sequence of steps on how to reproduce the crash. I am using Pharo 4 (Pharo 40622 as installed by PhaROS) + Roassal which required an install of libcairo2:i386 . VM version details below. >>> >>> There is no printout on stdout, and the debug.log does not contain recent entries (timestamp is always some minutes before the actual crash happens). >>> >>> Is this a known problem? If so, how can I fix it, and if not how can I provide more debugging info? >>> >>> Thanks in advance! >> >> I'm not much help since I haven't done these myself, but just some >> ideas (maybe someone can add more details) >> * compile and run a debug vm >> * trace all function calls, http://tinyurl.com/gdb-trace-all > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > >

Oct. 24, 2015

Re: [Pharo-users] VM crash on Ubuntu 14.04

by Johan Fabry

Ben, thanks for replying but since no VM guys are following up on this, apparently, it does not make much sense for me to go this way. Guys, am I to assume there is not help for me on this topic? > On Oct 23, 2015, at 11:03, Ben Coman <btc(a)openInWorld.com> wrote: > > On Thu, Oct 22, 2015 at 2:25 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: >> Hi all, >> >> I am having some unpleasant experiences on Ubuntu 14.04 (experimenting with Live Robot Programming on PhaROS). The VM crashes after a random amount of time (< 25 minutes), with no clear sequence of steps on how to reproduce the crash. I am using Pharo 4 (Pharo 40622 as installed by PhaROS) + Roassal which required an install of libcairo2:i386 . VM version details below. >> >> There is no printout on stdout, and the debug.log does not contain recent entries (timestamp is always some minutes before the actual crash happens). >> >> Is this a known problem? If so, how can I fix it, and if not how can I provide more debugging info? >> >> Thanks in advance! > > I'm not much help since I haven't done these myself, but just some > ideas (maybe someone can add more details) > * compile and run a debug vm > * trace all function calls, http://tinyurl.com/gdb-trace-all > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Oct. 24, 2015

fast subclassing/class creation in tests

by Peter UhnÃ¡k

Hi, is it possible to do fast, non-system wide class subclassing in tests? Currently I would do something like ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MyTest>>testSomething cls := SomeParent subclass: #Something. "... do some tests ..." cls removeFromSystem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is for example what ClassTest is doing. However this is very slow, and even for small tests suite --- just ten (so far) test methods it takes over ten seconds to test it all, which is quite bad for TDD. My guess is that since it has to write to class to the environment and disk and then remove it it takes a while: ~~~~~~~~~~~~~ [ Object subclass: #Something ] timeToRun. "0:00:00:00.021" [ #Something asClass removeFromSystem ] timeToRun. "0:00:00:00.526" ~~~~~~~~~~~~~ is it possible to speed it up? Create classes that are fast to remove? Thanks, Peter

Oct. 24, 2015