March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Mac Carbon VM 4.0.0b1 Closure Compiler Aware with Alien support

by John M McIntosh

I've stuck this VM on my iDisk & ftp site in the EXPERIMENTAL folder found via http://smalltalkconsulting.com/squeak.html Please note the post on the Pharo list about the building and availability of the windows & unix VM with closure support. On 2-Mar-09, at 9:48 PM, John M McIntosh wrote: > Yes it compiles, yes after a bit of poking I could take a Squeak3.9- > final-7067.image and build a closure aware image. > No I could not do that without poking a bit, however I hope that > we'll resolve the problems in a day or two. > > Yes, I could take a Pharo0.1Core-10243.image and after more poking > could generate a closure aware Pharo image. > > At this time the 4.0.0b1 VM is not publicly available, another day > or two of cross checking is required, I've asked the Pharo > team to review my changes and the changes from Eliot. I've also > asked Eliot to supply some fixes so we can recompile > the Squeak3.9-final-7067 image without problems. > > I cannot speak for the 3.10 or 3.11 images, other parties will need > to pursue any work to make them closure aware. > > Tomorrow I'll poke at making the iPhone VM closure aware, however > any iPhone image relies on the Pharo team resolving > what the change sets should be to make the image closure aware. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

March 4, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by John M McIntosh

I'll suspect these both are missing the fixes for the 32bit/64bit number conversion To confirm someone can load the Alien work and run the SUnits to see if the math tests fail. Attached are the hacks to let you work with a 3.9 image if you pull the ClosureBootstrap-08-11-14.tar.gz from http://www.mirandabanda.org/files/Cog/Closures0811/Bootstrap/ To modifiy an Pharo image first I'd let someone look carefully at what's in the ClosureBootstrap change sets. As mentioned I have build a macintosh carbon vm 4.0.0b1 You can find that in the EXPERIMENTAL Folder via the FTP or idisk link on http://smalltalkconsulting.com/squeak.html On 4-Mar-09, at 12:39 PM, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > wrote: > StÃ©phane Ducasse writes: >> creating a unix vm. > > Here's a Unix VM built with an up to date VMMaker and a Windows VM: > > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-linux.tz > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-win32.zip > > Both have the closure bytecodes and the FreeType bitblit extensions. > The Linux VM includes the FreeType plugin, the Windows VM doesn't. > > Bryce > > _______________________________________________ > 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 = = = ========================================================================

March 4, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by StÃ©phane Ducasse

Thanks a lot I'm sure that linuxers and windowzers will try and report. So I imagine that we will have to do the closure integration now :) Stef On Mar 4, 2009, at 9:39 PM, <bryce(a)kampjes.demon.co.uk> <bryce(a)kampjes.demon.co.uk > wrote: > StÃ©phane Ducasse writes: >> creating a unix vm. > > Here's a Unix VM built with an up to date VMMaker and a Windows VM: > > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-linux.tz > http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-win32.zip > > Both have the closure bytecodes and the FreeType bitblit extensions. > The Linux VM includes the FreeType plugin, the Windows VM doesn't. > > Bryce > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2009

Re: [Pharo-project] [Vm-dev] newDelta >0 failed in sqUnixMemory -- Was Re: Incompatibility between Pharo and Seasidehosting

by bryce＠kampjes.demon.co.uk

StÃ©phane Ducasse writes: > creating a unix vm. Here's a Unix VM built with an up to date VMMaker and a Windows VM: http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-linux.tz http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15-win32.zip Both have the closure bytecodes and the FreeType bitblit extensions. The Linux VM includes the FreeType plugin, the Windows VM doesn't. Bryce

March 4, 2009

Re: [Pharo-project] What's the problem people? :)

by StÃ©phane Ducasse

>>> normally we will have a lecture and practice to taste wine >> Lecture made by an expert in wine :) >> And this will be normally for any ESUG attendee. >> > i more concerned meeting you and Goran, Me too > than tasting a wine. > I'm not drinking :) me neither but food will be good :) And I want to get better at tasting wine :)

March 4, 2009

Re: [Pharo-project] Mac Carbon VM 4.0.0b1 Closure Compiler Aware with Alien support

by StÃ©phane Ducasse

Indeed. john you are probably right and it can be a good way to make sure that one bold guy will build a unix VM and this way we can avoid a deadlock On Mar 4, 2009, at 8:01 PM, John M McIntosh wrote: > If the unix vm hasn't been updated with basic fixes or even critical > fixes for the last two years, why would you put it on the critical > decision path? > > The macintosh VM is available now, and I'd guess a windows VM should > be available since no-doubt qwaq has been building a windows one for > bleeding edge deployment since > all this work (and more) is being funded by qwaq. > > > On 4-Mar-09, at 9:19 AM, StÃ©phane Ducasse wrote: > >> sounds a good attitude. >> We should fix the rest of the items then. >> >> Stef >> >> On Mar 4, 2009, at 6:00 PM, Adrian Lienhard wrote: >> >>> Do the major VMs (Unix, Mac, Win) support this *now*? >>> What is the required work to include the closure changes (are they >>> published somewhere?)? >>> >>> I'd like to avoid that we get a dependency on VMs that would delay >>> version 1.0. If everything is ready, though, I would also vote for >>> including them now. >>> >>> Cheers, >>> Adrian >>> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2009

Re: [Pharo-project] UI dragging improvement

by StÃ©phane Ducasse

Hi henrik I added an issue http://code.google.com/p/pharo/issues/detail?id=629 so that we did not forget it Stef On Feb 25, 2009, at 2:36 PM, Henrik Johansen wrote: > Had a look at drawWorld:submorphs:invalidAreasOn: today, the > "Experimental top-down drawing" there does not seem to be working > optimally. > Basically, when there's many windows behind one you're resizing, > this many times leads to ALL of them getting repainted. > Attached is a fix for this, so only the system window areas which > are visible and affected are updated. > It will not speed up cases when resizing a complex morph (like the > Changes Log), but helps when resizing simple ones with many other > windows in the background. > If anyone interested in faster resizing (without fastDragWindow) > would review the code/check if it helps them it'd be nice. > A simple test is to open up a couple system browsers, put them on > top of eachother, and resize a simple window (Like the "Welcome to > Pharo" window) over their bounds. > Then load the changes, and see if you notice a difference. > In a test i did (same windows open/resized, as described above), > time spent in drawWorld:submorphs:invalidAreasOn: was reduced from > 86% to 65.7% after filing in changes. > > If anyone with a better understanding of Morphic know if anything > larger than the clippingBounds is safe to use as default in > Morph>>areasRemainingToFill: , that would probably help as well. > > Cheers, > Henry > 'From Pharo0.1 of 16 May 2008 [Latest update: #10243] on 25 February > 2009 at 2:30:25 pm'! > > !Morph methodsFor: 'drawing' stamp: 'Henrik Sperre Johansen > 2/25/2009 12:06'! > areasRemainingToFill: aRectangle > "May be overridden by any subclasses with opaque regions" > > ^ Array withAll: (aRectangle areasOutside: self clippingBounds)! ! > > > !WorldState methodsFor: 'update cycle' stamp: 'Henrik Sperre > Johansen 2/25/2009 13:52'! > drawWorld: aWorld submorphs: submorphs invalidAreasOn: aCanvas > "Redraw the damaged areas of the given canvas and clear the damage > list. Return a collection of the areas that > were redrawn." > > | rectList c i n mm morphs rects rectToFill remnants > remnantIntersects rect validList | > rectList := damageRecorder invalidRectsFullBounds: aWorld viewBox. > "sort by areas to draw largest portions first" > rectList := rectList asArray sort: [:r1 :r2 | r1 area > r2 area]. > damageRecorder reset. > n := submorphs size. > morphs := OrderedCollection new: n * 2. > rects := OrderedCollection new: n * 2. > validList := OrderedCollection new: n * 2. > rectList do: > [:dirtyRect | > dirtyRect allAreasOutsideList: validList > do: > [:r | > "Experimental top-down drawing -- > Traverses top to bottom, stopping if the entire area is filled. > If only a single rectangle remains, then continue with the > reduced rectangle." > > rectToFill := r. > remnants := OrderedCollection with: r. > i := 1. > [remnants isEmpty or: [i > n]] whileFalse: > [mm := submorphs at: i. > ((remnantIntersects := remnants select: [:each | (mm > fullBounds intersects: each)]) notEmpty and: [mm visible]) > ifTrue: > [morphs addLast: mm. > > rects addLast: (Rectangle merging: (remnantIntersects > collect: [:each | mm fullBounds intersect: each])). > remnants removeAll: remnantIntersects. > remnantIntersects do: [:eachIntersect | remnants addAll: > (mm areasRemainingToFill: eachIntersect)]. > remnants size = 1 ifTrue: [rectToFill := remnants first]. > remnants isEmpty ifTrue: [rectToFill := nil]]. > i := i + 1]. > "Now paint from bottom to top, but using the reduced rectangles." > rectToFill > ifNotNil: [aWorld drawOn: (c := aCanvas copyClipRect: > rectToFill)]. > [morphs isEmpty] whileFalse: > [(rect := rects removeLast) == rectToFill > ifFalse: [c := aCanvas copyClipRect: (rectToFill := rect)]. > c fullDrawMorph: morphs removeLast]. > morphs reset. > rects reset. > validList add: r]]. > ^validList! ! > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 4, 2009

Re: [Pharo-project] UI performance

by StÃ©phane Ducasse

sebastian you can also use another theme and let us know. Stef On Mar 4, 2009, at 6:24 PM, Sebastian Sastre wrote: > Hi there, > rigth now I've save a method and it takes like 6 seconds (maybe more > sometimes) > to return control after dropping a method in another category or > even saving. > That is really a show stopper for productivity. > What can I disable to make the pharo's ui more responsive? > thanks, > sebastian > pd: I dont feel like is a visual thing, I guess is trying to deduct > too much at > every step, maybe something related to the OB Browser? > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2009

Re: [Pharo-project] UI performance

by Sebastian Sastre

ok, I'm using 243 now. Ahhhhh... much better. Still, not sub-second yet :) thanks, sebastian > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > nombre de Sebastian Sastre > Enviado el: Wednesday, March 04, 2009 15:13 > Para: Pharo-project(a)lists.gforge.inria.fr > Asunto: Re: [Pharo-project] UI performance > > I've just noticed I was working in 0.1-10231, now I'm > downloading 243 > > > -----Mensaje original----- > > De: pharo-project-bounces(a)lists.gforge.inria.fr > > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > > nombre de Sebastian Sastre > > Enviado el: Wednesday, March 04, 2009 14:56 > > Para: Pharo-project(a)lists.gforge.inria.fr > > Asunto: Re: [Pharo-project] UI performance > > > > Thanks for the tip Damien. I've tried 4 o 5 different > > sequences of load order > > without success. > > cheers, > > sebastian > > > > > -----Mensaje original----- > > > De: pharo-project-bounces(a)lists.gforge.inria.fr > > > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > > > nombre de Damien Cassou > > > Enviado el: Wednesday, March 04, 2009 14:30 > > > Para: Pharo-project(a)lists.gforge.inria.fr > > > Asunto: Re: [Pharo-project] UI performance > > > > > > On Wed, Mar 4, 2009 at 6:24 PM, Sebastian Sastre > > > <ssastre(a)seaswork.com> wrote: > > > > What can I disable to make the pharo's ui more responsive? > > > > > > Please start by updating all OB-related packages using Monticello. > > > > > > -- > > > 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 > > > > > > _______________________________________________ > > 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

March 4, 2009

Re: [Pharo-project] Unicode test II

by Yoshiki Ohshima

At Wed, 04 Mar 2009 10:24:48 -0800, Michael Rueger wrote: > > Yoshiki Ohshima wrote: > > > So I loaded the good old FontForJapaneseEnvironment.sar and the > > latter case it does display characters properly. > > do you have that anywhere available so I can check out what code it changes? available at: http://metatoys.org/pub/FontJapaneseEnvironment.sar It is basically an equivalent of: http://map.squeak.org/package/5279e9cb-1a06-4ddb-8eca-48ca954790d3 ("Japanese Environment Installer") -- Yoshiki

March 4, 2009