home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / programm / 2285 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  2.2 KB
  1. Xref: sparky comp.programming:2285 comp.unix.programmer:4257 comp.lang.c:12230 comp.arch:8861
  2. Path: sparky!uunet!dtix!darwin.sura.net!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!ai-lab!fiber-one!sundar
  3. From: sundar@fiber-one.ai.mit.edu (Sundar Narasimhan)
  4. Newsgroups: comp.programming,comp.unix.programmer,comp.lang.c,comp.arch
  5. Subject: Re: What would you like in a debugger?
  6. Message-ID: <26481@life.ai.mit.edu>
  7. Date: 12 Aug 92 17:47:52 GMT
  8. References: <bosullvn.713038630@unix1.tcd.ie> <1992Aug5.193946.16004@linus.mitre.org> <matt.713047463@centerline.com>
  9. Sender: news@ai.mit.edu
  10. Reply-To: sundar@ai.mit.edu
  11. Followup-To: comp.programming
  12. Organization: MIT Artificial Intelligence Laboratory
  13. Lines: 27
  14.  
  15. In article <matt.713047463@centerline.com>, matt@centerline.com (Matt Landau) writes:
  16. |> In <1992Aug5.193946.16004@linus.mitre.org> hargrove@ramirez.mitre.org (Paul H. Hargrove) writes:
  17. |> >I want a debugger that works well with X11.  This means that if I'm
  18. |> >tracing an X11 program and it has stopped at a breakpoint, and I
  19. |> >happen to uncover the window, my X server doesn't just sit there 
  20. |> >trying forever to tell the application to redraw it's window.
  21. |> 
  22. |> How, pray tell, do you expect your application to redraw its window if 
  23. |> it's stopped at a breakpoint?  
  24. |> 
  25. |> The X server isn't "sit[ting] there trying forever to tell the application" 
  26. |> to do anything at all.  The X server generates Expose events for your X11 
  27. |> client application, then forgets about you until something else happens 
  28. |> that you need to know about.  
  29. |> 
  30. |> The fact that your application doesn't read and process these Expose events 
  31. |> when it's stopped at a breakpiont is really not something a debugger can 
  32. |> do anything about.  This is kind of the definition of being "stopped at a 
  33. |> breakpoint", is it not?
  34. I agree with you on this, but the most painful thing about X/Motif 
  35. are programs that involve widgets that do pointer and keyboard grabs.
  36. I've had breakpoints in callback functions simply hang (freeze up the
  37. server) because of the grab -- which I can't get out of because to do this
  38. I would need to TYPE stuff at the debugger telling it to continue.
  39.  
  40. What is the right thing to do when this happens? (I have a solution 
  41. but it is hardly pretty).
  42.