|Summary:||ASTERISK-07441: [branch] AEL reverse compiler Enhancement Request|
|Reporter:||Sherwood McGowan (rushowr)||Labels:|
|Date Opened:||2006-08-01 16:00:48||Date Closed:||2007-08-15 14:39:31|
|Description:||how hard would it be to write a reverse compiler for translating existing dialplan files into .ael/.ael2 files?|
|Comments:||By: Steve Murphy (murf) 2006-08-01 16:04:52|
Now, as to the reverse, converting extensions.conf to AEL: it is possible, but a lot of work. Think of it this way: what you are asking for is a reverse compiler. Given, for example, an assembly file, produce the equivalent C++ code that might have produced that assembly file. It's a bit easier (relatively) if you have some nice constraints, say you know the assembly file was generated with g++, and only one particular version of it, at that. You could then pattern match certain sequences in the assembler output back into C++ structures with reasonable confidence. Others, you just synthesize something that would work.
But, incoming extensions.conf code does not follow such narrow limits.It would not be uncommon to see subtle tricks being used to accomplish some goal, which would be difficult for a human to interpret, let alone a program. That being said, most extensions code **is** pretty simple, and in most cases simple heuristics could cover a great majority of the code. Stuff that it can't grok could simply be copied verbatim into the output for a human to complete. Most of the formatting and easy stuff could be done by the translator and speed up the job of conversion tremendously.
I'm all for it. Such a program could help reduce the cost of converting to AEL, and aid the whole community greatly.
So, I'll keep this bug open until I have something to release. Here in a bit, I'll associate a development branch with this bug so others who are interested can review/add/complain/modify/etc.
By: Steve Murphy (murf) 2006-08-01 16:07:08
I'll soon create a branch for any code enhancements.
By: Sherwood McGowan (rushowr) 2006-08-01 16:15:51
You sir, rock. Thanks again for making AEL v2, it's made my life as a dialplan solution developer much easier :)
By: Steve Murphy (murf) 2006-08-01 16:43:01
I now have so created:
for development of this enhancement.
By: jmls (jmls) 2006-10-31 13:36:20.000-0600
and how is it going ?
By: jmls (jmls) 2006-12-10 08:04:38.000-0600
*cough* how's it going ?
By: Steve Murphy (murf) 2006-12-11 11:10:32.000-0600
* cough, cough, hack, haaaaack *
This is an enhancement, and non-trivial at that; I'll wait till 1.4 is released, before diving into this project.
By: Jason Parker (jparker) 2007-01-16 14:07:10.000-0600
1.4 has been released :)
By: Steve Murphy (murf) 2007-01-16 14:28:03.000-0600
And, indeed, I've started working on this!
By: Steve Murphy (murf) 2007-01-16 14:38:07.000-0600
Crude measure of progress: I've kludged together (by ripping static innards out of asterisk) a parser for extensions.conf, that builds the usual context/extension structs. I'm working on a PI to build pval trees; when this is complete, I'll rewrite the little bit that I've generated to build the tree, which generates contexts, extensions, and priorities, with pretty low-level code.
I need to generate stuff for switches/ignorepats/includes. I need to convert all macro contexts into macro definitions, and output macro calls appropriately. Convert all the Goto related app calls to apropriate structures. And more, I'm sure. And, look for weird stuff, and output appropriate comments. And, add comment capabilities. So, it'll take a while.
By: jmls (jmls) 2007-01-16 15:18:54.000-0600
"it's going to take a while". pah. that's what all developers say.
Big grin, looking forward to this.
By: Sherwood McGowan (rushowr) 2007-01-19 07:00:31.000-0600
Murph, good to see things are starting to move. Please let me know if I can be of service in any way.
By: Steve Murphy (murf) 2007-08-15 14:39:29
Commited the BEGINNINGS of this program into trunk via 79595.
From here on out, suggestions, patches, etc, can be filed under new bug numbers.
See conf2ael in the utils directory.
The plan is to form a graph of the control flow in the extensions.conf code, then pull it together into decent AEL code.
These same structures would then form a good basis for a really intelligent extensions.conf linter, that would look for all sorts of gaffs and goofs in the dialplan.