November 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] New pharo-dev based on latest version

by StÃ©phane Ducasse

I hope :) we want it in the first version of pharo :) Stef On Nov 11, 2008, at 1:45 PM, Igor Stasenko wrote: > 2008/11/11 Gary Chambers <gazzaguru2(a)btinternet.com>: >> Polymorph fixed the menu gradient oddity a long time ago... :-) >> > > btw, can it be loaded into dev image w/o problems? > I'm missing the taskbar, because when you open many browsers > overlapping each other, its hard to find needed one. > >> Regards, Gary. >> >> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com >> > >> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, November 10, 2008 6:08 PM >> Subject: Re: [Pharo-project] New pharo-dev based on latest version >> >> >>> Some of my observations of glitches found: >>> >>> - open world menu System->About. Now instead of clicking Ok, try >>> drag >>> the window. Leads to DNU when you release a mouse button. >>> >>> - a submenu gradient in OB (maybe not only in OB) is sporadically >>> loses its colors: >>> when you first open a context menu, and first open a submenu in it, >>> all is drawn ok. But then try hover over different menu items to >>> force >>> hiding/showing submenus, you will notice that newly opened submenus >>> start losing gradient background, until finally background becomes >>> completely white. >>> >>> 2008/11/10 Damien Cassou <damien.cassou(a)gmail.com>: >>>> >>>> >>>> http://gforge.inria.fr/frs/download.php/10931/pharo0.1-10142dev08.11.2.zip >>>> >>>> always available at: http://code.google.com/p/pharo/wiki/Downloads?tm=2 >>>> >>>> -- >>>> Damien Cassou >>>> http://damiencassou.seasidehosting.st >>>> >>>> _______________________________________________ >>>> 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 >> >> >> _______________________________________________ >> 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 >

Nov. 11, 2008

Re: [Pharo-project] New pharo-dev based on latest version

by Igor Stasenko

2008/11/11 Gary Chambers <gazzaguru2(a)btinternet.com>: > Polymorph fixed the menu gradient oddity a long time ago... :-) > btw, can it be loaded into dev image w/o problems? I'm missing the taskbar, because when you open many browsers overlapping each other, its hard to find needed one. > Regards, Gary. > > ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> > To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, November 10, 2008 6:08 PM > Subject: Re: [Pharo-project] New pharo-dev based on latest version > > >> Some of my observations of glitches found: >> >> - open world menu System->About. Now instead of clicking Ok, try drag >> the window. Leads to DNU when you release a mouse button. >> >> - a submenu gradient in OB (maybe not only in OB) is sporadically >> loses its colors: >> when you first open a context menu, and first open a submenu in it, >> all is drawn ok. But then try hover over different menu items to force >> hiding/showing submenus, you will notice that newly opened submenus >> start losing gradient background, until finally background becomes >> completely white. >> >> 2008/11/10 Damien Cassou <damien.cassou(a)gmail.com>: >>> >>> >>> http://gforge.inria.fr/frs/download.php/10931/pharo0.1-10142dev08.11.2.zip >>> >>> always available at: http://code.google.com/p/pharo/wiki/Downloads?tm=2 >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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.

Nov. 11, 2008

Re: [Pharo-project] New pharo-dev based on latest version

by Gary Chambers

Polymorph fixed the menu gradient oddity a long time ago... :-) Regards, Gary. ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Monday, November 10, 2008 6:08 PM Subject: Re: [Pharo-project] New pharo-dev based on latest version > Some of my observations of glitches found: > > - open world menu System->About. Now instead of clicking Ok, try drag > the window. Leads to DNU when you release a mouse button. > > - a submenu gradient in OB (maybe not only in OB) is sporadically > loses its colors: > when you first open a context menu, and first open a submenu in it, > all is drawn ok. But then try hover over different menu items to force > hiding/showing submenus, you will notice that newly opened submenus > start losing gradient background, until finally background becomes > completely white. > > 2008/11/10 Damien Cassou <damien.cassou(a)gmail.com>: >> http://gforge.inria.fr/frs/download.php/10931/pharo0.1-10142dev08.11.2.zip >> >> always available at: http://code.google.com/p/pharo/wiki/Downloads?tm=2 >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> _______________________________________________ >> 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

Nov. 11, 2008

Re: [Pharo-project] Re: FreeType

by Gary Chambers

Thanks. I'll do some further benchmarks once in the office. Regards, Gary. ----- Original Message ----- From: "Andrew Tween" <amtween(a)hotmail.com> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, November 09, 2008 6:21 PM Subject: [Pharo-project] Re: FreeType > Hi Gary, > > "Gary Chambers" <gazzaguru2(a)btinternet.com> wrote > in message news:859BE9D591B44E858830F5D4B74DFF26@GuruVista... >> Hi all. >> >> Using the latest FreeType (admittedly on a 3.9 image, though probably >> generally applicable) we are noticing quite a lot of cache thrash, >> meaning >> that the low-level glyph rendering is happening quite often. >> >> Really noticeable on slow machines (our deployment target has 800MHz >> processors). >> Was wondering if it might me a good idea to move the cached form >> rendering >> into a plugin (lots of bit manipulation in Squeak code loops)? > > The real killer is FreeTypeSubPixelAntiAliasedGlyphRenderer>>filter: > Moving it into a plugin would certainly speed things up. > > I've had a quick look to see what can be done to speed it up. > By hardcoding the filter parameters, and replacing floating point > arithmetic > with integer arithmetic, I have doubled its speed. (Attached as > FreeTypeSubPixelAntiAliasedGlyphRenderer-filter.st) > > >> >> We've stabilised thing for the moment by hanging onto the LogicalFonts >> used and modifying the real font lookup to reuse existing matches and >> switching to CRT mode (3 times quicker). First use of glyphs at varying >> subpixel positions miss the cache though. > > Clearly I need to do some work on this. > Much of the current design is based on assumptions which, for a Pharo > one-click distribution, are no longer valid. e.g. > > 1.The modified BitBlt plugin might not be present. > 2.The FT2Plugin might not be present. > 3.The display depth might be 16bit or 8 bit (or 4bit !? ) > 4.The current world might be MVC > > The current design is also based on plans I had for extra features (font > substitution, glyph substitution, hinting mode & kerning on a per-font > basis > rather than as global settings). > The current code is arguably over-engineered, with obvious signs of YAGNI. > I'll try to simplify it. > > As you have discovered, the sixty four possible sub-pixel positions > reduces > the chances of a cache hit and slows things down. Sixty four is the > maximum > resolution that FreeType supports. Using a lower resolution will speed > things up, and the difference in rendering quality may not be noticable. > (IIRC Sophie used a much lower resolution - 2 or 3 sub-pixel positions). > To > change the resolution, modify > FreeTypeFont>>glyphOf:destDepth:colorValue:subpixelPosition: so that this > line... > > ifTrue: [((sub asInteger max: 0) min: 63) "bitAnd: 2r1111000"] > > reads... > ifTrue: [((sub asInteger max: 0) min: 63) bitAnd: 2r1111000] > > This will reduce the 64 possible positions to 8 > (use 2r1111100 for 16 positions; 2r1111110 for 32 positions, 2r11110000 > for > 4 positions, etc.) > > n.b. Reducing the number of sub-pixel positions will speed up both the CRT > mode and the LCD mode. > > Cheers, > Andy > >> >> Regards, Gary. > -------------------------------------------------------------------------------- > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 11, 2008

Re: [Pharo-project] New pharo-dev based on latest version

by Igor Stasenko

2008/11/10 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On Nov 10, 2008, at 7:08 PM, Igor Stasenko wrote: > >> Some of my observations of glitches found: >> >> - open world menu System->About. Now instead of clicking Ok, try drag >> the window. Leads to DNU when you release a mouse button. > > thanks. > I may be the result of my etoy surgery. > I will check. > >> - a submenu gradient in OB (maybe not only in OB) is sporadically >> loses its colors: >> when you first open a context menu, and first open a submenu in it, >> all is drawn ok. But then try hover over different menu items to force >> hiding/showing submenus, you will notice that newly opened submenus >> start losing gradient background, until finally background becomes >> completely white. > > This is a feature :) > :) then you need to draw a funny paper clip flying around and telling 'see, gradient disappears.. cool, yeah?!?!' :) > Stef >> >> >> 2008/11/10 Damien Cassou <damien.cassou(a)gmail.com>: >>> >>> >>> http://gforge.inria.fr/frs/download.php/10931/pharo0.1-10142dev08.11.2.zip >>> >>> always available at: http://code.google.com/p/pharo/wiki/Downloads?tm=2 >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > 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.

Nov. 11, 2008

Re: [Pharo-project] Sunit Extensions breaking the TestRunner

by Igor Stasenko

2008/11/11 <bryce(a)kampjes.demon.co.uk>: > StÃ©phane Ducasse writes: > > > > Overrides are still something that we should avoid as much as possible. > > It's always possible to avoid overrides by having your own branch of a > package. Exupery does that for VMMaker. That works with MC 1.x's > merging, and allows it to track who's changed what to make it easier > to follow downstream changes. > It may work for VMMaker (because it is quite uncommon thing), but in broader range it will introduce even more problems. Going with your doctrine, there can be 10 developers, each forced to maintain own version of some basic package with own overrides. Now, if someone would want to use all 10 projects in single image, he will have to deal with 10 different versions of same package. The brave soul can go through all 10 versions, spend week or two merging them into common base. But i don't think he would want to repeat it over and over again, in case he wants to update one of 10 packages to new version, where some bugs fixed or new features added. > Bryce > > _______________________________________________ > 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.

Nov. 11, 2008

[Pharo-project] Re: Sake, Packages, and deployment code

by StÃ©phane Ducasse

You should show me sake. Because this is still really fuzzy for me. Stef On Nov 10, 2008, at 10:59 PM, Damien Pollet wrote: > Hi, > > I'm looking at Sake and Packages, and I'm wondering if it would make > sense to use them in a slightly different manner. > Currently, the Sake-Package classes duplicate the various existing > universes (most of them are generated from the universe descriptions), > so for end-developers it's basically the same, except there is no nice > OB-based UI for it. There is a difference though: sake package > descriptions are saved in Monticello. > > What I'm thinking is, it would be nice to have a kind of deployment > scripts for some projects, that is written and maintained by the > project authors and not an external guy. For instance, Doru wrote > PRDistribution to generate the Pier kernel in the one-click image, > which is pre-filled with a set of pages, access rights, etc. The > problem is, PRDistribution relies on all the code already being > present, and will fail if you forgot to install Pier-Blog, for > instance. > > So it would be nice if it was able to install the required packages > form Magritte, Pier, and Pier-Addons. Then it would act as a clear > entry point for users of the code, and a nice place for developers to > put stuff that currently goes into class initialization methods (like > the Licence-popping in magritte and pier, or the login/password > stuff). > > The pattern could look like this: > > - application developersâ¦ > package their application code in Foo-Subfoo packages > package their tests in Foo-Tests packages > package deployment stuff it Foo-Setup: dependancies between > individual Foo-specific packages + dependancies to high-level external > dependancies + deployment scripts like PRDistribution > (maybe) copy snapshots of Foo-Setup to a common repository > - code usersâ¦ > know that Foo-Setup will help them get a working installation of > Foo when they browse Squeaksource > install Foo-Setup package using Installer, then call one of the > sake tasks it defines (there can be several of them since they are > quite high-level) > - distribution maintainers (e.g. the other Damien)â¦ > pull carefully chosen versions of Foo-Setup into their repository, > and maybe maintain a distribution-specific -Setup package. > > What do you think? > > ps. remarks on Sake-Packagesâ¦ > IMHO the root class should be packaged separately from its subclasses, > since the former provides the code and the latter define the metadata > for particular distributions. > Also since the rules are somewhat like unit test methods, they could > be named taskFoo instead of just Foo. That would differenciate sake > rules from utility smalltalk methods. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Nov. 11, 2008

Re: [Pharo-project] Sunit Extensions breaking the TestRunner

by bryce＠kampjes.demon.co.uk

StÃ©phane Ducasse writes: > > Overrides are still something that we should avoid as much as possible. It's always possible to avoid overrides by having your own branch of a package. Exupery does that for VMMaker. That works with MC 1.x's merging, and allows it to track who's changed what to make it easier to follow downstream changes. Bryce

Nov. 10, 2008

Re: [Pharo-project] New pharo-dev based on latest version

by StÃ©phane Ducasse

Yes I fixed it in 10143 this was my mistake in etoy surgery. stef On Nov 10, 2008, at 9:20 PM, Adrian Lienhard wrote: > > On Nov 10, 2008, at 21:00 , StÃ©phane Ducasse wrote: > >> igor with upatde 10144 I cannot reproduce the first bug > > I can confirm that the problem is gone in 10144. I saw it in 142 (a > MNU of morphToDropInPasteUp:), but the message is not sent anymore > in 10144. > > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 10, 2008

Re: [Pharo-project] New pharo-dev based on latest version

by Adrian Lienhard

On Nov 10, 2008, at 21:00 , StÃ©phane Ducasse wrote: > igor with upatde 10144 I cannot reproduce the first bug I can confirm that the problem is gone in 10144. I saw it in 142 (a MNU of morphToDropInPasteUp:), but the message is not sent anymore in 10144. Adrian

Nov. 10, 2008