#browseMethodHistory in Debugger

Ian,

You've probably noticed by now that the base system in beta two has
menu options to cater for your Method History Extension.

I've also now added the Changes submenu to the debugger, so that one
can browse the changes to the method currently under investigation and
possibly install a previous version, if required. I wonder therefore if
you could add a #browseMethodHistory into the debugger as a loose
method for your Method History Extension?

best regards

--
Andy Bower
Dolphin Support
www.object-arts.com

Andy,

> You've probably noticed by now that the base system in beta two has
> menu options to cater for your Method History Extension.

I noticed the additional menu options this morning, and wondered what
they were, but as I couldn't get them enabled (I was running a base
image without my extensions) I had put them into the "have a look at
later" pile :-)

> I've also now added the Changes submenu to the debugger, so that one
> can browse the changes to the method currently under investigation and
> possibly install a previous version, if required. I wonder therefore if
> you could add a #browseMethodHistory into the debugger as a loose
> method for your Method History Extension?

Will do, I'll also remove the MethodHistoryBrowser's IdeExtension
methods from my package to avoid doubling up the menu options.

If you want to make the MethodHistoryBrowser a more permanent addition
to the image then feel free to take it and integrate it in any way you
see fit.  You'll probably want to tidy it up a bit first though :-)  The
only sneaky bit is making the sml/chg file searches as fast as possible.

Regards
        Ian

Andy,

> I've also now added the Changes submenu to the debugger, so that one
> can browse the changes to the method currently under investigation and
> possibly install a previous version, if required.

I've been having a play with this but I'm not sure what should be happening?

If I am debugging and modify, in an external browser, the method that
the Debugger is currently displaying should the Debugger automatically
reflect the changes and do a restart on the method?.  That's what I was
expecting to happen but, although the Debugger receives an
#onMethodUpdated notification, it just seems to ignore the changes until
I do a manual restart.

Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
Correct, because unwinding the stack changes the state of the computation,
which you may not want (remember it might involve unwinding the stack to way
below the top frame). When you modify a method outside the debugger it
highlights the frames as "unbound" so you know the code you are looking at
is not the current code. When you modify a method in the debugger itself it
will normally restart the method, as this probably is what you want in that
case.

Regards

Blair

Blair,

> is not the current code. When you modify a method in the debugger itself it
> will normally restart the method, as this probably is what you want in that
> case.

Thanks for the clarification.  I'll have a look into changing the
HistoryBrowser so it asks the requesting tool to restore a method.  That
way I can just let the recompilation cause the source update in the
normal browsers but can also make it generate a restart in the Debugger.

In the Debugger I would think that restoring source from the change log
should be the same as modifying a method manually (as above)and would
justify the restart?

Ian

Andy,

> I've also now added the Changes submenu to the debugger, so that one
> can browse the changes to the method currently under investigation and
> possibly install a previous version, if required. I wonder therefore if
> you could add a #browseMethodHistory into the debugger as a loose
> method for your Method History Extension?

I've revamped the MethodHistory package to make is a bit more amenable
to being added to the base image.  I can send you a copy if you wish?

Basically...

#browseMethodHistory now only appears in...
ClassBrowserAbstract
Debugger
MethodExplorerShell

#browseMethodHistoryForClass only appears in...
ClassBrowserAbstract

Each of the above classes has also got a
#canBrowseMethodHistory(ForClass) method which you can use in the
appropriate #queryCommand method to check whether the submenu option
should be enabled.

If a change is made to a method in the Debugger then the selected method
is restarted to reflect the changes.

Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
> ...
> In the Debugger I would think that restoring source from the change log
> should be the same as modifying a method manually (as above)and would
> justify the restart?

I agree.

Regards

Blair

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
Yes please do if you want it included.

Thanks

Blair