Until now, the typical way of using the EGL IDE was to make a change, press save and then allow the IDE to kick off an EGL compilation. Although this is a good way of doing work, at times it can fall short when performance is taken into account. Consider the case where an EGL top-level function, record or data item, used by many generate-able parts (like a program, handler, service, form group, data table, UIRecord or library), is changed. This simple act of changing that commonly used part will kick off an IDE compilation and possible generation of every generate-able part that uses it. The amount of work involved in this action could be huge, causing the IDE to go into the dreaded long-running "building workspace" mode. With version 9.1.1 and higher, a new feature has been added to the EGL user interface called the "Deferred Work View". Together, these intend to allow the user to avoid the long running build on save scenario altogether and control when builds take place.
Deferred work mode instructs the EGL builder to work in a mode where compilations are handled in one of two ways:
- Immediate compilation for any directly changed part
- Deferred compilation for the unchanged parts whose only consideration is that they happen to use the changed part.
For example, if the changed part is a generate-able part, then that part and any changed part it uses are compiled immediately. If the changed part is a top-level function, record, or data item, then usually only that changed part is compiled immediately. Any generate-able parts that use the changed part are not compiled immediately but instead placed onto the EGL deferred work queue. The contents of the deferred work queue are displayed in the "Deferred Work View". A user can then take actions at their discretion within that view to start a compilation or even generation. This allows a user to determine when they wish to have this potentially large amount of work to be performed.
To activate the deferred work mode, use the Eclipse Windows Preferences selection and navigate to EGL Editor. There you will find a check box for the option. You must also ensure that the Build Automatically project option is also set. Unless both of these option are activated, the deferred work view logic cannot work. The logic requires that the dependency information for the workspace be accurate, in order to calculate the affected parts list for a changed top-level function, record or data item and this information is available only when the Build Automatically project option is set on. For users that did not previously have the Build Automatically option turned on, once this flag gets set, an automatic build of the workspace will take place, which could take substantial time.
Some points to consider:
- If record A embeds record B and then record B is changed, then both record A and record B are compiled due to the change. The deferred work logic accesses the dependency information for the changed records and continues to compile through the higher levels, stopping the compilation once it reaches the generate-able part level. The same goes for top-level functions. If top-level function A references top-level function B and then top-level function B is changed, then both top-level function A and top-level function B are compiled due to the change. The deferred work logic stops the dependent compilations once it reaches the generate-able part level. These un-compiled generate-able parts are then placed onto the deferred work queue, allowing the user to control when compilations will occur.
- The deferred work queue is not stored when the IDE is shut down. Any information about outstanding work is not kept from session to session. Additionally, if the IDE determines that a full build is needed, then the deferred work mode is unable to prevent it from happening, and the full build will occur.
The "deferred work view" is an Eclipse view, similar to the EGL Generation View, that is shown as a window in the Eclipse environment. This view is activated automatically the first time that a part is added to the queue. The view is divided into two sections:
- The left section containing a list of the directly changed top-level functions, records, or data items.
- The right section shows the generate-able parts that use those changed parts.
If a top-level function, record or data item is not displayed in the left section when it was changed, it means that either the Build Automatically project option is not on, or the changed part is not used by any generate-able part. Actions can be taken on either side of the view, by using the right-mouse popup displays.
Outstanding work items are depicted by the "?" icon, indicating that changed have been made.
During the course of the day, while the user is going about their usual work, a generate-able part might get changed, saved and compiled. When this happens, the deferred work view is scanned for this generate-able part entry and the icon associated with it is changed to be one of a green check-mark, yellow warning, or red error, depending upon the return code of the compilation. These icons provide the user with a visual checkpoint of outstanding work, whether this work is programs or libraries that need to be compiled, or ones that contain errors. For example, if segtest.egl were compiled, then the display would change to this:
Right-mouse menus are available to both the left section and the right section, to allow a user to process deferred work. More information on the various left and right selections can be found in the EGL documentation.
When a generate-able part is generated, the generation logic will automatically cause a compilation of the generate-able part first, ensuring that the IR code is up to date. The view will also be updated to show that the compile was complete.
When in deferred work mode and an un-compiled part is about to be debugged by the EGL debugger, then the debugger will automatically cause the compilation of the part prior to it being loaded. This ensures that the EGL program logic is up to date during the debug session.