- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Filesystem in collab book

by Alexandre Bergel

Ok, we will go through it. Alexandre On 26 Aug 2011, at 10:11, Max Leske wrote: > Haha! :) > > All a misunderstanding. > > I already made the pass and submitted a pull request. > > You had written: >>>>>> Max did you see the chapter in the new pharo book on git? > > which I interpreted as: "there's a chapter about 'Git' in the new PBE". > > Sorry for the confusion. Everything's fine now. > > Cheers, > Max > > > On 26.08.2011, at 11:04, StÃ©phane Ducasse wrote: > >> Pharo by example on github >> Sorry git is alienating me so I do not know how to do the equivalent of svn info (I'm too stupid). >> >> <FileSystem.pdf> >> >> here is the current status of the chapter. >> >> Stef >> >> On Aug 26, 2011, at 9:58 AM, Max Leske wrote: >> >>> Again, what about that Git chapter? >>> >>> Max >>> >>> >>> On 26.08.2011, at 09:03, StÃ©phane Ducasse wrote: >>> >>>> Thanks a lot for that max >>>> >>>> Stef >>>> >>>> On Aug 26, 2011, at 6:47 AM, Max Leske wrote: >>>> >>>>> No, I wasn't aware of that chapter. I'll do a pass on it and also on the Filesystem chapter (Camillo's changes should be reflected), which I originally wanted to do months agoâ¦ >>>>> >>>>> I should be done by next week. >>>>> >>>>> Max >>>>> >>>>> >>>>> On 25.08.2011, at 22:32, StÃ©phane Ducasse wrote: >>>>> >>>>>> Thanks. >>>>>> >>>>>> Max did you see the chapter in the new pharo book on git? >>>>>> Because I should do a pass on it but anybody is welcome. >>>>>> >>>>>> Stef >>>>>> >>>>>> On Aug 25, 2011, at 8:38 PM, Max Leske wrote: >>>>>> >>>>>>> I wrote a few lines on Filesystem in the collab book: http://book.pharo-project.org/book/PharoTools/Filesystem/ >>>>>>> >>>>>>> Please take a look and let me know if you'd like to see any changes. >>>>>>> >>>>>>> Cheers, >>>>>>> Max >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 26, 2011

Re: [Pharo-project] Filesystem in collab book

by Max Leske

Haha! :) All a misunderstanding. I already made the pass and submitted a pull request. You had written: >>>>> Max did you see the chapter in the new pharo book on git? which I interpreted as: "there's a chapter about 'Git' in the new PBE". Sorry for the confusion. Everything's fine now. Cheers, Max On 26.08.2011, at 11:04, StÃ©phane Ducasse wrote: > Pharo by example on github > Sorry git is alienating me so I do not know how to do the equivalent of svn info (I'm too stupid). > > <FileSystem.pdf> > > here is the current status of the chapter. > > Stef > > On Aug 26, 2011, at 9:58 AM, Max Leske wrote: > >> Again, what about that Git chapter? >> >> Max >> >> >> On 26.08.2011, at 09:03, StÃ©phane Ducasse wrote: >> >>> Thanks a lot for that max >>> >>> Stef >>> >>> On Aug 26, 2011, at 6:47 AM, Max Leske wrote: >>> >>>> No, I wasn't aware of that chapter. I'll do a pass on it and also on the Filesystem chapter (Camillo's changes should be reflected), which I originally wanted to do months agoâ¦ >>>> >>>> I should be done by next week. >>>> >>>> Max >>>> >>>> >>>> On 25.08.2011, at 22:32, StÃ©phane Ducasse wrote: >>>> >>>>> Thanks. >>>>> >>>>> Max did you see the chapter in the new pharo book on git? >>>>> Because I should do a pass on it but anybody is welcome. >>>>> >>>>> Stef >>>>> >>>>> On Aug 25, 2011, at 8:38 PM, Max Leske wrote: >>>>> >>>>>> I wrote a few lines on Filesystem in the collab book: http://book.pharo-project.org/book/PharoTools/Filesystem/ >>>>>> >>>>>> Please take a look and let me know if you'd like to see any changes. >>>>>> >>>>>> Cheers, >>>>>> Max >>>>> >>>>> >>>> >>>> >>> >>> >> >> >

Aug. 26, 2011

Re: [Pharo-project] Filesystem in collab book

by StÃ©phane Ducasse

Pharo by example on github Sorry git is alienating me so I do not know how to do the equivalent of svn info (I'm too stupid). here is the current status of the chapter. Stef On Aug 26, 2011, at 9:58 AM, Max Leske wrote: > Again, what about that Git chapter? > > Max > > > On 26.08.2011, at 09:03, StÃ©phane Ducasse wrote: > >> Thanks a lot for that max >> >> Stef >> >> On Aug 26, 2011, at 6:47 AM, Max Leske wrote: >> >>> No, I wasn't aware of that chapter. I'll do a pass on it and also on the Filesystem chapter (Camillo's changes should be reflected), which I originally wanted to do months agoâ¦ >>> >>> I should be done by next week. >>> >>> Max >>> >>> >>> On 25.08.2011, at 22:32, StÃ©phane Ducasse wrote: >>> >>>> Thanks. >>>> >>>> Max did you see the chapter in the new pharo book on git? >>>> Because I should do a pass on it but anybody is welcome. >>>> >>>> Stef >>>> >>>> On Aug 25, 2011, at 8:38 PM, Max Leske wrote: >>>> >>>>> I wrote a few lines on Filesystem in the collab book: http://book.pharo-project.org/book/PharoTools/Filesystem/ >>>>> >>>>> Please take a look and let me know if you'd like to see any changes. >>>>> >>>>> Cheers, >>>>> Max >>>> >>>> >>> >>> >> >> > >

Aug. 26, 2011

Re: [Pharo-project] Filesystem in collab book

by Max Leske

Again, what about that Git chapter? Max On 26.08.2011, at 09:03, StÃ©phane Ducasse wrote: > Thanks a lot for that max > > Stef > > On Aug 26, 2011, at 6:47 AM, Max Leske wrote: > >> No, I wasn't aware of that chapter. I'll do a pass on it and also on the Filesystem chapter (Camillo's changes should be reflected), which I originally wanted to do months agoâ¦ >> >> I should be done by next week. >> >> Max >> >> >> On 25.08.2011, at 22:32, StÃ©phane Ducasse wrote: >> >>> Thanks. >>> >>> Max did you see the chapter in the new pharo book on git? >>> Because I should do a pass on it but anybody is welcome. >>> >>> Stef >>> >>> On Aug 25, 2011, at 8:38 PM, Max Leske wrote: >>> >>>> I wrote a few lines on Filesystem in the collab book: http://book.pharo-project.org/book/PharoTools/Filesystem/ >>>> >>>> Please take a look and let me know if you'd like to see any changes. >>>> >>>> Cheers, >>>> Max >>> >>> >> >> > >

Aug. 26, 2011

Re: [Pharo-project] [Vm-dev] Cog in Jenkis has brokken finalization

by Mariano Martinez Peck

On Thu, Aug 25, 2011 at 5:40 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Aug 25, 2011, at 5:34 PM, Igor Stasenko wrote: > > > On 25 August 2011 14:38, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > >> > >> Hi guys. The linux Cog VM from hudson has broken the finalization. Just > run the WeakRegistryTest and you will see the broken test. It might > happened because of the ephemerons because Eliot's VM works correctly. > >> Even more, the VM from Jenkis is correct. So....I would remove the > broken one from Hudson. > >> > > > > I migrated unix and windows VM jobs to Jenkins. > > Please use VMs built on Jenkins servers. > > > > Can we delete the Hudson projects? Just to avoid confusion? > > That was all my email about in fact > -- > Marcus Denker -- http://marcusdenker.de > > > -- Mariano http://marianopeck.wordpress.com

Aug. 26, 2011

Re: [Pharo-project] Some bugs

by Michael Roberts

Hi the loop looks much better, but the first assignment (which was not in the original TestCase btw, it is just a side effect of the way i wrote my test) is still wrong. I think this is because it needs to start at pc 3 (?) rather than 2. I have attached my little analyser to the issue. I will post it in task forces or somewhere when it is cleaned a little. Usage DebuggerAnalyser inspectOn: #toDoOutsideTemp. This opens a debugger and an inspector. It positions the debugger at the method under 'analysis'. At the moment the methods are hard coded in the class itself, but it would not be hard to be more general. There is also the code in there to do this for arbitrary doits, but i have not wired this up yet. This class was originally a large script..... You can also do a trace: DebuggerAnalyser new traceSelector: #toDoOutsideTemp . I plan to use this class eventually for regression testing the debugger. So we will run tests that trace exact highlight sequences in Jenkins. Also there is a little text morph for visualising highlight intervals self openAnalysisText and then you can poke highlights via analysisHighlight: (3 to: 6) If you have the analyser open in one area, and then do things like (DebuggerAnalyser>>#basicAssignment) methodNode rawSourceRanges. in a separate debugger, then you can get the highlight points and 'visualise' what is going on at various stages of the machinery. Hope you get the idea, if this is useful... cheers, Mike On Fri, Aug 26, 2011 at 9:00 AM, Michael Roberts <mike(a)mjr104.co.uk> wrote: > I will try it in my image, thanks! > > I got a little further with Andres. The thing about the loop example is > that the block is copying values outside its scope. You get get extra > bytecodes at the start of the method (Array new: ...) and extra bytecodes in > the loop to do the copying of values. We suspect that the mapping is getting > confused by this. This is because the encoder hands out the ranges of the > original method correctly, but the mapping has to align the pc to ignore > these bytecodes because they are not in the debugger source. Anyway that was > our impression. I agree we need Eliot to review. > > cheers, > Mike > > > On Thu, Aug 25, 2011 at 9:43 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> thanks a lot nicolas >> It seems to work on my image too. I adding it to the bug entry. >> What is great is that tomorrow I will be able to follow your path in the >> train. >> >> Stef >> On Aug 25, 2011, at 9:12 PM, Nicolas Cellier wrote: >> >> > And by changing last line of this piece of code in #transformToDo: >> > test := MessageNode new >> > receiver: blockVar >> > selector: (increment key > 0 ifTrue: >> > [#<=] ifFalse: [#>=]) >> > arguments: (Array with: limit) >> > precedence: precedence from: encoder >> > sourceRange: (myRange first to: blockRange >> last). >> > I get a "correct" selection... >> > >> > Nicolas >> > >> > >> > 2011/8/25 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> >> 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 >> >>>> >> >>> >> >>> >> >>> >> >> >> > >> >> >> >

Aug. 26, 2011

[Pharo-project] CI down?

by Pavel Krivanek

The CI server https://ci.lille.inria.fr/pharo/ is not responding. Is it down? -- Pavel

Aug. 26, 2011

Re: [Pharo-project] Some bugs

by Michael Roberts

I will try it in my image, thanks! I got a little further with Andres. The thing about the loop example is that the block is copying values outside its scope. You get get extra bytecodes at the start of the method (Array new: ...) and extra bytecodes in the loop to do the copying of values. We suspect that the mapping is getting confused by this. This is because the encoder hands out the ranges of the original method correctly, but the mapping has to align the pc to ignore these bytecodes because they are not in the debugger source. Anyway that was our impression. I agree we need Eliot to review. cheers, Mike On Thu, Aug 25, 2011 at 9:43 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > thanks a lot nicolas > It seems to work on my image too. I adding it to the bug entry. > What is great is that tomorrow I will be able to follow your path in the > train. > > Stef > On Aug 25, 2011, at 9:12 PM, Nicolas Cellier wrote: > > > And by changing last line of this piece of code in #transformToDo: > > test := MessageNode new > > receiver: blockVar > > selector: (increment key > 0 ifTrue: > > [#<=] ifFalse: [#>=]) > > arguments: (Array with: limit) > > precedence: precedence from: encoder > > sourceRange: (myRange first to: blockRange > last). > > I get a "correct" selection... > > > > Nicolas > > > > > > 2011/8/25 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > >> 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 > >>>> > >>> > >>> > >>> > >> > > > > >

Aug. 26, 2011

[Pharo-project] squeaksource down

by Max Leske

Since squeaksource is down againâ¦ Does it make sense to move my own projects to ss3.gemstone.com/ss? Max

Aug. 26, 2011

Re: [Pharo-project] Filesystem in collab book

by StÃ©phane Ducasse

Thanks a lot for that max Stef On Aug 26, 2011, at 6:47 AM, Max Leske wrote: > No, I wasn't aware of that chapter. I'll do a pass on it and also on the Filesystem chapter (Camillo's changes should be reflected), which I originally wanted to do months agoâ¦ > > I should be done by next week. > > Max > > > On 25.08.2011, at 22:32, StÃ©phane Ducasse wrote: > >> Thanks. >> >> Max did you see the chapter in the new pharo book on git? >> Because I should do a pass on it but anybody is welcome. >> >> Stef >> >> On Aug 25, 2011, at 8:38 PM, Max Leske wrote: >> >>> I wrote a few lines on Filesystem in the collab book: http://book.pharo-project.org/book/PharoTools/Filesystem/ >>> >>> Please take a look and let me know if you'd like to see any changes. >>> >>> Cheers, >>> Max >> >> > >

Aug. 26, 2011