- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Moose-dev] Re: collection>>sum:

by Sven Van Caekenberghe

Hi, I agree with Frank on the processing block: it has nothing to do with summing. Mathematically, defining adding (sum) leads to a neutral element (zero). But you only need it if the collection is empty. The trick of the #zero selector is elegant, but not needed with the #anyOne trick. Currently, #sum does not work with empty collections in Pharo, which surprised me. I would add a Collection>>#sumFrom: value ^ self inject: value into: [ :sum :each | sum + each ] And change Collection>>#sum | sample sum | self isEmpty ifTrue: [ ^ self sumFrom: 0 ]. sample := self anyOne. sum := self inject: sample into: [ :sum :each | sum + each ]. ^ sum - sample A variant with an additional collect style processing block could be added along these lines, #sum: and #sum:from: Sven On 22 Apr 2013, at 12:29, Frank Shearar <frank.shearar(a)gmail.com> wrote: > "Sum" is usually well-defined, so I don't understand what the block's > for. With the block it's more like "take this collection, map the > values with some function, and sum the result". > > If so, it sounds like you're looking for a sugared form of > (myCollection collect: aBlock) inject: self first class zero into: #+. > ? > > (There's already Float class >> #zero and (in Squeak at least) Integer > class >> #zero, and so on. Just add MyUnit class >> #zero and you're > done.) > > frank > > On 22 April 2013 10:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I am CC-ing the pharo mailing list because it can be of interest. >> >> I agree with Guillaume that there is a legitimate need for a generic >> solution. However, at the same time we lose the convenience of simply adding >> numbers, which is likely to be the most encountered use case. >> >> I see a couple of possibilities: >> - add Collection>>sum: aBlock from: aZeroValue that takes aZeroValue as the >> default. >> - add Collection>>sumNumbers: aBlock that takes 0 as default rather than >> anyOne. >> >> What do you think? >> >> Cheers, >> Doru >> >> >> >> On Mon, Apr 22, 2013 at 10:14 AM, Guillaume Larcheveque >> <guillaume.larcheveque(a)gmail.com> wrote: >>> >>> For example, in Artefact we use Units and I have tried to use sum but it >>> doesn't works because Units doesn't allow to do 0 + 4 cm which is >>> inconsistent. >>> >>> >>> 2013/4/22 Alexandre Bergel <alexandre.bergel(a)me.com> >>>> >>>> Thanks for letting us know. I cannot see a case where having 0 as the >>>> initial value does not work as expected. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> Le 21 avr. 2013 Ã 17:35, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >>>> >>>>> Hi, >>>>> >>>>> Pharo 2.0 comes with Collection>>sum: >>>>> >>>>> Collection>>sum: aBlock >>>>> "This is implemented using a variant of the normal inject:into: >>>>> pattern. >>>>> The reason for this is that it is not known whether we're in the >>>>> normal >>>>> number line, i.e. whether 0 is a good initial value for the sum. >>>>> Consider a collection of measurement objects, 0 would be the >>>>> unitless >>>>> value and would not be appropriate to add with the unit-ed objects." >>>>> | sum sample | >>>>> sample := aBlock value: self anyOne. >>>>> sum := self inject: sample into: [ :previousValue :each | >>>>> previousValue + (aBlock value: each) ]. >>>>> ^ sum - sample >>>>> >>>>> To some extent, this is more generic than the one we had in Moose that >>>>> considered only numbers: >>>>> Collection>>sum: aSymbolOrBlock >>>>> ^ self >>>>> inject: 0 >>>>> into: [:sum :each | sum + (aSymbolOrBlock value: each)] >>>>> >>>>> >>>>> However, with the Pharo 2.0 implementation the collection must not be >>>>> empty, while the other implementation we get 0. If the collection is empty, >>>>> you get an exception due to anyOne. >>>>> >>>>> This induced several errors in metric computations (like number of >>>>> methods of a package when the package had no classes). These are now fixed, >>>>> but I thought I would let you know just in case you want to rely on this >>>>> method. >>>>> >>>>> I actually still believe we would benefit from a robust but more >>>>> limited sum:. Perhaps we could have sumNumbers:. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "If you can't say why something is relevant, >>>>> it probably isn't." >>>>> >>>>> >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> -- >>> Guillaume Larcheveque >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

April 22, 2013

Re: [Pharo-project] Question about AST annotation scopes order

by Marcus Denker

On Apr 22, 2013, at 1:23 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Hi! > > I'm taking a look at the AST annotation in > > RBProgramNode>>annotateInClass: aBehavior > self annotateInScope: (RBVariableScope > owner: (RBLiteralScope > owner: RBRootScope new > class: aBehavior) > class: aBehavior) > > With that code, the order in which variables are annotated is > > 1) inst vars > 2) literal vars (class vars, pools, globals in the environment) > 3) the root scope -> pseudo-vars (self, super, thiscontext) > > Shouldn't the order be different? Something like: > > 1) pseudo-vars (self, super, thiscontext) > 2) inst vars > 3) literal vars (class vars, pools, globals in the environment) > > So there are never conflicts, and no other scope can bind pseudo-vars? Hello, For now Opal is not using the semantic analysis of AST-Semantics but instead it's own. (it is more low-level with escaping variables and things like that). So the goal is to merge the two. What I wanted to say: No idea. :-) In Opal, self, super, thiscontex is in the Method Scope while self and super is in the Instance scope. So the lookup is temps + thisContext ivars + self + super literal vars Marcus

April 22, 2013

[Pharo-project] Question about AST annotation scopes order

by Guillermo Polito

Hi! I'm taking a look at the AST annotation in RBProgramNode>>annotateInClass: aBehavior self annotateInScope: (RBVariableScope owner: (RBLiteralScope owner: RBRootScope new class: aBehavior) class: aBehavior) With that code, the order in which variables are annotated is 1) inst vars 2) literal vars (class vars, pools, globals in the environment) 3) the root scope -> pseudo-vars (self, super, thiscontext) Shouldn't the order be different? Something like: 1) pseudo-vars (self, super, thiscontext) 2) inst vars 3) literal vars (class vars, pools, globals in the environment) So there are never conflicts, and no other scope can bind pseudo-vars? Cheers, Guille

April 22, 2013

Re: [Pharo-project] [Moose-dev] Re: collection>>sum:

by Frank Shearar

"Sum" is usually well-defined, so I don't understand what the block's for. With the block it's more like "take this collection, map the values with some function, and sum the result". If so, it sounds like you're looking for a sugared form of (myCollection collect: aBlock) inject: self first class zero into: #+. ? (There's already Float class >> #zero and (in Squeak at least) Integer class >> #zero, and so on. Just add MyUnit class >> #zero and you're done.) frank On 22 April 2013 10:37, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am CC-ing the pharo mailing list because it can be of interest. > > I agree with Guillaume that there is a legitimate need for a generic > solution. However, at the same time we lose the convenience of simply adding > numbers, which is likely to be the most encountered use case. > > I see a couple of possibilities: > - add Collection>>sum: aBlock from: aZeroValue that takes aZeroValue as the > default. > - add Collection>>sumNumbers: aBlock that takes 0 as default rather than > anyOne. > > What do you think? > > Cheers, > Doru > > > > On Mon, Apr 22, 2013 at 10:14 AM, Guillaume Larcheveque > <guillaume.larcheveque(a)gmail.com> wrote: >> >> For example, in Artefact we use Units and I have tried to use sum but it >> doesn't works because Units doesn't allow to do 0 + 4 cm which is >> inconsistent. >> >> >> 2013/4/22 Alexandre Bergel <alexandre.bergel(a)me.com> >>> >>> Thanks for letting us know. I cannot see a case where having 0 as the >>> initial value does not work as expected. >>> >>> Cheers, >>> Alexandre >>> >>> >>> Le 21 avr. 2013 Ã 17:35, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >>> >>> > Hi, >>> > >>> > Pharo 2.0 comes with Collection>>sum: >>> > >>> > Collection>>sum: aBlock >>> > "This is implemented using a variant of the normal inject:into: >>> > pattern. >>> > The reason for this is that it is not known whether we're in the >>> > normal >>> > number line, i.e. whether 0 is a good initial value for the sum. >>> > Consider a collection of measurement objects, 0 would be the >>> > unitless >>> > value and would not be appropriate to add with the unit-ed objects." >>> > | sum sample | >>> > sample := aBlock value: self anyOne. >>> > sum := self inject: sample into: [ :previousValue :each | >>> > previousValue + (aBlock value: each) ]. >>> > ^ sum - sample >>> > >>> > To some extent, this is more generic than the one we had in Moose that >>> > considered only numbers: >>> > Collection>>sum: aSymbolOrBlock >>> > ^ self >>> > inject: 0 >>> > into: [:sum :each | sum + (aSymbolOrBlock value: each)] >>> > >>> > >>> > However, with the Pharo 2.0 implementation the collection must not be >>> > empty, while the other implementation we get 0. If the collection is empty, >>> > you get an exception due to anyOne. >>> > >>> > This induced several errors in metric computations (like number of >>> > methods of a package when the package had no classes). These are now fixed, >>> > but I thought I would let you know just in case you want to rely on this >>> > method. >>> > >>> > I actually still believe we would benefit from a robust but more >>> > limited sum:. Perhaps we could have sumNumbers:. >>> > >>> > Cheers, >>> > Doru >>> > >>> > >>> > -- >>> > www.tudorgirba.com >>> > >>> > "If you can't say why something is relevant, >>> > it probably isn't." >>> > >>> > >>> > _______________________________________________ >>> > Moose-dev mailing list >>> > Moose-dev(a)iam.unibe.ch >>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> >> >> -- >> Guillaume Larcheveque >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

April 22, 2013

Re: [Pharo-project] [Moose-dev] Re: collection>>sum:

by Tudor Girba

Hi, I am CC-ing the pharo mailing list because it can be of interest. I agree with Guillaume that there is a legitimate need for a generic solution. However, at the same time we lose the convenience of simply adding numbers, which is likely to be the most encountered use case. I see a couple of possibilities: - add Collection>>sum: aBlock from: aZeroValue that takes aZeroValue as the default. - add Collection>>sumNumbers: aBlock that takes 0 as default rather than anyOne. What do you think? Cheers, Doru On Mon, Apr 22, 2013 at 10:14 AM, Guillaume Larcheveque < guillaume.larcheveque(a)gmail.com> wrote: > For example, in Artefact we use Units and I have tried to use sum but it > doesn't works because Units doesn't allow to do 0 + 4 cm which is > inconsistent. > > > 2013/4/22 Alexandre Bergel <alexandre.bergel(a)me.com> > >> Thanks for letting us know. I cannot see a case where having 0 as the >> initial value does not work as expected. >> >> Cheers, >> Alexandre >> >> >> Le 21 avr. 2013 Ã 17:35, Tudor Girba <tudor(a)tudorgirba.com> a Ã©crit : >> >> > Hi, >> > >> > Pharo 2.0 comes with Collection>>sum: >> > >> > Collection>>sum: aBlock >> > "This is implemented using a variant of the normal inject:into: >> pattern. >> > The reason for this is that it is not known whether we're in the >> normal >> > number line, i.e. whether 0 is a good initial value for the sum. >> > Consider a collection of measurement objects, 0 would be the unitless >> > value and would not be appropriate to add with the unit-ed objects." >> > | sum sample | >> > sample := aBlock value: self anyOne. >> > sum := self inject: sample into: [ :previousValue :each | >> previousValue + (aBlock value: each) ]. >> > ^ sum - sample >> > >> > To some extent, this is more generic than the one we had in Moose that >> considered only numbers: >> > Collection>>sum: aSymbolOrBlock >> > ^ self >> > inject: 0 >> > into: [:sum :each | sum + (aSymbolOrBlock value: each)] >> > >> > >> > However, with the Pharo 2.0 implementation the collection must not be >> empty, while the other implementation we get 0. If the collection is empty, >> you get an exception due to anyOne. >> > >> > This induced several errors in metric computations (like number of >> methods of a package when the package had no classes). These are now fixed, >> but I thought I would let you know just in case you want to rely on this >> method. >> > >> > I actually still believe we would benefit from a robust but more >> limited sum:. Perhaps we could have sumNumbers:. >> > >> > Cheers, >> > Doru >> > >> > >> > -- >> > www.tudorgirba.com >> > >> > "If you can't say why something is relevant, >> > it probably isn't." >> > >> > >> > _______________________________________________ >> > Moose-dev mailing list >> > Moose-dev(a)iam.unibe.ch >> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > > > > -- > *Guillaume Larcheveque* > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- www.tudorgirba.com "Every thing has its own flow"

April 22, 2013

[Pharo-project] [update 3.0] #30052

by Marcus Denker

30052 ----- 6745 Remove EncryptedMultiDisplayScanner and users https://pharo.fogbugz.com/f/cases/6745 10351 remove broken textual inst var renaming code https://pharo.fogbugz.com/f/cases/10351 10344 Fix SpecInterpreter https://pharo.fogbugz.com/f/cases/10344 10355 AlainTreeModel whenSelectedItemsChanged: fixed https://pharo.fogbugz.com/f/cases/10355 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Text-MarcusDenker.58 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Widgets-MarcusDenker.125 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Layout-MarcusDenker.41 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Polymorph-Widgets-MarcusDenk… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Core-MarcusDenker.101 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Morphic-MarcusDenker.1399 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1368

April 22, 2013

[Pharo-project] [update 3.0] #30051

by Marcus Denker

30051 ----- 10333 Update Opal in Image to latest version https://pharo.fogbugz.com/f/cases/10333/ Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/OpalCompiler-Tests-MarcusDen… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/OpalCompiler-Core-MarcusDenk… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/CompilerTests-MarcusDenker.1…

April 22, 2013

[Pharo-project] [update 3.0] #30050

by Marcus Denker

30050 ----- 10033 Integrate AST interpreter https://pharo.fogbugz.com/f/cases/10033 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/UIManager-MarcusDenker.99 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Kernel-MarcusDenker.1367 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/AST-Interpreter-Semantic-Bin… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/AST-Interpreter-Test-MarcusD… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/AST-Interpreter-Core-MarcusD… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/AST-Interpreter-Extension-Ma…

April 22, 2013

Re: [Pharo-project] plugin in Nautilus

by stephane ducasse

yes! we could try to see. > Group are made for this. > > Maybe we should automatically create a new group when a package is loaded > Ben > > On Apr 21, 2013, at 4:23 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >> I tried to use groups, but it does not really work for me. Here is my scenario: >> >> I take a fresh image, I load Versionner then I load Roassal. >> I open a code browser, and guess what, I want to see Roassal and Versionner right away, and not have to scroll down. >> >> But I think that the most important, is to be able to particularize the system, and not really to get the best behavior. >> >> Cheers, >> Alexandre >> >> >> >> On Apr 20, 2013, at 3:32 AM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: >> >>> I use a group for that :) >>> >>> And what I would love is a group: >>> latest loaded packages. >>> >>> >>> On Apr 20, 2013, at 12:24 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> >>>> Hi! >>>> >>>> Is there a documentation on how to create a plugin for Nautilus? >>>> >>>> I would like to create a command 'Hide all packages' in the Package column of Nautilus. Any hint on how to do this? >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >

April 21, 2013

Re: [Pharo-project] [BUG] Fix for MorphTreeMorph>>updateList

by Marcus Denker

On Apr 21, 2013, at 5:27 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > I know, but I will not do it right now and I don't want to forget it. > To not forget it, I added https://pharo.fogbugz.com/f/cases/10352/Fix-for-MorphTreeMorph-updateList ;-) > Hilaire > > Le 21/04/2013 17:13, Marcus Denker a Ã©crit : >> Hi, >> >> the easiest way to get fixes integrated is: >> >> -> add a bug tracker entry >> -> Make a SLICE, upload it to the inbox >> -> mention that there is a slice and set the issue in the tracker to "review need" >> >> If the person who did a fix does all that it will be the fastest. >> >> Marcus >> >> On Apr 21, 2013, at 4:56 PM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: >> >>> The scrollbar should be scrolled to the position before update. >>> Fix enclosed. >>> >>> Thanks >>> >>> Hilaire >>> >>> -- >>> Dr. Geo http://drgeo.eu >>> <MorphTreeMorph-updateList.st> >> >> >> > > > -- > Dr. Geo http://drgeo.eu > >

April 21, 2013