A debugging method, device and equipment

Abstract

This application provides a debugging method, apparatus, and device. The method includes: generating a task flowchart based on the program to be developed, the task flowchart including multiple task modules; obtaining the task execution result of the task flowchart by executing the multiple task modules, the task execution result being used to debug the program to be developed; obtaining the data to be displayed corresponding to the target task module through a debugger service process; the target task module is the task module among the multiple task modules that needs to display data, and the data to be displayed is the data obtained by the target task module during task execution; sending the data to be displayed to a visual debugger process through the debugger service process, and displaying the data based on the data to be displayed by the visual debugger process. Through the technical solution of this application, the debugging execution result can be sent to the visual debugger process for display via inter-process communication, and the visual debugger process is not blocked by breakpoint interruptions.

Description

Technical Field

[0001] This application relates to the field of debugging technology, and in particular to a debugging method, apparatus and equipment. Background Technology

[0002] An IDE (Integrated Development Environment) is an application that provides a program development environment, including tools such as code editors, compilers, debuggers, and graphical user interfaces. It is a suite of integrated development software services that integrates code writing, analysis, compilation, and debugging functions. Software or software suites (sets) with these characteristics can be called an integrated development environment.

[0003] In the process of debugging a program in an integrated development environment (IDE), a breakpoint is a specific location set by the debugging tool that pauses the execution of the program and enters debug mode. In debug mode, developers can inspect the program's variable values, memory state, and execution flow. Breakpoints can be categorized into instruction breakpoints and data breakpoints. Instruction breakpoints are implemented through the processor exception mechanism and are used to interrupt specific lines of code. Data breakpoints are used to detect changes in memory address data and are suitable for detecting unauthorized modifications.

[0004] When the program under development reaches a breakpoint, the program needs to pause execution and enter debug mode. In other words, the program is in an interrupted state, which makes it impossible to refresh the execution results of the program under development in real time. Summary of the Invention

[0005] This application provides a debugging method, the method comprising: A task flowchart is generated based on the program to be developed. The task flowchart includes multiple task modules. The task execution result of the task flowchart is obtained by executing the multiple task modules. The task execution result is used to debug the program to be developed. The data to be displayed corresponding to the target task module is obtained through the created debugger service process; wherein, the target task module is the task module that needs to display data among the multiple task modules, and the data to be displayed is the data obtained by the target task module during task execution; The debugger service process sends the data to be displayed to the created visual debugger process, and the visual debugger process displays the data based on the data to be displayed.

[0006] This application provides a debugging device, the device comprising: The processing module is used to generate a task flowchart based on the program to be developed, the task flowchart including multiple task modules; and to obtain the task execution result of the task flowchart by executing the multiple task modules, the task execution result being used for debugging the program to be developed. The acquisition module is used to acquire the data to be displayed corresponding to the target task module through the created debugger service process, and send the data to be displayed to the created visual debugger process through the debugger service process; wherein, the target task module is the task module that needs to display data among the multiple task modules, and the data to be displayed is the data acquired by the target task module during task execution; The display module is used to display data based on the data to be displayed through a visual debugger process.

[0007] This application provides an electronic device, including: a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the debugging method of the above example.

[0008] This application provides a computer program product, which includes a computer program that, when executed by a processor, implements the debugging method of the example described above.

[0009] This application provides a machine-readable storage medium storing machine-executable instructions that can be executed by a processor; wherein the processor is configured to execute the machine-executable instructions to implement the debugging method of the example described above when the machine-executable instructions are executed.

[0010] As can be seen from the above technical solutions, in the embodiments of this application, during the development of the program to be developed, the data to be displayed corresponding to the target task module can be obtained through the debugger service process, and the data to be displayed can be sent to the visual debugger process through the debugger service process. The visual debugger process then displays the data based on the data to be displayed, thereby displaying data during the development of the program to be developed. For example, when a breakpoint is reached in the program to be developed, although the program to be developed pauses execution and enters a debugging state, i.e., the program to be developed is in an interrupted state, the data can still be displayed through the visual debugger process, thereby refreshing the execution results of the program to be developed (such as the data to be displayed corresponding to the target task module) in real time. By designing an implementation mechanism for an external debugger, when debugging code in the integrated development environment, the single-step or multi-step debugging execution results (data to be displayed) can be automatically sent to the visual debugger process for display through inter-process communication. The visual debugger process is not blocked by breakpoint interruptions and can respond and refresh the debugging execution results in real time. Users can directly write debugging code in the code editor. When debugging is interrupted, the visual debugger process can render the user's debugging results in real time, making it more convenient for users. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating a debugging method in one embodiment of this application; Figure 2 This is a flowchart illustrating a debugging method in one embodiment of this application; Figure 3 This is a schematic diagram of the basic structure of an external debugger in one embodiment of this application; Figure 4 This is a schematic diagram illustrating the basic principle of an external debugger in one embodiment of this application; Figure 5A This is a data rendering diagram of a target task module in one embodiment of this application; Figure 5B This is a schematic diagram illustrating the rendering and visualization of an external debugger in one embodiment of this application; Figure 5C This is a schematic diagram of the process of exiting the plug-in debugger in one embodiment of this application; Figure 5D This is a schematic diagram illustrating the clearing operation of an external debugger in one embodiment of this application; Figure 6 This is a flowchart illustrating reverse debugging in one embodiment of this application; Figure 7 This is a schematic diagram of the debugging device in one embodiment of this application; Figure 8 This is a hardware structure diagram of an electronic device according to one embodiment of this application. Detailed Implementation

[0012] This application provides a debugging method that can be applied to electronic devices such as personal computers, laptops, smartphones, and servers, without limitation. See also Figure 1 The diagram shown illustrates the flowchart of this debugging method, which may include: Step 101: Generate a task flowchart based on the program to be developed. This task flowchart may include multiple task modules. The task execution results of the task flowchart are obtained by executing these multiple task modules. These results are used for debugging the program to be developed. For example, during the development of the program to be developed, a task flowchart is generated based on the program.

[0013] Step 102: Obtain the data to be displayed corresponding to the target task module through the created debugger service process; wherein, the target task module can be the task module that needs to display data among multiple task modules, and the data to be displayed can be the data obtained by the target task module during task execution.

[0014] Step 103: Send the data to be displayed to the created visual debugger process through the debugger service process, and display the data based on the data to be displayed through the visual debugger process.

[0015] For example, before obtaining the data to be displayed corresponding to the target task module through the already created debugger service process, if a debugger open command for the program to be developed is received, a debugger service process and a visual debugger process corresponding to the program to be developed can be created. Based on this, obtaining the data to be displayed corresponding to the target task module through the already created debugger service process can include: during the task execution of the target task module, if the target task module obtains the data to be displayed, determining whether a debugger service process has been created; if so, obtaining the data to be displayed corresponding to the target task module through the debugger service process. Specifically, for any task module in the task flowchart, if the task module has a first-type marker indicating that data needs to be displayed, then that task module is considered the target task module.

[0016] For example, before the visual debugger process displays data based on the data to be displayed, the debugger service process can send the target execution count corresponding to the target task module to the visual debugger process. After each execution of all task modules in the task flowchart, the target execution count corresponding to the target task module is incremented by a preset value (e.g., 1). Based on this, displaying data based on the data to be displayed by the visual debugger process can include, but is not limited to: determining whether the execution count corresponding to the stored historical data is the same as the target execution count; if so, displaying data based on the historical data and the data to be displayed; if not, deleting the historical data and displaying data based on the data to be displayed.

[0017] For example, data display based on historical data and data to be displayed may include, but is not limited to: if the data to be displayed is an image to be displayed and the historical data is a historical image, then the image to be displayed can be displayed within the rendering area; or, the image to be displayed and the historical image can be merged to obtain a merged image, and then the merged image can be displayed within the rendering area. Furthermore, if the data to be displayed is a graphic to be displayed and the historical data is a historical graphic, then a background image can be displayed within the rendering area, and the graphic to be displayed can be overlaid on the background image; or, a background image can be displayed within the rendering area, and the graphic to be displayed and the historical graphic can be overlaid on the background image; wherein, the background image is the output image of the preceding task module of the target task module, and the output image is the image obtained by the preceding task module after the task execution is completed.

[0018] For example, after the visual debugger process displays the data based on the data to be displayed, if an exit event of the visual debugger process is detected, the debugger service process is destroyed.

[0019] Alternatively, if the first type of marker corresponding to the target task module is modified to a second type of marker, and this second type of marker indicates that displayed data needs to be deleted, the debugger service process can send the unique identifier of the target task module to the visual debugger process, and the visual debugger process can delete the displayed data corresponding to the target task module based on the unique identifier of the target task module. Alternatively, if the preceding task module of the target task module has a second type of marker, the debugger service process can send the unique identifier of the target task module to the visual debugger process, and the visual debugger process can delete the displayed data corresponding to the target task module based on the unique identifier of the target task module.

[0020] For example, if the program to be developed includes at least one breakpoint, generating a task flowchart based on the program to be developed may include: when the program to be developed is debugged to the first breakpoint, generating a task flowchart based on the first program execution code in the program to be developed in the interrupted state of the first breakpoint; or, when the program to be developed is debugged to the first breakpoint, backtracking to the second breakpoint before the first breakpoint in the interrupted state of the first breakpoint, generating a task flowchart based on the second program execution code in the program to be developed in the interrupted state of the second breakpoint; wherein, the first program execution code may be the program execution code located before the first breakpoint; the second program execution code may be the program execution code located before the second breakpoint.

[0021] For example, the program to be developed includes a machine vision program to be developed, the task flowchart includes a machine vision task flowchart, and each task module includes an operator module; wherein, when each operator module is executed, machine vision task processing is performed by calling the operation file corresponding to the operator module; or, when each operator module is executed, machine vision task processing is performed by calling the network model corresponding to the operator module.

[0022] As can be seen from the above technical solutions, in the embodiments of this application, during the development of the program to be developed, the data to be displayed corresponding to the target task module can be obtained through the debugger service process, and the data to be displayed can be sent to the visual debugger process through the debugger service process. The visual debugger process then displays the data based on the data to be displayed, thereby displaying data during the development of the program to be developed. For example, when a breakpoint is reached in the program to be developed, although the program to be developed pauses execution and enters a debugging state, i.e., the program to be developed is in an interrupted state, the data can still be displayed through the visual debugger process, thereby refreshing the execution results of the program to be developed (such as the data to be displayed corresponding to the target task module) in real time. By designing an implementation mechanism for an external debugger, when debugging code in the integrated development environment, the single-step or multi-step debugging execution results (data to be displayed) can be automatically sent to the visual debugger process for display through inter-process communication. The visual debugger process is not blocked by breakpoint interruptions and can respond and refresh the debugging execution results in real time. Users can directly write debugging code in the code editor. When debugging is interrupted, the visual debugger process can render the user's debugging results in real time, making it more convenient for users.

[0023] The technical solutions described above in the embodiments of this application will be explained below in conjunction with specific application scenarios.

[0024] An Integrated Development Environment (IDE) is an application that provides a program development environment, including tools such as a code editor, compiler, debugger, and graphical user interface. It's a suite of integrated development software services that combines code writing, analysis, compilation, and debugging capabilities. Users (such as secondary development users, also known as developers) can use the IDE to debug programs, designating the programs that need debugging as "programs to be developed." Debugging these programs involves customizing and modifying them, extending their functionality, to ensure the debugged program meets user expectations.

[0025] During program debugging in an integrated development environment (IDE), breakpoints can be used to pause the execution of the program and enter debug mode. In debug mode, users can inspect the variable values, memory status, and execution flow of the program. However, when a breakpoint is reached, the program is in an interrupted state, meaning it is blocked and the execution results cannot be updated in real time.

[0026] To address the aforementioned findings, this application proposes a method for implementing an external visual debugger, relating to the field of debugger implementation and particularly suitable for debugging secondary development projects based on machine vision algorithm platforms. When a user debugs a program under development in an integrated development environment, after starting the external debugger (external visual debugger), the results of single-step or multi-step debugging execution can be automatically sent to the external debugger via inter-process communication. The external debugger is not blocked by the current breakpoint and can respond and refresh the debugging rendering results in real time. Furthermore, a reverse visual debugging mechanism is designed. When a problem is found in the execution result, the user can perform reverse troubleshooting, freely reverting to any interruption point and re-executing single-step or multi-step. The external debugger can respond to the results of the currently executed code and supports rendering and displaying image and graphical results. Additionally, the user can simultaneously operate the external debugger during debugging, switching between the graphical lists of the currently selected module's execution results and overlaying them for troubleshooting, thus making troubleshooting more convenient.

[0027] For example, "plug-in" refers to a debugger process that can be started when a user interrupts debugging a project developed based on an algorithm platform. The results of single or multiple steps of debugging can be automatically sent to the plug-in debugger via inter-process communication. The plug-in debugger can process and refresh this data in real time without being blocked by breakpoints in the integrated development environment.

[0028] For example, visualization means that the external debugger can support rendering images or graphics of the current debugging module (hereinafter referred to as the target task module), and will collect the graphic results (or image results) of the same target task module and the same number of executions. During the debugging process, the user can operate the external debugger at the same time, switch the list of graphics overlaid on the current image, and thus browse the rendering results more intuitively.

[0029] For example, reverse debugging refers to the process where, when a problem is found in the execution result, the user needs to investigate which step of the result is faulty. Therefore, it is necessary to roll back to any suspected position to perform reverse debugging. The external debugger in this embodiment supports real-time rendering of single or multi-step execution results after rollback interruption, making it faster for users to troubleshoot problems and quickly identify which step of the result is faulty.

[0030] In the above application scenarios, this application proposes a debugging method, see [link to relevant documentation]. Figure 2 The diagram shown illustrates the flowchart of this debugging method, which may include: Step 201: During the development of the program to be developed, a task flowchart is generated based on the program. This task flowchart may include multiple task modules. By executing multiple task modules, the task execution results of the task flowchart are obtained. These task execution results are used for debugging the program to be developed.

[0031] For example, the program to be developed can be any program (software) that needs to be debugged in an integrated development environment. It can be a program for machine vision algorithms or a program for other algorithms. There is no restriction on the type of program to be developed. Taking a machine vision program as an example, the task flowchart corresponding to the machine vision program can also be called a machine vision task flowchart. Each task module in the machine vision task flowchart can be an operator module.

[0032] In summary, during the development of a machine vision program, a machine vision task flowchart can be generated based on the program. This flowchart can include multiple operator modules. By executing these operator modules, the task execution result of the flowchart is obtained. This result is used for further development (secondary development) of the machine vision program, also known as debugging. In other words, the execution result is used to debug the machine vision program.

[0033] For example, in the field of machine vision, machine vision task flowcharts (i.e., flowcharts used to implement artificial intelligence) are used to achieve functions such as detection, measurement, recognition, or localization. A machine vision task flowchart can include multiple operator modules, which form a complete and logical task flow. These operator modules are interconnected, and the connection relationship can represent the input-output relationship between the operator modules.

[0034] For example, for each operator module, the input data of the operator module is the output data of another operator module, and / or, the output data of the operator module is the input data of another operator module.

[0035] For example, operation files or network models (i.e., model files) corresponding to operator modules can be pre-stored. When an operator module is executed, the corresponding operation file or network model can be called to perform machine vision processing on the input data of that operator module. Specifically, when an operator module is executed, machine vision task processing can be performed by calling the corresponding operation file; or, when an operator module is executed, machine vision task processing can be performed by calling the corresponding network model.

[0036] If the operator module corresponds to an operation file, then when calling the corresponding operation file to perform machine vision processing on the input data of the operator module, the operation file can be called directly to perform machine vision processing on the input data of the operator module. Alternatively, multiple configuration parameters can be displayed to the user, who can select a target configuration parameter from among them. Based on the target configuration parameter, the operation file can be called to perform machine vision processing on the input data of the operator module. Taking the operation file corresponding to the operator module for converting an RGB image to a grayscale image as an example, the input data of the operator module can be an RGB image. The operation file can be called directly to perform color conversion on the RGB image (i.e., color conversion is machine vision processing) to obtain a grayscale image, which can be the output data of the operator module.

[0037] If the operator module corresponds to a network model (such as a deep learning-based network model or a neural network model), then when calling the network model corresponding to the operator module to perform machine vision processing on the input data of the operator module, the input data of the operator module can be input to the network model, and the network model will perform machine vision processing based on the input data. Taking the network model corresponding to the operator module for image color recognition as an example, the input data of the operator module can be an image. The image can be input to the network model, which will perform color recognition based on the image, obtain the color recognition result, and output the color recognition result. This color recognition result is the output data of the operator module.

[0038] In one possible implementation, see Figure 3 The diagram shows the basic structure of an external debugger. When debugging a program under development (i.e., the development process of the program under development) in an integrated development environment, the code appender (i.e., the appender used for debugging the program under development in the integrated development environment) can include the secondary development project code area, the secondary development project appender, and the external debugger process.

[0039] The code area for secondary development projects can display the code of the program to be developed. Figure 3 This only shows a portion of the code in the program to be developed; the content of this code is not restricted. During program debugging in the integrated development environment, multiple breakpoints can be added to the program to be developed, meaning the program to be developed must include at least one breakpoint. Based on this, when the program to be developed is debugged to the first breakpoint (the first breakpoint can be any breakpoint in the program to be developed), in the interrupted state of the first breakpoint, a task flowchart is generated based on the first program execution code in the program to be developed. The first program execution code is the program execution code located before the first breakpoint.

[0040] exist Figure 3 The diagram shows five breakpoints in the program to be developed. When the program is debugged to breakpoint 1 (the first breakpoint), the program can be paused and enter debug mode. In this way, a task flowchart is generated based on the program execution code before breakpoint 1 (i.e., the lines of code before breakpoint 1). There are no restrictions on the process of generating this task flowchart, as long as it reflects the function of each line of code.

[0041] When the program under development reaches breakpoint 2, the program can be paused and enter debug mode. The task flowchart is generated based on the program execution code before breakpoint 2, and so on.

[0042] For additional programs in secondary development projects, the execution flow, real-time debugger, flow area, and rendering area can be involved. The flow area can display a task flowchart, which can include multiple task modules; for example, image source, circle search, and line search are multiple task modules that together form the task flowchart. For instance, when debugging reaches the first breakpoint, after generating a task flowchart based on the first program execution code preceding the breakpoint, this task flowchart can be displayed through the flow area.

[0043] Regarding the execution flow, multiple task modules in the task flowchart can be executed sequentially to obtain the task execution results. For example, first execute the "Image Source" task module, such as acquiring the image source. Then, execute the "Circle Search" task module, such as finding a circle that meets the requirements from the image source. Then, execute the "Line Search" task module, such as finding a straight line that meets the requirements from the circle that meets the requirements. In other words, the above three task modules are executed serially.

[0044] After the above processing, the task execution result of the task flowchart can be obtained. This result is used for debugging the program under development, such as displaying the task execution result of the flowchart so that users can view the task execution outcome and debug the program under development (i.e., performing secondary development on the code, such as modifying, adding, or deleting code content). There are no restrictions on this debugging process. For example, if problems are found in the code based on the task execution result of the flowchart, the program under development can be optimized by modifying, adding, or deleting code content.

[0045] The rendering area displays the image and graphics of the target module, which can be the last task module in the task flowchart. The image and graphics of the target module can be the output data of the last task module, serving as the task execution result of the task flowchart. Therefore, after obtaining the task execution result of the task flowchart, it can be displayed in the rendering area, allowing users to view the task execution results and debug the program under development.

[0046] For a real-time debugger, the real-time debugger is used to start the debugger process. For example, if the real-time debugger receives a debugger open command, it can start the debugger process, as described in the following embodiments.

[0047] Regarding external debuggers, an external debugger can be a new process, which may be called a visual debugger process, an external visual debugger process, or simply an external debugger process, hereinafter referred to as the external debugger process (abbreviated as external debugger). The external debugger process may include rendering controls, which display the debugging images and graphics in real time and present the debugging execution results in real time.

[0048] For example, the current debugging module can be denoted as the target task module. The target task module is the task module that needs to display data among the multiple task modules in the task flowchart. Figure 3 Taking the "Circle Search" task module as an example, the external debugger process can display the image and graphics of the "Circle Search" task module in real time.

[0049] Step 202: If a debugger open command is received for the program to be developed, a debugger service process corresponding to the program to be developed and a visual debugger process corresponding to the program to be developed are created.

[0050] For example, a user can start the external debugger process (i.e., the visual debugger process) by issuing a command. This way, the user will receive the debugger open command and create both the debugger service process and the external debugger process. Alternatively, the user can start the external debugger process by issuing configuration data (configuration data for starting the external debugger process). This way, the user will receive the debugger open command and create both the debugger service process and the external debugger process. Or, a debugger button can be provided to the user. If the user clicks the debugger button (indicating the start of the external debugger process), the user will receive the debugger open command and create both the debugger service process and the external debugger process. Of course, these are just a few examples and are not limitations. Users can decide whether to start the external debugger process based on their actual needs.

[0051] In one possible implementation, see Figure 4 The diagram shown illustrates the basic principle of an external debugger. Secondary development projects may include the original debugging program, the algorithm platform (such as a machine vision algorithm platform), and the secondary development project itself.

[0052] For secondary development of the original debugging add-on program, a debugger button can be provided to the user. If the user clicks this debugger button, it means that the user needs to open the debugger (i.e. start the external debugger process). The debugger can then receive the debugger open command and send the debugger open command to the debugger engine.

[0053] Regarding the algorithm platform, the algorithm platform is the framework layer upon which the secondary development program is based. The algorithm platform may include a debugger engine (i.e., Figure 3 In the context of a real-time debugger, after receiving a debugger open command, the debugger engine can start the debugger process, i.e., start the plugin, and obtain a plugin debugger process. After receiving the debugger open command, the debugger engine can also create a debugger service (a debugger service object instance), i.e., create a service, and obtain a debugger service, which is also a process, hereinafter referred to as the debugger service process.

[0054] After creating the debugger service process and the external debugger process, the debugger service process and the external debugger process can send data via inter-process communication, enabling real-time communication and interaction. Thus, the debugger service process can send rendering data to the external debugger process; the process of sending rendering data can be found in subsequent embodiments.

[0055] Step 203: Obtain the data to be displayed corresponding to the target task module through the debugger service process. For example, the target task module can be the task module that needs to display data among multiple task modules in the task flowchart, and the data to be displayed can be the data obtained by the target task module during task execution.

[0056] For example, a task flowchart may include multiple task modules. For any given task module, it is determined whether that module needs to display data. If the task module needs to display data, then that task module becomes the target task module; otherwise, it does not. For instance, if the task module corresponds to a first-type marker (a marker indicating that data display is required), it means that the task module needs to display data, i.e., it becomes the target task module. If the task module does not correspond to a first-type marker, it means that the task module does not need to display data, i.e., it does not become the target task module.

[0057] For example, during the execution of the target task module, if the target task module obtains the data to be displayed, it can determine whether a debugger service process has been created; if so, the target task module sends the data to be displayed to the debugger service process, and the debugger service process obtains the data to be displayed corresponding to the target task module; if not, the target task module does not send the data to be displayed.

[0058] For example, for a task module that needs to display data, a first-type marker can be pre-configured for that task module, making it a target task module. For instance, to pre-configure the first-type marker for the task module, an annotation method (also called a pre-embedded slice method, with the annotation method serving as the first-type marker) can be pre-embedded in the interface corresponding to the task module. Thus, when the interface corresponding to the task module is called, this annotation method (slice method) will be executed. Executing this annotation method (slice method) indicates that this task module is the target task module and its processing flow needs to be executed; that is, the target task module executes the annotation method (slice method).

[0059] For example, calling the interface corresponding to the task module means executing the task module's task by calling this interface, that is, executing the relevant task through the task module, without any restrictions on this process.

[0060] For example, regarding the execution of annotation methods (slicing methods), during the task execution of the target task module, if the target task module obtains the data to be displayed, it checks whether a debugger service process has been created. If so, the target task module sends the data to be displayed to the debugger service process, i.e., the debugger service process obtains the data to be displayed corresponding to the target task module. If not, the data to be displayed is not sent. In summary, if annotation methods (slicing methods) are pre-embedded in the user-exposed interface (i.e., the interface corresponding to the target task module), when this interface is executed, the pre-embedded annotation methods (slicing methods) will trigger the sending of the data to be displayed corresponding to the target task module to the debugger service process.

[0061] The data to be displayed for the target task module can be data acquired by the target task module during task execution, the execution result of the target task module (i.e., the result data of the target task module), or intermediate state data of the target task module (i.e., data used during task execution). There are no restrictions on the type of data to be displayed. The data to be displayed for the target task module can be an image, a graphic, or other types of data. For example, when the "Circle Search" task module searches for a circle that meets the requirements from the image source, this circle that meets the requirements is the data to be displayed. When the "Line Search" task module searches for a straight line that meets the requirements from within a circle that meets the requirements, this straight line that meets the requirements is the data to be displayed.

[0062] In one possible implementation, see Figure 4 As shown, the supplementary program for the secondary development project can include the secondary development project project, which can include an interrupt debugging state. For example, when the program under development reaches a breakpoint, it can be interrupted and enter debug mode. In debug mode, code execution retrieves the graphical interface. For instance, the task flowchart includes a circle search module. When calling the interface corresponding to the circle search module (i.e., retrieving the graphical interface), the circle search module needs to perform a graphical retrieval operation, such as retrieving graph 1 and graph 2. That is, graph 1 (graph 2) serves as the result data of the circle search module, and graph 1 (graph 2) serves as the data to be displayed by the circle search module.

[0063] Assuming the graphical interface is pre-embedded with an annotation method (slicing method), calling the graphical interface will trigger the execution of this annotation method (slicing method), with the circle search module as the target task module. When executing the annotation method (slicing method), it's necessary to check if the debugger service instance (i.e., the debugger service process) exists. If it exists, the data to be displayed from the circle search module (e.g., graph 1) is sent to the debugger service process; that is, rendering data is sent to the debugger service process, and the rendering data is the data to be displayed from the circle search module (e.g., graph 1). If it doesn't exist, no operation is performed.

[0064] Step 204: Send the data to be displayed to the visual debugger process through the debugger service process.

[0065] For example, after obtaining the data to be displayed corresponding to the target task module through the debugger service process, the debugger service process can send the data to be displayed corresponding to the target task module to the external debugger process (visual debugger process), that is, the debugging result is sent to the external debugger process.

[0066] In one possible implementation, see Figure 4 As shown, the debugger service process can send data via inter-process communication (IPC). For example, the debugger service process can send data to be displayed to the external debugger process via inter-process communication.

[0067] Step 205: Display the data based on the data to be displayed through the visual debugger process.

[0068] See Figure 4 As shown, when the program under development is debugged to a certain breakpoint (i.e., a breakpoint is added), the program under development is interrupted, that is, the attached program is blocked, and the program enters a debug blocked state. On this basis, the external debugger process (visual debugger process) processes and displays data in a non-blocking manner. That is to say, the external debugger process displays data based on the data to be displayed, rather than being in a debug blocked state.

[0069] In summary, when the program under development reaches a breakpoint during debugging, an additional external debugger process can be launched. This external debugger process then displays the data based on the data to be displayed, avoiding debugging blockages caused by the inability of additional programs in the secondary development project to display data. This allows for real-time data display. For example, while debugging code, the user can launch the external debugger process, so that data from each step of the debugging process that is interrupted can be sent to the external debugger process for processing and display in real time.

[0070] In one possible implementation, the debugger service process can also count the number of times the target task module is executed. When sending the data to be displayed to the visual debugger process through the debugger service process, the debugger service process also sends the number of times the target task module is executed to the visual debugger process. That is, the data to be displayed and the number of times the target is executed are sent to the visual debugger process simultaneously.

[0071] To determine the target execution count for a specific task module, after each execution of all task modules in the task flowchart, the target execution count for that module is incremented by a preset value (e.g., 1). For example, when the program under development enters a debugging blocking state, the task modules in the task flowchart may be executed multiple times. During the first execution of all task modules in the task flowchart, the target execution count for the target task module is updated to 1 (the initial value of the target execution count is 0). During the second execution of all task modules in the task flowchart, the target execution count for the target task module is updated to 2, and so on. Based on this, the debugger service process can record the target execution count for each target task module.

[0072] For example, after synchronously sending the data to be displayed and the target execution count to the visual debugger process, the visual debugger process can determine whether the execution count corresponding to the stored historical data is the same as the target execution count. If yes, it means that the historical data and the data to be displayed are from the same execution, and the data can be displayed based on the historical data and the data to be displayed. If no, it means that the historical data and the data to be displayed are from different executions, the historical data is deleted, and the data is displayed based on the data to be displayed.

[0073] For example, during the first execution of all task modules in the task flowchart, the visual debugger process stores graphs 1 and 2 corresponding to the target task module. During the second execution of all task modules in the task flowchart, it stores graphs 3 and 4 corresponding to the target task module. Clearly, since graph 3 and graph 1 (or graph 2) are from different executions, they will not be displayed together. Therefore, when graph 3 is obtained, because the execution count 1 corresponding to the stored historical data (graphs 1 and 2) differs from the target execution count 2, graphs 1 and 2 need to be deleted, and the data is displayed based on graph 3. When graph 4 is obtained, because the execution count 2 corresponding to the stored historical data (graph 3) is the same as the target execution count 2, graph 3 is not deleted; instead, the data is displayed based on graphs 3 and 4.

[0074] For example, the data to be displayed corresponding to the target task module can be an image or a graphic. The visual debugger process can display the image or graphic in different ways, which will be explained below.

[0075] For images: When displaying data based on historical data and data to be displayed, the data to be displayed is the image to be displayed, and the historical data is the historical image. Based on this, the image to be displayed can be shown within the rendering area, i.e., only the image to be displayed can be shown. Alternatively, a fusion operation can be performed on the image to be displayed and the historical images (such as weighted fusion, inputting the image to be displayed and the historical images into a neural network for fusion, etc., the fusion method is not limited) to obtain a fused image, which can then be displayed within the rendering area.

[0076] When displaying data based on the data to be displayed, the data to be displayed is the image to be displayed. Based on this, the image to be displayed can be displayed within the rendering area, that is, only one frame of the image to be displayed is displayed.

[0077] For graphics: When displaying data based on historical data and data to be displayed, the data to be displayed is the graphic to be displayed, and the historical data is the historical graphic. Based on this, a background image can be displayed within the rendering area, and the graphic to be displayed can be overlaid on this background image; that is, the graphic to be displayed is only displayed on the background image.

[0078] Alternatively, a background image can be displayed within the rendering area, and the graphic to be displayed and historical graphics can be overlaid on this background image, meaning that the graphic to be displayed and historical graphics can be displayed simultaneously. For example, the graphic to be displayed and historical graphics may or may not overlap. When multiple historical graphics exist, all historical graphics can be displayed on the background image, or a portion of the historical graphics can be displayed on the background image (e.g., providing the user with a list of graphics from which the user selects a portion of the historical graphics).

[0079] When displaying data based on data to be displayed, the data to be displayed is a graphic to be displayed. Based on this, a background image can be displayed within the rendering area, and the graphic to be displayed can be overlaid on the background image.

[0080] Regarding the background image, it can be a configured default image, such as an image where all pixels are 0. Alternatively, it can be the output image of the preceding task module of the target task module, and the output image can be the image obtained by the preceding task module after the task is completed.

[0081] For example, if a task flowchart includes task module 1, task module 2, and task module 3, with task module 3 as the target task module, then if task module 2 produces an image upon completion, task module 2 is considered the preceding task module, and the background image is its output image. If task module 2 does not produce an image upon completion, but task module 1 produces an image, then task module 1 is considered the preceding task module, and the background image is its output image, and so on. The task module preceding the target task module whose execution result is an image is considered the preceding task module, and the execution result of the preceding task module is considered the background image.

[0082] For example, the debugger service process can obtain the output image of the preceding task module of the target task module and send the output image of the preceding task module to the visual debugger process.

[0083] For example, see Figure 5A The diagram illustrates data rendering for a target task module. If the data to be displayed for the target task module is an image, the target task module can send the image data (i.e., the data to be displayed) to the external debugger process, allowing the external debugger process to receive the image data.

[0084] If the data to be displayed corresponding to the target task module is a graphic, i.e., the target task module is acquiring the graphic for the first time, then the target task module can send the output image of the previously subscribed module (i.e., the preceding task module) to the external debugger process, along with the current debug module information (such as the unique identifier of the target task module), and the graphic (such as the graphic acquired for the first time by the target task module) and its type (i.e., the type of the graphic, such as a line, a circle, etc.). The external debugger process can receive the output image of the preceding task module (as a background image), the module information of the target task module, the graphic, and its type. Furthermore, when the debug module (target task module) acquires the graphic for the first time, the target task module can send the graphic and its type to the external debugger process. The external debugger process can receive the graphic and its type.

[0085] After receiving data, the debugger process can render the data according to its data type. For example, if the debugger process receives an image (the data to be displayed is an image, and the data type is image), then the debugger renders the image (i.e., updates the rendering object and displays the currently received image). Or, if the debugger process receives a graphic (the data to be displayed is a graphic, and the data type is graphic), then the debugger renders the graphic (i.e., updates the rendering object and displays the currently received graphic).

[0086] If the external debugger process receives a graphic, the external debugger can collect a list of graphics, which includes the currently received graphics as well as previously stored historical graphics. In this way, all graphics in the graphic list can be rendered (i.e., the rendering object is updated to display all graphics in the graphic list).

[0087] Alternatively, under the same task module and the same number of executions, the graphic data acquired multiple times is processed and collected into graphic list a. The user can manually select graphic list b (i.e., switch to selecting graphic list b, which can include all or some of the graphics in graphic list a). In this way, all the graphics in graphic list b can be rendered (i.e., the rendering object is updated to display all the graphics in graphic list b).

[0088] For example, in debug mode, users can only see basic data results and cannot intuitively view the image and graphical data results of task modules. Therefore, the external debugger process can render the received images and graphics. Furthermore, during debugging, users can manually switch the list of overlaid rendered images for a clearer view of the currently executing module's results.

[0089] For example, see Figure 5B The image shows a schematic diagram of the external debugger's rendering visualization. The text display section shows the unique identifier of the target task module. The rendering controls section displays rendering layers and rendering graphic overlay selections. For rendering layers, the user can select layer information. For rendering graphic overlay selections, the user can choose which graphics to display; for example, the rendering graphic overlay selection can provide a list of graphics from which the user selects for display.

[0090] In the image and graphics display section (i.e., the rendering area), a background image can be displayed, and a user-selected graphic can be overlaid on the background image. Multiple graphics can be overlaid here.

[0091] In one possible implementation, if an exit event of the visual debugger process (external debugger process) is detected, the debugger service process is destroyed. For example, the debugger engine can listen for process exit events. When the external debugger process is closed (e.g., by terminating the process), such as when the user manually closes the external debugger process, the debugger engine receives an exit response and destroys the previously created debugger service process. Thus, when the user executes the graphical acquisition method again, since the debugger service process no longer exists, there will be no further interaction with the external debugger process, and no data will be displayed.

[0092] For example, see Figure 5CThe diagram shows the process of exiting the cheat debugger. When the cheat debugger process is closed (i.e., the program is closed), the debugger engine will detect the cheat exit (i.e., the cheat debugger process exits), and the debugger engine will destroy the debugger service instance (debugger service process).

[0093] In one possible implementation, after the external debugger process renders the data to be displayed corresponding to the target task module, if it needs to delete the target task module (e.g., by deleting the target task module during debugging of the program under development), or if it needs to delete the preceding task module (the task module located before the target task module in the task flowchart, also known as the parent task module to which the target task module belongs), then the data displayed by the external debugger process needs to be cleared before deleting the target task module (preceding task module). The deletion operation of the target task module (preceding task module) is only performed after the data clearing operation of the target task module is completed.

[0094] Regarding the data clearing process for the target task module, if the target task module corresponds to a second type of marker (the second type of marker is used to indicate that displayed data needs to be deleted), that is, if the first type of marker is modified to the second type of marker, it means that the external debugger process needs to clear the data of the target task module. Based on this, the debugger service process sends the unique identifier of the target task module to the external debugger process, and the external debugger process deletes the displayed data corresponding to the target task module based on the unique identifier of the target task module.

[0095] For example, if the target task module corresponds to a second type of marker, then it is determined whether a debugger service process has been created; if so, the unique identifier of the target task module is sent to the debugger service process through the target task module, and the unique identifier of the target task module is sent to the external debugger process through the debugger service process; if not, the target task module does not send the unique identifier of the target task module to the debugger service process.

[0096] For example, for a target task module that needs to delete data, a second type of marker can be configured for that module. This could be achieved by pre-embedding an annotation method (slice method, with this annotation method serving as the second type of marker) in the corresponding interface of the target task module. When the interface of the target task module is called, this annotation method (slice method) will be executed. During the execution of this annotation method (slice method), the target task module checks whether a debugger service process has already been created. If so, it sends its unique identifier to the debugger service process; otherwise, it does not.

[0097] See Figure 5DThe diagram illustrates the data clearing operation performed on the plug-in debugger process. When a scheme switch is required (i.e., the target task module becomes invalid), the target task module is triggered to execute the slice method. Deleting a module (target task module) also triggers the target task module to execute the slice method.

[0098] For the slicing method, the target task module checks if the debugger service instance (debugger service process) exists. If it does, it invokes the clearing process. The debugger service process can send a clearing signal to the external debugger process, which can include the unique identifier of the target task module. After receiving the clearing signal, the external debugger process clears the rendered data based on the unique identifier of the target task module, that is, clears all data corresponding to the target task module, thereby performing a data clearing operation on the external debugger process.

[0099] For the data clearing process of the target task module, if the preceding task module of the target task module has a second type of marker (the second type of marker is used to indicate that the displayed data needs to be deleted), the debugger service process sends the unique identifier of the target task module to the external debugger process, and the external debugger process deletes the displayed data corresponding to the target task module based on the unique identifier of the target task module.

[0100] For example, when it is necessary to delete the preceding task module of the target task module, if it is determined that the target task module exists in the sub-task module of the preceding task module (i.e. the task module located after the preceding task module in the task flowchart), a second type of marker can be configured for the preceding task module, such as pre-embedding the annotation method (slice method, which is used as the second type of marker) in the interface corresponding to the preceding task module.

[0101] In one possible implementation, when a user encounters an anomaly during code debugging, they need to trace back to identify the problematic step. The user rolls back to a breakpoint in the IDE and executes the code again. Assuming the current rollback breakpoint corresponds to target task module A, if the debugger service process finds that target task module A differs from the target task module B already recorded by the debugger service process, it sends the data to be displayed corresponding to target task module A (such as the output image and graphics data of the preceding task module, information about target task module A, etc.) to the external debugger process.

[0102] When the external debugger process detects a change in a module, it clears the rendering data of target task module B and displays the corresponding data to be displayed for target task module A in real time. This allows users to revert to any breakpoint within the IDE for real-time reverse debugging to troubleshoot problems.

[0103] In summary, regarding step 201, when generating a task flowchart based on the program to be developed, when the program to be developed is debugged to the first breakpoint, in the interrupted state of the first breakpoint, the task flowchart can be generated based on the first program execution code in the program to be developed. The first program execution code can be the program execution code located before the first breakpoint. Alternatively, when the program to be developed is debugged to the first breakpoint, in the interrupted state of the first breakpoint, it can also roll back to the second breakpoint located before the first breakpoint. The second breakpoint can be any breakpoint location before the first breakpoint, used for real-time reverse debugging to troubleshoot problems. In this way, in the interrupted state of the second breakpoint, the task flowchart can be generated based on the second program execution code in the program to be developed. The second program execution code can be the program execution code located before the second breakpoint.

[0104] For example, see Figure 6 The diagram illustrates the reverse debugging process. When debugging project code, during process execution, the graphical representations of module A and module B can be obtained, and breakpoints can be set. If a breakpoint rollback is performed at the breakpoint location, i.e., rollback to the process of obtaining the module A graphical representation, the code will be executed after the rollback, triggering the debugger service process and the external debugger process for subsequent processing.

[0105] For the debugger service process, the target task module (i.e., module A, which serves as the target task module) and the number of executions can be recorded. If a change in the module or the number of executions is detected, the output image of the preceding module (as the background image) is obtained, and data (i.e., the data to be displayed corresponding to the target task module) is sent. For example, the debugger service process can transmit data to the external debugger process through inter-process communication.

[0106] For the external debugger process, after obtaining the data, check whether the module or execution count has changed. If the module or execution count has changed, clear the current rendering data and graphics list, update the current executing module and count, render the new data (i.e. the data to be displayed corresponding to module A), and record the new graphics list.

[0107] As can be seen from the above technical solutions, this application provides a mechanism for a real-time plug-in debugger. Through the plug-in debugger, users can directly write debugging code in the code editor. When debugging is interrupted, the plug-in debugger can render the user's debugging results in real time, making it more convenient for users. A visual debugging mechanism supporting reverse lookup is also provided. Through the plug-in debugger, the graphical and image results obtained by the user during debugging can be rendered in real time, and users can switch graphical displays. The plug-in debugger can respond in real time to any user's rollback interruption operation and can render the module results executed after the user changes the breakpoint position, improving the efficiency of troubleshooting. By designing an implementation mechanism for a plug-in debugger, when debugging code in the integrated development environment, the single-step or multi-step debugging execution results (data to be displayed) can be automatically sent to the visual debugger process for display via inter-process communication. The visual debugger process is not blocked by breakpoint interruptions and can respond and refresh the debugging execution results in real time.

[0108] Based on the same concept as the method described above, this application proposes a debugging device, see [link to relevant documentation]. Figure 7 The diagram shown is a structural schematic of the debugging device, which may include: Processing module 71 is used to generate a task flowchart based on the program to be developed, the task flowchart including multiple task modules; and to obtain the task execution result of the task flowchart by executing the multiple task modules, the task execution result being used for debugging the program to be developed; acquisition module 72 is used to acquire the data to be displayed corresponding to the target task module through the created debugger service process, and to send the data to be displayed to the created visual debugger process through the debugger service process; wherein, the target task module is the task module among the multiple task modules that needs to display data, and the data to be displayed is the data acquired by the target task module during task execution; display module 73 is used to display data based on the data to be displayed through the visual debugger process.

[0109] For example, the processing module 71 is further configured to, if a debugger open command is received for the program to be developed, create a debugger service process and a visual debugger process corresponding to the program to be developed; the acquisition module 72, when acquiring the data to be displayed corresponding to the target task module through the created debugger service process, is specifically configured to: during the task execution of the target task module, if the target task module acquires the data to be displayed, determine whether the debugger service process has been created; if so, acquire the data to be displayed corresponding to the target task module through the debugger service process; wherein, for any task module in the task flowchart, if the task module has a first type of marker for indicating that data needs to be displayed, then the task module is the target task module.

[0110] For example, the acquisition module 72 is further configured to send the target execution count corresponding to the target task module to the visual debugger process through the debugger service process; wherein, after each execution of all task modules of the task flowchart, the target execution count corresponding to the target task module is added to a preset value; when the display module 73 displays data based on the data to be displayed through the visual debugger process, it is specifically configured to: determine whether the execution count corresponding to the stored historical data is the same as the target execution count; if so, display data based on the historical data and the data to be displayed; if not, delete the historical data and display data based on the data to be displayed.

[0111] For example, when the display module 73 displays data based on the historical data and the data to be displayed, it is specifically used for: if the data to be displayed is an image to be displayed and the historical data is a historical image, then the image to be displayed is displayed in the rendering area; or, performing a fusion operation on the image to be displayed and the historical image to obtain a fused image, and displaying the fused image in the rendering area; if the data to be displayed is a graphic to be displayed and the historical data is a historical graphic, then displaying a background image in the rendering area, and superimposing the graphic to be displayed on the background image; or, displaying a background image in the rendering area, and superimposing the graphic to be displayed and the historical graphic on the background image; wherein, the background image is the output image of the preceding task module of the target task module, and the output image is the image obtained by the preceding task module after the task is completed.

[0112] For example, the processing module 71 is further configured to destroy the debugger service process if an exit event of the visual debugger process is detected; or, if the first type of marker corresponding to the target task module is modified to a second type of marker, the second type of marker being used to indicate that displayed data needs to be deleted, or the preceding task module of the target task module has a second type of marker, then the unique identifier of the target task module is sent to the visual debugger process through the debugger service process, and the visual debugger process deletes the displayed data corresponding to the target task module based on the unique identifier.

[0113] For example, if the program to be developed includes at least one breakpoint, the processing module 71, when generating a task flowchart based on the program to be developed, specifically performs the following: when the program to be developed is debugged to the first breakpoint, under the interrupted state of the first breakpoint, generates the task flowchart based on the first program execution code in the program to be developed; or, when the program to be developed is debugged to the first breakpoint, under the interrupted state of the first breakpoint, rolls back to the second breakpoint before the first breakpoint, and under the interrupted state of the second breakpoint, generates the task flowchart based on the second program execution code in the program to be developed; wherein, the first program execution code is the program execution code located before the first breakpoint; and the second program execution code is the program execution code located before the second breakpoint.

[0114] For example, the program to be developed includes a machine vision program to be developed, the task flowchart includes a machine vision task flowchart, and each task module includes an operator module; when each operator module is executed, machine vision task processing is performed by calling the operation file corresponding to the operator module; or, when each operator module is executed, machine vision task processing is performed by calling the network model corresponding to the operator module.

[0115] Based on the same concept as the above method, this application proposes an electronic device, see [link to previous application]. Figure 8 As shown, the electronic device includes a processor 81 and a machine-readable storage medium 82, the machine-readable storage medium 82 storing machine-executable instructions that can be executed by the processor 81; the processor 81 is used to execute the machine-executable instructions to implement the debugging method disclosed in the above example of this application.

[0116] Based on the same concept as the above method, this application also provides a machine-readable storage medium storing a plurality of computer instructions, which, when executed by a processor, can implement the debugging method disclosed in the above examples of this application.

[0117] The aforementioned machine-readable storage medium can be any electronic, magnetic, optical, or other physical storage device that can contain or store information, such as executable instructions, data, etc. For example, machine-readable storage media can be: RAM (Random Access Memory), volatile memory, non-volatile memory, flash memory, storage drives (such as hard disk drives), solid-state drives, any type of storage disk (such as optical discs, DVDs, etc.), or similar storage media, or combinations thereof.

[0118] Based on the same concept as the methods described above, this application also provides a computer program product, which may include a computer program. When executed by a processor, the computer program implements the debugging method disclosed in the examples above.

[0119] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0120] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A debugging method, characterized in that, The method includes: A task flowchart is generated based on the program to be developed. The task flowchart includes multiple task modules. The task execution result of the task flowchart is obtained by executing the multiple task modules. The task execution result is used to debug the program to be developed. The data to be displayed corresponding to the target task module is obtained through the created debugger service process; wherein, the target task module is the task module that needs to display data among the multiple task modules, and the data to be displayed is the data obtained by the target task module during task execution; The debugger service process sends the data to be displayed to the created visual debugger process, and the visual debugger process displays the data based on the data to be displayed.

2. The method according to claim 1, characterized in that, Before obtaining the data to be displayed corresponding to the target task module through the already created debugger service process, the method further includes: if a debugger open command is received for the program to be developed, then a debugger service process and a visual debugger process corresponding to the program to be developed are created. The step of obtaining the data to be displayed corresponding to the target task module through the created debugger service process includes: during the task execution of the target task module, if the target task module obtains the data to be displayed, then determining whether the debugger service process has been created; if so, obtaining the data to be displayed corresponding to the target task module through the debugger service process. Specifically, for any task module in the task flowchart, if the task module corresponds to a first type of marker used to indicate that data needs to be displayed, then the task module is designated as the target task module.

3. The method according to claim 1, characterized in that, Before the visualization debugger process displays the data based on the data to be displayed, the method further includes: sending the target execution count corresponding to the target task module to the visualization debugger process through the debugger service process; wherein, after each execution of all task modules of the task flowchart, the target execution count corresponding to the target task module is added to a preset value; The visualization debugger process displays data based on the data to be displayed, including: Determine whether the number of executions corresponding to the stored historical data is the same as the target number of executions; If so, the data will be displayed based on the historical data and the data to be displayed; If not, delete the historical data and display the data based on the data to be displayed.

4. The method according to claim 3, characterized in that, The data display based on the historical data and the data to be displayed includes: If the data to be displayed is an image to be displayed and the historical data is a historical image, then the image to be displayed is displayed in the rendering area; or, the image to be displayed and the historical image are merged to obtain a merged image, and the merged image is displayed in the rendering area. If the data to be displayed is a graphic to be displayed, and the historical data is a historical graphic, then a background image is displayed in the rendering area, and the graphic to be displayed is superimposed on the background image; or, a background image is displayed in the rendering area, and the graphic to be displayed and the historical graphic are superimposed on the background image; wherein, the background image is the output image of the preceding task module of the target task module, and the output image is the image obtained by the preceding task module after the task is completed.

5. The method according to claim 2, characterized in that, After the visualization debugger process displays the data based on the data to be displayed, the method further includes: If an exit event of the visual debugger process is detected, the debugger service process is destroyed. Alternatively, if the first type of marker corresponding to the target task module is modified to a second type of marker, and the second type of marker is used to indicate that the displayed data needs to be deleted, or if the preceding task module of the target task module has a second type of marker, then the unique identifier of the target task module is sent to the visual debugger process through the debugger service process, and the displayed data corresponding to the target task module is deleted by the visual debugger process based on the unique identifier of the target task module.

6. The method according to any one of claims 1-5, characterized in that, If the program to be developed includes at least one breakpoint, the step of generating a task flowchart based on the program to be developed includes: When the program to be developed is debugged to the first breakpoint, under the interrupted state of the first breakpoint, the task flowchart is generated based on the first program execution code in the program to be developed; or... When the program to be developed is debugged to the first breakpoint, in the interrupted state of the first breakpoint, it rolls back to the second breakpoint before the first breakpoint. In the interrupted state of the second breakpoint, the task flowchart is generated based on the second program execution code in the program to be developed. Wherein, the first program execution code is the program execution code located before the first breakpoint; The second program execution code is the program execution code located before the second breakpoint.

7. The method according to any one of claims 1-5, characterized in that, The program to be developed includes a machine vision program to be developed, the task flowchart includes a machine vision task flowchart, and each task module includes an operator module; wherein, when each operator module is executed, machine vision task processing is performed by calling the operation file corresponding to the operator module; or, when each operator module is executed, machine vision task processing is performed by calling the network model corresponding to the operator module.

8. A debugging device, characterized in that, The device includes: The processing module is used to generate a task flowchart based on the program to be developed, the task flowchart including multiple task modules; and to obtain the task execution result of the task flowchart by executing the multiple task modules, the task execution result being used for debugging the program to be developed. The acquisition module is used to acquire the data to be displayed corresponding to the target task module through the created debugger service process, and send the data to be displayed to the created visual debugger process through the debugger service process; wherein, the target task module is the task module that needs to display data among the multiple task modules, and the data to be displayed is the data acquired by the target task module during task execution; The display module is used to display data based on the data to be displayed through a visual debugger process.

9. The apparatus according to claim 8, characterized in that, The processing module is further configured to, if it receives a debugger open command for the program to be developed, create a debugger service process and a visual debugger process corresponding to the program to be developed. When the acquisition module acquires the data to be displayed corresponding to the target task module through the created debugger service process, it is specifically used to: during the task execution of the target task module, if the target task module acquires the data to be displayed, determine whether the debugger service process has been created; if so, acquire the data to be displayed corresponding to the target task module through the debugger service process. Specifically, for any task module in the task flowchart, if the task module corresponds to a first type of marker used to indicate that data needs to be displayed, then the task module is designated as the target task module. Alternatively, the acquisition module is further configured to send the target execution count corresponding to the target task module to the visual debugger process through the debugger service process; wherein, after each execution of all task modules of the task flowchart, the target execution count corresponding to the target task module is added to a preset value; when the display module displays data based on the data to be displayed through the visual debugger process, it is specifically configured to: determine whether the execution count corresponding to the stored historical data is the same as the target execution count; if so, display data based on the historical data and the data to be displayed; if not, delete the historical data and display data based on the data to be displayed; Alternatively, when the display module displays data based on the historical data and the data to be displayed, it is specifically used for: if the data to be displayed is an image to be displayed and the historical data is a historical image, then displaying the image to be displayed in the rendering area; or, performing a fusion operation on the image to be displayed and the historical image to obtain a fused image, and displaying the fused image in the rendering area; if the data to be displayed is a graphic to be displayed and the historical data is a historical graphic, then displaying a background image in the rendering area, and superimposing the graphic to be displayed on the background image; or, displaying a background image in the rendering area, and superimposing the graphic to be displayed and the historical graphic on the background image; wherein, the background image is the output image of the preceding task module of the target task module, and the output image is the image obtained by the preceding task module after the task execution is completed; Alternatively, the processing module is further configured to destroy the debugger service process if an exit event of the visual debugger process is detected; or, if the first type of marker corresponding to the target task module is modified to a second type of marker, the second type of marker being used to indicate that displayed data needs to be deleted, or the preceding task module of the target task module has a second type of marker, then the debugger service process sends the unique identifier of the target task module to the visual debugger process, and the visual debugger process deletes the displayed data corresponding to the target task module based on the unique identifier; Alternatively, if the program to be developed includes at least one breakpoint, the processing module, when generating a task flowchart based on the program to be developed, specifically performs the following: when the program to be developed is debugged to the first breakpoint, under the interrupted state of the first breakpoint, generates the task flowchart based on the first program execution code in the program to be developed; or, when the program to be developed is debugged to the first breakpoint, under the interrupted state of the first breakpoint, rolls back to the second breakpoint preceding the first breakpoint, and under the interrupted state of the second breakpoint, generates the task flowchart based on the second program execution code in the program to be developed; wherein, the first program execution code is the program execution code located before the first breakpoint; and the second program execution code is the program execution code located before the second breakpoint. Alternatively, the program to be developed includes a machine vision program to be developed, the task flowchart includes a machine vision task flowchart, and each task module includes an operator module; wherein, when each operator module is executed, machine vision task processing is performed by calling the operation file corresponding to the operator module; or, when each operator module is executed, machine vision task processing is performed by calling the network model corresponding to the operator module.

10. An electronic device, characterized in that, include: A processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; The processor is configured to execute machine-executable instructions to implement the method of any one of claims 1-7.

Images