Using the Debugger to write code

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Using the Debugger to write code

horrido
The Pharo By Example book says that you can use the Debugger to write code. So if you have a "does not understand" error, you're given the option of Creating a new method. That's cool.

But for the life of me, I can't figure out how to create new classes for my application from within the Debugger. Must I create new classes using the System Browser first before I can continue adding new methods from within the Debugger? What's the recommended procedure for all this?

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

K K Subbu
On Wednesday 12 July 2017 08:33 AM, horrido wrote:
> But for the life of me, I can't figure out how to create new classes for my
> application from within the Debugger. Must I create new classes using the
> System Browser first before I can continue adding new methods from within
> the Debugger? What's the recommended procedure for all this?

Not necessarily. In Pharo, everything happens through message sends.
Classes are created by sending any one of subclass:* family of messages
to the parent class. System Browser makes it convenient by adding a
template to its bottom text panel. Magic happens in the subclass:*
message sends.

When you "inspect" an object in the Debugger, a text panel will open up
along the right side where you can type in a command just like in System
Browser and "doIt". E.g. to create a subclass from Object.

    Object subclass: ...

HTH .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

Marcus Denker-4

On 12 Jul 2017, at 08:35, K K Subbu <[hidden email]> wrote:

On Wednesday 12 July 2017 08:33 AM, horrido wrote:
But for the life of me, I can't figure out how to create new classes for my
application from within the Debugger. Must I create new classes using the
System Browser first before I can continue adding new methods from within
the Debugger? What's the recommended procedure for all this?


If you add a global variable that does not exist and save the method, you should get
a dialog like this, with “Define new class” as the first option:

Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

Sven Van Caekenberghe-2

> On 12 Jul 2017, at 08:42, Marcus Denker <[hidden email]> wrote:
>
>
>> On 12 Jul 2017, at 08:35, K K Subbu <[hidden email]> wrote:
>>
>> On Wednesday 12 July 2017 08:33 AM, horrido wrote:
>>> But for the life of me, I can't figure out how to create new classes for my
>>> application from within the Debugger. Must I create new classes using the
>>> System Browser first before I can continue adding new methods from within
>>> the Debugger? What's the recommended procedure for all this?
>>
>
> If you add a global variable that does not exist and save the method, you should get
> a dialog like this, with “Define new class” as the first option:
>
> <Untitled.jpg>

Yes, that is it.

From a Playground/Workspace this does not work, but I vaguely remember that it used to, no ?

Then you could start by just pretending your class existed:

MyClass new doSomething. <doit>

First dialog should be MyClass does not exist, do you want to create it ?

Once created, restart and DNU for #doSomething and option to create a new method.


Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

philippeback
In reply to this post by K K Subbu
What is not working? Check this:

Inline image 1

Hit Define new class and just accept what is proposed, then proceed

Inline image 2

Now hit Create and define the method.

Inline image 3

etc etc for usual coding.

Best,
Phil

On Wed, Jul 12, 2017 at 8:35 AM, K K Subbu <[hidden email]> wrote:
On Wednesday 12 July 2017 08:33 AM, horrido wrote:
But for the life of me, I can't figure out how to create new classes for my
application from within the Debugger. Must I create new classes using the
System Browser first before I can continue adding new methods from within
the Debugger? What's the recommended procedure for all this?

Not necessarily. In Pharo, everything happens through message sends.
Classes are created by sending any one of subclass:* family of messages to the parent class. System Browser makes it convenient by adding a template to its bottom text panel. Magic happens in the subclass:* message sends.

When you "inspect" an object in the Debugger, a text panel will open up along the right side where you can type in a command just like in System Browser and "doIt". E.g. to create a subclass from Object.

   Object subclass: ...

HTH .. Subbu



Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

Sven Van Caekenberghe-2
Yes, but these are all inside the method editor.

I wanted to start with

(Motivation fromString: 'foo') sayIt.

in a playground/workspace.

But with just a DNU it works.

> On 12 Jul 2017, at 08:49, [hidden email] wrote:
>
> What is not working? Check this:
>
> <image.png>
>
> Hit Define new class and just accept what is proposed, then proceed
>
> <image.png>
>
> Now hit Create and define the method.
>
> <image.png>
>
> etc etc for usual coding.
>
> Best,
> Phil
>
> On Wed, Jul 12, 2017 at 8:35 AM, K K Subbu <[hidden email]> wrote:
> On Wednesday 12 July 2017 08:33 AM, horrido wrote:
> But for the life of me, I can't figure out how to create new classes for my
> application from within the Debugger. Must I create new classes using the
> System Browser first before I can continue adding new methods from within
> the Debugger? What's the recommended procedure for all this?
>
> Not necessarily. In Pharo, everything happens through message sends.
> Classes are created by sending any one of subclass:* family of messages to the parent class. System Browser makes it convenient by adding a template to its bottom text panel. Magic happens in the subclass:* message sends.
>
> When you "inspect" an object in the Debugger, a text panel will open up along the right side where you can type in a command just like in System Browser and "doIt". E.g. to create a subclass from Object.
>
>    Object subclass: ...
>
> HTH .. Subbu
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

philippeback
(#Motivation asClass fromString: 'a') sayIt

is not working better :-)

Should.

Phil

On Wed, Jul 12, 2017 at 8:54 AM, Sven Van Caekenberghe <[hidden email]> wrote:
Yes, but these are all inside the method editor.

I wanted to start with

(Motivation fromString: 'foo') sayIt.

in a playground/workspace.

But with just a DNU it works.

> On 12 Jul 2017, at 08:49, [hidden email] wrote:
>
> What is not working? Check this:
>
> <image.png>
>
> Hit Define new class and just accept what is proposed, then proceed
>
> <image.png>
>
> Now hit Create and define the method.
>
> <image.png>
>
> etc etc for usual coding.
>
> Best,
> Phil
>
> On Wed, Jul 12, 2017 at 8:35 AM, K K Subbu <[hidden email]> wrote:
> On Wednesday 12 July 2017 08:33 AM, horrido wrote:
> But for the life of me, I can't figure out how to create new classes for my
> application from within the Debugger. Must I create new classes using the
> System Browser first before I can continue adding new methods from within
> the Debugger? What's the recommended procedure for all this?
>
> Not necessarily. In Pharo, everything happens through message sends.
> Classes are created by sending any one of subclass:* family of messages to the parent class. System Browser makes it convenient by adding a template to its bottom text panel. Magic happens in the subclass:* message sends.
>
> When you "inspect" an object in the Debugger, a text panel will open up along the right side where you can type in a command just like in System Browser and "doIt". E.g. to create a subclass from Object.
>
>    Object subclass: ...
>
> HTH .. Subbu
>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

Marcus Denker-4
In reply to this post by Sven Van Caekenberghe-2

> On 12 Jul 2017, at 08:54, Sven Van Caekenberghe <[hidden email]> wrote:
>
> Yes, but these are all inside the method editor.
>
> I wanted to start with
>
> (Motivation fromString: 'foo') sayIt.
>
> in a playground/workspace.

in the workspace it creates a variable (with value nil)… so it treats upper-case
unknown vars the same as lower case.

I think it might make sense to have for upper case instead the menu that asks
what to do (it could there have a “add binding to workspace” entry for the current
way, too)

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

Marcus Denker-4

> On 12 Jul 2017, at 09:09, Marcus Denker <[hidden email]> wrote:
>
>
>> On 12 Jul 2017, at 08:54, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> Yes, but these are all inside the method editor.
>>
>> I wanted to start with
>>
>> (Motivation fromString: 'foo') sayIt.
>>
>> in a playground/workspace.
>
> in the workspace it creates a variable (with value nil)… so it treats upper-case
> unknown vars the same as lower case.
>
> I think it might make sense to have for upper case instead the menu that asks
> what to do (it could there have a “add binding to workspace” entry for the current
> way, too)
>

for the #asClass case it is more complex.

The compiler knows two modes:
“Interactive” and not. So if there is a undeclared var, it will in interactive
mode ask the user what to do, but when compiling non-interactively it
will just add the var to Undeclared (with a nil value) and compile a binding
to that.

Now #asClass happens not at compile-time, but at runtime. The compiler can
not do anything (it’s just a message send), and at runtime we do *not* model
“interactive use” vs. not.

Now if you look at Denis enhancement of the test execution, there is now

CurrentExecutionEnvironment value

which allows us at runtime to check if we run a test (and which). Now
we could extend that and model “interactive use” vs. “non-interactive” in
addition.

Then code like #asClass could ask the user in interactive mode to create
a non-existing class.

But the question is if we would want that…

(I like the idea of modelling interactive vs. not using the execution
environment, though).

        Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

K K Subbu
On Wednesday 12 July 2017 01:36 PM, Marcus Denker wrote:
> The compiler knows two modes:
> “Interactive” and not. So if there is a undeclared var, it will in interactive
> mode ask the user what to do, but when compiling non-interactively it
> will just add the var to Undeclared (with a nil value) and compile a binding
> to that.

If I run

        Motivation fromString: 'loo'

from Playground or Inspector, I get a DNU window for #fromString not a
prompt for defining this variable. Shouldn't Playground/Inspector be
considered interactive? Why is Motivation assumed undeclared?

Curious .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

Denis Kudriashov
In reply to this post by Marcus Denker-4

2017-07-12 9:09 GMT+02:00 Marcus Denker <[hidden email]>:
in the workspace it creates a variable (with value nil)… so it treats upper-case
unknown vars the same as lower case.

I think it might make sense to have for upper case instead the menu that asks
what to do (it could there have a “add binding to workspace” entry for the current
way, too)

I would prefer same behaviour like in method editor. I really hate when I made mistake in class name and after evaluation I got uppercase binding with nil value. 
Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

Marcus Denker-4

On 12 Jul 2017, at 10:46, Denis Kudriashov <[hidden email]> wrote:


2017-07-12 9:09 GMT+02:00 Marcus Denker <[hidden email]>:
in the workspace it creates a variable (with value nil)… so it treats upper-case
unknown vars the same as lower case.

I think it might make sense to have for upper case instead the menu that asks
what to do (it could there have a “add binding to workspace” entry for the current
way, too)

I would prefer same behaviour like in method editor. I really hate when I made mistake in class name and after evaluation I got uppercase binding with nil value. 

yes, we should fix it. binding should just be created for lower case vars.

Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

Marcus Denker-4

On 12 Jul 2017, at 10:51, Marcus Denker <[hidden email]> wrote:


On 12 Jul 2017, at 10:46, Denis Kudriashov <[hidden email]> wrote:


2017-07-12 9:09 GMT+02:00 Marcus Denker <[hidden email]>:
in the workspace it creates a variable (with value nil)… so it treats upper-case
unknown vars the same as lower case.

I think it might make sense to have for upper case instead the menu that asks
what to do (it could there have a “add binding to workspace” entry for the current
way, too)

I would prefer same behaviour like in method editor. I really hate when I made mistake in class name and after evaluation I got uppercase binding with nil value. 

yes, we should fix it. binding should just be created for lower case vars.


How to fix it:

OCRequestorScope is the scope of variables in tools. #lookupVar: is the method that is doing the lookup.

replace the code

global := self lookupGlobalVar: name.
global ifNotNil: [ ^ global ].  

with:

name first isUppercase ifTrue: [ ^ outerScope lookupVar: name].

But: right now we abuse the requesterscope to implement the feature that you can hand
in an additional dictionary with bindings. See testEvaluateWithBindingsWithUppercaseName
This change breaks this feature… but it just means we need to implement this better, which 
I will do .

Marcus 

Reply | Threaded
Open this post in threaded view
|

Re: Using the Debugger to write code

Marcus Denker-4

2017-07-12 9:09 GMT+02:00 Marcus Denker <[hidden email]>:
in the workspace it creates a variable (with value nil)… so it treats upper-case
unknown vars the same as lower case.

I think it might make sense to have for upper case instead the menu that asks
what to do (it could there have a “add binding to workspace” entry for the current
way, too)

I would prefer same behaviour like in method editor. I really hate when I made mistake in class name and after evaluation I got uppercase binding with nil value. 

yes, we should fix it. binding should just be created for lower case vars.


How to fix it:

OCRequestorScope is the scope of variables in tools. #lookupVar: is the method that is doing the lookup.

replace the code

global := self lookupGlobalVar: name.
global ifNotNil: [ ^ global ].  

with:

name first isUppercase ifTrue: [ ^ outerScope lookupVar: name].

But: right now we abuse the requesterscope to implement the feature that you can hand
in an additional dictionary with bindings. See testEvaluateWithBindingsWithUppercaseName
This change breaks this feature… but it just means we need to implement this better, which 
I will do .

For Pharo6:


This adds a scope for additional bindings and uses this for the bindings, which then allows us to change
the requestorscope as needed.

    Marcus