Re: Re: Re: debugging

*To*: mathgroup at smc.vnet.net*Subject*: [mg56789] Re: [mg56729] Re: [mg56716] Re: [mg56676] debugging*From*: DrBob <drbob at bigfoot.com>*Date*: Fri, 6 May 2005 02:59:57 -0400 (EDT)*References*: <200505051001.GAA21843@smc.vnet.net>*Reply-to*: drbob at bigfoot.com*Sender*: owner-wri-mathgroup at wolfram.com

In all that, I see no clue how to get the "stack" argument to CallingFunction. Without that, we can't call the function. How about an example? Bobby On Thu, 5 May 2005 06:01:13 -0400 (EDT), E. Martin-Serrano <EmilioMartin-Serrano at wanadoo.es> wrote: > > 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 > To: mathgroup at smc.vnet.net > Subject: [mg56789] [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 >> > > >> > > >> > >> > >> >> > > -- DrBob at bigfoot.com

**References**:**Re: Re: debugging***From:*"E. Martin-Serrano" <EmilioMartin-Serrano@wanadoo.es>

**Re: Re: Variant of inner Product ...**

**Mathematica Notebook Organiztion**

**Re: Re: debugging**

**Re: Re: Re: debugging**