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

Re: [Pharo-project] expanding text morph

by Gary Chambers

Hi Doru. When adding a page to a tab group the morph has its h/v resizing set to #spaceFill, so needs resetting after addding: textMorph := UITheme builder newText: ''. textMorph borderWidth: 1; unlock. tabs := TabGroupMorph new. tabs vResizing: #shrinkWrap; hResizing: #spaceFill; addPage: textMorph label: 'Tab'. tabs selectedPageIndex: 1. textMorph vResizing: #shrinkWrap. "or #rigid will do" (UITheme builder newColumn: { UITheme builder newExpander: 'One' for: tabs. UITheme builder newExpander: 'Two' for: Morph new}) openInWindow. textMorph contentsWrapped: 'Some text here use #contentsWrapped: to change text' Regards, Gary ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, August 25, 2011 1:15 AM Subject: Re: [Pharo-project] expanding text morph Ok, here comes a follow up question. I would like now to have the morph in a tab, have the tab in the expander, and get this tab to resize when the inner text morph changes. I tried to make the tab shrinkWrap, but it does not seem to work there. Is it possible that this is a problem of the TabGroupMorph? Here is the code I used: textMorph := UITheme builder newText: ''. textMorph hResizing: #spaceFill; borderWidth: 1; unlock. tabs := TabGroupMorph new. tabs vResizing: #shrinkWrap; hResizing: #spaceFill; addPage: textMorph label: 'Tab'. tabs selectedPageIndex: 1. (UITheme builder newColumn: { UITheme builder newExpander: 'One' for: tabs. UITheme builder newExpander: 'Two' for: Morph new}) openInWindow. textMorph contentsWrapped: 'Some text here use #contentsWrapped: to change text' Cheers, Doru On 25 Aug 2011, at 01:24, Tudor Girba wrote: > Pretty cool! > > Thanks, > Doru > > > On 24 Aug 2011, at 11:54, Gary Chambers wrote: > >> In the following example the expander resizes >> >> |textMorph| >> textMorph := UITheme builder newText: ''. >> textMorph >> hResizing: #spaceFill; >> borderWidth: 1. >> (UITheme builder newColumn: { >> UITheme builder newExpander: 'One' for: textMorph. >> UITheme builder newExpander: 'Two' for: Morph new}) openInWindow. >> >> textMorph contentsWrapped: 'Some text here >> use #contentsWrapped: to change text' >> >> In general, if the surrounding morph has #shrinkWrap constraints then >> changes to the (minimum) dimensions of its submorphs will propagate >> resulting in a change of size for the surrounding morph. >> >> Regards, Gary >> >> ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, August 23, 2011 1:36 PM >> Subject: Re: [Pharo-project] expanding text morph >> >> >> Thanks, Gary! >> >> And now the next question: >> If I place this one in a surrounding pane / expander / tab, how do I get >> the surrounding morph to resize when the text changes? >> >> Cheers, >> Doru >> >> >> On 22 Aug 2011, at 12:15, Gary Chambers wrote: >> >>> Hi Doru >>> >>> >>> |textMorph| >>> textMorph := UITheme builder newText: ''. >>> textMorph >>> hResizing: #spaceFill; >>> borderWidth: 1. >>> (UITheme builder newColumn: {textMorph}) openInWindow. >>> textMorph contentsWrapped: 'Some text here >>> >>> Get a halo and inspect the text morph >>> then use #contentsWrapped: to change text >>> >>> >>> and see the results! >>> >>> #rigid hResizing also works.' >>> >>> >>> >>> Have fun! >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> >>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Sunday, August 21, 2011 11:57 PM >>> Subject: [Pharo-project] expanding text morph >>> >>> >>> Hi, >>> >>> I would like to create a Text Morph that wraps the text horizontally, >>> and expands the height to fit the text. Thus, this morph would never >>> offer scrolling. >>> >>> How could I do that? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "There are no old things, there are only old ways of looking at them." >>> >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know her." >> >> >> >> >> > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Aug. 25, 2011

Re: [Pharo-project] Some bugs

by StÃ©phane Ducasse

tx nicolas this is a cool way to help :) Stef On Aug 24, 2011, at 9:54 PM, Nicolas Cellier wrote: > So the entries of interest for highlighting are > > Debugger>>contentsSelection > Debugger>>pcRange > CompiledMethod>>debuggerMap > DebuggerMethodMap class>>forMethod: > DebuggerMethodMap>>rangeForPC:contextIsActiveContext: > > Then you see the DebuggerMethodMap>>forMethod:methodNode: takes both a > CompiledMethod and its #methodNode. > CompiledMethod>>methodNode invokes the Parser to get the > AbstractSyntaxTree from method source, and if it ever fails ends up by > trying to decompile the byteCodes. > > This is the easy part. Now we to deal with #abstractPCForConcretePC: > and #abstractSourceMap. > > By reading CompiledMethod>>abstractPCForConcretePC: you should quickly > understand that a concrete PC is a byte offset of current byteCode > (the offsets displayed in the byteCode view) while the abstractPC is > just the rank of current byteCode in the list of byteCodes > instructions composing the CompiledMethod. This is just because > "byteCodes" may spread on several bytes beside their name... > This will use InstructionStream and InstructionClient which are just > an iterator and a sort of visitor on byteCode instructions. > So this is not really interesting. > > The more interesting part is #abstractSourceMap > There is a first step to obtain CompiledMethod>>rawSourceRangesAndMethodDo: > This is the most important part. > The rest is again a mapping from concretePC (instruction byte offset) > to abstractPC (instruction rank). > And some build of a dictionary mapping instruction rank (abstractPC) > -> selected range. > > Note that the last trick seems to use a regenerated CompiledMethod > (theMethodToScan) rather than the original CompiledMethod. There is no > assertion whether these two are equivalent or not. A priori, they > should, unless the Compiler changed since last compilation or if its > behaviour is affected by some Preferences... Would we introduce some > customizable Compiler optimizations that this could become a problem > (We would then add to map decompiled AST to source code AST, probably > with guesses, unless the CompiledMethod would contain debugger > friendly hints...) > We will consider this is not a problem by now. > > So let's now concentrate on rawSourceRangesAndMethodDo: > The nice thing is that you now can just debug this > > (ClosureTests>>#testToDoOutsideTemp) methodNode > rawSourceRangesAndMethodDo: [:rs :mth | ] > > and see how it goes in Squeak. I did not look in Pharo yet, but I > would be amazed to see it much different. > It's now late, and my spare time is off, but you have clues to get > more insights. I wish you good debugging, and come back to me if it > ever goes in deeper complications. > > Cheers > > Nicolas > > 2011/8/24 Michael Roberts <mike(a)mjr104.co.uk>: >> >>> >>> Ok I'm curious to know then. >> >> Here is a little trace from this example method: >> >> toDoOutsideTemp >> | temp collection | >> collection := OrderedCollection new. >> 1 to: 5 do: [ :index | >> temp := index. >> collection add: [ temp ] ] >> >> Trace is start,stop position of the highlight for each 'step over'. >> >> Whilst the numbers are hard to visualise, below you can see how they >> slightly diverge. >> Left Pharo Right Squeak >> >> 50, 73 71, 73 diff >> 71, 73 71, 73 >> 50, 73 50, 73 >> 108, 115 79, 121 diff >> 79, 121 79, 121 >> 108, 115 108, 115 >> 132, 144 132, 144 >> 147, 146 146, 146 (diff negative size means no highlight) >> 146, 146 146, 146 >> 79, 121 79, 121 >> 108, 115 108, 115 >> 132, 144 132, 144 >> 147, 146 146, 146 >> 146, 146 146, 146 >> 79, 121 79, 121 >> 108, 115 108, 115 >> 132, 144 132, 144 >> 147, 146 146, 146 >> 146, 146 146, 146 >> 79, 121 79, 121 >> 108, 115 108, 115 >> etc... >> For example the first difference is because Pharo shows the whole assignment >> of the first line as the first send, even though it is not. >> The second difference is that Pharo shows the assignment inside the block as >> the first highlight of the loop even though the to:do should be >> highlighted....but both Pharo & Squeak get the to:do: wrong when they choose >> to show it. >> hope you get the idea... >> Mike >

Aug. 25, 2011

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] new Cog VMs available

by Eliot Miranda

On Aug 24, 2011, at 10:54 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Tue, 16 Aug 2011, Eliot Miranda wrote: > >> in http://www.mirandabanda.org/files/Cog/VM/VM.r2487/. >> >> Fix bugs described in the "[Pharo-project] Troubles with #flushCache and >> #run:with:in:" thread http://lists.gforge.inria.fr/pipermail/pharo-project/ >> 2011-July/050858.html. The PIC machinery wrongly treated invoke-as-method >> sends as MNUs. >> >> Closely related, finally fully implement PIC MNU cacheing where, by calling >> a >> special abort, a PIC is able to record that a gven selector is an MNU for a >> particular class. Speeds up a simple MNU benchmark by 33% (with more >> performance the deeper the receiver's cass hierarchy is). > > Sounds great. Does it work with #cannotInterpret:? In theory ;). Test it and see. If it fails, point me at the test ;). [at ESUG; wish you were here, Levente] Eliot (phone) > Levente > >> >> On Mac fix mis-editing of Info.plist to insert revision info so that VM .app >> once again starts on 10.5.x. >> -- >> best, >> Eliot >>

Aug. 25, 2011

Re: [Pharo-project] Some bugs

by Michael Roberts

http://code.google.com/p/pharo/wiki/DebuggerInternals

Aug. 25, 2011

Re: [Pharo-project] Some bugs

by Michael Roberts

;-) thanks! yes i looked at it a little with Marcus and got lost when the InstructionStream was invoked. Your analysis is really useful. i have a 4 hr train journey soon! Mike On Wed, Aug 24, 2011 at 10:08 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 2011/8/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > So the entries of interest for highlighting are > > > > Debugger>>contentsSelection > > Debugger>>pcRange > > CompiledMethod>>debuggerMap > > DebuggerMethodMap class>>forMethod: > > DebuggerMethodMap>>rangeForPC:contextIsActiveContext: > > > > Then you see the DebuggerMethodMap>>forMethod:methodNode: takes both a > > CompiledMethod and its #methodNode. > > CompiledMethod>>methodNode invokes the Parser to get the > > AbstractSyntaxTree from method source, and if it ever fails ends up by > > trying to decompile the byteCodes. > > > > This is the easy part. Now we to deal with #abstractPCForConcretePC: > > and #abstractSourceMap. > > > > By reading CompiledMethod>>abstractPCForConcretePC: you should quickly > > understand that a concrete PC is a byte offset of current byteCode > > (the offsets displayed in the byteCode view) while the abstractPC is > > just the rank of current byteCode in the list of byteCodes > > instructions composing the CompiledMethod. This is just because > > "byteCodes" may spread on several bytes beside their name... > > This will use InstructionStream and InstructionClient which are just > > an iterator and a sort of visitor on byteCode instructions. > > So this is not really interesting. > > > > The more interesting part is #abstractSourceMap > > There is a first step to obtain > CompiledMethod>>rawSourceRangesAndMethodDo: > > This is the most important part. > > The rest is again a mapping from concretePC (instruction byte offset) > > to abstractPC (instruction rank). > > And some build of a dictionary mapping instruction rank (abstractPC) > > -> selected range. > > > > Note that the last trick seems to use a regenerated CompiledMethod > > (theMethodToScan) rather than the original CompiledMethod. There is no > > assertion whether these two are equivalent or not. A priori, they > > should, unless the Compiler changed since last compilation or if its > > behaviour is affected by some Preferences... Would we introduce some > > customizable Compiler optimizations that this could become a problem > > (We would then add to map decompiled AST to source code AST, probably > > with guesses, unless the CompiledMethod would contain debugger > > friendly hints...) > > We will consider this is not a problem by now. > > > > So let's now concentrate on rawSourceRangesAndMethodDo: > > The nice thing is that you now can just debug this > > > > (ClosureTests>>#testToDoOutsideTemp) methodNode > > rawSourceRangesAndMethodDo: [:rs :mth | ] > > > > and see how it goes in Squeak. I did not look in Pharo yet, but I > > would be amazed to see it much different. > > It's now late, and my spare time is off, but you have clues to get > > more insights. I wish you good debugging, and come back to me if it > > ever goes in deeper complications. > > > > Cheers > > > > Nicolas > > > > Oh, I couldn't resist and just tried, and it's indeed getting harder, > because it involves a zoo of Compiler internals, at least the Encoder, > the BlockAnalyzer... > Funny, the method node is once more generated in this phase :). All > this stuff is cached at upper level, but we have at least clues for > further optimizations ;) > > Nicolas > > > 2011/8/24 Michael Roberts <mike(a)mjr104.co.uk>: > >> > >>> > >>> Ok I'm curious to know then. > >> > >> Here is a little trace from this example method: > >> > >> toDoOutsideTemp > >> | temp collection | > >> collection := OrderedCollection new. > >> 1 to: 5 do: [ :index | > >> temp := index. > >> collection add: [ temp ] ] > >> > >> Trace is start,stop position of the highlight for each 'step over'. > >> > >> Whilst the numbers are hard to visualise, below you can see how they > >> slightly diverge. > >> Left Pharo Right Squeak > >> > >> 50, 73 71, 73 diff > >> 71, 73 71, 73 > >> 50, 73 50, 73 > >> 108, 115 79, 121 diff > >> 79, 121 79, 121 > >> 108, 115 108, 115 > >> 132, 144 132, 144 > >> 147, 146 146, 146 (diff negative size means no highlight) > >> 146, 146 146, 146 > >> 79, 121 79, 121 > >> 108, 115 108, 115 > >> 132, 144 132, 144 > >> 147, 146 146, 146 > >> 146, 146 146, 146 > >> 79, 121 79, 121 > >> 108, 115 108, 115 > >> 132, 144 132, 144 > >> 147, 146 146, 146 > >> 146, 146 146, 146 > >> 79, 121 79, 121 > >> 108, 115 108, 115 > >> etc... > >> For example the first difference is because Pharo shows the whole > assignment > >> of the first line as the first send, even though it is not. > >> The second difference is that Pharo shows the assignment inside the > block as > >> the first highlight of the loop even though the to:do should be > >> highlighted....but both Pharo & Squeak get the to:do: wrong when they > choose > >> to show it. > >> hope you get the idea... > >> Mike > > > >

Aug. 25, 2011

Re: [Pharo-project] expanding text morph

by Tudor Girba

Ok, here comes a follow up question. I would like now to have the morph in a tab, have the tab in the expander, and get this tab to resize when the inner text morph changes. I tried to make the tab shrinkWrap, but it does not seem to work there. Is it possible that this is a problem of the TabGroupMorph? Here is the code I used: textMorph := UITheme builder newText: ''. textMorph hResizing: #spaceFill; borderWidth: 1; unlock. tabs := TabGroupMorph new. tabs vResizing: #shrinkWrap; hResizing: #spaceFill; addPage: textMorph label: 'Tab'. tabs selectedPageIndex: 1. (UITheme builder newColumn: { UITheme builder newExpander: 'One' for: tabs. UITheme builder newExpander: 'Two' for: Morph new}) openInWindow. textMorph contentsWrapped: 'Some text here use #contentsWrapped: to change text' Cheers, Doru On 25 Aug 2011, at 01:24, Tudor Girba wrote: > Pretty cool! > > Thanks, > Doru > > > On 24 Aug 2011, at 11:54, Gary Chambers wrote: > >> In the following example the expander resizes >> >> |textMorph| >> textMorph := UITheme builder newText: ''. >> textMorph >> hResizing: #spaceFill; >> borderWidth: 1. >> (UITheme builder newColumn: { >> UITheme builder newExpander: 'One' for: textMorph. >> UITheme builder newExpander: 'Two' for: Morph new}) openInWindow. >> >> textMorph contentsWrapped: 'Some text here >> use #contentsWrapped: to change text' >> >> In general, if the surrounding morph has #shrinkWrap constraints then changes to the (minimum) dimensions of its submorphs will propagate resulting in a change of size for the surrounding morph. >> >> Regards, Gary >> >> ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, August 23, 2011 1:36 PM >> Subject: Re: [Pharo-project] expanding text morph >> >> >> Thanks, Gary! >> >> And now the next question: >> If I place this one in a surrounding pane / expander / tab, how do I get the surrounding morph to resize when the text changes? >> >> Cheers, >> Doru >> >> >> On 22 Aug 2011, at 12:15, Gary Chambers wrote: >> >>> Hi Doru >>> >>> >>> |textMorph| >>> textMorph := UITheme builder newText: ''. >>> textMorph >>> hResizing: #spaceFill; >>> borderWidth: 1. >>> (UITheme builder newColumn: {textMorph}) openInWindow. >>> textMorph contentsWrapped: 'Some text here >>> >>> Get a halo and inspect the text morph >>> then use #contentsWrapped: to change text >>> >>> >>> and see the results! >>> >>> #rigid hResizing also works.' >>> >>> >>> >>> Have fun! >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> >>> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >>> Sent: Sunday, August 21, 2011 11:57 PM >>> Subject: [Pharo-project] expanding text morph >>> >>> >>> Hi, >>> >>> I would like to create a Text Morph that wraps the text horizontally, and expands the height to fit the text. Thus, this morph would never offer scrolling. >>> >>> How could I do that? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "There are no old things, there are only old ways of looking at them." >>> >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know her." >> >> >> >> >> > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Aug. 25, 2011

Re: [Pharo-project] [ANN] OpenDBXDriver Release - DBXTalk Release Step 1

by Guillermo Polito

Hmm, I confused and attached the tex file :P. Here is the pdf! On Wed, Aug 24, 2011 at 9:19 AM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hi folks!! > > We are proud to make our first release of OpenDBXDriver -1.0 version-, > formerly known as SqueakDBX. Now the project involves much more than just a > database driver. This whole new project is called DBXTalk and OpenDBXDriver > is just one of the sub-projects. > > There are several changes between this version and the last one of > SqueakDBX, but most of them is about infrastructure: test were moved to a > separate package, platform packages and backend classes were renamed, all > "SqueakDBX" was replaced with its new name. > > To install it: > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOpenDBXDriver'; > load. > > (((Smalltalk globals at: #ConfigurationOfOpenDBXDriver) perform: #project) > perform: #version: with: #stable) load. > > > We have also created a new repository for all the code: > http://www.squeaksource.com/DBXTalk > > The issue tracker is in: http://code.google.com/p/dbxtalk/issues/list > > Thanks to Natacha Perrin we have a new DBXTalk logo that you can see in: > http://imageshack.us/photo/my-images/37/dbxtalk46.png > The license of the logo is Creative Commons. > > We have also started a Pharo By Example chapter. So far we are writing > about DBXTalk, but soon we will do about Glorp. We attach a draft of it > while it is integrated into the main git repository of the book. > Just in case here is the git repo fork: > https://github.com/guillep/PharoByExample-english. > > Just to let you know, we have already ported the last VW release of Glorp > to Pharo and we have it already working MySQL, PostgreSQL, Oracle and > Sqlite3. We are closing some last problems and we will soon make the first > release. We want to thanks Alan Night for all his help and his reviews :). > > 4 persons of the team are present at ESUG right now and we are going to > give a talk on Friday. We will upload then the slides. > > Finally, we would like to thanks ESUG for the sponsorship through this ESUG > SummerTalk. > > Thanks! > Guille, Mariano, Esteban, Santiago, Gise >

Aug. 24, 2011

Re: [Pharo-project] expanding text morph

by Tudor Girba

Pretty cool! Thanks, Doru On 24 Aug 2011, at 11:54, Gary Chambers wrote: > In the following example the expander resizes > > |textMorph| > textMorph := UITheme builder newText: ''. > textMorph > hResizing: #spaceFill; > borderWidth: 1. > (UITheme builder newColumn: { > UITheme builder newExpander: 'One' for: textMorph. > UITheme builder newExpander: 'Two' for: Morph new}) openInWindow. > > textMorph contentsWrapped: 'Some text here > use #contentsWrapped: to change text' > > In general, if the surrounding morph has #shrinkWrap constraints then changes to the (minimum) dimensions of its submorphs will propagate resulting in a change of size for the surrounding morph. > > Regards, Gary > > ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, August 23, 2011 1:36 PM > Subject: Re: [Pharo-project] expanding text morph > > > Thanks, Gary! > > And now the next question: > If I place this one in a surrounding pane / expander / tab, how do I get the surrounding morph to resize when the text changes? > > Cheers, > Doru > > > On 22 Aug 2011, at 12:15, Gary Chambers wrote: > >> Hi Doru >> >> >> |textMorph| >> textMorph := UITheme builder newText: ''. >> textMorph >> hResizing: #spaceFill; >> borderWidth: 1. >> (UITheme builder newColumn: {textMorph}) openInWindow. >> textMorph contentsWrapped: 'Some text here >> >> Get a halo and inspect the text morph >> then use #contentsWrapped: to change text >> >> >> and see the results! >> >> #rigid hResizing also works.' >> >> >> >> Have fun! >> >> Regards, Gary >> >> ----- Original Message ----- From: "Tudor Girba" <tudor(a)tudorgirba.com> >> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Sunday, August 21, 2011 11:57 PM >> Subject: [Pharo-project] expanding text morph >> >> >> Hi, >> >> I would like to create a Text Morph that wraps the text horizontally, and expands the height to fit the text. Thus, this morph would never offer scrolling. >> >> How could I do that? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "There are no old things, there are only old ways of looking at them." >> >> >> >> >> > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > -- www.tudorgirba.com "We are all great at making mistakes."

Aug. 24, 2011

Re: [Pharo-project] [squeak-dev] new Cog VMs available

by Levente Uzonyi

On Tue, 16 Aug 2011, Eliot Miranda wrote: > in http://www.mirandabanda.org/files/Cog/VM/VM.r2487/. > > Fix bugs described in the "[Pharo-project] Troubles with #flushCache and > #run:with:in:" thread http://lists.gforge.inria.fr/pipermail/pharo-project/ > 2011-July/050858.html. The PIC machinery wrongly treated invoke-as-method > sends as MNUs. > > Closely related, finally fully implement PIC MNU cacheing where, by calling > a > special abort, a PIC is able to record that a gven selector is an MNU for a > particular class. Speeds up a simple MNU benchmark by 33% (with more > performance the deeper the receiver's cass hierarchy is). Sounds great. Does it work with #cannotInterpret:? Levente > > On Mac fix mis-editing of Info.plist to insert revision info so that VM .app > once again starts on 10.5.x. > -- > best, > Eliot >

Aug. 24, 2011

Re: [Pharo-project] Some bugs

by Nicolas Cellier

2011/8/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > So the entries of interest for highlighting are > > Debugger>>contentsSelection > Debugger>>pcRange > CompiledMethod>>debuggerMap > DebuggerMethodMap class>>forMethod: > DebuggerMethodMap>>rangeForPC:contextIsActiveContext: > > Then you see the DebuggerMethodMap>>forMethod:methodNode: takes both a > CompiledMethod and its #methodNode. > CompiledMethod>>methodNode invokes the Parser to get the > AbstractSyntaxTree from method source, and if it ever fails ends up by > trying to decompile the byteCodes. > > This is the easy part. Now we to deal with #abstractPCForConcretePC: > and #abstractSourceMap. > > By reading CompiledMethod>>abstractPCForConcretePC: you should quickly > understand that a concrete PC is a byte offset of current byteCode > (the offsets displayed in the byteCode view) while the abstractPC is > just the rank of current byteCode in the list of byteCodes > instructions composing the CompiledMethod. This is just because > "byteCodes" may spread on several bytes beside their name... > This will use InstructionStream and InstructionClient which are just > an iterator and a sort of visitor on byteCode instructions. > So this is not really interesting. > > The more interesting part is #abstractSourceMap > There is a first step to obtain CompiledMethod>>rawSourceRangesAndMethodDo: > This is the most important part. > The rest is again a mapping from concretePC (instruction byte offset) > to abstractPC (instruction rank). > And some build of a dictionary mapping instruction rank (abstractPC) > -> selected range. > > Note that the last trick seems to use a regenerated CompiledMethod > (theMethodToScan) rather than the original CompiledMethod. There is no > assertion whether these two are equivalent or not. A priori, they > should, unless the Compiler changed since last compilation or if its > behaviour is affected by some Preferences... Would we introduce some > customizable Compiler optimizations that this could become a problem > (We would then add to map decompiled AST to source code AST, probably > with guesses, unless the CompiledMethod would contain debugger > friendly hints...) > We will consider this is not a problem by now. > > So let's now concentrate on rawSourceRangesAndMethodDo: > The nice thing is that you now can just debug this > > (ClosureTests>>#testToDoOutsideTemp) methodNode > rawSourceRangesAndMethodDo: [:rs :mth | ] > > and see how it goes in Squeak. I did not look in Pharo yet, but I > would be amazed to see it much different. > It's now late, and my spare time is off, but you have clues to get > more insights. I wish you good debugging, and come back to me if it > ever goes in deeper complications. > > Cheers > > Nicolas > Oh, I couldn't resist and just tried, and it's indeed getting harder, because it involves a zoo of Compiler internals, at least the Encoder, the BlockAnalyzer... Funny, the method node is once more generated in this phase :). All this stuff is cached at upper level, but we have at least clues for further optimizations ;) Nicolas > 2011/8/24 Michael Roberts <mike(a)mjr104.co.uk>: >> >>> >>> Ok I'm curious to know then. >> >> Here is a little trace from this example method: >> >> toDoOutsideTemp >> | temp collection | >> collection := OrderedCollection new. >> 1 to: 5 do: [ :index | >> temp := index. >> collection add: [ temp ] ] >> >> Trace is start,stop position of the highlight for each 'step over'. >> >> Whilst the numbers are hard to visualise, below you can see how they >> slightly diverge. >> Left Pharo Â Right Â Squeak >> >> 50, 73 Â Â 71, 73 Â Â Â diff >> 71, 73 Â Â 71, 73 >> 50, 73 Â Â 50, 73 >> 108, 115 Â 79, 121 Â Â Â diff >> 79, 121 Â Â 79, 121 >> 108, 115 Â 108, 115 >> 132, 144 Â 132, 144 >> 147, 146 Â 146, 146 Â Â (diff negative size means no highlight) >> 146, 146 Â 146, 146 >> 79, 121 Â Â 79, 121 >> 108, 115 Â 108, 115 >> 132, 144 Â 132, 144 >> 147, 146 Â 146, 146 >> 146, 146 Â 146, 146 >> 79, 121 Â Â 79, 121 >> 108, 115 Â 108, 115 >> 132, 144 Â 132, 144 >> 147, 146 Â 146, 146 >> 146, 146 Â 146, 146 >> 79, 121 Â Â 79, 121 >> 108, 115 Â 108, 115 >> etc... >> For example the first difference is because Pharo shows the whole assignment >> of the first line as the first send, even though it is not. >> The second difference is that Pharo shows the assignment inside the block as >> the first highlight of the loop even though the to:do should be >> highlighted....but both Pharo & Squeak get the to:do: wrong when they choose >> to show it. >> hope you get the idea... >> Mike >

Aug. 24, 2011