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

Re: [Pharo-dev] Book farm working again

by Guillermo Polito

Thanks! On Wed, Feb 8, 2017 at 6:05 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > ï»¿https://ci.inria.fr/pharo-contribution/view/Books/ > I realised that jenkins dropped the connection to the github repositories > of the books and that they were not updated. > You can find my current evening occupation: Learning OOP with Pharo :) > I fixed some problems in UnifiedFFI and clean a bit before restarting to > work on Pillar. > > And we get more green books job. > > Stef >

Feb. 8, 2017

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

by Stephane Ducasse

Indeed. (We should one of these days improve the concurrent aspect of Pharo but we should finish first the current open work) On Wed, Feb 8, 2017 at 5:13 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Problem is related to RecursionStopper which not releases "stop method" > while first debugger will be close or step over. > Also this "stop method" is Halt>>once which could be mistake. > > Probably RecoursionStopper should be process specific variable and not > global registry. > > 2017-02-08 17:04 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> That's strange. >> >> I found that if you step over halt then you are able to halt on next >> call. Anyway it needs to be fixed >> >> 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-trac >>> e-through-same-method >>> >>> 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

Book farm working again

by Stephane Ducasse

Hi ï»¿https://ci.inria.fr/pharo-contribution/view/Books/ I realised that jenkins dropped the connection to the github repositories of the books and that they were not updated. You can find my current evening occupation: Learning OOP with Pharo :) I fixed some problems in UnifiedFFI and clean a bit before restarting to work on Pillar. And we get more green books job. Stef

Feb. 8, 2017

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

by Denis Kudriashov

Problem is related to RecursionStopper which not releases "stop method" while first debugger will be close or step over. Also this "stop method" is Halt>>once which could be mistake. Probably RecoursionStopper should be process specific variable and not global registry. 2017-02-08 17:04 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > That's strange. > > I found that if you step over halt then you are able to halt on next call. > Anyway it needs to be fixed > > 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-trac >> e-through-same-method >> >> 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] Pharo 6 cannot parallel trace through same method

by Denis Kudriashov

That's strange. I found that if you step over halt then you are able to halt on next call. Anyway it needs to be fixed 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 > > > > 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] 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