- Pharo-dev - lists.pharo.org

[Pharo-project] About Pharo - text to go with version 1.0

by Matthias Berth

Hello, I am thinking that some "getting started" info is a good idea for Pharo 1.0. As a first part, I have tried to compile various statements "about pharo" and what I read on the mailing list into a short text (see below). Does that capture what people doing the work are thinking about the project? Anything I should add? Anything you don't like? Cheers Matthias =About Pharo= The goal of the Pharo Project is to produce a clean and lean open-source Smalltalk for professional software development: * great tools, e.g. OmniBrowser with refactoring support * polished user interface with TrueType fonts and Polymorph widgets * clean and lean image * works out-of-the-box, with clear ways to add functionality Starting from version 1.0, Pharo wants to be stable to make sure that we can produce ideas based on it. An important test for Pharo is that mission critical Seaside (http://www.seaside.st) applications should run on it. Pharo started from Squeak (http://www.squeak.org) [which version, 3.10?] but it is a fork: Do not expect Etoy/Nebraska to work in Pharo. We will try to avoid to reinvent the wheel but will change if changing is better. Pharo wants to take a fresh look at the Smalltalk philosophy and current implementations. Ideally by 2011 we would like to have a small kernel and some cool packages that we can load on top. The current focus is not to produce such a kernel but good packages. Everybody is welcome to contribute. You can find a wiki, bug tracker, and a mailing list via the Pharo home page at http://www.pharoproject.org ==License== [A few words about the code that is already there in Pharo, please] Any code developed and committed to the SqueakSource/Pharo and PharoInbox repository is by default under the MIT License.

Nov. 5, 2008

Re: [Pharo-project] ArrayedCollection, Boolean SmallInteger>>ccg: cg generateCoerceToOopFrom: aNode on: aStream

by Alexandre Bergel

We may have to make sure that vmmaker works in pharo then... Alexandre On 5 Nov 2008, at 17:22, StÃ©phane Ducasse wrote: > I have the impression that we could remove these methods from the > images. > It seems that this is related to the VM generation? > Does someone know more about them? > Stef > > ccg: cg generateCoerceToOopFrom: aNode on: aStream > > self instSize > 0 ifTrue: > [self error: 'cannot auto-coerce arrays with named instance > variables']. > cg generateCoerceToObjectFromPtr: aNode on: aStream > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 5, 2008

Re: [Pharo-project] ArrayedCollection, Boolean SmallInteger>>ccg: cg generateCoerceToOopFrom: aNode on: aStream

by John M McIntosh

In my VMMaker images the only caller is the class SmartSyntaxPluginCodeGenerator which is part of the VMMaker package. On Nov 5, 2008, at 12:22 PM, StÃ©phane Ducasse wrote: > I have the impression that we could remove these methods from the > images. > It seems that this is related to the VM generation? > Does someone know more about them? > Stef > > ccg: cg generateCoerceToOopFrom: aNode on: aStream > > self instSize > 0 ifTrue: > [self error: 'cannot auto-coerce arrays with named instance > variables']. > cg generateCoerceToObjectFromPtr: aNode on: aStream > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 5, 2008

[Pharo-project] ArrayedCollection, Boolean SmallInteger>>ccg: cg generateCoerceToOopFrom: aNode on: aStream

by StÃ©phane Ducasse

I have the impression that we could remove these methods from the images. It seems that this is related to the VM generation? Does someone know more about them? Stef ccg: cg generateCoerceToOopFrom: aNode on: aStream self instSize > 0 ifTrue: [self error: 'cannot auto-coerce arrays with named instance variables']. cg generateCoerceToObjectFromPtr: aNode on: aStream

Nov. 5, 2008

Re: [Pharo-project] some minor tuning

by StÃ©phane Ducasse

Yes scanning all the memory at startup is not really exciting. I will add an entry to the issue list Thanks john. Stef > > I see we still do the forgetAllGrabCommandsFrom: dance across all > objects in the image at startup time, > not sure if this issue was ever resolved.

Nov. 5, 2008

Re: [Pharo-project] FreeType

by Gary Chambers

It would be a start, though, as I indicated, the major problem is the large computational expense of rendering the cached glyphs. Regards, Gary. ----- Original message ----- _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 5, 2008

Re: [Pharo-project] FreeType

by David Pennell

Changing the cache management policy and enhancing the mapping of logical to real fonts seem like relatively low hanging fruit or am I missing something? -david On Wed, Nov 5, 2008 at 11:19 AM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: [snip] > Currently, if the cache size limit (bytes of all glyph forms in the cache) > is hit the cache resets totally and subsequent requests will regenerate the > needed glyphs. > > Upping the FreeType glyph cache limit helps though the fact that two > different instances of a LogicalFont (with the same parameters) will create > a new real FreeTypeFont, the cache tends to churn. >

Nov. 5, 2008

Re: [Pharo-project] FreeType

by Gary Chambers

Having said all that, FreeType is a must. The font quality is awesome. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, November 05, 2008 4:57 PM Subject: Re: [Pharo-project] FreeType >I do not know anything about fonts > can you explain the cache mechanism for the font rendering? > briefly? > > Stef > > On Nov 5, 2008, at 4:20 PM, Gary Chambers wrote: > >> 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)? >> >> 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. >> >> Regards, Gary. >> >> _______________________________________________ >> 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

Nov. 5, 2008

Re: [Pharo-project] FreeType

by Gary Chambers

Looking at the latest FreeType, glyphs are cached (as forms) for each real font looked up by a LogicalFont. Two different instances of LogicalFont that happen to match actually has a second instance of real font. Aside from that, the glyph cache contains entries (for a real font instance) for any used character/sub-pixel-position/colour combination. The creation of the cached glyph forms is quite computationally expensive (as written in Squeak). So, from a logical font, asking for its real font will (lazily) (at present) load a new instance of FreeTypeFont, asking for a glyph (character) at a particular sub-pixel position and colour will look up in the cache and, if not present, create the form for it. Given kerning etc, up to 64 sub-pixel positions may be involved for each glyph. Currently, if the cache size limit (bytes of all glyph forms in the cache) is hit the cache resets totally and subsequent requests will regenerate the needed glyphs. Upping the FreeType glyph cache limit helps though the fact that two different instances of a LogicalFont (with the same parameters) will create a new real FreeTypeFont, the cache tends to churn. Given the multiple potential subpixel positions it is impractical to pre-cache all the glyphs for a font, hence there is a perfomance hit on first use of a glyph at a particular sub-pixel/colour point. Moving the low-level glyph rendering loops into a plugin will help the performance immensely. Sorry, there is no "briefly" :-) Regards, Gary. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, November 05, 2008 4:57 PM Subject: Re: [Pharo-project] FreeType >I do not know anything about fonts > can you explain the cache mechanism for the font rendering? > briefly? > > Stef > > On Nov 5, 2008, at 4:20 PM, Gary Chambers wrote: > >> 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)? >> >> 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. >> >> Regards, Gary. >> >> _______________________________________________ >> 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

Nov. 5, 2008

Re: [Pharo-project] FreeType

by StÃ©phane Ducasse

I do not know anything about fonts can you explain the cache mechanism for the font rendering? briefly? Stef On Nov 5, 2008, at 4:20 PM, Gary Chambers wrote: > 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)? > > 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. > > 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. 5, 2008