gtdebugger / gtinspector feedback
Locked
gtdebugger / gtinspector feedback
 
|
Hi,
Since a while, the Moose 5.0 image comes with GTDebugger and GTInspector installed by default. These tools are already useable, but there still is a long way to go. For this, we need feedback. So:
- did you use any of them? - first impression in one-two words (e.g., strange, useless, frustrating, too white, funny, productive). - what problems did you find? - what did you like?
Cheers, _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi!
Here are my bits > Since a while, the Moose 5.0 image comes with GTDebugger and GTInspector installed by default. > > These tools are already useable, but there still is a long way to go. For this, we need feedback. So: > - did you use any of them? Yes. I use the debugger and inspector. The debugger has an annoying problem with Cmd-s: method does not get recompiled, but I can live for now with pressing an icon. The inspector is fine with me, even though I have not used it that much to navigate between objects. > - first impression in one-two words (e.g., strange, useless, frustrating, too white, funny, productive). happy > - what problems did you find? the debugger could be improved I feel. For example, consider the following screenshot: https://dl.dropboxusercontent.com/u/31543901/TMP/Screen%20Shot%202013-12-03%20at%201.55.36%20PM.png I obtained it by evaluating a self halt in a workspace. There is not enough room for showing the source code. And there is too much (white) room for the instance variables Another problem is that the benefits are not obvious since I am using the tools pretty much the same way that the standard ones. What can I get from them I think should be made more explicit and apparent. Maybe with a help icon or something? > - what did you like? That they work :-) Alexandre _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: gtdebugger / gtinspector feedback
|
|
Hi,
On Tue, Dec 3, 2013 at 6:00 PM, Alexandre Bergel <[hidden email]> wrote: Hi! Ok. The inspector is fine with me, even though I have not used it that much to navigate between objects. I see. I mentioned on other occasions, that since I am using the GTInspector I am spending much more time looking at objects than I did before. It is the sliding and the preview possibilities that makes the difference for me. I am still trying to write up the core ideas behind the GTInspector and describe some scenarios in which it is useful. Maybe this could change something.
I am not quite convinced of how to show variables either, but your example is not necessarily relevant either given that you are looking at nil and you have essentially no interest in digging into that object either. The situation is slightly different when the receiver is slightly more complicated and less easy to understand. In this case, you get a full inspector at the bottom.
Another problem is that the benefits are not obvious since I am using the tools pretty much the same way that the standard ones. What can I get from them I think should be made more explicit and apparent. Maybe with a help icon or something? I agree. Communication is essential now. The GTInspector is already different. The GTDebugger will be different once we have the three custom debuggers for Announcement, Glamour and PetitParser available (it should be soon now).
My idea is to provide a set of hands-on stories on how these tools supported some debugging/inspecting scenario. For example like this one: This is why your stories are important. But, any other idea of how to communicate these tools are more than welcome.
Ok :). Cheers, Doru Alexandre "Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
Hi,
I use the inspector a lot, and I am very happy with it. I am not sure I use the debugger, I do not think so. Inspector is very productive. No big issues I like it that it gives me a context sensitive view, this really makes debugging faster. Cheers, Diego On Dec 3, 2013, at 5:02 PM, Tudor Girba wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: gtdebugger / gtinspector feedback
|
|
Hi,
Thanks. On Wed, Dec 4, 2013 at 10:38 AM, Diego Lont <[hidden email]> wrote:
Can you be more specific? Do you have some specific scenarios you can recount? Also, have you extended the GTInspector for your own objects? Cheers,
Doru
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: gtdebugger / gtinspector feedback
|
In reply to this post by DiegoLont
I only briefly tried the Moose image for the shake of trying Roassal. I hope we talking about the same debugger. All this white burns my eyes, very hard to concentrate on. Source code is on the right side away from my central focus. I could not find the proceed button , restart etc I see only a few buttons. Overall I dont like the debugger , I cant say I find anything that is better than the one used by Pharo.
On Wed, Dec 4, 2013 at 11:38 AM, Diego Lont <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: gtdebugger / gtinspector feedback
|
|
In reply to this post by Tudor Girba-2
Le 3 déc. 2013 à 17:02, Tudor Girba a écrit :
I use both of them. I agree with Alexandre concerning the annoying problem with Cmd-s. What is annoying, is that the orange right top corner is disappearing when clicking on cmd-s (like every else where), so we get a feedback but the code is not changed. I lost several time my changes. But it is also true that I can press a button for the moment. I find the inspector very fine, and useful. First impression was strange like always when you get a change ;o). Passing through this change, I find the inspector very good, because we can navigate through object and go back without having ten opened windows.
My major problem concerns the debugger. I don't know how to modify this by default, but when a debugger appears, the window is very small. The first thing I have to do is making the windows bigger and let more space for the code it self, in order to read it comfortably. It is not a big thing but when you do it tens times a day it becomes annoying. https://dl.dropboxusercontent.com/u/2801197/debugger.pdf I am not sure of this, but it seems that we don't have access to the full stack (as it was before).
Like Alexandre that it works ;o) and the inspector at the bottom of the debugger. Anne _______________________________________________ _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: gtdebugger / gtinspector feedback
|
|
In reply to this post by kilon.alios
Hi, Thanks :) What do you mean with "it burns your eyes"? Do you refer to it being white? In any case, I am happy that your main concerns seem to stem from less conceptual issues like small buttons and layout. The less prominent buttons do not worry me and they will likely not change because they are uniformly treated like that in all the Glamour browsers - and thus you get easily used to it.
The observation about the code is interesting, though. Should I understand that you find that having the code on the right hand side is less intuitive than having it at the bottom? Or is there something else you mean?
Cheers, Doru On Wed, Dec 4, 2013 at 10:48 AM, kilon alios <[hidden email]> wrote:
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: gtdebugger / gtinspector feedback
|
|
Ok apparently I was not as clear as intended to. a) Sorry about the buttons I completely missed them, so apparently the functionality is there. I thought it was not there, My mistake.
b) About the color white yes, I have an issue there, let me be more specific , I can barely see the scrollbars. I can't even find the scroll area since everything is white.
c) Yes source code in the right side makes no sense to me. You have the instance variables at the bottom and you waste so much space. why ? While source code on the right crammed and the window will need to be expanded for long lines. Also source code should be the center of the focus so it should be in the center , this where the eye will dwell the most during debugging. Instance variables should go at the right, source code at the bottom. d) Yes buttons could be bigger, I see no reason for them to be so small, e) I would not mind to have a menu too at least for showing the keyboard shortcuts. Are there any new things that this debugger offers ? On Wed, Dec 4, 2013 at 12:15 PM, Tudor Girba <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
> My idea is to provide a set of hands-on stories on how these tools supported some debugging/inspecting scenario. For example like this one:
> http://www.humane-assessment.com/blog/debugging-the-debugger-with-the-inspector The idea is to insert in my classes a method like: gtInspectorSourceIn: composite <gtInspectorPresentationOrder: 30> … ? Not sure to understand Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: gtdebugger / gtinspector feedback
|
|
Exactly. The main idea is that you custom views for your objects. For example, when looking at a Glamour Browser object you see its structure visually. This can be pretty important when debugging such browsers.  The way you add this is: GLMBrowser>>gtInspectorOpenTreeIn: composite
<gtInspectorPresentationOrder: 30> composite roassal title: 'Tree';
painting: [:view :b | b viewTreeOn: view ] I also recently extended ROView with a simple display to show a simple tree of elements. This again can be useful when debugging the creation of views:
gtInspectorElementsHierarchyIn: composite <gtInspectorPresentationOrder: 20> composite tree
title: 'Elements'; display: [ :each | {each} ]; children: #elements
But, here is another thing. Because it is directly in the code of the object, you can even use the Methods editor for each object to extend the inspector from within the inspector while inspecting :). The UI is not yet what it should or could be, but it does create new possibilities. This is similar to what happens in Moose when during analysis we realize that we need a visualization, so we switch to an easel, write the visualization and continue the interaction with the objects directly there. This can be very powerful if done right.
Doru On Wed, Dec 4, 2013 at 3:09 PM, Alexandre Bergel <[hidden email]> wrote:
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: gtdebugger / gtinspector feedback
|
|
In reply to this post by Anne Etien
Hi,
Thanks. On Wed, Dec 4, 2013 at 11:05 AM, Anne Etien <[hidden email]> wrote:
Thanks. It annoys me, too :)
Interesting. Are you using Cmd+o (instead of Cmd+i) to open the result of a script objects on the next pane? Also, are you using multiple views on your objects? Have you built your own presentations? Or do you mostly use the instance variables presentation?
Agreed. What is even worse is that if you resize the debugger window and then resume the execution, if you get another exception along the way, the debugger is back to the small size and you essentially lose visual context. This is terrible and will be fixed. At the moment, I think that the debugger should be spawned maximized.
Of course you do. Actually, you always look at the full stack (or at least should if there is no bug) :). Try this: | aClass | aClass := (Object subclass: #A
instanceVariableNames: ''
classVariableNames: '' poolDictionaries: '' category: 'A').
aClass compile: 'do: anInteger anInteger > 10000 ifTrue: [ self halt ]. self do: anInteger + 1'.
aClass new do: 1 If you execute this, you will get a stack list of 9999 items.
Do you actually interact with the inspector from the debugger often? Doru
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: gtdebugger / gtinspector feedback
|
|
Le 4 déc. 2013 à 15:24, Tudor Girba a écrit :
No, I was not aware of, but I will definitively do.
I only use the provided presentations and do not build any.
If you mean the part as the bottom as I suggested, yes, very often. Anne
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: gtdebugger / gtinspector feedback
|
|
In reply to this post by kilon.alios
Hi,
On Wed, Dec 4, 2013 at 1:37 PM, kilon alios <[hidden email]> wrote:
No problem.
This is the issue of the theme. I think this is observed only on certain screens: the gray becomes too white. I actually only saw this problem with my own eyes when connecting a crappy windows laptop to a projector. But, I am not sure this is the problem you are reporting. So just to check, now that we are at it, when you open Nautilus, do you see the scrollbar? How about the background of the Hierarchy button?
I disagree that the code is the first thing to look at, but in any case I now made the code pane larger and the inspector smaller. The inspector at the bottom might appear white at first, but it is a fully interactive interface that can spawn other panes to the right.
Indeed, I would also love to get scalable icons. I think they should come rather soon, but until then, the icons will remain like they are now. Is anyone interested in looking into importing SVG as icons and making them available as a library of icons? I know that Alex looked into that, but I think he is stuck. Alex?
The shortcuts should be available as hints on the buttons when they exist.
Several things: - it is extensible: you can build your own debuggers with your own specific actions and views. The goal is to redefine debugging: the debugger did not change its shape essentially since decades and as a consequence we are still only looking at raw stacks when debugging. We want domain specific debuggers in which libraries come with their own debugger. Andrei will release a couple of such debuggers soon to give people an idea of what can be done (for PetitParser, Glamour, Announcements, and an SUnit specific enhancement).
- it is tiny: 500 loc. This is particularly important to make debuggers be tangible for mere mortals (like me). You can actually learn about a debugger by reading its code in your lunch break. It's highly instructive. In fact, if you want to change the way it looks, you should be able to play with it in that break, too :).
Cheers, Doru
"Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: gtdebugger / gtinspector feedback
|
|
"Several things: - it is extensible: you can build your own debuggers with your own specific actions and views. The goal is to redefine debugging: the debugger did not change its shape essentially since decades and as a consequence we are still only looking at raw stacks when debugging. We want domain specific debuggers in which libraries come with their own debugger. Andrei will release a couple of such debuggers soon to give people an idea of what can be done (for PetitParser, Glamour, Announcements, and an SUnit specific enhancement).
- it is tiny: 500 loc. This is particularly important to make debuggers be tangible for mere mortals (like me). You can actually learn about a debugger by reading its code in your lunch break. It's highly instructive. In fact, if you want to change the way it looks, you should be able to play with it in that break, too :)."
Very interesting , thanks for sharing. I am very new with Pharo , looks like I have still tons to learn :) About Nautilus yes your colors seem more washed out than the ones used by standard Pharo for their instance of Nautilus. Dont know why. For example the packages scrollbar in Moose Nautilus is complete invisible while in Pharo Nautilus I can see it , barely , but I can.
But yes I generally dont like how Specs with its overuse of white that makes it hard for me to read code. I am also looking into implementing a dark theme for pharo. And my eyes have birghtness issues , sunglasses during summer is a must for me and I set my monitors always on lowest brightness. My eyes get tired easily. So take my opinion with a grain of salt , I just dislike non dark themes.
On Thu, Dec 5, 2013 at 1:05 PM, Tudor Girba <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
> d) Yes buttons could be bigger, I see no reason for them to be so small,
> > Indeed, I would also love to get scalable icons. I think they should come rather soon, but until then, the icons will remain like they are now. Is anyone interested in looking into importing SVG as icons and making them available as a library of icons? I know that Alex looked into that, but I think he is stuck. Alex? If you have icons that do make any use of bezier curves then there is no problem in importing them. http://iconmonstr.com could be a good starting point. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Tudor Girba-2
On Thu, Dec 5, 2013 at 3:05 AM, Tudor Girba <[hidden email]> wrote: <snip>
So, I have used it on two Windows machines, both with LCD monitors, and I am also unable to find the scroll bar at all (it just has no color that my eyes can see). Maybe you should look at more windows boxes with other monitors that you can find - seems like that might be the common factor.
As mentioned last time, I hack the code to make the bars darker so they show up for me. -cbc <snip> _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |