RJLRef: $RBGB/ralmonteSupport2bde080416.txt From lechner@cs.uml.edu Wed Apr 16 18:53:53 2008 From: Bob Lechner Subject: Re: $RBGB tree - OKAY. I'll soon checkin a new CVS version (much smaller) for you To: ralmonte@cs.uml.edu (Robert Almonte) Date: Wed, 16 Apr 2008 18:53:52 -0400 (EDT) Many thanks, I appreciate your interest Robert, and hope you can expeditge some of my X11 problems. THen if you want to attend bde2java to make it more consistent in behavior with bdeUnix, that would also be very valuable as a stand-alone boot-strap mechanism for class and state diagramming. I will ask Ken to retain your account to support bde. See more notes below and in bdestatusnotes080414.txt. Bob Lechner > From ralmonte@cs.uml.edu Tue Apr 15 21:19:55 2008 > > Thanks, > I was able to copy $RBGB (around 165MB). > I will try to build it and let you know it goes. > > - About remote CVS > Eclipse could access any CVS repo remotely. I used to have a CVS > repo on mercury and I remotely accessed it through Eclipse. > No extra configuration is required on the server side than the > regular CVS REPO. > > Now, you will have to host it, I am an alumnus so I don't know how long > my mercury account will be active (so far it has been a year). > > > - About bde2Java or bde > Java is what I do everyday, which could make it really easy > for me to update it. There is so many code generation in java that > I don't know how BDE will be useful in that context (ArgoUML, Web > Services, SOA, Eclipse, etc). Definitely if you would like to update the > bde2java version, I could help. In addition, I find Java still to slow > for graphic demanding application unless you have a really latest PC. > But if your idea is to have distributed BDE using client/server > paradigm, then Java is the best. > > I was more interested in C++ and FOX GUI. > Probably make BDE stable, and then migrate it to FOX GUI and C++. > Or whatever idea you have in mind. > I updated $RBGGB/test/bdestatusnotes080414.txt after I sent it to you. Up front I prefixed some important problems with the bdeunix version, particularly with X11R6 libs (not enough tutorial info in manpages) event masks and logs, etc. I dond't have enough background, references or experience with X11. bdeUnix was written by UML students when X11/Motif was intensive part of Grinstein's popular graphics course (which I shold have taken :-( My code generation goal is to encapsulate state actions as methods and call them from the LCP interpreter, after bdeState class project code is added to bde/src and bde state kmodels are documented in LCP. Then, LCP control tables can be auto-generated by bde2SM to handle button-events. bde/src follows this style. E.g. my state model (in nodeops.cc comments) logs state TRs and button events (grep print init.cc). The model says I can only get to state SRN1 by a Button-Down event - yet node_resize crashes in state SRN1 in switch(button_event) case button_down whose assert(0) which should never happen, because X11's MotionNotify event implies a ButtonPress pre-condition according to Gay: Adv. Unix Programming Cp 27 [557-575] example (p. 570). Bde does not use XSelectInout (Gay p. 168). See bde/test/noderesizetest080415.txt e.g. for the pre-crash printout. Although bde should respond ONLY to Button1 events, bde's callbacks use Button*Mask which I changed to BUtton1*Mask last night to see if it helps. (grep XtAddEventHandler init.cc) Lots of unwanted events currently get thru XtDispatchEvent in bde's main loop. I use it to gain access to event-> properties: init.cc:1008: PASS = XtDispatchEvent(&event); // process one event I'd appreciate your opinion of the label notation %%SRN[B?[G# or A#]] and DPS(label) logging macro. Please inspect nodeops.cc for this. node_move and node_resize use it. Most *ops.cc files follow state models. My code generation goal is to encapsulate state actions as methods and call them from the LCP interpreter, after bdeState class project code is added to bde/src. Then, LCP control tables can be auto-generated by bde2SM for button-event dispatching. Bob Lechner > > Thanks, > Robert ----------------- Update to $RBGB/bdestatusnotes080414.txt Update 080415: More TBD bugfixes : 1. Solve CTRL-C signal handling problem - After keypress 's' for replay stepping was introduced, the signal_handler() which saved current data to bdeabort.dat does not work for other signals including CTRL-a. bde/src/handler.cc has the earlier code. bde/src/bdeReplay.cc:709:void Keypress(..) handles later 's' char keycode for logfile replay used in the hominid path-following project. 2. Eliminate the logging of useless events (e.g. Event type 0, name notused) (e.g. Etype 6:Motion Notify when button is NOT Pressed.?) 3. First TBD - RJL: How get to SRN1BD from SRN after CAS at BD??? end update 080415