home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / arch / 8885 < prev    next >
Encoding:
Text File  |  1992-08-13  |  2.6 KB  |  59 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!uunet.ca!geac!itcyyz!yrloc!rbe
  3. From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
  4. Subject: Re:  What would you like in a debugger?
  5. Message-ID: <1992Aug13.144912.8504@yrloc.ipsa.reuter.COM>
  6. Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
  7. Organization: Snake Island Research Inc, Toronto
  8. References: <19920809.175600.935@almaden.ibm.com> <343@moene.indiv.nluug.nl> <chris.0qws@genly.uucp> <1992Aug12.011403.16934@technix.mn.org>
  9. Date: Thu, 13 Aug 92 14:49:12 GMT
  10. Lines: 47
  11.  
  12. In article <1992Aug12.011403.16934@technix.mn.org> bret@technix.mn.org (Bret Indrelee) writes:
  13. >
  14. >I don't know how many debuggers I have given up on because they decided
  15. >to display the contents of a pointer, rather than the value of the pointer.
  16. >
  17. >If you keep with the syntax of the native language, the programmer should
  18. >be able to see that they asked for the pointer rather than the value at
  19. >the pointer.  If you try to 'fix their error' it makes it really nasty
  20. >to really see the value of a pointer.
  21. >
  22. >Go chase a linked list bug if you don't think you need to see the value
  23. >of a pointer.  Or use mmap() with your favorite memory-mapped device.  Or
  24. >any number of other similair things...
  25. >
  26. >If you can manage it, another feature that would be nice is disassembing
  27. >code when someone asks you to display the contents of a pointer to function.
  28. >If your feeling really hot, try to relate it to the source line in the
  29. >program...just make sure that this 'feature' can be disabled for when there
  30. >is a misinterpretation.
  31.  
  32. I think the important point here is that no debugger designer can
  33. determine which debugging facilities are adequate for a specific
  34. debugging job. Because of this (and for convenience), we at I.P. Sharp
  35. Associates (May it rest in peace, stomped as it was by Big Feet)
  36. developed a system which combined interactive debugger and dump
  37. analysis facilities, written entirely in SHARP APL.
  38.  
  39. Since everything was just APL functions, it was trivial to 
  40. build a special purpose function on the fly for your particular
  41. problem. So, special purpose formatters (funny translations,
  42. linked list chasers, table transposers, etc) are trivial to
  43. build. 
  44. This work was incredibly successful, and I strongly recommend
  45. that those of you who are in possession of USABLE interactive
  46. systems consider the development and/or integration of interactive
  47. tools to allow on-the-fly customization of dump/debug tools to
  48. make the programmer's job easier.
  49.  
  50. Bob
  51.  
  52.  
  53.  
  54. Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
  55. Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
  56. 18 Fifth Street, Ward's Island
  57. Toronto, Ontario M5J 2B9 
  58. Canada
  59.