- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Animation bench

by Adrian Lienhard

> What is this "higher performance" preference? It makes me remember > old pcs > with the yellow button "Turbo" > > Why this is not true by default? Because it makes your image slow. For details please see the archive of this list. We've recently discussed this setting and concluded that it should be removed. Cheers, Adrian

June 12, 2009

Re: [Pharo-project] Animation bench

by Mariano Martinez Peck

In windows and "higher performance" disable: 0:00:00:07.7335 0:00:00:07.7292 0:00:00:07.7229 0:00:00:07.7408 In windows and "higher performance" enable: 0:00:00:04.4469 0:00:00:04.4255 0:00:00:04.4153 0:00:00:04.4373 What is this "higher performance" preference? It makes me remember old pcs with the yellow button "Turbo" Why this is not true by default? cheers, Mariano 2009/6/12 Luc Fabresse <luc.fabresse(a)gmail.com> > 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 >> > > > _______________________________________________ > 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 Henrik Johansen

Besides, durationToRun has a bug when durationTime is bigger than 1s, calling Duration milliSeconds: durationTime . (Or Duration milliSeconds: has a bug, depending on your point of view) Ex: (In Squeak) Duration milliSeconds: 7666 prints as: 0:00:00:00.7666 (In Pharo) Duration milliSeconds: 7666 prints as: 0:00:00:07.7666 In both cases, A Duration with 0 seconds, and 7666000000 nanoseconds is created. Cheers, Henry StÃ©phane Ducasse skrev: > 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 >> >> > > > _______________________________________________ > 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] Missing primitive

by Mariano Martinez Peck

This seems to be already reported but fixed in exupery-vm-0.15.1-linux.tz :( Here's a VM that should have the IP6 primitives in it: http://ftp.squeak.org/Exupery/vms/exupery-vm-0.15.1-linux.tz That's the vm that you are using? which version of Pharo? See this thread: http://n2.nabble.com/Undefined-symbol-using-Exupery-VM-td2581456.html#a2581… Cheers, Mariano On Fri, Jun 12, 2009 at 5:42 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > 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 > > > _______________________________________________ > 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 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