Pippijn van Steenhoven wrote:
I am going to do some work on the elsa parser. First, I will get rid of a
lot of smbase (string, some ADTs). Then I would like to remove anything
You certainly have my support--most of the stuff ought to be moved to
the STL where possible. I've already deleted unused sm::pair and
complained about the others.
not needed for pork.
If by that you mean removal of the various programs, you again have my
support; some of the stuff that involves ASTs is useful, IMO.
> Then, I would like to have perl bindings (maybe
python bindings) directly into the AST and build some tools with that. I
would also like to rewrite the deparser (pretty printer) in a scripting
language. For that, I would like to add intrusive support for perl.
This is the part that I am most wary about. Elsa can output the AST into
an XML string, which can easily be read in by nearly every major
scripting language. Initializing an interpreter for every run of pork
can hurt performance; I have also had experience with poor performance
crossing language boundaries, which means core APIs implemented in a
scripting language could be painful in terms of performance.
I should also note that Mozilla tends to prefer JS or Python these days
to perl.
> Before I do all that, I want to restructure the source tree and use
> automake, autoconf and libtool.
In my opinion, there is no reason to use the autotools suite if the
configuration arguments are simple enough: it adds complexity for so
little value (IMO). Indeed, if it's simple enough that a small script
would handle it just fine, there's no need to rip the system out for the
harder-to-understand autotools suite. Much of the standard arguments are
rather meaningless, since pork tools are probably too case-specific to
be amenable to an installation procedure, and there's no need to have
pork work on systems that require arcane reconfiguration.
Now: what is the stuff in porky/parser.py and porky/parser.py? Are you
trying to write a C++ parser in python? I hope not..
That is cjones's porky tool, which is designed to be able to write a
simple rewriting tool. The parsing is to parse the type names. You can
see his blog post on the tool at
<http://blog.mozilla.com/cjones/2009/08/04/introducing-porky-py-low-fat-pork/>
1. restructure source tree, use autotools
How do you intend to restructure the tree? I've also already given my
distrust of autotools, so unless it's strictly necessary, you should
probably save this step for later.
2. remove smbase string
3. remove other smbase ADTs and use std:: ones
4. remove even more smbase ADTs and use boost:: ones
Two things to note here. When I last spoke with Taras, one of the things
he mentioned was that his biggest perceived barrier to removing
sm::string was concerns over the performance of the codebase. The goal
of porky is to be able to handle thousands of files of code, with header
includes that can easily push files past the 100,000 line mark or more.
It would be advisable to ensure that your removal does not adversely
impact performance of code parsing.
The other thing to note is the usage of boost::. I think there are
likely to be systems without boost (std::tr1 should be usable with the
appropriate g++ options); it may be inadvisable to require external
libraries if there is no real need for them.
5. remove some unused or unneeded parts of elsa (they have some weird
macro support I don't think actually works)
Macro support--in terms of mcpp-style unwinding--is very much a
necessity for the fork of elsa that Mozilla maintains.
6. remove XML in/output from elsa (yes, it's nice, but it's for the
best and can easily be replaced by "my $xml = XMLout($ast)" after
integrating elsa with perl
Since I believe many people interested in pork will have no to little
experience with perl, I do not think that requiring people to use a
foreign language for a basic feature is a good idea.
7. add (intrusive) perl support to elsa's AST
8. rewrite the deparser in perl and remove it from the C++ code
Again, I personally believe that adding perl support would be the wrong
way to go.
Caveat: I am not the central maintainer of pork or the extant elsa fork.
My opinions are wholly my own, and I can only speculate as to what
others (including Taras) may think of this proposal.
_______________________________________________
dev-static-analysis mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-static-analysis
