OMEdit MetaModelica debugger suggestions

[perost]

Since Martin fixed the compilation of OMEdit I tried to use it instead of MDT for debugging, and while it seems to work pretty well after I finally figured out how it works there are some minor issues with it. Rather than creating individual tickets for every little issue I'll just collect them here:

1. If you specify an invalid program in a debug configuration, like using the wrong path for OMC, you don't get any error. It just looks like it's running without doing anything, and I didn't figure it out until I looked at the Debugger CLI.
2. When stopping at a break point, a window pops up after a while (I'm guessing after 40 seconds) saying that GDB hasn't responded for 40 seconds. GDB seems to be working fine though, and choosing the option to give GDB more time allows you to continue.
3. When the debugger steps into a file that's not yet open in a tab, OMEdit will open the file but will not go to the actual line. Double-clicking on the topmost stack frame will make OMEdit go to the line though.
4. Clicking on a stack frame seems to do nothing except highlight it, while double-clicking will go to that frame. I think it should be enough to single-click on a stack frame to go to it, since that's most likely what the user wants anyway.
5. The only way I've found so far to run a debug configuration is to go into Debug->Debug Configurations, select the configuration, and press Save & Debug. This can get a bit annoying. One option would be to have a submenu under Debug that lists all configurations, or maybe only some of the configurations ordered by last use time. Another option would be to have a button with a dropdown menu like Eclipse does it. Some way of easily starting the last used configuration would also be nice.
6. The variables browser lists name, type and value. I usually don't care about the type, since that can be inferred from the value most of the time anyway. So it would be nice to be able to configure which columns are shown. You can resize any column you want until it's really small though, so this is a very minor issue.
7. The opened folders and the breakpoints are not saved when you quit OMEdit.
8. Right-clicking on an empty spot in the library browser doesn't do anything. I was expecting it to open a context menu where you can choose to add things, like folders for debugging, instead of having to go the File menu.
9. After some further use I realised that this is not quite true, since strings are shown unquoted in the variable browser. I think it would be better to quote strings, because currently you can't differentiate between e.g. the string "1" and the number 1 without taking the extra step to look at the variable's type.
10. Another small issue: the variables in the variables browser are sorted alphabetically. That's fine for the local variables, but a bit annoying when record members are also sorted that way. As a developer I know many of the data structures in the compiler by heart, so I find it confusing when the order in OMEdit doesn't match the declared order I expect.
11. OMEdit doesn't mark the line the debugger is on in any way, except for highlighting it. But if you click on another line it will highlight that line instead, and you won't know which line is active except if you double-click on the current frame in the stack browser to select the active line again. I would suggest that either the active line should be highlighted with another color than the currently selected line, or to have some symbol in the margin that indicates the active line.
12. The program, work directory and GDB path will often be the same for several debug configurations, so some way of cloning debug configurations would be nice.

[perost]

Replying to perost:

• The variables browser lists name, type and value. I usually don't care about the type, since that can be inferred from the value most of the time anyway.

9. After some further use I realised that this is not quite true, since strings are shown unquoted in the variable browser. I think it would be better to quote strings, because currently you can't differentiate between e.g. the string "1" and the number 1 without taking the extra step to look at the variable's type.

[perost]

10. Another small issue: the variables in the variables browser are sorted alphabetically. That's fine for the local variables, but a bit annoying when record members are also sorted that way. As a developer I know many of the data structures in the compiler by heart, so I find it confusing when the order in OMEdit doesn't match the declared order I expect.

[perost]

11. OMEdit doesn't mark the line the debugger is on in any way, except for highlighting it. But if you click on another line it will highlight that line instead, and you won't know which line is active except if you double-click on the current frame in the stack browser to select the active line again. I would suggest that either the active line should be highlighted with another color than the currently selected line, or to have some symbol in the margin that indicates the active line.

[perost]

12. The program, work directory and GDB path will often be the same for several debug configurations, so some way of cloning debug configurations would be nice.

[adeas31]

Point 1 45442e0/OMEdit and 3 b906ae8/OMEdit are fixed now.

[adeas31]

Point 4 is fixed in e4d06b9/OMEdit.

[adeas31]

Replying to perost:

Replying to perost:

• The variables browser lists name, type and value. I usually don't care about the type, since that can be inferred from the value most of the time anyway.

9. After some further use I realised that this is not quite true, since strings are shown unquoted in the variable browser. I think it would be better to quote strings, because currently you can't differentiate between e.g. the string "1" and the number 1 without taking the extra step to look at the variable's type.

Fixed in 2349aed/OMEdit.
I believe you already know that you can change the order of columns. So if you click and drag the type column to the right then you will see name, value and type instead of name, type and value. The good thing is OMEdit remembers your preference for the later sessions.

[adeas31]

I can't reproduce point 2. Perhaps you have some test case for it?

In general the message is shown when one of the gdb command has not returned a value after few secs (you can set a different timeout in the settings Tools->Options->Debugger->GDB Command Timeout).
There is flag called NonCriticalResponse in the code. Only the commands that have this flag set are ignored (we don't care if we get the result back or not). Almost all commands in the debugger are without this flag.

One idea would be that when the timeout is hit we show the message to the user along with the command which is not completed yet and then user have options,

1. Give GDB more time
2. Ignore this command
3. Stop debugging

This gives more control to the user. The user can decide after seeing the command whether it is important to wait for an answer or ignore the command or stop debugging.

[adeas31]

Point 10 is fixed in 84f0aab/OMEdit.