February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Good reference on time on unit testing?

by Schwab,Wilhelm K

Norbert, Excellent points - I take exception with only one: you assume that all developers test - that is sadly not true. I am involved with a group who seem to think that a handful of tests added at the last minute will somehow magically fix their problems. I have no problem arguing that testing (if done well) can/will reduce overall development time; the question is how much of that time one should expect to devote to writing and maintaining unit and acceptance tests? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Norbert Hartl [norbert(a)hartl.name] Sent: Sunday, February 27, 2011 5:41 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Good reference on time on unit testing? Hi, On 27.02.2011, at 04:52, Schwab,Wilhelm K wrote: > Hello all, > > Can anyone recommend a good reference on the amount of time one should expect to spend writing tests? I will have to be the messenger (will be wearing running shoes just in case...), but I want the message to come from a solid source. I find that really hard to answer. To me the problem is the question itself. I heard the "..amount of time one should expect to spend writing tests?" so often in companies and I think it was always exactly this phrase. While the question is valid it gives the impression there is something that decucts time from your "normal" development work. So the people that are asking this question are often managing people that have read something about code quality and they want to apply _this_ to their teams. The definition over time is troublesome, too. Testing is not easy. Everything you read about testing gives you the impression that everyone knows how to test and that those developers are just too lazy. And that is not true. Most developers I met had problems to see what testing is all about. The don't see interfaces as provable promises etc. So if you tell any of these developers they should spend 1 hour a day in testing than you will get tests that are counter-productive. My favorite example is the one where you have any composite object with an add method. Than the test goes like adding something via the interface and then try to access the internal array and check if it is of size 1. To me it is the same as with documentation. I prefer to have less documentation than useless documentation. So every developer is testing in some way. You either test and debug on the way in an unstructured form or you write tests. To me writing tests is not an add-on it is a change in working style. From this point of view I would state that the time I need to spend _additionally_ for testing is negative. I grew up with a print statement being the ultimate debugging tool. A print/debugging statement is added at the time of debugging and probably removed if the error seems to be fixed. That can lead to a situation where you do this multiple times. Writing the same as a test (and that forces you to produce more fine grained code) you will have a saving in time and a little assurance about regression. Regression debugging (debugging it again later) is much more time spent because you have to fix the error _and_ you need to focus again on that problem (which takes most of the time). So the point in writing tests is not to spend time but to save time. The amount of time one should expect to spend writing tests is less than the time you need to spend for testing otherwise. :) Norbert

Feb. 27, 2011

Re: [Pharo-project] seaside.gemstone.com down?

by Marcus Denker

On Feb 27, 2011, at 1:35 PM, Tobias Pape wrote: > Am 2011-02-27 um 13:16 schrieb Marcus Denker: >> Hi, >> >> I tried to load the glamour based tools: >> >> Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. >> (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. >> >> And got this error: >> >> NameLookupFailure: Could not resolve the server named: seaside.gemstone.com > > > hmm, > $ host seaside.gemstone.com > seaside.gemstone.com has address 66.192.188.209 > > works fine for me, probably a DNS failure elsewhere? > Marcus-MacBook-Pro:~ denker$ host seaside.gemstone.com Host seaside.gemstone.com not found: 2(SERVFAIL) strange. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 27, 2011

Re: [Pharo-project] seaside.gemstone.com down?

by Tobias Pape

Am 2011-02-27 um 13:16 schrieb Marcus Denker: > Hi, > > I tried to load the glamour based tools: > > Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. > (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. > > And got this error: > > NameLookupFailure: Could not resolve the server named: seaside.gemstone.com hmm, $ host seaside.gemstone.com seaside.gemstone.com has address 66.192.188.209 works fine for me, probably a DNS failure elsewhere? So Long, -Tobias

Feb. 27, 2011

[Pharo-project] seaside.gemstone.com down?

by Marcus Denker

Hi, I tried to load the glamour based tools: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. And got this error: NameLookupFailure: Could not resolve the server named: seaside.gemstone.com (GoferRepositoryError) So now even that the stuff I want to load has nothing to do with seaside.gemstone.com, I can not load it. We should really try to make our tools more resilient to failures of servers... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 27, 2011

Re: [Pharo-project] About 1.2

by Marcus Denker

On Feb 27, 2011, at 9:11 AM, laurent laffont wrote: > > > > How can XML in 1.2 impacts 1.1 ??????? > > It's not XML, there is another problem. Status: => 1.2 now builds, without Mocketry. But that has been fixed in the meantime, so we can add it back. (it seems removing is a far better way to get people to fix something than anything else. I will do the same with the MethodWrapper package, you will see how quickly this gets fixed *after* removing it, but never without removing it...) => 1.1 does not build. I don't know why. *first* release 1.2, *than* release 1.1.2... => From the test side of things, there are only two things left in 1.2 -> MethodWrappers has test that fails 50% of the time. This will be solved by removing the package. -> there are Obsoletes after running tests. here I think as this is only after running tests, we can defer to 1.3 and remove the test for obsoletes in 1.2 Besides that, there are a number of things that need to be done for 1.2, they are listed here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage 1.2 can only be released if this list is empty. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 27, 2011

Re: [Pharo-project] Issue 3575 in pharo: [Failing Tests] Obsolete classes after tests

by pharo＠googlecode.com

Comment #7 on issue 3575 by m...(a)mjr104.co.uk: [Failing Tests] Obsolete classes after tests http://code.google.com/p/pharo/issues/detail?id=3575 Hi, some of the obsolete classes are being held onto by Tools->Recent Messages. Look at the bottom of the list.

Feb. 27, 2011

Re: [Pharo-project] Fwd: [ANN] pharo focused sprint - bern, feb 26

by StÃ©phane Ducasse

>>> - Lukas went over the WeakAnnouncements implementation to get the WeakMessageSend working. The code is in PharoTaskForces >> >> should we take action on this one? >> I mean integrating it. > > It can be integrated, because the base code works in the same way as before. > > Currently, the solution is implemented through a WeakAnnouncer which subclasses Announcer. I wanted the weak thing to be merged, because the clients of announcements should benefit from the Weak implementation, but Lukas says that he does not trust the Weak support in Pharo and that if you have many WeakAnnouncers it somehow does not scale. ok so ...? > The problem with the current approach is that models have to take an explicit stand of whether they want weak or non weak when instantiating the announcer. Unfortunately, I do have enough technical knowledge for this. It would be cool if someone with better knowledge in this area would take a look. > >>> - Lukas worked on getting OB work with the changes in TextMorph from Pharo 1.2. >>> >>> - Adrian, Jorge and Toon worked on implementing a Debugger on top of Glamour. They got a first version working that is able to do basic actions: step, restart, step into. The challenge was to get to understand the model, and to figure out that <primitive: 19> is used for marking that a method should not be debugged. In any case, working with Glamour seemed to work quite smoothly. The code is available in the Glamorous Toolkit. Adrian, did I get it right? :) >>> >>> - Mircea built a new widget for searching multiple categories of items in the same time, similar to spotlight where you enter one string and you get multiple hits from multiple categories. The implementation was spawned from the OBCompletionDialog / OBCompletionRequest and currently it simply provides multiple lists one below the other. The idea is to use this kind of widget to search simultaneously for classes / methods / packages. The code is available in Glamour (Glamour-Morphic-Renderer). The widget can definitely be improved visually, but Mircea already did a nice job. >> >> is the widget only for glamour because I think that a widget with search list integrated should be used everywhere? >> We were discussing with alain to have a look at the one in OB and push it/rewrite it as a core widget > > Neither the OB nor the Glamour widgets depend on Glamour, so they can be used independently. You just need to take the Request and the Dialog together. ok where is the code?

Feb. 27, 2011

Re: [Pharo-project] we cannot add attachment anymore on the bug tracker

by Norbert Hartl

On 26.02.2011, at 18:55, StÃ©phane Ducasse wrote: >> >> >> Redmine (http://www.redmine.org/) supports sub-projects. Or maybe https://www.chiliproject.org/ (a fork of redmine). > > Does anybody has experience with them? > It would be good to be able to play with them. I just want to ask if there are any plans to integrate issue support in the new squeaksource development. I don't know redmine but it looks similar to trac I'm using since a few years. I also know jira. To me one of the biggest gains of these systems is the integration of source, issues, timeline and wiki. You can easily reference a ticket from the wiki, a ticket from a commit message etc. In trac it is #<number> is interpreted as a link to a ticket. In jira it is <projectname>-<projectnumber>. In jira you can alter the issue tracker by committing new sources. If you write yourproject-58 into the commit than you can change the state of the ticket to something like "needs check" "treated" etc. It sounds a bit blurry but it helps a lot. Sad but true biblicello [1] wasn't in place at the right time. I think it has huge potential by leveraging pier usage. Norbert [1] http://a-bibliocello.gemstone.com/bibliocello/

Feb. 27, 2011

Re: [Pharo-project] Good reference on time on unit testing?

by Norbert Hartl

Hi, On 27.02.2011, at 04:52, Schwab,Wilhelm K wrote: > Hello all, > > Can anyone recommend a good reference on the amount of time one should expect to spend writing tests? I will have to be the messenger (will be wearing running shoes just in case...), but I want the message to come from a solid source. I find that really hard to answer. To me the problem is the question itself. I heard the "..amount of time one should expect to spend writing tests?" so often in companies and I think it was always exactly this phrase. While the question is valid it gives the impression there is something that decucts time from your "normal" development work. So the people that are asking this question are often managing people that have read something about code quality and they want to apply _this_ to their teams. The definition over time is troublesome, too. Testing is not easy. Everything you read about testing gives you the impression that everyone knows how to test and that those developers are just too lazy. And that is not true. Most developers I met had problems to see what testing is all about. The don't see interfaces as provable promises etc. So if you tell any of these developers they should spend 1 hour a day in testing than you will get tests that are counter-productive. My favorite example is the one where you have any composite object with an add method. Than the test goes like adding something via the interface and then try to access the internal array and check if it is of size 1. To me it is the same as with documentation. I prefer to have less documentation than useless documentation. So every developer is testing in some way. You either test and debug on the way in an unstructured form or you write tests. To me writing tests is not an add-on it is a change in working style. From this point of view I would state that the time I need to spend _additionally_ for testing is negative. I grew up with a print statement being the ultimate debugging tool. A print/debugging statement is added at the time of debugging and probably removed if the error seems to be fixed. That can lead to a situation where you do this multiple times. Writing the same as a test (and that forces you to produce more fine grained code) you will have a saving in time and a little assurance about regression. Regression debugging (debugging it again later) is much more time spent because you have to fix the error _and_ you need to focus again on that problem (which takes most of the time). So the point in writing tests is not to spend time but to save time. The amount of time one should expect to spend writing tests is less than the time you need to spend for testing otherwise. :) Norbert

Feb. 27, 2011

Re: [Pharo-project] [ANN] More on Keymappings

by Tudor Girba

I also I cannot load Keymapping 1.5 in Pharo 1.2. I get DNU for Character>>+. This is due to an initialization in KMKeyEvent (see the attached debug log). I did the followings: Gofer it squeaksource: 'Keymapping'; package: 'ConfigurationOfKeymapping'; load. (ConfigurationOfKeymapping project version: #stable) load Am I missing something, or is this version not supposed to work in Pharo 1.2? Cheers, Doru On 26 Feb 2011, at 21:08, Francisco Ortiz PeÃ±aloza wrote: > You're telling me that if i do a clean installation of 1.5 it would work? > > Thanks in advance, > Francisco > > On Sat, Feb 26, 2011 at 3:50 PM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: >> Mmm, If you had 1.4 and updated to 1.5, you will have some problems because >> I did some refactorings on that... :/. >> >> On Sat, Feb 26, 2011 at 10:12 AM, Francisco Ortiz PeÃ±aloza >> <patchinko(a)gmail.com> wrote: >>> >>> Guille i was using 1.4 and worked excellent, just tried 1.5 and on >>> every stroke i made i've got a DNU on #realtarget >>> >>> Installed on last PharoCore 1.2, should i try it on 1.3? >>> >>> Great work, >>> Fran >>> >>> On Sat, Feb 26, 2011 at 5:29 AM, laurent laffont >>> <laurent.laffont(a)gmail.com> wrote: >>>> >>>> On Sat, Feb 26, 2011 at 5:42 AM, Guillermo Polito >>>> <guillermopolito(a)gmail.com> wrote: >>>>> >>>>> What do we have now? >>>>> >>>>> - Can provide settings for a set of morphs >>>>> >>>>> - Can provide settings for a TextEditors (Smalltalk editor and related) >>>>> >>>>> - Settings integration >>>>> I added some methods to the Settings Tree Builder in order to avoid >>>>> references from the users code. >>>>> >>>>> - I ran Slint over it and cleaned it a lot more :). ( And learnt that >>>>> Slint is there :P ) >>>>> >>>>> More info in here: http://guilleel3.blogspot.com/ >>>> >>>> A new blog, cool ! >>>> Can I have Emacs-like keybinding in code editor, to switch browser, ... >>>> ? >>>> Laurent. >>>> >>>>> >>>>> Guille >>>> >>>> >>> >> >> > -- www.tudorgirba.com "Every thing has its own flow."

Feb. 27, 2011