Help:Lua debugging: Difference between revisions

Revision as of 07:50, 8 March 2013

Latest revision as of 15:03, 16 June 2024

(39 intermediate revisions by 23 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 "<font color=maroon>{{Script error</font>}}" 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 8:

== Causes of Script error ==

There can be many reasons why a Lua module triggers the message "<font color=maroon>'''{{Script error'''</font>}}" when run in another page. Clicking the error text displays a popup that includes the actual error message generated by Lua, which can be used in a search engine to find a thorough description of what the message means and common remedies, as well as a stack trace to help determine the part of the code that actually triggered the error.

However, some errors are more common than others:

Line 16:

:* '''Invalid function name:''' &nbsp; <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 "<font color=maroon>{{Script error</font>}}" but always look for the potential to have an unset, uninitialized variable which might stop the program at that point.

== 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&nbsp;&nbsp;&nbsp;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 "<font color=maroon>{{Script error</font>}}" 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.

Line 28 ⟶ 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.

== LuaUsing personal sandbox for script development ==

The English wikipediaWikipedia has the [[mw:Extension:TemplateSandbox|Template Sandbox]] extension installed. There is a Synergysynergy between the "template sandbox" and "ScribuntuScribunto" extensions, which allows to developdeveloping and modifymodifying Lua modules in private (i.e., in the user space) pages, before moving them to the global space.

=== How to useUsing "Template Sandbox" to develop scribuntuLua module?modules ===

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 milionsmillions of articles. Any bug will present a huge disruption to Wikipedia. The 2nd reason is more prosaic: because this module is so central, it is also protected, and our "Lua Developer" user does not have the required permissions to modify this module.

So, the first step in "sandboxing" is to copy [[Module:String]] to the private page [[User:Lua Developer/sandbox/Module:String]]. Now our developer can edit the module to her heart's content. At any given moment, she can open [[Special:TemplateSandbox]], using the default "Sandbox prefix", which in her case, will be "User:Lua Developer/sandbox". This means that viewing any page from the sandbox page, whenever the parser encounters a Template '''T''' or Module '''M''', it will look first to see if a page named "User:Lua Developer/sandbox/Template:T" or "User:Lua Developer/sandbox/Module/:M" exists, and if so, the parser will use those for the parsed page, instead of the ones in the "real" Module and Template namespaces. Any template or module which do not exist under the "Sandbox prefix", will be pulled by the parser from the appropriate namespace.

From the Template sandbox, the developer can view any page, and can also enter raw wikitext, and ask the parser to parse it using the faux templates and modules she created under the "Sandbox prefix"

=== Small caveat: The case of the wrong case ===

Wikipedia has a small perversion regarding page name casing: it will convert the first character of a page name to uppercase, regardless of the way it was entered. To compensate, it also converts the first letter of a template (when transcluded) and module (when invoked) to uppercase. however, this does not extend to the modules stored in User: namespace viewed through the special [[Template sandbox]], because in the sandbox "the first letter" is not the first letter any more. Here is an actual example: for real modules, let's say [[Module:String]], mediawiki software will allow you to use <nowiki>{{#invoke:mlx|String|replace|Hara I am|a|e}}</nowiki> to return "Here I em" (try it). It will also allow you to use <nowiki>{{#invoke:mlx|string|replace|Hara I am|a|e}}</nowiki> to get the same result:

{|class="wikitable"

|-

! wikitext !! result

|-

|<nowiki>{{#invoke:mlx|String | replace | Hara I am |a|e}}</nowiki>||{{#invoke:String | replace | Hara I am |a|e}}

|-

|<nowiki>{{#invoke:mlx|string | replace | Hara I am |a|e}}</nowiki>||{{#invoke:string | replace | Hara I am |a|e}}

|}

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 ==

Line 59 ⟶ 108:

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 64 ⟶ 128:

== See also ==

* [[Wikipedia:Lua]]

* [[wp:Lua in Wikipedia]] - essay about using [[Lua script]] in Wikipedia

* [[Template:HelpWikipedia navigationhelp pages]] - large navbox linking to other topics

{{Wikipedia technical help|collapsed}}

[[Category:Wikipedia how-to]]

[[Category:Wikipedia text help]]

[[Category:Module help|Debugging]]