Method and apparatus for visual debugging, and device

Abstract

Provided in the present disclosure are a method and apparatus for visual debugging, and a computing device, a computer-readable storage medium and a computer program product. The method comprises: on the basis of a code in an integrated development environment, generating a domain-specific language file associated with at least one graph in the code, wherein each graph represents a workflow in the code; on the basis of the domain-specific language file, acquiring node information and edge information of a graph corresponding to a workflow to be debugged; and on the basis of the node information and the edge information, generating a visual graphical representation of the graph.

Description

Method, device and apparatus for visual debugging TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computer, and more particularly, to a method, device, computing device, computer readable storage medium and computer program product for visual debugging. BACKGROUND

[0002] In the process of developing an application based on a generative model (e.g., a large language model LLM), a graph is usually used to represent a workflow in the application, also known as an execution link. When debugging code in an integrated development environment (IDE), a traditional method verifies the correctness of the execution link in the application by writing a special test function. As the model complexity increases and the arrangement of the execution link in the code becomes increasingly sophisticated, this method gradually reveals its limitations. Especially when the arranged execution link becomes extremely complex, the problem becomes particularly prominent.

[0003] SUMMARY

[0004] In view of this, the present disclosure provides a method, device, computing device, computer readable storage medium and computer program product for visual debugging, which can determine a domain-specific language file associated with a graph corresponding to a workflow to be debugged based on the workflow, obtain node information and edge information of the graph, and generate a visual graphical representation of the graph, so as to intuitively express the arranged execution link and improve the debugging efficiency.

[0005] According to a first aspect of the present disclosure, a method for visual debugging is provided, comprising: generating a domain-specific language file associated with at least one graph in code in an integrated development environment based on the code, each graph representing a workflow in the code; obtaining node information and edge information of a graph corresponding to a workflow to be debugged based on the domain-specific language file; and generating a visual graphical representation of the graph based on the node information and the edge information.

[0006] According to a second aspect of the present disclosure, a device for visual debugging is provided, comprising: a file generation unit configured to generate a domain-specific language file associated with at least one graph in code in an integrated development environment based on the code, each graph representing a workflow in the code; a graph information obtaining unit configured to obtain node information and edge information of a graph corresponding to a workflow to be debugged based on the domain-specific language file; and a visualization implementation unit configured to generate a visual graphical representation of the graph based on the node information and the edge information.

[0007] According to a third aspect of the disclosure, there is provided a computing device comprising: at least one processing unit; at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, causing the computing device to perform the method as described in the first aspect of the disclosure.

[0008] According to a fourth aspect of the disclosure, there is provided a non-transitory computer storage medium comprising machine executable instructions that, when executed by a device, cause the device to perform the method as described in the first aspect of the disclosure.

[0009] According to a fifth aspect of the disclosure, there is provided a computer program product comprising machine executable instructions that, when executed by a device, cause the device to perform the method as described in the first aspect of the disclosure.

[0010] It is to be understood that the Summary is not intended to identify key or essential features of embodiments of the disclosure, nor is it intended to be used to limit the scope of the disclosure. Other features, details, and advantages of the disclosure will become BRIEF DESCRIPTION OF DRAWINGS

[0011] The above and other objects, features and advantages of embodiments of the disclosure will become more readily understood from the following detailed description, taken in conjunction with the accompanying drawings, in which:

[0012] FIG. 1 illustrates a schematic diagram of an example environment in which embodiments of the disclosure can be implemented, according to an embodiment of the disclosure;

[0013] FIG. 2 illustrates a schematic diagram of a visualized graphical representation of code, according to an embodiment of the disclosure;

[0014] FIG. 3 illustrates a schematic flow diagram of a method of visualizing debugging, according to an embodiment of the disclosure;

[0015] FIG. 4 illustrates a schematic flow diagram of generating a domain specific language file, according to an embodiment of the disclosure;

[0016] FIG. 5 illustrates a schematic flow diagram of determining execution links and node information, according to an embodiment of the disclosure;

[0017] FIG. 6 illustrates a schematic diagram of visualized execution links and node information, according to an embodiment of the disclosure;

[0018] FIG. 7A illustrates a schematic diagram of setting a breakpoint node, according to an embodiment of the disclosure;

[0019] FIG. 7B shows a schematic diagram of suspending a debugging process at a breakpoint node according to an embodiment of the present disclosure;

[0020] FIG. 7C shows a schematic diagram of continuing a debugging process from a breakpoint node according to an embodiment of the present disclosure;

[0021] FIG. 8 shows a block diagram of an apparatus for visualizing debugging according to an embodiment of the present disclosure; and

[0022] FIG. 9 shows a block diagram of an electronic device according to an embodiment of the present disclosure.

[0023] In all the drawings, the same or similar reference numerals indicate the same or similar elements. DETAILED DESCRIPTION

[0024] Embodiments of the present disclosure will be described in more detail with reference to the drawings. Although certain embodiments of the present disclosure are shown in the drawings, it is understood that the present disclosure can be embodied in various forms and should not be interpreted as being limited to the embodiments set forth herein, but rather the embodiments are provided so that the present disclosure can be more thoroughly and completely understood. It is understood that the drawings and embodiments of the present disclosure are for exemplary purposes only and are not intended to limit the scope of protection of the present disclosure.

[0025] In the description of embodiments of the present disclosure, the term "comprising" and its conjugations should be understood to encompass the meanings of "consisting of" and "consisting essentially of". The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "an embodiment" should be understood as "at least one embodiment". The terms "first", "second", and the like can refer to different or identical objects unless otherwise specified. Other explicit and implicit definitions can also be included below.

[0026] As described above, when the execution link of orchestration becomes extremely complex, the traditional testing method cannot intuitively express the execution link of orchestration, and when there are many branch links of the graph, the developer cannot quickly debug each branch and node, resulting in low debugging efficiency.

[0027] To solve or alleviate the above problems and / or other potential problems, embodiments of the present disclosure propose a method for visualizing debugging. The method determines a domain-specific language file associated with a graph corresponding to a workflow to be debugged based on the workflow to obtain node information and edge information of the graph, and generates a visual graphical representation of the graph, so as to intuitively express the execution link of orchestration and improve the debugging efficiency.

[0028] The basic principles and implementations of the present disclosure are explained hereinafter with reference to the accompanying drawings. It should be understood that the exemplary embodiments are given for the purpose of better illustrating the embodiments of the present disclosure to those skilled in the art, and are not intended to limit the scope of the present disclosure in any way.

[0029] FIG. 1 shows a schematic diagram of an environment 100 capable of implementing multiple embodiments of the present disclosure. As shown in FIG. 1, the environment 100 can include an integrated development environment 101. The integrated development environment 101 is an application program that integrates multiple basic functions of software development, such as code editing, compiling, debugging, etc., aiming to make the entire development process from code writing to software building and testing more smooth and coherent by integrating various development tools (e.g., functional plug-ins, etc.). As shown in FIG. 1, the integrated development environment 101 can include code 102. The code 102 can be organized in the form of source code files according to the directory structure of a project and stored in the integrated development environment 101.

[0030] As shown in FIG. 1, the code 102 can include a graph 103. In the integrated development environment, the graph can be used to represent the dependency relationship, calling relationship or data flow relationship between codes, etc., to help developers understand and analyze the structure, dependency relationship and potential errors or performance bottlenecks of the code. It should be understood that the present disclosure does not limit the number of graphs in the integrated development environment 101.

[0031] The code relationship represented by the above graph can be abstracted as nodes and edges in a graph structure. The node can represent any entity or object (e.g., class, function, variable, module, component, etc.) that performs several logics, which can include basic attributes such as node name, node type, node input parameter declaration and node output parameter declaration. The edge is a data structure (e.g., adjacency matrix, adjacency list, etc.) connecting two nodes in the graph, which represents the relationship or interaction of data flow transfer and execution order between the nodes in the graph, and can include basic attributes such as edge type, start node name and end node name.

[0032] In some embodiments, the graph 103 can include several nodes and edges. As shown in FIG. 1, the graph 103 can include nodes 1-4 and edges 1-3, which can represent components performing several logics, and edges 1-3 can represent the relationship of data flow transfer and execution order between nodes 1-4. It should be understood that the present disclosure does not limit the number of nodes and edges in the graph 103, and one node can belong to different graph structures. According to the node information and edge information in the graph 103, a corresponding visual graph representation can be generated. The exemplary visual graph representation of the graph is further described below with reference to FIG. 2.

[0033] FIG. 2 shows a schematic diagram of a visualized graphical representation 200 of code according to an embodiment of the present disclosure. In some embodiments, a graph in the code can be visualized as a topology graph 200 as shown in FIG. 2. In some embodiments, the topology graph 200 can be presented in the form of a canvas in the code interface, and can support user operations such as zooming in, zooming out, etc. Optionally, the topology graph 200 can also support dragging in any direction to facilitate user viewing of information in the topology graph 200.

[0034] As shown in FIG. 2, the topology graph 200 can include nodes 210-1, 210-2, 210-3, 210-4, 210-5, 210-6, 210-7, and 210-8 (collectively referred to as nodes 210), and edges 220-1 and 220-2 (collectively referred to as edges 220). Among them, each node 210 in the topology graph 200 can be abstracted as a text box form, and includes node name, node type, input parameter, and output parameter, etc. information. Each edge 220 in the topology graph 200 can be abstracted into different forms according to its type, for example, a directed line as shown in FIG. 2 representing sequential execution between two nodes, a parallel relationship 220-1, or a branching relationship 220-2, to represent the workflow relationship between the nodes 210. In this way, through the visualized topology graph, the user can intuitively and clearly observe the workflow of the code, and then debug the corresponding code in the integrated development environment.

[0035] The process of implementing visualized debugging based on node information and edge information is further described below with reference to FIG. 3. FIG. 3 shows a schematic flowchart of a method 300 of visualized debugging according to an embodiment of the present disclosure. In some embodiments, the method 300 can be implemented by a functional plug-in in the integrated development environment 101, for example, as shown in FIG. 1. It should be understood that the method 300 can also include additional actions not shown and / or can omit the actions shown, and the scope of the present disclosure is not limited in this regard.

[0036] As shown in FIG. 3, at block 310, the method 300 can include generating, based on code in an integrated development environment, a domain-specific language file associated with at least one graph in the code, each graph representing a workflow in the code. A domain-specific language (DSL) file refers to a file written using a domain-specific language. A DSL is a language designed for a specific domain, which focuses on solving specific problems within that domain and provides syntax and semantics closely related to that domain. A DSL file usually contains code, declarations, rules, or configurations written using that DSL. These files can be processed by specific tools, compilers, or interpreters to generate code, perform calculations, verify rules, or configure systems, etc. The process of generating a DSL file is further described below with reference to FIG. 4.

[0037] FIG. 4 illustrates a schematic flowchart 400 of generating a domain-specific language file according to an embodiment of the present disclosure. As shown in FIG. 4, in some embodiments, the code in the integrated development environment 101 can include generative framework code 402. The IDE plug-in 401 can first start an application process to generate the generative model framework code 402 at step 403, and then collect node information and edge information of at least one graph in the runtime state of the code at step 404. At step 405, the IDE plug-in 401 can convert the node information and edge information according to a pre-defined structure protocol to generate a corresponding DSL file 406, and store in the developer's development environment (such as the integrated development environment 101). The DSL file 406 can be in the form as follows:

[0038] Wherein, each attribute of the node is interpreted as follows:

[0039] Table 1

[0040] Each attribute of the edge is interpreted as follows:

[0041] Table 2

[0042] Returning to FIG. 3, at block 320, the method 300 can include obtaining node information and edge information of a graph corresponding to the workflow to be debugged based on the domain-specific language file. In some embodiments, the IDE plug-in 401 can, in response to one of the at least one graph being selected, find the DSL file associated with the selected graph stored in the development environment, and then obtain the node information and edge information of the graph by parsing the determined DSL file.

[0043] The method 300 can include, at block 330, generating a visual graphical representation of the graph based on the node information and edge information. Alternatively, the IDE plug-in 401 can generate a topology graph as shown in FIG. 2 using the node information and edge information extracted from the DSL file to clearly express the workflow link.

[0044] In some embodiments, the IDE plug-in 401 can obtain a debug log associated with the debugging process of the code, and then determine execution link information and corresponding node information of the debugging process by parsing the debug log. In some embodiments, the IDE plug-in 401 can also determine the execution start time and the execution end time of each node, and then sort the nodes based on the order of the execution start time from small to large to determine the execution link information, and determine the execution time consumption of each node based on the execution start time and the execution end time of each node. The process of determining the execution link and node information is further described below with reference to FIG. 5.

[0045] FIG. 5 shows an illustrative flowchart 500 of determining execution link and node information according to embodiments of the present disclosure. As shown in FIG. 5, the flow 500 can include a debugging process 510 and an IDE plugin 520. At step 512, the debugging process 510 can perform generative model internal log collection by, for example, a method of instrumenting, to obtain a debugging log 513. The debugging log 513 can include node name, node type, node start execution time, node end execution time, input data, output data, and execution status of the node, etc. Then, the debugging process 510 can structure the internal running details recorded during debugging based on a structure protocol 511, and store them in a memory storage 514 of the debugging process.

[0046] The WebSocket protocol is a protocol for full-duplex communication over a single TCP connection. It makes data exchange between the client and the server much simpler, allowing the server to actively push data to the client. In some embodiments, at step 521, the IDE plugin 520 can obtain the debugging log in the debugging process 510 in real time through the WebSocket protocol. The IDE plugin 520 needs to first establish a WebSocket connection with the debugging process 510. For example, by writing code in the IDE plugin 520 to create a WebSocket client, and specifying the WebSocket service address and port provided by the debugging process 510. Then, the IDE plugin 520 can send debugging requests to the debugging process 510, such as starting debugging, pausing debugging, viewing variable values, etc. These requests are sent to the debugging process 510 in the form of messages through the WebSocket protocol. After receiving the debugging request, the debugging process 510 will perform the corresponding debugging operation, and send the debugging log to the IDE plugin 520 in the form of messages through the WebSocket connection.

[0047] At step 522, the IDE plugin 520 can parse the debugging log to refresh the execution link and node information. Among them, the IDE plugin 520 can obtain the execution start time and end time of the node from the debugging log, then according to the execution start time of the node, show the execution order of the node in the order from small to large, and can show the execution time of the node by subtracting the execution start time from the end execution time.

[0048] FIG. 6 shows a diagram 600 of visualized execution link and node information, according to an embodiment of the present disclosure. As shown in FIG. 6, the overall link can include execution order 601 and node information 602, and is presented in the order of execution of the nodes. The node information 602 can include node name, input information, output information, used generative model name, and time consumption 603. In some embodiments, the node information 602 can also include a toggle button to facilitate the user to view the input information and output information of an individual node.

[0049] In some embodiments, the IDE plug-in can also determine at least one breakpoint node on the visualized graphical representation, and then execute the debugging process by setting a first breakpoint node among the at least one breakpoint node as an end node. FIG. 7A shows a diagram 700A of setting a breakpoint node, according to an embodiment of the present disclosure. As shown in FIG. 7A, the overall link can include nodes 701, 702, and 703 that are executed sequentially. The developer can mark the node 702 with a breakpoint 704 to determine the node 702 as a breakpoint node. If the debugging process is executed from node 1 at this time, the debugging process will be aborted when executing to node 2 sequentially. In some embodiments, the IDE plug-in can also determine a second breakpoint node on the visualized graphical representation, and then continue the debugging process by setting the first breakpoint node as a start node and the second breakpoint node as an end node.

[0050] FIG. 7B shows a diagram 700B of aborting the debugging process at the breakpoint node, according to an embodiment of the present disclosure. As shown in FIG. 7B, the debugging program can be aborted after executing the node 702 and display the next node to be executed, to wait for further instructions from the developer. In some embodiments, the developer can click on an edit button 705 to modify the input of the breakpoint node, or modify the output of the breakpoint node, and then click on a continue button 706 to continue the debugging process.

[0051] FIG. 7C shows a diagram 700C of continuing the debugging process from the breakpoint node, according to an embodiment of the present disclosure. As shown in FIG. 7C, the developer aborted the debugging process at node 2 and modified the output data at node 2, and then continued the debugging process and entered node 3. Since the output of node 2 as the input of node 3 has been modified, the output data of node 3 has also changed. In this way, the developer can be allowed to directly modify the test case in the visualized link, without having to write a unit test case every time to debug the program, thereby improving the debugging efficiency.

[0052] The exemplary embodiments of the present disclosure are described above with reference to FIGS. 1-7C. Compared with the existing debugging method, the visual debugging scheme of the present disclosure determines a domain-specific language file associated with a graph corresponding to a workflow to be debugged in advance based on the workflow, acquires node information and edge information of the graph, and generates a visual graphical representation of the graph, so as to intuitively express the execution link of the orchestration and improve the debugging efficiency.

[0053] FIG. 8 shows a schematic block diagram of an apparatus 800 for visual debugging according to an embodiment of the present disclosure. As shown in FIG. 8, the apparatus 800 includes a file generation unit 810, a graph information acquisition unit 820, and a visualization implementation unit 830.

[0054] In some embodiments, the file generation unit 810 is configured to generate, based on code in an integrated development environment, a domain-specific language file associated with at least one graph in the code, each graph representing a workflow in the code; the graph information acquisition unit 820 is configured to acquire, based on the domain-specific language file, node information and edge information of a graph corresponding to a workflow to be debugged; and the visualization implementation unit 830 is configured to generate, based on the node information and the edge information, a visual graphical representation of the graph.

[0055] In some embodiments, the file generation unit 810 is further configured to start an application process of the code; acquire, in a runtime state of the code, node information and edge information of the at least one graph; and generate the domain-specific language file based on the acquired node information and edge information.

[0056] In some embodiments, the graph information acquisition unit 820 is further configured to, in response to one of the at least one graph being selected, determine a domain-specific language file associated with the selected graph; and acquire, by parsing the determined domain-specific language file, the node information and the edge information of the graph.

[0057] In some embodiments, the apparatus 800 further includes an execution link information determination unit configured to acquire a debugging log associated with a debugging process of the code; and determine, by parsing the debugging log, execution link information and corresponding node information of the debugging process.

[0058] In some embodiments, the execution link information determination unit is further configured to determine an execution start time and an execution end time of each node; sort the nodes based on the execution start time in ascending order to determine the execution link information; and determine an execution duration of each node based on the execution start time and the execution end time of each node.

[0059] In some embodiments, the execution link information determining unit is further configured to determine at least one breakpoint node on the visualized graphical representation; and perform the debugging process by setting a first breakpoint node among the at least one breakpoint node as an end node.

[0060] In some embodiments, the execution link information determining unit is further configured to determine a second breakpoint node on the visualized graphical representation; and perform the debugging process by setting the first breakpoint node as a start node and the second breakpoint node as an end node.

[0061] In some embodiments, the execution link information determining unit is further configured to modify an input to the breakpoint node or modify an output of the breakpoint node.

[0062] In some embodiments, the code in the integrated development environment comprises code of a generative model application.

[0063] It is to be noted that more actions or steps shown in FIGS. 1-7C can be implemented by the apparatus 800 shown in FIG. 8. For example, the apparatus 800 can comprise more modules or units to implement the actions or steps described above, or some units or modules shown in FIG. 8 can be further configured to implement the actions or steps described above. No further elaboration is made here.

[0064] FIG. 9 shows a schematic block diagram of an example device 900 that can be used to implement embodiments of the present disclosure. As shown, the device 900 includes a computing unit 901 that can perform various appropriate actions and processes according to computer program instructions stored in a read-only memory (ROM) 902 or loaded into a random access memory (RAM) 903 from a storage unit 906. Various programs and data required for operation of the device 900 can also be stored in the RAM 903. The computing unit 901, the ROM 902, and the RAM 903 are connected to each other through a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0065] Various components in the device 900 are connected to the I / O interface 905, including: an input unit 906, such as a keyboard, a mouse, etc.; an output unit 907, such as various types of displays, a speaker, etc.; a storage unit 908, such as a magnetic disk, an optical disk, etc.; and a communication unit 909, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 909 allows the device 900 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunication networks.

[0066] The computing unit 901 can be various general and / or special purpose processing components with processing and computing capabilities. Some examples of the computing unit 901 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 901 performs various methods and processes described above, such as the method 300. For example, in some embodiments, the method 300 can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 908. In some embodiments, part or all of the computer program can be loaded and / or installed onto the device 900 via the ROM 902 and / or the communication unit 909. When the computer program is loaded onto the RAM 903 and executed by the computing unit 901, one or more steps of the method 300 described above can be performed. Alternatively, in other embodiments, the computing unit 901 can be configured to perform the method 300 by any other suitable means, such as by means of firmware.

[0067] In some embodiments, the methods and processes described above can be implemented as computer program products. Computer program products can include computer readable storage media having computer readable program instructions thereon for performing various aspects of the present disclosure.

[0068] Computer readable storage media can be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, semiconductor system, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of computer readable storage media include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or punched tape, a magnetically encoded device such as tape, an optically encoded device such as a compact disc (CD) or DVD, and / or any suitable combination of the foregoing. Computer readable program instructions can be downloaded to or from computer readable storage media 910. The computer readable program instructions can be downloaded to the device 900 from the computer readable storage media 910 and / or the device 900 can read the computer readable program instructions from the computer readable storage media 910 while the device 900 is in operation. The computer readable program instructions can be downloaded to the device 900 from the computer readable storage media 910 and / or the device 900 can read the computer readable program instructions from the computer readable storage media 910 while the device 900 is in operation.

[0069] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0070] Computer readable program instructions for carrying out operations of the present disclosure can be assembly-level instructions, instructions set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including object oriented programming languages and conventional procedural programming languages. The computer readable program instructions can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate array (FPGA), or programmable logic array (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0071] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can include a non-transitory computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions for causing an apparatus to implement one or more functions / acts specified in the flowchart and / or block diagram block or blocks is provided.

[0072] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable data processing apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0073] The flow diagrams and the block diagrams in the drawings are presented to illustrate the architecture, functionality, and operation of possible implementations of devices, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flow diagrams and the block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logic functions. In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flow diagrams, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and

[0074] Embodiments of the present disclosure have been described above, and the description is intended to be illustrative of the embodiments and not restrictive. Many modifications and variations of the described embodiments are possible and are within the scope of the disclosure. The selection of terms is intended to best describe the principles of the embodiments, practical application, or technical improvements over the technology found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for visualizing debugging, comprising: generating, based on code in an integrated development environment, domain specific language files associated with at least one graph in the code, each graph representing a workflow in the code; acquiring, based on the domain specific language files, node information and edge information of a graph corresponding to a workflow to be debugged; and generating, based on the node information and the edge information, a visual graphical representation of the graph.

2. The method of claim 1, wherein generating the domain specific language files associated with the at least one graph in the code comprises: starting an application process of the code; collecting, in a runtime state of the code, node information and edge information of the at least one graph; and generating, based on the collected node information and edge information, the domain specific language files.

3. The method of claim 1, wherein acquiring the node information and the edge information of the graph corresponding to the workflow to be debugged comprises: determining, in response to one of the at least one graph being selected, a domain specific language file associated with the selected graph; and acquiring, by parsing the determined domain specific language file, the node information and the edge information of the graph.

4. The method of any one of claims 1 to 3, wherein the method further comprises: acquiring a debugging log associated with a debugging process of the code; and determining, by parsing the debugging log, execution link information and corresponding node information of the debugging process.

5. The method of claim 4, wherein determining the execution link information and node information of the debugging process comprises: determining an execution start time and an execution end time of each node; ordering nodes based on an ascending order of the execution start time to determine the execution link information; and determining an execution duration of each node based on the execution start time and the execution end time of each node.

6. The method of claim 4, wherein the method further comprises: determining at least one breakpoint node on the visual graphical representation; and executing a debugging process by setting a first breakpoint node of the at least one breakpoint node as an end node.

7. The method of claim 6, wherein the method further comprises: determining a second breakpoint node on the visual graphical representation; and executing the debugging process by setting the first breakpoint node as a start node and the second breakpoint node as an end node.

8. The method of claim 6, wherein the method further comprises at least one of: modifying an input to the breakpoint node; or modifying an output of the breakpoint node.

9. The method of claim 1, wherein the code in the integrated development environment comprises code of a generative model application.

10. A system for visualizing debugging, comprising: a file generation unit configured to generate, based on code in an integrated development environment, domain specific language files associated with at least one graph in the code, each graph representing a workflow in the code; ​ ​ ​ ​ ​ ​ ​ a graph information obtaining unit configured to obtain node information and edge information of a graph corresponding to the workflow to be debugged based on the domain-specific language file; and a visualization implementing unit configured to generate a visual graphical representation of the graph based on the node information and the edge information.

11. A computing device comprising: at least one processing unit; at least one memory coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions, when executed by the at least one processing unit, cause the computing device to perform the method of any one of claims 1 to 9.

12. A computer storage medium comprising machine executable instructions that, when executed by a device, cause the device to perform the method of any one of claims 1 to 9.

13. A computer program product comprising machine executable instructions that, when executed by a device, cause the device to perform the method of any one of claims 1 to 9.

Images