- Pharo-dev - lists.pharo.org

Re: [Pharo-project] In Smalltalk you can't loose code... hum
by StÃ©phane Ducasse Sept. 26, 2010

Sept. 26, 2010

On Sep 26, 2010, at 8:59 PM, Igor Stasenko wrote: > On 26 September 2010 21:53, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> 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. >>> >>> Yes. I told about potential use of new trailers, where we can implement a model >>> for storing/retrieving source code from any kind of storage. >>> >>> Unfortunately it requires some remodelling of system's source-code >>> management system, >>> to get rid of hard-wired SourceFiles code and add an abstract layer >>> for source management. >>> So we could implement different source managers, where .source and >>> .changes will be just default one. >>> >>> One of my ideas was to use CouchDB for storing everything there. It >>> opens quite interesting opportunities, >>> like being able to browse a history of some particular method up to >>> 1.0 squeak release :) >>> >>> @Stef: add this to pharo todo list :) >> >> but this one is on the path of veronica phd so we should do it fast. >> Veronica likes to work under pressure so this is good. >> > Haha.. so, when i described it sometimes ago you told that this good > for phd thesis, > you already had a plan & assignee for it :) I do not remember. doing too much stuff. Now the PhD of veronica is not one source code management. The PhD of veronica is about: how to help merging. How could we add a bit of semantics. In this topic we would like - to get changes characterization (cf ESUg talk) - to know the potential impact of a change - compare feature in the past and feature so having a good infrastructure will help everybody. We should be able to write nice and short queries to study the past and the present. Stef > > Nice. > >> stef >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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] ECUntypedModelTest >> testNarrowWith failing
by Mariano Martinez Peck Sept. 26, 2010

Sept. 26, 2010

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

2 1

Re: [Pharo-project] In Smalltalk you can't loose code... hum
by StÃ©phane Ducasse Sept. 26, 2010

Sept. 26, 2010

>> 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. > > Yes. I told about potential use of new trailers, where we can implement a model > for storing/retrieving source code from any kind of storage. > > Unfortunately it requires some remodelling of system's source-code > management system, > to get rid of hard-wired SourceFiles code and add an abstract layer > for source management. > So we could implement different source managers, where .source and > .changes will be just default one. > > One of my ideas was to use CouchDB for storing everything there. It > opens quite interesting opportunities, > like being able to browse a history of some particular method up to > 1.0 squeak release :) > > @Stef: add this to pharo todo list :) but this one is on the path of veronica phd so we should do it fast. Veronica likes to work under pressure so this is good. stef

2 1

Re: [Pharo-project] In Smalltalk you can't loose code... hum
by StÃ©phane Ducasse Sept. 26, 2010

Sept. 26, 2010

> > > 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> I know I told you that a while ago when you were still at cincom (probably around 2002 or 2003 when doru started his phd :) In the way vw does it defeats the purpose of having a markup language. Now XML is good when we do not have a language syntax that can mimic a declarative language. I was always amazed that tweak could use xml to represent CField instead of using plain CField new name: #nameOfVariable; ... So instead of xml (which requires to have an XML parser at end. We could have MethodDefinition selector: #on: ; class: #Bar; body: 'on: aStream aStream nextPutAll: 'jlkjlkj'. ^ self'. this way no need for a bad parser. > Its not a lot of work. ALso VW has a simple scheme for supporting both old chunk format and "new" xml format. Probably the problem is that I would love to have 3 days in a row to code and be concentrated. And we cannot change eveyrthing at the same time. > 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. I have to digest that :) > > 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

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

Sept. 26, 2010

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. Eliminate the core classes for now. Stef

1 0

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

Sept. 26, 2010

On Sep 26, 2010, at 5:56 PM, Nicolas Chillo wrote: > We can start improving pharo tests but we should first sign de MIT License agreement. Shouldn`t we? would be good :) Stef >

1 0

Re: [Pharo-project] In Smalltalk you can't loose code... hum
by StÃ©phane Ducasse Sept. 26, 2010

Sept. 26, 2010

> > > > > 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). Again it will take time but we should have a good (why not 'exquise') infrastructure so that we extend and build new tool easily. Stef

4 3

[Pharo-project] OB failing test08Execution and
by Mariano Martinez Peck Sept. 26, 2010

Sept. 26, 2010

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

2 2

Re: [Pharo-project] ECUntypedModelTest >> testNarrowWith failing
by Mariano Martinez Peck Sept. 26, 2010

Sept. 26, 2010

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

2 2

[Pharo-project] Cannot make latest OCompletion work with latest OB
by Mariano Martinez Peck Sept. 26, 2010

Sept. 26, 2010

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

1 0