- Pharo-dev - lists.pharo.org

Re: [Pharo-project] 1.2 one-click OSX and Linux: more failing tests

by laurent laffont

1.2 one-click on (Arch) Linux (build #160) there's errors too (see below). So I wonder which VM is used in Hudson ? 10773 run, 10669 passes, 69 expected failures, 6 failures, 29 errors, 0 unexpected passes Failures: FileDirectoryTest>>#testRecursiveMatching ProcessSpecificTest>>#testDynamicVariable FileStreamTest>>#testPositionPastEndIsAtEnd MethodContextTest>>#testClosureRestart BecomeTest>>#testBecomeIdentityHash ProcessSpecificTest>>#testLocalVariable Errors: PharoCorePackageDependenciesTests>>#testMonticello SocketStreamTest>>#testNextIntoClose SocketStreamTest>>#testNextIntoCloseNonSignaling SocketStreamTest>>#testUnCategorizedMethods SocketStreamTest>>#testUnCategorizedMethods SocketStreamTest>>#testUpTo SocketStreamTest>>#testUpTo SocketStreamTest>>#testUpToAfterCloseNonSignaling SocketStreamTest>>#testUpToAfterCloseNonSignaling SocketStreamTest>>#testUpToAfterCloseSignaling SocketStreamTest>>#testUpToAfterCloseSignaling SocketStreamTest>>#testUpToAll SocketStreamTest>>#testUpToAll SocketStreamTest>>#testUpToAllAfterCloseNonSignaling SocketStreamTest>>#testUpToAllAfterCloseNonSignaling SocketStreamTest>>#testUpToAllAfterCloseSignaling SocketStreamTest>>#testUpToAllAfterCloseSignaling SocketStreamTest>>#testUpToAllLimit SocketStreamTest>>#testUpToAllLimit SocketStreamTest>>#testUpToAllTimeout SocketStreamTest>>#testUpToAllTimeout SocketStreamTest>>#testUpToEndClose SocketStreamTest>>#testUpToEndClose SocketStreamTest>>#testUpToEndCloseNonSignaling SocketStreamTest>>#testUpToEndCloseNonSignaling SocketStreamTest>>#testUpToMax SocketStreamTest>>#testUpToMax SocketStreamTest>>#testUpToTimeout SocketStreamTest>>#testUpToTimeout Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/ On Sun, Feb 27, 2011 at 6:06 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > I take the last 1.2 one-click on OSX (build #160), run all tests. > > => tests don't finish because > of SocketStreamTest>>#testUpToAfterCloseNonSignaling which wait infinitely > (however, if you run only SocketStreamTests it works). > > So I deselect SocketStreamTests and run again. > > Result: > > 10743 run, 10669 passes, 67 expected failures, 6 failures, 1 errors, 0 > unexpected passes > Failures: > FileStreamTest>>#testPositionPastEndIsAtEnd > MethodContextTest>>#testClosureRestart > ProcessSpecificTest>>#testDynamicVariable > FileDirectoryTest>>#testRecursiveMatching > ProcessSpecificTest>>#testLocalVariable > AllocationTest>>#testOneGigAllocation > > Errors: > PharoCorePackageDependenciesTests>>#testMonticello > > > > Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/ >

Feb. 27, 2011

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

by Miguel CobÃ¡

El dom, 27-02-2011 a las 12:02 +0100, Norbert Hartl escribiÃ³: > > 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. Yes, redmine has those capabilities too. And as you said, they are very helpful indeed to automate things. > > > 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/ -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Feb. 27, 2011

Re: [Pharo-project] shout for pharo 1.2: Please help.

by Dale Henrichs

So Stef, I looked at ConfigurationOfPharo-StephaneDucasse.139 and I noticed that you commented out some package specs for 1.2-beta2 ... you need to be aware that commenting them out does not prevent those packages from being loaded .... To make structural changes you need to remove the package spec from 1.2-beta2 _and_ remove the package from 1.2-baseline. The specification for Shout Tests in 1.2-beta2 specifies the mcz file to load. By commenting out the spec and leaving the spec in 1.2-baseline you are telling Metacello to load the latest version of the Shout Tests package.. Since 1.2-baseline is already shared by multiple versions, one way to remove Shout Tests for version 1.2-beta2, is to create a 1.2-beta2-baseline that does not include Shout Tests... You comment says that you don't know which version of the Shout Tests to load, but by looking at 1.2-beta2-baseline, Shout Tests is referencing the same project as Shout with a different load directive so it is correct to use the save version as Shout. In a normal case I would recommend that you use the validator to look at the configuration and fix those issues, but there _are_ a number of validation issues with ConfigurationOfPharo already (which depending on what other changes you have made might actually be contributing to the problem ... There were also validation issues ConfigurationOfShout ... so you might have hit a "perfect storm" of validation issues .. I have merged your changes into my working copy and I'll be doing a test load shortly so perhaps I'll be able to observe some of the problems first hand .. Dale On Feb 27, 2011, at 8:30 AM, StÃ©phane Ducasse wrote: > Ok > I do not understand how it loaded before because > I got a duplicate instance warning raised (even if the class loaded was empty - I do not get it) > So I remove the empty package, fixing the version and the baseline... > > Now I have the decompiler popping windows.... problem > Today this is tedious. > For a fix of 1 min I already spent 2 hours to try to load a configuration. > > Stef > > >> Stef, >> >> I will try to take a look at your issue today along with testing out the configuration fixes I have pending ... both Pharo and Shout had configuration issues, but I can't say that your particular issue is related ... yet. >> >> Dale >> >> On Feb 27, 2011, at 7:57 AM, StÃ©phane Ducasse wrote: >> >>> Hi guys >>> >>> I modified >>> >>> version 1.2.1 of ConfigurationOfShout to load my version >>> Shout-sd.101 (apparently lot of comments were removed between Benjamin.100 and Benjamin.101 - strange) >>> >>> >>> In ConfigurationOfPharo there is >>> >>> project: 'Shout' with: '1.2.1'; >>> >>> >>> Now in ConfigurationOfShout there are >>> >>> version122: spec <version: '1.2.2' imports: #('1.1-baseline')> spec for: #common do: [ spec blessing: #development. spec author: 'Francisco Ortiz PeÃ±aloza'. spec description: 'Shout Changes for 1.2 using new SmalltalkEditor'. ]. >>> >>> >>> version121: spec >>> <version: '1.2.1' imports: #('1.1-baseline')> >>> >>> spec for: #common do: [ >>> spec blessing: #development. >>> spec author: 'Stephane Ducasse'. >>> spec description: 'Shout for 1.2'. >>> ]. >>> >>> >>> When I load the latest stable of Pharo >>> >>> ((Smalltalk globals at: #ConfigurationOfPharo) project version: #stable) load >>> >>> I get an error due to a duplicate (probably the instance variable of pluggableShout.....). >>> Probably loading the wrong package. >>> >>> So I do not know what to do and lost my time. >>> >>> Stef >> >> > >

Feb. 27, 2011

[Pharo-project] 1.2 one-click OSX: more failing tests

by laurent laffont

I take the last 1.2 one-click on OSX (build #160), run all tests. => tests don't finish because of SocketStreamTest>>#testUpToAfterCloseNonSignaling which wait infinitely (however, if you run only SocketStreamTests it works). So I deselect SocketStreamTests and run again. Result: 10743 run, 10669 passes, 67 expected failures, 6 failures, 1 errors, 0 unexpected passes Failures: FileStreamTest>>#testPositionPastEndIsAtEnd MethodContextTest>>#testClosureRestart ProcessSpecificTest>>#testDynamicVariable FileDirectoryTest>>#testRecursiveMatching ProcessSpecificTest>>#testLocalVariable AllocationTest>>#testOneGigAllocation Errors: PharoCorePackageDependenciesTests>>#testMonticello Laurent Laffont - @lolgzs <http://twitter.com/#!/lolgzs> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ Blog: http://magaloma.blogspot.com/

Feb. 27, 2011

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

by laurent laffont

On Sun, Feb 27, 2011 at 5:35 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Laurent, > > *I* get it - my audience does not. > :) What I've learned: - people think it will take time to write tests because they don't know what is testing, they don't know what is TDD, because it's hard (yes, it's hard). - showing them your fully tested project, 100% test coverage, happy customer is not enough (but can help to bring confidence) - showing statistics rarely works (may be for your boss, but not developers) - buying them good books can help, but for example here in France it's hard: developers rarely read, even less when the book is technical, even less if it's for their work, even less if written in english (and only one book about TDD in French :) What have worked for me: - the best (by far) is pair programming: but hard to convince people to do pair-programming - except when you are the manager of your team. So you can pair-program with every member and do TDD with them. - regular internal coding-dojo (randori mode is better): easy acceptance. But that doesn't mean people will test when alone. So it have to be often (every week). - reading group (as described in Pragmatic Thinking and Learning - Andrew Hunt): take a book, a copy for each developer. Each week (or more often if possible) meet for 1 hour and do the summary of last read chapter, discuss, see how it can be applied. It seems that to spread an idea / practice, we have to help and do things together (see Your brain at work - David Rock) Hope it can help. Laurent. > > Bill > > > > > ________________________________________ > From: laurent laffont [laurent.laffont(a)gmail.com] > Sent: Sunday, February 27, 2011 10:19 AM > To: Pharo-project(a)lists.gforge.inria.fr > Cc: Schwab,Wilhelm K > Subject: Re: [Pharo-project] Good reference on time on unit testing? > > On Sun, Feb 27, 2011 at 2:12 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu > <mailto:bschwab@anest.ufl.edu>> wrote: > Understood. But, doing it correctly, how much of your time do you spend on > the test writing/maintenance side? > > None. Seriously none. I never pause and say "OK now it's time to write > tests and maintain existing ones". It's part of the TDD cycle: write a test, > make it green, refactor. write a test, make it green, refactor. The cycle > can go from 1mn to 10mn, rarely more. And if you use the Pomodoro > technique, you feel it even better. Test writing/maintenance is part of > programming. > > Sometimes you can say "OK before implementing this new story, I would like > to refactor here and here (tests + code) because I don't like it". We also > do this stuff on legacy code when tests are not here. But it's far easier > when we have good test coverage. > > > I found some blog posts, but I was hoping for some peer-reviewed papers > that go on the record. > > I am trying to make the point you are making, and it will go over better if > I can point to literature and some numbers that I suspect will be seen as > sobering. Tests ARE being "written after" in this case, but assuming they > change to a proper process, they still need to understand that tests take > thought and work. > > > When tests are written after, it's another kind of story. Then "how much > time we should spend writing test" is valid. I don't have any answer. > > TDD is not easy. Learning to write good tests takes time (years), > investment. If someone in your team have good experience with it, he should > pair program continuously with other programmers. Participating in > coding-dojo , code retreats with experienced developers is great too. > > Laurent. > > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto: > pharo-project-bounces(a)lists.gforge.inria.fr> [ > pharo-project-bounces(a)lists.gforge.inria.fr<mailto: > pharo-project-bounces(a)lists.gforge.inria.fr>] On Behalf Of Peter > Hugosson-Miller [oldmanlink(a)gmail.com<mailto:oldmanlink@gmail.com>] > Sent: Sunday, February 27, 2011 2:58 AM > To: Pharo-project(a)lists.gforge.inria.fr<mailto: > Pharo-project(a)lists.gforge.inria.fr> > Subject: Re: [Pharo-project] Good reference on time on unit testing? > > +100 > > Couldn't have said it better myself! > > -- > Cheers, > Peter. > > On 27 feb 2011, at 08:27, laurent laffont <laurent.laffont(a)gmail.com > <mailto:laurent.laffont@gmail.com><mailto:laurent.laffont@gmail.com > <mailto:laurent.laffont@gmail.com>>> wrote: > > On Sun, Feb 27, 2011 at 4:52 AM, Schwab,Wilhelm K <<mailto: > bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>>bschwab(a)anest.ufl.edu > <mailto:bschwab@anest.ufl.edu><mailto:bschwab@anest.ufl.edu<mailto: > bschwab(a)anest.ufl.edu>>> 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. > > If you develop the TDD way (which I always do at work) then I would say > this question is not valid. Your production code will be there because of > tests. In legacy system, new and refactored code will be there because of > tests. > > IMHO the questions "how much time should I spend writing tests?" or "how > many tests should I write ?" are raised when tests are written after. And > sadly tests often become a burden in this case and doesn't support the > pressure of releases / last minute changes / ... (I've done it this way > almost 10 years ago, not good :) > > In TDD the question is "which stories / scenarios do we have to implement > ?". It's more a Product owner / customer point of view. > > The best book on TDD I've read is Dave Astels TDD: a practical guide > (Indeed, this one has really changed my mind on how testing should be done, > and other books I've read since don't). > > Laurent > > > > Bill > > > > > > > >

Feb. 27, 2011

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

by Schwab,Wilhelm K

I've asked the question three times because people seem to be trying to convince me (I'm on your side of this) rather than my audience. Your idea of how much test code gets written would be a fine answer to have. One of the points I am going to make in the presentation is that tests are code too (yes, they apparently need to hear that). If expectations were realistic, I would not need numbers. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Yanni Chiu [yanni(a)rogers.com] Sent: Sunday, February 27, 2011 11:19 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Good reference on time on unit testing? On 27/02/11 7:58 AM, Schwab,Wilhelm K wrote: > > 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? You've asked the question for the third time, so all the TDD explanations seem to have missed the mark. How about asking instead: how much test code do people write? Maybe this way, both the TDD and the "how much time" viewpoints can be accommodated (because volume of test code is roughly proportional to time to write test code). -- Yanni Chiu

Feb. 27, 2011

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

by Schwab,Wilhelm K

Sure. But the audience is a group that bangs out code and then fixes it later; I am trying to help them past that, and something quantitative in an ACM or IEEE journal would be harder to shoot down that our advice, not matter how correct it might be. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Ramon Leon [ramon.leon(a)allresnet.com] Sent: Sunday, February 27, 2011 11:26 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Good reference on time on unit testing? On 02/27/2011 06:12 AM, Schwab,Wilhelm K wrote: > Understood. But, doing it correctly, how much of your time do you spend on the test writing/maintenance side? Far less time than you'll spend manually testing over the course of writing and maintaining the program. You can't avoid testing, nor the time spent doing it, the only question is do want to do it manually and haphazardly with fingers crossed hoping you didn't break anything every publish, or do it with automated tests so you know you didn't break anything every time. -- Ramon Leon http://onsmalltalk.com

Feb. 27, 2011

Re: [Pharo-project] shout for pharo 1.2: Please help.

by StÃ©phane Ducasse

Ok I do not understand how it loaded before because I got a duplicate instance warning raised (even if the class loaded was empty - I do not get it) So I remove the empty package, fixing the version and the baseline... Now I have the decompiler popping windows.... problem Today this is tedious. For a fix of 1 min I already spent 2 hours to try to load a configuration. Stef > Stef, > > I will try to take a look at your issue today along with testing out the configuration fixes I have pending ... both Pharo and Shout had configuration issues, but I can't say that your particular issue is related ... yet. > > Dale > > On Feb 27, 2011, at 7:57 AM, StÃ©phane Ducasse wrote: > >> Hi guys >> >> I modified >> >> version 1.2.1 of ConfigurationOfShout to load my version >> Shout-sd.101 (apparently lot of comments were removed between Benjamin.100 and Benjamin.101 - strange) >> >> >> In ConfigurationOfPharo there is >> >> project: 'Shout' with: '1.2.1'; >> >> >> Now in ConfigurationOfShout there are >> >> version122: spec <version: '1.2.2' imports: #('1.1-baseline')> spec for: #common do: [ spec blessing: #development. spec author: 'Francisco Ortiz PeÃ±aloza'. spec description: 'Shout Changes for 1.2 using new SmalltalkEditor'. ]. >> >> >> version121: spec >> <version: '1.2.1' imports: #('1.1-baseline')> >> >> spec for: #common do: [ >> spec blessing: #development. >> spec author: 'Stephane Ducasse'. >> spec description: 'Shout for 1.2'. >> ]. >> >> >> When I load the latest stable of Pharo >> >> ((Smalltalk globals at: #ConfigurationOfPharo) project version: #stable) load >> >> I get an error due to a duplicate (probably the instance variable of pluggableShout.....). >> Probably loading the wrong package. >> >> So I do not know what to do and lost my time. >> >> Stef > >

Feb. 27, 2011

Re: [Pharo-project] Issue 3764 in pharo: Test runner: file out results sometimes disabled even with existing failures / errors.

by pharo＠googlecode.com

Updates: Status: FixProposed Comment #1 on issue 3764 by laurent....(a)gmail.com: Test runner: file out results sometimes disabled even with existing failures / errors. http://code.google.com/p/pharo/issues/detail?id=3764 in Inbox: SLICE-Issue-3764-Test-runner-file-out-results-sometimes-disabled-even-with-existing-failures--errors-LaurentLaffont.1

Feb. 27, 2011

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

by Ramon Leon

On 02/27/2011 06:12 AM, Schwab,Wilhelm K wrote: > Understood. But, doing it correctly, how much of your time do you spend on the test writing/maintenance side? Far less time than you'll spend manually testing over the course of writing and maintaining the program. You can't avoid testing, nor the time spent doing it, the only question is do want to do it manually and haphazardly with fingers crossed hoping you didn't break anything every publish, or do it with automated tests so you know you didn't break anything every time. -- Ramon Leon http://onsmalltalk.com

Feb. 27, 2011