A dynamic compilation method, device, equipment and storage medium

Abstract

The present disclosure provides a method, apparatus, device and storage medium for dynamic compilation, in the field of computer technology, particularly in the field of research and development and operation and maintenance of Internet and mobile applications. The specific implementation scheme is: using the DSL specification, parsing the source file to determine the DSL syntax tree corresponding to the source file, and obtaining a first target file; and according to the DSL syntax tree, determining the declaration type and calling order of the program object represented by each node, and then determining the loading order of the declaration type according to the declaration type and the calling order, and obtaining a second target file. Since the second target file contains the declaration types of each program object whose arrangement order is consistent with the calling order, in the process of converting the DSL product in the first target file into the executable file corresponding to the source file in the executable environment, the speed of loading the declaration type and program object can be greatly accelerated, thereby improving the efficiency of converting the DSL product into page display content in real time.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to the research and development and operation and maintenance of Internet and mobile applications. Background Art

[0002] As Flutter technology matures, online real-time update or hotfix technologies are gradually being implemented in some applications (apps), such as Flutter's dynamic compilation method based on runtime parsing of Domain Specific Language (DSL) products.

[0003] DSL is also a computer programming language with language expression capabilities. However, unlike general-purpose programming languages ​​(GPL) such as Java, C, and Python, DSL focuses on a specific field and has limited expression capabilities. For example, DSL can display HTML for web pages, SQL for database processing, regular expressions for retrieving or replacing text, and Gradle for automated builds.

[0004] Currently, the commonly used dynamic compilation method in the industry is to formulate DSL specifications based on their respective needs and dynamic parsing capabilities, and ultimately compile the Dart source code into DSL products. The runtime engine then converts the DSL products into page display content in real time. However, this process is very complex and inefficient. Summary of the Invention

[0005] The present disclosure provides a dynamic compilation method, apparatus, device, and storage medium.

[0006] According to one aspect of the present disclosure, a dynamic compilation method is provided, comprising: obtaining at least one source file; parsing each of the at least one source file using a DSL specification, determining a DSL syntax tree of the at least one source file, and obtaining at least one first target file, wherein each node in the DSL syntax tree represents a program object; determining, based on the DSL syntax tree, a declaration type and a calling order of the program objects represented by each node; and determining, based on the declaration type and the calling order, a loading order of the declared types, and obtaining a second target file.

[0007] According to another aspect of the present disclosure, a dynamic compilation apparatus is provided, comprising: a source file acquisition module for acquiring at least one source file; a first target file generation module for parsing each of the at least one source file using a DSL specification, determining a DSL syntax tree of the at least one source file, and obtaining at least one first target file, wherein each node in the DSL syntax tree represents a program object; a calling order determination module for determining, based on the DSL syntax tree, a declared type and a calling order of the program object represented by each node; and a second target file generation module for determining, based on the declared type and the calling order, a loading order of the declared types, and obtaining a second target file.

[0008] According to another aspect of the present disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so as to enable the at least one processor to execute any one of the above-mentioned dynamic compilation methods.

[0009] According to another aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to enable a computer to execute any of the above-mentioned dynamic compilation methods.

[0010] According to another aspect of the present disclosure, a computer program product is provided, including a computer program, which implements any of the above-mentioned dynamic compilation methods when executed by a processor.

[0011] The present disclosure provides a method, apparatus, device and storage medium for dynamic compilation. The method uses a DSL specification to parse a source file to determine a DSL syntax tree corresponding to the source file, thereby obtaining a first target file; and based on the DSL syntax tree, determining the declaration type and call order of the program object represented by each node, and then determining the loading order of the declaration type based on the declaration type and the call order, thereby obtaining a second target file. Since the second target file contains declaration types of each program object whose arrangement order is consistent with the call order, in the process of converting the DSL product in the first target file into an executable file corresponding to the source file in the executable environment, there is no need to calculate the loading order of each declaration type based on the first target file, but only needs to be loaded in sequence according to the arrangement order of each declaration type in the second target file, thereby greatly speeding up the speed of loading declaration types and program objects.

[0012] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present disclosure, nor are they intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The accompanying drawings are provided to facilitate a better understanding of the present invention and do not constitute a limitation of the present disclosure.

[0014] Figure 1 is a schematic diagram of a method for implementing dynamic compilation according to the first embodiment of the present disclosure;

[0015] Figure 2 is a schematic diagram of a method for implementing dynamic compilation according to the second embodiment of the present disclosure;

[0016] Figure 3 A schematic diagram of the conversion process of various data in the process of implementing the dynamic compilation method in the third embodiment of the present disclosure;

[0017] Figure 4 is a schematic diagram of a method for implementing dynamic compilation according to the third embodiment of the present disclosure;

[0018] Figure 5 Schematic diagram of the structure of the dynamic compilation device used in the first embodiment of the present disclosure;

[0019] Figure 6 It is a block diagram of an electronic device used to implement the dynamic compilation method of the embodiment of the present disclosure. DETAILED DESCRIPTION

[0020] The following description of exemplary embodiments of the present disclosure is made in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding. These details should be considered as merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0021] Figure 1 The main process of the method for implementing dynamic compilation in one embodiment of the present disclosure is shown as follows: Figure 1 As shown, the method includes:

[0022] Operation S110, obtaining at least one source file;

[0023] Among them, source files refer to files containing source code, that is, files that can be edited and modified by R&D personnel.

[0024] In the embodiments of the present disclosure, the programming language used to write the source code is not limited, and may be Java, Perl, Dart, etc.

[0025] What is obtained here is a batch of source files to be compiled, including at least one source file.

[0026] Operation S120, using the DSL specification, parsing each of the at least one source file, determining a DSL syntax tree of the at least one source file, and obtaining at least one first target file, wherein each node in the DSL syntax tree represents a program object;

[0027] The DSL specification refers to the meaning of each identifier used in the DSL, the attributes of each identifier, and the meaning of each attribute.

[0028] DSL specifications are also the standards or rules for converting source files into DSL products and converting DSL into executable files corresponding to source files in the running environment.

[0029] Typically, each program object in each source file, such as a library, method, function, variable, and attribute, corresponds to an identifier in the DSL.

[0030] When parsing source files using the DSL specification, each program object can be treated as a node with a corresponding identifier. Based on the relationships between program objects, lines are connected between the corresponding identifier nodes to form a graph structure. Since each source file belongs to, and only belongs to, a library or package, all nodes in the graph structure are subordinate to the "library" or "package" node, forming a syntax tree. This syntax tree is referred to as the DSL syntax tree in this disclosure.

[0031] The syntax tree is stored in a file in a data format that can represent the tree structure (for example, XML, Jason, etc.), thereby obtaining a first target file.

[0032] Typically, the existing solution ends here, and then the DSL parsing engine in the runtime environment parses the first target file and compiles it according to the DSL syntax tree to obtain executable files of various program objects corresponding to the source file.

[0033] When a DSL parsing engine compiles a DSL syntax tree, it typically needs to load the declaration types corresponding to each program object and determine the order in which these declaration types are loaded to ensure smooth program compilation and avoid problems finding the program object to be called during compilation. For example, if program object A calls program object B, program object B must be loaded first, followed by program object A. Otherwise, program object A will not be able to be compiled and run. The declaration type refers to the type and identifier of the program object. For example, in the Java code StingD = "hello";, "Sting D" is the declaration type of variable D.

[0034] To this end, the DSL parsing engine needs to parse the DSL syntax tree and determine the calling relationship between the program objects represented by each node in the DSL syntax tree, and determine the loading order of the declared types based on the calling relationship between the program objects.

[0035] Typically, the process of a DSL parsing engine parsing the DSL syntax tree and determining the order in which to load the program objects represented by each node in the DSL syntax tree is complex and time-consuming. Performing this process at runtime prolongs dynamic compilation time, further delaying page updates and leading to uncontrollable issues.

[0036] To this end, the dynamic compilation method disclosed in the present invention does not stop at the stage of generating only the DSL syntax tree. Instead, on this basis, it determines the loading order of the declaration types in advance according to the calling order of each program object, and arranges the declaration types according to the loading order.

[0037] Specifically, do the following:

[0038] Operation S130 , determining the declaration type and calling order of the program object represented by each node according to the DSL syntax tree;

[0039] Operation S140 : Determine the loading order of the declared types according to the declared types and the calling order, and obtain a second target file.

[0040] For example, assume the following syntax tree for program object A calling program object B:

[0041] -PackageX

[0042] --StructureA

[0043] ---String C

[0044] ---String B

[0045] Among them, Structure is the declared type of variable A, and String is the declared type of variable B.

[0046] The calling order is: X->A->C->B;

[0047] The loading order of the declared types is: StringB, StringC, StructureA and PackageX;

[0048] In this way, when the DSL parsing engine parses the DSL syntax tree in real time during runtime, it can sequentially load the declared types in the second target file according to the second target file, without having to parse the DSL syntax tree and determine the calling relationships between the program objects represented by each node in the DSL syntax tree, and determine the loading order of the declared types based on the calling relationships between the program objects.

[0049] This simplifies the operation of the DSL parsing engine to parse the DSL syntax tree in real time, greatly shortens the time it takes for the DSL parsing engine to parse the DSL syntax tree in real time during runtime, and improves the efficiency of dynamic compilation.

[0050] Figure 2 FIG. 1 shows the main process of a method for implementing dynamic compilation in another embodiment of the present disclosure. In the embodiment of the present disclosure, a word segmentation tool (eg, Analyze) and a custom DSL specification are used for dynamic compilation, such as Figure 2 As shown, before performing dynamic compilation, the embodiment of the present disclosure first performs operation S210 to define a DSL specification according to a syntax expression of the programming language used by the source file, and stores the defined DSL to obtain a customized DSL specification;

[0051] In this embodiment, the DSL specification is primarily defined by referencing established DSL specifications, traversing the syntax expressions of the programming language used in source files, and determining corresponding processing rules one by one. This ensures comprehensive coverage of the programming languages ​​used in source files and a certain degree of versatility.

[0052] Afterwards, the following operations are performed to dynamically compile the source file to obtain the first target file and the second target file:

[0053] Operation S220, obtaining at least one source file;

[0054] Operation S230 , using a word segmentation tool and a customized DSL specification, parsing each of the at least one source file, determining a DSL syntax tree for the at least one source file, and obtaining at least one first target file, wherein each node in the DSL syntax tree represents a program object;

[0055] In the embodiment of the present disclosure, since a customized DSL specification is used, a word segmentation tool is used to analyze the source file to extract the identifiers defined in the DSL specification; then, the identifiers are processed according to the processing rules defined in the DSL specification.

[0056] Operation S240 , determining the declaration type and calling order of the program object represented by each node according to the DSL syntax tree;

[0057] Operation S250, determining the loading order of the declared types according to the declared types and the calling order, and obtaining a second target file;

[0058] Afterwards, in the runtime environment, the DSL parsing engine performs the following steps:

[0059] Operation S260, sequentially loading the declared types in the second target file according to the second target file;

[0060] To enable the DSL parsing engine to sequentially load the declared types in the second target file based on the second target file, rather than calculating the loading order of the declared types, the following rule can be added to the custom DSL specification: if the second target file exists, the declared types in the second target file are loaded sequentially according to the loading order in the second target file; if the second target file does not exist, the declared types are extracted from the first target file and the loading order of each declared type is calculated. The DSL parsing engine code can also be modified to add the above logic to achieve similar functionality.

[0061] Operation S270 : updating an executable file corresponding to the at least one source file in the running environment according to the customized DSL specification and the first target file.

[0062] Because customized DSL specifications can cover more grammatical expressions and handle various situations that general DSL specifications cannot handle, dynamic compilation has a wider scope of application.

[0063] In another embodiment of the present disclosure, when defining the DSL specification, corresponding DSL specifications are customized for several widely used high-level programming languages, so that the dynamic compilation method of the present disclosure can be applied to multiple programming languages, further improving the scope of application of the dynamic compilation method of the present disclosure.

[0064] Figure 3 and Figure 4 Another embodiment of the present disclosure is shown, wherein: Figure 3 The data conversion process in the process of implementing the dynamic compilation method according to the embodiment of the present disclosure is shown; Figure 4 The operational flow of the method for implementing dynamic compilation according to an embodiment of the present disclosure is shown.

[0065] Specifically, the embodiment of the present disclosure is applied to the scenario where the flutter framework is used to update the page, wherein the page to be updated is written in Dart language. Figure 3As shown, when implementing the dynamic compilation method, the embodiment of the present disclosure first obtains a Dart source file 301. Then, a dynamic compiler 302 converts the Dart source file 301 into a json file 304 (a first target file) containing a DSL syntax tree and a totals file 305 (a second target file) containing a declared type loading order. Then, a DSL parsing engine 306 obtains an updated page 307 based on the json file 304 and the totals file 305. Both the dynamic compiler 302 and the DSL parsing engine 306 use the DSL specification 303 and perform corresponding compilation and parsing based on the DSL specification 303.

[0066] The DSL specification 303 can be a general specification or a custom specification. In the embodiment of the present disclosure, a custom DSL specification is used, and the following rules are added to the custom DSL specification to process await expressions, combination expressions of the ternary operator and await, and cascade expressions in the Dart language:

[0067] Decompose the combined expression of the ternary operator and await into an if expression through the algorithm;

[0068] Move await before the await expression statement.

[0069] In Dart, await means starting another task in parallel before one has completed. While it's defined in program code as an expression, it executes a single statement during execution. Therefore, when using a common DSL during dynamic compilation, await won't execute until the expression is complete, rendering it ineffective. The above rule resolves this issue.

[0070] Specific operation procedures, such as Figure 4 As shown, it mainly includes:

[0071] Operation S4010: Obtain the project path of the Dart source file;

[0072] Operation S4020: Determine whether the project file in the project path is a Flutter project. If so, proceed to operation S4030; if not, terminate this execution.

[0073] Operation S4030: Obtain a Dart source file;

[0074] Operation S4040 , using the DSL specification, parsing each source file in the at least one source file, and determining a DSL syntax tree for each file;

[0075] Subsequent processing is divided into two branches. The first branch is used to convert to .json file, including:

[0076] Operation S4050, determining whether the source file is part of another source file, if so, proceeding to step S4060, if not, proceeding to step S4070;

[0077] Operation S4060: Save the DSL syntax tree in a file format with a ".json" suffix.

[0078] Operation S4070: Save the DSL syntax tree in a file with a suffix of ".lb_tem".

[0079] Another branch is used to determine the loading order of the declared types and obtain the totals file, including:

[0080] Operation S4080: determining the declaration type and calling order of the program object represented by each node according to the DSL syntax tree;

[0081] Specifically, the declaration type and calling order of the program objects represented by each node can be determined through the following steps:

[0082] 1) determining node information according to the DSL syntax tree to obtain a set of node information, wherein the nodes include internal nodes and external nodes, and the node information includes an identifier and a type of the corresponding node, wherein the node type includes a class, a top-level variable, a top-level function, and an enumeration;

[0083] The identifier of the node is usually the identifier of the program object represented by the node in the DSL specification.

[0084] The type of a node is consistent with the type of the program object it represents. For example, the node type is marked according to the program object corresponding to each node in the DSL abstract syntax tree. The node type corresponding to the top variable is marked as 2; the node type of the top function (top function or top method) is marked as 1; the node type of the enumeration is marked as 0; and the node type of the class is marked as 3.

[0085] An internal node refers to a node corresponding to a program object defined in the source file; an external node refers to a node corresponding to a program object defined in other source files and referenced in the source file.

[0086] The node information of the internal node is added to the set of node information of the source file; the node information of the external node is added to the set of node information of the source file that defines the external node.

[0087] 2) determining the declared type of the program object represented by the node according to the identifier of the node;

[0088] 3) Determine the calling order of the program objects represented by each node based on the path information between each node in the DSL syntax tree.

[0089] In this process, the calling order of the program objects represented by each node can be obtained by traversing the DSL syntax tree.

[0090] Operation S4090: Determine the loading order of the declared types according to the declared types and the calling order;

[0091] For example, the order in which declared types are loaded is determined by the following steps:

[0092] 1) performing a first sorting on the set of node information from small to large according to size to obtain a first sorted set of node information;

[0093] Generally, a larger node information set indicates a more complex structure and a greater likelihood of calling other nodes. Therefore, sorting by set size increases the probability of prioritizing the called program objects, thus simplifying subsequent processing.

[0094] 2) classifying the sorted set of node information according to the declaration type to obtain a second sorted set of node information corresponding to at least one declaration type;

[0095] Categorizing by declaration type can eliminate duplication and reduce repeated calculations.

[0096] 3) Sort by the calling order, and perform a second sort on the sorted set of node information corresponding to each declaration type to obtain a second sorted set of node information:

[0097] For example, traverse the basic element list container after simple sorting, and find the index (position) of the source file root node from the stack. If the index is less than 0, it means it is not in the stack, then push the source file root node into the stack; otherwise, traverse the node information set under the source file root node.

[0098] Traverse the node information collection and search the stack for the index of each node information name. If the index is less than 0, indicating that it is not on the stack, push the node information name onto the stack. Otherwise, check whether the node type is 0. If so, compare the index of the node information with the index of the basic element. If the index of the node information is greater than the index of the basic element, insert the node information name into the stack before the basic element.

[0099] Operation S4100: record the declaration type and loading order;

[0100] In the embodiment of the present disclosure, the manifest type and loading order are recorded in a DSL static file, namely the totals file. The totals file is a type defined by the embodiment of the present disclosure, and implementers may also use files of other names or types.

[0101] Operation S4110: Determine whether there are source files to be compiled. If so, return to operation S4030 to dynamically compile the next Dart source file. If not, continue to step S4120.

[0102] Operation S4120: Merge the .lb_tem file into the .json file corresponding to the source file to which it belongs, and generate a .totals file based on the recorded declaration type and loading attributes;

[0103] In this way, the library and part DSL files, class and extension methods can be merged.

[0104] Operation S4130: output the .json file and the totals file.

[0105] In the embodiments of the present disclosure, the Flutter framework and Dart syntax are further refined to enable dynamic compilation and update of pages written in Dart syntax, solving the problems of await statements not working, difficulty in dynamic compilation under the Flutter framework, and low compilation efficiency.

[0106] In the technical solutions disclosed herein, the acquisition, storage, and application of user personal information involved comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0107] According to an embodiment of the present disclosure, the present disclosure also provides a device for dynamic compilation, such as Figure 5 As shown, the apparatus 50 includes: a source file acquisition module 501 for acquiring at least one source file; a first target file generation module 502 for parsing each of the at least one source file using a DSL specification, determining a DSL syntax tree of the at least one source file, and obtaining at least one first target file, wherein each node in the DSL syntax tree represents a program object; a calling order determination module 503 for determining, based on the DSL syntax tree, the declared type and calling order of the program object represented by each node; and a second target file generation module 504 for determining, based on the declared type and calling order, a loading order of the declared type, and obtaining a second target file.

[0108] According to an embodiment of the present disclosure, the first target file generating module 502 is specifically configured to parse each of the at least one source file using a word segmentation tool and a customized DSL specification, and determine a DSL syntax tree for the at least one source file.

[0109] According to an embodiment of the present disclosure, the apparatus 50 further includes: a DSL specification customization module, configured to define a DSL specification according to a grammatical expression of a programming language used in the source file, and obtain the customized DSL specification.

[0110] According to an embodiment of the present disclosure, the apparatus 50 further includes: a specific expression definition module, configured to define a conversion rule for a specific expression in the programming language used by the source file.

[0111] According to an embodiment of the present disclosure, the first target file generation module 502 is configured to parse each of the at least one source file using a DSL specification, determine a DSL syntax tree for each file, and obtain a third target file or the first target file for each source file. The first target file generation module 502 further includes: a third target file generation submodule configured to generate the third target file if the first source file in the at least one source file is associated with the second source file, and otherwise generate the first target file; and a merging submodule configured to merge the third target file of the first source file into the first target file of the second source file.

[0112] According to one embodiment of the present disclosure, the calling order determination module 503 includes: a node information set acquisition submodule, configured to determine node information based on the DSL syntax tree to obtain a node information set, wherein the nodes include internal nodes and external nodes, and the node information includes the identifier and type of the corresponding node, wherein the node type includes a class, a top-level variable, a top-level function, and an enumeration; a declaration type determination submodule, configured to determine the declaration type of the program object represented by the node based on the node identifier; and a calling order determination submodule, configured to determine the calling order of the program objects represented by each node based on path information between the nodes in the DSL syntax tree.

[0113] According to one embodiment of the present disclosure, the node information collection acquisition submodule includes: an internal node information processing unit, used to add the node information belonging to the first source file to the node information collection of the first source file; an external node information processing unit, used to add the node information of the program object in the second source file to the node information collection of the second source file if the first source file contains the program object in the second source file.

[0114] According to one embodiment of the present disclosure, the second target file generation module 504 includes: a simple sorting submodule, which is used to perform a first sort on the set of node information from small to large according to size, and obtain a set of node information after the first sorting; a classification submodule, which is used to classify the set of sorted node information according to the declaration type, and obtain a set of second sorted node information corresponding to at least one declaration type; a fine sorting submodule, which is used to sort according to the calling order, and perform a second sort on the set of sorted node information corresponding to each declaration type, and obtain a set of second sorted node information; a second target generation submodule, which is used to record the set of the second sorted node information, and obtain a second target file.

[0115] According to one embodiment of the present disclosure, the device 50 also includes: a declaration type loading module, used to sequentially load the declaration type in the second target file according to the second target file; and an executable file conversion module, used to convert the first target file into an executable file corresponding to the at least one source file in the running environment.

[0116] According to an embodiment of the present disclosure, the present disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0117] Figure 6 A schematic block diagram of an example electronic device 800 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are provided as examples only and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0118] like Figure 6 As shown, the device 600 includes a computing unit 601, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the device 600 can also be stored in the RAM 603. The computing unit 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0119] Various components in device 600 are connected to I / O interface 605, including an input unit 606, such as a keyboard, mouse, etc.; an output unit 607, such as various types of displays, speakers, etc.; a storage unit 608, such as a magnetic disk, optical disk, etc.; and a communication unit 609, such as a network card, modem, wireless communication transceiver, etc. The communication unit 609 allows device 600 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0120] The computing unit 601 can be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various computing units for running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The computing unit 601 performs the various methods and processes described above, such as the method of dynamic compilation of the present disclosure. For example, in some embodiments, the method of dynamic compilation of the present disclosure can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as a storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on the device 600 via ROM 602 and / or communication unit 609. When the computer program is loaded into RAM 603 and executed by the computing unit 601, one or more steps of the method of dynamic compilation of the present disclosure described above can be performed. Alternatively, in other embodiments, the computing unit 601 can be configured to perform the method of dynamic compilation of the present disclosure by any other appropriate means (e.g., by means of firmware).

[0121] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0122] The program code for implementing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device so that when the program code is executed by the processor or controller, the functions / operations specified in the flow chart and / or block diagram are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0123] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0124] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0125] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer having a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0126] A computer system may include a client and a server. The client and server are generally remote from each other and typically interact through a communication network. The client-server relationship arises from computer programs running on the respective computers and having a client-server relationship with each other. The server may be a cloud server, a server in a distributed system, or a server integrated with a blockchain.

[0127] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in this disclosure can be achieved. This is not a limitation herein.

[0128] The above specific embodiments do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure shall be included within the scope of protection of this disclosure.

Claims

1. A dynamic compilation method, comprising: Get at least one source file; parsing each of the at least one source file using a DSL specification, determining a DSL syntax tree for the at least one source file, and obtaining at least one first target file, wherein each node in the DSL syntax tree represents a program object; Adding the node information belonging to the first source file to the set of node information of the first source file; If the first source file includes the program object in the second source file, adding the node information of the program object in the second source file to the set of node information of the second source file; The nodes include internal nodes and external nodes, the node information includes the identifier and type of the corresponding node, and the node type includes class, top-level variable, top-level function and enumeration; Determining, based on the identifier of the node, a declared type of the program object represented by the node; Determining the calling order of the program objects represented by each node according to the path information between each node in the DSL syntax tree; Determine the loading order of the declaration types according to the declaration types and the calling order, and obtain a second target file; According to the second target file, sequentially load the declared types in the second target file; Convert the first target file into an executable file corresponding to the at least one source file in the running environment.

2. The method according to claim 1, wherein The step of parsing each of the at least one source file using the DSL specification to determine the DSL syntax tree of the at least one source file includes: Using a word segmentation tool and a customized DSL specification, each source file in the at least one source file is parsed to determine a DSL syntax tree for the at least one source file.

3. The method according to claim 2, further comprising: A DSL specification is defined according to a syntax expression of a programming language used by the source file to obtain the customized DSL specification.

4. The method according to claim 3, wherein: The programming language used by the source file includes at least one programming language.

5. The method according to claim 3, further comprising: For a specific expression of the programming language used by the source file, a conversion rule of the specific expression is defined.

6. The method according to claim 1, wherein The step of using the DSL specification to parse each of the at least one source file, determining a DSL syntax tree of the at least one source file, and obtaining at least one first target file includes: Parsing each of the at least one source file using a DSL specification, determining a DSL syntax tree for each source file, and obtaining a third target file or the first target file for each source file; If the first source file in the at least one source file is associated with the second source file, a third target file is generated; otherwise, the first target file is generated; The third target file of the first source file is merged into the first target file of the second source file.

7. The method according to claim 1, wherein Determining a loading order of the declaration types according to the declaration types and the calling order to obtain a second target file includes: sorting the node information set in ascending order according to size to obtain a first sorted node information set; Classifying the sorted set of node information according to the declaration type to obtain a set of classified node information corresponding to at least one declaration type; sorting the node information after classification corresponding to each declaration type in the calling order, and performing a second sorting on the node information after classification to obtain a second sorted node information set; The set of node information after the second sorting is recorded to obtain a second target file.

8. A dynamic compilation device comprising: A source file acquisition module, used to acquire at least one source file; a first target file generating module configured to parse each of the at least one source file using a DSL specification, determine a DSL syntax tree of the at least one source file, and obtain at least one first target file, wherein each node in the DSL syntax tree represents a program object; A calling sequence determination module, configured to determine the declaration type and calling sequence of the program object represented by each node according to the DSL syntax tree; A second target file generating module is used to determine the loading order of the declared types according to the declared types and the calling order, and obtain a second target file; a declaration type loading module, configured to sequentially load the declaration types in the second target file according to the second target file; An executable file conversion module, configured to convert the first target file into an executable file corresponding to the at least one source file in a running environment; The calling order determination module includes: a node information set acquisition submodule, configured to determine node information based on the DSL syntax tree to obtain a node information set, wherein the nodes include internal nodes and external nodes, and the node information includes the identifier and type of the corresponding node, wherein the node type includes class, top-level variable, top-level function, and enumeration; a declaration type determination submodule, configured to determine the declaration type of the program object represented by the node based on the node identifier; and a calling order determination submodule, configured to determine the calling order of the program objects represented by each node based on the path information between the nodes in the DSL syntax tree. Among them, the node information collection acquisition submodule includes: an internal node information processing unit, which is used to add the node information belonging to the first source file to the node information collection of the first source file; and an external node information processing unit, which is used to add the node information of the program object in the second source file to the node information collection of the second source file if the first source file contains the program object in the second source file.

9. The device according to claim 8, wherein The first target file generation module is specifically configured to use a word segmentation tool and a customized DSL specification to parse each of the at least one source file and determine a DSL syntax tree for the at least one source file.

10. The apparatus according to claim 9, further comprising: The DSL specification customization module is used to define the DSL specification according to the syntax expression of the programming language used by the source file to obtain the customized DSL specification.

11. The apparatus according to claim 10, further comprising: The specific expression definition module is used to define a conversion rule for a specific expression of the programming language used by the source file.

12. The apparatus according to claim 8, wherein the first target file generation module is specifically configured to parse each of the at least one source file using a DSL specification, determine a DSL syntax tree for each source file, and obtain the third target file or the first target file for each source file; The first target file generating module further includes a third target file generating submodule configured to generate the third target file if the first source file in the at least one source file is associated with the second source file, and otherwise generate the first target file; A merging submodule is configured to merge the third target file of the first source file into the first target file of the second source file.

13. An electronic device comprising: at least one processor; as well as a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 7.

14. A non-transitory computer-readable storage medium storing computer instructions, wherein: The computer instructions are used to cause the computer to execute the method according to any one of claims 1 to 7.

15. A computer program product comprising a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 7.

Images