Gvim interface to the ruby debugger?

ruby-talk
1

I’ve been thinking about this (for both Ruby and Perl). The main
problem is that you have to have an external connection to the
debugger […]

Yes, this was the biggest obstacle I saw when I first tried to
envision how such a system would work. Since Vim is not a shell
and will never be, and AFAIK can only execute shell commands in
“batch mode” (open a shell and wait for the command to terminate),
it seemed at first that you’d need a one-shot script that takes
a command from Vim, connects to a running debug server through a
socket (starting the server which in turn starts the debugger
if there isn’t one running), executes the command, and returns
the results back to Vim. Kinda convoluted. Someone here suggested
using an expect script as the interface, but I wanted to keep the
solution confined to Ruby and Vim.

The built-in debugger interface is pretty specialized, and hooks into
the main event loop of Vim (and only works with X).

Agreed. I didn’t even know Vim had a debugger interface until I did
a Google search on “Vim Ruby debugger” and was directed to one
of the Vim help pages. But in doing so I found the VIM Ruby
module; so now my current thinking is a central debug server that
forks off a Gvim window on one side as a client and a debug session
on the other. This means you can’t start it from inside an existing
Gvim window, but that’s acceptable to me.

I don’t know if you want this to work under Windows

It’s not my main platform, but yes.

but it’s possible
(I think) to use named pipes in both the Unix and Windows envronment
(at least Windows/NT; don’t know if you can do this with
DOS-windows).

So you could whip up a version of debug.rb that talks to a couple of
named pipes, and then open a connection to those pipes from Vim.

Can you talk to an open pair of pipes from Vim? I didn’t think you
could keep a live connection to another process in Vim in this way,
hence my convoluted socket-based architecture.

Thanks for the suggestions,

  • jeff
···

Ned Konz [ned@bike-nomad.com] wrote:

2

No, named pipes (a/k/a fifo). To run a debugger command (perhaps
step):

  • open debugger output fifo for read.
  • open debugger input fifo for write.
  • send command to debugger.
  • close debugger input fifo (if you have to)
  • read lines from debugger output fifo till you get a “done” response
    – for each line, update line number display as needed.

The catch is that you can’t do “normal” file operations in VimL. You
can read a whole file, of course, and you can write or read to pipes
or files.

The built-in Ruby interpreter keeps files open.

Have you looked at the clientserver stuff? (:he clientserver) It
allows Vim to act as a remote editor. You could use it (I think) to
run Vim as a front-end for a debugger.

Under Unix, it uses communications via X, and under Windows it uses
either regular Windows messages, or you could use the OLE interface.

There is ruby-xlib-wrap, ruby/xlib, and rubyx11 in the RAA.

From the help:

There are a number of VimL functions for scripting the command server.
See
the description in |eval.txt| or use CTRL-] on the function name to
jump to
the full explanation.

synopsis				     explanation ~
remote_expr( server, string, idvar)      send expression
remote_send( server, string, idvar)      send key sequence
serverlist()			     get a list of available servers
remote_peek( serverid, retvar)	     check for reply string
remote_read( serverid)		     read reply string
server2client( serverid, string)	     send reply string
remote_foreground( server)		     bring server to the front
···

On Thursday 27 June 2002 04:42 pm, Gray, Jeff wrote:

named pipes, and then open a connection to those pipes from Vim.

Can you talk to an open pair of pipes from Vim? I didn’t think you
could keep a live connection to another process in Vim in this way,
hence my convoluted socket-based architecture.

–
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE