RJLRef; ~/01f522/MoreOnAsgntand4.txt Here are some corrections to path and file names, and answers to questions by Jenkins and Jaganathan plus more on the architecture of bde in the menu and state model area, and on bde's evolution and current version problems. - RJL 011028 I changed access to r-x for $CASE/bde. Sorry about that. You need r-x to paths and r-- to read/copy files. I don't expect you to execute bde yet - it won't build correctly. I will provide cvs checkout procedures if you want to try rebuilding bde. Note that bde uses UNIX/X11 not MSWindows. I do expect you to figure out how the case labels in bde/src/*ops.cc relate to the codes in state.h and .ps figures in /usr/proj3/case/bde/doc/idraw/ (.idraw is .ps and ghostview can display them in xterm windows.). The reason is so that you can design similar (but far simpler) state models for the OO MENU. You should describe how to integrate your design with or replace the code in bde/src/smselect.cc. (sm means StateModel.): ---------------------------------- // Name: smselect.cc // // Description: The functions in this file is used to set the state as well as // highlight and dehighlight the graphical menu at the left of the // interface. -------------------------------- (select.cc merely helps select a diagram for canvas display. and in retrospect should have been named hgselect.cc.) W.r.t Bill's question, there are really a pair of component or sub-machine state diagrams, that handle MouseButton event responses on the two left side menus only. Taken together, these two are called the OO MENU. (See OO MENU in the online bde User Guide (.ppt). You can ignore the top FILE menu and drawing actions inside the canvas. Bill is right that TWO pairs of deliverables are required - one for each radio-button menu. But they form an integrated whole - because they illustrate the direct product of two state machines: OO MENU button actions set the initial value of global variable 'state' to some value in state.h. Then the dobutton callback from XWindows makes the switch(state) enter the sub-machine starting at this state, for a particular canvas object type and method in bde/src/*ops.cc. Bill is right that TWO pairs of deliverables are required - one for each radio-button menu. But they are an integrated whole - because they illustrate the direct product of two state machines. I. Current problems with bde ---------------------------- These involve (1) state label inconsistencies, (2) timing for log file playback, and (3) porting to alpha platforms: (1) State Label Partitioning ----------------------------- I had tried recoding state.h values as hex digits, one for the class (HG, CG, HN, HL, HP, HI, HA, GX) and one for the operation (add/move/delete/restyls/etc.), and a third digit for the intermediate state within each class*method pair. Incomplete refactoring of code for that recoding causes bde to crash in ~/bde2alpha_rjl/bde/... Ideally, object type selection will change only the most significant of three hex digits in the value of state (to some value in state.h). Selecting an operation on any type should update only the middle digit of state. Finally, executing this transaction type on this object type should cause the least-significant digit to vary over (at most three states). Then pre- and post-conditions on OO MENU/dostate and changeAttribState can be defined in t erms of these three digts of state independently. Unfortunately, the state values #defined in state.h are not directly coupled to the statename[] array defined in smselect.cc. Furthermore they are not partitioned into three hex digits that can be updated independently from object and operation lists in OO MENU and transitions within *ops.cc actions. (To see these actions, do See II. Structure of smselect.cc below for more details of the OO MENU's interface with canvas operations. =========================================================== (2) usleep vs. nanosleep: ----------------------- An obsolete version of usleep prevented pr_log.c from compiling there; it should be ignored if chgen's -log option is not used. Current libraries for usleep don't work with this code. (pr_log.c uses usleep. So does JPsim/olcarch.) I just acquired the only text I have found which mentions usleep and [POSIX] nanosleep: [Gay: Advanced Unix Programming, SAMS 2000] It says don't mix these two incompatible standards. ========================================================= (3) Porting to alpha platforms: ---------------------------------- (3A) CVS branch tag for bde is bde2alpha_rv: ----------------------------------------- I am currently rebuilding bde in $CASE/bde, which must be checked-out with branch tag bde2alpha_rv, to get the correct code that worked on alpha platforms. My starting point is code to be checked in from ~/bde2alpha_rjl, which upgraded the version tagged bde2alpha_rv. (3B) Manual edits for alpha platform: ------------------------------- I copied 94sbde_schema.h and pr*.c files from ~/bde2alpha_rjl/bde/new_pr_util to $CASE/bde/new_pr_util. This directory had my manual edits to remove g++ -Wall warnings during compilation. (K Miu did similar but independent updates to ntansala's gencpp code.) Whenever $CASE/bde/pr_util/{*schema.h, pr_*.c} files are regenerated by chgen, they must be re-copied from new_pr_util to overwrite obsolete bde/pr_util files. $CASE/gen/ver_11 produces obsolete pr_util code that causes many g++ warnings; WARNING: bde/pr_util/Imakefile has pr_*.c and 94sbde_chema.h dependencies on SCHEMASRCS = ../schema/94sbde_schema.sch; so, if the schema.sch file changes, make will remove pr_*.c by re-running chgen. ==================================================== II. Structure of smselect.cc: ----------------------------- smselect.cc has an array statename[] used for printing messages about states of bde drawing operations. It also has this rotine: void dostate(Widget w, int client_data, caddr_t call_data) which calls changestate() to change canvas state and changes cursor as necessary: selected.changestate(w, client_data); /* This is where the state of the selected object changes */ /* The data of the state comes from newbutton.cc Callback */ The changestate function void Select::changestate(Widget stwd, int st) is only called from dostate, which is the OO MENU callback function. It divides its switch(st) cases into three groups: Group one is for initial states fromm the OO MENU; Group two is for 'secondary' states (beyond the initial state of a canvas operation with two or more states); Group three is for states (OO MENU combinations) that are not yet implemented or that do not make sense. The other function in smselect.cc is int Select::changeAttribState(int st) It is not called from dostate, but only from dialog.cc and from *ops.cc. ChangeAttribState also partitions the values in state.h: Group A is that subset of primary states that may recur in state models that can return to their initial staet (or never leave it). (These machines can repeat the same operation on multiple objects of the same type.) Both changeState and changeAttributeState can assign these values to the global variable 'state'. Group B is the secondary states that can only be assigned by changeAttribState, not by changeState. Group C (unimplemented states) is the same in both routines and may not be assigned in either of them. So the canvas operation state models in *ops.cc may update state to some value in Group A or B (depending on the previous state, which may have been set by dostate() via changestate). For a look at canvas state actions, see these switch(state), switch(button_op) and changeAttribState references in *ops.cc: (The latter represent next-state transitions from within bde's canvas state action routines in thetse case blocks.) ------------------- saturn.cs.uml.edu(224)> grep changeAttribState *ops.cc | wc 37 93 2609 saturn.cs.uml.edu(225)> grep 'switch \(state\)' *ops.cc | wc 20 72 725 saturn.cs.uml.edu(226)> grep 'switch \(button_op\)' *ops.cc | wc 35 136 1577 -------------------- ======================================================= III Upgrade plan for bde: ---------------------------- (A) alpha port cleanup in chgen itself: --------------------------------- Sathy Jaganathan will try to fix chgen so it produces new_pr_util automatically. This will help port any other chgen application to alpha platforms with 64-bit pointers and modern C++ compilers. (B) bde SAVE-AS .gif Option ------------------------- I will import the $CASE/97s523/bde2gif/yuwong/bde/extern_code directory that supports a SAVEAS type .gif FILE menu option. This option produced files which bde2htm converted into web-browsable ERD and STD diagrams for the JPsim demo on my home page. Caution: Many of the diagrams there there are really branch trees for the switch(state) and switch(event) source code. Please inspect some of these diagrams to see WHAT I DO NOT WANT! However, note that a radio-button menu state model inevitably looks like a tree, at least until it gets to a point of merging common actions. [Every CS/EE/CE major SHOULD know what a state diagram looks like, and how to verify by inspection that its transition labels define deterministic, not ambiguous, behavior. If you cannot verify this, your documentation is incomplete!] (C) usleep vs. nanosleep: --------------------- I need to fix pr_log sleep actions to use the chgen -log option which logs and (TBD:) replays bde database changes. (D) bde FILE/PRINT option: ---------------------- I need to fix fprint.cc so it generates correct .ps files for the displayed diagram (or al diagrams). (E) bde state.h and smselect.cc/statename[]: ---------------------------------------- The state values #defined in state.h and implicit in statenames[] will be recoded and made consistent in all places where they are used.