- Pharo-users - lists.pharo.org

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

by jtuchel＠objektfabrik.de

Hi Peter, I just realize it is probably best to return to your initial post in order to not drift into D) ;-) Am 24.10.15 um 20:36 schrieb Peter UhnÃ¡k: > 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). > > So my question is --- how to compare collections irrespective of > type, and possibly of order? > > A) always convert the actual collection toanArray > I don't think it is a good idea to provide tests fro general Collections that first convert it to some specialized Collection class. There may be nothing wrong with doing so, but it always depends on what exactly you want to test for. If converting to an Array is part of that test, the test is specialized and not for Collections in general. Seems to be an indication that your test is not a general Test on Collections... > B) change difference: behavior for non-sets (ton of work with > catastrophic consequences) > You name it ;-) > > C) extend TAssertable with new methods like > > #assertElementsOf: actualCollection equals: expectedCollection > #assertUnorderedElementsOf: actualCollection equals: > expectedCollection > These names (I know, they are just examples, so I don't pick on them specifically) are always open for interpretation. > C.a) directly in Pharo/SUnit > No. For several reasons: * The whole discussione we're having on this * SUnit is a framework that is cross-platform. You can never be completely sure that a certain method on a Collection class which is not in the ANSI standard gives you the same results on another Smalltalk > C.b) in independend SUnit-Extensions repository/project > A much better approach. But then we have a portability problem if things like extensions and method overrides come into play. So this requires architectural changes in SUnit to enable a plugin mechanism. That, btw, would be a great thing! > C.c) just in my project > This should surely be a starting point to stabilize things. If we had plugins, it would be easy to publish your stuf as plugin at any time. > > D) stop discussing non-problems > If you mean others think you should just shut up and you should just do it for yourself, then I think it is not a good option. I am quite sure your question shows that there is a problem with SUnit. Be it with Collections or any other area. SUnit started as something quick and dirty and thus is not perfect for many situations. We should look for patterns and solutions. I would definitely disagree if you suggest people might think your questions are a non-problem! Joachim -- ----------------------------------------------------------------------- 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. 26, 2015

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

by Sven Van Caekenberghe

> On 26 Oct 2015, at 09:09, Justine STIENNE <justine.stienne(a)gmail.com> wrote: > > Of course. Sorry to bother you but I'm a beginner. OK, no problem. You are mixing instance and class side. All your methods except #renderContentOn: should be on the class side. There should also be no super initialise on the class side. What book/tutorial are you following ? Standard Pharo books are at http://books.pharo.org You should make sure that you read and experiment with the first one. There is also the Seaside book. The learning curve in the beginning can be quite steep, depending on your background, nothing to worry about. > 2015-10-26 9:01 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Could you do a File Out of your WAHelloWorld class code and show us ? > > > On 26 Oct 2015, at 08:58, Justine STIENNE <justine.stienne(a)gmail.com> wrote: > > > > I have just done it. And now, on 'http://localhost:8080/config/hello' , I can choose 'a WAHelloWorld', but not 'WAHelloWorld'. > > When I go to 'http://localhost:8080/hello', I have : > > MessageNotUnderstood: WAHelloWorld>>new > > > > Your request could not be completed. An exception occurred. > > > > > > > > Thanks in advance, > > > > Justine > > > > > > > > 2015-10-25 20:03 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > 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 <justine.stienne(a)gmail.com> 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 <justine.stienne(a)gmail.com>: > > > 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 > > > > > > > > > > > > > > > > > > > <WAHelloWorld.st>

Oct. 26, 2015

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

by Justine STIENNE

Of course. Sorry to bother you but I'm a beginner. 2015-10-26 9:01 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Could you do a File Out of your WAHelloWorld class code and show us ? > > > On 26 Oct 2015, at 08:58, Justine STIENNE <justine.stienne(a)gmail.com> > wrote: > > > > I have just done it. And now, on 'http://localhost:8080/config/hello' , > I can choose 'a WAHelloWorld', but not 'WAHelloWorld'. > > When I go to 'http://localhost:8080/hello', I have : > > MessageNotUnderstood: WAHelloWorld>>new > > > > Your request could not be completed. An exception occurred. > > > > > > > > Thanks in advance, > > > > Justine > > > > > > > > 2015-10-25 20:03 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > 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 <justine.stienne(a)gmail.com> > 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 <justine.stienne(a)gmail.com > >: > > > 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. 26, 2015

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

by Sven Van Caekenberghe

Could you do a File Out of your WAHelloWorld class code and show us ? > On 26 Oct 2015, at 08:58, Justine STIENNE <justine.stienne(a)gmail.com> wrote: > > I have just done it. And now, on 'http://localhost:8080/config/hello' , I can choose 'a WAHelloWorld', but not 'WAHelloWorld'. > When I go to 'http://localhost:8080/hello', I have : > MessageNotUnderstood: WAHelloWorld>>new > > Your request could not be completed. An exception occurred. > > > > Thanks in advance, > > Justine > > > > 2015-10-25 20:03 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > 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 <justine.stienne(a)gmail.com> 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 <justine.stienne(a)gmail.com>: > > 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. 26, 2015

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

by Justine STIENNE

I have just done it. And now, on 'http://localhost:8080/config/hello' , I can choose 'a WAHelloWorld', but not 'WAHelloWorld'. When I go to 'http://localhost:8080/hello', I have : MessageNotUnderstood: WAHelloWorld>>new Your request could not be completed. An exception occurred. Thanks in advance, Justine 2015-10-25 20:03 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > 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 <justine.stienne(a)gmail.com> > 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 <justine.stienne(a)gmail.com>: > > 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. 26, 2015

Re: [Pharo-users] Pharo family update

by Serge Stinckwich

Great job ! This could be a great poster ;-) Maybe you have to put Pharo Logo in the middle and enhance the fonts of different topics in blue circle (Server, Data, etc ...) so the people can read them more easily. Regards, On Mon, Oct 26, 2015 at 1:23 AM, Adam <adam(a)234.cz> wrote: > Hello, > > next update. I tried to follow all sugestions - but not all is implemented > into drawings (maybe because I did not quite understand, or I did not found > enough information, or something like that). > > Pharo is mostly development platform, and image shows mostly libraries and > frameworks for development, but "Development" circle in the image is more > about tools primarly targeted to support process of development. So, if Gofer > and Metacello is not used for this purpose (maybe it is, I'm not sure), it > should be in "Working" circle. > > "Working" circle is mostly about tools and applications for "normal" people. > Maybe it should be named like: "Desktop"... > > "Server" circle is meant to show that Pharo itself can offer services to other > parties. > > Development/Working/Server are some kinde of trinity around it everyhing else > is rotating. But Pharo is more about Development so other circles are main > groups of libraries and frameworks. > > Adam > > Dne PÃ¡ 23. ÅÃjna 2015 23:58:48, Adam napsal(a): >> Hello, >> >> I just updated drawing of projects around Pharo. >> >> Main idea is to guide people (new users of Pharo) through fields of >> interests - something they might be looking for. I choose these 10 fields >> devided into some specific subjects. Somewhere it is too detailed, while >> elsewhere it is too fuzzy - it is just showing image of Pharo I have in my >> mind. >> >> It should help people to: >> - identify important classes in Pharo, >> - select right project, >> - understand what is application, tool or framework, >> - see what is allready inside main Pharo image. >> >> I would like to add links pointing to part of books or to videos where >> specific projects are used. And maybe a star symbol for very important or >> enterprise ready projects. >> >> As You can see I left few subjects empty. Maybe someone can help me fill >> this. But I will be happy for any type of correction - changing fields of >> interest, subjects, adding/removing projects etc... >> >> I prepared textual version on github - but right now it is not coherent with >> the drawing (I will correct this if needed). >> >> Adam. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Oct. 26, 2015

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

by jtuchel＠objektfabrik.de

Am 25.10.15 um 16:33 schrieb 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. > I'm sorry, but what you are saying doesn't make any sense. Even if I "only" want to test code (which is exactly what you do in TDD, btw.), I need good feedback. That is, btw., the reason why I suggested an extension to SUnit a few years ago that would help keep test results in a collection for use in CI environments. So I agree there is the problem of short and precise ways of giving precise and helpful feedback in SUnit. But solving this by adding more and more variants of assert: to the framework, just to give nicer error strings is like healing a headache by decapitating the patient. What is needed is some way to make providing feedback easier and friendlier, and we should think about ways to achieve that. Adding lots of sloppily-defined assertion methods is just the wrong solution. We could think about subclassing TestFailure and a way to hand information to the TestFailure so that a nice String can be produced. Like a method like cull: that adds arguments' printString representation into the failure description. > 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. Please step back for a second and think again: these are two very different things. The job of an Assertion is to make a problem visible. The representation of the problem is something else, even if these are closely related. This is object thinking lesson #2 or so. > > It is a world of difference. I agree. Good and exact feedback is at least as important as finding a problem. Because knowing there is a problem without understanding the problem is not enough. But that does not support the theory of "more assertion variants make our life so much easier". It only says we need a way to provide good feedback that is short and precise enough to not be ignored to our laziness. But: adding more and more misnamed and misleading assertion methods makes the use of SUnit frustrating and will make it obsolete over time. If I have to hunt for design problems in SUnit because it assumes something to be wrong even though my understanding of waht I tested is different, I lose way more time than I am ready to accept. This doesn't happen to me often. If finding that I misunderstood an assertion method means I lost a few hours, the best thing that may happen is that I never use that method again. In the worst case, I decide I think SUnit is useless for me. That would be really bad, don't you think? > > > 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. Sorry to say that, but this is ambiguity by design: you define hasSameElements: as "both result in the same Set". So the name of this assertion method is a great example of bad naming, IMO. > 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. This is just nonsense. You name a method after a general collection class and try to tell me that it doesn't matter that it is only suitable for Sets and that is okay? > 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 {} ). > I don't really care. If what you try t say is that the testing code can be ugly and long, then I agree. If you need tests like this very often and want something to make this easier, I understand and agree that some additions to SUnit can be helpful. But the way this has been tried so far seems completely wrong to me. > > 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 what, again, was the point of naming a method after a general Collection class and use a question that is very unspecific? A Collection has the same elements as another does not necessarily mean they both result in the same set. Can we agree on that? All the question asks if all Elements in Collection A can also be found in Collection B. The method name states nothing more than that. > > 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. This is a misconception we also discussed in this other discussion. It simply isn't true. And even if it was true, it still wouldn't match with the chosen method name. My point here is that a general purpose framework like SUnit should be free of such debatable things. SUnit has to be reliable and understandable. There is nothing wrong with providing some "plugins" for problems like Collections that make life easier. It would be desirable to have more control over SUnit's feedback with little typing. But there is a lot that's wrong in polluting a general purpose framework like SUnit with unclear method names that are misleading, just plain wrong or debatable. So we are discussing existing, real problems that exist in SUnit, and we are discussing about one of the possible ways to make SUnit friendlier that - in my opinion - is counter-productive. > > please keep these highly fragile > > why is it fragile? Because my misunderstanding of what the author of assertCollection:hasSameElementsAs: thought the question means can cause me a hunt for bugs in his misnaming rather than my code. I may throw SUnit into the corner or just not trust in it. That's fragile, not agile. > and debatable things > > that's why I initiated this debate in the first place. Which is a good thing and I hope I could explain exactly enough why I think the addition of more and more assert: variations for the sake of better failure texts is the wrong path. We should look for better, more precise ways to achieve what is needed. One step, IMO, is to agree on the fact that formulating an assertion and providing a helpful failure text are two strongly-related, but separate concerns. So a redesign of SUnit should be based on the question of how we can extend the feedback providing side of SUnit, and not on the question of what else people might be testing for and what the resulting text should be looking like and then find the best possible assertion method name based on that. By writing this last sentence, I found another argument: not only teh new assertion method name could be misleading and debatable, but also the failure text you provide in the SUNit code base. This adds a third level of problems. What if your failure text was just "Not all Elements of $A are in $B" - does it match your implementation? I think it matches the method name, but not your implementation... Nuff said, Joachim -- ----------------------------------------------------------------------- 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. 26, 2015

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

by jtuchel＠objektfabrik.de

Hi Sven, Am 25.10.15 um 11:45 schrieb 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'. 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: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. 26, 2015

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

by Eliot Miranda

Hi Alexandre, On Fri, Oct 23, 2015 at 2:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> 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

Oct. 26, 2015

Re: [Pharo-users] Pharo family update

by Adam

Hello, next update. I tried to follow all sugestions - but not all is implemented into drawings (maybe because I did not quite understand, or I did not found enough information, or something like that). Pharo is mostly development platform, and image shows mostly libraries and frameworks for development, but "Development" circle in the image is more about tools primarly targeted to support process of development. So, if Gofer and Metacello is not used for this purpose (maybe it is, I'm not sure), it should be in "Working" circle. "Working" circle is mostly about tools and applications for "normal" people. Maybe it should be named like: "Desktop"... "Server" circle is meant to show that Pharo itself can offer services to other parties. Development/Working/Server are some kinde of trinity around it everyhing else is rotating. But Pharo is more about Development so other circles are main groups of libraries and frameworks. Adam Dne PÃ¡ 23. ÅÃjna 2015 23:58:48, Adam napsal(a): > Hello, > > I just updated drawing of projects around Pharo. > > Main idea is to guide people (new users of Pharo) through fields of > interests - something they might be looking for. I choose these 10 fields > devided into some specific subjects. Somewhere it is too detailed, while > elsewhere it is too fuzzy - it is just showing image of Pharo I have in my > mind. > > It should help people to: > - identify important classes in Pharo, > - select right project, > - understand what is application, tool or framework, > - see what is allready inside main Pharo image. > > I would like to add links pointing to part of books or to videos where > specific projects are used. And maybe a star symbol for very important or > enterprise ready projects. > > As You can see I left few subjects empty. Maybe someone can help me fill > this. But I will be happy for any type of correction - changing fields of > interest, subjects, adding/removing projects etc... > > I prepared textual version on github - but right now it is not coherent with > the drawing (I will correct this if needed). > > Adam.

Oct. 26, 2015