October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] [ANN] Test Coverage with Hapao

by Pavel Krivanek

Hi Alexandre, I would like to see Hapao to be used for coverage testing of the Pharo kernel classes. I checked that it is possible run it on Pharo-minimal: wget http://files.pharo.org/image/40/latest-minimal.zip unzip latest-minimal.zip ./pharo config http://smalltalkhub.com/mc/Pharo/SystemConfigurations/main ConfigurationOfSUnit --group=Core,Tests --install=bleedingEdge ./pharo Pharo-minimal hapao.st where hapao.st loads S2py and Fuel, runs the analysis and exports result to the a Fuel file: Gofer new smalltalkhubUser: 'ObjectProfile' project: 'S2py'; package: 'S2py'; load. Gofer new smalltalkhubUser: 'Pharo' project: 'Pharo40'; package: 'Fuel'; load. ! FLSerializer serialize: (Hapao2 runTestsForClasses: {SUnitTest }) toFileNamed: 'hapao.fuel'. Smalltalk exitSuccess. The result can be loaded to the full image with Roassal: (FLMaterializer materializeFromFileNamed: 'hapao.fuel' ) visualize. It would be great if you will extract all visualisaton code and MessageTally extensions from the S2py package. What are the limitations of Hapao for testing of the core classes? Cheers, -- Pavel 2014-10-07 16:06 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > Thanks Maximiliano for your kind words. > > Regarding your particular menu entry, I guess I understand well how you did > it. No need to share it with me then. > > Let us know how to adapt Hapao. We will improve it. For example, the small > window popup at the bottom of the window is not that useful. We will fix > this... > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Oct 6, 2014, at 12:49 PM, Maximiliano Taborda <mtaborda(a)gmail.com> wrote: > > Hi Alexandre. > > Perfect about the legends problem. Thanks. > > And about the best way to exclude some methods, I don't know what it is. I > use the world menu to run Hapao. In fact, I made a new entry in the world > menu that fit with my needs, that is: > - excludes all initialization methods, i.e. selectors named like > #initialize* > - excludes all the #new methods > - excludes all methods that are defined in a protocol named as private, > i.e. 'accessing - private' > This new entry checks the coverage over a class/es hierarchy and, also, > - run only the tests related to this hierarchy > - not take into account the abstract methods when computing the covered > percentage; if I have an abstract method without a concrete one implemented > in all the subclasses, I have a design error, so my real problem is the > absence of the concrete method and not the absence of the test. > > If you are interested I leave you attached to this email the code related to > this entry. Maybe is not the best way to implement what I need, but is a > quickly one. > > Congratulations for this tool, is great to easily visualize what portion of > my model are not covered by tests. > > Regards. > Maximiliano > > > > 2014-10-05 22:27 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >> >> Hi Maximiliano! >> >> The legend problem is now fixed. Can you double check please? >> >> What would be the best way to exclude some methods? This question slightly >> rephrased: how do you run Hapao? Programmatically or using the World menu? >> >> Cheers, >> Alexandre >> >> >> On Oct 2, 2014, at 11:34 PM, Maximiliano Taborda <mtaborda(a)gmail.com> >> wrote: >> >> > Hi Alexandre. >> > >> > Yes, now it works. Thank you. But, the box with the legends don't show >> > very well. Like in the attached image: >> > >> > <RelativeDate.png> >> > >> > And, a question. Is there a way to exclude some methods from the >> > analysis? I have some class methods, used for initialize some singletons for >> > example, that I do not want to be considered for coverage. >> > >> > Regards. >> > Maxi >> > >> > 2014-10-02 18:39 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >> > Hi! >> > >> > Sorry, we somehow slightly messed up with the configurations. >> > I just took the last Pharo 4.0, and loaded Roassal2: >> > >> > -=-=-=-=-=-=-=-=-=-=-=-= >> > Gofer new smalltalkhubUser: 'ObjectProfile' >> > project: 'Roassal2'; >> > package: 'ConfigurationOfRoassal2'; >> > load. >> > (Smalltalk at: #ConfigurationOfRoassal2) loadDevelopment >> > -=-=-=-=-=-=-=-=-=-=-=-= >> > >> > Then I loaded S2py: >> > -=-=-=-=-=-=-=-=-=-=-=-= >> > Gofer new smalltalkhubUser: 'ObjectProfile' >> > project: 'S2py'; >> > package: 'S2py'; >> > load. >> > -=-=-=-=-=-=-=-=-=-=-=-= >> > >> > It works here. >> > Can you confirm? >> > >> > Sorry for having taken long to answer... >> > >> > Cheers, >> > Alexandre >> > >> > On Sep 24, 2014, at 8:24 PM, Maximiliano Taborda <mtaborda(a)gmail.com> >> > wrote: >> > >> > > Hi Alexandre, >> > > >> > > I want to try Hapao2 to check the coverage level of Chalten, but it's >> > > not working (at least for me). >> > > I load Roassal2 and S2py in a fresh 3.0 image like you say and the new >> > > entries appear in the world menu, but the only option that partially works >> > > is the one for a particular class (Hapao @ Class ...) and after run all the >> > > tests (I see the progress showing that) a MNU is raised in the method >> > > #addMethodEdges:scope:view: of Hapa2 class because RTEdgeBuilder is not >> > > loaded. >> > > >> > > So, could you tell me what I missed please? I need to load another >> > > thing, which?, at least the package which defines RTEdgeBuilder. >> > > >> > > Thanks for your help. >> > > >> > > Regards. >> > > Maxi >> > > >> > > 2014-09-16 20:10 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >> > > Excellent! >> > > >> > > Alexandre >> > > >> > > Le 16-09-2014 Ã 16:15, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >> > > >> > >> Great! >> > >> >> > >> I will go over it more thoroughly in the following weeks and get back >> > >> to you with feedback. >> > >> >> > >> Cheers, >> > >> Doru >> > >> >> > >> >> > >> >> > >> On Tue, Sep 16, 2014 at 6:03 PM, Alexandre Bergel >> > >> <alexandre.bergel(a)me.com> wrote: >> > >> Dear all, >> > >> >> > >> We are happy to release Hapao2 for Pharo. Ricard Jacas and Alejandro >> > >> Infante put quite some work on Spy2 (an Ã¼ber cool profiling framework for >> > >> Pharo) and Hapao2. >> > >> Hapao2 is about assessing the test coverage of your code and is a >> > >> major revamp of Hapao1, which was presented a couple of years ago by >> > >> Vanessa. >> > >> Hapao2 does not only list covered and uncovered methods, as most test >> > >> coverage tool on Earth will do. Hapao gives a great visualization to easily >> > >> navigate in your code, assess its complexity, and give you a great visual >> > >> output telling its coverage. >> > >> >> > >> You need Roassal in your image: >> > >> >> > >> Gofer new smalltalkhubUser: 'ObjectProfile' >> > >> project: 'Roassal2'; >> > >> package: 'ConfigurationOfRoassal2'; >> > >> load. >> > >> (Smalltalk at: #ConfigurationOfRoassal2) load >> > >> >> > >> >> > >> and you need S2py: >> > >> MCHttpRepository >> > >> location: 'http://smalltalkhub.com/mc/ObjectProfile/S2py/main' >> > >> user: '' >> > >> password: '' >> > >> >> > >> >> > >> New entries will appear in the world menu: >> > >> <Screen Shot 2014-09-16 at 11.49.06 AM.png> >> > >> >> > >> You can run the test coverage on : >> > >> - the class classes you have modified, >> > >> - on a particular >> > >> - on a particular class category >> > >> - on the last class categories you have modified >> > >> - on the last packages you have modified >> > >> >> > >> Here is a portion of a large coverage: >> > >> >> > >> <Screen Shot 2014-09-16 at 12.00.11 PM.png> >> > >> >> > >> A technical description of Hapao may be found on >> > >> http://bergel.eu/download/papers/Berg12c-HapaoSCP.pdf >> > >> >> > >> We are daily using Hapao to help us understand our tests. >> > >> >> > >> Cheers, >> > >> Ricardo, Alejandro & Alexandre >> > >> -- >> > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > >> Alexandre Bergel http://www.bergel.eu >> > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> >> > >> >> > >> >> > >> >> > >> _______________________________________________ >> > >> Moose-dev mailing list >> > >> Moose-dev(a)iam.unibe.ch >> > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > >> >> > >> >> > >> >> > >> >> > >> -- >> > >> www.tudorgirba.com >> > >> >> > >> "Every thing has its own flow" >> > > >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > <S2py-MaximilianoTaborda.73.mcz> > >

Oct. 10, 2014

Re: [Pharo-dev] OSProcess in 3.0

by David T. Lewis

> Le 10/10/2014 17:52, David T. Lewis a Ã©crit : >>> 2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: >>> >>>> >>>> Right. But please do test it in your applications to be sure, I really >>>> only >>>> did simple testing and I am sure there may still chances for problems >>>> in >>>> this area. >>>> >>> >>> Hi Dave, >>> >>> Would it has a chance of slowing down things a lot? >>> >>> There is apparently something going very very slow compared to >>> OSProcess >>> 4.5.11 when used from GitFileTree. So slow that I killed the image >>> building >>> script before it was over. Reverting GitFileTree to 4.5.11 solved it. >>> >> >> I don't this so, but I am not certain. The update for PipeableOSProcess >> affects only the methods in PipeableOSProcess class>>command: and >> closely >> related methods. If GitFileTree is using that idiom, then it is >> certainly >> possible that I have introduced a bug that does not show up in my unit >> tests. > > Typical code in GitFileTree is this: > > [ > c := PipeableOSProcess command: ''. > output := c output. > ... > ] ensure: [c closePipes] > > Maybe it's triggering something. > > Thierry > Hmmm... I wonder if the #closePipes is causing a problem now. I don't know if I ever tested to see if sending closePipes works after the pipes are already closed, and my recent change closes the pipes after #output is evaluated. I'll check it when I get home. Thanks, Dave

Oct. 10, 2014

Re: [Pharo-dev] OSProcess in 3.0

by Thierry Goubier

Le 10/10/2014 17:52, David T. Lewis a Ã©crit : >> 2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: >> >>> >>> Right. But please do test it in your applications to be sure, I really >>> only >>> did simple testing and I am sure there may still chances for problems in >>> this area. >>> >> >> Hi Dave, >> >> Would it has a chance of slowing down things a lot? >> >> There is apparently something going very very slow compared to OSProcess >> 4.5.11 when used from GitFileTree. So slow that I killed the image >> building >> script before it was over. Reverting GitFileTree to 4.5.11 solved it. >> > > I don't this so, but I am not certain. The update for PipeableOSProcess > affects only the methods in PipeableOSProcess class>>command: and closely > related methods. If GitFileTree is using that idiom, then it is certainly > possible that I have introduced a bug that does not show up in my unit > tests. Typical code in GitFileTree is this: [ c := PipeableOSProcess command: ''. output := c output. ... ] ensure: [c closePipes] Maybe it's triggering something. Thierry

Oct. 10, 2014

Re: [Pharo-dev] [ANN] flow: a living full-stack #âframework for the web

by Sebastian Sastre

On Oct 10, 2014, at 11:16 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > sebastian(a)flowingconcept.com wrote >> Your thoughts and further questions are welcomed > > "How does it compare to Tide" seems like a popular question ;) > Card for that here: https://trello.com/c/nCzIHxc9/49-how-does-it-flow-compare-to-tide > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ANN-flow-a-living-full-stack-framework-for-the-web-tp… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 10, 2014

Re: [Pharo-dev] OSProcess in 3.0

by David T. Lewis

> 2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: > >> >> Right. But please do test it in your applications to be sure, I really >> only >> did simple testing and I am sure there may still chances for problems in >> this area. >> > > Hi Dave, > > Would it has a chance of slowing down things a lot? > > There is apparently something going very very slow compared to OSProcess > 4.5.11 when used from GitFileTree. So slow that I killed the image > building > script before it was over. Reverting GitFileTree to 4.5.11 solved it. > I don't this so, but I am not certain. The update for PipeableOSProcess affects only the methods in PipeableOSProcess class>>command: and closely related methods. If GitFileTree is using that idiom, then it is certainly possible that I have introduced a bug that does not show up in my unit tests. > The absence of the AioPlugin warning may also be problematic, since it > appears on stdout or stderr when Pharo is used on the command line. > Yes I should get rid that annoyance. Thanks, Dave > Thierry > > >> >> > >> > Also, I see that there is apparently no AioPlugin support in Pharo >> 3.0. >> Or >> > so say the tests of OSProcess. >> > >> > What is the state of affairs there? >> > >> >> Ask someone to include AioPlugin in the VM builds. >> >> Dave >> >> >> >

Oct. 10, 2014

Re: [Pharo-dev] OSProcess in 3.0

by phil＠highoctane.be

Yes, the AioPlugin warning is annoying. The lack of it also, for a number of use cases I am currently on. Phil On Fri, Oct 10, 2014 at 5:04 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: > >> >> Right. But please do test it in your applications to be sure, I really >> only >> did simple testing and I am sure there may still chances for problems in >> this area. >> > > Hi Dave, > > Would it has a chance of slowing down things a lot? > > There is apparently something going very very slow compared to OSProcess > 4.5.11 when used from GitFileTree. So slow that I killed the image building > script before it was over. Reverting GitFileTree to 4.5.11 solved it. > > The absence of the AioPlugin warning may also be problematic, since it > appears on stdout or stderr when Pharo is used on the command line. > > Thierry > > >> >> > >> > Also, I see that there is apparently no AioPlugin support in Pharo 3.0. >> Or >> > so say the tests of OSProcess. >> > >> > What is the state of affairs there? >> > >> >> Ask someone to include AioPlugin in the VM builds. >> >> Dave >> >> >> >

Oct. 10, 2014

Re: [Pharo-dev] OSProcess in 3.0

by Thierry Goubier

2014-10-10 14:09 GMT+02:00 David T. Lewis <lewis(a)mail.msen.com>: > > Right. But please do test it in your applications to be sure, I really only > did simple testing and I am sure there may still chances for problems in > this area. > Hi Dave, Would it has a chance of slowing down things a lot? There is apparently something going very very slow compared to OSProcess 4.5.11 when used from GitFileTree. So slow that I killed the image building script before it was over. Reverting GitFileTree to 4.5.11 solved it. The absence of the AioPlugin warning may also be problematic, since it appears on stdout or stderr when Pharo is used on the command line. Thierry > > > > > Also, I see that there is apparently no AioPlugin support in Pharo 3.0. > Or > > so say the tests of OSProcess. > > > > What is the state of affairs there? > > > > Ask someone to include AioPlugin in the VM builds. > > Dave > > >

Oct. 10, 2014

Re: [Pharo-dev] https://ci.inria.fr/pharo-contribution down

by Yuriy Tymchuk

Up now. Thanks :) > On 10 Oct 2014, at 16:54, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Can someone restart it? >

Oct. 10, 2014

https://ci.inria.fr/pharo-contribution down

by Yuriy Tymchuk

Can someone restart it?

Oct. 10, 2014

Re: [Pharo-dev] About ways to participate in community and general negativity

by Tim Mackinnon

Hi guys - this was an interesting thread - and exactly the reason why I brought up âZapp Empowermentâ at ESUG this year. I felt the passion from every single one of you - and in fact, everyone had an interesting point to make. I got a bit nervous as I worked up the 40+ replies, but I was pleased that no-one seemed to take great offence as we covered a wide range of related ideas. If I could make one small comment - sometimes I think the gems in a reply can easily get lost if you donât pay special attention to how the person(s) reading it might react. I think we all agree that we do like this community and the amazing work it has done (and continues to do) - and so its worth acknowledging someoneâs ideas and then building on them. If you disagree with them however - try acknowledging what they have said and then suggest that there is an equally valid point of view/idea that they can also consider. But Iâm also glad we arenât afraid to cover difficult conversations. I do think we can all practice giving and receiving feedback in a way that can keep the energy high. Personally I really like that many of the old things are being modernised (GT Inspector blew me away - as it has done for colleagues who donât even use Smalltalk). Equally, finding a way to get some community input via a survey/vote sounds quite interesting to prioritise a few things (possibly not for everything - as we are asking people to invest their spare time and energy on a labor of love - so we should go where the energy is). Equally, anything we can do to help keep the engineering high is equally appreciated - and I have seen it get better and better over the years. Tim On 3 Oct 2014, at 12:44, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Iâm writing this because Iâm sad about what is happening in this list. > Iâm seeing a lot of general negativity and non constructive ways to discuss things. > Iâm also seeing more and more people using Pharo for their particular interests (which is of course a good thing) but less and less people who contribute back to Pharo. > Finally, Iâm seeing more frequently an attitude of âcustomerâ, more than the conviction than this, Pharo, is also yoursâ¦ > > Please people, we (the pharo âcoreâ team) cannot do everything. We do not have the manpower or the resources to hire manpower. We would like, but we just do not have the resources (is already a blessing that we can work on this, for now: INRIA is paying, but what it pays is *research*, not âpharo the languageâ, so this is a collateral advantageâ¦.) > > So, having an OPEN SOURCE project, with limited resources means that there is a lot of things that depend on the community. > It depends on the community not just to fix, but to enlarge the ecosystem in general too. > > So, I refuse to believe that we cannot be a cool and helpful community. > I refuse to believe that general negativity and bad humor can overcome the joy of participating in this collective effort. > > So, here some recommendations for enhance the way we participate: > > - Be positive. Just âthis is a s**tâ does not help. Even if it is. > - Be propositional. Just âthis is a s**tâ, and not telling what you want/prefer does not help. > - Be proactive. Just âthis is a s**tâ, and not report, discuss and (at least time to time) provide a fix/enhancement does not help. > > In conclusion: not helping does not help :) > After all, this is the âpharo-devâ list. I mean, the list of people wanting to participate from this great, community effort. > > cheers, > Esteban, still grateful of belonging to this community > > >

Oct. 10, 2014