[Home]

Summary:ASTERISK-02990: [PATCH] add MacroExit application
Reporter:Kevin P. Fleming (kpfleming)Labels:
Date Opened:2004-12-14 22:10:03.000-0600Date Closed:2008-01-15 15:20:20.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_macro
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) macro_forced_exit_rev3.diff.txt
Description:While bug 2720 goes much farther and adds Gosub/Return, there is still a need to be able to do simple subroutine-like calls in the diaplan. This application, MacroExit, facilitates that. It accepts no parameters, and should only be used inside an executing macro.

It does nothing except cause the extension processing loop in app_macro to stop processing, and exit the macro as if the loop had run out of priorities to execute.

****** ADDITIONAL INFORMATION ******

Disclaimer is on file.
Comments:By: Mark Spencer (markster) 2004-12-14 22:24:23.000-0600

Can you give me an example of where this is useful?  Thanks!
By: Kevin P. Fleming (kpfleming) 2004-12-14 22:30:43.000-0600

Sure, it's a cut down version of what I'm using:

[macro-officeopen]
exten => s,1,GotoIfTime(09:00-17:59|mon-fri|*|*?open)
exten => s,n,GotoIfTime(10:00-16:59|sat|*|*?open)
exten => s,n,SetVar(officeopen=closed)
exten => s,n,MacroExit
exten => s,n(open),SetVar(officeopen=open)

The MacroExit allows me to ensure that the following steps don't get run, without having to rely on the non-obvious technique of making the "open" priority much higher to leave a gap. I also don't need to put in an explicit Goto and construct the target using the MACRO_CONTEXT/MACRO_EXTEN variables, because Asterisk already knows where I want to go back to...

The real macro we use also does DBGets to check various things, and has other points at which it has determined what it needs to do, so it exits early. Saves a whole load of GotoIf()s to just skip the parts that aren't needed.

I'm sure there are other ways this simple macro could be structured to avoid the need for this app, but I don't want to redesign the 100-line one that does this for real :-)
By: Mark Spencer (markster) 2004-12-14 23:02:02.000-0600

Would this not be more brief and just as effective?

[macro-officeopen]
exten => s,1,GotoIfTime(09:00-17:59|mon-fri|*|*?open)
exten => s,n,GotoIfTime(10:00-16:59|sat|*|*?open)
exten => s,n,SetVar(officeopen=closed)
exten => s,n+1(open),SetVar(officeopen=open)
By: Kevin P. Fleming (kpfleming) 2004-12-14 23:12:28.000-0600

Sure, as long as you never reorganize the steps or accidentally add another step in between open and closed that eliminates the gap (if you are using hardcoded numbers, which your example doesn't but mine used to). The whole idea is here is to make it plainly obvious what is supposed to happen at that point in the macro, rather than having to "read between the lines" (in this case, literally).

It's not a big deal for me, I can live with it being a local change... just thought I'd pass it along, as people seem to be asking for "subroutine" functionality and this is a pretty painless way to get there.
By: Mark Spencer (markster) 2004-12-14 23:18:35.000-0600

Well, is this more or less like the GoSub app in here?  It seems to me that it would be helpful to merge the gosub functionality into Macro, so perhaps this application could be called "Return" then?

Your implementation is certainly very clean, and I don't have any objection to its implementation other than if it is called outside a macro, we should probably print some sort of error message.
By: Kevin P. Fleming (kpfleming) 2004-12-14 23:40:01.000-0600

I think that converting Macro() to use the code that is in bug 2720 and calling this application "Return" is a fine idea :-) That bug is currently awaiting action on bug 2278 I believe, otherwise it would likely already be in CVS.

Moving to that code also eliminates the need for any special return value, or checking to see if MacroExit has been called outside a macro. It is more intrusive, though, in that it adds a pointer to a stack list to the channel structure.
By: Mark Spencer (markster) 2004-12-18 18:38:42.000-0600

Yah, I think that implementation is going to likely need some work.  I can see no reason that the channel structure should need to be modified.  Is the question just one of how to maintain local variables?
By: Kevin P. Fleming (kpfleming) 2004-12-18 19:48:33.000-0600

Well, you'd have to bring in Corydon to say for sure, but I think that even the Gosub/Return part will require some place to keep a pointer to the stack. Local variables are a logical extension of that, but it would still be required (or some equivalent method) even without them.
By: Kevin P. Fleming (kpfleming) 2004-12-18 21:04:30.000-0600

rediffed against current CVS (no changes)
By: Mark Spencer (markster) 2005-01-06 23:37:46.000-0600

Added to CVS, thanks!
By: Digium Subversion (svnbot) 2008-01-15 15:20:20.000-0600

Repository: asterisk
Revision: 4699

U   trunk/apps/app_macro.c

------------------------------------------------------------------------
r4699 | markster | 2008-01-15 15:20:20 -0600 (Tue, 15 Jan 2008) | 2 lines

Add MacroExit application (bug ASTERISK-2990)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=4699