From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1ObA9j-0000Rj-An for garchives@archives.gentoo.org; Tue, 20 Jul 2010 10:34:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E8BC2E08ED; Tue, 20 Jul 2010 10:34:29 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id AD053E08ED for ; Tue, 20 Jul 2010 10:34:29 +0000 (UTC) Received: from [192.168.1.116] (dynamic-adsl-94-38-245-45.clienti.tiscali.it [94.38.245.45]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPSA id 7E2881B40D5; Tue, 20 Jul 2010 10:34:28 +0000 (UTC) Message-ID: <4C457BAA.4090708@gentoo.org> Date: Tue, 20 Jul 2010 12:34:18 +0200 From: Luca Barbato User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.4) Gecko/20100708 Lightning/1.0b2pre Mnenhy/0.8.3 Thunderbird/3.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-soc@lists.gentoo.org Reply-to: gentoo-soc@lists.gentoo.org MIME-Version: 1.0 To: gentoo-soc@lists.gentoo.org CC: Nathan Eloe Subject: Re: [gentoo-soc] libbash Weekly Update References: <4C447338.7090401@gmail.com> In-Reply-To: <4C447338.7090401@gmail.com> X-Enigmail-Version: 1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 4c1b1961-3210-447f-86ca-07ee6bcf717e X-Archives-Hash: 28535190ea11a2403a03dfc75ea0b6d2 On 07/19/2010 05:46 PM, Nathan Eloe wrote: > I've had a productive week overall, with lots of good progress towards > the final goal of this project. > > As the grammar becomes finalized, a change must be made. All of the > debugging tools are used for grammars that output Java code, but I want > a C/C++ library to handle everything. So this meant the following things: > 1) Grammar file had to work regardless of what the output language was. > 2) I needed to know just how the C runtime worked for ANTLR. > 3) Since I'm starting to write library code (not just a grammar in a > fancy IDE) I need to document my coding standards for any C/C++ code > written over the next half of the project. > > And that indeed is what I've done. I now have coding style guidelines > (which can be found at http://web.mst.edu/~nwe5g8/coding_standard.pdf, > though as changes are made to the .tex file in the repository, the > guaranteed up to date version of the guidelines can be generated from that). > > Also, I've written a quick sample program that parses a single ebuild. > This is mostly a proof of concept, not a final product. All I was > trying to do was get familiar with the C runtime and see how it worked. > > In a previous email I wrote about "infinite loops" in the parser, or at > least loops that I was too impatient to wait to finish (5 minutes is too > long to wait for a parser to finish parsing something). I found the > problem: I was attempting to recursively aggregate complex strings in > the parser, and the backtracking became too complex for it to handle. > So, I removed the aggregation step, instead just showing the individual > portions of the strings. Aggregation will be handled by the C++ > implementation (which has to do other things with variable expansions in > strings, etc). So that was a major problem solved, and it tuned the > performance of the parser quite nicely. > > The last thing I needed to do was get a language agnostic grammar. C++ > already has functions like exp, and bitor, bitxor, and bitand are C++ > keywords. The runtime doesn't do anything to fix/catch any of this. As > such I had to go back and do that manually. However, the changes I made > seemed to make it a grammar that was easier to read. > > > This week is mostly setup and input. I'm writing a big bash script that > demonstrates all the features that the grammar supports, and will be > sending the resulting AST to the bash upstream mailing list and the > portage_devs mailing list to see if they have suggestions. I'm also > going to scour man bash for missing features, set up the build system > for the libbash portion of the code (most likely cmake), Implement a > very simple bash builtin (echo), and finally implement a symbol table. > A busy week, but a week that should leave me in excellent shape for the > rest of the project. If it has to be used in portage please: - use autotools or ask for help about using them. - consider staying on plain C as much as possible, breakage in C++ software because of tiny differences in the stdc++ runtime are a constant and portage must survive them. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero