- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Tracing changes in MC

by Keith Hodges

Lukas Renggli wrote: >> A problem of implementing this is that you have to download each >> version of a repository and analyze it, which can take a considerable >> amount of time. >> > > Such a search is not really practicable. Even if you have the versions > stored locally you need to load and calculate the difference between > the snapshots. Furthermore you might have versions missing that are > required to accurately answer the question. Different branches make > the search even more complicated. > > Monticello 2 can answer such questions efficiently. > > Lukas > > MC1.5 reinstates the in-memory "dictionary" repository to speed up such analyses. The "dual changes" sorter puts two repositories, (or the same repository) on both sides, and the delta's in the middle. There is supposed to be a "report" function which generates a step by step description of thechanges between two repos. This report is supposed to be displayed in the middle. Keith

May 20, 2009

Re: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

by Damien Pollet

I use nearly the same script, except with the sans fonts, and a couple settings: Preferences enable: #halosEnabled; enable: #swapMouseButtons; disable: #gradientMenu. Most important to me is swapMouseButtons, because it puts menus back on the correct button. Apparently this setting is needed on macs and linux, so by the magic of (possibly biased) numbers, the exception is windows. Can we have #swapMouseButtons enabled by default ? On Mon, May 18, 2009 at 10:45, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Mon, May 18, 2009 at 10:37 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >> That looks great, though I would prefer a sans-serif font (DejaVu >> Sans) instead of a serif font (DejaVu Serif) in the UI. >> Serif fonts add too much noise on the screen and are typically used in >> print only, not in user interfaces. > > If people agree with this, I can change that. The script I currently > use is the following one. If you have ideas on how to improve it, > please tell me. > > font := LogicalFont familyName: 'DejaVu Serif' pointSize: 10. > codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. > Preferences setListFontTo: font. > Preferences setMenuFontTo: font. > Preferences setCodeFontTo: codeFont. > Preferences setButtonFontTo: font. > Preferences setSystemFontTo: font. > font := LogicalFont familyName: 'DejaVu Serif' pointSize: 11. > Preferences setWindowTitleFontTo: font. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 20, 2009

Re: [Pharo-project] Symbol>>value:value:

by Lukas Renggli

> self collect: #abs Yes, that looks cool. However it is difficult to understand what it does for #(-2 3 4) - Does it collect the literal #abs for all the values of the collection? --> #(abs abs abs) - Does it collect the values of performing #abs on the collection? --> #(2 3 4) With #value:value: you even have more freedom, and it is even less clear how the result is obtained. The implementation given by the original poster might work in one (common) case, but this is definitely not the only way to use a symbol for evaluation. In Seaside 2.9 there are the classes WADelayedSend, WABoundDelayedSend and WAUnboundDelayedSend that are polymorphic to block closures and that reify different forms of message sends as first class objects. GNU Smalltalk has a similar construct built into their core library. I think that using symbols is a rather poor approach to model message sends. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

May 20, 2009

Re: [Pharo-project] Symbol>>value:value:

by Tudor Girba

Hi, (I apologize for the length of this email, but I did not know how to write it shorter) My reasons for Symbol>>value: and similar selectors are as follows. A Symbol is already used for several things, like a key in an identity dictionary. But it is also used for parameterizing a mapping to a piece of behavior via a #symbol stored in a selector instance variable. Later on, this behavior is invoked as: receiver perform: selector. This is for example what happens in Morphic, and as a result I am forced to create a Model class for a custom Morph, even if the customization is minimal. This is a hurdle when you are in prototype mode. Instead I would like to have the possibility to prototype faster using blocks instead of creating a class. This is possible right now for unary methods when the framework does not directly do a perform:, but instead it does: selector value: receiver. Ideally, we could have in the entire image only one place in which perform: is called explicitly: in the Symbol>>value:. In this way, I will be able to pass a block everywhere a unary method is now used. This is something we do when we want to use Smalltalk for scripting (Mondrian and Glamour do that) The same case goes for Symbol>>value:value: . These two methods would already cover the large majority of performs, but I would argue for adding all possibilities of evaluating blocks and of performing messages. If you are asking what do Symbol have to do with blocks from a conceptual point of view, I will answer that when the Symbol is used as a selector, it does nothing else but point to a piece of behavior. Given that a Block does a similar thing, you can as well treat them in a polymorphic fashion. The only question that remains in my mind is: does a modification like this has the possibility of harming? I am not aware of a case in which it is harmful, but who knows. Cheers, Doru On 20 May 2009, at 15:27, StÃ©phane Ducasse wrote: > value from Object and value: from Symbol are different > with value: on Symbol you can do > > self collect: #abs > > :) > > On May 20, 2009, at 2:48 PM, Gabriel Cotelli wrote: > >> +1 to the removal of value: from Symbol.... >> >> On Wed, May 20, 2009 at 3:18 AM, Lukas Renggli <renggli(a)gmail.com> >> wrote: >>> Given that in Pharo we have Symbol>>value:, are there any reasons >> not >>> to have also >>> >>> Symbol>>value: anObject value: anotherObject >>> ^ anObject perform: self with: anotherObject >> >> While Symbol>>#value: is at the border of being readable, >> Symbol>>#value:value: is even worse. It is not immediately obvious >> what it does. The order of receiver and arguments is hardcoded and >> thus the construct cannot be applied in most cases without rewriting >> the code. Fixed arguments cannot be given. >> >> Instead of adding new #value: variants, we should rather try to >> remove >> Object>>#value which is a real nightmare ;-) >> >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding."

May 20, 2009

Re: [Pharo-project] Symbol>>value:value:

by StÃ©phane Ducasse

value from Object and value: from Symbol are different with value: on Symbol you can do self collect: #abs :) On May 20, 2009, at 2:48 PM, Gabriel Cotelli wrote: > +1 to the removal of value: from Symbol.... > > On Wed, May 20, 2009 at 3:18 AM, Lukas Renggli <renggli(a)gmail.com> > wrote: > > Given that in Pharo we have Symbol>>value:, are there any reasons > not > > to have also > > > > Symbol>>value: anObject value: anotherObject > > ^ anObject perform: self with: anotherObject > > While Symbol>>#value: is at the border of being readable, > Symbol>>#value:value: is even worse. It is not immediately obvious > what it does. The order of receiver and arguments is hardcoded and > thus the construct cannot be applied in most cases without rewriting > the code. Fixed arguments cannot be given. > > Instead of adding new #value: variants, we should rather try to remove > Object>>#value which is a real nightmare ;-) > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 20, 2009

Re: [Pharo-project] Symbol>>value:value:

by Gabriel Cotelli

+1 to the removal of value: from Symbol.... On Wed, May 20, 2009 at 3:18 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Given that in Pharo we have Symbol>>value:, are there any reasons not > > to have also > > > > Symbol>>value: anObject value: anotherObject > > ^ anObject perform: self with: anotherObject > > While Symbol>>#value: is at the border of being readable, > Symbol>>#value:value: is even worse. It is not immediately obvious > what it does. The order of receiver and arguments is hardcoded and > thus the construct cannot be applied in most cases without rewriting > the code. Fixed arguments cannot be given. > > Instead of adding new #value: variants, we should rather try to remove > Object>>#value which is a real nightmare ;-) > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 20, 2009

Re: [Pharo-project] Smalltalk idiom

by Ramiro Diaz Trepat

Hi Igor, Thank you very much for your thorough reply. May be I did not express myself properly, but I am not really interested in discussing the implementation of a Matrix. It was only an example. I'm interested in discussing wether or not people in the community find it neat and useful to have a method that behaves like #collect: but without arguments, just like #timesRepeat: for the iterations. Sorry for the misunderstanding. Cheers r. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: 20 May 2009 09:40 To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Smalltalk idiom 2009/5/20 Ramiro Diaz Trepat <ramiro(a)diaztrepat.name>: > I have a simple question regarding the use of a proper idiom. > I had to create a matrix (n X m) of random values and I used a line similar > to this one: > NMatrix withRows: ((1 to: n) collect: [ :i | random next: m ]). > Since Smalltalk is so neat for its collection handling, I obviously did not > like to write that line. > I thought that I did not want to explicitly create the interval, nor use a > block that requires an > argument that I also don't use. > The question, finally, is if there an elegant way of replicating the > behaviour of #collect: but > without the argument? > In my case, I thought it would be great for Integer to have something like > #timesCollect: > that would allow me to rewrite the line above as: > NMatrix withRows: (n timesCollect: [ random next: m ]) > Does anyone else think that this would be an useful method to have? depends on how you represent a matrix. It seems that you using a collection of N rows. IMO its more efficient to use a flat array, while you can declare the matrix as: Array subclass: #NMatrix instanceVariables: 'numRows' then, an instance size \\ numRows - gives number of columns and you can simply add/override some methods , while reuse most of Collection protocol when you don't need to care about item row/col position - like in regular flat Array. Override a #species method, so NMatrix collect: will create NMatrix when using #collect: and other related methods. Then, a multiplication can be implemented as: NMatrix >>* numberOrMatrix ^ numberOrMatrix isNumber ifTrue: [ self collect: [: each | each * number ] ] ifFalse: [ self mulMatrix: numberOrMatrix ] as you can see, a #collect: method can be used for scalar multiplication. > Cheers > > r. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email.

May 20, 2009

Re: [Pharo-project] Smalltalk idiom

by Igor Stasenko

2009/5/20 Ramiro Diaz Trepat <ramiro(a)diaztrepat.name>: > I have a simple question regarding the use of a proper idiom. > I had to create a matrix (n X m) of random values and I used a line similar > to this one: > NMatrix withRows: ((1 to: n) collect: [ :i | random next: m ]). > Since Smalltalk is so neat for its collection handling, I obviously did not > like to write that line. > I thought that I did not want to explicitly create the interval, nor use a > block that requires an > argument that I also don't use. > The question, finally, is if there an elegant way of replicating the > behaviour of #collect: but > without the argument? > In my case, I thought it would be great for Integer to have something like > #timesCollect: > that would allow me to rewrite the line above as: > NMatrix withRows: (n timesCollect: [ random next: m ]) > Does anyone else think that this would be an useful method to have? depends on how you represent a matrix. It seems that you using a collection of N rows. IMO its more efficient to use a flat array, while you can declare the matrix as: Array subclass: #NMatrix instanceVariables: 'numRows' then, an instance size \\ numRows - gives number of columns and you can simply add/override some methods , while reuse most of Collection protocol when you don't need to care about item row/col position - like in regular flat Array. Override a #species method, so NMatrix collect: will create NMatrix when using #collect: and other related methods. Then, a multiplication can be implemented as: NMatrix >>* numberOrMatrix ^ numberOrMatrix isNumber ifTrue: [ self collect: [: each | each * number ] ] ifFalse: [ self mulMatrix: numberOrMatrix ] as you can see, a #collect: method can be used for scalar multiplication. > Cheers > > r. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 20, 2009

Re: [Pharo-project] Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)

by Lukas Renggli

> A problem of implementing this is that you have to download each > version of a repository and analyze it, which can take a considerable > amount of time. Such a search is not really practicable. Even if you have the versions stored locally you need to load and calculate the difference between the snapshots. Furthermore you might have versions missing that are required to accurately answer the question. Different branches make the search even more complicated. Monticello 2 can answer such questions efficiently. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

May 20, 2009

Re: [Pharo-project] Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)

by Adrian Lienhard

I don't think you are the only one! - the previous version(s) of a method A problem of implementing this is that you have to download each version of a repository and analyze it, which can take a considerable amount of time. Adrian On May 20, 2009, at 10:00 , Alexandre Bergel wrote: > I meant in Monticello. > What I often need is the following: > - the name of the committer who removed/added a class/method > - the comment of the version in which this change occurs. > > Am I the only one who experience this? > > Alexandre > > On 19 May 2009, at 23:33, Michael Roberts wrote: > >> To be honest I think that is the wrong way around. I never need to >> search for a method. I am normally in a debugger so have the method. >> Just want to work out when it changed. However if the only way to >> solve that is to write a top down search rather than a bottom up sort >> of approach then go for it. It should be possible to spawn the search >> from all the browsers. >> >> Thanks mike >> >> On Tuesday, May 19, 2009, Alexandre Bergel <alexandre(a)bergel.eu> >> wrote: >>> the topic of the discussion is not in sync with the thread topic. >>> >>> My answer to Nicolas' was: >>> Here is an idea: >>> - Adding a button 'search' in a Monticello repository >>> inspector (the >>> one you get when opening a repository) >>> - with a 'search' button, you can then enter a method >>> location such >>> as TextMorphEditor>>keystroke: >>> - the list of versions that either added the method or >>> removed it >>> according to the ancestors. >>> >>> How does that sound? I can work on it. >>> >>> Cheers, >>> Alexandre >>> >>> >>> Begin forwarded message: >>> >>>> From: Michael Roberts <mike(a)mjr104.co.uk> >>>> Date: 19 May 2009 19:06:13 CEDT >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] ThirtyTwoBitRegister methods removed >>>> Reply-To: Pharo-project(a)lists.gforge.inria.fr >>>> >>>> In general I would like to see a bit more envy tool like support in >>>> mc. I have not checked out OT or newer mc versions to see what is >>>> implemented. I would like the method vesions tool to map into a mc >>>> version and to quickly go from the class to mc view. Can we do this >>>> already? If not this would be really useful but I appreciate it >>>> has to >>>> be built. Otherwise I too scratch my head trying to work out where >>>> all >>>> the changes come in. I am not for a second proposing the envy model >>>> but the tool was integrated nicely. >>>> thanks mike >>>> >>>> On Tuesday, May 19, 2009, Mariano Martinez Peck >>>> <marianopeck(a)gmail.com> wrote: >>>>> >>>>> >>>>> On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com >>>>>> wrote: >>>>> >>>>> To me, this raises a more general question. >>>>> How can we trace a particular change in Pharo? >>>>> Why when and where this change did occur? I know all is in the >>>>> Monticello repository, but is there a quick and convenient way to >>>>> answer such a question? I mean avoiding a manual scan of each and >>>>> every Monticello version... >>>>> >>>>> Or is it logged in the ChangeSet? In this case, what hidden menu >>>>> or >>>>> code snippet will help tracking the change? >>>>> >>>>> Or should we use the issue tracker? Ideally, the reason for every >>>>> change should be logged here. And every Monticello uploaded should >>>>> refer to an issue. Even if this were strictly applied, not sure >>>>> that >>>>> is the way to retrieve information at such a detailed level. >>>>> >>>>> If none of these tools can provide an easy answer, then yes, >>>>> requests >>>>> on mailing lists, IRC, or internet search can provide a much >>>>> efficient >>>>> answer. But that's the signature a tool is lacking. >>>>> >>>>> I am agree. Actually, I thought to add in my email a generic >>>>> question of that because I faced this problem several times and I >>>>> didn't know what to do. >>>>> >>>>> >>>>> >>>>> I wish Mariano gets an answer, but an answer on the method would >>>>> be >>>>> more profitable to every one. >>>>> No problem. Perhaps someone knows haha. >>>>> >>>>> >>>>> >>>>> Cheers >>>>> >>>>> Nicolas >>>>> >>>>> 2009/5/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>>> Hi folks. I noticed that this two methods were removed from >>>>>> ThirtyTwoBitRegister: >>>>>> >>>>>> asByteArray >>>>>> ^ ByteArray with: (low bitAnd: 16rFF) with: (low bitShift: >>>>>> -8) with: >>>>>> (hi bitAnd: 16rFF) with: (hi bitShift: -8) >>>>>> >>>>>> >>>>>> >>>>>> reverseLoadFrom: aByteArray at: index >>>>>> "Load my 32-bit value from the four bytes of the given >>>>>> ByteArraystarting at the given index. Consider the first byte to >>>>>> contain the >>>>>> mostsignificant bits of the word (i.e., use big-endian byte >>>>>> ordering)." >>>>>> >>>>>> hi := ((aByteArray at: index + 3) bitShift: 8) + >>>>>> ( aByteArray at: >>>>>> index + 2). >>>>>> low := ((aByteArray at: index + 1) bitShift: 8) + >>>>>> ( aByteArray at: >>>>>> index). >>>>>> >>>>>> >>>>>> >>>>>> I need them for Glorp. I looked but I didn't found a similar >>>>>> message for >>>>>> them. I don't think adding them as an extension is a good >>>>>> solution >>>>>> here >>>>>> since this seems to be very "internal". is there a reason of the >>>>>> removing? >>>>>> If not, could them be added again? If there are reason, which >>>>>> should be the >>>>>> best approach to fix this in mi case? >>>>>> >>>>>> I have no problem in commit them if you want. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Mariano >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>>> project >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 20, 2009