- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by StÃ©phane Ducasse

>> Just because someone magically pretends to have come up with the same >> idea (and some others "coincidentally") without giving you credit >> for it >> does not mean that your work is suddenly obsolete. Please keep up the >> good work for Pharo!!! >> > thank for your support Michael. > but if I remember well, the idea is from Lukas, and Gary help me also. :) Stef ]

March 4, 2009

Re: [Pharo-project] Fwd: [squeak-dev] [ANN] Preference pragmas

by StÃ©phane Ducasse

So let us know when we integrate it :) Stef > StÃ©phane Ducasse a Ã©crit : >> I reread all the emails you exchanged with gary and igor. >> What is a parentNode in AbtsractPreferenceValue? >> This is when you have a composite preference? > yes >> I understood when reading the code of PrefProvider2 >> >>> no problem but tell me >>> that I stop working on this. >>> >>> The set of system preferences constitutes a tree of preferences. >>> The model for the tree is implemented by the PreferenceNode >>> hierarchy. >>> (see PrefCore2). This is the only mandatory part. >>> The tree can be visualized with a PreferenceTree UI built on top of >>> PrefCore2 (see PrefTool2 and snapshot). >>> Examples of preference declaration are given in PrefProvider2. >>> in order to open the tree: >>> PreferenceTree open >> >> I have two naive questions: >> - I imagine that we will be able to reuse the Preference browser >> and that we do not have to rebuild one? >> because the pragma preference collector could be put there? Or is >> it better to rewrite everything? > I guess we can reuse some parts. >> >> - second I was wondering why you only use <preference> and not >> <preference:zork:> like in andreas solution? >> Gary mentioned that some objects can be more complex than mere >> literal. > and he convinced me not to use <preference:zork:> for two main > reasons > -Only one model for preference in the image (no need to retrieve the > pragma or to store them in a second model) > -<preference:zork:> is flat, it allow on literals as parameters, so it > is very difficult to describe composites >> >> I was wondering if for the interface it would not be better to have >> cascaded selector instead of >> methods with multiple argument. >> >> PreferenceNode name: 'HTTP proxy' description: 'http proxy name >> and port' parent: #networkPreferenceNode >> vs >> PreferenceNode new >> name: 'HTTP proxy' ; >> description: 'http proxy name and port' ; >> parent: #networkPreferenceNode > ok for me. >> >> So can I summarize your approach as follow? >> >> - packages can defined locally their preferences (by construction >> this will be better >> since people will have to think about preferences value as their >> stuff. not the one of preference >> so this will help the flow to be local --- good. >> - preferences are not centralized anymore (youpi) >> - tools can register to get notified when preferences changes >> - preferences can be complex objects >> - preferences are structured in preferences tree. > exactly >> >> Sounds cool to me. I will let the other give their point of view. >> I'm leaving on vacation now. >> >> Stef >> >> PS: test should be >> >> >> "self test" >> PrefChangeListener new inspect. >> UIPreferences gradientButtonLook value: UIPreferences >> gradientButtonLook value not. >> UIPreferences gradientButtonLook value: UIPreferences >> gradientButtonLook value not. >> UIPreferences gradientButtonLook value: UIPreferences >> gradientButtonLook value not. > yes, this is the version you have in PrefListener.5.mcz > > alain >> >> >> >> > > > _______________________________________________ > 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] Fwd: [squeak-dev] [ANN] Preference pragmas

by StÃ©phane Ducasse

+200 I think that Pharo is becoming cool and aggregating good energy and some people are afraid of it to succeed because of its good energy. And indeed such coincidence look suspicious to me. I only see great and cool stuff happening: no mvc, no etoy, lot of fixes,... and more soon Stef On Mar 4, 2009, at 8:24 PM, Michael Rueger wrote: > Alain Plantec wrote: >> Hi all, >> Here is a Preference engine based on pragma. >> please, check it and tell me if it is ok or not. >> If you prefer squeak version, no problem but tell me >> that I stop working on this. > > Well, I guess that is exactly what we don't want (that you stop > working > on it). > > Just because someone magically pretends to have come up with the same > idea (and some others "coincidentally") without giving you credit > for it > does not mean that your work is suddenly obsolete. Please keep up the > good work for Pharo!!! > > Michael > > _______________________________________________ > 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