Nykditor (NyktOP - Editor) or NykTCL is as well a first project of and an editor for NyktOP.
It is a TCL/TK-Based Editor for different kinds of diagrams; supported is a configuration to edit Extended Entity-Relationship-Diagrams like those introduced by MOOSE. The class hierarchy diagrams modelled with this editor may be used to generate source code for C++, TCL, Smalltalk and Perl (preparation for java, idl and vb is in progress) via NyktOP's perl-based code generator, however they can not be interchanged with MOOSE.
(Contributed are also some other sample configurations:
The editor by default writes its files in SLANG format; sorry for that inconvenience, but currently this is the only file format, that is I/O-interface generated for all supported languages. (It is possible to dump files into another format called fdump, which is in fact a TCL-script to restore all values, but I would not rely on the usability of that format: it is not only language-specific, but it also depends on some internals of nyktop.tcl, which may change in future)
The reason for using TCL/TK for a bigger project like this is not, that I wanted to waste resources. I must admit, that I dislike bigger projects in interpretative languages w/o strict typechecking.
But for a generic editor this is exactly, whats needed: a language without strict typechecking.
If we did the project in C++, we would have to create a completely new application for each configuration. Walking through all steps, i.e. (re)modelling the datastructures, generating the code (which tends to be a bit bigger with the C++-generator) and finally invoking the compiler. the last step probably needs about a quarter of an hour, if we e.g. added an attribute (unfortunately I had decided to use a global include file to store attribute indices in - something that should be changed soon:}), and produces an executable of more than a meg.
Now the interpreted TCL solution needs about 10-15K configuration and
generated code for each config and reuses all other parts of the project.
The generator takes just a couple of seconds and a make/compiler process
over several minutes can be omitted completely.
Thus turnaround times can be reduced a lot. (Ok, a perl/Tk version would
have done the same, but when starting the project I did not even know that
perl had a Tk-interface ;))
It´s right: we buy this advantage with consumption of lots of cputime during application runtime (I´d dare to say, we are 10-20 times slower than using a C++ solution). But at least during development time, this is IMHO the cheaper way. (Besides: the bigger CC version would also take a little bit more of RAM)
We might think about creating an additional C++-Version that gets generated, when a configuration is designed and tested. But I (since I am still working alone on this project) unfortunately have not enough manpower to start an additional project.
Huh ? Still interested? :)))
Ok, U can get the outdated package here (gzipped tar; around 50k) or a newer version here (gzipped tar; around 100k) the newer version uses aggregation instead of inheritance for gfx-information, but it is not yet tested for anything other than States, MiniMoose & Patterner (nor implemented for ered).
just for Ur own convenience: There is a C-module here , that speeds up reading slang files a factor of five.
External links (just to name some of them)