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

[Pharo-project] Cannot make latest OCompletion work with latest OB

by Mariano Martinez Peck

Hi. I am trying to load OB and OCOmpletion in a PharoCore1.1 and OCompletion doesn't seem to work. However, OCOmpletion and OB tests are green. To reproduce take a PharoCore 1.1 and evaluate: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOmniBrowser'; load. (ConfigurationOfOmniBrowser project version: '1.2') load: #('Dev' 'Dev Tests') And you will see that you open OB, and you type....but OCompletion doesn't appear. Thanks Mariano

Sept. 26, 2010

Re: [Pharo-project] In Smalltalk you can't loose code... hum

by Schwab,Wilhelm K

Keeping things out of the change log? Does that imply that all code must be packaged? It more or less is already, though not always meaningfully. When repackaging a class or method, do you plan to take the code out of the old package's log and put it in the new one? Dolphin uses "real" packages, but it is possible to have unpackaged code - I'm not sure if that's a good thing or not. One day, I would like to see Pharo have a *hierarchy* browser as good as Dolphin's. I think it could be built absent an ability to have unpackaged classes, but I would not want to see it sabotaged by design. Probably a bigger risk would be having work lost by gaps in the packaging system when a catch-all change log would have held onto it. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Sunday, September 26, 2010 11:18 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] In Smalltalk you can't loose code... hum On Sun, Sep 26, 2010 at 2:36 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: > > > > > Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? > > the problem is that the change files logic is old and it works 'well' for what it should but extending it will break other part. > This is why slowly we will have to think to get something better. > > Do you mean improving the change scanner parsing or throwing away and going for something different? > Hi eliot our vision is that we would like to have - all the code of all the squeak and pharo version in a queryable service available from the web. for that we want a source code metamodel a la ginsu or famix Use this metamodel to aggregate several meta models: pseudo class/rb make sure that when possible this model as a compative API with the one of classes and friends => tools reuse Veronica is working on that. Hernan will probably join. May be Colin should join. We could have a nice momentum. - for the changes we would like to have something else than a chunk format because invoking the parser to know if we are manipulating a class definition is bad (with token at: 2 do that and token at: 3 do that). xml works for VisualWorks; it's the obvious choice. The great thing is that if you look at the VisualWorks schema you can learn from their mistakes. IIRC the schema for methods is broken because the selector is not a property (? I don't know xml terminology) of a method, e.g. in VW you see <method>this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> but this would be much mire useful: <method selector="this:is:a:selector:">this: hic is: hic a: hic selector: hic ^self tooMuchBeer</method> Again it will take time but we should have a good (why not 'exquise') infrastructure so that we extend and build new tool easily. Its not a lot of work. ALso VW has a simple scheme for supporting both old chunk format and "new" xml format. BTW, now we have Igor's method trailers we can start playing with more than two source files, e.g. /not/ appending a Monticello package's source to the changes file, but merely adding it to a special directory, e.g. sources. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2010

Re: [Pharo-project] ECUntypedModelTest >> testNarrowWith failing

by Mariano Martinez Peck

On Sun, Sep 26, 2010 at 7:09 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sun, Sep 26, 2010 at 6:58 PM, Romain Robbes <romain.robbes(a)gmail.com>wrote: > >> This one of the tests that were inherited from ECompletion I believe ... >> I don't really know what to do with them. >> >> Same for your other email actually, although I seem to remember it >> used to take a normal amount of time, maybe the implementation of some >> method changed for the worse? >> > > I remember there was some slowdown in certain type of collections in Pharo > 1.1. I don't know if hashed, or sorted, weak...I don't know. > Maybe it is something related to that? > Ups...sorry this answer was to the other email..the one of the time... for this one, I have no idea. MAybe just chaning it to 80 is ok :) Or maybe Lukas can explain us. Cheers Mariano > > Thanks > > Mariano > > > >> >> Romain >> >> On Sun, Sep 26, 2010 at 6:32 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >> > This fails where it does: >> > >> > self assert: count == model entries size. >> > self assert: count > 100. >> > >> > >> > since model entries size -> 85 >> > >> > >> > Of course, if I change the test to >> > >> > self assert: count == model entries size. >> > self assert: count > 80. >> > >> > it works :) >> > >> > Romain ? >> > >> > thanks >> > >> > mariano >> > >> > >

Sept. 26, 2010

Re: [Pharo-project] ECUntypedModelTest >> testNarrowWith failing

by Mariano Martinez Peck

On Sun, Sep 26, 2010 at 6:58 PM, Romain Robbes <romain.robbes(a)gmail.com>wrote: > This one of the tests that were inherited from ECompletion I believe ... > I don't really know what to do with them. > > Same for your other email actually, although I seem to remember it > used to take a normal amount of time, maybe the implementation of some > method changed for the worse? > I remember there was some slowdown in certain type of collections in Pharo 1.1. I don't know if hashed, or sorted, weak...I don't know. Maybe it is something related to that? Thanks Mariano > > Romain > > On Sun, Sep 26, 2010 at 6:32 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: > > This fails where it does: > > > > self assert: count == model entries size. > > self assert: count > 100. > > > > > > since model entries size -> 85 > > > > > > Of course, if I change the test to > > > > self assert: count == model entries size. > > self assert: count > 80. > > > > it works :) > > > > Romain ? > > > > thanks > > > > mariano > > >

Sept. 26, 2010

Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Levente Uzonyi

On Sun, 26 Sep 2010, Mariano Martinez Peck wrote: > Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev image. > If I just take a core image, load OCompletion and run tests, they take a lot > of time, not acceptable. 7-8 seconds in Squeak using Cog. > > Now....if I build a Dev image (with OB, RB, etc) and at the end I try to run > OCompletion tests, the tests takes HOURS. The image seems frozen, but > actually is working. If I interrupt I see the problem is in > > ECUntypedModel >> initializeSelectors > > the part of > > > [ Smalltalk environment keysDo: > [ :each | > selectors add: (ECGlobalEntry > contents: each > type: #globalVar) ]. > > > takes a lot of time I know I'm saying this all the time, but it's true: SortedCollection is not suitable for this usage. Levente > > and it seems related to "ECPreferences caseSensitive" and "ECUntypedModel >>> resetSelectors" > > I don't know what else to say. To reproduce, take a PharoCore 1.1 and > evaluate: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOCompletion'; > load. > > (ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests' > > Then, run all the tests inside OCompletionTests. You will see that after > running some threads....it will look like frozen. There, do an interrupt and > analize. > > IF you do that for a Dev image, it takes muuuuch more. I guess this is > because "Smalltalk environment keys" will have muuuuuch more elements than a > simple core. > > Anyway, help is appreciated. > > Cheers > > Mariano >

Sept. 26, 2010

[Pharo-project] OB failing test08Execution and

by Mariano Martinez Peck

Hi Lukas. Both implementations of test08Execution fail in: n prompt = 'Create Category'. becasue "n prompt" -> 'Add Category' :) cheers mariano

Sept. 26, 2010

[Pharo-project] ECUntypedModelTest >> testNarrowWith failing

by Mariano Martinez Peck

This fails where it does: self assert: count == model entries size. self assert: count > 100. since model entries size -> 85 Of course, if I change the test to self assert: count == model entries size. self assert: count > 80. it works :) Romain ? thanks mariano

Sept. 26, 2010

[Pharo-project] ECompletion/OCompletion tests takes A LIFE!!

by Mariano Martinez Peck

Hi. I am loading OCompletion in PharoCore 1.1 while building the Dev image. If I just take a core image, load OCompletion and run tests, they take a lot of time, not acceptable. Now....if I build a Dev image (with OB, RB, etc) and at the end I try to run OCompletion tests, the tests takes HOURS. The image seems frozen, but actually is working. If I interrupt I see the problem is in ECUntypedModel >> initializeSelectors the part of [ Smalltalk environment keysDo: [ :each | selectors add: (ECGlobalEntry contents: each type: #globalVar) ]. takes a lot of time and it seems related to "ECPreferences caseSensitive" and "ECUntypedModel >> resetSelectors" I don't know what else to say. To reproduce, take a PharoCore 1.1 and evaluate: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOCompletion'; load. (ConfigurationOfOCompletion project version: '1.2') load: 'Core Tests' Then, run all the tests inside OCompletionTests. You will see that after running some threads....it will look like frozen. There, do an interrupt and analize. IF you do that for a Dev image, it takes muuuuch more. I guess this is because "Smalltalk environment keys" will have muuuuuch more elements than a simple core. Anyway, help is appreciated. Cheers Mariano

Sept. 26, 2010

Re: [Pharo-project] MuTalk: Mutation Testing for Pharo Smalltalk

by Nicolas Chillo

We can start improving pharo tests but we should first sign de MIT License agreement. Shouldn`t we? NicolÃ¡s 2010/9/26 Gabriel Brunstein <gaboto(a)gmail.com> > For the research, we made analysis is some random packages like: Aconcagua, > VB-Regex, Network, Magritte and Pier. > > Of course we found places to improve testing on all of these packages. We > can continue analysing other places and work on improving testing. > > However, a problem to solve is using MuTalk to run mutation testing on > Collection (because MuTalk uses collections) or running mutation testing on > MuTalk, I mean, its own model. That is because you are changing its own > behaviour while it is running. > > > > On Sun, Sep 26, 2010 at 6:44 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> cool! >> >> Did you run MuTalk on pharo tests and did you find place where they could >> be improved? >> >> Stef >> >> On Sep 26, 2010, at 2:26 AM, Gabriel Brunstein wrote: >> >> > Hi! >> > >> > I just want to let you know that MuTalk is available for Pharo-Dev >> versions 1.0 and 1.1 >> > >> > >> > you can load it with monticello from >> http://www.squeaksource.com/MutationTesting >> > >> > >> > MutationTesting-NicolasChillo.101 for loading last version in Pharo 1.1 >> (thanks to Francisco Ortiz PeÃ±aloza) >> > >> > MutationTesting-GabrielBrunstein.97 for loading last verion in Pharo 1.0 >> > >> > >> > More info here: http://code.google.com/p/mutalk/ >> > >> > >> > We developed it with Nicolas Chillo for our career thesis but we will >> continue working on it. >> > >> > Basically, Mutation Testing is a technique for measuring and improving >> tests quality. >> > >> > >> > >> > All suggestions are welcome. >> > >> > >> > >> > Bests, >> > >> > Gabriel >> > >> > >> > >> > PS: it doesn't work with CogVM but I think that this problem will be >> solved with Pharo 1.2 (we must adapt it to work there). >> > >> > _______________________________________________ >> > 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 >

Sept. 26, 2010

Re: [Pharo-project] MuTalk: Mutation Testing for Pharo Smalltalk

by Gabriel Brunstein

For the research, we made analysis is some random packages like: Aconcagua, VB-Regex, Network, Magritte and Pier. Of course we found places to improve testing on all of these packages. We can continue analysing other places and work on improving testing. However, a problem to solve is using MuTalk to run mutation testing on Collection (because MuTalk uses collections) or running mutation testing on MuTalk, I mean, its own model. That is because you are changing its own behaviour while it is running. On Sun, Sep 26, 2010 at 6:44 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > cool! > > Did you run MuTalk on pharo tests and did you find place where they could > be improved? > > Stef > > On Sep 26, 2010, at 2:26 AM, Gabriel Brunstein wrote: > > > Hi! > > > > I just want to let you know that MuTalk is available for Pharo-Dev > versions 1.0 and 1.1 > > > > > > you can load it with monticello from > http://www.squeaksource.com/MutationTesting > > > > > > MutationTesting-NicolasChillo.101 for loading last version in Pharo 1.1 > (thanks to Francisco Ortiz PeÃ±aloza) > > > > MutationTesting-GabrielBrunstein.97 for loading last verion in Pharo 1.0 > > > > > > More info here: http://code.google.com/p/mutalk/ > > > > > > We developed it with Nicolas Chillo for our career thesis but we will > continue working on it. > > > > Basically, Mutation Testing is a technique for measuring and improving > tests quality. > > > > > > > > All suggestions are welcome. > > > > > > > > Bests, > > > > Gabriel > > > > > > > > PS: it doesn't work with CogVM but I think that this problem will be > solved with Pharo 1.2 (we must adapt it to work there). > > > > _______________________________________________ > > 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 >

Sept. 26, 2010