- Pharo-dev - lists.pharo.org

About Pharo in Ohloh

by kilon alios

As you know Ohloh is a very good promotional site for open source projects. Pharo has already a page on it. However I did observe that Pharo page experiences the same issue as Amber. In Amber it reported that 80% of the project was made with Javascript. It reported that because Amber compiles it source code (smalltalk) to javascript. So all I had to do was to go to preferences page and add ignore filter for javascript folders and viola since then Amber is reported to be 80% smalltalk. http://www.ohloh.net/p/pharo Pharo is in somewhat or even more weird situation. Its reported to be 30% C which is the bad and 17% C# (WTF?) and 30% some other thing which are the weird parts. So maybe if you add ignore filters for some of the folders it may be able to increase the % of the smalltalk. It does not take time and if I was familiar with the build process of Pharo I could do it for you, but I have no clue. I assume it probably sees Slang as C# though I am not sure. I think its unfair for Pharo to be given the impression of a C/C# project.

Dec. 19, 2013

Re: [Pharo-dev] gtinspector deconstructed

by Tudor Girba

Hi Roberto, Thanks for expressing an interest :). Please let us know when you encounter something that does not work for you. This is a critical tool in a Pharo environment and we need all the feedback we can get to improve it. It can indeed feel strange at first as it requires you to work a bit differently. Just out of curiosity: have you read the post already? Does it address your concerns? Dies it provide hints for how your workflow can be different? Cheers, Doru On Thu, Dec 19, 2013 at 9:38 AM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > Hi Doru, > > I have never used it till 2 days ago when I was playing with Andrei to do > something. > > The only thing I can say is that it âfeelsâ strange at the beginningâ¦ I am > not used to this horizontal navigationâ¦ I am more used to spawning a lot of > small inspectors that I can also use to compare things, i.e., one inspector > close to the other. > > Apart from that, Andrei told me it takes time but then you get used to it > and you love it. Letâs see. > > Cheers, > R > > On Dec 19, 2013, at 7:50 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > I took a bit of time to describe how the GTInspector works, what makes > it different, and to provide hints for several usage scenarios. > > > http://www.humane-assessment.com/blog/the-moldable-gtinspector-deconstructed > > > > It's a long post, I know :), but please take a look. As you might know, > this is the default inspector in the Moose image, but it can also be loaded > in a fresh Pharo image. > > > > I am particularly interested in the following: > > - if you never used it, and tried it now, what don't you like? > > - if you used it, was there anything that you did not know? > > - and of course, what do you like about it? > > > > Cheers, > > Doru > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Dec. 19, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30654 Home: https://github.com/pharo-project/pharo-core

Dec. 19, 2013

[pharo-project/pharo-core] 845bfd: 30654

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 845bfde743adcc8cd68a235ef2101e6cf52b8de0 https://github.com/pharo-project/pharo-core/commit/845bfde743adcc8cd68a235e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-19 (Thu, 19 Dec 2013) Changed paths: M Morphic-Base.package/SystemWindow.class/definition.st A Morphic-Base.package/SystemWindow.class/instance/controls/beResizeable.st A Morphic-Base.package/SystemWindow.class/instance/controls/beUnresizeable.st A Morphic-Base.package/SystemWindow.class/instance/controls/defaultIsResizeable.st A Morphic-Base.package/SystemWindow.class/instance/controls/isResizeable.st A Morphic-Base.package/SystemWindow.class/instance/controls/isResizeable_.st M Polymorph-Widgets.package/DialogWindow.class/definition.st R Polymorph-Widgets.package/DialogWindow.class/instance/controls/beResizeable.st R Polymorph-Widgets.package/DialogWindow.class/instance/controls/beUnresizeable.st A Polymorph-Widgets.package/DialogWindow.class/instance/testing/defaultIsResizeable.st R Polymorph-Widgets.package/DialogWindow.class/instance/testing/isResizeable.st M Polymorph-Widgets.package/extension/SystemWindow/instance/canBeMaximized.st M Polymorph-Widgets.package/extension/SystemWindow/instance/doubleClick_.st M Polymorph-Widgets.package/extension/SystemWindow/instance/wantsGrips.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script307.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30654.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30654 12385 Move isResizeable to SystemWindow https://pharo.fogbugz.com/f/cases/12385 http://files.pharo.org/image/30/30654.zip

Dec. 19, 2013

[OT] ouch! Too few likes?

by Sebastian Sastre

Hi there, I don't believe in vanity metrics but I'm receiving some critics about low quantity of likes that would be nice to answer. Can you help us boost this pharo-powered app with your like here? https://www.facebook.com/airflowing Many many thanks! Also this should help us to promote it later if we choose to because facebook itself requires a minimum of likes to give you commercial campaign tools Again thank you for your support! sebastian o/ PD: sorry we're prioritising portuguese there but most of our paying clients are in fact from Brazil, thanks again!

Dec. 19, 2013

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

by Nicolas Cellier

2013/12/19 <btc(a)openinworld.com> > Nicolas Cellier wrote: > >> 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? >> >> 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... >> >> 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? >> > Could 6 bits be enough for transparency? Perhaps only for Pharo's own > system & UI stuff. Any bitmap editor application would probably need to > extend to handle the full 8 bit alpha. Or maybe that adds unneeded > complexity. > > cheers -ben > > Yes, it would be sufficient, but it seems simpler to manage a separate 8 bit alpha channel as it is the case now.

Dec. 19, 2013

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

by Nicolas Cellier

2013/12/19 Bert Freudenberg <bert(a)freudenbergs.de> > > On 19.12.2013, at 18:06, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > 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? > > 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... > > 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? > > > All opaque colors would be LargeIntegers, not SmallIntegers: 16rFFxxxxxx. > > - Bert - > > Yes, that's why we would need to invert the encoding of alpha channel... But this change would be much more intrusive (change primitives...), and not really compatible with established practices where alpha channel is interpreted as opcity level, not as transparency level ( http://en.wikipedia.org/wiki/RGBA_color_space) I think we can forget this part of the proposition which is too much Smalltalk-centric. Nicolas

Dec. 19, 2013

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

by btc＠openinworld.com

Nicolas Cellier wrote: > 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? > > 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... > > 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? Could 6 bits be enough for transparency? Perhaps only for Pharo's own system & UI stuff. Any bitmap editor application would probably need to extend to handle the full 8 bit alpha. Or maybe that adds unneeded complexity. cheers -ben

Dec. 19, 2013

Why Color rgb components are on 10 bits?

by Nicolas Cellier

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? 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... 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. 19, 2013

Re: [Pharo-dev] Problem with wrapping text in pdf documentation

by Damien Cassou

On Thu, Dec 19, 2013 at 11:54 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > Take a look here > > https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… > > code is cut out and does not wrap. Looks it exceeds its boundaries. Maybe > some sort of bug ? Fixed. That was a problem in the sources. The text was: =User >> fuelAfterMaterialization = acumulatedLogins := 0. whereas it should have been: [[[language=Smalltalk User >> fuelAfterMaterialization acumulatedLogins := 0. ]]] -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Dec. 19, 2013