Yeah let us be wild.

Stef

Begin forwarded message:

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


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

Reply via email to