Integrate Eclipse debugger with VIM

[Kannan]

Eric,

  I have attempted to expose Eclipse debugger functionality from inside VIM. It's a first cut. I am sending it out early so that I can get your feedback on the approach, coding conventions, etc. This is the first time I am contributing, so will need your guidance. Your documentation is excellent and it helped me quickly ramp up.

I have pushed the changes to my fork of the eclim repo. Please review the changes. I have marked some TODOs in the code itself. I have described the functionality in the commit message.

https://github.com/rkannan82/eclim/commit/270c14cca62adca12dcfef29d97361c9c6d84503

 

 

-- 

Kannan

[Eric Van Dewoestine]

Overall this looks very good!

I haven't had a chance to try it out yet, but after scanning the code
I have some comments:
- code style: you can run $ ant checkstyle from the eclim repo root
to see what parts of the code don't conform to eclim's coding style.
While scanning the code I see obvious stuff, but running checkstyle
will give you a full report.
- regarding the vimInstanceId, it would be nice to pass v:servername
from vim to eclim when running :JavaDebug, and to have :JavaDebug
validate that v:servername is indeed set, and if not, instruct the
user on how to do that.
- I think the DebugCommand should perform some validation of the
connection info (<host>:<port>) and return an appropriate error
message if it is malformed. It should probably also return some sort
of status message on start/stop, and maybe resume.
- Would it make sense to have some sort of status command so the user
can see some info regarding the current session? Does eclipse allow
you to have more than one debugging session open at a time?

I'm not sure exactly when I'll get a chance to actually run this code
and provide more feedback, but please feel free to keep working on
this as it is looking great!

If any other eclim users out there are reading this and would like to
try out Kannan's code and provide feedback, that would be much
appreciated as well.

> -- 
> Kannan

--
eric

[Kannan]

Eric,

  I have pushed another commit to my local repo. I have addressed your earlier comments and added a bunch of new capabilities. Commit: https://github.com/rkannan82/eclim/commit/833e1bb0253d342b35c056237b069f2833171fbb

Comments addressed

1. ant checkstyle does not report any errors.

2. Pass vim instance id, error handling.

3. Error handling for host and port arguments while starting debug session.

4. Status command: Thanks for pointing this out. I will definitely add them in the coming weeks. But want to focus on adding some core functions before that.

I have documented the commands implemented so far in debug.rst file: https://github.com/rkannan82/eclim/blob/debugger/doc/content/vim/java/debug.rst

-- 

Kannan

--
You received this message because you are subscribed to the Google Groups "eclim-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.
To post to this group, send email to ecli...@googlegroups.com.
Visit this group at http://groups.google.com/group/eclim-dev.
For more options, visit https://groups.google.com/d/optout.

[Kannan]

Eric,

  I want to get a sense of how and when this debugger functionality can be folded into your repo so that it can be made available as part of eclim release. I suppose we need to consider the following. Please let me know what the expectations are so that I can work on them.

1. Testing: Make sure that this feature does not destabilize the regular functionalities. So far I have only been doing manual testing. Need to write unit tests.

2. Code review: This is a pain staking part given your busy schedule.

3. We can call this as an experimental feature until we get sufficient feedback and improvements.

 

-- 

Kannan

To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.

[Eric Van Dewoestine]

On 2014-08-06 10:35:43, Kannan wrote:
> Eric,
>   I want to get a sense of how and when this debugger functionality can be folded into your repo so that it can be made available as part of eclim release.

I was hoping to have done it last sunday, but I didn't get a chance.
Hopefully I'll get to it this weekend.

> I suppose we need to consider the following. Please let me know what the expectations are so that I can work on them.
>
> 1. Testing: Make sure that this feature does not destabilize the regular functionalities. So far I have only been doing manual testing. Need to write unit tests.
> 2. Code review: This is a pain staking part given your busy schedule.
> 3. We can call this as an experimental feature until we get sufficient feedback and improvements.
>

Normally I wouldn't merge the feature into master until the tests and
docs are completed (both of which I've almost always done for
contributed features), but I think I'm fine with merging this in as
soon as I can run through some manual tests and a do a quick scanning
of the code.

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.

--
eric

[Kannan]

Thanks for your time Eric. As I mentioned earlier, I have documented the command here: https://github.com/rkannan82/eclim/blob/debugger/doc/content/vim/java/debug.rst

 

-- 

Kannan

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.

--
eric

--
You received this message because you are subscribed to the Google Groups "eclim-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

[Eric Van Dewoestine]

On 2014-08-02 17:23:28, Kannan wrote:
> Eric,

>   I have pushed another commit to my local repo. I have addressed your earlier comments and added a bunch of new capabilities. Commit: https://github.com/rkannan82/eclim/commit/833e1bb0253d342b35c056237b069f2833171fbb
>
> Comments addressed
> 1. ant checkstyle does not report any errors.
> 2. Pass vim instance id, error handling.
> 3. Error handling for host and port arguments while starting debug session.
> 4. Status command: Thanks for pointing this out. I will definitely add them in the coming weeks. But want to focus on adding some core functions before that.
>
> I have documented the commands implemented so far in debug.rst file: https://github.com/rkannan82/eclim/blob/debugger/doc/content/vim/java/debug.rst
>
> -- 
> Kannan

I created a new branch (debugger[1]) which now includes your changes. I
did make some changes[2] of my own as I started testing and looking at
the code:

- I couldn't compile the code as is, so I had to add the
org.eclipse.jdt.debug/*.jar files to the org.eclim.jdt build
classpath
- When I attempted to start a debugging session I got an error because
it was attempting to add all projects to the JavaSourceLocator,
which in turn failed when it encountered a non-java project.
- there is no need to call logger.isXXXEnabled since these aren't high
volume logging statements. It just bloats the code. If they were
high volume, I'd suggest using the logger.xxx(<string>, <arg>,
<arg>, ...) form instead to avoid the string concatenation overhead.
- no need to log the command executed in each command implementation. Eclim
already does this if you start eclimd with --debug

Aside from those the code looks good, but as a user a few things
bothered me:
- there is no indication that the program is suspended on a particular
line, or that it is running and I need to wait for one of my
breakpoints to be hit. Perhaps the current breakpoint line should be
highlighted when the program is waiting on it. I think a temp window
opened at the start of the debug session and updated accordingly as
the user steps though would be nice. If they close it, it would be
nice to have a way to ask the daemon for the current state so that
the window could be re-opened with the proper info.
I know this isn't trivial, but I think having good feedback as to
what is happening is vital to a good user experience.
- is there any way to know that the program has terminated? running
debug step gives no indication. perhaps another use for a temp
session window.
- these should probably be dedicated commands since :JavaDebugStart is a
command. As a user I was looking for :JavaDebugStop in particular:
:JavaDebugControl suspend
:JavaDebugControl resume
:JavaDebugControl stop


Thanks again for all the work on this. I think it's pretty close to
being release worthy.


[1] https://github.com/ervandew/eclim/tree/debugger
[2] https://github.com/ervandew/eclim/commit/e736aa74051eb12cbbdcfe91de28933002c5fff4

eric

[Kannan]

Great Eric! I will rebase my branch using your debugger branch. I will also follow the coding guidelines based on your last commit.

- Missing jar: Totally forgot about it. I was manually copying the jdimodel.jar to the plugins locations until now :)

- Didn't realize the --debug option. I was going to suggest that we create an execute method in AbstractCommand and create an abstract method called onExecute that all commands can implement. It can be useful for adding common code like this. Today, when there is an exception, it just shows up as a generic error in eclimd.log. A stacktrace would be helpful here. Thoughts?

-----------------------------

AbstractCommand

execute() {

  try {

    onExecute();

  } catch (Exception e) {

    logger.error("Command failed", e);

  }

}

-----------------------------

- User interface: You rightly pointed out the issues. I am going to address them in this iteration. As you suggested, I will look at creating a DebugSessionStatus window with relevant information. Note that we already have 2 windows available; one for variables and another for thread stack frames. I intend to add a watch point view similar to Eclipse UI once we iron out the basic UI issues.

- I combined those into JavaDebugControl because they seemed related and I thought of avoiding creating multiple classes. But as you said, its better to separate them out. I will go ahead and create 2 commands:

:JavaDebugStop

:JavaDebugThread -a suspend/resume -t thread_id  -> if thread_id is not specified, then it applies to all threads. 

 

-- 

Kannan

[Kannan]

Eric,

  I have a Git question. While pulling your changes, I did a simple "git pull upstream debugger" which produced a merge commit based on your debugger branch. Is this right, or do you want me to rebase using "git pull --rebase" command? What command did you use to pull my changes?

  About handling failures. When eclim command fails, the exception is displayed in VIM. How does this happen? What is the code that that outputs it to VIM?

  Also, after getting your changes, I get this /formic does not exist error. How do I fix it?

Example:

If I run :JavaDebugStart localhost 5000 without running a target VM, then I get this error on VIM:

  

org.eclipse.core.internal.resources.ResourceException: Resource '/formic' does not exist.

while executing command (port: 9092): -editor vim -command java_debug_start -p "eclim" -h "localhost" -n "5000" -v "ECLIM"

 

-- 

Kannan

To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.

[Eric Van Dewoestine]

On 2014-08-09 23:36:57, Kannan wrote:
> Eric,

>   I have a Git question. While pulling your changes, I did a simple "git pull upstream debugger" which produced a merge commit based on your debugger branch. Is this right, or do you want me to rebase using "git pull --rebase" command?

A straight merge is fine, don't worry about rebasing.

> What command did you use to pull my changes?

I simply used a merge so that I could get your changes on top of the
latest eclim master without altering your history.

>   About handling failures. When eclim command fails, the exception is displayed in VIM. How does this happen? What is the code that that outputs it to VIM?

When an error occurs, the exception is returned to the client instead
of the json, and it's up to the client (my vim plugins in this case)
to recognize that and alter the user. When I converted to all json
responses a while back I should have thrown the exceptions in a json
response as well, but I didn't think about it at the time.

>   Also, after getting your changes, I get this /formic does not exist error. How do I fix it?
> Example:
> If I run :JavaDebugStart localhost 5000 without running a target VM, then I get this error on VIM:
>
> org.eclipse.core.internal.resources.ResourceException: Resource '/formic' does not exist.
> while executing command (port: 9092): -editor vim -command java_debug_start -p "eclim" -h "localhost" -n "5000" -v "ECLIM"

Hmm, I'm surprised that got past the p.hasNature(JavaCore.NATURE_ID)
test. Try updating DebuggerContext to check if the project exists
prior to the hasNature check:

if (p.exists() && p.hasNature(JavaCore.NATURE_ID)){
javaProjects.add(JavaUtils.getJavaProject(p));
}

Also I'm guessing you ran :JavaDebugStart while an eclim source file
was focused? With my change to the DebugStartCommand, it expects that
a source file from the project you want to debug is in focus, so that
it can load that project and all its dependencies into the
JavaSourceLocator, instead of the previous behavior of loading all
projects (I've seen users with a ton of projects, so I don't like the
idea of loading them all).

> - User interface: You rightly pointed out the issues. I am going to address them in this iteration. As you suggested, I will look at creating a DebugSessionStatus window with relevant information. Note that we already have 2 windows available; one for variables and another for thread stack frames. I intend to add a watch point view similar to Eclipse UI once we iron out the basic UI issues.

I was thinking about this some more today and I think it would be nice
to have the following flow:

:JavaDebugStart ...

[Debug Session] temp window is opened containing:
- current program state: running, suspended, waiting on breakpoint
(whatever all the states are).
- when a break point is triggered, I think the window should update
with the file and line number of the breakpoint and the user should
be allowed to hit <enter> on that to jump to that file/line (the
file may or may not currently be open in a window). For text style
links like this I have a quasi eclim standard of using |link name|
similar to vim help files, then I use a little syntax highlighting
to make them stand out.
- I also think the variables and stack frame windows can be
incorporated here by providing 2 more links, which when triggered
via <enter> can display the requested info inline (I haven't thought
much about the formatting). Another option would be to push that
info to vim when a breakpoint is encountered, but that may required
using vim's netbeans integration, which isn't ideal. I'm also not
sure what the overhead is of grabbing that info in a large program,
so perhaps sticking to links would be easiest.
A couple advantages of this consolidation would be:
- keeps the debugging session down to a max of 1 temp window
- the user can get the info they want without having to
remember/recall the proper eclim command to get that info. As a
result, those dedicated vim commands could also be removed.

Thoughts?

> - I combined those into JavaDebugControl because they seemed related and I thought of avoiding creating multiple classes. But as you said, its better to separate them out. I will go ahead and create 2 commands:
> :JavaDebugStop
> :JavaDebugThread -a suspend/resume -t thread_id  -> if thread_id is not specified, then it applies to all threads. 

Sounds good.

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.

--
eric

[Kannan]

Eric,

  I made progress last week on improving the user interface by adding a status command and a view. But I haven't figured out a few issues. It will be great if you can help me out with some vimscript functionalities that I am not familiar with.

1. :JavaDebugStatus command will open a temp window and split it vertically. On left side, it will show connection information and threads. On the right side, it will show the variables. I modified the TempWindow method in util.vim to create a vertical split (vert sview command), but it does not work. It ends up creating a single window with both threads and variables. What am I doing wrong?

https://github.com/rkannan82/eclim/commit/d79b5b51bdc8d5bb6a81f9fe42cd9be518b06055

https://github.com/rkannan82/eclim/commit/d79b5b51bdc8d5bb6a81f9fe42cd9be518b06055

2. The temp window gets created in the bottom. But when I try to load a file from external VIM command in VimClient.java, its position shifts to top and then some other time it comes to bottom. I am not sure what is causing this. Do you have any idea? Is there a way to force the position to not change?

Command used from Java: vim --servername x --remote-tab +10 file_path

 

-- 

Kannan

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.

--
eric

--
You received this message because you are subscribed to the Google Groups "eclim-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

[Eric Van Dewoestine]

On 2014-08-18 13:48:00, Kannan wrote:
> Eric,
>   I made progress last week on improving the user interface by adding a status command and a view. But I haven't figured out a few issues. It will be great if you can help me out with some vimscript functionalities that I am not familiar with.
>
> 1. :JavaDebugStatus command will open a temp window and split it vertically. On left side, it will show connection information and threads. On the right side, it will show the variables. I modified the TempWindow method in util.vim to create a vertical split (vert sview command), but it does not work. It ends up creating a single window with both threads and variables. What am I doing wrong?
>
> https://github.com/rkannan82/eclim/commit/d79b5b51bdc8d5bb6a81f9fe42cd9be518b06055
>
> https://github.com/rkannan82/eclim/commit/d79b5b51bdc8d5bb6a81f9fe42cd9be518b06055
>
> 2. The temp window gets created in the bottom. But when I try to load a file from external VIM command in VimClient.java, its position shifts to top and then some other time it comes to bottom. I am not sure what is causing this. Do you have any idea? Is there a way to force the position to not change?

You couldn't see the issue because the TempWindow function opens the
window with the use of 'silent!' (to suppress autocmd warnings, etc),
but just adding 'vert' to the command didn't work because the height
argument was then in the wrong place. I updated the TempWindow code to
handle this and remove those 2 separate functions and went back to a
single function with an 'orientation' option.

My changes get the windows working, but there are resizing issues as
other windows are opened/closed. I can look more into that when I get
time, but window management in vim is a huge pain. I think the
orientation of these windows should also be configurable by the user.
I run vim in a tiling window manager, where vim takes up half my
screen, so I don't have a lot of space for displaying debugging info
side by side with the file. For cases like this it would be nice to
open those windows at the bottom as horizontal splits.

> Command used from Java: vim --servername x --remote-tab +10 file_path

Once I fixed the temp window issue I did notice that the use of
'--remote-tab' seems to induce opening of the file in a new tab
(multiple times). I'm guessing that command is intended to jump to the
current breakpoint? If so, that might be better accomplished as a part
of the JavaDebugStatus call, where you can have more control (perhaps
as an extra argument when called from eclimd).

I should also mention that I made more coding style changes. I also
renamed ':JavaDebugToggleBreakpoint' to ':JavaDebugBreakpointToggle'.
I tend to use vim's wildmenu to complete commands, so when I type
:JavaDebug<tab> I would see :JavaDebugBreakpoint, but not the toggle
version (since it was at or near the end), so I kept wanting to run
:JavaDebugBreakpoint. The new names puts these side by side. I'm also
thinking that perhaps :JavaDebugBreakpoint should be renamed or split
out into the 2 commands that it represents.

Overall this feature is looking pretty good! I think now it's just a
matter of dealing with edge cases, etc.

--
eric

[Kannan]

Thanks Eric. I will rebase with your changes today. Please note that I am working on some critical bug fixes related to the debug status window from usability point of view. Once I resolve those, I will send you an update. So until then, you don't have to unnecessarily spend time on the window management problem. Let me wrap up this part and then we can nail them down.

 

-- 

Kannan

--
eric

[Carlos Torres]

I have a couple of questions about the new window created:
Is it a gvim window or a term window with vim in it, what is the pwd if the New window? Can the terminal it starts in be changed? Is that configurable? Suppose I want to change the wmclass of the terminal?

Thanks this is a great addition!

To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.

[Eric Van Dewoestine]

On 2014-08-24 17:11:47, Carlos Torres wrote:
> I have a couple of questions about the new window created:
> Is it a gvim window or a term window with vim in it, what is the pwd if the
> New window? Can the terminal it starts in be changed? Is that configurable?
> Suppose I want to change the wmclass of the terminal?

It is just another window in the current vim instance (2 windows
actually, one for the variables, and the other for the stack).

> > email to eclim-dev+...@googlegroups.com.
> > To post to this group, send email to ecli...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/eclim-dev.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "eclim-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to eclim-dev+...@googlegroups.com.
> > To post to this group, send email to ecli...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/eclim-dev.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.

--
eric

[Kannan]

Eric,

  I rebased against your changes. Latest commit is here: https://github.com/rkannan82/eclim/commit/c0fbc4f8145a31dae75cf23c8e642bad99e1b18e

1. About the vertical split change that you made to debug status window  ...  You are using the VeriticalToolWindowOpen method and this created a vertical window that spans the full height of VIM window . I actually wanted to create the vertical split inside the first temp window that was created for Debug Threads. So I have changed it to use the following. Hope that is OK.

     let split_cmd = "belowright vertical " . width . " sview "

      silent! noautocmd exec "keepalt " . split_cmd . name 

 2. Next, I will be addressing your earlier comments about creating separate command for debug stop, etc.

  

 3. Problems/Questions

- I have created the GoToTabAwareBufferWindowOrOpen method in util.vim to be able to switch to buffers that are in different tab. This requires us to set vim setting 'switchbuf'. I have set it to: switchbuf=usetab,newtab. But this does not open window in a tab if buffer already exists, but is not present in any tab/window. It always splits the current window. Do you know why?

- When I have set cursorline, the current line is highlighted using some highlight group. When I stepping through code, I am also highlighting the line using a hard coded color group - DebugStop. In my case its RED. But the current line color (light blue) seems to over shadow the debug highlight color red. Is there a way to reverse it and set the precedence?

- When we place multiple signs on same line using the same identifier (line number), that would cause problems when we unplace, right? How do we normally address this problem? For e.g., eclim could be placing signs for compilation results. The debugging session creates signs for breakpoint, current line, etc and then removes them as we step through.

4. TODOs

- externalize highlight color group to use for showing current debug step line

- externalize height and width of debug status window 

 

-- 

Kannan

To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.

[Carlos Torres]

On Aug 24, 2014 7:34 PM, "Eric Van Dewoestine" <erva...@gmail.com> wrote:
> It is just another window in the current vim instance (2 windows
> actually, one for the variables, and the other for the stack).

Lol, my bad,

--Carlos

[Eric Van Dewoestine]

On 2014-08-24 17:23:43, Kannan wrote:
> Eric,
>   I rebased against your changes. Latest commit is here: https://github.com/rkannan82/eclim/commit/c0fbc4f8145a31dae75cf23c8e642bad99e1b18e
>
> 1. About the vertical split change that you made to debug status window  ...  You are using the VeriticalToolWindowOpen method and this created a vertical window that spans the full height of VIM window . I actually wanted to create the vertical split inside the first temp window that was created for Debug Threads.

Ah, ok, that makes sense. I mis-interpreted your intent, but I like
your actually intent much better.

> So I have changed it to use the following. Hope that is OK.
>      let split_cmd = "belowright vertical " . width . " sview "
>       silent! noautocmd exec "keepalt " . split_cmd . name 

That looks good for now, but this is pretty specific usage, so it
might need a refactoring later. Although I've never had a use for a
'true' (as in full vertical) virtically split temp window, so perhaps
this is just fine.

>  2. Next, I will be addressing your earlier comments about creating separate command for debug stop, etc.
>   
>  3. Problems/Questions
> - I have created the GoToTabAwareBufferWindowOrOpen method in util.vim to be able to switch to buffers that are in different tab. This requires us to set vim setting 'switchbuf'. I have set it to: switchbuf=usetab,newtab. But this does not open window in a tab if buffer already exists, but is not present in any tab/window. It always splits the current window. Do you know why?

I don't know off hand. If you can't figure it out, I'll try it out and
see what I can come up with. I did notice that in your current
implementation of that function you aren't setting 'switchbuf', so
does that mean you have it set in your vimrc? You can set it in that
function so long as you save the user's current setting and restore it
in a finally block.

> - When I have set cursorline, the current line is highlighted using some highlight group. When I stepping through code, I am also highlighting the line using a hard coded color group - DebugStop. In my case its RED. But the current line color (light blue) seems to over shadow the debug highlight color red. Is there a way to reverse it and set the precedence?

This can get tricky since colorschemes can vary widely. I try to base
all my highlight groups on core groups, but if you are dealing with
background colors to highlight the line, then its bound to cause a
problem with someone's colorscheme at some point. I'd have to play
with this as well to see what's going on and perhaps come up with
something that will hopefully look ok for most users.

> - When we place multiple signs on same line using the same identifier (line number), that would cause problems when we unplace, right? How do we normally address this problem? For e.g., eclim could be placing signs for compilation results. The debugging session creates signs for breakpoint, current line, etc and then removes them as we step through.

Signs can definitely be a problem. This may require some rethinking of
eclim sign placement. Perhaps some sort of bit masking can be used
when generating the sign id so we can then later unplace based on the
original type. It's been awhile since I've really thought about vim
signs and their quirks, so again, this is another aspect that I'd have
to fiddle with.

> 4. TODOs
> - externalize highlight color group to use for showing current debug step line
> - externalize height and width of debug status window 

Looking good. I'll probably be busy all week again, but hopefully I
can squeeze out some time to play around some more and get you more
feedback and/or minor improvements.

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.
> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.

--
eric

[Kannan]

Eric,

  I have completed the core functionalities. I have removed the breakpoint toggle command and added separate commands for adding, removing breakpoints. I will add back the toggle for enabling or disabling breakpoints. This is not very important right now.

I have updated debug.rst with latest commands. Please let me know if you have any feedback.

Next, I am going to look at 2 main things:

1. Performance: The status window is refreshed every time a new thread is created. Every time a thread is created, the stacktrace of all threads are being recomputed (concatenated into string). In a large setup like Hadoop where there are about 200 threads, this takes a long time, especially when you debugging VM is remote. I am going to find a way to send incremental information to the status window.

One limitation of VIM that I realized is how its single threaded. When I run one command from the editor, I cannot do anything else. Can't even jump to a different window, because that is another VIM command. This becomes problematic when the debugging session is started as new threads get added one after other. The debug status refresh command is run many times. Of course, this happens mostly during startup.

2. Breakpoint window: Instead of opening a separate window, I plan to load the breakpoint buffer inside the variables window (right side of status window). When you quit the breakpoint buffer, variables buffer will be automatically restored. The thread view will remain as is during this time. This will be concise and also similar to Eclipse shows it.

 

-- 

Kannan

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.

--
eric

--
You received this message because you are subscribed to the Google Groups "eclim-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+unsub...@googlegroups.com.

[Eric Van Dewoestine]

On 2014-09-06 18:46:19, Kannan wrote:
> Eric,
> I have completed the core functionalities. I have removed the breakpoint toggle command and added separate commands for adding, removing breakpoints. I will add back the toggle for enabling or disabling breakpoints. This is not very important right now.
> I have updated debug.rst with latest commands. Please let me know if you have any feedback.
>
> Next, I am going to look at 2 main things:
> 1. Performance: The status window is refreshed every time a new thread is created. Every time a thread is created, the stacktrace of all threads are being recomputed (concatenated into string). In a large setup like Hadoop where there are about 200 threads, this takes a long time, especially when you debugging VM is remote. I am going to find a way to send incremental information to the status window.
>
> One limitation of VIM that I realized is how its single threaded. When I run one command from the editor, I cannot do anything else. Can't even jump to a different window, because that is another VIM command. This becomes problematic when the debugging session is started as new threads get added one after other. The debug status refresh command is run many times. Of course, this happens mostly during startup.

Yeah, vim being single threaded makes things like this a bit of a pain
to deal with. A few thoughts on working around vim's limitations (none
of which are ideal):

- Perhaps the daemon side can queue up changes for some configured
timeout so that it won't send more than one update for that time
frame? Waiting for even 100ms could potentially reduce the command
chatter without the user perceiving any additional delay. Obviously
an app with a lot of thread churn could still make the updates
painfully disruptive.

- If starting up the session is when this most commonly occurs,
perhaps the daemon can monitor as threads are created and keep track
of that rate for some amount of time to decide when the initial
flurry has passed before starting to send status updates to the
client? It could even always track the rate at which updates are
occurring and inform the user that the rate is too high for vim to
handle. That would prevent the daemon from ever overloading vim to
the point at which the user can't interact with it.

- Another option would be to send updates to something other than the
current vim instance, like a separate instance in tmux. I wrote
another vim plugin[1] which can bootstrap a new tmux session from
vim, create a new pane if the user is already in a tmux session, or
spawn off a shell with tmux in it if the user is using gvim/macvim.
Something like that could be used when starting a debug session, and
status updates could be directed to a the vim instance in the new
tmux pane. This is a pretty hacky workaround with its own set of
limitations, so I'd try solving this problem on the daemon side as
much as possible.

- For completeness I'll also mention that you can get around vim being
single threaded by using its python support, which can start threads
in the python vm. However, I've played around with doing this for
other plugins, and issuing vim commands from a python thread is full
of ways to inadvertently crash vim. You would also still be forced
to rely on vim to update the status window, so you'd be back to a
case of rapid status changes potentially disrupting the user's vim
interaction.

[1] https://github.com/ervandew/screen

> 2. Breakpoint window: Instead of opening a separate window, I plan to load the breakpoint buffer inside the variables window (right side of status window). When you quit the breakpoint buffer, variables buffer will be automatically restored. The thread view will remain as is during this time. This will be concise and also similar to Eclipse shows it.

I scanned over your changes and they look good to me. I'll hold off on
testing your changes extensively until you've addressed the other
changes you want to make. Overall this continues to look great, so
once you are happy with the implementation, let me know and I'll do
some thorough testing myself before I merge it into master.

For any other eclim users monitoring this discussion, please feel free
to test this out and provide feedback (Kannan's latest changes are now
on eclim's 'debugger' branch). From a user interaction point of view,
this is probably the most complex feature added to eclim to date, so
feedback from other users would be nice to have.

> > To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.

> > To post to this group, send email to ecli...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/eclim-dev.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "eclim-dev" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.

> > To post to this group, send email to ecli...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/eclim-dev.
> > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google Groups "eclim-dev" group.

> > To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.

> > To post to this group, send email to ecli...@googlegroups.com.
> > Visit this group at http://groups.google.com/group/eclim-dev.
> > For more options, visit https://groups.google.com/d/optout.
>
>
> --
> eric
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.

> To post to this group, send email to ecli...@googlegroups.com.
> Visit this group at http://groups.google.com/group/eclim-dev.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "eclim-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to eclim-dev+...@googlegroups.com.

[Kannan]

Eric,

  Great suggestions. I was also thinking of buffering the updates, but later realized that there is an easier way to just wait until the debug target is created and then do a status refresh. The last commit that that you merged has it. The right fix is to push incremental updates to status window instead of recreating it every time something changes. I expect that to address this concern fully. If it does not, then I will try to do the buffering as you suggested.

  Here are the pending items in the order of priority. Let me know if you are OK with this or you want me to do get some of them done for this release itself.

This release

- Command to expand variables: I will try to get this done this week.

Right now, I have limited the depth of variables to just 2. This means, if a variable is an object and it has objects within it, then we would only go 1 level deep. It doesn't make sense to compute the entire depth as users wouldn't need all of them. It is a very costly operation for complicated data structures such as Hadoop. Also, there are cases where there can be infinite nesting because of 2 objects referring each other.

Next release

- Performance improvement: Incremental updates to status window.

- Merge breakpoint window into the debug status window.

 

-- 

Kannan