Hi, I am trying to set the GTInspector as the default explorer. However, I see that the inspector registration has changed. It seems to me that registering to #objectExplorer has no effect. Instead, we are now sending #inspect: and #explore to the #inspector: Object>>explore ^Smalltalk tools inspector explore: self I do not quite see the rationale behind the current design. Furthermore, Smalltalk tools still has an entry for #objectExplorer: (Smalltalk tools instVarNamed: #tools) at: #objectExplorer ==> ObjectExplorer Anyway, I added #inspect: and #explore: to GTInspector class, and I registered it as the #inspector. It seems fine, but the problem now is that the default Spec-based debugger relies on a #inspectorSpec method in the inspector class. This is highly problematic and I am stuck. I think we should not introduce Spec-specific requirements at such a basic level. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
On 01 Nov 2013, at 22:49, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am trying to set the GTInspector as the default explorer.
However, I see that the inspector registration has changed. It seems to me that registering to #objectExplorer has no effect. Instead, we are now sending #inspect: and #explore to the #inspector:
Object>>explore ^Smalltalk tools inspector explore: self
I do not quite see the rationale behind the current design.
With the new inspector, the inspector and explorer are the same tool. If you open a normal inspector, you can even turn it into an explorer with a keyboard shortcut. Therefore it makes conceptually no sense to have a #objectExplorer tool. There was a basicInspector in the tools, too, which is now gone. Explorers are just special inspectors, like the special inspectors for CompiledMethod or Dictionary, just available for all classes.
Furthermore, Smalltalk tools still has an entry for #objectExplorer: (Smalltalk tools instVarNamed: #tools) at: #objectExplorer ==> ObjectExplorer
It should not. I thought I removed it. ObjectExplorer should be removed eventually (it is now only used for the PointerExplorer, which is a subclass).
Anyway, I added #inspect: and #explore: to GTInspector class, and I registered it as the #inspector. It seems fine, but the problem now is that the default Spec-based debugger relies on a #inspectorSpec method in the inspector class.
This is highly problematic and I am stuck. I think we should not introduce Spec-specific requirements at such a basic level.
It should normally not âleakâ that the inspector is implemented with Spec, you should be able to replace the inspector (via Smalltalk tools) with another one. So this should be checked and fixed. But it is clear that we can not have all the tools âin a crap version in the kernelâ and âthat version that everyone usesâ. This Philosophy is *wrong* just the same for tools as it is for libraries. Marcus
On 02 Nov 2013, at 07:18, Marcus Denker <marcus.denker@inria.fr> wrote:
It should not. I thought I removed it. ObjectExplorer should be removed eventually (it is now only used for the PointerExplorer, which is a subclass).
Anyway, I added #inspect: and #explore: to GTInspector class, and I registered it as the #inspector. It seems fine, but the problem now is that the default Spec-based debugger relies on a #inspectorSpec method in the inspector class.
I think this can be easily fixed: somewhere in the Debugger, it calls Smalltalk tools inspector where it should hard-code EyeInspector, as the Debugger require this specific implementation. Now finding that place⦠I will check Marcus
Exactly. That would be the solution I would favor as well. Doru On Sat, Nov 2, 2013 at 8:15 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 02 Nov 2013, at 07:18, Marcus Denker <marcus.denker@inria.fr> wrote:
It should not. I thought I removed it. ObjectExplorer should be removed eventually (it is now only used for the PointerExplorer, which is a subclass).
Anyway, I added #inspect: and #explore: to GTInspector class, and I registered it as the #inspector. It seems fine, but the problem now is that the default Spec-based debugger relies on a #inspectorSpec method in the inspector class.
I think this can be easily fixed: somewhere in the Debugger, it calls Smalltalk tools inspector where it should hard-code EyeInspector, as the Debugger require this specific implementation. Now finding that place⦠I will check
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
I opened an issue: https://pharo.fogbugz.com/f/cases/12055/The-Spec-Debugger-should-not-require... Doru On Sat, Nov 2, 2013 at 9:44 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Exactly. That would be the solution I would favor as well.
Doru
On Sat, Nov 2, 2013 at 8:15 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 02 Nov 2013, at 07:18, Marcus Denker <marcus.denker@inria.fr> wrote:
It should not. I thought I removed it. ObjectExplorer should be removed eventually (it is now only used for the PointerExplorer, which is a subclass).
Anyway, I added #inspect: and #explore: to GTInspector class, and I registered it as the #inspector. It seems fine, but the problem now is that the default Spec-based debugger relies on a #inspectorSpec method in the inspector class.
I think this can be easily fixed: somewhere in the Debugger, it calls Smalltalk tools inspector where it should hard-code EyeInspector, as the Debugger require this specific implementation. Now finding that place⦠I will check
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Hi Marcus, On Sat, Nov 2, 2013 at 7:17 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 01 Nov 2013, at 22:49, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
I am trying to set the GTInspector as the default explorer.
However, I see that the inspector registration has changed. It seems to me that registering to #objectExplorer has no effect. Instead, we are now sending #inspect: and #explore to the #inspector:
Object>>explore ^Smalltalk tools inspector explore: self
I do not quite see the rationale behind the current design.
With the new inspector, the inspector and explorer are the same tool. If you open a normal inspector, you can even turn it into an explorer with a keyboard shortcut. Therefore it makes conceptually no sense to have a #objectExplorer tool. There was a basicInspector in the tools, too, which is now gone.
Explorers are just special inspectors, like the special inspectors for CompiledMethod or Dictionary, just available for all classes.
I agree that the explorer is like the inspector. But, if now they are the same, I do not see why we need to distinguish between them. I would leave only #inspect (no more #explore) around. However, a stripped down basic inspector can still be useful as a fallback solution in case the fancy one fails given that it relies on much more widgets that can cause exceptions. For example, try this in a fresh Pharo 3.0 image: Smalltalk tools explore You will get an exception. Having a basic inspector around is useful in this case. As it is now, the basic inspector is wrapped in a more complex widget which can induce errors in the future, and we get stuck. So, all in all, I argue that we need a basic inspector mapped on a more complicated keyboard shortcut.
Furthermore, Smalltalk tools still has an entry for #objectExplorer:
(Smalltalk tools instVarNamed: #tools) at: #objectExplorer ==> ObjectExplorer
It should not. I thought I removed it. ObjectExplorer should be removed eventually (it is now only used for the PointerExplorer, which is a subclass).
Yes, I know. I was just pointing this out to show that I looked and that I was not sure of the current state.
Anyway, I added #inspect: and #explore: to GTInspector class, and I registered it as the #inspector. It seems fine, but the problem now is that the default Spec-based debugger relies on a #inspectorSpec method in the inspector class.
This is highly problematic and I am stuck. I think we should not introduce Spec-specific requirements at such a basic level.
It should normally not âleakâ that the inspector is implemented with Spec, you should be able to replace the inspector (via Smalltalk tools) with another one. So this should be checked and fixed.
Ok.
But it is clear that we can not have all the tools âin a crap version in the kernelâ and âthat version that everyone usesâ. This Philosophy is *wrong* just the same for tools as it is for libraries.
+100. I completely agree that the core needs powerful tools. That is why I actually argued for Glamour in that base image a long time ago. I still want to make that argument, but this is a discussion for another time :). Doru
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
participants (2)
-
Marcus Denker -
Tudor Girba