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

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

by Lukas Renggli

> I'm thinking aloud, so bear with me! Â I think that an "a_1." would be sintatically incorrect except if you can find a variable elsewhere a_1, right? The problem is that during the lexical analysis variable information is not yet available. Parsing a_1 different depending on the context would be extremely dangerous (the exact same code could mean two entirely different things depending on where you type it) and in many case not be possible (the refactoring engine needs to be able to parse code without knowing the context). Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 13, 2009

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

by csrabak＠bol.com.br

Em 13/11/2009 13:36, Lukas Renggli < renggli(a)gmail.com > escreveu: >> It should be possible to forbid _ assignment in interactive mode, but >> still authorize in batch mode (loading an external package for >> example) to make sure those assignments disappear... > Yes, but you still wouldn't know if a_1 is an old assignment or a new > variable access. Or am I missing something? Lukas, I'm thinking aloud, so bear with me! I think that an "a_1." would be sintatically incorrect except if you can find a variable elsewhere a_1, right? My 0.0199999... -- Cesar Rabak

Nov. 13, 2009

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

by Marcus Denker

On Nov 13, 2009, at 7:24 PM, Nicolas Cellier wrote: > The former is very easy, ugly and cheap. yes. Ugly. And even wrong. I remember when I tried to explain a die-hard compiler researcher how the "optimizations" of #ifTrue: and friends work in Smalltalk... > The later neither is easy nor cheap, and i doubt many of us will > concentrate on this. > Unless "concentrate" means "wait for Eliot's changes and pray". :-) I did once do some work on Eliot's AOStA. I plan to work on resurrecting that, soon. Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Nov. 13, 2009

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

by Nicolas Cellier

2009/11/13 Martin McClure <martin(a)hand2mouse.com>: > Igor Stasenko wrote: >> No, please no more inilining hacks. :) >> If someone wants to run everything at light speed - just code in C, >> but leave smalltalk honoring the >> message passing. >> And besides, these tricks won't make any difference when having good >> inlining JIT. >> In bytecode, they just add a complexity to compiler and headache to developers. > > +64 to banning bytecode compiler hacks and instead concentrate on > producing an inlining JIT. > > -Martin > The former is very easy, ugly and cheap. The later neither is easy nor cheap, and i doubt many of us will concentrate on this. Unless "concentrate" means "wait for Eliot's changes and pray". This can be reformulated as "don't bother on such details untill then". ;) Nicolas > > _______________________________________________ > 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

[Pharo-project] Project removal continued

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=1438 Another batch ready Stef

Nov. 13, 2009

[Pharo-project] Profile It - Use of TimeProfiler instead + general information displayed by default

by CÃ©drick BÃ©ler

Hi, I made these small changes so that "profile it" open a TimeProfiler. I also added a documentation method that is displayed when no method are selected. This doc need review. It's a summary of the chapter on profiling to explain the spy results. Last remark, there is still a bug when selecting for instance the line **Tree** (see below). I think that was happening too before but right now I can't check (need to leave, I'll open a ticket later if needed). hope it helps... -- CÃ©drick VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: #10074] Image: Pharo1.0rc1 [Latest update: #10492] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /home/cedrick/Bureau/Poker/prjPoker-02nov Trusted Dir /home/cedrick/Bureau/Poker/prjPoker-02nov/secure Untrusted Dir /home/cedrick/Bureau/Poker/prjPoker-02nov/My Squeak TimeProfileBrowser(Object)>>doesNotUnderstand: #allInstVarNames Receiver: a TimeProfileBrowser Arguments and temporary variables: aMessage: allInstVarNames exception: MessageNotUnderstood: TimeProfileBrowser>>allInstVarNames resumeValue: nil Receiver's instance variables: dependents: a DependentsArray(a SystemWindow(3666) a PluggableListMorph(1080) a...etc... contents: nil currentCompiledMethod: nil contentsSymbol: #source systemOrganizer: ('AST-Core-Matching') ('AST-Core-Nodes') ('AST-Core-Parser') (...etc... classOrganizer: nil metaClassOrganizer: nil systemCategoryListIndex: 0 classListIndex: 0 messageCategoryListIndex: 0 messageListIndex: 2 editSelection: #editMessage metaClassIndicated: false messageList: an OrderedCollection(' - 14 tallies, 37 msec.' '' '**Tree**' '----...etc... autoSelectString: nil growable: nil selectedClass: Integer selectedSelector: #factorial block: MessageSend(#runBlock:pollingEvery: -> a TimeProfileBrowser) tally: a MessageTally SHParserST80>>initializeInstanceVariables Receiver: a SHParserST80 Arguments and temporary variables: Receiver's instance variables: classOrMetaClass: a TimeProfileBrowser source: '"Choose a method to see its implementation ****General information...etc... workspace: nil arguments: a Dictionary() sourcePosition: 700 currentToken: nil currentTokenFirst: Character space temporaries: a Dictionary() instanceVariables: a Set() errorBlock: nil currentTokenSourcePosition: nil blockDepth: 0 bracketDepth: 0 ranges: an OrderedCollection(a SHRange) environment: Smalltalk SHParserST80>>parse: Receiver: a SHParserST80 Arguments and temporary variables: isAMethod: true Receiver's instance variables: classOrMetaClass: a TimeProfileBrowser source: '"Choose a method to see its implementation ****General information...etc... workspace: nil arguments: a Dictionary() sourcePosition: 700 currentToken: nil currentTokenFirst: Character space temporaries: a Dictionary() instanceVariables: a Set() errorBlock: nil currentTokenSourcePosition: nil blockDepth: 0 bracketDepth: 0 ranges: an OrderedCollection(a SHRange) environment: Smalltalk SHParserST80>>parse Receiver: a SHParserST80 Arguments and temporary variables: Receiver's instance variables: classOrMetaClass: a TimeProfileBrowser source: '"Choose a method to see its implementation ****General information...etc... workspace: nil arguments: a Dictionary() sourcePosition: 700 currentToken: nil currentTokenFirst: Character space temporaries: a Dictionary() instanceVariables: a Set() errorBlock: nil currentTokenSourcePosition: nil blockDepth: 0 bracketDepth: 0 ranges: an OrderedCollection(a SHRange) environment: Smalltalk SHParserST80>>rangesIn:classOrMetaClass:workspace:environment: Receiver: a SHParserST80 Arguments and temporary variables: sourceString: '"Choose a method to see its implementation ****General infor...etc... aBehaviour: a TimeProfileBrowser aWorkspace: nil anEnvironmentOrNil: nil Receiver's instance variables: classOrMetaClass: a TimeProfileBrowser source: '"Choose a method to see its implementation ****General information...etc... workspace: nil arguments: a Dictionary() sourcePosition: 700 currentToken: nil currentTokenFirst: Character space temporaries: a Dictionary() instanceVariables: a Set() errorBlock: nil currentTokenSourcePosition: nil blockDepth: 0 bracketDepth: 0 ranges: an OrderedCollection(a SHRange) environment: Smalltalk SHTextStylerST80>>rangesIn:setWorkspace: Receiver: a SHTextStylerST80 Arguments and temporary variables: aText: a Text for '"Choose a method to see its implementation ****General i...etc... aBoolean: true Receiver's instance variables: sem: nil backgroundProcess: nil text: a Text for '"Choose a method to see its implementation ****General in...etc... monitor: a Monitor view: a PluggableShoutMorph(625) stylingEnabled: true classOrMetaClass: a TimeProfileBrowser workspace: nil font: a LogicalFont familyName: DejaVu Sans Mono emphasis: nil pointSize: 9 ...etc... parser: a SHParserST80 formatAssignments: true environment: nil sourceMap: nil processedSourceMap: nil pixelHeight: 13.33333333333333 SHTextStylerST80>>privateStyle: Receiver: a SHTextStylerST80 Arguments and temporary variables: aText: a Text for '"Choose a method to see its implementation

Nov. 13, 2009

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

by Martin McClure

Igor Stasenko wrote: > No, please no more inilining hacks. :) > If someone wants to run everything at light speed - just code in C, > but leave smalltalk honoring the > message passing. > And besides, these tricks won't make any difference when having good > inlining JIT. > In bytecode, they just add a complexity to compiler and headache to developers. +64 to banning bytecode compiler hacks and instead concentrate on producing an inlining JIT. -Martin

Nov. 13, 2009

Re: [Pharo-project] status about hash changes

by Martin McClure

StÃ©phane Ducasse wrote: > Hi andres and martin > > what is the status of the changes you proposed ? > Because it would be nice to integrate them. Apologies for the delay. I've been incrementally reviewing Andres' changes as I get a few moments here and there. I have a tiny bit of reviewing yet to do, and some comments to make; if I get packed to leave for the weekend early today I might have time to write them up today. Regards, -Martin

Nov. 13, 2009

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

by Miguel Enrique CobÃ¡ Martinez

El vie, 13-11-2009 a las 13:16 +0100, Lukas Renggli escribiÃ³: > 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 I also vote for 1, but to manage the second case, the use is suggested to use a 1.0 image to change all the _ assignments and then export the package and load to the 1.1 image. As the 1.1 isn't the stable one, and the 1.0 will be the stable one, they will have time to change it. Besides. It isn't so big change to do either. Isn't as hard as rearchitecting the whole software or changing the inner implementation. It is a simple find and replace. And they have the slime rules to help. So go for the clean solution and do not look back. It will be a little hard at the beginning but good at the end. Cheers > -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Nov. 13, 2009

Re: [Pharo-project] Fwd: Fwd: MouseOverHandler

by Gary Chambers

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(a)inria.fr> To: "Pharo Development" <Pharo-project(a)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(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 > _______________________________________________ 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