May 2009 - Pharo-dev - lists.pharo.org

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

[Pharo-project] Smalltalk idiom

by Ramiro Diaz Trepat

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? Cheers r.

May 20, 2009

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

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 20, 2009

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

by Alexandre Bergel

> However, there are few things to add: > > - the same situation can happen with removed classes, not only methods > - suppose I found in which version a method was removed. What can I > do ? just see commit comments. So, apart from that, we have to put a > description in the comment that explains what was removed for > example an even why. > > What do you think ? It makes sense. The method or the class could even be reintroduced. I will give a try in the next few days. 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 20, 2009

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

by StÃ©phane Ducasse

henrik May be we can find a slow machine for you :) if this could fuel your passion to fix that. Having a fast UI is still really important. Stef On May 19, 2009, at 10:24 PM, Henrik Sperre Johansen wrote: > FreetypeFont rendering is alot slower than StrikeFont rendering. > There's surely some microoptimizations possible, but one big > (theoretical at least) macro-level enhancement is: > - Currently, morphs by default do not respect the damagerect when > rendering submorphs, instead clipping by its own clippingBounds. > Which means however small the damage to the window was, all > submorphs WILL be redrawn. > Attached is a changeset which changes this, instead intersecting the > Morphs clippingBounds with the Canvas' current clipRect. > > Sadly, this will NOT improve typing performance by itself, as > another problem here is Morphs reporting waaaay too big damage rects > in alot of cases. (try evaluating (Preferences preferenceAt: > #debugShowDamage) preferenceValue: true, and see the damage reported > by a single keypress...) > This has to be rectified on a Morph by Morph basis, as well as > making the displayOn: method use the clipRect intelligently (see > MultiNewParagraph >> displayOn:using:at: for an example of this ). > Personally, I'm not affected enough to fuel the passion to do this, > but if anyone are, I suspect the steps described above are the ones > which will yield the best results, performancewise. > > So what's the changeset currently good for? (Non- > fastForMorphic)resizing of a simple morph that occludes only some of > another SystemWindow's submorphs should see some improvements. > Resizing a window with nothing below will probably suffer abit due > to the extra operation/garbage from the intersect: though. > I haven't had access to a slow enough machine to have visual > confirmation, nor any automated tests to test resizing performance, > so take it with a grain of salt as this is purely in theory :) (Or > file it in and do a quick visual check of the effects described > above if you're on a slow machine) > > Cheers, > Henry > > > On 18.05.2009 16:08, Adrian Lienhard wrote: >> >> I also noticed the slow responsiveness (and I am on a quite fast >> machine). >> Adrian >> >> On May 18, 2009, at 15:57 , Schwab,Wilhelm K wrote: >> >> >>> Damien, >>> >>> In a word, WOW. >>> >>> Have you changed the desktop menus somehow? A left click now (I >>> _think_ this is new) gives me a find-window menu, and it takes a >>> right click to get the world menu, which looks different to me. >>> Wait - this might just be themes? I seleected Vistary and things >>> are back to "normal." >>> >>> >>> One snag: I find this image to very sluggish on typing. In fairness >>> I am running Ubuntu on an older machine that isn't the fastest, but >>> it is still far more sluggish than even my recent web image (10303), >>> and that (I think) has lost some speed too. Sorry to keep harping >>> on this, but I type pretty fast (enough to draw complaints in a >>> crowded room). Maybe there is so much noise because every third key >>> is the backspace :) >>> >>> The anti-aliased fonts are wonderful, but for me at least, snappy >>> response to the keyboard is more important. Having both would be >>> great! >>> >>> Bill >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr >>> ] On Behalf Of Damien Cassou [damien.cassou(a)gmail.com] >>> Sent: Monday, May 18, 2009 8:02 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] New Pharo based on core 10309 with >>> antialiased fonts >>> >>> On Mon, May 18, 2009 at 1:51 PM, Adrian Lienhard <adi(a)netstyle.ch> >>> wrote: >>> >>>> I agree with Lukas, Bill, and Simon (that is, to change the default >>>> font to DejaVu Sans). >>>> >>> Ok, here is the new version. What do you think? >>> >>> font := LogicalFont familyName: 'DejaVu Sans' pointSize: 10. >>> codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. >>> titleFont := LogicalFont familyName: 'DejaVu Serif' pointSize: 11. >>> >>> Preferences setListFontTo: font. >>> Preferences setMenuFontTo: font. >>> Preferences setCodeFontTo: codeFont. >>> Preferences setButtonFontTo: font. >>> Preferences setSystemFontTo: font. >>> Preferences setWindowTitleFontTo: titleFont. >>> >>> -- >>> 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 >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > < > submorphsrespectingdamagerect > .st>_______________________________________________ > 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