- Pharo-dev - lists.pharo.org

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

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