CN117519814A - Sharing method and device - Google Patents
Sharing method and device Download PDFInfo
- Publication number
- CN117519814A CN117519814A CN202211083725.2A CN202211083725A CN117519814A CN 117519814 A CN117519814 A CN 117519814A CN 202211083725 A CN202211083725 A CN 202211083725A CN 117519814 A CN117519814 A CN 117519814A
- Authority
- CN
- China
- Prior art keywords
- plug
- data
- service
- knowledge data
- sharing device
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 117
- 230000008859 change Effects 0.000 claims description 106
- 238000004458 analytical method Methods 0.000 claims description 42
- 238000004519 manufacturing process Methods 0.000 claims description 30
- 230000015654 memory Effects 0.000 claims description 30
- 238000011161 development Methods 0.000 claims description 19
- 230000008569 process Effects 0.000 claims description 18
- 230000003068 static effect Effects 0.000 claims description 11
- 238000004590 computer program Methods 0.000 claims description 7
- 238000010586 diagram Methods 0.000 description 30
- 206010047289 Ventricular extrasystoles Diseases 0.000 description 17
- 230000008439 repair process Effects 0.000 description 17
- 238000005129 volume perturbation calorimetry Methods 0.000 description 17
- 230000006870 function Effects 0.000 description 13
- 230000003993 interaction Effects 0.000 description 13
- 238000004891 communication Methods 0.000 description 11
- 230000004044 response Effects 0.000 description 6
- SPBWHPXCWJLQRU-FITJORAGSA-N 4-amino-8-[(2r,3r,4s,5r)-3,4-dihydroxy-5-(hydroxymethyl)oxolan-2-yl]-5-oxopyrido[2,3-d]pyrimidine-6-carboxamide Chemical compound C12=NC=NC(N)=C2C(=O)C(C(=O)N)=CN1[C@@H]1O[C@H](CO)[C@@H](O)[C@H]1O SPBWHPXCWJLQRU-FITJORAGSA-N 0.000 description 3
- 102100021677 Baculoviral IAP repeat-containing protein 2 Human genes 0.000 description 3
- 102100021662 Baculoviral IAP repeat-containing protein 3 Human genes 0.000 description 3
- 101000896157 Homo sapiens Baculoviral IAP repeat-containing protein 2 Proteins 0.000 description 3
- 101000896224 Homo sapiens Baculoviral IAP repeat-containing protein 3 Proteins 0.000 description 3
- 230000002452 interceptive effect Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 239000007787 solid Substances 0.000 description 3
- 239000008186 active pharmaceutical agent Substances 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 239000012634 fragment Substances 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000000295 complement effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000000802 evaporation-induced self-assembly Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/903—Querying
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/72—Code refactoring
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/75—Structural analysis for program understanding
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
- G06N5/00—Computing arrangements using knowledge-based models
- G06N5/02—Knowledge representation; Symbolic representation
- G06N5/022—Knowledge engineering; Knowledge acquisition
Abstract
The sharing method is suitable for an IDE architecture, wherein the IDE architecture comprises a sharing device, a first plug-in unit and a second plug-in unit, the sharing device is used for executing the sharing method, M pieces of knowledge data provided by the first plug-in unit are stored in the sharing device, M is a positive integer, the sharing device receives a data acquisition request of the second plug-in unit, and the sharing device searches target knowledge data from the M pieces of knowledge data according to the data acquisition request and sends the target knowledge data to the second plug-in unit.
Description
The present application claims priority from the chinese patent application filed at 2022, 7 and 28, by the intellectual property office of the people's republic of China, application number 202210901542.0, entitled "integrated development Environment plug-in base framework", the entire contents of which are incorporated herein by reference.
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a sharing method and apparatus.
Background
The modern program development basically needs to be realized by relying on an integrated development environment (integrated development environment, IDE) architecture, the IDE in the current industry is various in variety and different in function emphasis, and the main IDE technical architecture in the industry is architecture separation, namely a core is separated from a plug in, the core is mainly responsible for separating an operating system, and the plug in is responsible for separating functions.
The IDE architecture includes a plurality of plug-ins for code analysis classes, such as a plurality of language service class plug-ins for code hopping, code completion, and code generation. The multiple plug-ins in the IDE architecture are isolated from each other, and there is a problem that the multiple plug-ins may need to have some same capability and even need to perform some same operation, so that resources are wasted.
Disclosure of Invention
The application provides a sharing method and device for solving the problem of resource waste in an IDE architecture.
In a first aspect, the present application provides a sharing method applicable to an IDE architecture, where the IDE architecture includes a sharing device, a first plugin, and a second plugin, and the sharing method is performed by the sharing device.
M pieces of knowledge data provided by the first plug-in are stored in the sharing device, and M is a positive integer. The method comprises the following steps: the sharing device receives a data acquisition request of the second plug-in; the sharing device searches target knowledge data from M knowledge data according to the data acquisition request; the sharing device sends the target knowledge data to the second plug-in.
In the above technical solution, M pieces of knowledge data provided by the first plug-in are stored in the sharing device, and when the second plug-in needs to use a certain knowledge data (i.e., target knowledge data) in the M pieces of knowledge data, the second plug-in can directly request the target knowledge data from the sharing device, without analyzing the code file, which is helpful for saving computing resources.
In one possible implementation manner, before the sharing device receives the data acquisition request of the second plugin, the sharing device further includes: the sharing device receives a data registration request of the first plugin, wherein the data registration request comprises identifications of M pieces of knowledge data; the sharing device records an identification of the M pieces of knowledge data.
In the above technical solution, the first plugin may register the identification of the M pieces of knowledge data with the sharing device, so that the sharing device can determine whether there is the target knowledge data to be requested by the data acquisition request in the current sharing device.
In one possible implementation manner, after the sharing device records the identification of the M pieces of knowledge data, the M pieces of knowledge data are further obtained from the first plugin, and the M pieces of knowledge data are stored; the M knowledge data are obtained by analyzing code files in the working space by the first plug-in; or the M pieces of knowledge data are obtained by analyzing basic data by the first plug-in unit, and the basic data are obtained by analyzing code files in the working space by the sharing device; the first insert and the second insert act together in the workspace; the basic data is one or more of an abstract syntax tree, token (token) sequence; the M pieces of knowledge data comprise one or more of code indexes, static single assignment, control flow graphs and program dependency graphs.
In the above technical solution, the sharing device synchronizes M pieces of knowledge data from the first plug-in, so that the sharing device can find target knowledge data to be requested by the data acquisition request from M pieces of knowledge data stored in the sharing device.
In one possible implementation manner, after the sharing device stores the M pieces of knowledge data, the sharing device further obtains change information of the M pieces of knowledge data from the first plugin; the sharing device updates M 'knowledge data in the M knowledge data according to the change information of the M' knowledge data; the change information of the M' knowledge data is obtained by performing incremental analysis on the first plugin according to the change information of the code file in the working space; or, the change information of the M' knowledge data is obtained by performing incremental analysis by the first plug-in according to the change information of the basic data, and the change information of the basic data is obtained by performing incremental analysis by the sharing device according to the change information of the code file in the working space.
According to the technical scheme, the sharing device can also acquire the change information of the knowledge data from the first plug-in, and update the locally corresponding knowledge data according to the change information of the knowledge data, so that the knowledge data stored in the sharing device is ensured to be identical to the knowledge data obtained by analysis of the first plug-in, namely, the knowledge data stored in the sharing device is ensured to be the latest knowledge data.
In one possible implementation manner, after the sharing device sends the target knowledge data to the second plugin, the sharing device further receives a subscription request of the second plugin to the target knowledge data, where the subscription request is used to obtain change information of the target knowledge data; the sharing device also transmits the change information of the target knowledge data to the second plug-in after receiving the change information of the target knowledge data from the first plug-in.
In the above technical solution, when the sharing device determines that the target knowledge data is changed, the sharing device further sends change information of the target knowledge data to the second plugin, so as to ensure that the target knowledge data acquired by the second plugin is the latest knowledge data.
In one possible implementation manner, m pieces of knowledge data provided by a production plug-in are stored in the sharing device, the production plug-in comprises a first plug-in, and m is a positive integer; in the process of developing the third plug-in by the user, the sharing device further sends description information of m pieces of knowledge data to the front-end module, so that the user selects knowledge data which can be obtained from the sharing device by the third plug-in from the m pieces of knowledge data according to the description information of the m pieces of knowledge data displayed in the front-end module.
In the above technical solution, the sharing device displays the description information of m pieces of knowledge data stored in the sharing device in the front-end module, and the user can learn which knowledge data can be directly obtained from the sharing device in the process of developing the third plugin, so that the third plugin is set to request the knowledge data from the sharing device, without analyzing the code file again, that is, multiple plugins are avoided from repeatedly analyzing the code file, which is helpful for saving computing resources.
In a second aspect, the present application provides a sharing method, applicable to an IDE architecture, where the IDE architecture includes a sharing device, a first plugin, and a second plugin, and the sharing method is performed by the sharing device.
N services provided by the first plug-in are registered in the sharing device, wherein N is a positive integer. The method comprises the following steps: the sharing device receives a service call request of the second plug-in; the sharing device calls target service in N services according to the service call request; the sharing device receives an operation result obtained by the first plug-in providing the target service and sends the operation result to the second plug-in.
In the above technical solution, N services provided by the first plug-in are registered in the sharing device, and when the second plug-in needs to use a certain service (i.e., a target service) of the N services, the second plug-in can directly request to call the target service to the sharing device, without implementing the target service in the second plug-in, which is helpful for saving computing resources.
In one possible implementation, the first plug-in and the second plug-in act on the same workspace, with the result that the first plug-in provides the target service to the workspace.
In one possible implementation manner, before the sharing device receives the service call request of the second plugin, the sharing device also receives the service registration request of the first plugin, where the service registration request includes first interface addresses of N services, and the first interface addresses of the services are used for the sharing device to call the service; the sharing device generates second interface addresses of the N services according to the first interface addresses of the N services, and the second interface addresses of the services are used for the second plug-in unit to call the services; the sharing device records the first interface address and the second interface address of the N services.
In the above technical solution, the first plugin may register the first interface addresses of the N services with the sharing device, so that the sharing device can determine whether to provide the target service requested by the service call request in the current sharing device.
In one possible implementation manner, after the sharing device records the first interface address and the second interface address of the N services, the sharing device further receives a service query request of the second plugin, where the service query request includes an identifier of a target service, and the N services include the target service; the sharing device sends the second interface address of the target service to the second plug-in. Correspondingly, the sharing device calls the target service in the N services according to the service call request, specifically, the sharing device determines the first interface address of the target service according to the second interface address of the target service in the service call request; the sharing device calls the target service according to the first interface address of the target service.
In the above technical solution, the sharing device sends the second interface address of the target service to the second plug-in, so that when the second plug-in needs to request to call the target service, the second plug-in sends a service call request including the second interface address of the target service to the sharing device, and the sharing device calls the target service according to the second interface address of the target service in the service call request and according to the first interface address of the target service.
In one possible implementation manner, n services provided by a production plugin are registered in the sharing device, the production plugin includes a first plugin, and n is a positive integer; in the process of developing the third plugin by the user, the method further comprises: the sharing device sends the description information of the n services to the front-end module, so that the user selects a service which can be called from the sharing device by the third plug-in from the n services according to the description information of the n services displayed by the front-end module.
In the above technical solution, the sharing device displays the description information of n services registered in the sharing device in the front-end module, and the user can learn which services can be directly requested to be invoked from the sharing device in the process of developing the third plugin, so that the third plugin is set to request to invoke the services from the sharing device, without implementing the services in the third plugin, that is, avoiding implementing the same services in multiple plugins, and contributing to saving computing resources.
In a third aspect, the present application provides a sharing device adapted for use in an IDE architecture, the IDE architecture comprising a device, a first plug-in, and a second plug-in; m pieces of knowledge data provided by the first plug-in are stored in the device, wherein M is a positive integer;
The device comprises:
the data query module is used for receiving a data acquisition request of the second plug-in; searching target knowledge data from M knowledge data according to the data acquisition request;
and the data downloading module is used for sending the target knowledge data to the second plug-in.
In one possible implementation, the apparatus further includes: a data registration module; before the data query module receives a data acquisition request of the second plugin, the data registration module is used for receiving a data registration request of the first plugin, wherein the data registration request comprises identifications of M pieces of knowledge data; the identity of the M knowledge data is recorded.
In one possible implementation, the apparatus further includes: a data uploading module; after the data registration module records the identification of the M knowledge data, the data uploading module is configured to: m pieces of knowledge data are obtained from the first plug-in unit, and the M pieces of knowledge data are stored; the M knowledge data are obtained by analyzing code files in the working space by the first plug-in; or the M pieces of knowledge data are obtained by analyzing basic data by the first plug-in unit, and the basic data are obtained by analyzing code files in the working space by the device; the first plug-in and the second plug-in act together in the working space; the basic data is one or more items in abstract grammar tree and token sequence; the M pieces of knowledge data comprise one or more of code indexes, static single assignment, control flow graphs and program dependency graphs.
In one possible implementation, after the data upload module stores M pieces of knowledge data, the data upload module is further configured to: acquiring change information of M' knowledge data from a first plug-in; updating M 'knowledge data in the M knowledge data according to the change information of the M' knowledge data; the change information of the M' knowledge data is obtained by performing incremental analysis on the first plugin according to the change information of the code file in the working space; or, the change information of the M' knowledge data is obtained by performing incremental analysis by the first plug-in according to the change information of the basic data, and the change information of the basic data is obtained by performing incremental analysis by the device according to the change information of the code file in the working space.
In one possible implementation, after the data download module sends the target knowledge data to the second plugin, the data download module is further configured to: receiving a subscription request of the second plugin for the target knowledge data, wherein the subscription request is used for the second plugin to acquire change information of the target knowledge data; correspondingly, after the data uploading module receives the change information of the target knowledge data from the first plug-in, the data downloading module is further used for sending the change information of the target knowledge data to the second plug-in.
In one possible implementation manner, m pieces of knowledge data provided by a production plug-in are stored in the device, the production plug-in comprises a first plug-in, and m is a positive integer; in the process of developing the third plugin by the user, the data query module is further configured to: and sending the description information of the m pieces of knowledge data to the front-end module, so that a user selects knowledge data which can be acquired from the device by the third plug-in from the m pieces of knowledge data according to the description information of the m pieces of knowledge data, which is displayed by the front-end module.
In a fourth aspect, the present application provides a sharing device adapted for use in an IDE architecture, the IDE architecture comprising a device, a first plug-in, and a second plug-in; the device comprises:
the service registration module is used for registering N services provided by the first plug-in, wherein N is a positive integer;
the service calling module is used for receiving a service calling request of the second plug-in; according to the service calling request, calling a target service in the N services; receiving an operation result obtained by providing a target service by a first plug-in; and sending the operation result to the second plug-in.
In one possible implementation, the first plug-in and the second plug-in act on the same workspace, with the result that the first plug-in provides the target service to the workspace.
In one possible implementation, before the service invocation module receives the service invocation request of the second plugin, the service registration module is configured to: receiving a service registration request of a first plugin, wherein the service registration request comprises first interface addresses of N services, and the first interface addresses of the services are used for calling the services by a device; generating second interface addresses of the N services according to the first interface addresses of the N services, wherein the second interface addresses of the services are used for calling the services by the second plug-in; the first interface address and the second interface address of the N services are recorded.
In one possible implementation, the method further includes: a service discovery module; after the service registration module records the first interface address and the second interface address of the N services, the service discovery module is configured to: receiving a service query request of the second plugin, wherein the service query request comprises an identifier of a target service, and N services comprise the target service; and sending the second interface address of the target service to the second plug-in.
In one possible implementation manner, the service calling module is specifically configured to, when calling a target service in the N services according to the service calling request: determining a first interface address of the target service according to a second interface address of the target service in the service call request; and calling the target service according to the first interface address of the target service.
In one possible implementation manner, n services provided by a production plug-in are registered in the service registration module, the production plug-in includes a first plug-in, and n is a positive integer; the apparatus further comprises: a service discovery module; in the process of developing the third plugin by the user, the service discovery module is used for: and sending the description information of the n services to the front-end module so that the user can select the service which can be called from the device by the third plug-in from the n services according to the description information of the n services displayed by the front-end module.
In a fifth aspect, the present application provides a cluster of computing devices, comprising at least one computing device, each computing device comprising a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method of or the method of any of the possible implementations of the first aspect or the second aspect described above.
In a sixth aspect, the present application provides a computer program product comprising instructions which, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method of the first aspect or any of the possible implementations of the first aspect, or to perform the method of the second aspect or any of the possible implementations of the second aspect.
In a seventh aspect, the present application provides a computer readable storage medium comprising computer program instructions which, when executed by a cluster of computing devices, perform the method of the first aspect or any of the possible implementations of the first aspect, or perform the method of the second aspect or any of the possible implementations of the second aspect.
In an eighth aspect, the present application provides a sharing system, including: the apparatus of the third aspect or any possible implementation manner of the third aspect, and the apparatus of the fourth aspect or any possible implementation manner of the fourth aspect.
The technical effects that can be achieved by any one of the third aspect to the eighth aspect may be referred to the description of the beneficial effects in the first aspect or the second aspect, and the detailed description is not repeated here.
Drawings
FIG. 1 is a process by which a language server analyzes code;
FIG. 2 is a schematic diagram of an IDE architecture;
FIG. 3 is a schematic diagram of an IDE architecture provided herein;
FIG. 4 is a schematic flow chart of providing knowledge data to a sharing device by a first plug-in provided by the present application;
FIG. 5 is a schematic diagram of a data registry provided herein;
FIG. 6 is a schematic diagram of a code file and control flow graph provided herein;
FIG. 7 is a schematic diagram of another code file and control flow graph provided herein;
FIG. 8 is a flow chart of a second plug-in requesting knowledge data from a sharing device;
FIG. 9 is an interactive schematic diagram of knowledge sharing provided herein;
FIG. 10 is a schematic diagram of interactions of yet another knowledge sharing provided herein;
FIG. 11 is a schematic flow chart of providing services to a sharing device by a first plug-in provided by the present application;
FIG. 12 is a schematic diagram of a service registry provided herein;
FIG. 13 is a schematic flow chart of a second plug-in requesting services from a sharing device;
FIG. 14 is an interactive schematic diagram of a service sharing provided herein;
FIG. 15 is an interactive schematic diagram of yet another service sharing provided herein;
FIG. 16 is a schematic structural diagram of a knowledge data sharing device provided in the present application;
FIG. 17 is a schematic structural diagram of a sharing device for a service provided in the present application;
FIG. 18 is a schematic diagram of a sharing system provided herein;
FIG. 19 is a schematic diagram of a computing device provided herein;
Fig. 20 is a schematic structural diagram of a computing device cluster provided in the present application.
Detailed Description
For a better explanation of embodiments of the present application, related terms or techniques in the present application are explained first:
1. integrated development environment (integrated development environment, IDE): application software for assisting programmers in realizing software development generally comprises functions of a language editor, an automatic construction tool and the like, and belongs to a development tool.
The IDE architecture is generally divided into a kernel layer and a plug-in layer, wherein the kernel layer is responsible for realizing the calling of the bottom layer instruction of an operating system and realizing part of basic public capability, such as environment service, file system service and the like; the plug-in layer invokes and orchestrates basic common capabilities using the kernel layer's application programming interfaces (application programming interface, APIs) to implement corresponding plug-in functions, e.g., code definition jumps, reference lookups, etc.
2. Plug-in: the plug-in can only run under the system platform specified by the program, but can not run independently from the specified system platform.
3. Language service protocol (language server protocol, LSP): both IDE and language server (language server) act as protocols to be followed by both parties.
The language server illustrated in fig. 1 illustrates a process of analyzing a code, wherein the language server may provide plug-ins of language service classes such as code skipping, code complement, code generation, code reconstruction, code defect detection, code repair, test case detection, etc., each of which needs to analyze the code and extract knowledge data corresponding to the code. Specifically, each plug-in generates a token by performing lexical analysis on the code; an abstract syntax tree (abstract syntax tree, AST) is then generated by parsing the code, wherein the token and abstract syntax tree can be used as the underlying data for the code. The plug-ins then extract knowledge data of the code, such as code index, static single-assignment (SSA), control flow graph (control flow graph, CFG), program dependency graph (program dependence graph, PDG), etc., based on the abstract syntax tree and token.
4. A workspace (workspace) contains the following resources: items, files, folders. The workspace has a distinct hierarchy in which items are at the highest level, with files and folders in the items, and the plugins can manage the resources of the workspace through APIs provided by the kernel layer of the IDE. The user may open a workspace when an item is started.
5. A file: a file comprising software code (also referred to as a code file) with a file suffix of Java for example and c++ for example.
Embodiments of the present application will be described in detail below with reference to the accompanying drawings.
Fig. 2 is a schematic diagram of an IDE architecture, which may be deployed in a development device, where the development device is included in a terminal device (e.g., a computer). Plug-in modules and front-end modules may be included in the development device. The plug-in module comprises K plug-ins, K is an integer greater than 1, wherein the plug-ins are plug-ins of language service types, for example, and can be used for developing application programs. The front-end module is used for interacting with a user.
Illustratively, the user performs operations in the front-end module, such as opening a workspace for developing the application, or code editing a code file in the workspace that has been opened, etc. Correspondingly, the front-end module generates a user interaction event according to the operation executed by the user and sends the user interaction event to the plug-in module.
Illustratively, when a user opens a workspace in the front-end module, the user interaction event generated by the front-end module is used to instruct the user to open the workspace. Correspondingly, the plug-in module loads K plug-ins acting on the working space, wherein each plug-in the K plug-ins analyzes a code file in the working space to obtain knowledge data of the code file. When a user edits the code file through the front-end module, a user interaction event generated by the front-end module is used for indicating the content of the user for editing the code file, and correspondingly, each plug-in the K plug-ins determines the latest code file according to the content of the user for editing the code file and the code file before editing, and analyzes the latest code file to obtain knowledge data of the latest code file.
In this application, analysis of code files by plug-ins may be considered static analysis.
In the above scheme, when each plug-in develops an application program, knowledge data of a code file in a working space is required to be used, so that each plug-in needs to analyze the code file to obtain the knowledge data. The knowledge data obtained by analyzing the same code file by a plurality of plug-ins are the same, and the problem of repeated analysis exists.
Based on this, the present application provides an IDE architecture based on fig. 2, and the schematic diagram of the IDE architecture provided in the present application can be seen in fig. 3, compared to the IDE architecture of fig. 2 in which the sharing device is newly added. The sharing device is used for sharing knowledge data among a plurality of plug-ins in the plug-in module.
The sharing means may be located in the terminal device, in particular the sharing means and the development means are located in the same terminal device, or the sharing means and the development means are located in different terminal devices. The shared device is, for example, a language service class plug-in the IDE architecture. The sharing means may also be located remotely, for example in a server, or in an edge device.
Taking a case that a user opens a certain working space in the front-end module as an example, a user interaction event generated by the front-end module is used for indicating the working space opened by the user. Correspondingly, the plug-in modules sequentially load K plug-ins acting on the working space according to the user interaction event, for example, the plug-in modules sequentially load plug-ins 1 to K. The plug-in 1 analyzes the code file in the working space to obtain the knowledge data of the code file, the plug-in 1 sends the knowledge data of the code file to the sharing device, any plug-in 2 to the plug-in K does not need to analyze the code file again, but requests the knowledge data of the code file from the sharing device, so that only one plug-in is needed to analyze the code file in the K plug-ins acting on the working space, and the problem of repeated analysis and calculation is avoided.
Correspondingly, the application provides a knowledge data sharing method, which is applicable to an IDE architecture, wherein the IDE architecture comprises a sharing device and a development device, the development device comprises a first plug-in unit and a second plug-in unit, and the sharing device is respectively connected with the first plug-in unit and the second plug-in unit.
The IDE architecture schematic shown in connection with fig. 3, for example, the first card and the second card are card 1 and card 2, respectively, and for another example, the first card and the second card are card 1 and card K, respectively, and so on.
The first plug-in and the second plug-in may act on the same workspace, which includes code files for a certain application being developed, it being understood that the first plug-in and the second plug-in may be used to co-develop the application. The first plug-in can analyze the code file to obtain knowledge data of the code file, synchronize the knowledge data obtained by analysis into the sharing device, and the second plug-in can request the knowledge data obtained by analysis of the first plug-in from the sharing device.
In this application, a first plug-in may be understood as a producer of knowledge data and a second plug-in as a consumer of knowledge data. It will also be appreciated that the first insert belongs to the production insert and the second insert belongs to the consumer insert.
The data sharing method provided in the present application is explained in two parts, wherein the first part: the first plug-in provides knowledge data to the sharing device; a second part: the second plug-in requests knowledge data from the sharing device.
The first part is explained with reference to a flow diagram of the first plug-in providing knowledge data to the sharing device, which is exemplarily shown in fig. 4:
in step 401, the first plugin analyzes the code file in the workspace to obtain M pieces of knowledge data, where M is a positive integer. Illustratively, the M pieces of knowledge data include one or more of a code index, a static single assignment, a control flow graph, and a program dependency graph.
In one possible implementation, the first plugin obtains the code file in the workspace, and analyzes the code file to obtain M pieces of knowledge data, and a specific analysis process may be described in the related embodiment of fig. 1.
Optionally, before step 401, the first plug-in first requests to the sharing device to acquire M pieces of knowledge data, and after determining that the M pieces of knowledge data do not exist in the knowledge database of the sharing device, analyzes the code file to obtain the knowledge data. In one possible implementation manner, the first plugin sends a data acquisition request to the sharing device, where the data acquisition request includes the identification of M pieces of knowledge data, and accordingly, the sharing device sends a response to the first plugin requesting failure if it is determined that the M pieces of knowledge data do not currently exist. The first plug-in analyzes the code file after receiving the response of the request failure to obtain M pieces of knowledge data of the code file.
In step 402, the first plugin sends a data registration request to the sharing device, where the data registration request includes registration information of M pieces of knowledge data provided by the first plugin.
In one possible implementation, the sharing device may first verify and authenticate the identity information of the source of the request (i.e. the first card) after receiving the data registration request, and obtain the registration information of the M pieces of knowledge data from the data registration request after determining that the identity information of the first card passes the verification and authentication.
Taking one knowledge data of the M knowledge data as an example: the registration information of the knowledge data includes an identification of the knowledge data. Optionally, the registration information of the knowledge data further includes one or more of description, type and data structure of the knowledge data. For example, the knowledge data is a control flow graph, and the registration information of the control flow graph includes an identifier "codelf.cfg" of the control flow graph, a description "code control flow graph data" of the control flow graph, a type "CFG" of the control flow graph, and a data structure "point data structure" of the control flow graph. For another example, the knowledge data is a program dependency graph, and the registration information of the program dependency graph includes an identifier "codelf.pdg" of the program dependency graph, a description "code program dependency data" of the program dependency graph, a type "PDG" of the program dependency graph, and a data structure "edge data structure" of the program dependency graph.
It should be noted that the sequence of the step 401 and the step 402 is not limited. The first plugin may first send a data registration request to the sharing device (i.e., perform step 402), and then analyze the code file in the workspace to obtain knowledge data (i.e., perform step 401). Alternatively, the first plug-in performs step 402 before performing step 401.
In step 403, the sharing device records registration information of the M pieces of knowledge data provided by the first plug-in.
Optionally, the sharing device includes data statistics information, and the sharing device acquires registration information of M pieces of knowledge data from the data registration request, and then records the registration information of the M pieces of knowledge data in the data statistics information.
It will be appreciated that the data statistics have recorded therein registration information for m pieces of knowledge data provided by one or more production plug-ins. That is, the first plug-in is included in the one or more production plug-ins, registration information of M pieces of knowledge data includes registration information of M pieces of knowledge data, and M is an integer greater than or equal to M.
For example, both plug-in A and plug-in B belong to production plug-ins, the plug-in A sends a data registration request A to a sharing device, the data registration request A comprises registration information of knowledge data 1 to knowledge data 10, and the sharing device records the registration information of the knowledge data 1 to the knowledge data 10 in data statistics information; the plug-in B sends a data registration request B to the sharing device, wherein the data registration request B comprises registration information from the knowledge data 11 to the knowledge data 20, and the sharing device records the registration information from the knowledge data 11 to the knowledge data 20 in data statistics information; the card B is a first card.
The data statistics information is, for example, a data registry, such as a schematic diagram of a data registry provided in fig. 5 for an exemplary application, where the data registry includes registration information of m pieces of knowledge data, such as registration information including a control flow graph and registration information of a program dependency graph, and each field in the registration information may be described in step 402.
In step 404, the sharing device obtains M pieces of knowledge data from the first plugin.
In one possible implementation, the sharing device obtains/synchronizes M pieces of knowledge data from the first plug-in according to the registration information of the M pieces of knowledge data in the registration request. The sharing device sends a data synchronization request to the first plugin, where the data synchronization request includes an identifier of the M pieces of knowledge data, and the first plugin synchronizes the M pieces of knowledge data to the sharing device.
In another possible implementation manner, the first plug-in actively transmits not only the data registration request to the sharing device, but also M pieces of knowledge data corresponding to the data registration request to the sharing device. In one possible example, when the first plug-in is loaded, the plug-in module sends a data registration request to the sharing device, and when the plug-in module invokes the first plug-in, the first plug-in performs static code analysis to generate M pieces of knowledge data, and sends the M pieces of knowledge data to the sharing device.
In step 405, the sharing device stores M pieces of knowledge data in a knowledge database.
In one possible implementation, the sharing device includes a knowledge database, and the sharing device stores the M pieces of knowledge data of the first plugin in the knowledge database after receiving the M pieces of knowledge data from the first plugin. In this way, m knowledge data from one or more production plugins are stored in the knowledge database.
It is understood that the knowledge database and the data statistics have a correspondence. When the sharing device needs to search for certain knowledge data, whether the registration information of the knowledge data is recorded in the data statistics information can be determined first, and if the registration information of the knowledge data is recorded in the data statistics information, the knowledge data is searched from the knowledge database.
Alternatively, when the knowledge data is stored in the knowledge database, the sharing device may further acquire an address where the knowledge data is stored in the knowledge database, and then record the address in the data statistics. If the sharing device determines that the registration information of the knowledge data is recorded in the data statistics information, the address of the knowledge data stored in the knowledge database is further acquired, and the knowledge data is acquired from the knowledge database according to the acquired address.
It should be noted that the code file may also be changed, for example, the user modifies the content in the original code file based on the original code file, where the modification may include newly adding a certain new code file or a certain new code file based on the original code file, modifying the code in the code file, deleting a certain code file or a code in a certain code file, etc. To ensure that the knowledge data more accurately expresses the changed code file, the first plug-in may perform incremental analysis (which may be referred to as incremental analysis) according to the changed code file to determine the knowledge data after the change.
It can be appreciated that when the user modifies the content in the original code file, the first plug-in needs to analyze not only the change information of the code file in the workspace, but also the other code files associated with the change information of the code file. Illustratively, the code file includes a code file 1 and a code file 2, the user adds a code file 3 on the basis of the code file 1 and the code file 2, and the code file 3 and the code file 1 can mutually influence. To this end, the first plug-in needs to analyze not only the code file 3 but also the code file 1 associated with the code file 3, i.e., the first plug-in determines that the code file 1 and the code file 3 to be incrementally analyzed are included in the code file.
In one possible implementation, the first plug-in obtains change information of the code file, and determines the affected code file (i.e., the code file that needs incremental analysis) in the workspace according to the change information of the code file. The first plug-in performs incremental analysis on the affected code files in the working space to obtain change information of M 'knowledge data, wherein M' is a positive integer less than or equal to M. For example, the code file includes a code file 1 and a code file 2, and the first plug-in analyzes the code file 1 and the code file 2 to obtain a code index, a static single assignment, a control flow graph, a program dependency graph, i.e. 4 pieces of knowledge data. Further, the user adds the code file 3 on the basis of the code file 1 and the code file 2, the first plug-in determines that the code files needing incremental analysis are the code file 1 and the code file 3 according to the newly added code file 3, and further, the first plug-in analyzes the code file 1 and the code file 3 to obtain the change information of the code index and the change information of the control flow diagram, namely the change information of 2 knowledge data.
In the implementation mode that the first plug-in acquires the change information of the code file, the first plug-in can periodically detect whether the change information exists in the current code file, and when the first plug-in determines that the change information exists in the current code file, the first plug-in determines the code file needing to be subjected to incremental analysis according to the change information of the code file. Or after modifying the content in the original code file, the user triggers the first plug-in to acquire the code file needing incremental analysis, that is, the first plug-in can also respond to the user instruction to acquire the change information of the code file from the current code file.
The first plug-in also needs to synchronize the change information of the M' knowledge data into the sharing device. Optionally, the first plugin further carries a change instruction when synchronizing the change information of the knowledge data to the sharing device, where the change instruction is used to indicate that the knowledge data is obtained based on incremental analysis. Optionally, the change instruction is further used for indicating an update position when the change information of the knowledge data is updated to the original knowledge data. And the sharing device updates M 'knowledge data currently stored in the knowledge database according to the change information of the M' knowledge data and the M 'change instructions, so as to obtain M' knowledge data after updating.
In combination with the above example, the sharing device obtains the change information and the change instruction of the code index from the first plug-in, and the sharing device updates the currently stored code index in the knowledge database according to the change information and the change instruction of the code index; the sharing device also acquires the change information and the change instruction of the control flow graph from the first plug-in, and updates the control flow graph currently stored in the knowledge database according to the change information and the change instruction of the control flow graph.
The control flow graph is explained as an example as follows:
The original code file acquired by the first plug-in is shown in fig. 6 (a), the first plug-in analyzes the original code file, and the obtained control flow graph is shown in fig. 6 (b), wherein each circle represents a Basic Block (BB), a circle 1 represents an input block, a circle 8 represents an output block, and a circle 3 represents an if statement. The first plug-in sends the acquired control flow graph to the sharing device, and the sharing device stores the control flow graph.
Then, after the user adds two lines of codes before the 5 th line and the 9 th line in the original code file, the obtained modified code file is shown in fig. 7 (a), and the first plug-in performs incremental analysis on the modified code file to determine that the change information of the control flow graph is: a circle 2 is added before a circle 3, and a circle 7 is added before a circle 8, wherein the circle 2 represents a while sentence, two branches of the circle 2 point to the circle 3 and the circle 7 respectively, and the circle 6 further points to the circle 2. Accordingly, the first plugin updates the obtained control flow graph according to the change information of the control flow graph as shown in fig. 7 (b). The first plugin also transmits the change information of the control flow graph to the sharing device, and the sharing device updates the obtained control flow graph according to the change information of the control flow graph as shown in fig. 7 (b).
In addition, in the step 404, the first plugin may also send an indication of the change of the M pieces of knowledge data to the sharing device. Here, the change indication may be used to indicate whether the corresponding knowledge data was derived based on an incremental analysis. For example, the change instruction occupies 1 bit (bit), and when the change instruction takes a value of 1, the corresponding knowledge data is indicated to be obtained based on incremental analysis; when the change indication value is 0, indicating that the corresponding knowledge data is not obtained based on incremental analysis. Correspondingly, when the first plug-in synchronizes M pieces of knowledge data to the sharing device, the value of the change instruction of each piece of knowledge data carried is 0, and when the first plug-in synchronizes M' incremental pieces of knowledge data to the sharing device, the value of the change instruction carried is 1.
It should be added that the sharing device also has basic code analysis capability. Illustratively, the sharing device obtains the code file, performs a basic analysis based on the code file, obtains basic data (such as abstract syntax trees and tokens) of the code, and then stores the basic data of the code in the knowledge database.
Furthermore, the sharing device can also obtain the affected code file (namely the code file needing to be subjected to incremental analysis) in the working space according to the change information of the code file, determine the change information of the basic data according to the affected code file in the working space, and update the basic data in the knowledge database according to the change information of the basic data. When the first plug-in needs to be analyzed, the latest basic data can be directly obtained from the knowledge database, and the latest basic data is further analyzed to obtain knowledge data.
Therefore, the plurality of plug-ins can acquire the basic data from the sharing device without respectively analyzing the code files to obtain the basic data first and analyzing the basic data to obtain the knowledge data, thereby being beneficial to reducing the calculation amount of the plug-ins.
Optionally, the sharing device may further send description information of m pieces of knowledge data recorded in the data statistics information to a front-end module, where the description information of the m pieces of knowledge data is displayed correspondingly.
The description information of the knowledge data is determined by the sharing device according to the registration information of the knowledge data. Illustratively, the description information of the knowledge data includes an identification, description, type, and data structure of the knowledge data.
The description information of the m knowledge data displayed in the front-end module can be used for a user to select knowledge data which can be directly accessed from the sharing device by the third plug-in when the third plug-in is developed. The third plug-in is arranged to request the knowledge data from the sharing device without analyzing the code file again, so that the computing resource is saved.
Alternatively, the user may query the front-end module for knowledge data that is currently registered in the sharing device, and specifically, the front-end module sends a data query request to the sharing device in response to a user instruction. And the sharing device sends the description information of the m pieces of knowledge data which are currently registered in the sharing device to the front-end module according to the data query request, and the front-end module displays the description information of the m pieces of knowledge data. And the user selects the knowledge data which can be directly requested from the sharing device by the third plug-in from the m knowledge data according to the description information of the m knowledge data displayed in the front-end module, and sets the identification of the selected knowledge data in the configuration of the third plug-in.
The second part is explained with reference to a flow diagram of the second plug-in requesting knowledge data from the sharing device, which is exemplarily shown in fig. 8:
in step 801, the second plug-in sends a data acquisition request to the sharing device, and correspondingly, the sharing device receives the data acquisition request from the second plug-in.
In one possible implementation, the second plug-in, when acting on a workspace, needs knowledge data (which may be referred to as target knowledge data) that depends on the code file in the workspace, such as a code index of the code file, static single assignments, control flow graphs, program dependency graphs, and the like. Accordingly, after the user invokes the second plug-in the front-end module, the second plug-in may request the target knowledge data from the sharing device.
In one possible implementation, the second plug-in determines an identity of the target knowledge data, including the identity of the target knowledge data in the data acquisition request. Correspondingly, the sharing device receives a data acquisition request from the second plug-in, and acquires the identification of the target knowledge data from the data acquisition request.
Step 802, the sharing device searches the knowledge database for the target knowledge data according to the identification of the target knowledge data in the data acquisition request. The target knowledge data is one of M knowledge data provided by the first plug-in, namely, the target knowledge data is obtained by analyzing the code file by the first plug-in.
In one possible implementation, the sharing device determines whether registration information of the target knowledge data is recorded in the data statistics information according to the identification of the target knowledge data. For example, if the sharing device determines that the identifier of the target knowledge data is recorded in the data statistics information, determining that the registration information of the target knowledge data is recorded in the data statistics information; if the sharing device determines that the identification of the target knowledge data is not recorded in the data statistics information, the sharing device determines that the registration information of the target knowledge data is not recorded in the data statistics information.
The sharing device searches the knowledge database for the target knowledge data after determining that the registration information of the knowledge data is recorded in the data statistics information. The sharing device obtains registration information of the target knowledge data from the data statistics information, and searches the target knowledge data from the knowledge database according to the address of the target knowledge data recorded in the registration information.
In step 803, the sharing device sends the target knowledge data to the second plug-in.
Accordingly, the second plug-in receives the target knowledge data from the sharing device. The second plug-in can develop the application program according to the target knowledge data without analyzing the code file of the application program.
Optionally, after receiving the target knowledge data from the sharing device, the second plug-in further sends a subscription request of the target knowledge data to the sharing device, where the subscription request is used for the second plug-in to obtain the change information of the target knowledge data from the sharing device. In one possible implementation, when the first plugin determines that the code file is changed, the first plugin determines change information of the target knowledge data, and sends the change information of the target knowledge data to the sharing device. Correspondingly, the sharing device sends the change information of the target knowledge data to the second plug-in unit.
In addition, the sharing device may send a response to the second plugin requesting failure in the case that the sharing device does not find the target knowledge data from the knowledge database according to the identification of the target knowledge data in the data acquisition request. Accordingly, after receiving the response of the request failure, the second plug-in analyzes the code file of the application program to obtain knowledge data of the code file. Optionally, the second plug-in may also register the knowledge data obtained by analysis into the sharing device, and the specific registration manner may be described in the related embodiment of fig. 4.
In one possible implementation, the sharing device includes a data registration module, a data upload module, a data query module, a data download module, and a knowledge database.
The data registration module is used for receiving a data registration request from the first plug-in, wherein the data registration request comprises registration information of M pieces of knowledge data, and the registration information of the knowledge data comprises identification, description, type and data structure of the knowledge data. The data registration module is further used for recording registration information of M pieces of knowledge data in the registration request in the data statistics information. Optionally, the data statistics are stored in the data registration module.
And the data uploading module is used for acquiring M pieces of knowledge data obtained by analyzing the code file of the application program of the first plug-in from the first plug-in, and storing the M pieces of knowledge data in the knowledge database.
And the data query module is used for searching the target knowledge data indicated in the data acquisition request from the knowledge database according to the data acquisition request of the second plugin.
And the data downloading module is used for downloading the target knowledge data by the second plug-in.
Based on the architecture diagram shown in fig. 3 and the data registration module, the data uploading module, the data query module and the data downloading module in the sharing device, two possible interaction diagrams for knowledge sharing are provided respectively in fig. 9 and 10.
It is noted in advance that a first insert is, for example, insert 1 and a second insert is, for example, insert 2. The sequence numbers 1 to 12 in fig. 9 indicate the order between the steps; the sequence numbers 1 to 4 in fig. 10 also indicate the order of the steps. Details not described in detail in fig. 9 and 10 can be described with reference to the related embodiments of fig. 4 to 8.
In the interaction diagram shown in fig. 9:
when the user opens a workspace in the front-end module, the plug-in module will automatically load plug-in 1 and plug-in 2.
Plug-in module when plug-in 1 is loaded, plug-in 1 sends registration information of the control flow graph (i.e., one example of knowledge data) to the data registration module. The data registration module stores registration information of the control flow graph in the data statistics.
Further, when the user invokes plug-in 1 in the front-end module, plug-in 1 analyzes the code file to obtain a control flow graph (i.e. an example of knowledge data), plug-in 1 uploads the control flow graph to the data uploading module, and the data uploading module correspondingly stores the control flow graph in the knowledge database. In addition, the plug-in 1 may also return the result 1 obtained by executing the service in the plug-in 1 to the front-end module according to the control flow graph by the plug-in 1.
When the user invokes the plug-in 2 in the front-end module, the target knowledge data to be acquired by the plug-in 2 is a control flow graph, the plug-in 2 sends a data acquisition request to the data query module, the data acquisition request comprises an identifier (such as codelf. Cfg in fig. 5) of the control flow graph, and correspondingly, the data query module acquires the control flow graph from the knowledge database according to the identifier of the control flow graph and sends the control flow graph to the plug-in 2. After the plugin 2 obtains the control flow graph, the control flow graph is obtained using the control flow graph without analyzing the code file of the application program. In addition, the plug-in 2 may also return the result 2 obtained by executing the service in the plug-in 2 to the front-end module according to the control flow graph.
In the interaction diagram shown in fig. 10:
in the process of developing the third plugin by the user, the front-end module can also respond to the instruction of inquiring knowledge data by the user and send a data inquiry request to the data inquiry module. The data query module sends the description information of the m pieces of knowledge data to the front-end module according to the data query request, and the front-end module displays the description information of the m pieces of knowledge data. The user can select the knowledge data which can be directly inquired from the sharing device by the third plug-in according to the description information of the m knowledge data displayed in the front-end module, and the identification of the selected knowledge data is arranged in the configuration of the third plug-in.
In addition, the application also provides a service sharing method which is applicable to an IDE architecture, wherein the IDE architecture comprises a sharing device and a development device, and the development device comprises a first plug-in and a second plug-in. The sharing device is respectively connected with the first plug-in unit and the second plug-in unit.
The IDE architecture schematic shown in connection with fig. 3, for example, the first card and the second card are card 1 and card 2, respectively, and for another example, the first card and the second card are card 1 and card K, respectively, and so on.
The first plug-in and the second plug-in may act on the same workspace, which includes code files for a certain application being developed, it being understood that the first plug-in and the second plug-in may be used to co-develop the application. The first plug-in can register the service which can be provided by the first plug-in into the sharing device. The second plug-in is capable of requesting to the sharing device to invoke the service provided by the first plug-in.
In this application, a first plug-in may be understood as the producer of a service and a second plug-in as the consumer of the service. It will also be appreciated that the first insert belongs to the production insert and the second insert belongs to the consumer insert.
The service sharing method provided in the present application is explained in two parts, wherein part 1: the first plug-in provides service for the sharing device; part 2: the second plug-in requests a service from the sharing device.
Part 1 is explained with reference to a flowchart of a first plug-in providing services to a sharing device, which is exemplarily shown in fig. 11:
in step 1101, the first plug-in sends a service registration request to the sharing device. Accordingly, the sharing device receives a service registration request from the first plug-in. The service registration request comprises registration information of N services provided by the first plug-in.
In one possible implementation, the first plug-in determines N services that the first plug-in can provide, where N is a positive integer, and where a service may be considered an atomic service, i.e., a minimum, non-resolvable service that the first plug-in can provide, and an atomic service may also be referred to as an atomic capability. Illustratively, the N atomic services that the first plug-in determines that the first plug-in can provide include a code automatic generation service and a code repair service.
Taking one of the N services as an example, the registration information of the service includes an identifier of the service and an interface address, where the interface address is used to call the service corresponding to the identifier. Optionally, the registration information of the service further includes one or more of description, type, calling parameter and return result of the service.
For example, the service provided by the first plugin is a code automatic generation service, and the registration information of the code automatic generation service may include an identifier "codelf. Generation" of the code automatic generation service, an interface address "API1" of the code automatic generation service, a description "code fragment of generation function level" of the code automatic generation service, a type "code generation" of the code automatic generation service, and a call parameter "cursor position" of the code automatic generation service: int: a cursor position; code context: JOSN: to generate code context ", the return result" generate "of the code automatic generation service: string: generating a code segment; position: int: the code location is inserted.
For another example, the service provided by the first plug-in is a code repair service, and the registration information of the code repair service may include an identifier "codelf. Fix" of the code repair service, an interface address "API2" of the code repair service, a description "repair code defect" of the code repair service, a type "code fix" of the code repair service, and a call parameter "code to be fix" of the code repair service: string: code segments to be repaired; code context: JOSN: code repair code context ", and return result of code repair service" is fixed: bool: whether repair is implemented; code after fix: string: post-repair code fragments).
In step 1102, the sharing device records registration information of N services provided by the first plugin.
In one possible implementation, the sharing device may first verify and authenticate the identity information of the source of the request (i.e. the first plugin) after receiving the service registration request, and obtain the registration information of the N services from the service registration request after determining that the identity information of the first plugin passes the verification and authentication.
Further, the sharing device includes service statistics information, and the sharing device may record registration information of the N services in the service statistics information. It will be appreciated that the service statistics have recorded therein registration information for n services provided by one or more production plug-ins. That is, the one or more production plug-ins include a first plug-in, and the registration information of the N services includes registration information of the N services, where N is an integer greater than or equal to N.
For example, both plugin a and plugin B belong to production plugins, plugin a sends a service registration request a to a sharing device, the service registration request a includes registration information of service 1 to service 10, and the sharing device records the registration information of service 1 to service 10 in service statistics information; the plug-in B sends a service registration request B to a sharing device, wherein the service registration request B comprises registration information from the service 11 to the service 20, and the sharing device records the registration information from the service 11 to the service 20 in service statistics information; the card B is a first card.
In step 1103, the sharing device generates N interface addresses that can be called by the second plug-in according to the interface addresses of the N services provided by the first plug-in.
Still taking one of the N services as an example, the interface address of the service provided by the first plug-in, specifically, the interface address (denoted as the first interface address) used for the sharing device to call the service provided by the first plug-in, that is, the sharing device may execute the operation corresponding to the service when calling the first interface address.
Further, the sharing device also needs to generate an interface address (denoted as a second interface address) in the sharing device for the second plug-in call corresponding to the first interface address.
In step 1104, the sharing device sends the generated N interface addresses (i.e., the second interface address) to the second plug-in. Correspondingly, the second plug-in acquires N interface addresses generated by the sharing device.
In one example, the sharing device sends the identification of the service and the second interface address of the service to the second plug-in.
In yet another example, the second plugin may send an interface address query request to the sharing device, where the interface address query request includes an identifier of the service, and the sharing device sends, to the second plugin, a second interface address of the service (or the identifier of the service and the second interface address of the service) according to the identifier of the service.
It can be appreciated that when the second plug-in needs to use the service, the second interface address may be requested to be called from the sharing device, and the sharing device may call the first interface address of the first plug-in according to the correspondence between the second interface address and the first interface address.
It should be added that the second plug-in may also obtain, from the sharing device, the second interface address of the service provided by the other production plug-in. The second plugin sends an interface address query request to the sharing device, and accordingly, the second plugin obtains, from the sharing device, the identifiers of the n services currently registered in the sharing device and the second interface address.
In addition, the sharing device may record the second interface address of the service in the service statistics after generating the second interface address of the service.
In combination with the above example, when the service is the code automatic generation service, the first interface address of the code automatic generation service is API1, the sharing device generates that the second interface address corresponding to API1 is API1-1, and the sharing device records API1-1 in the service statistics information. When the service is a code repair service, the first interface address of the code repair service is API2, the sharing device generates that the second interface address corresponding to the API2 is API2-1, and the sharing device records the API2-1 in the service statistics.
The service statistics information is, for example, a service registry, as shown in fig. 12, which is a schematic diagram of the service registry provided by the present application, for example, the service registry includes registration information of the code automatic generation service, and a second interface address of the code automatic generation service; the service registry also includes registration information for the code repair service and a second interface address for the code repair service. In fig. 12, fields in the registration information are described with reference to step 1001.
In one possible implementation, the sharing device may further send the description information of the n services in the service statistics to the second plugin. Optionally, the second plugin sends a service query request to the sharing device, and the sharing device sends description information of n services to the second plugin. The second plug-in acquires second interface addresses of the n services from the description information of the n services.
Optionally, the sharing device may further send description information of n services in the service statistics information to the front end module, where the description information of the n services is displayed correspondingly.
Wherein the description information of the service is determined by the sharing device according to the registration information of the service. Illustratively, the description information of the service includes an identification, description, type, calling parameters and returned results of the service.
The description information of the n services displayed in the front-end module can be used for a user to select the service which can be directly called from the sharing device by the third plug-in when the third plug-in is developed. It is understood that the sharing device may display the description information of the n services registered in the sharing device in the front-end module, and the user may learn which services can be directly called from the sharing device in the process of developing the third plug-in, so that the third plug-in is set to call the services from the sharing device, without implementing the services in the third plug-in. In this way, avoiding the implementation of the same service in multiple plug-ins helps to save computing resources.
Alternatively, the user may query the front-end module for n services that are currently registered in the sharing device, and specifically, the front-end module sends a service query request to the sharing device in response to a user instruction. The sharing device sends the description information of the n services currently registered in the sharing device to the front-end module according to the service query request, and the front-end module displays the description information of the n services. And the user selects a service which can be directly called from the sharing device by the third plug-in from the n services according to the description information of the n services displayed by the front-end module, and sets the identification of the selected service in the configuration of the third plug-in.
Part 2 is explained with reference to a flowchart of the second plug-in requesting a service from the sharing device, which is exemplarily shown in fig. 13:
in step 1301, the second plug-in sends a service call request to the sharing device, and correspondingly, the sharing device receives the service call request from the second plug-in.
In one possible implementation, after the user invokes the second plug-in the front-end module, the second plug-in sends a service invocation request to the sharing device. Wherein the service call request includes a second interface address of a service (denoted as a target service) called by the second plug-in request. Optionally, the service call request further includes an identifier of the target service.
In connection with the related example in fig. 12, the target service is a code automatic generation service, and the second plug-in sends a service call request to the sharing device, where the service call request includes a second interface address "API1-1" of the code automatic generation service, or the service call request includes an identifier "codellf. Generate" of the code automatic generation service and a second interface address "API1-1".
In step 1302, the sharing device determines the first interface address of the target service according to the second interface address of the target service in the service call request.
The service statistics information of the sharing device records registration information of n services currently registered and second interface addresses of the n services. The sharing device searches the registration information of the target service from the service statistics information according to the second interface address of the target service, and then acquires the first interface address of the target service from the registration information of the target service.
It may also be understood that the service statistics information of the sharing device records the correspondence between the first interface addresses and the second interface addresses of the n services currently registered. And the sharing device determines the first interface address corresponding to the second interface address of the target service from the service statistical information according to the second interface address of the target service.
In step 1303, the sharing device invokes the target service provided by the first plug-in according to the first interface address of the target service.
In step 1304, the first plugin executes an operation corresponding to the target service on the workspace, thereby obtaining an operation result.
For example, the target service is a code auto-generation service, and the first plug-in executes the code auto-generation service on the workspace, that is, the executed operation is an auto-generation code, that is, the operation result corresponding to the target service.
In step 1305, the first plug-in sends the operation result to the sharing device. Accordingly, the sharing device receives the operation result from the first plug-in.
In step 1306, the sharing device sends the operation result to the second plug-in.
In one possible implementation, the sharing device includes a service registration module, a service discovery module, and a service invocation module.
The service registration module is configured to receive a service registration request from the first plugin, where the service registration request includes registration information of N services, and each piece of registration information of the service includes, for example, an identifier of the service, an interface address (i.e., a first interface address), a description, a type, a call parameter, and a return result. The service registration module is also used for recording registration information of the N services in the service statistical information; and generating a second interface address of the service according to the first interface address of the service, and recording the second interface address of the service in the service statistics information.
And the service discovery module is used for receiving an interface address query request from the second plugin, wherein the interface address query request comprises an identification of a target service called by the second plugin request. The service discovery module is further configured to send, to the second plug-in, a second interface address of the target service according to the identifier of the target service.
The service calling module is used for receiving a service calling request of the second plugin, acquiring a second interface address of a target service called by the second plugin request from the service calling request, determining a first interface address corresponding to the second interface address from the service statistical information, and dispatching the target service provided by the first plugin according to the first interface address.
Based on the architecture diagram shown in fig. 3 and the service registration module, the service discovery module and the service invocation module in the sharing device, two possible interaction diagrams of service sharing are provided as shown in fig. 14 and 15, respectively.
It is noted in advance that a first insert is, for example, insert 1 and a second insert is, for example, insert 2. The sequence numbers 1 to 9 in fig. 14 indicate the order between the steps; the sequence numbers 1 to 4 in fig. 15 also indicate the order of the steps. Details not described in detail in fig. 14 and 15 can be described with reference to the related embodiments of fig. 11 to 13.
In the interaction diagram shown in fig. 14:
when the user opens a workspace in the front-end module, the plug-in module will automatically load plug-in 1 and plug-in 2.
Plug-in module when loading plug-in 1, plug-in 1 sends registration information of code automatic generation service (i.e. one example of service) to service registration module, and correspondingly, service registration module stores registration information of code automatic generation service in service statistics information.
When loading the plug-in 2, the plug-in 2 sends an interface address query request to the service discovery module, where the interface address query request includes an identifier of the code automatic generation service (such as codelf. Generate in fig. 12), and correspondingly, the service discovery module determines, according to the identifier of the code automatic generation service and the service statistics information, a second interface address of the code automatic generation service. The service discovery module returns a code to the second plug-in to automatically generate a second interface address for the service.
When the user calls the plug-in 2 in the front-end module, the plug-in 2 sends a service call request to the service call module, the service call request comprises a second interface address of the code automatic generation service, and correspondingly, the service call module determines a first interface address corresponding to the second interface address according to the second interface address included in the service call request, and further automatically generates the service according to the first interface address call code. The plug-in 1 performs an operation corresponding to the code space automatic generation service, that is, automatically generates a code in the code space. Subsequently, the plug-in 1 sends the operation result to the service call module, the service call module further sends the operation result to the plug-in 2, and the plug-in 2 returns the operation result to the front-end module.
In the interaction diagram shown in fig. 15:
in the process of developing the third plugin by the user, the front-end module can also respond to the instruction of inquiring the service by the user and send a service inquiry request to the service discovery module. The service discovery module sends the description information of the n services to the front-end module according to the service query request, and the front-end module displays the description information of the n services. The user can select the service which can be directly called by the third plug-in from the sharing device according to the description information of the n services displayed in the front-end module, and the identifier of the selected service is set in the configuration of the third plug-in.
Based on the same inventive concept, the present application further provides a sharing device 1600, where the sharing device 1600 may be used to implement the method in the above-mentioned embodiments of the methods related to fig. 4 to fig. 10, that is, to implement knowledge data sharing between plugins. The sharing device 1600 is suitable for use in an IDE architecture, which includes the sharing device 1600, a first plug-in and a second plug-in. The sharing device 1600 is, for example, the sharing device of fig. 3.
The sharing device 1600 stores M pieces of knowledge data provided by the first card, where M is a positive integer.
As shown in fig. 16, the sharing apparatus 1600 includes:
A data query module 1601, configured to receive a data acquisition request of a second plugin; searching target knowledge data from M knowledge data according to the data acquisition request;
the data download module 1602 is configured to send the target knowledge data to the second plug-in.
In one possible implementation, the sharing device 1600 further includes: a data registration module 1603; before the data query module 1601 receives a data acquisition request of the second plugin, the data registration module 1603 is configured to receive a data registration request of the first plugin, where the data registration request includes an identifier of M pieces of knowledge data; the identity of the M knowledge data is recorded.
In one possible implementation, the sharing device 1600 further includes: a data upload module 1604; after the data registration module 1603 records the identity of the M knowledge data, the data upload module 1604 is configured to: m pieces of knowledge data are obtained from the first plug-in unit, and the M pieces of knowledge data are stored; the M knowledge data are obtained by analyzing code files in the working space by the first plug-in; or, the M pieces of knowledge data are obtained by analyzing basic data by the first plug-in, where the basic data are obtained by analyzing a code file in the working space by the sharing device 1600; the first plug-in and the second plug-in act together in the working space; the basic data is one or more items in abstract grammar tree and token sequence; the M pieces of knowledge data comprise one or more of code indexes, static single assignment, control flow graphs and program dependency graphs.
In one possible implementation, after the data upload module 1604 stores M pieces of knowledge data, it is further configured to: acquiring change information of M' knowledge data from a first plug-in; updating M 'knowledge data in the M knowledge data according to the change information of the M' knowledge data; the change information of the M' knowledge data is obtained by performing incremental analysis on the first plugin according to the change information of the code file in the working space; alternatively, the change information of the M' pieces of knowledge data is obtained by performing incremental analysis by the first plug-in based on the change information of the basic data, and the change information of the basic data is obtained by performing incremental analysis by the sharing device 1600 based on the change information of the code file in the workspace.
In one possible implementation, after the data download module 1602 sends the target knowledge data to the second plug-in, it is further configured to: receiving a subscription request of the second plugin for the target knowledge data, wherein the subscription request is used for the second plugin to acquire change information of the target knowledge data; accordingly, after the data upload module 1604 receives the change information of the target knowledge data from the first plugin, the data download module 1602 is further configured to send the change information of the target knowledge data to the second plugin.
In one possible implementation manner, m pieces of knowledge data provided by a production plug-in are stored in the sharing device 1600, where the production plug-in includes a first plug-in, and m is a positive integer; in the process of developing the third plugin by the user, the data query module 1601 is further configured to: the description information of the m pieces of knowledge data is sent to the front-end module, so that the user selects knowledge data that the third plug-in can obtain from the sharing device 1600 from the m pieces of knowledge data according to the description information of the m pieces of knowledge data displayed by the front-end module.
It should be noted that, in other embodiments, the data query module 1601 may be configured to perform any of the method embodiments related to fig. 4 to 10, the data download module 1602 may be configured to perform any of the method embodiments related to fig. 4 to 10, the data registration module 1603 may be configured to perform any of the method embodiments related to fig. 4 to 10, and the data upload module 1604 may be configured to perform any of the method embodiments related to fig. 4 to 10. It can be appreciated that the steps that the data query module 1601, the data download module 1602, the data registration module 1603 and the data upload module 1604 are responsible for implementing may be specified as required, and the data query module 1601, the data download module 1602, the data registration module 1603 and the data upload module 1604 implement the different steps in the related method embodiments of fig. 4 to 10, respectively, to implement the overall functions of the sharing device 1600 in fig. 16.
Based on the same inventive concept, the present application further provides a sharing apparatus 1700, where the sharing apparatus 1700 may be used to implement the methods in the above-described embodiments of the methods related to fig. 11 to 15, that is, to implement service sharing between the plugins. The sharing device 1700 is suitable for use in an IDE architecture that includes the sharing device 1700, a first plug-in, and a second plug-in. The sharing apparatus 1700 is, for example, the sharing apparatus in fig. 3.
As shown in fig. 17, the sharing apparatus 1700 includes:
a service registration module 1701, configured to register N services provided by the first plugin, where N is a positive integer;
a service calling module 1702 configured to receive a service calling request of a second plugin; according to the service calling request, calling a target service in the N services;
the service calling module 1702 is further configured to receive an operation result obtained by providing the target service by the first plug-in; and sending the operation result to the second plug-in.
In one possible implementation, the first plug-in and the second plug-in act on the same workspace, with the result that the first plug-in provides the target service to the workspace.
In one possible implementation, before the service invocation module 1702 receives the service invocation request of the second plugin, the service registration module 1701 is configured to: receiving a service registration request of a first plugin, wherein the service registration request comprises first interface addresses of N services, and the first interface addresses of the services are used for calling the services by the sharing device 1700; generating second interface addresses of the N services according to the first interface addresses of the N services, wherein the second interface addresses of the services are used for calling the services by the second plug-in; the first interface address and the second interface address of the N services are recorded.
In one possible implementation, the method further includes: a service discovery module 1703; after the service registration module 1701 records the first interface address and the second interface address of the N services, the service discovery module 1703 is configured to: receiving a service query request of the second plugin, wherein the service query request comprises an identifier of a target service, and N services comprise the target service; and sending the second interface address of the target service to the second plug-in.
In one possible implementation, the service invocation module 1702 is specifically configured to, when invoking a target service of the N services according to the service invocation request: determining a first interface address of the target service according to a second interface address of the target service in the service call request; and calling the target service according to the first interface address of the target service.
In one possible implementation, n services provided by a production plugin are registered in the service registration module 1701, where the production plugin includes a first plugin, and n is a positive integer; the sharing apparatus 1700 further includes: a service discovery module 1703; in the process of developing the third plug-in by the user, the service discovery module 1703 is configured to: the description information of the n services is sent to the front-end module, so that the user selects, from the n services, a service that the third plug-in can call from the sharing apparatus 1700 according to the description information of the n services displayed by the front-end module.
It should be noted that, in other embodiments, the service registration module 1701 may be configured to perform any step of the method embodiments related to fig. 11 to 15, the service invocation module 1702 may be configured to perform any step of the method embodiments related to fig. 11 to 15, and the service discovery module 1703 may be configured to perform any step of the method embodiments related to fig. 11 to 15. It will be appreciated that the steps that the service registration module 1701, the service invocation module 1702 and the service discovery module 1703 are responsible for implementing may be specified as required, and that the service registration module 1701, the service invocation module 1702 and the service discovery module 1703 implement different steps in the related method embodiments of fig. 11 to 15, respectively, to implement all the functions of the sharing apparatus 1700 in fig. 17.
In the related embodiment of fig. 16, the data query module 1601, the data download module 1602, the data registration module 1603, and the data upload module 1604 may all be implemented by software or may be implemented by hardware. In the related embodiment of fig. 17, the service registration module 1701, the service invocation module 1702, and the service discovery module 1703 may all be implemented by software or may be implemented by hardware.
Next, taking the data query module 1601 as an example, an implementation of the data query module 1601 is described. Similarly, the implementation of the data downloading module 1602, the data registering module 1603 and the data uploading module 1604 in the related embodiment of fig. 16 may refer to the implementation of the data querying module 1601. Similarly, the implementation of the service registration module 1701, the service invocation module 1702, and the service discovery module 1703 in the related embodiment of fig. 17 may also refer to the implementation of the data query module 1601.
Module as an example of a software functional unit, the data query module 1601 may include code that runs on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container, among others. Further, the above-described computing examples may be one or more. For example, the data query module 1601 may include code running on multiple hosts/virtual machines/containers. It should be noted that, multiple hosts/virtual machines/containers for running the code may be distributed in the same region (region), or may be distributed in different regions. Further, multiple hosts/virtual machines/containers for running the code may be distributed in the same availability zone (availability zone, AZ) or may be distributed in different AZs, each AZ comprising a data center or multiple geographically close data centers. Wherein typically a region may comprise a plurality of AZs.
Also, multiple hosts/virtual machines/containers for running the code may be distributed in the same virtual private cloud (virtual private cloud, VPC) or in multiple VPCs. In general, one VPC is disposed in one region, and a communication gateway is disposed in each VPC for implementing inter-connection between VPCs in the same region and between VPCs in different regions.
Module as an example of a hardware functional unit, the data query module 1601 may include at least one computing device, such as a server or the like. Alternatively, the data query module 1601 may be a device or the like implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (programmable logic device, PLD). The PLD may be implemented as a complex program logic device (complex programmable logical device, CPLD), a field-programmable gate array (FPGA), a general-purpose array logic (generic array logic, GAL), or any combination thereof.
The multiple computing devices included in the data query module 1601 may be distributed in the same region or may be distributed in different regions. The plurality of computing devices included in the data query module 1601 may be distributed in the same AZ or may be distributed in different AZ. Likewise, the multiple computing devices included in the data query module 1601 may be distributed in the same VPC or may be distributed in multiple VPCs. Wherein the plurality of computing devices may be any combination of computing devices such as servers, ASIC, PLD, CPLD, FPGA, and GAL.
The present application also provides a sharing system, as shown in fig. 18, where the sharing system includes: the sharing apparatus 1600 in fig. 16 and the sharing apparatus 1700 in fig. 17. It will also be appreciated that the sharing device 1600 may be used to implement the methods described above in connection with the method embodiments of fig. 4-10; the sharing apparatus 1700 may be used to implement the methods described above in connection with the method embodiments of fig. 11-15.
Both sharing device 1600 and sharing device 1700 may be implemented by software, or may be implemented by hardware. By way of example, an implementation of the sharing device 1600 is described next. Similarly, the implementation of sharing apparatus 1700 may refer to the implementation of sharing apparatus 1600.
Modules as one example of a software functional unit, the shared device 1600 may include code running on a computing instance. Wherein the computing instance may be at least one of a physical host (computing device), a virtual machine, a container, etc. computing device. Further, the computing device may be one or more. For example, the shared device 1600 may include code running on multiple hosts/virtual machines/containers. It should be noted that, multiple hosts/virtual machines/containers for running the application may be distributed in the same region, or may be distributed in different regions. Multiple hosts/virtual machines/containers for running the code may be distributed among the same AZ or among different AZs, each AZ including one data center or multiple geographically close data centers. Wherein typically a region may comprise a plurality of AZs.
Also, multiple hosts/virtual machines/containers for running the code may be distributed in the same VPC, or may be distributed among multiple VPCs. Where typically one VPC is placed within one region. The inter-region communication between two VPCs in the same region and between VPCs in different regions needs to set a communication gateway in each VPC, and the interconnection between the VPCs is realized through the communication gateway.
Modules as an example of hardware functional units, the sharing apparatus 1600 may include at least one computing device, such as a server or the like. Alternatively, the sharing device 1600 may be a device implemented by ASIC or PLD. Wherein, the PLD can be CPLD, FPGA, GAL or any combination thereof.
The plurality of computing devices included in the shared apparatus 1600 may be distributed in the same region or may be distributed in different regions. The plurality of computing devices included in the sharing apparatus 1600 may be distributed in the same AZ or may be distributed in different AZ. Likewise, multiple computing devices included in the sharing apparatus 1600 may be distributed in the same VPC, or may be distributed among multiple VPCs. Wherein the plurality of computing devices may be any combination of computing devices such as servers, ASIC, PLD, CPLD, FPGA, and GAL.
The present application also provides a computing device 100. As shown in fig. 19, the computing device 100 includes: a processor 101, a bus 102, a memory 103, and a communication interface 104. The processor 101, memory 103, and communication interface 104 communicate via bus 102. Computing device 100 may be a server or a terminal device. It should be understood that the present application is not limited to the number of processors, memories in computing device 100.
Bus 102 may be a peripheral component interconnect standard (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, only one line is shown in fig. 19, but not only one bus or one type of bus. Bus 104 may include a path for transferring information between various components of computing device 100 (e.g., memory 103, processor 101, communication interface 104).
The processor 101 may include any one or more of a central processing unit (central processing unit, CPU), a graphics processor (graphics processing unit, GPU), a Microprocessor (MP), or a digital signal processor (digital signal processor, DSP).
The memory 103 may include volatile memory (RAM), such as random access memory (random access memory). The processor 101 may also include a non-volatile memory (non-volatile memory), such as read-only memory (ROM), flash memory, a mechanical hard disk (HDD) or a solid state disk (solid state drive, SSD).
The memory 103 stores executable program codes, and the processor 101 executes the executable program codes to implement the functions of the aforementioned data query module 1601, data download module 1602, data registration module 1603, and data upload module 1604, respectively, so as to implement the methods in the aforementioned method embodiments related to fig. 4 to 10. That is, the memory 103 has stored thereon instructions for performing the methods of the embodiments of the methods related to fig. 4-10.
Alternatively, the memory 103 stores executable program codes, and the processor 101 executes the executable program codes to implement the functions of the service registration module 1701, the service invocation module 1702 and the service discovery module 1703, respectively, so as to implement the methods in the above-described method embodiments related to fig. 11 to 15. That is, the memory 103 has stored thereon instructions for performing the methods of the related method embodiments of fig. 11-15.
Alternatively, the memory 103 stores executable program codes, and the processor 101 executes the executable program codes to implement the functions of the sharing device 1600 and the sharing device 1700, respectively, so as to implement the methods in the above-mentioned method embodiments related to fig. 4 to 15. That is, the memory 103 has stored thereon instructions for performing the methods of the embodiments of the methods related to fig. 4-15.
Communication interface 104 enables communication between computing device 100 and other devices or communication networks using a transceiver module such as, but not limited to, a network interface card, transceiver, or the like.
The embodiment of the application also provides a computing device cluster. The cluster of computing devices includes at least one computing device. The computing device may be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device may also be a terminal device such as a desktop, notebook, or smart phone.
As shown in fig. 20, a cluster of computing devices includes at least one computing device 100.
In some possible implementations, the same instructions for performing the embodiments of the methods related to fig. 4-10 may be stored in memory 103 in one or more computing devices 100 in a computing device cluster. In some possible implementations, some of the instructions for performing the method embodiments related to fig. 4-10 may also be stored in the memory 103 of one or more computing devices 100 in the computing device cluster, respectively. In other words, a combination of one or more computing devices 100 may collectively execute instructions for use in embodiments of the methods related to fig. 4-10.
Alternatively, the same instructions for performing the methods of the related method embodiments of fig. 11-15 may be stored in memory 103 in one or more computing devices 100 in a computing device cluster. In some possible implementations, part of the instructions for performing the relevant method embodiments of fig. 11-15 may also be stored in the memory 103 of one or more computing devices 100 in the computing device cluster, respectively. In other words, a combination of one or more computing devices 100 may collectively execute instructions for use in embodiments of the methods related to fig. 11-15.
Alternatively, the same instructions for performing the method embodiments of the related methods of fig. 4-15 may be stored in memory 103 in one or more computing devices 100 in a computing device cluster. In some possible implementations, some of the instructions for performing the method embodiments related to fig. 4-15 may also be stored in the memory 103 of one or more computing devices 100 in the computing device cluster, respectively. In other words, a combination of one or more computing devices 100 may collectively execute instructions for use in embodiments of the methods related to fig. 4-15.
The following is an example of a cluster of computing devices for performing the method embodiments related to fig. 4-10:
The memories 103 in different computing devices 100 in a cluster of computing devices may store different instructions for performing part of the functions of the shared apparatus 1600, respectively. That is, the instructions stored by the memory 103 in the different computing devices 100 may implement the functionality of one or more of the data query module 1601, the data download module 1602, the data registration module 1603, and the data upload module 1604.
In some possible implementations, one or more computing devices in a cluster of computing devices may be connected through a network. Wherein the network may be a wide area network or a local area network, etc.
Fig. 20 shows one possible implementation. As shown in fig. 20, two computing devices 100A and 100B are connected by a network. Specifically, the connection to the network is made through a communication interface in each computing device. In this type of possible implementation, instructions to perform the functions of the data query module 1601 and the data download module 1602 are stored in the memory 103 in the computing device 100A. Meanwhile, instructions to perform the functions of the data registration module 1603 and the data upload module 1604 are stored in the memory 103 in the computing device 100B.
It should be appreciated that the functionality of computing device 100A shown in fig. 20 may also be performed by multiple computing devices 100. Likewise, the functionality of computing device 100B may also be performed by multiple computing devices 100.
Embodiments of the present application also provide a computer program product comprising instructions. The computer program product may be a software or program product containing instructions capable of running on a computing device or stored in any useful medium. The computer program product, when executed on at least one computing device, causes the at least one computing device to perform the method of the method embodiments of fig. 4-10, or to perform the instructions of the method embodiments of fig. 11-15, or to perform the instructions of the method embodiments of fig. 4-15.
Embodiments of the present application also provide a computer-readable storage medium. Computer readable storage media can be any available media that can be stored by a computing device or data storage device such as a data center containing one or more available media. Usable media may be magnetic media (e.g., floppy disks, hard disks, magnetic tape), optical media (e.g., DVD), or semiconductor media (e.g., solid state disk), among others. The computer readable storage medium includes instructions that instruct a computing device to perform the method of the related method embodiments of fig. 4-10, or to perform the method of the related method embodiments of fig. 11-15, or to perform the method of the related method embodiments of fig. 4-15.
Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and are not limiting; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; these modifications or substitutions do not depart from the essence of the corresponding technical solutions from the protection scope of the technical solutions of the embodiments of the present invention.
Claims (28)
1. The sharing method is characterized by being suitable for an integrated development environment IDE architecture, wherein the IDE architecture comprises a sharing device, a first plug-in and a second plug-in;
m pieces of knowledge data provided by the first plug-in are stored in the sharing device, wherein M is a positive integer;
the method comprises the following steps:
the sharing device receives a data acquisition request of the second plug-in;
the sharing device searches target knowledge data from the M knowledge data according to the data acquisition request;
the sharing device sends the target knowledge data to the second plug-in.
2. The method of claim 1, wherein prior to the sharing device receiving the data acquisition request of the second plug-in, further comprising:
The sharing device receives a data registration request of the first plug-in, wherein the data registration request comprises identifications of the M pieces of knowledge data;
the sharing device records the identification of the M pieces of knowledge data.
3. The method of claim 2, wherein after the sharing device records the identity of the M pieces of knowledge data, further comprising:
the sharing device acquires the M pieces of knowledge data from the first plug-in;
the sharing device stores the M pieces of knowledge data;
the M knowledge data are obtained by analyzing code files in a working space by the first plug-in; or the M pieces of knowledge data are obtained by analyzing basic data by the first plug-in, wherein the basic data are obtained by analyzing code files in the working space by the sharing device;
the first insert and the second insert act together in the workspace;
the basic data is one or more items in an abstract syntax tree and token sequence;
the M knowledge data comprises one or more of a code index, a static single assignment, a control flow graph and a program dependency graph.
4. The method of claim 3, wherein after the sharing device stores the M pieces of knowledge data, further comprising:
The sharing device acquires the change information of M' knowledge data from the first plug-in unit;
the sharing device updates M 'knowledge data in the M knowledge data according to the change information of the M' knowledge data;
the change information of the M' knowledge data is obtained by performing incremental analysis on the first plug-in according to the change information of the code file in the working space; or,
the change information of the M' knowledge data is obtained by performing incremental analysis on the first plug-in according to the change information of the basic data, and the change information of the basic data is obtained by performing incremental analysis on the sharing device according to the change information of the code file in the working space.
5. The method of claim 1, wherein after the sharing device sends the target knowledge data to the second plug-in, further comprising:
the sharing device receives a subscription request of the second plug-in to the target knowledge data, wherein the subscription request is used for acquiring change information of the target knowledge data;
the sharing device transmits the change information of the target knowledge data to the second plug-in after receiving the change information of the target knowledge data from the first plug-in.
6. The method of any one of claims 1-5, wherein m knowledge data provided by a production plug-in is stored in the sharing device, wherein the production plug-in comprises the first plug-in, and m is a positive integer;
in the process of developing the third plug-in by the user, the method further comprises:
the sharing device sends the description information of the m pieces of knowledge data to a front-end module, so that the user selects knowledge data which can be acquired from the sharing device by the third plug-in from the m pieces of knowledge data according to the description information of the m pieces of knowledge data, which is displayed by the front-end module.
7. The sharing method is characterized by being suitable for an integrated development environment IDE architecture, wherein the IDE architecture comprises a sharing device, a first plug-in and a second plug-in;
the sharing device is registered with N services provided by the first plug-in, wherein N is a positive integer;
the method comprises the following steps:
the sharing device receives a service call request of the second plug-in;
the sharing device calls target service in the N services according to the service call request;
the sharing device receives an operation result obtained by the first plug-in providing the target service;
The sharing device sends the operation result to the second plug-in.
8. The method of claim 7, wherein the first plug-in and the second plug-in act on the same workspace, the result of the operation being that the first plug-in provides the target service to the workspace.
9. The method of claim 7, wherein prior to the sharing device receiving the service invocation request of the second plugin, further comprising:
the sharing device receives a service registration request of the first plug-in, wherein the service registration request comprises first interface addresses of the N services, and the first interface addresses of the services are used for the sharing device to call the services;
the sharing device generates second interface addresses of the N services according to the first interface addresses of the N services, wherein the second interface addresses of the N services are used for the second plug-in to call the services;
the sharing device records the first interface address and the second interface address of the N services.
10. The method of claim 9, wherein after the sharing device records the first interface address and the second interface address of the N services, further comprising:
The sharing device receives a service query request of the second plug-in, wherein the service query request comprises the identification of the target service;
the sharing device sends a second interface address of the target service to the second plug-in.
11. The method of claim 9, wherein the sharing means invoking the target service of the N services according to the service invocation request, comprises:
the sharing device determines a first interface address of the target service according to a second interface address of the target service in the service call request;
and the sharing device calls the target service according to the first interface address of the target service.
12. The method according to any of claims 7-11, wherein n services provided by a production plug-in are registered in the sharing device, the production plug-in comprising the first plug-in, n being a positive integer;
in the process of developing the third plug-in by the user, the method further comprises:
and the sharing device sends the description information of the n services to a front-end module, so that the user selects the service which can be called from the sharing device by the third plug-in from the n services according to the description information of the n services, which is displayed by the front-end module.
13. A sharing device, adapted to an integrated development environment, IDE, architecture, the IDE architecture comprising the device, a first plug-in, and a second plug-in;
m pieces of knowledge data provided by the first plug-in are stored in the device, wherein M is a positive integer;
the device comprises:
the data query module is used for receiving a data acquisition request of the second plug-in; searching target knowledge data from the M knowledge data according to the data acquisition request;
and the data downloading module is used for sending the target knowledge data to the second plug-in.
14. The apparatus of claim 13, wherein the apparatus further comprises: a data registration module;
the data registration module is used for:
before the data query module receives a data acquisition request of the second plugin, receiving a data registration request of the first plugin, wherein the data registration request comprises identifications of the M pieces of knowledge data;
and recording the identification of the M pieces of knowledge data.
15. The apparatus of claim 14, wherein the apparatus further comprises: a data uploading module;
after the data registration module records the identities of the M pieces of knowledge data, the data uploading module is configured to: acquiring the M pieces of knowledge data from the first plug-in, and storing the M pieces of knowledge data;
The M knowledge data are obtained by analyzing code files in a working space by the first plug-in; or the M pieces of knowledge data are obtained by analyzing basic data by the first plug-in, wherein the basic data are obtained by analyzing a code file in the working space by the device;
the first insert and the second insert act together in the workspace;
the basic data is one or more items in an abstract syntax tree and token sequence;
the M knowledge data comprises one or more of a code index, a static single assignment, a control flow graph and a program dependency graph.
16. The apparatus of claim 15, wherein the data upload module, after storing the M pieces of knowledge data, is further to:
acquiring change information of M' knowledge data from the first plug-in;
updating M 'knowledge data in the M knowledge data according to the change information of the M' knowledge data;
the change information of the M' knowledge data is obtained by performing incremental analysis on the first plug-in according to the change information of the code file in the working space; or,
The change information of the M' knowledge data is obtained by performing incremental analysis on the first plug-in according to the change information of the basic data, and the change information of the basic data is obtained by performing incremental analysis on the device according to the change information of the code file in the working space.
17. The apparatus of claim 13, wherein the data download module, after sending the target knowledge data to the second plug-in, is further to:
receiving a subscription request of the second plug-in to the target knowledge data, wherein the subscription request is used for acquiring change information of the target knowledge data;
and after the data uploading module receives the change information of the target knowledge data from the first plug-in, the data uploading module sends the change information of the target knowledge data to the second plug-in.
18. The apparatus of any one of claims 13-17, wherein m knowledge data provided by a production plugin is stored in the apparatus, the production plugin including the first plugin, m being a positive integer;
in the process of developing the third plugin by the user, the data query module is further configured to:
and sending the description information of the m pieces of knowledge data to a front-end module, so that the user selects knowledge data which can be acquired from the device by the third plug-in from the m pieces of knowledge data according to the description information of the m pieces of knowledge data, which is displayed by the front-end module.
19. A sharing device, adapted to an integrated development environment, IDE, architecture, the IDE architecture comprising the device, a first plug-in, and a second plug-in;
the device comprises:
the service registration module is used for registering N services provided by the first plug-in, wherein N is a positive integer;
the service calling module is used for receiving a service calling request of the second plug-in; according to the service calling request, calling a target service in the N services; receiving an operation result obtained by providing the target service by the first plug-in; and sending the operation result to the second plug-in.
20. The apparatus of claim 19, wherein the first plug-in and the second plug-in act on the same workspace, the result of the operation being that the first plug-in provides the target service to the workspace.
21. The apparatus of claim 19, wherein the service registration module is to, prior to the service invocation module receiving the service invocation request of the second plug-in:
receiving a service registration request of the first plug-in, wherein the service registration request comprises first interface addresses of the N services, and the first interface addresses of the services are used for the device to call the services;
Generating second interface addresses of the N services according to the first interface addresses of the N services, wherein the second interface addresses of the services are used for the second plug-in to call the services;
and recording the first interface addresses and the second interface addresses of the N services.
22. The apparatus as recited in claim 21, further comprising: a service discovery module;
after the service registration module records the first interface address and the second interface address of the N services, the service discovery module is configured to:
receiving a service query request of the second plug-in, wherein the service query request comprises the identification of the target service;
and sending a second interface address of the target service to the second plug-in.
23. The apparatus of claim 21, wherein when the service invocation module invokes a target service of the N services according to the service invocation request, the service invocation module is specifically configured to:
determining a first interface address of the target service according to a second interface address of the target service in the service call request;
and calling the target service according to the first interface address of the target service.
24. The apparatus of any of claims 19-23, wherein n services provided by a production plug-in are registered in the service registration module, the production plug-in including the first plug-in, n being a positive integer;
the apparatus further comprises: a service discovery module;
in the process of developing the third plugin by the user, the service discovery module is used for:
and sending the description information of the n services to a front-end module, so that the user selects the service which can be called from the device by the third plug-in from the n services according to the description information of the n services displayed by the front-end module.
25. A cluster of computing devices, comprising at least one computing device, each computing device comprising a processor and a memory;
the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method of any one of claims 1-6 or to cause the cluster of computing devices to perform the method of any one of claims 7-12.
26. A computer program product containing instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the method of any of claims 1-6 or cause the cluster of computing devices to perform the method of any of claims 7-12.
27. A computer readable storage medium comprising computer program instructions which, when executed by a cluster of computing devices, perform the method of any of claims 1-6 or cause the cluster of computing devices to perform the method of any of claims 7-12.
28. A sharing system, the system comprising: the device of any one of claims 13-18, and the device of any one of claims 19-24.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/CN2023/102351 WO2024021952A1 (en) | 2022-07-28 | 2023-06-26 | Sharing method and device |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210901542 | 2022-07-28 | ||
| CN2022109015420 | 2022-07-28 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117519814A true CN117519814A (en) | 2024-02-06 |
Family
ID=89744457
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211083725.2A Pending CN117519814A (en) | 2022-07-28 | 2022-09-06 | Sharing method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117519814A (en) |
-
2022
- 2022-09-06 CN CN202211083725.2A patent/CN117519814A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109885311B (en) | Application program generation method and device | |
| CN107066242B (en) | Method and system for determining identification of software in software container | |
| CN111324571B (en) | Container cluster management method, device and system | |
| US8752043B2 (en) | Providing guidance for software installation | |
| US9811325B2 (en) | Systems and methods for dynamically replacing code objects for code pushdown | |
| US20030093420A1 (en) | Method and system for retrieving sharable information using a hierarchically dependent directory structure | |
| US10585655B2 (en) | Systems and methods for automated retrofitting of customized code objects | |
| US20150363195A1 (en) | Software package management | |
| CN111176717B (en) | Method and device for generating installation package and electronic equipment | |
| US11144292B2 (en) | Packaging support system and packaging support method | |
| US20170154123A1 (en) | System and method for processing metadata to determine an object sequence | |
| WO2020156268A1 (en) | Method and system for cloud application and service integration using pattern-based discovery | |
| US20160124795A1 (en) | Evaluation method and apparatus | |
| US9411618B2 (en) | Metadata-based class loading using a content repository | |
| CN115599386A (en) | Code generation method, device, equipment and storage medium | |
| CN113987337A (en) | Search method, system, equipment and storage medium based on componentized dynamic arrangement | |
| WO2023151397A1 (en) | Application program deployment method and apparatus, device, and medium | |
| CN116414774A (en) | File migration method, device, equipment and storage medium | |
| CN117519814A (en) | Sharing method and device | |
| CN113495723B (en) | Method, device and storage medium for calling functional component | |
| CN115237631A (en) | Easily-extensible data sharing system and method based on data sharing plug-in | |
| WO2024021952A1 (en) | Sharing method and device | |
| CN112988225A (en) | Annotation configuration method, device, equipment and storage medium | |
| US20240037017A1 (en) | Verification of core file debugging resources | |
| US7475096B2 (en) | System for distributed communications |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication |