ct6502 / vscode-idl

VS Code Extension for IDL (Interactive Data Language)
Other
16 stars 6 forks source link

Add debugging #6

Open znorman-harris opened 4 years ago

znorman-harris commented 4 years ago

Placeholder to add debugging into the extension.

znorman-harris commented 4 years ago

@astrowq Here is a beta of debugging if you want to try it out! It is in a pretty good state and I have done some basic testing on Windows, Mac, and Linux. You might find some oddities, but feel free to give it a whirl and let me know if you have any issues.

It should auto-detect the location of IDL and will alert you to configure it if it can't find it. There is a command to set this preference, which can be accessed through the preferences UI.

If you download the .vsix file from the link below, you can install it through the extensions tab by clicking on the ellipsis (the three dots) and picking Install from VSIX.... Make sure to uninstall the previous version first.

https://github.com/chris-torrence/vscode-idl/releases/tag/v2.0.0-rc6


Edit: Update the link to the latest beta.

astrowq commented 4 years ago

Happy new year! Thanks for the efforts that you put into the requested feature and other nice features. I have tried the new version and am glad to see the debug is working now. Following are some feedbacks:

  1. When I start the debug session from the opened file, the working directory of IDL is always the home directory instead of the directory where the file is in. It would be better to set the working directory to file's.
  2. During the debug session, whenever I evaluate an expression in the debug console, there is always a notification pop up saying "Error getting scope information form IDL output". Screenshot_20200101_182128
  3. Sometimes there is no response after inputting expressions in the debug console e.g. Screenshot_20200101_182905-1 Basically, it becomes malfunctional and one has to restart the session.
  4. Yes, there exist many oddities, some I don't know how to describe properly, e.g. breakpoints have sorta memory of the previous ones after I removed them. The overall debugging experience is okay but not so smooth. Often I have to restart the session and get into my code's directory first.
  5. I miss the Compile and Run buttons (and shortcuts with key bindings) in the previous version which work in the terminal. In this new version, they only work in the debug session.
  6. I like the new Novus IDL theme especially the bold keywords, but I do enjoy my current Solarized dark theme. I had a look of the source code but got no clue how to customize the colours for idl code without replacing the current colour theme. Any suggestions on this?

By the way, I barely use the GUI workbench and kept using emacs before switching to vscode. My workflow heavily depends on the remote ssh extension to connect to the server. So maybe some issues I got have something to do the remote and local environments. (5) is the issue I wish to solve as soon as possible. Thanks a lot!

znorman-harris commented 4 years ago

Thanks for trying it out! Apologies for the annoying message, I missed including a file into the package which I just fixed and made a new pre-release which also has support for the profiler. You can find the updated file here, which should hopefully work better for you.

https://github.com/chris-torrence/vscode-idl/releases/tag/v2.0.0-rc3

Here are some notes about your comments (same numbering):

  1. Is the working directory where the files live the same as the vscode workspace folder? I could see adding a preference for changing the working directory to the workspace folder directory and having the option, if you have a PRO file open, to start in the same folder.

  2. Should be fixed with the latest release. Let me know if it isn't

  3. This should hopefully work better now. I was seeing this before and I caught a few cases that were missed.

  4. Breakpoints are kind of goofy - especially if they are added to a main level program. If they are added to main level, you need to recompile the file that they are in. Have to do a bit of digging to see what the workbench does to get around this.

  5. That is an interesting comment about the terminal vs the debug console which is the VSCode standard. Is that why it helps you more to have the commands spit out into the terminal instead of the debug console? I could certainly add a configuration option which will use the terminal instead of the debug console considering. The only catch here, and the main reason I stepped away from the terminal, is that debugging wont be supported because vscode does not have an official feature to capture the output from terminals. I posed a couple of questions and, the feature I need is in vscode insiders, but there is no plan for it to become a stable feature and in vscode.

  6. This is pretty easy to do! In the theme file that is included with IDL you will take this code and add it to the tokenColors of the theme you are trying to edit. I'm not sure where the default vscode themes are at, but I'm sure some quick googling will find them.

astrowq commented 4 years ago

Thanks for the reply!

  1. I put the workspace file in the home directory. It includes several folders related to my work. My habit is to have a directory tree, and my idl code lives somewhere in this tree. I always go to the code's folder first and then start the session.

I did this even before using vscode. Because I rarely use the workbench. There is no auto-completion in IDL's console. So if not doing this, there would be a huge pain to input file's relative path to my current work directory.

The current released version helps me a lot in terms of eliminating the need to input, such as ".r file_name.pro" every time. With the key binding, I don't even need to touch the mouse. So it's a huge time saver.

The bottom line is I would love to see options of changing the behaviour of where the working directory is located, when starting the debug session or terminal session.

2&3. Unfortunately, the problems still exist. Error messages seem to display only in the main program level, not inside the procedure. 2&3 seem to be related somehow.

  1. I had a look at the IDL workbench. There the IDL console is both the debug console and normal idl session. I also studied the debugger by Python extension. I feel like the difference between these three is that IDL workbench's console is always open, the same as I open an IDL session in the vscode terminal, and use shortcut commands provided by the extension, but in lack of debugging functionalities for the reasons you mentioned. If I just wanna run some idl code, I can quickly compile it and get it run, in both workbench and vscode terminal.

This pre-released version, apart from not being fully functional in debugging, has a disadvantage compared with python extension, which is the start-up time is way too longer than python. I am using idl8.7.2. Older version like idl8.0 indeed starts up quickly, but there are only newer versions on our server (>8.5). They are slow to get started (a few secs). So if I want to just run a pro file, I would prefer to run it in the terminal where there's already a session open, instead of waiting for the debug session opening up. The current version has done this job nicely. I would like to see this way of running code could be kept.

In summary, for quickly running the code, the current version is pretty good. Maybe resolving (1) could make even better i.e. open an IDL terminal session whose working directory is the opened file's.

For debugging, a separate set of commands and doing all the stuff in the debug console seem to be the only solution at the moment.

For me, I don't spend 90% of my time in debugging but mostly analysing data and making plots, at which IDL is good. So I like the current stable version.

znorman-harris commented 4 years ago

Thanks for giving more feedback! I appreciate you taking the time to respond and give input into the extension development.

I went ahead and added back in the terminal functionality that was there. I did some basic testing on Windows and Mac so it should be good on Linux as well. There are two sets of commands now: one for debugging and one for the terminal so that your use case will be covered. I'll work on the preference/ability to set the working directory next (workaround below)! You can grab the latest version here:

https://github.com/chris-torrence/vscode-idl/releases/tag/v2.0.0-rc5

It might be worthwhile to do a clean install of the extension and remove/verify all of your older idl extensions are gone which could be part of the problem. For this, you'll need to go into the extensions folder. Any of the folders that start with ct6502 can be deleted and you'll want to restart VSCode after. The extension folder can be found here on your machine:

https://code.visualstudio.com/docs/editor/extension-gallery#_where-are-extensions-installed

A couple of notes and comments:

vkantchev commented 4 years ago

Looks like this feature was implemented, released and then removed. Any plans to make this available again?

vkantchev commented 3 years ago

Any plans to add debugging back?

znorman-harris commented 11 months ago

FYI if you didn't notice, we have a new version of the extension that has basic support for running IDL within VSCode:

https://marketplace.visualstudio.com/items?itemName=IDL.idl-for-vscode