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

Re: [Pharo-project] Animation bench

by StÃ©phane Ducasse

I tried in 10304 (since the fix 832 was introduced in 312). update10312 "self new update10312" self withUpdateLog:'- 819 argumentCount - stef fixing his methods (tests) - Issue 820: Re-implement Boolean>>#==> that was removed because it was not license clean - Issue 821: Preference to settings refactoring: #confirmFirstUseOfStyle case- Issue 657: About dialog is too big http://code.google.com/p/pharo/issues/detail?id=657 - Issue 832: morphs do not respect the damagerect http://code.google.com/p/pharo/issues/detail?id=832 But the results are the same 0:00:00:06.6055 quite bad :( > Hi guys > > could you run the following: > >>> [ >>> (m := Morph new) openInWorld. >>> 1 to: 300 do: [:i | >>> m position: m position + (1@1). >>> World doOneCycle] >>> ] >>> durationToRun > > because frederic.ferrere(a)free.fr did it and here are the result > > * vm : pharo-vm-0.15.1b-linux > * image : pharo0.1-10332dev09.06.2 > - Test 1 : Project est vide, juste le workspace ouvert Ã l'opposÃ© du > trajet > RÃ©sultat 0:00:00:07.704 > - Test 2 : ClassBrowser recouvrant tout le 'World' > RÃ©sultat : 0:00:00:00.689 > > - Test 1 > * vm : squeak3.9.8-3ubuntu3 > * image : Squeak-dev 3.10.2 > - Test 1 : Project est vide, juste le workspace ouvert Ã l'opposÃ© du > trajet > RÃ©sultat : 0:00:00:02.098 > - Test 2 : ClassBrowser recouvrant tout le 'World' > RÃ©sultat : 0:00:00:00.608 > Donc contrairement Ã ce qu'il semblait Ãªtre logique, > le morph avance plus vite si le "World" n'est pas vide. > > StÃ©phane Rollandin a Ã©crit : >> >> [ >> (m := Morph new) openInWorld. >> 1 to: 300 do: [:i | >> m position: m position + (1@1). >> World doOneCycle] >> ] >> durationToRun >> >> retourne 0:00:00:00.373 dans mon image, soit un gros tiers de >> seconde. on est loin des 6 s > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 12, 2009

Re: [Pharo-project] Animation bench

by Luc Fabresse

My results : VM Mac (john) : 4.1.1b2U Image : pharo0.1-10324dev Just with the workspace windows : 0:00:00:06.6051 With an OBPackageBrowser taking fullscreen : 0:00:00:06.6048 VM Mac (john) : 4.1.1b2U Image : pharo0.1-core10331cl Just with the workspace windows : 0:00:00:06.6047 With an OBPackageBrowser taking fullscreen : 0:00:00:06.6056 Luc Le 12 juin 2009 08:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : > Hi guys > > could you run the following: > > >> [ > >> (m := Morph new) openInWorld. > >> 1 to: 300 do: [:i | > >> m position: m position + (1@1). > >> World doOneCycle] > >> ] > >> durationToRun > > because frederic.ferrere(a)free.fr did it and here are the result > > * vm : pharo-vm-0.15.1b-linux > * image : pharo0.1-10332dev09.06.2 > - Test 1 : Project est vide, juste le workspace ouvert Ã l'opposÃ© du > trajet > RÃ©sultat 0:00:00:07.704 > - Test 2 : ClassBrowser recouvrant tout le 'World' > RÃ©sultat : 0:00:00:00.689 > > - Test 1 > * vm : squeak3.9.8-3ubuntu3 > * image : Squeak-dev 3.10.2 > - Test 1 : Project est vide, juste le workspace ouvert Ã l'opposÃ© du > trajet > RÃ©sultat : 0:00:00:02.098 > - Test 2 : ClassBrowser recouvrant tout le 'World' > RÃ©sultat : 0:00:00:00.608 > Donc contrairement Ã ce qu'il semblait Ãªtre logique, > le morph avance plus vite si le "World" n'est pas vide. > > StÃ©phane Rollandin a Ã©crit : > > > > [ > > (m := Morph new) openInWorld. > > 1 to: 300 do: [:i | > > m position: m position + (1@1). > > World doOneCycle] > > ] > > durationToRun > > > > retourne 0:00:00:00.373 dans mon image, soit un gros tiers de > > seconde. on est loin des 6 s > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 12, 2009

[Pharo-project] Missing primitive

by Norbert Hartl

Hi, I fixed issue 864 a few minutes ago. But that showed another problem. SocketAddress>>hostNumber is using a primitve primitiveResolverHostNameSize that is not there. At least not on my machine. I use expury-0.15.1 vm. Can anybody check if this is a problem or only on my site? I created an issue 882 for it Norbert

June 12, 2009

Re: [Pharo-project] Fixes for Numbers are ready (toward ANSI)

by StÃ©phane Ducasse

yes something like that. I think that the community should be more active reviewing fixes :) > >> Nicolas Cellier a Ã©crit : >>> 2009/6/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>>> thanks nicolas >>>> BTW did you got feedback about this one? >>>> http://code.google.com/p/pharo/issues/detail?id=860&colspec=ID%20Type%20Sta… >>>> >>> >>> None yet. I only see 3 explanations: >>> - everyone is busy, dead, in hollidays, in the garden, etc... >>> - everyone disabled the preference for generating the error log >>> - I'm the only one doing bugs, no one else ever seen a slow Notifier >>> >> :) >> Hi Nicolas, >> sorry for the stupid question but what are you asking testers to do ? >> I've loaded the 4 .cs, verified that the preference is on and >> evaluated 0/0. >> seen a notifier, click on proceed and get a SqueakDebug.log. >> and then what ? >> thanks >> Alain >> > > The speed should increase, that's what the patch is all for. > I don't know what test Stef wants exactly, I see two possibilities: > -1) review the changes > -2) install the changes and do normal activity, report if any trouble > > Nicolas > >> _______________________________________________ >> 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 >

June 12, 2009

Re: [Pharo-project] Issue 832

by StÃ©phane Ducasse

What is the status of that rollback? Because if pahro get slower we should roll back Stef On May 28, 2009, at 11:46 AM, Henrik Johansen wrote: > Sure. > I'd wait applying it till others can confirm that simply saving after > running an update does not fix their performance problems though, as > outlined in my last mail. > > Cheers, > Henry > > StÃ©phane Ducasse skrev: >> can you send me the st for the reverting? >> >> Stef >> >> On May 28, 2009, at 10:08 AM, Henrik Johansen wrote: >> >> >>> It's strange though, for me dragging is just as slow reverting the >>> changes I made in a 319 image... >>> And filing in the .st in a 309 image, I notice no slow downs. (309 >>> upgraded to 319 I do). >>> >>> Are we sure nothing else causes this, perhaps changes related to >>> events/polling frequency or something? >>> >>> Cheers, >>> Henry >>> >>> Schwab,Wilhelm K skrev: >>> >>>> Henry, >>>> >>>> I for one appreciate your effort, and encourage you to keep going. >>>> Speaking of slow machines, I have a small herd and would be willing >>>> to >>>> help you profile the problem. Give me about a month, and I will be >>>> in >>>> a position to press them into service to help with this. >>>> >>>> Bill >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* pharo-project-bounces(a)lists.gforge.inria.fr >>>> [mailto:pharo-project-bounces@lists.gforge.inria.fr] *On Behalf Of >>>> *Henrik Sperre Johansen >>>> *Sent:* Wednesday, May 27, 2009 5:07 PM >>>> *To:* Pharo-project(a)lists.gforge.inria.fr >>>> *Subject:* Re: [Pharo-project] Issue 832 >>>> >>>> Sorry, just back from the pub (YAY BARCELONA!) my initial reaction >>>> was really: >>>> I'd rather see the cause of such slowdowns while resizing >>>> investigated >>>> (and fixed), but considering the time needed to accomplish that, >>>> rollbacking is probably a safer option at this time. >>>> My mind absolutely boggles that a resizing performance decrease >>>> would >>>> be the most visible effect of the changes made in that update... >>>> Welcome to the wonderful world of Morphic! >>>> >>>> Cheers, >>>> Henry >>>> >>>> On 27.05.2009 23:54, Henrik Sperre Johansen wrote: >>>> >>>>> Yes, rollbacking probably is the safest choice, >>>>> As I implied in the mail, this was really meant as a experimental >>>>> effort, to see if people on slower machines noticed the effects I >>>>> was >>>>> (pre)anticipating. >>>>> I really don't see how an extra intersect: per Morph (containing >>>>> submorphs) can make such a big difference... >>>>> >>>>> I'll definately post another update sometime in the future, I >>>>> don't >>>>> know when I'll have to look into it though. >>>>> <rant> >>>>> To me, the way it is right now seems unacceptable, there's >>>>> really no >>>>> reason to write a "smart" drawOn: routine for morphs that are >>>>> likely >>>>> to end up as a subMorph (saaaay, the TextMorph which I started >>>>> investigating in the first place), as they have to redraw the >>>>> entire >>>>> area anyways. >>>>> This leads to a bad cycle in morph development; >>>>> "As long as at minimum the area we want to redraw is marked as, >>>>> it's >>>>> fine. There's no performance gain from reporting a more accurate >>>>> area >>>>> anyways". >>>>> So you end up with "sloppy" damage rects for new morphs, which >>>>> leads >>>>> to more to fix if it IS changed, and slower performance for those >>>>> whom redrawing the entire area rather than a subsection IS >>>>> expensive. >>>>> </rant> >>>>> >>>>> Cheers, >>>>> Henry >>>>> >>>>> >>>>> On 27.05.2009 19:44, StÃ©phane Ducasse wrote: >>>>> >>>>>> Thanks for reporting. >>>>>> Henrik? >>>>>> I could rollback the changes. >>>>>> >>>>>> Stef >>>>>> >>>>>> On May 27, 2009, at 6:25 PM, Gary Chambers wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Performance of UI seems poor after 832 integration. >>>>>>> >>>>>>> http://code.google.com/p/pharo/issues/detail?id=832 >>>>>>> >>>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> 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 >> >> >> > 'From Pharo0.1 of 16 May 2008 [Latest update: #10309] on 28 May 2009 > at 11:39:22 am'! > > !Morph methodsFor: 'drawing' stamp: 'dgd 2/22/2003 14:31'! > drawSubmorphsOn: aCanvas > "Display submorphs back to front" > > | drawBlock | > submorphs isEmpty ifTrue: [^self]. > drawBlock := [:canvas | submorphs reverseDo: [:m | canvas > fullDrawMorph: m]]. > self clipSubmorphs > ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] > ifFalse: [drawBlock value: aCanvas]! ! > > > !LazyMorphListMorph methodsFor: 'as yet unclassified' stamp: 'gvc > 5/3/2006 14:27'! > drawSubmorphsOn: aCanvas > "Display submorphs back to front" > > |drawBlock i| > submorphs isEmpty ifTrue: [^self]. > drawBlock := [:canvas | > (self topVisibleRowForCanvas: aCanvas) to: (self > bottomVisibleRowForCanvas: aCanvas) do: [ :row | > i := self item: row. > canvas fullDrawMorph: i]]. > self clipSubmorphs > ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] > ifFalse: [drawBlock value: aCanvas]! ! > > > !PasteUpMorph methodsFor: 'painting' stamp: 'nk 7/4/2003 15:59'! > drawSubmorphsOn: aCanvas > "Display submorphs back to front, but skip my background sketch." > > | drawBlock | > submorphs isEmpty ifTrue: [^self]. > drawBlock := [:canvas | submorphs reverseDo: [:m | m ~~ > backgroundMorph ifTrue: [ canvas fullDrawMorph: m ]]]. > self clipSubmorphs > ifTrue: [aCanvas clipBy: self clippingBounds during: drawBlock] > ifFalse: [drawBlock value: aCanvas]! ! > > > !TabSelectorMorph methodsFor: 'as yet unclassified' stamp: 'gvc > 5/31/2007 14:11'! > drawSubmorphsOn: aCanvas > "Display submorphs back to front. > Draw the focus here since we are using inset bounds > for the focus rectangle." > > super drawSubmorphsOn: aCanvas. > self hasKeyboardFocus ifTrue: [ > self selectedTab ifNotNilDo: [:t | > self clipSubmorphs > ifTrue: [aCanvas > clipBy: self clippingBounds > during: [:c | t drawKeyboardFocusOn: c]] > ifFalse: [t drawKeyboardFocusOn: aCanvas]]]! ! > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 12, 2009

[Pharo-project] Animation bench

by StÃ©phane Ducasse

Hi guys could you run the following: >> [ >> (m := Morph new) openInWorld. >> 1 to: 300 do: [:i | >> m position: m position + (1@1). >> World doOneCycle] >> ] >> durationToRun because frederic.ferrere(a)free.fr did it and here are the result * vm : pharo-vm-0.15.1b-linux * image : pharo0.1-10332dev09.06.2 - Test 1 : Project est vide, juste le workspace ouvert Ã l'opposÃ© du trajet RÃ©sultat 0:00:00:07.704 - Test 2 : ClassBrowser recouvrant tout le 'World' RÃ©sultat : 0:00:00:00.689 - Test 1 * vm : squeak3.9.8-3ubuntu3 * image : Squeak-dev 3.10.2 - Test 1 : Project est vide, juste le workspace ouvert Ã l'opposÃ© du trajet RÃ©sultat : 0:00:00:02.098 - Test 2 : ClassBrowser recouvrant tout le 'World' RÃ©sultat : 0:00:00:00.608 Donc contrairement Ã ce qu'il semblait Ãªtre logique, le morph avance plus vite si le "World" n'est pas vide. StÃ©phane Rollandin a Ã©crit : > > [ > (m := Morph new) openInWorld. > 1 to: 300 do: [:i | > m position: m position + (1@1). > World doOneCycle] > ] > durationToRun > > retourne 0:00:00:00.373 dans mon image, soit un gros tiers de > seconde. on est loin des 6 s

June 12, 2009

Re: [Pharo-project] Fixes for Numbers are ready (toward ANSI)

by Nicolas Cellier

2009/6/11 Alain Plantec <alain.plantec(a)free.fr>: > Nicolas Cellier a Ã©crit : >> 2009/6/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>> thanks nicolas >>> BTW did you got feedback about this one? >>> http://code.google.com/p/pharo/issues/detail?id=860&colspec=ID%20Type%20Sta… >>> >> >> None yet. I only see 3 explanations: >> - everyone is busy, dead, in hollidays, in the garden, etc... >> - everyone disabled the preference for generating the error log >> - I'm the only one doing bugs, no one else ever seen a slow Notifier >> > :) > Hi Nicolas, > sorry for the stupid question but what are you asking testers to do ? > I've loaded the 4 .cs, verified that the preference is on and evaluated 0/0. > seen a notifier, click on proceed and get a SqueakDebug.log. > and then what ? > thanks > Alain > The speed should increase, that's what the patch is all for. I don't know what test Stef wants exactly, I see two possibilities: -1) review the changes -2) install the changes and do normal activity, report if any trouble Nicolas > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 12, 2009

Re: [Pharo-project] Fwd: to go beta?

by Serge Stinckwich

On Fri, Jun 12, 2009 at 3:19 AM, Adrian Lienhard<adi(a)netstyle.ch> wrote: > That's a good question I was also thinking about today... > > I suggest the following steps: > > 1. Review all issues in the tracker and decide for each whether it is > important for 1.0. > 2. We concentrate on completing these 1.0-tagged items. New issues > should only be tagged with 1.0 if they are critical bugs (i.e., no new > improvements get integrated anymore!) > 3. As soon as we have completed all items that change the behavior of > the system (i.e., that are not bugfixes) we declare beta > 4. As soon as all items are done, we declare gamma and after a while > without newly reported problems we release 1.0 What could be great is a release during next ESUG conference in september. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

June 12, 2009

Re: [Pharo-project] a plea for "save and quit"

by Hernan Wilkinson

I like this one too.I don't like "Save" ..> "Save", "Save as".. etc, to much cliks (or moves) just to save On Thu, Jun 11, 2009 at 9:17 AM, Alain Plantec <alain.plantec(a)free.fr>wrote: > Tudor Girba a Ã©crit : > > "Save" > > "Save as..." > > "Save and quit" > > ----- > > "Quit > Hi all, > I like this simple proposition. > We still have 'recover lost changes' in the case of unwanted quit > without saving. > alain > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 12, 2009

Re: [Pharo-project] multiple native windows

by Carlos Crosetti

I tried wxsqueak. Demos ar really good, and populating a grid with miliions of rows is very fast, however you have to turn your mind to build so defensively... I crashed the wm 3 to 4 times in around 4 hours - effort,m then I gave up. -----Mensaje original----- De: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Mariano Martinez Peck Enviado el: Jueves, 11 de Junio de 2009 12:25 p.m. Para: Pharo-project(a)lists.gforge.inria.fr Asunto: Re: [Pharo-project] multiple native windows Perhaps you can join forces with the rest of the present alternatives. For example, squeakgtk I think there is a lot of people that wants native windows so that being able to create desktop applications. Cheers, Mariano 2009/6/11 Steve Wirts <stevewirts(a)gmail.com> If the primitives existed in pharo that would allow someone to create and control native windows, I would be more than happy to take the time to try and massage morphic into working cleanly/elegantly with multiple windows. On Thu, Jun 11, 2009 at 10:44 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: On Thu, Jun 11, 2009 at 4:38 PM, Michael Rueger<m.rueger(a)acm.org> wrote: > Also the GTK bindings and Newspeak use native windows (I > think?). Newspeak uses either native or morphic windows, depending on the wishes of the user. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry _______________________________________________ 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

June 12, 2009