Difference between revisions of "Clean IDE"
Bas Lijnse (talk | contribs) |
Bas Lijnse (talk | contribs) |
||
(3 intermediate revisions by the same user not shown) | |||
Line 38: | Line 38: | ||
[[Image:findidentifier.jpg|none]] | [[Image:findidentifier.jpg|none]] | ||
== Compiler Options == | == Compiler Options == | ||
− | The Clean compiler is a very fast one. It includes a fast and smart strictness analyzer (abstract reduction) leading to more efficient code. The compiler can also reuse space occupied by uniquely typed objects. For each implementation module you can set the appropriate compiler / code generation options. | + | The Clean compiler is a very fast one. It includes a fast and smart '''strictness analyzer''' ('''abstract reduction''') leading to more efficient code. The compiler can also reuse space occupied by uniquely typed objects. For each implementation module you can set the appropriate compiler / code generation options. |
+ | [[Image:compileroptions.jpg|none]] | ||
+ | |||
+ | == Project Options == | ||
+ | Many options can be set for each project. There are among options for the generated application (Clean generates stand alone applications executing native code), profiling options (time and space profilers are included), diagnostic options, one can add aditional search paths, and there are several linker options (e.g. one can select static and dynamic linkers). | ||
+ | [[Image:applicationoptions.jpg|none]] | ||
+ | By default the output of a Clean program is displayed in the '''console window'''. The console is useful for small applications using text based input / output. The console window can be switched off for GUI-based programs. | ||
+ | |||
+ | Each Clean application uses a '''heap''' for the storage of objects ('''graph nodes'''). Nodes are allocated automatically (lazy, when needed). When they are no longer used, they are automatically removed by the garbage collector. There are '''two garbage collectors''' (a '''copying''' and a '''mark-scan''' one). The '''Clean run-time system''' decides during execution which collecting method is best to use. The initial, incremental and maximum size of the heap can be set. Also the maximum size available for the two '''stacks''' (to store return addresses and function arguments) can be set. Although Clean applications (due to the automatic memory management) use more space than comparable C code (where space allocation and de-allocation has to be controlled by the programmer), it is far less space hungry than other lazy functional languages. | ||
+ | |||
+ | One can switch on '''time or space profiling'''. In that case the run-time system will measure the time or space consumption when the application is running. | ||
+ | [[Image:a_timeprofile.jpg|none]] | ||
+ | When the '''time or space profiling''' option is chosen as application option, the measurements are dumped in a file during the execution of the application. There are two tools to examine the generated files. They can be launched from the IDE project menu ('''show time profile...''', '''show heap profile..'''). | ||
+ | |||
+ | One can use the profilers to make a more efficient application. When a '''function consumes a lot of time and it is applied frequently''' one can try to define a '''more efficient algorithm''' for that function. The '''time profiler''' will tell you which function to work on and what the time is that can be gained. | ||
+ | If the application is consuming too much space the '''heap profiler''' will show you which function is most '''space hungry'''. Space consumption can be improved by making functions or data structures '''strict''' or by using '''destructive updateable data structures''' (using uniqueness typing). | ||
+ | |||
+ | One can choose to do '''run-time checks'''. We advice to set this option. The code becomes slightly less efficient, but, when a program terminates unexpectedly it will '''always be clear what has happened'''. Clean programs actually do not crash very often. It can only happen when array indices are out of range, a partial function is called outside the domain, or when there is no more heap or stack space. All these errors can be detected at run-time. Use the Diagnostics panel of the Project Options to set this option. | ||
+ | |||
+ | One can use a '''static linker''' or a '''dynamic linker'''. If you use a dynamic linker, Clean code can be added to a running application (add '''plug-ins''' or link in a '''dynamic''' ). One can even decide to start with an empty application and link all code each time the application is started ('''lazy linking'''). In this way an application is always constructed using the latest version of the library modules available on the site. |
Latest revision as of 14:05, 5 July 2010
The Clean IDE is the kernel of the Clean System which forms the interface to the programmer and communicates with the other system components. To illustrate what the new IDE looks like and how to work with it we show on this page what you have to do to compile a simple program, the "Game of Life". The program shown here uses the object I/O library. While we explain what to do to generate an application, we also show you some of the options of the Clean IDE. If you work with the IDE, remember that
The IDE is entirely written in Clean. So, the IDE is also an example of a Clean program, and not a small one either! The 2.0 version of the IDE is currently only available on the Wintel platform. On the other platforms a much more restricted and older version of the IDE is available which is not discussed here.
Making a project and generating an application
Start the Clean IDE (CleanIDE.exe). You see an empty project window. First we have to make a new project (or open an existing project). A Clean program consists of definition modules (.dcl files) and implementation modules (.icl files). A definition module indicates which definitions defined in the corresponding implementation module are exported. The topmost root module (the main module) is always an implementation module.
Open the main module of the "Game of Life" , LifeGameExample.icl (in ObjectIO Examples, Life folder). The source text of this Clean implementation module will be displayed in a text window and can be modified with the built-in editor (see below).
We now make a new Clean project, which will have LifeGameExample as main module.
Choose "New Project..." and a new project will be made. The project administration needs to be saved in a file (e.g. LifeGameExample.prj). The name of the main module (LifeGameExample) will appear in the project window.
The LifeGameExample uses other Clean modules, namely modules from the StdEnv library and modules from the Object I/O library. Each project has an environment in which it is specified which libraries are being used in the project.
The IDE has a couple of popular environments predefined. You have to choose which one you would like to use in this particular project. From the "Environment" menu choose "Object IO". Now the IDE knows which libraries to use in this project.
By the way, one can define new environments ("New Environment...") or change existing ones ("Edit Current..."). One can set the libraries to be used, by adding the paths of the folders in which the corresponding Clean source modules can be found. In the environments one can also include "real" libraries containing object code (Static Libraries and Dynamic Libraries). One can even define which IDE components (Tools) to use (which Clean compiler, e.g. version 1.3 or version 2.0 , which linker, and so on). In this way you can easily assign your own preferences to a project or switch from settings just by choosing another environment setting. The environments will be remembered by the IDE, the chosen environment will be remembered in the project administration file.
In addition to the environment you might also want to use more project specific libraries which you might have created to structure your projects, but, which are too specific to put in an environment. For example, the Life Game has a help facility. The corresponding Clean modules are put in a separate folder to be shared by other examples.
Choose "Project Options..." from the "Project" menu, select the "Paths" panel and add the library "ObjectIO Examples\gui utilities" to the Life Game project paths.
Now all libraries used by the "LifeGameExample" are included and we can generate the application. Of course, next time, when you open the Life Game project, everything is remembered and you can start right away with compilation.
From the "Project" menu choose "Update and Run" . All Clean modules used by "LifeGameExample" will appear in the project window. Those modules which are not up to date will be compiled to abc code. If no errors are found, the code generator will translate all abc-files to object code. Finally, the linker will build the application. If everything is fine, the Clean IDE will launch the application automatically.
Make new life cells in the window of the Life Game application by clicking with the mouse in de window and choose "Play" from the "Commands" menu.
Some features of the editor
The text editor uses syntax coloring for keywords, characters, strings, tabs, comments and backgrounds. You can set your own colors. Different kind of colors can be chosen for the different types of windows. Also fonts, font size and tab size can be set. There are several kinds of windows: for displaying implementation modules, definition modules, type information, errors and warnings, search results, project information, text files). Drag and drop of files is supported.
The various editor commands can be completely customized as well.
One can search for a piece of text in a window. The search string can be indicated by a regular expression. One can also do a global search to find all occurrences of a certain identifier (in the project, in the environment). The search facility knows about Clean language constructs (e.g. it will skip comments). It can find the definition or the implementation of an identifier, but it e.g. can also find all instances of a certain class. The editor can check whether brackets are balanced (also for list and record brackets). One can easily jump to the next error or next search result found.
Compiler Options
The Clean compiler is a very fast one. It includes a fast and smart strictness analyzer (abstract reduction) leading to more efficient code. The compiler can also reuse space occupied by uniquely typed objects. For each implementation module you can set the appropriate compiler / code generation options.
Project Options
Many options can be set for each project. There are among options for the generated application (Clean generates stand alone applications executing native code), profiling options (time and space profilers are included), diagnostic options, one can add aditional search paths, and there are several linker options (e.g. one can select static and dynamic linkers).
By default the output of a Clean program is displayed in the console window. The console is useful for small applications using text based input / output. The console window can be switched off for GUI-based programs.
Each Clean application uses a heap for the storage of objects (graph nodes). Nodes are allocated automatically (lazy, when needed). When they are no longer used, they are automatically removed by the garbage collector. There are two garbage collectors (a copying and a mark-scan one). The Clean run-time system decides during execution which collecting method is best to use. The initial, incremental and maximum size of the heap can be set. Also the maximum size available for the two stacks (to store return addresses and function arguments) can be set. Although Clean applications (due to the automatic memory management) use more space than comparable C code (where space allocation and de-allocation has to be controlled by the programmer), it is far less space hungry than other lazy functional languages.
One can switch on time or space profiling. In that case the run-time system will measure the time or space consumption when the application is running.
When the time or space profiling option is chosen as application option, the measurements are dumped in a file during the execution of the application. There are two tools to examine the generated files. They can be launched from the IDE project menu (show time profile..., show heap profile..).
One can use the profilers to make a more efficient application. When a function consumes a lot of time and it is applied frequently one can try to define a more efficient algorithm for that function. The time profiler will tell you which function to work on and what the time is that can be gained. If the application is consuming too much space the heap profiler will show you which function is most space hungry. Space consumption can be improved by making functions or data structures strict or by using destructive updateable data structures (using uniqueness typing).
One can choose to do run-time checks. We advice to set this option. The code becomes slightly less efficient, but, when a program terminates unexpectedly it will always be clear what has happened. Clean programs actually do not crash very often. It can only happen when array indices are out of range, a partial function is called outside the domain, or when there is no more heap or stack space. All these errors can be detected at run-time. Use the Diagnostics panel of the Project Options to set this option.
One can use a static linker or a dynamic linker. If you use a dynamic linker, Clean code can be added to a running application (add plug-ins or link in a dynamic ). One can even decide to start with an empty application and link all code each time the application is started (lazy linking). In this way an application is always constructed using the latest version of the library modules available on the site.