Content deleted Content added
new key for Category:Module help: "Debugging" using HotCat |
|||
| (47 intermediate revisions by 26 users not shown) | |||
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 "
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 7 ⟶ 8:
== Causes of Script error ==
There can be many reasons why a Lua module triggers the message "
However, some errors are more common than others:
:* '''Invalid concatenation of empty string:''' <code>my_str = my_str .. "xx"</code> - The string named 'my_str' must not be nil when used inside a string concatenation operation.
Line 13 ⟶ 16:
:* '''Invalid function name:''' <code>len = string.long(my_str)</code> - The string-length operator is hash mark '#' (as in: <code>#my_str</code>), or use function '<code>string.len(my_str)</code>' but trying to use unknown function '<code>string.long(my_str)</code>' will successfully pass during the pre-compile of edit-save, yet it will hit "Script error" when that portion of the Lua script is executed.
There are many other causes of "
== Saving fall-back stable versions ==
To avoid facing too many errors at once, the general strategy is to make "one small change" at a time, do a run show-preview, and then save that tested version after a few good changes to have a stable version to restore, in case terrible errors occur after numerous later changes. Note: the saving of each working copy can be done to a set of offline text files, perhaps each with a specific version name (and internal comments), rather than saving each version into the Wikipedia module revisions.
== How to debug==
===Simple review===
To see the value of a variable in a single point of the module:
====To see the value of a variable by modifying the code====
The <code>error()</code> function can be used to show the value of a variable at any point in the module. So to know the value of a variable <code>var</code> at a certain point in the code, add the line <code>error(var)</code> at that point.
In the case that the variable is a table (let's call the variable <code>tab</code>), <code>mw.dumpObject(tab)</code> can be used to show the table. If the variable does not have nested tables, <code>table.concat(tab, ',')</code> can also be used as parameter in the <code>error()</code> function, i.e. <code>error(table.concat(tab, ','))</code>.
==== To see the value of a variable without changing the code ====
To obtain variables and values returned from functions (not local in both cases) the "Debug console" can be used. The "Debug console" appears below in the module page (when it is in edit mode). Then <code>mw.log</code>, <code>mw.logObject</code>, and <code>=</code> can be used. Let's see its usefulness in the next example:
{{#tag:syntaxhighlight|
{{Module:Example of lua debugging}}
|lang=lua}}
Requests to "Debug Console":
{| class="wikitable"
|-
! Request !! Returned value
|-
| {{code|2=lua|mw.log(p.Hello)}}|| {{samp|"Hello"}}
|-
| {{code|2=lua|mw.log(p.calc(10/2))}} || {{samp|5}}
|-
| {{code|2=lua|mw.log(p.sum_mult(3))}} || {{samp|6 9}}
|-
| {{code|2=lua|mw.log(p.mtable(4))}} || {{samp|table}}
|-
| {{code|2=lua|mw.logObject(p.mtable(4))}} || {{sxhl|2=lua|
table#1 {
:4,
:5,
}
}}
|-
| {{code|2=lua|{{=}}p.sum_mult(10)}} || {{samp|20 100}}
|-
| {{code|2=lua|{{=}}p.Hello .. ', World!'}} || {{samp|Hello, World!}}
|}
{{edit|Module:Example of lua debugging|Try it out in Module:Example of lua debugging}}. The Debug console does not store the requests, then they will have to be copied or rewritten again in each module modification.
===Review of the flow and the variable values in several points===
The functions of the [[Module:SimpleDebug]] can be used for cases such as those mentioned above or for more complex cases:
* When variables or the returned value (or values) by a function are local.
* To see if the flow of the program goes through a point (to which you will label).
* To limit the number of values returned from a loop or set conditions to enable the registration of values.
== 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 "
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.
Line 25 ⟶ 75:
A tactic, for dealing with older bugs, is to plan to run special extra test data to activate code areas, or show debug-display output, where new Lua script might be added, to provide a [[sanity check]] that the affected areas are functioning soundly, before adding too much new, detailed logic. In most cases, note: "''proofreading is the fastest form of testing"'' if having the patience, or mental memory power, to review the details of older source code. However, another tactic is to reserve specific test-data values to trigger debug-display code which dumps the values of all related data to the screen, or provides a call-tree list to ensure the logic flows into various function sections as expected. In many cases, human memory cannot cope with details beyond 5-9 variables, and so debug-display becomes an easier option, despite the extra time needed to write the debug-print statements into the Lua module. Be careful to proceed slowly, because once extensive amounts of new Lua script are added, then it can become a puzzling guessing game whether the problems were caused by "all the new stuff" rather than by pre-existing bugs in the older Lua script.
==
The English
===
Let's take a practical example. for this example, assume your user name is "Lua Developer". Let's say you want to test a bug-fix or enhancement to the [[Module:String|String]] module. There are two reasons you can't do it directly: this module contains functions that are used by hundreds of templates, transcluded in
So, the first
From the Template sandbox, the developer can view any page, and
=== Small caveat: The case of the wrong case ===
Wikipedia has a small perversion regarding
{|class="wikitable"
|-
! wikitext !! result
|-
|
|-
|
|}
However, if our developer would create a page named [[User:Lua Developer/sandbox/Module:string]], she would not be able to invoke this module in any way, because the parser will look for a page named "Module:String" and not "Module:string" under the sandbox prefix, Wikipedia will not convert the name to "Module:String" (because it only converts the 1st character in the page name), and will not find it, so it will take the module from the main namespace (if such module exists), or will complain that the module does not exist.
Upper/lower case is correctly handled for all modules in normal use, which are housed in the Module: namespace.
== Plan for extensive debug-display code ==
As another issue of strategy, adding debug-display sections does not slow Lua code as it might the speed of markup-based template execution, because Lua can process hundreds of if-conditions at rapid speed. Even the addition of an extra if-statement for every Lua variable has little drag on speed, compared to slowing a template by perhaps 50% if adding similar if-expressions inside a markup template. Feel free to have many sections of debug-display added into a Lua module, or add several [[parameter validation]] tests as extra if-statements to check the values of variables to detect typical bad data.
== Occasional timeout errors ==
The Lua software was initially configured with a small, 10-second timeout limit, for the combined operation of all Lua code when formatting a page. By comparison, the markup-based templates have a 60-second timeout (6x higher time limit), and when the servers are slow, the markup-based templates could format perfectly, up through 59 seconds, but the Lua portions of templates will be stopped at the 10-second limit. The error message might be:
:: Lua 'script error': "The time allocated for running scripts has expired."
Unlike markup-based templates, the formatted page will contain "script error" for each further invoked Lua module, as text to store in the page-cache copy. The danger of the timeout limit occurs during the rare periods of 3x-4x slower server delay, where a 3-second Lua operation might slow to 12-second duration with busy servers, and thus garble the processing to store "script error" into the formatted page, for thousands of readers to view.
The overall effort appears unstable, or unreliable, as if Lua suddenly "gets too tired" and starts complaining by storing "Script error" into the resultant page, where formatted text would have been expected instead. The timeout problem is somewhat rare, and when a formatted article contains "Script error" text inside the page, then perhaps edit the page slightly, to make a small change, to force the replacement of the page with a clean Lua run.
== Exasperating bugs ==
{{Main|Help:Lua for beginners#Exasperating bugs}}
== Off-wiki tools ==
=== IDE ===
Running your code through an IDE is helpful for its text highlighting features, which can help you quickly spot syntax errors. Any IDE with the ability to install a Lua text highlighting plugin should work. This could be as simple as [[Notepad++]] (with Lua selected from the language menu) or as full-featured as [[Visual Studio Code]].
=== Step debugger ===
Step debugging is a powerful tool that allows you to step through code one line at a time, and hover over variables to see their contents at the time of execution. IDEs that easily support Lua step debugging include [[ZeroBrane Studio]], and [[IntelliJ IDEA]] with various debugger plugins ([https://plugins.jetbrains.com/plugin/9768-emmylua Emmy Lua] or [https://github.com/Benjamin-Dobell/IntelliJ-Luanalysis Lunalysis]).
=== RegEx ===
{{See also|mw:Extension:Scribunto/Lua reference manual#Patterns}}
Lua uses a unique flavor of [[Regular expression|regular expressions]] that is not supported by top RegEx tools. One tool that can be used for checking Lua RegEx is [https://gitspartv.github.io/lua-patterns/ GitSparTV's Lua Patterns].
== Support ==
Line 54 ⟶ 128:
== See also ==
* [[Wikipedia:Lua]]
* [[Template:
{{Wikipedia technical help|collapsed}}
[[Category:Wikipedia how-to]]
[[Category:Wikipedia text help]]
[[Category:Module help|Debugging]]
| |||