July 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Books for summer (was: Time Machine)

by Geoffroy Couprie

2010/7/26 laurent laffont <laurent.laffont(a)gmail.com> > > > On Sat, Jul 24, 2010 at 10:59 AM, Patrick Barroca < > patrick.barroca(a)gmail.com> wrote: > >> I've ordered "Why programs fail" by Andreas Zeller. >> It will be my summer holidays book ;) >> > > So I'll borrow it once read :) > > I've ordered > "Your Brain at Work: Strategies for Overcoming Distraction, Regaining > Focus, and Working Smarter All Day Long" - David Rock > > "The 10-day MBA: A Step-by-Step Guide to Mastering the Skills Taught in Top > Business Schools" - Steven Silbiger (recommended in "Passionate Programmer" > by Chad Fowler). > > And you dear Pharoers, what will you read this summer regarding your > computing/business activity ? > > The blue book :)

July 26, 2010

Re: [Pharo-project] Comparing floats

by Marcus Denker

On Jul 26, 2010, at 10:24 AM, Alexandre Bergel wrote: > Hi! > > In one of my test, I want to check the equality of an array of floats. > The following goes yellow: > self assert: (service outgoingLinks collect: #bandwidth) asArray = #(0.876846926482685 14.7478812578828). > > But this one goes green: > self assert: (service outgoingLinks collect: #bandwidth) asArray printString = '#(0.876846926482685 14.7478812578828)' . > > Any idea how I can avoid a conversion to strings? > there is a method #closeTo: on Float that compares in a way that should be ok for tests like this. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 26, 2010

[Pharo-project] Comparing floats

by Alexandre Bergel

Hi! In one of my test, I want to check the equality of an array of floats. The following goes yellow: self assert: (service outgoingLinks collect: #bandwidth) asArray = #(0.876846926482685 14.7478812578828). But this one goes green: self assert: (service outgoingLinks collect: #bandwidth) asArray printString = '#(0.876846926482685 14.7478812578828)' . Any idea how I can avoid a conversion to strings? In JUnit, there is assertEquals(double, double, delta). Where delta is an approximation. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 26, 2010

Re: [Pharo-project] [ANN 1.1] One-Click 1.1 release

by Marcus Denker

On Jul 26, 2010, at 9:06 AM, Serge Stinckwich wrote: > Why Pier.icns, PetitParser.icns and Seaside.icns files are included in > the Contents/Resources directory ? > Because the one-click is based on Lukas' setup for Hudson auto-build... We should fix that for 1.2 Marcus > > On Sun, Jul 25, 2010 at 9:02 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Jul 25, 2010, at 12:05 PM, Marcus Denker wrote: >> >>> >>> >>> https://gforge.inria.fr/frs/download.php/27302/Pharo-1.1-OneClick.zip >> >> >> due to a small glicht (used the wrong zip, added macos meta data...) >> >> Sadly the gforge can not replace files and keep the same path... >> >> https://gforge.inria.fr/frs/download.php/27303/Pharo-1.1-OneClick.zip >> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 26, 2010

Re: [Pharo-project] [ANN 1.1] One-Click 1.1 release

by Serge Stinckwich

Why Pier.icns, PetitParser.icns and Seaside.icns files are included in the Contents/Resources directory ? On Sun, Jul 25, 2010 at 9:02 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jul 25, 2010, at 12:05 PM, Marcus Denker wrote: > >> >> >> Â Â Â https://gforge.inria.fr/frs/download.php/27302/Pharo-1.1-OneClick.zip > > > due to a small glicht (used the wrong zip, added macos meta data...) > > Sadly the gforge can not replace files and keep the same path... > > https://gforge.inria.fr/frs/download.php/27303/Pharo-1.1-OneClick.zip > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 26, 2010

Re: [Pharo-project] [ANN 1.1] One-Click 1.1 release

by Serge Stinckwich

2010/7/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Sun, Jul 25, 2010 at 4:02 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: >> >> Hm, the link doesn't work for me. I just get an empty response... >> > > https://gforge.inria.fr/frs/download.php/27303/Pharo-1.1-OneClick.zip > > works ok here Works ok for me also. 9764 tests, 9693 passes, 53 expected failures, 17 failures, 1 error on Mac OS X 10.6.4. Most of the failures reported are inside RBSpellingRuleTest. Tests like: testPerfectSentence | result | result := self checker check: 'This is an english sentence without problems.'. self assert: result isCollection. self assert: result isEmpty could not work on my machine, because by default i'm using the french speller ... I made some modifications to switch the speller to english and came back to the original language after the tests. I put my modifications here: http://code.google.com/p/pharo/issues/detail?id=2714 After that all RBSpellingRuleTest are green. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

July 26, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by Alexandre Bergel

Ideally, we should not tag long tests. The system should be smart enough to characterize a test as long. If it takes more than 200ms, then it is long. Autotest should then offer me to include long test or not in the automatic test execution. Using tags means that I have to go over each method test and tag them. This is a costly effort that is likely to not work in practice. We have -=-=-=-=-=-=-=-=-=-=-=-= TestCase class>>newTestDictionary ^ Dictionary new at: #timeStamp put: TimeStamp now; at: #passed put: Set new; at: #failures put: Set new; at: #errors put: Set new; yourself -=-=-=-=-=-=-=-=-=-=-=-= Maybe it should be extended with -=-=-=-=-=-=-=-=-=-=-=-= at: #long put: Set new -=-=-=-=-=-=-=-=-=-=-=-= I guess the tweak in SUnit to identify long tests should not be that hard to implement. Cheers, Alexandre On 26 Jul 2010, at 07:44, laurent laffont wrote: > > On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. > However, I have to disable Autotest when the tests take time to execute. > > > An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2) > > Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests. > > > How would you name the tag ? Where the implementation should go ? (TestCase ?) > > > Laurent. > > > Alexandre > > > On 15 Jun 2010, at 21:41, laurent laffont wrote: > > > Hi Alexandre, > > > > I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback. > > > > Cheers, > > > > Laurent Laffont > > > > http://pharocasts.blogspot.com/ > > http://magaloma.blogspot.com/ > > > > > > On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > Hi Laurent, > > > > I tried to program while having AutoTest running. > > More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this? > > > > Cheers, > > Alexandre > > > > > > On 11 Jun 2010, at 09:02, laurent laffont wrote: > > > > > On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > Hi Laurent, > > > > > > I like Autotest. It is true that I always execute the test after modifying it. > > > There are three horizontal panes. Why so? Is it just to open a debugger when necessary? > > > > > > I want to be able to open a debugger from autotest. I agree the GUI is crap now. > > > > > > > > > We could imagine one standalone button instead with a green color to say the test I just edited is green, and yellow or red when it fails. In that case, clicking on the button open a debugger. > > > > > > I just feel the window of autotest takes a lot of space in the screen, without having a real benefit. > > > > > > Yes it's true. I'm still thinking on a good GUI. But I'm learning how to make GUI now :) > > > > > > If you look at Autotest package, AutotestView is just the GUI, so we can implement several GUI and see the best solution. I need to take the time to do it, repository is read / write so feel free to commit :) > > > > > > What I want to have is a dashboard docked on one side of the screen which acts like you're driving a car. It's always visible, you have to be able to look quickly at it as when you check the speed of your car, adjust your drive, .... > > > > > > Also another problem with the current version if that if a test fails, change it and fails again, you don't see it has run (nothing moves in the GUI). > > > > > > Finally, another problem is that you see that a test has failed, but you don't know why (SUnit TestRunner has the same problem). I want to display the exception message too. > > > > > > Thanks a lot for feedback. > > > > > > Laurent Laffont > > > > > > http://pharocasts.blogspot.com/ > > > http://magaloma.blogspot.com/ > > > > > > > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 3 Jun 2010, at 17:11, laurent laffont wrote: > > > > > > > Hi, > > > > > > > > I've written a proof-of-concept for Autotest. Draft/crappy code and no tests (exploration mode :) but it loads on PharoCore-1.1-11383-beta image. > > > > > > > > Load it: > > > > Gofer new > > > > squeaksource: 'Autotest'; > > > > package: 'Autotest'; > > > > load > > > > > > > > Open it: > > > > AutotestView open > > > > (there's en entry in WorldMenu > Tools) > > > > > > > > And change a tested method to see the results. > > > > > > > > There's a bug I need to find, maybe someone knows: > > > > - Change Bag>>occurrencesOf: > > > > - Autotest gives: > > > > > > > > 284 run, 281 passes, 0 expected failures, 1 failures, 2 errors, 0 unexpected passes > > > > Failures: > > > > CollectionRootTest>>#test0FixtureIterateTest > > > > > > > > Errors: > > > > CollectionRootTest>>#testBasicCollect > > > > CollectionRootTest>>#testDoWithout > > > > > > > > but in SUnit CollectionRootTest gives > > > > 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes ?? > > > > > > > > > > > > Cheers, > > > > > > > > Laurent Laffont > > > > > > > > http://pharocasts.blogspot.com/ > > > > http://magaloma.blogspot.com/ > > > > > > > > > > > > On Thu, Jun 3, 2010 at 6:09 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > > The idea is excellent. > > > > > > > > Cheers, > > > > Alexandre > > > > > > > > > > > > On 3 Jun 2010, at 10:22, laurent laffont wrote: > > > > > > > > > > > > > > > > > > > On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > > > > You may have a lot of noise. > > > > > > > > > > > > I guess that Ruby uses files as a unit of development/deployment. The closest Smalltalk/Pharo has is the class and the package. > > > > > > > > > > > > I would suggest that TestCase which would use this feature use some pragma/method to identify/declare which classes/packages this test depends upon. Then the "autotest" framework would register such tests and listen for changes in the given classes/packages, launching required tests whenever a change happen. > > > > > > > > > > > > Additionally, one could declare such a pragma on a single test method, when this test should be run for a specific class. > > > > > > > > > > > > Of course, you also to take care of long running tests, which you probably want to exclude from auto-testing. > > > > > > > > > > I see autotest in Pharo in a slighly different way: When I press save in the Monticello browser, I have a popup menu which asks me whether (i) I want to run all the tests or (ii) only the tests that cover that I changed from the last version. > > > > > > > > > > Does this make sense? > > > > > > > > > > Please no popup :) What I like in ruby autotest is that I can quickly look at test results if I want (or not) without stop writing. Often you want to see your tests failing, as you type / save code. I don't have to stop writing, click a button, wait test results, go again.... testing is done in background and I just see notifications whether it's OK or not. > > > > > > > > > > So test log in a Transcript is OK for me. > > > > > > > > > > > > > > > For autotest unit of work is file: it runs the test file which has the same name as the code file, but you can customize this behavior. For autotest-rails: > > > > > "A simplified version of Autotest heuristics in this mode would be: > > > > > When changing a test file, only this file is run (e.g. test/unit/foo_test.rb âtest/unit/foo_test.rb). > > > > > When changing a model file, only associated unit test file is run (e.g.app/models/foo.rb â test/unit/foo_test.rb). > > > > > When changing a controller file, associated functional test file is run (e.g.app/controllers/foo_controller.rb âtest/functional/foo_controller_test.rb). > > > > > When changing a fixture file, associated unit test and functional test are run (e.g.app/fixtures/foos.yml â test/unit/foo_test.rb +test/functional/foo_controller_test.rb). > > > > > When changing a helper file, associated functional test file is run (e.g.app/helpers/foo_helper.rb âtest/functional/foo_controller_test.rb). > > > > > When changing application_helper.rb file all functional test files are run (e.g.application_helper.rb â test/functional/*_test.rb). > > > > > When changing a file under the config directory, all tests are run." > > > > > > > > > > Laurent > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > Alexandre > > > > > -- > > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > > Alexandre Bergel http://www.bergel.eu > > > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pharo-project mailing list > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > _______________________________________________ > > > > > Pharo-project mailing list > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > Alexandre Bergel http://www.bergel.eu > > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 26, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by laurent laffont

On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > I have been using Autotest for a while already. I greatly reduce the window > switching. This is cool. > However, I have to disable Autotest when the tests take time to execute. > An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2) Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests. How would you name the tag ? Where the implementation should go ? (TestCase ?) Laurent. > > Alexandre > > > On 15 Jun 2010, at 21:41, laurent laffont wrote: > > > Hi Alexandre, > > > > I've reorganized Autotest to write tests. The tests now run in a thread > with lower priority. Thanks for feedback. > > > > Cheers, > > > > Laurent Laffont > > > > http://pharocasts.blogspot.com/ > > http://magaloma.blogspot.com/ > > > > > > On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre(a)bergel.eu> > wrote: > > Hi Laurent, > > > > I tried to program while having AutoTest running. > > More importantly than the interface, I experienced some problem with long > executing tests. Basically, these tests should not be executed while I am > programming. Or at least in a thread of a lesser priority. Am I the only one > to experience this? > > > > Cheers, > > Alexandre > > > > > > On 11 Jun 2010, at 09:02, laurent laffont wrote: > > > > > On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre(a)bergel.eu> > wrote: > > > Hi Laurent, > > > > > > I like Autotest. It is true that I always execute the test after > modifying it. > > > There are three horizontal panes. Why so? Is it just to open a debugger > when necessary? > > > > > > I want to be able to open a debugger from autotest. I agree the GUI is > crap now. > > > > > > > > > We could imagine one standalone button instead with a green color to > say the test I just edited is green, and yellow or red when it fails. In > that case, clicking on the button open a debugger. > > > > > > I just feel the window of autotest takes a lot of space in the screen, > without having a real benefit. > > > > > > Yes it's true. I'm still thinking on a good GUI. But I'm learning how > to make GUI now :) > > > > > > If you look at Autotest package, AutotestView is just the GUI, so we > can implement several GUI and see the best solution. I need to take the time > to do it, repository is read / write so feel free to commit :) > > > > > > What I want to have is a dashboard docked on one side of the screen > which acts like you're driving a car. It's always visible, you have to be > able to look quickly at it as when you check the speed of your car, adjust > your drive, .... > > > > > > Also another problem with the current version if that if a test fails, > change it and fails again, you don't see it has run (nothing moves in the > GUI). > > > > > > Finally, another problem is that you see that a test has failed, but > you don't know why (SUnit TestRunner has the same problem). I want to > display the exception message too. > > > > > > Thanks a lot for feedback. > > > > > > Laurent Laffont > > > > > > http://pharocasts.blogspot.com/ > > > http://magaloma.blogspot.com/ > > > > > > > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 3 Jun 2010, at 17:11, laurent laffont wrote: > > > > > > > Hi, > > > > > > > > I've written a proof-of-concept for Autotest. Draft/crappy code and > no tests (exploration mode :) but it loads on PharoCore-1.1-11383-beta > image. > > > > > > > > Load it: > > > > Gofer new > > > > squeaksource: 'Autotest'; > > > > package: 'Autotest'; > > > > load > > > > > > > > Open it: > > > > AutotestView open > > > > (there's en entry in WorldMenu > Tools) > > > > > > > > And change a tested method to see the results. > > > > > > > > There's a bug I need to find, maybe someone knows: > > > > - Change Bag>>occurrencesOf: > > > > - Autotest gives: > > > > > > > > 284 run, 281 passes, 0 expected failures, 1 failures, 2 errors, 0 > unexpected passes > > > > Failures: > > > > CollectionRootTest>>#test0FixtureIterateTest > > > > > > > > Errors: > > > > CollectionRootTest>>#testBasicCollect > > > > CollectionRootTest>>#testDoWithout > > > > > > > > but in SUnit CollectionRootTest gives > > > > 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 > unexpected passes ?? > > > > > > > > > > > > Cheers, > > > > > > > > Laurent Laffont > > > > > > > > http://pharocasts.blogspot.com/ > > > > http://magaloma.blogspot.com/ > > > > > > > > > > > > On Thu, Jun 3, 2010 at 6:09 PM, Alexandre Bergel < > alexandre(a)bergel.eu> wrote: > > > > The idea is excellent. > > > > > > > > Cheers, > > > > Alexandre > > > > > > > > > > > > On 3 Jun 2010, at 10:22, laurent laffont wrote: > > > > > > > > > > > > > > > > > > > On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel < > alexandre(a)bergel.eu> wrote: > > > > > > You may have a lot of noise. > > > > > > > > > > > > I guess that Ruby uses files as a unit of development/deployment. > The closest Smalltalk/Pharo has is the class and the package. > > > > > > > > > > > > I would suggest that TestCase which would use this feature use > some pragma/method to identify/declare which classes/packages this test > depends upon. Then the "autotest" framework would register such tests and > listen for changes in the given classes/packages, launching required tests > whenever a change happen. > > > > > > > > > > > > Additionally, one could declare such a pragma on a single test > method, when this test should be run for a specific class. > > > > > > > > > > > > Of course, you also to take care of long running tests, which you > probably want to exclude from auto-testing. > > > > > > > > > > I see autotest in Pharo in a slighly different way: When I press > save in the Monticello browser, I have a popup menu which asks me whether > (i) I want to run all the tests or (ii) only the tests that cover that I > changed from the last version. > > > > > > > > > > Does this make sense? > > > > > > > > > > Please no popup :) What I like in ruby autotest is that I can > quickly look at test results if I want (or not) without stop writing. Often > you want to see your tests failing, as you type / save code. I don't have to > stop writing, click a button, wait test results, go again.... testing is > done in background and I just see notifications whether it's OK or not. > > > > > > > > > > So test log in a Transcript is OK for me. > > > > > > > > > > > > > > > For autotest unit of work is file: it runs the test file which has > the same name as the code file, but you can customize this behavior. For > autotest-rails: > > > > > "A simplified version of Autotest heuristics in this mode would be: > > > > > When changing a test file, only this file is run (e.g. > test/unit/foo_test.rb âtest/unit/foo_test.rb). > > > > > When changing a model file, only associated unit test file is run > (e.g.app/models/foo.rb â test/unit/foo_test.rb). > > > > > When changing a controller file, associated functional test file is > run (e.g.app/controllers/foo_controller.rb > âtest/functional/foo_controller_test.rb). > > > > > When changing a fixture file, associated unit test and functional > test are run (e.g.app/fixtures/foos.yml â test/unit/foo_test.rb > +test/functional/foo_controller_test.rb). > > > > > When changing a helper file, associated functional test file is run > (e.g.app/helpers/foo_helper.rb âtest/functional/foo_controller_test.rb). > > > > > When changing application_helper.rb file all functional test files > are run (e.g.application_helper.rb â test/functional/*_test.rb). > > > > > When changing a file under the config directory, all tests are > run." > > > > > > > > > > Laurent > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > Alexandre > > > > > -- > > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > > Alexandre Bergel http://www.bergel.eu > > > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > Pharo-project mailing list > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > > _______________________________________________ > > > > > Pharo-project mailing list > > > > > Pharo-project(a)lists.gforge.inria.fr > > > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > Alexandre Bergel http://www.bergel.eu > > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 26, 2010

Re: [Pharo-project] Books for summer (was: Time Machine)

by laurent laffont

On Sat, Jul 24, 2010 at 10:59 AM, Patrick Barroca <patrick.barroca(a)gmail.com > wrote: > I've ordered "Why programs fail" by Andreas Zeller. > It will be my summer holidays book ;) > So I'll borrow it once read :) I've ordered "Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long" - David Rock "The 10-day MBA: A Step-by-Step Guide to Mastering the Skills Taught in Top Business Schools" - Steven Silbiger (recommended in "Passionate Programmer" by Chad Fowler). And you dear Pharoers, what will you read this summer regarding your computing/business activity ? Laurent > > On Thu, Jul 22, 2010 at 11:52 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > http://www.st.cs.uni-saarland.de/dd/ > > you can get some papers but also the slides that go with the book > > Stef > > > > On Jul 22, 2010, at 11:36 PM, laurent laffont wrote: > > > >> > >> On Thu, Jul 22, 2010 at 11:34 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> did you read delta debugging from andreas Zeller? > >> > >> No. Where ? > >> > >> Laurent > >> > >> > >> > >> Stef > >> > >> On Jul 22, 2010, at 11:11 PM, laurent laffont wrote: > >> > >> > Hi, > >> > > >> > From a discussion I had with Kent Beck about Continuous Testing / > Autotest (see > http://pharocasts.blogspot.com/2010/07/live-testing-with-autotest.html ), > I would like to add a kind of Time Machine for Smalltalk code in Autotest. > >> > > >> > When a test fails, what I really want to know is why. Sometimes a test > fails and I don't know why. So I have to go through a debugging session > which distracts me from what I've been coding. > >> > > >> > So an idea is to diff backtrace before and after the test fails: > >> > - revert to last green > >> > - replay the test and save the trace > >> > - forward to current test and run (test fails) > >> > - compare execution paths in order to see the consequence of last > change > >> > > >> > How would you do this ? Where should I look for materials which can > help me coding this ? > >> > > >> > Cheers, > >> > > >> > Laurent Laffont > >> > > >> > http://pharocasts.blogspot.com/ > >> > http://magaloma.blogspot.com/ > >> > _______________________________________________ > >> > Pharo-project mailing list > >> > Pharo-project(a)lists.gforge.inria.fr > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Patrick Barroca > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 26, 2010

Re: [Pharo-project] Primitives ?

by Michael Haupt

James, from the caller perspective, a primitive looks just like a method, so the VM, when executing the primitive, finds the arguments on the stack. Look at any of the primitive implementations in the VM source and how arguments are retrieved. HTH, Michael P.S. Will there eventually be content on redline.st? ;-) Am 26.07.2010 um 00:52 schrieb James Ladd <james_ladd(a)hotmail.com>: > Hi All, > > I'm looking at some low level details of Pharo Smalltalk and I am wondering, > when I see a primitive in the bytecode, is it safe to assume that before > the primitive is executed, the receiver and any args to the method are pushed > onto the stack? > > Rgs, James. > > Australia's #1 job site If It Exists, You'll Find it on SEEK > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 26, 2010