[ Home Page ] [ Eiffel Archive ] [ Eiffel Classes and Clusters ]
Written by Software Services Koeppen (email@example.com)
eiffelpd.tar.zip (35,571 bytes)
This is the second implementation. There have been several changes, improvements and bug fixes, though I would still consider it a beta release, since some constructs appear not clean enough to me, and there are many things which haven't been implemented yet. The classes should work under both X11R4 and X11R5. Currently, I use them under XFree86 1.3, running on a 386/33, 20 MB, with Esix 4.0.3a, and there are almost no problems, neither stability or performance.
This class collection represents a subset of the Athena Widget Set. Anybody familiar with this widget set should have no problems using the classes, since their functionality resembles very much the Athena Widgets. An application usually consists of a main class which creates an object of the class XTOPLEVEL. This object serves as the parent object for any other user interface object in the application. At object creation time, the objects are assigned a parent object, and the toplevel object is the topmost object in the whole application. It contains the event processing loop, which can be terminated only through a call to 'set_finished'.
For a more detailed example, you should look at Hipnotic, which is an interface to the Eiffel/S compiler. It makes use of almost all implemented widgets. The use of event handlers (classes XCALLER, XCALLABLE, XEVENT) resembles the X approach, but more detailed information on how to implement an application that handles events should follow in one of the next releases.
Hipnotic is an environment for the Eiffel/S compiler running under X11R4 and R5. Hipnotic makes it possible to perform all the operations involved in compiling and running Eiffel applications. It is easily extendable but not perfect yet.
Unfortunately, it evolved from a quick hack to test out the abilities of the Eiffel/S 1.0 compiler, so the documentation is quite poor and the program could stand a little more consistency.
Hipnotic offers several windows to compile and control an Eiffel program. The first window contains only a list of subclusters of the current cluster. It is possible to move up and down the cluster hierarchy and create and delete clusters. If a selected cluster is opened, a second window will be displayed. It shows a list of PDL files, .e files, .c and .h files and makefiles which are recognized by their extension which has to be .m !
There are several obvious operations for any of this lists such as deletion and creation of new entries. The list of makefiles contains a button which makes the invocation of make with a selected makefile possible.
The most important list is the list of the PDL files. The user can compile and run a program and control the compilation options as well as the resources of the program with the options and the control windows.
The source files for the program are in the subclusters hipnotic, extension and widgets. Each of these clusters contains a README file containing some additional information on the sources.
The file hipnotic.ad contains the resources for the program. This file should be copied to /usr/lib/X11/app-defaults/hipnotic (or wherever you keep your resource defaults) to make sure that the layout of the widget is set properly.
Black mask is an alpha version of an OODBMS to be used with Eiffel. Currently, it consists only of a single class BANY, which implements all of the needed functionality to establish an OODB. This OODBMS creates and uses dBase compatible data files, only the index files are not compatible.
There are still some bugs and missing features (the iterator stuff works, but not the way it should !), but black mask makes it possible to implement an OODB without too much effort. This alpha release serves only as a demonstration of a general principle (which is not very easy to implement, but easy to use).
I recommend reading Richie Bielak's excellent article series in Eiffel Outlook (Vol. 2,
No. 4 and No. 5, Vol. 3 No. 1), which gives a short but good introduction to the
principles and problems creating an OODBMS. Much of his ideas can be found in black mask
too, although I first had a different approach. My first idea was to make the persistence
of objects totally invisible to the programmer, who only should decide which objects will
be persistent. This means that the runtime system has to take care of where the objects
are, either in memory or on persistent storage, and has to fetch them accordingly. Since
all objects are attributes of other objects, they will be accessed by
usual attribute declarations and modified by some modification procedures.
This is the hook where a OODBMS could start its work. Persistent attributes generate an
access and modification function, but this is transparent to the programmer. Even very big
objects (with regards to structural complexity) can
be handled, because the needed attributes are only fetched from persistent storage when they are accessed. Otherwise, only an ID will point to the place where they can be found.
But all this is only theory. In reality, this approach fails due to many reasons: The transparent access to persistent attributes is a compiler and runtime system issue, to which I do not have access. The performance of such a system would be close to unacceptable for time critical applications. The question of where to store the code which the persistent objects obviously need to be created and to operate is not clear. Should it be in the application program, thus making Eiffel the DDL and DML ? Should it be in some kind of server ?
After encountering so many problems, I put the project aside, until I read Richie Bielak's articles. I saw many of the ideas I had, and possible solutions too. The only problem was the availability of his system. He uses Versant as an underlying DBMS, which is a big cost factor. So I decided to implement a free version of an OODBMS, which represents a mixture of ideas of different origin. Its base is an relational DBMS (creating this is another story, it still is not perfect yet, consider it alpha software).
On top of this sits the one and only class in this cluster, BANY. It allows the programmer to implement persistent objects. This project is not even half-begun, so you should take a look at the sample code (BTEST, BTEXT). Further documentation will follow. Any comments are welcome !
[ Home Page ] [ Eiffel Archive ] [ Eiffel Classes and Clusters ]