Re: Re: debugging

*To*: mathgroup at smc.vnet.net*Subject*: [mg56729] Re: [mg56716] Re: [mg56676] debugging*From*: "E. Martin-Serrano" <EmilioMartin-Serrano at wanadoo.es>*Date*: Thu, 5 May 2005 06:01:13 -0400 (EDT)*Sender*: owner-wri-mathgroup at wolfram.com

The lack of debugging tools is, no doubt, an issue in Mathematica. I wrote the following utility package to deal with semantic/dynamic debugging; mainly to control calling functions flow. (* :Context: DFramework`DFrameworkMessage`*) (* :Title: Design Framework Environment *) (* :Author: E.Martin-Serrano - In Houston - Texas (USA) *) (* :Package Version:1.0,0 , July 3rd, 2004 *) (* :Mathematica Version:5.0.1 *) (* :Copyright: Copyright 2004 *) (* :History:Original version: July 3rd, 2004 *) (* :Summary: CallingFunction[stack] yields a list of functions. The meaning of this list of functions is that described ahead. Let us have a function 'f', whose body contains a call to another function 'f1'. Let us suppose that the call to 'f1', inside the body of 'f', fails due to an improper parameter passing. This failure may typically happen in situations of uncertainty: either the system is under construction (debugging) or in production when the parameters are produced dynamically from inputs inherited from other functions. To identify and locate the source of the problem, and the point of the failure, it is necessary to know three things: 1) the piece of code wrapping the point from where 'f1' was called when the failure came up, 2) The name of the parent function 'f' owning the piece of code wrapping the calling point to 'f1' where the failure came up, and 3) the domain of valid parameters for the function 'f1'. The necessity of this utility comes from the fact that any function may, in principle, be invoked from many different points or functions in a network-like manner, so there is not a way to know in advance which function is the culprit of a particular failure."*) (* :Keywords: Testing, debugging, messages *) (* :Contents:*) (* :Discussion: The present implementation is the first version and is mainly meant to describe the purpose of the utility itself, yet it seems to be working properly as far as it is currently used. The implementation should probably be improved in a more efficient and elegant manner*) (* :Sources: The function 'Domain' was taken from Ted Ersek's Tricks and slighted modify to accept arguments of the form ' arg___' *) (* :Credits: The function 'Domain[]' in its original form is due to Ted Ersek as mentioned above. David Park has been helping me a lot with his suggestions about systematic package developing *) (* :Warning: I have not performed a systematic thoroughly test *) BeginPackage["GeneralServices`CallingFunctionControl`"] Unprotect[Evaluate[$Context<>"*"]] FunctionDomain::usage= "FunctionDomain[function] computes the valid domain of the arguments accepted by 'function[]'." CallingFunction::usage= "CallingFunction[stack] yields a list of functions. The meaning of this list of functions is that described ahead. Let us have a function 'f', whose body contains a call to another function 'f1'. Let us suppose that the call to 'f1', inside the body of 'f', fails due to an improper parameter passing. This failure may typically happen in situations of uncertainty: either the system is under construction (debugging) or in production when the parameters are produced dynamically from inputs inherited from other functions. To identify and locate the source of the problem, and the point of the failure, it is necessary to know three things: 1) the piece of code wrapping the point from where 'f1' was called when the failure came up; 2) The name of the parent function, 'f', owning the piece of code that wraps the calling point to 'f1' where the failure came up; and 3) the domain of valid parameters for the function 'f1'. The necessity of this utility comes from the fact that any function may, in principle, be invoked from many different points or functions in a network-like manner, so that there is not an easy way to know in advance which function is the culprit of a particular failure." Begin["`Private`"] FunctionDomain[f_]:=Module[{result}, result=HoldForm@@{First/@DownValues[f]}; result=result/.Verbatim[HoldPattern][e_]\[RuleDelayed]e ] CallingFunction[stack_]:= Module[{downvalues,callingcontext,stp,index,functions}, downvalues= DownValues[#]&/@Cases[Map[ToExpression,Names[Context[]<>"*"]],_Symbol]// Flatten; callingcontext = StringDrop[stack,5]; callingcontext = StringDrop[callingcontext,-1]; stp =StringPosition[#,callingcontext]&/@(ToString[#]&/@downvalues); index = Table[If[stp[[i]]\[NotEqual]{},{i},{}],{i,Length[stp]}]//Flatten; functions =StringDrop[ ToString[First[downvalues[[#]]]],12]&/@index; StringDrop[#,-1]&/@functions ] End[] Protect[Evaluate[$Context<>"*"]] EndPackage[] -----Original Message----- From: Chris Chiasson [mailto:chris.chiasson at gmail.com] To: mathgroup at smc.vnet.net Subject: [mg56729] [mg56716] Re: [mg56676] debugging Do you mean it wasn't an error that referenced a line number? Some errors in Mathematica do come with line numbers; I thought you had one of those kind and were just looking for a way to display line numbers. You could add your own type checking/debugging code that will produce its own warning messages. That would help you locate the problem. I usually start from the name of the function that produces an error and tear my function apart, call by call, until I find the step between which the output went from good to bad. You may find ctrl+shift+b useful for this. You may also wish to make use of the Interrupt[] , Abort[] and Throw/Catch calls. On 5/3/05, Daniel Roy <droy at mit.edu> wrote: > There are no line numbers in the reported bugs, of course. > > On Tue, 2005-05-03 at 13:10 -0400, Chris Chiasson wrote: > > You could load the code into the vi editor (or your favorite text > > editor) and turn on the line numbers. > > > > On 5/3/05, Daniel Roy <droy at mit.edu> wrote: > > > > > > My question concerns debugging. I've done googling to find a quick > > > answer but have failed. I'm developming large functions and without > > > line numbers telling me where the errors occurred, its becoming very > > > difficult to develop code quickly. Can anyone point me in the right > > > direction in terms of debugging multi line (at least 50+ lines) > > > functions? > > > > > > thanks, > > > dan > > > > > > > > > > > > -- Chris Chiasson http://chrischiasson.com/ 1 (810) 265-3161

**Follow-Ups**:**Re: Re: Re: debugging***From:*DrBob <drbob@bigfoot.com>