Loading ...
Sorry, an error occurred while loading the content.
 

remote debugging ideas for vimscripts

Expand Messages
  • Hari Krishna Dara
    My latest breakpts.vim script is quite usable and at times I have observed that you can completely avoid creating breakpoints by hand, making it much simpler
    Message 1 of 8 , Jun 23, 2003
      My latest breakpts.vim script is quite usable and at times I have
      observed that you can completely avoid creating breakpoints by hand,
      making it much simpler and faster to do so. But one thing that is still
      not possible is to extend this convenience when you are already
      debugging a script.

      Now I have got a some ideas that would circumvent this problem and
      make the script much more powerful, making the entire debugging
      experience much better and almost on par or better than many debuggers.
      The idea is based on combining the existing plugin capabilities with
      that of Vim's |remote.txt| features, and be able to control a
      running/debugging instance of Vim with another Vim through the plugin.
      At the simplest level, it should be possible to just redirect the
      commands to another instance through remote_send() and remote_expr()
      functions, and get a big bang for the buck. But it should also be
      possible to even visually show the navigate of the execution, and
      remotely control the flow with the debug commands such as Next, Step
      etc.

      To come up with a proof of concept, I started trying some experiments,
      and the first thing that I noticed is that remote execution of vim code
      in a Vim instance that is in debug mode is buggy at best. The called
      instance of Vim either hangs or crashes. There is a lot of built-in
      functions that can still be executed using remote_expr(), suggesting
      that this at least is supported.

      Here is something that can show this buggy behavior:

      I have the following function defined to get the output of Vim built-in
      commands, which the plugin is already using.


      " Just a convenience function. This returns the output of the command as a
      " string, without corrupting any registers. Returns empty string on errors.
      " Check for v:errmsg after calling this function for any error messages.
      function! GetVimCmdOutput(cmd)
      let v:errmsg = ''
      let output = ''
      let _z = @z
      try
      redir @z
      silent exec a:cmd
      catch /.*/
      let v:errmsg = substitute(v:exception, '^[^:]\+:', '', '')
      finally
      redir END
      if v:errmsg == ''
      let output = @z
      endif
      let @z = _z
      endtry
      return output
      endfunction


      - When I remote_expr() this function when Vim is in normal mode, it
      works fine, but if Vim is in debug mode, then it hangs. The call would
      look something like this:

      :echo remote_expr('<vim server name>', "GetVimCmdOutput('ls')")

      - Similarly, if I remote_send() a command using this function, if Vim is
      in normal mode, it works fine, but if Vim is in debug mode, it just
      crashes. The call would look something like this:

      :call remote_send('<vim server name>', ":let @z=GetVimCmdOutput('ls')\<CR>")

      Having remote debugging functionality for Vim scripts will not only be
      cool, but very useful, so I hope that Bram also agrees with me, and
      provides patches for these bugs.

      Meanwhile, I will appreciate if you guys can share your thoughts and
      comments on having this functionality for breakpts plugin.

      Thank you,
      Hari

      __________________________________
      Do you Yahoo!?
      SBC Yahoo! DSL - Now only $29.95 per month!
      http://sbc.yahoo.com
    • Hari Krishna Dara
      Isn t anyone else interested in this topic? With minor changes, I was able to get remote browsing of functions/breakpoints and even set/clear breakpoints
      Message 2 of 8 , Jun 25, 2003
        Isn't anyone else interested in this topic? With minor changes, I was
        able to get remote browsing of functions/breakpoints and even set/clear
        breakpoints working for normal mode. But as I said earlier this is not
        much useful unless if the same is possible even when the remote vim is
        in debug mode.

        Bram, how difficult it would be to fix these bugs? If it is not possible
        for you, I can try to debug myself, but I would need some good pointers
        (I never looked into Vim code).

        I wonder if anyone is reading this thread at all.

        Thanks,
        Hari

        On Mon, 23 Jun 2003 at 5:46pm, Hari Krishna Dara wrote:

        >
        > My latest breakpts.vim script is quite usable and at times I have
        > observed that you can completely avoid creating breakpoints by hand,
        > making it much simpler and faster to do so. But one thing that is still
        > not possible is to extend this convenience when you are already
        > debugging a script.
        >
        > Now I have got a some ideas that would circumvent this problem and
        > make the script much more powerful, making the entire debugging
        > experience much better and almost on par or better than many debuggers.
        > The idea is based on combining the existing plugin capabilities with
        > that of Vim's |remote.txt| features, and be able to control a
        > running/debugging instance of Vim with another Vim through the plugin.
        > At the simplest level, it should be possible to just redirect the
        > commands to another instance through remote_send() and remote_expr()
        > functions, and get a big bang for the buck. But it should also be
        > possible to even visually show the navigate of the execution, and
        > remotely control the flow with the debug commands such as Next, Step
        > etc.
        >
        > To come up with a proof of concept, I started trying some experiments,
        > and the first thing that I noticed is that remote execution of vim code
        > in a Vim instance that is in debug mode is buggy at best. The called
        > instance of Vim either hangs or crashes. There is a lot of built-in
        > functions that can still be executed using remote_expr(), suggesting
        > that this at least is supported.
        >
        > Here is something that can show this buggy behavior:
        >
        > I have the following function defined to get the output of Vim built-in
        > commands, which the plugin is already using.
        >
        >
        > " Just a convenience function. This returns the output of the command as a
        > " string, without corrupting any registers. Returns empty string on errors.
        > " Check for v:errmsg after calling this function for any error messages.
        > function! GetVimCmdOutput(cmd)
        > let v:errmsg = ''
        > let output = ''
        > let _z = @z
        > try
        > redir @z
        > silent exec a:cmd
        > catch /.*/
        > let v:errmsg = substitute(v:exception, '^[^:]\+:', '', '')
        > finally
        > redir END
        > if v:errmsg == ''
        > let output = @z
        > endif
        > let @z = _z
        > endtry
        > return output
        > endfunction
        >
        >
        > - When I remote_expr() this function when Vim is in normal mode, it
        > works fine, but if Vim is in debug mode, then it hangs. The call would
        > look something like this:
        >
        > :echo remote_expr('<vim server name>', "GetVimCmdOutput('ls')")
        >
        > - Similarly, if I remote_send() a command using this function, if Vim is
        > in normal mode, it works fine, but if Vim is in debug mode, it just
        > crashes. The call would look something like this:
        >
        > :call remote_send('<vim server name>', ":let
        @z=GetVimCmdOutput('ls')\<CR>")
        >
        > Having remote debugging functionality for Vim scripts will not only be
        > cool, but very useful, so I hope that Bram also agrees with me, and
        > provides patches for these bugs.
        >
        > Meanwhile, I will appreciate if you guys can share your thoughts and
        > comments on having this functionality for breakpts plugin.
        >
        > Thank you,
        > Hari
        >
        > __________________________________
        > Do you Yahoo!?
        > SBC Yahoo! DSL - Now only $29.95 per month!
        > http://sbc.yahoo.com
        >

        __________________________________
        Do you Yahoo!?
        SBC Yahoo! DSL - Now only $29.95 per month!
        http://sbc.yahoo.com
      • Keith Roberts
        I thought the idea was stupendous, myself, but am far too busy right now to participate in a thread that I thought was outside my purview. I have a lot more to
        Message 3 of 8 , Jun 25, 2003
          I thought the idea was stupendous, myself, but am far too busy right now to
          participate in a thread that I thought was outside my purview.

          I have a lot more to learn before I can contribute intelligently at this
          level, but this seems like something I would use going forward.

          -----Original Message-----
          From: Hari Krishna Dara [mailto:hari_vim@...]
          Sent: Wednesday, June 25, 2003 2:58 PM
          To: vim@...
          Subject: Re: remote debugging ideas for vimscripts


          Isn't anyone else interested in this topic? With minor changes, I was
          able to get remote browsing of functions/breakpoints and even set/clear
          breakpoints working for normal mode. But as I said earlier this is not
          much useful unless if the same is possible even when the remote vim is
          in debug mode.

          Bram, how difficult it would be to fix these bugs? If it is not possible
          for you, I can try to debug myself, but I would need some good pointers
          (I never looked into Vim code).

          I wonder if anyone is reading this thread at all.

          Thanks,
          Hari

          On Mon, 23 Jun 2003 at 5:46pm, Hari Krishna Dara wrote:

          >
          > My latest breakpts.vim script is quite usable and at times I have
          > observed that you can completely avoid creating breakpoints by hand,
          > making it much simpler and faster to do so. But one thing that is still
          > not possible is to extend this convenience when you are already
          > debugging a script.
          >
          > Now I have got a some ideas that would circumvent this problem and
          > make the script much more powerful, making the entire debugging
          > experience much better and almost on par or better than many debuggers.
          > The idea is based on combining the existing plugin capabilities with
          > that of Vim's |remote.txt| features, and be able to control a
          > running/debugging instance of Vim with another Vim through the plugin.
          > At the simplest level, it should be possible to just redirect the
          > commands to another instance through remote_send() and remote_expr()
          > functions, and get a big bang for the buck. But it should also be
          > possible to even visually show the navigate of the execution, and
          > remotely control the flow with the debug commands such as Next, Step
          > etc.
          >
          > To come up with a proof of concept, I started trying some experiments,
          > and the first thing that I noticed is that remote execution of vim code
          > in a Vim instance that is in debug mode is buggy at best. The called
          > instance of Vim either hangs or crashes. There is a lot of built-in
          > functions that can still be executed using remote_expr(), suggesting
          > that this at least is supported.
          >
          > Here is something that can show this buggy behavior:
          >
          > I have the following function defined to get the output of Vim built-in
          > commands, which the plugin is already using.
          >
          >
          > " Just a convenience function. This returns the output of the command as a
          > " string, without corrupting any registers. Returns empty string on
          errors.
          > " Check for v:errmsg after calling this function for any error messages.
          > function! GetVimCmdOutput(cmd)
          > let v:errmsg = ''
          > let output = ''
          > let _z = @z
          > try
          > redir @z
          > silent exec a:cmd
          > catch /.*/
          > let v:errmsg = substitute(v:exception, '^[^:]\+:', '', '')
          > finally
          > redir END
          > if v:errmsg == ''
          > let output = @z
          > endif
          > let @z = _z
          > endtry
          > return output
          > endfunction
          >
          >
          > - When I remote_expr() this function when Vim is in normal mode, it
          > works fine, but if Vim is in debug mode, then it hangs. The call would
          > look something like this:
          >
          > :echo remote_expr('<vim server name>', "GetVimCmdOutput('ls')")
          >
          > - Similarly, if I remote_send() a command using this function, if Vim is
          > in normal mode, it works fine, but if Vim is in debug mode, it just
          > crashes. The call would look something like this:
          >
          > :call remote_send('<vim server name>', ":let
          @z=GetVimCmdOutput('ls')\<CR>")
          >
          > Having remote debugging functionality for Vim scripts will not only be
          > cool, but very useful, so I hope that Bram also agrees with me, and
          > provides patches for these bugs.
          >
          > Meanwhile, I will appreciate if you guys can share your thoughts and
          > comments on having this functionality for breakpts plugin.
          >
          > Thank you,
          > Hari
          >
          > __________________________________
          > Do you Yahoo!?
          > SBC Yahoo! DSL - Now only $29.95 per month!
          > http://sbc.yahoo.com
          >

          __________________________________
          Do you Yahoo!?
          SBC Yahoo! DSL - Now only $29.95 per month!
          http://sbc.yahoo.com
        • Hugh Saunders
          ... i am, but im very new to programming [except VB-yuk and a few bash scripts :-/ ] so wouldnt be much use to you for vim-hacking!! Just to say someone is
          Message 4 of 8 , Jun 25, 2003
            On Wed, Jun 25, 2003 at 03:58:29PM -0700, Hari Krishna Dara wrote:
            > I wonder if anyone is reading this thread at all.
            i am, but im very new to programming [except VB-yuk and a few bash
            scripts :-/ ] so wouldnt be much use to you for vim-hacking!!

            Just to say someone is listening ;)

            --
            hugh
          • Bram Moolenaar
            ... I have no high priority for extending the debug facilities, but crashes must be fixed, of course. It s in the todo list now. An indication where it
            Message 5 of 8 , Jun 26, 2003
              Hari Krishna Dara wrote:

              > Isn't anyone else interested in this topic? With minor changes, I was
              > able to get remote browsing of functions/breakpoints and even set/clear
              > breakpoints working for normal mode. But as I said earlier this is not
              > much useful unless if the same is possible even when the remote vim is
              > in debug mode.
              >
              > Bram, how difficult it would be to fix these bugs? If it is not possible
              > for you, I can try to debug myself, but I would need some good pointers
              > (I never looked into Vim code).

              I have no high priority for extending the debug facilities, but crashes
              must be fixed, of course. It's in the todo list now. An indication
              where it crashes would help a lot.

              --
              Some of the well know MS-Windows errors:
              EMULTI Multitasking attempted, system confused
              EKEYBOARD Keyboard locked, try getting out of this one!
              EXPLAIN Unexplained error, please tell us what happened
              EFUTURE Reserved for our future mistakes

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
              \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
              \\\ Help AIDS victims, buy at Amazon -- http://ICCF.nl/click1.html ///
            • Hari Krishna Dara
              Keith and Hugh, thanks a lot for your responses. I thought, may be it was a wachky idea which is why nobody even cared to say it is going to be useful :) Hari
              Message 6 of 8 , Jun 26, 2003
                Keith and Hugh, thanks a lot for your responses. I thought, may be it
                was a wachky idea which is why nobody even cared to say it is going to be
                useful :)

                Hari

                On Wed, 25 Jun 2003 at 4:05pm, Keith Roberts wrote:

                > I thought the idea was stupendous, myself, but am far too busy right now to
                > participate in a thread that I thought was outside my purview.
                >
                > I have a lot more to learn before I can contribute intelligently at this
                > level, but this seems like something I would use going forward.
                >
                > -----Original Message-----
                > From: Hari Krishna Dara [mailto:hari_vim@...]
                > Sent: Wednesday, June 25, 2003 2:58 PM
                > To: vim@...
                > Subject: Re: remote debugging ideas for vimscripts
                >
                >
                > Isn't anyone else interested in this topic? With minor changes, I was
                > able to get remote browsing of functions/breakpoints and even set/clear
                > breakpoints working for normal mode. But as I said earlier this is not
                > much useful unless if the same is possible even when the remote vim is
                > in debug mode.
                >
                > Bram, how difficult it would be to fix these bugs? If it is not possible
                > for you, I can try to debug myself, but I would need some good pointers
                > (I never looked into Vim code).
                >
                > I wonder if anyone is reading this thread at all.
                >
                > Thanks,
                > Hari

                __________________________________
                Do you Yahoo!?
                SBC Yahoo! DSL - Now only $29.95 per month!
                http://sbc.yahoo.com
              • Hari Krishna Dara
                ... Fixing these issues itself is a BIG help to me for providing most of the enhancements that I was thinking for breakpts.vim. Though only a few people
                Message 7 of 8 , Jun 30, 2003
                  On Thu, 26 Jun 2003 at 10:22am, Bram Moolenaar wrote:

                  >
                  > I have no high priority for extending the debug facilities, but crashes
                  > must be fixed, of course. It's in the todo list now. An indication
                  > where it crashes would help a lot.
                  >

                  Fixing these issues itself is a BIG help to me for providing most of the
                  enhancements that I was thinking for breakpts.vim. Though only a few
                  people responded to this thread, I am sure a lot more people would find
                  these features useful. Isn't providing better tools to help develop vim
                  scripts, going to indirectly help more people switch to Vim (by helping
                  to create better/more plugins faster)?

                  I don't know how to figure out where it is crashing. What kind of
                  information are you looking for? In my original email I reported a way
                  to reproduce the crash/malfunction (on W2K at least), here it is again:


                  > Here is something that can show this buggy behavior:
                  >
                  > I have the following function defined to get the output of Vim built-in
                  > commands, which the plugin is already using.
                  >
                  >
                  > " Just a convenience function. This returns the output of the command as a
                  > " string, without corrupting any registers. Returns empty string on errors.
                  > " Check for v:errmsg after calling this function for any error messages.
                  > function! GetVimCmdOutput(cmd)
                  > let v:errmsg = ''
                  > let output = ''
                  > let _z = @z
                  > try
                  > redir @z
                  > silent exec a:cmd
                  > catch /.*/
                  > let v:errmsg = substitute(v:exception, '^[^:]\+:', '', '')
                  > finally
                  > redir END
                  > if v:errmsg == ''
                  > if v:errmsg == ''
                  > let output = @z
                  > endif
                  > let @z = _z
                  > endtry
                  > return output
                  > endfunction
                  >
                  >
                  > - When I remote_expr() this function when Vim is in normal mode, it
                  > works fine, but if Vim is in debug mode, then it hangs. The call would
                  > look something like this:
                  >
                  > :echo remote_expr('<vim server name>', "GetVimCmdOutput('ls')")
                  >
                  > - Similarly, if I remote_send() a command using this function, if Vim is
                  > in normal mode, it works fine, but if Vim is in debug mode, it just
                  > crashes. The call would look something like this:
                  >
                  > :call remote_send('<vim server name>', ":let
                  @z=GetVimCmdOutput('ls')\<CR>")

                  To be more precise about the steps,
                  - start two instances of vim, say vim1 and vim2.
                  - source the above function in vim2.
                  - take vim2 in debug mode. You can try:
                  :debug Explore
                  and a couple of >step's.
                  - Go to vim1 and try the following for the hang:
                  :echo remote_expr('vim2', "GetVimCmdOutput('ls')")
                  - and the following for the crash:
                  :call remote_send('vim2', ":let @z=GetVimCmdOutput('ls')\<CR>")

                  Please let me know what other information you need, I will be happy to
                  provide you whatever I can.

                  Thank you,
                  Hari

                  __________________________________
                  Do you Yahoo!?
                  SBC Yahoo! DSL - Now only $29.95 per month!
                  http://sbc.yahoo.com
                • Zdenek Sekera
                  Very good idea, I would certainly make use of it!
                  Message 8 of 8 , Jul 1, 2003
                    Very good idea, I would certainly make use of it!

                    ---Zdenek

                    > > -----Original Message-----
                    > > From: Hari Krishna Dara [mailto:hari_vim@...]
                    > > Sent: Wednesday, June 25, 2003 2:58 PM
                    > > To: vim@...
                    > > Subject: Re: remote debugging ideas for vimscripts
                    > >
                    > >
                    > > Isn't anyone else interested in this topic? With minor changes, I was
                    > > able to get remote browsing of functions/breakpoints and even set/clear
                    > > breakpoints working for normal mode. But as I said earlier this is not
                    > > much useful unless if the same is possible even when the remote vim is
                    > > in debug mode.
                    > >
                    > > Bram, how difficult it would be to fix these bugs? If it is not possible
                    > > for you, I can try to debug myself, but I would need some good pointers
                    > > (I never looked into Vim code).
                    > >
                    > > I wonder if anyone is reading this thread at all.
                    > >
                    > > Thanks,
                    > > Hari
                    >
                    > __________________________________
                    > Do you Yahoo!?
                    > SBC Yahoo! DSL - Now only $29.95 per month!
                    > http://sbc.yahoo.com
                  Your message has been successfully submitted and would be delivered to recipients shortly.