Smalltalk › Pharo › Pharo Smalltalk Developers

Fwd: Fwd: MouseOverHandler

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Stéphane Ducasse

Fwd: Fwd: MouseOverHandler

Yeah let us be wild.

Stef

Begin forwarded message:

> From: "Gary Chambers" <[hidden email]>
> Date: November 13, 2009 2:29:53 PM GMT+01:00
> To: Stéphane Ducasse <[hidden email]>
> 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" <[hidden email]>
> To: <[hidden email]>; <[hidden email]>
> 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: [hidden email] [mailto:pharo- [hidden email]] On Behalf Of Stéphane Ducasse
>>> Sent: Monday, November 02, 2009 3:28 PM
>>> To: [hidden email]
>>> 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: [hidden email]
>>>> 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 <[hidden email]>
>>>> 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 <[hidden email]>
>>>>>> Date: October 29, 2009 2:02:32 PM GMT+01:00
>>>>>> To: Stéphane Ducasse <[hidden email]>
>>>>>> 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
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Gary Chambers-4

Re: Fwd: Fwd: MouseOverHandler

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" <[hidden email]>
To: "Pharo Development" <[hidden email]>
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" <[hidden email]>
> Date: November 13, 2009 2:29:53 PM GMT+01:00
> To: Stéphane Ducasse <[hidden email]>
> 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"
> <[hidden email]>
> To: <[hidden email]>; <[hidden email]>
> 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: [hidden email] [mailto:pharo-
>>> [hidden email]] On Behalf Of Stéphane Ducasse
>>> Sent: Monday, November 02, 2009 3:28 PM
>>> To: [hidden email]
>>> 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: [hidden email]
>>>> 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 <[hidden email]>
>>>> 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 <[hidden email]>
>>>>>> Date: October 29, 2009 2:02:32 PM GMT+01:00
>>>>>> To: Stéphane Ducasse <[hidden email]>
>>>>>> 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
>>>>> [hidden email]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [hidden email]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project