- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Stuck trying to contribute

by Pavel Krivanek

I use something like this: pharoRepository := IceRepository registry detect: [ :each | each name = 'pharo' ]. pharoRepository checkoutBranch: 'development'. pharoRepository backend pullFrom: pharoRepository origin. pharoRepository push. Beware, it switches the branch and you can loose non-committed work. It supposes origin to be pharo-project/pharo and your fork to be set as default push remote. -- Pavel 2017-11-15 20:44 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Yes, it is working for me too now, and it is actually pretty nice. > > I wonder though what the best way is to keep your personal fork up to date > ? > > I managed to do it with a PR from the fork to the origin (or is it the > reverse ?), like this > > https://github.com/svenvc/pharo/pull/1 > > but it felt a bit weird because obviously the diff is large and I had the > impression that the CI process than had to process all this. > > Maybe there is a better/easier/more correct way ? > > > On 15 Nov 2017, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Just to add a positive note to this discussion: > > > > After cloning the pharo repository, adding my fork as a remote and > > using Guille's scripts from earlier this year to configure the > > repositories in image, I was able to: > > > > - Create new branch from Fogbugz issue... > > - Make the changes > > - Push the changes up to my fork (Synchronise repository) > > - Create pull request... > > - Make some more changes > > - Push changes to my fork > > > > All from within the image, without any problems. > > > > There's still plenty that is manual and outside the image, and it > > would be nice to have a GUI that guided you through the process (at > > the moment you need to know what steps to do and in what order), but > > we have a good solid basis for moving forward. > > > > Cheers, > > Alistair > > > > > > > > On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> > >>> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >>> > >>> Sven > >>> > >>> have a look at the TipsAndTricks new booklet available at > http://books.pharo.org. There is a configuration for iceberg that sets > and reduce > >>> the pain for me. > >> > >> Ah, OK, found it. Thanks. > >> > >> Nice document BTW ;-) > >> > >>> Stef > >>> > >>> > >>> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano < > estebanlm(a)gmail.com> wrote: > >>> > >>> > >>>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >>>> > >>>> If you give me precise instructions I can update the post :) > >>> > >>> precise instructions is: > >>> - do not use https, use ssh > >>> - if you do not follow our recommendation and you insist on use https, > add your credentials before doing any commit. > >>> > >>>> > >>>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>> I think I succeeded: > >>>> > >>>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments > >>>> https://github.com/pharo-project/pharo/pull/420 > >>>> > >>>> It does contain 4 identical commits due to my troubles earlier on. > >>>> I also did not see a confirmation by way of an #inform: after the > pull request in Iceberg. > >>>> > >>>>> On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >>>>>> > >>>>>> hi, > >>>>>> > >>>>>> thing is, you should not use https authentication (and the guide > should not point to it) > >>>>>> Using SSH mode works out of the box. > >>>>>> Using HTTPS there is currently a bug and the workaround is to > introduce your credentials *before* trying to commit (in settings) > >>>>> > >>>>> Well, after entering my username/password in Settings > Tools > > Software Configuration Management > Iceberg > Plaintext Credentials I am > one step further - I managed to 'Commit & Push'. > >>>>> > >>>>> Thanks ! > >>>>> > >>>>>> Esteban > >>>>>> > >>>>>>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new > way. > >>>>>>> > >>>>>>> I was following https://github.com/guillep/ > PharoIntegrationProcess/wiki/Contribute-a-fix-to-Pharo and I got stuck > just before step 3, after trying to do "That will calculate the differences > between the checked-out branch and your image, show you the tree with the > differences and let you commit (and push)". Specifically, the 'and push' > fails. > >>>>>>> > >>>>>>> $ sw_vers > >>>>>>> ProductName: Mac OS X > >>>>>>> ProductVersion: 10.13 > >>>>>>> BuildVersion: 17A405 > >>>>>>> > >>>>>>> $ curl get.pharo.org/70+vm | bash > >>>>>>> ... > >>>>>>> > >>>>>>> $ ./pharo-ui Pharo.image > >>>>>>> > >>>>>>> I now have the following setup, which is correct I think. > >>>>>>> > >>>>>>> <Screen Shot 2017-10-30 at 20.28.05.png> > >>>>>>> > >>>>>>> I can commit on my local branch (left button), but when I try to > do the 'and Push' (right button), things hang after I enter my credentials. > >>>>>>> > >>>>>>> Locally, I see > >>>>>>> > >>>>>>> $ git status > >>>>>>> On branch 20613-Improve-some-UUID-comments > >>>>>>> nothing to commit, working tree clean > >>>>>>> > >>>>>>> with the new code already committed > >>>>>>> > >>>>>>> $ cat src/Network-UUID.package/UUID.class/class/new.st > >>>>>>> instance creation > >>>>>>> new > >>>>>>> "Create and return a new UUID" > >>>>>>> > >>>>>>> "self new" > >>>>>>> > >>>>>>> ^ (self new: 16) > >>>>>>> > >>>>>>> What did I do wrong ? How do I proceed ? > >>>>>>> > >>>>>>> Sven > >>>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Guille Polito > >>>> Research Engineer > >>>> > >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille > >>>> CRIStAL - UMR 9189 > >>>> French National Center for Scientific Research - http://www.cnrs.fr > >>>> > >>>> Web: http://guillep.github.io > >>>> Phone: +33 06 52 70 66 13 > >>> > >>> > >> > >> > > > > >

Nov. 15, 2017

Re: [Pharo-dev] Stuck trying to contribute

by Sven Van Caekenberghe

Yes, it is working for me too now, and it is actually pretty nice. I wonder though what the best way is to keep your personal fork up to date ? I managed to do it with a PR from the fork to the origin (or is it the reverse ?), like this https://github.com/svenvc/pharo/pull/1 but it felt a bit weird because obviously the diff is large and I had the impression that the CI process than had to process all this. Maybe there is a better/easier/more correct way ? > On 15 Nov 2017, at 20:08, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Just to add a positive note to this discussion: > > After cloning the pharo repository, adding my fork as a remote and > using Guille's scripts from earlier this year to configure the > repositories in image, I was able to: > > - Create new branch from Fogbugz issue... > - Make the changes > - Push the changes up to my fork (Synchronise repository) > - Create pull request... > - Make some more changes > - Push changes to my fork > > All from within the image, without any problems. > > There's still plenty that is manual and outside the image, and it > would be nice to have a GUI that guided you through the process (at > the moment you need to know what steps to do and in what order), but > we have a good solid basis for moving forward. > > Cheers, > Alistair > > > > On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Sven >>> >>> have a look at the TipsAndTricks new booklet available at http://books.pharo.org. There is a configuration for iceberg that sets and reduce >>> the pain for me. >> >> Ah, OK, found it. Thanks. >> >> Nice document BTW ;-) >> >>> Stef >>> >>> >>> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>> >>>> If you give me precise instructions I can update the post :) >>> >>> precise instructions is: >>> - do not use https, use ssh >>> - if you do not follow our recommendation and you insist on use https, add your credentials before doing any commit. >>> >>>> >>>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> I think I succeeded: >>>> >>>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments >>>> https://github.com/pharo-project/pharo/pull/420 >>>> >>>> It does contain 4 identical commits due to my troubles earlier on. >>>> I also did not see a confirmation by way of an #inform: after the pull request in Iceberg. >>>> >>>>> On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>> >>>>> >>>>>> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>> >>>>>> hi, >>>>>> >>>>>> thing is, you should not use https authentication (and the guide should not point to it) >>>>>> Using SSH mode works out of the box. >>>>>> Using HTTPS there is currently a bug and the workaround is to introduce your credentials *before* trying to commit (in settings) >>>>> >>>>> Well, after entering my username/password in Settings > Tools > Software Configuration Management > Iceberg > Plaintext Credentials I am one step further - I managed to 'Commit & Push'. >>>>> >>>>> Thanks ! >>>>> >>>>>> Esteban >>>>>> >>>>>>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new way. >>>>>>> >>>>>>> I was following https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… and I got stuck just before step 3, after trying to do "That will calculate the differences between the checked-out branch and your image, show you the tree with the differences and let you commit (and push)". Specifically, the 'and push' fails. >>>>>>> >>>>>>> $ sw_vers >>>>>>> ProductName: Mac OS X >>>>>>> ProductVersion: 10.13 >>>>>>> BuildVersion: 17A405 >>>>>>> >>>>>>> $ curl get.pharo.org/70+vm | bash >>>>>>> ... >>>>>>> >>>>>>> $ ./pharo-ui Pharo.image >>>>>>> >>>>>>> I now have the following setup, which is correct I think. >>>>>>> >>>>>>> <Screen Shot 2017-10-30 at 20.28.05.png> >>>>>>> >>>>>>> I can commit on my local branch (left button), but when I try to do the 'and Push' (right button), things hang after I enter my credentials. >>>>>>> >>>>>>> Locally, I see >>>>>>> >>>>>>> $ git status >>>>>>> On branch 20613-Improve-some-UUID-comments >>>>>>> nothing to commit, working tree clean >>>>>>> >>>>>>> with the new code already committed >>>>>>> >>>>>>> $ cat src/Network-UUID.package/UUID.class/class/new.st >>>>>>> instance creation >>>>>>> new >>>>>>> "Create and return a new UUID" >>>>>>> >>>>>>> "self new" >>>>>>> >>>>>>> ^ (self new: 16) >>>>>>> >>>>>>> What did I do wrong ? How do I proceed ? >>>>>>> >>>>>>> Sven >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Guille Polito >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> CRIStAL - UMR 9189 >>>> French National Center for Scientific Research - http://www.cnrs.fr >>>> >>>> Web: http://guillep.github.io >>>> Phone: +33 06 52 70 66 13 >>> >>> >> >> >

Nov. 15, 2017

Re: [Pharo-dev] Stuck trying to contribute

by Alistair Grant

Just to add a positive note to this discussion: After cloning the pharo repository, adding my fork as a remote and using Guille's scripts from earlier this year to configure the repositories in image, I was able to: - Create new branch from Fogbugz issue... - Make the changes - Push the changes up to my fork (Synchronise repository) - Create pull request... - Make some more changes - Push changes to my fork All from within the image, without any problems. There's still plenty that is manual and outside the image, and it would be nice to have a GUI that guided you through the process (at the moment you need to know what steps to do and in what order), but we have a good solid basis for moving forward. Cheers, Alistair On 31 October 2017 at 12:27, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 31 Oct 2017, at 11:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Sven >> >> have a look at the TipsAndTricks new booklet available at http://books.pharo.org. There is a configuration for iceberg that sets and reduce >> the pain for me. > > Ah, OK, found it. Thanks. > > Nice document BTW ;-) > >> Stef >> >> >> On Tue, Oct 31, 2017 at 10:51 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >>> On 31 Oct 2017, at 10:37, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> If you give me precise instructions I can update the post :) >> >> precise instructions is: >> - do not use https, use ssh >> - if you do not follow our recommendation and you insist on use https, add your credentials before doing any commit. >> >>> >>> On Mon, Oct 30, 2017 at 10:03 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> I think I succeeded: >>> >>> https://pharo.fogbugz.com/f/cases/20613/Improve-some-UUID-comments >>> https://github.com/pharo-project/pharo/pull/420 >>> >>> It does contain 4 identical commits due to my troubles earlier on. >>> I also did not see a confirmation by way of an #inform: after the pull request in Iceberg. >>> >>> > On 30 Oct 2017, at 21:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> > >>> > >>> > >>> >> On 30 Oct 2017, at 21:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >> >>> >> hi, >>> >> >>> >> thing is, you should not use https authentication (and the guide should not point to it) >>> >> Using SSH mode works out of the box. >>> >> Using HTTPS there is currently a bug and the workaround is to introduce your credentials *before* trying to commit (in settings) >>> > >>> > Well, after entering my username/password in Settings > Tools > Software Configuration Management > Iceberg > Plaintext Credentials I am one step further - I managed to 'Commit & Push'. >>> > >>> > Thanks ! >>> > >>> >> Esteban >>> >> >>> >>> On 30 Oct 2017, at 20:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> >>> >>> Hi, >>> >>> >>> >>> Sorry, but I am person 237 trying to contribute to Pharo 7 the new way. >>> >>> >>> >>> I was following https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… and I got stuck just before step 3, after trying to do "That will calculate the differences between the checked-out branch and your image, show you the tree with the differences and let you commit (and push)". Specifically, the 'and push' fails. >>> >>> >>> >>> $ sw_vers >>> >>> ProductName: Mac OS X >>> >>> ProductVersion: 10.13 >>> >>> BuildVersion: 17A405 >>> >>> >>> >>> $ curl get.pharo.org/70+vm | bash >>> >>> ... >>> >>> >>> >>> $ ./pharo-ui Pharo.image >>> >>> >>> >>> I now have the following setup, which is correct I think. >>> >>> >>> >>> <Screen Shot 2017-10-30 at 20.28.05.png> >>> >>> >>> >>> I can commit on my local branch (left button), but when I try to do the 'and Push' (right button), things hang after I enter my credentials. >>> >>> >>> >>> Locally, I see >>> >>> >>> >>> $ git status >>> >>> On branch 20613-Improve-some-UUID-comments >>> >>> nothing to commit, working tree clean >>> >>> >>> >>> with the new code already committed >>> >>> >>> >>> $ cat src/Network-UUID.package/UUID.class/class/new.st >>> >>> instance creation >>> >>> new >>> >>> "Create and return a new UUID" >>> >>> >>> >>> "self new" >>> >>> >>> >>> ^ (self new: 16) >>> >>> >>> >>> What did I do wrong ? How do I proceed ? >>> >>> >>> >>> Sven >>> >>> >>> >> >>> > >>> >>> >>> >>> >>> >>> -- >>> >>> Guille Polito >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> CRIStAL - UMR 9189 >>> French National Center for Scientific Research - http://www.cnrs.fr >>> >>> Web: http://guillep.github.io >>> Phone: +33 06 52 70 66 13 >> >> > >

Nov. 15, 2017

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

by Thomas Dupriez

Here they are: https://github.com/dupriezt/Pharo-RunToSelectionDebuggerFeature Le 15/11/2017 Ã 10:47, Guillermo Polito a Ã©critÂ : > Thomas, can you try writing some real test cases in SUnit? > > I don't care if they are originally red (they will be because it is > not working). > > The idea is that we capture all these different scenarios and have a > way to know automatically in the future if > Â - we fixed all them > Â - or we have a regression and broke some. > > On Wed, Nov 15, 2017 at 10:44 AM, Thomas Dupriez > <thomas.dupriez(a)ens-paris-saclay.fr > <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: > > > > Le 15/11/2017 Ã 01:19, Ben Coman a Ã©critÂ : >> >> >> On 14 November 2017 at 23:55, Thomas Dupriez >> <thomas.dupriez(a)ens-paris-saclay.fr >> <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: >> >> While working on writing a test, I discovered that just using >> stepThrough instead of stepOver may not be the definitive >> solution. >> >> # Example1: When using the `value` message directly (instead >> of calling a method that does that as in my previous >> example), the RunToHere moves the debugSession to the `value` >> message and not the inside of the block. >> >> `meth2 >> Â Â Â self halt. >> Â Â Â [ >> Â Â Â Â Â Â 1+1. >> Â Â Â Â Â Â 2+2."< cursor before the RunToHere" >> Â Â Â ] ">"value"<result of the RunToHere". >> Â Â Â 3+3. >> Â Â Â "Two stepInto are required after the RunToHere to reach >> the cursor (the `+2` message)"` >> >> # Example2: Going back to using a dedicated method for >> evaluating the block, but increasing the block's size. The >> RunToHere moves the debugSession to the first message of the >> block instead of the pointed one. >> >> `meth3 >> Â Â Â self halt. >> Â Â Â MyClass new evalBlock: >> Â Â Â [ >> Â Â Â Â Â Â 1">"+1"< result of the RunToHere". >> Â Â Â Â Â Â 2+2."< cursor before the RunToHere" >> Â Â Â ]. >> Â Â Â 3+3. >> Â Â Â "One stepInto is required after the RunToHere to reach >> the cursor (the `+2` message)"` >> >> cheers -thomas >> >> >> In both cases, what happens with an additional step-Through? >> >> cheers -ben > # Example1*: > Operation: RunToHere with cursor at the end of the `2+2.` line + 1 > stepThrough. > Result: DebugSession at the `+1`, first instruction of the block > but not the intended position. > Note: Doing an additional stepThrough brings the debugSession to > the intended `+2`. > > `meth2 > Â Â Â self halt. > Â Â Â [ > Â Â Â Â Â Â 1">"+1"<"."result of the RunToHere + 1 stepThrough" > Â Â Â Â Â Â 2+2."< cursor before the RunToHere" > Â Â Â ] ">"value"<result of the RunToHere". > Â Â Â 3+3. > Â Â Â "Two stepInto are required after the RunToHere to reach the > cursor (the `+2` message)"` > > # Example2*: > Operation: RunToHere with cursor at the end of the `2+2.` line + 1 > stepThrough > Result: DebugSession at the intended `+2` position. > Note: The additional stepThrough just moves the DebugSession to > the next instruction. See Example3 for what happens when the > target instruction is further away. > > `meth3 > Â Â Â self halt. > Â Â Â MyClass new evalBlock: > Â Â Â [ > Â Â Â Â Â Â 1">"+1"< result of the RunToHere". > Â Â Â Â Â Â 2">"+2"<result of RunToHere+1stepThrough"."< cursor before > the RunToHere" > Â Â Â ]. > Â Â Â 3+3. > Â Â Â "One stepInto is required after the RunToHere to reach the > cursor (the `+2` message)"` > > > # Example3: > Operation: RunToHere with cursor at the end of the `3+3.` line. + > 1 stepThrough. > Result: DebugSession is at the `+2` instruction, not the intended > `+3` one. > > `meth4 > Â Â Â self halt. > Â Â Â MyClass new evalBlock: > Â Â Â [ > Â Â Â Â Â Â 1">"+1"< result of the RunToHere". > Â Â Â Â Â Â 2">"+2"<result of RunToHere+1stepThrough". > Â Â Â Â Â Â 3">"+3"<result of RunToHere+2stepThrough"."< cursor before > the RunToHere" > Â Â Â ]. > Â Â Â 4+4. > Â Â Â "One stepInto is required after the RunToHere to reach the > cursor (the `+2` message)"` > > cheers -thomas > >> Le 13/11/2017 Ã 17:23, Thomas Dupriez a Ã©critÂ : >>> >>> >>> >>> Le 13/11/2017 Ã 15:56, Ben Coman a Ã©critÂ : >>>> >>>> >>>> On Mon, Nov 13, 2017 at 9:32 PM, Thomas Dupriez >>>> <thomas.dupriez(a)ens-paris-saclay.fr >>>> <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: >>>> >>>> >>>> >>>> Le 13/11/2017 Ã 14:08, Ben Coman a Ã©critÂ : >>>>> >>>>> >>>>> On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez >>>>> <thomas.dupriez(a)ens-paris-saclay.fr >>>>> <mailto:thomas.dupriez@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 >>>> >>>> Using `stepThrough: aContext` instead of `stepInto: >>>> aContext`, the RunToHere in the block stops at the >>>> intended place: the 2+2. >>>> Printing the sequence of `self pcRangeForContext: >>>> aContext` yields the following. It doesn't show >>>> precisely the stop in the block, and instead shows an >>>> interval encompassing the whole block. That's what I >>>> was using to see where the execution was going during >>>> the RunToHere loop so I guess that's not a precise >>>> enough indicator for this situation... >>>> (21 to: 22)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60) >>>> >>>> I also tried the case where the block does not get >>>> evaluated (changing myEvalBlock so that it does >>>> nothing). In this situation, the RunToHere with a >>>> stepThrough ends up at the intended place, the 3+3. >>>> >>>> So... just use stepThrough for the RunToHere I guess? >>>> >>>> >>>> Seems like expected behaviour. >>>> Could you create an Issue/Pull Request to provide some >>>> concrete code to review? >>>> >>>> Now the trick will be if you can devise some tests to go >>>> with this. >>>> For examples perhaps look at senders of >>>> newDebugSessionNamed:startedAt: >>>> including SpecDebugger>>testBasic. >>>> >>>> cheers -ben >>>> >>> I opened an issue on FogBugz: >>> https://pharo.fogbugz.com/f/cases/20687/ >>> <https://pharo.fogbugz.com/f/cases/20687/> >>> >>> Attached are the file out of the test code (MyClass.st) and >>> the fixed runToSelection:inContext: >>> (DebugSession-runToSelectioninContext). >>> I'll make a pull request tomorrow. >>> >>> For the test, I'm thinking about something like the >>> following, that checks the source code position of the pc >>> after the runToSelection. (It's not working yet) >>> Now that I think of it, the source code position of the pc >>> will maybe be the whole block (as experienced earlier) so >>> this approach may end up not working. >>> I'll come back to that tomorrow. >>> >>> Draft for a test: >>> Â Â Â `testRunToSelectionInContext >>> Â Â Â |context_ process_ session_| >>> Â Â Â "The variable names have an underscore to distinguish >>> them from those declared in the setUp method of this >>> TestCase (DebuggerModelTest), which are not suited for this >>> test (because not making a debug session out of suitable code)" >>> Â Â Â context_ := [1+1. >>> Â Â Â Â Â Â self evalBlock:[2+2]. >>> Â Â Â Â Â Â 3+3. >>> Â Â Â ] asContext. >>> Â Â Â process_ := Process >>> Â Â Â Â Â Â forContext: context_ >>> Â Â Â Â Â Â priority: Processor userInterruptPriority. >>> >>> Â Â Â session_:= process_ newDebugSessionNamed: 'test session' >>> startedAt: context_. >>> Â Â Â session_ runToSelection: (Interval from: 28 to: 27) >>> inContext: context_. >>> Â Â Â self assert: ((session_ pcRangeForContext: context_) >>> first == 3)` >>> >>> cheers - Thomas >>> >>>> >>>> Thomas >>>> >>>> >>>>> >>>>> - 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 >>>>> <mailto:tudor@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> >>>>> <mailto:tim@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 >>>>> <mailto:stepharo.self@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 <http://www.tudorgirba.com> >>>>> www.feenk.com <http://www.feenk.com> >>>>> >>>>> "Value is always contextual." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > > > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - _http://www.cnrs.fr_ > > > *Web:* _http://guillep.github.io_ > > *Phone: *+33 06 52 70 66 13 >

Nov. 15, 2017

[Pharo 7.0-dev] Build #296: 20689-Make-Pharo-bootstrap-independent-on-source-repository

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

There is a new Pharo build available! The status of the build #296 was: SUCCESS. The Pull Request #479 was integrated: "20689-Make-Pharo-bootstrap-independent-on-source-repository" Pull request url: https://github.com/pharo-project/pharo/pull/479 Issue Url: https://pharo.fogbugz.com/f/cases/20689 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 15, 2017

[ANN] Lifeware upgraded to Platinum Membership

by Marcus Denker

The Pharo Consortium is very happy to announce that Lifeware has upgraded to Platinum Member status. About - Lifeware: http://www.lifeware.ch - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: http://association.pharo.org

Nov. 15, 2017

[Pharo 7.0-dev] Build #295: 20693-Incorrect-basename-of-empty-relative-path

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

There is a new Pharo build available! The status of the build #295 was: SUCCESS. The Pull Request #481 was integrated: "20693-Incorrect-basename-of-empty-relative-path" Pull request url: https://github.com/pharo-project/pharo/pull/481 Issue Url: https://pharo.fogbugz.com/f/cases/20693 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 15, 2017

[Pharo 7.0-dev] Build #294: 20678-selecting-of-a-method-version-causes-DNU

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

There is a new Pharo build available! The status of the build #294 was: SUCCESS. The Pull Request #482 was integrated: "20678-selecting-of-a-method-version-causes-DNU" Pull request url: https://github.com/pharo-project/pharo/pull/482 Issue Url: https://pharo.fogbugz.com/f/cases/20678 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 15, 2017

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

by Guillermo Polito

Thomas, can you try writing some real test cases in SUnit? I don't care if they are originally red (they will be because it is not working). The idea is that we capture all these different scenarios and have a way to know automatically in the future if - we fixed all them - or we have a regression and broke some. On Wed, Nov 15, 2017 at 10:44 AM, Thomas Dupriez < thomas.dupriez(a)ens-paris-saclay.fr> wrote: > > > Le 15/11/2017 Ã 01:19, Ben Coman a Ã©crit : > > > > On 14 November 2017 at 23:55, Thomas Dupriez <thomas.dupriez@ens-paris- > saclay.fr> wrote: > >> While working on writing a test, I discovered that just using stepThrough >> instead of stepOver may not be the definitive solution. >> >> # Example1: When using the `value` message directly (instead of calling a >> method that does that as in my previous example), the RunToHere moves the >> debugSession to the `value` message and not the inside of the block. >> >> `meth2 >> self halt. >> [ >> 1+1. >> 2+2."< cursor before the RunToHere" >> ] ">"value"<result of the RunToHere". >> 3+3. >> "Two stepInto are required after the RunToHere to reach the cursor >> (the `+2` message)"` >> >> # Example2: Going back to using a dedicated method for evaluating the >> block, but increasing the block's size. The RunToHere moves the >> debugSession to the first message of the block instead of the pointed one. >> >> `meth3 >> self halt. >> MyClass new evalBlock: >> [ >> 1">"+1"< result of the RunToHere". >> 2+2."< cursor before the RunToHere" >> ]. >> 3+3. >> "One stepInto is required after the RunToHere to reach the cursor >> (the `+2` message)"` >> >> cheers -thomas >> > > In both cases, what happens with an additional step-Through? > > cheers -ben > > > # Example1*: > Operation: RunToHere with cursor at the end of the `2+2.` line + 1 > stepThrough. > Result: DebugSession at the `+1`, first instruction of the block but not > the intended position. > Note: Doing an additional stepThrough brings the debugSession to the > intended `+2`. > > `meth2 > self halt. > [ > 1">"+1"<"."result of the RunToHere + 1 stepThrough" > 2+2."< cursor before the RunToHere" > ] ">"value"<result of the RunToHere". > 3+3. > "Two stepInto are required after the RunToHere to reach the cursor > (the `+2` message)"` > > # Example2*: > Operation: RunToHere with cursor at the end of the `2+2.` line + 1 > stepThrough > Result: DebugSession at the intended `+2` position. > Note: The additional stepThrough just moves the DebugSession to the next > instruction. See Example3 for what happens when the target instruction is > further away. > > `meth3 > self halt. > MyClass new evalBlock: > [ > 1">"+1"< result of the RunToHere". > 2">"+2"<result of RunToHere+1stepThrough"."< cursor before the > RunToHere" > ]. > 3+3. > "One stepInto is required after the RunToHere to reach the cursor (the > `+2` message)"` > > > # Example3: > Operation: RunToHere with cursor at the end of the `3+3.` line. + 1 > stepThrough. > Result: DebugSession is at the `+2` instruction, not the intended `+3` one. > > `meth4 > self halt. > MyClass new evalBlock: > [ > 1">"+1"< result of the RunToHere". > 2">"+2"<result of RunToHere+1stepThrough". > 3">"+3"<result of RunToHere+2stepThrough"."< cursor before the > RunToHere" > ]. > 4+4. > "One stepInto is required after the RunToHere to reach the cursor (the > `+2` message)"` > > cheers -thomas > > Le 13/11/2017 Ã 17:23, Thomas Dupriez a Ã©crit : >> >> >> >> Le 13/11/2017 Ã 15:56, Ben Coman a Ã©crit : >> >> >> >> On Mon, Nov 13, 2017 at 9:32 PM, Thomas Dupriez < >> thomas.dupriez(a)ens-paris-saclay.fr> wrote: >> >>> >>> >>> Le 13/11/2017 Ã 14:08, Ben Coman a Ã©crit : >>> >>> >>> >>> 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 >>> >>> >>> Using `stepThrough: aContext` instead of `stepInto: aContext`, the >>> RunToHere in the block stops at the intended place: the 2+2. >>> Printing the sequence of `self pcRangeForContext: aContext` yields the >>> following. It doesn't show precisely the stop in the block, and instead >>> shows an interval encompassing the whole block. That's what I was using to >>> see where the execution was going during the RunToHere loop so I guess >>> that's not a precise enough indicator for this situation... >>> (21 to: 22)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60) >>> >>> I also tried the case where the block does not get evaluated (changing >>> myEvalBlock so that it does nothing). In this situation, the RunToHere with >>> a stepThrough ends up at the intended place, the 3+3. >>> >>> So... just use stepThrough for the RunToHere I guess? >>> >> >> Seems like expected behaviour. >> Could you create an Issue/Pull Request to provide some concrete code to >> review? >> >> Now the trick will be if you can devise some tests to go with this. >> For examples perhaps look at senders of newDebugSessionNamed:startedAt: >> including SpecDebugger>>testBasic. >> >> cheers -ben >> >> >> >> I opened an issue on FogBugz: https://pharo.fogbugz.com/f/cases/20687/ >> >> Attached are the file out of the test code (MyClass.st) and the fixed >> runToSelection:inContext: (DebugSession-runToSelectioninContext). >> I'll make a pull request tomorrow. >> >> For the test, I'm thinking about something like the following, that >> checks the source code position of the pc after the runToSelection. (It's >> not working yet) >> Now that I think of it, the source code position of the pc will maybe be >> the whole block (as experienced earlier) so this approach may end up not >> working. >> I'll come back to that tomorrow. >> >> Draft for a test: >> `testRunToSelectionInContext >> |context_ process_ session_| >> "The variable names have an underscore to distinguish them from those >> declared in the setUp method of this TestCase (DebuggerModelTest), which >> are not suited for this test (because not making a debug session out of >> suitable code)" >> context_ := [1+1. >> self evalBlock:[2+2]. >> 3+3. >> ] asContext. >> process_ := Process >> forContext: context_ >> priority: Processor userInterruptPriority. >> >> session_:= process_ newDebugSessionNamed: 'test session' startedAt: >> context_. >> session_ runToSelection: (Interval from: 28 to: 27) inContext: >> context_. >> self assert: ((session_ pcRangeForContext: context_) first == 3)` >> >> cheers - Thomas >> >> >>> Thomas >>> >>> >>> >>> >>> >>>> - 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> >>>>>>> <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." >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>> >>> >> >> >> > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Nov. 15, 2017

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

by Thomas Dupriez

Le 15/11/2017 Ã 01:19, Ben Coman a Ã©critÂ : > > > On 14 November 2017 at 23:55, Thomas Dupriez > <thomas.dupriez(a)ens-paris-saclay.fr > <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: > > While working on writing a test, I discovered that just using > stepThrough instead of stepOver may not be the definitive solution. > > # Example1: When using the `value` message directly (instead of > calling a method that does that as in my previous example), the > RunToHere moves the debugSession to the `value` message and not > the inside of the block. > > `meth2 > Â Â Â self halt. > Â Â Â [ > Â Â Â Â Â Â 1+1. > Â Â Â Â Â Â 2+2."< cursor before the RunToHere" > Â Â Â ] ">"value"<result of the RunToHere". > Â Â Â 3+3. > Â Â Â "Two stepInto are required after the RunToHere to reach the > cursor (the `+2` message)"` > > # Example2: Going back to using a dedicated method for evaluating > the block, but increasing the block's size. The RunToHere moves > the debugSession to the first message of the block instead of the > pointed one. > > `meth3 > Â Â Â self halt. > Â Â Â MyClass new evalBlock: > Â Â Â [ > Â Â Â Â Â Â 1">"+1"< result of the RunToHere". > Â Â Â Â Â Â 2+2."< cursor before the RunToHere" > Â Â Â ]. > Â Â Â 3+3. > Â Â Â "One stepInto is required after the RunToHere to reach the > cursor (the `+2` message)"` > > cheers -thomas > > > In both cases, what happens with an additional step-Through? > > cheers -ben # Example1*: Operation: RunToHere with cursor at the end of the `2+2.` line + 1 stepThrough. Result: DebugSession at the `+1`, first instruction of the block but not the intended position. Note: Doing an additional stepThrough brings the debugSession to the intended `+2`. `meth2 Â Â Â self halt. Â Â Â [ Â Â Â Â Â Â 1">"+1"<"."result of the RunToHere + 1 stepThrough" Â Â Â Â Â Â 2+2."< cursor before the RunToHere" Â Â Â ] ">"value"<result of the RunToHere". Â Â Â 3+3. Â Â Â "Two stepInto are required after the RunToHere to reach the cursor (the `+2` message)"` # Example2*: Operation: RunToHere with cursor at the end of the `2+2.` line + 1 stepThrough Result: DebugSession at the intended `+2` position. Note: The additional stepThrough just moves the DebugSession to the next instruction. See Example3 for what happens when the target instruction is further away. `meth3 Â Â Â self halt. Â Â Â MyClass new evalBlock: Â Â Â [ Â Â Â Â Â Â 1">"+1"< result of the RunToHere". Â Â Â Â Â Â 2">"+2"<result of RunToHere+1stepThrough"."< cursor before the RunToHere" Â Â Â ]. Â Â Â 3+3. Â Â Â "One stepInto is required after the RunToHere to reach the cursor (the `+2` message)"` # Example3: Operation: RunToHere with cursor at the end of the `3+3.` line. + 1 stepThrough. Result: DebugSession is at the `+2` instruction, not the intended `+3` one. `meth4 Â Â Â self halt. Â Â Â MyClass new evalBlock: Â Â Â [ Â Â Â Â Â Â 1">"+1"< result of the RunToHere". Â Â Â Â Â Â 2">"+2"<result of RunToHere+1stepThrough". Â Â Â Â Â Â 3">"+3"<result of RunToHere+2stepThrough"."< cursor before the RunToHere" Â Â Â ]. Â Â Â 4+4. Â Â Â "One stepInto is required after the RunToHere to reach the cursor (the `+2` message)"` cheers -thomas > Le 13/11/2017 Ã 17:23, Thomas Dupriez a Ã©critÂ : >> >> >> >> Le 13/11/2017 Ã 15:56, Ben Coman a Ã©critÂ : >>> >>> >>> On Mon, Nov 13, 2017 at 9:32 PM, Thomas Dupriez >>> <thomas.dupriez(a)ens-paris-saclay.fr >>> <mailto:thomas.dupriez@ens-paris-saclay.fr>> wrote: >>> >>> >>> >>> Le 13/11/2017 Ã 14:08, Ben Coman a Ã©critÂ : >>>> >>>> >>>> On Mon, Nov 13, 2017 at 8:40 PM, Thomas Dupriez >>>> <thomas.dupriez(a)ens-paris-saclay.fr >>>> <mailto:thomas.dupriez@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 >>> >>> Using `stepThrough: aContext` instead of `stepInto: >>> aContext`, the RunToHere in the block stops at the intended >>> place: the 2+2. >>> Printing the sequence of `self pcRangeForContext: aContext` >>> yields the following. It doesn't show precisely the stop in >>> the block, and instead shows an interval encompassing the >>> whole block. That's what I was using to see where the >>> execution was going during the RunToHere loop so I guess >>> that's not a precise enough indicator for this situation... >>> (21 to: 22)(34 to: 36)(49 to: 60)(38 to: 60)(38 to: 60) >>> >>> I also tried the case where the block does not get evaluated >>> (changing myEvalBlock so that it does nothing). In this >>> situation, the RunToHere with a stepThrough ends up at the >>> intended place, the 3+3. >>> >>> So... just use stepThrough for the RunToHere I guess? >>> >>> >>> Seems like expected behaviour. >>> Could you create an Issue/Pull Request to provide some concrete >>> code to review? >>> >>> Now the trick will be if you can devise some tests to go with this. >>> For examples perhaps look at senders of >>> newDebugSessionNamed:startedAt: >>> including SpecDebugger>>testBasic. >>> >>> cheers -ben >>> >> I opened an issue on FogBugz: >> https://pharo.fogbugz.com/f/cases/20687/ >> <https://pharo.fogbugz.com/f/cases/20687/> >> >> Attached are the file out of the test code (MyClass.st) and the >> fixed runToSelection:inContext: >> (DebugSession-runToSelectioninContext). >> I'll make a pull request tomorrow. >> >> For the test, I'm thinking about something like the following, >> that checks the source code position of the pc after the >> runToSelection. (It's not working yet) >> Now that I think of it, the source code position of the pc will >> maybe be the whole block (as experienced earlier) so this >> approach may end up not working. >> I'll come back to that tomorrow. >> >> Draft for a test: >> Â Â Â `testRunToSelectionInContext >> Â Â Â |context_ process_ session_| >> Â Â Â "The variable names have an underscore to distinguish them >> from those declared in the setUp method of this TestCase >> (DebuggerModelTest), which are not suited for this test (because >> not making a debug session out of suitable code)" >> Â Â Â context_ := [1+1. >> Â Â Â Â Â Â self evalBlock:[2+2]. >> Â Â Â Â Â Â 3+3. >> Â Â Â ] asContext. >> Â Â Â process_ := Process >> Â Â Â Â Â Â forContext: context_ >> Â Â Â Â Â Â priority: Processor userInterruptPriority. >> >> Â Â Â session_:= process_ newDebugSessionNamed: 'test session' >> startedAt: context_. >> Â Â Â session_ runToSelection: (Interval from: 28 to: 27) >> inContext: context_. >> Â Â Â self assert: ((session_ pcRangeForContext: context_) first == 3)` >> >> cheers - Thomas >> >>> >>> Thomas >>> >>> >>>> >>>> - 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 >>>> <mailto:tudor@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> >>>> <mailto:tim@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 >>>> <mailto:stepharo.self@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 <http://www.tudorgirba.com> >>>> www.feenk.com <http://www.feenk.com> >>>> >>>> "Value is always contextual." >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> > >

Nov. 15, 2017