- Pharo-dev - lists.pharo.org

protocol pane "no messages" Re: [Pharo-users] setter method

by Ben Coman

[Forwarded to pharo-dev for side discussion...] On Sat, Dec 10, 2016 at 2:15 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Sat, Dec 10, 2016 at 1:39 AM, Kateryna Aloshkina > <aloshkina(a)ucu.edu.ua> wrote: >> Hi everybody! >> >> I've just joined the community:) and have a question >> How to write the method count: such that, when invoked on an instance of >> Counter, instance variable is set to the argument given to the message? >> so that >> Counter new count: 7 >> would set the value of a new Counter instance to 7 >> (It is a little exercise from >> http://rmod-pharo-mooc.lille.inria.fr/MOOC/Exercises/Exo-Counter.pdf) >> >> >> Best wishes, >> Kateryna > > Welcome Kateryna, > I hope you are having fun and Pharo changes the way you think about programming. > > Referring to Figure 1.2, assuming you've already created the class, > first make sure you are on the instance-side rather than the class-side > of the class such that the class definition in the bottom (code) pane > looks just like Figure 1.2. Click the <Class> button to toggle which > side you look at. > > Now in the third (protocols) pane on "no messages" > and you will get a method template in the code pane > > Change... messageSelectorAndArgumentNames > to... count: > > then change.... statements > to an assignment to the instance variable. > and <Accept> the the code to save & compile the method. To be pedantic, shouldn't "no messages" actually be "no methods" But maybe even better would be... "click for method template" ? cheers -ben

Dec. 9, 2016

Re: [Pharo-dev] consider putting stars on our nice books on github :)

by Sven Van Caekenberghe

Done. > On 9 Dec 2016, at 16:11, stepharong <stepharong(a)free.fr> wrote: > > https://github.com/SquareBracketAssociates/EnterprisePharo > > https://github.com/SquareBracketAssociates/NumericalMethods > > https://github.com/SquareBracketAssociates/UpdatedPharoByExample > > https://github.com/SquareBracketAssociates/BuildingUIWithSpec > > https://github.com/SquareBracketAssociates/TinyBlogTutorial > > https://github.com/SquareBracketAssociates/ExploringVMs > > https://github.com/SquareBracketAssociates/DeepIntoPharo > > Stef > -- > Using Opera's mail client: http://www.opera.com/mail/ >

Dec. 9, 2016

Re: [Pharo-dev] about syntaxError

by stepharong

> Change line 3 of RBExtractMethodRefactoring>>extractMethod to something > like: > [ extractedParseTree := RBParser parseExpression: extractCode ] on: > SyntaxErrorNotification do: [ :ex| ex debug ]. > > To bring up a debugger. Tx this is what I was trying to do (but I should not because I was in a hacking session) and then I went to bed. I will try it. STef > > Best regards, > Henrik > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of > stepharong > Sent: Thursday, December 8, 2016 9:08 PM > To: pharo-dev(a)lists.pharo.org > Subject: [Pharo-dev] about syntaxError > > I tried to fix the extract method refactoring that seems broken when > extracting class or variables. > And I wanted to understand if I can get a debugger stack instead of this > useless Syntax Error: window. > Now I cannot find reference to SyntaxErrorDebugger. > still putting a break point in > > buildMorphicViewOn: aSyntaxError > "Answer an Morphic view on the given SyntaxError." > > | window | > self halt. > > bring a debugger but with a cut stack .... > > open: aSyntaxError > "Answer a standard system view whose model is an instance of me." > <primitive: 19> > "Simulation guard" > | process | > process := Processor activeProcess. > UIManager default spawnNewProcessIfThisIsUI: process. > UIManager default defer: [ > self buildMorphicViewOn: aSyntaxError. > ]. > ^ process suspend > > so it does not really help to understand the syntax error. > I do not get why this is so opaque. > > Stef > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > > -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 9, 2016

consider putting stars on our nice books on github :)

by stepharong

https://github.com/SquareBracketAssociates/EnterprisePharo https://github.com/SquareBracketAssociates/NumericalMethods https://github.com/SquareBracketAssociates/UpdatedPharoByExample https://github.com/SquareBracketAssociates/BuildingUIWithSpec https://github.com/SquareBracketAssociates/TinyBlogTutorial https://github.com/SquareBracketAssociates/ExploringVMs https://github.com/SquareBracketAssociates/DeepIntoPharo Stef -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 9, 2016

Re: [Pharo-dev] about syntaxError

by Igor Stasenko

and this works simply by knowing that primitive 19 always fails (this is guaranteed by VM itself). so when you run code naturally - the primitive fails, and so it runs the body of method. but when same method attempted to activate(simulate) via debugger - it doesn't runs a method body and doing something else, what exactly - look at debugger code, because i don't remember :). On 9 December 2016 at 02:00, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 9 December 2016 at 01:39, phil(a)highoctane.be <phil(a)highoctane.be> > wrote: > >> Nice to now understand how this debugger thing behaves. >> >> I have some issues when debugging tests GTDebugger in Pharo5 when there >> is a self halt in the test method. For some reason the step through looks >> like out of what with the actual thing to step through. >> >> How does that work? >> > > well, IIRC, when you stepping through, the debugger running a simulation > and detects that you trying to interrupt it > and since it is not a good idea to interrupt the debugger itself , else > you will need to open yet another debugger window, > showing where the simulation/exception handling was interrupted.. and so > you enter an endless recursive loop, > and as result won't be able to debug anything :) > > And this 'simulation guard' is serving to prohibit further processing in > such cases, or in certain cases, it simply ignores > it and pretends that it is done, suppressing actual code behavior, which > would be triggered, if it wouldn't run simulated by debugger. > > >> Phil >> >> > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Dec. 9, 2016

Re: [Pharo-dev] about syntaxError

by Igor Stasenko

On 9 December 2016 at 01:39, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Nice to now understand how this debugger thing behaves. > > I have some issues when debugging tests GTDebugger in Pharo5 when there is > a self halt in the test method. For some reason the step through looks like > out of what with the actual thing to step through. > > How does that work? > well, IIRC, when you stepping through, the debugger running a simulation and detects that you trying to interrupt it and since it is not a good idea to interrupt the debugger itself , else you will need to open yet another debugger window, showing where the simulation/exception handling was interrupted.. and so you enter an endless recursive loop, and as result won't be able to debug anything :) And this 'simulation guard' is serving to prohibit further processing in such cases, or in certain cases, it simply ignores it and pretends that it is done, suppressing actual code behavior, which would be triggered, if it wouldn't run simulated by debugger. > Phil > > -- Best regards, Igor Stasenko.

Dec. 9, 2016

Re: [Pharo-dev] about syntaxError

by phil＠highoctane.be

Nice to now understand how this debugger thing behaves. I have some issues when debugging tests GTDebugger in Pharo5 when there is a self halt in the test method. For some reason the step through looks like out of what with the actual thing to step through. How does that work? Phil On Fri, Dec 9, 2016 at 12:06 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 8 December 2016 at 22:56, stepharong <stepharong(a)free.fr> wrote: > >> Sorry igot but I do not understand what you are saying. >> Too tired. >> > > the exception handler if it runs in UI process does following: > - spawns new UI process, > suspending the old one, that caused exception, > then creates a debugger that showing where the original exception occur. > > but if you put halt somewhere in the middle of exception handler , you > will either create an endless loop (of attempting to bring debugger), > or, when you lucky, as in your case - it will show you debugger , where > you interrupted the exception handling, > but not the original exception. > > >> >> coz u putting exception inside an exception handler.. >> yo gawd, so you like exceptions? >> lets put an exception inside your exception, so it will be thrown while >> it thrown >> :)))))) >> (i hope everyone knows this reference :) >> >> >> On 8 December 2016 at 22:07, stepharong <stepharong(a)free.fr> wrote: >> >>> I tried to fix the extract method refactoring that seems broken when >>> extracting class or variables. >>> And I wanted to understand if I can get a debugger stack instead of this >>> useless Syntax Error: window. >>> Now I cannot find reference to SyntaxErrorDebugger. >>> still putting a break point in >>> >>> buildMorphicViewOn: aSyntaxError >>> "Answer an Morphic view on the given SyntaxError." >>> >>> | window | >>> self halt. >>> >>> bring a debugger but with a cut stack .... >>> >>> open: aSyntaxError >>> "Answer a standard system view whose model is an instance of me." >>> <primitive: 19> >>> "Simulation guard" >>> | process | >>> process := Processor activeProcess. >>> UIManager default spawnNewProcessIfThisIsUI: process. >>> UIManager default defer: [ >>> self buildMorphicViewOn: aSyntaxError. >>> ]. >>> ^ process suspend >>> >>> so it does not really help to understand the syntax error. >>> I do not get why this is so opaque. >>> >>> Stef >>> >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> > > > > -- > Best regards, > Igor Stasenko. >

Dec. 8, 2016

Re: [Pharo-dev] about syntaxError

by Igor Stasenko

and this: <primitive: 19> "Simulation guard" is a good indication of what's gone wrong.. you are basically attempting to debug a debugger, using the very same debugger and this primitive is used throughout the debugger code to guard against such cases. On 9 December 2016 at 01:06, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 8 December 2016 at 22:56, stepharong <stepharong(a)free.fr> wrote: > >> Sorry igot but I do not understand what you are saying. >> Too tired. >> > > the exception handler if it runs in UI process does following: > - spawns new UI process, > suspending the old one, that caused exception, > then creates a debugger that showing where the original exception occur. > > but if you put halt somewhere in the middle of exception handler , you > will either create an endless loop (of attempting to bring debugger), > or, when you lucky, as in your case - it will show you debugger , where > you interrupted the exception handling, > but not the original exception. > > >> >> coz u putting exception inside an exception handler.. >> yo gawd, so you like exceptions? >> lets put an exception inside your exception, so it will be thrown while >> it thrown >> :)))))) >> (i hope everyone knows this reference :) >> >> >> On 8 December 2016 at 22:07, stepharong <stepharong(a)free.fr> wrote: >> >>> I tried to fix the extract method refactoring that seems broken when >>> extracting class or variables. >>> And I wanted to understand if I can get a debugger stack instead of this >>> useless Syntax Error: window. >>> Now I cannot find reference to SyntaxErrorDebugger. >>> still putting a break point in >>> >>> buildMorphicViewOn: aSyntaxError >>> "Answer an Morphic view on the given SyntaxError." >>> >>> | window | >>> self halt. >>> >>> bring a debugger but with a cut stack .... >>> >>> open: aSyntaxError >>> "Answer a standard system view whose model is an instance of me." >>> <primitive: 19> >>> "Simulation guard" >>> | process | >>> process := Processor activeProcess. >>> UIManager default spawnNewProcessIfThisIsUI: process. >>> UIManager default defer: [ >>> self buildMorphicViewOn: aSyntaxError. >>> ]. >>> ^ process suspend >>> >>> so it does not really help to understand the syntax error. >>> I do not get why this is so opaque. >>> >>> Stef >>> >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.

Dec. 8, 2016

Re: [Pharo-dev] about syntaxError

by Igor Stasenko

On 8 December 2016 at 22:56, stepharong <stepharong(a)free.fr> wrote: > Sorry igot but I do not understand what you are saying. > Too tired. > the exception handler if it runs in UI process does following: - spawns new UI process, suspending the old one, that caused exception, then creates a debugger that showing where the original exception occur. but if you put halt somewhere in the middle of exception handler , you will either create an endless loop (of attempting to bring debugger), or, when you lucky, as in your case - it will show you debugger , where you interrupted the exception handling, but not the original exception. > > coz u putting exception inside an exception handler.. > yo gawd, so you like exceptions? > lets put an exception inside your exception, so it will be thrown while it > thrown > :)))))) > (i hope everyone knows this reference :) > > > On 8 December 2016 at 22:07, stepharong <stepharong(a)free.fr> wrote: > >> I tried to fix the extract method refactoring that seems broken when >> extracting class or variables. >> And I wanted to understand if I can get a debugger stack instead of this >> useless Syntax Error: window. >> Now I cannot find reference to SyntaxErrorDebugger. >> still putting a break point in >> >> buildMorphicViewOn: aSyntaxError >> "Answer an Morphic view on the given SyntaxError." >> >> | window | >> self halt. >> >> bring a debugger but with a cut stack .... >> >> open: aSyntaxError >> "Answer a standard system view whose model is an instance of me." >> <primitive: 19> >> "Simulation guard" >> | process | >> process := Processor activeProcess. >> UIManager default spawnNewProcessIfThisIsUI: process. >> UIManager default defer: [ >> self buildMorphicViewOn: aSyntaxError. >> ]. >> ^ process suspend >> >> so it does not really help to understand the syntax error. >> I do not get why this is so opaque. >> >> Stef >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> >> > > > -- > Best regards, > Igor Stasenko. > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > -- Best regards, Igor Stasenko.

Dec. 8, 2016

Re: [Pharo-dev] about syntaxError

by Henrik Nergaard

Change line 3 of RBExtractMethodRefactoring>>extractMethod to something like: [ extractedParseTree := RBParser parseExpression: extractCode ] on: SyntaxErrorNotification do: [ :ex| ex debug ]. To bring up a debugger. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharong Sent: Thursday, December 8, 2016 9:08 PM To: pharo-dev(a)lists.pharo.org Subject: [Pharo-dev] about syntaxError I tried to fix the extract method refactoring that seems broken when extracting class or variables. And I wanted to understand if I can get a debugger stack instead of this useless Syntax Error: window. Now I cannot find reference to SyntaxErrorDebugger. still putting a break point in buildMorphicViewOn: aSyntaxError "Answer an Morphic view on the given SyntaxError." | window | self halt. bring a debugger but with a cut stack .... open: aSyntaxError "Answer a standard system view whose model is an instance of me." <primitive: 19> "Simulation guard" | process | process := Processor activeProcess. UIManager default spawnNewProcessIfThisIsUI: process. UIManager default defer: [ self buildMorphicViewOn: aSyntaxError. ]. ^ process suspend so it does not really help to understand the syntax error. I do not get why this is so opaque. Stef -- Using Opera's mail client: http://www.opera.com/mail/

Dec. 8, 2016