Difference between revisions of "ApCoCoA-1:GUI"
From ApCoCoAWiki
m (→Extensability: update with example) |
m (GUI TNG moved to ApCoCoA:GUI: This article refers to the new ApCoCoA gui. therefor, it should not be part of the general namespace, but of ApCoCoA's) |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
== Language(s) == | == Language(s) == | ||
| − | *C++ with some C for certain tasks | + | *C++ with some C for certain tasks, i.e. lexer and parser. |
* 64bit clean | * 64bit clean | ||
| − | * GUI is based on qt4, since a GPL version is available on Linux, MacOSX, UNIX and MS Windows. | + | * GUI is based on qt4, since a GPL version is available on Linux, MacOSX, UNIX and MS Windows. The latest release is qt-4.0.1 . qt4 is available in three different releases: A desktop, a light desktop and a version for the console only. Using qt provides portable classes to to threading, sockets, internationalisation, file operations, etc. which takes a lot of the burden of porting away from us. |
== Looks & i18n == | == Looks & i18n == | ||
| − | Should be pretty much a clone of the old CoCoA-GUI, i.e. similar/identical | + | Should be pretty much a clone of the old CoCoA-GUI, i.e. similar/identical menu-layout, shortcuts, and so on. We can use i18n, i.e. internationalisation |
| − | menu-layout, shortcuts, and so on. We can use i18n, i.e. internationalisation | + | with UniCODE, so one can translate the CoCoAGUI to foreign languages easily without touching the code or the need to recompile the programm. The tr()-macro in qt provides such a functionality which is nicely done and easy to handle for non-programmers, i.e. qt-linguist provides a gui for the task. The result of those translations is provided by a blob that just has to be copied into the build directory. It just works without recompilation. The language can be changed at runtime and is immediatly switched. |
| − | with UniCODE, so one can translate the CoCoAGUI to foreign languages easily | ||
| − | without touching the code or the need to recompile the programm. The tr()-macro | ||
| − | in qt provides such a functionality which is nicely done and easy to handle | ||
| − | for non- | ||
| − | of those translations is provided by a blob that just has to be copied into | ||
| − | the build directory. It just works without recompilation. The language can be | ||
| − | changed at runtime and is immediatly switched. | ||
== Internal Layout == | == Internal Layout == | ||
| Line 27: | Line 20: | ||
* Since there is no way to interrupt a computation one cannot write a CoCoA-debugger | * Since there is no way to interrupt a computation one cannot write a CoCoA-debugger | ||
* There are no meaningful error messages from the parser | * There are no meaningful error messages from the parser | ||
| − | * Internally the code is a total mess, i.e. instead of using the parser directly we build a list/tree of cterms which are then parsed internally again. While doing that we do some really nonportable truly ugly optimizations | + | * Internally the code is a total mess, i.e. instead of using the parser directly we build a list/tree of cterms which are then parsed internally again. While doing that we do some really nonportable truly ugly optimizations (building an array of function pointers which we call with opcodes[funtion]) |
* The code is pretty much undocumented and the coding-style is utter crap. There are tons of macros that obsfucate the code and rewriting those is not an option since it is propably more work then a complete rewrite. | * The code is pretty much undocumented and the coding-style is utter crap. There are tons of macros that obsfucate the code and rewriting those is not an option since it is propably more work then a complete rewrite. | ||
* The code is littered with old/unsused code, i.e. support for KDE, MacOS 9, DOS, etc. The qt-GUI build uses different C++ sources and makefiles. The qt2->qt3 port is a really big mess using a helper class from Trolltech. | * The code is littered with old/unsused code, i.e. support for KDE, MacOS 9, DOS, etc. The qt-GUI build uses different C++ sources and makefiles. The qt2->qt3 port is a really big mess using a helper class from Trolltech. | ||
| Line 34: | Line 27: | ||
== What to do? == | == What to do? == | ||
| − | There have been plans to migrate the current CoCoAL to the new CoCoALib. Since the new CoCoALib is | + | There have been plans to migrate the current CoCoAL to the new CoCoALib. Since the new CoCoALib is approaching usability, I would consider it feasible to attempt such a port. I would suggest doing the following course of action: |
| − | # Write a new parser. The grammar and lexer are fine but as mentioned above the internal workings of the CoCoA client are pretty much crap. Since the CoCoALib doesn't support all features that the CoCoAL needs (by design?, i.e. what about | + | # Write a new parser. The grammar and lexer are fine but as mentioned above the internal workings of the CoCoA client are pretty much crap. Since the CoCoALib doesn't support all features that the CoCoAL needs (by design?, i.e. what about sockets, all non-mathematical stuff) I would suggest writing a CoCoAL2cpp compiler, that translates the CoCoAL to C++ using the new CoCoAL. For some details see [Lit 1] |
| − | # Once the compiler works, one can | + | # Once the compiler works, one can write an interpreter by swapping out the code-creation to use CoCoALib directly. In addition to the regular interpreter one can also implement a debugger. We should also be able to provide proper error messages. |
# Wrapping a QT-interface around it is little work in itself since qt provides tools for rapid prototyping and most of the needed classes are quikly implemented (menus, shortcuts, MDI, ...) | # Wrapping a QT-interface around it is little work in itself since qt provides tools for rapid prototyping and most of the needed classes are quikly implemented (menus, shortcuts, MDI, ...) | ||
| − | |||
== Architecture == | == Architecture == | ||
| Line 47: | Line 39: | ||
# Modularity: less code duplication and reducred complexity | # Modularity: less code duplication and reducred complexity | ||
| − | # Asynchronus Development cycle: Due to 1) we can develop and test GUI and computational kernel | + | # Asynchronus Development cycle: Due to 1) we can develop and test GUI and computational kernel independently. Another added bonus is that GUI and computational kernel can be compiled using different modes, i.e. on MacOSX GUI application can only be compiled in 32bit mode due to its hybrid 32/64 bit development model. Once the client wants to adress more than 4G of memory the 32bit client will fail. In 06/2005 this is not really an issue since there are few Macs with more than 4G ram (the dual models go up to 8G) but a year or two down the road 4G+ will be commonplace. Besides MacOSX Solaris also employes a hybrid 32/64 bit mode due to legacy support. As a consequence many libraries are not available in 64 bit per default and if they are available one has to spend some time to set things like LD_LIBRARY_PATH appropriatly for a given machine. |
| − | == Extensability == | + | ==Extensability== |
| − | |||
| − | PlugIn-architecture using | + | PlugIn-architecture using loadLibrary (Linux, MacOSX, Unix) or LoadDLL (Win32) |
Example: LU decomposition on a 500000x500000 sparse matrix with roughly 13 million | Example: LU decomposition on a 500000x500000 sparse matrix with roughly 13 million | ||
non zero entries. | non zero entries. | ||
| − | * Umfpack + Standard Fortran BLAS: 3.5 | + | * Umfpack + Standard Fortran BLAS: 3.5 hours using 6 Gig RAM |
| − | * Umfpack + P4 Atlas Blas: 60 | + | * Umfpack + P4 Atlas Blas: 60 seconds using 2.5 Gig RAM |
| − | Since those Plug-Ins can be loaded at run-time these can be architecture specific and | + | Since those Plug-Ins can be loaded at run-time these can be architecture specific and one can experiment much more rapidly. |
| − | one can experiment much more rapidly. | ||
| − | Since we will need Eigenvalue-solvers for a reimplemented SOLVE using Borderbases this | + | Since we will need Eigenvalue-solvers for a reimplemented SOLVE using Borderbases this can make quite a difference with large systems. Potential libraries are: |
| − | can make quite a difference with large systems. Potential libraries are: | ||
* Classic Fortran Lapack | * Classic Fortran Lapack | ||
Latest revision as of 14:48, 14 October 2007
This page is meant for discussion regarding the design of a new GUI for CoCoA.
Language(s)
- C++ with some C for certain tasks, i.e. lexer and parser.
- 64bit clean
- GUI is based on qt4, since a GPL version is available on Linux, MacOSX, UNIX and MS Windows. The latest release is qt-4.0.1 . qt4 is available in three different releases: A desktop, a light desktop and a version for the console only. Using qt provides portable classes to to threading, sockets, internationalisation, file operations, etc. which takes a lot of the burden of porting away from us.
Looks & i18n
Should be pretty much a clone of the old CoCoA-GUI, i.e. similar/identical menu-layout, shortcuts, and so on. We can use i18n, i.e. internationalisation with UniCODE, so one can translate the CoCoAGUI to foreign languages easily without touching the code or the need to recompile the programm. The tr()-macro in qt provides such a functionality which is nicely done and easy to handle for non-programmers, i.e. qt-linguist provides a gui for the task. The result of those translations is provided by a blob that just has to be copied into the build directory. It just works without recompilation. The language can be changed at runtime and is immediatly switched.
Internal Layout
There are some problems with the CoCoA 4.4 client:
- One can't interrupt a computation
- Since there is no way to interrupt a computation one cannot write a CoCoA-debugger
- There are no meaningful error messages from the parser
- Internally the code is a total mess, i.e. instead of using the parser directly we build a list/tree of cterms which are then parsed internally again. While doing that we do some really nonportable truly ugly optimizations (building an array of function pointers which we call with opcodes[funtion])
- The code is pretty much undocumented and the coding-style is utter crap. There are tons of macros that obsfucate the code and rewriting those is not an option since it is propably more work then a complete rewrite.
- The code is littered with old/unsused code, i.e. support for KDE, MacOS 9, DOS, etc. The qt-GUI build uses different C++ sources and makefiles. The qt2->qt3 port is a really big mess using a helper class from Trolltech.
- Licensing of the code is also a problem, since it isn't clear who wrote what.
What to do?
There have been plans to migrate the current CoCoAL to the new CoCoALib. Since the new CoCoALib is approaching usability, I would consider it feasible to attempt such a port. I would suggest doing the following course of action:
- Write a new parser. The grammar and lexer are fine but as mentioned above the internal workings of the CoCoA client are pretty much crap. Since the CoCoALib doesn't support all features that the CoCoAL needs (by design?, i.e. what about sockets, all non-mathematical stuff) I would suggest writing a CoCoAL2cpp compiler, that translates the CoCoAL to C++ using the new CoCoAL. For some details see [Lit 1]
- Once the compiler works, one can write an interpreter by swapping out the code-creation to use CoCoALib directly. In addition to the regular interpreter one can also implement a debugger. We should also be able to provide proper error messages.
- Wrapping a QT-interface around it is little work in itself since qt provides tools for rapid prototyping and most of the needed classes are quikly implemented (menus, shortcuts, MDI, ...)
Architecture
We should separate the qt-client from the computational kernel. There are a number of reasons to do that:
- Modularity: less code duplication and reducred complexity
- Asynchronus Development cycle: Due to 1) we can develop and test GUI and computational kernel independently. Another added bonus is that GUI and computational kernel can be compiled using different modes, i.e. on MacOSX GUI application can only be compiled in 32bit mode due to its hybrid 32/64 bit development model. Once the client wants to adress more than 4G of memory the 32bit client will fail. In 06/2005 this is not really an issue since there are few Macs with more than 4G ram (the dual models go up to 8G) but a year or two down the road 4G+ will be commonplace. Besides MacOSX Solaris also employes a hybrid 32/64 bit mode due to legacy support. As a consequence many libraries are not available in 64 bit per default and if they are available one has to spend some time to set things like LD_LIBRARY_PATH appropriatly for a given machine.
Extensability
PlugIn-architecture using loadLibrary (Linux, MacOSX, Unix) or LoadDLL (Win32) Example: LU decomposition on a 500000x500000 sparse matrix with roughly 13 million non zero entries.
- Umfpack + Standard Fortran BLAS: 3.5 hours using 6 Gig RAM
- Umfpack + P4 Atlas Blas: 60 seconds using 2.5 Gig RAM
Since those Plug-Ins can be loaded at run-time these can be architecture specific and one can experiment much more rapidly.
Since we will need Eigenvalue-solvers for a reimplemented SOLVE using Borderbases this can make quite a difference with large systems. Potential libraries are:
- Classic Fortran Lapack
- Intel Math Kernel Library
- Sun PerfLib
- Atlas
