https://origsvn.digium.com/svn/asterisk/trunk
................
r136746 | murf | 2008-08-07 18:48:35 -0600 (Thu, 07 Aug 2008) | 40 lines
Merged revisions 136726 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r136726 | murf | 2008-08-07 18:15:34 -0600 (Thu, 07 Aug 2008) | 32 lines
(closes issue #13236)
Reported by: korihor
Wow, this one was a challenge!
I regrouped and ran a new strategy for
setting the ~~MACRO~~ value; I set it once
per extension, up near the top. It is only
set if there is a switch in the extension.
So, I had to put in a chunk of code to detect
a switch in the pval tree.
I moved the code to insert the set of ~~exten~~
up to the beginning of the gen_prios routine,
instead of down in the switch code.
I learned that I have to push the detection
of the switches down into the code, so everywhere
I create a new exten in gen_prios, I make sure
to pass onto it the values of the mother_exten
first, and the exten next.
I had to add a couple fields to the exten
struct to accomplish this, in the ael_structs.h
file. The checked field makes it so we don't
repeat the switch search if it's been done.
I also updated the regressions.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@136778 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r131243 | murf | 2008-07-16 11:59:33 -0600 (Wed, 16 Jul 2008) | 27 lines
Merged revisions 131242 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r131242 | murf | 2008-07-16 11:53:43 -0600 (Wed, 16 Jul 2008) | 19 lines
(closes issue #13090)
Reported by: murf
The problem was that, esoteric as it is, because the hangerupper
context immediately preceded the std-priv-extent macro, that
the checking code accidentally would fall from traversing hangerupper
into the std-priv-exten macro, where it would hit the hangerupper
in the 'includes', and proceed into an infinite recursion.
A small fix to traverse into the statements of the context instead
of the context solves this issue.
I also added some commented out printfs for debug, which were pretty
handy in the face of a dorky gdb.
This was a problem around since the package was first written;
but evidently pretty rare in turning up in the field.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@131248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
https://origsvn.digium.com/svn/asterisk/trunk
................
r119930 | murf | 2008-06-03 09:07:20 -0600 (Tue, 03 Jun 2008) | 24 lines
Merged revisions 119929 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r119929 | murf | 2008-06-03 08:49:46 -0600 (Tue, 03 Jun 2008) | 16 lines
as per http://lists.digium.com/pipermail/asterisk-users/2008-June/212934.html,
which is a message from Philipp Kempgen, requesting that the WARNING
that an extension is empty be reduced to a NOTICE or less, as empty
extensions are syntactically possible, and no big deal.
With which I agree, and have removed that WARNING message entirely.
I think it is not necessary to see this message. It didn't
state that a NoOp() was inserted automatically on your behalf,
and really, as users, who cares? Why freak out dialplan writers
with unnecessary warnings? The details of the machinations a compiler goes
thru to produce working assembly code is of little interest
to most programmers-- we will follow the unix principal of
doing our work silently.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@119931 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r111360 | murf | 2008-03-26 22:47:12 -0600 (Wed, 26 Mar 2008) | 23 lines
Merged revisions 111341 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r111341 | murf | 2008-03-26 21:21:05 -0600 (Wed, 26 Mar 2008) | 15 lines
(closes issue #12302)
Reported by: pj
Tested by: murf
These changes will set a channel variable ~~EXTEN~~ just before generating code
for a switch, with the value of ${EXTEN}. The exten is marked as having a switch,
and ever after that, till the end of the exten, we substitute any ${EXTEN}
with ${~~EXTEN~~} instead in application arguments; (and the ${EXTEN: also).
The reason for this, is that because switches are coded using
separate extensions to provide pattern matching, and
jumping to/from these switch extensions messes up the ${EXTEN} value,
which blows the minds of users.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@111361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In this commit:
- move the ast_register/unregister_app functions to module.h
to avoid the need to include pbx.h for the simpler apps;
- move the ast_group structure to channel.h to remove the
dependency of app.h on linkedlists.h
Note, this is a long process that I am doing in small steps.
The main difficulty is that now for each subsystem we
have a single header (e.g. channel.h) included by the subsystem
provider (usually one file, e.g. channel.c) and by its clients
(dozens of them, e.g. we have some 70+ apps and 30+ functions).
This requires the clients to include all the extra headers
required by the provider (eg. lock.h, linkedlists.h, definitions
of substructures...) even though many of the clients would be
just happy with opaque struct declarations and function prototypes.
The long term plan is to eventually rectify this structure
so that the compilation can become faster, and also APIs
are more stable.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@89522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r87775 | murf | 2007-10-30 21:51:52 -0600 (Tue, 30 Oct 2007) | 1 line
Included some verbage in the check_includes func, to inform the user that included contexts that have no match in the AEL, might be OK, as AEL cannot check in the extensions.conf or the in-memory contexts, as they may not be there at the time of the check.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@87776 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r84511 | murf | 2007-10-03 08:23:00 -0600 (Wed, 03 Oct 2007) | 1 line
closes issue #10834 ; where a null input to a switch statement results in a hangup; since switch is implemented with extensions, and the default case is implemented with a '.', and the '.' matches 1 or more remaining characters, the case where 0 characters exist isn't matched, and the extension isn't matched, and the goto fails, and a hangup occurs. Now, when a default case is generated, it also generates a single fixed extension that will match a null input. That extension just does a goto to the default extension for that switch. I played with an alternate solution, where I just tack an extra char onto all the patterns and the goto, but not the default case's pattern. Then even a null input will still have at least one char in it. But it made me nervous, having that extra char in , even if that's a pretty secret and low-level issue.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@84512 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r83589 | murf | 2007-09-22 13:39:16 -0600 (Sat, 22 Sep 2007) | 1 line
This closes issue #10788 -- The exact same fixes are made here for the first arg in the for(arg1; arg2; arg3) {} statement, as were done for the 3rd arg. It can now be an assignment that will embedded in a Set() app, or a macro call, or an app call.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@83590 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r83558 | murf | 2007-09-22 10:41:43 -0600 (Sat, 22 Sep 2007) | 1 line
This closes issue #10788 -- the 3rd arg in the for statement is now wrapped in Set() only if there's an '=' in that string. Otherwise, if it begins with '&', then a Macro call is generated; otherwise it is made into an app call. A bit more accomodating, keeps the new guys happy, and the guys with ael-1 code should be happy, too
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@83575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
