Updated 2016-11-16 03:43:55 by escargo

Tcl Relational Algebra Library, or TclRal, a C-based Tcl extension by Andrew Mangogna, implements the Relational Algebra. It introduces tuple and [relation] data types and a set of commands that operate on them.

Attributes  edit

website
http://chiselapp.com/user/mangoa01/repository/tclral
website
http://repos.modelrealization.com/cgi-bin/fossil/tclral
website (deprecated)
http://tclral.sourceforge.net/
website (deprecated)
http://sf.net/projects/tclral/
current release
0.11.8
release time
2015-09-30

See Also  edit

Relations as Stacks
Relations as Object Oriented Stacks
Relation Oriented Programming with Raloo
crosstab a la Relations
Rough sets a la Relations
Relation Transitive Closure
rosea

Documentation  edit

official documentation
TclRal: A Relational Algebra for Tcl (alternates: 1 2) ,Andrew Mangogna ,Thirteenth Annual Tcl/Tk Conference ,2006

Examples  edit

TCL calculate mapping, stackoverflow, 2016-11-11
An example by Andrew of loading some relationships into TclRal in order to then produce a Cartesian map.

Development  edit

fossil repository

Description  edit

The Third Manifesto lists TclRAL as:
an implementation of the relational algebra concepts in TTM as an extension of the Tcl language. It does not attempt to mimic the syntax of Tutorial D, but does implement a complete set of relational operations in a manner that is adapted to the Tcl programming environment. Since many of the systems listed are described as not quite complete, TclRAL seems to do Very Good in an area of heavy duty computer science.

GAM 2007-11-19

In the spirit of full disclosure, I wrote the synopsis that is on the Third Manifesto web site. Mr. Darwen was kind enough to offer to put a link to the project on his web site after one of his associates brought it to his attention. He asked me to provide a synopsis which is what is found on the web site.

News  edit

GAM 2015-10-09: Version 0.11.8 is now released. This corrected a bug that could cause a segmentation violation should a relvar trace callback return an inappropriate value. Precompiled binaries for the major platforms are available in the fossil repositories.

GAM 2015-09-10: Version 0.11.7 is now released. This version follows 0.10.2. Other versions in the 0.11 series saw only limited distribution. This version corrects several bugs and improves the way that procedural constraints are dealt with. This has been much improvement in the ability to serialize a set of relation variables to a SQLite database. SQLite serialization places each relvar in its own table and defines SQL foreign key constraints to enforce the referential integrity implied by the TclRAL constraints. Support for building under Tcl 8.4 has been eliminated. Precompiled binaries for popular platforms are available from the fossil repository as well as from Sourceforge.

GAM 2012-03-10: Version 0.10.2 is now released. Please see the info at sourceforge.net This is a bug fix release and all users are encouraged to upgrade to this release.

GAM 2011-10-22: Version 0.10.1 is now released. Please see the info at sourceforge.net All users are encouraged to upgrade to this release.

GAM 2011-06-13: Version 0.10.0 is now released. Please see the info at sourceforge.net. All users are encouraged to upgrade to this release.

GAM 2009-09-15: Version 0.9.1 is now released. This is primarily a bug fix release, but several new relation commands are also included. Users are encouraged to upgrade.

GAM 2009-014-18: Version 0.9.0 is now released. Revision 0.9.0 is a major change in TclRAL. Prior to this revision, TclRAL contained a fundamental conceptual error in the way it treated relation values. Previously, identification constraints were associated with relation values. This was incorrect as those constraints should only be associated with relation variables or relvars.

This error has been corrected in revision 0.9.0. However, the correction forced significant script level incompatibility with revisions 0.8.9 and earlier. Under the assumption that once backwards compatibility is broken it does not matter how large the break is, TclRAL 0.9.0 cleans up a number of command interfaces, adds new commands and discards much accumulated cruft. The release notes give the details.

Although 0.8.9 is stable and any significant bugs will be fixed, new designs should begin to use revision 0.9.0. To aid the transition, revision 0.9.0 is able to read files containing the serialization format from 0.8.9 and earlier. People with serialized data that needs to be moved forward can read that data with 0.9.0 and reserialize it to be current.

AM 2006-10-01:

I recently released Version 0.8 of TclRAL and thought that now was an appropriate time to make this page a bit more active for anyone that may be interested in the extension and wish to ask questions or post examples.

Version 0.8 is a complete rewrite of the extension to improve the code base and lay in a more maintainable structure. The major new feature of 0.8 is referential integrity checking. My current vision for the future is (roughly):

  • Additional code rework and testing.
  • Adding a few new features.
  • Honing the command interfaces leading up to a 0.9 release.
  • At Version 0.9, freezing the command interface for longer term backward compatibility support.
  • Leading to a Version 1.0 release.

I won't be so bold as to state a time frame for all of this, but as I use the extension myself I am as anxious to see it improve as anyone.

AM 2007-02-06: Released Version 0.8.1. This version is script compatible with 0.8 and includes some new commands and command options. Most notable is the ability to trace relvars in much the same manner that one can trace ordinary Tcl variables.

GAM 2008-17-01 Released Version 0.8.5. This is a small bug fix release to deal with a latent bug that was exposed by a small change in the semantics of Tcl 8.5. Small though the bug was, it did prevent serializing relvars when used with Tcl 8.5.

RZ: I had problems to compile tclral with native c-compilers on sun and sgi-irix. It is because of the use of unnamed structure/unions. Could you change this? With gcc there is no such problem.

Have you tried compiling 0.8.5 with the Sun compiler? I did remove the anonymous union that was being used. Unfortunately, I don't have access to native Sun and SGI compilers. Please let me know or post a bug report if there is still a problem.

LV I have tried this for you. The problem continues to exist because of this code:
typedef struct Ral_AttributeTypeScanFlags {
    Ral_AttrDataType attrType ;
    int nameFlags ;
    int nameLength ;    /* Since attribute names appear several places,
                         * we save the scan length result and reuse it*/
    union {
        int simpleFlags ;
        struct {
            int count ;
            struct Ral_AttributeTypeScanFlags *flags ;
        } compoundFlags ;
    } ;
} Ral_AttributeTypeScanFlags ;

typedef struct Ral_AttributeValueScanFlags {
    Ral_AttrDataType attrType ;
    union {
        int simpleFlags ;
        struct {
            int count ;
            struct Ral_AttributeValueScanFlags *flags ;
        } compoundFlags ;
    } ;
} Ral_AttributeValueScanFlags ;

The union in these two structures have no name. The current Sun compiler requires that any structure, union, or, I think, typedef must be named in some fashion.

GAM 2008-01-19

Oh bother! I corrected one of these and clearly missed the others. I'll put out a new release very soon. Thanks to whoever submitted the bug report with patch. Much appreciated.

GAM 2008-01-21

I released Version 0.8.6 and hope that I have managed to remove all the constructs that bothered non-gcc compilers.

GAM 2008-01-31

I released Version 0.8.7 to fix a problem with serialization. In Version 0.8.5, I accidentally included some modifications to the serialization code that I was working on for a future 0.9 release. Needless to say this broke things. Please upgrade to 0.8.7 if you are currently using 0.8.5 or 0.8.6. Sorry for the trouble.

GAM 2008-04-15

I released Version 0.8.8 to fix a series of problems where I had used some of the internals of the Tcl object system badly. I found a better way to enforce relational type integrity and interact properly with the internal Tcl types. The code no longer relies on registered type names and has a specific set of type names that are supported and these are then mapped to the internal Tcl types. All values are obtained via the Tcl_GetXXXFromObj() functions and the internal representation of Tcl types is no longer used. Thanks to all who posted bugs and for the very helpful discussion on comp.lang.tcl that helped me correct my misunderstandings.