This is a UNIX-based log file compatible with the log files that are specified in the Enchilada testing tool. Each entry in the log file is defined with the following five information fields: DATE Date the log entry is made. The date format is ddmmmyy where dd is a one- or two-digit date, mmm is a three-character month name, yy is a two-digit year. E.g., 15apr97 AUTHOR Two- or three-character initials of author, uppercase, e.g., GLF. Non-unique initials are suffixed with a disambiguating digit. E.g., JJS1, JJS2. STATUS Entry status information, defined further below. FILE(S) File(s) affected by the log entry. DESCRIPTION Prose description of the entry. Log entry status values are the following: BUG Something that needs to be be fixed ASAP. TODO An enhancement that needs to be made. FIX A response to a BUG item that fixes the bug. The second line of the status entry of the FIX refers by date to the bug that it fixes. DO A response to a TODO item that does the thing to be done. The second line of the status entry of the DO refers by date to the todo that it does. ,FIXED Suffix attached to a fixed BUG item; a corresponding FIX entry appears at a later date in the log. ,DONE Suffix attached to a completed or TODO item; a corresponding DO entry appears at a later date in the log. &FIXED Suffix attached to an immediately fixed BUG item; no corresponding FIX entry appears at a later date in the log. &DONE Suffix attached to an immediately completed TODO item; no corresponding DONE entry appears at a later date in the log. This status convention is designed to leave historical information in tact. I.e., instead of changing the status of a BUG or TODO item permanently to FIXED or DONE, the suffix is attached and a new FIXED or DONE item is added later in the log. This allows us to see when a problem is noticed and when it is fixed. On occasion, BUG or TODO items will be handled immediately when they are entered. In this case, the suffix added is &FIXED or &DONE, which means there is no corresponding FIXED or DONE later in the log. The following linguistic conventions are used in the text of descriptions: * The descriptions of BUG and TODO items not fixed immediately are written in present tense, imperative voice. * The descriptions of FIX and DO items are written in past tense, declarative voice. * Generally, the description of a DO is brief, simply noting that the item has been completed, unless some particular difficulty or noteworthy circumstance arose, in which case such should be described. * Generally, the description of a FIX is longer, containing an explanation of how the bug was fixed. The best way to maintain the currency of LOG files is the following: * Small TODO items and all bugs should be added as soon as they are discovered. The definition of "small" for a TODO item is a reasonably immediate task that is considered too small to be added to the main project schedule. * All of the tasks in the main project schedule should be considered larger TODO items, log entries for which should be made when they are completed. The descrption of such scheduled tasks can be brief, refering by name to the scheduled task, e.g., "Milestone 1". * An effective way to deal with task-related log entries is to make them whenever a file is checked in. When this occurs, diff the file being checked in with the previous version and make log entries for each "major" change, where major is a change separate from other changes. The diff file itself can be discarded after the affected file is checked in. DATE AUTHOR STATUS FILE(S) DESCRIPTION ============================================================================== 25aug99 GLF BUG regexp.c Woe, yet another "how'd this ever &DONE work". In Regexp::Search, when the value of the char* text arg was "" (the empty string), things went badly amuck, ending up in a seg fault. The deal was that strchr was being called with "", leading to a null string being alloc'c, leading to a value of 0 for a pointer, and so on. Since this has shown up on the new thyme, I have a feeling that the specs for the regexp and/or strtok routines may have changed. Anyway, the fix is to add a check for strlen(text) == 0 at the top of Regexp::Search. 13aug99 GLF TODO menu.* and A number of things need to be done to probably menus. (1) Add down-pointing arrow others when menu goes off bottom of screen. (2) In service of what we want to do with Inferno tools, add a function that allows menu items to be added and removed, replaced, and appended. Append is basically the same as the current Include, but the name Append is clearer, particularly with the addition of remove and replace. (3) Change behavior, or allow behavior change option, the makes pulldowns behave the now normal way of staying put when clicked on, i.e., not requiring that the mouse button stay down to keep the menu visible. If there are differences in the details of how this works, use Apple as the model. 23mar99 GLF TODO ifc.c Finish geometry property updates started today. 22mar99 GLF TODO world.{h,c} Fix things so that more than one world *cannot* be created. Also, consider adding a static member to Interactor that points to THE world, so that all interactors will automatically inherit a pointer to THE same world. I'd like to do this with some implementation other than a static member, but I'm not sure it's feasible. 22mar99 GLF TODO interactor.{ Add an overload of Config with no args h,c} that defaults the Scene arg to THE world. This is motivated by the lameness of the comment for Interactor::Config in interactor.c. Note that we need to figure out the best way in general to get THE world, which is the topic of another log item. In conjunction with this change, update the doc for Interactor to explain the parameterless version of Config is the one that is normally called. The parametered version can be called if someone wants to config an interactor with properties other than those of the root world. 14mar99 GLF TODO idraw/ Well, I'm not completely sure that the Makefile observations made in the FIX entry just below are completely accurate. Viz., there may be something else going on in the way of library inclusion or dependency that caused the problem, not -l include order. What gives me pause about include order being the problem is the lack of any mention of it in the gld docs. However, I do recall this being problem, or at least seeming to be a problem, in the not too distance passt. Anyway, we should come to some full understanding of this issue one way or another, which is really the same conclusion made in the 12mar99 entry. The other disturbing problem with the Makefile is that it seems not to remake enough files when a change to idraw-interface-main.c and/or idraw-interfade.c is made. Specifically, the problem shows up as bogus behavior, not well traceable with gdb, and is fixed by make clean followed by make. It occurs to me that the friend relationship between idraw-interface and editor might possibly have something to do with it, but I'm relly only guessing here. Again, this issue should be come to grips with. To do so probably involves grubbing around in code that works with a make clean, which is code we figure works fine, which is code that seems like kind of a waste of time to dick with, but we really should just do it. 12mar99 GLF FIX idraw- Woe -- this was a scary one. The pro- 12mar99 interface.c blem was due to the order of libs SUN4G-work-work listed in the link step in the /Makefile makefile. There's comment in the -work-work Makefile with a bit more info. As the comment suggests, this order-of-linking problem should be definitively understood at some point. 12mar99 GLF BUG, idraw- Figure out why desrtructor dies. FIXED interface.c 2mar99 GLF TODO * Yet more making it simpler. To be consistent, an interactor should treat its shape and painter properties consistent. At present, a painter is not automatically alloc'd prior to config, but a shape is. This has led to a lot of confusion for me. So, here's the deal -- we should make shaping and painting easy to set at the Interactor level, and annouce for each interactor what its default treatment of shaping is. A particularly annoying feature of the current situation is that some things don't happen until after (Re)Config is called, and in some cases what (Re)Config does can't be changed. E.g., with StringEditor, the Reconfig unconditionally sets the shape to be stretchable, and there's no way after Reconfig to make it rigid. 2mar99 GLF TODO texteditor.* Here's another one for the "make it easier to use" file. Right now, in order not to blow up a text editor, one has to both construct the editor *and* call TextEditor::Edit with a text buffer. The latter call in turn requires that one understand the someone crytic text buffer constructor. All of this is way more complicated than it needs to be. The fix is to automatically alloc a TextBuffer in the TextEditor constructor, with a buffer size of, say, two times the editor size. Better yet, the buffer should automatically resize as necessary. In addition, the text editor should have an auto-wrap mode that acts like a combination of XEmacs and Mac Note Pad wrap modes. Some playing with Emacs and Note Pad will reveal the precise specs of the "combination". 25feb99 GLF TODO graphic.h, Figure out why Graphic wont work in place of FullGraphic in color-test.C. In particular, if fg is declared as Graphic instead of FullGraphic, fg->SetBrush(psingle) leaves fg->GetBrush still returning null. This is bizarre. Bottom line, in keeping with simplification theme in the other entries below of today's date, there shouldn't really be any diff between a Graphic vs a FullGraphic, at least when it comes to things like setting brushes, etc. Also, figure, if necessary, why this version of color-test.C doesnt work FullGraphic *fg = new FullGraphic(); Rect* rect = new Rect(0, 0, 20, 20, fg); Perspective* p = new Perspective(); InitPPaint(); fg->SetBrush(psingle); while this one does FullGraphic *fg = new FullGraphic(); Rect* rect; Perspective* p = new Perspective(); InitPPaint(); fg->SetBrush(psingle); rect = new Rect(0, 0, 20, 20, fg); The diff is that the first one puts the fg into the rect before the fg's brush is set. Since we're dealing with pointers, this seemingly shouldn't happen. This last problem may just go away with the removal of the who persisent stuff, which means we won't have to worry about this exact problem. Bottom line: clean this mess up! 25feb99 GLF TODO persistent.* & The whole persistent stuff really related files should go. It looks really stupid in the inheritance hierarchy, and as I just discovered, the obscure requirements for having to call InitPPaint in order to do any kind of drawing is *really* dumb. As with the entries that follow, there's a bunch of general clean up to do in the area of making graphics simpler to use. Even if a lot of the current capabilities remain, they should defaulted out so as not to be required explicilty of the user. InitPPaint is a perfect example of what should happen automatically in some clean way. 25fe99 GLF TODO streditor & Design and implement a tabbing dialog related in which tabs work as expected between streditors. 25feb99 GLF TODO/ graphic.C & In implementing the simple color test BUG related files file, it was determined that in order to use a GraphicBlock at all, a Perspective object has to be allocated, even though it is never explicitly referenced anywhere. If it's not allocated, then a whole slew of link errors about undefined perspective stuff occur. This clearly sucks. So, what should be done is to have a (default) perspective somehow automatically allocated so these link errors don't happen. 25feb99 GLF TODO/ ditto As exemplified in examples/graphics, BUG it appears to be necessary to explicitly declare a full graphic to hold the state for a graphic. This should not have to happen. I.e., the fix is to automatically alloc some (default) state for any Graphic. This problem is again illustrated in the simple color-test example, where if the dfault FullGraphic is not supplied to the Rect constructor, then IV blows up when it tries to reference the first thing it needs in the Rect's state, which happens to be a paint brush. Hence it dies as follows: Program received signal SIGSEGV, Segmentation fault. Width__6PBrush (this=0x0) at ../ppaint.c:297 (gdb) bt #0 Width__6PBrush (this=0x0) at ../ppaint.c:297 #1 0x3452c in getExtent__4RectRfN41P7Graphic (this=0x750f0, l=@0xeffff69c, b=@0xeffff698, cx=@0xeffff694, cy=@0xeffff690, tol=@0xeffff584, gs=0xeffff5f8) at ../polygons.c:88 #2 0x3d3e8 in getBounds__7GraphicRfN31P7Graphic (this=0x750f0, l=@0xeffff69c, b=@0xeffff698, r=@0xeffff694, t=@0xeffff690, gs=0xeffff5f8) at ../base.c:922 #3 0x3a578 in GetBounds__7GraphicRfN31 (this=0x750f0, x0=@0xeffff69c, y0=@0xeffff698, x1=@0xeffff694, y1=@0xeffff690) at ../base.c:401 #4 0x3a61c in GetBox__7GraphicRiN31 (this=0x750f0, x0=@0xeffff78c, y0=@0xeffff788, x1=@0xeffff784, y1=@0xeffff780) at ../base.c:407 #5 0x333a8 in GetGraphicBox__12GraphicBlockRiN31 (this=0x79b98, l=@0xeffff78c, b=@0xeffff788, r=@0xeffff784, t=@0xeffff780) at ../grblock.c:347 #6 0x32414 in Init__12GraphicBlock (this=0x79b98) at ../grblock.c:66 #7 0x32334 in __12GraphicBlockP6SensorP7GraphiciUi7Zooming (this=0x79b98, in=0x0, gr=0x750f0, padding=0, a=4, z=Continuous) at ../grblock.c:54 #8 0x13aac in main () at ../color-test.C:25 (gdb) which for your average schmoe is admitedly *quite* ugly. Again, the fix is not make a default graphic state happen automatically, so the user doesn't have to make one explicitly. 25feb99 GLF TODO/ color.* What's up with PColor vs Color? In BUG particular, why does Graphic::SetColors require a PColor vs a Color? If possible, there shouldn't be a difference. 16feb99 GLF TODO view.C, *.C Put some nice error messages and null ptr tests in View.C and possibly additional IV .C files. This is motivated specifically by a 206 lab meeting where gdb was used to find the following two runtime errors: a) A view's screen being null; chk for this can go whereever the screen data member is used. The message can be of the form: "Your screen is null -- make sure that your view constructor is passing in a valid screen to this view and that your constructor is calling View::View with the screen value." b) A view's window being null; chk for this whereever the window data member is used. The message can be of the form: "Your window is null -- make sure that your view Compose function is setting the w data member to the top-level interactor for the view (e.g., a Box, Tray, or MonoScene that contains all of the view's other Interactors." 9feb99 GLF TODO doc/examples/ Figure out why glue at left of "Press str-br-ed/ to read ... " is allowed to shrink to advanced.C size zero, when the comparable left glues in the rows immediately above and below do not shrink. The WeirdoGlue classs was set up to help track this, however, it doesn't really to the trick. The place that needs to be traced is in HBox::ComputeShape or even Box::Resize. I did a bit of this, but didn't finish. See what you can find. The gist of the problem appears to be that the box elem immediately to the right of the glue is being given a left position of zero relative to the left edge of the hbox. It appears, from a bit of tracing in Box::Resize, that glue is actually not placed via PlaceElement, but just used to compute relative positions of other (non-glue) elements. 2jul98 GLF BUG X11-world.c Ref to rep->display()->xdefaults got &FIXED Makefile compilation error. After a bit of poking, in particular in /usr/include/ X11/xlib.h, we find another case of XLIB_ILLEGAL_ACCESS not being defined. The fix is to add a -D for this flag to the Makefile. It is unclear why this happened now and not earlier, since the mod date on /usr/include/X11/xlib.h was 18jun97, which is well before all of the winter 98 compilation. It's likely the change to gcc 2.8.0 triggered the problem. Whatever. 21feb98 GLF TODO interactor.* Add a GetPainter, at least, and possibly more direct functions, so that it is not necessary to subclasss in order to change fonts or perform other painter-based operations.