My issues with Decoda 1.13 so far

Maximilien

Hello,

I've just started playing with Decoda to debug some project of mine based on the LuaforWindows package, and making use of IUP.
I've got a few problems that I list here, hoping that there is a solution I've missed:

* Decoda won't parse or colorize files with .wlua extension. It only accepts files with .lua extension. I'd like to be able to tell Decoda which extensions should be recognized as Lua files.
* When watching a table that contains tables, like so:


<div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-space:pre;overflow:auto'>parent =
{
child1 = { subchild1 = {a = 1, b = 2}},
child2 = { subchild2 = {a = 1, b = 2}},
}</div>

I can expand child1 and child2, but subchild1 and subchild2 can't be expanded to see their contents. I can work around this by watching expression parent.child1, but this is what the name says: a workaround. How can I tell Decoda to increase the max table expand depth (even better, to remove this limit)?

* IUP binary modules contain embedded Lua files. The objects IUP gives me have metatables where methods are implemented in those files. Whenever stepping inside a function enters one of those files, Decoda opens a new document saying:
"The source code for this script is not available. To view script source code, the script file must be added to the current project, or the debugger must be attached when the client loads the file."
I don't care about those files. I just want the execution step to skip them until I reach a point in the files I added in the project. Instead, I must step blindly until I enter a file I know. How can I tell Decoda to ignore steps inside those files?
Also, each file loaded by IUP appears in the project's file list at root level as two temporary files (source and bytecode versions), along the files I added to the project. There are about 150 of those. My own 5 files are lost in this huge list. I know I can choose to hide them, but I'd rather have them added in a project's subfolder so that I can just ignore them even when they are visible.

* There is no "Locals" or "Upvalues" window to inspect locals, parameters and upvalues. It's either the tooltips or the watch to inspect their values. These would be a very nice addition do Decoda :-).
EDIT: Please don't forget some way of inspecting the contents of the vararg expression '...'.

* There is no "step-out" step mode to continue execution until I exit the current function. I can't even work around this by using a "Run to cursor" command to reach some return statement, since there is none either. Thus, if I step into a function with lots of statements to execute, such as a loop that processes a lot of data, my only option to get out is to manually set a breakpoint right after the call site, or to step manually until the loop terminates, hoping I don't overshoot when letting the keyboard autorepeat doing it for me. Those two step commands would be a very nice addition do Decoda :-).


Best regards,


Benoit.

Maximilien

Also:

* ProjectExplorer doesn't list functions in files when they are written as

<div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-space:pre;overflow:auto'>f = function()
...
end</div>

but only when declared as

<div class='codetop'>CODE</div><div class='codemain' style='height:200px;white-space:pre;overflow:auto'>function f()
...
end</div>

There is no reason for this, since the latter is only syntactic sugar for the former, which more accurately expresses what is going on (the instanciation of a closure with proto corresponding to the function's body, with a reference held in variable f).

* ProjectExplorer doesn't list functions defined inside other functions as children of their parent, but at the same level.

* When double-clicking a function in the ProjectExplorer to jump to its definition, causing the corresponding line to be selected in the source file would help seeing it.

* I am not a big fan, but maybe some would appreciate code folding à la SciTE.

* I would like to be able to select different syntax colors for single quote, double quote, and long strings.

* I would like to be able to select different syntax colors for integer and floating point constants.

* I would like the negative sign of negative constants to be colored as a number, not as the minus operator.

* I would like to to able to select different syntax colors for locals, parameters and upvalues.

* I would like to be able to select different syntax colors for line comments and block comments.

* I would like to be able to select different syntax colors for the 'self' and 'nil' keywords.

* I would like to be able to select a visible syntax color for whitespace characters 'space' and 'tab'.

* I would like syntax coloring items to have a 'Default' background color that reuses that of the 'Default' item.

* I would like the Output window not to apply the default background color.

Maximilien

Same player, shoot again :-)

I am the maintainer of Lanes, a multithreading solution. I am using Decoda to debug tests scripts I write while improving Lanes. The different Lua states created for each lane are properly shown in the Virtual Machines window. I can see two improvements there though:

* when triggering a breakpoint in one of the virtual machines, I would like to have the possibility to cause all virtual machines to be suspended at the same time so that I can inspect what they are doing. Of course, when all Virtual Machines are stopped, selecting one of them should update the callstack and watch windows accordingly. This is not currently the case, but I suspect this is because the other virtual machines are still running.

* Some means to restrict a breakpoint to be triggered only in a given Virtual Machine would be useful.

I also got bitten by a little bug that could have had far greater consequences: when saving a new project I just created, I first selected the visible file types to "All Files". I then clicked some test script file with extension .lua in the file selector panel, because my intention was to create a project with this name. I then validated the dialog without removing the extension from the file name. This caused my project config to overwrite the Lua file I just selected without any kind of confirmation instead of writing a file with extension .deproj. I was lucky it was a little side test script instead of one of my other main application files, because it was then irremediably lost...

Maximilien

Let's continue:

One of my project files contained character '²' in its name. After having added this file to the project, and saved the project, Decoda is unable to load it again.

Also, it would be nice if the display filter settings of the Project Explorer were saved somewhere.

I also notice that a call to dofile() appears in the Project Explorer window as a function definition. Is it intentional?
EDIT1: I've found out why. This is because of the preceding comment:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->-- run this file to register a global function
dofile( "some_file.lua")<!--c2--></div><!--ec2-->
The 'function' word inside the comment is understood as the beginning of a function declaration statement, following which we find the call to dofile.
EDIT2: My main issue with this is that each time I write a for loop, Decoda offers me to complete the 'do' reserved word with 'dofile'. All I ask is to be left alone when Decoda sees I've just typed a reserved word. If I have some function named forEachItemDo(), I don't want Decoda to propose it each time I want to write for i = 1, 10 do.

Last (for now) but not least: it's been almost a year since the last update. Is Decoda still maintained? I can't believe that not one single user has not felt the need for a single one of the improvements I listed after only a few days of use, especially at Unknown Worlds. I hope that this version isn't frozen just because Havok spawned Kore VM.

Edit: I obviously mistook NGT's Kore VM and Decoda when I said the their product spawned from Decoda. I must have been brain-addled at that time. But the comment stands: The community needs an affordable Lua IDE, Decoda is definitely a good choice, but please keep it alive and evolving.

Edit2: I wans't brain-addled after all. I recently found again Unknow World's statement about Kore offering full support for Xbox 360 and PS3 based on Decoda.


Regards,


Benoit.

Maximilien

Two more little things:

When replacing text in a source file, a popup is displayed with the message "Replaced X occurances."

* It should read "occurrences."
* I don't really care about the number of occurrences. I'd like to be able to tell Decoda to stop showing it everytime I replace text. (This is also true for the popup telling me "Find reached the start point of the search.")

Maximilien

One more:

I use setfenv to sandbox user-provided functions to execute in a controlled environment. The debug library isn't available in the lua interpreter I am using, so I can't inspect the function's environment to see if it is the expected one. Even getting access to an object's metatable isn't always possible, because some modules set their __metatable field so that getmetatable(o) returns this field instead of the actual metatable.

Therefore, general support for displaying an object's environment and metatable wherever applicable would be most welcome.

And while we are at it, let's consider showing the VM's registry and global environment a useful addition too.

Maximilien

Another bug:

Consider the following script

<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->local function statement(n)
  print( "statement" .. n)
end

statement(1)
local status, result = pcall( dofile, "some file that doesn't exist")
statement(2)<!--c2--></div><!--ec2-->

Set a breakpoint on the pcall() line and press F5 to start debugging.
Press F10 to execute the pcall() line.
Execution won't stop at the statement(2) line, but will continue until script termination.
If the file you try to execute existed, the execution would have stopped at the next statement (as it always should).

Maximilien

And another one:

Project Explorer view will list functions even if the <!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1--> funcname = function(...)<!--c2--></div><!--ec2-->
line is commented out, be it by a line or block comment.

Maximilien

Another problem I frequently have:

IUP objects are full userdata with lots of attributes. For example iup.text() function returns a full userdata. Indexing this userdata with the key "value", as in
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->local textControl = iup.text{}
local textString = textControl.value<!--c2--></div><!--ec2-->
triggers a C metamethod call that fetches the control's contents and returns them as a string.

More often than not, when the application is suspended on a breakpoint and I want to examine the expression textControl.value by hovering the mouse cursor to get a tooltip showing it, Decoda freezes and I must kill it with the task manager.

Maximilien

One more:

When typing the dot character ('.'), Decoda seems to propose a list of functions that were declared with the ':' syntax in one of the project's file, as in
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->local t = {}
function  t:foo()
  return 42
end<!--c2--></div><!--ec2-->

Now let's say that I type this dot inside a string. If I happen to type this at the end of what looks like a valid Lua identifier, Decoda still offers the method list popup, although I am typing text inside a string, and not writing a method call. This is more a nuisance thatn anything else.

While we are at it, Decoda could be smarter about the methods it proposes: methods declared with the ':' syntax, or methods whose first argument is named 'self', should only be proposed when coding a ':' call. On the opposite, regular methods declared with '.' syntax and whose first argument is not named 'self' should be proposed only when coding a '.' call.

Maximilien

And three more:

The first time I run Decoda after my PC has booted, Decoda interface won't show up. I see the process in the task manager, eating 0 CPU and about 10Mb of RAM. If I use said Task Manager to kill this process and run Decoda again it shows up instantly and all is fine. Now, it happens that I was typing this post while I had this hidden Decoda around, and it eventually appeared. Maybe this is a problem with CPU load? (I have an mprime client running in the background).

Also, Decoda detects externally modified source files. I happen to have utility Lua modules that I use in different applications that I debug simultaneously. When I fix something in one of the Decoda instances, the other detects the change and ask to reload the modified file. When I do so, the Decoda interface is broken and I have the top left quarter of the document which is no longer properly displayed because there is some text control in there that appeared and isn't refreshed. Maybe this is a bug in wxLua, who knows. It seems this happens when the file is modified while a debugging session is in progress.

I also once got a message about a malformed XML code. I suppose this is related to some value I had in the watch window. Maybe Decoda has to generate XML from the watched expression to feed it to this window, and the variable content was not handled properly. EDIT: This happens when I have a string that contains character '²'.

Maximilien

And another suggestion:

When performing "Find in Files", I miss "next" and "previous" key shortcuts to navigate the search results. Also, I think that these results should be displayed in a dedicated window, not the output window, and that there should be more than one of them, just like Visual Studio does. (As a matter of fact, I guess that this applies to a lot of what I've been reporting :-) ).

EDIT: Each time I perform a search, Decoda opens the "Find" popup at the same location, even if I moved it elsewhere during a previous search. This is also true for the "Find in Files" popup. And funnily enough, those don't appear at the same location: "Find" is somewhere below and right of the Decoda window's topleft corner, whereas "Find in Files" is screen-centered.
Anyway, it might be a good idea to convert both popups into dockable windows so that I can put them out of the way in my layout.

Maximilien

Another little thing:

When doing "Find in Files", Decoda performs its search on the disk, and doesn't search inside the loaded buffers. As a result, if there is a modified buffer where a line is changed so that it matched the search, but no longer does, Decoda shows a hit result where the displayed line is the original content, which obviously doesn't match what is found in the edited buffer. Worse, if I added/deleted some lines in Decoda without saving the buffer, a subsequent search has wrong line numbers and clicking a search result won't bring the editor to the proper location.

I think it would be better if Decoda searched preferably in the loaded buffers, and would search on disk only for unloaded files.

Maximilien

Other search-related problems:

"Find" dialog is localized according to my OS locale, but "Find in Files" is not, as well as the rest of the IDE. I'd rather have the Find dialog not localized either, so that the interface is consistent (the most bothering part about this are the localized keyboard shortcuts for case-sensitivity and entire word search options, which are locale-dependant).


Also, I miss keyboard shortcuts for the 3 boolean options in Find in Files dialog.


Let's consider this little bit of text:
<!--c1--><div class='codetop'>CODE</div><div class='codemain'><!--ec1-->"foo", -- 1
foo, -- 2
"Foo", -- 3
Foo, -- 4
"foo" -- 5
foo -- 6
"Foo" -- 7
Foo -- 8<!--c2--></div><!--ec2-->
Find foo, whatever the options, works as expected.
Find "foo", no entire word, case insensitive, will return hits 1 3 5 7 (ok)
Find "foo", no entire word, case sensitive, will return hits 1 5 (ok)
Find "foo", entire word, case insensitive, will return hits 5 7 (where are hits 1 and 3?)
Find "foo", entire word, case sensitive, will return hit 5 (where is hit 1?)
-> it looks like the comma is considered as part of the hit, causing some of the hits to be rejected because they are not considered as whole words.

I would also appreciate a "jump to matching brace" feature in the editor (aka Visual Studio's Ctrl-^). Ideally, it would work on curly braces, square braces, parentheses, string delimiters (regular and long string), block comment delimiters, and scope delimiter keywords (do, end, repeat, until, then, function). Of course, this would have to work properly even if commented-out unbalanced code is in the way :-).

Maximilien

Now some issues about breakpoints and step debugging:

I miss the following features:
Breakpoint disabling.
Setting a breakpoint that triggers only in a given VM.
Conditional breakpoints (expression, hit count)

There is also a bug with breakpoints when a file is externally modified: when I accept the file to be reloaded, if such a file contains breakpoints, all of them will disappear and will be replaced by a single breakpoint set at the last line of the file.

Did I already mention problems when stepping in multithreaded applications? I'll do so again, just in case :-). Lets say I have several concurrent independant VMs (not coroutines) and I stop on a breakpoint in one of the VMs.

If I don't step with F10 or F11, but resume execution with F5, all goes well.

However, if I step with F10/F11. step mode will be applied to all VMs from then on, which triggers several issues:

1. At each step, Decoda will bring me to whichever line at which any VM happens to trigger the debug line hook first, thus causing execution steps to jump from one VM to the other.
2. With some VMs stopped that way (but not necessarily all of them, since they are stopped in blocking functions, such as socket polling), selecting the stopped VMs in the list won't switch context appropriately, and I will only be able to inspect the context of the VM whose current statement Decoda last showed me.
3. After having stepped execution at least once in these different VMs), if I resume execution, my application no longer functions correctly. It looks like only the VM where I was last stopped leaves step mode, but the other VMs are still in step mode and are therefore frozen, while Decoda believes that no VMs is still in step mode.
4. Just to be sure to repeat myself: frequently, when inspecting expressions through select-and-tooltip, Decoda and my application will get frozen in some deadlock. If I use the Windows Task Manager to kill my application, Decoda will unfreeze and leave debug mode as if nothing happened.

One last thing: When step-debugging in a file, the current statement is marked with a yellow arrow in the left column of the edited file. If I interrupt the execution with Shift+F5, the arrow is not removed and will stay there until I step on this statement in a subsequent debug session.

Maximilien

One more thing:

I have moved a project on my disk from a location to another.
Because of this, the MRU entry for this project is no longer valid, and causes an error when I select it. I wish again for a Visual-Studio-like behavior: when project loading fails, Decoda should remove it from the MRU, maybe after asking confirmation. Also, an MRU max length limit would be welcome in the user settings.

Maximilien

Another thing I noticed about Fonts and Colors settings:

If I create a custom color in the Windows color chooser panel and add it to the list of personalized colors, Decoda won't remember it: the next time I open the color chooser, all the personalized color slots are empty.

Did I mention that for display items other than Default, 'Default' setting that uses that of the Default item would be useful?

Also, I happen to use a setting with a dark background (RGB 45, 45, 0), because it is easier for the eyes. Unfortunately, this makes the black cursor somewhat hard to see, bordering on invisible. Negating the default background color to generate the cursor color would improve visibility. Even better, highlighting the current edited line by surrounding it with a box (with either dotted or full line style) would be great, since a cursor is quite small on a recent full HD display.

There seems to be an issue with the line number display as well. When I first launch Decoda, these are displayed black against the light gray background. Now let's say that I change the Default item's foreground color, validating each time to see the results in the main editor window. This will cause the line numbers display to use the color that I replaced. For example, let's say that I launch Decoda, I start with:
Line numbers: black / Default item foreground: yellow
then I change Default item foreground to red, I'll have then
Line numbers: yellow / Default item foreground: red
etc.

Maximilien

Another little detail with 'Find in Files" results:

I'd like the tabulation width to respect the settings I am using in the main edition windows.
And I'd appreciate an option to remove leading whitespaces altogether from the hits to make them more readable.

Did I already mention that 'prev' and 'next' keyboard shortcuts to easily navigate the hits instead of having to click them would be a real boon? And of course, having the current result line highlighted both in the results window and the editor window.