Smalltalk › Pharo › Pharo Smalltalk Users

Using the Debugger to write code

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

14 messages Options

horrido

Using the Debugger to write code

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.

K K Subbu

Re: Using the Debugger to write code

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

Marcus Denker-4

Re: Using the Debugger to write code

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:

Sven Van Caekenberghe-2

Re: Using the Debugger to write code

> 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.

philippeback

Re: Using the Debugger to write code

In reply to this post by K K Subbu

What is not working? Check this:

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

Now hit Create and define the method.

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

Sven Van Caekenberghe-2

Re: Using the Debugger to write code

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
>
>
>

philippeback

Re: Using the Debugger to write code

(#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
>
>
>

Marcus Denker-4

Re: Using the Debugger to write code

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

Marcus Denker-4

Re: Using the Debugger to write code

> 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

K K Subbu

Re: Using the Debugger to write code

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

Denis Kudriashov

Re: Using the Debugger to write code

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.

Marcus Denker-4

Re: Using the Debugger to write code

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

Marcus Denker-4

Re: Using the Debugger to write code

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

Marcus Denker-4

Re: Using the Debugger to write code

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:

https://pharo.fogbugz.com/f/cases/20254/Playground-should-ask-to-create-class-for-non-Existing-Globals

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

the requestorscope as needed.

Marcus