March 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 2559 in pharo: Senders of #ifNotNil: do not show

by pharo＠googlecode.com

Comment #6 on issue 2559 by nicolas....(a)gmail.com: Senders of #ifNotNil: do not show http://code.google.com/p/pharo/issues/detail?id=2559 There are too many changes pending in old Compiler from Squeak. If you integrate issue2360 first, I'll see if i can merge. Anyway, you might be more interested in an Opal solution...

March 30, 2011

Re: [Pharo-project] Issue 2559 in pharo: Senders of #ifNotNil: do not show

by pharo＠googlecode.com

Updates: Status: FixedWaitingToBePharoed Labels: Milestone-1.3 Type-Squeak Comment #5 on issue 2559 by nicolas....(a)gmail.com: Senders of #ifNotNil: do not show http://code.google.com/p/pharo/issues/detail?id=2559 Nicolas Cellier uploaded a new version of Compiler to project The Trunk: http://source.squeak.org/trunk/Compiler-nice.201.mcz ==================== Summary ==================== Name: Compiler-nice.201 Author: nice Time: 31 March 2011, 12:45:32.697 am UUID: d694a5f8-4d75-2f4d-a06d-4c5de7fe1656 Ancestors: Compiler-nice.200 Put optimized selectors in CompiledMethod literals so that senders can be browsed normally. Take care to not overflow the scarse literal ressource. It is necessary to evaluate (Compiler recompileAll) before succesfully browsing senders of #ifNil: Thanks to Marcus at http://code.google.com/p/pharo/issues/detail?id=2559 for the idea. =============== Diff against Compiler-nice.200 =============== Item was changed: ParseNode subclass: #Encoder + instanceVariableNames: 'scopeTable nTemps supered requestor class selector literalStream selectorSet litIndSet litSet sourceRanges globalSourceRanges addedSelectorAndMethodClassLiterals optimizedSelectors' - instanceVariableNames: 'scopeTable nTemps supered requestor class selector literalStream selectorSet litIndSet litSet sourceRanges globalSourceRanges addedSelectorAndMethodClassLiterals' classVariableNames: '' poolDictionaries: '' category: 'Compiler-Kernel'! !Encoder commentStamp: '<historical>' prior: 0! I encode names and literals into tree nodes with byte codes for the compiler. Byte codes for literals are not assigned until the tree-sizing pass of the compiler, because only then is it known which literals are actually needed. I also keep track of sourceCode ranges during parsing and code generation so I can provide an inverse map for the debugger.! Item was changed: ----- Method: Encoder>>allLiterals (in category 'results') ----- allLiterals + addedSelectorAndMethodClassLiterals ifFalse: - ((literalStream isKindOf: WriteStream) - and: [ (addedSelectorAndMethodClassLiterals ifNil: [ false ]) not]) ifTrue: [addedSelectorAndMethodClassLiterals := true. + "Put the optimized selectors in literals so as to browse senders more easily" + optimizedSelectors := optimizedSelectors reject: [:e| literalStream originalContents hasLiteral: e]. + optimizedSelectors isEmpty ifFalse: [ + "Use one entry per literal if enough room, else make anArray" + literalStream position + optimizedSelectors size + 2 > 255 + ifTrue: [self litIndex: optimizedSelectors asArray] + ifFalse: [optimizedSelectors do: [:e | self litIndex: e]]]. + "Add a slot for selector or MethodProperties" + self litIndex: nil. + self litIndex: self associationForClass]. + ^literalStream contents! - self litIndex: nil. - self litIndex: self associationForClass]. - ^literalStream contents - - "The funky ifNil: [false], even though the init method initializes addedSAMCL, - is simply so that Monticello can load and compile this update without - killing the encoder that is compiling that update itself..."! Item was changed: ----- Method: Encoder>>initScopeAndLiteralTables (in category 'initialize-release') ----- initScopeAndLiteralTables scopeTable := StdVariables copy. litSet := StdLiterals copy. "comments can be left hanging on nodes from previous compilations. probably better than this hack fix is to create the nodes afresh on each compilation." scopeTable do: [:varNode| varNode comment: nil]. litSet do: [:varNode| varNode comment: nil]. selectorSet := StdSelectors copy. litIndSet := Dictionary new: 16. literalStream := WriteStream on: (Array new: 32). + addedSelectorAndMethodClassLiterals := false. + optimizedSelectors := Set new! - addedSelectorAndMethodClassLiterals := false! Item was removed: - ----- Method: Encoder>>nTemps:literals:class: (in category 'initialize-release') ----- - nTemps: n literals: lits class: cl - "Decompile." - - supered := false. - class := cl. - nTemps := n. - literalStream := ReadStream on: lits. - literalStream position: lits size. - sourceRanges := Dictionary new: 32. - globalSourceRanges := OrderedCollection new: 32. - ! Item was added: + ----- Method: Encoder>>noteOptimizedSelector: (in category 'encoding') ----- + noteOptimizedSelector: aSymbol + "Register a selector as being optimized. + These optimized selectors will later be registered into the literals so that tools can easily browse senders." + optimizedSelectors add: aSymbol! Item was changed: ----- Method: MessageNode>>sizeCodeForEffect: (in category 'code generation') ----- sizeCodeForEffect: encoder special > 0 + ifTrue: + [encoder noteOptimizedSelector: originalSelector. + ^self perform: (MacroSizers at: special) with: encoder with: false]. - ifTrue: [^self perform: (MacroSizers at: special) with: encoder with: false]. ^super sizeCodeForEffect: encoder! Item was changed: ----- Method: MessageNode>>sizeCodeForValue: (in category 'code generation') ----- sizeCodeForValue: encoder | total | special > 0 + ifTrue: + [encoder noteOptimizedSelector: originalSelector. + ^self perform: (MacroSizers at: special) with: encoder with: true]. - ifTrue: [^self perform: (MacroSizers at: special) with: encoder with: true]. receiver == NodeSuper ifTrue: [selector := selector copy "only necess for splOops"]. total := selector sizeCode: encoder args: arguments size super: receiver == NodeSuper. receiver == nil ifFalse: [total := total + (receiver sizeCodeForValue: encoder)]. sizes := arguments collect: [:arg | | argSize | argSize := arg sizeCodeForValue: encoder. total := total + argSize. argSize]. ^total!

March 30, 2011

Re: [Pharo-project] Issue 3916 in pharo: Can't input some Russian characters at text editors

by pharo＠googlecode.com

Comment #2 on issue 3916 by Dionisiy...(a)gmail.com: Can't input some Russian characters at text editors http://code.google.com/p/pharo/issues/detail?id=3916 I make another fix. Now all buttons pressed analizing works good Attachments: TextEditor-dispatchOn.st 2.3 KB

March 30, 2011

Re: [Pharo-project] Issue 3916 in pharo: Can't input some Russian characters at text editors

by pharo＠googlecode.com

Comment #1 on issue 3916 by Dionisiy...(a)gmail.com: Can't input some Russian characters at text editors http://code.google.com/p/pharo/issues/detail?id=3916 In TextEditor>>dispatchOn: aKeyboardEvent aKeyboardEvent>>keyValue analized for special actions like leftArrow should do. I think proplem that for russian "Ð" input keyboardEvent has keyValue 29 which is really leftRight ascii value. Possible fix attached. I replace analazing keyValue with analazing keyCharacter asciiValue. I make fix on pharo1.2 Attachments: TextEditor-dispatchOn.st 2.3 KB

March 30, 2011

Re: [Pharo-project] Thanks for Pharo

by Scott Gibson

Thanks Stef. I have signed the license form and will be sending it off. I will also do what I can in the other areas too. The consortium idea is interesting. I will need to read it further. Thanks, Scott On Mar 29, 2011, at 1:33 PM, StÃ©phane Ducasse wrote: > Thanks a lot scott and welcome. > > - sign the license :) > - report bug > - report successful stories :) > - tell us what are also your needs. For us this is important that people can make money and create cool products/ideas with Pharo. > > Then we are currently reading: http://caml.inria.fr/consortium/index.en.html to get an example for a possible Pharo consortium. > Our idea is to make sure that single people or really small entreprise can contribute. > > Stef > >> I just wanted to say thanks to everyone for all of the hard work that has been done for Pharo. Pharo 1.2 has come a long way and has been very enjoyable to use. >> >> Recently I had been given the opportunity to develop an application for a potential customer. I chose to use Pharo and Seaside and have been very happy with how well using Pharo 1.2 has been, with Cog even. >> >> I am very new to Smalltalk but I have been looking to help in any way (financially, documentation, etc.) that I can in order to help the progress of an open source Smalltalk, Pharo specifically. I am so new to Smalltalk that I feel I would be more of a hinderance than anything so I have not quite figured out how I could best help though I do hope to contribute in some way soon. >> >> >> Thanks again! >> Scott Gibson >> >> > > -- Scott Gibson wsgibson(a)windstream.net

March 30, 2011

[Pharo-project] Issue 3916 in pharo: Can't input some Russian characters at text editors

by pharo＠googlecode.com

Status: New Owner: ---- New issue 3916 by Dionisiy...(a)gmail.com: Can't input some Russian characters at text editors http://code.google.com/p/pharo/issues/detail?id=3916 Can't input some Russian characters at text editors. For example I can't input uppercased russian "Ð" and "Ð". Instead cursor go to left or to begin of line. Same happen with lowercase mode with shift pressed. I test it on Windows7 and XP, Pharo1.2 and 1.1 I debug texteditor code and found strange behavior at TextEditor>>dispatchOn: aKeyboardEvent method aKeyboardEevent in case of "Ð" input interpreted as leftArrow character. But in inspector I see aKeyboardEvent($Ð). I try to set up RussionEnvirenment as Locale current but no success.

March 30, 2011

Re: [Pharo-project] [COTDC] 38 - PathShape

by laurent laffont

An example: ps := Polygon new addVertex: 0@0; addVertex: 30@30; addVertex: 50@10. self assert: (ps containsPoint: 24@24). self assert: (ps containsPoint: 40@30) not. Transcript show: ps calculatedBounds asString; cr. On Wed, Mar 30, 2011 at 9:22 PM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > > > On Tue, Mar 29, 2011 at 10:47 AM, Gary Chambers <gazzaguru2(a)btinternet.com > > wrote: > >> "I represent a model of an open sequence of connected points that can be >> queried for >> enclosing bounds and whether a point lies along any segment. >> >> I am typically used for drawing with a Canvas." >> >> > Thanks Gary > > > Laurent. > > > >> Regards, Gary >> >> ----- Original Message ----- >> *From:* laurent laffont <laurent.laffont(a)gmail.com> >> *To:* An open mailing list to discuss any topics related to an >> open-sourceSmalltalk <pharo-project(a)lists.gforge.inria.fr> >> *Sent:* Tuesday, March 29, 2011 7:51 AM >> *Subject:* [Pharo-project] [COTDC] 38 - PathShape >> >> Let's comment Polymorph for several days. >> >> Today: PathShape >> >> Comment Of The Day Contest - One Day One Comment >> Rules: >> #1: Each day a not commented class is elected. Each day the best comment >> will be integrated with name of the author(s). >> #2: If you cannot comment it, deprecate it. >> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >> >> Laurent >> >> >

March 30, 2011

[Pharo-project] [COTDC] 39 - EditableDropListMorph

by laurent laffont

Today: EditableDropListMorph Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

March 30, 2011

Re: [Pharo-project] [COTDC] 38 - PathShape

by laurent laffont

On Tue, Mar 29, 2011 at 10:47 AM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > "I represent a model of an open sequence of connected points that can be > queried for > enclosing bounds and whether a point lies along any segment. > > I am typically used for drawing with a Canvas." > > Thanks Gary Laurent. > Regards, Gary > > ----- Original Message ----- > *From:* laurent laffont <laurent.laffont(a)gmail.com> > *To:* An open mailing list to discuss any topics related to an > open-sourceSmalltalk <pharo-project(a)lists.gforge.inria.fr> > *Sent:* Tuesday, March 29, 2011 7:51 AM > *Subject:* [Pharo-project] [COTDC] 38 - PathShape > > Let's comment Polymorph for several days. > > Today: PathShape > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent > >

March 30, 2011

Re: [Pharo-project] Which methods are really not executed?

by Marcus Denker

On Mar 28, 2011, at 11:28 AM, Mariano Martinez Peck wrote: > Hi folks. I would like to know which are the messages that are not really executed, thus not being intercepted by proxies. > So far, I know: > > 1) > those are inlined by the compiler... > yes. > 2) Special shorcut bytecodes that are in "Smalltalk specialSelectors" / "ParseNode classVarNamed: 'StdSelectors'" / "Smalltalk specialObjectsArray at: 24" > > Here I have a question...if I understand correctly, in this list of selectors there are 3 cases: > > 2.1) methods may or may not be executed depending on the receiver/arguments. For example > 1 + 2 will never send the message #+ to 1. > but 1 + 'mariano' will do. > yes. > 2.2) methods that are NEVER sent, like #class and #== > yes > 2.3) methods that are ALWAYS sent, like #new, #next, #nextPut:, #size, etc. > > So...did I understand correclty this part? > I think so, yes. > > are there more cases where a message may not be really executed? You could see the block creation bytecode as a problematic case. It's not a message, so you can't trap it. But then when we are on that level, the same is with iVar access. Or temp access. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 30, 2011