1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
I've had a productive week overall, with lots of good progress towards |
5 |
the final goal of this project. |
6 |
|
7 |
As the grammar becomes finalized, a change must be made. All of the |
8 |
debugging tools are used for grammars that output Java code, but I want |
9 |
a C/C++ library to handle everything. So this meant the following things: |
10 |
1) Grammar file had to work regardless of what the output language was. |
11 |
2) I needed to know just how the C runtime worked for ANTLR. |
12 |
3) Since I'm starting to write library code (not just a grammar in a |
13 |
fancy IDE) I need to document my coding standards for any C/C++ code |
14 |
written over the next half of the project. |
15 |
|
16 |
And that indeed is what I've done. I now have coding style guidelines |
17 |
(which can be found at http://web.mst.edu/~nwe5g8/coding_standard.pdf, |
18 |
though as changes are made to the .tex file in the repository, the |
19 |
guaranteed up to date version of the guidelines can be generated from that). |
20 |
|
21 |
Also, I've written a quick sample program that parses a single ebuild. |
22 |
This is mostly a proof of concept, not a final product. All I was |
23 |
trying to do was get familiar with the C runtime and see how it worked. |
24 |
|
25 |
In a previous email I wrote about "infinite loops" in the parser, or at |
26 |
least loops that I was too impatient to wait to finish (5 minutes is too |
27 |
long to wait for a parser to finish parsing something). I found the |
28 |
problem: I was attempting to recursively aggregate complex strings in |
29 |
the parser, and the backtracking became too complex for it to handle. |
30 |
So, I removed the aggregation step, instead just showing the individual |
31 |
portions of the strings. Aggregation will be handled by the C++ |
32 |
implementation (which has to do other things with variable expansions in |
33 |
strings, etc). So that was a major problem solved, and it tuned the |
34 |
performance of the parser quite nicely. |
35 |
|
36 |
The last thing I needed to do was get a language agnostic grammar. C++ |
37 |
already has functions like exp, and bitor, bitxor, and bitand are C++ |
38 |
keywords. The runtime doesn't do anything to fix/catch any of this. As |
39 |
such I had to go back and do that manually. However, the changes I made |
40 |
seemed to make it a grammar that was easier to read. |
41 |
|
42 |
|
43 |
This week is mostly setup and input. I'm writing a big bash script that |
44 |
demonstrates all the features that the grammar supports, and will be |
45 |
sending the resulting AST to the bash upstream mailing list and the |
46 |
portage_devs mailing list to see if they have suggestions. I'm also |
47 |
going to scour man bash for missing features, set up the build system |
48 |
for the libbash portion of the code (most likely cmake), Implement a |
49 |
very simple bash builtin (echo), and finally implement a symbol table. |
50 |
A busy week, but a week that should leave me in excellent shape for the |
51 |
rest of the project. |
52 |
|
53 |
Nate |
54 |
-----BEGIN PGP SIGNATURE----- |
55 |
Version: GnuPG/MacGPG2 v2.0.14 (Darwin) |
56 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
57 |
|
58 |
iEYEARECAAYFAkxEczgACgkQFpoRlVgtqKbq2QCZAU3Fy549/3WTRc3X5i6xmhlt |
59 |
o9AAoIOv4spJ3BkwFIlcRvdFhzqCjpKN |
60 |
=eJON |
61 |
-----END PGP SIGNATURE----- |