2007-08-23 23:37:33 +00:00
/* A Bison parser, made by GNU Bison 2.1a. */
2006-04-24 17:41:27 +00:00
2007-08-23 23:37:33 +00:00
/* Skeleton parser for Yacc-like parsing with Bison,
Copyright ( C ) 1984 , 1989 , 1990 , 2000 , 2001 , 2002 , 2003 , 2004 , 2005 , 2006 Free Software Foundation , Inc .
2006-04-24 17:41:27 +00:00
This program is free software ; you can redistribute it and / or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation ; either version 2 , or ( at your option )
any later version .
This program is distributed in the hope that it will be useful ,
but WITHOUT ANY WARRANTY ; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE . See the
GNU General Public License for more details .
You should have received a copy of the GNU General Public License
along with this program ; if not , write to the Free Software
Foundation , Inc . , 51 Franklin Street , Fifth Floor ,
Boston , MA 02110 - 1301 , USA . */
2007-08-23 23:37:33 +00:00
/* As a special exception, when this file is copied by Bison into a
Bison output file , you may use that output file without restriction .
This special exception was added by the Free Software Foundation
in version 1.24 of Bison . */
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
/* C LALR(1) parser skeleton written by Richard Stallman, by
simplifying the original so - called " semantic " parser . */
2006-04-24 17:41:27 +00:00
/* All symbols defined below should begin with yy or YY, to avoid
infringing on user name space . This should be done even for local
variables , as they might otherwise be expanded by user macros .
There are some unavoidable exceptions within include files to
define necessary library symbols ; they are noted " INFRINGES ON
USER NAME SPACE " below. */
/* Identify Bison output. */
# define YYBISON 1
/* Bison version. */
2007-08-23 23:37:33 +00:00
# define YYBISON_VERSION "2.1a"
2006-04-24 17:41:27 +00:00
/* Skeleton name. */
# define YYSKELETON_NAME "yacc.c"
/* Pure parsers. */
# define YYPURE 1
/* Using locations. */
# define YYLSP_NEEDED 1
/* Substitute the variable and function names. */
# define yyparse ael_yyparse
# define yylex ael_yylex
# define yyerror ael_yyerror
# define yylval ael_yylval
# define yychar ael_yychar
# define yydebug ael_yydebug
# define yynerrs ael_yynerrs
# define yylloc ael_yylloc
/* Tokens. */
# ifndef YYTOKENTYPE
# define YYTOKENTYPE
/* Put the tokens into the symbol table, so that GDB and other debuggers
know about them . */
enum yytokentype {
KW_CONTEXT = 258 ,
LC = 259 ,
RC = 260 ,
LP = 261 ,
RP = 262 ,
SEMI = 263 ,
EQ = 264 ,
COMMA = 265 ,
COLON = 266 ,
AMPER = 267 ,
BAR = 268 ,
AT = 269 ,
KW_MACRO = 270 ,
KW_GLOBALS = 271 ,
KW_IGNOREPAT = 272 ,
KW_SWITCH = 273 ,
KW_IF = 274 ,
KW_IFTIME = 275 ,
KW_ELSE = 276 ,
KW_RANDOM = 277 ,
KW_ABSTRACT = 278 ,
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
KW_EXTEND = 279 ,
EXTENMARK = 280 ,
KW_GOTO = 281 ,
KW_JUMP = 282 ,
KW_RETURN = 283 ,
KW_BREAK = 284 ,
KW_CONTINUE = 285 ,
KW_REGEXTEN = 286 ,
KW_HINT = 287 ,
KW_FOR = 288 ,
KW_WHILE = 289 ,
KW_CASE = 290 ,
KW_PATTERN = 291 ,
KW_DEFAULT = 292 ,
KW_CATCH = 293 ,
KW_SWITCHES = 294 ,
KW_ESWITCHES = 295 ,
KW_INCLUDES = 296 ,
KW_LOCAL = 297 ,
word = 298
2006-04-24 17:41:27 +00:00
} ;
# endif
/* Tokens. */
# define KW_CONTEXT 258
# define LC 259
# define RC 260
# define LP 261
# define RP 262
# define SEMI 263
# define EQ 264
# define COMMA 265
# define COLON 266
# define AMPER 267
# define BAR 268
# define AT 269
# define KW_MACRO 270
# define KW_GLOBALS 271
# define KW_IGNOREPAT 272
# define KW_SWITCH 273
# define KW_IF 274
# define KW_IFTIME 275
# define KW_ELSE 276
# define KW_RANDOM 277
# define KW_ABSTRACT 278
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
# define KW_EXTEND 279
# define EXTENMARK 280
# define KW_GOTO 281
# define KW_JUMP 282
# define KW_RETURN 283
# define KW_BREAK 284
# define KW_CONTINUE 285
# define KW_REGEXTEN 286
# define KW_HINT 287
# define KW_FOR 288
# define KW_WHILE 289
# define KW_CASE 290
# define KW_PATTERN 291
# define KW_DEFAULT 292
# define KW_CATCH 293
# define KW_SWITCHES 294
# define KW_ESWITCHES 295
# define KW_INCLUDES 296
# define KW_LOCAL 297
# define word 298
2006-04-24 17:41:27 +00:00
/* Copy the first part of user declarations. */
# line 1 "ael.y"
/*
2006-04-26 18:43:29 +00:00
* Asterisk - - An open source telephony toolkit .
2006-04-24 17:41:27 +00:00
*
* Copyright ( C ) 2006 , Digium , Inc .
*
* Steve Murphy < murf @ parsetree . com >
*
* See http : //www.asterisk.org for more information about
* the Asterisk project . Please do not directly contact
* any of the maintainers of this project for assistance ;
* the project provides a web site , mailing lists and IRC
* channels for your use .
*
* This program is free software , distributed under the terms of
* the GNU General Public License Version 2. See the LICENSE file
* at the top of the source tree .
*/
/*! \file
*
* \ brief Bison Grammar description of AEL2 .
2006-04-26 18:43:29 +00:00
*
2006-04-24 17:41:27 +00:00
*/
2006-07-19 02:55:24 +00:00
2006-06-07 18:54:56 +00:00
# include "asterisk.h"
ASTERISK_FILE_VERSION ( __FILE__ , " $Revision$ " )
2006-04-24 17:41:27 +00:00
# include <stdio.h>
# include <stdlib.h>
# include <string.h>
2006-06-07 18:54:56 +00:00
2006-04-24 17:41:27 +00:00
# include "asterisk/logger.h"
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# include "asterisk/lock.h"
# include "asterisk/hashtab.h"
2006-04-24 17:41:27 +00:00
# include "asterisk/ael_structs.h"
2007-08-15 19:21:27 +00:00
pval * linku1 ( pval * head , pval * tail ) ;
2006-08-07 12:59:47 +00:00
static void set_dads ( pval * dad , pval * child_list ) ;
2006-04-26 22:41:16 +00:00
void reset_parencount ( yyscan_t yyscanner ) ;
void reset_semicount ( yyscan_t yyscanner ) ;
void reset_argcount ( yyscan_t yyscanner ) ;
2007-08-15 19:21:27 +00:00
2006-04-24 17:41:27 +00:00
# define YYLEX_PARAM ((struct parse_io *)parseio)->scanner
# define YYERROR_VERBOSE 1
extern char * my_file ;
# ifdef AAL_ARGCHECK
int ael_is_funcname ( char * name ) ;
# endif
2007-09-27 00:06:06 +00:00
static char * ael_token_subst ( const char * mess ) ;
2006-04-26 18:43:29 +00:00
2006-04-24 17:41:27 +00:00
/* Enabling traces. */
# ifndef YYDEBUG
# define YYDEBUG 0
# endif
/* Enabling verbose error messages. */
# ifdef YYERROR_VERBOSE
# undef YYERROR_VERBOSE
# define YYERROR_VERBOSE 1
# else
# define YYERROR_VERBOSE 1
# endif
/* Enabling the token table. */
# ifndef YYTOKEN_TABLE
# define YYTOKEN_TABLE 0
# endif
2006-06-18 21:36:24 +00:00
# if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
typedef union YYSTYPE
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 56 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-30 12:44:54 +00:00
int intval ; /* integer value, typically flags */
char * str ; /* strings */
struct pval * pval ; /* full objects */
2006-06-18 21:36:24 +00:00
}
2007-08-23 23:37:33 +00:00
/* Line 198 of yacc.c. */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 240 "ael.tab.c"
2006-06-18 21:36:24 +00:00
YYSTYPE ;
2006-04-24 17:41:27 +00:00
# define yystype YYSTYPE /* obsolescent; will be withdrawn */
# define YYSTYPE_IS_DECLARED 1
# define YYSTYPE_IS_TRIVIAL 1
# endif
2006-06-18 21:36:24 +00:00
# if ! defined YYLTYPE && ! defined YYLTYPE_IS_DECLARED
2006-04-24 17:41:27 +00:00
typedef struct YYLTYPE
{
int first_line ;
int first_column ;
int last_line ;
int last_column ;
} YYLTYPE ;
# define yyltype YYLTYPE /* obsolescent; will be withdrawn */
# define YYLTYPE_IS_DECLARED 1
# define YYLTYPE_IS_TRIVIAL 1
# endif
/* Copy the second part of user declarations. */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 62 "ael.y"
2006-04-24 17:41:27 +00:00
/* declaring these AFTER the union makes things a lot simpler! */
void yyerror ( YYLTYPE * locp , struct parse_io * parseio , char const * s ) ;
int ael_yylex ( YYSTYPE * yylval_param , YYLTYPE * yylloc_param , void * yyscanner ) ;
2006-04-26 18:43:29 +00:00
2006-04-30 13:57:08 +00:00
/* create a new object with start-end marker */
2007-08-15 19:21:27 +00:00
pval * npval ( pvaltype type , int first_line , int last_line ,
2006-04-30 13:57:08 +00:00
int first_column , int last_column ) ;
2006-04-27 18:09:20 +00:00
/* create a new object with start-end marker, simplified interface.
* Must be declared here because YYLTYPE is not known before
*/
static pval * npval2 ( pvaltype type , YYLTYPE * first , YYLTYPE * last ) ;
2006-04-24 17:41:27 +00:00
2006-04-30 13:57:08 +00:00
/* another frontend for npval, this time for a string */
static pval * nword ( char * string , YYLTYPE * pos ) ;
2006-04-30 12:12:39 +00:00
/* update end position of an object, return the object */
static pval * update_last ( pval * , YYLTYPE * ) ;
2006-04-24 17:41:27 +00:00
2007-08-23 23:37:33 +00:00
/* Line 221 of yacc.c. */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 285 "ael.tab.c"
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
# ifdef short
# undef short
2006-04-24 17:41:27 +00:00
# endif
2006-06-18 21:36:24 +00:00
# ifdef YYTYPE_UINT8
typedef YYTYPE_UINT8 yytype_uint8 ;
# else
typedef unsigned char yytype_uint8 ;
2006-04-24 17:41:27 +00:00
# endif
2006-06-18 21:36:24 +00:00
# ifdef YYTYPE_INT8
typedef YYTYPE_INT8 yytype_int8 ;
# elif (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
typedef signed char yytype_int8 ;
# else
typedef short int yytype_int8 ;
2006-04-24 17:41:27 +00:00
# endif
2006-06-18 21:36:24 +00:00
# ifdef YYTYPE_UINT16
typedef YYTYPE_UINT16 yytype_uint16 ;
# else
typedef unsigned short int yytype_uint16 ;
2006-04-24 17:41:27 +00:00
# endif
2006-06-18 21:36:24 +00:00
# ifdef YYTYPE_INT16
typedef YYTYPE_INT16 yytype_int16 ;
# else
typedef short int yytype_int16 ;
# endif
# ifndef YYSIZE_T
# ifdef __SIZE_TYPE__
# define YYSIZE_T __SIZE_TYPE__
# elif defined size_t
# define YYSIZE_T size_t
# elif ! defined YYSIZE_T && (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
# include <stddef.h> /* INFRINGES ON USER NAME SPACE */
# define YYSIZE_T size_t
# else
# define YYSIZE_T unsigned int
# endif
# endif
# define YYSIZE_MAXIMUM ((YYSIZE_T) -1)
2006-04-24 17:41:27 +00:00
# ifndef YY_
2007-06-05 22:04:22 +00:00
# if YYENABLE_NLS
2006-04-24 17:41:27 +00:00
# if ENABLE_NLS
# include <libintl.h> /* INFRINGES ON USER NAME SPACE */
# define YY_(msgid) dgettext ("bison-runtime", msgid)
# endif
# endif
# ifndef YY_
# define YY_(msgid) msgid
# endif
# endif
2006-06-18 21:36:24 +00:00
/* Suppress unused-variable warnings by "using" E. */
# if ! defined lint || defined __GNUC__
# define YYUSE(e) ((void) (e))
# else
# define YYUSE(e) /* empty */
# endif
/* Identity function, used to suppress warnings about constant conditions. */
# ifndef lint
# define YYID(n) (n)
# else
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
static int
YYID ( int i )
# else
static int
YYID ( i )
int i ;
# endif
{
return i ;
}
# endif
# if ! defined yyoverflow || YYERROR_VERBOSE
2006-04-24 17:41:27 +00:00
/* The parser invokes alloca or malloc; define the necessary symbols. */
# ifdef YYSTACK_USE_ALLOCA
# if YYSTACK_USE_ALLOCA
# ifdef __GNUC__
# define YYSTACK_ALLOC __builtin_alloca
2006-06-18 21:36:24 +00:00
# elif defined __BUILTIN_VA_ARG_INCR
# include <alloca.h> /* INFRINGES ON USER NAME SPACE */
# elif defined _AIX
# define YYSTACK_ALLOC __alloca
# elif defined _MSC_VER
# include <malloc.h> /* INFRINGES ON USER NAME SPACE */
# define alloca _alloca
2006-04-24 17:41:27 +00:00
# else
# define YYSTACK_ALLOC alloca
2006-06-18 21:36:24 +00:00
# if ! defined _ALLOCA_H && ! defined _STDLIB_H && (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
# include <stdlib.h> /* INFRINGES ON USER NAME SPACE */
2006-06-18 21:36:24 +00:00
# ifndef _STDLIB_H
# define _STDLIB_H 1
# endif
2006-04-24 17:41:27 +00:00
# endif
# endif
# endif
# endif
# ifdef YYSTACK_ALLOC
2006-06-18 21:36:24 +00:00
/* Pacify GCC's `empty if-body' warning. */
# define YYSTACK_FREE(Ptr) do { /* empty */ ; } while (YYID (0))
2006-04-24 17:41:27 +00:00
# ifndef YYSTACK_ALLOC_MAXIMUM
/* The OS might guarantee only one guard page at the bottom of the stack,
and a page size can be as small as 4096 bytes . So we cannot safely
invoke alloca ( N ) if N exceeds 4096. Use a slightly smaller number
to allow for a few compiler - allocated temporary stack slots . */
2006-06-18 21:36:24 +00:00
# define YYSTACK_ALLOC_MAXIMUM 4032 /* reasonable circa 2006 */
2006-04-24 17:41:27 +00:00
# endif
# else
# define YYSTACK_ALLOC YYMALLOC
# define YYSTACK_FREE YYFREE
# ifndef YYSTACK_ALLOC_MAXIMUM
2006-06-18 21:36:24 +00:00
# define YYSTACK_ALLOC_MAXIMUM YYSIZE_MAXIMUM
2006-04-24 17:41:27 +00:00
# endif
2007-08-23 23:37:33 +00:00
# ifdef __cplusplus
extern " C " {
2006-04-24 17:41:27 +00:00
# endif
# ifndef YYMALLOC
# define YYMALLOC malloc
2006-06-18 21:36:24 +00:00
# if ! defined malloc && ! defined _STDLIB_H && (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
void * malloc ( YYSIZE_T ) ; /* INFRINGES ON USER NAME SPACE */
# endif
# endif
# ifndef YYFREE
# define YYFREE free
2006-06-18 21:36:24 +00:00
# if ! defined free && ! defined _STDLIB_H && (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
void free ( void * ) ; /* INFRINGES ON USER NAME SPACE */
# endif
# endif
2007-08-23 23:37:33 +00:00
# ifdef __cplusplus
}
# endif
2006-04-24 17:41:27 +00:00
# endif
2006-06-18 21:36:24 +00:00
# endif /* ! defined yyoverflow || YYERROR_VERBOSE */
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
# if (! defined yyoverflow \
& & ( ! defined __cplusplus \
| | ( defined YYLTYPE_IS_TRIVIAL & & YYLTYPE_IS_TRIVIAL \
& & defined YYSTYPE_IS_TRIVIAL & & YYSTYPE_IS_TRIVIAL ) ) )
2006-04-24 17:41:27 +00:00
/* A type that is properly aligned for any stack member. */
union yyalloc
{
2006-06-18 21:36:24 +00:00
yytype_int16 yyss ;
2006-04-24 17:41:27 +00:00
YYSTYPE yyvs ;
YYLTYPE yyls ;
} ;
/* The size of the maximum gap between one aligned stack and the next. */
# define YYSTACK_GAP_MAXIMUM (sizeof (union yyalloc) - 1)
/* The size of an array large to enough to hold all stacks, each with
N elements . */
# define YYSTACK_BYTES(N) \
2006-06-18 21:36:24 +00:00
( ( N ) * ( sizeof ( yytype_int16 ) + sizeof ( YYSTYPE ) + sizeof ( YYLTYPE ) ) \
2006-04-24 17:41:27 +00:00
+ 2 * YYSTACK_GAP_MAXIMUM )
/* Copy COUNT objects from FROM to TO. The source and destination do
not overlap . */
# ifndef YYCOPY
2006-06-18 21:36:24 +00:00
# if defined __GNUC__ && 1 < __GNUC__
2006-04-24 17:41:27 +00:00
# define YYCOPY(To, From, Count) \
__builtin_memcpy ( To , From , ( Count ) * sizeof ( * ( From ) ) )
# else
# define YYCOPY(To, From, Count) \
do \
{ \
YYSIZE_T yyi ; \
for ( yyi = 0 ; yyi < ( Count ) ; yyi + + ) \
( To ) [ yyi ] = ( From ) [ yyi ] ; \
} \
2006-06-18 21:36:24 +00:00
while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
# endif
# endif
/* Relocate STACK from its old location to the new one. The
local variables YYSIZE and YYSTACKSIZE give the old and new number of
elements in the stack , and YYPTR gives the new location of the
stack . Advance YYPTR to a properly aligned location for the next
stack . */
# define YYSTACK_RELOCATE(Stack) \
do \
{ \
YYSIZE_T yynewbytes ; \
YYCOPY ( & yyptr - > Stack , Stack , yysize ) ; \
Stack = & yyptr - > Stack ; \
yynewbytes = yystacksize * sizeof ( * Stack ) + YYSTACK_GAP_MAXIMUM ; \
yyptr + = yynewbytes / sizeof ( * yyptr ) ; \
} \
2006-06-18 21:36:24 +00:00
while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
# endif
2006-06-18 21:36:24 +00:00
/* YYFINAL -- State number of the termination state. */
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
# define YYFINAL 17
2006-04-24 17:41:27 +00:00
/* YYLAST -- Last index in YYTABLE. */
2007-11-27 18:50:44 +00:00
# define YYLAST 327
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
/* YYNTOKENS -- Number of terminals. */
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
# define YYNTOKENS 44
2006-06-18 21:36:24 +00:00
/* YYNNTS -- Number of nonterminals. */
2007-06-20 20:10:19 +00:00
# define YYNNTS 56
2006-06-18 21:36:24 +00:00
/* YYNRULES -- Number of rules. */
2007-11-27 18:50:44 +00:00
# define YYNRULES 142
2006-06-18 21:36:24 +00:00
/* YYNRULES -- Number of states. */
2007-11-27 18:50:44 +00:00
# define YYNSTATES 288
2006-04-24 17:41:27 +00:00
/* YYTRANSLATE(YYLEX) -- Bison symbol number corresponding to YYLEX. */
# define YYUNDEFTOK 2
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
# define YYMAXUTOK 298
2006-04-24 17:41:27 +00:00
# define YYTRANSLATE(YYX) \
( ( unsigned int ) ( YYX ) < = YYMAXUTOK ? yytranslate [ YYX ] : YYUNDEFTOK )
/* YYTRANSLATE[YYLEX] -- Bison symbol number corresponding to YYLEX. */
2006-06-18 21:36:24 +00:00
static const yytype_uint8 yytranslate [ ] =
2006-04-24 17:41:27 +00:00
{
0 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 , 2 ,
2 , 2 , 2 , 2 , 2 , 2 , 1 , 2 , 3 , 4 ,
5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 , 14 ,
15 , 16 , 17 , 18 , 19 , 20 , 21 , 22 , 23 , 24 ,
25 , 26 , 27 , 28 , 29 , 30 , 31 , 32 , 33 , 34 ,
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
35 , 36 , 37 , 38 , 39 , 40 , 41 , 42 , 43
2006-04-24 17:41:27 +00:00
} ;
# if YYDEBUG
/* YYPRHS[YYN] -- Index of the first RHS symbol of rule number YYN in
YYRHS . */
2006-06-18 21:36:24 +00:00
static const yytype_uint16 yyprhs [ ] =
2006-04-24 17:41:27 +00:00
{
0 , 0 , 3 , 5 , 7 , 10 , 13 , 15 , 17 , 19 ,
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
21 , 23 , 25 , 32 , 34 , 35 , 37 , 40 , 43 , 52 ,
57 , 58 , 61 , 64 , 65 , 71 , 72 , 79 , 80 , 82 ,
86 , 89 , 90 , 93 , 96 , 98 , 100 , 102 , 104 , 106 ,
2007-11-27 18:50:44 +00:00
108 , 110 , 113 , 115 , 120 , 124 , 130 , 135 , 143 , 152 ,
153 , 156 , 159 , 165 , 167 , 175 , 176 , 181 , 184 , 187 ,
192 , 194 , 197 , 199 , 202 , 206 , 210 , 212 , 215 , 219 ,
221 , 224 , 228 , 234 , 238 , 240 , 242 , 246 , 250 , 253 ,
254 , 255 , 256 , 269 , 273 , 275 , 279 , 282 , 285 , 286 ,
292 , 295 , 298 , 301 , 305 , 307 , 310 , 311 , 313 , 317 ,
321 , 327 , 333 , 339 , 345 , 346 , 349 , 352 , 357 , 358 ,
364 , 368 , 369 , 373 , 377 , 380 , 382 , 383 , 385 , 386 ,
390 , 391 , 394 , 399 , 403 , 408 , 409 , 412 , 414 , 416 ,
422 , 427 , 432 , 433 , 437 , 443 , 446 , 448 , 452 , 455 ,
459 , 462 , 467
2006-04-24 17:41:27 +00:00
} ;
2006-06-18 21:36:24 +00:00
/* YYRHS -- A `-1'-separated list of the rules' RHS. */
static const yytype_int8 yyrhs [ ] =
2006-04-24 17:41:27 +00:00
{
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
45 , 0 , - 1 , 46 , - 1 , 47 , - 1 , 46 , 47 , - 1 ,
46 , 1 , - 1 , 49 , - 1 , 51 , - 1 , 52 , - 1 , 8 ,
- 1 , 43 , - 1 , 37 , - 1 , 50 , 3 , 48 , 4 , 59 ,
5 , - 1 , 23 , - 1 , - 1 , 24 , - 1 , 24 , 23 , - 1 ,
23 , 24 , - 1 , 15 , 43 , 6 , 58 , 7 , 4 , 92 ,
5 , - 1 , 16 , 4 , 53 , 5 , - 1 , - 1 , 54 , 53 ,
- 1 , 1 , 53 , - 1 , - 1 , 43 , 9 , 55 , 43 , 8 ,
- 1 , - 1 , 42 , 43 , 9 , 57 , 43 , 8 , - 1 , - 1 ,
43 , - 1 , 58 , 10 , 43 , - 1 , 58 , 1 , - 1 , - 1 ,
60 , 59 , - 1 , 1 , 59 , - 1 , 62 , - 1 , 99 , - 1 ,
94 , - 1 , 95 , - 1 , 61 , - 1 , 54 , - 1 , 56 , - 1 ,
43 , 1 , - 1 , 8 , - 1 , 17 , 25 , 43 , 8 , - 1 ,
2007-11-27 18:50:44 +00:00
43 , 25 , 74 , - 1 , 43 , 14 , 43 , 25 , 74 , - 1 ,
31 , 43 , 25 , 74 , - 1 , 32 , 6 , 70 , 7 , 43 ,
25 , 74 , - 1 , 31 , 32 , 6 , 70 , 7 , 43 , 25 ,
74 , - 1 , - 1 , 74 , 63 , - 1 , 1 , 63 , - 1 , 71 ,
11 , 71 , 11 , 71 , - 1 , 43 , - 1 , 64 , 13 , 71 ,
13 , 71 , 13 , 71 , - 1 , - 1 , 6 , 67 , 69 , 7 ,
- 1 , 19 , 66 , - 1 , 22 , 66 , - 1 , 20 , 6 , 65 ,
7 , - 1 , 43 , - 1 , 43 , 43 , - 1 , 43 , - 1 , 70 ,
43 , - 1 , 70 , 11 , 43 , - 1 , 70 , 12 , 43 , - 1 ,
43 , - 1 , 43 , 43 , - 1 , 43 , 43 , 43 , - 1 , 43 ,
- 1 , 43 , 43 , - 1 , 72 , 11 , 43 , - 1 , 18 , 66 ,
4 , 90 , 5 , - 1 , 4 , 63 , 5 , - 1 , 54 , - 1 ,
56 , - 1 , 26 , 80 , 8 , - 1 , 27 , 82 , 8 , - 1 ,
43 , 11 , - 1 , - 1 , - 1 , - 1 , 33 , 6 , 75 , 43 ,
8 , 76 , 43 , 8 , 77 , 43 , 7 , 74 , - 1 , 34 ,
66 , 74 , - 1 , 73 , - 1 , 12 , 83 , 8 , - 1 , 87 ,
8 , - 1 , 43 , 8 , - 1 , - 1 , 87 , 9 , 78 , 43 ,
8 , - 1 , 29 , 8 , - 1 , 28 , 8 , - 1 , 30 , 8 ,
- 1 , 68 , 74 , 79 , - 1 , 8 , - 1 , 21 , 74 , - 1 ,
- 1 , 72 , - 1 , 72 , 13 , 72 , - 1 , 72 , 10 , 72 ,
- 1 , 72 , 13 , 72 , 13 , 72 , - 1 , 72 , 10 , 72 ,
10 , 72 , - 1 , 37 , 13 , 72 , 13 , 72 , - 1 , 37 ,
10 , 72 , 10 , 72 , - 1 , - 1 , 10 , 43 , - 1 , 72 ,
81 , - 1 , 72 , 81 , 14 , 48 , - 1 , - 1 , 43 , 6 ,
84 , 89 , 7 , - 1 , 43 , 6 , 7 , - 1 , - 1 , 43 ,
6 , 86 , - 1 , 85 , 89 , 7 , - 1 , 85 , 7 , - 1 ,
43 , - 1 , - 1 , 69 , - 1 , - 1 , 89 , 10 , 88 , - 1 ,
- 1 , 91 , 90 , - 1 , 35 , 43 , 11 , 63 , - 1 , 37 ,
11 , 63 , - 1 , 36 , 43 , 11 , 63 , - 1 , - 1 , 93 ,
92 , - 1 , 74 , - 1 , 99 , - 1 , 38 , 43 , 4 , 63 ,
5 , - 1 , 39 , 4 , 96 , 5 , - 1 , 40 , 4 , 96 ,
5 , - 1 , - 1 , 43 , 8 , 96 , - 1 , 43 , 14 , 43 ,
8 , 96 , - 1 , 1 , 96 , - 1 , 48 , - 1 , 48 , 13 ,
65 , - 1 , 97 , 8 , - 1 , 98 , 97 , 8 , - 1 , 98 ,
1 , - 1 , 41 , 4 , 98 , 5 , - 1 , 41 , 4 , 5 ,
- 1
2006-04-24 17:41:27 +00:00
} ;
/* YYRLINE[YYN] -- source line where rule number YYN was defined. */
2006-06-18 21:36:24 +00:00
static const yytype_uint16 yyrline [ ] =
2006-04-24 17:41:27 +00:00
{
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
0 , 188 , 188 , 191 , 192 , 193 , 196 , 197 , 198 , 199 ,
202 , 203 , 206 , 215 , 216 , 217 , 218 , 219 , 222 , 228 ,
234 , 235 , 236 , 239 , 239 , 245 , 245 , 252 , 253 , 254 ,
255 , 258 , 259 , 260 , 263 , 264 , 265 , 266 , 267 , 268 ,
269 , 270 , 271 , 274 , 279 , 283 , 291 , 296 , 301 , 310 ,
311 , 312 , 318 , 323 , 327 , 335 , 335 , 339 , 342 , 345 ,
356 , 357 , 364 , 365 , 369 , 373 , 379 , 380 , 385 , 393 ,
394 , 398 , 404 , 413 , 416 , 417 , 418 , 421 , 424 , 427 ,
428 , 429 , 427 , 435 , 439 , 440 , 441 , 442 , 445 , 445 ,
478 , 479 , 480 , 481 , 485 , 488 , 489 , 492 , 493 , 496 ,
499 , 503 , 507 , 511 , 517 , 518 , 522 , 525 , 531 , 531 ,
536 , 544 , 544 , 555 , 562 , 565 , 566 , 569 , 570 , 573 ,
576 , 577 , 580 , 584 , 588 , 594 , 595 , 598 , 599 , 600 ,
606 , 611 , 616 , 617 , 618 , 620 , 623 , 624 , 631 , 632 ,
633 , 636 , 639
2006-04-24 17:41:27 +00:00
} ;
# endif
# if YYDEBUG || YYERROR_VERBOSE || YYTOKEN_TABLE
/* YYTNAME[SYMBOL-NUM] -- String name of the symbol SYMBOL-NUM.
2006-06-18 21:36:24 +00:00
First , the terminals , then , starting at YYNTOKENS , nonterminals . */
2006-04-24 17:41:27 +00:00
static const char * const yytname [ ] =
{
" $end " , " error " , " $undefined " , " KW_CONTEXT " , " LC " , " RC " , " LP " , " RP " ,
" SEMI " , " EQ " , " COMMA " , " COLON " , " AMPER " , " BAR " , " AT " , " KW_MACRO " ,
" KW_GLOBALS " , " KW_IGNOREPAT " , " KW_SWITCH " , " KW_IF " , " KW_IFTIME " ,
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
" KW_ELSE " , " KW_RANDOM " , " KW_ABSTRACT " , " KW_EXTEND " , " EXTENMARK " ,
" KW_GOTO " , " KW_JUMP " , " KW_RETURN " , " KW_BREAK " , " KW_CONTINUE " ,
" KW_REGEXTEN " , " KW_HINT " , " KW_FOR " , " KW_WHILE " , " KW_CASE " , " KW_PATTERN " ,
" KW_DEFAULT " , " KW_CATCH " , " KW_SWITCHES " , " KW_ESWITCHES " , " KW_INCLUDES " ,
" KW_LOCAL " , " word " , " $accept " , " file " , " objects " , " object " ,
" context_name " , " context " , " opt_abstract " , " macro " , " globals " ,
" global_statements " , " assignment " , " @1 " , " local_assignment " , " @2 " ,
" arglist " , " elements " , " element " , " ignorepat " , " extension " , " statements " ,
" timerange " , " timespec " , " test_expr " , " @3 " , " if_like_head " , " word_list " ,
" hint_word " , " word3_list " , " goto_word " , " switch_statement " , " statement " ,
" @4 " , " @5 " , " @6 " , " @7 " , " opt_else " , " target " , " opt_pri " , " jumptarget " ,
" macro_call " , " @8 " , " application_call_head " , " @9 " , " application_call " ,
" opt_word " , " eval_arglist " , " case_statements " , " case_statement " ,
" macro_statements " , " macro_statement " , " switches " , " eswitches " ,
" switchlist " , " included_entry " , " includeslist " , " includes " , 0
2006-04-24 17:41:27 +00:00
} ;
# endif
# ifdef YYPRINT
/* YYTOKNUM[YYLEX-NUM] -- Internal token number corresponding to
token YYLEX - NUM . */
2006-06-18 21:36:24 +00:00
static const yytype_uint16 yytoknum [ ] =
2006-04-24 17:41:27 +00:00
{
0 , 256 , 257 , 258 , 259 , 260 , 261 , 262 , 263 , 264 ,
265 , 266 , 267 , 268 , 269 , 270 , 271 , 272 , 273 , 274 ,
275 , 276 , 277 , 278 , 279 , 280 , 281 , 282 , 283 , 284 ,
285 , 286 , 287 , 288 , 289 , 290 , 291 , 292 , 293 , 294 ,
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
295 , 296 , 297 , 298
2006-04-24 17:41:27 +00:00
} ;
# endif
/* YYR1[YYN] -- Symbol number of symbol that rule YYN derives. */
2006-06-18 21:36:24 +00:00
static const yytype_uint8 yyr1 [ ] =
2006-04-24 17:41:27 +00:00
{
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
0 , 44 , 45 , 46 , 46 , 46 , 47 , 47 , 47 , 47 ,
48 , 48 , 49 , 50 , 50 , 50 , 50 , 50 , 51 , 52 ,
53 , 53 , 53 , 55 , 54 , 57 , 56 , 58 , 58 , 58 ,
58 , 59 , 59 , 59 , 60 , 60 , 60 , 60 , 60 , 60 ,
2007-11-27 18:50:44 +00:00
60 , 60 , 60 , 61 , 62 , 62 , 62 , 62 , 62 , 63 ,
63 , 63 , 64 , 64 , 65 , 67 , 66 , 68 , 68 , 68 ,
69 , 69 , 70 , 70 , 70 , 70 , 71 , 71 , 71 , 72 ,
72 , 72 , 73 , 74 , 74 , 74 , 74 , 74 , 74 , 75 ,
76 , 77 , 74 , 74 , 74 , 74 , 74 , 74 , 78 , 74 ,
74 , 74 , 74 , 74 , 74 , 79 , 79 , 80 , 80 , 80 ,
80 , 80 , 80 , 80 , 81 , 81 , 82 , 82 , 84 , 83 ,
83 , 86 , 85 , 87 , 87 , 88 , 88 , 89 , 89 , 89 ,
90 , 90 , 91 , 91 , 91 , 92 , 92 , 93 , 93 , 93 ,
94 , 95 , 96 , 96 , 96 , 96 , 97 , 97 , 98 , 98 ,
98 , 99 , 99
2006-04-24 17:41:27 +00:00
} ;
/* YYR2[YYN] -- Number of symbols composing right hand side of rule YYN. */
2006-06-18 21:36:24 +00:00
static const yytype_uint8 yyr2 [ ] =
2006-04-24 17:41:27 +00:00
{
0 , 2 , 1 , 1 , 2 , 2 , 1 , 1 , 1 , 1 ,
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
1 , 1 , 6 , 1 , 0 , 1 , 2 , 2 , 8 , 4 ,
0 , 2 , 2 , 0 , 5 , 0 , 6 , 0 , 1 , 3 ,
2 , 0 , 2 , 2 , 1 , 1 , 1 , 1 , 1 , 1 ,
2007-11-27 18:50:44 +00:00
1 , 2 , 1 , 4 , 3 , 5 , 4 , 7 , 8 , 0 ,
2 , 2 , 5 , 1 , 7 , 0 , 4 , 2 , 2 , 4 ,
1 , 2 , 1 , 2 , 3 , 3 , 1 , 2 , 3 , 1 ,
2 , 3 , 5 , 3 , 1 , 1 , 3 , 3 , 2 , 0 ,
0 , 0 , 12 , 3 , 1 , 3 , 2 , 2 , 0 , 5 ,
2 , 2 , 2 , 3 , 1 , 2 , 0 , 1 , 3 , 3 ,
5 , 5 , 5 , 5 , 0 , 2 , 2 , 4 , 0 , 5 ,
3 , 0 , 3 , 3 , 2 , 1 , 0 , 1 , 0 , 3 ,
0 , 2 , 4 , 3 , 4 , 0 , 2 , 1 , 1 , 5 ,
4 , 4 , 0 , 3 , 5 , 2 , 1 , 3 , 2 , 3 ,
2 , 4 , 3
2006-04-24 17:41:27 +00:00
} ;
/* YYDEFACT[STATE-NAME] -- Default rule to reduce with in state
STATE - NUM when YYTABLE doesn ' t specify something else to do . Zero
means the default is an error . */
2006-06-18 21:36:24 +00:00
static const yytype_uint8 yydefact [ ] =
2006-04-24 17:41:27 +00:00
{
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
14 , 9 , 0 , 0 , 13 , 15 , 0 , 0 , 3 , 6 ,
0 , 7 , 8 , 0 , 0 , 17 , 16 , 1 , 5 , 4 ,
0 , 27 , 0 , 0 , 0 , 0 , 11 , 10 , 0 , 28 ,
0 , 22 , 23 , 19 , 21 , 0 , 30 , 0 , 0 , 0 ,
0 , 42 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 ,
2007-11-27 18:50:44 +00:00
39 , 40 , 0 , 0 , 38 , 34 , 36 , 37 , 35 , 125 ,
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
29 , 0 , 33 , 0 , 0 , 0 , 0 , 0 , 0 , 0 ,
2007-11-27 18:50:44 +00:00
0 , 41 , 0 , 0 , 12 , 32 , 0 , 94 , 0 , 0 ,
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 ,
2007-11-27 18:50:44 +00:00
0 , 0 , 74 , 75 , 0 , 84 , 127 , 118 , 0 , 0 ,
125 , 128 , 24 , 0 , 0 , 0 , 62 , 0 , 0 , 0 ,
0 , 0 , 142 , 136 , 0 , 0 , 25 , 0 , 44 , 0 ,
0 , 0 , 0 , 0 , 55 , 0 , 57 , 0 , 58 , 0 ,
69 , 97 , 0 , 104 , 0 , 91 , 90 , 92 , 79 , 0 ,
0 , 111 , 87 , 78 , 96 , 114 , 60 , 117 , 0 , 86 ,
88 , 18 , 126 , 43 , 0 , 46 , 0 , 0 , 0 , 63 ,
135 , 0 , 0 , 130 , 131 , 0 , 138 , 140 , 141 , 0 ,
0 , 0 , 51 , 73 , 50 , 108 , 85 , 0 , 120 , 53 ,
0 , 0 , 0 , 0 , 0 , 70 , 0 , 0 , 0 , 76 ,
0 , 106 , 77 , 0 , 83 , 0 , 112 , 0 , 93 , 61 ,
113 , 116 , 0 , 0 , 0 , 64 , 65 , 133 , 0 , 137 ,
139 , 0 , 45 , 110 , 118 , 0 , 0 , 0 , 0 , 0 ,
120 , 67 , 0 , 59 , 0 , 0 , 0 , 99 , 71 , 98 ,
105 , 0 , 0 , 0 , 95 , 115 , 119 , 0 , 0 , 0 ,
0 , 26 , 0 , 56 , 0 , 0 , 0 , 72 , 121 , 68 ,
66 , 0 , 0 , 0 , 0 , 0 , 0 , 107 , 80 , 129 ,
89 , 0 , 47 , 134 , 109 , 0 , 0 , 123 , 0 , 0 ,
103 , 102 , 101 , 100 , 0 , 48 , 122 , 124 , 0 , 52 ,
0 , 0 , 81 , 54 , 0 , 0 , 0 , 82
2006-04-24 17:41:27 +00:00
} ;
2006-06-18 21:36:24 +00:00
/* YYDEFGOTO[NTERM-NUM]. */
static const yytype_int16 yydefgoto [ ] =
2006-04-24 17:41:27 +00:00
{
2007-11-27 18:50:44 +00:00
- 1 , 6 , 7 , 8 , 113 , 9 , 10 , 11 , 12 , 24 ,
92 , 39 , 93 , 170 , 30 , 52 , 53 , 54 , 55 , 120 ,
180 , 181 , 125 , 177 , 94 , 147 , 107 , 182 , 131 , 95 ,
121 , 193 , 274 , 284 , 202 , 198 , 132 , 191 , 134 , 123 ,
214 , 97 , 196 , 98 , 236 , 148 , 219 , 220 , 99 , 100 ,
56 , 57 , 110 , 114 , 115 , 58
2006-04-24 17:41:27 +00:00
} ;
/* YYPACT[STATE-NUM] -- Index in YYTABLE of the portion describing
STATE - NUM . */
2007-11-27 18:50:44 +00:00
# define YYPACT_NINF -219
2006-06-18 21:36:24 +00:00
static const yytype_int16 yypact [ ] =
2006-04-24 17:41:27 +00:00
{
2007-11-27 18:50:44 +00:00
102 , - 219 , - 25 , 40 , 24 , 29 , 70 , 249 , - 219 , - 219 ,
74 , - 219 , - 219 , 107 , 11 , - 219 , - 219 , - 219 , - 219 , - 219 ,
- 6 , 65 , 11 , 137 , 148 , 11 , - 219 , - 219 , 152 , - 219 ,
87 , - 219 , - 219 , - 219 , - 219 , 123 , - 219 , 173 , 126 , 136 ,
123 , - 219 , 159 , - 11 , 186 , 190 , 194 , 196 , 158 , 86 ,
- 219 , - 219 , 203 , 123 , - 219 , - 219 , - 219 , - 219 , - 219 , 177 ,
- 219 , 201 , - 219 , 170 , 208 , 191 , 179 , 12 , 12 , 19 ,
214 , - 219 , 181 , 213 , - 219 , - 219 , 115 , - 219 , 183 , 222 ,
222 , 223 , 222 , 36 , 187 , 226 , 228 , 229 , 232 , 222 ,
202 , 182 , - 219 , - 219 , 213 , - 219 , - 219 , 16 , 113 , 239 ,
177 , - 219 , - 219 , 240 , 179 , 213 , - 219 , 22 , 12 , 101 ,
246 , 248 , - 219 , 241 , 250 , 10 , - 219 , 234 , - 219 , 56 ,
255 , 56 , 256 , 253 , - 219 , 259 , - 219 , 224 , - 219 , 26 ,
225 , 157 , 258 , 119 , 261 , - 219 , - 219 , - 219 , - 219 , 213 ,
266 , - 219 , - 219 , - 219 , 254 , - 219 , 231 , - 219 , 59 , - 219 ,
- 219 , - 219 , - 219 , - 219 , 60 , - 219 , 233 , 235 , 236 , - 219 ,
- 219 , 12 , 237 , - 219 , - 219 , 224 , - 219 , - 219 , - 219 , 263 ,
238 , 213 , - 219 , - 219 , - 219 , 270 , - 219 , 242 , 124 , - 1 ,
269 , 276 , 273 , 187 , 187 , - 219 , 187 , 243 , 187 , - 219 ,
244 , 274 , - 219 , 247 , - 219 , 115 , - 219 , 213 , - 219 , - 219 ,
- 219 , 251 , 252 , 257 , 264 , - 219 , - 219 , - 219 , 283 , - 219 ,
- 219 , 284 , - 219 , - 219 , 242 , 286 , 260 , 262 , 285 , 292 ,
124 , 265 , 267 , - 219 , 267 , 172 , 15 , 176 , - 219 , 165 ,
- 219 , - 6 , 290 , 294 , - 219 , - 219 , - 219 , 293 , 277 , 213 ,
12 , - 219 , 129 , - 219 , 295 , 296 , 56 , - 219 , - 219 , - 219 ,
268 , 291 , 298 , 187 , 187 , 187 , 187 , - 219 , - 219 , - 219 ,
- 219 , 213 , - 219 , - 219 , - 219 , 56 , 56 , - 219 , 267 , 267 ,
301 , 301 , 301 , 301 , 271 , - 219 , - 219 , - 219 , 300 , - 219 ,
307 , 267 , - 219 , - 219 , 275 , 309 , 213 , - 219
2006-04-24 17:41:27 +00:00
} ;
/* YYPGOTO[NTERM-NUM]. */
2006-06-18 21:36:24 +00:00
static const yytype_int16 yypgoto [ ] =
2006-04-24 17:41:27 +00:00
{
2007-11-27 18:50:44 +00:00
- 219 , - 219 , - 219 , 310 , - 19 , - 219 , - 219 , - 219 , - 219 , 125 ,
5 , - 219 , - 15 , - 219 , - 219 , - 31 , - 219 , - 219 , - 219 , - 114 ,
- 219 , 154 , 25 , - 219 , - 219 , 143 , 217 , - 218 , - 82 , - 219 ,
- 59 , - 219 , - 219 , - 219 , - 219 , - 219 , - 219 , - 219 , - 219 , - 219 ,
- 219 , - 219 , - 219 , - 219 , - 219 , 108 , 103 , - 219 , 227 , - 219 ,
- 219 , - 219 , - 65 , 209 , - 219 , - 51
2006-04-24 17:41:27 +00:00
} ;
/* YYTABLE[YYPACT[STATE-NUM]]. What to do in state STATE-NUM. If
positive , shift that token . If negative , reduce the rule which
number is the opposite . If zero , do what YYDEFACT says .
If YYTABLE_NINF , syntax error . */
2007-11-27 18:50:44 +00:00
# define YYTABLE_NINF -133
2006-06-18 21:36:24 +00:00
static const yytype_int16 yytable [ ] =
2006-04-24 17:41:27 +00:00
{
2007-11-27 18:50:44 +00:00
96 , 28 , 133 , 111 , 251 , 172 , 252 , 174 , 101 , 62 ,
- 66 , 167 , 22 , 108 , 118 , 168 , - 20 , - 132 , 13 , 25 ,
51 , 64 , 75 , 145 , 112 , 51 , 187 , 25 , 254 , 156 ,
25 , 26 , 65 , 157 , 158 , 144 , 183 , 27 , 51 , 184 ,
50 , 96 , 221 , 160 , 14 , 50 , 155 , 26 , 15 , 101 ,
278 , 279 , 16 , 27 , 23 , 109 , 26 , 119 , 50 , 146 ,
76 , - 49 , 27 , 283 , 77 , 159 , 200 , 203 , 78 , 201 ,
17 , 157 , 158 , 129 , 79 , 80 , 81 , 20 , 82 , 130 ,
194 , 233 , 83 , 84 , 85 , 86 , 87 , 71 , 36 , 88 ,
89 , - 49 , - 49 , - 49 , 37 , 32 , 207 , 38 , 48 , 91 ,
72 , 225 , 226 , 159 , 227 , 126 , 229 , 128 , 29 , 161 ,
1 , 73 , 212 , 21 , 139 , 162 , 119 , 2 , 3 , 76 ,
- 49 , 149 , 150 , 77 , 40 , 4 , 5 , 78 , - 31 , 190 ,
187 , 41 , 267 , 79 , 80 , 81 , 264 , 82 , 234 , 201 ,
42 , 83 , 84 , 85 , 86 , 87 , 32 , 31 , 88 , 89 ,
34 , 276 , 277 , 33 , 43 , 44 , 35 , 48 , 91 , 216 ,
217 , 218 , 45 , 46 , 47 , 48 , 49 , 186 , 187 , 60 ,
188 , 270 , 271 , 272 , 273 , 263 , 187 , 59 , 256 , 61 ,
262 , 76 , 253 , 187 , 63 , 77 , 255 , 187 , 141 , 78 ,
142 , 32 , 66 , 143 , 67 , 79 , 80 , 81 , 68 , 82 ,
69 , 70 , 275 , 83 , 84 , 85 , 86 , 87 , 74 , 102 ,
88 , 89 , 257 , 103 , 104 , 90 , 105 , 76 , 47 , 48 ,
91 , 77 , 106 , 116 , 117 , 78 , 122 , 287 , 124 , 127 ,
130 , 79 , 80 , 81 , 135 , 82 , 136 , 137 , 138 , 83 ,
84 , 85 , 86 , 87 , 151 , 140 , 88 , 89 , 153 , - 2 ,
18 , 163 , - 14 , 164 , 165 , 48 , 91 , 1 , 166 , 171 ,
173 , 176 , 175 , 178 , 2 , 3 , 189 , 179 , 185 , 192 ,
195 , 210 , 4 , 5 , 199 , 197 , 204 , 213 , 205 , 206 ,
208 , 211 , 222 , 223 , 224 , 146 , 228 , 230 , 231 , 239 ,
232 , 240 , 241 , 243 , 235 , 237 , 246 , 247 , 258 , 259 ,
238 , 260 , 261 , 244 , 268 , 245 , 265 , 266 , 249 , 269 ,
250 , 221 , 187 , 281 , 280 , 282 , 286 , 19 , 285 , 209 ,
215 , 154 , 242 , 248 , 169 , 0 , 0 , 152
2006-04-24 17:41:27 +00:00
} ;
2007-11-27 18:50:44 +00:00
static const yytype_int16 yycheck [ ] =
2006-04-24 17:41:27 +00:00
{
2007-11-27 18:50:44 +00:00
59 , 20 , 84 , 68 , 222 , 119 , 224 , 121 , 59 , 40 ,
11 , 1 , 1 , 1 , 73 , 5 , 5 , 5 , 43 , 14 ,
35 , 32 , 53 , 7 , 5 , 40 , 11 , 22 , 13 , 7 ,
25 , 37 , 43 , 11 , 12 , 94 , 10 , 43 , 53 , 13 ,
35 , 100 , 43 , 108 , 4 , 40 , 105 , 37 , 24 , 100 ,
268 , 269 , 23 , 43 , 43 , 43 , 37 , 1 , 53 , 43 ,
4 , 5 , 43 , 281 , 8 , 43 , 7 , 7 , 12 , 10 ,
0 , 11 , 12 , 37 , 18 , 19 , 20 , 3 , 22 , 43 ,
139 , 195 , 26 , 27 , 28 , 29 , 30 , 1 , 1 , 33 ,
34 , 35 , 36 , 37 , 7 , 9 , 161 , 10 , 42 , 43 ,
14 , 183 , 184 , 43 , 186 , 80 , 188 , 82 , 43 , 8 ,
8 , 25 , 171 , 6 , 89 , 14 , 1 , 15 , 16 , 4 ,
5 , 8 , 9 , 8 , 1 , 23 , 24 , 12 , 5 , 10 ,
11 , 8 , 246 , 18 , 19 , 20 , 7 , 22 , 197 , 10 ,
17 , 26 , 27 , 28 , 29 , 30 , 9 , 22 , 33 , 34 ,
25 , 265 , 266 , 5 , 31 , 32 , 4 , 42 , 43 , 35 ,
36 , 37 , 39 , 40 , 41 , 42 , 43 , 10 , 11 , 43 ,
13 , 253 , 254 , 255 , 256 , 240 , 11 , 4 , 13 , 43 ,
239 , 4 , 10 , 11 , 25 , 8 , 10 , 11 , 6 , 12 ,
8 , 9 , 6 , 11 , 4 , 18 , 19 , 20 , 4 , 22 ,
4 , 43 , 261 , 26 , 27 , 28 , 29 , 30 , 5 , 8 ,
33 , 34 , 231 , 43 , 6 , 38 , 25 , 4 , 41 , 42 ,
43 , 8 , 43 , 9 , 43 , 12 , 43 , 286 , 6 , 6 ,
43 , 18 , 19 , 20 , 8 , 22 , 8 , 8 , 6 , 26 ,
27 , 28 , 29 , 30 , 5 , 43 , 33 , 34 , 8 , 0 ,
1 , 5 , 3 , 5 , 13 , 42 , 43 , 8 , 8 , 25 ,
5 , 8 , 6 , 4 , 15 , 16 , 8 , 43 , 43 , 8 ,
4 , 8 , 23 , 24 , 43 , 21 , 43 , 7 , 43 , 43 ,
43 , 43 , 13 , 7 , 11 , 43 , 43 , 43 , 14 , 25 ,
43 , 8 , 8 , 7 , 43 , 43 , 11 , 5 , 8 , 5 ,
43 , 8 , 25 , 43 , 13 , 43 , 11 , 11 , 43 , 11 ,
43 , 43 , 11 , 13 , 43 , 8 , 7 , 7 , 43 , 165 ,
177 , 104 , 214 , 220 , 115 , - 1 , - 1 , 100
2006-04-24 17:41:27 +00:00
} ;
/* YYSTOS[STATE-NUM] -- The (internal number of the) accessing
symbol of state STATE - NUM . */
2006-06-18 21:36:24 +00:00
static const yytype_uint8 yystos [ ] =
2006-04-24 17:41:27 +00:00
{
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
0 , 8 , 15 , 16 , 23 , 24 , 45 , 46 , 47 , 49 ,
50 , 51 , 52 , 43 , 4 , 24 , 23 , 0 , 1 , 47 ,
3 , 6 , 1 , 43 , 53 , 54 , 37 , 43 , 48 , 43 ,
58 , 53 , 9 , 5 , 53 , 4 , 1 , 7 , 10 , 55 ,
1 , 8 , 17 , 31 , 32 , 39 , 40 , 41 , 42 , 43 ,
54 , 56 , 59 , 60 , 61 , 62 , 94 , 95 , 99 , 4 ,
43 , 43 , 59 , 25 , 32 , 43 , 6 , 4 , 4 , 4 ,
2007-11-27 18:50:44 +00:00
43 , 1 , 14 , 25 , 5 , 59 , 4 , 8 , 12 , 18 ,
19 , 20 , 22 , 26 , 27 , 28 , 29 , 30 , 33 , 34 ,
38 , 43 , 54 , 56 , 68 , 73 , 74 , 85 , 87 , 92 ,
93 , 99 , 8 , 43 , 6 , 25 , 43 , 70 , 1 , 43 ,
96 , 96 , 5 , 48 , 97 , 98 , 9 , 43 , 74 , 1 ,
63 , 74 , 43 , 83 , 6 , 66 , 66 , 6 , 66 , 37 ,
43 , 72 , 80 , 72 , 82 , 8 , 8 , 8 , 6 , 66 ,
43 , 6 , 8 , 11 , 74 , 7 , 43 , 69 , 89 , 8 ,
9 , 5 , 92 , 8 , 70 , 74 , 7 , 11 , 12 , 43 ,
96 , 8 , 14 , 5 , 5 , 13 , 8 , 1 , 5 , 97 ,
57 , 25 , 63 , 5 , 63 , 6 , 8 , 67 , 4 , 43 ,
64 , 65 , 71 , 10 , 13 , 43 , 10 , 11 , 13 , 8 ,
10 , 81 , 8 , 75 , 74 , 4 , 86 , 21 , 79 , 43 ,
7 , 10 , 78 , 7 , 43 , 43 , 43 , 96 , 43 , 65 ,
8 , 43 , 74 , 7 , 84 , 69 , 35 , 36 , 37 , 90 ,
91 , 43 , 13 , 7 , 11 , 72 , 72 , 72 , 43 , 72 ,
43 , 14 , 43 , 63 , 74 , 43 , 88 , 43 , 43 , 25 ,
8 , 8 , 89 , 7 , 43 , 43 , 11 , 5 , 90 , 43 ,
43 , 71 , 71 , 10 , 13 , 10 , 13 , 48 , 8 , 5 ,
8 , 25 , 74 , 96 , 7 , 11 , 11 , 63 , 13 , 11 ,
72 , 72 , 72 , 72 , 76 , 74 , 63 , 63 , 71 , 71 ,
43 , 13 , 8 , 71 , 77 , 43 , 7 , 74
2006-04-24 17:41:27 +00:00
} ;
# define yyerrok (yyerrstatus = 0)
# define yyclearin (yychar = YYEMPTY)
# define YYEMPTY (-2)
# define YYEOF 0
# define YYACCEPT goto yyacceptlab
# define YYABORT goto yyabortlab
# define YYERROR goto yyerrorlab
/* Like YYERROR except do call yyerror. This remains here temporarily
to ease the transition to the new meaning of YYERROR , for GCC .
Once GCC version 2 has supplanted version 1 , this can go . */
# define YYFAIL goto yyerrlab
# define YYRECOVERING() (!!yyerrstatus)
# define YYBACKUP(Token, Value) \
do \
if ( yychar = = YYEMPTY & & yylen = = 1 ) \
{ \
yychar = ( Token ) ; \
yylval = ( Value ) ; \
yytoken = YYTRANSLATE ( yychar ) ; \
2006-06-18 21:36:24 +00:00
YYPOPSTACK ( 1 ) ; \
2006-04-24 17:41:27 +00:00
goto yybackup ; \
} \
else \
{ \
yyerror ( & yylloc , parseio , YY_ ( " syntax error: cannot back up " ) ) ; \
YYERROR ; \
} \
2006-06-18 21:36:24 +00:00
while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
# define YYTERROR 1
# define YYERRCODE 256
/* YYLLOC_DEFAULT -- Set CURRENT to span from RHS[1] to RHS[N].
If N is 0 , then set CURRENT to the empty location which ends
the previous symbol : RHS [ 0 ] ( always defined ) . */
# define YYRHSLOC(Rhs, K) ((Rhs)[K])
# ifndef YYLLOC_DEFAULT
# define YYLLOC_DEFAULT(Current, Rhs, N) \
do \
2006-06-18 21:36:24 +00:00
if ( YYID ( N ) ) \
2006-04-24 17:41:27 +00:00
{ \
( Current ) . first_line = YYRHSLOC ( Rhs , 1 ) . first_line ; \
( Current ) . first_column = YYRHSLOC ( Rhs , 1 ) . first_column ; \
( Current ) . last_line = YYRHSLOC ( Rhs , N ) . last_line ; \
( Current ) . last_column = YYRHSLOC ( Rhs , N ) . last_column ; \
} \
else \
{ \
( Current ) . first_line = ( Current ) . last_line = \
YYRHSLOC ( Rhs , 0 ) . last_line ; \
( Current ) . first_column = ( Current ) . last_column = \
YYRHSLOC ( Rhs , 0 ) . last_column ; \
} \
2006-06-18 21:36:24 +00:00
while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
# endif
/* YY_LOCATION_PRINT -- Print the location on the stream.
This macro was not mandated originally : define only if we know
we won ' t break user code : when these are the locations we know . */
# ifndef YY_LOCATION_PRINT
# if YYLTYPE_IS_TRIVIAL
# define YY_LOCATION_PRINT(File, Loc) \
fprintf ( File , " %d.%d-%d.%d " , \
2006-06-18 21:36:24 +00:00
( Loc ) . first_line , ( Loc ) . first_column , \
( Loc ) . last_line , ( Loc ) . last_column )
2006-04-24 17:41:27 +00:00
# else
# define YY_LOCATION_PRINT(File, Loc) ((void) 0)
# endif
# endif
/* YYLEX -- calling `yylex' with the right arguments. */
# ifdef YYLEX_PARAM
# define YYLEX yylex (&yylval, &yylloc, YYLEX_PARAM)
# else
# define YYLEX yylex (&yylval, &yylloc)
# endif
/* Enable debugging if requested. */
# if YYDEBUG
# ifndef YYFPRINTF
# include <stdio.h> /* INFRINGES ON USER NAME SPACE */
# define YYFPRINTF fprintf
# endif
# define YYDPRINTF(Args) \
do { \
if ( yydebug ) \
YYFPRINTF Args ; \
2006-06-18 21:36:24 +00:00
} while ( YYID ( 0 ) )
# define YY_SYMBOL_PRINT(Title, Type, Value, Location) \
do { \
if ( yydebug ) \
{ \
YYFPRINTF ( stderr , " %s " , Title ) ; \
yy_symbol_print ( stderr , \
Type , Value , Location , parseio ) ; \
YYFPRINTF ( stderr , " \n " ) ; \
} \
} while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
/*--------------------------------.
| Print this symbol on YYOUTPUT . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
/*ARGSUSED*/
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
static void
2007-08-23 23:37:33 +00:00
yy_symbol_value_print ( FILE * yyoutput , int yytype , const YYSTYPE * const yyvaluep , const YYLTYPE * const yylocationp , struct parse_io * parseio )
2006-06-18 21:36:24 +00:00
# else
static void
yy_symbol_value_print ( yyoutput , yytype , yyvaluep , yylocationp , parseio )
FILE * yyoutput ;
int yytype ;
2007-08-23 23:37:33 +00:00
const YYSTYPE * const yyvaluep ;
const YYLTYPE * const yylocationp ;
2006-06-18 21:36:24 +00:00
struct parse_io * parseio ;
# endif
{
if ( ! yyvaluep )
return ;
YYUSE ( yylocationp ) ;
YYUSE ( parseio ) ;
# ifdef YYPRINT
if ( yytype < YYNTOKENS )
YYPRINT ( yyoutput , yytoknum [ yytype ] , * yyvaluep ) ;
# else
YYUSE ( yyoutput ) ;
# endif
switch ( yytype )
{
default :
break ;
}
}
/*--------------------------------.
| Print this symbol on YYOUTPUT . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
static void
2007-08-23 23:37:33 +00:00
yy_symbol_print ( FILE * yyoutput , int yytype , const YYSTYPE * const yyvaluep , const YYLTYPE * const yylocationp , struct parse_io * parseio )
2006-06-18 21:36:24 +00:00
# else
static void
yy_symbol_print ( yyoutput , yytype , yyvaluep , yylocationp , parseio )
FILE * yyoutput ;
int yytype ;
2007-08-23 23:37:33 +00:00
const YYSTYPE * const yyvaluep ;
const YYLTYPE * const yylocationp ;
2006-06-18 21:36:24 +00:00
struct parse_io * parseio ;
# endif
{
if ( yytype < YYNTOKENS )
YYFPRINTF ( yyoutput , " token %s ( " , yytname [ yytype ] ) ;
else
YYFPRINTF ( yyoutput , " nterm %s ( " , yytname [ yytype ] ) ;
YY_LOCATION_PRINT ( yyoutput , * yylocationp ) ;
YYFPRINTF ( yyoutput , " : " ) ;
yy_symbol_value_print ( yyoutput , yytype , yyvaluep , yylocationp , parseio ) ;
YYFPRINTF ( yyoutput , " ) " ) ;
}
2006-04-24 17:41:27 +00:00
/*------------------------------------------------------------------.
| yy_stack_print - - Print the state stack from its BOTTOM up to its |
| TOP ( included ) . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
static void
2006-06-18 21:36:24 +00:00
yy_stack_print ( yytype_int16 * bottom , yytype_int16 * top )
2006-04-24 17:41:27 +00:00
# else
static void
yy_stack_print ( bottom , top )
2006-06-18 21:36:24 +00:00
yytype_int16 * bottom ;
yytype_int16 * top ;
2006-04-24 17:41:27 +00:00
# endif
{
YYFPRINTF ( stderr , " Stack now " ) ;
2006-06-18 21:36:24 +00:00
for ( ; bottom < = top ; + + bottom )
2006-04-24 17:41:27 +00:00
YYFPRINTF ( stderr , " %d " , * bottom ) ;
YYFPRINTF ( stderr , " \n " ) ;
}
# define YY_STACK_PRINT(Bottom, Top) \
do { \
if ( yydebug ) \
yy_stack_print ( ( Bottom ) , ( Top ) ) ; \
2006-06-18 21:36:24 +00:00
} while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
/*------------------------------------------------.
| Report that the YYRULE is going to be reduced . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
static void
2006-06-18 21:36:24 +00:00
yy_reduce_print ( YYSTYPE * yyvsp , YYLTYPE * yylsp , int yyrule , struct parse_io * parseio )
2006-04-24 17:41:27 +00:00
# else
static void
2006-06-18 21:36:24 +00:00
yy_reduce_print ( yyvsp , yylsp , yyrule , parseio )
YYSTYPE * yyvsp ;
YYLTYPE * yylsp ;
2006-04-24 17:41:27 +00:00
int yyrule ;
2006-06-18 21:36:24 +00:00
struct parse_io * parseio ;
2006-04-24 17:41:27 +00:00
# endif
{
2006-06-18 21:36:24 +00:00
int yynrhs = yyr2 [ yyrule ] ;
2006-04-24 17:41:27 +00:00
int yyi ;
unsigned long int yylno = yyrline [ yyrule ] ;
2006-06-18 21:36:24 +00:00
YYFPRINTF ( stderr , " Reducing stack by rule %d (line %lu): \n " ,
yyrule - 1 , yylno ) ;
/* The symbols being reduced. */
for ( yyi = 0 ; yyi < yynrhs ; yyi + + )
{
fprintf ( stderr , " $%d = " , yyi + 1 ) ;
yy_symbol_print ( stderr , yyrhs [ yyprhs [ yyrule ] + yyi ] ,
& ( yyvsp [ ( yyi + 1 ) - ( yynrhs ) ] )
, & ( yylsp [ ( yyi + 1 ) - ( yynrhs ) ] ) , parseio ) ;
fprintf ( stderr , " \n " ) ;
}
2006-04-24 17:41:27 +00:00
}
# define YY_REDUCE_PRINT(Rule) \
do { \
if ( yydebug ) \
2006-06-18 21:36:24 +00:00
yy_reduce_print ( yyvsp , yylsp , Rule , parseio ) ; \
} while ( YYID ( 0 ) )
2006-04-24 17:41:27 +00:00
/* Nonzero means print parse trace. It is left uninitialized so that
multiple parsers can coexist . */
int yydebug ;
# else /* !YYDEBUG */
# define YYDPRINTF(Args)
# define YY_SYMBOL_PRINT(Title, Type, Value, Location)
# define YY_STACK_PRINT(Bottom, Top)
# define YY_REDUCE_PRINT(Rule)
# endif /* !YYDEBUG */
/* YYINITDEPTH -- initial size of the parser's stacks. */
# ifndef YYINITDEPTH
# define YYINITDEPTH 200
# endif
/* YYMAXDEPTH -- maximum size the stacks can grow to (effective only
if the built - in stack extension method is used ) .
Do not make this value too large ; the results are undefined if
YYSTACK_ALLOC_MAXIMUM < YYSTACK_BYTES ( YYMAXDEPTH )
evaluated with infinite - precision integer arithmetic . */
# ifndef YYMAXDEPTH
# define YYMAXDEPTH 10000
# endif
# if YYERROR_VERBOSE
# ifndef yystrlen
2006-06-18 21:36:24 +00:00
# if defined __GLIBC__ && defined _STRING_H
2006-04-24 17:41:27 +00:00
# define yystrlen strlen
# else
/* Return the length of YYSTR. */
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
static YYSIZE_T
yystrlen ( const char * yystr )
2006-06-18 21:36:24 +00:00
# else
static YYSIZE_T
2006-04-24 17:41:27 +00:00
yystrlen ( yystr )
2006-06-18 21:36:24 +00:00
const char * yystr ;
# endif
2006-04-24 17:41:27 +00:00
{
2006-06-18 21:36:24 +00:00
YYSIZE_T yylen ;
for ( yylen = 0 ; yystr [ yylen ] ; yylen + + )
2006-04-24 17:41:27 +00:00
continue ;
2006-06-18 21:36:24 +00:00
return yylen ;
2006-04-24 17:41:27 +00:00
}
# endif
# endif
# ifndef yystpcpy
2006-06-18 21:36:24 +00:00
# if defined __GLIBC__ && defined _STRING_H && defined _GNU_SOURCE
2006-04-24 17:41:27 +00:00
# define yystpcpy stpcpy
# else
/* Copy YYSRC to YYDEST, returning the address of the terminating '\0' in
YYDEST . */
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
static char *
yystpcpy ( char * yydest , const char * yysrc )
2006-06-18 21:36:24 +00:00
# else
static char *
2006-04-24 17:41:27 +00:00
yystpcpy ( yydest , yysrc )
2006-06-18 21:36:24 +00:00
char * yydest ;
const char * yysrc ;
# endif
2006-04-24 17:41:27 +00:00
{
char * yyd = yydest ;
const char * yys = yysrc ;
while ( ( * yyd + + = * yys + + ) ! = ' \0 ' )
continue ;
return yyd - 1 ;
}
# endif
# endif
# ifndef yytnamerr
/* Copy to YYRES the contents of YYSTR after stripping away unnecessary
quotes and backslashes , so that it ' s suitable for yyerror . The
heuristic is that double - quoting is unnecessary unless the string
contains an apostrophe , a comma , or backslash ( other than
backslash - backslash ) . YYSTR is taken from yytname . If YYRES is
null , do not copy ; instead , return the length of what the result
would have been . */
static YYSIZE_T
yytnamerr ( char * yyres , const char * yystr )
{
if ( * yystr = = ' " ' )
{
2007-08-23 23:37:33 +00:00
size_t yyn = 0 ;
2006-04-24 17:41:27 +00:00
char const * yyp = yystr ;
for ( ; ; )
switch ( * + + yyp )
{
case ' \' ' :
case ' , ' :
goto do_not_strip_quotes ;
case ' \\ ' :
if ( * + + yyp ! = ' \\ ' )
goto do_not_strip_quotes ;
/* Fall through. */
default :
if ( yyres )
yyres [ yyn ] = * yyp ;
yyn + + ;
break ;
case ' " ' :
if ( yyres )
yyres [ yyn ] = ' \0 ' ;
return yyn ;
}
do_not_strip_quotes : ;
}
if ( ! yyres )
return yystrlen ( yystr ) ;
return yystpcpy ( yyres , yystr ) - yyres ;
}
# endif
2006-06-18 21:36:24 +00:00
/* Copy into YYRESULT an error message about the unexpected token
YYCHAR while in state YYSTATE . Return the number of bytes copied ,
including the terminating null byte . If YYRESULT is null , do not
copy anything ; just return the number of bytes that would be
copied . As a special case , return 0 if an ordinary " syntax error "
message will do . Return YYSIZE_MAXIMUM if overflow occurs during
size calculation . */
static YYSIZE_T
yysyntax_error ( char * yyresult , int yystate , int yychar )
2006-04-24 17:41:27 +00:00
{
2006-06-18 21:36:24 +00:00
int yyn = yypact [ yystate ] ;
2006-04-24 17:41:27 +00:00
2007-08-23 23:37:33 +00:00
if ( ! ( YYPACT_NINF < yyn & & yyn < YYLAST ) )
2006-06-18 21:36:24 +00:00
return 0 ;
2006-04-24 17:41:27 +00:00
else
2006-06-18 21:36:24 +00:00
{
int yytype = YYTRANSLATE ( yychar ) ;
YYSIZE_T yysize0 = yytnamerr ( 0 , yytname [ yytype ] ) ;
YYSIZE_T yysize = yysize0 ;
YYSIZE_T yysize1 ;
int yysize_overflow = 0 ;
enum { YYERROR_VERBOSE_ARGS_MAXIMUM = 5 } ;
char const * yyarg [ YYERROR_VERBOSE_ARGS_MAXIMUM ] ;
int yyx ;
# if 0
/* This is so xgettext sees the translatable formats that are
constructed on the fly . */
YY_ ( " syntax error, unexpected %s " ) ;
YY_ ( " syntax error, unexpected %s, expecting %s " ) ;
YY_ ( " syntax error, unexpected %s, expecting %s or %s " ) ;
YY_ ( " syntax error, unexpected %s, expecting %s or %s or %s " ) ;
YY_ ( " syntax error, unexpected %s, expecting %s or %s or %s or %s " ) ;
# endif
char * yyfmt ;
char const * yyf ;
static char const yyunexpected [ ] = " syntax error, unexpected %s " ;
static char const yyexpecting [ ] = " , expecting %s " ;
static char const yyor [ ] = " or %s " ;
char yyformat [ sizeof yyunexpected
+ sizeof yyexpecting - 1
+ ( ( YYERROR_VERBOSE_ARGS_MAXIMUM - 2 )
* ( sizeof yyor - 1 ) ) ] ;
char const * yyprefix = yyexpecting ;
/* Start YYX at -YYN if negative to avoid negative indexes in
YYCHECK . */
int yyxbegin = yyn < 0 ? - yyn : 0 ;
/* Stay within bounds of both yycheck and yytname. */
2007-08-23 23:37:33 +00:00
int yychecklim = YYLAST - yyn ;
2006-06-18 21:36:24 +00:00
int yyxend = yychecklim < YYNTOKENS ? yychecklim : YYNTOKENS ;
int yycount = 1 ;
yyarg [ 0 ] = yytname [ yytype ] ;
yyfmt = yystpcpy ( yyformat , yyunexpected ) ;
for ( yyx = yyxbegin ; yyx < yyxend ; + + yyx )
if ( yycheck [ yyx + yyn ] = = yyx & & yyx ! = YYTERROR )
{
if ( yycount = = YYERROR_VERBOSE_ARGS_MAXIMUM )
{
yycount = 1 ;
yysize = yysize0 ;
yyformat [ sizeof yyunexpected - 1 ] = ' \0 ' ;
break ;
}
yyarg [ yycount + + ] = yytname [ yyx ] ;
yysize1 = yysize + yytnamerr ( 0 , yytname [ yyx ] ) ;
yysize_overflow | = ( yysize1 < yysize ) ;
yysize = yysize1 ;
yyfmt = yystpcpy ( yyfmt , yyprefix ) ;
yyprefix = yyor ;
}
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
yyf = YY_ ( yyformat ) ;
yysize1 = yysize + yystrlen ( yyf ) ;
yysize_overflow | = ( yysize1 < yysize ) ;
yysize = yysize1 ;
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
if ( yysize_overflow )
return YYSIZE_MAXIMUM ;
if ( yyresult )
{
/* Avoid sprintf, as that infringes on the user's name space.
Don ' t have undefined behavior even if the translation
produced a string with the wrong number of " %s " s . */
char * yyp = yyresult ;
int yyi = 0 ;
while ( ( * yyp = * yyf ) ! = ' \0 ' )
{
if ( * yyp = = ' % ' & & yyf [ 1 ] = = ' s ' & & yyi < yycount )
{
yyp + = yytnamerr ( yyp , yyarg [ yyi + + ] ) ;
yyf + = 2 ;
}
else
{
yyp + + ;
yyf + + ;
}
}
}
return yysize ;
2006-04-24 17:41:27 +00:00
}
}
2006-06-18 21:36:24 +00:00
# endif /* YYERROR_VERBOSE */
2006-04-24 17:41:27 +00:00
/*-----------------------------------------------.
| Release the memory associated to this symbol . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
2006-06-18 21:36:24 +00:00
/*ARGSUSED*/
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
static void
2006-06-18 21:36:24 +00:00
yydestruct ( const char * yymsg , int yytype , YYSTYPE * yyvaluep , YYLTYPE * yylocationp , struct parse_io * parseio )
2006-04-24 17:41:27 +00:00
# else
static void
2006-06-18 21:36:24 +00:00
yydestruct ( yymsg , yytype , yyvaluep , yylocationp , parseio )
2006-04-24 17:41:27 +00:00
const char * yymsg ;
int yytype ;
YYSTYPE * yyvaluep ;
YYLTYPE * yylocationp ;
2006-06-18 21:36:24 +00:00
struct parse_io * parseio ;
2006-04-24 17:41:27 +00:00
# endif
{
2006-06-18 21:36:24 +00:00
YYUSE ( yyvaluep ) ;
YYUSE ( yylocationp ) ;
YYUSE ( parseio ) ;
2006-04-24 17:41:27 +00:00
if ( ! yymsg )
yymsg = " Deleting " ;
YY_SYMBOL_PRINT ( yymsg , yytype , yyvaluep , yylocationp ) ;
switch ( yytype )
{
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 43 : /* "word" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 180 "ael.y"
2006-06-18 21:36:24 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1458 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 46 : /* "objects" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1466 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 47 : /* "object" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1474 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 48 : /* "context_name" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 180 "ael.y"
2006-06-18 21:36:24 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1479 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 49 : /* "context" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1487 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 51 : /* "macro" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1495 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 52 : /* "globals" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1503 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 53 : /* "global_statements" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1511 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 54 : /* "assignment" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1519 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 56 : /* "local_assignment" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-30 12:30:08 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1527 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 58 : /* "arglist" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1535 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 59 : /* "elements" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1543 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 60 : /* "element" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1551 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 61 : /* "ignorepat" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1559 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 62 : /* "extension" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1567 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 63 : /* "statements" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1575 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 64 : /* "timerange" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 180 "ael.y"
2006-06-18 21:36:24 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1580 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 65 : /* "timespec" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-05-02 18:33:15 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1588 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 66 : /* "test_expr" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 180 "ael.y"
2006-06-18 21:36:24 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1593 "ael.tab.c"
2007-06-20 20:10:19 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 68 : /* "if_like_head" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2007-06-20 20:10:19 +00:00
{
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1601 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 69 : /* "word_list" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 180 "ael.y"
2006-06-18 21:36:24 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1606 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 71 : /* "word3_list" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 180 "ael.y"
2007-06-20 20:10:19 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1611 "ael.tab.c"
2007-06-20 20:10:19 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 72 : /* "goto_word" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 180 "ael.y"
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1616 "ael.tab.c"
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
break ;
case 73 : /* "switch_statement" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-05-02 18:23:41 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1624 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 74 : /* "statement" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1632 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 79 : /* "opt_else" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1640 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 80 : /* "target" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1648 "ael.tab.c"
2006-08-12 19:28:33 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 81 : /* "opt_pri" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 180 "ael.y"
2006-08-12 19:28:33 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1653 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 82 : /* "jumptarget" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1661 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 83 : /* "macro_call" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1669 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 85 : /* "application_call_head" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1677 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 87 : /* "application_call" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1685 "ael.tab.c"
2006-08-12 19:28:33 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 88 : /* "opt_word" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 180 "ael.y"
2006-08-12 19:28:33 +00:00
{ free ( ( yyvaluep - > str ) ) ; } ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1690 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 89 : /* "eval_arglist" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-05-03 16:12:31 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1698 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 90 : /* "case_statements" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-05-03 16:12:31 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1706 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 91 : /* "case_statement" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1714 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 92 : /* "macro_statements" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-30 12:44:54 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1722 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 93 : /* "macro_statement" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1730 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 94 : /* "switches" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1738 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 95 : /* "eswitches" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1746 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 96 : /* "switchlist" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1754 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 97 : /* "included_entry" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1762 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 98 : /* "includeslist" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-06-18 21:36:24 +00:00
{
2006-04-27 21:09:52 +00:00
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
2006-04-27 19:51:59 +00:00
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1770 "ael.tab.c"
2006-06-18 21:36:24 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 99 : /* "includes" */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 167 "ael.y"
2006-08-12 19:28:33 +00:00
{
destroy_pval ( ( yyvaluep - > pval ) ) ;
prev_word = 0 ;
} ;
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 1778 "ael.tab.c"
2006-08-12 19:28:33 +00:00
break ;
2006-04-24 17:41:27 +00:00
default :
2006-06-18 21:36:24 +00:00
break ;
2006-04-24 17:41:27 +00:00
}
}
/* Prevent warnings from -Wmissing-prototypes. */
# ifdef YYPARSE_PARAM
2006-06-18 21:36:24 +00:00
# if defined __STDC__ || defined __cplusplus
2006-04-24 17:41:27 +00:00
int yyparse ( void * YYPARSE_PARAM ) ;
2006-06-18 21:36:24 +00:00
# else
2006-04-24 17:41:27 +00:00
int yyparse ( ) ;
2006-06-18 21:36:24 +00:00
# endif
2006-04-24 17:41:27 +00:00
# else /* ! YYPARSE_PARAM */
2006-06-18 21:36:24 +00:00
# if defined __STDC__ || defined __cplusplus
2006-04-24 17:41:27 +00:00
int yyparse ( struct parse_io * parseio ) ;
# else
int yyparse ( ) ;
# endif
# endif /* ! YYPARSE_PARAM */
/*----------.
| yyparse . |
` - - - - - - - - - - */
# ifdef YYPARSE_PARAM
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
int
yyparse ( void * YYPARSE_PARAM )
# else
int
yyparse ( YYPARSE_PARAM )
void * YYPARSE_PARAM ;
# endif
2006-04-24 17:41:27 +00:00
# else /* ! YYPARSE_PARAM */
2006-06-18 21:36:24 +00:00
# if (defined __STDC__ || defined __C99__FUNC__ \
| | defined __cplusplus | | defined _MSC_VER )
2006-04-24 17:41:27 +00:00
int
yyparse ( struct parse_io * parseio )
# else
int
yyparse ( parseio )
struct parse_io * parseio ;
# endif
# endif
{
/* The look-ahead symbol. */
int yychar ;
/* The semantic value of the look-ahead symbol. */
YYSTYPE yylval ;
/* Number of syntax errors so far. */
int yynerrs ;
/* Location data for the look-ahead symbol. */
YYLTYPE yylloc ;
int yystate ;
int yyn ;
int yyresult ;
/* Number of tokens to shift before error messages enabled. */
int yyerrstatus ;
/* Look-ahead token as an internal (translated) token number. */
int yytoken = 0 ;
2006-06-18 21:36:24 +00:00
# if YYERROR_VERBOSE
/* Buffer for error messages, and its allocated size. */
char yymsgbuf [ 128 ] ;
char * yymsg = yymsgbuf ;
YYSIZE_T yymsg_alloc = sizeof yymsgbuf ;
# endif
2006-04-24 17:41:27 +00:00
/* Three stacks and their tools:
` yyss ' : related to states ,
` yyvs ' : related to semantic values ,
` yyls ' : related to locations .
Refer to the stacks thru separate pointers , to allow yyoverflow
to reallocate them elsewhere . */
/* The state stack. */
2006-06-18 21:36:24 +00:00
yytype_int16 yyssa [ YYINITDEPTH ] ;
yytype_int16 * yyss = yyssa ;
yytype_int16 * yyssp ;
2006-04-24 17:41:27 +00:00
/* The semantic value stack. */
YYSTYPE yyvsa [ YYINITDEPTH ] ;
YYSTYPE * yyvs = yyvsa ;
YYSTYPE * yyvsp ;
/* The location stack. */
YYLTYPE yylsa [ YYINITDEPTH ] ;
YYLTYPE * yyls = yylsa ;
YYLTYPE * yylsp ;
2006-06-18 21:36:24 +00:00
/* The locations where the error started and ended. */
2006-04-24 17:41:27 +00:00
YYLTYPE yyerror_range [ 2 ] ;
2006-06-18 21:36:24 +00:00
# define YYPOPSTACK(N) (yyvsp -= (N), yyssp -= (N), yylsp -= (N))
2006-04-24 17:41:27 +00:00
YYSIZE_T yystacksize = YYINITDEPTH ;
/* The variables used to return semantic value and location from the
action routines . */
YYSTYPE yyval ;
YYLTYPE yyloc ;
2006-06-18 21:36:24 +00:00
/* The number of symbols on the RHS of the reduced rule.
Keep to zero when no symbol should be popped . */
int yylen = 0 ;
2006-04-24 17:41:27 +00:00
YYDPRINTF ( ( stderr , " Starting parse \n " ) ) ;
yystate = 0 ;
yyerrstatus = 0 ;
yynerrs = 0 ;
yychar = YYEMPTY ; /* Cause a token to be read. */
/* Initialize stack pointers.
Waste one element of value and location stack
so that they stay on the same level as the state stack .
The wasted elements are never initialized . */
yyssp = yyss ;
yyvsp = yyvs ;
yylsp = yyls ;
# if YYLTYPE_IS_TRIVIAL
/* Initialize the default location before parsing starts. */
yylloc . first_line = yylloc . last_line = 1 ;
yylloc . first_column = yylloc . last_column = 0 ;
# endif
goto yysetstate ;
/*------------------------------------------------------------.
| yynewstate - - Push a new state , which is found in yystate . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yynewstate :
/* In all cases, when you get here, the value and location stacks
2006-06-18 21:36:24 +00:00
have just been pushed . So pushing a state here evens the stacks . */
2006-04-24 17:41:27 +00:00
yyssp + + ;
yysetstate :
* yyssp = yystate ;
if ( yyss + yystacksize - 1 < = yyssp )
{
/* Get the current used size of the three stacks, in elements. */
YYSIZE_T yysize = yyssp - yyss + 1 ;
# ifdef yyoverflow
{
2006-06-18 21:36:24 +00:00
/* Give user a chance to reallocate the stack. Use copies of
2006-04-24 17:41:27 +00:00
these so that the & ' s don ' t force the real ones into
memory . */
YYSTYPE * yyvs1 = yyvs ;
2006-06-18 21:36:24 +00:00
yytype_int16 * yyss1 = yyss ;
2006-04-24 17:41:27 +00:00
YYLTYPE * yyls1 = yyls ;
/* Each stack pointer address is followed by the size of the
data in use in that stack , in bytes . This used to be a
conditional around just the two extra args , but that might
be undefined if yyoverflow is a macro . */
yyoverflow ( YY_ ( " memory exhausted " ) ,
& yyss1 , yysize * sizeof ( * yyssp ) ,
& yyvs1 , yysize * sizeof ( * yyvsp ) ,
& yyls1 , yysize * sizeof ( * yylsp ) ,
& yystacksize ) ;
yyls = yyls1 ;
yyss = yyss1 ;
yyvs = yyvs1 ;
}
# else /* no yyoverflow */
# ifndef YYSTACK_RELOCATE
goto yyexhaustedlab ;
# else
/* Extend the stack our own way. */
if ( YYMAXDEPTH < = yystacksize )
goto yyexhaustedlab ;
yystacksize * = 2 ;
if ( YYMAXDEPTH < yystacksize )
yystacksize = YYMAXDEPTH ;
{
2006-06-18 21:36:24 +00:00
yytype_int16 * yyss1 = yyss ;
2006-04-24 17:41:27 +00:00
union yyalloc * yyptr =
( union yyalloc * ) YYSTACK_ALLOC ( YYSTACK_BYTES ( yystacksize ) ) ;
if ( ! yyptr )
goto yyexhaustedlab ;
YYSTACK_RELOCATE ( yyss ) ;
YYSTACK_RELOCATE ( yyvs ) ;
YYSTACK_RELOCATE ( yyls ) ;
# undef YYSTACK_RELOCATE
if ( yyss1 ! = yyssa )
YYSTACK_FREE ( yyss1 ) ;
}
# endif
# endif /* no yyoverflow */
yyssp = yyss + yysize - 1 ;
yyvsp = yyvs + yysize - 1 ;
yylsp = yyls + yysize - 1 ;
YYDPRINTF ( ( stderr , " Stack size increased to %lu \n " ,
( unsigned long int ) yystacksize ) ) ;
if ( yyss + yystacksize - 1 < = yyssp )
YYABORT ;
}
YYDPRINTF ( ( stderr , " Entering state %d \n " , yystate ) ) ;
goto yybackup ;
/*-----------.
| yybackup . |
` - - - - - - - - - - - */
yybackup :
2006-06-18 21:36:24 +00:00
/* Do appropriate processing given the current state. Read a
look - ahead token if we need one and don ' t already have one . */
2006-04-24 17:41:27 +00:00
/* First try to decide what to do without reference to look-ahead token. */
yyn = yypact [ yystate ] ;
if ( yyn = = YYPACT_NINF )
goto yydefault ;
/* Not known => get a look-ahead token if don't already have one. */
/* YYCHAR is either YYEMPTY or YYEOF or a valid look-ahead symbol. */
if ( yychar = = YYEMPTY )
{
YYDPRINTF ( ( stderr , " Reading a token: " ) ) ;
yychar = YYLEX ;
}
if ( yychar < = YYEOF )
{
yychar = yytoken = YYEOF ;
YYDPRINTF ( ( stderr , " Now at end of input. \n " ) ) ;
}
else
{
yytoken = YYTRANSLATE ( yychar ) ;
YY_SYMBOL_PRINT ( " Next token is " , yytoken , & yylval , & yylloc ) ;
}
/* If the proper action on seeing token YYTOKEN is to reduce or to
detect an error , take that action . */
yyn + = yytoken ;
if ( yyn < 0 | | YYLAST < yyn | | yycheck [ yyn ] ! = yytoken )
goto yydefault ;
yyn = yytable [ yyn ] ;
if ( yyn < = 0 )
{
if ( yyn = = 0 | | yyn = = YYTABLE_NINF )
goto yyerrlab ;
yyn = - yyn ;
goto yyreduce ;
}
if ( yyn = = YYFINAL )
YYACCEPT ;
2006-06-18 21:36:24 +00:00
/* Count tokens shifted since error; after three, turn off error
status . */
if ( yyerrstatus )
yyerrstatus - - ;
2006-04-24 17:41:27 +00:00
/* Shift the look-ahead token. */
YY_SYMBOL_PRINT ( " Shifting " , yytoken , & yylval , & yylloc ) ;
2006-06-18 21:36:24 +00:00
/* Discard the shifted token unless it is eof. */
2006-04-24 17:41:27 +00:00
if ( yychar ! = YYEOF )
yychar = YYEMPTY ;
2006-06-18 21:36:24 +00:00
yystate = yyn ;
2006-04-24 17:41:27 +00:00
* + + yyvsp = yylval ;
* + + yylsp = yylloc ;
goto yynewstate ;
/*-----------------------------------------------------------.
| yydefault - - do the default action for the current state . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yydefault :
yyn = yydefact [ yystate ] ;
if ( yyn = = 0 )
goto yyerrlab ;
goto yyreduce ;
/*-----------------------------.
| yyreduce - - Do a reduction . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyreduce :
/* yyn is the number of a rule to reduce with. */
yylen = yyr2 [ yyn ] ;
/* If YYLEN is nonzero, implement the default value of the action:
` $ $ = $ 1 ' .
Otherwise , the following line sets YYVAL to garbage .
This behavior is undocumented and Bison
users should not rely upon it . Assigning to YYVAL
unconditionally makes the parser a bit smaller , and it avoids a
GCC warning that YYVAL may be used uninitialized . */
yyval = yyvsp [ 1 - yylen ] ;
2006-06-18 21:36:24 +00:00
/* Default location. */
YYLLOC_DEFAULT ( yyloc , ( yylsp - yylen ) , yylen ) ;
2006-04-24 17:41:27 +00:00
YY_REDUCE_PRINT ( yyn ) ;
switch ( yyn )
{
case 2 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 188 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = parseio - > pval = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 3 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 191 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 4 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 192 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 5 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 193 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 6 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 196 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 7 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 197 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 8 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 198 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 9 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 199 "ael.y"
2006-04-24 17:41:27 +00:00
{ ( yyval . pval ) = 0 ; /* allow older docs to be read */ ; }
break ;
case 10 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 202 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 11 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 203 "ael.y"
2006-04-30 08:21:46 +00:00
{ ( yyval . str ) = strdup ( " default " ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
case 12 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 206 "ael.y"
2006-04-27 02:00:35 +00:00
{
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
( yyval . pval ) = npval2 ( PV_CONTEXT , & ( yylsp [ ( 1 ) - ( 6 ) ] ) , & ( yylsp [ ( 6 ) - ( 6 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 3 ) - ( 6 ) ] . str ) ;
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 5 ) - ( 6 ) ] . pval ) ;
set_dads ( ( yyval . pval ) , ( yyvsp [ ( 5 ) - ( 6 ) ] . pval ) ) ;
( yyval . pval ) - > u3 . abstract = ( yyvsp [ ( 1 ) - ( 6 ) ] . intval ) ; ; }
2006-04-30 12:44:54 +00:00
break ;
case 13 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 215 "ael.y"
2006-04-30 12:44:54 +00:00
{ ( yyval . intval ) = 1 ; ; }
2006-04-24 17:41:27 +00:00
break ;
2006-04-30 12:30:08 +00:00
case 14 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 216 "ael.y"
2006-04-30 12:44:54 +00:00
{ ( yyval . intval ) = 0 ; ; }
break ;
case 15 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 217 "ael.y"
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
{ ( yyval . intval ) = 2 ; ; }
break ;
case 16 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 218 "ael.y"
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
{ ( yyval . intval ) = 3 ; ; }
break ;
case 17 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 219 "ael.y"
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
{ ( yyval . intval ) = 3 ; ; }
break ;
case 18 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 222 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_MACRO , & ( yylsp [ ( 1 ) - ( 8 ) ] ) , & ( yylsp [ ( 8 ) - ( 8 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 8 ) ] . str ) ; ( yyval . pval ) - > u2 . arglist = ( yyvsp [ ( 4 ) - ( 8 ) ] . pval ) ; ( yyval . pval ) - > u3 . macro_statements = ( yyvsp [ ( 7 ) - ( 8 ) ] . pval ) ;
set_dads ( ( yyval . pval ) , ( yyvsp [ ( 7 ) - ( 8 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 19 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 228 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_GLOBALS , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . statements = ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ;
set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 20 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 234 "ael.y"
2006-05-03 16:28:48 +00:00
{ ( yyval . pval ) = NULL ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 21 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 235 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 22 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 236 "ael.y"
2007-08-23 23:37:33 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 23 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 239 "ael.y"
2006-05-02 18:48:47 +00:00
{ reset_semicount ( parseio - > scanner ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 24 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 239 "ael.y"
2006-05-02 18:48:47 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_VARDEC , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ;
( yyval . pval ) - > u2 . val = ( yyvsp [ ( 4 ) - ( 5 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 25 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 245 "ael.y"
2007-06-20 20:10:19 +00:00
{ reset_semicount ( parseio - > scanner ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 26 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 245 "ael.y"
2007-06-20 20:10:19 +00:00
{
( yyval . pval ) = npval2 ( PV_LOCALVARDEC , & ( yylsp [ ( 1 ) - ( 6 ) ] ) , & ( yylsp [ ( 6 ) - ( 6 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 6 ) ] . str ) ;
( yyval . pval ) - > u2 . val = ( yyvsp [ ( 5 ) - ( 6 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 27 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 252 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = NULL ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 28 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 253 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 1 ) ] ) ) ; ; }
2006-05-02 18:51:33 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 29 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 254 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 3 ) ] . pval ) , nword ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ) ; ; }
2006-05-03 16:28:48 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 30 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 255 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 31 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 258 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = 0 ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 32 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 259 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-30 12:30:08 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 33 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 260 "ael.y"
2007-08-23 23:37:33 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ; ; }
2006-04-30 12:30:08 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 34 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 263 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 35 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 264 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 36 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 265 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 37 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 266 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 38 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 267 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 39 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 268 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 40 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 269 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 41 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 270 "ael.y"
2007-06-20 20:10:19 +00:00
{ free ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ) ; ( yyval . pval ) = 0 ; ; }
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 42 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 271 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = 0 ; /* allow older docs to be read */ ; }
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 43 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 274 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_IGNOREPAT , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 3 ) - ( 4 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 44 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 279 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_EXTENSION , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
Merged revisions 87168 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87168 | murf | 2007-10-26 10:34:02 -0600 (Fri, 26 Oct 2007) | 1 line
closes issue #11086 where a user complains that references to following contexts report a problem; The problem was REALLy that he was referring to empty contexts, which were being ignored. Reporter stated that empty contexts should be OK. I checked it out against extensions.conf, and sure enough, empty contexts ARE ok. So, I removed the restriction from AEL. This, though, highlighted a problem with multiple contexts of the same name. This should be OK, also. So, I added the extend keyword to AEL, and it can preceed the 'context' keyword (mixed with 'abstract', if nec.). This will turn off the warnings in AEL if the same context name is used 2 or more times. Also, I now call ast_context_find_or_create for contexts now, instead of just ast_context_create; I did this because pbx_config does this. The 'extend' keyword thus becomes a statement of intent. AEL can now duplicate the behavior of pbx_config,
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87187 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-26 17:39:39 +00:00
case 45 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 283 "ael.y"
2007-11-27 18:50:44 +00:00
{
( yyval . pval ) = npval2 ( PV_EXTENSION , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 3 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u1 . str = malloc ( strlen ( ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ) + strlen ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) ) + 2 ) ;
strcpy ( ( yyval . pval ) - > u1 . str , ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ) ;
strcat ( ( yyval . pval ) - > u1 . str , " @ " ) ;
strcat ( ( yyval . pval ) - > u1 . str , ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ) ;
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 5 ) - ( 5 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 5 ) - ( 5 ) ] . pval ) ) ; ; }
break ;
case 46 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 291 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_EXTENSION , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 4 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ) ;
2006-04-27 02:29:32 +00:00
( yyval . pval ) - > u4 . regexten = 1 ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 47 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 296 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_EXTENSION , & ( yylsp [ ( 1 ) - ( 7 ) ] ) , & ( yylsp [ ( 7 ) - ( 7 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 5 ) - ( 7 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 7 ) - ( 7 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 7 ) - ( 7 ) ] . pval ) ) ;
2006-06-18 21:36:24 +00:00
( yyval . pval ) - > u3 . hints = ( yyvsp [ ( 3 ) - ( 7 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 48 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 301 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_EXTENSION , & ( yylsp [ ( 1 ) - ( 8 ) ] ) , & ( yylsp [ ( 8 ) - ( 8 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 6 ) - ( 8 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 8 ) - ( 8 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 8 ) - ( 8 ) ] . pval ) ) ;
2006-04-27 02:29:32 +00:00
( yyval . pval ) - > u4 . regexten = 1 ;
2006-06-18 21:36:24 +00:00
( yyval . pval ) - > u3 . hints = ( yyvsp [ ( 4 ) - ( 8 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 49 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 310 "ael.y"
2006-05-03 16:33:00 +00:00
{ ( yyval . pval ) = NULL ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 50 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 311 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 51 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 312 "ael.y"
2007-08-23 23:37:33 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 52 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 318 "ael.y"
2006-05-02 18:23:41 +00:00
{
2006-06-18 21:36:24 +00:00
asprintf ( & ( yyval . str ) , " %s:%s:%s " , ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) , ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) , ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ) ;
free ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) ) ;
free ( ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 53 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 323 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 54 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 327 "ael.y"
2006-05-02 18:33:15 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 7 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 7 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 7 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 7 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 5 ) - ( 7 ) ] . str ) , & ( yylsp [ ( 5 ) - ( 7 ) ] ) ) ;
( yyval . pval ) - > next - > next - > next = nword ( ( yyvsp [ ( 7 ) - ( 7 ) ] . str ) , & ( yylsp [ ( 7 ) - ( 7 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 55 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 335 "ael.y"
2006-05-02 18:33:15 +00:00
{ reset_parencount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 56 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 335 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 3 ) - ( 4 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 57 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 339 "ael.y"
2006-05-02 19:17:49 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_IF , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 58 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 342 "ael.y"
2006-05-02 18:23:41 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_RANDOM , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ; ; }
2006-05-02 18:23:41 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 59 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 345 "ael.y"
2006-04-27 02:29:32 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_IFTIME , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ;
2006-05-02 18:33:15 +00:00
prev_word = 0 ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 60 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 356 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 61 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 357 "ael.y"
2006-04-27 08:24:00 +00:00
{
2006-06-18 21:36:24 +00:00
asprintf ( & ( ( yyval . str ) ) , " %s%s " , ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ;
2006-04-27 08:24:00 +00:00
prev_word = ( yyval . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 62 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 364 "ael.y"
2006-08-12 19:28:33 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 63 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 365 "ael.y"
2006-08-12 19:28:33 +00:00
{
asprintf ( & ( ( yyval . str ) ) , " %s %s " , ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 64 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 369 "ael.y"
2007-10-24 04:44:27 +00:00
{
asprintf ( & ( ( yyval . str ) ) , " %s:%s " , ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 65 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 373 "ael.y"
2006-08-12 19:28:33 +00:00
{ /* there are often '&' in hints */
asprintf ( & ( ( yyval . str ) ) , " %s&%s " , ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 66 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 379 "ael.y"
2006-08-12 19:28:33 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 67 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 380 "ael.y"
2006-04-27 08:24:00 +00:00
{
2006-06-18 21:36:24 +00:00
asprintf ( & ( ( yyval . str ) ) , " %s%s " , ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ;
2006-04-27 08:24:00 +00:00
prev_word = ( yyval . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 68 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 385 "ael.y"
2006-04-27 08:24:00 +00:00
{
2006-06-18 21:36:24 +00:00
asprintf ( & ( ( yyval . str ) ) , " %s%s%s " , ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , ( yyvsp [ ( 2 ) - ( 3 ) ] . str ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 2 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ;
2006-04-27 08:24:00 +00:00
prev_word = ( yyval . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 69 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 393 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 70 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 394 "ael.y"
2006-04-27 08:24:00 +00:00
{
2006-06-18 21:36:24 +00:00
asprintf ( & ( ( yyval . str ) ) , " %s%s " , ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ) ;
free ( ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 71 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 398 "ael.y"
2006-04-27 08:24:00 +00:00
{
2006-06-18 21:36:24 +00:00
asprintf ( & ( ( yyval . str ) ) , " %s:%s " , ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ) ;
free ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 72 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 404 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_SWITCH , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 5 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 4 ) - ( 5 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 4 ) - ( 5 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 73 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 413 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_STATEMENTBLOCK , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 74 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 416 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 75 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 417 "ael.y"
2007-06-20 20:10:19 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 76 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 418 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_GOTO , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 77 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 421 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_GOTO , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 78 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 424 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_LABEL , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 79 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 427 "ael.y"
2006-05-02 20:13:58 +00:00
{ reset_semicount ( parseio - > scanner ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 80 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 428 "ael.y"
2006-04-24 17:41:27 +00:00
{ reset_semicount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 81 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 429 "ael.y"
2006-04-24 17:41:27 +00:00
{ reset_parencount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 82 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 429 "ael.y"
2006-05-02 19:17:49 +00:00
{ /* XXX word_list maybe ? */
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_FOR , & ( yylsp [ ( 1 ) - ( 12 ) ] ) , & ( yylsp [ ( 12 ) - ( 12 ) ] ) ) ;
( yyval . pval ) - > u1 . for_init = ( yyvsp [ ( 4 ) - ( 12 ) ] . str ) ;
( yyval . pval ) - > u2 . for_test = ( yyvsp [ ( 7 ) - ( 12 ) ] . str ) ;
( yyval . pval ) - > u3 . for_inc = ( yyvsp [ ( 10 ) - ( 12 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u4 . for_statements = ( yyvsp [ ( 12 ) - ( 12 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 12 ) - ( 12 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 83 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 435 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_WHILE , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 3 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 84 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 439 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 85 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 440 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = update_last ( ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) , & ( yylsp [ ( 2 ) - ( 3 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 86 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 441 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = update_last ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 87 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 442 "ael.y"
2006-04-27 08:37:40 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_APPLICATION_CALL , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 88 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 445 "ael.y"
2006-04-24 17:41:27 +00:00
{ reset_semicount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 89 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 445 "ael.y"
2006-04-24 17:41:27 +00:00
{
2006-04-27 08:37:40 +00:00
char * bufx ;
int tot = 0 ;
pval * pptr ;
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_VARDEC , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u2 . val = ( yyvsp [ ( 4 ) - ( 5 ) ] . str ) ;
2006-04-27 08:37:40 +00:00
/* rebuild the original string-- this is not an app call, it's an unwrapped vardec, with a func call on the LHS */
/* string to big to fit in the buffer? */
2006-06-18 21:36:24 +00:00
tot + = strlen ( ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u1 . str ) ;
for ( pptr = ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u2 . arglist ; pptr ; pptr = pptr - > next ) {
2006-04-27 08:37:40 +00:00
tot + = strlen ( pptr - > u1 . str ) ;
tot + + ; /* for a sep like a comma */
}
tot + = 4 ; /* for safety */
2006-05-02 03:03:27 +00:00
bufx = calloc ( 1 , tot ) ;
2006-06-18 21:36:24 +00:00
strcpy ( bufx , ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u1 . str ) ;
2006-04-27 08:37:40 +00:00
strcat ( bufx , " ( " ) ;
/* XXX need to advance the pointer or the loop is very inefficient */
2006-06-18 21:36:24 +00:00
for ( pptr = ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u2 . arglist ; pptr ; pptr = pptr - > next ) {
if ( pptr ! = ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u2 . arglist )
2006-04-27 08:37:40 +00:00
strcat ( bufx , " , " ) ;
strcat ( bufx , pptr - > u1 . str ) ;
}
strcat ( bufx , " ) " ) ;
2006-04-24 17:41:27 +00:00
# ifdef AAL_ARGCHECK
2006-06-18 21:36:24 +00:00
if ( ! ael_is_funcname ( ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u1 . str ) )
2006-04-27 08:37:40 +00:00
ast_log ( LOG_WARNING , " ==== File: %s, Line %d, Cols: %d-%d: Function call? The name %s is not in my internal list of function names \n " ,
2006-06-18 21:36:24 +00:00
my_file , ( yylsp [ ( 1 ) - ( 5 ) ] ) . first_line , ( yylsp [ ( 1 ) - ( 5 ) ] ) . first_column , ( yylsp [ ( 1 ) - ( 5 ) ] ) . last_column , ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) - > u1 . str ) ;
2006-04-24 17:41:27 +00:00
# endif
2006-04-27 08:37:40 +00:00
( yyval . pval ) - > u1 . str = bufx ;
2006-06-18 21:36:24 +00:00
destroy_pval ( ( yyvsp [ ( 1 ) - ( 5 ) ] . pval ) ) ; /* the app call it is not, get rid of that chain */
2006-04-27 08:37:40 +00:00
prev_word = 0 ;
; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 90 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 478 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = npval2 ( PV_BREAK , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 91 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 479 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = npval2 ( PV_RETURN , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 92 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 480 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = npval2 ( PV_CONTINUE , & ( yylsp [ ( 1 ) - ( 2 ) ] ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 93 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 481 "ael.y"
2006-04-27 16:40:25 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = update_last ( ( yyvsp [ ( 1 ) - ( 3 ) ] . pval ) , & ( yylsp [ ( 2 ) - ( 3 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ) ;
( yyval . pval ) - > u3 . else_statements = ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 94 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 485 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . pval ) = 0 ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 95 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 488 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 96 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 489 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . pval ) = NULL ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 97 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 492 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 1 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 98 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 493 "ael.y"
2006-04-27 06:44:38 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 99 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 496 "ael.y"
2006-04-27 17:59:09 +00:00
{
2007-10-24 04:44:27 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 100 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 499 "ael.y"
2006-04-27 17:59:09 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 101 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 503 "ael.y"
2006-04-27 17:59:09 +00:00
{
2007-10-24 04:44:27 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 5 ) ] ) ) ;
2006-06-18 21:36:24 +00:00
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 102 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 507 "ael.y"
2006-04-27 17:59:09 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( strdup ( " default " ) , & ( yylsp [ ( 1 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 103 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 511 "ael.y"
2007-10-24 04:44:27 +00:00
{
( yyval . pval ) = nword ( strdup ( " default " ) , & ( yylsp [ ( 1 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 5 ) - ( 5 ) ] . str ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 104 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 517 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . str ) = strdup ( " 1 " ) ; ; }
2006-05-03 17:07:56 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 105 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 518 "ael.y"
2007-10-24 04:44:27 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 106 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 522 "ael.y"
2006-05-03 17:07:56 +00:00
{ /* ext[, pri] default 1 */
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 2 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 2 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 2 ) - ( 2 ) ] . str ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 107 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 525 "ael.y"
2006-05-02 20:11:24 +00:00
{ /* context, ext, pri */
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 4 ) - ( 4 ) ] . str ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
( yyval . pval ) - > next = nword ( ( yyvsp [ ( 1 ) - ( 4 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 4 ) ] ) ) ;
( yyval . pval ) - > next - > next = nword ( ( yyvsp [ ( 2 ) - ( 4 ) ] . str ) , & ( yylsp [ ( 2 ) - ( 4 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 108 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 531 "ael.y"
2006-04-24 17:41:27 +00:00
{ reset_argcount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 109 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 531 "ael.y"
2006-04-27 17:59:09 +00:00
{
2006-04-27 18:18:12 +00:00
/* XXX original code had @2 but i think we need @5 */
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_MACRO_CALL , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ;
( yyval . pval ) - > u2 . arglist = ( yyvsp [ ( 4 ) - ( 5 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 110 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 536 "ael.y"
2006-04-27 17:59:09 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_MACRO_CALL , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 111 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 544 "ael.y"
2006-04-24 17:41:27 +00:00
{ reset_argcount ( parseio - > scanner ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 112 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 544 "ael.y"
2006-04-27 08:37:40 +00:00
{
2006-06-18 21:36:24 +00:00
if ( strcasecmp ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , " goto " ) = = 0 ) {
( yyval . pval ) = npval2 ( PV_GOTO , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 2 ) - ( 3 ) ] ) ) ;
free ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ) ; /* won't be using this */
ast_log ( LOG_WARNING , " ==== File: %s, Line %d, Cols: %d-%d: Suggestion: Use the goto statement instead of the Goto() application call in AEL. \n " , my_file , ( yylsp [ ( 1 ) - ( 3 ) ] ) . first_line , ( yylsp [ ( 1 ) - ( 3 ) ] ) . first_column , ( yylsp [ ( 1 ) - ( 3 ) ] ) . last_column ) ;
2006-05-01 00:02:12 +00:00
} else {
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_APPLICATION_CALL , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 2 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) ;
2006-05-01 00:02:12 +00:00
} ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 113 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 555 "ael.y"
2006-04-30 12:12:39 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = update_last ( ( yyvsp [ ( 1 ) - ( 3 ) ] . pval ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
2006-04-24 17:41:27 +00:00
if ( ( yyval . pval ) - > type = = PV_GOTO )
2006-06-18 21:36:24 +00:00
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ;
2006-04-24 17:41:27 +00:00
else
2006-06-18 21:36:24 +00:00
( yyval . pval ) - > u2 . arglist = ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ;
2006-04-30 12:12:39 +00:00
; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 114 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 562 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = update_last ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , & ( yylsp [ ( 2 ) - ( 2 ) ] ) ) ; ; }
2006-05-02 20:13:58 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 115 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 565 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . str ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) ; }
2006-05-02 20:11:24 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 116 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 566 "ael.y"
2006-05-02 20:13:58 +00:00
{ ( yyval . str ) = strdup ( " " ) ; ; }
2006-05-02 18:51:33 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 117 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 569 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 1 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 118 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 570 "ael.y"
2006-05-02 20:13:58 +00:00
{
( yyval . pval ) = npval ( PV_WORD , 0 /*@1.first_line*/ , 0 /*@1.last_line*/ , 0 /* @1.first_column*/ , 0 /*@1.last_column*/ ) ;
( yyval . pval ) - > u1 . str = strdup ( " " ) ; ; }
2006-04-30 08:21:46 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 119 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 573 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 3 ) ] . pval ) , nword ( ( yyvsp [ ( 3 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ) ; ; }
2006-04-30 08:21:46 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 120 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 576 "ael.y"
2006-05-02 20:18:02 +00:00
{ ( yyval . pval ) = NULL ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 121 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 577 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 122 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 580 "ael.y"
2006-04-27 19:14:07 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_CASE , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 3 ) - ( 4 ) ] ) ) ; /* XXX 3 or 4 ? */
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 4 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 123 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 584 "ael.y"
2006-04-27 19:14:07 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_DEFAULT , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ;
2006-05-03 16:12:31 +00:00
( yyval . pval ) - > u1 . str = NULL ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 124 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 588 "ael.y"
2006-04-27 19:14:07 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_PATTERN , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ; /* XXX@3 or @4 ? */
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 4 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 4 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 125 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 594 "ael.y"
2006-05-02 18:51:33 +00:00
{ ( yyval . pval ) = NULL ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 126 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 595 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 127 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 598 "ael.y"
2006-06-18 21:36:24 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 128 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 599 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 1 ) ] . pval ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 129 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 600 "ael.y"
2006-04-28 06:26:27 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_CATCH , & ( yylsp [ ( 1 ) - ( 5 ) ] ) , & ( yylsp [ ( 5 ) - ( 5 ) ] ) ) ;
( yyval . pval ) - > u1 . str = ( yyvsp [ ( 2 ) - ( 5 ) ] . str ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u2 . statements = ( yyvsp [ ( 4 ) - ( 5 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 4 ) - ( 5 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 130 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 606 "ael.y"
2006-04-28 06:26:27 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_SWITCHES , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 2 ) - ( 4 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 131 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 611 "ael.y"
2006-04-28 11:20:21 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_ESWITCHES , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 2 ) - ( 4 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 132 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 616 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = NULL ; ; }
2006-04-30 12:44:54 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 133 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 617 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = linku1 ( nword ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 3 ) ] ) ) , ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 134 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 618 "ael.y"
2007-06-05 22:04:22 +00:00
{ char * x ; asprintf ( & x , " %s@%s " , ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) , ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) ) ; free ( ( yyvsp [ ( 1 ) - ( 5 ) ] . str ) ) ; free ( ( yyvsp [ ( 3 ) - ( 5 ) ] . str ) ) ;
( yyval . pval ) = linku1 ( nword ( x , & ( yylsp [ ( 1 ) - ( 5 ) ] ) ) , ( yyvsp [ ( 5 ) - ( 5 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 135 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 620 "ael.y"
2007-08-23 23:37:33 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 2 ) - ( 2 ) ] . pval ) ; ; }
2007-05-03 14:24:00 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 136 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 623 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 1 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 1 ) ] ) ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 137 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 624 "ael.y"
2006-04-24 17:41:27 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = nword ( ( yyvsp [ ( 1 ) - ( 3 ) ] . str ) , & ( yylsp [ ( 1 ) - ( 3 ) ] ) ) ;
( yyval . pval ) - > u2 . arglist = ( yyvsp [ ( 3 ) - ( 3 ) ] . pval ) ;
2006-05-02 18:41:57 +00:00
prev_word = 0 ; /* XXX sure ? */ ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 138 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 631 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 139 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 632 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = linku1 ( ( yyvsp [ ( 1 ) - ( 3 ) ] . pval ) , ( yyvsp [ ( 2 ) - ( 3 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 140 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 633 "ael.y"
2007-06-05 22:04:22 +00:00
{ ( yyval . pval ) = ( yyvsp [ ( 1 ) - ( 2 ) ] . pval ) ; ; }
break ;
2007-11-27 18:50:44 +00:00
case 141 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 636 "ael.y"
2006-04-27 06:44:38 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_INCLUDES , & ( yylsp [ ( 1 ) - ( 4 ) ] ) , & ( yylsp [ ( 4 ) - ( 4 ) ] ) ) ;
2006-08-07 12:59:47 +00:00
( yyval . pval ) - > u1 . list = ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ; set_dads ( ( yyval . pval ) , ( yyvsp [ ( 3 ) - ( 4 ) ] . pval ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-11-27 18:50:44 +00:00
case 142 :
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 639 "ael.y"
2006-04-27 06:44:38 +00:00
{
2006-06-18 21:36:24 +00:00
( yyval . pval ) = npval2 ( PV_INCLUDES , & ( yylsp [ ( 1 ) - ( 3 ) ] ) , & ( yylsp [ ( 3 ) - ( 3 ) ] ) ) ; ; }
2006-04-24 17:41:27 +00:00
break ;
2007-08-23 23:37:33 +00:00
/* Line 1270 of yacc.c. */
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 3014 "ael.tab.c"
2006-04-24 17:41:27 +00:00
default : break ;
}
2006-06-18 21:36:24 +00:00
YY_SYMBOL_PRINT ( " -> $$ = " , yyr1 [ yyn ] , & yyval , & yyloc ) ;
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
YYPOPSTACK ( yylen ) ;
yylen = 0 ;
2006-04-24 17:41:27 +00:00
YY_STACK_PRINT ( yyss , yyssp ) ;
* + + yyvsp = yyval ;
* + + yylsp = yyloc ;
/* Now `shift' the result of the reduction. Determine what state
that goes to , based on the state we popped back to and the rule
number reduced by . */
yyn = yyr1 [ yyn ] ;
yystate = yypgoto [ yyn - YYNTOKENS ] + * yyssp ;
if ( 0 < = yystate & & yystate < = YYLAST & & yycheck [ yystate ] = = * yyssp )
yystate = yytable [ yystate ] ;
else
yystate = yydefgoto [ yyn - YYNTOKENS ] ;
goto yynewstate ;
/*------------------------------------.
| yyerrlab - - here on detecting error |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyerrlab :
/* If not already recovering from an error, report this error. */
if ( ! yyerrstatus )
{
+ + yynerrs ;
2006-06-18 21:36:24 +00:00
# if ! YYERROR_VERBOSE
yyerror ( & yylloc , parseio , YY_ ( " syntax error " ) ) ;
# else
{
YYSIZE_T yysize = yysyntax_error ( 0 , yystate , yychar ) ;
if ( yymsg_alloc < yysize & & yymsg_alloc < YYSTACK_ALLOC_MAXIMUM )
{
YYSIZE_T yyalloc = 2 * yysize ;
if ( ! ( yysize < = yyalloc & & yyalloc < = YYSTACK_ALLOC_MAXIMUM ) )
yyalloc = YYSTACK_ALLOC_MAXIMUM ;
if ( yymsg ! = yymsgbuf )
YYSTACK_FREE ( yymsg ) ;
yymsg = ( char * ) YYSTACK_ALLOC ( yyalloc ) ;
if ( yymsg )
yymsg_alloc = yyalloc ;
else
2006-04-24 17:41:27 +00:00
{
2006-06-18 21:36:24 +00:00
yymsg = yymsgbuf ;
yymsg_alloc = sizeof yymsgbuf ;
2006-04-24 17:41:27 +00:00
}
2006-06-18 21:36:24 +00:00
}
2006-04-24 17:41:27 +00:00
2006-06-18 21:36:24 +00:00
if ( 0 < yysize & & yysize < = yymsg_alloc )
{
( void ) yysyntax_error ( yymsg , yystate , yychar ) ;
yyerror ( & yylloc , parseio , yymsg ) ;
}
else
{
yyerror ( & yylloc , parseio , YY_ ( " syntax error " ) ) ;
if ( yysize ! = 0 )
2006-04-24 17:41:27 +00:00
goto yyexhaustedlab ;
2006-06-18 21:36:24 +00:00
}
}
# endif
2006-04-24 17:41:27 +00:00
}
yyerror_range [ 0 ] = yylloc ;
if ( yyerrstatus = = 3 )
{
/* If just tried and failed to reuse look-ahead token after an
error , discard it . */
if ( yychar < = YYEOF )
2006-06-18 21:36:24 +00:00
{
2006-04-24 17:41:27 +00:00
/* Return failure if at end of input. */
if ( yychar = = YYEOF )
YYABORT ;
2006-06-18 21:36:24 +00:00
}
2006-04-24 17:41:27 +00:00
else
{
2006-06-18 21:36:24 +00:00
yydestruct ( " Error: discarding " ,
yytoken , & yylval , & yylloc , parseio ) ;
2006-04-24 17:41:27 +00:00
yychar = YYEMPTY ;
}
}
/* Else will try to reuse look-ahead token after shifting the error
token . */
goto yyerrlab1 ;
/*---------------------------------------------------.
| yyerrorlab - - error raised explicitly by YYERROR . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyerrorlab :
/* Pacify compilers like GCC when the user code never invokes
YYERROR and the label yyerrorlab therefore never appears in user
code . */
2006-06-18 21:36:24 +00:00
if ( /*CONSTCOND*/ 0 )
2006-04-24 17:41:27 +00:00
goto yyerrorlab ;
yyerror_range [ 0 ] = yylsp [ 1 - yylen ] ;
2006-06-18 21:36:24 +00:00
/* Do not reclaim the symbols of the rule which action triggered
this YYERROR . */
YYPOPSTACK ( yylen ) ;
yylen = 0 ;
YY_STACK_PRINT ( yyss , yyssp ) ;
2006-04-24 17:41:27 +00:00
yystate = * yyssp ;
goto yyerrlab1 ;
/*-------------------------------------------------------------.
| yyerrlab1 - - common code for both syntax error and YYERROR . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyerrlab1 :
yyerrstatus = 3 ; /* Each real token shifted decrements this. */
for ( ; ; )
{
yyn = yypact [ yystate ] ;
if ( yyn ! = YYPACT_NINF )
{
yyn + = YYTERROR ;
if ( 0 < = yyn & & yyn < = YYLAST & & yycheck [ yyn ] = = YYTERROR )
{
yyn = yytable [ yyn ] ;
if ( 0 < yyn )
break ;
}
}
/* Pop the current state because it cannot handle the error token. */
if ( yyssp = = yyss )
YYABORT ;
yyerror_range [ 0 ] = * yylsp ;
2006-06-18 21:36:24 +00:00
yydestruct ( " Error: popping " ,
yystos [ yystate ] , yyvsp , yylsp , parseio ) ;
YYPOPSTACK ( 1 ) ;
2006-04-24 17:41:27 +00:00
yystate = * yyssp ;
YY_STACK_PRINT ( yyss , yyssp ) ;
}
if ( yyn = = YYFINAL )
YYACCEPT ;
* + + yyvsp = yylval ;
yyerror_range [ 1 ] = yylloc ;
/* Using YYLLOC is tempting, but would change the location of
2006-06-18 21:36:24 +00:00
the look - ahead . YYLOC is available though . */
YYLLOC_DEFAULT ( yyloc , ( yyerror_range - 1 ) , 2 ) ;
2006-04-24 17:41:27 +00:00
* + + yylsp = yyloc ;
2006-06-18 21:36:24 +00:00
/* Shift the error token. */
2006-04-24 17:41:27 +00:00
YY_SYMBOL_PRINT ( " Shifting " , yystos [ yyn ] , yyvsp , yylsp ) ;
yystate = yyn ;
goto yynewstate ;
/*-------------------------------------.
| yyacceptlab - - YYACCEPT comes here . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyacceptlab :
yyresult = 0 ;
goto yyreturn ;
/*-----------------------------------.
| yyabortlab - - YYABORT comes here . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyabortlab :
yyresult = 1 ;
goto yyreturn ;
# ifndef yyoverflow
/*-------------------------------------------------.
| yyexhaustedlab - - memory exhaustion comes here . |
` - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */
yyexhaustedlab :
yyerror ( & yylloc , parseio , YY_ ( " memory exhausted " ) ) ;
yyresult = 2 ;
/* Fall through. */
# endif
yyreturn :
if ( yychar ! = YYEOF & & yychar ! = YYEMPTY )
yydestruct ( " Cleanup: discarding lookahead " ,
2006-06-18 21:36:24 +00:00
yytoken , & yylval , & yylloc , parseio ) ;
/* Do not reclaim the symbols of the rule which action triggered
this YYABORT or YYACCEPT . */
YYPOPSTACK ( yylen ) ;
YY_STACK_PRINT ( yyss , yyssp ) ;
2006-04-24 17:41:27 +00:00
while ( yyssp ! = yyss )
{
yydestruct ( " Cleanup: popping " ,
2006-06-18 21:36:24 +00:00
yystos [ * yyssp ] , yyvsp , yylsp , parseio ) ;
YYPOPSTACK ( 1 ) ;
2006-04-24 17:41:27 +00:00
}
# ifndef yyoverflow
if ( yyss ! = yyssa )
YYSTACK_FREE ( yyss ) ;
2006-06-18 21:36:24 +00:00
# endif
# if YYERROR_VERBOSE
if ( yymsg ! = yymsgbuf )
YYSTACK_FREE ( yymsg ) ;
2006-04-24 17:41:27 +00:00
# endif
2007-08-23 23:37:33 +00:00
return yyresult ;
2006-04-24 17:41:27 +00:00
}
Merged revisions 130145 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
Merging this rev from trunk to 1.6.0 was not
simple. Why? Because we've enhanced trunk to
do a [fast] merge-and-delete operation which
also solved problems with contexts having
entries from different registrars.
Fast as in the amount of time the contexts
are locked down. That *is* fast, but traversing
the entire dialplan looking for priorities to
delete takes more time overall.
This particular fix involved pulling in those
enhancements from trunk, along with all the
various fixes and refinements made along the
way.
Merging all this from trunk into 1.6 involved:
a. mergetrunk6 in the stuff from 130145;
b. revert all but the prop changes
c. catalog all revisions to pbx.c since 1.6.0 was forked
(at rev 105596).
d. catalog all revisions to pbx.c in trunk since 1.6.0
was forked, making special note of all revs that
were not merged into 1.6.0.
e. study each rev in trunk not applied to 1.6.0, and
determine if it was involved in the merge_and_delete
enhancements in trunk. 25 commits were done in 1.6.0,
all but one (106306) was a merge from trunk.
Trunk had 22 additional changes, of which 7 were
involved in the merge_and_delete enhancements:
106757
108894
109169
116461
123358
130145
130297
f. Go to trunk and collect patches, one by one,
of the changes made by each rev across the
entire source tree, using svn diff -c <num> > pfile
g. Apply each patch in order to 1.6.0, and
resolve all failures and compilation problems
before proceding to the next patch.
h. test the stuff.
i. profit!
........
r130145 | murf | 2008-07-11 12:24:31 -0600 (Fri, 11 Jul 2008) | 40 lines
(closes issue #13041)
Reported by: eliel
Tested by: murf
(closes issue #12960)
Reported by: mnicholson
In this 'omnibus' fix, I **think** I solved both
the problem in 13041, where unloading pbx_ael.so
caused crashes, or incomplete removal of previous
registrar'ed entries. And I added code to completely
remove all includes, switches, and ignorepats that
had a matching registrar entry, which should
appease 12960.
I also added a lot of seemingly useless brackets
around single statement if's, which helped debug
so much that I'm leaving them there.
I added a routine to check the correlation between
the extension tree lists and the hashtab
tables. It can be amazingly helpful when you have
lots of dialplan stuff, and need to narrow
down where a problem is occurring. It's ifdef'd
out by default.
I cleaned up the code around the new CIDmatch code.
It was leaving hanging extens with bad ptrs, getting confused
over which objects to remove, etc. I tightened
up the code and changed the call to remove_exten
in the merge_and_delete code.
I added more conditions to check for empty context
worthy of deletion. It's not empty if there are
any includes, switches, or ignorepats present.
If I've missed anything, please re-open this bug,
and be prepared to supply example dialplan code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@130946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2008-07-15 13:14:07 +00:00
# line 644 "ael.y"
2006-04-24 17:41:27 +00:00
2006-04-26 18:43:29 +00:00
static char * token_equivs1 [ ] =
2006-04-24 17:41:27 +00:00
{
" AMPER " ,
" AT " ,
" BAR " ,
" COLON " ,
" COMMA " ,
" EQ " ,
" EXTENMARK " ,
2006-04-26 18:43:29 +00:00
" KW_BREAK " ,
" KW_CASE " ,
" KW_CATCH " ,
2006-04-24 17:41:27 +00:00
" KW_CONTEXT " ,
2006-04-26 18:43:29 +00:00
" KW_CONTINUE " ,
" KW_DEFAULT " ,
2006-04-24 17:41:27 +00:00
" KW_ELSE " ,
" KW_ESWITCHES " ,
2006-04-26 18:43:29 +00:00
" KW_FOR " ,
2006-04-24 17:41:27 +00:00
" KW_GLOBALS " ,
" KW_GOTO " ,
" KW_HINT " ,
" KW_IFTIME " ,
" KW_IF " ,
" KW_IGNOREPAT " ,
" KW_INCLUDES "
" KW_JUMP " ,
" KW_MACRO " ,
2006-04-26 18:43:29 +00:00
" KW_PATTERN " ,
" KW_REGEXTEN " ,
" KW_RETURN " ,
" KW_SWITCHES " ,
2006-04-24 17:41:27 +00:00
" KW_SWITCH " ,
2006-04-26 18:43:29 +00:00
" KW_WHILE " ,
2006-04-24 17:41:27 +00:00
" LC " ,
" LP " ,
" RC " ,
" RP " ,
" SEMI " ,
} ;
2006-04-26 18:43:29 +00:00
static char * token_equivs2 [ ] =
2006-04-24 17:41:27 +00:00
{
" & " ,
" @ " ,
" | " ,
" : " ,
" , " ,
" = " ,
" => " ,
2006-04-26 18:43:29 +00:00
" break " ,
" case " ,
" catch " ,
2006-04-24 17:41:27 +00:00
" context " ,
2006-04-26 18:43:29 +00:00
" continue " ,
" default " ,
2006-04-24 17:41:27 +00:00
" else " ,
" eswitches " ,
2006-04-26 18:43:29 +00:00
" for " ,
2006-04-24 17:41:27 +00:00
" globals " ,
" goto " ,
" hint " ,
" ifTime " ,
" if " ,
" ignorepat " ,
" includes "
" jump " ,
" macro " ,
2006-04-26 18:43:29 +00:00
" pattern " ,
" regexten " ,
" return " ,
" switches " ,
2006-04-24 17:41:27 +00:00
" switch " ,
2006-04-26 18:43:29 +00:00
" while " ,
2006-04-24 17:41:27 +00:00
" { " ,
" ( " ,
" } " ,
" ) " ,
" ; " ,
} ;
2007-09-27 00:06:06 +00:00
static char * ael_token_subst ( const char * mess )
2006-04-24 17:41:27 +00:00
{
/* calc a length, malloc, fill, and return; yyerror had better free it! */
int len = 0 , i ;
2007-09-27 00:06:06 +00:00
const char * p ;
2006-04-24 17:41:27 +00:00
char * res , * s , * t ;
int token_equivs_entries = sizeof ( token_equivs1 ) / sizeof ( char * ) ;
for ( p = mess ; * p ; p + + ) {
for ( i = 0 ; i < token_equivs_entries ; i + + ) {
if ( strncmp ( p , token_equivs1 [ i ] , strlen ( token_equivs1 [ i ] ) ) = = 0 )
{
len + = strlen ( token_equivs2 [ i ] ) + 2 ;
p + = strlen ( token_equivs1 [ i ] ) - 1 ;
break ;
}
}
len + + ;
}
2006-05-02 03:03:27 +00:00
res = calloc ( 1 , len + 1 ) ;
2006-04-24 17:41:27 +00:00
res [ 0 ] = 0 ;
s = res ;
for ( p = mess ; * p ; ) {
int found = 0 ;
for ( i = 0 ; i < token_equivs_entries ; i + + ) {
if ( strncmp ( p , token_equivs1 [ i ] , strlen ( token_equivs1 [ i ] ) ) = = 0 ) {
* s + + = ' \' ' ;
for ( t = token_equivs2 [ i ] ; * t ; ) {
* s + + = * t + + ;
}
* s + + = ' \' ' ;
p + = strlen ( token_equivs1 [ i ] ) ;
found = 1 ;
break ;
}
}
if ( ! found )
* s + + = * p + + ;
}
* s + + = 0 ;
return res ;
}
void yyerror ( YYLTYPE * locp , struct parse_io * parseio , char const * s )
{
2007-10-24 04:44:27 +00:00
char * s2 = ael_token_subst ( ( char * ) s ) ;
2006-04-24 17:41:27 +00:00
if ( locp - > first_line = = locp - > last_line ) {
ast_log ( LOG_ERROR , " ==== File: %s, Line %d, Cols: %d-%d: Error: %s \n " , my_file , locp - > first_line , locp - > first_column , locp - > last_column , s2 ) ;
} else {
ast_log ( LOG_ERROR , " ==== File: %s, Line %d Col %d to Line %d Col %d: Error: %s \n " , my_file , locp - > first_line , locp - > first_column , locp - > last_line , locp - > last_column , s2 ) ;
}
free ( s2 ) ;
parseio - > syntax_error_count + + ;
}
2007-08-15 19:21:27 +00:00
struct pval * npval ( pvaltype type , int first_line , int last_line ,
2006-04-27 17:39:55 +00:00
int first_column , int last_column )
2006-04-24 17:41:27 +00:00
{
2006-05-02 03:03:27 +00:00
pval * z = calloc ( 1 , sizeof ( struct pval ) ) ;
2006-04-24 17:41:27 +00:00
z - > type = type ;
z - > startline = first_line ;
z - > endline = last_line ;
z - > startcol = first_column ;
z - > endcol = last_column ;
z - > filename = strdup ( my_file ) ;
return z ;
}
2006-04-27 18:09:20 +00:00
static struct pval * npval2 ( pvaltype type , YYLTYPE * first , YYLTYPE * last )
{
return npval ( type , first - > first_line , last - > last_line ,
first - > first_column , last - > last_column ) ;
}
2006-04-30 12:12:39 +00:00
static struct pval * update_last ( pval * obj , YYLTYPE * last )
{
obj - > endline = last - > last_line ;
obj - > endcol = last - > last_column ;
return obj ;
}
2006-04-30 13:57:08 +00:00
/* frontend for npval to create a PV_WORD string from the given token */
static pval * nword ( char * string , YYLTYPE * pos )
{
pval * p = npval2 ( PV_WORD , pos , pos ) ;
if ( p )
p - > u1 . str = string ;
return p ;
}
2006-08-07 12:59:47 +00:00
/* this routine adds a dad ptr to each element in the list */
static void set_dads ( struct pval * dad , struct pval * child_list )
{
struct pval * t ;
for ( t = child_list ; t ; t = t - > next ) /* simple stuff */
t - > dad = dad ;
}