January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Can we override == in Pharo ?

by Marcus Denker

On 07 Jan 2014, at 03:10, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > I don't like all these messages with no lookup. I don't even know if this permits to earn performance now that we have inline caches. > > Well, the arithmetic selectors *really* pay their way. Try your experiment with #+ through #~= and I bet you'll see slower loops. I think there's a compromise, which is to only inline the arithmetic selectors. That's what we did with the VisualWorks VM, HPS. There one can set a hidden flag in the image which directs the JIT (HPS only has a JIT) not to inline #== (VW does not inline #class), and change the flag with a primitive. We could (and I think should) do the same. Note that currently only #== and #class are inlined for all objects. The arithmetic selectors #+ et al and #< et al are only inlined by the JIT for SmallInteger, and executed without lookup in the interpreter for SmallInteger x Float. > We removed the #class inclining in Pharo in 2.0 (so already when the old compiler is used). Marcus

Jan. 7, 2014

fixing the search in the MC browser would be sooooo cool

by StÃ©phane Ducasse

Hi guys if you want to help, the search (left) in the mCBrowser (once we do Open) is totally broken. It is a pain to look for packages when we have to check things. There is a bug entry (I od not remember its number). Stef

Jan. 7, 2014

Re: [Pharo-dev] Athens SVG Import

by StÃ©phane Ducasse

Hi rick Thanks for your email :) > This message is mainly for Igor, who probably already curses every time he sees my name on the development list. But, perhaps others have had some experience with this as well. No igor is not like that. He loves to see people using what he did and improving in case so please continue. This is the best motivation for igor. > I'm still working on moving my touch applications to Athens. I am running into a major problem with icons. My applications tend to have quite a few icons in them. In the old BitBlt versions, I just used forms for the icons. That same approach fails with Athens as form rendering is time consuming. With just ten medium-sized forms open in my AthensWrapMorph, the system starts to crawl. My guess is that form rendering needs to be sped up before Athens can be widely adopted. Using the form as a paint, while flexible, seems pretty intense. Yes because the buffer is copied several times around. Igor and Ronie started laste thursday an effort to see how to shortcut all the buffers to speed up the system. > Anyway, for most of my applications, switching over to vector-based graphics would be a better choice as it would allow for me to more easily scale to different screen sizes. So, I was excited to try the SVG import. Now that the XMLParser is working, I am running into some problems with the SVG import code. It seems that it doesn't support some of the features that an SVG export from Illustrator produces. I was wondering if I could get some help there. Yes!!!! > First, Illustrator tends to spit out SVGs that use #reflectedCubicBezier curves, which is not yet implemented. I remember that he started to add some functionalities that were not supported by Cairo like arc something. > Second, I found a small bug in ASPathConverter>>readPoint The "self skipBlanks" has to be changed to "self skipBlanksAndComma" or multiple points cannot be read in sequence. Igor will give you access to commit because we need more people helping and improving. > > Third, while ASPathConverter supports vLineTo: and hLineTo:, AthensCairoPathBuilder does not. I tried implementing these myself but they apparently don't work the way I thought they should. > > Here are two examples of the kind of SVG files I would like to read: > button-swapShapes.svg - This one fails because of vLineTo: and hLineTo: > button-erase.svg - This one fails because of reflectedCubicBezier curves. > > Cheers, > > Jeff > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick

Jan. 7, 2014

Re: [Pharo-dev] Spotlight Demo

by Sean P. DeNigris

Tudor Girba-2 wrote > First, would it be Ok with you to move the project to a more public place Great, whereever you think... Tudor Girba-2 wrote > Second, I created a configuration with a development and stable version. Cool, thanks :) Tudor Girba-2 wrote > Please note that I named the configuration Spotter, > because there already exists a ConfigurationOfSpotlight for the widget of > Esteban. Would it be Ok to change the name of the classes, too, to avoid > confusion? I would prefer ConfigurationOfNewSpotlight or ConfigurationOfSpotlight2. Spotlight is what we are modeling, and introducing a new term will I think generate more confusion (i.e. "what the heck is a Spotter" vs. "oh, cool, just like the Mac Spotlight that I already use"). Tudor Girba-2 wrote > Third, I think we should not mix the morph with the global shortcut. I > understand this is convenient, but these should pretty much be different > projects. Is that Ok with you? I guess as a compromise I can just extract the shortcut into another package, so the default will not integrate with the system, and loading the additional package will. For me, I want this widget to come up on shift + cr. Tudor Girba-2 wrote > Fourth, I would like to theme this morph, too :). With this occasion, I > would like to try a slightly different design for handling the theme code. This is exciting. I found Polymorph / Themes to be very confusing. I welcome another look at this. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spotlight-Demo-tp4733076p4734781.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 7, 2014

Re: [Pharo-dev] Spotlight Demo

by Sean P. DeNigris

StÃ©phane Ducasse wrote > then type string and remove character by chracter and the last one crashes > completely the system Thanks! Spotlight-SeanDeNigris.25 Fixed error when last character removed from text field e.g. by backspace. Thanks for Steph for the report. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Spotlight-Demo-tp4733076p4734780.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 7, 2014

Re: [Pharo-dev] Can we override == in Pharo ?

by Eliot Miranda

Hi Clement, On Mon, Jan 6, 2014 at 4:42 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > So I tried and it worked. > > In Opal to remove the usage of #==, I removed it from the special selector > array in the method: > IRBytecodeGenerator class>>specialSelectorsArray > ^ #(#+ 1 #- 1 #< 1 #> 1 #<= 1 #>= 1 #= 1 #~= 1 #* 1 #/ 1 #\\ 1 #@ 1 > #bitShift: 1 #// 1 #bitAnd: 1 #bitOr: 1 #at: 1 #at:put: 2 #size 0 #next 0 > #nextPut: 1 #atEnd 0 #== 1 nil 0 #blockCopy: 1 #value 0 #value: 1 #do: 1 > #new 0 #new: 1 #x 0 #y 0) > > Then I ran: > IRBytecodeGenerator initialize. > OpalCompiler recompileAll. > > Then in my example: > > A>>== > ^ true > > a := A new. > b := A new. > a == b answered true, so it worked. > > I don't like all these messages with no lookup. I don't even know if this > permits to earn performance now that we have inline caches. > Well, the arithmetic selectors *really* pay their way. Try your experiment with #+ through #~= and I bet you'll see slower loops. I think there's a compromise, which is to only inline the arithmetic selectors. That's what we did with the VisualWorks VM, HPS. There one can set a hidden flag in the image which directs the JIT (HPS only has a JIT) not to inline #== (VW does not inline #class), and change the flag with a primitive. We could (and I think should) do the same. Note that currently only #== and #class are inlined for all objects. The arithmetic selectors #+ et al and #< et al are only inlined by the JIT for SmallInteger, and executed without lookup in the interpreter for SmallInteger x Float. > @Frank Shearar > Just a detail, #timesRepeat: is not inlined any more by default in Pharo > 3.0 because there were conflicts with a stream library. Anyway it didn't > provide a lot of performance (just removed 1 indirection). > > > > > > > 2014/1/6 Frank Shearar <frank.shearar(a)gmail.com> > >> On 6 January 2014 11:11, Nicolai Hess <nicolaihess(a)web.de> wrote: >> > 2014/1/6 ClÃ©ment Bera <bera.clement(a)gmail.com> >> >> >> >> Hello, >> >> >> >> here I have a class >> >> >> >> A>>== >> >> ^ true >> >> >> >> Now: >> >> a := A new. >> >> b := A new. >> >> a == b "Answers false" >> >> a perform: #== with: b "Answers true" >> >> >> >> Do I have to remove the usage of the byte code for #== in the compiler >> to >> >> be able to override == ? >> >> >> >> >> > >> > >> > No, a==b should be used for "are the same Objects" (pointing to the same >> > object) and not "are equal". >> > Look for example at the commentn for ProtoObject>>== >> >> Given the kinds of things ClÃ©ment does, I suspect he knows full well >> the difference between #== and #=. >> >> My understanding is that the compiler inlines #== sends like it does >> with #timesRepeat: and ifTrue:ifFalse:. So yes, you'd need to fiddle >> with the compiler for any #== overrides to actually run. >> >> (I'm keen for Marcus to show us how exactly to do that in Opal!) >> >> frank >> >> > Nicolai >> >> > -- best, Eliot

Jan. 7, 2014

Re: [Pharo-dev] some questions about Object and Spec

by Esteban A. Maringolo

So it seems you don't follow your doctor advice. :) Esteban A. Maringolo 2014/1/6 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi ben > > I was looking at Spec code and I wonder why we have these methods in Object? > > asWidget > > ^ self > > I do not get why any object could get a widget. > > isSpecAdapter > > ^ false > > since an adapter is a subclass of Morph why can we move it to morph? > If in the future we have other adapter then we will just add isSpecAdapter to the root of the new hierarchy. > > isSpecLayout > > ^ false > > For this one I did not have an idea. > > Stef

Jan. 6, 2014

some questions about Object and Spec

by StÃ©phane Ducasse

Hi ben I was looking at Spec code and I wonder why we have these methods in Object? asWidget ^ self I do not get why any object could get a widget. isSpecAdapter ^ false since an adapter is a subclass of Morph why can we move it to morph? If in the future we have other adapter then we will just add isSpecAdapter to the root of the new hierarchy. isSpecLayout ^ false For this one I did not have an idea. Stef

Jan. 6, 2014

Re: [Pharo-dev] [Glass] printString and asString

by Tudor Girba

+1 On Mon, Jan 6, 2014 at 4:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > + 1 > > >>>> I need for example a string representation of objects generally to > >>>> display in anchors in our seaside application. We have a class > >>>> DomainObject from which most of our classes inherit, so this is > >>>> probably the place to add a 'displayString' for something like this. > >>> > >>> Not necessarily domain objects only. > >>> > >>> Some core objects (Blocks, CompiledMethods, etc.) could benefit from > >>> having a developer string representation (#printString) and a UI > >>> string representation (#displayString). > >> > >> I don't really understand why. How would you distinguish between which > >> (kinds of) core objects and which not? Will you not end up with a > >> displayString on Object again? > > > > Yes, I want displayString on Object. > > > > What I don't like is #asString in Object. > > > > I want to be able to do: > > Transcript show: anyObject displayString. > > > > Without getting a single quoted output if anyObject was a String. > > > > Regards. > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 6, 2014

Re: [Pharo-dev] Spotlight Demo

by Tudor Girba

Hi Stef, On Mon, Jan 6, 2014 at 5:54 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Ok I read > > > UITheme would act as a theme factory. > and each widget delegate to the Themer associated to themselve and the > current theme > > So subclasse of UITheme can propose different themer for the same widget. > Exactly. > Now since the themer is a separate class (from the morph it means that you > must have all the hooks to customise it). > So why not. > I was also thinking that a widget could be an âabstractâ class whose > subclasses implement the themes. > > Then you would create a widget like that > > > SpolightItemMorph forThemer: UITheme blue > and it would create an instance of a subclas SpotligherBluerItemMorph. > > Did you try this design? > I think this is too convoluted because, like Estaban says, you want to keep the theming orthogonal with widget definition. But, you gave me an idea: If we implement in Morph the followings: Morph>>themer ^ themer ifNil: [self themerFor: self theme] Morph>>themerFor: aTheme ^ self subclassResponsibility And then in a morph we would have something like this: SpotlightItemMorph>>themerFor: aTheme ^ aTheme spotterThemer SpotlightItemMorph>>onSelected self themer configureSelectedItemMorph: self Then we could simply do pretty much what you want: SpotlightItemMorph new themer: MySpotterThemer new. I like this idea. What do you think? Doru Stef > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 6, 2014