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

Re: [Pharo-project] packages :)

by StÃ©phane Ducasse

I forgot to mention You should load RPackage-All from PharoTaskForces Stef On Mar 16, 2010, at 5:21 PM, StÃ©phane Ducasse 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

March 16, 2010

Re: [Pharo-project] about long tests

by Ralph Boland

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. 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

March 16, 2010

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

by Hernan Wilkinson

Hi Damien, I just tried it in the last pharo version and works fine. I'd like to add an option to print the methods source code. Do you mind if I do it? If so, can you add me as developer in SqueakSource for this package so I can commit the change? My user is HAW Thanks! Hernan. On Tue, Mar 16, 2010 at 11:43 AM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Tue, Mar 16, 2010 at 3:25 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > Damien did a package to print latex but I do not know its status. > > I'm still dreaming about a Visitor over package, class.... > > that would produce > > fileout > > html > > tex > > SmallAutoDoc produces html or latex. It's quite old however and I > don't know it's current status: > http://www.squeaksource.com/SmallAutoDoc/ > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > 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] [enh] Cleaning of and test for MessageTally

by StÃ©phane Ducasse

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

March 16, 2010

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

by Hernan Wilkinson

hi Lukas, I'm not a Pier expert, but how would you convert them to latex, etc? On Tue, Mar 16, 2010 at 11:54 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > Also Pier-Document converts Packages, Classes and Methods to Pier > pages that can then be displayed on the web or converted to LaTeX or a > book or ... > > Lukas > > On 16 March 2010 15:43, Damien Cassou <damien.cassou(a)gmail.com> wrote: > > On Tue, Mar 16, 2010 at 3:25 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> Damien did a package to print latex but I do not know its status. > >> I'm still dreaming about a Visitor over package, class.... > >> that would produce > >> fileout > >> html > >> tex > > > > SmallAutoDoc produces html or latex. It's quite old however and I > > don't know it's current status: > > http://www.squeaksource.com/SmallAutoDoc/ > > > > -- > > Damien Cassou > > http://damiencassou.seasidehosting.st > > > > "Lambdas are relegated to relative obscurity until Java makes them > > popular by not having them." James Iry > > > > _______________________________________________ > > 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

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

by StÃ©phane Ducasse

alex I saw that you remove contentsChanged from CodeHolder. Is it on purpose? contentsChanged super contentsChanged. self changed: #annotation 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

March 16, 2010

Re: [Pharo-project] packages :)

by Lukas Renggli

Thank you, I will give it a try (fed up writing). 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

March 16, 2010

[Pharo-project] Congratulations Norberto Manzanos! - Re: [Pkg] Installer: Installer-Core-nm.357.mcz

by Ken G. Brown

Big CONGRATULATIONS to Norberto Manzanos for maintaining Installer in the proper squeaksource repository, rather than local to some fork or other. This is a breakthrough! Here's a great opportunity for developers to work out some procedures around maintaining packages external to the trunk repository, in the interest of improved modularity. Ken G. Brown At 4:15 PM +0100 3/16/10, squeak-dev-noreply(a)lists.squeakfoundation.org apparently wrote: >A new version of Installer-Core was added to project Installer: >http://www.squeaksource.com/Installer/Installer-Core-nm.357.mcz > >==================== Summary ==================== > >Name: Installer-Core-nm.357 >Author: nm >Time: 16 March 2010, 12:15:30 pm >UUID: 7e6635ca-259c-3549-8034-d3bbfcbd0f14 >Ancestors: Installer-Core-nm.357 > > - still a bug on detecting version number, due to this monticello bad design. Package with names like 'Seaside2.8a1-xx.1.mcz' will be sorted wrongly. Fixed, I think > >=============== Diff against Installer-Core-nm.357 ===============

March 16, 2010

Re: [Pharo-project] NewTextMorph status

by Fernando olivero

On Mar 16, 2010, at 3:24 PM, StÃ©phane Ducasse wrote: > >> >> >> Stef, should i use the lastest 1.1 image as the base for preparing the SLICE? > > please I''l prepare the SLICE tonight. > Now Fernando when you are talking about > MethodMorph > and ClassDefinitionMorph this is for your ide? > So may be you should keep that for you? > Or/and are you saying that we should have a new SmalltalkCodeMorph that has a SmalltalkEditor? > > Stef I noticed that spreading the behavior to each editor, makes the code much cleaner and provides better support for maintenance and extensions. Also i'm using announcements, for announcing acceptedContents and escape pressed. This would allow us to unify the TextMorph and PluggableTextMorph, that currently (in my opinion) is mess of shared behavior and subclasification. pd: Examples of usage: t := NewTextMorph new. t text:'hola que tal como andas?. Tenemos dos lineas ahora.Y que tal tres?' asText . t onAcceptSend: #delete to: t. m := MethodMorph new. m class: Object selector:#name. m font: ( LogicalFont familyName: 'DejaVu Serif' pointSize: 15 ) copy. m := ClassDefinitionMorph new. m class: Object. e := EntryFieldMorph example1. e onAcceptSend: #hello to: e. e onEscapeSend: #delete to: e. > _______________________________________________ > 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 Tudor Girba

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."

March 16, 2010