comp.lang.idl-pvwave archive: archive

Home » Public Forums » archive » Re: IDLVM and retall

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Re: IDLVM and retall [message #49998 is a reply to message #49996]

Fri, 08 September 2006 09:02

btt
Messages: 345
Registered: December 2000

Senior Member

R.G. Stockwell wrote:
> "Ben Tupper" <btupper@bigelow.org> wrote in message
> news:4mdendF5h4mvU1@individual.net...
> ...
>> At risk of exposing my arrested development, I harken back to exchange I
>> witnessed between David and Martin Schultz eons ago. I can't remember if
>> it was on the newsgroup or "off-line". But I do remember clearly that
>> Martin and David leaned toward a FUNCTION event handling method rather
>> than a PROcedure - the function event handling method returned 0/1 for
>> fail/success. If I remember rightly, the decision was driven by the
>> messaging aspect of events (or pseudo-events) and that functions, if
>> nothing else, pass messages by default.
>>
>> Would that suffice to resolve the issue?
> ...
>> Cheers,
>> Ben
>
> I was about to suggest the same thing. I have not needed to
> do such a thing in IDL, but in creating very large applications
> in Labview I always had this type of behaviour.
> Every module had an "error input" structure, and if there was
> an error, it just passed through (skipped) the module passing on the error,
> and filling return values with defaults (like NAN or something appropriate).
> One could append the whole routine call tree i guess too.
> The errors were handled at a much higher level.
>
> I have in mind something like the following:
>
> function MyClass::f1, ev, errstruct
> if n_params() ne 2 then message:"developer error: must pass errstruct"
> if (errstruct.set eq FALSE) then begin
> ; no error passed in so perform this function
> result = do_calc(errstruct)
> endif else begin
> ; pass through errors and create default values.
> result = NULL
> endelse
> return, result
> end
>
> pro MyClass::p1, ev, errstruct
> if n_params() ne 2 then message:"developer error: must pass errstruct"
> if (errstruct.set eq FALSE) then begin
> ; no error passed in so do this routine
> do_stuff, ev,errstruct
> endif
> end
>
> function MyClass::f2,ev, errstruct
> OK = self->f1(ev, errstruct) ; error occurs
> result = do_another_calc(ev,errstruct) ; not executed, error passed
> result2 = do_yet_another_calc(result,errstruct); not executed, error
> passed
> result3 = do_yet_another_calc(result2,errstruct); not executed, error
> passed
> result4 = do_yet_another_calc(result3,errstruct); not executed, error
> passed
> return, result4
> end
>
> Coming out of f2 is the errstruct with a message such as:
> "error divide by 1 occurred in myclass f1 function do_calc()"
>
>
> It is a lot of work to retrofit a code base, but it would be easy
> enough to implement when starting out.
> Labview had the very nice feature of easily being able to demand that
> errstruct always be passed (with a dataflow scheme you can do that).
>

That is a really good analogy. If you really are handling events with
object methods then you could make the "errstruct" a property of the
object. You could then skip it as a second parameter. But that would
reduce the problem (or the solution really) to the one David addressed
in the Catalyst library.

That error-property-passing feature in LabView is mostly built-in, and
where it isn't I'll bet there are a lot of wrappers that add that
feature. It is wicked handy to prevent race conditions (where you don't
know or have control over which software component gets the data first).
Parallel while loops come to mind (one for acquisition and one for
processing). Most of us IDL users don't bump into race conditions
because it's a procedural language and we only handle one event at a
time. If JD is not using XMANAGER to generate events then maybe all bets
are off. Although, if I think about this hard enough... no, it's no good
trying to think, it just gets me confused.

I wonder if the new IDL-IDL bridge (or any of these bridgy things) will
begin a blurring between the data-flow and procedural software ideas.

Report message to a moderator

[Message index]

		Re: IDLVM and retall By: JD Smith on Fri, 08 September 2006 09:35
		Re: IDLVM and retall By: JD Smith on Fri, 08 September 2006 09:30
		Re: IDLVM and retall By: JD Smith on Fri, 08 September 2006 09:26
		Re: IDLVM and retall By: JD Smith on Fri, 08 September 2006 09:12
		Re: IDLVM and retall By: news.qwest.net on Fri, 08 September 2006 09:10
		Re: IDLVM and retall By: btt on Fri, 08 September 2006 09:02
		Re: IDLVM and retall By: news.qwest.net on Fri, 08 September 2006 08:42
		Re: IDLVM and retall By: David Fanning on Fri, 08 September 2006 08:28
		Re: IDLVM and retall By: btt on Fri, 08 September 2006 07:57
		Re: IDLVM and retall By: David Fanning on Thu, 07 September 2006 21:00
		Re: IDLVM and retall By: JD Smith on Thu, 07 September 2006 15:57
		Re: IDLVM and retall By: David Fanning on Thu, 07 September 2006 12:14
		Re: IDLVM and retall By: JD Smith on Thu, 07 September 2006 11:54
		Re: IDLVM and retall By: David Fanning on Thu, 07 September 2006 06:52
		Re: IDLVM and retall By: JD Smith on Thu, 07 September 2006 01:57
		Re: IDLVM and retall By: JD Smith on Wed, 06 September 2006 23:21
		Re: IDLVM and retall By: Foldy Lajos on Wed, 06 September 2006 12:30
		Re: IDLVM and retall By: JD Smith on Wed, 06 September 2006 11:53
		Re: IDLVM and retall By: Foldy Lajos on Tue, 05 September 2006 08:31
		Re: IDLVM and retall By: David Fanning on Fri, 08 September 2006 09:48

Previous Topic:	Re: ascii_template advanced
Next Topic:	IDLVM and retall

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Wed Oct 08 17:28:02 PDT 2025

Total time taken to generate the page: 0.00487 seconds