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