| 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 |
Archives