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

Re: [Pharo-project] MuTalk: Mutation Testing for Pharo Smalltalk
by StÃ©phane Ducasse Sept. 26, 2010

Sept. 26, 2010

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

3 2

[Pharo-project] Squeak/Pharo Talk
by DeNigris Sean Sept. 26, 2010

Sept. 26, 2010

The presentation was great! There were about 10 Squeak/Pharo-ers there, from hobbyists to a surprise XEROX-PARC celebrity :) We had a dialogue, nudged along by a slideshow, which I posted at http://seandenigris.com/blog/?p=541 Sean

1 0

Re: [Pharo-project] [Vm-dev] VM Maker: VMMaker-oscog.33.mcz
by Mariano Martinez Peck Sept. 26, 2010

Sept. 26, 2010

On Sun, Sep 26, 2010 at 1:45 PM, stephane ducasse < stephane.ducasse(a)gmail.com> wrote: > > Eliot > > I wanted to understand what: ' Have various places check for > isOopCOmpiledMethod: > rather than isCompiledMethod: to allow SmallIntegers to be used as > methods.' > means > in which circumstances do we want to have smalltalkIntegers used as > methods? > when we put an object instead of a compiled method and that by > accident this is an integer? > > Eliot, first of all, thanks A LOT!!! This is really important for us....wiiii we have TestCoverage again :) BTW, I think I found something related to what Stef says....In normal squeakVM : testAddNumbers self assert: (self add: 3 with: 4) = 7. self assert: (self perform: #add:with: withArguments: #(3 4)) = 7. this is ok, since (self perform: #add:with: withArguments: #(3 4)) answers 7. But with this new CogVM, there is a primitiveError. so...we can update the test to: self should: (self perform: #add:with: withArguments: #(3 4)) rise: Error. or something like that....but this test will fail with normal VM.. what we should do? thanks mariano > Stef > > > > > > > > Name: VMMaker-oscog.33 > > Author: eem > > Time: 25 September 2010, 7:13:51 am > > UUID: 733b7c50-b973-4ca0-9831-5c84d09032bf > > Ancestors: VMMaker-oscog.32 > > > > OSCogVM: > > Support object-as-method: > > Eagerly evaluate the interpreter version of a primitive > > to ease the object-as-method implementation and to > > improve interpreter performance. > > Refuse to enter anything that isn't a CompiledMethod > > into the method-lookup cache to avoid open PICs having > > to check for valid compiled methods. > > Have various places check for isOopCOmpiledMethod: > > rather than isCompiledMethod: to allow SmallIntegers to > > be used as methods. > > Interpreter: > > Have various places check for isOopCOmpiledMethod: > > rather than isCompiledMethod: to allow SmallIntegers to > > be used as methods. > > Slang: > > support super sends by expanding them at translation > > time. This allows CoInterpreter>>addMethodToCache > > to avoid cacheing non-compiled methods via a super > > send, avoiding duplicating SrackInterpreter's method. > > > >

1 0

Re: [Pharo-project] systemNavigation cleaning
by StÃ©phane Ducasse Sept. 26, 2010

Sept. 26, 2010

On Sep 25, 2010, at 10:45 PM, Lukas Renggli wrote: > 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). yes! > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Re: [Pharo-project] #copy and friends
by StÃ©phane Ducasse Sept. 26, 2010

Sept. 26, 2010

+ 1 http://code.google.com/p/pharo/issues/detail?id=3004 Stef On Sep 26, 2010, at 2:21 AM, Levente Uzonyi wrote: > 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Re: [Pharo-project] [Vm-dev] VM Maker: VMMaker-oscog.33.mcz
by StÃ©phane Ducasse Sept. 26, 2010

Sept. 26, 2010

Thanks Eliot Here this is the total pressure. Deadline yesterday and some for a week. So I hope that we will be back on track soon. Marcus will certainly check because this is something really important for us. Alex too. Stef > I would appreciate anyone interested in objects-as-methods on Cog pounding on the latest Cog VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2313/) as this involved substantial changes to method lookup/inline cacheing machinery and there could easily be bugs. The tests run, but they're insubstantial compared e.g. to a full coverage test. > > best > Eliot > > (repeat with fixed email address: squeakfountation => squeakfoundation) > > On Sat, Sep 25, 2010 at 9:20 PM, <squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://www.squeaksource.com/VMMaker/VMMaker-oscog.33.mcz > > ==================== Summary ==================== > > Name: VMMaker-oscog.33 > Author: eem > Time: 25 September 2010, 7:13:51 am > UUID: 733b7c50-b973-4ca0-9831-5c84d09032bf > Ancestors: VMMaker-oscog.32 > > OSCogVM: > Support object-as-method: > Eagerly evaluate the interpreter version of a primitive > to ease the object-as-method implementation and to > improve interpreter performance. > Refuse to enter anything that isn't a CompiledMethod > into the method-lookup cache to avoid open PICs having > to check for valid compiled methods. > Have various places check for isOopCOmpiledMethod: > rather than isCompiledMethod: to allow SmallIntegers to > be used as methods. > Interpreter: > Have various places check for isOopCOmpiledMethod: > rather than isCompiledMethod: to allow SmallIntegers to > be used as methods. > Slang: > support super sends by expanding them at translation > time. This allows CoInterpreter>>addMethodToCache > to avoid cacheing non-compiled methods via a super > send, avoiding duplicating SrackInterpreter's method. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] reminder: you are all welcome to participate to the sprint friday.
by StÃ©phane Ducasse Sept. 26, 2010

Sept. 26, 2010

Hi guys we will have a sprint friday to prepare the beta of 1.2 and you are welcome to participate. The place will be probably at INRIA lille Now please register at: http://code.google.com/p/pharo/wiki/PharoSprints so that we get information for the organization. Stef

1 0

Sept. 26, 2010

Yes it is a polymorph features. I ask gary to have a look when he has time. Stef On Sep 25, 2010, at 10:52 PM, Guillermo Polito wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

Sept. 26, 2010

Thanks!!! Because this bug is annoying. At one point we will have to dive into MC :). So many things to do. ;) Stef > We had a similar problem in squeaknos package, but just for some kind of classes. It was caused by having an initialize class method in classes derived from ExternalStructure, maybe it's because of the same reason? look there, you may get some answers. > > regards, > javier. > > 2010/9/26 Norbert Hartl <norbert(a)hartl.name> > FYI I encountered the same problem in gemstone. The only thing I know is that all loaded packages were created in pharo that showed this behaviour. It didn't show up in a reproducable manner and some packages were clean again after a few package updates. And for some month now I didn't see it. > > Norbert > > > Am 25.09.2010 um 21:12 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> On Sat, Sep 25, 2010 at 9:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote: >> >> > Hi. I am having a probem with Glorp and I really have no idea what can be. The problem is that I load the package Glorp and just after loading, I do a "changes" in the MC Browser and I see a lot of classes with a lot of changes and all of them like "revison changed". This is annoying since it doesn't let me easily see what I have really changed. >> > >> > To reproduce: >> > >> > - Load the package "Glorp" from http://www.squeaksource.com/SqueakDBX >> > - Open a MC Browser, select Glorp package and press the "Changes" button agains the ss repo. And you will see :) >> >> May be the image used to save the package got a problem and changed the timestamp of the methods. >> So when you merge you get changed methods. >> >> I've just tried commiting and load them in a clean image...same problem. >> >> And if it were what you say...is there a solution? >> >> thanks >> >> mariano >> >> >> > >> > Any help is really appreaciated. >> > >> > Thanks >> > >> > Mariano >> > _______________________________________________ >> > 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 > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] NativeBoost opportunties?
by Schwab,Wilhelm K Sept. 26, 2010

Sept. 26, 2010

Sig, Today, I ran into a bug of mine that I would not have had to track down if the various typed byte arrays (double in particular) existed. The more you can offer in that area, with indexing, bulk fill, bulk copy, etc., the better. I also ran into what appears to be a maximum number of arguments to an external call. Can you get around that? I can too, in this case. It's shameless, but I will "dumb down" the call so that FFI can handle it. There are arguments that I can default or provide from a shared library, and just call into a facade function exported from there. Shouldn't have to do that, clearly, but it will work. Bill

2 1