Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: Hack

From: sunandadh:aol at: 28-Dec-2001 19:35

Hi Joel,
> Knowing that I happened to have accessed the function via the > (temporary!) reference in a word named FF is of little use, if what > I am really trying to do is find (and, presumably, fix) the defective > code.
(Replying to several emails in one go, and may losing part of the thread in the process). Absolutely, I agree. I want first-class diagnostic information, and some of my questions over the past couple of weeks have been about this (e.g. the thread on "Better Error Messages?" We probably have different sets of priorities. I'll tell you mine, so you can see where I'm coming from (and then you can tell me where to go!). I'm still trying out Rebol, wanting to see if it is possible to build largish applications with this basic structure: Rebol [] Do Preparation ShutDown: false While [not ShutDown] [ if Error? Try [Do RunApplication] [If Error? Try [Do ReportIncident Do AttemptRecovery ] ;try [ShutDown: True] ] ;if ] ;while Where: --Preparation does what ever is necessary in advance for error recovery and quality control (For example, I've built one pilot application which checksums the *.r sources to ensure the distribution set is consistent and untampered with). RunApplication is the payload (the pilot is about 6,000 lines of Rebol as measured out of Mold). ReportIncident should dump (or email or whatever) scads of useful stuff about where and why we've failed: failing function name, complete call stack, status of ports, maybe molds of crucial data structures). This is the weakest part of the pilot. it doesn't do much more than print the error object. And that gives barely a hint of where in the 6000 lines we're a-pumping mud. AttemptRecovery is application-specific code to repair (or direct the user to repair) the damage. I've been conscientiously putting bugs into code for over 30 years now, and even back then the first thing a diagnostic tool would tell me is "last known function call was X. Call stack is ...". Maybe I'm hopelessly old-fashioned butI can't believe the programming world has made so much progress that these things are now impossible <wry g>. I've toyed with ideas like object identifiers (as suggested in another of you emails), but that only works for my objects, not for any third-party ones I might be using (unless it becomes a standard method). And I've experimented with hand-coding a call stack: Anyfunc: [...] [ Stack "AnyFunc" .... Unstack Return true ] Where Stack and Unstack simple append/remove the string in a global block. But it's a real hassle to remember to do it for every return statement. I think maybe the real problem (from my perspective) is that RT haven't delivered what is needed in the field as opposed to the lab. But they are not far off: if they action a couple of feedback requests, I'll be very happy. Sunanda.