1 |
It’s been four months since I started working on this project. I just |
2 |
passed the mid-term evaluation so I’d like to talk about the current |
3 |
status of libbash. |
4 |
|
5 |
My plan for the mid-term evaluation is to be able to parse the ebuilds |
6 |
that don’t inherit any eclass. With a few exceptions, I achieved that |
7 |
more than a month ago. If you read my weekly reports, you might have |
8 |
noticed that we could parse about 7000+ ebuilds at some point. That’s |
9 |
when I achieved the goal. |
10 |
|
11 |
If you want to see what libbash can handle so far, there are several |
12 |
test scripts[1] where you can find the answer. |
13 |
|
14 |
But why are there some exceptions? The answer is due to the limitation |
15 |
of parser grammar. The parser grammar was supposed to be working at the |
16 |
end of GSoC 2010. However we found there were still many issues in the |
17 |
grammar while implementing the runtime of libbash. The parser grammar is |
18 |
quite important and I can’t work on the runtime if the parser grammar |
19 |
does not work properly. |
20 |
|
21 |
Then what are you doing these days? I spent most of the time fixing the |
22 |
problems in the parser grammar. In my GSoC application, I said if I had |
23 |
enough time, I would try to disable global backtracking for the parser |
24 |
grammar. But now this seems to be required. I started working on it from |
25 |
last week and it goes pretty well so far. |
26 |
|
27 |
Some people doubt if I could completely disable backtracking. I’m not a |
28 |
compiler expert and I don’t have the confidence to say if bash is LL(k). |
29 |
As far as I see, I can handle most of the syntax with LL(k) parser. But |
30 |
what I am really trying to do is to remove the global backtracking |
31 |
option of ANTLR grammar. With that option, ANTLR will automatically |
32 |
backtrack so there might be many places where you could have avoided |
33 |
backtracking. It also makes the problems in the parser grammar even more |
34 |
complicated. It’s highly recommended not to use that option in |
35 |
production code. As a result, I’m trying to use left factoring, |
36 |
syntactic predicate and local backtracking option instead of the global |
37 |
one. So far the parser grammar is faster and it’s much easier to fix the |
38 |
problems in it. I’ll give the performance comparison in the next weekly |
39 |
report. |
40 |
|
41 |
What I have done in the last week: |
42 |
|
43 |
worked on a new parser grammar without the global backtracking option |
44 |
|
45 |
Plan for this week: |
46 |
|
47 |
finish the work with the new parser grammar and improve unit tests |
48 |
incorporate the new parser grammar |
49 |
fully support here document |
50 |
improve the rules for parameter expansion |
51 |
improve the rules for built-in and keyword test |
52 |
fix the problem with \newline |
53 |
|
54 |
[1] |
55 |
http://git.overlays.gentoo.org/gitweb/?p=proj/libbash.git;a=tree;f=scripts;h=5aac894cce36dca87cd3dfb924b91712e560f7fc;hb=HEAD |
56 |
|
57 |
-- |
58 |
Best wishes, |
59 |
Mu Qiao |
60 |
GnuPG fingerprint: 92B1 B0C4 8D14 F8C4 EFA5 3ACC 30B3 0DE4 17B1 57E9 |