That sounds very cool! If you can maybe keep some amount of model/view abstraction going maybe we could get that into drr?<div><br></div><div>Robby<br><br>On Thursday, March 19, 2015, Greg Hendershott <<a href="mailto:greghendershott@gmail.com">greghendershott@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thank you, Robby.<br>
<br>
> Another approach that you might want to try is to catch the "c:c;c:c"<br>
> at the emacs level and instead of turning that into SIGINT (or<br>
> whatever signal it is) send an explicit message across to the "(sync<br>
> never-evt)" code that tells it to break the user's program's thread.<br>
> This is closer to what DrRacket does and it has the advantage that you<br>
> can still use the raw breaks to debug racket mode, should the need<br>
> arise (I find this very useful when debugging drracket -- but no one<br>
> expects a control-c to drracket to turn into breaking the program<br>
> running inside drr!)<br>
<br>
That's a good idea, too. Thanks!<br>
<br>
<br>
Speaking of breaks and deubgging: I have a `debugger` branch (pushed to<br>
GitHub, but not ready to be merged to master) with an experimental<br>
debugger. It uses the annotations from gui-debugger, which was a huge<br>
head start.<br>
<br>
Instead of a separate watch window, it draws top-level and local binding<br>
values directly in the source code buffer (somewhat like Light Table?).<br>
<br>
On my first pass, I was thinking of debugging as a Special Mode you're<br>
in, during which you break and resume etc., and then you exit. That<br>
worked OK, but it was too modal and "too special".<br>
<br>
So on my second (current) pass, you're in a special mode only while<br>
you're at a breakpoint. And it's less special in the bad sense: Now<br>
there's a full REPL available, extended with some debugging commands for<br>
Emacs commands to use (or you could type them directly as a human). A<br>
couple of the comamnds like ,(go) or ,(step) exit the special REPL and<br>
resume execution; others don't.<br>
<br>
And it's a normal REPL to eval code, not just for commands. In addition<br>
to entering the module namespace, for read/write access to top-level<br>
bindings, the prompt-read handler wraps your input in a let-syntax<br>
mapping all local bound identifiers to set!-transformers. So you can<br>
play with them interactively at the REPL. e.g.<br>
<br>
    DEBUG:foot.rkt> (set! some-local (add1 some-local))<br>
<br>
And so on, and eventually resume with those values in effect.<br>
<br>
Currently you can break only via breakpoints (although there are various<br>
flavors of these, including skip-N breakpoints, run-to-cursor, and so<br>
on). I also want to support breaking as a result of:<br>
<br>
1. A statement you could put in your source (like `debug` in Elisp, or<br>
   `pry`, or whatever).<br>
<br>
2. exn:break, although I'm not yet sure how that will work.<br>
<br>
It's been fun to work on so far, although I'm scared I don't know what I<br>
don't know, and there are probably huge gaping holes.<br>
</blockquote></div>