On 2014-09-13 11:08:24, Kannan wrote:
> Eric,
> I have implemented the variable expansion command. Now we should be able to press <Enter> on a variable and expand it to show its child variables. I also externalized some settings. The doc has been updated to reflect all of this. Please let me know your suggestions based on your testing.
I started looking at the latest code and I do have some feedback:
- I fixed some coding style issues and committed those
- I update the :JavaDebugStart command to not require args on the vim
definition so that the function can perform it's own validation and
provide better feedback to the user. I keep finding myself
forgetting what the format of the command is, so now I'll get a
clear example should I not supply the correct args (I kept wanting
to use :JavaDebugStart localhost:1044, but would get the generic
vim error do to insufficient args)
- I also updated the status function to issue a full redraw since the
remote initiated status calls would result in a pretty bad rendering
state. A full redraw may or may not be overkill, but I didn't notice
any flickering in my simple test case.
- I'm wondering why you got rid of JavaDebugBreakpointToggle in
favor of Add/Remove commands? The toggle version seems like
something that most people would want to create mapping for.
- Regarding the thread suspend/resume commands, I think it would be
nice to remove these as commands and instead make them textual links
in the status window. If the thread is running you can hit a
'suspend' link, and if the thread is suspended you can hit a
'resume' link. That alleviates the need for the user to track down
the proper command names and exposes only the relevant action based
on the thread's current status.
- Another issue to consider for the next iteration (not a requirement
for getting this initial version merged) would be how to re-load
existing breakpoints on subsequent edits of files. Eclipse actually
remembered my existing breakpoints in my test file across eclipse
restarts, so I had breakpoints, but they weren't marked in the file.
That's as far as I could get today. I'll continue looking at this as I
get time.
> Next, I will focus on writing unit test. I am thinking of an end to end kind of testing. Let me know if you have any suggestions.
> I looked at some of your examples. Here is my understanding.
> -----------------------------------------------------------------------------------------------------------
>
> 1. Add the vunit file called debug.vim under org.eclim.jdt/test/vunit/eclim/autoload/eclim/java
> 2. Add the Java classes that will be used in testing under eclim_unit_test_java/src/org/eclim/test/debug
>
> Code inside the vunit file will look like this ...
> - Start a java application in debug mode using files mentioned in 2.
>
> - Open TestDebugger.java. This is one of the files. Start user interaction ... add breakpoints, connect to remote VM, step through, etc.
> - At each point, verify the contents of the status window, code window, etc.
> -----------------------------------------------------------------------------------------------------------
That should work. Interacting with vim via vunit has it's quirks, but
hopefully the core debugging pieces can be tested.
> Questions
> 1. While creating splits, is it possible to specify a % instead of an absolute number?
Not that I know of. I think you'd have to calculate the resulting
value yourself.
> 2. There is one issue that I haven't been able to figure out. I included this in the troubleshooting section for now. Note that the step over does not have this issue. I think that's because its going to the same file. During a step operation, the following functions are called in this order:
> 1. eclim#java#debug#GoToFile
> 2. eclim#java#debug#Status
> * A split window is created when stepping into a function (JavaDebugStep into) from the debug status window. It is not clear why this is happening. To avoid this problem, run step into command outside the debug status window.
I haven't had time to look into this yet. During my testing I somehow
triggered a case (without using :JavaDebugStep) where the variable
split somehow jumped up above the debug status window and the source
file I was editing ended up with a duplicate split next to the
variable window.
> > > > To unsubscribe from this group and stop receiving emails from it, send an email to
eclim-dev+...@googlegroups.com.
> > > > To unsubscribe from this group and stop receiving emails from it, send an email to
eclim-dev+...@googlegroups.com.
> > > > To unsubscribe from this group and stop receiving emails from it, send an email to
eclim-dev+...@googlegroups.com.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to
eclim-dev+...@googlegroups.com.
> > > To unsubscribe from this group and stop receiving emails from it, send an email to
eclim-dev+...@googlegroups.com.
> > To unsubscribe from this group and stop receiving emails from it, send an email to
eclim-dev+...@googlegroups.com.
> > To unsubscribe from this group and stop receiving emails from it, send an email to
eclim-dev+...@googlegroups.com.
> To unsubscribe from this group and stop receiving emails from it, send an email to
eclim-dev+...@googlegroups.com.
> To unsubscribe from this group and stop receiving emails from it, send an email to
eclim-dev+...@googlegroups.com.