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

Re: [Pharo-project] [enh] Cleaning of and test for MessageTally

by Alexandre Bergel

I removed the duplicated code in SLICE-MessageTallyCleaningAndTest- Alexandre_Bergel.2 MessageTally is a nice piece of code, but a bit messy on some part. And some further cleaning is needed (e.g., the way the time is computed). I did this to fully understand how MessageTally works. This will be helpful for Pharo By Example. Cheers, Alexandre On 16 Mar 2010, at 13:24, StÃ©phane Ducasse wrote: > You have some duplicated code > > spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber > openResultWindow: openResultWindow > > | node result | > node := self new. > node reportOtherProcesses: aBoolean. > result := node spyEvery: self defaultPollPeriod on: aBlock. > > openResultWindow ifTrue: > [ (CodeHolder new contents: (String streamContents: [:s | node > report: s cutoff: aNumber; close])) > openLabel: 'Spy Results' wrap: false ]. > > ^ node > "^ result" > > spyOn: aBlock reportOtherProcesses: aBoolean cutoff: aNumber > openResultWindow: openResultWindow closeAfter: closeAfter > > | node result | > node := self new. > node reportOtherProcesses: aBoolean. > result := node spyEvery: self defaultPollPeriod on: aBlock. > > openResultWindow ifTrue: > [ (CodeHolder new contents: (String streamContents: [:s | node > report: s cutoff: aNumber])) > openLabel: 'Spy Results' wrap: false ]. > > closeAfter ifTrue: [ node close ]. > > ^ node > "^ result" > > It is a good idea to have some tests. Now maybe you should not rely > on float printString but > one a mock class else if we change float printing these tests will > break. > > Stef > > > On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote: > >> Waiting in PharoInbox. This fix has been developed in a 11271. >> >> SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 >> >> >> This slices comprises an update for two packages, Tools and >> ToolsTest. >> The new version of Tools clean MessageTally. A user of MessageTally >> may now decide whether he >> wants to close the tally. Although it is convenient to close it (in >> order to not keep a reference of the >> compiled method and the class), this behavior is not always wished. >> Especially when test have to be >> written! >> The user has now the option to not open the result window. >> >> ToolsTest contains few and simple tests. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 16, 2010

Re: [Pharo-project] [enh] Cleaning of and test for MessageTally

by Alexandre Bergel

> I saw that you remove contentsChanged from CodeHolder. > Is it on purpose? > > contentsChanged > super contentsChanged. > self changed: #annotation No, apparently some problem with the merge. It should not be removed. I update the Slice. Alexandre > On Mar 16, 2010, at 2:15 AM, Alexandre Bergel wrote: > >> Waiting in PharoInbox. This fix has been developed in a 11271. >> >> SLICE-MessageTallyCleaningAndTest-Alexandre_Bergel.1 >> >> >> This slices comprises an update for two packages, Tools and >> ToolsTest. >> The new version of Tools clean MessageTally. A user of MessageTally >> may now decide whether he >> wants to close the tally. Although it is convenient to close it (in >> order to not keep a reference of the >> compiled method and the class), this behavior is not always wished. >> Especially when test have to be >> written! >> The user has now the option to not open the result window. >> >> ToolsTest contains few and simple tests. >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 16, 2010

[Pharo-project] Fixed strange coloring in TestRunner

by Lukas Renggli

Name: SUnitGUI-LukasRenggli.61 Author: lr Time: 16 March 2010, 7:42:35 pm UUID: afa7782a-a37f-4607-8d44-6d03d0f847d6 Ancestors: SUnitGUI-StephaneDucasse.60 - fixed priority of coloring test result: if there are errors then red else if there are failures then yellow else -> green -- Lukas Renggli http://www.lukas-renggli.ch

March 16, 2010

[Pharo-project] BTree packaging

by Chris Muller

Hi Lukas, are there plans to include BTree standard in the Pharo image? I was just wondering whether that was why the package is named Collections-BTree, or if you would renaming it to simply BTree. It's mostly intangible that I have a dirty Collections package in many image (because I often use BTree). Except that, I do find myself sometimes checking in Monticello, "did I change something in Collections? Oh, no, it's just BTree.. Or is it? Let me scroll this list to be sure....." :) Kind of inconvenient, kind of inconsistent for an external package. What do you think?

March 16, 2010

Re: [Pharo-project] What is the best way to...

by Lukas Renggli

> hi Lukas, I'm not a Pier expert, but how would you convert them to latex, > etc? It is a visitor that walks over the document tree and emits LaTeX instead of HTML. I used it to create the documentation in the appendix of my master thesis (http://scg.unibe.ch/archive/masters/Reng06a.pdf) Similar the PDF version of the Seaside Book (http://book.seaside.st) is created with a similar visitor (in this case the pages are not automatically created from comments in the system though). Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 16, 2010

[Pharo-project] [update 1.1] #11275

by StÃ©phane Ducasse

11275 ----- - Issue 2156: Accepting lower case 16rff broke float reading in base 16. Let NumberParser test auto-detect whether lowercase digit letters are allowed or not, and then disbale non-10-based floating point tests. This makes the tests green again.

March 16, 2010

Re: [Pharo-project] about long tests

by StÃ©phane Ducasse

On Mar 16, 2010, at 6:28 PM, Ralph Boland wrote: > I read a few Pharo posts lately about long tests. > In this regard allow me to describe briefly some code I am now writing. > I will eventually release this code to SqueakSource and, if the Pharo group > is interested, I will port it to run on Pharo as well. did you check the work of adrian kuhn on Sunit? I'm interested in your work but I have to get into it. What I would like is also a better way to which class I want to compute the coverage > I use long tests a lot in development. These tests are not really suitable as > SUnit tests because they are too slow and some of them are parameterizable. > These tests are meant for finding bugs during development; less so for verifying > code still works before a release. However, I decided to use the SUnit idea and > code to enhance running these tests. > > First, I refactored TestCase by giving is a superclass and moving all > the TestCase > code into its superclass. I then created a class RunnCase which has the same > parent class as TestCase. The reason for refactoring TestCase this way > is so that if TestRunner is run the classes under RunnCase DO NOT SHOW UP. > I now put my long tests into RunnCase subclasses. > Note that I believe that TestCase should be so refactored even if you > are not interested > in using the tools I am building because it allows others to build > their own tools just as > I am doing. > > I then subclassed TestRunner with subclass TestPlusRunner. > TestPlusRunner allows > running the same tests as TestRunner. TestPlusRunner is like > TestRunner with a few > minor changes including: > 1) an extra window that displays individual test case methods when > only one class > is selected. Subsets of test cases from an single class can be > selected and run. > 2) (Ignore this paragraph is you like) it has as some additional buttons. > Currently the buttons are there but not the functionality. > The intent of the buttons is to be able distribute > the running of a set of tests over a number of computers and > return to one > computer only the tests that failed so they can be debugged. > Specifically, the intent is to be able to file out a set of tests, > send them to another user/computer, have that user/computer > run those tests > and send back a file containing all the tests that fail, > and then be able to load the failed test and debug them. > > I then subclassed TestPlusRunner with subclass RunnRunner. > RunnRunner runs tests > of subclasses of RunnTest. RunnRunner is like TestPlusRunner with > the ability to set parameters that can affect the running of tests. > Currently the only > parameter that can be set are a list of size values. For example, if > this parameter is > set to '3-5,7,9-12' then the tests that are run will be given this > parameter and then > use this parameter however they want but presumably either ignore it or run the > test once with each of the size values: 3,4,5,7,9,10,11,12. > Several other parameters are also planned: > 1) seed. The seed is a value with which to initialize a random > number generator > that the tests can optionally use in the generation of test > data for the tests. > 2) number of subtests. A test may have the ability to generate > and run a number > of subtests (probably using 1)). This parameters indicates > how many subtests to > run. > 3) subtest start. If a test runs 1000 subtests and then detects > a failure then the user > may not want to rerun the first 999 subtests before running > subtest 1000 again. > This parameter allow the subtests to be run starting at subtest #1000. > > Feedback on this work is most welcome either positive or negative (but > constructive). > Regardless of opinions, it would be great if the refactoring of > TestCase described > above were done. It is the way it should have been written in the first place. > Note that some additional minor refactoring of TestCase and TestRunner > is required. > Email me if you want details. > > Regards, > > Ralph Boland > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 16, 2010

[Pharo-project] [update 1.1] #11274

by StÃ©phane Ducasse

11274 ----- - Issue 2155: Gofer test 30% faster - Issue 2153: Fixed compiler exceptions - Issue 2152: fixing Closure compiler Tests - Issue 2150: nextInto:startingAt:count: returning false count - Issue 2132: ExceptionAboutToReturn is not used - Issue 2149: MultiByteFileStreamTest forget to remove a file Stef

March 16, 2010

Re: [Pharo-project] SqNumberParserTests green

by StÃ©phane Ducasse

TX! On Mar 16, 2010, at 5:35 PM, Nicolas Cellier wrote: > PharoInbox/KernelTests-nice.217 > Ancestors: KernelTests-StephaneDucasse.216 > > Accepting lower case 16rff broke float reading in base 16. > Let NumberParser test auto-detect whether lowercase digit letters are > allowed or not, and then disbale non-10-based floating point tests. > This makes the tests green again. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 16, 2010

Re: [Pharo-project] packages :)

by StÃ©phane Ducasse

> Thank you, I will give it a try (fed up writing). this is a good sign :) Stef > > Lukas > > On 16 March 2010 18:00, Tudor Girba <tudor.girba(a)gmail.com> wrote: >> Hi, >> >> To get it: >> Gofer new >> squeaksource: 'PharoTaskForces'; >> package: 'RPackageAll'; >> load. >> >> To get a super-simple browser that shows extensions in italics: >> >> Gofer new >> squeaksource: 'glamoroust'; >> package: 'ConfigurationOfGlamoroust'; >> load. >> (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. >> >> >> To execute it on a super simple package structure: >> RMockFilledPackageOrganizer fillUp. >> (Smalltalk at: #GTCoder) openOn: RMockFilledPackageOrganizer default >> >> Cheers, >> Doru >> >> >> On 16 Mar 2010, at 17:23, Lukas Renggli wrote: >> >>> Can you provide a Gofer expression to load it? >>> >>> Lukas >>> >>> On 16 March 2010 17:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>>> >>>> Hi >>>> >>>> I started to reimplement the package class is did because the previous >>>> one was a bit messy. >>>> I'm currently migrating old the tests to the new implementation and for >>>> now I have around 93% coverage. >>>> I started to build a stupid browser to check my api. >>>> Doru started to code a Glamour browser to see if this was ok. >>>> >>>> Now I would really like if >>>> - somebody could have a look at the code >>>> - develop a simple package browser showing class extensions (it >>>> would help me to define >>>> a good api to walk though a package). I started to use Momo and >>>> this is why I reimplemented the class >>>> but so far I get nearly the same interface and I think that I can >>>> do better. >>>> >>>> Of course there are comments and tests so if one of you want to join we >>>> could do remote pair coding to be able >>>> to release a first version. So far >>>> - integration with MC >>>> - migrating from packageInfo >>>> - event notification >>>> are missing. >>>> >>>> Stef >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 16, 2010