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

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

by Schwab,Wilhelm K

I feel somewhat responsible for this branch of the thread :( For the record, I am freely willing to "give up" underscore assignment. The idea of allowing it via a whitespace trick seemed worthy of due consideration, but I am liking it less as the debate continues. IIRC, the whole mess got started over a desire to have a single keypress for assignment. Sadly, I was not consulted, because that could have been accomplished as an optional feature of the editor (_ inserts :=, backing up over = removes a preceding :, turn it off if you want no part of it; done), but it was instead allowed to seep into the compiler and the sources. It can't go away too soon for my tastes, but a transition period makes sense too. Whatever you guys want to do is fine by me. Thanks for tackling the problem!! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Saturday, November 14, 2009 4:01 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Status about compiler _ changes >> (2) it complicates the scanning significantly, the same token >> represents different things depending on context and an extended >> lookahead is required to parse it, > > I'm afraid I'm not seeing this point. From a brief look at the > scanner, it appears that allowing := assignment did complicate the > scanner somewhat, but that allowing _ to mean assignment should be > similar complexity and still only require one-char lookahead. But > perhaps I'm missing something. You need to make sure that there is a delimiter (or comment) before and after the underscore character, which I think is not trivial to scan. Certainly possible, but not trivial. Furthermore it would make it impossible to write code like a _ b where a is a variable, #_ and #b are unary messages. The above code is valid in other Smalltalk dialects. >> and (3) it allows that people >> continue to use crappy underscore assignments, there will be a mess >> forever. > > I can't (and don't want to) argue with that :-) I'll gladly accept "we > don't want to allow underscore assignment" as an argument, I'm not so > sure about the "it's hard" argument. I am not saying it is impossible. My main concerns are the following: 1. I don't like that _ means different things depending on context. 2. I don't like that the use of _ in identifiers has unnecessary restrictions and exceptions. 3. I don't want to break compatibility with other Smalltalk dialects. 4. I don't want to see _ as assignment operator anymore. 5. I don't want to rewrite the complete compiler, there are probably more changes coming from Eliot for closures, the stack VM and the JIT. I don't want to make integrating those unnecessarily hard. 6. I don't want to break irreparably other tools that depend on the Smalltalk syntax like the Refactoring Engine or the NewCompiler. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 14, 2009

[Pharo-project] [update 1.1] #11042

by Marcus Denker

11042 ----- Issue 1438: Project removal continued.... Marcus -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Nov. 14, 2009

[Pharo-project] annotation pane revival

by Alain Plantec

Hi all, For those who like the annotation pane in browsers, changes sorter etc (of Pharo-core) Here is a SLICE that make it work again. It also cleans PluggableTextMorph (remove dirty code related to annotation) Could you check before I send it to the inbox ? thanks Alain

Nov. 14, 2009

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

by Lukas Renggli

>> (2) it complicates the scanning significantly, the same >> token represents different things depending on context and an extended >> lookahead is required to parse it, > > I'm afraid I'm not seeing this point. From a brief look at the scanner, > it appears that allowing := assignment did complicate the scanner > somewhat, but that allowing _ to mean assignment should be similar > complexity and still only require one-char lookahead. But perhaps I'm > missing something. You need to make sure that there is a delimiter (or comment) before and after the underscore character, which I think is not trivial to scan. Certainly possible, but not trivial. Furthermore it would make it impossible to write code like a _ b where a is a variable, #_ and #b are unary messages. The above code is valid in other Smalltalk dialects. >> and (3) it allows that people >> continue to use crappy underscore assignments, there will be a mess >> forever. > > I can't (and don't want to) argue with that :-) > I'll gladly accept "we don't want to allow underscore assignment" as an > argument, I'm not so sure about the "it's hard" argument. I am not saying it is impossible. My main concerns are the following: 1. I don't like that _ means different things depending on context. 2. I don't like that the use of _ in identifiers has unnecessary restrictions and exceptions. 3. I don't want to break compatibility with other Smalltalk dialects. 4. I don't want to see _ as assignment operator anymore. 5. I don't want to rewrite the complete compiler, there are probably more changes coming from Eliot for closures, the stack VM and the JIT. I don't want to make integrating those unnecessarily hard. 6. I don't want to break irreparably other tools that depend on the Smalltalk syntax like the Refactoring Engine or the NewCompiler. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Nov. 14, 2009

[Pharo-project] macintosh carbon VM goes to legacy status.

by John M McIntosh

The macintosh carbon VM is going into a legacy support state. Why? ESUG has provided me with some funds to help build a new 32/64 bit Cocoa (intel/ppc) based Squeak VM, please don't forget to thank them for supporting the community. Today based on the iPhone VM tree and many more hours of effort I managed to start up a 64 bit intel based Cocoa VM using a 32bit squeak image. I still have a "bit" more to go in order to get the keyboard logic to correctly mimic the older carbon behaviour, so I won't start public beta testing until the end of the month. And it only feels like a sea of "warning: cast from pointer to integer of different size" to work thru, but previous efforts by folks like David T Lewis has reduced that to I think a manageable issue. If you are interested in alpha testing the VM please email me privately and I'll see if I can get you a workable VM by the end of next week. The primary project goal is to: Build a new cocoa based 32/64bit intel/ppc VM with an MIT license, basically from scratch, to enable the ability to use a 32bit image or 64bit image. Some other objectives: To build it from scratch using the 4.2.2 VM as a reference To ensure the xcode project can build both an OSX VM and a iPhone VM. Port as little code from the past, excluding the Socket and basic file I/O logic. Other plugins address as needed. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Nov. 14, 2009

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

by StÃ©phane Ducasse

open a ticket. Your changes are neat. Stef On Nov 13, 2009, at 6:29 PM, CÃ©drick BÃ©ler wrote: > 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 > <ParagraphEditor-tallySelection.st><TimeProfileBrowser-selectedMessage.st><TimeProfileBrowser class-helpMessage.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 14, 2009

Re: [Pharo-project] status about hash changes

by StÃ©phane Ducasse

Thanks martin. Don't worry take your time. I just wanted to know where you were. Stef > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 14, 2009

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

by StÃ©phane Ducasse

argh! I loved magic. In that case I would go for 2 because supporting migration is important. Stef >> 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 > > That would be the magic solution :-) > > The problem is that it would not be clear how to parse a_1. Is it the > assignment of 1 to a or the access of the variable a_1? > > I don't like the proposal of requiring a delimiter before and after an > underscore assignment: (1) there is existing code where this is not > the case, (2) it complicates the scanning significantly, the same > token represents different things depending on context and an extended > lookahead is required to parse it, and (3) it allows that people > continue to use crappy underscore assignments, there will be a mess > forever. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 14, 2009

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

by Bryce Kampjes

On Fri, 2009-11-13 at 09:13 -0800, Martin McClure wrote: > 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. I'm working on inlining in Exupery now. The first three basic tests pass. Bryce

Nov. 13, 2009

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

by Martin McClure

Lukas Renggli wrote: >> 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 > > That would be the magic solution :-) > > The problem is that it would not be clear how to parse a_1. Is it the > assignment of 1 to a or the access of the variable a_1? > > I don't like the proposal of requiring a delimiter before and after an > underscore assignment: (1) there is existing code where this is not > the case, A small minority of code, surely? > (2) it complicates the scanning significantly, the same > token represents different things depending on context and an extended > lookahead is required to parse it, I'm afraid I'm not seeing this point. From a brief look at the scanner, it appears that allowing := assignment did complicate the scanner somewhat, but that allowing _ to mean assignment should be similar complexity and still only require one-char lookahead. But perhaps I'm missing something. > and (3) it allows that people > continue to use crappy underscore assignments, there will be a mess > forever. I can't (and don't want to) argue with that :-) I'll gladly accept "we don't want to allow underscore assignment" as an argument, I'm not so sure about the "it's hard" argument. Regards, -Martin

Nov. 13, 2009