These are intended to be brief notes supplementing and outlining the course material presented in the course Introduction to Daylight. The Daylight manuals should be considered the text for the course and the authoritative documentation, and should be used in conjunction with these notes for best results!
In particular, the Daylight Toolkit Programmer's Guide and the Daylight Toolkit Reference Manual are the relevant manuals for the toolkit unit.
$DY_ROOT/contrib/src/directory. There are C, Fortran, and Perl example programs, the most extensive set for C.
The Daylight Toolkit has a strictly defined functional interface. It is defined by the dt_* functions and constants and their prescribed syntax as documented in the man pages. Daylight is committed to supporting this stable interface, thereby allowing forward compatibility of toolkit programs. Thus, features and functions may be added, but not taken away.
|Toolkit||Object library||License entry||Prerequisites|
|Reaction w/ Reaction Transform Capability||libdt_smiles.a||reaction||SMILES|
|Toolkit||Object library||License entry||Prerequisites|
|Widgets (basic)||libdw_xview.a||widgets depictwidget||SMILES|
The Rubicon Toolkit is a set of function calls not fully conforming to the object paradigm, thus prefixed "dc_", since it is a C interface. It still uses normal toolkit molecule and conformation objects, so it is very toolkit-like.
The Daylight system has integrated web capabilities which allow access to Daylight tools via web browser. The "DayCGI toolkit" is not a rigorously defined API as is the dt_ function libraries, the true Daylight Toolkit. Rather, DayCGI programming means combining an assortment of Daylight and non-Daylight tools to deliver Daylight database and computational services via the web.
In version 4.61, JavaGRINS is introduced providing a full function molecular editor for use in web applications. This tool will be incorporated in Daylight web applications and provided for use in custom user applications.
The Remote Toolkit is a system for providing toolkit services to personal computers by means of the DayToolserver, which runs on a unix machine. Remote Toolkit programs are identical to normal toolkit programs except for a few functions which must be called to make the client/server connection. In this way, native Mac and Windows applications may be written using Daylight toolkit calls.
The contrib directory contains several functions not part of
the toolkit but rather built upon toolkit functions. They have
been compiled into one library
The API (Application Programming Interface) comprised by the toolkit possesses object oriented features but is not a complete object-oriented language such as Smalltalk or Java. The concept of an object is essential to the toolkit interface, however, and atoms, bonds, molecules, datatrees, reactions, and many other things are toolkit objects. They may be created, manipulated, and destroyed easily using the toolkit interface. The Daylight Toolkit manages the objects for you - you need not be concerned with details of how the Toolkit represents the molecule or depiction.
An object is identified by its "handle" which is a simple and lightweight integer datatype. The handles themselves contain no information - they are not pointers to complex structures. Handles are opaque in that they cannot be dereferenced -- no access to the internal data structures is allowed. Handles are unique. Only one handle refers to one object. Handles are valid when they refer to an existing object, or invalid if they have been deallocated by the program, revoked by the toolkit or never assigned.
Because objects are managed by the Daylight Toolkit, the interface to various programming languages is straightforward: the Daylight Toolkit works equally well with C, FORTRAN, Pascal, or LISP.
Objects are self-describing: Each object "knows" what it is. Many toolkit functions are polymorphic: they will take a variety of different object types The function "asks" the object what type it is and performs the appropriate action.
|atom||atom in a molecule|
|bond||bond in a molecule|
|column||column of data in a pool|
|cycle||ring in a molecule|
|datafield||datum in a dataitem|
|dataitem||dataitem in a TDT|
|datatree||a THOR datatree (TDT)|
|depiction||2-D coordinates of a molecule|
|fieldtype||one datafield's type|
|hitlist||search/sort results in a Merlin database|
|merserver||Merlin server connection|
|monomerset||set of monomers|
|monomertable||table of monomer definitions|
|monopattern||search pattern for a monomer|
|multimer||multimer object (CHUCKLES)|
|path||results of a structural search|
|pathset||set of path objects|
|pattern||structural pattern (SMARTS)|
|pool||Merlin database ("pool")|
|program||external program object|
|real||real number object|
|sequence||ordered list of objects|
|server||THOR server connection|
|stream||enumerated constituents of another object|
|varimer||varimer object (CHORTLES)|
|varipattern||varimer pattern (CHARTS)|
|vbind||object providing faster evaluation of a match|
The toolkit function
dt_stream is able to
derive streams of constituent objects from base objects. Streams
of atoms or bonds can be derived from a molecule, streams of
datatrees can be derived from a database, streams of molecules
can be derived from a reaction. Streams are easily obtained and
used, but may be revoked if the base object is modified. Deallocating
a stream does not affect its member objects.
Sequences behave like streams but are not deallocated if a member object is modified. The are simply ordered lists of objects. Objects may be added or deleted from a sequence. Deallocating a sequence does not affect its member objects.
Regardless of the programming language used to access the toolkit, the toolkit will use dynamic memory allocation in creating objects. The implication of this is that the process size of an executable program will grow as objects are allocated and care must be taken that it doesn't grow uncontrollably. If a "memory leak" is present in a loop, the process size will increase until the program crashes or the computer is paralyzed. So the issue becomes how and when to reliably deallocate objects to avoid memory leaks.
In general, the essential task is to deallocate objects which
are allocated inside loops. For example, if a new molecule is
allocated for each iteration of a loop, either by
it must be deallocated inside the loop. When a molecule is
deallocated, all atoms and bonds beloning to the parent molecule,
and any streams over the molecule, are deallocated. Likewise,
if each iteration of a loop allocates a TDT object, it must
be deallocated. Objects which are allocated only once in a
program need not be deallocated, but it is considered good
form to do so.
SMILES is a language for representing a molecule as an ASCII string. The toolkit can parse a SMILES into a molecule and express a molecule as a SMILES. But it should be noted that the molecule object is not itself a SMILES. This correspondence between a toolkit object and a linguistic representation is common in the toolkit.
Objects persist until they are deallocated by the program, revoked by the toolkit, or until the program terminates. In contrast, in C, a returned string is a (char *) pointer to a location in memory containing the string, managed by the toolkit, and not guaranteed to persist after the next toolkit function call.
C is the native language of the toolkit and so the overhead required is least when programming in C. Thus, the speed of C programs may be superior to Fortran. C compilers are readily available on all machines, including Free Software Foundation GNU C (gcc). Most of the contrib code available from Daylight is in C, providing a head start for many programming tasks. But many programmers, expecially novice programmers, find C to be hazardous and cryptic.
Fortran compilers are readily available thanks to the historical importance and proliferation of Fortran code. Limitations in Fortran-77 were corrected in Fortran-90, but F90 is not as widely used and not supported by Daylight. Much less contrib code is available in F77.
An interpreted scripting language, Perl programs will generally be slower than C or Fortran equivalents. However, ease of use and no-compilation are advantages far outweighing performance loss for many users. The amount of contrib code is small but growing, and C programs are generally easily translated to Perl.
It is possible to construct wrappers for various other compiled and scripting languages, including Pascal, LISP, C++, Java, tcl, python, and guile. These are not currently supported by Daylight, however.
Debugging is essential to any project. In addition to usual debugging methods, the Daylight Toolkit provides error handling functions which can be used to debug, and "vigilance". The vigilant toolkit monitors handles and can report whether a handle is valid or not.
The following functions comprise this facility:
See the Daylight Toolkit Reference Manual, for the complete functional definitions of all 373 functions in version 4.61.
There is no Daylight toolkit for web development in any strict sense, with an integrated and consistent developer environment. However, there are several tools in the Daylight suite which are useful for web development