DietLore Implementor's Page

The following assumes that the reader is familar with the features of DietLore and is ment for people who need to know more about the implementation.

Making DietLore

DietLore can be created by defining DIETLORE as compilation directive in the Makefile. It will avoid any usage of shared memory (shm.cc uses global memory instead), mapped files or any OS or memory semaphores. It will also turn off locking. DietLore will thus always require single-user mode but it will not be able to enforce it (it would need at least semaphores and mapped files (it could use normal file as well but this requires more work)). Unless for very specific reasons, do not use NO_LOCKING, NO_LOGGING or any of these compilation directives anymore. They are now all controlled via DIETLORE.

Cross-platform Compatibility

DietLore and Lore both support DEC OSF and Sun Solaris. DietLore should run on Linux 1.3 and higher (see also section "Known Problems" below).

Added Features

To avoid the usage of a lore db on the wrong platform I added several entries to the config.db file. When connecting these entries are checked as follows:

LORE_VERSION is either DIET or LORE
We currently do not support the usage of DietLore dbs with Lore or viceversa. The main reason is that the data stored in the log file has currently not the same format. While this could easily be fixed for a given platform, it is not 100% clear that this is the only possible problem.
VERSION_NO at the moment 1.0
This version number can be set in the Makefile for a new release. Currently if a difference in the version number of the executable with the Lore db is detected, a warning is displayed. This information can be used for automatic version migration of the database. Note that this is also the reason, why some files (lore.cc, Database.cc etc) are dependent on the Makefile and are compiled everytime the Makefile changes.
OS as determined by get_os()
PROCESSOR as determined by get_processor()
COMPILER as determined by get_compiler()

Guarantees that only a lore executable compiled on the same machine as the executable which generated the database can access the database. This ensure that we don't get into problems with different word sizes, different structure of system specific data structures (in the shared memory), little endian vs big endian etc. If we truly understand the implications of using a db generated on Solaris with Linux code, we can relax the current strict handling.

If you would like to reuse an existing db, add the entries by hand (the values are the same as the header of lore when executed with -v).

Known Problems with DietLore

There are still some problems which I did not feel responsible for and did not have the time to investigate. They are:

DietLore on Linux 1.3

I compiled DietLore on Snapper without problems, but I get a segmentation violation at the first cout << statement. If I compile the same code on Trout (Linux 2.x) this problem disappears.

Compiling on Linux

For some of the executables (eg lshow), make tries to generate a second rule which I can't find in the Makefile. I added some echo"" at the appropriate places (only at those where I cared) and would like to ask a Linux make specialist to fix it for good. Did nobody run into this problem before?

DietLore on Dec OSF

I have some strange parsing problems with tester 6 and 10. Issuing a command such as help; or an assignment and then issuing any other statement results in a syntax error for that statement. Reexecuting the statement again works.

Since the problems seems to be a yacc/lex problem on OSF and Vin and Roy don't need the OSF version anymore, I did not investigate much further (It somehow finds a syntax error in parse.cc on line 1355 (OSF version) 1496 (Solaris version)). Generating parse.cc on Solaris and then compiling on OSF did not help.

Michael Rys < rys@db.stanford.edu >