Setting gdb to use eshell buffer

Setting gdb to use eshell buffer

[ncohen]

Hi I'm using tramp to successfully transparently edit remote files however I 
also want to compile and debug them from inside emacs.  How do I do this?

I'm wondering if there is a way to 'point' the emacs gdb process to a shell 
that is currently running as a process 'inside'(?) emacs.  Then I could use 
eshell to connect to a remote machine, and then issue either a gdb command in 
eshell and somehow have emacs-gdb take control of the buffer, or issue a gdb 
command in emacs and have it issue the command to the eshell (so the remote 
gdb will start).    

Thanks,
Ben

Re: Setting gdb to use eshell buffer

[Kai Grossjohann]

ncohen@ucsd.edu writes:

> Hi I'm using tramp to successfully transparently edit remote files
> however I also want to compile and debug them from inside emacs.
> How do I do this?

With difficulty :-/

Tramp comes with a file tramp-util.el which contains a function that
allows you to do remote compiles.  It is, however, a fake, because it
doesn't show any output until the remote compile is finished.  (M-x
compile RET shows you output as it is arriving.)  And what's more,
Emacs is frozen while it is waiting for the compile to finish.

I'm thinking about extending Tramp to allow background processes.  I
think that Tramp needs to open multiple connections to the remote host
to do that.  (If somebody has other ideas, please speak up.)  And if
you open multiple connections to a host, then password caching becomes
interesting.  And password caching is potentially very dangerous.
Also, it would make sense to reuse connections, instead of opening a
new connection whenever you issue a new compile command.

> I'm wondering if there is a way to 'point' the emacs gdb process to
> a shell that is currently running as a process 'inside'(?) emacs.
> Then I could use eshell to connect to a remote machine, and then
> issue either a gdb command in eshell and somehow have emacs-gdb take
> control of the buffer, or issue a gdb command in emacs and have it
> issue the command to the eshell (so the remote gdb will start).

I think it should be possible to have GUD take control of an already
existing buffer that's running GDB.  But I don't know how to do that.
Maybe GUD is not designed for this, so it could be difficult.

But using eshell to "connect" to a remote machine seems a bit
strange.  Either you are using "cd /user@host:/path/to/dir" to do this
connection.  In that case, it's all fake -- no actual process is
involved.  Whenever you type something into eshell, then eshell will
run that command as a shell command.  And Tramp intercepts the
shell-command action for its directories, so it kinda appears as if
eshell was "connected" to the remote machine.  But it isn't, really.

The other possibility is that you are invoking ssh at the eshell
prompt.  That won't do much good, since eshell does not have good
facilities for interacting with subprocesses.  (The facilities aren't
that bad, but eshell wasn't designed for it.)

The third possibility is you're talking about M-x shell RET and not
M-x eshell RET.  In that case, everything is different ;-)  But it
remains difficult to use Tramp for compilation.

Kai

Re: Setting gdb to use eshell buffer

[Ulrich Herbst]

Kai Grossjohann <kai@emptydomain.de> writes:

> ncohen@ucsd.edu writes:
> 
> > Hi I'm using tramp to successfully transparently edit remote files
> > however I also want to compile and debug them from inside emacs.
> > How do I do this?
> 
> With difficulty :-/
> 
> Tramp comes with a file tramp-util.el which contains a function that
> allows you to do remote compiles.  It is, however, a fake, because it
> doesn't show any output until the remote compile is finished.  (M-x
> compile RET shows you output as it is arriving.)  And what's more,
> Emacs is frozen while it is waiting for the compile to finish.
> 
> I'm thinking about extending Tramp to allow background processes.  I
> think that Tramp needs to open multiple connections to the remote host
> to do that.  (If somebody has other ideas, please speak up.)  And if
> you open multiple connections to a host, then password caching becomes
> interesting.  And password caching is potentially very dangerous.
> Also, it would make sense to reuse connections, instead of opening a
> new connection whenever you issue a new compile command.

No, i haven't other ideas (and i don't understand the rest of that
post).
Would it be possible to use that "extended" tramp to debug perlscripts
remote ? (I need that).

Uli

-- 
                             '''
                             (0 0)
                +------oOO----(_)--------------+
                |                              |
                |         Ulrich Herbst        |
                |                              |
                |      Ulrich.Herbst@gmx.de    |
                +-------------------oOO--------+
                            |__|__|
                             || ||
                            ooO Ooo

Re: Setting gdb to use eshell buffer

[Kai Grossjohann]

Ulrich Herbst <ulrich.herbst@gmx.de> writes:

> No, i haven't other ideas (and i don't understand the rest of that
> post).

A pity.  I'm always looking for other ideas.  Tramp needs to solve
nontrivial problems, IMHO.

> Would it be possible to use that "extended" tramp to debug perlscripts
> remote ? (I need that).

It would be the first step (of perhaps five or so) to allow you to
debug perl scripts remotely.

Kai

Re: Setting gdb to use eshell buffer

[Kevin Rodgers]

Kai Grossjohann wrote:

> ncohen@ucsd.edu writes:
>>Hi I'm using tramp to successfully transparently edit remote files
>>however I also want to compile and debug them from inside emacs.
>>How do I do this?
> 
> With difficulty :-/
> 
> Tramp comes with a file tramp-util.el which contains a function that
> allows you to do remote compiles.  It is, however, a fake, because it
> doesn't show any output until the remote compile is finished.  (M-x
> compile RET shows you output as it is arriving.)  And what's more,
> Emacs is frozen while it is waiting for the compile to finish.


 From that, I infer that Tramp has the connection write its output to a
local temporary file that it then inserts into a compilation buffer.  If
that's the case, why can't the compilation buffer be set up with a process
that tail's the temp file as its written?


> I'm thinking about extending Tramp to allow background processes.  I
> think that Tramp needs to open multiple connections to the remote host
> to do that.  (If somebody has other ideas, please speak up.)  And if
> you open multiple connections to a host, then password caching becomes
> interesting.  And password caching is potentially very dangerous.
> Also, it would make sense to reuse connections, instead of opening a
> new connection whenever you issue a new compile command.


I don't know.  If caching passwords is so dangerous, maybe it is worth

the overhead to establish a new connection for each background command.


-- 
Kevin Rodgers

Re: Setting gdb to use eshell buffer

[Kai Grossjohann]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Kai Grossjohann wrote:
>
>> ncohen@ucsd.edu writes:
>>>Hi I'm using tramp to successfully transparently edit remote files
>>>however I also want to compile and debug them from inside emacs.
>>>How do I do this?
>> With difficulty :-/
>> Tramp comes with a file tramp-util.el which contains a function that
>> allows you to do remote compiles.  It is, however, a fake, because it
>> doesn't show any output until the remote compile is finished.  (M-x
>> compile RET shows you output as it is arriving.)  And what's more,
>> Emacs is frozen while it is waiting for the compile to finish.
>
>  From that, I infer that Tramp has the connection write its output to a
> local temporary file that it then inserts into a compilation buffer.  If
> that's the case, why can't the compilation buffer be set up with a process
> that tail's the temp file as its written?

Remember that Tramp uses a shell connection, the *tramp/foo* buffer,
for most of its stuff.  (For all of it, except file transfer in the
case of out-of-band methods.)

The Tramp compilation function sends the compile command to the remote
host, waits for the next shell prompt to appear, then extracts what's
in *tramp/foo* and copies it to another buffer which it calls a
*compilation* buffer.

One *could* temporarily rename the *tramp/foo* buffer to *compilation*
and show it to the user, then when the compilation is finished, revert
the renaming and do the copying thing.  Down that path lies madness,
though.

Or one could install a process filter that fishes things from the
*tramp/foo* buffer and copies them into the *compilation* buffer as
they arrive.  But in that case, we need to prohibit users from
invoking Tramp in the meantime, as the *tramp/foo* buffer is already
busy.

>> I'm thinking about extending Tramp to allow background processes.  I
>> think that Tramp needs to open multiple connections to the remote host
>> to do that.  (If somebody has other ideas, please speak up.)  And if
>> you open multiple connections to a host, then password caching becomes
>> interesting.  And password caching is potentially very dangerous.
>> Also, it would make sense to reuse connections, instead of opening a
>> new connection whenever you issue a new compile command.
>
> I don't know.  If caching passwords is so dangerous, maybe it is worth
> the overhead to establish a new connection for each background command.

Hm?  That means that the poor user will have to type their password
for every background command...  (In the case of multi-hop methods,
multiple passwords.)

Kai

Re: Setting gdb to use eshell buffer

[Kevin Rodgers]

Kai Grossjohann wrote:
 > Remember that Tramp uses a shell connection, the *tramp/foo* buffer,
 > for most of its stuff.  (For all of it, except file transfer in the
 > case of out-of-band methods.)
 >
 > The Tramp compilation function sends the compile command to the remote
 > host, waits for the next shell prompt to appear, then extracts what's
 > in *tramp/foo* and copies it to another buffer which it calls a
 > *compilation* buffer.
 >
 > One *could* temporarily rename the *tramp/foo* buffer to *compilation*
 > and show it to the user, then when the compilation is finished, revert
 > the renaming and do the copying thing.  Down that path lies madness,
 > though.
 >
 > Or one could install a process filter that fishes things from the
 > *tramp/foo* buffer and copies them into the *compilation* buffer as
 > they arrive.  But in that case, we need to prohibit users from
 > invoking Tramp in the meantime, as the *tramp/foo* buffer is already
 > busy.

Isn't that necessary anyway?  Because otherwise, the current
implementation would have other Tramp data interspersed with the compile
command's output in the *tramp/foo* buffer.

Would it be feasible for the Tramp compilation function to install the
process filter and arrange for it to be uninstalled when its done?

-- 
Kevin Rodgers

Re: Setting gdb to use eshell buffer

[Kai Grossjohann]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> Kai Grossjohann wrote:
>  >
>  > Or one could install a process filter that fishes things from the
>  > *tramp/foo* buffer and copies them into the *compilation* buffer as
>  > they arrive.  But in that case, we need to prohibit users from
>  > invoking Tramp in the meantime, as the *tramp/foo* buffer is already
>  > busy.
>
> Isn't that necessary anyway?  Because otherwise, the current
> implementation would have other Tramp data interspersed with the compile
> command's output in the *tramp/foo* buffer.

Well, my original plan was to allow multiple connections.  Then each
connection could be dedicated to a single compilation, until that
compilation is finished.

If two (remote) processes are writing to the same *tramp/foo* buffer,
it is nearly impossible to tell the chunks apart later.  At least I
haven't found a way to do that.  But if there was a way, multiplexing
a single *tramp/foo* buffer might be the way to go.

But you're right anyway: we need a way to copy the output from the
remote end from the *tramp/foo* buffer to the *compilation* buffer, as
that output arrives, and we need to do that in the background.  This
means that process filters are the easiest way.  And if I want to
reuse the same *tramp/foo* buffer for multiple compilations (which is
a good idea to avoid connection setup overhead), then it won't work to
just name the buffer the *compilation* buffer...

> Would it be feasible for the Tramp compilation function to install the
> process filter and arrange for it to be uninstalled when its done?

Sure.  set-process-filter will be my friend.

Kai

Re: Setting gdb to use eshell buffer

[Stefan Monnier]

> Well, my original plan was to allow multiple connections.  Then each
> connection could be dedicated to a single compilation, until that
> compilation is finished.

That's probably the easiest and more robust way to do it.

> If two (remote) processes are writing to the same *tramp/foo* buffer,
> it is nearly impossible to tell the chunks apart later.  At least I
> haven't found a way to do that.  But if there was a way, multiplexing
> a single *tramp/foo* buffer might be the way to go.

I'm sure it's possible, but it's probably also very painful to do,
especially in the context of Tramp (you'd probably have to either require
users install some multiplexing program on the server's end or write it in
Perl and transmit it, but it's likely to be a large piece of code).

It might be easier to think of it as a tramp-server, which you'd run in
place of a bourne shell.  Maybe it's not a bad idea.


        Stefan

Re: Setting gdb to use eshell buffer

[Kai Grossjohann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'm sure it's possible, but it's probably also very painful to do,
> especially in the context of Tramp (you'd probably have to either require
> users install some multiplexing program on the server's end or write it in
> Perl and transmit it, but it's likely to be a large piece of code).
>
> It might be easier to think of it as a tramp-server, which you'd run in
> place of a bourne shell.  Maybe it's not a bad idea.

Yes, something like this could be useful.  It would be more similar to
Ange-FTP, in a sense, because we expect a certain kind of server to be
installed on the remote end, instead of just making do with a shell.

Gives the M in Tramp a new meaning ;-)

Kai