November 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: Fwd: MouseOverHandler

by StÃ©phane Ducasse

Yeah let us be wild. Stef Begin forwarded message: > From: "Gary Chambers" <gazzaguru2(a)btinternet.com> > Date: November 13, 2009 2:29:53 PM GMT+01:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)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(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr>; <gazzaguru2(a)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(a)lists.gforge.inria.fr [mailto:pharo- project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse >>> Sent: Monday, November 02, 2009 3:28 PM >>> To: Pharo-project(a)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(a)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(a)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(a)gmail.com> >>>>>> Date: October 29, 2009 2:02:32 PM GMT+01:00 >>>>>> To: StÃ©phane Ducasse <stephane.ducasse(a)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(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 >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Nov. 13, 2009

Re: [Pharo-project] Status about compiler _ changes

by Schwab,Wilhelm K

Stef, I have been making a lot of use of SIF. There are some silly problems with method categories that I have learned to remember (the hard part<g>) to fix using even search and replace, but I have also done some "refactoring" using the regex package and match/replace. Assuming you have an image with offending code, an expression that matches an isolated $_ (white space on either side) migh be able to fix assignments by replacing the matches with :=. It might be useful on its own, and it brings up another proposed solution, which is to optionally treat isolated underscores as assignments, and to treat them as part of identifiers when not bracketed on both sides by whitespace (from Gemstone??). Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Friday, November 13, 2009 8:12 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Status about compiler _ changes On Nov 13, 2009, at 1:16 PM, Lukas Renggli wrote: > As far as I remember from the other mail-thread there was consensus to > allow underscores in identifiers and get rid of underscores in > assignments. What is unclear for me is how we want to proceed and when > to integrate it? > > 1. Do we just change the scanner for 1.1 without fallback? > > 2. Do we add a setting (fix the existing setting) so that the scanner > can be changed on demand? > > I prefer 1, because it is simpler and does not allow the system to be > in an inconsistent state. 2 is more convenient for people, because > they can change the setting to load old code, fix the code and change > the setting back. Potentially that leaves the system in an > inconsistent state though. 2 would be nice because as integrators we could make sure that the code is in consistent state even with pain. Now could not we have 3? 3 do 1 (ie no preference) but transform the code from _ into := automatically. It would be really great in fact Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 13, 2009

Re: [Pharo-project] Status about compiler _ changes

by StÃ©phane Ducasse

On Nov 13, 2009, at 1:16 PM, Lukas Renggli wrote: > As far as I remember from the other mail-thread there was consensus to > allow underscores in identifiers and get rid of underscores in > assignments. What is unclear for me is how we want to proceed and when > to integrate it? > > 1. Do we just change the scanner for 1.1 without fallback? > > 2. Do we add a setting (fix the existing setting) so that the scanner > can be changed on demand? > > I prefer 1, because it is simpler and does not allow the system to be > in an inconsistent state. 2 is more convenient for people, because > they can change the setting to load old code, fix the code and change > the setting back. Potentially that leaves the system in an > inconsistent state though. 2 would be nice because as integrators we could make sure that the code is in consistent state even with pain. Now could not we have 3? 3 do 1 (ie no preference) but transform the code from _ into := automatically. It would be really great in fact Stef

Nov. 13, 2009

Re: [Pharo-project] Status about compiler _ changes

by Damien Cassou

On Fri, Nov 13, 2009 at 1:16 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > I prefer 1, because it is simpler and does not allow the system to be > in an inconsistent state. 2 is more convenient for people, because > they can change the setting to load old code, fix the code and change > the setting back. Potentially that leaves the system in an > inconsistent state though. I vote 1. However, if we could provide a simple script that runs on version 1.0 and that fixes the code or at least point to _ uses, that would be cool. -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Nov. 13, 2009

[Pharo-project] Status about compiler _ changes

by Lukas Renggli

As far as I remember from the other mail-thread there was consensus to allow underscores in identifiers and get rid of underscores in assignments. What is unclear for me is how we want to proceed and when to integrate it? 1. Do we just change the scanner for 1.1 without fallback? 2. Do we add a setting (fix the existing setting) so that the scanner can be changed on demand? I prefer 1, because it is simpler and does not allow the system to be in an inconsistent state. 2 is more convenient for people, because they can change the setting to load old code, fix the code and change the setting back. Potentially that leaves the system in an inconsistent state though. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 13, 2009

[Pharo-project] status about hash changes

by StÃ©phane Ducasse

Hi andres and martin what is the status of the changes you proposed ? Because it would be nice to integrate them. Stef

Nov. 13, 2009

Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by Marcus Denker

On Nov 13, 2009, at 10:05 AM, Peter Hugosson-Miller wrote: > Results for VisualAge (just FYI): > > | count | > count := 0. > [1 to: 10000000 do: [:i | count :=count + 1]] timeToRun. "151702" > > | count | > count := 0. > [10000000 timesRepeat: [count := count + 1]] timeToRun. "139971" > > (results are in microseconds) > > So maybe there's a case for inlining #timesRepeat: (or making a clear comment that it is much slower in Pharo) > In general inlining is evil ;-) timesRepeat for the special case of being send to an int, detected statically... maybe I could be convinced of that. But in general, what would be much nicer would be to do it based on type-feedback information nicely hidden so nobody sees it. Marcus

Nov. 13, 2009

Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by Lukas Renggli

> How does it compare to Pharo? ifTrue: ifFalse: ifTrue:ifFalse: ifFalse:ifTrue: and: or: whileFalse: whileTrue: whileFalse whileTrue to:do: to:by:do: caseOf: caseOf:otherwise: ifNil: ifNotNil: ifNil:ifNotNil: ifNotNil:ifNil: See MessageNode for details. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 13, 2009

[Pharo-project] Issue 1437 : Bitmap #decompress:fromByteArray:at: not wellformed

by arnaud Jean Baptiste

I paste the issue open : the primitive method #decompress:fromByteArray:at: aren't well-formed, cause the code of this method is using by VMMaker to generate source code of the primitive, then it can happen which a selector using in the method was never implemented. Then if the code is fix VMMaker may not be able to generate a clean source code. the main point of this issue is the selector call: #primitiveFail, he doesn't exist in the Pharo environment and seem be change by #primitiveFailed which exist, and then the mistake can't be see if we don't try to generate to use VMMaker without using MiscPrimitivesPlugin. I post a fix in the Inbox. i have simply correct #primitiveFailed to #primitiveFail If you have a better solution i will be glad to discuss with you. link : http://code.google.com/p/pharo/issues/detail?id=1437

Nov. 13, 2009

Re: [Pharo-project] x4 difference between #to:do: and #timesRepeat - bug ?

by Peter Hugosson-Miller

+1 for making an inlined version of #timesRepeat: Sometimes speed matters, and for someone coming from an environment where it's faster than #to:do: it might not be so easy to detect where the unexpected time penalty came from. Unfortunately, I'm not sufficiently familiar with the Compiler/Decompiler to volunteer to do it myself :-p And to answer CÃ©drick's question, browsing senders of a method should tell you if it's inlined of not. In VA there are no senders of #timesRepeat: or #to:do, although both are used extensively. In case anyone is interested, here is the complete list of inlined methods in VA #== #~~ #and: #ifFalse: #ifFalse:ifTrue: #ifTrue: #ifTrue:ifFalse: #isNil #not #notNil #or: #timesRepeat: #to:do: #whileFalse: #whileTrue: How does it compare to Pharo? -- Cheers, Peter 2009/11/13 CÃ©drick BÃ©ler <cdrick65(a)gmail.com> > Thanks all. > > Interesting. I saw by using tallySends that: > > timesRepeat: > This simulation took 6.0 seconds. > **Tree** > 1 SmallInteger(Integer)>>timesRepeat: > > **Leaves** > 100001 UndefinedObject>>DoIt > 1 SmallInteger(Integer)>>timesRepeat: > 1 UndefinedObject>>DoIt > > > to:do: > This simulation took 3.0 seconds. > **Tree** > > **Leaves** > 1 UndefinedObject>>DoIt > > > I guess this is one consequence of being inlined. > > > This makes ask another questions: > > -how to know what's inlined, what method have suche properties (a comment > would be cool, so if we had to choose...) ? > -how to add Compiler inlining rules (as it's easy ;) ) ? > -why not inlining timesRepeat: (as I guess we don't really change it often) > ? > > > Thanks. > > ps: the result is slow because I used a 5 year old (at least) computer :). > I think I got a 10x difference in a 2 year one... > > > 2009/11/13 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > >> There is also a difference between: >> >> >> [self atEnd ifTrue: [^nil]. >> self next. >> true] whileTrue. >> >> and: >> >> [self atEnd ifTrue: [^nil] >> self next] repeat. >> >> Warning: it's quite easy to add Compiler inlining rules, a bit tougher >> to add corresponding Decompiler tricks. >> >> 2009/11/13 Marcus Denker <denker(a)acm.org>: >> > >> > On Nov 13, 2009, at 9:51 AM, CÃ©drick BÃ©ler wrote: >> > >> >> Hi, >> >> >> >> I noticed quite a difference between the two method who "looks" the >> same to me. Is it normal ? >> >> >> > >> > Normal. to:do: is lnlined (compiled as jumps in the bytecode), whereas >> timesRepeat: is a message >> > send with a closure activation. >> > >> > Marcus >> > >> > fun is the difference between: >> > >> > (1 to : 10000) do: >> > and >> > 1 to: 10000 do: >> > >> > one is compiled to jumps, the other not and in addition creates a temp >> collection. >> > >> > Marcus >> > >> > >> > >> >> I use a rc image (haven't tested in squeak). And it's the same on >> windows and linux. >> >> >> >> count := 0. >> >> [1 to: 10000000 do: [:i | count :=count + 1]] timeToRun." 677" >> >> count := 0. >> >> [10000000 timesRepeat: [count := count + 1]] timeToRun" 2571" >> >> >> >> If not normal, I'll open a issue. >> >> >> >> Thanks >> >> >> >> -- >> >> CÃ©drick >> >> _______________________________________________ >> >> 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 >> > > > > -- > CÃ©drick > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Cheers, Peter

Nov. 13, 2009