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

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Ben Coman

On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez < thomas.dupriez(a)ens-paris-saclay.fr> wrote: > I dug a bit in this issue. Here are the results: > > > # Problem raised by Stephanne > Code like the following is open in the debugger: > > `myMethod > 1+1. <PROGRAMCOUNTER> > MyClass new myEvalBlock: [ > 2+2. <CURSOR> > ]. > 3+3.` > > The program counter is on the 1+1, the cursor is at the end of the 2+2 > line. > Right-click, "Run to here". > -> the program counter moves to the 3+3, and does not stop at the 2+2 > (where the cursor is). Even though the 2+2 does get evaluated (the > myEvalBlock method evaluates the blocks it receives). > If there was no code after the block, the debugger would jump back to the > caller of myMethod. > > # Why this happens > The implementation of RunToHere (source code below) is basically to > stepOver until the context is different or the source code position of the > program counter is higher or equal to the source code position of the > cursor/selection. > > Since the debugger uses stepOver, it executes myEvalBlock without > stopping, reaches the 3+3 and see it has gone further than the source code > position of the cursorm so it stops. > > Source code of DebugSession>>#runToSelection:inContext: > > `runToSelection: selectionInterval inContext: aContext > "Attempt to step over instructions in selectedContext until the > execution reaches the selected instruction. This happens when the > program counter passes the begining of selectionInterval. > > A not nill and valid interval is expected." > > (self pcRangeForContext: aContext) first >= selectionInterval first > ifTrue: [ ^self ]. > self stepOver: aContext. > [ aContext == self interruptedContext and: [ (self > pcRangeForContext: aContext) first < selectionInterval first ] ] > whileTrue: [ self stepOver: aContext ]` > > # Observations and thoughts > - Replacing the stepOver with a stepInto -> This made the RunToHere stops > when resolving the 'new' message (because the context changes). > Thanks for looking into this Thomas. What happens if you use stepThrough rather than stepInto? cheers -ben > > - Replacing the stepOver with stepInto and removing the equal condition on > contexts -> The RunToHere goes to the 3+3. Looking at the source code > position of the program counter, it doesn't enter the block and seems to > resolve it in a single step. I don't really get why that is, considering > using the stepInto button of the debugger does enter the block. Here is the > series of source code positions of the program counter during the > RunToHere: (21 to: 22)(34 to: 36)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: > 60)(65 to: 66). > However, removing the equal condition on contexts means that if the method > call returns before reaching the cursor, it won't stop! > > - An idea could be to have the RunToHere place a metalink on the selected > node and let the execution run until it hits the metalink, which then > updates the debugger. Potential problems are that it implies installing a > metalink on a method that is already on the stack, which may not be that > easy to do properly (in particular, it affects the program counter since it > changes the bytecode), and there is the potential case where the metalink > is never reached (for example imagine the myEvalBlock: method of my example > is just storing the block and not evaluating it). > > > Cheers, > Thomas > > > > Le 09/11/2017 Ã 22:06, Stephane Ducasse a Ã©crit : > >> Agreed. Thomas? It would be a good bone to ... (Un bon os a ronger) . >> >> Stef >> >> On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> The basic tools, such as debugger, are expected to work. If something >>> does not work, itâs a bug. >>> >>> Cheers, >>> Doru >>> >>> >>> On Nov 8, 2017, at 11:59 PM, Tim Mackinnon <tim(a)testit.works> wrote: >>>> >>>> I think it's broken in Pharo 6 too, as I often find it unreliable. >>>> >>>> It's hard to know what should work anymore - we really need a >>>> stabilisation release to let the dust settle. >>>> >>>> I'm always a bit reticent to report things as I'm not sure what you >>>> expect to work. >>>> >>>> Tim >>>> >>>> Sent from my iPhone >>>> >>>> On 8 Nov 2017, at 20:40, Stephane Ducasse <stepharo.self(a)gmail.com> >>>>> wrote: >>>>> >>>>> Hi >>>>> >>>>> I have the following method and I have my cursor -MY CURSOR HERE- >>>>> I select the menu run to here and .... I exit the method. >>>>> :( >>>>> >>>>> Is run to here working in Pharo 70? >>>>> I start to get worry about the number of bugs I get when using Pharo70. >>>>> >>>>> Stef >>>>> >>>>> >>>>> fileOut >>>>> "File out the receiver, to a file whose name is a function of the >>>>> change-set name and a unique numeric tag." >>>>> >>>>> | nameToUse | >>>>> self halt. >>>>> self class promptForDefaultChangeSetDirectoryIfNecessary. >>>>> nameToUse := (self defaultChangeSetDirectory / self name , 'cs') >>>>> nextVersion basename. >>>>> UIManager default >>>>> showWaitCursorWhile: >>>>> [ >>>>> | internalStream | >>>>> internalStream := (String new: 10000) writeStream. >>>>> >>>>> -MY CURSOR HERE- >>>>> >>>>> internalStream >>>>> header; >>>>> timeStamp. >>>>> self fileOutPreambleOn: internalStream. >>>>> self fileOutOn: internalStream. >>>>> self fileOutPostscriptOn: internalStream. >>>>> CodeExporter >>>>> writeSourceCodeFrom: internalStream >>>>> baseName: (nameToUse copyFrom: 1 to: nameToUse size - 3) >>>>> isSt: false ] >>>>> >>>>> >>>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Value is always contextual." >>> >>> >>> >>> >>> >>> > >

Nov. 13, 2017

Re: [Pharo-dev] [Debugger] Is "run to here" broken?

by Thomas Dupriez

I dug a bit in this issue. Here are the results: # Problem raised by Stephanne Code like the following is open in the debugger: Â Â Â `myMethod Â Â Â Â Â Â 1+1. <PROGRAMCOUNTER> Â Â Â Â Â Â MyClass new myEvalBlock: [ Â Â Â Â Â Â Â Â Â 2+2. <CURSOR> Â Â Â Â Â Â ]. Â Â Â Â Â Â 3+3.` The program counter is on the 1+1, the cursor is at the end of the 2+2 line. Right-click, "Run to here". -> the program counter moves to the 3+3, and does not stop at the 2+2 (where the cursor is). Even though the 2+2 does get evaluated (the myEvalBlock method evaluates the blocks it receives). If there was no code after the block, the debugger would jump back to the caller of myMethod. # Why this happens The implementation of RunToHere (source code below) is basically to stepOver until the context is different or the source code position of the program counter is higher or equal to the source code position of the cursor/selection. Since the debugger uses stepOver, it executes myEvalBlock without stopping, reaches the 3+3 and see it has gone further than the source code position of the cursorm so it stops. Source code of DebugSession>>#runToSelection:inContext: Â Â Â `runToSelection: selectionInterval inContext: aContext Â Â Â Â Â Â "Attempt to step over instructions in selectedContext until the Â Â Â Â Â Â execution reaches the selected instruction. This happens when the Â Â Â Â Â Â program counter passes the begining of selectionInterval. Â Â Â Â Â Â A not nill and valid interval is expected." Â Â Â Â Â Â (self pcRangeForContext: aContext) first >= selectionInterval first Â Â Â Â Â Â Â Â Â ifTrue: [ ^self ]. Â Â Â Â Â Â self stepOver: aContext. Â Â Â Â Â Â [ aContext == self interruptedContext and: [ (self pcRangeForContext: aContext) first < selectionInterval first ] ] Â Â Â Â Â Â Â Â Â whileTrue: [ self stepOver: aContext ]` # Observations and thoughts - Replacing the stepOver with a stepInto -> This made the RunToHere stops when resolving the 'new' message (because the context changes). - Replacing the stepOver with stepInto and removing the equal condition on contexts -> The RunToHere goes to the 3+3. Looking at the source code position of the program counter, it doesn't enter the block and seems to resolve it in a single step. I don't really get why that is, considering using the stepInto button of the debugger does enter the block. Here is the series of source code positions of the program counter during the RunToHere: (21 to: 22)(34 to: 36)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60)(65 to: 66). However, removing the equal condition on contexts means that if the method call returns before reaching the cursor, it won't stop! - An idea could be to have the RunToHere place a metalink on the selected node and let the execution run until it hits the metalink, which then updates the debugger. Potential problems are that it implies installing a metalink on a method that is already on the stack, which may not be that easy to do properly (in particular, it affects the program counter since it changes the bytecode), and there is the potential case where the metalink is never reached (for example imagine the myEvalBlock: method of my example is just storing the block and not evaluating it). Cheers, Thomas Le 09/11/2017 Ã 22:06, Stephane Ducasse a Ã©critÂ : > Agreed. Thomas? It would be a good bone to ... (Un bon os a ronger) . > > Stef > > On Thu, Nov 9, 2017 at 4:32 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> The basic tools, such as debugger, are expected to work. If something does not work, itâs a bug. >> >> Cheers, >> Doru >> >> >>> On Nov 8, 2017, at 11:59 PM, Tim Mackinnon <tim(a)testit.works> wrote: >>> >>> I think it's broken in Pharo 6 too, as I often find it unreliable. >>> >>> It's hard to know what should work anymore - we really need a stabilisation release to let the dust settle. >>> >>> I'm always a bit reticent to report things as I'm not sure what you expect to work. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>>> On 8 Nov 2017, at 20:40, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>> Hi >>>> >>>> I have the following method and I have my cursor -MY CURSOR HERE- >>>> I select the menu run to here and .... I exit the method. >>>> :( >>>> >>>> Is run to here working in Pharo 70? >>>> I start to get worry about the number of bugs I get when using Pharo70. >>>> >>>> Stef >>>> >>>> >>>> fileOut >>>> "File out the receiver, to a file whose name is a function of the >>>> change-set name and a unique numeric tag." >>>> >>>> | nameToUse | >>>> self halt. >>>> self class promptForDefaultChangeSetDirectoryIfNecessary. >>>> nameToUse := (self defaultChangeSetDirectory / self name , 'cs') >>>> nextVersion basename. >>>> UIManager default >>>> showWaitCursorWhile: >>>> [ >>>> | internalStream | >>>> internalStream := (String new: 10000) writeStream. >>>> >>>> -MY CURSOR HERE- >>>> >>>> internalStream >>>> header; >>>> timeStamp. >>>> self fileOutPreambleOn: internalStream. >>>> self fileOutOn: internalStream. >>>> self fileOutPostscriptOn: internalStream. >>>> CodeExporter >>>> writeSourceCodeFrom: internalStream >>>> baseName: (nameToUse copyFrom: 1 to: nameToUse size - 3) >>>> isSt: false ] >>>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Value is always contextual." >> >> >> >> >>

Nov. 13, 2017

[Pharo 7.0-dev] Build #289: 20676 Categorize uncategorized methods in classes starting with K

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #289 was: SUCCESS. The Pull Request #470 was integrated: "20676 Categorize uncategorized methods in classes starting with K" Pull request url: https://github.com/pharo-project/pharo/pull/470 Issue Url: https://pharo.fogbugz.com/f/cases/20676 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2017

[Pharo 7.0-dev] Build #288: 20674 Categorize uncategorized methods in classes starting with J

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #288 was: SUCCESS. The Pull Request #468 was integrated: "20674 Categorize uncategorized methods in classes starting with J" Pull request url: https://github.com/pharo-project/pharo/pull/468 Issue Url: https://pharo.fogbugz.com/f/cases/20674 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2017

[Pharo 7.0-dev] Build #287: 20677-Improve-system-dependencies-tests

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #287 was: SUCCESS. The Pull Request #472 was integrated: "20677-Improve-system-dependencies-tests" Pull request url: https://github.com/pharo-project/pharo/pull/472 Issue Url: https://pharo.fogbugz.com/f/cases/20677 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 13, 2017

Iceberg pull request tool is broken

by Stephane Ducasse

https://github.com/pharo-vcs/iceberg/issues/515

Nov. 13, 2017

Esteban's ChangeLog week of 6 November 2017

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 6 November 2017 to 12 November 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=6/11/2017&to=12/11/2017 ChangeLog ========= 5 November 2017: ---------------- * I spent the full week working on the conversion to tonel, which is not working. So I can say "mission accomplished" ;) Please notice that for properly use Pharo7.0a with tonel you should: * update/sync your clone and fork * download a new Pharo7.0a image Next week I'm on holidays and on Smalltalks conf so you will not hear much, but right after I will work on simplify the contribution process (make it more coherent at least) and improvements to speed up Iceberg a bit more. cheers! Esteban

Nov. 13, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Esteban Lorenzano

When working with git (and iceberg) you do not add two repos (one original, one yours). What you do in git is to add your fork as a âremoteâ (in iceberg is in remotes tab). So you have one repo and you push/pull from different remotes as needed. Esteban > On 12 Nov 2017, at 16:59, Todd Blanchard <tblanchard(a)mac.com> wrote: > > It seems like there ought to be a way to install a package from a github repo without typing scripts? > > I'm going to make changes so I forked Estaban's repo and entered that into iceberg browser. The iceberg UI, BTW, does not show a way to distinguish between different forks so both just say libclang-pharo-bindings and I can't tell one from another. > > I had to delete everything, download yet another fresh copy of Pharo, and start again from scratch. > > I'm really struggling to understand the relationship between metacello and iceberg. I've been a happy git user for many years but this still feels very foreign to me. > >> On Nov 12, 2017, at 11:22 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> If I execute the metacello command in the screenshot I can see 5 >> packages in the list. >

Nov. 12, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Todd Blanchard

It seems like there ought to be a way to install a package from a github repo without typing scripts? I'm going to make changes so I forked Estaban's repo and entered that into iceberg browser. The iceberg UI, BTW, does not show a way to distinguish between different forks so both just say libclang-pharo-bindings and I can't tell one from another. I had to delete everything, download yet another fresh copy of Pharo, and start again from scratch. I'm really struggling to understand the relationship between metacello and iceberg. I've been a happy git user for many years but this still feels very foreign to me. > On Nov 12, 2017, at 11:22 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > If I execute the metacello command in the screenshot I can see 5 > packages in the list.

Nov. 12, 2017

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Todd Blanchard

Yes, that worked. Thanks. > On Nov 12, 2017, at 11:22 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Todd, > > On 12 November 2017 at 17:57, Todd Blanchard <tblanchard(a)mac.com> wrote: >> Hi Alistair, >> >> THANK YOU! This cleared up a lot and I didn't know where to go to read all >> that stuff. Seems I just had to check "Use Custom SSH Keys" and I was good. >> >> I think probably opening that panel on auth error would be a nice >> enhancement (and once I figure out iceberg I'll submit a pull request that >> does just that). >> >> So I cloned the repository...but I don't see how to load it into my image - >> no packages are shown. I should find 'BaselineOfLibClang' somewhere, yes? > > Was this resolved by: > > Iceberg enableMetacelloIntegration: true. > > > If I execute the metacello command in the screenshot I can see 5 > packages in the list. > > Cheers, > Alistair > > > > >> On Nov 12, 2017, at 8:18 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Todd, >> >> On 12 November 2017 at 17:00, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> And how do I do this? I can fetch the repo from the command line >> >> >> Take a look at the FAQ in the Iceberg readme: >> https://github.com/pharo-vcs/iceberg >> >> >> Sent from the road >> >> On Nov 12, 2017, at 05:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> >> On 11 Nov 2017, at 17:43, Todd Blanchard <tblanchard(a)mac.com> wrote: >> >> >> "No ssh-agent suitable credentials found". Why? Its a public repository. >> >> >> because you are using an SSH protocol, regardless itâs public state. You >> need to identify yourself so the handshake can happen. >> >> Esteban >> >> >> >

Nov. 12, 2017