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

Re: [Pharo-dev] Xtreams in Pharo 3

by mkobetic＠gmail.com

"Sven Van Caekenberghe"<sven(a)stfx.eu> wrote: > On 20 Nov 2013, at 17:24, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > Sven Van Caekenberghe-2 wrote > >> Are there version differences with the VW code, and how do you see that > >> evolving ? > > > > When we looked a few years ago at ESUG in Ghent, the port was out-of-date > > with the VW code. We were able to patch filetree to bring the code > > round-trip to/from VW, mapping namespaces to prefixes. I have our > > experimental image somewhere if that would be helpfulâ¦ > > Well, years, not last ESUG but the one before, August 2012, and yes I remember, sitting next to you when you were hacking away. Yes, it's taking embarrassingly long, but we are inching forward. I've made some progress with the Cypress experiment, the github project (https://github.com/mkobetic/Xtreams) now has branches for VW, Pharo and ST/X. The branches still have differences that shouldn't be there, but we're getting there. It would be fantastic if Sean or somebody would meet me halfway with the Filetree tweaks for prefix to namespace mapping. Anyway, I still intend to get there eventually, but I have to admit that I'm spending a lot less time in Smalltalk these days. FWIW I definitely haven't lost interest though. That said, I think all three ports are relatively solid (Thanks Nicolas, Frank, Jan, ...!). The core components haven't changed much in a while (although there are few things that I would like to improve there, I'll create issues for those on google code eventually), so there shouldn't be much catching up to do. Most of the recent activity was building on top of the core, that's primarily where VW is ahead (multiplexing, compression, ...) and where more should be done (e.g. compression can offer a lot more beyond just deflate). > Maybe, you and Nicolas should sync up a bit. I'll also try to answer any questions that I'll notice on the mailing lists. I'm monitoring issues on google code, feel free to raise anything there as well. Martin > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: http://forum.world.st/Xtreams-in-Pharo-3-tp4723225p4723773.html > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > >

Nov. 21, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Eliot Miranda

Hi Sven, On Wed, Nov 20, 2013 at 11:33 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > > On 20 Nov 2013, at 18:53, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > > > > On Wed, Nov 20, 2013 at 8:47 AM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > The only thing that annoyed me is that I failed to discover the > incantation thru sender/implementor chain because some messages are > constructed... > > > > that's an anti-pattern to be avoided. One can use dictionaries to make > the link explicit, then one has a chance of tracking things down. Always > use something equivalent to > > > > self perform: (Dictionary newFromPairs: #(#timesRepeat: > #optimizeTimesRepeat: ...) at: message) with: ... > > > > instead of > > > > self perform: ('compile', message) asSymbol with: > > > > It'll be far clearer, and (cuz the dictionary will be precomputed) it'll > be faster too. > > I donât get the âbecause the Dictionary will be precomputedâ in the code > example you give. On the contrary, you will create a new Dictionary every > time you execute your example, no ? > It's an example. In real use you'd cache the translation dictionary in a variable, likely a class variable. See ClÃ©ment's reply; thats exactly what he did. cheers! > > > I tried the senders of timesRepeat: then the senders of corresponding > visitor message (no image near my keyboard to check the name). > > Of course, once you've learned the incantation, it's OK... > > > > > > 2013/11/20 Igor Stasenko <siguctua(a)gmail.com> > > > > > > > > On 19 November 2013 16:20, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > On 19 Nov 2013, at 16:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > Hi, > > > > > > It seems that #timesRepeat: is compiled/optimized away by Opal, which > is probably good. BTW, what is the list of selectors that get this > treatment ? > > > > > RBMessageNode has #isInlined that returns trueâ¦ not all cases where the > selector is send it is optimised, so a list would be one of > âpossiblyoptimizedâ selectorsâ¦ > > maybe #isInlined could check first against that list to quickly return > false for all the other selectors. > > > > > In the PEGParser example of Xtreams #timesRepeat: is implemented for a > non Integer class, which obviously leads to errors. > > > > > oh, yes, that is a problem. We started for ifTrue: to do an on-the-fly > re-compiling and executing the ifTrue:, but itâs a bit of work to get it > right for all casesâ¦ so we did not finish > > that. But it would be possible... > > > > > Is there a way to tune this ? > > > Can it be set at a level higher than in each method ? > > > > > > > Yes, you can do it per class-hierarchyâ¦ you can implement on the class > side a method to parametrize the compiler: > > > > compiler > > ^super compiler options: #(- optionInlineTimesRepeat) > > > > > > .. and i feel really glad that Marcus armed my idea of option > specification e.g. > > > > #(+ optionToEnable1 - optionToDisable anotherOptionToDisable + > optionToEnable2 ) > > > > :) > > > > > > Marcus > > > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > > > > -- > > best, > > Eliot > > > -- best, Eliot

Nov. 20, 2013

Re: [Pharo-dev] petit parser longest match

by Chris Cunningham

ehh, ignore this for now. Neither is working well enough. If I get something working well, I'll post back. On Wed, Nov 20, 2013 at 1:45 PM, Chris Cunningham <cunningham.cb(a)gmail.com>wrote: > Actually, do this [the #( 0 nil ) meant it was shared with ALL choice > parsers forever - not a good choice]. > > parseOn: aStream > "This is optimized code that avoids unnecessary block activations, do not > change. When all choices fail, the last failure is answered." > > | element longest | > longest := Array with: 0 with: nil. > 1 to: parsers size do: [ :index | > element := (parsers at: index) > parseOn: aStream. > element isPetitFailure > ifTrue: [ aStream position > longest first ifTrue: [ longest at: 1 put: > aStream position; at: 2 put: element ] ] > ifFalse: [ ^ element ] ]. > aStream position: longest first. > ^ element > > > On Wed, Nov 20, 2013 at 1:35 PM, Chris Cunningham <cunningham.cb(a)gmail.com > > wrote: > >> Ho about this (replacement for yours, or just replace in PPChoiceParser - >> but it will result in different behavior for that method outside of your >> particular parser, so beware): >> >> parseOn: aStream >> "This is optimized code that avoids unnecessary block activations, do >> not change. When all choices fail, the last failure is answered." >> >> | element longest | >> longest := #( 0 nil ). >> 1 to: parsers size do: [ :index | >> element := (parsers at: index) >> parseOn: aStream. >> element isPetitFailure >> ifTrue: [ aStream position > longest first ifTrue: [ longest at: 1 put: >> aStream position; at: 2 put: element ] ] >> ifFalse: [ ^ element ] ]. >> aStream position: longest first. >> ^ element >> >> I had a need for it in the past (and, just now, in fact - so minimally >> tested just now). >> >> -cbc >> >> >> On Wed, Nov 20, 2013 at 2:15 AM, Norbert Hartl <norbert(a)hartl.name>wrote: >> >>> I talked to Lukas two years ago about parsing the longest match [1]. He >>> committed it to PetitBeta back then. Now I need it and I had a look at the >>> current parsers but didnât find one that can do the same. Is there a parser >>> that can do longest match? >>> >>> If not I would propose adding that to the default petit parser package. >>> Lukasâ proposal back then was >>> >>> LongestChoiceParser>>parseOn: aStream >>> | start element longestEnd longestElement | >>> start := aStream position. >>> 1 to: parsers size do: [ :index | >>> element := (parsers at: index) >>> parseOn: aStream. >>> (longestEnd isNil or: [ longestEnd < aStream position ]) ifTrue: [ >>> longestEnd := aStream position. >>> longestElement := element ]. >>> aStream position: start ]. >>> aStream position: longestEnd. >>> ^ longestElement >>> >>> >>> Norbert >>> >>> [1] http://www.iam.unibe.ch/pipermail/moose-dev/2011-July/009365.html >>> >> >> >

Nov. 20, 2013

Re: [Pharo-dev] petit parser longest match

by Chris Cunningham

Actually, do this [the #( 0 nil ) meant it was shared with ALL choice parsers forever - not a good choice]. parseOn: aStream "This is optimized code that avoids unnecessary block activations, do not change. When all choices fail, the last failure is answered." | element longest | longest := Array with: 0 with: nil. 1 to: parsers size do: [ :index | element := (parsers at: index) parseOn: aStream. element isPetitFailure ifTrue: [ aStream position > longest first ifTrue: [ longest at: 1 put: aStream position; at: 2 put: element ] ] ifFalse: [ ^ element ] ]. aStream position: longest first. ^ element On Wed, Nov 20, 2013 at 1:35 PM, Chris Cunningham <cunningham.cb(a)gmail.com>wrote: > Ho about this (replacement for yours, or just replace in PPChoiceParser - > but it will result in different behavior for that method outside of your > particular parser, so beware): > > parseOn: aStream > "This is optimized code that avoids unnecessary block activations, do > not change. When all choices fail, the last failure is answered." > > | element longest | > longest := #( 0 nil ). > 1 to: parsers size do: [ :index | > element := (parsers at: index) > parseOn: aStream. > element isPetitFailure > ifTrue: [ aStream position > longest first ifTrue: [ longest at: 1 put: > aStream position; at: 2 put: element ] ] > ifFalse: [ ^ element ] ]. > aStream position: longest first. > ^ element > > I had a need for it in the past (and, just now, in fact - so minimally > tested just now). > > -cbc > > > On Wed, Nov 20, 2013 at 2:15 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I talked to Lukas two years ago about parsing the longest match [1]. He >> committed it to PetitBeta back then. Now I need it and I had a look at the >> current parsers but didnât find one that can do the same. Is there a parser >> that can do longest match? >> >> If not I would propose adding that to the default petit parser package. >> Lukasâ proposal back then was >> >> LongestChoiceParser>>parseOn: aStream >> | start element longestEnd longestElement | >> start := aStream position. >> 1 to: parsers size do: [ :index | >> element := (parsers at: index) >> parseOn: aStream. >> (longestEnd isNil or: [ longestEnd < aStream position ]) ifTrue: [ >> longestEnd := aStream position. >> longestElement := element ]. >> aStream position: start ]. >> aStream position: longestEnd. >> ^ longestElement >> >> >> Norbert >> >> [1] http://www.iam.unibe.ch/pipermail/moose-dev/2011-July/009365.html >> > >

Nov. 20, 2013

Re: [Pharo-dev] petit parser longest match

by Chris Cunningham

Ho about this (replacement for yours, or just replace in PPChoiceParser - but it will result in different behavior for that method outside of your particular parser, so beware): parseOn: aStream "This is optimized code that avoids unnecessary block activations, do not change. When all choices fail, the last failure is answered." | element longest | longest := #( 0 nil ). 1 to: parsers size do: [ :index | element := (parsers at: index) parseOn: aStream. element isPetitFailure ifTrue: [ aStream position > longest first ifTrue: [ longest at: 1 put: aStream position; at: 2 put: element ] ] ifFalse: [ ^ element ] ]. aStream position: longest first. ^ element I had a need for it in the past (and, just now, in fact - so minimally tested just now). -cbc On Wed, Nov 20, 2013 at 2:15 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > I talked to Lukas two years ago about parsing the longest match [1]. He > committed it to PetitBeta back then. Now I need it and I had a look at the > current parsers but didnât find one that can do the same. Is there a parser > that can do longest match? > > If not I would propose adding that to the default petit parser package. > Lukasâ proposal back then was > > LongestChoiceParser>>parseOn: aStream > | start element longestEnd longestElement | > start := aStream position. > 1 to: parsers size do: [ :index | > element := (parsers at: index) > parseOn: aStream. > (longestEnd isNil or: [ longestEnd < aStream position ]) ifTrue: [ > longestEnd := aStream position. > longestElement := element ]. > aStream position: start ]. > aStream position: longestEnd. > ^ longestElement > > > Norbert > > [1] http://www.iam.unibe.ch/pipermail/moose-dev/2011-July/009365.html >

Nov. 20, 2013

Re: [Pharo-dev] Spotlight behaviour

by phil＠highoctane.be

Does not work with proper font hinting. On Wednesday, November 20, 2013, Torsten Bergmann wrote: > I agree with Pavel: having a dark theme is easy. In the end > it is all Smalltalk, so just evaluate > > Color black become: Color white > > to swap the color objects and then open a new Nautlius. ;) > > Have fun > T. > > > Gesendet: Mittwoch, 20. November 2013 um 15:36 Uhr > Von: "Pavel Krivanek" <pavel.krivanek(a)gmail.com <javascript:;>> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org <javascript:;>> > Betreff: Re: [Pharo-dev] Spotlight behaviour > > You can get interesting results when you play a little bit with Color > class. It's Smalltalk ;-) > > -- Pavel > > 2013/11/20 Esteban Lorenzano <estebanlm(a)gmail.com <javascript:;>>ok... I > will package it and made it available in the course of the day then. > more hands means faster results :) > > Esteban > > On Nov 20, 2013, at 2:53 PM, Sven Van Caekenberghe <sven(a)stfx.eu<javascript:;> > [sven(a)stfx.eu <javascript:;>]> wrote: > > > > > On 20 Nov 2013, at 14:42, Esteban Lorenzano <estebanlm(a)gmail.com<javascript:;> > [estebanlm(a)gmail.com <javascript:;>]> wrote: > > > >> :) > >> > >> <Screen Shot 2013-11-20 at 2.40.12 PM.png> > >> > >> I'm slowly working in a darktheme... problem is the INCREDIBLE amount > of hardcode colors and silly code. > >> So it will take some time until is ready (also because I work on it > when I'm bored and not wanting to do what I should do... like today :P) > > > > Hey, Esteban, that looks already quite impressive. > > I am sure there are some people really anxious to try this and help. > > Is this theme already available somewhere ? > > > >> Esteban > >> > >> > >> On Nov 20, 2013, at 2:34 PM, kilon alios <kilon.alios(a)gmail.com<javascript:;> > [kilon.alios(a)gmail.com <javascript:;>]> wrote: > >> > >>> yes I can confirm that this work also on windoom 7. Indeed Sven your > Pharo looks a bit more sexy than mine. > >>> > >>> the code you posted works also like a charm for me , thank you. Now If > I could get also a dark theme working with pharo that would be awesome. All > this white hurts my eyes. But I guess I will have to compromise for the > time being :) > >>> > >>> thank you > >>> > >>> > >>> On Wed, Nov 20, 2013 at 2:58 PM, Sven Van Caekenberghe <sven(a)stfx.eu<javascript:;> > [sven(a)stfx.eu <javascript:;>]> wrote: > >>> > >>> On 20 Nov 2013, at 13:46, Esteban A. Maringolo <emaringolo(a)gmail.com<javascript:;> > [emaringolo(a)gmail.com <javascript:;>]> wrote: > >>> > >>>> Sven. > >>>> > >>>> What version are YOU using? Fonts and windows look so clean an sharp! > :) > >>> > >>> ;-) > >>> > >>> Yes they are. > >>> > >>> Like I said, Pharo version #30582 > >>> > >>> defaultFont Source Sans Pro Normal points: 12 height: 21 > >>> listFont Source Sans Pro Normal points: 12 height: 21 > >>> menuFont Source Sans Pro Normal points: 12 height: 21 > >>> windowTitleFont Source Sans Pro Bold points: 12 height: 21 > >>> balloonFont Source Sans Pro Normal points: 9 height: 16 > >>> codeFont Source Code Pro Normal points: 11 height: 19 > >>> buttonFont Source Sans Pro Normal points: 12 height: 21 > >>> haloFont Source Sans Pro Normal points: 9 height: 16 > >>> > >>> Installed with a script from our local look and feel guru, Doru: > >>> > >>> #('SourceCodeProRegular' 'SourceCodeProBold' 'SourceSansProRegular' > 'SourceSansProBoldâ) > >>> do: [ :each | > >>> Smalltalk globals > >>> at: each asSymbol > >>> ifAbsent: [ > >>> Gofer new > >>> smalltalkhubUser: 'girba' project: 'FreeFonts'; > >>> package: each; > >>> load ]. > >>> (Smalltalk at: each asSymbol) new install ]. > >>> FreeTypeSystemSettings loadFt2Library: true. > >>> FreeTypeFontProvider current updateFromSystem. > >>> > >>> StandardFonts > >>> setAllStandardFontsTo: (LogicalFont familyName: 'Source Sans Pro' > pointSize: 12); > >>> haloFont: (LogicalFont familyName: 'Source Sans Pro' pointSize: 9); > >>> windowTitleFont: (LogicalFont familyName: 'Source Sans Pro Bold' > pointSize: 12); > >>> balloonFont: (LogicalFont familyName: 'Source Sans Pro' pointSize: 9); > >>> codeFont: (LogicalFont familyName: 'Source Code Pro' pointSize: 11). > >>> > >>> And then I finally make the window font bold, manually. > >>> > >>> The screenshot was done on Mac OS X 10.9 > >>> > >>> HTH, > >>> > >>> Sven > >>> > >>>> Esteban A. Maringolo > >>>> > >>>> > >>>> 2013/11/20 Sven Van Caekenberghe <sven(a)stfx.eu <javascript:;>[ > sven(a)stfx.eu <javascript:;>]> > >>>> What version are you using ? > >>>> > >>>> In #30582 it does work: > >>>> <Screen Shot 2013-11-20 at 13.34.46.png> > >>>> > >>>> You can always try typing a space after Objectâ¦ > >>>> > >>>> Sven > >>>> > >>>> On 20 Nov 2013, at 13:23, Yuriy Tymchuk <yuriy.tymchuk(a)me.com<javascript:;> > [yuriy.tymchuk(a)me.com <javascript:;>]> wrote: > >>>> > >>>>> HI, > >>>>> > >>>>> do you know why search behaves like this? I was expecting Object to > show up > >>>>> > >>>>> <Screenshot 2013-11-20 13.20.40.png> > >>>>> > >>>>> > >>>>> Cheers > >>>>> Uko > >>>> > >>>> > >>> > >>> > >>> > >> > > > > > > > > -- --- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail:phil@highoctane.be | Web: http://philippeback.eu Blog: http://philippeback.be | Twitter: @philippeback Youtube: http://www.youtube.com/user/philippeback/videos High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/ Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller

Nov. 20, 2013

Re: [Pharo-dev] Multithreading

by ClÃ©ment Bera

So what you are looking for is Process and semaphores. This is not multithreading in the default Pharo VM + image, currently our semaphore/process management is not multithreaded, but executes all the process in the same thread. What happens basically is that you will run several processes in 1 thread with different priorities, and processes with highest priorities will be executed first. This is very good for your case, because if you put your task in another process with lower priority than the UI process, each time you will trigger a UI interaction the secondary process will be temporarily stopped to execute your UI interaction. (see #forkAt: Process userBackgroundPriority) Seemingly there's no chapter about Process and semaphores yet but Stef is planning to write one. The other alternatives are to use CogMT, a version of the Cog VM with real multithreading for FFI (but I think it will not work easily with your case) or the island VM plugin, which seemingly is an actor based multithreading system in Squeak/Pharo (however there is only 1 project that successfully uses it, which is the one of 3DICC). 2013/11/20 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > Iâm not proficient in multithreading, but I think that Iâm looking > for Semaphore and Process. Things that I implement take a very long time to > run, and I canât do anything else during that time or even cancel them. So > I guess they should run in a separate process which I can achieve with > #fork. But as I start to work with that I want to know all the rest that > can be useful. > > uko > > On 20 Nov 2013, at 19:21, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > What do you mean by multithreading ? > Do you mean Semaphore and Process, Cog Multithreading, the Island VM > plugin ? > > > 2013/11/20 Yuriy Tymchuk <yuriy.tymchuk(a)me.com> > >> Hi everyone, is there any chapter on multithreading in Pharo books? If >> not maybe Iâll write something about that, but any material will be useful >> for me right now. >> > > >

Nov. 20, 2013

Re: [Pharo-dev] Spotlight behaviour

by Torsten Bergmann

I agree with Pavel: having a dark theme is easy. In the end it is all Smalltalk, so just evaluate Color black become: Color white Â to swap the color objects and then open a new Nautlius. ;) Have fun T. Gesendet:Â Mittwoch, 20. November 2013 um 15:36 Uhr Von:Â "Pavel Krivanek" <pavel.krivanek(a)gmail.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] Spotlight behaviour You can get interesting results when you play a little bit with Color class. It's Smalltalk ;-) Â -- Pavel Â 2013/11/20 Esteban Lorenzano <estebanlm(a)gmail.com>ok... I will package it and made it available in the course of the day then. more hands means faster results :) Esteban On Nov 20, 2013, at 2:53 PM, Sven Van Caekenberghe <sven@stfx.eu[sven@stfx.eu]> wrote: > > On 20 Nov 2013, at 14:42, Esteban Lorenzano <estebanlm@gmail.com[estebanlm@gmail.com]> wrote: > >> :) >> >> <Screen Shot 2013-11-20 at 2.40.12 PM.png> >> >> I'm slowly working in a darktheme... problem is the INCREDIBLE amount of hardcode colors and silly code. >> So it will take some time until is ready (also because I work on it when I'm bored and not wanting to do what I should do... like today :P) > > Hey, Esteban, that looks already quite impressive. > I am sure there are some people really anxious to try this and help. > Is this theme already available somewhere ? > >> Esteban >> >> >> On Nov 20, 2013, at 2:34 PM, kilon alios <kilon.alios@gmail.com[kilon.alios@gmail.com]> wrote: >> >>> yes I can confirm that this work also on windoom 7. Indeed Sven your Pharo looks a bit more sexy than mine. >>> >>> the code you posted works also like a charm for me , thank you. Now If I could get also a dark theme working with pharo that would be awesome. All this white hurts my eyes. But I guess I will have to compromise for the time being :) >>> >>> thank you >>> >>> >>> On Wed, Nov 20, 2013 at 2:58 PM, Sven Van Caekenberghe <sven@stfx.eu[sven@stfx.eu]> wrote: >>> >>> On 20 Nov 2013, at 13:46, Esteban A. Maringolo <emaringolo@gmail.com[emaringolo@gmail.com]> wrote: >>> >>>> Sven. >>>> >>>> What version are YOU using? Fonts and windows look so clean an sharp! :) >>> >>> ;-) >>> >>> Yes they are. >>> >>> Like I said, Pharo version #30582 >>> >>> defaultFont Source Sans Pro Normal points: 12 height: 21 >>> listFont Source Sans Pro Normal points: 12 height: 21 >>> menuFont Source Sans Pro Normal points: 12 height: 21 >>> windowTitleFont Source Sans Pro Bold points: 12 height: 21 >>> balloonFont Source Sans Pro Normal points: 9 height: 16 >>> codeFont Source Code Pro Normal points: 11 height: 19 >>> buttonFont Source Sans Pro Normal points: 12 height: 21 >>> haloFont Source Sans Pro Normal points: 9 height: 16 >>> >>> Installed with a script from our local look and feel guru, Doru: >>> >>> #('SourceCodeProRegular' 'SourceCodeProBold' 'SourceSansProRegular' 'SourceSansProBoldâ) >>> Â do: [ :each | >>> Â Â Smalltalk globals >>> Â Â Â at: each asSymbol >>> Â Â Â ifAbsent: [ >>> Â Â Â Â Gofer new >>> Â Â Â Â Â smalltalkhubUser: 'girba' project: 'FreeFonts'; >>> Â Â Â Â Â package: each; >>> Â Â Â Â Â load ]. >>> Â Â (Smalltalk at: each asSymbol) new install ]. >>> FreeTypeSystemSettings loadFt2Library: true. >>> FreeTypeFontProvider current updateFromSystem. >>> >>> StandardFonts >>> Â setAllStandardFontsTo: (LogicalFont familyName: 'Source Sans Pro' pointSize: 12); >>> Â haloFont: (LogicalFont familyName: 'Source Sans Pro' pointSize: 9); >>> Â windowTitleFont: (LogicalFont familyName: 'Source Sans Pro Bold' pointSize: 12); >>> Â balloonFont: (LogicalFont familyName: 'Source Sans Pro' pointSize: 9); >>> Â codeFont: (LogicalFont familyName: 'Source Code Pro' pointSize: 11). >>> >>> And then I finally make the window font bold, manually. >>> >>> The screenshot was done on Mac OS X 10.9 >>> >>> HTH, >>> >>> Sven >>> >>>> Esteban A. Maringolo >>>> >>>> >>>> 2013/11/20 Sven Van Caekenberghe <sven@stfx.eu[sven@stfx.eu]> >>>> What version are you using ? >>>> >>>> In #30582 it does work: >>>> <Screen Shot 2013-11-20 at 13.34.46.png> >>>> >>>> You can always try typing a space after Objectâ¦ >>>> >>>> Sven >>>> >>>> On 20 Nov 2013, at 13:23, Yuriy Tymchuk <yuriy.tymchuk@me.com[yuriy.tymchuk@me.com]> wrote: >>>> >>>>> HI, >>>>> >>>>> do you know why search behaves like this? I was expecting Object to show up >>>>> >>>>> <Screenshot 2013-11-20 13.20.40.png> >>>>> >>>>> >>>>> Cheers >>>>> Uko >>>> >>>> >>> >>> >>> >> > > Â

Nov. 20, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Sven Van Caekenberghe

On 20 Nov 2013, at 18:53, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Wed, Nov 20, 2013 at 8:47 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > The only thing that annoyed me is that I failed to discover the incantation thru sender/implementor chain because some messages are constructed... > > that's an anti-pattern to be avoided. One can use dictionaries to make the link explicit, then one has a chance of tracking things down. Always use something equivalent to > > self perform: (Dictionary newFromPairs: #(#timesRepeat: #optimizeTimesRepeat: ...) at: message) with: ... > > instead of > > self perform: ('compile', message) asSymbol with: > > It'll be far clearer, and (cuz the dictionary will be precomputed) it'll be faster too. I donât get the âbecause the Dictionary will be precomputedâ in the code example you give. On the contrary, you will create a new Dictionary every time you execute your example, no ? > I tried the senders of timesRepeat: then the senders of corresponding visitor message (no image near my keyboard to check the name). > Of course, once you've learned the incantation, it's OK... > > > 2013/11/20 Igor Stasenko <siguctua(a)gmail.com> > > > > On 19 November 2013 16:20, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 19 Nov 2013, at 16:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > Hi, > > > > It seems that #timesRepeat: is compiled/optimized away by Opal, which is probably good. BTW, what is the list of selectors that get this treatment ? > > > RBMessageNode has #isInlined that returns trueâ¦ not all cases where the selector is send it is optimised, so a list would be one of âpossiblyoptimizedâ selectorsâ¦ > maybe #isInlined could check first against that list to quickly return false for all the other selectors. > > > In the PEGParser example of Xtreams #timesRepeat: is implemented for a non Integer class, which obviously leads to errors. > > > oh, yes, that is a problem. We started for ifTrue: to do an on-the-fly re-compiling and executing the ifTrue:, but itâs a bit of work to get it right for all casesâ¦ so we did not finish > that. But it would be possible... > > > Is there a way to tune this ? > > Can it be set at a level higher than in each method ? > > > > Yes, you can do it per class-hierarchyâ¦ you can implement on the class side a method to parametrize the compiler: > > compiler > ^super compiler options: #(- optionInlineTimesRepeat) > > > .. and i feel really glad that Marcus armed my idea of option specification e.g. > > #(+ optionToEnable1 - optionToDisable anotherOptionToDisable + optionToEnable2 ) > > :) > > > Marcus > > > > > > > -- > Best regards, > Igor Stasenko. > > > > > -- > best, > Eliot

Nov. 20, 2013

Re: [Pharo-dev] Tuning Opal Optimizations

by Eliot Miranda

On Wed, Nov 20, 2013 at 10:54 AM, ClÃ©ment Bera <bera.clement(a)gmail.com>wrote: > 2013/11/20 Eliot Miranda <eliot.miranda(a)gmail.com> > >> >> On Wed, Nov 20, 2013 at 8:47 AM, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >>> The only thing that annoyed me is that I failed to discover the >>> incantation thru sender/implementor chain because some messages are >>> constructed... >>> >> >> that's an anti-pattern to be avoided. One can use dictionaries to make >> the link explicit, then one has a chance of tracking things down. Always >> use something equivalent to >> >> self perform: (Dictionary newFromPairs: #(#timesRepeat: >> #optimizeTimesRepeat: ...) at: message) with: ... >> >> instead of >> >> self perform: ('compile', message) asSymbol with: >> >> It'll be far clearer, and (cuz the dictionary will be precomputed) it'll >> be faster too. >> > > Nice idea. I've never liked this dynamic dispatch with string/symbol > manipulation in Opal. > > I added your fix in Opal on my computer right now, I put the optimized > dictionary in a class variable. I will check with Marcus tomorrow if he's > fine with it we will add it in Pharo 3.0 in the next few days. > > However I didn't see compilation time being faster, I guess the > performance improvement is not noticeable in the whole image recompilation > time. > Right. It's a mcro-optimization: | d | d := Dictionary newFromPairs: #('your' yourself). { [1000000 timesRepeat: [self perform: ('your', 'self') asSymbol]] timeToRun. [1000000 timesRepeat: [self perform: (d at: 'your')]] timeToRun } #(796 341) :-) on my 2.2GHz Core i7 MBP, Cog r2798 VMMaker.oscog-eem.496 > >> >> I tried the senders of timesRepeat: then the senders of corresponding >>> visitor message (no image near my keyboard to check the name). >>> Of course, once you've learned the incantation, it's OK... >>> >>> >>> 2013/11/20 Igor Stasenko <siguctua(a)gmail.com> >>> >>>> >>>> >>>> >>>> On 19 November 2013 16:20, Marcus Denker <marcus.denker(a)inria.fr>wrote: >>>> >>>>> >>>>> On 19 Nov 2013, at 16:07, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> > Hi, >>>>> > >>>>> > It seems that #timesRepeat: is compiled/optimized away by Opal, >>>>> which is probably good. BTW, what is the list of selectors that get this >>>>> treatment ? >>>>> > >>>>> RBMessageNode has #isInlined that returns trueâ¦ not all cases where >>>>> the selector is send it is optimised, so a list would be one of >>>>> âpossiblyoptimizedâ selectorsâ¦ >>>>> maybe #isInlined could check first against that list to quickly return >>>>> false for all the other selectors. >>>>> >>>>> > In the PEGParser example of Xtreams #timesRepeat: is implemented for >>>>> a non Integer class, which obviously leads to errors. >>>>> > >>>>> oh, yes, that is a problem. We started for ifTrue: to do an on-the-fly >>>>> re-compiling and executing the ifTrue:, but itâs a bit of work to get it >>>>> right for all casesâ¦ so we did not finish >>>>> that. But it would be possible... >>>>> >>>>> > Is there a way to tune this ? >>>>> > Can it be set at a level higher than in each method ? >>>>> > >>>>> >>>>> Yes, you can do it per class-hierarchyâ¦ you can implement on the class >>>>> side a method to parametrize the compiler: >>>>> >>>>> compiler >>>>> ^super compiler options: #(- optionInlineTimesRepeat) >>>>> >>>>> >>>> .. and i feel really glad that Marcus armed my idea of option >>>> specification e.g. >>>> >>>> #(+ optionToEnable1 - optionToDisable anotherOptionToDisable + >>>> optionToEnable2 ) >>>> >>>> :) >>>> >>>> >>>>> Marcus >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> >> >> -- >> best, >> Eliot >> > > -- best, Eliot

Nov. 20, 2013