US7877738B2 - Speculative compilation - Google Patents

Abstract

The invention is a method and apparatus for use in developing a program. More particularly, a method and apparatus for compiling a source code program during editing of the same is disclosed, where editing can be initial entry or modification subsequent to initial entry. The method comprises compiling at least a portion of a source code program defined by a waypoint during the editing of the source code program. In other aspects, the invention includes a program storage medium encoded with instructions that, when executed, perform this method and a computer programmed to perform this method. The apparatus includes a computing apparatus, comprising a text editor through which a source code program may be entered; and a compiler that may compile the source code program. The control block is capable of determining at least one waypoint in the source code program and invoking the compiler to compile the source code program up to the waypoint.

Description

This application claims the earlier effective filing date of U.S. Provisional Application Ser. No. 60/480,301, filed Jun. 20, 2003, entitled “SPECULATIVE COMPILATION”, in the name of the inventors Theodore C. Goldstein, et al., and commonly assigned herewith.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention pertains to program compilation and, more particularly, to speculative compilation of a program.

2. Description of the Related Art

There typically is a sharp distinction between the code with which people program a computer and the code that the computer actually executes. Computers perform their programmed tasks by executing what is known as “object code.” Object code is a series of 1's and 0's that the computer's processor reads and interprets to perform its programmed tasks. However, actually programming in object code is exceedingly difficult, tedious, and time-consuming for a programmer. Programmers therefore rarely program in “object code.” Once a program has been designed, a programmer will usually code the program in “source code.” Source code is a high level language such as C, C++, Objective C, FORTRAN, ADA, PASCAL, etc. that is easier for people to read.

“Compilation,” in the context of computer programming, is the process by which a computer translates source code to object code. Compilation is performed by a software tool called a “compiler” executed by the computer for this purpose. Compiler design and compilation involve many considerations and are sufficiently complex that whole books have been written on the topic. See, e.g., Alfred V. Aho, et al.,Compilers—Principles, Techniques and Tools(Addison-Wesley Pub. Co. 1986) (ISBN 0-201-10088-6). However, some generalizations may be drawn.

In the classic scenario, the programmer codes the program in source code using a “text editor,” another software tool. When the programmer finishes coding the program, the programmer saves the program and invokes a compiler. More particularly, a programmer writes and edits one or more source code program files and then initiates a “build” to compile these source code files. The build process may be initiated by the programmer in various ways, including through a user interface gesture (e.g., clicking on a “build” button) or by invoking a command, such as make or jam, from a command line.

Once the compiler compiles the source code into object code, the compiled object code can then be executed by the computer. In the program's development phase, the source code may be debugged by editing the program in the text editor and then compiling (or, recompiling) the edited source code. This process may be iterated many times, depending on the complexity of the program. Each time, the compiler is invoked on the whole program. However, under the conventional approach, no compilation occurs until the user expressly initiates a build. As such, much of the “idle time” during which the user is proof-reading or editing source code goes unused.

Consider the example shown inFIG. 1.FIG. 1 illustrates asource code program100 comprised of multiple files. Thesource code program100 is written in C, and is presented in pseudo-code. Thesource code program100 comprises asource file102 name “a.c” andseveral header files104,106,108 named “a.h,” “b.h,” and “c.h,” respectively. The header files104-108 are defined as part of thesource code program100 by the “#include”statements110,112,114, in accordance with the programming principles for C. The header files104-108 may contain declarations or definitions of data types and variable declarations and some inline code declarations used by thesource file102.

In accord with conventional practice, the programmer fully enters all thesource code100 through theend116 thereof. The programmer then invokes a compiler, not shown inFIG. 1. The compiler includes a “file reader” that starts reading thesource file102, diverting to the header files104-108 as it comes across the respective “#include” statements110-114. The compiler reads through each header file104-108 to its end, and returns to thesource file102 after finishing the respective header files104-108. The compiler continues reading thesource file102, diverting to header files104-108 when it encounters the “#include” statements110-114, respectively, until it reaches the end of116 of thesource file102. This reading of thesource file102 is but one part of the compilation process.

On average, the majority of time spent in any given compilation of a C-type program is spent in reading the header files of the source code program. It is not unusual for a compiler to process orders of magnitude more data in header files than it does in source files. However, the code in the header files rarely, if ever, changes during the editing sessions of the source files. Thus, as a general rule, the header files take less time to develop than do the source files, but take much longer to process for compilation.

Some attempts have been made to combine the steps of coding the source code and compiling it into object code. Typically, these attempts are in the form of “interpreted languages.” Apple's APPLESCRIPT and Microsoft's VISUAL BASIC are two tools that attempt to compile the source code as the programmer codes the program. Both of these tools combine the function of the text editor and the compiler. In theory, this accelerates the development process since the compilation does not have to wait for all the source code to be entered.

Users of these kinds of tools report great satisfaction because the development process is relatively rapid. However, these tools suffer from disadvantages. One disadvantage is loss of efficiency. One important aspect of most compiler designs is code “optimization.” See Aho et al., supra, at pp. 585-718. Code optimization typically involves modifying some portions of an intermediate representation of the source code so that the resulting object code runs more efficiently. Most optimizations require analysis of, and modifications to, instructions that may be separated by any number of lines of source code. By handling each line of code one line at a time, these types of tools lose the efficiencies that might otherwise be obtained through optimization. These tools therefore are used for smaller kinds of programs and those in which speed is not of prime importance, and generally are not used to create, for example, large desktop applications.

Some attempts have therefore been made to develop text editor-compiler tools dedicated to C-type languages commonly used to create desktop applications. C-type languages include, e.g., C, C++, and Objective C. Exemplary of this type of tool is SABER-C. These types of tools generally performed well in implementing a rapid development phase compiler and a slower production phase compiler. However, these tools failed to implement the identical production compiler semantics of their competitors and lost popularity.

An alternative approach employs “pre-compiled” header files with C-type languages. In this approach, some header files that may be frequently used are pre-compiled and stored. Then, when it comes time to compile the program, the header files are already compiled, thereby reducing compile time for the program as a whole. Pre-compiled header files, however, take a relatively large amount of storage. This mitigates against their frequent use, particularly with arbitrary sets of files with non-uniform initial sequences of preprocessing directives.

The present invention is directed to resolving, or at least reducing, one or all of the problems mentioned above.

SUMMARY OF THE INVENTION

The invention is a method and apparatus for use in developing a program. More particularly, a method and apparatus for compiling a source code program during editing of the same is disclosed, where editing can be initial entry or modification subsequent to initial entry. The method comprises compiling at least a portion of a source code program defined by a waypoint during the editing of the source code program. In other aspects, the invention includes a program storage medium encoded with instructions that, when executed, perform this method and a computer programmed to perform this method. The apparatus includes a computing apparatus, comprising a text editor through which a source code program may be entered; and a compiler that may compile the source code program. The control block is capable of determining at least one waypoint in the source code program and invoking the compiler to compile the source code program up to the waypoint.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may be understood by reference to the following description taken in conjunction with the accompanying drawings, in which like reference numerals identify like elements, and in which:

FIG. 1 illustrates a conventional program development process in which a source code program is compiled after entry through a text editor;

FIG. 2 illustrates a program development process in accordance with the present invention in which the source code program ofFIG. 1 is speculatively compiled before it is completely entered;

FIG. 3 depicts, in a block diagram, a computing apparatus such as may be used to implement the process ofFIG. 2 in one particular embodiment;

FIG. 4 is a flowchart of one particular embodiment of the present invention;

FIG. 5 depicts, in a block diagram, one particular implementation of the computing apparatus inFIG. 3; and

FIG. 6 is a flowchart of one particular implementation of the embodiment inFIG. 4 relative to the computing apparatus inFIG. 5.

While the invention is susceptible to various modifications and alternative forms, the drawings illustrate specific embodiments herein described in detail by way of example. It should be understood, however, that the description herein of specific embodiments is not intended to limit the invention to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE INVENTION

Illustrative embodiments of the invention are described below. In the interest of clarity, not all features of an actual implementation are described in this specification. It will of course be appreciated that in the development of any such actual embodiment, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which will vary from one implementation to another. Moreover, it will be appreciated that such a development effort, even if complex and time-consuming, would be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure.

The invention includes a method and apparatus for use in code development. More particularly, the invention is a method for speculatively compiling a source code program on an appropriately programmed computing apparatus. For convenience, the method will be illustrated on a portion of the samesource code program100 first shown inFIG. 1, and reproduced inFIG. 2. However, thesource code program100 inFIG. 2 is still being edited by a user, since theend106 of thesource file102, shown inFIG. 1, is missing inFIG. 2. As was previously mentioned, thesource code program100 is coded in C. However, the present invention is not limited to C programming language environments, or even C-type (e.g., C++, Objective C) language environments. The present invention may be applied to virtually any type of high level, source code programming language also including, but not limited to, FORTRAN, ADA, PASCAL, JAVA, assembly language, etc.

The invention may be implemented in software on a computing apparatus, such as thecomputing apparatus300 illustrated inFIG. 3. Thecomputing apparatus300 may be implemented in any convenient fashion known to the art, including, but not limited to, a desktop personal computer, a workstation, a notebook or laptop computer, or an embedded processor. Thecomputing apparatus300 illustrated inFIG. 3 includes aprocessor305 communicating withstorage310 over abus system315 and operating under the direction of anoperating system330. Theoperating system330 may be any operating system known to the art, such as MacOS®, Windows®, Disk Operating System®, Unix®, Linux®, etc. In the illustrated embodiment, theoperating system330 is a Unix® operating system.

Thestorage310 may comprise a hard disk and/or Random Access Memory (“RAM”) and/or removable storage such as amagnetic disk317 or anoptical disk320. Theuser interface software335, in conjunction with auser interface345 allows a user to input information that can be displayed on adisplay340. Theuser interface345 may include peripheral I/O devices such as a key pad orkeyboard350, amouse355, or ajoystick360. Theprocessor305 runs under the control of theoperating system330, which may be practically any operating system known to the art.

Thesource code program100, aconventional text editor365 that provides conventional editing functions, and acompiler370 may be stored in thestorage370. Thetext editor365,compiler370, and acontrol block372 comprise, in the illustrated embodiment, a portion of an Integrated Development Environment (“IDE”)tool375. Other commonly known and understood components of theIDE375, such as linkers, debuggers, etc., are not shown for the sake of clarity and so as not to obscure the invention. Alternative embodiments of theIDE375 may have more, fewer, or different components from those of the embodiment illustrated inFIG. 3. Common examples of IDE systems include CodeWarrior™ offered by Metrowerks™ and, Project Builder by Apple®, Visual Studio® offered by Microsoft®.

The invention is not limited to embodiments implementing an IDE. For illustrative purposes, the present invention is described in the context of an IDE, although it should be appreciated that one or more embodiments of the present invention may be applicable to other integrated environments that may be employed to design and develop software applications. Note also that thecontrol block372 may be implemented in various alternative embodiments as a standalone component, integrated into theIDE tool375, or may be integrated into some other software component (not shown) capable of interfacing with theIDE tool375. Although the instant invention is not so limited, in the illustrated embodiment, thecontrol block372 is implemented as a background thread that is capable of performing one or more tasks for theIDE tool375, as described in greater detail below.

Thecontrol block372 may comprise a portion of thetext editor365 or thecompiler370, or may be separate therefrom. Thetext editor365 andcompiler370 may be any suitable text editor and compiler, respectively, known to the art in the illustrated embodiment. The design and implementation of text editors and compilers is well known in the art, and so further discussion will be omitted so as not to obscure the invention.

FIG. 4 charts the flow of the operation of the embodiment illustrated inFIG. 2-FIG.3. Referring now toFIG. 2-FIG.4, in accordance with the present invention, a programmer (not shown) opens thetext editor365 through theuser interface345 and begins editing (at402) thesource code program100. The editing may comprise the initial entry of thesource code program100, or a session in whichsource code program100 is being altered subsequent to the initial entry. The programmer may or may not actually save what has been entered of thesource code program100. However, theprocessor305 has access to one or more files containing that portion of thesource code program100 that has been entered by the programmer stored in thestorage310. As thesource code program100 is entered, theIDE375 determines (at404) that a compilation of all or some of the entered portion of thesource code program100, e.g., theportion200, is desirable. In the illustrated embodiment, theIDE375 then sends (at406) the desiredportion200 to thecompiler370 for compilation. TheIDE375 does not wait for the programmer to finish entering thesource code program100, but rather performs its function at some point during the entry. Thus, the portion of thesource code program100 sent (at406) to the compiler is “speculatively” compiled.

More particularly, theIDE375 selects (at404) a “waypoint,” e.g., apoint205 shown inFIG. 2, in thesource code program100. A “waypoint” is a point in thesource code program100 defining a bound of a portion of thesource code program100 for which it is desirable to begin compiling prior to the end of an editing session. In the illustrated embodiment, a waypoint at thepoint205 defines a lower bound for theportion200, the first “#include”statement110 defining the upper bound. The determination and selection of thewaypoint205 will be implementation specific, and will be discussed further below. The upper and lower bounds should be distant enough to realize benefits from the application of one or more of the optimization techniques employed by thecompiler370. However, thewaypoint205 should not be so distant as to exceed the point of diminishing returns from the application of the invention. For instance, if thewaypoint205 is selected to define aportion200 that essentially constitutes the entiresource code program100 once it is fully entered, then, in some instances, some of the benefits of the present invention will be lost.

One approach to identifying thewaypoint205 is to statically define the criteria for a waypoint. An embodiment may define a waypoint at some appropriate, top level form language element such as a definition or declaration. For instance, when programming with a C-type language, it may be convenient to statically define a waypoint at thepoint205 where the “#include” statements110-114 defining the applicable header files104-108 for the source file102 conclude. As was previously noted, in C-type languages, compilers spend many times the amount of effort in analyzing header files that they do in analyzing the remaining portion of the source files. Thus, thewaypoint205 at the point after which all the “#include” statements110-114 have been put forth will greatly reduce the total development time for thesource code program100, as a whole. Alternatively, thewaypoint205 may be defined as a particular line number in the file, or after some predetermined number of loops, etc.

However, the waypoint need not be defined statically. For instance, a waypoint may be defined at thepoint210 of the programmer'stext editor365 after some predetermined time. Alternatively, the waypoint may be defined at any point up to thepoint210 of the programmer's text editor insertion point, or even to some point after the text editor insertion point. For instance, the waypoint may be after some predetermined number of branch statements, or conditionals regardless of the text editor insertion point. The waypoint may also be defined to be some text position offset in the file. In still another alternative, the programmer may manually select the waypoint, for example, while editing.

Note also that multiple waypoints may be used in some embodiments. For instance, it may be desirable to compile in accordance with the present invention amiddle portion215 of thesource code program100. In this alternative, afirst waypoint205 defines an upper bound for the portion to be compiled and asecond waypoint210 defines the lower bound in the manner described above. Note that, in the embodiment illustrated inFIG. 2 above, thefirst statement110 in the source file102 can be considered a waypoint defining the upper bound of theportion200. However, in such an embodiment, there may be at least one waypoint intermediate the first and last lines of the source file. Multiple waypoints may also be employed in embodiments where multiple portions, e.g., theportion200 and themiddle portion215, are both compiled in the same editing session.

In the context of C-type programming languages, a waypoint at thepoint205 at which the “#include” statements110-114 may be sufficient to reap one or more of the benefits of the present invention. Nevertheless, other programming languages might exhibit compiler processing characteristics mitigating for a static definition at some other point in the source code program or even a dynamic definition.

Returning to the illustrated embodiment, theIDE tool375, shown inFIG. 3, causes thecompiler370 to start and read thesource code program100. TheIDE tool375 causes thecompiler370 to start and read from the standard input defined, in the illustrated embodiment, by UNIX. For instance, in C syntax:
=popen(“gcc-stdin”);
TheIDE305 then sends theportion200, i.e., up to thewaypoint205, to thecompiler370. Thecompiler370 compiles theportion200, and waits until further portions are supplied. As thecompiler370 compiles theportion200, the programmer continues coding thesource code program100. Once the programmer is finished coding thesource code program100, the programmer saves it. Note that, in some embodiments, thesource code program100 may not be saved or may be saved at some point after compilation.

Existing IDEs may be modified to practice the present invention. As will be appreciated by those skilled in the art having the benefit of this disclosure, engineers frequently modify existing systems, such as IDEs, to support additional functionality. IDEs generally use an external compiler that operates in batch mode. Typically, this batch mode processing is slower than what is found in dynamic environments. There are many IDEs commercially available that use an external compiler. These include but are not limited to Microsoft's Visual Studio and Apple's Project Builder environments. The present invention can provide the speed of a dynamic environment without compromising the design integrity and advantages of maintaining a separate code base for the compiler and the IDE. The present invention can also enhance the functionality of such an environment by modification of the structure of the IDE tool itself without substantially adversely affecting the existing functionality that the IDE supports.

FIG. 5 illustrates acomputing apparatus500 in which an existingIDE tool575 includes abuild system580 that invokes theexternal compiler570 and is modified to support this interaction. In this particular embodiment, the invention is employed during debugging, as opposed to initial entry. However, as discussed above, the invention is not so limited and may be employed during initial entry. TheIDE tool575 includes atext editor365. Thetext editor365 edits a region of text in thesource code program100 whose bytes may be numbered from 1 to N, where N is the size of the file. Thewaypoint205, shown inFIG. 2, is a point in the text W of thesource code program100 such that 1<W<N, (i.e., thewaypoint205 is somewhere between the beginning and the end of the file) as is apparent from the above discussion of thewaypoint205 relative toFIG. 2.

Thecontrol block572 includes a code routine which, for present purposes, is called the speculative compiler event monitor (“SCEM”)573. The existingIDE tool575 can be modified to speculatively compile thesource code program100 by first identifying the mainevent processing loop574 of theIDE tool575 or theevent handler architecture576. Anagent577 known to theSCEM573 is then inserted into either the mainevent processing loop574 or theevent handler architecture576. Awaypoint identification routine578, whose functionality is described above relative toFIG. 2, is then inserted into theIDE tool575. The compiler can then be modified by identifying thefile reader portion578 of the code568 and modifying it as described above to read from standard input using the open system call or other similar read routine. Thebuild system580 of theIDE tool575 can then by modified by identifying the build dependencies and maintenance aspects of the system and exposing them through an interface to theSCEM573.

The aspects of modifying the build system in one particular embodiment are more fully disclosed in U.S. patent application Ser. No. 10/660,353, filed Sep. 11, 2003, in the name of P. Anders I. Bertelrud, et al., entitled “Predictively Processing Tasks for Building Software”, and commonly assigned herewith. In general, theIDE tool575 allows a user to design and develop software applications or products. The initial step of developing the software product(s) generally involves creating a project. A project contains one or more elements that are used to “build” the software product(s). In a programming context, and as used herein, the term “build” refers to putting individual coded components (e.g., source file102 andheader files104,106,108, inFIG. 2) of a program (e.g., thesource code program100,FIG. 2) together.

The project created using theIDE tool575 typically maintains the relationships between various elements contained therein. A project may contain a variety of elements, such as file references, targets and build styles, products, and the like. File references, for example, may include source code files, resource files, libraries, and frameworks. Targets generally describe how to build a particular product, such as a framework, command-line tool, or application, and a build style describes how to create a variation of the target's product. In the illustrated example, thesource code program100 constitutes a “project”, comprising the source and header files102-108, that is a “product” under development. As utilized herein, the term “product” refers to the finished model, and may, for example, include one or more of the linked executable files, associated resource files, etc.

A project may have one or more associated targets. For example, a project for a client-server software package may contain targets that create a client application, a server application, command-line tools that can replace the applications, and a private framework that all the other targets use. By putting these related targets into a single project, it is possible to share files and express dependencies among them. For example, if a project is set up so that the applications and command-line tools depend on the private framework, theIDE tool575 can determine that it should first build the framework before it builds the applications or tools.

For a given project, theIDE tool575 maintains alist582 of dependency nodes for each file that participates in the build, where the files may include source files, intermediate files, and product files. Examples of “source files” may include source code files (e.g., the source code file102), resource files, library files, header files (e.g., the header files102,104,106 inFIG. 2), and frameworks. Examples of “product files” may include files that appear in the deployable product such as executable files. Examples of “intermediate files” may include files that are neither specified by the user nor end up in the product, such as generated object code files, precompiled headers, and temporary files used by custom shell scripts. In the illustrated embodiment, the source file102 is dependent on the header files104-108. The dependency node list for this project would therefore list the source and header files102-108.

In the illustrated embodiment, theIDE tool575 creates thelist582 of dependency nodes based on information from the product type and the target before the build process starts. Each dependency node typically includes a set of references to other nodes on which it depends and a set of actions that may be performed to bring the node up-to-date. In one embodiment, theIDE tool575 utilizes a directed acyclic graph (“DAG”, not shown) as is known in the art to define the dependency relationships between the various nodes in the project. The use of DAGs is well known in the art, and thus is not described in detail herein so as to avoid unnecessarily obscuring the instant invention.

Once the desired file reference components (e.g., source file102 andheader files104,106,108, inFIG. 2) have been created for a given project, the user can build the product under development. This may be accomplished, for example, by invoking the make or jam tools via the command line or through a user interface gesture, such as selecting a build button (not shown) that may be part of agraphical user interface345. TheIDE tool575 comprises a variety of tools to build the product, such as a linker (not shown). The compiler470 compiles one or more of the source files to create object code files. The linker links the object files produced by the compiler470 against the frameworks and libraries listed to create a binary file. As part of the build process, various tools of theIDE tool575 can also process resource files, which define the windows, menus, icons, and the like that are associated with the product under development.

Once the build of the development product is complete, theIDE tool575 provides an executable file that may be executed and tested by the user. The user may use a debugger (not shown) of theIDE tool575 to, for example, view the various variable values of the executing file, examine the call chain, evaluate expressions, and the like. If any errors are discovered, the user may edit the source code files (or other types of files) to correct the error and then initiate the build process again. This process may be iterated as many times as desired to produce a final software product.

During the development stage of the product, it is not unusual for the user to engage in several iterations of debug and recompile sessions before arriving at the final product. As the user creates new source code (or resource) files or modifies existing source code (or resource) files associated with a project, these files become out-of-date and thus require compiling or recompiling. The compilation or recompilation of each out-of-date file is considered a task, and each task is placed in awork queue586. The control block472 tasks in thework queue586 in a variety of ways, depending on the particular implementation. For example, the control block472 may periodically check thework queue586 to see if any tasks need processing. Or, the control block472 may be invoked or awakened each time a new task is posted in thework queue586 by theIDE tool575. TheIDE tool575 may alternatively identify a task in response to, for example, determining that the user has saved (or resaved) a revised version of a source file (e.g., source code file, resource file, etc.), or in response to other conditions.

Processing tasks from thework queue586 may comprise performing, for example, one or more of the following tasks: creating directories, moving files, invoking thecompiler570 and the linker, and the like. Thework queue586 contains, in dependency-sorted order (based on the information from the DAG), a set of tasks for files that are out-of-date. Thus, for example, if a user modifies a header file that is referenced in a source file, both the header file and the source file may be identified in thework queue586 because of the underlying dependency.

In accordance with the present invention, theIDE tool575 identifies a file as being out-of-date in response to determining (at404,FIG. 4) that it is desirable to compile a portion of asource code program100 currently being edited or entered. Note that this may occur not only during debugging but during initial entry. This response may be triggered, for example, by the identification of a waypoint (e.g., thewaypoint205,FIG. 2), as described above, by thewaypoint identification routine578. Wheremultiple waypoints205,210 are identified, this response is triggered by each identification. At this point, theIDE tool575 “sends” theportion200 to thecompiler570 for compilation.

More technically, this “sending” can be accomplished in one of several ways. In one implementation, theSCEM573 places a task on thework queue586, for thecompiler570 to compile theportion200 of the source file100 defined by thewaypoint205. In a second implementation, theSCEM573 creates a separate file (not shown) that includes only thatportion200 of the source file100 defined by thewaypoint205 and then places that file on thework queue586. Still other embodiments may employ various other implementations to initiate the compilation of theportion200 of thesource file100.

Referring now to bothFIG. 2 andFIG. 5, theSCEM573 awaits processing of the incoming user keystrokes and chooses an appropriate time to begin processing of the compilation of the pre-waypoint code, e.g., theportion200 of thesource code program100 inFIG. 2. Those skilled in the art having the benefit of this disclosure will be able to choose a time that does not distract from the programming experience. On slower machines this may be a rare interval where a programmer has paused programming for some predetermined number of minutes. On a fast computer, this may be every second. Thus, the appropriate time will be implementation specific depending on the implementation of the computing apparatus.

TheSCEM573 conducts its processing in at least two phases: first, it processes the pre-waypoint processing from byte one to byte W, i.e., up to the waypoint295. TheSCEM573 then processes the post-waypoint code from byte W to byte N, i.e., from thewaypoint205 to thenext waypoint210 or the end of theprogram source code102. Ifmultiple waypoints205,210 are present, the process repeats until theSCEM573 processes to the end of theprogram source code102. TheSCEM573 begins the mainevent processing loop574 when the programmer first starts editing a file, e.g., thesource code program100, and begins the first phase, pre-waypoint processing as soon as the programmer edits a new file. TheSCEM573 performs the second phase, post-waypoint processing either speculatively, when it has some idle cycles, or when the user saves the file. TheSCEM573 observes the compilation, and then updates thebuild system580 to know the precise state of the truth of the file.

For each phase of the processing, the control block472 of theIDE575 processes the tasks in thework queue586 to bring the software under development up-to-date. Thework queue586 includes a file corresponding to theportion200 of thesource code program100 ofFIG. 2 identified by thewaypoint205. That is, the control block472 initiates the processing of the tasks identified in thework queue586 even before the user initiates a build. The control block472 is able to process the files in this manner because thework queue586 identifies the out-of-date nodes and the order in which these nodes should be processed. In the illustrated embodiment, the control block472 is a thread executing in the background.

Referring now toFIG. 6, a flow diagram of a method of the present invention is illustrated, in accordance with one embodiment thereof. A programmer begins a text editing session (at602), in which they either edit an existing source code program100 (shown inFIG. 2) or begin initial entry of an newsource code program100. As described above, theSCEM573 then determines a waypoint (at604) at an appropriate time. This identification places (at606) a task, e.g., to compile or recompile theportion200 of thesource code file102 inFIG. 2, on thework queue586 and triggers (at608) theIDE tool575 to update the nodes on thework queue586. In updating thework queue586, the control block472 may identify and execute tasks other than the recompile of theportion200. In the illustrated embodiment, these other tasks may be associated with building a software application, and thus may involve acts such as moving files and directories, invoking compilers and linkers to respectively compile and link, and the like.

In the illustrated embodiment, once theportion200 has been compiled, the task is removed from the work queue586 (at610) and the compiled code is stored (at612) in ashadow location584, shown inFIG. 5, different from the location where the files are typically stored when a build is initiated by the user. For example, object code files produced by compiling source code files may be stored in shadow folders. Storing files in a different location from the normal files allows the user to “roll back” to the results of the most recent user-initiated build process, in case situations where the user decides to undo any of the modifications that triggered the speculative processing. As described below, once the user initiates the build process, any files stored in thealternative location584 may later be moved to the official location. Furthermore, in the illustrated embodiment, as the identified tasks are processed before the user initiates a build, any error(s) or warning(s) that are detected are suppressed (at614) so as not to disturb the user until a time the user explicitly initiates the build process.

As was discussed above, some embodiments may employ multiple waypoints, e.g., thesecond waypoint210 inFIG. 2. In these embodiments, the process of identifying a waypoint (at604), placing the task on the work queue586 (at606), triggering theIDE575 to update (at608), and removing the task from the work queue586 (at610), may be iterated, as indicated by the ghostedlines616. Note that, also as was discussed above, other conditions might trigger (at608) the IDE to update tasks placed on the work queue586 (at606) and then remove them from the work queue586 (at610).

At the time of the user's choosing, the user may initiate (at618) the build process, for example, when the editing is finished. The user initiates the build through the command line or through the graphical user interface. Ordinarily, upon detecting the user's request to initiate the build, theIDE tool575 typically executes the tasks identified in thework queue586. However, in accordance with the present invention, because the control block472 may have pre-processed one or more of the tasks associated with the build process, the control block472, upon detecting the user request to initiate the build (at618), indicates (at620) a status of the processing of the one or more tasks once the build process successfully completes or stops because of errors or warnings. The particular type of status indication provided (at620) to the user depends on the results of the speculative processing.

If the speculative processing was unsuccessful because of error(s)/warning(s) that were detected (and suppressed) (at614) during the process, the user may be notified (at622) of the detected error(s)/warning(s) in response to detecting the request from the user to initiate the build. Thus, if errors are encountered during the speculative processing (such as during the compiling phase, for example), the user, once he initiates the build process, is notified that the compilation could not be completed because of the errors that were found. The user may then decide whether to keep the results of the compilation or scrap them. Since the results are stored in theshadow location584, this is easily done.

If, on the other hand, the speculative processing completes successfully, then the files stored in the alternative (shadow)location584 are moved (at624) to the official locations and the user is thereafter notified that the build completed successfully. It should be noted that the act of moving the files from the alternative location to the official location may itself be an indication of the status (at620) of the processing of the tasks. In one embodiment, a message may also be provided to the user indicating that the processing of the tasks was successful.

As will be appreciated by those skilled in the art, most aspects of the present invention will typically be implemented as software on an appropriately programmed computing device, e.g., thecomputing apparatus300 inFIG. 3. The instructions may be encoded on, for example, thestorage310, thefloppy disk317, and/or theoptical disk320. Typically, though, the instruction will be encoded on a local hard disk (not shown) for the computer apparatus that comprises a part of thestorage310. The present invention therefore includes, in one aspect, a computing apparatus programmed to perform the method of the invention. In another aspect, the invention includes a program storage device encoded with instructions that, when executed by a computing apparatus, perform the method of the invention.

Some portions of the detailed descriptions herein are consequently presented in terms of a software implemented process involving symbolic representations of operations on data bits within a memory in a computing system or a computing device. These descriptions and representations are the means used by those in the art to most effectively convey the substance of their work to others skilled in the art. The process and operation require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical, magnetic, or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantifies. Unless specifically stated or otherwise as may be apparent, throughout the present disclosure, these descriptions refer to the action and processes of an electronic device, that manipulates and transforms data represented as physical (electronic, magnetic, or optical) quantities within some electronic device's storage into other data similarly represented as physical quantities within the storage, or in transmission or display devices. Exemplary of the terms denoting such a description are, without limitation, the terms “processing,” “computing,” “calculating,” “determining,” “displaying,” and the like.

This concludes the detailed description. The particular embodiments disclosed above are illustrative only, as the invention may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. Furthermore, no limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope and spirit of the invention. Accordingly, the protection sought herein is as set forth in the claims below.

Claims (44)

1. A method for use in developing a program, comprising:

compiling at least a portion of a source code program defined by a first waypoint during the editing of the source code program;

identifying a second waypoint in the source code during editing of the source code; and

compiling the source code from the first waypoint to the second waypoint before completing editing of the source code.

2. The method ofclaim 1, wherein compiling includes:

identifying the first waypoint in an edited source code during editing of the source code; and

compiling the source code up to the identified waypoint before completing the edit of the source code.

3. The method ofclaim 1, wherein identifying the first waypoint includes one of identifying the waypoint from a static definition and identifying the waypoint from a dynamic definition.

4. The method ofclaim 1, further comprising:

completing editing of the source code; and

compiling the source code from the second waypoint to the end of the source code.

5. The method ofclaim 1, further comprising saving the edited source code.

6. The method ofclaim 1, further comprising compiling the source code from the waypoint to the end of the source code upon completing editing of the source code.

7. An apparatus for developing a program, comprising a processor capable of:

identifying a first waypoint in an edited source code program during editing of the source code program;

compiling the source code program up to the identified first waypoint during at least a portion of a time period in which the source code program is being edited;

identifying a second waypoint in the edited source code program during editing of the source code program; and

compiling the source code program from the first waypoint to the second waypoint before completing editing of the source code program.

8. The apparatus ofclaim 7, wherein the processor capable of identifying the first waypoint further comprises the processor being capable of performing at least one of identifying the first waypoint from a static definition and identifying the waypoint from a dynamic definition.

9. The apparatus ofclaim 7, wherein the processor is further capable of compiling the source code program from the first waypoint to the end of the source code program upon completing editing of the source code program.

10. A method for modifying a compiler to engage in rapid compilation, comprising:

identifying a file reader portion of the compiler; and modifying the identified file reader to read a portion of a source code program defined by a first waypoint from a standard input and a second waypoint from a standard input, wherein the identified file reader is adapted to read the portion of the source code program during editing of the source code program.

11. The method ofclaim 10, wherein modifying the identified file reader to read from the standard input includes modifying the identified file reader to read from an open system call.

12. The method ofclaim 11, wherein modifying the identified file reader to read from the open system call includes modifying the identified file reader to read from a UNIX gcc command.

13. The method ofclaim 10, wherein the waypoint is identified by one of identifying the first waypoint from a static definition and identifying the first waypoint from a dynamic definition.

14. The method ofclaim 10, wherein the first waypoint defines a lower bound of the portion of the source code program.

15. The method ofclaim 10, wherein the first waypoint defines an upper bound of the portion of the source code program.

16. A method for suspending compiler execution prior to reaching the end of a source code program, comprising:

identifying a waypoint in the source code program;

compiling a portion of the source code program whose lower bound is defined by the identified waypoint; and

suspending compilation of the source code program once the portion whose lower bound is identified by the waypoint is compiled.

17. The method ofclaim 16, wherein the waypoint is identified by one of identifying the waypoint from a static definition and identifying the waypoint from a dynamic definition.

18. The method ofclaim 16, wherein suspending compilation of the source code program once the portion whose lower bound is identified by the waypoint is compiled includes at least one of removing a corresponding task from a work queue in an IDE, storing the compiled code in a shadow location, and suppressing errors or warning.

19. The method ofclaim 16, wherein the upper bound of the portion is defined by the start of the source code program or another waypoint.

20. A method for building a source code program capable of suspending and resuming compilation, comprising:

identifying a waypoint in a source code program being edited;

triggering a compilation of a portion of the source code program defined by the waypoint;

compiling the portion of the source code program defined by the waypoint;

suspending the compilation of the portion defined by the waypoint once the compilation reaches the waypoint;

triggering the compilation of the remainder of the source code program; and

resuming the compilation of the source code program to compile the remainder.

21. The method ofclaim 20, wherein the waypoint is identified by one of identifying the waypoint from a static definition and identifying the waypoint from a dynamic definition.

22. The method ofclaim 20, wherein triggering the compilation of the portion of the source code includes identifying the waypoint.

23. The method ofclaim 20, wherein suspending compilation of the source code program once the portion whose lower bound is identified by the waypoint is compiled includes at least one of removing a corresponding task from a work queue in an IDE, storing the compiled code in a shadow location, and suppressing errors or warning.

24. The method ofclaim 20, wherein the upper bound of the portion is defined by the start of the source code program or another waypoint.

25. The method ofclaim 20, wherein triggering the compilation of the remainder of the source code program includes identifying a second waypoint, saving the source code program, or ending an editing session.

26. A method for using a UNIX standard input read mechanism for speculative compilation of a source code program, comprising:

identifying a first waypoint and a second waypoint in an edited source code program during editing of the source code program, wherein the second waypoint is after the first waypoint in the source code program; invoking a compile of at least a portion of a source code program defined by the first waypoint and the second waypoint during the editing of the source code program with a UNIX input read mechanism; and

compiling the at least a portion of the source code program from the first waypoint to the second waypoint before completing editing of the source code program.

27. The method ofclaim 26, wherein the portion comprises a portion of the source code program defined by the start of the source code program and the second waypoint.

28. The method ofclaim 26, wherein the portion comprises a portion of the source code program defined by the first waypoint and the end of the source code program.

29. The method ofclaim 26, wherein the first waypoint is identified by one of identifying the first waypoint from a static definition and identifying the first waypoint from a dynamic definition.

30. A method for managing the output of a compile, comprising:

compiling at least a portion of a source code program defined by a waypoint during the editing of the source code program in a first phase;

compiling the remainder of the source code program in a subsequent phase; and

notifying a user of any errors that may have occurred during the compilation.

31. The method ofclaim 30, wherein the portion comprises a portion of the source code program defined by the start of the source code program and the waypoint.

32. The method ofclaim 30, wherein the portion comprises a portion of the source code program defined by the waypoint and the end of the source code program.

33. The method ofclaim 30, wherein the waypoint is identified by one of identifying the waypoint from a static definition and identifying the waypoint from a dynamic definition.

34. The method ofclaim 30, further comprising scrapping the compiled first and second portions.

35. The method ofclaim 34, wherein scrapping the compiled first and second portions includes one of scrapping the compiled first and second portions responsive to the notification and scrapping the compiled first and second portions responsive to a user input.

36. A method for use in developing a program, comprising:

identifying at least two or more instructions in a file to compile;

compiling the identified instructions while the file is being edited;

completing editing of the file; and

compiling the remainder of the edited file.

37. The method ofclaim 36, wherein the instructions are identified at a predetermined line number in the source code program, identifying the instructions at the point of insertion for a text editor, identifying the instructions after a predetermined number of branches as conditionals, identifying the instructions at a predetermined text offset.

38. The methodclaim 36, further comprising:

identifying at least two more instructions in the file during editing; and

compiling the at least two more instruction while the file is being edited.

39. The method ofclaim 36, further comprising saving the edited file.

40. The method ofclaim 36, further comprising compiling the remainder of the edited file in response to completing editing of the file.

41. A method for compiling a source code program, comprising:

identifying an upper bound for a portion of the source code program to compile;

identifying a lower bound for the portion;

compiling the portion defined by the upper and lower bounds during an editing session on the source code program;

identifying a third bound in the edited source code during editing of the source code; and

compiling the source code from the lower bound to the third bound before completing editing of the source code.

42. The method ofclaim 41, wherein at least one of identifying the upper bound and identifying the lower bound includes one of identifying the bound from a static definition and identifying the bound from a dynamic definition.

43. The method ofclaim 41, further comprising compiling the source code from the lower bound to the end of the source code upon completing editing of the source code.

44. A computer readable storage device encoded with instructions that, when executed by a processor, perform the method of:

identifying a first waypoint in an edited source code program during editing of the source code program;

compiling the source code program up to the identified first waypoint during at least a portion of a time period in which the source code program is being edited;

identifying a second waypoint in the edited source code program during editing of the source code program; and

compiling the source code program from the first waypoint to the second waypoint before completing editing of the source code program.

Images