Re: [Plplot-devel] Third proof of concept for the "exception handling" topic -- Further discussion

[Alan W. I. <ir...@be...>]

On 2017-07-23 06:00-0700 Alan W. Irwin wrote:

P.P.S.  As I am just discovering, one of the huge problems in this
field is terminology. For example, the wikipedia article
<https://en.wikipedia.org/wiki/Call_stack> refers immediately to 6
synomyms (ouch!) for call stack with one of those being just plain
"stack" which is the terminology used by the Linux man pages for
setjmp and longjmp.

"Call chain" is not one of those wikipedia-approved synonyms, but I
believe I must have picked up that terminology from another article I
read (where it meant the same thing).  Therefore, since the principal
terminology in wikipedia is "call stack", that is much preferable to
the "call chain" terminology I used below.  But nevertheless, I
thought I did pretty well below considering I wrote that at
6 o'clock in the morning after a long night of analysis without sleep.  :-)

Alan

> P.S. I just reviewed the wikipedia article on call graphs, and it
> appears I was misusing that term and should have used call chain
> instead where a call graph for a given library consists of all the
> potential call chains in the library with each one starting at one of
> the public API's.
>
> So my understanding now is the PLTHROW macro in plexit unwinds the
> particular call chain that called plexit until it reaches the first
> routine higher in that call chain where the
> the call was made in a PLTRY block and transfer control to the code in the
> corresponding PLCATCH block.
>
> @Phil:
>
> Do you agree with this explanation of PLTHROW, PLTRY, and PLCATCH or
> does it need further correction?
>
> If that explanation is substantially correct, that one scenario I was
> discussing could be described as two possible call chains in the call
> graph with one starting at the first public API traversing through the
> second public API and eventually traversing to plexit, and the second
> starting at the second public API and eventually traversing to plexit
> as well.  So the question was does the code need enhancement to deal
> with those two different possible call chains where in one case the
> PLCATCH block of the second API needs to PLTHROW to unwind the call
> chain to the first API PLTRY and transfer control to the corresponding
> PLCATCH block, and in the other case the second API catch block needs
> simply to return to the calling routine in the external application.
>
> And similarly this change in terminology needs to be applied to my
> just-previous discussion of other topics related to PLTHROW, PLTRY,
> and PLCATCH.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.sf.net); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________