Help:Lua debugging: Difference between revisions

Revision as of 14:19, 2 November 2020

Revision as of 14:21, 2 November 2020

Line 1:

{{WikiProject Lua header}}

This help-page, '''Help:Lua debugging''', explains issues of writing [[Lua (programming language)|Lua script]] and [[debugging]] the [[source code]], to remove errors or improve performance. Because Lua is a "semi-compiled" interpreted language, it does not prescreen for all common syntax errors, nor detect misspelled variables, which are only found at runtime when seeing the "<span style="color:maroon">{{Script error</span>}}" message. Also, unlike [[wp:template]]s which can be run interactively by edit-preview, the Lua script must be tested by show-preview (or run preview) of another page which uses a template which <code>#invoke</code>'s the Lua module being edited. In general, make one small change at a time, do a run show-preview, and save after a few good changes to have a version to restore, in case terrible errors occur after numerous later changes. Note: the saving of a working copy can be done to an offline text file, rather than saving each version into the module revisions.

Other pre-compiled, or semi-compiled, languages can pinpoint the line number, or code phrase, where a syntax error, or undefined variable name, has been detected; however, that processing can require extra time to perform. Instead, it might be possible to use a [[lexical analysis]] tool, specifically for Lua script, to better detect and pinpoint misspelled variables or logic errors in Lua source code.

Line 68:

== Debugging older modules ==

In some situations, a Lua module might be an older effort, perhaps modified by various other editors along the way, with multiple unknown problems. A Lua module can contain numerous logic errors, and even misspelled variables, if the module was not properly tested, for all features, when initially developed. The message "<span style="color:maroon">{{Script error</span>}}" only occurs when the test data triggers an invalid section of Lua code, so an untested module could contain many hidden bugs, only revealed when broader test data activates more areas of the source code, or uses more internal functions.

A common, and complex, problem is to try expanding an older module, for newer features, but unaware how some prior, unsolved bugs will only be triggered when the expanded functionality is added. Note how the errors are, often, not in the newly added Lua script, but rather waiting silently in older sections to be triggered (surprise) when the new code activates other parts of the Lua script. A hidden bug can be as simple as an undefined (or misspelled) variable name, which had been processed with a default value, but when used with newly added features, generates completely mysterious results, as though the new code had errors, when actually, the older misspelled variables, in other areas, completely trashed the operation of the new features.