The Trunk: System-mt.826.mcz

Marcel Taeumel uploaded a new version of System to project The Trunk:
http://source.squeak.org/trunk/System-mt.826.mcz

==================== Summary ====================

Name: System-mt.826
Author: mt
Time: 9 May 2016, 1:14:47.861723 pm
UUID: ec4d495c-324c-214f-9944-0e2be7e78ec6
Ancestors: System-mt.825

Return the result of a debug-it for further processing.

=============== Diff against System-mt.825 ===============

Item was changed:
  ----- Method: Project>>debugMethod:forReceiver:inContext: (in category 'debugging') -----
  debugMethod: aCompiledMethod forReceiver: anObject inContext: aContextOrNil
  "Just execute the method and return the result. We cannot know how interactive debugging works for arbitrary projects."
 
+ ^ aCompiledMethod
- aCompiledMethod
  valueWithReceiver: anObject
  arguments: (aContextOrNil
  ifNil: [#()]
+ ifNotNil: [{aContextOrNil}])!
- ifNotNil: [{aContextOrNil}]).!

Hi Marcel, is this philosophically consistent with the change you made
to "inspect it" a while back?  You had changed "inspect it" to answer
the PluggableSystemWindow instead of the object being inspected.  Your
argument, IIRC, was that there is "no other way" to get the window.

The only persons who  ever want the PluggableWindow are IDE
developers, who could just change #inspect themself, privately, or
just add a new method and use that..

#inspect has been a USER method in Smalltalk-80 since its inception 30
years ago.  Unfortnately, it now only caters to its 2 or 3 internal
IDE developers (e.g., you and me), instead of hundreds of users who
might use #inspect as an inline debugging tool.

So, my question is, is this the same philosophy with "debug it?"  Or
is this more like the original #inspect which provided better access
to the underlying domain object being debugged?

On Mon, May 9, 2016 at 6:14 AM,  <[hidden email]> wrote:

Hi Chris,

this does not compare with Object >> inspect. I called it "debug it" because it is the thing you that happens when you click "debug it" somewhere.

We could, however, implement String >> #debugIt and return the debuggers system window. But even then, process scheduling will usually not allow you to process the result.

This somewhat compares with all the things in ToolSet and StandardToolSet. As you can see, they all return the result of the delegated call. For example, StandardToolSet >> #browse:selector:.

With the return here, new kinds of projects can use some basic means of debugging an expression, which is merely an evaluation of it. Therefore the return.

---

Anyway, you can always call #model on the result of, for example, "Morph new inspect" to get the model. :-)

Speaking of return values, I find it not good that Browser >> #openBrowserView:label: does not return the "browser view", which would be a morph in Morphic, but the model. This makes it very difficult to find the thing that was created as the view.

---

Of course, all these things affect only IDE developers. Users usually do-it things. Then, the return value does not matter at all.

Best,
Marcel