For a fun test, with both packages loaded: |m| m := Morph new extent: 200@150. m clipSubmorphs: true. m openInWindow. [[World syncDo: [ (Delay forMilliseconds: 20) wait. m removeAllMorphs. 10 timesRepeat: [ m addMorphBack: (Morph new color: (Color wheel: 200) atRandom; position: m position + (m width atRandom @ m height atRandom))]]. Sensor controlKeyPressed] whileFalse] forkAt: Processor lowIOPriority Or, unprotected: |m| m := Morph new extent: 200@150. m clipSubmorphs: true. m openInWindow. [[(Delay forMilliseconds: 20) wait. m removeAllMorphs. 10 timesRepeat: [ m addMorphBack: (Morph new color: (Color wheel: 200) atRandom; position: m position + (m width atRandom @ m height atRandom))]. Sensor controlKeyPressed] whileFalse] forkAt: Processor lowIOPriority See how many times you can execute either (repeat your doit)! Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: "Pharo Development" <Pharo-project@lists.gforge.inria.fr> Sent: Friday, November 13, 2009 1:35 PM Subject: [Pharo-project] Fwd: Fwd: MouseOverHandler Yeah let us be wild. Stef Begin forwarded message:
From: "Gary Chambers" <gazzaguru2@btinternet.com> Date: November 13, 2009 2:29:53 PM GMT+01:00 To: Stéphane Ducasse <stephane.ducasse@inria.fr> Subject: Re: [Pharo-project] Fwd: MouseOverHandler
If you want to play then load Synchronization-gvc.1.mcz from the Polymorph squeaksource repo. Optionaly, load Morphic-Synchronization-gvc.1.mcz for protecting the morphic event loop with a synchronisation monitor.
Any questions, just ask... Have fun.
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr>; <gazzaguru2@btinternet.com> Sent: Tuesday, November 03, 2009 3:40 PM Subject: Re: [Pharo-project] Fwd: MouseOverHandler
excellent! we are in alpha so we can be wild :)
Stef
On Nov 2, 2009, at 10:36 PM, Gary Chambers wrote:
No arguments on weak stuff... VisualAge did a good job of those things (perhaps the garbage collector was better integrated with the concept).
The driving force for our synchronisation stuff was the need to provide timely feedback, in terms of screen redraws, driven from separate processes that, for instance, were monitoring keystrokes from non-standard keypad devices, network messages etc. Was a necessity and proven in the field! I can get things together as a package later in the week. Very small footprint for a generalised per-object/sub-object scheme.
On Mon, 2009-11-02 at 16:24 -0500, Schwab,Wilhelm K wrote:
Stef, Gary,
Having recently ranted a little about thread safety for weak collection, how can I argue? Well, let me see if I can do so and keep my credibility intact :)
Squeak's weak collections, and we have not moved beyond their limitations, do not clean themselves after their elements are finalized. That means they do half of what they should do; once they do all of it, they need to be thread safe; hence they do one third of what they should do.
The GUI is arguably a little different. #addDeferredUIMessage: provides a clean way to interact with it from background threads, and that might be enough. IDE specific messages (e.g. #inspect) could probably stand to be queued to make them safe w/o horrible penalties, with the remainder of the GUI understood not to be thread safe for performance reasons. A backround thread can do expensive calculations and then queue a GUI update to safely update the display.
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo- project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Monday, November 02, 2009 3:28 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Fwd: MouseOverHandler
Hi gary do you think that it make sense to have it in general (my gut feeling is saying yes but I'm not thread-safe)
If yes, yes we are interested for 1.1
BTW hernan I integrated your changes now it would be interesting to understand from where this nil is coming.
Stef On Nov 2, 2009, at 8:58 PM, Gary Chambers wrote:
Yet the cause is unexplained. I still think it is due to non-ui processes fiddling with morphs (likely delettion or creation). The Morphic event loop remains non-thread safe. We have some modifications to ensure thread safety, based on a generalised synchronisation protocol if anyone is interested.
Regards, Gary ----- Original Message ----- From: Hernan Wilkinson To: Pharo-project@lists.gforge.inria.fr Sent: Monday, November 02, 2009 7:45 PM Subject: Re: [Pharo-project] Fwd: MouseOverHandler
Hi Adrian, the current implementation has problems, ie. send messages to nil, and it bothers a lot when that happens because it comes from nowhere... I've been using this implementation for a long time in my images and I did not get those problems anymore (and it is more readable...)
On Sat, Oct 31, 2009 at 2:41 PM, Adrian Lienhard <adi@netstyle.ch> wrote: Hi Hernan,
The reason this was not integrated is that nobody marked it as 'fixed' nor tagged it as 1.0.
Is this critical for 1.0?
Cheers, Adrian
BTW, if anybody sees changes/fixes not being integrated please ask on the mailing list.
On Oct 31, 2009, at 14:29 , Stéphane Ducasse wrote:
Begin forwarded message:
From: Hernan Wilkinson <hernan.wilkinson@gmail.com> Date: October 29, 2009 2:02:32 PM GMT+01:00 To: Stéphane Ducasse <stephane.ducasse@inria.fr> Subject: MouseOverHandler
Hi Stef, do you know why the MouseOverHandler version I made is not in the main image? the current version is not working well, under heavy use it generates exceptions... I'm attaching the version I wrote that I'm using without
problem...
Hernan.
<MouseOverHandler.st>
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project