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

Re: [Pharo-project] About SourcedMethodReference

by Johan Brichau

On 10 Nov 2010, at 12:14, Eliot Miranda wrote: > Why do you want to remove MethodReference? The work was initiated from Benjamin's work on a new browser for 'recent changes', which basically needs to manipulate source references. MethodReference is being used to this end in various parts of the system but it represents various different things: class comment reference, method source reference, class definition reference, etc.. In addition, it always represents a reference to the current source. To retrieve older versions of the source, you need to walk the changes stream yourself. Last but not least, various different tools are walking the changes file with different implementations. >From that experience, the idea arose to create a sourcereference model that explicitly models the different source elements (methods, class comments, definitions, etc) and that has explicit timestamping. At the same time, we don't want to break existing tools and have embedded the exisiting MethodReference in that model. Johan

Nov. 10, 2010

Re: [Pharo-project] ExternalIconFamily framework finally decoupled from Gaucho

by Juan Vuletich

Hi Fernando, Fernando Olivero wrote: > Hi, i set up the repo here http://www.squeaksource.com/ExternalIconFamily > > "This framework allows importing and managing any external icon > family. Once imported , the icon family is reified into the image, > As an example it comes with the Oxygen icon family imported, to load > others see the example named OxygenIconFamilyBuilder. > Subclasses of ExternalIconFamily act as caches for all the forms, that > were requested previously. > To load a form send, ExternalIconFamily>>iconNamed: aString size: aNumber " > > Now the integration to UITheme is missing, i will try to have a > working example soon. > > Fernando > I like it! Just a couple of details: GMIconFamily and GMIcon are Undeclared in PharoCore-1.2-12146. And a few methods use underscores in the selector... Cuis supports it, but I prefer having the preference off by default. I think underscores in identifiers should only be used when there are very strong reasons. And I don't see them here. Could you consider removing them? Cheers, Juan Vuletich

Nov. 10, 2010

Re: [Pharo-project] About SimpleMorphic

by Juan Vuletich

Hi Fernando, Fernando Olivero wrote: > I just ran the examples, and just can say...NICE!! > > m := LayoutMorph example3 > m width: 400. > m width: 600. > row := m submorphs anyOne. > row submorphs last delete. > row delete. > m delete. > > I've just added these lines to the example. You can find the minor > changes in the attached changeset. > Thanks! > AH! i've misread the submorph of LayoutMorph part. > > Still i think that LayoutMorph does not necessarily have to be a > Morph, because it only has the responsibility of laying out a group of > "rectangles" right? My comments were in this direction, to decouple > LayoutMorph from Morph. I couldn't tell if Brazil's Area is a "Brazil > visual", but i ask why not decuple it? > That would be an interesting experiment. I guess these non-morph object in the morph / submorphs tree will need to support many messages of the Morph protocol. I guess someone needs to do it and see if the results are good. Go for it! > When i did my own GauchoLayouts i've implemented like this, but now i > would like ditch them and use your classes and merge them with Morph. > You already did non-morph objects in the submorph tree? How was the result? Do you like it? Can we see the code? > Fernando > pd: i couldnt go to Smalltalks this year, so sadly i wont see you next > talk on Morphic3.0? > Well, I'm not giving a talk this year, so at least you're not missing that :( > I will continue to play with you layout morphs, and possibly adapt > them to Pharo. > Fernando Great! Cheers, Juan Vuletich

Nov. 10, 2010

Re: [Pharo-project] About SimpleMorphic

by Hannes Hirzel

On 11/10/10, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: > I just ran the examples, and just can say...NICE!! > > m := LayoutMorph example3 > m width: 400. > m width: 600. > row := m submorphs anyOne. > row submorphs last delete. > row delete. > m delete. > .... > Still i think that LayoutMorph does not necessarily have to be a > Morph, because it only has the responsibility of laying out a group of > "rectangles" right? My comments were in this direction, to decouple > LayoutMorph from Morph. I couldn't tell if Brazil's Area is a "Brazil > visual", but i ask why not decuple it? Good question --- I am curious to see what the answers will be..... --Hannes

Nov. 10, 2010

[Pharo-project] ExternalIconFamily framework finally decoupled from Gaucho

by Fernando Olivero

Hi, i set up the repo here http://www.squeaksource.com/ExternalIconFamily "This framework allows importing and managing any external icon family. Once imported , the icon family is reified into the image, As an example it comes with the Oxygen icon family imported, to load others see the example named OxygenIconFamilyBuilder. Subclasses of ExternalIconFamily act as caches for all the forms, that were requested previously. To load a form send, ExternalIconFamily>>iconNamed: aString size: aNumber " Now the integration to UITheme is missing, i will try to have a working example soon. Fernando

Nov. 10, 2010

Re: [Pharo-project] Added Issue 3223 : Replace all sends to compile: in SystemNavigationTest by compileSilently:

by StÃ©phane Ducasse

tx! On Nov 9, 2010, at 10:07 PM, Luc Fabresse wrote: > Fix in pharo task forces Tests-LucFabresse.242 > > #Luc

Nov. 10, 2010

Re: [Pharo-project] About SourcedMethodReference

by StÃ©phane Ducasse

> Why do you want to remove MethodReference? To be able to have MethodReferenceWithSource which will be renamed MethodReference and in the same time not put the system on its knees. ;) Right now MethodReference and friend sucks even if I already fixed a lot of Feature Envy. I do not like the logic to read change files with case statement #Comment .... all the bad logic it implies. There is a lack of real objects there. When you read the code of RecentMessages or recovery you can faint and re fixed a lot of Feature Envy, Duplicated code in 1.2. A lot is happening in 1.2 under the surface and a lot more will happen in 1.3. We want a real declarative model of source code. Veronica will start to work on that. We want to store also **all** the code of all the version in a database so that we can do real versions queries. Now the changes made on MethodReference are to make sure that we can have two methodReference with the same selector, class, but a different timestamp and source code. Like what we see in versions and recent changes, but done in a much better way. Benjaman rewrote completely recentMessages and this is great we can filter recentMessages based on time, class, packages..... and without the changes in MethodReference we had to put isKindOf and other nasty checks all over the place. So in summary, we want to put in place an infrastructure for building next generation tools. Ideally we will have ClassDefinition MethodDefinition InstanceVariableDefinition and migrate all the tools to them. We will experiment with that and certainly build a robust infrastructure for that. I hope it explains. We wrote a document explaining that. But now we should build it. Stef

Nov. 10, 2010

Re: [Pharo-project] squaksource up again

by StÃ©phane Ducasse

tx! I asked again inria to get a date for the web dav server. I hope to have an answer soon. On Nov 10, 2010, at 11:15 AM, Fabrizio Perin wrote: >

Nov. 10, 2010

Re: [Pharo-project] About SourcedMethodReference

by Eliot Miranda

On Tue, Nov 9, 2010 at 7:22 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > > On Nov 9, 2010, at 10:48 PM, Luc Fabresse wrote: > > Hi all, >> >> When SourcedMethodReference have been introduced, some tests in >> SystemNavigationTest turned yellow. >> The tests are currently expecting a MethodReference. >> If I modify the tests to exepect a SourcedMethodReference, the problem is >> now on: >> >> SourcedMethodReference>>= >> ^self == aMethodReference. >> >> Why this has been redefined in SourcedMethodReference? >> > > It has been redefined becausea the end, we want to remove MethodReference, > and this is the default behavior for the method = Why do you want to remove MethodReference? > > > I think that the super class (MethodReference) implementation is >> semantically better. No? >> >> MethodReference>>= anotherMethodReference >> "Answer whether the receiver and the argument represent the >> same object." >> ^ self species == anotherMethodReference species >> and: [(self classSymbol = anotherMethodReference >> classSymbol) >> and: [(self classIsMeta = >> anotherMethodReference classIsMeta) >> and: [self methodSymbol = >> anotherMethodReference methodSymbol]]] >> #Luc >> > > This method doesn't answer what we expect anymore, because here, two > references (with different source) pointing on two versions of the same > method are evaluate as equal, and we do not want that. > > About tests, JB and I had wrote a fix, but we have lost it ... > But I will take a look at that asap > > > Thank you for your feedback > > > Ben > > >

Nov. 10, 2010

Re: [Pharo-project] squaksource up again

by Fernando Olivero

grazie mille ragazzo! On Wed, Nov 10, 2010 at 11:14 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote: > >

Nov. 10, 2010