- Pharo-dev - lists.pharo.org

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

by Gabriel Brunstein

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

Sept. 26, 2010

Re: [Pharo-project] #copy and friends

by Levente Uzonyi

On Sat, 25 Sep 2010, Schwab,Wilhelm K wrote: > copy > "Answer another instance just like the receiver. Subclasses typically override postCopy; they typically do not override shallowCopy. Copy is a template method in the sense of Design Patterns. So do not override it. Override shallowCopy instead. Pay attention that normally you should call postCopy of your superclass too." It should be: Override postCopy instead. Levente > > ^self shallowCopy postCopy > > > > shallowCopy > "Answer a copy of the receiver which shares the receiver's instance variables. It should never be overridden. I'm invoked from the copy template method. Subclasses that need to specialize the copy should specialize the postCopy hook method." > > > The references to #postCopy are probably valid, but the comments above can't both be correct. Right?? > > Bill > > > _______________________________________________ > 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

[Pharo-project] #copy and friends

by Schwab,Wilhelm K

copy "Answer another instance just like the receiver. Subclasses typically override postCopy; they typically do not override shallowCopy. Copy is a template method in the sense of Design Patterns. So do not override it. Override shallowCopy instead. Pay attention that normally you should call postCopy of your superclass too." ^self shallowCopy postCopy shallowCopy "Answer a copy of the receiver which shares the receiver's instance variables. It should never be overridden. I'm invoked from the copy template method. Subclasses that need to specialize the copy should specialize the postCopy hook method." The references to #postCopy are probably valid, but the comments above can't both be correct. Right?? Bill

Sept. 26, 2010

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

by FranÃ§ois Tanguy

Le 25 sept. 2010 Ã 21:43, George Herolyants a Ã©crit : > Hi, > > 2010/9/25 FranÃ§ois Tanguy <francois.tanguy(a)gmail.com>: >> Hi, >> >> the statement is true when the code is saved in the browser. >> But in a workspace or in the script manager that is not true. > > You can save a workspace into a file and it will be renewed each time > you press Cmd+S. Here is what I did: 1) Open a workspace / save the image 2) edit the workspace / save Cmd + S 3) quit Pharo without saving 4) Open pharo -> the workspace is empty > > _______________________________________________ > 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] In Smalltalk you can't loose code... hum

by FranÃ§ois Tanguy

Le 25 sept. 2010 Ã 21:53, StÃ©phane Ducasse a Ã©crit : > > On Sep 25, 2010, at 9:25 PM, FranÃ§ois Tanguy wrote: > >> Hi, >> >> the statement is true when the code is saved in the browser. >> But in a workspace or in the script manager that is not true. >> >> Actually it is a feature request: You can't loose code even when you are working in the script browser. > > check if you can find a way and I'm sure that the maintainer of scriptmanager will integrate it. > I always prefer to define methods so I never use script or workspace to write anything useful. In my case, I wrote some crap and got an endless loop... Had to quit the image and lost some code. But I kind of like the script manager to write codes that build models or examples to remind me how to do some stuff. I will have a look at the script manager and hope we can come up with a solution. At least when Cmd + S is pressed, the minimum would be to save the code. > >> >> 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. > > >> >> Francois >> _______________________________________________ >> 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

[Pharo-project] Implement Keyboard focus on a custom morph when have rounded corners

by nullPointer

IÂ´m developing new widgets, integrateds in Polymorph. But when I try implement the keyboard focus appearance fails when the widget have rounded corners: http://forum.world.st/file/n2713899/RoundedCorner.png I imagine something miss, but I donÂ´t know what. I implement the keyboard focus with drawSubmorphsOn: aCanvas super drawSubmorphsOn: aCanvas. self hasKeyboardFocus ifTrue: [self drawKeyboardFocusOn: aCanvas]. Many thanks for the help :)) -- View this message in context: http://forum.world.st/Implement-Keyboard-focus-on-a-custom-morph-when-have-… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Sept. 25, 2010

Re: [Pharo-project] Webpage for research paper about Pharo?

by Alexandre Bergel

Makes sense. However, I do not want to emphasize on the past with old papers. I am now working on the webpage Cheers, Alexandre On 25 Sep 2010, at 03:10, StÃ©phane Ducasse wrote: > guys > > all my papers are using Smalltalk (visualworks, squeak mainly so far) as a research vehicule. You can use them to do marketing around smalltalk because there are good papers in prestigious venues. Please do not have the time. > > Now pharo has the right to mention the papers using pharo on the pharo web site. > > Stef > > On Sep 25, 2010, at 12:20 AM, Sean P. DeNigris wrote: > >> >> How about putting the papers on both sites ;-) >> >> Sean >> -- >> View this message in context: http://forum.world.st/Webpage-for-research-paper-about-Pharo-tp2549096p2606… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 25, 2010

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

by Eliot Miranda

On Sat, Sep 25, 2010 at 12:53 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > > On Sep 25, 2010, at 9:25 PM, FranÃ§ois Tanguy wrote: > > > Hi, > > > > the statement is true when the code is saved in the browser. > > But in a workspace or in the script manager that is not true. > > > > Actually it is a feature request: You can't loose code even when you are > working in the script browser. > > check if you can find a way and I'm sure that the maintainer of > scriptmanager will integrate it. > I always prefer to define methods so I never use script or workspace to > write anything useful. > > > > > 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? > > > > > Francois > > _______________________________________________ > > 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. 25, 2010

Re: [Pharo-project] do we need handleDisabledKey:

by Guillermo Polito

I had a look at CUIS, and it doesn't use it neither. On Fri, Sep 24, 2010 at 3:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > hi gary > > do we need handleDisabledKey: because this is not defined on the new > editorHierarchy? > > http://code.google.com/p/pharo/issues/detail?id=3003 > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 25, 2010

Re: [Pharo-project] systemNavigation cleaning

by Lukas Renggli

I think people want all packages by default. This package separation is more to make it possible to replace some parts of PharoCore with the more modern and powerful mechanisms from the refactoring engline, e.g. SystemNavigation -> BrowserEnvironment, (e.g. SystemNavigation -> BrowserEnvironemnt and ChangeRecord -> RefactoryChange). Lukas 2010/9/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Thanks. And do you have an idea of better groups that the basic ones I have > defined?Â (look at the end). > I mean, imagine groups of packages that it is likely a user will load only > them, andÂ all together > > > > > spec for: #pharo do: [ > Â Â Â Â Â Â spec repository: 'http://www.squeaksource.com/rb'. > Â Â Â Â Â Â spec > Â Â Â Â Â Â Â Â Â package: 'AST-Core'; > Â Â Â Â Â Â Â Â Â package: 'AST-Tests-Core' with: [ spec requires: 'AST-Core' ]; > > Â Â Â Â Â Â Â Â Â package: 'AST-Semantic' with: [ spec requires: 'AST-Core' ]; > Â Â Â Â Â Â Â Â Â package: 'AST-Tests-Semantic' with: [ spec requires: > 'AST-Semantic' ]; > > Â Â Â Â Â Â Â Â Â package: 'Refactoring-Environment' with: [ spec requires: > 'AST-Core' ]; > Â Â Â Â Â Â Â Â Â package: 'Refactoring-Tests-Environment' with: [ spec requires: > 'Refactoring-Environment' ]; > > Â Â Â Â Â Â Â Â Â package: 'Refactoring-Changes' with: [ spec requires: > 'Refactoring-Environment' ]; > Â Â Â Â Â Â Â Â Â package: 'Refactoring-Tests-Changes' with: [ spec requires: > 'Refactoring-Changes' ]; > > Â Â Â Â Â Â Â Â Â package: 'Refactoring-Core' with: [ spec requires: > 'Refactoring-Changes' ]; > Â Â Â Â Â Â Â Â Â package: 'Refactoring-Tests-Core' with: [ spec requires: > 'Refactoring-Core' ]; > > Â Â Â Â Â Â Â Â Â package: 'Refactoring-Critics' with: [ spec requires: > 'Refactoring-Changes' ]; > Â Â Â Â Â Â Â Â Â package: 'Refactoring-Tests-Critics' with: [ spec requires: > 'Refactoring-Critics' ]; > > Â Â Â Â Â Â Â Â Â package: 'Refactoring-Spelling' with: [ > Â Â Â Â Â Â Â Â Â Â Â Â spec requires: 'Refactoring-Critics'. > Â Â Â Â Â Â Â Â Â Â Â Â spec postLoadDoIt: #postLoadRBSpelling ]; > Â Â Â Â Â Â Â Â Â package: 'Refactoring-Tests-Spelling' with: [ spec requires: > 'Refactoring-Tests-Critics'. ]. > > Â Â Â Â Â Â spec > Â Â Â Â Â Â Â Â Â group: 'default' with: #('Core' ); > Â Â Â Â Â Â Â Â Â group: 'Core' with: #( 'AST-Core' 'AST-Semantic' > 'Refactoring-Environment'Â 'Refactoring-Changes' 'Refactoring-Core' > 'Refactoring-Critics' 'Refactoring-Spelling'Â ); > Â Â Â Â Â Â Â Â Â group: 'Tests' with: #( 'AST-Tests-Core'Â 'AST-Tests-Semantic' > 'Refactoring-Tests-Environment'Â 'Refactoring-Tests-Changes' > 'Refactoring-Tests-Core' 'Refactoring-Tests-Critics' > 'Refactoring-Tests-Spelling' ); > Â Â Â Â Â Â Â Â Â group: 'Core Tests' with: #('Core' 'Tests' ); > > > > cheers > > mariano > > > On Sat, Sep 25, 2010 at 10:18 PM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> Refactoring-Spelling depends on Refactoring-Critics. >> Refactoring-Tests-Spelling depends on Refactoring-Tests-Critics. >> >> Lukas >> >> 2010/9/25 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> > >> > >> > 2010/9/5 Lukas Renggli <renggli(a)gmail.com> >> >> >> >> I've split the refactoring model into various packages as outlined in >> >> the previous mail. >> >> >> >> The dependencies between the tests are slightly problematic, but will >> >> eventually be fixed as depicted in red in the attached dependency >> >> graph. It shouldn't matter for loading, so there is no hurry. >> >> >> > >> > Lukas, and what happens with 'Refactoring-Spelling'Â Â ?? >> > >> > is this still valid? >> > >> > package: 'Refactoring-Spelling' with: [ >> > Â Â Â Â Â Â Â Â Â Â Â Â spec requires: 'Refactoring-Core'. >> > Â Â Â Â Â Â Â Â Â Â Â Â spec postLoadDoIt: #postLoadRBSpelling ]; >> > Â Â Â Â Â Â Â Â Â package: 'Refactoring-Tests-Spelling' with: [ spec requires: >> > 'Refactoring-Spelling'. ]. >> > >> > >> > thanks >> > >> > mariano >> > >> > >> >> >> >> Thank you for updating the configuration Mariano. Note that >> >> OB-Refactory depends on all the non-test packages. >> >> >> >> Lukas >> >> >> >> On 4 September 2010 14:01, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> wrote: >> >> > >> >> > On Sep 4, 2010, at 1:08 PM, Lukas Renggli wrote: >> >> > >> >> >>>> I agree that SystemNavigation is ugly, but *a lot* of existing >> >> >>>> code >> >> >>>> depends on it. >> >> >>> >> >> >>> Well if I start forking all the classes that we should fix because >> >> >>> there are used it will be endless. >> >> >>> I was thinking to start also to look at senders and use deprecate. >> >> >>> >> >> >>> do you have a lot of external tools that use it? >> >> >> >> >> >> Yes, all tools use it: >> >> >> >> >> >> Â Monticello, Paragraph Editor (new and old), OmniBrowser, >> >> >> eCompletion, Refactoring Engine. >> >> >> >> >> >> Now I removed its use from the BrowserEnvironment in the refactoring >> >> >> engine itself. There are still a couple of references though, where >> >> >> people used the wrong abstraction layer when implementing stuff >> >> >> (platform code instead of the abstraction of the refactoring >> >> >> engine). >> >> >> >> >> >>> So what do you suggest? >> >> >>> Separating BrowserEnvironment and its superclass from RB and >> >> >>> starting >> >> >>> to >> >> >>> Â Â Â Â - check its api >> >> >>> Â Â Â Â - improve it >> >> >>> Â Â Â Â - migrate caller of systemNavigation -> BrowserEnvironment >> >> >>> (rename browserEnvironment) >> >> >> >> >> >> Yeah, maybe one step would be to split the refactoring engine into >> >> >> smaller and independent packages: >> >> >> >> >> >> Â AST-Core (that already is separate) >> >> >> Â Refactoring-Environment (this is currently part of >> >> > >> >> > yes this would be good so that we can start do the idea with the >> >> > integration related to systemDictionary been a potential leave of the >> >> > composition >> >> > tree we talked last time you visit us. >> >> > >> >> >> Refactoring-Core, but would work independently) >> >> >> Â Refactoring-Changes (this is currently part of Refactoring-Core, >> >> >> but would work independently) >> >> > >> >> > yes I'm curious to see if/how we could use changes to represent >> >> > changeset. >> >> > >> >> > >> >> >> Â Refactoring-Refactorings (this is currently part of >> >> >> Refactoring-Core and depends on all of the above) >> >> >> Â Refactoring-Lint (this is currently part of Refactoring-Core and >> >> >> depends on all of the above) >> >> >> >> >> >> Like this Pharo could integrate Refactoring-Environment and >> >> >> Refactoring-Changes independently. >> >> > >> >> > :) >> >> > >> >> >> I'll see if I can repackage the refactoring browser a bit, might >> >> >> take >> >> >> a while though because the tests are not that nicely separated. >> >> > >> >> > I imagine. >> >> > Now incremental changes is the only way for us :) >> >> >> >> >> >> Lukas >> >> >> >> >> >> -- >> >> >> Lukas Renggli >> >> >> 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 >> >> > >> >> > >> >> > _______________________________________________ >> >> > Pharo-project mailing list >> >> > Pharo-project(a)lists.gforge.inria.fr >> >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > >> >> >> >> >> >> >> >> -- >> >> Lukas Renggli >> >> 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 >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Lukas Renggli >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Sept. 25, 2010