- Pharo-dev - lists.pharo.org

[Pharo-project] how to capture pasting in a textmorph

by Tudor Girba

Hi, I have a PluggableTextMorph, and I would like to get notified every time the text contents change. Currently, I intercept keystroke:from:, but the problem is that this does not capture pasting of text. Is there a better hook? Cheers, Doru -- www.tudorgirba.com "Value is always contextual."

Sept. 7, 2011

Re: [Pharo-project] ProfStef port

by Bernat Romagosa

Oh wow! I love the design! I told you somebody else had to do it ;) Cheers, 2011/9/6 Michael Roberts <mike(a)mjr104.co.uk> > this is brilliant!... > > one tiny thing i noticed on page 22/24 if you print the method source, > the editor highlight only covers the first line of the multi-line > output. Perhaps it only ever expects single line highlights. > > cheers, > Mike > > On Tue, Sep 6, 2011 at 9:27 PM, laurent laffont > <laurent.laffont(a)gmail.com> wrote: > > Funny, Bernat and Nicolas have written a port of ProfStef to > > JTalk: http://jtalk-project.org/learn.html > > Laurent > > > > -- Bernat Romagosa.

Sept. 7, 2011

Re: [Pharo-project] data set

by GastÃ³n Dall' Oglio

Possibly the wikipedia database raw is not as useful, so there are efforts in different ways to structure the information it contains. See: http://dbpedia.org/ GastÃ³n. 2011/9/6 GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> > Hello. > > The Wikipedia database? > http://en.wikipedia.org/wiki/Wikipedia:Database_download > > GastÃ³n. > > 2011/9/6 Tudor Girba <tudor(a)tudorgirba.com> > >> Thanks everyone for the suggestions. I will try to look into them. >> >> Cheers, >> Doru >> >> >> >> On 5 Sep 2011, at 07:04, Lukas Renggli wrote: >> >> > Stanford has many large graph-like datasets to download: social >> > networks, web graphs, peer-to-peer networks, shopping networks, road >> > networks, wikipedia networks, etc. >> > >> > http://snap.stanford.edu/data/ >> > >> > Lukas >> > >> > On 5 September 2011 06:24, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> I've used as an example of datamining a dataset about car accidents we >> got >> >> from here http://www.nhtsa.gov/NASS . >> >> >> >> Hope it helps :) >> >> Guille >> >> >> >> On Sun, Sep 4, 2011 at 11:58 PM, HernÃ¡n Morales Durand >> >> <hernan.morales(a)gmail.com> wrote: >> >>> >> >>> 2011/9/4 Tudor Girba <tudor(a)tudorgirba.com>: >> >>>> Hi, >> >>>> >> >>>> Thanks, but I am looking for data sets that contained graphs of >> entities >> >>>> with properties, rather then numbers. >> >>>> >> >>> >> >>> Oh, that was just the top of the iceberg, look at cellular interaction >> >>> networks like protein-protein interactions, relations between genes >> >>> and QTLs, phylogenetic trees, gene ontology classifications, etc. >> >>> probably they have more "properties" and relationships than you ever >> >>> imagined. Check for example >> >>> http://www.nature.com/msb/journal/v3/n1/fig_tab/msb4100166_F2.html or >> >>> the one from the Human Interactome here >> >>> http://www.blog.republicofmath.com/archives/2005, or >> >>> >> http://www.biomedcentral.com/content/supplementary/1471-2164-9-96-s6.jpeg >> >>> for Gene Ontology "objects". Also PubMed have thousands of related >> >>> papers about real case studies. >> >>> >> >>>> To give an idea, an example would be a set of persons that have >> multiple >> >>>> properties, such as age or function, and have various kinds of >> relationships >> >>>> with other persons. Ideally, it should be something containing some >> more >> >>>> than 5-10 types of entities. >> >>>> >> >>>> Cheers, >> >>>> Doru >> >>>> >> >>>> >> >>>> On 5 Sep 2011, at 02:51, HernÃ¡n Morales Durand wrote: >> >>>> >> >>>>> Hi Tudor, >> >>>>> >> >>>>> I don't know if you want few data sets or many ones, but for each >> case >> >>>>> I found "Selecting genes with dissimilar discrimination strength for >> >>>>> sample class prediction", report case studies in two real cancer >> >>>>> microarray datasets (CAR and LUNG) for gene expression profiling. >> The >> >>>>> Lymphoma case study in humans contains 30 case study genes, you may >> >>>>> read about it in "Examples and Applications of Fuzzy Measure >> >>>>> Similarity Using GO Terms". In general you can find many case >> studies >> >>>>> from SNP data experiments doing all kind of predictions, for example >> >>>>> from protein structure prediction studies that use LiveBench data >> sets >> >>>>> (http://en.wikipedia.org/wiki/LiveBench) search for "Consensus >> fold >> >>>>> recognition by predicting model quality". >> >>>>> If you need more or something more specific just ask :) >> >>>>> Cheers, >> >>>>> >> >>>>> HernÃ¡n >> >>>>> >> >>>>> 2011/9/4 Tudor Girba <tudor(a)tudorgirba.com>: >> >>>>>> Hi, >> >>>>>> >> >>>>>> To show how Moose can support the analysis of various data sets, I >> am >> >>>>>> looking for a case study containing a complex data structure that >> does not >> >>>>>> represent a software system, and a set of questions associated with >> it. >> >>>>>> Ideally, the data should be freely available and it should contain >> a set of >> >>>>>> entities with various properties and various relationships with >> other >> >>>>>> entities. >> >>>>>> >> >>>>>> Anyone has any idea regarding such a case study? >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Doru >> >>>>>> >> >>>>>> -- >> >>>>>> www.tudorgirba.com >> >>>>>> >> >>>>>> "There are no old things, there are only old ways of looking at >> them." >> >>>>>> >> >>>>> >> >>>> >> >>>> -- >> >>>> www.tudorgirba.com >> >>>> >> >>>> "Every successful trip needs a suitable vehicle." >> >>>> >> >>> >> >> >> >> >> > >> > >> > >> > -- >> > Lukas Renggli >> > www.lukas-renggli.ch >> > >> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> >> >> >

Sept. 7, 2011

Re: [Pharo-project] data set

by GastÃ³n Dall' Oglio

Hello. The Wikipedia database? http://en.wikipedia.org/wiki/Wikipedia:Database_download GastÃ³n. 2011/9/6 Tudor Girba <tudor(a)tudorgirba.com> > Thanks everyone for the suggestions. I will try to look into them. > > Cheers, > Doru > > > > On 5 Sep 2011, at 07:04, Lukas Renggli wrote: > > > Stanford has many large graph-like datasets to download: social > > networks, web graphs, peer-to-peer networks, shopping networks, road > > networks, wikipedia networks, etc. > > > > http://snap.stanford.edu/data/ > > > > Lukas > > > > On 5 September 2011 06:24, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> I've used as an example of datamining a dataset about car accidents we > got > >> from here http://www.nhtsa.gov/NASS . > >> > >> Hope it helps :) > >> Guille > >> > >> On Sun, Sep 4, 2011 at 11:58 PM, HernÃ¡n Morales Durand > >> <hernan.morales(a)gmail.com> wrote: > >>> > >>> 2011/9/4 Tudor Girba <tudor(a)tudorgirba.com>: > >>>> Hi, > >>>> > >>>> Thanks, but I am looking for data sets that contained graphs of > entities > >>>> with properties, rather then numbers. > >>>> > >>> > >>> Oh, that was just the top of the iceberg, look at cellular interaction > >>> networks like protein-protein interactions, relations between genes > >>> and QTLs, phylogenetic trees, gene ontology classifications, etc. > >>> probably they have more "properties" and relationships than you ever > >>> imagined. Check for example > >>> http://www.nature.com/msb/journal/v3/n1/fig_tab/msb4100166_F2.html or > >>> the one from the Human Interactome here > >>> http://www.blog.republicofmath.com/archives/2005, or > >>> > http://www.biomedcentral.com/content/supplementary/1471-2164-9-96-s6.jpeg > >>> for Gene Ontology "objects". Also PubMed have thousands of related > >>> papers about real case studies. > >>> > >>>> To give an idea, an example would be a set of persons that have > multiple > >>>> properties, such as age or function, and have various kinds of > relationships > >>>> with other persons. Ideally, it should be something containing some > more > >>>> than 5-10 types of entities. > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>>> On 5 Sep 2011, at 02:51, HernÃ¡n Morales Durand wrote: > >>>> > >>>>> Hi Tudor, > >>>>> > >>>>> I don't know if you want few data sets or many ones, but for each > case > >>>>> I found "Selecting genes with dissimilar discrimination strength for > >>>>> sample class prediction", report case studies in two real cancer > >>>>> microarray datasets (CAR and LUNG) for gene expression profiling. The > >>>>> Lymphoma case study in humans contains 30 case study genes, you may > >>>>> read about it in "Examples and Applications of Fuzzy Measure > >>>>> Similarity Using GO Terms". In general you can find many case studies > >>>>> from SNP data experiments doing all kind of predictions, for example > >>>>> from protein structure prediction studies that use LiveBench data > sets > >>>>> (http://en.wikipedia.org/wiki/LiveBench) search for "Consensus fold > >>>>> recognition by predicting model quality". > >>>>> If you need more or something more specific just ask :) > >>>>> Cheers, > >>>>> > >>>>> HernÃ¡n > >>>>> > >>>>> 2011/9/4 Tudor Girba <tudor(a)tudorgirba.com>: > >>>>>> Hi, > >>>>>> > >>>>>> To show how Moose can support the analysis of various data sets, I > am > >>>>>> looking for a case study containing a complex data structure that > does not > >>>>>> represent a software system, and a set of questions associated with > it. > >>>>>> Ideally, the data should be freely available and it should contain a > set of > >>>>>> entities with various properties and various relationships with > other > >>>>>> entities. > >>>>>> > >>>>>> Anyone has any idea regarding such a case study? > >>>>>> > >>>>>> Cheers, > >>>>>> Doru > >>>>>> > >>>>>> -- > >>>>>> www.tudorgirba.com > >>>>>> > >>>>>> "There are no old things, there are only old ways of looking at > them." > >>>>>> > >>>>> > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> > >>>> "Every successful trip needs a suitable vehicle." > >>>> > >>> > >> > >> > > > > > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > >

Sept. 7, 2011

Re: [Pharo-project] Some bugs

by Michael van der Gulik

On Tue, Sep 6, 2011 at 8:12 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 6 September 2011 07:41, Michael van der Gulik <mikevdg(a)gmail.com> wrote: >> On Tue, Sep 6, 2011 at 12:10 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>> On Sep 5, 2011, at 2:06 PM, Nicolas Cellier wrote: >>>> >>>> By the way, I would find it cool to have an optional byteCode view >>>> parallel to source code view and see the execution of byte codes, and >>>> why not, a view of Context stack frames. >>>> Also, the debugger might step message by message (AST-based) rather >>>> than byteCode by byteCode, is this what you mean by wrong abstraction >>>> level ? >>>> >>> With the wrong abstraction level: Why do we care about stepping bytecodes >>> at all? Why not only have an AST interpreter based debugger? >> >> Because the debugger might be looking at bytecodes that were generated >> by something other than a Smalltalk compiler. >> > > Then AST will serve for that even better, because a single AST node > could be represented by several bytecodes, > and by using a proper AST, Â debugger will know for sure how to step > over single semantic element, written in your language. The bytecodes may not have come from an AST or language. Examples: * Aspect-oriented programming, e.g. automatic logging before and after a method using bytecode injection. * Automatically generated objects, e.g. proxies that filter and send messages to another object. * Hand-crafted bytecodes (for... er... fun) * Compiler bugs - you want the debugger to actually be useful in finding incorrectly generated methods. * Commercial software, with no source code or obfuscated source code, and possibly obfuscated bytecodes if that's somehow possible. My point of view is that the debugger should be debugging bytecodes, and stepping through the original source code is a nice extra feature. This conversation is relevant to me because eventually I'll be making changes to the debugger as well. Michael. -- http://gulik.pbwiki.com/

Sept. 6, 2011

Re: [Pharo-project] Some bugs

by Eliot Miranda

On Tue, Sep 6, 2011 at 2:37 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > On Tue, Sep 6, 2011 at 2:10 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > >> Hi Eliot, >> >> Nicolas' change that we put on the tracker didn't really work as >> intended (Nicolas did you see that?), but i'll let him respond to the >> points he was making. >> >> For me (point #1) It would be better for you to try and tell us the >> classes/methods that are either obviously broken or need the attention >> to get to a series of fixes. >> >> e.g., ignoring the loop highlight for the moment, the pc mapping goes >> wrong right at the start of this example: >> >> toDoOutsideTemp >> | temp collection | >> collection := OrderedCollection new. >> 1 to: 5 do: [ :index | >> temp := index. >> collection add: [ temp ] ]. >> >> by highlighting pc=2 (IIRC) which is the assignment, but the first >> highlight should be pc=3 which is the send of #new. It doesn't >> correctly map/avoid the extra instructions for the array >> initialisation for copying the values outside the block. is it >> possible to fix that first? where do we look? >> > > Well, this works in Squeak. The pc ranges must be determined after > generating the method *with closure analysis*. i.e. the code ranges must be > derived form the same resulting bytecode. To derive 2 for the pc of the > send of new the system I guess must be compiling for source ranges > differently from normal compilation. Haver you compares Squeak to Pharo for > this example? > and then things get better, but not ideal, if the send of startOfLastStatement: is removed from Parser>>statements:innerBlock:blockNode:, i.e. if hereType ~~ #rightBracket ifTrue: [[theBlockNode startOfLastStatement: (start := self startOfNextToken). (returns := self matchReturn) ... becomes hereType ~~ #rightBracket ifTrue: [[start := self startOfNextToken. (returns := self matchReturn) ... I think my confusion was that I wanted to remember in the block node the /end/ of the last statement, not the beginning, and I wasn't thinking at all clearly at the time. Looks like startOfLastStatement in BlockNode should be removed. With the above change the debugger highlights the "to: limit do:", but not the entire block as it would for a non-optimized block. For me, I want the debugger to highlight the entire thing, from to: expr though to the closing ']'. So I think more needs to be done (i.e. note the position of the closing ']' and pass this to the BlockNode). >> I am just wondering how this can be approached in stages if possible. >> i know it is all related at some level. stepping into the code/method >> that does the majority of the pc mapping is a funny experience ;-) >> because the method is structured in such a way to expose a number of >> these bugs. >> >> for point #2 ideally we would not ask for a step and have nothing >> happen. However i wonder if we can get the highlight areas correct, >> even if we have to "step" through hidden parts. This assumes we can >> suppress the highlight for the hidden bits which i think we already >> have...but only if we can do one without the other. I would then >> write tests for the highlights, and we would have some protection for >> further changes. >> > > Right. First thing is to get the source ranges correct. Next thing is to > modify the debugger so that step has a visible effect, i.e. that the > debugger steps until the source range changes. > > >> >> thanks, >> Mike >> >> >> On Mon, Sep 5, 2011 at 5:14 PM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> > Hi Nicolas, >> > that's quite a lot to absorb. Exactly what do you want me to >> review? >> > The first thing it seems to me is to define what we want to be >> highlighted >> > at different bytecodes in an optimized loop. A second thing is to think >> > about how the debugger can avoid stepping through the hidden sends that >> are >> > part of a loop. What I mean is that >> > 1 to: n do: [:i| ....] >> > is actually >> > i := 1. >> > [i <= n] whileTrue: [ >> > and so the debugger steps through i:= 1 and i <= n, even though these >> aren't >> > visible in the source. That's why one has to click several times to get >> > into the body of the loop. The debugger could for example use the >> source >> > ranges for the bytecodes to step until the source range changes. So if >> > there is the same source range info for all the bytecodes involved in >> the >> > loop iteration (not the loop body) the debugger will be able to respond >> to >> > step properly. What do you think? >> > >> > [sorry for not having responded sooner; esug and personal issues have >> got in >> > the way. apologies] >> > On Thu, Aug 25, 2011 at 1:06 PM, Nicolas Cellier >> > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> >> >> A few more notes: >> >> >> >> - Encoder>>rawSourceRanges answer a mapping AST Node -> sourceRange >> >> Gnerally, I would expect sourceRange to be an Interval, but this has >> >> to be confirmed. >> >> Theses ranges are constructed at source code Parse time (see senders >> >> of #noteSourceRange:forNode:) >> >> - The program counters are assigned to AST nodes at byte code #generate >> >> time >> >> - for inlined macros, like #to:do: in our case, this pc is after the >> >> initialize and test statements. >> >> >> >> in CompiledMethod>>#rawSourceRangesAndMethodDo: >> >> I just evaluated this: >> >> >> >> methNode encoder rawSourceRanges collect: [:ival | >> >> sourceText copyFrom: ival first to: ival last] >> >> >> >> And what I see is that the original to:do: message (before macros >> >> inlining) has the right range >> >> {1 >> >> to: 5 >> >> do: [:index | >> >> temp := index. >> >> collection >> >> add: [temp]]}->a Text for 'to: 5 do: [ :index | >> >> temp := index. >> >> collection add: [ temp ] ]' >> >> This node is the original #to:do: and has pc=42 >> >> >> >> There is also >> >> {a LeafNode}->a Text for '[ :index | >> >> temp := index. >> >> collection add: [ temp ] ]' >> >> which has a nil pc so it won't be taken into account in the source map. >> >> >> >> But one of the messages produced by the inlining has this curious >> range: >> >> {index <= 5}->a Text for 'to: 5 do: [ :index | >> >> temp := index. >> >> c' >> >> This node has pc = 40, so it will be selected before the correct one >> >> above has a chance to be. >> >> {index <= 5} is the test statement produced by inlining, and this >> >> seems to be the incorrect highlighting we see. >> >> Thus we know we have to concentrate on macro inlining. >> >> This happens in MessageNode>>transformToDo: >> >> We'll see this. >> >> >> >> In the interim, I played with eliminating the nodes having >> unitilialized >> >> pc >> >> Let us try to evaluate this snippet in debugger's inspector: >> >> (methNode encoder rawSourceRanges keys select: [:e | e pc > 0]) >> >> collect: [:node | >> >> | ival | >> >> ival := methNode encoder rawSourceRanges at: node. >> >> node -> (sourceText copyFrom: ival first to: ival last)] >> >> >> >> Oh god, a bug in the debugger: >> >> DoItIn: homeContext >> >> ^ ((homeContext namedTempAt: 2) encoder rawSourceRanges keys >> >> select: [:e | e pc > 0]) >> >> collect: [:node | >> >> | ival | >> >> ival := (node namedTempAt: 2) encoder >> >> rawSourceRanges at: node. >> >> node >> >> -> (sourceText copyFrom: ival first to: >> >> ival last)] >> >> (node namedTempAt: 2) does not mean a thing... >> >> A confusion occurred between the homeContext (DoItIn: method argument) >> >> and node (the block argument) >> >> Nevermind... forget about it. >> >> >> >> Now let's just concentrate on MessageNode>>transformToDo: >> >> We see this code: >> >> test := MessageNode new >> >> receiver: blockVar >> >> selector: (increment key > 0 ifTrue: >> [#<=] >> >> ifFalse: [#>=]) >> >> arguments: (Array with: limit) >> >> precedence: precedence from: encoder >> >> sourceRange: (myRange first to: >> blockRange >> >> first). >> >> >> >> So the intention seems to select 'to: 5 do: ' >> >> >> >> But we see this: >> >> BlockNode>>noteSourceRangeStart:end:encoder: >> >> "Note two source ranges for this node. One is for the debugger >> >> and is of the last expression, the result of the block. One is >> >> for >> >> source analysis and is for the entire block." >> >> encoder >> >> noteSourceRange: (start to: end) >> >> forNode: self closureCreationNode. >> >> startOfLastStatement >> >> ifNil: >> >> [encoder >> >> noteSourceRange: (start to: end) >> >> forNode: self] >> >> ifNotNil: >> >> [encoder >> >> noteSourceRange: (startOfLastStatement >> to: >> >> end - 1) >> >> forNode: self] >> >> >> >> So it seems intentional to select only the last instruction of the >> >> block for the debugger. >> >> We'd better not change this without prior asking Eliot. >> >> But obviously, this is not what is expected by the #transformToDo: >> >> >> >> Nicolas >> >> >> >> 2011/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> > 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 >> >> >> >> >> > >> >> > >> >> > >> >> >> > >> > >> > >> > -- >> > best, >> > Eliot >> > >> >> > > > -- > best, > Eliot > > -- best, Eliot

Sept. 6, 2011

Re: [Pharo-project] Some bugs

by Eliot Miranda

On Tue, Sep 6, 2011 at 2:10 PM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > Hi Eliot, > > Nicolas' change that we put on the tracker didn't really work as > intended (Nicolas did you see that?), but i'll let him respond to the > points he was making. > > For me (point #1) It would be better for you to try and tell us the > classes/methods that are either obviously broken or need the attention > to get to a series of fixes. > > e.g., ignoring the loop highlight for the moment, the pc mapping goes > wrong right at the start of this example: > > toDoOutsideTemp > | temp collection | > collection := OrderedCollection new. > 1 to: 5 do: [ :index | > temp := index. > collection add: [ temp ] ]. > > by highlighting pc=2 (IIRC) which is the assignment, but the first > highlight should be pc=3 which is the send of #new. It doesn't > correctly map/avoid the extra instructions for the array > initialisation for copying the values outside the block. is it > possible to fix that first? where do we look? > Well, this works in Squeak. The pc ranges must be determined after generating the method *with closure analysis*. i.e. the code ranges must be derived form the same resulting bytecode. To derive 2 for the pc of the send of new the system I guess must be compiling for source ranges differently from normal compilation. Haver you compares Squeak to Pharo for this example? > I am just wondering how this can be approached in stages if possible. > i know it is all related at some level. stepping into the code/method > that does the majority of the pc mapping is a funny experience ;-) > because the method is structured in such a way to expose a number of > these bugs. > > for point #2 ideally we would not ask for a step and have nothing > happen. However i wonder if we can get the highlight areas correct, > even if we have to "step" through hidden parts. This assumes we can > suppress the highlight for the hidden bits which i think we already > have...but only if we can do one without the other. I would then > write tests for the highlights, and we would have some protection for > further changes. > Right. First thing is to get the source ranges correct. Next thing is to modify the debugger so that step has a visible effect, i.e. that the debugger steps until the source range changes. > > thanks, > Mike > > > On Mon, Sep 5, 2011 at 5:14 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Hi Nicolas, > > that's quite a lot to absorb. Exactly what do you want me to review? > > The first thing it seems to me is to define what we want to be > highlighted > > at different bytecodes in an optimized loop. A second thing is to think > > about how the debugger can avoid stepping through the hidden sends that > are > > part of a loop. What I mean is that > > 1 to: n do: [:i| ....] > > is actually > > i := 1. > > [i <= n] whileTrue: [ > > and so the debugger steps through i:= 1 and i <= n, even though these > aren't > > visible in the source. That's why one has to click several times to get > > into the body of the loop. The debugger could for example use the source > > ranges for the bytecodes to step until the source range changes. So if > > there is the same source range info for all the bytecodes involved in the > > loop iteration (not the loop body) the debugger will be able to respond > to > > step properly. What do you think? > > > > [sorry for not having responded sooner; esug and personal issues have got > in > > the way. apologies] > > On Thu, Aug 25, 2011 at 1:06 PM, Nicolas Cellier > > <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> > >> A few more notes: > >> > >> - Encoder>>rawSourceRanges answer a mapping AST Node -> sourceRange > >> Gnerally, I would expect sourceRange to be an Interval, but this has > >> to be confirmed. > >> Theses ranges are constructed at source code Parse time (see senders > >> of #noteSourceRange:forNode:) > >> - The program counters are assigned to AST nodes at byte code #generate > >> time > >> - for inlined macros, like #to:do: in our case, this pc is after the > >> initialize and test statements. > >> > >> in CompiledMethod>>#rawSourceRangesAndMethodDo: > >> I just evaluated this: > >> > >> methNode encoder rawSourceRanges collect: [:ival | > >> sourceText copyFrom: ival first to: ival last] > >> > >> And what I see is that the original to:do: message (before macros > >> inlining) has the right range > >> {1 > >> to: 5 > >> do: [:index | > >> temp := index. > >> collection > >> add: [temp]]}->a Text for 'to: 5 do: [ :index | > >> temp := index. > >> collection add: [ temp ] ]' > >> This node is the original #to:do: and has pc=42 > >> > >> There is also > >> {a LeafNode}->a Text for '[ :index | > >> temp := index. > >> collection add: [ temp ] ]' > >> which has a nil pc so it won't be taken into account in the source map. > >> > >> But one of the messages produced by the inlining has this curious range: > >> {index <= 5}->a Text for 'to: 5 do: [ :index | > >> temp := index. > >> c' > >> This node has pc = 40, so it will be selected before the correct one > >> above has a chance to be. > >> {index <= 5} is the test statement produced by inlining, and this > >> seems to be the incorrect highlighting we see. > >> Thus we know we have to concentrate on macro inlining. > >> This happens in MessageNode>>transformToDo: > >> We'll see this. > >> > >> In the interim, I played with eliminating the nodes having unitilialized > >> pc > >> Let us try to evaluate this snippet in debugger's inspector: > >> (methNode encoder rawSourceRanges keys select: [:e | e pc > 0]) > >> collect: [:node | > >> | ival | > >> ival := methNode encoder rawSourceRanges at: node. > >> node -> (sourceText copyFrom: ival first to: ival last)] > >> > >> Oh god, a bug in the debugger: > >> DoItIn: homeContext > >> ^ ((homeContext namedTempAt: 2) encoder rawSourceRanges keys > >> select: [:e | e pc > 0]) > >> collect: [:node | > >> | ival | > >> ival := (node namedTempAt: 2) encoder > >> rawSourceRanges at: node. > >> node > >> -> (sourceText copyFrom: ival first to: > >> ival last)] > >> (node namedTempAt: 2) does not mean a thing... > >> A confusion occurred between the homeContext (DoItIn: method argument) > >> and node (the block argument) > >> Nevermind... forget about it. > >> > >> Now let's just concentrate on MessageNode>>transformToDo: > >> We see this code: > >> test := MessageNode new > >> receiver: blockVar > >> selector: (increment key > 0 ifTrue: > [#<=] > >> ifFalse: [#>=]) > >> arguments: (Array with: limit) > >> precedence: precedence from: encoder > >> sourceRange: (myRange first to: > blockRange > >> first). > >> > >> So the intention seems to select 'to: 5 do: ' > >> > >> But we see this: > >> BlockNode>>noteSourceRangeStart:end:encoder: > >> "Note two source ranges for this node. One is for the debugger > >> and is of the last expression, the result of the block. One is > >> for > >> source analysis and is for the entire block." > >> encoder > >> noteSourceRange: (start to: end) > >> forNode: self closureCreationNode. > >> startOfLastStatement > >> ifNil: > >> [encoder > >> noteSourceRange: (start to: end) > >> forNode: self] > >> ifNotNil: > >> [encoder > >> noteSourceRange: (startOfLastStatement > to: > >> end - 1) > >> forNode: self] > >> > >> So it seems intentional to select only the last instruction of the > >> block for the debugger. > >> We'd better not change this without prior asking Eliot. > >> But obviously, this is not what is expected by the #transformToDo: > >> > >> Nicolas > >> > >> 2011/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > >> > 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 > >> >> > >> > > >> > > >> > > >> > > > > > > > > -- > > best, > > Eliot > > > > -- best, Eliot

Sept. 6, 2011

Re: [Pharo-project] Some bugs

by Michael Roberts

Hi Eliot, Nicolas' change that we put on the tracker didn't really work as intended (Nicolas did you see that?), but i'll let him respond to the points he was making. For me (point #1) It would be better for you to try and tell us the classes/methods that are either obviously broken or need the attention to get to a series of fixes. e.g., ignoring the loop highlight for the moment, the pc mapping goes wrong right at the start of this example: toDoOutsideTemp | temp collection | collection := OrderedCollection new. 1 to: 5 do: [ :index | temp := index. collection add: [ temp ] ]. by highlighting pc=2 (IIRC) which is the assignment, but the first highlight should be pc=3 which is the send of #new. It doesn't correctly map/avoid the extra instructions for the array initialisation for copying the values outside the block. is it possible to fix that first? where do we look? I am just wondering how this can be approached in stages if possible. i know it is all related at some level. stepping into the code/method that does the majority of the pc mapping is a funny experience ;-) because the method is structured in such a way to expose a number of these bugs. for point #2 ideally we would not ask for a step and have nothing happen. However i wonder if we can get the highlight areas correct, even if we have to "step" through hidden parts. This assumes we can suppress the highlight for the hidden bits which i think we already have...but only if we can do one without the other. I would then write tests for the highlights, and we would have some protection for further changes. thanks, Mike On Mon, Sep 5, 2011 at 5:14 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Nicolas, > Â Â that's quite a lot to absorb. Â Exactly what do you want me to review? > Â The first thing it seems to me is to define what we want to be highlighted > at different bytecodes in an optimized loop. Â A second thing is to think > about how the debugger can avoid stepping through the hidden sends that are > part of a loop. Â What I mean is that > Â Â 1 to: n do: [:i| ....] > is actually > Â Â Â i := 1. > Â Â Â [i <= n] whileTrue: [ > and so the debugger steps through i:= 1 and i <= n, even though these aren't > visible in the source. Â That's why one has to click several times to get > into the body of the loop. Â The debugger could for example use the source > ranges for the bytecodes to step until the source range changes. Â So if > there is the same source range info for all the bytecodes involved in the > loop iteration (not the loop body) the debugger will be able to respond to > step properly. Â What do you think? > > [sorry for not having responded sooner; esug and personal issues have got in > the way. apologies] > On Thu, Aug 25, 2011 at 1:06 PM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> A few more notes: >> >> - Encoder>>rawSourceRanges answer a mapping AST Node -> sourceRange >> Â Gnerally, I would expect sourceRange to be an Interval, but this has >> to be confirmed. >> Â Theses ranges are constructed at source code Parse time (see senders >> of #noteSourceRange:forNode:) >> - The program counters are assigned to AST nodes at byte code #generate >> time >> - for inlined macros, like #to:do: in our case, this pc is after the >> initialize and test statements. >> >> in CompiledMethod>>#rawSourceRangesAndMethodDo: >> I just evaluated this: >> >> methNode encoder rawSourceRanges collect: [:ival | >> Â Â Â Â sourceText copyFrom: ival first to: ival last] >> >> And what I see is that the original to:do: message (before macros >> inlining) has the right range >> {1 >> Â Â Â Â to: 5 >> Â Â Â Â do: [:index | >> Â Â Â Â Â Â Â Â temp := index. >> Â Â Â Â Â Â Â Â collection >> Â Â Â Â Â Â Â Â Â Â Â Â add: [temp]]}->a Text for 'to: 5 do: [ :index | >> Â Â Â Â Â Â Â Â temp := index. >> Â Â Â Â Â Â Â Â collection add: [ temp ] ]' >> This node is the original #to:do: and has pc=42 >> >> There is also >> {a LeafNode}->a Text for '[ :index | >> Â Â Â Â Â Â Â Â temp := index. >> Â Â Â Â Â Â Â Â collection add: [ temp ] ]' >> which has a nil pc so it won't be taken into account in the source map. >> >> But one of the messages produced by the inlining has this curious range: >> {index <= 5}->a Text for 'to: 5 do: [ :index | >> Â Â Â Â Â Â Â Â temp := index. >> Â Â Â Â Â Â Â Â c' >> This node has pc = 40, so it will be selected before the correct one >> above has a chance to be. >> {index <= 5} is the test statement produced by inlining, and this >> seems to be the incorrect highlighting we see. >> Thus we know we have to concentrate on macro inlining. >> This happens in MessageNode>>transformToDo: >> We'll see this. >> >> In the interim, I played with eliminating the nodes having unitilialized >> pc >> Let us try to evaluate this snippet in debugger's inspector: >> (methNode encoder rawSourceRanges keys select: [:e | e pc > 0]) >> collect: [:node | >> Â Â Â Â | ival | >> Â Â Â Â ival := methNode encoder rawSourceRanges at: node. >> Â Â Â Â node -> (sourceText copyFrom: ival first to: ival last)] >> >> Oh god, a bug in the debugger: >> DoItIn: homeContext >> Â Â Â Â ^ ((homeContext namedTempAt: 2) encoder rawSourceRanges keys >> Â Â Â Â Â Â Â Â select: [:e | e pc > 0]) >> Â Â Â Â Â Â Â Â collect: [:node | >> Â Â Â Â Â Â Â Â Â Â Â Â | ival | >> Â Â Â Â Â Â Â Â Â Â Â Â ival := (node namedTempAt: 2) encoder >> rawSourceRanges at: node. >> Â Â Â Â Â Â Â Â Â Â Â Â node >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â -> (sourceText copyFrom: ival first to: >> ival last)] >> (node namedTempAt: 2) does not mean a thing... >> A confusion occurred between the homeContext (DoItIn: method argument) >> and node (the block argument) >> Nevermind... forget about it. >> >> Now let's just concentrate on MessageNode>>transformToDo: >> We see this code: >> Â Â Â Â test := MessageNode new >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â receiver: blockVar >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â selector: (increment key > 0 ifTrue: [#<=] >> ifFalse: [#>=]) >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â arguments: (Array with: limit) >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â precedence: precedence from: encoder >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â sourceRange: (myRange first to: blockRange >> first). >> >> So the intention seems to select 'to: 5 do: ' >> >> But we see this: >> BlockNode>>noteSourceRangeStart:end:encoder: >> Â Â Â Â "Note two source ranges for this node. Â One is for the debugger >> Â Â Â Â and is of the last expression, the result of the block. Â One is >> for >> Â Â Â Â source analysis and is for the entire block." >> Â Â Â Â encoder >> Â Â Â Â Â Â Â Â noteSourceRange: (start to: end) >> Â Â Â Â Â Â Â Â forNode: self closureCreationNode. >> Â Â Â Â startOfLastStatement >> Â Â Â Â Â Â Â Â ifNil: >> Â Â Â Â Â Â Â Â Â Â Â Â [encoder >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â noteSourceRange: (start to: end) >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â forNode: self] >> Â Â Â Â Â Â Â Â ifNotNil: >> Â Â Â Â Â Â Â Â Â Â Â Â [encoder >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â noteSourceRange: (startOfLastStatement to: >> end - 1) >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â forNode: self] >> >> So it seems intentional to select only the last instruction of the >> block for the debugger. >> We'd better not change this without prior asking Eliot. >> But obviously, this is not what is expected by the #transformToDo: >> >> Nicolas >> >> 2011/8/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> > 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 >> >> >> > >> > >> > >> > > > > -- > best, > Eliot >

Sept. 6, 2011

Re: [Pharo-project] ProfStef port

by Michael Roberts

this is brilliant!... one tiny thing i noticed on page 22/24 if you print the method source, the editor highlight only covers the first line of the multi-line output. Perhaps it only ever expects single line highlights. cheers, Mike On Tue, Sep 6, 2011 at 9:27 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Funny, Bernat and Nicolas have written a port of ProfStef to > JTalk:Â http://jtalk-project.org/learn.html > Laurent >

Sept. 6, 2011

[Pharo-project] ProfStef port

by laurent laffont

Funny, Bernat and Nicolas have written a port of ProfStef to JTalk: http://jtalk-project.org/learn.html Laurent

Sept. 6, 2011