October 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] RPackage / Metacello mystery woes

by StÃ©phane Ducasse

I do not see why this would be related to RPackage. On Oct 4, 2011, at 8:10 PM, Damien Pollet wrote: > Loading Coral is failing, apparently because something calls > #addMethod: on a Symbol, when it should have been an instance of > RPackageâ¦ > > See for instance https://ci.lille.inria.fr/pharo/job/Coral/191/console > > I suspect it's coming from me updating ConfigurationOfCoral, which > indirectly (via PetitParser) depends on > ConfigurationOfRefactoringBrowser. I've seen MC try to load > Refactoring-Tests-Core (lr.54) on top of (MarcusDenker.54), and there > it complains some definitions are not there. If I proceed there, code > seems to load but a bunch of debuggers open at the end, all with a > similar error as the trace above. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Oct. 4, 2011

[Pharo-project] RPackage / Metacello mystery woes

by Damien Pollet

Loading Coral is failing, apparently because something calls #addMethod: on a Symbol, when it should have been an instance of RPackageâ¦ See for instance https://ci.lille.inria.fr/pharo/job/Coral/191/console I suspect it's coming from me updating ConfigurationOfCoral, which indirectly (via PetitParser) depends on ConfigurationOfRefactoringBrowser. I've seen MC try to load Refactoring-Tests-Core (lr.54) on top of (MarcusDenker.54), and there it complains some definitions are not there. If I proceed there, code seems to load but a bunch of debuggers open at the end, all with a similar error as the trace above. -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Oct. 4, 2011

Re: [Pharo-project] looking for Kent Beck, in his roll of MongoTalk creator/admin

by Philippe Marschall

On 09/28/2011 06:02 PM, Sean P. DeNigris wrote: > > Esteban Lorenzano wrote: >> >> 2) write permission, if it is ok I to commit my changes there (a global >> Read/Write would also be cool, but not everybody âincluding meâ likes it >> everytime :) ) >> > Please, please, please, oh wonderful creators of SqS3 and SmalltalkHub, > include a feature that overcomes this longstanding, frustrating problem. One > good idea might be a per-project inbox, so at least all contributed code can > be found in one place even if it can't/won't be integrated. Or maybe a > forking feature, like git. Or both! > > > Esteban Lorenzano wrote: >> >> 1) license information (it would be really cool if it is MIT ;)) >> > Research shows that when you get people to "do the right thing" by "making > doing good the default option" [1]. Let's have the license default to MIT so > that people who don't really care, don't know, forget to select an option > end up with the choice most beneficial to the community. Choosing a license is a serious matter and should be done consciously. Unlike a default value for some configuration value it as far reaching legal consequences. Cheers Philippe

Oct. 4, 2011

Re: [Pharo-project] About Dictionary >> #at:ifAbsentPut:

by Henrik Sperre Johansen

On 04.10.2011 12:52, Mariano Martinez Peck wrote: > Hi guys. If I tell you the selector is Dictionary >> #at:ifAbsentPut: > what would you expect the second parameter to be? the value. > So, one would do: > Dictionary new at: #foo ifAbsentPut: 4 > > But if you see Dictionary >> > > at: key ifAbsentPut: aBlock > "Return the value at the given key. > If key is not included in the receiver store the result > of evaluating aBlock as new value." > > ^ self at: key ifAbsent: [self at: key put: aBlock value] > > so it expects a Block. Ok, we are in Smalltalk, so implementing #value > is enough. > > Well..the previous example works, but only because we have an ugly > Object >> value that returns self. > If I put instances of subclasses from ProtoObjects (proxies), that do > not work anymore. > > So...my question is we do Dictionary at: #foo put: 4, why > #at:ifAbsentPut: expects a block and not directly the value? Sven's reasons are correct I think, it's for efficiency, and elegant lazy initialization of a cache. The same reasons will never hold true when using #at:put:. > in which case I need a block instead of the value object directly ? In addition to when you want delayed computation, when you have value objects who redefine/do not define #value ;) Cheers, Henry

Oct. 4, 2011

Re: [Pharo-project] looking for Kent Beck, in his roll of MongoTalk creator/admin

by HwaJong Oh

Recently, I was in similar situation. I wanted to commit on http://www.squeaksource.com/Printf.html, but I had no right to do so. I made my version of Printf and send an email to Dominic Letz, the creator of the project, with mcz file attached. He replied with thank of participation and let my verion be uploaded. http://www.squeaksource.com/Printf HwaJong Oh -- View this message in context: http://forum.world.st/looking-for-Kent-Beck-in-his-roll-of-MongoTalk-creato… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 4, 2011

Re: [Pharo-project] About Dictionary >> #at:ifAbsentPut:

by Schwab,Wilhelm K

Execution time is not the only consideration. Often one needs state from other objects at the time of creation of the new element, so the creation really needs to be deferred by default. Having "everything" understand #value is probably harmless, and certainly better than doing away with the ability to use a block to create the new element. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Tuesday, October 04, 2011 7:08 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About Dictionary >> #at:ifAbsentPut: On 04 Oct 2011, at 12:52, Mariano Martinez Peck wrote: > Hi guys. If I tell you the selector is Dictionary >> #at:ifAbsentPut: what would you expect the second parameter to be? the value. > So, one would do: > Dictionary new at: #foo ifAbsentPut: 4 > > But if you see Dictionary >> > > at: key ifAbsentPut: aBlock > "Return the value at the given key. > If key is not included in the receiver store the result > of evaluating aBlock as new value." > > ^ self at: key ifAbsent: [self at: key put: aBlock value] > > so it expects a Block. Ok, we are in Smalltalk, so implementing #value is enough. > > Well..the previous example works, but only because we have an ugly Object >> value that returns self. > If I put instances of subclasses from ProtoObjects (proxies), that do not work anymore. > > So...my question is we do Dictionary at: #foo put: 4, why #at:ifAbsentPut: expects a block and not directly the value? > in which case I need a block instead of the value object directly ? You are right, it feels a bit silly. However, have a look at the senders (there are many). Often the block holds an expensive operation when using the dictionary as a cache: cache at: key ifAbsent: [ backEnd get: key ] Then it feels quite elegant. Sven

Oct. 4, 2011

Re: [Pharo-project] About Dictionary >> #at:ifAbsentPut:

by Norbert Hartl

Am 04.10.2011 um 13:33 schrieb Mariano Martinez Peck: > > > On Tue, Oct 4, 2011 at 1:08 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 04 Oct 2011, at 12:52, Mariano Martinez Peck wrote: > > > Hi guys. If I tell you the selector is Dictionary >> #at:ifAbsentPut: what would you expect the second parameter to be? the value. > > So, one would do: > > Dictionary new at: #foo ifAbsentPut: 4 > > > > But if you see Dictionary >> > > > > at: key ifAbsentPut: aBlock > > "Return the value at the given key. > > If key is not included in the receiver store the result > > of evaluating aBlock as new value." > > > > ^ self at: key ifAbsent: [self at: key put: aBlock value] > > > > so it expects a Block. Ok, we are in Smalltalk, so implementing #value is enough. > > > > Well..the previous example works, but only because we have an ugly Object >> value that returns self. > > If I put instances of subclasses from ProtoObjects (proxies), that do not work anymore. > > > > So...my question is we do Dictionary at: #foo put: 4, why #at:ifAbsentPut: expects a block and not directly the value? > > in which case I need a block instead of the value object directly ? > > You are right, it feels a bit silly. > However, have a look at the senders (there are many). > Often the block holds an expensive operation when using the dictionary as a cache: > > cache at: key ifAbsent: [ backEnd get: key ] > > > and what is the difference to do: > > cache at: key ifAbsent: ( backEnd get: key ) (notice the parenthesis instead of []) > > [500 timesRepeat:[ > Dictionary new at: #foo ifAbsentPut: [ CompiledMethod instanceCount ] ]] timeToRun 7254 > > [500 timesRepeat:[ > Dictionary new at: #foo ifAbsentPut: (CompiledMethod instanceCount) ]] timeToRun 7294 > > gives me more or less the same... > try | dict | dict := Dictionary new. [500 timesRepeat:[ dict at: #foo ifAbsentPut: [ CompiledMethod instanceCount ] ]] timeToRun. 21 | dict | dict := Dictionary new. [500 timesRepeat:[ dict at: #foo ifAbsentPut: (CompiledMethod instanceCount) ]] timeToRun 10501 Norbert

Oct. 4, 2011

Re: [Pharo-project] About Dictionary >> #at:ifAbsentPut:

by Mariano Martinez Peck

On Tue, Oct 4, 2011 at 1:08 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 04 Oct 2011, at 12:52, Mariano Martinez Peck wrote: > > > Hi guys. If I tell you the selector is Dictionary >> #at:ifAbsentPut: > what would you expect the second parameter to be? the value. > > So, one would do: > > Dictionary new at: #foo ifAbsentPut: 4 > > > > But if you see Dictionary >> > > > > at: key ifAbsentPut: aBlock > > "Return the value at the given key. > > If key is not included in the receiver store the result > > of evaluating aBlock as new value." > > > > ^ self at: key ifAbsent: [self at: key put: aBlock value] > > > > so it expects a Block. Ok, we are in Smalltalk, so implementing #value is > enough. > > > > Well..the previous example works, but only because we have an ugly Object > >> value that returns self. > > If I put instances of subclasses from ProtoObjects (proxies), that do not > work anymore. > > > > So...my question is we do Dictionary at: #foo put: 4, why > #at:ifAbsentPut: expects a block and not directly the value? > > in which case I need a block instead of the value object directly ? > > You are right, it feels a bit silly. > However, have a look at the senders (there are many). > Often the block holds an expensive operation when using the dictionary as a > cache: > > cache at: key ifAbsent: [ backEnd get: key ] > > and what is the difference to do: cache at: key ifAbsent: ( backEnd get: key ) (notice the parenthesis instead of []) [500 timesRepeat:[ Dictionary new at: #foo ifAbsentPut: [ CompiledMethod instanceCount ] ]] timeToRun 7254 [500 timesRepeat:[ Dictionary new at: #foo ifAbsentPut: (CompiledMethod instanceCount) ]] timeToRun 7294 gives me more or less the same... Thanks > Then it feels quite elegant. > > Sven > > > -- Mariano http://marianopeck.wordpress.com

Oct. 4, 2011

Re: [Pharo-project] About Dictionary >> #at:ifAbsentPut:

by Sven Van Caekenberghe

On 04 Oct 2011, at 12:52, Mariano Martinez Peck wrote: > Hi guys. If I tell you the selector is Dictionary >> #at:ifAbsentPut: what would you expect the second parameter to be? the value. > So, one would do: > Dictionary new at: #foo ifAbsentPut: 4 > > But if you see Dictionary >> > > at: key ifAbsentPut: aBlock > "Return the value at the given key. > If key is not included in the receiver store the result > of evaluating aBlock as new value." > > ^ self at: key ifAbsent: [self at: key put: aBlock value] > > so it expects a Block. Ok, we are in Smalltalk, so implementing #value is enough. > > Well..the previous example works, but only because we have an ugly Object >> value that returns self. > If I put instances of subclasses from ProtoObjects (proxies), that do not work anymore. > > So...my question is we do Dictionary at: #foo put: 4, why #at:ifAbsentPut: expects a block and not directly the value? > in which case I need a block instead of the value object directly ? You are right, it feels a bit silly. However, have a look at the senders (there are many). Often the block holds an expensive operation when using the dictionary as a cache: cache at: key ifAbsent: [ backEnd get: key ] Then it feels quite elegant. Sven

Oct. 4, 2011

[Pharo-project] About Dictionary >> #at:ifAbsentPut:

by Mariano Martinez Peck

Hi guys. If I tell you the selector is Dictionary >> #at:ifAbsentPut: what would you expect the second parameter to be? the value. So, one would do: Dictionary new at: #foo ifAbsentPut: 4 But if you see Dictionary >> at: key ifAbsentPut: aBlock "Return the value at the given key. If key is not included in the receiver store the result of evaluating aBlock as new value." ^ self at: key ifAbsent: [self at: key put: aBlock value] so it expects a Block. Ok, we are in Smalltalk, so implementing #value is enough. Well..the previous example works, but only because we have an ugly Object >> value that returns self. If I put instances of subclasses from ProtoObjects (proxies), that do not work anymore. So...my question is we do Dictionary at: #foo put: 4, why #at:ifAbsentPut: expects a block and not directly the value? in which case I need a block instead of the value object directly ? thanks -- Mariano http://marianopeck.wordpress.com

Oct. 4, 2011