RJLRef: $RBGB/bdeStatusReply2sfrye060820.txt (symlinked from $PH/06f522/non-browsable-links/bdeRefactoringTasks060820.txt > From sfrye@cs.uml.edu Sun Aug 20 07:52:51 2006 > Subject: BDE issues :) > Professor, > > > #2 refactoring of pr_util without fixing BDE! I'll keep this in mind. > Maybe I'll stumble across some solutions to BDE bugs along the way, maybe > not. Maybe we are getting to a point where we should just rewrite BDE > [RJL: rewrite bde from scratch? Perhaps so. I MIGHT, if I were you, without my investment in bde-code-reading and no Linux PC at home. But I balk at the sheer code volume to restart, and am highly motivated to prove that my refactoring-with-ghost-vars approach will work on pr_util code migration from chgen to gencpp. So I am stuck with trying to regain a working version of bde for 06f522 and beginning this gvars_refactoring process frm that start point. Some key architectural ideas in bde and chgen/gencpp are designed to permit the following changes, so I believe the work can be modularized into tasks and partitioned among a team . Items 3 and 11 have a big impact on productivity and so have max priority. I will try listing them again - from memory (without definition because I go off into tangents that way:-) 1. Packaging for PCVS and the Eclipse IDE 2. Absorbing pr_util changes since 04f523 into chgen (v14) (retaining schema independence from bde). 3. Eliminating the version# byte from pfkeys (and removing pr_init() from pr_load.c). (A MAJOR code reduction, that permits version control of DB tables by CVS.) 4. Refactoring bde to use chgen13's pr_accessors.c instead of pr_{get,set}_type. 5. Refactoring bde to use pr_util from gencpp This includes: (a) combining chgen's intrusive parent-child lists with gencpp's STL Vector container classes for individual table types; and (b) migrating from chgen13's pr_accessors.c to gencpp's equivalent XX::{get,set)field class methods.). 6. Enhancing LCP to support pointers to guard condition evaluation functions along with pointers to state action routines. (Ref: TRAIL paper) 7. Refactoring bde's state actions as [guarded] single calls. This will permit migration of bde toward LCP state model interpretation and auto-generation of its table-driven control flow by gencpp enhancements. 8. Migrating the X11-specific GUI of bde to a subclass under the fox PI-GUI, and perhaps under 05f523/ralmonte's generic GUI on top of fox (fox as a special case of a wider class of PI-GUI platforms). [Ref: $PH/05f523/bde2fox (linked from $PH/06f522/05s523bde2foxProject)] 9. Evolving 05s523bde2foxProject to support MSWindows GUI as well as X11. 10.Resume work on logging and replay for bde, as a test case for generic code generaton by gencpp. 11. Last but not least: improving bde's make process by (a) removing Makefile dependence for fully concurrent builds of 4 versions. (b) avoiding redundant compilation of unchanged files in src and pr_util*. (This may require a more modern process than imake and gmake) [end RJL] > > #3 BDE Errors. > Since I've been using the xmkmfnolog.csh most of the compile problems have > gone away. I was under the impression that this only had to be used the > 1st time and that afterwards, I could use the make command. I THINK this > might still work as long as I always apply it to the root bde directory as > you recommended. > > However, I am still getting some errors like: > > ../src/fileio.cc: In function .void printrowcounts(char*).: > ../src/fileio.cc:872: error: .get_rcount. was not declared in this scope > > I traced the problem down to the definition of the get_rcount macro. This > macro is defined in bde/pr_util_nolog/i386-linux/probj/dprint.h. > > However there is no include for this file in my version of fileio.cc. [RJL: I spent a month or more debugging set_rcount and moving it around so it can become useful. Right now it's only for debugging the part of bde.cc, init.cc and calls to fileio.cc iand *menu* files that PRECEDE X11's event loop. This is because I can't get any printouts or File/Save* output, just empty or non-existxent files. Nor can I get Create_HGDialog box to recognize any pr_loaded HG-rows. My comments in fileio.cc suggest that last year's merge and/or my revs may have merged file-read and HG_row-selection code blocks by losing some critical code here. My bdegen13/bde compiles OK right now, but has not been fully checked in. dprint.h is #included indirectly from graph.h I believe. I have been giving my gdb runs more detailed inspections, by extracting and summarizing outputs, which is time-consuming, in $RBGB/test/bde*. using $RBGFB/test/cmd. as a starting point (modified online). Look at $RBGB/prep.csh which sets up command abbrev'ns for testing. ($RBGB is ~lechner/bde2alpha_rl/sandbox/bdeNT050526/bdegen13/bde) dprint,h is multiply #included by nested #includes. (94*schema.h is #included in dprint.c only because I put printrowcounts() there. That won't last - other dprint functions are schema-invariant, but printrowcounts() is schema-dwaspecific. Nevertheless, both should be auto-generated from chgen for an arbitrary schema.sch input. Here is the evidence: ----- grep "dprint.h" */*.{h,c,cc} > $RBGB/dprint.h.includes.060820 [edited to remove obsolete file refs and comments-RJL060820] ----------------------------------------------------- pr_util_log/94sbde_schema.h:18:#include "dprint.h" pr_util_nolog/94sbde_schema.h:18:#include "dprint.h" pr_util_log/dprint.c:38:#include "94sbde_schema.h" // #includes "dprint.h" pr_util_nolog/dprint.c:38:#include "94sbde_schema.h" // #includes "dprint.h"" pr_util_nolog/pr_load.c:39:/* includes dprint.h but not lut.h */ src/handler.cc:125:#include "dprint.h" src/leftmenu.cc:99:#include "dprint.h" src/menubar.cc:102:#include "94sbde_schema.h" /* for dprint.h */ src/leftmenu_cb.cc:206:#include "dprint.h" // for EP and DP macros src/menubar_cb.cc:128:#include "94sbde_schema.h" /* for dprint.h */ src/strdup.cc:81:#include "dprint.h" --------------------------------------------------------- [end RJL] > > I did a diff against your copy and found MANY differences (diff file at > bottom of email) but a cvs status indicates that I have the latest > version. It looks like the version in your directory doesn't even call > get_rcount like the version in cvs does. > > Have you checked the latest version of this file into cvs? I will try to > compile with your version later this weekend if I get some time and see if > it fixes the error. > [RJL: No - see above. I will try to update CVSROOT repository tomorrow. It's time-consuming since I must edit cvs diffs into reviision comments. CVS checkin will include pr_util_[no]log mods that chgen does NOT produce, so do NOT rerun chgen. My current pr_util_nolog version compiles, so your copy should also. My pr_util_log version probably compiles but its sources do NOT YET track my runtime bug'fixes' in pr_util_nolog.] [end RJL] > Have a nice weekend, despite the rain... :) [Thanks - RJL] [cut]