This email is about chgen/gencpp/genjava integration (if that is what you intended :-) and pr_init() replacement. RJLRef: $PH/COOL-GEN/gencpp_genjavaIntegration050328.txt ---------- > From ralmonte@cs.uml.edu Mon Mar 28 18:22:14 2005 > To: "Bob Lechner" > Subject: How to use eclipse to connect to mercury.cs.uml.edu. etc. > Hi Prof. Lechner, ---------- > > [RJL]I prefer a pre-processor that converts .dat files to/from SV/TT/TA. > > Lots of XML parsers exist so auto-generating an XML parser 'grammar' > > or schema for .dat-files from the genxml schema that represents TT and TA > > metadata has more value. This is just another chgen-based application. > > I didn't mean to use XML-parser, but using the current .dat file, parse it > and convert it to > neutral syntax in which we could decide in which language to generate the > library. > Nothing really fancy like a compiler, just regular .dat --> abstract > syntax -->semantic syntax > Doing this seems odd to me. Obviously I need more explanation. I presume you mean a .dat file not metadata TT, TA etc. But what does 'using' it mean? A .dat file is just data, not code, and its syntax does not vary. You can think of it as a typed list of ASCII tuples or structs, whose type depends on its first byte. SV,TT,TA define its external format. pr_util or equivalent from chgen or gencpp or genjava provides its C, C++ or Java internal format and generates its API code library. Gencpp almost completely subsumes genv12 + KMiu's 64-bit fixes. and it already has two C++ options, although not a C-language one. All three are data-compaatible (have interchangeable data file format) Do you mean merging genv12, gencpp and genjava into one program with a single input schema.sch parser and multiple back ends for code generation in C, C++, Java, etc.? That is a nice future goal. Note that there is no external source code to parse, just data. genv12 already converts schema.sch into schenma.msdat, and chgen, gencpp, and genjava can already pr_load that. The rest of *gen* code is back-end code generation for C/C++/Java. It is certainly possible to generate all three C, C++ or Java code versions or more from one program. If written in C++ or Java, they can inherit any sharable output generation such as comments. for people and for doxygen, a free documentation browser that is compatible with Javadoc. I believe all three versions should first work separately. I would prefer that .msdat content be prefixed to the .dat file, loaded first, and interpreted by chgen to generate a reflective compilable code base (not just interpreted during the application - gendb did this] After a single schema.sch pre-processor pass, one .msdat file should be the input to the GEN code generator family. (Later, we could have one .msdat file per namespace.) The generated code API processes the application database defined by the application's schema.sch file and .msdat tables. > ----- C lib > -----> C++ lib > -----> Java lib > ------> C# > ------> etc.... > > Obviously, it will be more suitable for C++gen.. > > Yes, I will continue with pr_init() in my spare time. pr_init() behavior with empty filelist: ------------------------------------- I had another thought on pr_init() as I looked at $CASE/96s523/bdesym. (rcostell + rconnell's project using genv10.2). There is mention in a file (that I lost after adding comments) of a pr_init(*) call with NULL "" filelist (but non-null viewdefs file). It would be interesting to trace pr_init's action with a null filelist. I expect that it initializes the hcg_structs with the allowed views (table type lists, not version numbers which we will ignore) and initialize rowcount and maxPkey to an empty range. Then I'd expect (or upgrade) pr_load() to populate the tables and update maxkey as we will certainly require this in the future. pr_replay calls pr_init with a filelist that pr_log created earlier from the current pr_init filelist. In the future, this also will contain just one filename. Key compresson from 8 or 12-byte ASCII to 32-bit unsigned int: -------------------------------------------------------------- Key compression #defines a bit-size for each key component: ttidx, version# and row# (currently 8,8,16 bits since genv7). Another inspection (and test) opportunity is to see if key compression still 'does the right thing if these field lengths become 8,0 and 24? Version number testing might still work without version #s but it probably also needs code changes if we remove pr_init(). View Definitions must be maintained: ----------------------------------- Note that view definitions (defined in a chgen user manual section) are still important without version numbers: One viewname can select a subset of table types during input, and another during output. Another view can select a subset of tables to be logged, such as event types and state transiions for testing. R Lechner