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

Re: [Pharo-project] Issue 832 feedback

by Henrik Johansen

The only thing which has been reported: "Having tried it both ways, the rollback is "a must." There is probably an argument that the updated image dos a little better with it than does my 10303 image, but both benefit when the rollback is applied. Bill" I see no way to reproduce the slowdown (which I don't experience) from that information. Care to share some more on exactly what version you are running when noticing/not noticing slowdowns + process that eliminated slowdown for you? Gary, got any feedback? There has been no feedback (that I've noticed) about my experience that simply saving the image would eliminate the slowdown experienced after a System... -> Software Update. Cheers, Henry StÃ©phane Ducasse skrev: > 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 >> > > > _______________________________________________ > 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 Henrik Johansen

I did some testing. During a minute of dragging/resizing windows (Class Browser, with 7-8 other windows in the background), the extra intersect happened approximately 6000 times. A small intersect speed test: a := Rectangle origin: 1@1 corner: 10@100. b := Rectangle origin: 3@0 corner: 5 @ 50. [1000000 timesRepeat:[ a intersect: b]] durationToRun 0:00:00:00.992 So, about 6 ms overhead added over the course of a minute... Unless somehow there are Morphs which ends up redrawing MORE with a consistently SMALLER damage rect, I think it'd be wise to look elsewhere for any slowdowns experienced... Cheers, Henry StÃ©phane Ducasse skrev: > 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 >> > > > _______________________________________________ > 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 StÃ©phane Ducasse

on mac 0:00:00:00.409 On Jun 12, 2009, at 11:43 AM, Gary Chambers wrote: > Depends if the preference for "higher performance" is enabled too... > > For comparison (Windows VM, updated 10304cl image): > > "higher performance" off: 0:00:00:06.6087 > "higher performance" on: 0:00:00:00.524 > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, June 12, 2009 7:12 AM > Subject: [Pharo-project] Animation bench > > > 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 > > > _______________________________________________ > 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] Fwd: [vwnc] Smalltalk forum in French

by StÃ©phane Ducasse

Begin forwarded message: > From: Florent Arrignon <florent_arrignon(a)hotmail.fr> > Date: June 12, 2009 11:29:18 AM CEDT > To: <vwnc(a)cs.uiuc.edu> > Subject: [vwnc] Smalltalk forum in French > > Hi list, > > I just wanted to inform the french speaking VisualWorks users that I > have created a free website about Smalltalk in french at this url: > > http://www.smalltalkinfrench.org > > The site is very new so there is not much content until now but > there is already a forum available (http://www.smalltalkinfrench.org/forum > ). I have space to host Smalltalk resources in french if needed. > > The aims are simply to provide a place to point all resources about > Smalltalk (mailing lists, wiki, websites, blogs) and also to > experiment a single forum where french Smalltalkers could ask and > answer questions about Smalltalk and its different implementations > (whether open source or not), from beginners to experts, just to see > if it helps to strenghten the french Smalltalk community. > > So for the french speaking VisualWorks users, I hope you'll visit us > and for the non native french speaking users, sorry for the spam but > I can still send you this message: it is allways time to learn > French and then visit us ;-) > > Have a good day all, > > Florent Arrignon > > > > > > > > Vous voulez savoir ce que vous pouvez faire avec le nouveau Windows > Live ? Lancez-vous !_______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

June 12, 2009

Re: [Pharo-project] Animation bench

by Gary Chambers

Depends if the preference for "higher performance" is enabled too... For comparison (Windows VM, updated 10304cl image): "higher performance" off: 0:00:00:06.6087 "higher performance" on: 0:00:00:00.524 Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, June 12, 2009 7:12 AM Subject: [Pharo-project] Animation bench 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] multiple native windows

by Igor Stasenko

2009/6/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > So publish something and aks for people to join so that for pharo 1.1 > we get it :) > i will publish it, when i'll have an integration/VM platform code refactoring done. Currently new plugin can just create/manipulate host windows and having an API to access different window properties from image side, declared by plugin (different platforms/OS window managers can provide different sets of properties). > Stef > >> >> >>> >>>> Would it be ok if this was configurable via a user preference, >>>> meaning pharo supported both? >>> >>> sure. >>> >>>> A VisualWorks multiple-native-window capability would open up the >>>> possibility of creating a different class of applications. Â Alot of >>>> my work revolves around integration with legacy systems. Â Having a >>>> smalltalk with multiple native windows would allow me to more >>>> seamlessly introduce it into the world of tools at my company. >>> >>> I really think that if somebody would work on ffenestria we would >>> integrate it. >>> >> >> Do you remember, i started it. Still i don't released anything. But >> the idea is to move all windowing code into a new plugin , which will >> have an inherent support of controlling native windows (& events) from >> image side. >> >> >>>> >>>> >>>> thanks >>>> sw >>>> >>>> On Thu, Jun 11, 2009 at 11:33 AM, Alexandre Bergel <alexandre(a)bergel.eu >>>>> wrote: >>>> >>>> I used Visualworks and Squeak, and frankly, I prefer to have >>>> embedded >>>> morphic windows in a unique native window, as it is now in Pharo. >>>> Application switching is easier in my opinion and I do not feel a >>>> need >>>> to have an email clients between two code browsers. >>>> As the discussion on save and quit testified, people have radically >>>> different habits when programming. Even for simple things. >>>> Interesting. >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On 11 Jun 2009, at 10:58, Steve Wirts wrote: >>>> >>>>> 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 >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel Â http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

June 12, 2009

Re: [Pharo-project] multiple native windows

by StÃ©phane Ducasse

So publish something and aks for people to join so that for pharo 1.1 we get it :) Stef > > >> >>> Would it be ok if this was configurable via a user preference, >>> meaning pharo supported both? >> >> sure. >> >>> A VisualWorks multiple-native-window capability would open up the >>> possibility of creating a different class of applications. Alot of >>> my work revolves around integration with legacy systems. Having a >>> smalltalk with multiple native windows would allow me to more >>> seamlessly introduce it into the world of tools at my company. >> >> I really think that if somebody would work on ffenestria we would >> integrate it. >> > > Do you remember, i started it. Still i don't released anything. But > the idea is to move all windowing code into a new plugin , which will > have an inherent support of controlling native windows (& events) from > image side. > > >>> >>> >>> thanks >>> sw >>> >>> On Thu, Jun 11, 2009 at 11:33 AM, Alexandre Bergel <alexandre(a)bergel.eu >>>> wrote: >>> >>> I used Visualworks and Squeak, and frankly, I prefer to have >>> embedded >>> morphic windows in a unique native window, as it is now in Pharo. >>> Application switching is easier in my opinion and I do not feel a >>> need >>> to have an email clients between two code browsers. >>> As the discussion on save and quit testified, people have radically >>> different habits when programming. Even for simple things. >>> Interesting. >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 11 Jun 2009, at 10:58, Steve Wirts wrote: >>> >>>> 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 >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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: First try of Pharo

by Torsten Bergmann

Hi Andres, (CC-ing the list) yes, some points: - the newest Pharo is AFAIK currently slow due to a bug introduced in one of the latest updates, Stephane tries to roll back (see http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/009729.html) - I think it would be better to package VM+sources+changes+image in one file per platform for the main download page in the future or provide a "one click" experience. There is already a one click install for Seaside based on pharo (see new on www.seaside.st) - so could be a "one click pharo" - the windows installer is releatively new and therefore not yet on the download page (we will change that) There is now a newer, see: http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/009656.html Thanks for the feedback and tell us how the win32 Setup goes as soon as you are ready. Bye Torsten -------- Original-Nachricht -------- > Datum: Wed, 10 Jun 2009 16:32:07 -0300 > Von: andres <...> > An: Torsten Bergmann <...> > Betreff: Re: Fwd: First try of Pharo > Hi Torsten, thanks for the quick response! I think that, since I didn't > have much time to write, I couldn't explain myself in the previous mail. > So, here is my second try :). I really like the goals of Pharo and I > wish that it becomes a professional St open source solution. I have > historically worked with VW and could never get used to Squeak, yet I > would love to work with something like pharo in the future. So, the aim > of my mail was more to portrait the experience of someone saying "I've > been hearing about Pharo, let's give it a try". > So I went into the page, download section and got the pharo 09.06.01 > image (with seaside and pier) and the corresponding vm for my platform. > My feeling is that if I just wanted to get a taste of Pharo I would just > say that I got an error message and that the environment was very slow > and I think this is really a pity. Of course I'm not working too hard > here and I know the project hasn't reach the 1.0 version, but in some > cases (and this is more a personal appreciation) you got only one shot > to attract people to your product and if this was the only shot for > pharo I would have dismissed it. > As you said, the first issue is extremely simple to solve and it is > really frustrating that the first thing you see when trying a new piece > of software is an error message. After you mentioned it in the mail, I > realized that the sources where in the page, however the first time I > saw the page I associated them with the /VM/ sources files, since it is > an open source project and the title of the section is "Source file" > (which I misread as "Source Files", hence the confusion). Regarding the > one-click image I think it is a great idea and I think it would be great > to include that in the download page of the project together with the > other files. That would make the newcommers life easier. > I'm on my linux box now, so as soon as I'm on the other machine and get > some air I'll try the one-click image and tell you how it went. > > HTH, > AndrÃ©s > > Torsten Bergmann escribiÃ³: > > Andres wrote: > >> Starting the image would give the error attached in the > >> screenshot. I tried moving the image to be in the same folder as the > >> VM with no luck. > > > > The *.source file is missing. Download the file from [1] and > > extract it where the VM is located. > > > > You can also use the prepackaged Installer for Windows (containing > > anything you need, so pharo shows up in the start menu) - see [2] > > to download the setup.exe > > > > > > Use this and tell us how it goes. > > Take care: your files with the *.image extension are still associated > > with the other VM that you installed. > > > > Bye > > Torsten > > > > BTW: If you are afraid of the traffic on the mailinglist just subscribe > > but set option to not get emails. Then you can browse the archive > > to read but still post questions. See [3] > > > > > > [1] http://pharo-project.org/download > > [2] > https://gforge.inria.fr/frs/download.php/22410/setup_pharo_0.0.0.3.exe > > [3] > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-June/009617.html -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

June 12, 2009

Re: [Pharo-project] multiple native windows

by Igor Stasenko

2009/6/11 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > >> Would it be ok if this was configurable via a user preference, >> meaning pharo supported both? > > sure. > >> A VisualWorks multiple-native-window capability would open up the >> possibility of creating a different class of applications. Â Alot of >> my work revolves around integration with legacy systems. Â Having a >> smalltalk with multiple native windows would allow me to more >> seamlessly introduce it into the world of tools at my company. > > I really think that if somebody would work on ffenestria we would > integrate it. > Do you remember, i started it. Still i don't released anything. But the idea is to move all windowing code into a new plugin , which will have an inherent support of controlling native windows (& events) from image side. >> >> >> thanks >> sw >> >> On Thu, Jun 11, 2009 at 11:33 AM, Alexandre Bergel <alexandre(a)bergel.eu >> > wrote: >> >> I used Visualworks and Squeak, and frankly, I prefer to have embedded >> morphic windows in a unique native window, as it is now in Pharo. >> Application switching is easier in my opinion and I do not feel a need >> to have an email clients between two code browsers. >> As the discussion on save and quit testified, people have radically >> different habits when programming. Even for simple things. >> Interesting. >> >> Cheers, >> Alexandre >> >> >> On 11 Jun 2009, at 10:58, Steve Wirts wrote: >> >> > 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 >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel Â http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

June 12, 2009

Re: [Pharo-project] call for tester for

by Damien Cassou

On Thu, Jun 11, 2009 at 9:50 PM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: > would be nice if some of u could test: > > http://code.google.com/p/pharo/issues/detail?id=860&colspec=ID%20Type%20Sta… I've commented on the issue -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 12, 2009