[racket] racket-mode

[Greg Hendershott]

Just a heads-up on some progress with racket-mode over the last couple
months:

- Support for errortrace in error message stack traces.

- A profile command that shows profile results in a major mode buffer
and lets you view the source locations in the other window. You can
also evaluate more expressions in the REPL, and refresh the displayed
profile results.

- The option to run tests with coverage enabled, highlighting uncovered
spots similar to DrRacket. (Note: This uses errortrace's
get-execute-counts. Spencer Florence and I have been discussing
replacing this with better instrumentation from the cover package.)

- A check-syntax minor mode, using functionality exposed by Robby
Findler (thanks!!) in Racket 6.1.1.6+. Although there aren't any
arrows, it does highlight related bindings, let you jump among them,
and rename related lexical bindings.

- An open require path command (similar to DrRacket's), as well as
integration with the raco-find-collection package if you have that
installed.

- Behind the scenes: The method of getting command output from Racket to
Emacs has been overhauled to be more reliable. There are now tests for
font-lock and indentation.

- Bugs have been squashed:

https://github.com/greghendershott/racket-mode/issues?q=is%3Aissue+is%3Aclosed

- A number of people have contributed great pull requests (thanks!!).


For more information:

- There's a Reference.md file you can browse online (it's created from
the doc strings you can view directly in Emacs help):

https://github.com/greghendershott/racket-mode/blob/master/Reference.md

- The README is here:

https://github.com/greghendershott/racket-mode/blob/master/README.md

- You can install racket-mode from MELPA: `M-x install-package`,
`racket-mode`. (If you have the minimal Racket distribution, e.g. from
Homebrew, then you'll need some more packages; simplest way to get
them all is to `raco pkg install drracket`.)


If you have really detailed questions, or problem reports, it would
probably be better for this list (and easier for me to track them)
if you lob them to GitHub Issues:

https://github.com/greghendershott/racket-mode/issues
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Konrad Hinsen]

Post by Greg Hendershott
Just a heads-up on some progress with racket-mode over the last couple

...

Post by Greg Hendershott
If you have really detailed questions, or problem reports, it would
probably be better for this list (and easier for me to track them)

What I think does belong on this list is a big and visible "thank-you"
message for all the great work that you are doing on racket-mode. It has
become my preferred development environment for Racket because it offers
very useful language-specific support perfectly integrated into a
language-neutral environment (Emacs).

Konrad.


____________________
Racket Users list:
http://lists.racket-lang.org/users

[Matthias Felleisen]

Don't make me want to go back to programming Racket in Emacs :-)
But thanks for mapping Emacs back into the fold. -- Matthias

Post by Greg Hendershott
Just a heads-up on some progress with racket-mode over the last couple
- Support for errortrace in error message stack traces.
- A profile command that shows profile results in a major mode buffer
and lets you view the source locations in the other window. You can
also evaluate more expressions in the REPL, and refresh the displayed
profile results.
- The option to run tests with coverage enabled, highlighting uncovered
spots similar to DrRacket. (Note: This uses errortrace's
get-execute-counts. Spencer Florence and I have been discussing
replacing this with better instrumentation from the cover package.)
- A check-syntax minor mode, using functionality exposed by Robby
Findler (thanks!!) in Racket 6.1.1.6+. Although there aren't any
arrows, it does highlight related bindings, let you jump among them,
and rename related lexical bindings.
- An open require path command (similar to DrRacket's), as well as
integration with the raco-find-collection package if you have that
installed.
- Behind the scenes: The method of getting command output from Racket to
Emacs has been overhauled to be more reliable. There are now tests for
font-lock and indentation.
https://github.com/greghendershott/racket-mode/issues?q=is%3Aissue+is%3Aclosed
- A number of people have contributed great pull requests (thanks!!).
- There's a Reference.md file you can browse online (it's created from
https://github.com/greghendershott/racket-mode/blob/master/Reference.md
https://github.com/greghendershott/racket-mode/blob/master/README.md
- You can install racket-mode from MELPA: `M-x install-package`,
`racket-mode`. (If you have the minimal Racket distribution, e.g. from
Homebrew, then you'll need some more packages; simplest way to get
them all is to `raco pkg install drracket`.)
If you have really detailed questions, or problem reports, it would
probably be better for this list (and easier for me to track them)
https://github.com/greghendershott/racket-mode/issues
____________________
http://lists.racket-lang.org/users

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Greg Hendershott]

Post by Matthias Felleisen
Don't make me want to go back to programming Racket in Emacs :-)
But thanks for mapping Emacs back into the fold. -- Matthias

The more I do with racket-mode, the deeper my appreciation for
everything that DrRacket does. It's really quite amazing.

Also the more I program in Emacs Lisp, the more I appreciate programming
in Racket. :)


p.s. The edebug feature in Emacs Lisp is one thing I do now miss in
Racket. IOW I'm tempted to tackle using DrRacket debugger annotations,
with an edebug UI in Emacs. Either per-function like edebug, or per
module(s) like DrR.

Sure, I hardly ever want a debugger for Racket, in the way I used one
heavily and religiously for C/C++ (to step through new code the first
time instead of just hitting Run). After all we have the REPL, and
functions. And TBH printfs usually suffice. So I hardly every used the
debugger in DrRacket.

And yet. Sometimes it would be handy to set breakpoints and step through
code. Now that I've done that enough with Elisp for racket-mode, I want
to be able to do it for Racket code, too.

Aside from utility, there's just the raw challenge of making something
like that work. At least it would be a challenge, for me.
____________________
Racket Users list:
http://lists.racket-lang.org/users

[Konrad Hinsen]

Post by Greg Hendershott
Sure, I hardly ever want a debugger for Racket, in the way I used one
heavily and religiously for C/C++ (to step through new code the first
time instead of just hitting Run). After all we have the REPL, and
functions. And TBH printfs usually suffice. So I hardly every used the
debugger in DrRacket.

What I miss, coming from Python, is the Python debugger's post-mortem
inspection feature. When a program crashes, I can inspect the complete
program state at that point. That has taken care of 90% of my debugging
needs in Python.

My impression is that even DrRacket doesn't have something like that,
although I may have easily missed some DrRacket feature.

Konrad.

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Matthias Felleisen]

I think we don't miss a conventional debugger in Racket (Emacs or Dr)
because, unlike say Python, Racket is not a shallow layer over some
unsafe amalgam of C and C++. Sure there is some of it left but our
crashes don't leave core dumps because most of them are safe.

I agree that on occasion it would be neat to say "stop here and
let me explore/modify the environment and the store." Most of the
time though you get away with printf because the language is safe
I just don't consider it high priority until someone shows me a
really good use case.

-- Matthias

Post by Greg Hendershott

Post by Matthias Felleisen
Don't make me want to go back to programming Racket in Emacs :-)
But thanks for mapping Emacs back into the fold. -- Matthias

The more I do with racket-mode, the deeper my appreciation for
everything that DrRacket does. It's really quite amazing.
Also the more I program in Emacs Lisp, the more I appreciate programming
in Racket. :)
p.s. The edebug feature in Emacs Lisp is one thing I do now miss in
Racket. IOW I'm tempted to tackle using DrRacket debugger annotations,
with an edebug UI in Emacs. Either per-function like edebug, or per
module(s) like DrR.
Sure, I hardly ever want a debugger for Racket, in the way I used one
heavily and religiously for C/C++ (to step through new code the first
time instead of just hitting Run). After all we have the REPL, and
functions. And TBH printfs usually suffice. So I hardly every used the
debugger in DrRacket.
And yet. Sometimes it would be handy to set breakpoints and step through
code. Now that I've done that enough with Elisp for racket-mode, I want
to be able to do it for Racket code, too.
Aside from utility, there's just the raw challenge of making something
like that work. At least it would be a challenge, for me.

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Sam Tobin-Hochstadt]

Having spent a bunch of time writing Python over the last year (while
building Pycket [1]), the debugger is the one thing I wish I had in
Racket. This isn't because it interacts with C (I've not used any C
extensions), but because it makes debugging much faster than when I
have to use printf (my usual strategy in Racket). I'm really excited
about Medic (https://github.com/lixiangqi/medic), which seems like a
very cool approach for adding more debugging to Racket.

[1] https://github.com/samth/pycket

Sam

On Sat, Feb 28, 2015 at 2:41 PM, Matthias Felleisen

Post by Matthias Felleisen
I think we don't miss a conventional debugger in Racket (Emacs or Dr)
because, unlike say Python, Racket is not a shallow layer over some
unsafe amalgam of C and C++. Sure there is some of it left but our
crashes don't leave core dumps because most of them are safe.
I agree that on occasion it would be neat to say "stop here and
let me explore/modify the environment and the store." Most of the
time though you get away with printf because the language is safe
I just don't consider it high priority until someone shows me a
really good use case.
-- Matthias

Post by Greg Hendershott

Post by Matthias Felleisen
Don't make me want to go back to programming Racket in Emacs :-)
But thanks for mapping Emacs back into the fold. -- Matthias

The more I do with racket-mode, the deeper my appreciation for
everything that DrRacket does. It's really quite amazing.
Also the more I program in Emacs Lisp, the more I appreciate programming
in Racket. :)
p.s. The edebug feature in Emacs Lisp is one thing I do now miss in
Racket. IOW I'm tempted to tackle using DrRacket debugger annotations,
with an edebug UI in Emacs. Either per-function like edebug, or per
module(s) like DrR.
Sure, I hardly ever want a debugger for Racket, in the way I used one
heavily and religiously for C/C++ (to step through new code the first
time instead of just hitting Run). After all we have the REPL, and
functions. And TBH printfs usually suffice. So I hardly every used the
debugger in DrRacket.
And yet. Sometimes it would be handy to set breakpoints and step through
code. Now that I've done that enough with Elisp for racket-mode, I want
to be able to do it for Racket code, too.
Aside from utility, there's just the raw challenge of making something
like that work. At least it would be a challenge, for me.

____________________
http://lists.racket-lang.org/users

____________________
Racket Users list:
http://lists.racket-lang.org/users

[Jay McCarthy]

I don't like debugging with printf, although Medic does seem cool.

I like to turn errors into test cases and then trace the execution of
the program and turn one test case into more. This is a nice way to
debug because it ensures the same error won't come up again.

Jay

On Sat, Feb 28, 2015 at 2:51 PM, Sam Tobin-Hochstadt

Post by Sam Tobin-Hochstadt
Having spent a bunch of time writing Python over the last year (while
building Pycket [1]), the debugger is the one thing I wish I had in
Racket. This isn't because it interacts with C (I've not used any C
extensions), but because it makes debugging much faster than when I
have to use printf (my usual strategy in Racket). I'm really excited
about Medic (https://github.com/lixiangqi/medic), which seems like a
very cool approach for adding more debugging to Racket.
[1] https://github.com/samth/pycket
Sam
On Sat, Feb 28, 2015 at 2:41 PM, Matthias Felleisen

Post by Matthias Felleisen
I think we don't miss a conventional debugger in Racket (Emacs or Dr)
because, unlike say Python, Racket is not a shallow layer over some
unsafe amalgam of C and C++. Sure there is some of it left but our
crashes don't leave core dumps because most of them are safe.
I agree that on occasion it would be neat to say "stop here and
let me explore/modify the environment and the store." Most of the
time though you get away with printf because the language is safe
I just don't consider it high priority until someone shows me a
really good use case.
-- Matthias

Post by Greg Hendershott

Post by Matthias Felleisen
Don't make me want to go back to programming Racket in Emacs :-)
But thanks for mapping Emacs back into the fold. -- Matthias

The more I do with racket-mode, the deeper my appreciation for
everything that DrRacket does. It's really quite amazing.
Also the more I program in Emacs Lisp, the more I appreciate programming
in Racket. :)
p.s. The edebug feature in Emacs Lisp is one thing I do now miss in
Racket. IOW I'm tempted to tackle using DrRacket debugger annotations,
with an edebug UI in Emacs. Either per-function like edebug, or per
module(s) like DrR.
Sure, I hardly ever want a debugger for Racket, in the way I used one
heavily and religiously for C/C++ (to step through new code the first
time instead of just hitting Run). After all we have the REPL, and
functions. And TBH printfs usually suffice. So I hardly every used the
debugger in DrRacket.
And yet. Sometimes it would be handy to set breakpoints and step through
code. Now that I've done that enough with Elisp for racket-mode, I want
to be able to do it for Racket code, too.
Aside from utility, there's just the raw challenge of making something
like that work. At least it would be a challenge, for me.

____________________
http://lists.racket-lang.org/users

____________________
http://lists.racket-lang.org/users

--
Jay McCarthy
http://jeapostrophe.github.io

"Wherefore, be not weary in well-doing,
for ye are laying the foundation of a great work.
And out of small things proceedeth that which is great."
- D&C 64:33
____________________
Racket Users list:
http://lists.racket-lang.org/users