[Home]

Summary:ASTERISK-17497: [patch] AELsub() for calling routines that will remain stable between internal changes
Reporter:Alexandre Keller (alexandrekeller)Labels:
Date Opened:2011-03-02 18:31:03.000-0600Date Closed:2011-03-12 14:42:35.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:PBX/pbx_ael
Versions:1.6.2.17 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20110304__issue18919__1.4.diff.txt
( 1) 20110304__issue18919__1.6.2.diff.txt
Description:After update from asterisk-1.6.2.14 to asterisk-1.6.2.17 Gosub(macro,s,1(args)) stopped working.

Then I realized all my AEL macros wasn't created with extension s, instead there is a ~~s~~ extension, which has broken my entire dialplan.

What happened? How to solve that?

Thanks
Comments:By: Leif Madsen (lmadsen) 2011-03-03 14:20:46.000-0600

This may be a regression. Can you look into this?

By: Bradley Watkins (marquis) 2011-03-03 14:30:12.000-0600

I don't personally view this as a regression.  Within AEL, if you want to use GoSub you should absolutely be using the AEL macro facility rather than directly calling GoSub.

By: Leif Madsen (lmadsen) 2011-03-03 14:31:14.000-0600

Talked to Tilghman on IRC about this, and he says you should actually be doing:

&macro(args)

and not calling GoSub() directly like that.

By: Alexandre Keller (alexandrekeller) 2011-03-03 14:36:10.000-0600

Are you guys kidding me?

Some months ago, everybody was talking abou NOT TO USE Macro() app anymore, instead we should use Gosub(), now you're telling me to go back my entire dialplan do Macro().

Come on?! Is this a joke from Digium?

By: Leif Madsen (lmadsen) 2011-03-03 14:37:51.000-0600

That's not what I said at all.

I said to use &macro(...) which is a wrapper for GoSub().

<Corydon76-home> He's depending upon an implementation detail of subroutines
<Corydon76-home> when the implementation detail changed, that broke
<Corydon76-home> There's nothing that says the extension is named "s" or even that it starts at priority 1
<Corydon76-home> Assuming that you know where the macro starts executing is a(n) [...] assumption

By: Alexandre Keller (alexandrekeller) 2011-03-03 14:52:39.000-0600

Can anybody tell me why that's change from one version to another? One single version, fro 1.6.2.16.2 to 1.6.2.17?

That's really nice, to correct one thing, you change another on which break an entire application.

This is really great.

By: Bradley Watkins (marquis) 2011-03-03 15:06:36.000-0600

The primary issue here is that you have apparently long been relying upon an implementation detail of AEL that, admittedly, changed.

But you should not have been relying on that behavior in the first place, as it was never guaranteed.  Had you been using the AEL macro facility from the start, then you would have noticed no change.

There was an issue (linked above in the Relationships section) that caused spurious warnings to be issued by the AEL compiler. It is the fix for this that is the difference between 1.6.2.16.2 (and before) and 1.6.2.17.

By: Bradley Watkins (marquis) 2011-03-03 15:20:28.000-0600

An option you do have, by the way, is to revert the patch locally.  It's pretty trivial.

In fact, here is a direct link to a patch that you can apply:
http://svnview.digium.com/svn/asterisk/branches/1.6.2/res/ael/pval.c?view=patch&r1=290254&r2=299448&pathrev=299448

By: Alexandre Keller (alexandrekeller) 2011-03-03 15:34:01.000-0600

Ok.

My problem is I've developed all my macros in AEL, but my contexts are on Realtime, what's the best way to call my macros from Realtime?

I was using Gosub. I've just tested & but it doesn't work in Reatime, nor App MACRO() which search for a macro name macro-mymacro, and in AEL I haven't done it. My macros doesn't start its name witch macro.

And Now?! What should I do?

Thanks in advance.

By: Leif Madsen (lmadsen) 2011-03-03 15:59:47.000-0600

I'd suggest you use the asterisk-users mailing list for support. Thanks!

By: Alexandre Keller (alexandrekeller) 2011-03-03 16:05:53.000-0600

Mr lmaden I've opened a issue here because you guys from Digium, to fix one issue, changed a feature in Asterisk, which buy the way has been working just fine for the past five years.

I've always use AEL and Realtime. But Now, you guys told me to use again & to call a macro in AEL, Ok. And in Realtime, & doesn't work.

I guess I was only dreaming to expect any help from you, because every issue opened here has the same answers, put this patch ou use a different list for help.

But thanks anyway. I guess I'll fave to figure out, AGAIN, by myself.

By: Tilghman Lesher (tilghman) 2011-03-03 16:13:24.000-0600

We have never recommended that you call subroutines in AEL from Realtime.  In fact, we suggest that you either use all realtime or all AEL, not a mixture of the two.

By: Alexandre Keller (alexandrekeller) 2011-03-03 16:29:43.000-0600

No one has ever recommended it to me.

I use because AEL is great to develop functions and macros, and Realtime to manage the entire aplication.

If is there, why can't I use them?

Is there any isssue related on using Asterisk Features all together?

By: Tilghman Lesher (tilghman) 2011-03-03 16:36:07.000-0600

Given that subroutines have changed before, we find it odd that you're adamant that such implementation details don't change.  However, we're discussing creating an application called something like CallAEL(), that will allow you to call a particular routine built in AEL, whose redirection will remain stable, even if the internals change.  We believe this would meet your requirements.  What do you  think?

By: Alexandre Keller (alexandrekeller) 2011-03-03 16:47:59.000-0600

Actually, It's changed from 1.4 to 1.6, than when I've started using 1.6 I made the changes, that's not a problem at all, because the change was from one version of Asterisk to a new one.

It would be great to have a application to call an AEL function from inside Realtime.

I was testing change my Realtime appdata to mymacro,~~s~~,1(args), but i haven't finished all of them yes.

Thanks.

By: Alexandre Keller (alexandrekeller) 2011-03-10 18:21:48.000-0600

I've just tested AELSub() application on extensions.con, Realtime and even in AEL.

It's worked just fine.

Is AELSub() going to be part of Asterisk 1.8 too?

Thanks Mr. tilghman

By: Digium Subversion (svnbot) 2011-03-12 14:22:11.000-0600

Repository: asterisk
Revision: 310435

U   branches/1.4/pbx/pbx_ael.c

------------------------------------------------------------------------
r310435 | tilghman | 2011-03-12 14:22:10 -0600 (Sat, 12 Mar 2011) | 31 lines

Add AELSub, which provides a stable entry point into AEL subroutines.

This commit needs some explanation, given that we're adding a new application
into an existing release branch.  This is generally a violation of our release
policy, except in very limited circumstances, and I believe this is one of
those circumstances.

The problem that this solves is one of the sanity of using multiple dialplan
languages to define a dialplan.  In the case of the reporter, he or she is
using AEL is define subroutines, while using Realtime extensions to invoke
those subroutines.  While you can do this, it's based upon the reality of AEL
using actual dialplan extensions; however, there is no guarantee that the
details of _how_ AEL is compiled into extensions will remain stable.  In fact,
at the time of this commit, it has already changed twice, once in a
fundamental way.

Now normally, a new application would only be added to trunk.  However, this
application is explicitly to create a stable user-level API between versions,
and adding it to trunk only will not solve the user's problem of switching
between 1.6.2 and 1.8, nor will it help anybody switching from 1.8 to 1.10.
Therefore, it needs to go into existing release branches.  For the sake of
consistency, and also because one of the changes was between 1.4 and 1.6.x,
I am also electing to commit this to 1.4.

(closes issue ASTERISK-17497)
Reported by: alexandrekeller
Patches:
      20110304__issue18919__1.6.2.diff.txt uploaded by tilghman (license 14)
      20110304__issue18919__1.4.diff.txt uploaded by tilghman (license 14)
Tested by: alexandrekeller

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

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

By: Digium Subversion (svnbot) 2011-03-12 14:24:55.000-0600

Repository: asterisk
Revision: 310448

_U  branches/1.6.2/
U   branches/1.6.2/pbx/pbx_ael.c

------------------------------------------------------------------------
r310448 | tilghman | 2011-03-12 14:24:55 -0600 (Sat, 12 Mar 2011) | 38 lines

Recorded merge of revisions 310435 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
 r310435 | tilghman | 2011-03-12 14:22:07 -0600 (Sat, 12 Mar 2011) | 31 lines
 
 Add AELSub, which provides a stable entry point into AEL subroutines.
 
 This commit needs some explanation, given that we're adding a new application
 into an existing release branch.  This is generally a violation of our release
 policy, except in very limited circumstances, and I believe this is one of
 those circumstances.
 
 The problem that this solves is one of the sanity of using multiple dialplan
 languages to define a dialplan.  In the case of the reporter, he or she is
 using AEL is define subroutines, while using Realtime extensions to invoke
 those subroutines.  While you can do this, it's based upon the reality of AEL
 using actual dialplan extensions; however, there is no guarantee that the
 details of _how_ AEL is compiled into extensions will remain stable.  In fact,
 at the time of this commit, it has already changed twice, once in a
 fundamental way.
 
 Now normally, a new application would only be added to trunk.  However, this
 application is explicitly to create a stable user-level API between versions,
 and adding it to trunk only will not solve the user's problem of switching
 between 1.6.2 and 1.8, nor will it help anybody switching from 1.8 to 1.10.
 Therefore, it needs to go into existing release branches.  For the sake of
 consistency, and also because one of the changes was between 1.4 and 1.6.x,
 I am also electing to commit this to 1.4.
 
 (closes issue ASTERISK-17497)
  Reported by: alexandrekeller
  Patches:
        20110304__issue18919__1.6.2.diff.txt uploaded by tilghman (license 14)
        20110304__issue18919__1.4.diff.txt uploaded by tilghman (license 14)
  Tested by: alexandrekeller
........

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

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

By: Digium Subversion (svnbot) 2011-03-12 14:27:56.000-0600

Repository: asterisk
Revision: 310462

_U  branches/1.8/
U   branches/1.8/pbx/pbx_ael.c

------------------------------------------------------------------------
r310462 | tilghman | 2011-03-12 14:27:56 -0600 (Sat, 12 Mar 2011) | 45 lines

Merged revisions 310448 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2

................
 r310448 | tilghman | 2011-03-12 14:24:54 -0600 (Sat, 12 Mar 2011) | 38 lines
 
 Recorded merge of revisions 310435 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.4
 
 ........
   r310435 | tilghman | 2011-03-12 14:22:07 -0600 (Sat, 12 Mar 2011) | 31 lines
   
   Add AELSub, which provides a stable entry point into AEL subroutines.
   
   This commit needs some explanation, given that we're adding a new application
   into an existing release branch.  This is generally a violation of our release
   policy, except in very limited circumstances, and I believe this is one of
   those circumstances.
   
   The problem that this solves is one of the sanity of using multiple dialplan
   languages to define a dialplan.  In the case of the reporter, he or she is
   using AEL is define subroutines, while using Realtime extensions to invoke
   those subroutines.  While you can do this, it's based upon the reality of AEL
   using actual dialplan extensions; however, there is no guarantee that the
   details of _how_ AEL is compiled into extensions will remain stable.  In fact,
   at the time of this commit, it has already changed twice, once in a
   fundamental way.
   
   Now normally, a new application would only be added to trunk.  However, this
   application is explicitly to create a stable user-level API between versions,
   and adding it to trunk only will not solve the user's problem of switching
   between 1.6.2 and 1.8, nor will it help anybody switching from 1.8 to 1.10.
   Therefore, it needs to go into existing release branches.  For the sake of
   consistency, and also because one of the changes was between 1.4 and 1.6.x,
   I am also electing to commit this to 1.4.
   
   (closes issue ASTERISK-17497)
    Reported by: alexandrekeller
    Patches:
          20110304__issue18919__1.6.2.diff.txt uploaded by tilghman (license 14)
          20110304__issue18919__1.4.diff.txt uploaded by tilghman (license 14)
    Tested by: alexandrekeller
 ........
................

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

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

By: Digium Subversion (svnbot) 2011-03-12 14:42:34.000-0600

Repository: asterisk
Revision: 310500

_U  trunk/
U   trunk/pbx/pbx_ael.c

------------------------------------------------------------------------
r310500 | tilghman | 2011-03-12 14:42:34 -0600 (Sat, 12 Mar 2011) | 52 lines

Merged revisions 310462 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

................
 r310462 | tilghman | 2011-03-12 14:27:54 -0600 (Sat, 12 Mar 2011) | 45 lines
 
 Merged revisions 310448 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.6.2
 
 ................
   r310448 | tilghman | 2011-03-12 14:24:54 -0600 (Sat, 12 Mar 2011) | 38 lines
   
   Recorded merge of revisions 310435 via svnmerge from
   https://origsvn.digium.com/svn/asterisk/branches/1.4
   
   ........
     r310435 | tilghman | 2011-03-12 14:22:07 -0600 (Sat, 12 Mar 2011) | 31 lines
     
     Add AELSub, which provides a stable entry point into AEL subroutines.
     
     This commit needs some explanation, given that we're adding a new application
     into an existing release branch.  This is generally a violation of our release
     policy, except in very limited circumstances, and I believe this is one of
     those circumstances.
     
     The problem that this solves is one of the sanity of using multiple dialplan
     languages to define a dialplan.  In the case of the reporter, he or she is
     using AEL is define subroutines, while using Realtime extensions to invoke
     those subroutines.  While you can do this, it's based upon the reality of AEL
     using actual dialplan extensions; however, there is no guarantee that the
     details of _how_ AEL is compiled into extensions will remain stable.  In fact,
     at the time of this commit, it has already changed twice, once in a
     fundamental way.
     
     Now normally, a new application would only be added to trunk.  However, this
     application is explicitly to create a stable user-level API between versions,
     and adding it to trunk only will not solve the user's problem of switching
     between 1.6.2 and 1.8, nor will it help anybody switching from 1.8 to 1.10.
     Therefore, it needs to go into existing release branches.  For the sake of
     consistency, and also because one of the changes was between 1.4 and 1.6.x,
     I am also electing to commit this to 1.4.
     
     (closes issue ASTERISK-17497)
      Reported by: alexandrekeller
      Patches:
            20110304__issue18919__1.6.2.diff.txt uploaded by tilghman (license 14)
            20110304__issue18919__1.4.diff.txt uploaded by tilghman (license 14)
      Tested by: alexandrekeller
   ........
 ................
................

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

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