[gentoo-soc] libbash weeky report #9 (mid-term summary)

[gentoo-soc] libbash weeky report #9 (mid-term summary)

[Mu Qiao]

[-- Attachment #1: Type: text/plain, Size: 2838 bytes --]

It’s been four months since I started working on this project. I just
passed the mid-term evaluation so I’d like to talk about the current
status of libbash.

My plan for the mid-term evaluation is to be able to parse the ebuilds
that don’t inherit any eclass. With a few exceptions, I achieved that
more than a month ago. If you read my weekly reports, you might have
noticed that we could parse about 7000+ ebuilds at some point. That’s
when I achieved the goal.

If you want to see what libbash can handle so far, there are several
test scripts[1] where you can find the answer.

But why are there some exceptions? The answer is due to the limitation
of parser grammar. The parser grammar was supposed to be working at the
end of GSoC 2010. However we found there were still many issues in the
grammar while implementing the runtime of libbash. The parser grammar is
quite important and I can’t work on the runtime if the parser grammar
does not work properly.

Then what are you doing these days? I spent most of the time fixing the
problems in the parser grammar. In my GSoC application, I said if I had
enough time, I would try to disable global backtracking for the parser
grammar. But now this seems to be required. I started working on it from
last week and it goes pretty well so far.

Some people doubt if I could completely disable backtracking. I’m not a
compiler expert and I don’t have the confidence to say if bash is LL(k).
As far as I see, I can handle most of the syntax with LL(k) parser. But
what I am really trying to do is to remove the global backtracking
option of ANTLR grammar. With that option, ANTLR will automatically
backtrack so there might be many places where you could have avoided
backtracking. It also makes the problems in the parser grammar even more
complicated. It’s highly recommended not to use that option in
production code. As a result, I’m trying to use left factoring,
syntactic predicate and local backtracking option instead of the global
one. So far the parser grammar is faster and it’s much easier to fix the
problems in it. I’ll give the performance comparison in the next weekly
report.

What I have done in the last week:

    worked on a new parser grammar without the global backtracking option

Plan for this week:

    finish the work with the new parser grammar and improve unit tests
    incorporate the new parser grammar
    fully support here document
    improve the rules for parameter expansion
    improve the rules for built-in and keyword test
    fix the problem with \newline

[1]
http://git.overlays.gentoo.org/gitweb/?p=proj/libbash.git;a=tree;f=scripts;h=5aac894cce36dca87cd3dfb924b91712e560f7fc;hb=HEAD

-- 
Best wishes,
Mu Qiao
GnuPG fingerprint: 92B1 B0C4 8D14 F8C4 EFA5  3ACC 30B3 0DE4 17B1 57E9


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]