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

Re: [Pharo-dev] [squeak-dev] Re: Why Color rgb components are on 10 bits?

by Nicolas Cellier

2013/12/25 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > > 2013/12/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> Hello nicolas >> >> > I know the answer, we have 30 bits available for keeping the rgb >> instance variable as SmallInteger... >> > So it's the best we can do, while keeping an efficient format. >> > >> > But we are never using 10 bits for each component, for 32 bits image >> only 8 bit by color are used. >> > Since nowadays most Forms are 32 bits deep, this force useless >> conversions where we could have none. >> > >> > I see that Pharo 3.0 did unify Color and TranslucentColor by moving the >> alpha information in Color. >> > But did not change the rgb ComponentMax... Any reason why? >> >> No special reason. We just started to clean the code to understand it and >> avoid isKindOf: and because we thought >> that there is no need to have color and translucent colors anymore. >> >> > If we encoded rgb component on 8 bits, and reverted the alpha channel >> encoding, then we could have colors pre-encoded on 32 bits, but most using >> only 24 bits (because most are opaque) would be represented as SmallInteger. >> > But I don't know if it is really inter-operable, or more naturalâ¦ >> >> Thanks for the discussion. Now do you have an idea about the speed gain? >> > > Absolutely no idea. > BitBlt is rich enough (color maps or direct color components, depths, > endianness) to make this unpredictable by simply analyzing sender chain in > source code (it's too deep and convoluted). > The best way is to try it, but then one must choose a benchmark, and here > again it is a difficult decision, because maybe you didn't bench a path > that some other use intensively, how to guess without above analysis? > > I saw those un-necessary mismatch while analyzing Graphics code... > By a principle of economy, I suggest to remove them. > Simplifying code a little bit is already a win. > > BTW, did you see that scaled rgb components use 10bits while scaled alpha uses 8? This was in Squeak already and has been perpetuated in Pharo refactoring... Then, les petits ruisseaux font les grandes riviÃ¨res, cumulated micro > optimizations may pay. > > > >> > Juan followed another path for Cuis, opting for float components, which >> is another possibility, but our VM are not yet optimized for handling >> Floats... >> > >> > Thoughts? >> >> >> >

Dec. 25, 2013

Re: [Pharo-dev] [squeak-dev] Re: Why Color rgb components are on 10 bits?

by Nicolas Cellier

2013/12/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Hello nicolas > > > I know the answer, we have 30 bits available for keeping the rgb > instance variable as SmallInteger... > > So it's the best we can do, while keeping an efficient format. > > > > But we are never using 10 bits for each component, for 32 bits image > only 8 bit by color are used. > > Since nowadays most Forms are 32 bits deep, this force useless > conversions where we could have none. > > > > I see that Pharo 3.0 did unify Color and TranslucentColor by moving the > alpha information in Color. > > But did not change the rgb ComponentMax... Any reason why? > > No special reason. We just started to clean the code to understand it and > avoid isKindOf: and because we thought > that there is no need to have color and translucent colors anymore. > > > If we encoded rgb component on 8 bits, and reverted the alpha channel > encoding, then we could have colors pre-encoded on 32 bits, but most using > only 24 bits (because most are opaque) would be represented as SmallInteger. > > But I don't know if it is really inter-operable, or more naturalâ¦ > > Thanks for the discussion. Now do you have an idea about the speed gain? > Absolutely no idea. BitBlt is rich enough (color maps or direct color components, depths, endianness) to make this unpredictable by simply analyzing sender chain in source code (it's too deep and convoluted). The best way is to try it, but then one must choose a benchmark, and here again it is a difficult decision, because maybe you didn't bench a path that some other use intensively, how to guess without above analysis? I saw those un-necessary mismatch while analyzing Graphics code... By a principle of economy, I suggest to remove them. Simplifying code a little bit is already a win. Then, les petits ruisseaux font les grandes riviÃ¨res, cumulated micro optimizations may pay. > > > Juan followed another path for Cuis, opting for float components, which > is another possibility, but our VM are not yet optimized for handling > Floats... > > > > Thoughts? > > >

Dec. 25, 2013

Re: [Pharo-dev] Critical ClassBuilder bug

by StÃ©phane Ducasse

Ok I do not understand why I just receive today these old mails :) On 25 Dec 2013, at 20:53, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 25 Dec 2013, at 20:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Guillermo >> >> do you have a test because we should really cover the classBuilder with such >> scenario? >> > > Yes, tests and the fix have been integrated last friday. > >> Stef >> On 17 Dec 2013, at 16:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >>> Hi!! >>> >>> I started this afternoon to see a bug on class bindings on trait methods. This one: https://pharo.fogbugz.com/f/cases/11756/Reshaping-a-class-breaks-classBindi… >>> >>> Now, after playing and moving around that, I noticed that the problem is worse: >>> >>> 1)Create Class A. >>> 2)Create method A>>m1. >>> 3)Create method A>>m2. >>> 4)reshape the class (e.g. add an inst var) >>> >>> Then: (A>>#m2) classBinding == (A>>#m3) classBinding ==> false!!! >>> >>> >>> The problem is caused because the recompilation of the methods is taking place in a class that is not yet installed in its environment (the Smalltalk system dictionary in this case). The installation of the class takes part after the reshaping+the recompilation. Then, when the methods are compiled, the binding is not available for them and new bindings are created. >>> >>> Would someone with more idea on the new class builder give some advice? Cause I'm a bit lost in the new class builder code :) >>> >>> Tx, >>> Guille >> >

Dec. 25, 2013

Re: [Pharo-dev] [Moose-dev] Re: Activity Diagram

by StÃ©phane Ducasse

Yes you are right. I was looking at the code today and this is too large. I will read the code from time to time to see what we can do with it because may be a lighter version would be good. Stef >> Yes indeed then in that case I would really try to get ConnectorMorph working in pharo. >> I can send you a drop box with a working version in 3.9 >> > > Keep in mind that Connectors where a quite huge and complex (and intrusive) > (yet *Very very* coolâ¦) piece of workâ¦ getting them to work in Pharo will be a challenge. > > In the end, I think the largest problem of connectors always was that they here not merged > with Morphic *for real* (while cleaning up both), as they show very much the real power of Morphic. > > I did start to integrate the hooks + enhancements in Squeak 3.9, but in the end it turned out > to be quite a hack in some parts and thus just increased the complexity of Morphicâ¦ > > Marcus

Dec. 25, 2013

Re: [Pharo-dev] PackageTreeNautilus (undestroyable?)

by StÃ©phane Ducasse

Hi esteban so is it a bug or not? I do not like having all these announcement hanging around. In Pharo 40 we should also revisit the announcer subclasses. Stef On 20 Dec 2013, at 16:07, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > yeah, I call him âthe willisâ :) > > On 19 Dec 2013, at 22:25, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> Hi, >> >> I recently noticed a awful big number of Announcer instances (thousends). >> I traced them back to PackageTreeNautilus. I closed the unsaved image >> and reopened pharo. >> I couldn't reproduce this but found out, that if you opened Nautilus once, >> there will allways be one instance of PackageTreeNautilus >> even if you close all windows. >> >> How to reproduce: >> Load a freshly image. >> >> Announcer allInstances size.-> 155 >> PackageTreeNautilus allInstances size. -> 0 >> >> Open and close Nautilus. >> >> SmalltalkImage current garbageCollect. >> Announcer allInstances size. -> 1261 >> PackageTreeNautilus allInstances size. -> 1 >> >> This instance of PackageTreeNautilus won't go away. >> Is this intended? >> >> >> Nicolai > >

Dec. 25, 2013

Re: [Pharo-dev] Why Color rgb components are on 10 bits?

by StÃ©phane Ducasse

Hello nicolas > I know the answer, we have 30 bits available for keeping the rgb instance variable as SmallInteger... > So it's the best we can do, while keeping an efficient format. > > But we are never using 10 bits for each component, for 32 bits image only 8 bit by color are used. > Since nowadays most Forms are 32 bits deep, this force useless conversions where we could have none. > > I see that Pharo 3.0 did unify Color and TranslucentColor by moving the alpha information in Color. > But did not change the rgb ComponentMax... Any reason why? No special reason. We just started to clean the code to understand it and avoid isKindOf: and because we thought that there is no need to have color and translucent colors anymore. > If we encoded rgb component on 8 bits, and reverted the alpha channel encoding, then we could have colors pre-encoded on 32 bits, but most using only 24 bits (because most are opaque) would be represented as SmallInteger. > But I don't know if it is really inter-operable, or more naturalâ¦ Thanks for the discussion. Now do you have an idea about the speed gain? > > Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats... > > Thoughts?

Dec. 25, 2013

Re: [Pharo-dev] about the Pharo Catalog

by StÃ©phane Ducasse

On 19 Dec 2013, at 11:40, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Thu, Dec 12, 2013 at 9:59 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I really want to have an official catalog soon, so please add the missing metadata in your configurations. > > > please tell us what is a good example of a project so we can get > inspiration from it. Also, can I use Pillar syntax in the strings? Soup you can in the changes and keyclasses use pillar we could use it in the description too. Stef

Dec. 25, 2013

Re: [Pharo-dev] Critical ClassBuilder bug

by Marcus Denker

On 25 Dec 2013, at 20:42, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Guillermo > > do you have a test because we should really cover the classBuilder with such > scenario? > Yes, tests and the fix have been integrated last friday. > Stef > On 17 Dec 2013, at 16:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > >> Hi!! >> >> I started this afternoon to see a bug on class bindings on trait methods. This one: https://pharo.fogbugz.com/f/cases/11756/Reshaping-a-class-breaks-classBindi… >> >> Now, after playing and moving around that, I noticed that the problem is worse: >> >> 1)Create Class A. >> 2)Create method A>>m1. >> 3)Create method A>>m2. >> 4)reshape the class (e.g. add an inst var) >> >> Then: (A>>#m2) classBinding == (A>>#m3) classBinding ==> false!!! >> >> >> The problem is caused because the recompilation of the methods is taking place in a class that is not yet installed in its environment (the Smalltalk system dictionary in this case). The installation of the class takes part after the reshaping+the recompilation. Then, when the methods are compiled, the binding is not available for them and new bindings are created. >> >> Would someone with more idea on the new class builder give some advice? Cause I'm a bit lost in the new class builder code :) >> >> Tx, >> Guille >

Dec. 25, 2013

Re: [Pharo-dev] inspect slices

by StÃ©phane Ducasse

I would take an older image and do a merge like that you see the changes contained in the slices but this is not satisfactory. I would like to have a db storing all the changes and that we could do queries like show me the diff between the senders of foo in version 30399 and 30405 we are slowly getting there. Stef > On 18 Dec 2013, at 00:26, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > How can I find out the changes from a slice that is already included > > in the main image? > > So what I just do is to âmergeâ â> if empty, all changes are in. > > Marcus > > > This "all changes are in" case is where I want to know "what were these changes". > Or, how can we "undo" those changes made by the fix for issue 12288, for example. > Or can I open a version browser on all those changes from this slice. > > Nicolai >

Dec. 25, 2013

Re: [Pharo-dev] Easy issue to fix: 12063

by StÃ©phane Ducasse

> \That wasn't a report of a bug. It was just tracking my progress as I tried to understand it - but point taken - it is easier for reviewers if there is not too much irrelevant details. > btw, What do you think about Finder > Search > Source being inclusive of class comments? Yes it should be like that :) > Then I would not have ended up down that path. > > > btw2, Slice submitted for 12063, and also a new related one I found along the way > https://pharo.fogbugz.com/f/cases/12446 > > cheers -ben

Dec. 25, 2013