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

Re: [Pharo-project] About SourcedMethodReference

by StÃ©phane Ducasse

On Nov 9, 2010, at 10:57 PM, Igor Stasenko wrote: > I think identity is better. It forcing more strict rules: no more than > one method reference > in system necessary for representing same method. I'm not sure I understand exactly what you mean. In the recent message or in the versions, you get mulitple version of the "same" methods but different methodreference. > > On 9 November 2010 23:48, Luc Fabresse <luc.fabresse(a)gmail.com> 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? >> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

Nov. 10, 2010

Re: [Pharo-project] Smalltalks 2010

by StÃ©phane Ducasse

no idea ask the organizer On Nov 10, 2010, at 11:08 AM, Torsten Bergmann wrote: > Will "Smalltalks 2010" in Argentina be recorded to provide > the sessions on the web later or streamed to the web similar > to ESUG? > > Thx > T. > -- > GRATIS! Movie-FLAT mit Ã¼ber 300 Videos. > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome >

Nov. 10, 2010

[Pharo-project] squaksource up again

by Fabrizio Perin

Nov. 10, 2010

[Pharo-project] Smalltalks 2010

by Torsten Bergmann

Will "Smalltalks 2010" in Argentina be recorded to provide the sessions on the web later or streamed to the web similar to ESUG? Thx T. -- GRATIS! Movie-FLAT mit Ã¼ber 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

Nov. 10, 2010

[Pharo-project] squeaksource under maintenance back again in an hour i hope

by Fabrizio Perin

Nov. 10, 2010

Re: [Pharo-project] About SourcedMethodReference

by Benjamin

On Nov 10, 2010, at 8:43 AM, Johan Brichau wrote: > There is still a lot to be done, so I did not know the changes were > already integrated ;-) > But the subclassing construction is temporary to allow code to > migrate to the new sourcereference framework. > > Benjamin: is the latest version in 1.2 or on pharotaskforce or ... ? > The last version is in !.2, and I'm still working on killing MethodReference references (I've done a ChangeSorter, I'm still playing with it, expecting for explosions ^^ If you want to play with it too, just say it to me) Ben > > On 10 Nov 2010, at 04:22, Benjamin 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 = >> >>> 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] About SimpleMorphic

by Fernando Olivero

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. 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? 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. Fernando pd: i couldnt go to Smalltalks this year, so sadly i wont see you next talk on Morphic3.0? I will continue to play with you layout morphs, and possibly adapt them to Pharo. Fernando On Tue, Nov 9, 2010 at 4:58 PM, Juan Vuletich <juan(a)jvuletich.org> wrote: > Hi Fernando, > > Fernando Olivero wrote: >> Hi Juan, i have a couple of questions regarding the new Cuis layout, >> which by the way , is a much cleaner implementation!. >> > > Good! Did you play a bit with the examples in LayoutMorph class methods? > They are kinda cool. For instance, do LayoutMorph example3, enlarge the > morph and remove some of the submorphs, and see how the layout adjust > itself. > >> "LayoutSpecs are the basis for a new layout mechanism, alternative to >> LayoutFrame. Any Morph can be given a LayoutSpec, but in order to >> honor it, the morph must be submorph of a LayoutMorph." >> >> In my opinion, we dont need to enforce the LayoutMorph subclasification. >> > > Well, I guess you misread. I didn't say 'subclass of LayoutMorph'. I > said 'submorph of a LayoutMorph' :) > >> Because Morph>>doLayoutIfNeeded could use its "layoutMorphSpec" >> collaborator, if present. >> >> doLayoutIfNeeded >> Â Â Â ... >> Â Â Â [self layoutSpec layoutSubmorphsIn: self layoutBounds] on: Error do: [ :ex | >> Â Â Â Â ... >> What do you think? >> >> Fernando >> >> pd: Similar to decoupling the "visual layout properties" that Brazil is doing. >> > > Well, LayoutSpec is quite like what Brazil does. For example, from the > Brazil description: "When the same visual is a child of a Row, the area > is an instance of a different class whose attributes and behavior are > meaningful for a row cell." Looks like the main difference is that I > merged the Row object and the Area object in the LayoutMorph object. > > Cheers, > Juan Vuletich > Ps. Do you happen to be in Buenos Aires these days? We'd meet! > >> On Mon, Nov 8, 2010 at 3:05 PM, Juan Vuletich <juan(a)jvuletich.org> wrote: >> >>> Hi Folks, >>> >>> WRT Layout APIs, SimpleMorphic includes the same simplified version of >>> LayoutFrame as Cuis. >>> >>> Cuis also includes a new approach, implemented in LayoutSpec and >>> LayoutMorph. I did this for an application that requies adding new >>> widgets without specifying a new layout for all of them. It is also >>> nicer than LayoutFrame, and will replace it at some moment. But it is >>> not used at all by SimpleMorphic or Cuis, and that's why I did not >>> include it in SimpleMorphic for Pharo. But you might open Cuis and take >>> a look it, and load it in Pharo if you like. Try the example class >>> methods in LayoutMorph, and resize the morph to see what it can do. >>> >>> Cheers, >>> Juan Vuletich >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> No virus found in this incoming message. >>> Checked by AVG - www.avg.com >>> Version: 9.0.864 / Virus Database: 271.1.1/3246 - Release Date: 11/09/10 04:34:00 >>> >>> > > >

Nov. 10, 2010

Re: [Pharo-project] About SourcedMethodReference

by Johan Brichau

There is still a lot to be done, so I did not know the changes were already integrated ;-) But the subclassing construction is temporary to allow code to migrate to the new sourcereference framework. Benjamin: is the latest version in 1.2 or on pharotaskforce or ... ? On 10 Nov 2010, at 04:22, Benjamin 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 = > >> 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] About SourcedMethodReference

by Benjamin

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 = > 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] Strange graphics effect (getting Pharo running on the RoarVM)

by David T. Lewis

On Tue, Nov 09, 2010 at 11:06:30PM +0100, Stefan Marr wrote: > Hi: > > On 09 Nov 2010, at 17:00, Juan Vuletich wrote: > > > Looks like you're using an outdated, buggy BitBlt plugin. I fixed several issues there some time ago. > > Thank you all, that seems to be the problem. > > > Have ported the changes from [1], and it works beautiful :) > > Bye the way, there are a number of 'unsigned int's in function declarations which probably are supposed to by usqInt for consistency. These are probably correct as written. The sqInt and usqInt types may be either 32 or 64 bits in size, depending on whether the image is a 32 or 64 bit object memory. So if something is meant to be 32 bits, you'll find it explicitly declared as an int or unsigned int. There is an explanation of the terms at http://squeakvm.org/squeak64/faq.html Dave

Nov. 10, 2010