Re: [racket-dev] stepper UI question

[Everett Morse]

I was just trying to debug a program today that goes through a series of 
complex macros.  I used Check Syntax so I can see what variables are 
bound where (some of which are syntax variables), and when I got stuck I 
wanted to see how the macro reduces.  I clicked the macro stepper, and 
it spun for a long time before crashing Racket (this is the dev version, 
5.0.1.7--2010-10-04).


It occurred to me then that the best way to do this would be to select 
some piece of code in the editor and tell DrRacket to expand it, but 
just that one spot. (It would have to know the macros defined in the 
editor, but I already ran check syntax and the code is already compiled, 
so somewhere it ought to be able to grab the definitions.)  This would 
avoid a long wait for parts I'm not interested in.  If I was stupid 
enough to select code that does expand right, that's my fault.


Anyway, this probably isn't easy, practical, etc.  But it is what I 
naturally looked for and so I consider it the ideal.  The macro stepper, 
as is, is too slow and hard to focus in on the right place.


-Everett

On 08/27/2010 07:39 AM, Shriram Krishnamurthi wrote:

I can think of many different ways to make the stepper-definition
correspondence manifest.   As John said, I once suggested that the code
should be reduced in-place, in the definition window. Shriram doesn't
like that idea (but he has never bothered to say why.)
 

That's right, I didn't.

Here's why.  It introduces subtle state into the editor.

If you start stepping, and then try to Save, are you saving the
stepped version or the original?

If you start stepping, forget that you are doing that, and then start
editing, what are you editing?

If you step, does it affect the unsavedness of the editor?
(Presumably not.)

If I have a textual program, and step, does it next save in graphical
format?  (I wouldn't want that.)

One way to prevent some of the more egregious problems is to make
stepping a mode.  That brings its own problems -- how do you make it
not suck, how do you focus attention on it, etc.

I think people have a clear model of what an editor is: it's like
Word, like the text box of GMail, etc.  Each one offers some
highlighting feedback and some rich-text editing -- but it's just an
editor.  It's not a place where programs run.  Putting the stepper
into the editor in a model way really messes with that.

I certainly agree with you (and have always agreed with you, for the
many years we've talked about this) that losing the correspondence to
the source program is a problem.  But I don't think putting it in the
editor is the solution.  I do find Ryan's suggestion -- to use
highlighting in the editor -- very intriguing.  We already highlight
in the editor, and it's pretty unintrusive.  In that style, it might
even be possible for a stepper window to combine highlighting with
showing *just* the current redex, and giving the user the option of
expanding the scope of attention (ie, show me more of the current
expression when I want it).

Shriram
_
   For list-related administrative tasks:
   http://lists.racket-lang.org/listinfo/dev
   

_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[Ryan Culpepper]

On 10/06/2010 12:37 PM, Everett Morse wrote:

I was just trying to debug a program today that goes through a series of
complex macros. I used Check Syntax so I can see what variables are
bound where (some of which are syntax variables), and when I got stuck I
wanted to see how the macro reduces. I clicked the macro stepper, and it
spun for a long time before crashing Racket (this is the dev version,
5.0.1.7--2010-10-04).


I'll see if there's anything I can do to make it more responsive.


It occurred to me then that the best way to do this would be to select
some piece of code in the editor and tell DrRacket to expand it, but
just that one spot. (It would have to know the macros defined in the
editor, but I already ran check syntax and the code is already compiled,
so somewhere it ought to be able to grab the definitions.) This would
avoid a long wait for parts I'm not interested in. If I was stupid
enough to select code that does expand right, that's my fault.


Check Syntax gathers far less information than the macro stepper. But if 
you just want to see the fully-expanded code for some subexpression, you 
could probably bolt that on to Check Syntax fairly easily. (Whether 
that's a good idea is another question... and if you do add it, make 
sure it doesn't show up in the teaching languages!)


As to selectively expanding things in place in DrRacket, you're right: 
it's not easy.


Ryan



Anyway, this probably isn't easy, practical, etc. But it is what I
naturally looked for and so I consider it the ideal. The macro stepper,
as is, is too slow and hard to focus in on the right place.

-Everett

On 08/27/2010 07:39 AM, Shriram Krishnamurthi wrote:

I can think of many different ways to make the stepper-definition
correspondence manifest. As John said, I once suggested that the code
should be reduced in-place, in the definition window. Shriram doesn't
like that idea (but he has never bothered to say why.)

That's right, I didn't.

Here's why. It introduces subtle state into the editor.

If you start stepping, and then try to Save, are you saving the
stepped version or the original?

If you start stepping, forget that you are doing that, and then start
editing, what are you editing?

If you step, does it affect the unsavedness of the editor?
(Presumably not.)

If I have a textual program, and step, does it next save in graphical
format? (I wouldn't want that.)

One way to prevent some of the more egregious problems is to make
stepping a mode. That brings its own problems -- how do you make it
not suck, how do you focus attention on it, etc.

I think people have a clear model of what an editor is: it's like
Word, like the text box of GMail, etc. Each one offers some
highlighting feedback and some rich-text editing -- but it's just an
editor. It's not a place where programs run. Putting the stepper
into the editor in a model way really messes with that.

I certainly agree with you (and have always agreed with you, for the
many years we've talked about this) that losing the correspondence to
the source program is a problem. But I don't think putting it in the
editor is the solution. I do find Ryan's suggestion -- to use
highlighting in the editor -- very intriguing. We already highlight
in the editor, and it's pretty unintrusive. In that style, it might
even be possible for a stepper window to combine highlighting with
showing *just* the current redex, and giving the user the option of
expanding the scope of attention (ie, show me more of the current
expression when I want it).

Shriram
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev

_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev

_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[Shriram Krishnamurthi]

 I can think of many different ways to make the stepper-definition
 correspondence manifest.   As John said, I once suggested that the code
 should be reduced in-place, in the definition window. Shriram doesn't
 like that idea (but he has never bothered to say why.)

That's right, I didn't.

Here's why.  It introduces subtle state into the editor.

If you start stepping, and then try to Save, are you saving the
stepped version or the original?

If you start stepping, forget that you are doing that, and then start
editing, what are you editing?

If you step, does it affect the unsavedness of the editor?
(Presumably not.)

If I have a textual program, and step, does it next save in graphical
format?  (I wouldn't want that.)

One way to prevent some of the more egregious problems is to make
stepping a mode.  That brings its own problems -- how do you make it
not suck, how do you focus attention on it, etc.

I think people have a clear model of what an editor is: it's like
Word, like the text box of GMail, etc.  Each one offers some
highlighting feedback and some rich-text editing -- but it's just an
editor.  It's not a place where programs run.  Putting the stepper
into the editor in a model way really messes with that.

I certainly agree with you (and have always agreed with you, for the
many years we've talked about this) that losing the correspondence to
the source program is a problem.  But I don't think putting it in the
editor is the solution.  I do find Ryan's suggestion -- to use
highlighting in the editor -- very intriguing.  We already highlight
in the editor, and it's pretty unintrusive.  In that style, it might
even be possible for a stepper window to combine highlighting with
showing *just* the current redex, and giving the user the option of
expanding the scope of attention (ie, show me more of the current
expression when I want it).

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[Neil Van Dyke]

John Clements wrote at 08/27/2010 05:38 PM:

On Aug 26, 2010, at 11:09 PM, Ryan Culpepper wrote:
  

Another, less invasive, way of making the stepper-definition connection might 
be on every step to scroll the definitions window and highlight the term from 
which the redex is derived. For function application the function definition 
could be highlighted too in a different color. The highlighting would require 
some creativity for forms like cond (maybe de-highlight clauses as they're 
eliminated?), but it would be a more incremental approach than forcing the 
stepper UI into the definitions window.



This might be awesome, or it might be confusing; I can imagine students seeing 
the definitions window jumping around and at a minimum being distracted, or 
even think that the definitions were changing. I guess I'd want to see it, 
first.


If anyone wants to try out a simple stepper for Lisp-ish code that 
scrolls your window to highlight the current expression in your actual 
source files, your Emacs has EDebug:


http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node/edebug.html

It actually only highlights if you have some kind of matching-paren 
highlighting enabled; otherwise it just puts the cursor on the first 
character of the expression.  My favorite for matching paren 
highlighting in Emacs is to have this in my ~/.emacs, and to elsewhere 
configure my cursor to be a full-size solid unblinking red background:


(setq show-paren-style 'parenthesis)
(require 'paren)
(show-paren-mode t)

In Emacs, experienced users are already accustomed to the current window 
switching which file/buffer it's showing, so EDebug just does that when 
moving between files.  I don't know whether that's appropriate for DrRacket.


--
http://www.neilvandyke.org/
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[Neil Van Dyke]

John Clements wrote at 08/27/2010 06:29 PM:

My earlier comment isn't suggesting that this isn't useful; it's asking whether 
doing this *simultaneously* with a separate display that's using substitution 
to evaluate an expression would cause cognitive overload.


If none of the languages people has a flash of inspiration, how about 
finding an HCI or visualization specialist in one of the universities, 
and enlisting them as a collaborator?


(I'd bet that these multiple views could be made intuitive, if 
approached as an interactive graphical visualization design problem.  
Maybe they can get a publication out of the approach alone.  Whether an 
alternative approach using only some arrangement of existing GUI widgets 
could be made accessible enough to students, I could not guess offhand.  
Were I not saturated with Racket consulting work at the moment, I'd love 
to tackle this HCI/viz problem myself.)


--
http://www.neilvandyke.org/
_
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[Shriram Krishnamurthi]

I like this.  The Stepper becomes available as an aid to help you
answer questions about how things came to be.  It is indeed often the
case that I lose the plot when stepping forward and hence go to the
end and work backward; this could put you there right away.

Yes, left-to-right scrolling makes much more sense, especially since
screens are generally wider than taller, and have become more so in
the HD era.  Sort of like the file selector on an Apple, right?  (I
forget the name for that style of columnar presentation.)

Is this a fair, operational restatement of your cautionary note:
It will be much less complicated to add just a `how did I get here?'
button to the REPL and have the rest of the stepper reside in its own
window, than trying to embed the whole stepper in the REPL?

Shriram
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[Shriram Krishnamurthi]

Understood, and agreed.  Thanks!

Anyone else have comments/suggestions?  I really like Robby's UI
suggestion and am treating it as the lead contender.

On Thu, Aug 26, 2010 at 10:57 AM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 On Thu, Aug 26, 2010 at 9:35 AM, Shriram Krishnamurthi s...@cs.brown.edu 
 wrote:
 Is this a fair, operational restatement of your cautionary note:
 It will be much less complicated to add just a `how did I get here?'
 button to the REPL and have the rest of the stepper reside in its own
 window, than trying to embed the whole stepper in the REPL?

 Yes.

 In general, I think the right way to proceed, even if you do decide
 that you want it in the same window, is to mock it up in a different
 window and get it close to the way you want it and then try to think
 thru how to put it back into the same window.

 Robby

_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[Matthias Felleisen]

On Aug 26, 2010, at 11:59 AM, Shriram Krishnamurthi wrote:

 Anyone else have comments/suggestions? 

Robby's idea of allowing students to choose how a RUN actually worked occurred 
to me too but I had a different behavior in mind. Instead of opening a separate 
window, I'd much rather see a step-by-step evaluation in the repl. 

Here is what I have in mind assuming (f x y) (sqrt (+ (sqr x) (sqr y))) is in 
the Definitions area: 

 (f 3 4)
5   { STEP }

If STEP is clicked, the following line appears: 
== (f 3 4)

and the student has the option of seeing the rest of the reduction sequence: 
== (f 3 4)
== (sqrt (+ (sqr 3) (sqr 4))
== (sqrt (+ 9 (sqr 4))
== (sqrt (+ 9 16))
... 
Each line highlights the contractum. 
The penultimate line highlights the redex. 

Each step is generated in response to a student action (return or click of 
button or keyboard shortcut). Students should have actions available to skip to 
the next function application, conditional, or primitive operation. 

;; --- 

Thanks for tackling that. 

Do keep in mind that Stephen is working on adapting the stepper (guts) to the 
Lazy language too. 

-- Matthias






_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[Robby Findler]

I can see how to do what Mattgias is suggesting at the snip level (so
not as bad as I made out) but you won't get nested scroll bars so you
might not like it.

Robby

On Thursday, August 26, 2010, Shriram Krishnamurthi s...@cs.brown.edu wrote:
 Understood.  But I think this is what Robby is saying is very
 difficult to implement correctly, and he's suggesting we put it in a
 different window at least for now so that we don't get bogged down in
 the details of the Interactions window.  Right, Robby?

 Shriram

 On Thu, Aug 26, 2010 at 1:21 PM, Matthias Felleisen
 matth...@ccs.neu.edu wrote:

 On Aug 26, 2010, at 11:59 AM, Shriram Krishnamurthi wrote:

 Anyone else have comments/suggestions?

 Robby's idea of allowing students to choose how a RUN actually worked 
 occurred to me too but I had a different behavior in mind. Instead of 
 opening a separate window, I'd much rather see a step-by-step evaluation in 
 the repl.

 Here is what I have in mind assuming (f x y) (sqrt (+ (sqr x) (sqr y))) is 
 in the Definitions area:

 (f 3 4)
 5   { STEP }

 If STEP is clicked, the following line appears:
 == (f 3 4)

 and the student has the option of seeing the rest of the reduction sequence:
 == (f 3 4)
 == (sqrt (+ (sqr 3) (sqr 4))
 == (sqrt (+ 9 (sqr 4))
 == (sqrt (+ 9 16))
 ...
 Each line highlights the contractum.
 The penultimate line highlights the redex.

 Each step is generated in response to a student action (return or click of 
 button or keyboard shortcut). Students should have actions available to skip 
 to the next function application, conditional, or primitive operation.

 ;; ---

 Thanks for tackling that.

 Do keep in mind that Stephen is working on adapting the stepper (guts) to 
 the Lazy language too.

 -- Matthias








_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[John Clements]

On Aug 26, 2010, at 10:59 AM, Shriram Krishnamurthi wrote:

 Got it.  Thanks for all the inputs and for the great suggestion!


A couple of comments:

1) I could very well be mis-stating his position, but I think that Guillaume 
felt quite strongly that the reductions should occur in the definitions window. 
 Guillaume?

2) you describe showing steps only for non-definitions; that seems like a 
needless restriction.  Most definitions won't have steps, but those that do 
should probably be step-able. This will require at least some change to Robby's 
click on a result suggestion, since definitions don't currently produce 
output text. Perhaps this is why you (Robby?) suggested excluding these.

3) It's not clear how you want to handle test cases; they don't currently 
generate anything in the interactions window, and yet this sounds like the 
thing that you're *most* likely to want to be able to step.  For the sake of 
argument, let me propose something:

the result of generate-report (the hidden summary-generation call that 
check-expect inserts) should be a snip that shows up in the interactions 
window, called (e.g.) Test Report.  Clicking on this (right-clicking on 
this?) should open a window showing the test cases in some tabular format, 
indicating which ones succeeded and which ones failed.  Selecting one of these, 
the user could choose to see its steps. 

Additional hidden benefit of this structure: because of the syntactic 
fol-de-rol that surrounds test cases, it should be fairly easy in such a 
tabular window to also show those test cases that didn't get run at all, 
because an earlier one caused a runtime error.

Finally, we probably want to think a bit about what happens on a runaway 
computation.  The current stepper handles this reasonably; it would be nice if 
the user could step through these computations to see what went wrong.  Most of 
my initial thoughts on how to handle this require unpleasantly significant 
changes to the way that the interactions window works.


John



smime.p7s
Description: S/MIME cryptographic signature
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[Kathy Gray]

On 26 Aug 2010, at 11:32:48, John Clements wrote:

 3) It's not clear how you want to handle test cases; they don't currently 
 generate anything in the interactions window, and yet this sounds like the 
 thing that you're *most* likely to want to be able to step.  For the sake of 
 argument, let me propose something:
 
 the result of generate-report (the hidden summary-generation call that 
 check-expect inserts) should be a snip that shows up in the interactions 
 window, called (e.g.) Test Report.  Clicking on this (right-clicking on 
 this?) should open a window showing the test cases in some tabular format, 
 indicating which ones succeeded and which ones failed.  Selecting one of 
 these, the user could choose to see its steps. 
 
 Additional hidden benefit of this structure: because of the syntactic 
 fol-de-rol that surrounds test cases, it should be fairly easy in such a 
 tabular window to also show those test cases that didn't get run at all, 
 because an earlier one caused a runtime error.

What about tying the stepper in with the current test result window (that's 
either docked or a free floating window) for stepping through tests? So the 
step = button would appear along with the failed tests and a different drop 
down expansion point with the successful tests to list the separate tests and 
respective step = buttons.

Cheers,
-Kathy
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[Shriram Krishnamurthi]

That seems like the wrong point of integration.  If I have

  (define v complex expr)

  (check-expect (g v) h)

then simply stepping into (g v) may not at all be enough.  If the
stepper forced people to rewrite their programs just for steppability,
that should be considered a bad design.

Shriram

On Thu, Aug 26, 2010 at 8:27 PM, Robby Findler
ro...@eecs.northwestern.edu wrote:
 It seems to me it would be nice to contemplate a design that
 integrates test suites and the stepper (also in light of Mike's
 signatures).

 Robby

 On Thu, Aug 26, 2010 at 7:23 PM, Shriram Krishnamurthi s...@cs.brown.edu 
 wrote:
 I know Guillaume proposed to do it in the context of the editor.  I'm
 unconvinced that that's the right way to go.  At any rate, integrating
 into an existing bit of infrastructure (def'ns or inter's) is going to
 be much more complex than an off-line prototype that people can
 critique.  So we should do that regardless.

 You and Kathy raise good and interesting points.  This tells me that
 there is not yet a good answer to *where* the stepper should run.  I
 believe this is quite separable from *how* the stepper runs, ie, how
 it displays the sequence of expressions.  Since I feel that is
 currently the biggest problem with it, it seems wise that we focus on
 the latter for now.  Once we make some real progress on that
 high-order bit, we can see what percolates up.

 Do others agree that this is the high-order bit?  If not (and perhaps
 even if so), can you articulate why?

 Shriram
 _
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev


_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[Robby Findler]

Well, that makes sense.

I'm just saying that, in an ideal world, when using the DR, you're
much more writing tests that typing things into the REPL. So it would
be good if the stepper could support that better in some way.

Robby

On Thu, Aug 26, 2010 at 7:30 PM, Shriram Krishnamurthi s...@cs.brown.edu 
wrote:
 That seems like the wrong point of integration.  If I have

  (define v complex expr)

  (check-expect (g v) h)

 then simply stepping into (g v) may not at all be enough.  If the
 stepper forced people to rewrite their programs just for steppability,
 that should be considered a bad design.

 Shriram

 On Thu, Aug 26, 2010 at 8:27 PM, Robby Findler
 ro...@eecs.northwestern.edu wrote:
 It seems to me it would be nice to contemplate a design that
 integrates test suites and the stepper (also in light of Mike's
 signatures).

 Robby

 On Thu, Aug 26, 2010 at 7:23 PM, Shriram Krishnamurthi s...@cs.brown.edu 
 wrote:
 I know Guillaume proposed to do it in the context of the editor.  I'm
 unconvinced that that's the right way to go.  At any rate, integrating
 into an existing bit of infrastructure (def'ns or inter's) is going to
 be much more complex than an off-line prototype that people can
 critique.  So we should do that regardless.

 You and Kathy raise good and interesting points.  This tells me that
 there is not yet a good answer to *where* the stepper should run.  I
 believe this is quite separable from *how* the stepper runs, ie, how
 it displays the sequence of expressions.  Since I feel that is
 currently the biggest problem with it, it seems wise that we focus on
 the latter for now.  Once we make some real progress on that
 high-order bit, we can see what percolates up.

 Do others agree that this is the high-order bit?  If not (and perhaps
 even if so), can you articulate why?

 Shriram
 _
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev



_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev

Re: [racket-dev] stepper UI question

[John Clements]

On Aug 26, 2010, at 5:23 PM, Shriram Krishnamurthi wrote:

 I know Guillaume proposed to do it in the context of the editor.  I'm
 unconvinced that that's the right way to go.  At any rate, integrating
 into an existing bit of infrastructure (def'ns or inter's) is going to
 be much more complex than an off-line prototype that people can
 critique.  So we should do that regardless.
 
 You and Kathy raise good and interesting points.  This tells me that
 there is not yet a good answer to *where* the stepper should run.  I
 believe this is quite separable from *how* the stepper runs, ie, how
 it displays the sequence of expressions.  Since I feel that is
 currently the biggest problem with it, it seems wise that we focus on
 the latter for now.  Once we make some real progress on that
 high-order bit, we can see what percolates up.
 
 Do others agree that this is the high-order bit?  If not (and perhaps
 even if so), can you articulate why?

I do agree.  Your original message seemed to be entirely focused on the *where* 
question, which I think is why it's what we've all been discussing.

John



smime.p7s
Description: S/MIME cryptographic signature
_
  For list-related administrative tasks:
  http://lists.racket-lang.org/listinfo/dev