- Pharo-dev - lists.pharo.org

Re: [Pharo-project] HostWindows rewrite

by David T. Lewis

On Sun, Nov 09, 2008 at 05:05:45PM +0200, Igor Stasenko wrote: > 2008/11/9 David T. Lewis <lewis(a)mail.msen.com>: > Oh, that's the bits i'm missing. I found the sources of > HostWindowPlugin for win and mac, but > was unable to find anything for X11. Can you please send me a sources > of it, or link for downloads? There is no implementation for X11, but I posted a copy of my imcomplete work to the vm-dev list here: http://lists.squeakfoundation.org/pipermail/vm-dev/2008-July/001977.html This does have enough support to permit opening windows, moving them, setting window label, etc but it is incomplete and is not integrated into Squeak in any useful way. > And of course, i don't see a need in packing X and Y into a single 32 > bit int as its currently done in HostWindowPlugin. Good, that sounds fine. Dave

Nov. 9, 2008

[Pharo-project] Issue 324: nullable closure: #valueSupplyingAnswers crashes on #matchesRegex:

by Damien Cassou

http://code.google.com/p/pharo/issues/detail?id=324 The following expression crashes: [UIManager default confirm: 'blah blah'] valueSupplyingAnswers: {{'*username' . true}}. -- Damien Cassou http://damiencassou.seasidehosting.st

Nov. 9, 2008

[Pharo-project] Re: Squeak Carbon OS-X VM 3.8.19beta1U ships

by John M McIntosh

> > In the past we have read the image file into a pre-allocated chunk > of memory allocated via mmap, now I have changed to a more > complicated but faster method of reading which then allows us to > someday depending on your VM to avoid re-swizzling pointers for an > image that is launched on a unix, windows, or iPhone since all oops > should start on the 500MB boundary. > > What happens is we mmap the image file with copy on write mmap into > a segment of memory starting at a real address of 500MB > (500*1024*1024), the next virtual memory page follow the size of the > file then is anonymously mmap upto the maximum memory size choosen > for the implmentation. In this case we allocate 512MB of memory > which is a settable option in the info.plist. I had a chance to evaluate the impact of this on an older powerbook G3, what I found is the traditional way of doing things required just about 550 ms of time as it reads in the image and iterates over the objects. After the change and saving the image so that you've a 500MB start location, that 550ms of time is reduced to about 125ms. On slower devices like the iphone the improvement is measured in seconds. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Nov. 9, 2008

[Pharo-project] Re: FreeType

by Andrew Tween

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.

Nov. 9, 2008

[Pharo-project] [ANN] Sourcetalk

by Lukas Renggli

Hello everyone We am happy to announce the first release of my bachelor project which is called Sourcetalk. Most of you know already Squeaksource (www.squeaksource.com) which works with Monticello. Meanwhile Colin Putney released first versions of Monticello 2, which aims to not only support Squeak/Pharo but all Smalltalk dialects. My bachelor work contains the making of a web application, with Smalltalk, Seaside, Magritte and Pier, as an interface to a Monticello 2 repository, similar to Squeaksource. Feel free to give it a look and to try it out at <http://scg.unibe.ch/sourcetalk>. Should you encounter bugs, please report them to me (andreaquadri(a)students.unibe.ch) Keep in mind that this is an early version and only ment for experimentation. Do not store your important projects on the server (yet). We'll setup a real server that is properly persistent and backed up at its own domain at a later point this year. To give it a try from your image you need to load Monticello 2 into a recent Pharo/Squeak image: http://www.wiresong.ca/static/releases/Monticello-2.0.29.zip Then load in the attached file-out. It contains a new repository type and some patches to Monticello 2 to make it work with Sourcetalk. Greetings Andrea Quadri Lukas Renggli -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 9, 2008

Re: [Pharo-project] About etoy cleaning

by Gary Chambers

I'm sure I missed a lot. As you say, the tendrils go deep! Regards, Gary. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, November 08, 2008 9:04 PM Subject: [Pharo-project] About etoy cleaning > Hi guys > > I just wanted to let you know that I'm working on etoy cleaning from > Object, Morph and friends. > And I will probably do some mistakes (because this is complex). I'm > trying to do that concentrated > but still this is serious beast. > > Now I'm keeping a list of my progress at this page > http://code.google.com/p/pharo/w/edit/CurrentlyWorkingOn > so that you can follow my progression and that I'm not lost either. > > I'm using gary etoy removal and going over his list and checking senders > of senders .... and verifying when I have doubts. > and I'm finding missed points from time to time and this is normal when > we see the complexity of etoy and morphic together. > So gary may be at the end I would appreciate that you have a look at the > stuff I'm removing. > May be by doing a "changes" comparison. > Right now I'm cleaning object and I will keep a list of the difficult > methods I did not fixed yet. > May be these ones will be easier to treat when etoy will be removed. > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 9, 2008

Re: [Pharo-project] Repaint does not work

by StÃ©phane Ducasse

I was thinking. I would not removed all the painting tools and other for now. When we will get done with etoys this will remove a **lot** of code and then we can repackage a lot of nice little applications like the drawing tool and others. On Nov 9, 2008, at 5:40 PM, StÃ©phane Ducasse wrote: > I see > > PaintBoxMorph classPool at: #ColorChart put: nil. > PaintBoxMorph classPool at: #Prototype put: nil. > > > On Nov 9, 2008, at 3:29 PM, Adrian Lienhard wrote: > >> Yes, I removed this morph as it used a lot of memory. I thought it >> was only used from within EToys but I didn't realize it was >> accessible from elsewhere. Now, the question is whether we still >> want to have the drawing tool in Pharo? > > I imagine that we could let it and repackage it later. > Pharo should still be fun and powerful. I think that having examples > for morphs is also important. > Now what we could do it to have a better lazy initialization of this > variables :) > May be having the resources as class methods. > > Stef > > >> >> >> To see my cleanup check out #cleanUpForRelease. >> >> Adrian >> >> On Nov 9, 2008, at 15:15 , StÃ©phane Ducasse wrote: >> >>> It worked in 10112 >>> but does not in 10116 >>> >>> On Nov 9, 2008, at 3:03 PM, StÃ©phane Ducasse wrote: >>> >>>> Hi adrian >>>> >>>> do you remember if you did something with the SketchEditorMorph >>>> when you optimise memory, >>>> because now I cannot repaint a form, I get a plainCursor error >>>> since the palette is nil. >>>> >>>> To reproduce >>>> bring halos on the pharo logo >>>> click on repaint >>>> you get one DNU because Prototype classVariable is nil and not a >>>> PaintBoxMorph >>>> then if you bring again the halos and move the mouse over the >>>> area we get >>>> a plainCursor DNU. >>>> >>>> I was not working on this area so I imagine that it may be your >>>> cleans. >>>> >>>> was working 10107 >>>> >>>> but not in 10133 >>>> >>>> >>>> Sytef >>>> >>>> _______________________________________________ >>>> 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 >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 9, 2008

Re: [Pharo-project] About etoy cleaning

by StÃ©phane Ducasse

>> > > Right, i dealt with Morphic code a bit, when implemented a GLCanvas > thingy, and know how awfull it can be :) > I think, that inherent basic structure of implementation, like > SystemDictionary and its globals and lack of modular design at first > place, makes developers tend to write highly wired-up code, which is > then hard to decompose. I have some plans to fix that but I do not want to discuss that now. :) Stef

Nov. 9, 2008

Re: [Pharo-project] Repaint does not work

by StÃ©phane Ducasse

I see PaintBoxMorph classPool at: #ColorChart put: nil. PaintBoxMorph classPool at: #Prototype put: nil. On Nov 9, 2008, at 3:29 PM, Adrian Lienhard wrote: > Yes, I removed this morph as it used a lot of memory. I thought it > was only used from within EToys but I didn't realize it was > accessible from elsewhere. Now, the question is whether we still > want to have the drawing tool in Pharo? I imagine that we could let it and repackage it later. Pharo should still be fun and powerful. I think that having examples for morphs is also important. Now what we could do it to have a better lazy initialization of this variables :) May be having the resources as class methods. Stef > > > To see my cleanup check out #cleanUpForRelease. > > Adrian > > On Nov 9, 2008, at 15:15 , StÃ©phane Ducasse wrote: > >> It worked in 10112 >> but does not in 10116 >> >> On Nov 9, 2008, at 3:03 PM, StÃ©phane Ducasse wrote: >> >>> Hi adrian >>> >>> do you remember if you did something with the SketchEditorMorph >>> when you optimise memory, >>> because now I cannot repaint a form, I get a plainCursor error >>> since the palette is nil. >>> >>> To reproduce >>> bring halos on the pharo logo >>> click on repaint >>> you get one DNU because Prototype classVariable is nil and not a >>> PaintBoxMorph >>> then if you bring again the halos and move the mouse over the >>> area we get >>> a plainCursor DNU. >>> >>> I was not working on this area so I imagine that it may be your >>> cleans. >>> >>> was working 10107 >>> >>> but not in 10133 >>> >>> >>> Sytef >>> >>> _______________________________________________ >>> 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 >

Nov. 9, 2008

Re: [Pharo-project] About etoy cleaning

by Igor Stasenko

2008/11/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I'm appreciate your efforts. Keep going! >> >> Just one question. >> You seem planning to remove Project from system, as part of Etoys. >> I'm not really sure about it. A removal of Projects will lead to >> model, which having only a single World (a PasteUpMorph instance), >> what i fear of, because i want to make a plugin which supports >> multiple windows, and therefore each window can have own PasteUpMorph >> instance. > > I do not know. now each time I look at Project and its impact everywhere. > May be it would be better to reimplement a clean multiple world abstraction. > For now I'm removing player and etoy support from Project when I see them. > >> And it seems like its least painful way to get multiple windows support. >> >> Of course, it would require rethinking the role of Display & World >> globals, because there will be more than a single window and this will >> require to do something with code, which assuming that there is always >> a Display/World where everyone can put his dirty hands on :) >> For instance, i have no idea, what to do with commonly used (and quite >> convenient, in fact) message , like #openInWorld. >> When you have multiple worlds, its a big question, where new morph >> should appear. >> >> Maybe, as solution, a World/Display globals can stay, but they will >> track the currently active window. In this way, all new morphs will >> appear in currently active window. The problem is, that its not really >> necessary for window to be associated with PasteUpMorph - it can be a >> window which only having a Form for drawing and nothing more, or >> window which may use different UI framework and therefore >> creating/keeping an instance of PasteUpMorph for it is not an option. > > Probably but I do not really know. > Now I'm trying not to break Morphic while removing etoys. > I think that once this is done we will have to think about it. > May be rebuilding another solution on the side and switching is the best > when I see the current state of the code. > Not a really optimistic answer but I'm getting burned by etoy Right, i dealt with Morphic code a bit, when implemented a GLCanvas thingy, and know how awfull it can be :) I think, that inherent basic structure of implementation, like SystemDictionary and its globals and lack of modular design at first place, makes developers tend to write highly wired-up code, which is then hard to decompose. To my sense, lack of modularity is the main drawback of smalltalk-80 implementation. And the main reason, why smalltalk is not the #1 language in the world. > > > _______________________________________________ > 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. 9, 2008