A gui-driven tcl program trace comprehension method and system

Abstract

The application relates to a GUI-driven TCL program tracking and understanding method and system, and belongs to the technical field of TCL program tracking and program understanding, and solves the problem that the prior art cannot realize tracking and understanding of a GUI-driven TCL program. The method comprises the following steps: acquiring all functions and function declarations in TCL program source code; judging whether the functions are bound with a graphical interface component and an event associated with the graphical interface component, if yes, the functions are event handling functions triggered by the event associated with the graphical interface component; otherwise, the functions are non-event handling functions; positioning a plug-in position based on the function declaration, inserting event information collection code at the plug-in position of the event handling functions, and inserting non-event information collection code at the plug-in position of the non-event handling functions; running the TCL program, collecting log files collected by the event information collection code and the non-event information collection code, and obtaining tracking and understanding results of the TCL program based on the collected log files.

Description

Technical Field

[0001] This invention relates to the field of TCL program tracing and understanding technology, and in particular to a GUI-driven TCL program tracing and understanding method. Background Technology

[0002] As software systems become increasingly complex, understanding their runtime behavior has become an effective means of understanding these systems. Many practitioners frequently use automated tracing techniques to collect and analyze this runtime behavior. There are two basic methods for collecting runtime information: sampling and tracing.

[0003] The sampling analyzer periodically monitors (typically every millisecond) the program stack, recording the executed functions and providing statistical information on function execution time and order. Currently, there are many sampling analyzers available, such as gdb hacks for languages ​​like C, C++, and Go, pyflame for Python, and ruby-prof for Ruby. The TCL program of interest in this invention can also use the TCL interpreter to generate sampling-based analysis reports. However, the information collected through sampling may be incomplete.

[0004] A trace analyzer monitors the function call stack, recording every function call made by the program. It is typically integrated into the IDEs of most programming languages, such as cProfile. The TCL interpreter (responsible for executing TCL code), which this invention focuses on, also has a built-in command—the `info` command—for viewing the function call stack. This command can be used to obtain the TCL interpreter's state information, including the function stack. However, using the `info` command once only retrieves the state information at a specific moment and cannot record continuous state changes. Therefore, for the purpose of monitoring the TCL function stack, there is currently no widely used and publicly available command.

[0005] Developers also employ program instrumentation, developing tracing analyzers tailored to their specific needs. Based on the timing of the instrumentation action, it can be categorized into target code instrumentation and source code instrumentation. Target code instrumentation includes techniques like AspectJ, ASM, and JavaSISST for Java bytecode, and Pin techniques for C and C++ executables. However, due to the limited popularity of the TCL language, a lack of supporting testing tools and technical documentation, and the fact that scripting languages ​​are more flexible than compiled languages, developing general-purpose tools has limited practical value. Therefore, existing technologies lack instrumentation techniques specifically for TCL programs.

[0006] Furthermore, since previous technologies were not designed for GUI software, neither sampling nor tracing methods distinguished between event-handling functions and non-event-handling functions when recording execution information. Considering that event-handling functions are called by triggering components on the GUI interface, while non-event-handling functions are called by other functions (event-handling or non-event-handling functions), the functions of event-handling functions are more specific, intuitive, and easy to understand (the function of event-handling functions can be understood through the GUI). In contrast, the functions of non-event-handling functions are not easy to understand and require reading the code, sorting out the call relationships (which event-handling functions directly or indirectly call them), and understanding the parameter information to understand the functions of non-event-handling functions. Therefore, in order to further understand the runtime information collected from GUI software, it is necessary to distinguish the types of recorded functions.

[0007] In summary, due to the unique characteristics of GUI software, existing methods for collecting runtime information are not suitable for GUI-driven TCL program tracing and understanding. Therefore, there is an urgent need for a GUI-driven TCL program tracing and understanding method specifically designed for analyzing and understanding runtime information. Summary of the Invention

[0008] Based on the above analysis, the embodiments of the present invention aim to provide a GUI-driven TCL program tracing and understanding method and system to solve the problem that the prior art cannot achieve tracing and understanding of GUI-driven TCL programs.

[0009] On one hand, this invention discloses a GUI-driven TCL program tracing and understanding method, including:

[0010] Retrieve all functions and their declarations from the TCL program source code;

[0011] Determine whether the function is bound to a graphical interface component and an event associated with the graphical interface component. If so, the function is an event handling function triggered by the event associated with the graphical interface component; otherwise, the function is a non-event handling function.

[0012] Based on the function declaration, the instrumentation position is located, and event information collection code is inserted at the instrumentation position of the event handling function, while non-event information collection code is inserted at the instrumentation position of the non-event handling function.

[0013] Run the TCL program to collect log files gathered by the event information collection code and the non-event information collection code, and obtain the tracking and understanding results of the TCL program based on the collected log files.

[0014] Based on the above solution, the present invention also makes the following improvements:

[0015] Furthermore, the event information collection code includes:

[0016] Global variable $Number;

[0017] The temporary variable $Arguments is used to assign the top-of-the-heap information of the command collection function call to $Arguments; the top-of-the-heap information includes the top-of-the-heap function name and the parameter values ​​of each parameter in the parameter list passed in at runtime;

[0018] The incrementing principle of $Number: $Number is incremented by 1 each time the event information collection code is executed;

[0019] The Print command is used to output the numbers in $Number, the word "isEvent", and the function names and parameter values ​​in the runtime parameter list to a log file.

[0020] Furthermore, the non-event information collection code includes:

[0021] Global variable $Number;

[0022] The temporary variable $Arguments is used to assign the top-of-the-heap information of the command collection function call to $Arguments; the top-of-the-heap information includes the top-of-the-heap function name and the parameter values ​​of each parameter in the parameter list passed in at runtime;

[0023] $Depth is used to measure the depth of function call stacks.

[0024] The incrementing principle of $Number: $Number is incremented by 1 each time the event information collection code is executed;

[0025] The Print command is used to output the numbers in $Number, $Depth, and the function names and runtime parameters passed in from Arguments to a log file.

[0026] Furthermore, the instrumentation position is located based on the function declaration:

[0027] The starting position of the function body in the function declaration is determined as the instrumentation position.

[0028] Furthermore, log files collected by the event information collection code and the non-event information collection code are included, including:

[0029] Collect function log records gathered by the event information collection code, including: execution sequence number, event handling function flag, function name, and parameter list;

[0030] The function log records collected by the non-event information collection code include: execution order number, function call stack depth, function name, and parameter list;

[0031] Specifically, the function log record is determined based on the Print command:

[0032] The number in $Number is the execution sequence number in the function log record;

[0033] The word "isEvent" is used to identify the event handling function flag in the function log record; if the function log record contains the event handling function flag, then the function call stack depth corresponding to the current function log record is 1;

[0034] The function names in the Arguments are the function names recorded in the function log.

[0035] The parameter values ​​of each parameter in the parameter list passed in at runtime are used to determine the parameter values ​​of each parameter in the parameter list in the function log record;

[0036] The $Depth is used to determine the function call stack depth in the function log record.

[0037] Furthermore, based on the collected log files, the tracing and understanding results of the TCL program are obtained, including:

[0038] In the log file, the execution order of all functions is sorted based on the execution order number in the function log record;

[0039] After sorting, the relationship between two adjacent functions is determined based on the function call stack depth in the function log records:

[0040] If two adjacent function logs record function call stack depths of n and n+1 respectively, then they are in a calling relationship: the function with function call stack depth n calls the function with function call stack depth n+1.

[0041] If two adjacent function logs both record function call stack depths of n, then they are executed sequentially and are both called by a function with a function call stack depth of n-1.

[0042] If two adjacent function logs record function call stack depths of n and m respectively, and m is less than n, then the two are executed sequentially, but are not called by the same function.

[0043] The integrated function relationships, along with the function name and parameter list for each function, will be used as the results of TCL program tracing and understanding.

[0044] Furthermore, the method also includes:

[0045] The log file is converted into an XML file to present the TCL program tracing and understanding results; the XML file includes:

[0046] The root tag `process` is the root tag of the XML file converted from the log file.

[0047] The function tag `procedure` is used to identify functions in the log file; the function tag `procedure` includes the following tags:

[0048] The function name tag `name` describes the function name of the function marked by the function tag `procedure`.

[0049] The function execution order label `sequence` describes the execution order of the functions marked by the function label `procedure`.

[0050] The argument list label describes one or more argument labels of the function marked by the procedure label;

[0051] The parameter label `argument` describes the parameter value of the function marked by the function label `procedure`.

[0052] Other function tags, such as procedure, are used to describe other functions that have a calling or sequential execution relationship with the function marked by the procedure tag;

[0053] If the "isEvent" attribute of the function tag "procedure" is "true", then the function marked by the function tag "procedure" is an event handling function; then the function tag "procedure" also includes a component name tag "component", which describes the name of the component to which the event handling function is bound.

[0054] Furthermore, obtaining all functions and their declarations in the TCL program source code includes:

[0055] Lexical analysis is performed on the TCL program source code to obtain lexical analysis results; the lexical analysis results include all words and symbols in the source code, as well as the order of the words and symbols, bracket matching, and bracket hierarchy;

[0056] Syntax analysis is performed on the lexical analysis results based on the function declaration syntax to obtain all functions and their function declarations in the TCL program source code.

[0057] Furthermore, determining whether the function is bound to a graphical user interface component and the events associated with the graphical user interface component includes:

[0058] Based on the event binding syntax, the lexical analysis results of each function are analyzed. If the analysis result satisfies the event binding syntax, then the function is bound to the graphical interface component and the event associated with the graphical interface component; otherwise, it is not bound.

[0059] On the other hand, the present invention also discloses a GUI-driven TCL program tracing and understanding system, comprising:

[0060] The function and function declaration retrieval module is used to retrieve all functions and their declarations in the TCL program source code.

[0061] The function judgment module is used to determine whether the function is bound to a graphical interface component and an event associated with the graphical interface component. If so, the function is an event handling function triggered by the event associated with the graphical interface component; otherwise, the function is a non-event handling function.

[0062] The information collection code instrumentation module is used to locate the instrumentation position based on the function declaration, insert event information collection code at the instrumentation position of the event handling function, and insert non-event information collection code at the instrumentation position of the non-event handling function.

[0063] The tracking and understanding result acquisition module is used to run the TCL program, collect log files collected by the event information collection code and the non-event information collection code, and obtain the tracking and understanding results of the TCL program based on the collected log files.

[0064] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:

[0065] The GUI-driven TCL program tracing and understanding method and system provided by this invention divides functions into time processing functions and non-event processing functions, and uses different information collection codes to instrument the aforementioned functions to obtain the log files of the aforementioned functions; then, by analyzing the log information in the log files, the tracing and understanding results of the TCL program can be obtained.

[0066] This method enables the tracing and understanding of TCL programs, effectively solving the problem that existing technologies cannot trace and understand GUI-driven TCL programs, thereby helping practitioners to better analyze and understand event handling functions and non-event handling functions.

[0067] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0068] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0069] Figure 1 This is a flowchart of the GUI-driven TCL program tracing and understanding method provided in Embodiment 1 of the present invention;

[0070] Figure 2 This is a flowchart of another GUI-driven TCL program tracing and understanding method provided in Embodiment 1 of the present invention;

[0071] Figure 3 A diagram illustrating the multidimensional relationships between components, events, and event handling functions;

[0072] Figure 4 A flowchart for recursively tracing the runtime environment;

[0073] Figure 5 A flowchart for converting log files to XML format;

[0074] Figure 6 This is a schematic diagram of the GUI-driven TCL program tracing and understanding system structure provided in Embodiment 2 of the present invention. Detailed Implementation

[0075] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0076] Example 1

[0077] This invention provides a GUI-driven TCL program tracing method, the flowchart of which is shown below. Figure 1 and Figure 2 As shown, it includes the following steps:

[0078] Step S1: Obtain all functions and their declarations in the TCL program source code;

[0079] Preferably, all functions and their function declarations in the TCL program source code can be obtained by performing the following operations:

[0080] Step S11: Perform lexical analysis on the TCL program source code and obtain the lexical analysis results; the lexical analysis results include all words and symbols in the source code, as well as the order of the words and symbols, bracket matching, and bracket hierarchy;

[0081] Specifically, lexical analysis can be implemented based on a lexical analyzer, which utilizes word segmentation technology and is based on the syntax of the TCL scripting language to perform lexical analysis. The specific operation is as follows:

[0082] Extract all words and symbols from the source code, including whitespace tabs, semicolons, parentheses, commas, numbers, and words, while preserving their order, parenthesis matching, and parenthesis hierarchy.

[0083] Step S12: Perform syntactic analysis on the lexical analysis results based on the function declaration syntax to obtain all functions and their function declarations in the TCL program source code;

[0084] Specifically, syntax analysis can be implemented based on a parser. Since function declaration syntax is relatively fixed, function declaration statements can be identified based on a parser.

[0085] At the same time, since each function has a unique function declaration, after identifying the function declaration, the function name is extracted from it to obtain the function corresponding to the function declaration.

[0086] In the TCL language, the syntax structure for a function declaration is "function declaration reserved words function name {parameter list} {function body}"; where,

[0087] The parameter list is enclosed in a pair of curly braces, with each field separated by a comma within the braces.

[0088] The function body consists of several TCL statements enclosed in curly braces.

[0089] For example, the implementation process of this step is illustrated below:

[0090] For example, the following code snippet is a function named func1 with three parameters: x, s, and arr. "set x 1" is the starting position of the function:

[0091]

[0092] In the example above, the lexical analyzer identifies all words, symbols, bracket matching, and bracket hierarchy relationships in the source code. The syntax analyzer identifies the source code segment as a function declaration based on the function declaration syntax of the TCL language, and extracts the function name and the starting position of the function body from the function declaration. The function name describes the function corresponding to the function declaration, and the starting position of the function body is used as the code instrumentation position in step S3.

[0093] Step S2: Determine whether the function is bound to a graphical interface component and an event associated with the graphical interface component. If so, the function is an event handling function triggered by the event associated with the graphical interface component; otherwise, the function is a non-event handling function.

[0094] The syntax involved in this process includes component creation syntax and event binding syntax; specifically,

[0095] The component creation syntax is used to describe the multidimensional relationships between graphical interface components, associated events, and event handlers, such as... Figure 3 As shown. A graphical interface component may be associated with multiple events, but a component and an event determine a unique event handler function.

[0096] In TCL programs, graphical user interface components provided by the Tk software package can be used to create graphical applications. These components are configurable, meaning that various appearance properties and event handling functions can be specified. When a specific type of component is needed, a new instance can be created. The component creation syntax is as follows:

[0097] Component type Component name [Property type Property value] (1)

[0098] The attribute type and attribute value are optional. The `-command` attribute can be used to add event handlers to the component's default events. The attribute value following `-command` and the component name are the function names of the event handlers obtained and stored in this example. Alternatively, event handlers can be added later using the binding command without adding them when creating the component. Below is the syntax for binding event handlers to an already created component (i.e., the event binding syntax):

[0099] bind component_name<event_name> event_handler_function(2)

[0100] bind is a command in the TCL language used to bind events and event handling functions, and the above statement is also the target of acquisition and storage in this embodiment.

[0101] For example, graphical interface components include buttons, menus, windows, input boxes, etc. The operations that can be bound (i.e., events associated with the graphical interface component) include left and right mouse button clicks, double clicks, and keyboard operations. The following specific example illustrates how to identify event handling functions and extract binding relationships.

[0102] For example, the following code snippet binds a left mouse button event handler function to a component named Entry, with the function name being func1.

[0103] bind Entry <button-1>func1

[0104] Based on the above description, the following operations can be performed to determine whether the function is bound to a graphical interface component and the events associated with the graphical interface component:

[0105] Based on the event binding syntax, the lexical analysis results of each function are analyzed to determine whether the function is bound to a graphical interface component and the event associated with the graphical interface component. If bound, the function is an event handling function; otherwise, the function is a non-event handling function.

[0106] Furthermore, in TCL programs, event handling functions have call relationships with non-event handling functions. To reduce the code complexity of non-event handling functions, complex functions are generally not written directly in event handling functions, but are distributed among many non-event handling functions. Event handling functions implement complex functions by calling non-event handling functions. Considering the above relationship between event handling functions and non-event handling functions, and to more clearly trace and understand GUI-driven TCL programs, this embodiment uses different information acquisition codes to instrument event handling functions and non-event handling functions. The specific implementation process is as follows:

[0107] Step S3: Based on the function declaration, locate the instrumentation position, insert event information collection code at the instrumentation position of the event handling function, and insert non-event information collection code at the instrumentation position of the non-event handling function;

[0108] The instrumentation position is before the first executable statement of the function, i.e., at the beginning of the function body. Considering that not all statements within a function will be executed, and some statements may not be executed due to conditional checks or premature program termination, while the information collection code inserted before the first executable statement will definitely be executed, this embodiment chooses the aforementioned instrumentation position. In addition, since function declarations in each language have fixed syntax, the first executable statement of the function can be located based on the function declaration.

[0109] Considering that event handling functions are always triggered by an event and cannot be called by other functions, the event information collection code includes:

[0110] Global variable $Number;

[0111] The temporary variable $Arguments is used to assign the top-of-the-heap information of the command collection function call to $Arguments; the top-of-the-heap information includes the top-of-the-heap function name and the parameter values ​​of each parameter in the parameter list passed in at runtime;

[0112] The incrementing principle of $Number: $Number is incremented by 1 each time the event information collection code is executed;

[0113] The Print command is used to output the numbers in $Number, the word "isEvent", and the function names and parameter values ​​in the runtime parameter list to a log file.

[0114] The event information acquisition code format corresponding to the TCL language can be represented as follows:

[0115] Global$Number

[0116] $Arguments:=info level-1

[0117] $Number := [expr$Number+1]

[0118] Print "$Number isEvent$Arguments"

[0119] In the above event information collection code format:

[0120] The first line of code, Global$Number, indicates that $Number is a global variable, which is incremented by 1 each time the information collection code is executed; its initial value is 0.

[0121] The "info level-1" in the second line of code represents the command collection function, used to call the top-of-the-heap information. This top-of-the-heap information includes the top-of-the-heap function name and the parameter values ​​of each parameter in the runtime parameter list. The top-of-the-heap function name is the name of the event handling function; that is, the name of the event handling function to be tracked, which is currently located at the top of the heap. The parameter values ​​in the runtime parameter list are the values ​​of each parameter in the parameter list during source code execution, and these values ​​may change as the code runs. Executing the second line of code assigns the called top-of-the-heap information to the temporary variable $Arguments.

[0122] The meaning of the third line of code is: $Number is incremented by 1 every time the information collection code is executed;

[0123] The meaning of the fourth line of code is: the Print command outputs the number in $Number, the word "isEvent", and the event handler function name and runtime parameters passed in from Arguments to the log file.

[0124] For non-event handling functions, since they are executed by calls from other functions, it is also necessary to record the depth of their calls. Therefore, the non-event information collection code includes:

[0125] Global variable $Number;

[0126] The temporary variable $Arguments is used to assign the top-of-the-heap information of the command collection function call to $Arguments; the top-of-the-heap information includes the top-of-the-heap function name and the parameter values ​​of each parameter in the parameter list passed in at runtime;

[0127] The function call stack depth $Depth is used to calculate the function call stack depth.

[0128] The incrementing principle of $Number: $Number is incremented by 1 each time the event information collection code is executed;

[0129] The Print command is used to output the number in $Number, the function call stack depth $Depth, and the function name and the parameter values ​​of each parameter in the argument list passed at runtime to the log file.

[0130] The corresponding non-event information collection code format can be:

[0131] Global$Number

[0132] $Arguments:=info level-1

[0133] $Depth:=info level

[0134] $Number := [expr$Number+1]

[0135] Print"$Number$Depth$Arguments"

[0136] Compared to the event information collection code in the event handler function, the non-event information collection code has an additional instruction for calculating the function call stack depth (in the TCL language used in this example, the info level command is used to calculate the function call stack depth); when outputting to the log file, it adds the function call stack depth compared to the event handler function, and does not have the event handler function flag.

[0137] Step S4: Run the TCL program, collect log files gathered by the event information collection code and the non-event information collection code, and obtain the tracing and understanding results of the TCL program based on the collected log files. The recursive tracing process for this step is as follows: Figure 4 As shown.

[0138] In the collected log files,

[0139] The function log records collected by the event information collection code include: execution sequence number, event handling function flag, function name, and parameter list;

[0140] The function log records collected by the non-event information collection code include: execution order number, function call stack depth, function name, and parameter list;

[0141] Specifically, the function log record is determined based on the Print command:

[0142] The number in $Number is the execution sequence number in the function log record;

[0143] The word "isEvent" is used to identify the event handling function flag in the function log record;

[0144] The function names in the Arguments are the function names recorded in the function log.

[0145] The parameter values ​​of each parameter in the parameter list passed in at runtime are used to determine the parameter values ​​of each parameter in the parameter list in the function log record;

[0146] The $Depth is used to determine the function call stack depth in the function log record.

[0147] It should be noted that the function call stack depth corresponding to the event handling function is 1. That is, if a function log record contains an event handling function flag, the function call stack depth corresponding to the current function log record is 1.

[0148] Since the function logs collected by the non-event information collection code contain function call stack depth information, by comparing the function call stack depth information of two adjacent functions, it can be determined whether they are sequential execution relationships or call relationships. Therefore, by analyzing the above log files, the tracing and understanding results of the TCL program can be obtained. The specific implementation process is as follows:

[0149] Step S41: In the log file, sort the execution order of all functions based on the execution order number in the function log record;

[0150] Step S42: After sorting, determine the relationship between two adjacent functions based on the function call stack depth in the function log records:

[0151] If two adjacent function logs record function call stack depths of n and n+1 respectively, then they are in a calling relationship: the function with function call stack depth n calls the function with function call stack depth n+1.

[0152] If two adjacent function logs both record function call stack depths of n, then they are executed sequentially and are both called by a function with a function call stack depth of n-1.

[0153] If two adjacent function logs record function call stack depths of n and m respectively, and m is less than n, then the two are executed sequentially, but are not called by the same function.

[0154] The integrated function relationships, along with the function name and parameter list for each function, will be used as the results of TCL program tracing and understanding.

[0155] For example, suppose two adjacent log records, A and B, contain function call stack depth information respectively:

[0156] If n and n+1 are given, then their relationship is that A calls B;

[0157] If n and n are respectively, then they are executed sequentially and are both called by C (the function whose most recent call stack depth is n-1).

[0158] Let n and m be the numbers, and m be less than n. A and B are executed sequentially, but they are not executed by the same function call. The corresponding scenario is that D (the function with call stack depth information of m-1) calls C (the function with call stack depth information of n-1), C calls A, A finishes executing, C finishes executing, and then D calls B.

[0159] Furthermore, considering that the log file obtained after step S4 is generally in string text format, each line stores the execution information of one function, and different information items are separated by commas within the line, and this format of log file cannot directly reflect the calling or sequential execution relationship between functions, after the log file is collected, its format can be converted to XML format in order to distinguish the calling and sequential execution relationship between functions and obtain the tracing flowchart;

[0160] The XML file includes:

[0161] The root tag `process` is the root tag of the XML file converted from the log file; that is, the declaration file is an XML file that describes the execution order and calling relationship of functions.

[0162] The function tag `procedure` is used to identify functions in the log file; the function tag `procedure` includes the following tags:

[0163] The function name tag `name` describes the function name of the function marked by the function tag `procedure`.

[0164] The function execution order label `sequence` describes the execution order of the functions marked by the function label `procedure`.

[0165] The argument list label describes one or more argument labels of the function marked by the procedure label;

[0166] The parameter tag `argument` describes the parameter value of the function marked by the function tag `procedure`; its attribute `name` is the parameter name.

[0167] Other function tags, such as procedure, are used to describe other functions that have a calling or sequential execution relationship with the function marked by the procedure tag;

[0168] If the "isEvent" attribute of the function tag "procedure" is "true", then the function marked by the function tag "procedure" is an event handling function; the function tag "procedure" also includes a component name tag, which describes the name of the component to which the event handling function is bound.

[0169] Specifically, the format conversion process is as follows: Figure 5 The XML language format for describing control flow information is as follows:

[0170]

[0171]

[0172] Preferably, the log file can be converted into an XML file by performing the following operations:

[0173] Add a process start tag and set the initial value of the counter to 0;

[0174] The function log records in the log file are sorted in ascending order of function call stack depth;

[0175] Based on the sorting results, read the function log records sequentially, and perform the following operations for each function log record:

[0176] Compare the counter value with the function call stack depth. If the counter value is greater than or equal to the function call stack depth, add "counter value - function call stack depth + 1" procedure end tags and update the counter value to the function call stack depth; otherwise, directly update the counter value to the function call stack depth.

[0177] Determine whether the function log contains an event handler function identifier. If it does, add a procedure start tag with the isEvent attribute set to true, determine the function name tag based on the function name in the function log, and then add a component name tag based on the binding relationship between the event handler function and the component. If it does not contain an event handler function identifier, directly add a procedure start tag with the isEvent attribute set to false, and determine the function name tag based on the function name in the function log.

[0178] The function execution order label (sequence) is determined based on the call or sequential execution relationship between the function and other functions in the current function log record.

[0179] The parameter list label `arguments` is determined based on the parameter list in the function log record;

[0180] Add an argument tag based on the parameter values ​​of each parameter in the function log record;

[0181] Add an arguments closing tag based on the parameter list in the function log.

[0182] In summary, the GUI-driven TCL program tracing and understanding method provided in this embodiment obtains the log files of the aforementioned functions by dividing them into time-processing functions and non-event-processing functions and instrumenting them with different information collection codes; then, by analyzing the log information in the log files, the tracing and understanding results of the TCL program can be obtained.

[0183] This method enables the tracing and understanding of TCL programs, effectively solving the problem that existing technologies cannot tracing and understanding GUI-driven TCL programs, thereby helping practitioners to better analyze and understand event handling functions and non-event handling functions;

[0184] Furthermore, by converting the log files into corresponding XML files, it is easier for relevant technical personnel to better understand the call relationships and sequential execution relationships between functions involved in the log files, and to more clearly describe the tracing and understanding process of TCL programs.

[0185] Example 2

[0186] This embodiment discloses a GUI-driven TCL program tracing and understanding system, the structural diagram of which is shown below. Figure 6 As shown, it includes:

[0187] The function and function declaration retrieval module is used to retrieve all functions and their declarations in the TCL program source code.

[0188] The function judgment module is used to determine whether the function is bound to a graphical interface component and an event associated with the graphical interface component. If so, the function is an event handling function triggered by the event associated with the graphical interface component; otherwise, the function is a non-event handling function.

[0189] The information collection code instrumentation module is used to locate the instrumentation position based on the function declaration, insert event information collection code at the instrumentation position of the event handling function, and insert non-event information collection code at the instrumentation position of the non-event handling function.

[0190] The tracking and understanding result acquisition module is used to run the TCL program, collect log files collected by the event information collection code and the non-event information collection code, and obtain the tracking and understanding results of the TCL program based on the collected log files.

[0191] The specific implementation process of this embodiment can be found in the above method embodiments, and will not be repeated here. Since this embodiment is based on the same principle as the above method embodiments, this system also has the corresponding technology of the above method embodiments.

[0192] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0193] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A GUI-driven method for tracing and understanding TCL programs, characterized in that, include: Retrieve all functions and their declarations from the TCL program source code; Determine whether the function is bound to a graphical interface component and an event associated with the graphical interface component. If so, the function is an event handling function triggered by the event associated with the graphical interface component; otherwise, the function is a non-event handling function. Based on the function declaration, the instrumentation position is located, and event information collection code is inserted at the instrumentation position of the event handling function, while non-event information collection code is inserted at the instrumentation position of the non-event handling function. Run the TCL program to collect log files collected by the event information collection code and the non-event information collection code, and obtain the tracking and understanding results of the TCL program based on the collected log files; The log files collected by the event information collection code and the non-event information collection code include: Collect function log records gathered by the event information collection code, including: execution sequence number, event handling function flag, function name, and parameter list; The function log records collected by the non-event information collection code include: execution order number, function call stack depth, function name, and parameter list; The tracing and understanding results of the TCL program obtained based on the collected log files include: In the log file, the execution order of all functions is sorted based on the execution order number in the function log record; After sorting, the relationship between two adjacent functions is determined based on the function call stack depth in the function log records: If two adjacent function logs record function call stack depths of n and n+1 respectively, then they are in a calling relationship: the function with function call stack depth n calls the function with function call stack depth n+1. If two adjacent function logs both record function call stack depths of n, then they are executed sequentially and are both called by a function with a function call stack depth of n-1. If two adjacent function logs record function call stack depths of n and m respectively, and m is less than n, then the two are executed sequentially, but are not called by the same function. The integrated function relationships, along with the function name and parameter list for each function, will be used as the results of TCL program tracing and understanding.

2. The GUI-driven TCL program tracing and understanding method according to claim 1, characterized in that, The event information collection code includes: Global variable $Number; The temporary variable $Arguments is used to assign the top-of-the-heap information of the command collection function call to $Arguments; the top-of-the-heap information includes the top-of-the-heap function name and the parameter values ​​of each parameter in the parameter list passed in at runtime; The incrementing principle of $Number: $Number is incremented by 1 each time the event information collection code is executed; The Print command is used to output the numbers in $Number, the word "isEvent", and the function names and parameter values ​​in the runtime parameter list to a log file.

3. The GUI-driven TCL program tracing and understanding method according to claim 2, characterized in that, The non-event information collection code includes: Global variable $Number; The temporary variable $Arguments is used to assign the top-of-the-heap information of the command collection function call to $Arguments; the top-of-the-heap information includes the top-of-the-heap function name and the parameter values ​​of each parameter in the parameter list passed in at runtime; $Depth is used to measure the depth of function call stacks. The incrementing principle of $Number: $Number is incremented by 1 each time the event information collection code is executed; The Print command is used to output the numbers in $Number, $Depth, and the function names and runtime parameters passed in from Arguments to a log file.

4. The GUI-driven TCL program tracing and understanding method according to claim 3, characterized in that, The instrumentation position is located based on the function declaration. The starting position of the function body in the function declaration is determined as the instrumentation position.

5. The GUI-driven TCL program tracing and understanding method according to claim 4, characterized in that, The function log record is determined based on the Print command: The number in $Number is the execution sequence number in the function log record; The word "isEvent" is used to identify the event handling function flag in the function log record; If the function log record contains an event handling function flag, then the function call stack depth corresponding to the current function log record is 1; The function names in the Arguments are the function names recorded in the function log. The parameter values ​​of each parameter in the parameter list passed in at runtime are used to determine the parameter values ​​of each parameter in the parameter list in the function log record; The $Depth value is used to determine the function call stack depth in the function log record.

6. The GUI-driven TCL program tracing and understanding method according to claim 5, characterized in that, The method further includes: The log file is converted into an XML file to present the TCL program tracing and understanding results; the XML file includes: The root tag `process` is the root tag of the XML file converted from the log file. The function tag `procedure` is used to identify functions in the log file; the function tag `procedure` includes the following tags: The function name tag `name` describes the function name of the function marked by the function tag `procedure`. The function execution order label `sequence` describes the execution order of the functions marked by the function label `procedure`. The argument list label describes one or more argument labels of the function marked by the procedure label; The parameter label `argument` describes the parameter value of the function marked by the function label `procedure`. Other function tags, such as procedure, are used to describe other functions that have a calling or sequential execution relationship with the function marked by the procedure tag; If the "isEvent" attribute of the function tag "procedure" is "true", then the function marked by the function tag "procedure" is an event handling function; the function tag "procedure" also includes a component name tag, which describes the name of the component to which the event handling function is bound.

7. The GUI-driven TCL program tracing and understanding method according to any one of claims 1-6, characterized in that, The process of obtaining all functions and their declarations in the TCL program source code includes: Lexical analysis is performed on the TCL program source code to obtain lexical analysis results; the lexical analysis results include all words and symbols in the source code, as well as the order of the words and symbols, bracket matching, and bracket hierarchy; Syntax analysis is performed on the lexical analysis results based on the function declaration syntax to obtain all functions and their function declarations in the TCL program source code.

8. The GUI-driven TCL program tracing and understanding method according to claim 7, characterized in that, Determining whether the function is bound to a graphical user interface (GUI) component, and the events associated with the GUI component, includes: Based on the event binding syntax, the lexical analysis results of each function are analyzed. If the analysis result satisfies the event binding syntax, then the function is bound to the graphical interface component and the event associated with the graphical interface component; otherwise, it is not bound.

9. A GUI-driven TCL program tracing and understanding system, characterized in that, include: The function and function declaration retrieval module is used to retrieve all functions and their declarations in the TCL program source code. The function judgment module is used to determine whether the function is bound to a graphical interface component and an event associated with the graphical interface component. If so, the function is an event handling function triggered by the event associated with the graphical interface component; otherwise, the function is a non-event handling function. The information collection code instrumentation module is used to locate the instrumentation position based on the function declaration, insert event information collection code at the instrumentation position of the event handling function, and insert non-event information collection code at the instrumentation position of the non-event handling function. The tracking and understanding result acquisition module is used to run the TCL program, collect log files collected by the event information collection code and the non-event information collection code, and obtain the tracking and understanding results of the TCL program based on the collected log files; The log files collected by the event information collection code and the non-event information collection code include: Collect function log records gathered by the event information collection code, including: execution sequence number, event handling function flag, function name, and parameter list; The function log records collected by the non-event information collection code include: execution order number, function call stack depth, function name, and parameter list; The tracing and understanding results of the TCL program obtained based on the collected log files include: In the log file, the execution order of all functions is sorted based on the execution order number in the function log record; After sorting, the relationship between two adjacent functions is determined based on the function call stack depth in the function log records: If two adjacent function logs record function call stack depths of n and n+1 respectively, then they are in a calling relationship: the function with function call stack depth n calls the function with function call stack depth n+1. If two adjacent function logs both record function call stack depths of n, then they are executed sequentially and are both called by a function with a function call stack depth of n-1. If two adjacent function logs record function call stack depths of n and m respectively, and m is less than n, then the two are executed sequentially, but are not called by the same function. The integrated function relationships, along with the function name and parameter list for each function, will be used as the results of TCL program tracing and understanding.

Images