3 Dec
2013
3 Dec
'13
5:02 p.m.
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,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
3 Dec
3 Dec
6 p.m.
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…
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
10:23 p.m.
Hi,
On Tue, Dec 3, 2013 at 6:00 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote;wrote:
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
Alexandre
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
--
www.tudorgirba.com
"Every thing has its own flow"
Hi!
Here are my bits
Ok.
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.
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.
- 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…
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
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:
http://www.humane-assessment.com/blog/debugging-the-debugger-with-the-inspe…
This is why your stories are important. But, any other idea of how to
communicate these tools are more than welcome.
- what did you like?
That they work :-)
Ok :).
Cheers,
Doru
4 Dec
4 Dec
3:09 p.m.
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-inspe…
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
3:22 p.m.
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.
[image: Inline image 1]
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 <alexandre.bergel(a)me.com>wrote;wrote:
http://www.humane-assessment.com/blog/debugging-the-debugger-with-the-inspe…
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
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
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:
10:38 a.m.
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:
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,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:45 a.m.
Hi,
Thanks.
On Wed, Dec 4, 2013 at 10:38 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
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.
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
Cheers,
Diego
On Dec 3, 2013, at 5:02 PM, Tudor Girba wrote:
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,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
10:48 a.m.
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 <diego.lont(a)delware.nl> wrote:
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:
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,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:15 a.m.
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 <kilon.alios(a)gmail.com> wrote:
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 <diego.lont(a)delware.nl> wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
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:
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,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:37 p.m.
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 <tudor(a)tudorgirba.com> wrote:
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 <kilon.alios(a)gmail.com>wrote;wrote:
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 <diego.lont(a)delware.nl>wrote;wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
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,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5 Dec
5 Dec
12:05 p.m.
Hi,
On Wed, Dec 4, 2013 at 1:37 PM, kilon alios <kilon.alios(a)gmail.com> wrote:
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
> On Wed, Dec 4, 2013 at 12:15 PM, Tudor Girba <tudor(a)tudorgirba.com>
wrote:
>> 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 <kilon.alios(a)gmail.com>wrote;wrote:
> >>> 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 <diego.lont(a)delware.nl>wrote;wrote:
>> >>>> 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:
>>> >>>> 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,
>>>> Doru
>>> >>>> --
>>>> www.tudorgirba.com
>>> >>>>
"Every thing has its own flow"
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>> >>> >>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>> >>> >>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>> >> >
> >> --
>> www.tudorgirba.com
> >> "Every thing has its own
flow"
> >>
_______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
>
_______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
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.
No problem.
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.
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?
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.
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.
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?
e) I would not mind to have a menu too at least for
showing the keyboard
shortcuts.
The shortcuts should be available as hints on the buttons when they exist.
Are there any new things that this debugger offers ?
12:29 p.m.
"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 <tudor(a)tudorgirba.com> wrote:
Hi,
On Wed, Dec 4, 2013 at 1:37 PM, kilon alios <kilon.alios(a)gmail.com> wrote:
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
> On Wed, Dec 4, 2013 at 12:15 PM, Tudor Girba
<tudor(a)tudorgirba.com>wrote;wrote:
>> 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 <kilon.alios(a)gmail.com>wrote;wrote:
> >>> 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
<diego.lont(a)delware.nl>wrote;wrote:
>> >>>> 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:
>>> >>>> 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,
>>>> Doru
>>> >>>> --
>>>> www.tudorgirba.com
>>> >>>> "Every
thing has its own flow"
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>> >>> >>> >>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>> >>> >>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>> >> > > >> --
>> www.tudorgirba.com
> >> "Every thing has its own
flow"
> >>
_______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> > >
_______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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.
No problem.
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.
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?
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.
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.
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?
e) I would not mind to have a menu too at least
for showing the keyboard
shortcuts.
The shortcuts should be available as hints on the buttons when they exist.
Are there any new things that this debugger offers ?
1:28 p.m.
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
5:11 p.m.
On Thu, Dec 5, 2013 at 3:05 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
<snip>
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>
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.
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?
So, I have used it on two Windows machines, both with LCD monitors, and I 
4 Dec
4 Dec
11:05 a.m.
Le 3 déc. 2013 à 17:02, Tudor Girba a écrit :
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?
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 in one-two words (e.g., strange,
useless, frustrating, too white, funny, productive).
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.
- what problems did you find?
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).
- what did you like?
Like Alexandre that it
works ;o)
and the inspector at the bottom of the debugger.
Anne
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3:24 p.m.
Hi,
Thanks.
On Wed, Dec 4, 2013 at 11:05 AM, Anne Etien <anne.etien(a)univ-lille1.fr>wrote;wrote:
Le 3 déc. 2013 à 17:02, Tudor Girba a écrit :
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?
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.
Thanks. It annoys me, too :)
I find the inspector very fine, and useful.
- first impression in one-two words (e.g., strange, useless, frustrating,
too white, funny, productive).
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.
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?
- what problems did you find?
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
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.
I am not sure of this, but it seems that we don't
have access to the full
stack (as it was before).
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.
- what did you like?
Like Alexandre that it works ;o)
and the inspector at the bottom of the debugger.
Do you actually interact with the inspector from the debugger often?
Doru
Anne
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
4:20 p.m.
Le 4 déc. 2013 à 15:24, Tudor Girba a écrit :
I will try ;o)
If you mean the part as the bottom as I suggested, yes, very often.
Anne
Hi,
Thanks.
On Wed, Dec 4, 2013 at 11:05 AM, Anne Etien <anne.etien(a)univ-lille1.fr> wrote:
Le 3 déc. 2013 à 17:02, Tudor Girba a écrit :
No, I was not aware of, but I will definitively do.
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?
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.
Thanks. It annoys me, too :)
I find the inspector very fine, and useful.
- first impression in one-two words (e.g.,
strange, useless, frustrating, too white, funny, productive).
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.
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?
I only use the provided presentations and do not build any.
- what problems did you find?
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
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.
I am not sure of this, but it seems that we don't have access to the full stack (as
it was before).
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. - what did you like?
Like Alexandre that it works ;o)
and the inspector at the bottom of the debugger.
Do you actually interact with the inspector from the debugger often?
Doru
Anne
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3804
days inactive
3806
days old
16 comments
6 participants
participants (6)
-
Alexandre Bergel -
Anne Etien -
Chris Cunningham -
Diego Lont -
kilon alios -
Tudor Girba