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

Fwd: Your request to join pharo-contribution has been accepted

by Sven Van Caekenberghe

I guess this is not yet enough to be able to create a new CI job ? Do I still have to wait for a manual approval ? Begin forwarded message: > From: no-reply(a)ci.inria.fr > Subject: Your request to join pharo-contribution has been accepted > Date: 20 Nov 2013 20:02:57 GMT+1 > To: sven(a)stfx.eu > > Hi Sven Van Caekenberghe, > Your request to join the project pharo-contribution has been accepted ! > > Regards, > Support team.

Nov. 20, 2013

Re: [Pharo-dev] Multithreading

by Yuriy Tymchuk

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] Tuning Opal Optimizations

by ClÃ©ment Bera

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

Nautilus Tree

by Sean P. DeNigris

That's really cool that we have started making the package list more manageable! I noticed that right now, separate packages within the same project are not collapsed. E.g. if I have MyProject-Core and MyProject-Platform, they will be siblings in the tree, instead of both under MyProject. It seems like it would be more useful to have - MyProject - Core - Platform in the tree ----- Cheers, Sean -- View this message in context: http://forum.world.st/Nautilus-Tree-tp4723819.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 20, 2013

Re: [Pharo-dev] Multithreading

by ClÃ©ment Bera

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] Tuning Opal Optimizations

by Peter Hugosson-Miller

Nice one, Eliot! :-) -- Cheers, Peter. 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 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 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 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] Smalltalks 2013 video now available

by kilon alios

I watched 3 videos so far, Stephane's , Estebans, and the one about an rpg game. All of them very interesting. thanks On Wed, Nov 20, 2013 at 6:15 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Thanks Andres! This is sooooo important to share the conferences beyond the > slice of our community attending :) > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Smalltalks-2013-video-now-available-tp4723610p4723764… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Nov. 20, 2013

Re: [Pharo-dev] Pharo's Gofer

by Sean P. DeNigris

There's also: Sean P. DeNigris wrote > Gofer>>#directory: > ... > repository := (aDirectoryOrString isString and: [ aDirectoryOrString > endsWith: '*' ]) I don't like the double-duty of appending $* to the string argument to indicate a subdirectory repository. How about adding to the API, like directoriesIn: or similar... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-s-Gofer-tp4723799p4723804.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 20, 2013

Pharo's Gofer

by Sean P. DeNigris

Gofer>>#directory: ... Smalltalk globals at: #MCSubDirectoryRepository ifAbsent: [ self error: aDirectoryOrString printString , ' is an unsupported repository type' ] Why wouldn't MCSubDirectoryRepository be present? Are we staying compatible with other platforms? Or another reason? If it's unnecessary I will gut... err, I mean simplify, hehe... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-s-Gofer-tp4723799.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 20, 2013