home *** CD-ROM | disk | FTP | other *** search
/ Education Sampler 1992 [NeXTSTEP] / Education_1992_Sampler.iso / Programming / Source / winterp-1.13 / doc / BUGS next >
Encoding:
Text File  |  1991-10-06  |  8.8 KB  |  164 lines
  1. # 
  2. # WINTERP Copyright 1989, 1990, 1991 Hewlett-Packard Company (by Niels Mayer).
  3. # XLISP version 2.1, Copyright (c) 1989, by David Betz.
  4. #
  5. # Permission to use, copy, modify, distribute, and sell this software and its
  6. # documentation for any purpose is hereby granted without fee, provided that
  7. # the above copyright notice appear in all copies and that both that
  8. # copyright notice and this permission notice appear in supporting
  9. # documentation, and that the name of Hewlett-Packard, David Betz and
  10. # Niels Mayer not be used in advertising or publicity pertaining to distribution
  11. # of the software without specific, written prior permission.  Hewlett-Packard,
  12. # David Betz and Niels Mayer makes no representations about the suitability of
  13. # this software and documentation for any purpose.  It is provided "as is"
  14. # without express or implied warranty.
  15. #
  16.  
  17. There following describes bugs in WINTERP, all of which surfaced with Motif
  18. 1.1, and will hopefully go away in Motif 1.2 and/or X11r5. Despite these
  19. bugs, we've managed to run a number of WINTERP applications successfully --
  20. it is important to know the cause of these problems, and have knowledge of
  21. what sorts of operations will cause trouble.
  22.  
  23.             --------------------
  24.  
  25. The first bug occurs whenever a shell containing a popup or option menu is
  26. closed.  This causes an erroneous XtWarning:
  27.  
  28.     "Warning: Attempt to remove non-existant passive grab"
  29.  
  30. The warning itself is harmless. However, if you start up WINTERP with
  31. resource "Winterp.enableXtWarningBreak" set to TRUE (or specify the command
  32. line flag "-enable_xtwarn_brk"), you will notice problems. When
  33. enableXtWarningBreak is set, any XtWarnings will break out of the routine
  34. that caused the XtWarning and go to the XLISP error handling routine. For
  35. many XtWarnings, that works out just fine, allowing you to trace the exact
  36. call which cause the toolkit to balk. Unfortunately, for the "Attempt to
  37. remove non-existant passive grab" warning, it seems to leave Motif/Xt in an
  38. indeterminate state that can result in odd behavior, program freezes, or
  39. core dumps. After a popup menu gets popupped up, any subsequent attempts at
  40. "closing" the shell containing the popup-menu or option-menu don't work
  41. correctly. By "closing" I mean using the window-manager's "close" menu
  42. entry (f.kill). Upon doing a "close" on a shell containing a popup menu,
  43. I've seen a number of things happen:
  44.    (1) The "close" is ignored, but subsequent attempts at closing a
  45.        different WINTERP shell result in a core dump.
  46.    (2) Doing the "close" generates the message:
  47.     error: X Toolkit Warning:
  48.         Attempt to remove non-existant passive grab
  49.        Doing the "close" again, on either the same shell, or a different
  50.        WINTERP shell will result in the following sort of error message:
  51.     XIO:  fatal IO error 32 (Broken pipe) on X server "unix:0.1"
  52.     after 19581 requests (19573 known processed) with 0 events remaining.
  53.     The connection was probably broken by a server shutdown or KillClient.
  54.  
  55. The workaround for the above problem is simple -- don't set resource
  56. "Winterp.enableXtWarningBreak" to TRUE. The default for WINTERP 1.13 is to
  57. set the resource to FALSE so as to avoid the problem.
  58.  
  59. Typically, you will also want to deliver WINTERP applications with
  60. "Winterp.enableXtWarningBreak" set to the default FALSE value. XtWarnings
  61. can occur when your X server runs out of colors, or can't find a particular
  62. font, etc -- such situations often warrant continuing program operation
  63. normally (after issuing a warning), rather than causing a Lisp break.
  64.  
  65. The only reason why you'd want to set "Winterp.enableXtWarningBreak" to
  66. TRUE is during debugging a program -- enableXtWarningBreak combined with
  67. 'baktrace' will allow you to figure out which particular call in your
  68. program caused the warning to be issued.
  69.  
  70.             --------------------
  71.  
  72. The second major problem is related to X11r4&Motif-1.1's flaw of not being
  73. able to destroy widgets properly when running in nested Xt eventloops
  74. (XtAppMainLoop(), or XtAppNextEvent()+XtDispatchEvent()). This had not been
  75. a problem in Motif 1.0/X11r3 which was WINTERP's original design platform,
  76. and the bug has supposedly been fixed in Motif 1.2 and X11r5.
  77.  
  78. WINTERP uses nested event loops in its handling of XLISP's debug breakloop.
  79. Problems seem to arise when XLISP is set up such that Lisp, Motif, Xt, or X
  80. errors throw into the Lisp break loop "at the wrong time".  This mode is
  81. not the default for XLISP -- it must be explicitly enabled by setting
  82. variable *BREAKENABLE* to T, by evaluating the function DEBUG (defined in
  83. examples/initialize.lsp), or by turning on the "debug" toggle-button in
  84. examples/w_ctrlpnl.lsp.
  85.  
  86. The symptoms of the problem are that on certain occasions, when
  87. *BREAKENABLE* is set, and a previous error has thrown you into the
  88. breakloop, you will not be able to destroy widgets or close windows using
  89. the window manager "close" (f.kill) function. Sometimes you will also see
  90. subsequent core dumps and other strange behavior indicating that Motif is
  91. stepping on its own memory.
  92.  
  93. The problem will simply not arise if *BREAKENABLE* is not set. There are
  94. even occasions where *BREAKENABLE* can be set and you won't see this
  95. problem.  Unfortunately, that may make debugging WINTERP programs difficult
  96. because you won't be able to find out which particular section of code
  97. caused an error and you will have to rely on the information presented by
  98. the error message.
  99.  
  100. The problem is seems to be caused by entering/exiting out of a break-level
  101. through a callback, which was how WINTERP 1.12's w_ctrlpnl.lsp implemented
  102. the Err-Cont (continue), Err-^Level (clean-up), and Err-~Level (top-level)
  103. commnands. Likewise, the problem will manifest itself if an error occurs
  104. while loading a file out of a callback (an error will throw into a
  105. different nesting of event loop). The workaround is to prevent such cases
  106. from arising out of callbacks.
  107.  
  108. WINTERP 1.13's w_ctrlpnl.lsp implements (kludges, hacks,...) the workaround
  109. to this problems by having "Load File", "Err-Cont", "Err-^Level", and
  110. "Err-~Level" not move between break-levels through callbacks. Instead, they
  111. call WINTERP's eval-server through the kludge of calling the Winterp-Lisp
  112. client 'wl' through SYSTEM. While this is certainly less direct/efficient
  113. means of interacting with XLISP than presented in WINTERP 1.12's
  114. w_ctrlpnl.lsp, users will not notice this as a problem since the operation
  115. occurs once per click on the "Load File", "Err-Cont", "Err-^Level", or
  116. "Err-~Level" buttons (i.e. it's a non-inner loop sort of operation).
  117.  
  118. The only real problem caused by this workaround to w_ctrlpnl.lsp is that
  119. you will not be able to use the control panel with a WINTERP that doesn't
  120. have an eval-server running (i.e. you must not specify -no_unix_server
  121. command line flag or resource "Winterp.enableUnixServer: false"). Of
  122. course, w_ctrlpnl.lsp now requires that the executable 'wl' be on your
  123. search path. Note that for Motif 1.0, none of this is a problem --
  124. w_ctrlpnl.lsp knows which version of Motif you are running and will adjust
  125. it's behavior accordingly, such that the "normal" callback-based "Load
  126. File", "Err-Cont", "Err-^Level", and "Err-~Level" functions will occur.
  127.  
  128. When interacting with WINTERP through the gnu-emacs interface
  129. (src-client/winterp.el), the eval-server is used by default, which means
  130. you will not be incurring the problem of entering/exiting the breakloop out
  131. of a callback.
  132.  
  133. I'm looking into better solutions for this problem in WINTERP release 1.14.
  134. Until then, please note the above warnings such that you can avoid
  135. problems, or at least understand which actions you took are causing
  136. problems. At worst, while debugging, you'll have to restart WINTERP
  137. occasionally, which is still far better than restarting a C application
  138. every time a trivial error occurs. Typically, delivered WINTERP
  139. applications will never enter a break-level, and when they do, it may make
  140. the most sense to pop up a dialog box and exit.
  141.  
  142.             --------------------
  143.  
  144. The last problem of note in WINTERP 1.13 and Motif 1.1 is that option menus
  145. created via XmCreateSimpleOptionMenu() (see examples/RowColumn.lsp) invoke
  146. yet another widget destroy problem. Basically, anytime I destroy a shell
  147. containing a simple option menu, I get a core dump, typically containgin
  148. the following C backtrace:
  149. | __XtDoPhase2Destroy+0x44:       _XtCreateApplicationShell+0x1CA (0x1F1538)
  150. | _XtDispatchEvent+0x46:  __XtDoPhase2Destroy     (0x151E88, 0x1)
  151. | _main+0x9FE:    _XtDispatchEvent(0xFFEFFCB8)
  152.  
  153. This problem, seems to be fixed in WINTERP 1.14, which will be released
  154. real soon now. Put yourself on the WINTERP mailing list
  155. (winterp-request@hplnpm.hpl.hp.com) or watch
  156. comp.windows.x/comp.windows.x.motif for annoucements of that release.
  157.  
  158. -------------------------------------------------------------------------------
  159.         Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com
  160.           Human-Computer Interaction Department
  161.                Hewlett-Packard Laboratories
  162.                   Palo Alto, CA.
  163.                    *
  164.