- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo 6 cannot parallel trace through same method

by Nicolai Hess

2017-02-08 16:37 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > > This has bugged me a few times recently, so I've produced a demo. > Define... > > Object subclass: #AA > instanceVariableNames: '' > classVariableNames: '' > package: 'AAAA' > > AA>>test > self haltOnce. > self inform: 'I got here'. > > then in playground evaluate.... > Halt resetOnce. "i.e. World > Debugging > Enable all break/inspect once." > AA new test. > > and as expected you get a debugger window. > Now once again without closing the debugger ... > Halt resetOnce. > AA new test. > > and I'd expect another debugger, but instead I'm informed 'I got here'. > Its extremely useful sometimes to parallel trace through code comparing > two cases, > and the current behaviour prevents that. . > > The Pharo 5 equivalent works as expected... > Halt enableHaltOnce. > AA new test. > > I'm not sure where to hang it, but the following test > differentiates between Pharo 5 & 6. (you can also run it from the > playground.) > > testParallelTrace > |completed p1 ds1 p2 ds2| > completed := 0. > Halt resetOnce. "enableHaltOnce" > p1 := [ self haltOnce. completed := completed + 1 ] newProcess. > ds1 := DebugSession named: 'Trace1' on: p1 startedAt: p1 > suspendedContext. > ds1 resume. > Halt resetOnce. "enableHaltOnce" > p2 := [ self haltOnce. completed := completed + 1 ] newProcess. > ds2 := DebugSession named: 'Trace2' on: p2 startedAt: p2 > suspendedContext. > ds2 resume. > self assert: (completed = 0) > > I've opened > https://pharo.fogbugz.com/f/cases/19677/Cannot-parallel- > trace-through-same-method > > cheers -ben > > I think this is a result of the change how haltOnce are now implemented with metalinks. > > > P.S. I'm not sure if enabling the global haltOnce might cause issues. > It would be useful to be able to set it only for the DebugSession. >

Feb. 8, 2017

Pharo 6 cannot parallel trace through same method

by Ben Coman

This has bugged me a few times recently, so I've produced a demo. Define... Object subclass: #AA instanceVariableNames: '' classVariableNames: '' package: 'AAAA' AA>>test self haltOnce. self inform: 'I got here'. then in playground evaluate.... Halt resetOnce. "i.e. World > Debugging > Enable all break/inspect once." AA new test. and as expected you get a debugger window. Now once again without closing the debugger ... Halt resetOnce. AA new test. and I'd expect another debugger, but instead I'm informed 'I got here'. Its extremely useful sometimes to parallel trace through code comparing two cases, and the current behaviour prevents that. . The Pharo 5 equivalent works as expected... Halt enableHaltOnce. AA new test. I'm not sure where to hang it, but the following test differentiates between Pharo 5 & 6. (you can also run it from the playground.) testParallelTrace |completed p1 ds1 p2 ds2| completed := 0. Halt resetOnce. "enableHaltOnce" p1 := [ self haltOnce. completed := completed + 1 ] newProcess. ds1 := DebugSession named: 'Trace1' on: p1 startedAt: p1 suspendedContext. ds1 resume. Halt resetOnce. "enableHaltOnce" p2 := [ self haltOnce. completed := completed + 1 ] newProcess. ds2 := DebugSession named: 'Trace2' on: p2 startedAt: p2 suspendedContext. ds2 resume. self assert: (completed = 0) I've opened https://pharo.fogbugz.com/f/cases/19677/Cannot-parallel-trace-through-same-… cheers -ben P.S. I'm not sure if enabling the global haltOnce might cause issues. It would be useful to be able to set it only for the DebugSession.

Feb. 8, 2017

Re: [Pharo-dev] [QA] Debugger buttons explained

by Stephane Ducasse

looks good to me. On Tue, Feb 7, 2017 at 8:40 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 7 Feb 2017, at 08:05, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > > > > Sven I do not get > > > > Step over the highlighted message, i.e. do not follow the sent message, > taking debugger control after the method invoked returns or whenever > execution should return inside a block used as an argument before that. > > > > in particular the taking debugger control > > may be > > > > give back debugger control? > > Give back might be clearer than take back, I guess, I don't know. > > Maybe the 'before that' should be moved too, as in > > Step over the highlighted message, i.e. do not follow the sent message, > give back debugger control after the method invoked returns or whenever > before that execution should return inside a block used as an argument. > > > On Mon, Feb 6, 2017 at 7:39 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > On 6 Feb 2017, at 18:55, Hilaire <hilaire(a)drgeo.eu> wrote: > > > > > > How will you describe these buttons in the debugger? > > > Here are proposals for tooltips, please fix it, I am sure there are > > > better way to write it. > > > > > > Proceed > > > Quit the debugger and resume the execution of the method. > > > > > > Restart > > > Reset the local variable and restart stepping at the beginning of the > > > method. > > > > > > Into > > > Step in the highlighted message, i.e. follow the sent message in its > method. > > > > > > Over > > > Execute the highlighted message, i.e. do not follow the sent message in > > > its method. > > > > > > Through > > > Execute the highlighted message, when argument is a bloc to #do:, > > > #collect:, #select: #detect: step in the bloc. > > > > That last one is not correct. It has nothing to do with specific > iteration selectors. It means: stop when execution returns in one of the > argument blocks. It also works for #on:error: #streamContents: or any other > message that accepts blocks as argument - which is pretty cool. > > > > Consult DebugSession for good descriptions of the actions. > > > > > > This is my version/take, probably not perfect either. > > > > > > Into > > > > Step in the highlighted message, i.e. follow the sent message, taking > debugger control in the method invoked. > > > > Over > > > > Step over the highlighted message, i.e. do not follow the sent message, > taking debugger control after the method invoked returns. > > > > Through > > > > Step over the highlighted message, i.e. do not follow the sent message, > taking debugger control after the method invoked returns or whenever > execution should return inside a block used as an argument before that. > > > > Restart > > > > Go back the start of the current execution context, resetting all local > variables and take debugger control. > > > > Continue > > > > Relinquish debugger control and proceed execution from the current point > of debugger control. > > > > > > > https://pharo.fogbugz.com/f/cases/19654/Tooltips-with- > description-of-the-over-and-through-debugger-buttons-actions > > > > > > -- > > > Dr. Geo > > > http://drgeo.eu > > > > > > > > > > > > > > >

Feb. 8, 2017

Re: [Pharo-dev] Language Server Protocol

by Ben Coman

Hi Stefan, Thanks for your insight. On Wed, Feb 8, 2017 at 4:47 PM, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi Ben: > >> On 8 Feb 2017, at 08:01, Ben Coman <btc(a)openInWorld.com> wrote: >> >> Just a very brief thought, to wonder being a Language Server Protocol client >> might be a path to polygot programming in Pharo. >> Or if providing a LSP server might be a bridge-head >> for Pharo to be integrated into larger projects. >> >> * http://langserver.org/ >> * https://github.com/Microsoft/language-server-protocol/blob/master/protocol.… > > Just to report on my experience with the language server protocol. > Most IDEs supporting it assume that you got a file syntax to start from. > So, that would seem like the biggest hurdle, if you arenât happy with change sets. Perhaps a WebDAV server interface, since in the spec I think I saw the file references were urls. I vaguely thought I'd seen someone had done a WebDAV server, but I can't find the reference. > > Beside that, providing a basic language server for Pharo should be pretty simple. > You got already all the functionality in the image, and merely need to expose it via the language server protocol to be consumed by for instance VS Code. > So, that includes simple parser errors, lookup of senders, documentation or even code critique results. > > To get an impression of how that could look for a Smalltalk-like language, check the screenshots here: > http://stefan-marr.de/2016/08/can-we-get-the-ide-for-free-too/ > > and here: > https://marketplace.visualstudio.com/items?itemName=MetaConcProject.SOMns > > Thatâs how it looks for Newspeak/SOMns. cool. cheers -ben

Feb. 8, 2017

Re: [Pharo-dev] Language Server Protocol

by phil＠highoctane.be

Yes, the protocol first step is about "Documents" What do you think would be the best thing for "Document" besides "ChangeSet"? We can have $root/packagename/classname/[class|instance]/protocol/method.st mapping with method as document but there would be quite a lot. $root/packagename/classname_[class|instance].st may be a simpler mapping but editing and save will be complicated. Why did you go the way you went for SOM? Phil On Wed, Feb 8, 2017 at 9:47 AM, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > Hi Ben: > > > On 8 Feb 2017, at 08:01, Ben Coman <btc(a)openInWorld.com> wrote: > > > > Just a very brief thought, to wonder being a Language Server Protocol > client > > might be a path to polygot programming in Pharo. > > Or if providing a LSP server might be a bridge-head > > for Pharo to be integrated into larger projects. > > > > * http://langserver.org/ > > * https://github.com/Microsoft/language-server-protocol/blob/ > master/protocol.md > > Just to report on my experience with the language server protocol. > Most IDEs supporting it assume that you got a file syntax to start from. > So, that would seem like the biggest hurdle, if you arenât happy with > change sets. > > Beside that, providing a basic language server for Pharo should be pretty > simple. > You got already all the functionality in the image, and merely need to > expose it via the language server protocol to be consumed by for instance > VS Code. > So, that includes simple parser errors, lookup of senders, documentation > or even code critique results. > > To get an impression of how that could look for a Smalltalk-like language, > check the screenshots here: > http://stefan-marr.de/2016/08/can-we-get-the-ide-for-free-too/ > > and here: > https://marketplace.visualstudio.com/items?itemName=MetaConcProject.SOMns > > Thatâs how it looks for Newspeak/SOMns. > > Best regards > Stefan > > -- > Stefan Marr > Johannes Kepler UniversitÃ¤t Linz > http://stefan-marr.de/research/ > > > > >

Feb. 8, 2017

Re: [Pharo-dev] Language Server Protocol

by Stefan Marr

Hi Ben: > On 8 Feb 2017, at 08:01, Ben Coman <btc(a)openInWorld.com> wrote: > > Just a very brief thought, to wonder being a Language Server Protocol client > might be a path to polygot programming in Pharo. > Or if providing a LSP server might be a bridge-head > for Pharo to be integrated into larger projects. > > * http://langserver.org/ > * https://github.com/Microsoft/language-server-protocol/blob/master/protocol.… Just to report on my experience with the language server protocol. Most IDEs supporting it assume that you got a file syntax to start from. So, that would seem like the biggest hurdle, if you arenât happy with change sets. Beside that, providing a basic language server for Pharo should be pretty simple. You got already all the functionality in the image, and merely need to expose it via the language server protocol to be consumed by for instance VS Code. So, that includes simple parser errors, lookup of senders, documentation or even code critique results. To get an impression of how that could look for a Smalltalk-like language, check the screenshots here: http://stefan-marr.de/2016/08/can-we-get-the-ide-for-free-too/ and here: https://marketplace.visualstudio.com/items?itemName=MetaConcProject.SOMns Thatâs how it looks for Newspeak/SOMns. Best regards Stefan -- Stefan Marr Johannes Kepler UniversitÃ¤t Linz http://stefan-marr.de/research/

Feb. 8, 2017

Language Server Protocol

by Ben Coman

Just a very brief thought, to wonder being a Language Server Protocol client might be a path to polygot programming in Pharo. Or if providing a LSP server might be a bridge-head for Pharo to be integrated into larger projects. * http://langserver.org/ * https://github.com/Microsoft/language-server-protocol/blob/master/protocol.… cheers -ben

Feb. 8, 2017

Re: [Pharo-dev] Pharo 60 needs help because Removing-a-package-with-extensions-let-the-extensions-in-the-system-and-break-their-reload

by Stephane Ducasse

Super tx guille!!! On Tue, Feb 7, 2017 at 12:18 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > I proposed a slice in the inbox for this. > > - added RPackage>>removeFromSystem > - this version removes defined classes and also extension methods > defined in the package. > - make Nautilus ask the RPackage to remove itself (instead of doing it in > the UI) > > I tested it with the fileout of a package with extension methods, removing > the package and filing it in again. > > On Tue, Feb 7, 2017 at 11:41 AM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> https://pharo.fogbugz.com/f/cases/19664/Removing-a-package- >> with-extensions-let-the-extensions-in-the-system-and-break-their-reload >> > >

Feb. 8, 2017

Re: [Pharo-dev] [QA] Debugger buttons explained

by Hilaire

As we are here, what are your best proposals for these buttons: Full stack Run to here Where is? Le 06/02/2017 Ã 21:25, Sean P. DeNigris a Ã©crit : > How about... -- Dr. Geo http://drgeo.eu

Feb. 7, 2017

Re: [Pharo-dev] [QA] Debugger buttons explained

by Hilaire

ok got it! Le 07/02/2017 Ã 20:49, Andrei Chis a Ã©crit : > Seems that I made a small mistake before. > DebugAction>>#asMenuRegistrationIn: is called only when creating the > context menu. > SpecDebuggerDynamicToolbar is the class that builds the toolbar with the > step buttons. Then each button will be an instance of SpecDebugActionButton. > -- Dr. Geo http://drgeo.eu

Feb. 7, 2017