ApCoCoA-1:GUI

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:

1. 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]
2. 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.
3. 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:

1. Modularity: less code duplication and reducred complexity
2. 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 loadLibraray (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