From MAILER-DAEMON Thu Jul 06 20:56:24 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Fyeds-0003rc-FY for mharc-bug-bison@gnu.org; Thu, 06 Jul 2006 20:56:24 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fyedq-0003qD-UE for bug-bison@gnu.org; Thu, 06 Jul 2006 20:56:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fyedo-0003o2-Eo for bug-bison@gnu.org; Thu, 06 Jul 2006 20:56:21 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fyedo-0003ns-7I for bug-bison@gnu.org; Thu, 06 Jul 2006 20:56:20 -0400 Received: from [67.95.107.114] (helo=mail1.thewrittenword.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fyee6-0006F4-QK for bug-bison@gnu.org; Thu, 06 Jul 2006 20:56:38 -0400 Received: by mail1.thewrittenword.com (Postfix, from userid 1000) id 02E3C28C; Thu, 6 Jul 2006 19:56:19 -0500 (CDT) Date: Thu, 6 Jul 2006 19:56:18 -0500 From: Albert Chin To: bug-bison@gnu.org Message-ID: <20060707005618.GA74336@mail1.thewrittenword.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: bison 2.3 test report X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bug-bison@gnu.org List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2006 00:56:23 -0000 We've built bison-2.3 on a number of platforms with the native C, C++ compiler. All tests passed. Solaris 2.6/SPARC: 137 tests were successful. 21 tests were skipped. Solaris 7/SPARC: 148 tests were successful. 10 tests were skipped. Solaris 8/SPARC, 9/SPARC, 10/SPARC, 10/x86: 151 tests were successful. 7 tests were skipped. HP-UX 10.20: 142 tests were successful. 16 tests were skipped. HP-UX 11.00, 11.11: 137 tests were successful. 21 tests were skipped. HP-UX 11.23/PA, 11.23/IA: 140 tests were successful. 18 tests were skipped. AIX 4.3.3: 140 tests were successful. 18 tests were skipped. AIX 5.1, 5.2, 5.3: 151 tests were successful. 7 tests were skipped. Tru64 UNIX 4.0D, 5.1: 148 tests were successful. 10 tests were skipped. IRIX 6.5: 151 tests were successful. 7 tests were skipped. Redhat 7.1, RHEL 2.1/x86 (with gcc-3.4.3): 156 tests were successful. 2 tests were skipped. Redhat 9, RHEL 3/x86, 3/amd64, 4/x86, 4/amd64: All 158 tests were successful. -- albert chin (china@thewrittenword.com) From MAILER-DAEMON Fri Jul 07 03:21:47 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Fykep-0005xM-AN for mharc-bug-bison@gnu.org; Fri, 07 Jul 2006 03:21:47 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fyken-0005vS-PU for bug-bison@gnu.org; Fri, 07 Jul 2006 03:21:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fykei-0005pw-TC for bug-bison@gnu.org; Fri, 07 Jul 2006 03:21:45 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fykei-0005pt-R6 for bug-bison@gnu.org; Fri, 07 Jul 2006 03:21:40 -0400 Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fykf5-0001Zp-8d for bug-bison@gnu.org; Fri, 07 Jul 2006 03:22:03 -0400 Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by kiwi.cs.ucla.edu (8.11.7p2+Sun/8.11.7/UCLACS-5.2) with ESMTP id k677Ld919870 for ; Fri, 7 Jul 2006 00:21:39 -0700 (PDT) Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1Fykeh-0007fb-Gr for bug-bison@gnu.org; Fri, 07 Jul 2006 00:21:39 -0700 To: bug-bison@gnu.org References: <20060707005618.GA74336@mail1.thewrittenword.com> From: Paul Eggert Date: Fri, 07 Jul 2006 00:21:39 -0700 In-Reply-To: <20060707005618.GA74336@mail1.thewrittenword.com> (Albert Chin's message of "Thu, 6 Jul 2006 19:56:18 -0500") Message-ID: <87ejwxop6k.fsf@penguin.cs.ucla.edu> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: bison 2.3 test report X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2006 07:21:46 -0000 Thanks for doing all those tests, and reporting the results. From MAILER-DAEMON Tue Jul 11 04:13:32 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G0DN6-0005Zl-7V for mharc-bug-bison@gnu.org; Tue, 11 Jul 2006 04:13:32 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fztky-0007ZA-EN for bug-bison@gnu.org; Mon, 10 Jul 2006 07:16:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fztkx-0007Yv-FS for bug-bison@gnu.org; Mon, 10 Jul 2006 07:16:52 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fztkx-0007Ym-8i for bug-bison@gnu.org; Mon, 10 Jul 2006 07:16:51 -0400 Received: from [207.172.157.102] (helo=smtp02.lnh.mail.rcn.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Fztm1-0002O7-Tx for bug-bison@gnu.org; Mon, 10 Jul 2006 07:17:58 -0400 Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 10 Jul 2006 07:16:53 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id LUZ27147; Mon, 10 Jul 2006 07:16:45 -0400 (EDT) Received: from 207-237-215-235.c3-0.80w-ubr16.nyr-80w.ny.cable.rcn.com (HELO [127.0.0.1]) ([207.237.215.235]) by smtp01.lnh.mail.rcn.net with ESMTP; 10 Jul 2006 07:16:45 -0400 X-IronPort-AV: i="4.06,223,1149480000"; d="scan'208"; a="236050680:sNHT21499782" Message-ID: <44B2371A.3080602@ajrh.net> Date: Mon, 10 Jul 2006 07:16:42 -0400 From: Anthony Heading User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: bug-bison@gnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/300, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.44B234DC.0005,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.4/2006-05-04 X-Mailman-Approved-At: Tue, 11 Jul 2006 04:13:31 -0400 Subject: trying out the c++ parser skeleton / b4_post_prologue X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jul 2006 11:16:52 -0000 Hi, Using a couple of hours on an airplane, I tried switching some of my code to use the lalr1.cc c++ skeleton. It seems natural to subclass the generated parser object, which requires prologue code to be inserted _after_ the generated parser declaration. The right point appears to be the b4_post_prologue macro, but bizarrely this seems to be inaccessible unless the parser uses %union. src/reader.c:576 /*----------------------------------------------------------------. | There are two prologues: one before %union, one after. Augment | | the current one. | `----------------------------------------------------------------*/ As proof-of-principle, I created a new directive (naturally called "%no-union"!) which only flipped the prologue. That seemed to work OK, but I wonder if there's a better solution? Anthony From MAILER-DAEMON Tue Jul 11 11:29:47 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G0KBH-0008JW-Ik for mharc-bug-bison@gnu.org; Tue, 11 Jul 2006 11:29:47 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G0KBF-0008Iz-GD for bug-bison@gnu.org; Tue, 11 Jul 2006 11:29:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G0KBD-0008IV-ON for bug-bison@gnu.org; Tue, 11 Jul 2006 11:29:45 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G0KBD-0008IQ-JF for bug-bison@gnu.org; Tue, 11 Jul 2006 11:29:43 -0400 Received: from [130.127.200.32] (helo=ces.clemson.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G0KCY-0002vE-HN for bug-bison@gnu.org; Tue, 11 Jul 2006 11:31:06 -0400 Received: from unixlab02.ces.clemson.edu (unixlab02.ces.clemson.edu [130.127.220.152]) by ces.clemson.edu (8.13.6/8.13.6) with ESMTP id k6BFT9uk003650; Tue, 11 Jul 2006 11:29:20 -0400 (EDT) Received: from localhost (jdenny@localhost) by unixlab02.ces.clemson.edu (8.9.3/8.9.3) with ESMTP id LAA22595; Tue, 11 Jul 2006 11:29:09 -0400 (EDT) X-Authentication-Warning: unixlab02.ces.clemson.edu: jdenny owned process doing -bs Date: Tue, 11 Jul 2006 11:29:09 -0400 (EDT) From: "Joel E. Denny" To: Anthony Heading In-Reply-To: <44B2371A.3080602@ajrh.net> Message-ID: References: <44B2371A.3080602@ajrh.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.45 Cc: bug-bison@gnu.org Subject: Re: trying out the c++ parser skeleton / b4_post_prologue X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 15:29:45 -0000 On Mon, 10 Jul 2006, Anthony Heading wrote: > The right point appears to be the b4_post_prologue macro, > but bizarrely this seems to be inaccessible unless the > parser uses %union. Thanks for the feedback. We've been debating how to clean this behavior up. A solution is actually implemented in CVS, but I'm not sure if that one will stick. You should see some sort of solution in Bison 2.4. Joel From MAILER-DAEMON Tue Jul 11 17:32:11 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G0Ppy-0002UC-TU for mharc-bug-bison@gnu.org; Tue, 11 Jul 2006 17:32:10 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G0Ppx-0002U4-9Y for bug-bison@gnu.org; Tue, 11 Jul 2006 17:32:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G0Ppu-0002Tp-OD for bug-bison@gnu.org; Tue, 11 Jul 2006 17:32:08 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G0Ppu-0002Tm-Kt for bug-bison@gnu.org; Tue, 11 Jul 2006 17:32:06 -0400 Received: from [81.228.8.83] (helo=pne-smtpout1-sn2.hy.skanova.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G0PrJ-0007oy-4D for bug-bison@gnu.org; Tue, 11 Jul 2006 17:33:33 -0400 Received: from [83.250.195.81] (83.250.195.81) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) (authenticated as u83812478) id 44A2E86F0029DA14; Tue, 11 Jul 2006 23:31:47 +0200 In-Reply-To: References: <44B2371A.3080602@ajrh.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hans Aberg Date: Tue, 11 Jul 2006 23:31:45 +0200 To: Joel E. Denny X-Mailer: Apple Mail (2.752.2) Cc: Anthony Heading , bug-bison@gnu.org Subject: Re: trying out the c++ parser skeleton / b4_post_prologue X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 21:32:09 -0000 On 11 Jul 2006, at 17:29, Joel E. Denny wrote: > On Mon, 10 Jul 2006, Anthony Heading wrote: > >> The right point appears to be the b4_post_prologue macro, >> but bizarrely this seems to be inaccessible unless the >> parser uses %union. > > Thanks for the feedback. We've been debating how to clean this > behavior > up. http://www.wsu.edu/~brians/errors/churchill.html > A solution is actually implemented in CVS, but I'm not sure if that > one will stick. You should see some sort of solution in Bison 2.4. >> As proof-of-principle, I created a new directive (naturally >> called "%no-union"!) which only flipped the prologue. That >> seemed to work OK, but I wonder if there's a better solution? The developers are currently settling for very simple C++, and there is little chance you will be able to do normal C++ code writing via Bison 2.4 or whatever. There is an experimental %define directive which can be used to place C++ code correctly, some time in the future when it can be used to place code, except for 1-liners. So you (Anthony Heading) are on right track: one needs a way to place code more accurately in order to do C++. In fact, I have made my own tweaks of Bison for last couple of years in order to place the C++ code correctly. :-) But I got tired of patching up the many frequent Bison releases, so I am currently stuck with Bison 2.0. And when you use %union, the underlying C++ implementation must currently be untyped, not something that one would use in ordinary C+ + programming. Hans Aberg From MAILER-DAEMON Wed Jul 12 03:13:16 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G0YuK-0000Ou-5W for mharc-bug-bison@gnu.org; Wed, 12 Jul 2006 03:13:16 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G0YuI-0000Nb-DT for bug-bison@gnu.org; Wed, 12 Jul 2006 03:13:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G0YuG-0000NP-OO for bug-bison@gnu.org; Wed, 12 Jul 2006 03:13:14 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G0YuG-0000NM-L2 for bug-bison@gnu.org; Wed, 12 Jul 2006 03:13:12 -0400 Received: from [62.39.139.2] (helo=kualalumpur.lrde.epita.fr) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G0Yvk-0000YV-R1 for bug-bison@gnu.org; Wed, 12 Jul 2006 03:14:45 -0400 Received: from nostromo.lrde.epita.fr ([192.168.101.52]) by kualalumpur.lrde.epita.fr with esmtp (Exim 4.50) id 1G0YuE-0005wZ-Qp; Wed, 12 Jul 2006 09:13:10 +0200 From: Akim Demaille To: Anthony Heading References: <44B2371A.3080602@ajrh.net> Date: Wed, 12 Jul 2006 09:13:10 +0200 In-Reply-To: <44B2371A.3080602@ajrh.net> (Anthony Heading's message of "Mon, 10 Jul 2006 07:16:42 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bug-bison@gnu.org Subject: Re: trying out the c++ parser skeleton / b4_post_prologue X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 07:13:14 -0000 >>> "Anthony" == Anthony Heading writes: > Hi, > Using a couple of hours on an airplane, I tried switching > some of my code to use the lalr1.cc c++ skeleton. It seems > natural to subclass the generated parser object, Could you please detail why you'd like to do that? For several reasons, including recursion support, I think the proper way to extend the parser is to couple it with a parsing driver. See http://www.gnu.org/software/bison/manual/html_mono/bison.html#A-Complete-C_002b_002b-Example for an example. From MAILER-DAEMON Wed Jul 12 09:23:51 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G0egw-00088p-Ug for mharc-bug-bison@gnu.org; Wed, 12 Jul 2006 09:23:50 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G0egu-00084E-Rm for bug-bison@gnu.org; Wed, 12 Jul 2006 09:23:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G0egs-00080Z-Mo for bug-bison@gnu.org; Wed, 12 Jul 2006 09:23:48 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G0egs-00080I-HD for bug-bison@gnu.org; Wed, 12 Jul 2006 09:23:46 -0400 Received: from [207.172.157.102] (helo=smtp02.lnh.mail.rcn.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G0eiQ-0004So-0t for bug-bison@gnu.org; Wed, 12 Jul 2006 09:25:22 -0400 Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 12 Jul 2006 09:22:57 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id LVM46233; Wed, 12 Jul 2006 09:22:44 -0400 (EDT) Received: from 207-237-215-235.c3-0.80w-ubr16.nyr-80w.ny.cable.rcn.com (HELO [127.0.0.1]) ([207.237.215.235]) by smtp01.lnh.mail.rcn.net with ESMTP; 12 Jul 2006 09:22:44 -0400 X-IronPort-AV: i="4.06,234,1149480000"; d="scan'208"; a="237389837:sNHT35473296" Message-ID: <44B4F7A1.4030009@ajrh.net> Date: Wed, 12 Jul 2006 09:22:41 -0400 From: Anthony Heading User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Akim Demaille References: <44B2371A.3080602@ajrh.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/300, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090207.44B4F55A.002A,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.4/2006-05-04 Cc: Anthony Heading , bug-bison@gnu.org Subject: Re: trying out the c++ parser skeleton / b4_post_prologue X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 13:23:49 -0000 Akim Demaille wrote: > Could you please detail why you'd like to do that? For several > reasons, including recursion support, I think the proper way to extend > the parser is to couple it with a parsing driver. Yes, I did read the example in the docs, and thought it an odd design. Perhaps you also could expand on those reasons - here are my thoughts as an end-user. First, it is very natural in C++ for a programmer to link in some types of application-specific code by providing an implementation of an abstract interface. See e.g. Stroustrup C++PL ch. 24, MFC, Qt, etc. I was surprised to find, for example, that in this bison-c++, the interface to the lexer is not created as an abstract virtual function for the end-programmer to implement, but instead remains a C macro. Obviously this isn't wrong per se, but there has been a decade of aggregate common thinking (agree with it or not) about how ideally C++ code should differ from C, and the bison-c++ design differs enough in many areas from this convergence of practice that I found it unintuitive and hard to use. Therefore I chose to ignore the documentation example, and instead read the skeleton source code. Your parsing-driver suggestion leads the semantic action code to be filled with references to a driver handle. | TOKEN_IDENTIFIER { $$ = driver.variables[*$1]; } This is the main reason for my attempt to subclass. To me, this is unacceptable - the programmer should totally own the scope in which the semantic actions are being executed. Yacc has always allowed this. But in C++, there is the huge benefit that this scope can transparently be an _instance_ of a parser, which surely is a great tool to solve many of the recursion problems. If I were starting again, I would flip your parser/parsing-driver relationship, and have the semantic action code generated within the scope of the parsing driver, i.e. within the scope of a user-extensible class which maintains the semantic state. I would certainly make bison not the user do the boilerplate work: e.g. "$1" conceptually can be automatically expanded to "yy_parser_instance_->yysemantic_stack_[1]" so that bison reaches out to find the parser class, the user isn't required to reach to find his driver via e.g "driver.variables". But then I'd go further to suggest that the parser-driver should inherit from the parser rather than being in a strange peer relationship, because there's enormous support within the C++ language for that type of design. But probably we're not starting again, so I'm not sure what to suggest. I've spent another couple of hours this morning studying the code while composing this response, and I begin to understand the frustration expressed by e.g. Hans. So in my now somewhat- considered view, the current C++ skeleton is a poor design, and I'm inclined not to use it. That's a bit troublesome though, because a non-POD C++ YYSTYPE is a very desirable thing, and I don't believe that works fully with the C parser. And as Hans mentions, bison isn't static enough for a user to maintain their own skeleton. Hmm... Thanks for the responses. Rgds Anthony From MAILER-DAEMON Wed Jul 12 10:19:49 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G0fZ7-000155-PA for mharc-bug-bison@gnu.org; Wed, 12 Jul 2006 10:19:49 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G0fZ5-00012S-NO for bug-bison@gnu.org; Wed, 12 Jul 2006 10:19:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G0fZ5-00011p-1R for bug-bison@gnu.org; Wed, 12 Jul 2006 10:19:47 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G0fZ4-00011g-UR for bug-bison@gnu.org; Wed, 12 Jul 2006 10:19:46 -0400 Received: from [62.39.139.2] (helo=kualalumpur.lrde.epita.fr) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G0fad-00007T-2A for bug-bison@gnu.org; Wed, 12 Jul 2006 10:21:23 -0400 Received: from nostromo.lrde.epita.fr ([192.168.101.52]) by kualalumpur.lrde.epita.fr with esmtp (Exim 4.50) id 1G0fZ3-0003qq-54; Wed, 12 Jul 2006 16:19:45 +0200 From: Akim Demaille To: Anthony Heading References: <44B2371A.3080602@ajrh.net> <44B4F7A1.4030009@ajrh.net> Date: Wed, 12 Jul 2006 16:19:44 +0200 In-Reply-To: <44B4F7A1.4030009@ajrh.net> (Anthony Heading's message of "Wed, 12 Jul 2006 09:22:41 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Heading , bug-bison@gnu.org Subject: Re: trying out the c++ parser skeleton / b4_post_prologue X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 14:19:48 -0000 >>> "Anthony" == Anthony Heading writes: hi Anthony, > Akim Demaille wrote: >> Could you please detail why you'd like to do that? For several >> reasons, including recursion support, I think the proper way to extend >> the parser is to couple it with a parsing driver. > Yes, I did read the example in the docs, and thought it an odd design. > Perhaps you also could expand on those reasons The main reason is to provide a reentrant parser, and that requires a lot of interaction with the rest of the environment. It proved to be much simpler that capture the environment within the so-called driver, which is passed to the parser. Another issue was how to pass additional members to the parser, so that they could be used in the user actions. Trying to extend the parser class directly is difficult and does not fit nicely with the current interface (in particular because one has to extend the constructor of the parser with constructors to the new members). Obviously you can't add these new members in a subclass, since the user actions are run in the superclass. There was a time when we provided the user with a means to define a *superclass* of the parser class, letting him initialize his members this way. But it was also very inconvenient. In the end, after having tried several approaches, the driver pattern proved to be not only simpler, but also much more flexible and more powerful. Until very recently, there were still scares from this time when, trying to pay for the indirection, we planned on using a more STL-like interface: various traits. These guys were a problem for someone willing to subclass. But they are no longer there, si it *might* be feasible to subclass. But why in the very files? What's wrong with subclassing in subparser.{hh,cc}? > - here are my thoughts as an end-user. > First, it is very natural in C++ for a programmer to link in some > types of application-specific code by providing an implementation of > an abstract interface. See e.g. Stroustrup C++PL ch. 24, MFC, Qt, etc. > I was surprised to find, for example, that in this bison-c++, the > interface to the lexer is not created as an abstract virtual function > for the end-programmer to implement, but instead remains a C macro. Right. Valid or not, the point was simply to avoid an indirection. Generated parsers are expected to run fast, and it seemed like a waste to subclass for yylex alone. By I nevertheless agree that this is not nice. > Obviously this isn't wrong per se, but there has been a decade of > aggregate common thinking (agree with it or not) about how ideally > C++ code should differ from C, and the bison-c++ design differs > enough in many areas from this convergence of practice that I found > it unintuitive and hard to use. Therefore I chose to ignore the > documentation example, and instead read the skeleton source code. OK. > Your parsing-driver suggestion leads the semantic action code to be > filled with references to a driver handle. | TOKEN_IDENTIFIER { > $$ = driver.variables[*$1]; } > This is the main reason for my attempt to subclass. I explained above why subclassing does not work. > But in C++, there is the huge benefit that this scope can > transparently be an _instance_ of a parser, which surely is a great > tool to solve many of the recursion problems. It is not. As we will move the implement of the push-parser scheme in Bison, you'll see that the parser object maintains state. For each parse, instantiate a new object. > If I were starting again, I would flip your parser/parsing-driver > relationship, and have the semantic action code generated within > the scope of the parsing driver, i.e. within the scope of a > user-extensible class which maintains the semantic state. So what exactly are you proposing? That we generate code for a subclass that the user is expected to write? How is that simpler than the current scheme? Also, in case of recursive parses, while there are several parsers, there is a unique driver. > I would certainly make bison not the user do the boilerplate work: > e.g. "$1" conceptually can be automatically expanded to > "yy_parser_instance_->yysemantic_stack_[1]" so that bison reaches > out to find the parser class, the user isn't required to reach to > find his driver via e.g "driver.variables". But then I'd go > further to suggest that the parser-driver should inherit from the > parser rather than being in a strange peer relationship, because > there's enormous support within the C++ language for that type of > design. A parser driver is not a parser. The relationship here is not subclassing. But you might be referring to some new kind of relationship that would need more description. > But probably we're not starting again, so I'm not sure what to > suggest. I've spent another couple of hours this morning studying > the code while composing this response, and I begin to understand > the frustration expressed by e.g. Hans. So in my now somewhat- > considered view, the current C++ skeleton is a poor design, and > I'm inclined not to use it. OK. If you have concrete suggestions on how to make it more useful without making it useless to some of its users, we'll buy it. > That's a bit troublesome though, because a non-POD C++ YYSTYPE > is a very desirable thing, and I don't believe that works fully > with the C parser. I totally agree on this point. This is real pain in the neck, but currently there is no nice answer to this. Hans makes a proposal which is simply unacceptable in many situations (not everyone wants to have all there semantics values derive from a single base class). Discussion is underway to provide the user with a means to define yystype on his own, and that will implement Hans' proposal. But someday if one has enough time to implement this, what is truly needed to accommodate C++ requirements and its users expectations in this respect, is a stripped down version of variants, allowing not only PODs, but also non-PODs. > And as Hans mentions, bison isn't static enough for a user to > maintain their own skeleton. Hmm... I don't know what static means here. There is one feature that Hans (and I, for one) wants for quite a while now, and that was technically difficult until very recently: %define for code. It is now at hand, and it turns out I have a patch almost ready for it (I have a s/r conflict to kill first). That should provide knowledgeable users with more freedom. Much work needs to be done on the C++ skeletons, and we could use people willing to contribute *code*: - use instead of (at the user's choice) - merge the loc and val stacks, and possibly the state stack too. In fact I think all skeletons should consider this move - propagate Bob Rossi's changes for push parsers - push the contexts to the mergers too From MAILER-DAEMON Wed Jul 12 14:04:03 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G0j47-0001gF-EG for mharc-bug-bison@gnu.org; Wed, 12 Jul 2006 14:04:03 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G0j46-0001fw-FY for bug-bison@gnu.org; Wed, 12 Jul 2006 14:04:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G0j44-0001eH-Mq for bug-bison@gnu.org; Wed, 12 Jul 2006 14:04:01 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G0j44-0001du-H5; Wed, 12 Jul 2006 14:04:00 -0400 Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G0j5e-0002gL-OR; Wed, 12 Jul 2006 14:05:39 -0400 Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by kiwi.cs.ucla.edu (8.11.7p2+Sun/8.11.7/UCLACS-5.2) with ESMTP id k6CI3u908302; Wed, 12 Jul 2006 11:03:56 -0700 (PDT) Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1G0j3z-0004fL-UL; Wed, 12 Jul 2006 11:03:55 -0700 To: Hung Nguyen References: <44B2ACBA.8060801@ahpcrc.org> <34C683A5-D41A-42CE-B6BE-31626451D224@math.su.se> From: Paul Eggert Date: Wed, 12 Jul 2006 11:03:55 -0700 In-Reply-To: <34C683A5-D41A-42CE-B6BE-31626451D224@math.su.se> (Hans Aberg's message of "Wed, 12 Jul 2006 09:40:47 +0200") Message-ID: <87y7uyn1is.fsf@penguin.cs.ucla.edu> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bison Help , bison-patches@gnu.org, bug-bison@gnu.org Subject: Re: problem with installation on cray x1e system X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jul 2006 18:04:02 -0000 Thanks for reporting that, though as Hans Aberg notes it's better to report bugs to bug-bison@gnu.org. I installed the following patch. By the way, I suggest you use Bison 2.3 rather than 2.1, as it should be a bit more reliable. 2006-07-12 Paul Eggert * data/lalr1.cc (YYCDEBUG): Use 'if (yydebug_) (*yycdebug_)' rather than a for-loop that declares a local bool variable. This should work around a compatibility problem with a Cray x1e C++ compiler reported by Hung Nguyen in . The for-loop was introduced in the 2004-11-17 change but I don't know why it was needed. --- data/lalr1.cc 9 Jul 2006 20:36:33 -0000 1.137 +++ data/lalr1.cc 12 Jul 2006 18:00:15 -0000 @@ -336,9 +336,7 @@ b4_defines_if([ #define YYUSE(e) ((void) (e)) /* A pseudo ostream that takes yydebug_ into account. */ -# define YYCDEBUG \ - for (bool yydebugcond_ = yydebug_; yydebugcond_; yydebugcond_ = false) \ - (*yycdebug_) +# define YYCDEBUG if (yydebug_) (*yycdebug_) /* Enable debugging if requested. */ #if YYDEBUG From MAILER-DAEMON Thu Jul 13 07:58:36 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G0zq0-0001u9-59 for mharc-bug-bison@gnu.org; Thu, 13 Jul 2006 07:58:36 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G0zpy-0001to-AJ for bug-bison@gnu.org; Thu, 13 Jul 2006 07:58:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G0zpw-0001tC-FU for bug-bison@gnu.org; Thu, 13 Jul 2006 07:58:33 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G0zpw-0001t5-7T for bug-bison@gnu.org; Thu, 13 Jul 2006 07:58:32 -0400 Received: from [207.172.157.102] (helo=smtp02.lnh.mail.rcn.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G0zrh-0006CA-1a for bug-bison@gnu.org; Thu, 13 Jul 2006 08:00:21 -0400 Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 13 Jul 2006 07:58:35 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id LVR77994; Thu, 13 Jul 2006 07:58:24 -0400 (EDT) Received: from 207-237-215-235.c3-0.80w-ubr16.nyr-80w.ny.cable.rcn.com (HELO [127.0.0.1]) ([207.237.215.235]) by smtp01.lnh.mail.rcn.net with ESMTP; 13 Jul 2006 07:58:25 -0400 X-IronPort-AV: i="4.06,237,1149480000"; d="scan'208"; a="237892785:sNHT24336760" Message-ID: <44B6355B.2030308@ajrh.net> Date: Thu, 13 Jul 2006 07:58:19 -0400 From: Anthony Heading User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Akim Demaille References: <44B2371A.3080602@ajrh.net> <44B4F7A1.4030009@ajrh.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/300, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090206.44B6330C.0042,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.4/2006-05-04 Cc: Anthony Heading , bug-bison@gnu.org Subject: Re: trying out the c++ parser skeleton / b4_post_prologue X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 11:58:34 -0000 Hi Akim, This is very informative - thanks! You wrote: > Obviously you can't add these new members in a subclass, since the > user actions are run in the superclass. Ah - I was certainly assuming a solution to that problem: to achieve what I was aiming for it would be necessary to have the actions run with those members in scope. > In the end, after having tried several approaches, the driver pattern > proved to be not only simpler, but also much more flexible and more > powerful. OK. My complaints are: 1) The pattern is not so intuitive - the simplicity is maybe relative 2) The scope in which the semantic actions run seems to be wasted - it's not utilisable by the end-user for anything except a single "driver" variable. > > I was surprised to find, for example, that in this bison-c++, the > > interface to the lexer is not created as an abstract virtual function > > for the end-programmer to implement, but instead remains a C macro. > > Right. Valid or not, the point was simply to avoid an indirection. Very fair, and I probably agree with that call. I meant it only as an example where following conventions could increase ease-of-use. > Also, in case of recursive parses, while there are several parsers, > there is a unique driver. > [...] > A parser driver is not a parser. The relationship here is not > subclassing. But you might be referring to some new kind of > relationship that would need more description. OK. I guess there's more than one aspect to this. Specifically, I want to access the token table parser::yytname_[] from my "driver" code. This variable with many others are declared as private members, which is a bit extreme given that they're fully accessible in a C parser. With a nod to the benefits of encapsulation, I compromised by changing the skeleton to make everything protected, which admittedly begs the question as to the need to subclass :-). But anyway, there's a lot of such useful static data which it's nice to be able to bring into scope in the way that an inheritance relationship provides. I understand that recursive parsing demands that much of the parser state exists in a many-to-one relationship with the user state. It wasn't that type of parser data that I was thinking to inherit. > So what exactly are you proposing? That we generate code for a > subclass that the user is expected to write? How is that simpler than > the current scheme? Hmm. Well, I'm wanting user actions to run in the context of the user- controlled state, so I suppose I'm thinking that bison should write out an implementation of a member function e.g. MyDriver::parse(). The user probably has to declare that himself. The question of inheritance is perhaps only an implementation artifact. If bison were supposed to generate parsing code that would compile within a user's class MyDriver, maybe that might be made easier if MyDriver were required to inherit from a bison-generated base class, which could simultaneously make available info like e.g. the token table, but perhaps some other data too. (Does e.g. the debug level need to be parser-instance specific for recursive parsers?). Obviously though such an infrastructure class is not "the parser" in the way that term is currently used. Is this simpler than the current scheme? Well, to me, yes: the idea of filling in slots in a single user-visible hierarchy is simpler than setting up a parser <-> parser driver pairing. But simplicity is all eye of the beholder, of course. And then maybe this doesn't work at all for some reason... > There is one feature that Hans (and I, for one) wants for quite a > while now, and that was technically difficult until very recently: > %define for code. It is now at hand, and it turns out I have a patch > almost ready for it (I have a s/r conflict to kill first). That > should provide knowledgeable users with more freedom. I'll look forward to that. Regards Anthony From MAILER-DAEMON Thu Jul 13 08:39:08 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G10TE-0004Je-7s for mharc-bug-bison@gnu.org; Thu, 13 Jul 2006 08:39:08 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G10TC-0004JO-QU for bug-bison@gnu.org; Thu, 13 Jul 2006 08:39:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G10TB-0004J9-PX for bug-bison@gnu.org; Thu, 13 Jul 2006 08:39:06 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G10TB-0004J5-Kr for bug-bison@gnu.org; Thu, 13 Jul 2006 08:39:05 -0400 Received: from [62.39.139.2] (helo=kualalumpur.lrde.epita.fr) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G10Uw-00029s-Mm for bug-bison@gnu.org; Thu, 13 Jul 2006 08:40:55 -0400 Received: from nostromo.lrde.epita.fr ([192.168.101.52]) by kualalumpur.lrde.epita.fr with esmtp (Exim 4.50) id 1G10T9-0004pl-QQ; Thu, 13 Jul 2006 14:39:03 +0200 From: Akim Demaille To: Anthony Heading References: <44B2371A.3080602@ajrh.net> <44B4F7A1.4030009@ajrh.net> <44B6355B.2030308@ajrh.net> Date: Thu, 13 Jul 2006 14:39:03 +0200 In-Reply-To: <44B6355B.2030308@ajrh.net> (Anthony Heading's message of "Thu, 13 Jul 2006 07:58:19 -0400") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Heading , bug-bison@gnu.org Subject: Re: trying out the c++ parser skeleton / b4_post_prologue X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 12:39:07 -0000 >>> "Anthony" == Anthony Heading writes: >> Obviously you can't add these new members in a subclass, since the >> user actions are run in the superclass. > Ah - I was certainly assuming a solution to that problem: to achieve > what I was aiming for it would be necessary to have the actions run > with those members in scope. But I can't see elegant means to achieve this. > OK. My complaints are: > 1) The pattern is not so intuitive - the simplicity is maybe relative Well, the pattern is mostly useful if you want to do sophisticate things, otherwise use a plain "context" is quite straightforward. > 2) The scope in which the semantic actions run seems to be wasted > - it's not utilisable by the end-user for anything except a single > "driver" variable. What do you propose? > OK. I guess there's more than one aspect to this. Specifically, I > want to access the token table parser::yytname_[] from my "driver" > code. This variable with many others are declared as private > members, which is a bit extreme given that they're fully accessible > in a C parser. This is because I believe this "feature" was never designed, it just "happened". I'd much prefer to understand what are the concrete needs from the user, and fulfill them via a call to an interface rather than exposing implementation details. yytname is a nice example of what, imho, should not have been documented. Rather, the function that is in the documentation for (i = 0; i < YYNTOKENS; i++) @{ if (yytname[i] != 0 && yytname[i][0] == '"' && ! strncmp (yytname[i] + 1, token_buffer, strlen (token_buffer)) && yytname[i][strlen (token_buffer) + 1] == '"' && yytname[i][strlen (token_buffer) + 2] == 0) break; @} should be provided. The user shouldn't have to copy it, it should be provided. > With a nod to the benefits of encapsulation, I compromised by > changing the skeleton to make everything protected, which > admittedly begs the question as to the need to subclass :-). I'm not eager to bind myself to implementation details. If something smarter than an array could be used, I'd be sad to be bound to it because of a public or protected. My strategy is more to look for the use cases, and them design the interface that suits them. I've been working for years on Autoconf where far too much of the internals had been exposed, requiring huge effort from the maintainers to try to maintain backward compatibility while still addressing bugs or fixing bad details. "By default private" is now my motto. > But anyway, there's a lot of such useful static data which it's > nice to be able to bring into scope in the way that an inheritance > relationship provides. Such as? > Hmm. Well, I'm wanting user actions to run in the context of the user- > controlled state, so I suppose I'm thinking that bison should write > out an implementation of a member function e.g. MyDriver::parse(). > The user probably has to declare that himself. A driver is not needed to run bison. There is none for the simple calculator for instance. I'm not willing to make the basic example more complex to make the complex one slightly simpler. And actually, the driver pattern is just what it is: a pattern, a suggestion. The user is free to do differently! Including several members. >> There is one feature that Hans (and I, for one) wants for quite a >> while now, and that was technically difficult until very recently: >> %define for code. > I'll look forward to that. Committed this morning. 2006-07-13 Akim Demaille Support %define "KEY" {VALUE}. * src/scan-code.h, src/scan-code.l (translate_action) (translate_rule_action, translate_symbol_action, translate_code): Return char *, not const char *. * src/parse-gram.y (declaration): Rename as... (prologue_declaration): this. (string_content): Remove this nonterminal, use STRING. (braceless, content, content.opt): New nonterminal. Use them. (%define): Now accept content.opt, i.e., accept also BRACED_CODE as value. * src/scan-gram.l (getargs.h): Don't include it. From MAILER-DAEMON Thu Jul 13 09:35:10 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G11LS-0000rp-91 for mharc-bug-bison@gnu.org; Thu, 13 Jul 2006 09:35:10 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G11LR-0000qq-BD for bug-bison@gnu.org; Thu, 13 Jul 2006 09:35:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G11LP-0000p4-GR for bug-bison@gnu.org; Thu, 13 Jul 2006 09:35:09 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G11LP-0000os-BQ for bug-bison@gnu.org; Thu, 13 Jul 2006 09:35:07 -0400 Received: from [207.172.157.102] (helo=smtp02.lnh.mail.rcn.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G11NA-0006Fs-W4 for bug-bison@gnu.org; Thu, 13 Jul 2006 09:36:57 -0400 Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 13 Jul 2006 09:35:08 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.7.5a-GA) with ESMTP id LVS21014; Thu, 13 Jul 2006 09:34:56 -0400 (EDT) Received: from 207-237-215-235.c3-0.80w-ubr16.nyr-80w.ny.cable.rcn.com (HELO [127.0.0.1]) ([207.237.215.235]) by smtp01.lnh.mail.rcn.net with ESMTP; 13 Jul 2006 09:34:57 -0400 X-IronPort-AV: i="4.06,237,1149480000"; d="scan'208"; a="237934559:sNHT24542142" Message-ID: <44B64BFF.2010601@ajrh.net> Date: Thu, 13 Jul 2006 09:34:55 -0400 From: Anthony Heading User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Akim Demaille References: <44B2371A.3080602@ajrh.net> <44B4F7A1.4030009@ajrh.net> <44B6355B.2030308@ajrh.net> In-Reply-To: <44B6355B.2030308@ajrh.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/300, host=mr02.lnh.mail.rcn.net X-Junkmail-SD-Raw: score=unknown, refid=str=0001.0A090201.44B649AC.0053,ss=1,fgs=0, ip=207.172.4.11, so=2006-05-09 23:27:51, dmn=5.2.4/2006-05-04 Cc: Anthony Heading , bug-bison@gnu.org Subject: Re: trying out the c++ parser skeleton / b4_post_prologue X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jul 2006 13:35:09 -0000 Akim Demaille wrote: > But I can't see elegant means to achieve this. > [...] > What do you propose? Well, as you mention below, I was thinking of an approach where the semantic action code is created as a member function of a user class. But I would concur it comes with problems of its own and might be inelegant, even if the end result would be good. > exposing implementation details. yytname is a nice example of what, > imho, should not have been documented. Rather, the function that is > in the documentation > [...] > for (i = 0; i < YYNTOKENS; i++) > @{ > if (yytname[i] != 0 > && yytname[i][0] == '"' > && ! strncmp (yytname[i] + 1, token_buffer, > strlen (token_buffer)) > && yytname[i][strlen (token_buffer) + 1] == '"' > && yytname[i][strlen (token_buffer) + 2] == 0) > break; > @} > > should be provided. The user shouldn't have to copy it, it should be > provided. I don't agree here. A raw array is a good interface. For example, I want read it once and build my own hash table of tokens. That's hard if the data is hidden behind some arbitrary linear-scan search interface. > I'm not eager to bind myself to implementation details. If something > smarter than an array could be used, I'd be sad to be bound to it > because of a public or protected. > > My strategy is more to look for the use cases, and them design the > interface that suits them. Well, there's balance in all things. In the case of the token names and numbers, they are so fundamental that I wonder if it's misguided to believe you can anticipate all the reasonable use-cases with the functional interface approach you suggest above. To break the link with implementation internals, you could just choose to document and make public a different array to that which might be used internally. I obviously don't disagree about exposing internals, but any data tables become much less flexible tools if the bison designers force a particular access algorithm. Rgds Anthony From MAILER-DAEMON Mon Jul 24 00:49:45 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G4sO1-0007sL-A1 for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 00:49:45 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G4sO0-0007rm-BL for bug-bison@gnu.org; Mon, 24 Jul 2006 00:49:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G4sNy-0007r0-Us for bug-bison@gnu.org; Mon, 24 Jul 2006 00:49:43 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4sNy-0007qo-Or for bug-bison@gnu.org; Mon, 24 Jul 2006 00:49:42 -0400 Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G4sOv-00067m-CN; Mon, 24 Jul 2006 00:50:41 -0400 Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by kiwi.cs.ucla.edu (8.11.7p2+Sun/8.11.7/UCLACS-5.2) with ESMTP id k6O4nQ910292; Sun, 23 Jul 2006 21:49:27 -0700 (PDT) Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1G4sNi-0003Z6-HU; Sun, 23 Jul 2006 21:49:26 -0700 To: From: Paul Eggert Date: Sun, 23 Jul 2006 21:49:26 -0700 Message-ID: <8764hnwqsp.fsf@penguin.cs.ucla.edu> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: traduc@traduc.org, bug-gnu-gettext@gnu.org, bug-bison@gnu.org Subject: French translation of Bison runs afoul of gettext 0.15 X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 04:49:44 -0000 I'm having trouble building CVS Bison using GNU gettext 0.15, which was released recently. One issue is that gettext 0.15 rejects the French translation of Bison: http://www.iro.umontreal.ca/translation/teams/PO/fr/bison-runtime-2.3.fr.po with a fatal diagnostic, as follows: rm -f fr.gmo && msgfmt -c --statistics -o fr.gmo fr.po fr.po:79: number of format specifications in 'msgid' and 'msgstr[1]' doe= s not match msgfmt: found 1 fatal error Here's the offending entry: #: src/conflicts.c:520 #, c-format msgid "expected %d reduce/reduce conflict" msgid_plural "expected %d reduce/reduce conflicts" msgstr[0] "attendait 0 conflit par r=C3=A9duction/r=C3=A9duction" msgstr[1] "attendait 0 conflits par r=C3=A9duction/r=C3=A9duction" Could you please fix this, and send email to bug-bison@gnu.org when it's fixed? I'm afraid we'll have to temporarily disable the use of the French translation in the meantime, so that CVS builds work. I'm CC'ing this to bug-gnu-gettext, because it seems to me that the translations are not strictly an error from a printf point of view (ignoring any issue of the correctness of the French), since printf allows formats that do not consume all the arguments. For example, says "If the format is exhausted while arguments remain, the excess arguments shall be evaluated but are otherwise ignored."; this is longstanding practice. So it may make sense to warn about this particular usage, but a fatal error is a bit strong. From MAILER-DAEMON Mon Jul 24 01:00:18 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G4sYE-0000qR-Fd for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 01:00:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G4sYC-0000pR-OK for bug-bison@gnu.org; Mon, 24 Jul 2006 01:00:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G4sYA-0000nX-Py for bug-bison@gnu.org; Mon, 24 Jul 2006 01:00:15 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4sYA-0000nG-CI for bug-bison@gnu.org; Mon, 24 Jul 2006 01:00:14 -0400 Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G4sZB-0006sO-0C for bug-bison@gnu.org; Mon, 24 Jul 2006 01:01:17 -0400 Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by kiwi.cs.ucla.edu (8.11.7p2+Sun/8.11.7/UCLACS-5.2) with ESMTP id k6O509911010; Sun, 23 Jul 2006 22:00:10 -0700 (PDT) Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1G4sY5-0003cs-Qt; Sun, 23 Jul 2006 22:00:09 -0700 To: translation@iro.umontreal.ca From: Paul Eggert Date: Sun, 23 Jul 2006 22:00:09 -0700 Message-ID: <87zmezvbqe.fsf@penguin.cs.ucla.edu> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bug-bison@gnu.org Subject: translation project needs to upgrade to gettext 0.15 X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 05:00:17 -0000 I just now tried the latest GNU gettext (0.15) with the translations for Bison, and ran into problems with 4 translations: fr.po:79: number of format specifications in 'msgid' and 'msgstr[1]' does not match id.po:7: nplurals = 1... id.po:74: ...but some messages have 2 plural forms ms.po:7: nplurals = 1... ms.po:74: ...but some messages have 2 plural forms tr.po:7: nplurals = 1... tr.po:72: ...but some messages have 2 plural forms These are all fatal errors, so CVS Bison won't build. I'll work around the problem temporarily by suppressing these translations by hand, and will notify each translation team about the problem. But it strikes me that the Translation Project should be using gettext 0.15, and should clean out and/or reject translations that are rejected by gettext 0.15. That way, package maintainers won't have to worry about this sort of thing. Just a suggestion. Thanks. From MAILER-DAEMON Mon Jul 24 01:29:12 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G4t0C-00058p-Ow for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 01:29:12 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G4t0A-00058S-R6 for bug-bison@gnu.org; Mon, 24 Jul 2006 01:29:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G4t09-00057z-0s for bug-bison@gnu.org; Mon, 24 Jul 2006 01:29:10 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4t08-00057t-K5 for bug-bison@gnu.org; Mon, 24 Jul 2006 01:29:08 -0400 Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G4t19-0000Kq-Nr for bug-bison@gnu.org; Mon, 24 Jul 2006 01:30:11 -0400 Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by kiwi.cs.ucla.edu (8.11.7p2+Sun/8.11.7/UCLACS-5.2) with ESMTP id k6O5Sk912192; Sun, 23 Jul 2006 22:28:46 -0700 (PDT) Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1G4szm-0004yN-Kc; Sun, 23 Jul 2006 22:28:46 -0700 To: Tedi Heriyanto , , bug-bison@gnu.org Message-Id: From: Paul Eggert Date: Sun, 23 Jul 2006 22:28:46 -0700 Cc: Subject: error in Indonesian translation for Bison X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 05:29:11 -0000 The latest Indonesian translation for Bison at is rejected by GNU gettext 0.15 with the following diagnostic: msgfmt -c --statistics -o id.gmo id.po id.po:7: nplurals = 1... id.po:74: ...but some messages have 2 plural forms msgfmt: found 1 fatal error Here is the offending translation: #: src/conflicts.c:515 #, c-format msgid "expected %d shift/reduce conflict" msgid_plural "expected %d shift/reduce conflicts" msgstr[0] "mengharapkan %d shift/reduce konflik" msgstr[1] "mengharapkan %d shift/reduce konflik" Could you please fix this, and send email to bug-bison@gnu.org when it's fixed? I'm afraid we'll have to temporarily disable the use of this translation in the meantime, so that CVS builds work. Thanks. From MAILER-DAEMON Mon Jul 24 01:32:01 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G4t2v-0005x5-Me for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 01:32:01 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G4t2u-0005wc-Rm for bug-bison@gnu.org; Mon, 24 Jul 2006 01:32:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G4t2s-0005vZ-Me for bug-bison@gnu.org; Mon, 24 Jul 2006 01:31:59 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4t2s-0005vL-I4 for bug-bison@gnu.org; Mon, 24 Jul 2006 01:31:58 -0400 Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G4t3t-0000Va-Lh for bug-bison@gnu.org; Mon, 24 Jul 2006 01:33:01 -0400 Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by kiwi.cs.ucla.edu (8.11.7p2+Sun/8.11.7/UCLACS-5.2) with ESMTP id k6O5Vo912322; Sun, 23 Jul 2006 22:31:51 -0700 (PDT) Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1G4t2k-0004yT-Sx; Sun, 23 Jul 2006 22:31:50 -0700 To: Sharuzzaman Ahmat Raslan , , bug-bison@gnu.org Message-Id: From: Paul Eggert Date: Sun, 23 Jul 2006 22:31:50 -0700 Cc: Subject: error in Malay translation for Bison X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 05:32:01 -0000 The latest Malay translation for Bison at is rejected by GNU gettext 0.15 with the following diagnostic: msgfmt -c --statistics -o ms.gmo ms.po ms.po:7: nplurals = 1... ms.po:74: ...but some messages have 2 plural forms msgfmt: found 1 fatal error Here is the offending translation: #: src/conflicts.c:515 #, c-format msgid "expected %d shift/reduce conflict" msgid_plural "expected %d shift/reduce conflicts" msgstr[0] "jangkaan %d konflik pemindahan/pengurangan" msgstr[1] "jangkaan %d konflik pemindahan/pengurangan" Could you please fix this, and send email to bug-bison@gnu.org when it's fixed? I'm afraid we'll have to temporarily disable the use of this translation in the meantime, so that CVS builds work. Thanks. From MAILER-DAEMON Mon Jul 24 01:38:02 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G4t8k-0001N7-Ib for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 01:38:02 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G4t8j-0001Ls-Ql for bug-bison@gnu.org; Mon, 24 Jul 2006 01:38:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G4t8j-0001Kp-70 for bug-bison@gnu.org; Mon, 24 Jul 2006 01:38:01 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4t8i-0001KP-VO for bug-bison@gnu.org; Mon, 24 Jul 2006 01:38:01 -0400 Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G4t9k-0000sk-41 for bug-bison@gnu.org; Mon, 24 Jul 2006 01:39:04 -0400 Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by kiwi.cs.ucla.edu (8.11.7p2+Sun/8.11.7/UCLACS-5.2) with ESMTP id k6O5be912538; Sun, 23 Jul 2006 22:37:40 -0700 (PDT) Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1G4t8O-0004yW-M8; Sun, 23 Jul 2006 22:37:40 -0700 To: ÃaÄrı Ãöltekin , , bug-bison@gnu.org MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Message-Id: From: Paul Eggert Date: Sun, 23 Jul 2006 22:37:40 -0700 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by kiwi.cs.ucla.edu id k6O5be912538 Cc: Subject: error in Turkish translation for Bison X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 05:38:02 -0000 The latest Turkish translation for Bison at is rejected by GNU gettext 0.15 with the following diagnostic: msgfmt -c --statistics -o tr.gmo tr.po tr.po:7: nplurals =3D 1... tr.po:72: ...but some messages have 2 plural forms msgfmt: found 1 fatal error Here is the first offending translation: #: src/conflicts.c:515 #, c-format msgid "expected %d shift/reduce conflict" msgid_plural "expected %d shift/reduce conflicts" msgstr[0] "%d =C3=B6teleme/indirgeme =C3=A7eli=C5=9Fkisi bekleniyor" msgstr[1] "%d =C3=B6teleme/indirgeme =C3=A7eli=C5=9Fkisi bekleniyor" Could you please fix this, and send email to bug-bison@gnu.org when it's fixed? I'm afraid we'll have to temporarily disable the use of this translation in the meantime, so that CVS builds work. Thanks. From MAILER-DAEMON Mon Jul 24 06:52:47 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G4y3L-0007SA-B8 for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 06:52:47 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G4y3J-0007Q1-M6 for bug-bison@gnu.org; Mon, 24 Jul 2006 06:52:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G4y3H-0007M9-WD for bug-bison@gnu.org; Mon, 24 Jul 2006 06:52:45 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4y3H-0007Lm-SY for bug-bison@gnu.org; Mon, 24 Jul 2006 06:52:43 -0400 Received: from [212.247.154.65] (helo=swip.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G4y4M-000386-2n for bug-bison@gnu.org; Mon, 24 Jul 2006 06:53:50 -0400 X-T2-Posting-ID: 2yF4ydxc0UI9xI7FHZPfog== X-Cloudmark-Score: 0.000000 [] Received: from 83.72.134.122.ip.tele2adsl.dk ([83.72.134.122] verified) by mailfe03.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 247383614 for bug-bison@gnu.org; Mon, 24 Jul 2006 12:52:38 +0200 Content-Disposition: inline From: Frans Englich To: bug-bison@gnu.org Date: Mon, 24 Jul 2006 11:06:34 +0000 User-Agent: KMail/1.8.50 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200607241106.34456.frans.englich@telia.com> Subject: Fwd: %token QUOTE "\"" X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 10:52:45 -0000 Is this a bug in Bison? Cheers, Frans ---------- Forwarded Message ---------- Subject: "Bison Help" oken QUOTE "\"" Date: Friday 21 July 2006 23:18 From: Frans Englich To: "Bison Help" Have a look at these two tokens: %token QUOTE "\"" %token APOS "'" When QUOTE is printed it literally prints: \". It hasn't "un-escaped" when printing, although enough for parsing the grammar at compile time. What is the proper way to print a '"'? (I'm using Bison 2.3.) Cheers, Frans _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison ------------------------------------------------------- From MAILER-DAEMON Mon Jul 24 09:50:16 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G50p6-0008JN-33 for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 09:50:16 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G50p2-0008IY-Qj for bug-bison@gnu.org; Mon, 24 Jul 2006 09:50:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G50p1-0008I0-KP for bug-bison@gnu.org; Mon, 24 Jul 2006 09:50:12 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G50p1-0008Hw-F2 for bug-bison@gnu.org; Mon, 24 Jul 2006 09:50:11 -0400 Received: from [81.80.162.195] (helo=ftp.ilog.fr) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G50q5-0002fT-CA; Mon, 24 Jul 2006 09:51:17 -0400 Received: from laposte.ilog.fr (cerbere-qfe0 [81.80.162.193]) by ftp.ilog.fr (8.13.1/8.13.1) with ESMTP id k6ODnx5n026355; Mon, 24 Jul 2006 15:50:00 +0200 Received: from marbore.ilog.biz (marbore.ilog.biz [172.17.2.61]) by laposte.ilog.fr (8.13.1/8.13.1) with ESMTP id k6ODnrVF015132; Mon, 24 Jul 2006 15:49:53 +0200 Received: from honolulu.ilog.fr ([172.16.15.17]) by marbore.ilog.biz with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Jul 2006 15:50:51 +0200 Received: by honolulu.ilog.fr (Postfix, from userid 1001) id C49B0F142A; Mon, 24 Jul 2006 15:47:19 +0200 (CEST) From: Bruno Haible To: Paul Eggert Date: Mon, 24 Jul 2006 15:47:18 +0200 User-Agent: KMail/1.9.1 References: <8764hnwqsp.fsf@penguin.cs.ucla.edu> In-Reply-To: <8764hnwqsp.fsf@penguin.cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200607241547.19656.bruno@clisp.org> X-OriginalArrivalTime: 24 Jul 2006 13:50:52.0092 (UTC) FILETIME=[2D57CFC0:01C6AF28] Cc: robitail@iro.umontreal.ca, bug-gnu-gettext@gnu.org, bug-bison@gnu.org Subject: Re: French translation of Bison runs afoul of gettext 0.15 X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 13:50:13 -0000 Paul Eggert wrote: > I'm CC'ing this to bug-gnu-gettext, because it seems to me that the > translations are not strictly an error from a printf point of view > (ignoring any issue of the correctness of the French), since printf > allows formats that do not consume all the arguments. For example, > > says "If the format is exhausted while arguments remain, the excess > arguments shall be evaluated but are otherwise ignored."; this is > longstanding practice. So it may make sense to warn about this > particular usage, but a fatal error is a bit strong. It is true that the printf function would not crash if some arguments are passed but not used by the format string. However, these %d directives are meant to give some information to the user. If the English original string shows the precise number of reduce/reduce conflicts, but the translation only shows that there is more than 1, without giving the number, the translation is inadequate. This is why msgfmt gives an error. You will notice that msgfmt didn't complain about msgstr[0]. This is because this case is only used for n=3D0 and n=3D1. Here the translator could have put all relevant information into the string without using %d. #: src/conflicts.c:520 #, c-format msgid "expected %d reduce/reduce conflict" msgid_plural "expected %d reduce/reduce conflicts" msgstr[0] "attendait 0 conflit par r=C3=A9duction/r=C3=A9duction" msgstr[1] "attendait 0 conflits par r=C3=A9duction/r=C3=A9duction" Incidentally this msgstr[0] translation is wrong as well: it says that there were 0 conflicts, but it could be 0 or 1 (according to the Plural-Forms formula in the PO file's header). Bruno From MAILER-DAEMON Mon Jul 24 12:40:59 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G53UJ-00026y-4n for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 12:40:59 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G53UH-00026a-NK for bug-bison@gnu.org; Mon, 24 Jul 2006 12:40:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G53UC-00022D-Bf for bug-bison@gnu.org; Mon, 24 Jul 2006 12:40:56 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G53UC-00021y-6K for bug-bison@gnu.org; Mon, 24 Jul 2006 12:40:52 -0400 Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G53VJ-00055M-QT for bug-bison@gnu.org; Mon, 24 Jul 2006 12:42:02 -0400 Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by kiwi.cs.ucla.edu (8.11.7p2+Sun/8.11.7/UCLACS-5.2) with ESMTP id k6OGem919523; Mon, 24 Jul 2006 09:40:48 -0700 (PDT) Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1G53U8-0003pF-7k; Mon, 24 Jul 2006 09:40:48 -0700 To: "Sharuzzaman Ahmat Raslan" References: <295041390607240816k25357fcbw466ee5a4eb7310b@mail.gmail.com> From: Paul Eggert Date: Mon, 24 Jul 2006 09:40:48 -0700 In-Reply-To: <295041390607240816k25357fcbw466ee5a4eb7310b@mail.gmail.com> (Sharuzzaman Ahmat Raslan's message of "Mon, 24 Jul 2006 23:16:03 +0800") Message-ID: <874px7ufan.fsf@penguin.cs.ucla.edu> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bug-bison@gnu.org Subject: Re: Translation-team-ms post from eggert@cs.ucla.edu requires approval X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 16:40:58 -0000 "Sharuzzaman Ahmat Raslan" writes: > I have fixed the problem, but I don't have gettext 0.15 nearby so I > cannot a full test for this file. I believe I read Bruno's email today > announcing the release of gettext 0.15. Thanks. I see that the fix has not yet propagated into . Will that happen soon? If so, I can test it myself and let you know how it works. From MAILER-DAEMON Mon Jul 24 13:09:18 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G53vi-0004gU-LC for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 13:09:18 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G52Eu-00055M-OC for bug-bison@gnu.org; Mon, 24 Jul 2006 11:21:00 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G52Es-00050t-P1 for bug-bison@gnu.org; Mon, 24 Jul 2006 11:21:00 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G52Es-00050U-Jq for bug-bison@gnu.org; Mon, 24 Jul 2006 11:20:58 -0400 Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G52Fx-0004Jr-Rc; Mon, 24 Jul 2006 11:22:05 -0400 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 3C9822CE9BB; Mon, 24 Jul 2006 11:20:56 -0400 (EDT) Received: from [132.204.27.33] (poseidon.iro.umontreal.ca [132.204.27.33]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id BA975445C; Mon, 24 Jul 2006 11:20:50 -0400 (EDT) Message-ID: <44C4E53C.5030705@iro.umontreal.ca> Date: Mon, 24 Jul 2006 11:20:28 -0400 From: Michel Robitaille User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Paul Eggert References: <8764hnwqsp.fsf@penguin.cs.ucla.edu> In-Reply-To: <8764hnwqsp.fsf@penguin.cs.ucla.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=UTF-8 X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82) X-DIRO-MailScanner-From: robitail@iro.umontreal.ca Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 24 Jul 2006 13:09:17 -0400 Cc: traduc@traduc.org, bug-gnu-gettext@gnu.org, bug-bison@gnu.org Subject: Re: French translation of Bison runs afoul of gettext 0.15 X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 15:21:01 -0000 Hi Paul (You already received the following message) It is now corrected (I was using the previous version of gettext).. The files have been send out. Cheers Best regards Michel Paul Eggert wrote: > I'm having trouble building CVS Bison using GNU gettext 0.15, which > was released recently. One issue is that gettext 0.15 rejects > the French translation of Bison: >=20 > http://www.iro.umontreal.ca/translation/teams/PO/fr/bison-runtime-2.3.f= r.po >=20 > with a fatal diagnostic, as follows: >=20 > rm -f fr.gmo && msgfmt -c --statistics -o fr.gmo fr.po > fr.po:79: number of format specifications in 'msgid' and 'msgstr[1]'= does not match > msgfmt: found 1 fatal error >=20 > Here's the offending entry: >=20 > #: src/conflicts.c:520 > #, c-format > msgid "expected %d reduce/reduce conflict" > msgid_plural "expected %d reduce/reduce conflicts" > msgstr[0] "attendait 0 conflit par r=C3=A9duction/r=C3=A9duction" > msgstr[1] "attendait 0 conflits par r=C3=A9duction/r=C3=A9duction" >=20 > Could you please fix this, and send email to bug-bison@gnu.org when > it's fixed? I'm afraid we'll have to temporarily disable the use of > the French translation in the meantime, so that CVS builds work. >=20 > I'm CC'ing this to bug-gnu-gettext, because it seems to me that the > translations are not strictly an error from a printf point of view > (ignoring any issue of the correctness of the French), since printf > allows formats that do not consume all the arguments. For example, > > says "If the format is exhausted while arguments remain, the excess > arguments shall be evaluated but are otherwise ignored."; this is > longstanding practice. So it may make sense to warn about this > particular usage, but a fatal error is a bit strong. --=20 Chef des laboratoires, DIRO =C2=B0oO=C2=B0[:]-) Coord. : http://www.iro.umontreal.ca/~robitail Cl=C3=A9 PGP: http://www.iro.umontreal.ca/~robitail/pgp/ From MAILER-DAEMON Mon Jul 24 13:09:38 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G53w2-00050y-3w for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 13:09:38 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G52AI-0004Lx-9x for bug-bison@gnu.org; Mon, 24 Jul 2006 11:16:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G52AE-0004Cq-LY for bug-bison@gnu.org; Mon, 24 Jul 2006 11:16:13 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G52AE-0004CD-EY for bug-bison@gnu.org; Mon, 24 Jul 2006 11:16:10 -0400 Received: from [66.249.82.198] (helo=wx-out-0102.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G52BK-0003u9-OF for bug-bison@gnu.org; Mon, 24 Jul 2006 11:17:19 -0400 Received: by wx-out-0102.google.com with SMTP id t5so1208176wxc for ; Mon, 24 Jul 2006 08:16:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Xdnzkh3Ie3dxlBZW+hIFEo5ivu4BbmXZPo0jilbxzYrgHTldiO9DK+jSycn4pQSozlndsWSPcLfnytBKk4n7tchblBQbjvks3UUPIt3+jjkvttqvNpajIdaFp7z/DkfjTNtG2wz3j4rkRuDNvzt8idhvk1HLu7YrgKVQ/0PgFQ0= Received: by 10.70.13.16 with SMTP id 16mr4875094wxm; Mon, 24 Jul 2006 08:16:03 -0700 (PDT) Received: by 10.70.66.19 with HTTP; Mon, 24 Jul 2006 08:16:03 -0700 (PDT) Message-ID: <295041390607240816k25357fcbw466ee5a4eb7310b@mail.gmail.com> Date: Mon, 24 Jul 2006 23:16:03 +0800 From: "Sharuzzaman Ahmat Raslan" To: bug-bison@gnu.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_122133_2502910.1153754163184" References: X-Mailman-Approved-At: Mon, 24 Jul 2006 13:09:36 -0400 Cc: eggert@CS.UCLA.EDU Subject: Re: Translation-team-ms post from eggert@cs.ucla.edu requires approval X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 15:16:14 -0000 ------=_Part_122133_2502910.1153754163184 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello Paul and Bison developers. Thank you for the error report. I have fixed the problem, but I don't have gettext 0.15 nearby so I cannot a full test for this file. I believe I read Bruno's email today announcing the release of gettext 0.15. Please contact me directly through this email address, if you encounter any problem with this translation. Thanks. > ---------- Forwarded message ---------- > From: Paul Eggert > To: Sharuzzaman Ahmat Raslan , , bug-bison@gnu.org > Date: Sun, 23 Jul 2006 22:31:50 -0700 > Subject: error in Malay translation for Bison > The latest Malay translation for Bison at > > is rejected by GNU gettext 0.15 with the following diagnostic: > > msgfmt -c --statistics -o ms.gmo ms.po > ms.po:7: nplurals = 1... > ms.po:74: ...but some messages have 2 plural forms > msgfmt: found 1 fatal error > > Here is the offending translation: > > #: src/conflicts.c:515 > #, c-format > msgid "expected %d shift/reduce conflict" > msgid_plural "expected %d shift/reduce conflicts" > msgstr[0] "jangkaan %d konflik pemindahan/pengurangan" > msgstr[1] "jangkaan %d konflik pemindahan/pengurangan" > > Could you please fix this, and send email to bug-bison@gnu.org when > it's fixed? I'm afraid we'll have to temporarily disable the use of > this translation in the meantime, so that CVS builds work. > > Thanks. > -- Sharuzzaman Ahmat Raslan ------=_Part_122133_2502910.1153754163184 Content-Type: text/x-pofile; name=bison-2.3.ms.po; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Attachment-Id: f_eq0z9hii Content-Disposition: attachment; filename="bison-2.3.ms.po" # Bison Bahasa Melayu (Malay) (ms). # Copyright (C) 2003 Free Software Foundation, Inc. # This file is distributed under the same license as the Bison package. # Sharuzzaman Ahmat Raslan , 2003. # msgid "" msgstr "" "Project-Id-Version: bison 1.875d\n" "Report-Msgid-Bugs-To: bug-bison@gnu.org\n" "POT-Creation-Date: 2006-06-05 00:32-0700\n" "PO-Revision-Date: 2005-03-27 14:50+0800\n" "Last-Translator: Sharuzzaman Ahmat Raslan \n" "Language-Team: Malay \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=3DUTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3D1; plural=3D0;\n" "X-Generator: KBabel 0.9.5\n" #: src/complain.c:53 src/complain.c:68 msgid "warning: " msgstr "amaran: " #: src/complain.c:124 src/complain.c:140 msgid "fatal error: " msgstr "ralat maut: " #: src/conflicts.c:77 #, c-format msgid " Conflict between rule %d and token %s resolved as shift" msgstr " Konflik antara hukum %d dan token %s diselesaikan sebagai pinda= han" #: src/conflicts.c:85 #, c-format msgid " Conflict between rule %d and token %s resolved as reduce" msgstr " Konflik antara hukum %d dan token %s diselesaikan sebagai pengu= rangan" #: src/conflicts.c:92 #, c-format msgid " Conflict between rule %d and token %s resolved as an error" msgstr " Konflik antara hukum %d dan token %s diselesaikan sebagai ralat= " #: src/conflicts.c:400 #, c-format msgid "conflicts: %d shift/reduce, %d reduce/reduce\n" msgstr "konflik: %d pemindahan/pengurangan, %d pengurangan/pengurangan\n" #: src/conflicts.c:403 #, c-format msgid "conflicts: %d shift/reduce\n" msgstr "konflik: %d pemindahan/pengurangan\n" #: src/conflicts.c:405 #, c-format msgid "conflicts: %d reduce/reduce\n" msgstr "konflik: %d pengurangan/pengurangan\n" #: src/conflicts.c:423 #, c-format msgid "State %d " msgstr "Keadaan %d " #: src/conflicts.c:490 #, c-format msgid "%%expect-rr applies only to GLR parsers" msgstr "%%expect-rr hanya berkesan kepada parser GLR" #: src/conflicts.c:515 #, c-format msgid "expected %d shift/reduce conflict" msgid_plural "expected %d shift/reduce conflicts" msgstr[0] "jangkaan %d konflik pemindahan/pengurangan" #: src/conflicts.c:520 #, c-format msgid "expected %d reduce/reduce conflict" msgid_plural "expected %d reduce/reduce conflicts" msgstr[0] "dijangkakan %d pengurangan/pengurangan konflik" #: src/files.c:112 #, c-format msgid "cannot open file `%s'" msgstr "tidak dapat membuka fail `%s'" #: src/files.c:128 msgid "I/O error" msgstr "Ralat I/O" #: src/files.c:131 msgid "cannot close file" msgstr "tidak dapat menutup fail" #: src/files.c:339 #, c-format msgid "conflicting outputs to file %s" msgstr "keluaran berkonflik kepada fail %s" #: src/getargs.c:194 #, c-format msgid "Try `%s --help' for more information.\n" msgstr "Cuba `%s --help' untuk lebih maklumat.\n" #: src/getargs.c:200 msgid "GNU bison generates parsers for LALR(1) grammars.\n" msgstr "GNU bison menjanakan penghurai untuk tatabahasa LALR(1).\n" #: src/getargs.c:204 #, c-format msgid "Usage: %s [OPTION]... FILE\n" msgstr "Penggunaan: %s [PILIHAN]... FAIL\n" #: src/getargs.c:208 msgid "" "If a long option shows an argument as mandatory, then it is mandatory\n" "for the equivalent short option also. Similarly for optional arguments.\n= " msgstr "" "Jika satu pilihan panjang menunjukkan satu hujah sebagai mandatori, oleh i= tu ia\n" "mandatori untuk pilihan pendek sepadan juga. Serupa juga dengan hujah tid= ak wajib.\n" #: src/getargs.c:214 #, fuzzy msgid "" "Operation modes:\n" " -h, --help display this help and exit\n" " -V, --version output version information and exit\n" " --print-localedir output directory containing locale-dependent = data\n" " -y, --yacc emulate POSIX yacc\n" msgstr "" "Mod operasi:\n" " -h, --help papar bantuan ini dan keluar\n" " -V, --version keluarkan maklumat versi dan keluar\n" " -y, --yacc tiru POSIX yacc\n" #: src/getargs.c:222 msgid "" "Parser:\n" " -S, --skeleton=3DFILE specify the skeleton to use\n" " -t, --debug instrument the parser for debugging\n" " --locations enable locations computation\n" " -p, --name-prefix=3DPREFIX prepend PREFIX to the external symbols\n" " -l, --no-lines don't generate `#line' directives\n" " -n, --no-parser generate the tables only\n" " -k, --token-table include a table of token names\n" msgstr "" "Parser:\n" " -S, --skeleton=3DFAIL nyatakan rangka untuk digunakan\n" " -t, --debug peralatan parser untuk nyahpepijat\n" " --locations hidupkan pengiraan lokasi\n" " -p, --name-prefix=3DAWALAN tambah AWALAN kepada simbol luaran\n" " -l, --no-lines jangan jana arahan `#line'\n" " -n, --no-parser jana jadual sahaja\n" " -k, --token-table sertakan jadual nama token\n" #: src/getargs.c:234 msgid "" "Output:\n" " -d, --defines also produce a header file\n" " -r, --report=3DTHINGS also produce details on the automaton\n" " -v, --verbose same as `--report=3Dstate'\n" " -b, --file-prefix=3DPREFIX specify a PREFIX for output files\n" " -o, --output=3DFILE leave output to FILE\n" " -g, --graph also produce a VCG description of the automat= on\n" msgstr "" "Keluaran:\n" " -d, --defines juga hasilkan fail header\n" " -r, --report=3DPERKARA juga hasilkan butir terperinci bagi automat= on\n" " -v, --verbose sama seperti `--report=3Dstate'\n" " -b, --file-prefix=3DAWALAN nyatakan AWALAN untuk fail keluaran\n" " -o, --output=3DFAIL biarkan keluaran kepada FAIL\n" " -g, --graph juga hasilkan huraian VCG bagi automaton\n" #: src/getargs.c:245 #, fuzzy msgid "" "THINGS is a list of comma separated words that can include:\n" " `state' describe the states\n" " `itemset' complete the core item sets with their closure\n" " `look-ahead' explicitly associate look-ahead tokens to items\n" " `solved' describe shift/reduce conflicts solving\n" " `all' include all the above information\n" " `none' disable the report\n" msgstr "" "PERKARA adalah senarai perkataan dipisah koma yang boleh termasuk:\n" " `state' nyatakan keadaan\n" " `itemset' lengkapkan perkara asas dengan penutupnya\n" " `lookahead' dengan jelas kaitkan lookahead kepada perkara\n" " `solved' nyatakan penyelesaian konflik pemindahan/pengurangan\n" " `all' masukkan semua maklumat diatas\n" " `none' matikan laporan\n" #: src/getargs.c:256 msgid "Report bugs to .\n" msgstr "Lapor pepijat kepada .\n" #: src/getargs.c:273 #, c-format msgid "bison (GNU Bison) %s" msgstr "bison (GNU Bison) %s" #: src/getargs.c:275 msgid "Written by Robert Corbett and Richard Stallman.\n" msgstr "Ditulis oleh Robert Corbett dan Richard Stallman.\n" #: src/getargs.c:279 #, c-format msgid "Copyright (C) %d Free Software Foundation, Inc.\n" msgstr "Hakcipta (C) %d Free Software Foundation, Inc.\n" #: src/getargs.c:281 msgid "" "This is free software; see the source for copying conditions. There is NO= \n" "warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE= .\n" msgstr "" "Ini adalah perisian bebas; lihat sumber untuk syarat menyalin. TIADA\n" "jaminan disediakan; tidak juga untuk KEBOLEHDAGANGAN atau KEUPAYAAN UNTUK = SESUATU TUJUAN KHUSUS.\n" #: src/getargs.c:453 #, c-format msgid "missing operand after `%s'" msgstr "operan hilang selepas `%s'" #: src/getargs.c:455 #, c-format msgid "extra operand `%s'" msgstr "operan tambahan `%s'" #: src/gram.c:139 msgid "empty" msgstr "kosong" #: src/gram.c:233 msgid "Grammar" msgstr "Tatabahasa" #: src/gram.c:320 src/reduce.c:395 msgid "warning" msgstr "amaran" #: src/main.c:125 msgid "rule never reduced because of conflicts" msgstr "hukum tidak dikurangkan kerana konflik" #: src/parse-gram.y:548 msgid "missing identifier in parameter declaration" msgstr "pengecam hilang dalam parameter pengisytiharan" #: src/print.c:49 #, c-format msgid " type %d is %s\n" msgstr " jenis %d adalah %s\n" #: src/print.c:165 #, c-format msgid "shift, and go to state %d\n" msgstr "pindah, dan pergi ke keadaan %d\n" #: src/print.c:167 #, c-format msgid "go to state %d\n" msgstr "pergi ke keadaan %d\n" #: src/print.c:204 msgid "error (nonassociative)\n" msgstr "ralat (tidak bergabung)\n" #: src/print.c:292 #, c-format msgid "reduce using rule %d (%s)" msgstr "kurang menggunakan hukum %d (%s)" #: src/print.c:294 #, c-format msgid "accept" msgstr "terima" #: src/print.c:325 src/print.c:391 msgid "$default" msgstr "$default" #: src/print.c:420 #, c-format msgid "state %d" msgstr "keadaan %d" #: src/print.c:456 msgid "Terminals, with rules where they appear" msgstr "Terminal, dengan hukum dimana mereka kelihatan" #: src/print.c:483 msgid "Nonterminals, with rules where they appear" msgstr "Tidak terminal, dengan hukum dimana mereka kelihatan" #: src/print.c:512 #, c-format msgid " on left:" msgstr " pada kiri:" #: src/print.c:527 #, c-format msgid " on right:" msgstr " pada kanan:" #: src/print.c:555 msgid "Rules never reduced" msgstr "Hukum tidak dikurangkan" #: src/reader.c:58 #, c-format msgid "multiple %s declarations" msgstr "pelbagai pengisytiharan %s" #: src/reader.c:120 #, c-format msgid "result type clash on merge function %s: <%s> !=3D <%s>" msgstr "jenis hasil bertelingkah pada fungsi gabung %s: <%s> !=3D <%s>" #: src/reader.c:210 #, c-format msgid "rule given for %s, which is a token" msgstr "hukum diberi untuk %s, dimana ia adalah token" #: src/reader.c:253 #, c-format msgid "type clash on default action: <%s> !=3D <%s>" msgstr "pertelingkahan jenis pada tindakan default: <%s> !=3D <%s>" #: src/reader.c:259 msgid "empty rule for typed nonterminal, and no action" msgstr "hukum kosong untuk bukan terminal ditaip, dan tiada tindakan" #: src/reader.c:273 #, fuzzy, c-format msgid "unused value: $%d" msgstr "nilai tidak sah: %s" #: src/reader.c:275 msgid "unset value: $$" msgstr "" #: src/reader.c:353 src/reader.c:367 src/reader.c:380 #, c-format msgid "only one %s allowed per rule" msgstr "hanya satu %s dibenarkan setiap hukum" #: src/reader.c:363 src/reader.c:378 #, c-format msgid "%s affects only GLR parsers" msgstr "%s hanya berkesan kepada parser GLR" #: src/reader.c:365 #, c-format msgid "%s must be followed by positive number" msgstr "%s mesti diikuti dengan nombor positif" #: src/reader.c:534 msgid "no rules in the input grammar" msgstr "tiada hukum dalam masukan tatabahasa" #: src/reduce.c:243 msgid "useless rule" msgstr "hukum tidak berguna" #: src/reduce.c:304 #, c-format msgid "useless nonterminal: %s" msgstr "bukan terminal tidak berguna: %s" #: src/reduce.c:352 msgid "Useless nonterminals" msgstr "Bukan terminal tidak berguna" #: src/reduce.c:365 msgid "Terminals which are not used" msgstr "Terminal yang tidak digunakan" #: src/reduce.c:374 msgid "Useless rules" msgstr "Hukum tidak berguna" #: src/reduce.c:390 #, c-format msgid "%d rule never reduced\n" msgid_plural "%d rules never reduced\n" msgstr[0] "%d hukum tidak dikurangkan\n" #: src/reduce.c:398 #, c-format msgid "%d useless nonterminal" msgid_plural "%d useless nonterminals" msgstr[0] "%d bukan terminal tidak berguna" #: src/reduce.c:404 #, c-format msgid " and " msgstr " dan " #: src/reduce.c:407 #, c-format msgid "%d useless rule" msgid_plural "%d useless rules" msgstr[0] "%d hukum tidak berguna" #: src/reduce.c:437 #, c-format msgid "start symbol %s does not derive any sentence" msgstr "simbol permulaan %s tidak menghasilkan sebarang perkataan" #: src/scan-gram.l:197 msgid "stray `,' treated as white space" msgstr "`,' sesat dianggap sebagai ruang" #: src/scan-gram.l:261 #, c-format msgid "invalid directive: %s" msgstr "arahan tidak sah: %s" #: src/scan-gram.l:321 #, c-format msgid "invalid character: %s" msgstr "aksara tidak sah: %s" #: src/scan-gram.l:441 msgid "invalid null character" msgstr "aksara null tidak sah" #: src/scan-gram.l:454 src/scan-gram.l:465 src/scan-gram.l:486 #, c-format msgid "invalid escape sequence: %s" msgstr "turutan escape tidak sah: %s" #: src/scan-gram.l:456 src/scan-gram.l:467 src/scan-gram.l:488 #, c-format msgid "invalid null character: %s" msgstr "aksara null tidak sah: %s" #: src/scan-gram.l:493 #, c-format msgid "unrecognized escape sequence: %s" msgstr "turutan escape tidak dikenali: %s" #: src/scan-gram.l:575 #, fuzzy, c-format msgid "missing `{' in %s" msgstr "`(' hilang dalam `%s'" #: src/scan-gram.l:640 msgid "stray `$'" msgstr "" #: src/scan-gram.l:644 msgid "stray `@'" msgstr "" #: src/scan-gram.l:776 src/scan-gram.l:1087 msgid "line number overflow" msgstr "" #: src/scan-gram.l:778 msgid "column number overflow" msgstr "" #: src/scan-gram.l:861 #, c-format msgid "$$ of `%s' has no declared type" msgstr "$$ dari `%s' tiada jenis diisytiharkan" #: src/scan-gram.l:881 #, c-format msgid "$%d of `%s' has no declared type" msgstr "$%d dari `%s' tiada jenis diisytiharkan" #: src/scan-gram.l:891 src/scan-gram.l:958 src/scan-gram.l:1009 #, c-format msgid "integer out of range: %s" msgstr "integer diluar julat: %s" #: src/scan-gram.l:927 src/scan-gram.l:993 #, c-format msgid "invalid value: %s" msgstr "nilai tidak sah: %s" #: src/scan-gram.l:1103 msgid "rule is too long" msgstr "" #: src/scan-gram.l:1131 #, c-format msgid "missing `%s' at end of file" msgstr "`%s' hilang pada penghujung fail" #: src/scan-gram.l:1142 #, c-format msgid "missing `%s' at end of line" msgstr "`%s' hilang pada penghujung baris" #: src/symlist.c:145 #, fuzzy, c-format msgid "invalid $ value: $%d" msgstr "nilai tidak sah: %s" #: src/symtab.c:71 #, c-format msgid "too many symbols in input grammar (limit is %d)" msgstr "" #: src/symtab.c:110 #, c-format msgid "%s redeclaration for %s" msgstr "%s pengisytiharan semula untuk %s" #: src/symtab.c:111 #, fuzzy msgid "first declaration" msgstr "pelbagai pengisytiharan %s" #: src/symtab.c:199 #, c-format msgid "symbol %s redefined" msgstr "simbol %s ditakrif semula" #: src/symtab.c:213 #, fuzzy, c-format msgid "symbol %s redeclared" msgstr "simbol %s ditakrif semula" #: src/symtab.c:230 #, c-format msgid "redefining user token number of %s" msgstr "mentakrif semula nombor token pengguna %s" #: src/symtab.c:257 #, c-format msgid "symbol %s is used, but is not defined as a token and has no rules" msgstr "simbol %s digunakan, tetapi tidak ditakrifkan sebagai token atau me= mpunyai hukum" #: src/symtab.c:282 #, c-format msgid "symbol `%s' used more than once as a literal string" msgstr "simbol `%s' digunakan lebih dari sekali sebagai rentetan perkataan" #: src/symtab.c:285 #, c-format msgid "symbol `%s' given more than one literal string" msgstr "simbol `%s' diberikan lebih daripada satu rentetan perkataan" #: src/symtab.c:428 #, c-format msgid "tokens %s and %s both assigned number %d" msgstr "token %s dan %s kedua-dunya diberi nombor %d" #: src/symtab.c:651 #, c-format msgid "the start symbol %s is undefined" msgstr "simbol permulaan %s tidak ditakrifkan" #: src/symtab.c:655 #, c-format msgid "the start symbol %s is a token" msgstr "simbol permulaan %s adalah token" #: lib/argmatch.c:137 #, c-format msgid "invalid argument %s for %s" msgstr "hujah tidak sah %s untuk %s" #: lib/argmatch.c:138 #, c-format msgid "ambiguous argument %s for %s" msgstr "hujah kabur %s untuk %s" #: lib/argmatch.c:157 #, c-format msgid "Valid arguments are:" msgstr "Hujah yang sah adalah:" #: lib/bitset_stats.c:177 #, c-format msgid "%u bitset_allocs, %u freed (%.2f%%).\n" msgstr "%u bitset_allocs, %u dibebaskan (%.2f%%).\n" #: lib/bitset_stats.c:180 #, c-format msgid "%u bitset_sets, %u cached (%.2f%%)\n" msgstr "%u bitset_sets, %u disimpan (%.2f%%)\n" #: lib/bitset_stats.c:183 #, c-format msgid "%u bitset_resets, %u cached (%.2f%%)\n" msgstr "%u bitset_resets, %u disimpan (%.2f%%)\n" #: lib/bitset_stats.c:186 #, c-format msgid "%u bitset_tests, %u cached (%.2f%%)\n" msgstr "%u bitset_tests, %u disimpan (%.2f%%)\n" #: lib/bitset_stats.c:190 #, c-format msgid "%u bitset_lists\n" msgstr "%u bitset_lists\n" #: lib/bitset_stats.c:192 msgid "count log histogram\n" msgstr "kira histogram log\n" #: lib/bitset_stats.c:195 msgid "size log histogram\n" msgstr "saiz histogram log\n" #: lib/bitset_stats.c:198 msgid "density histogram\n" msgstr "histogram kepadatan\n" #: lib/bitset_stats.c:212 #, c-format msgid "" "Bitset statistics:\n" "\n" msgstr "" "Statistik bitset:\n" "\n" #: lib/bitset_stats.c:215 #, c-format msgid "Accumulated runs =3D %u\n" msgstr "Pelaksanaan terkumpul =3D %u\n" #: lib/bitset_stats.c:259 lib/bitset_stats.c:264 msgid "Could not read stats file." msgstr "Tidak dapat membaca fail stats." #: lib/bitset_stats.c:261 #, c-format msgid "Bad stats file size.\n" msgstr "Saiz fail stats tidak betul.\n" #: lib/bitset_stats.c:287 lib/bitset_stats.c:289 msgid "Could not write stats file." msgstr "Tidak dapat menulis fail stats." #: lib/bitset_stats.c:292 msgid "Could not open stats file for writing." msgstr "Tidak dapat membuka fail stats untuk menulis." #: lib/error.c:121 msgid "Unknown system error" msgstr "Ralat sistem tidak diketahui" #: lib/getopt.c:531 lib/getopt.c:547 #, c-format msgid "%s: option `%s' is ambiguous\n" msgstr "%s: pilihan `%s' adalah kabur\n" #: lib/getopt.c:580 lib/getopt.c:584 #, c-format msgid "%s: option `--%s' doesn't allow an argument\n" msgstr "%s: pilihan `--%s' tidak mengizinkan hujah\n" #: lib/getopt.c:593 lib/getopt.c:598 #, c-format msgid "%s: option `%c%s' doesn't allow an argument\n" msgstr "%s: pilihan `%c%s' tidak mengizinkan hujah\n" #: lib/getopt.c:641 lib/getopt.c:660 lib/getopt.c:976 lib/getopt.c:995 #, c-format msgid "%s: option `%s' requires an argument\n" msgstr "%s: pilihan `%s' memerlukan hujah\n" #: lib/getopt.c:698 lib/getopt.c:701 #, c-format msgid "%s: unrecognized option `--%s'\n" msgstr "%s: pilihan tidak dikenali `--%s'\n" #: lib/getopt.c:709 lib/getopt.c:712 #, c-format msgid "%s: unrecognized option `%c%s'\n" msgstr "%s: pilihan tidak dikenali '%c%s'\n" #: lib/getopt.c:764 lib/getopt.c:767 #, c-format msgid "%s: illegal option -- %c\n" msgstr "%s: pilihan salah -- %c\n" #: lib/getopt.c:773 lib/getopt.c:776 #, c-format msgid "%s: invalid option -- %c\n" msgstr "%s: pilihan tidak sah -- %c\n" #: lib/getopt.c:828 lib/getopt.c:844 lib/getopt.c:1048 lib/getopt.c:1066 #, c-format msgid "%s: option requires an argument -- %c\n" msgstr "%s: pilihan memerlukan hujah -- %c\n" #: lib/getopt.c:897 lib/getopt.c:913 #, c-format msgid "%s: option `-W %s' is ambiguous\n" msgstr "%s: pilihan `-W %s' adalah kabur\n" #: lib/getopt.c:937 lib/getopt.c:955 #, c-format msgid "%s: option `-W %s' doesn't allow an argument\n" msgstr "%s: pilihan `-W %s' tidak mengizinkan hujah\n" #: lib/obstack.c:433 lib/obstack.c:435 lib/xalloc-die.c:37 msgid "memory exhausted" msgstr "kehabisan memori" #. TRANSLATORS: #. Get translations for open and closing quotation marks. #. #. The message catalog should translate "`" to a left #. quotation mark suitable for the locale, and similarly for #. "'". If the catalog has no translation, #. locale_quoting_style quotes `like this', and #. clocale_quoting_style quotes "like this". #. #. For example, an American English Unicode locale should #. translate "`" to U+201C (LEFT DOUBLE QUOTATION MARK), and #. should translate "'" to U+201D (RIGHT DOUBLE QUOTATION #. MARK). A British English Unicode locale should instead #. translate these to U+2018 (LEFT SINGLE QUOTATION MARK) and #. U+2019 (RIGHT SINGLE QUOTATION MARK), respectively. #. #. If you don't know what to put here, please see #. #. and use glyphs suitable for your language. #: lib/quotearg.c:245 msgid "`" msgstr "`" #: lib/quotearg.c:246 msgid "'" msgstr "'" #: lib/subpipe.c:171 #, c-format msgid "subsidiary program `%s' could not be invoked" msgstr "program subsidiari `%s' tidak dapat dilaksanakan" #: lib/subpipe.c:173 #, c-format msgid "subsidiary program `%s' not found" msgstr "program subsidiari `%s' tidak dijumpai" #: lib/subpipe.c:175 #, c-format msgid "subsidiary program `%s' failed" msgstr "program subsidiari `%s' gagal" #: lib/subpipe.c:176 #, c-format msgid "subsidiary program `%s' failed (exit status %d)" msgstr "program subsidiari `%s' gagal (status keluar %d)" #: lib/timevar.c:475 msgid "" "\n" "Execution times (seconds)\n" msgstr "" "\n" "Masa pelaksanaan (saat)\n" #: lib/timevar.c:525 msgid " TOTAL :" msgstr " JUMLAH :" #: lib/timevar.c:561 #, c-format msgid "time in %s: %ld.%06ld (%ld%%)\n" msgstr "masa dalam %s: %ld.%06ld (%ld%%)\n" #~ msgid "POSIX forbids declarations in the grammar" #~ msgstr "POSIX melarang pengisytiharan didalam tatabahasa" #~ msgid "invalid $ value" #~ msgstr "nilai $ tidak sah" #~ msgid "type redeclaration for %s" #~ msgstr "pengisytiharan semula jenis untuk %s" #~ msgid "redefining precedence of %s" #~ msgstr "mentakrif semula keutamaan %s" #~ msgid "conflicting precedences for %s and %s" #~ msgstr "konflik keutamaan untuk %s dan %s" #~ msgid "conflicting associativities for %s (%s) and %s (%s)" #~ msgstr "konflik kaitan bagi %s (%s) dan %s (%s)" ------=_Part_122133_2502910.1153754163184-- From MAILER-DAEMON Mon Jul 24 15:59:43 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G56ad-0002Yt-Na for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 15:59:43 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G56ab-0002VR-Vm for bug-bison@gnu.org; Mon, 24 Jul 2006 15:59:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G56aa-0002St-KP for bug-bison@gnu.org; Mon, 24 Jul 2006 15:59:41 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G56aa-0002SV-Af for bug-bison@gnu.org; Mon, 24 Jul 2006 15:59:40 -0400 Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G56bj-00016m-J9 for bug-bison@gnu.org; Mon, 24 Jul 2006 16:00:51 -0400 Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by kiwi.cs.ucla.edu (8.11.7p2+Sun/8.11.7/UCLACS-5.2) with ESMTP id k6OJxY906351; Mon, 24 Jul 2006 12:59:34 -0700 (PDT) Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1G56aU-0003w0-9w; Mon, 24 Jul 2006 12:59:34 -0700 To: Frans Englich References: <200607241106.34456.frans.englich@telia.com> From: Paul Eggert Date: Mon, 24 Jul 2006 12:59:34 -0700 In-Reply-To: <200607241106.34456.frans.englich@telia.com> (Frans Englich's message of "Mon, 24 Jul 2006 11:06:34 +0000") Message-ID: <87odveu63d.fsf@penguin.cs.ucla.edu> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bug-bison@gnu.org Subject: Re: Fwd: %token QUOTE "\"" X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 19:59:42 -0000 Frans Englich writes: > Is this a bug in Bison? Could be, but I don't know what the problem is yet, Can you please supply a self-contained example so that we can reproduce the problem? > %token QUOTE "\"" > %token APOS "'" > > When QUOTE is printed it literally prints: \". It hasn't "un-escaped" when > printing, although enough for parsing the grammar at compile time. From MAILER-DAEMON Mon Jul 24 17:13:50 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G57kM-0006FG-6x for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 17:13:50 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G57kL-0006F7-3y for bug-bison@gnu.org; Mon, 24 Jul 2006 17:13:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G57kK-0006Ev-78 for bug-bison@gnu.org; Mon, 24 Jul 2006 17:13:48 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G57kK-0006Es-4S for bug-bison@gnu.org; Mon, 24 Jul 2006 17:13:48 -0400 Received: from [66.249.92.171] (helo=ug-out-1314.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G57lU-0000Am-FH for bug-bison@gnu.org; Mon, 24 Jul 2006 17:15:00 -0400 Received: by ug-out-1314.google.com with SMTP id u2so64549uge for ; Mon, 24 Jul 2006 14:13:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=loG48DHJ4glCCQHDYF3MM4CxpZPYwbKIa/169wfYHfj+YDI+TnmiI3HZ5zoiZ+SvBUzzAtDQPFZ6qFP/Oc+g/JWeu/SB5vsmnmbfPLEyV9/dwBRUPG/bXiCCmpFmUmZlbC9L1Sx3Vxe5EqgXdYQSZ7LvKG0mgD3PfApUuh54BB0= Received: by 10.78.122.11 with SMTP id u11mr1998232huc; Mon, 24 Jul 2006 14:13:46 -0700 (PDT) Received: by 10.78.150.18 with HTTP; Mon, 24 Jul 2006 14:13:46 -0700 (PDT) Message-ID: Date: Mon, 24 Jul 2006 16:13:46 -0500 From: Satya To: "Paul Eggert" In-Reply-To: <87odveu63d.fsf@penguin.cs.ucla.edu> MIME-Version: 1.0 References: <200607241106.34456.frans.englich@telia.com> <87odveu63d.fsf@penguin.cs.ucla.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Frans Englich , bug-bison@gnu.org Subject: Re: Fwd: %token QUOTE "\"" X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 21:13:49 -0000 hi, I poked into it a bit during the weekend; The problem is this: In file parse-gram.y we have a rule for string_as_id: string_as_id: STRING { $$ = symbol_get (quotearg_style (c_quoting_style, $1), @1); symbol_class_set ($$, token_sym, @1, false); } The token returned by lexer (STRING) is a quote mark (") but the result of quotearg_style (c_quoting_style, $1) is this quote mark with a backslash preceding it (and surrounded by quotes) ("\""); So in the symbol table, the quote mark gets stored as a backslah and quote. When printed, the symbol gets printed as such; Infact the .output file also shows it as \" in the description of the grammar. Is there a cure to it? Satya. On 7/24/06, Paul Eggert wrote: > > Frans Englich writes: > > > Is this a bug in Bison? > > Could be, but I don't know what the problem is yet, > Can you please supply a self-contained example so > that we can reproduce the problem? > > > %token QUOTE "\"" > > %token APOS "'" > > > > When QUOTE is printed it literally prints: \". It hasn't "un-escaped" > when > > printing, although enough for parsing the grammar at compile time. > > > -- "When you have eliminated the impossible, whatever remains, however improbable, must be the truth". -Sherlock Holmes, The sign of four. From MAILER-DAEMON Mon Jul 24 23:19:52 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G5DSa-0005ud-FI for mharc-bug-bison@gnu.org; Mon, 24 Jul 2006 23:19:52 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G5DSY-0005tP-3o for bug-bison@gnu.org; Mon, 24 Jul 2006 23:19:50 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G5DSU-0005qy-Gw for bug-bison@gnu.org; Mon, 24 Jul 2006 23:19:49 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G5DSU-0005qr-EH for bug-bison@gnu.org; Mon, 24 Jul 2006 23:19:46 -0400 Received: from [66.249.82.194] (helo=wx-out-0102.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G5DTi-0000XH-3G for bug-bison@gnu.org; Mon, 24 Jul 2006 23:21:02 -0400 Received: by wx-out-0102.google.com with SMTP id t5so1304876wxc for ; Mon, 24 Jul 2006 20:19:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MgHy+erxN1/zW4hS6cnjUf+fK96/vN39GW/Jmih3VuJZzk8TSZRE8LxJHvQHeqQ4t2xVyG3gfxM75E5TtFJNpb09+kYr7WPFg/e4s2fE5x8VwmI3p1IM+BWzaP9xPfMR+AGaNW3/1l7barzaFViLMHEl4c5w4UPikmfMi1/xoAQ= Received: by 10.70.71.4 with SMTP id t4mr5977690wxa; Mon, 24 Jul 2006 20:19:41 -0700 (PDT) Received: by 10.70.66.19 with HTTP; Mon, 24 Jul 2006 20:19:41 -0700 (PDT) Message-ID: <295041390607242019j3f6eb2f0h440a05dd98d6883d@mail.gmail.com> Date: Tue, 25 Jul 2006 11:19:41 +0800 From: "Sharuzzaman Ahmat Raslan" To: "Paul Eggert" In-Reply-To: <874px7ufan.fsf@penguin.cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <295041390607240816k25357fcbw466ee5a4eb7310b@mail.gmail.com> <874px7ufan.fsf@penguin.cs.ucla.edu> Cc: bug-bison@gnu.org Subject: Re: Translation-team-ms post from eggert@cs.ucla.edu requires approval X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 03:19:50 -0000 Sure.. I'll submit it to the TP-Robot soon. I'll update this list when the robot has accepted the file. On 7/25/06, Paul Eggert wrote: > "Sharuzzaman Ahmat Raslan" writes: > > > I have fixed the problem, but I don't have gettext 0.15 nearby so I > > cannot a full test for this file. I believe I read Bruno's email today > > announcing the release of gettext 0.15. > > Thanks. I see that the fix has not yet propagated into > . > Will that happen soon? If so, I can test it myself and let you know > how it works. > -- Sharuzzaman Ahmat Raslan From MAILER-DAEMON Tue Jul 25 00:08:58 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G5EE6-00081L-0C for mharc-bug-bison@gnu.org; Tue, 25 Jul 2006 00:08:58 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G552L-00070F-To for bug-bison@gnu.org; Mon, 24 Jul 2006 14:20:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G552J-0006xa-Gc for bug-bison@gnu.org; Mon, 24 Jul 2006 14:20:12 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G552J-0006xN-6r for bug-bison@gnu.org; Mon, 24 Jul 2006 14:20:11 -0400 Received: from [200.61.161.185] (helo=mx.zarauza-net.com.ar) by monty-python.gnu.org with smtp (Exim 4.52) id 1G553R-0006hz-I3 for bug-bison@gnu.org; Mon, 24 Jul 2006 14:21:22 -0400 Received: (qmail 18205 invoked from network); 24 Jul 2006 18:30:56 -0000 Received: from customer.iplannetworks.net (HELO desa4) (200.69.225.115) by 0 with SMTP; 24 Jul 2006 18:30:56 -0000 From: "Laura Arce" To: Date: Mon, 24 Jul 2006 15:24:00 -0300 Message-ID: <000001c6af4e$564aa440$1100a8c0@winsrv.ateliersoftware.com.ar> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailman-Approved-At: Tue, 25 Jul 2006 00:08:56 -0400 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: BISON CONNECT MYSQL WHIT API C X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jul 2006 18:20:14 -0000 Hi: I=92m trating to use a API C to connect to mysql, because I must to extract from it the formulates to . where I must copy file C to be able to do inclue in the code bison? =20 Thanks. =20 Laura Arce. =20 =20 =20 =20 --=20 No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.4/396 - Release Date: 24/07/2006 =20 From MAILER-DAEMON Tue Jul 25 03:30:24 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G5HN1-0005zt-WA for mharc-bug-bison@gnu.org; Tue, 25 Jul 2006 03:30:24 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G5HMz-0005yM-Qh for bug-bison@gnu.org; Tue, 25 Jul 2006 03:30:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G5HMy-0005xW-A0 for bug-bison@gnu.org; Tue, 25 Jul 2006 03:30:21 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G5HMx-0005xR-PO for bug-bison@gnu.org; Tue, 25 Jul 2006 03:30:19 -0400 Received: from [131.179.128.19] (helo=kiwi.cs.ucla.edu) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G5HOD-0007tF-TV for bug-bison@gnu.org; Tue, 25 Jul 2006 03:31:38 -0400 Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by kiwi.cs.ucla.edu (8.11.7p2+Sun/8.11.7/UCLACS-5.2) with ESMTP id k6P7UC925302; Tue, 25 Jul 2006 00:30:12 -0700 (PDT) Received: from eggert by penguin.cs.ucla.edu with local (Exim 4.50) id 1G5HMq-0004wl-Nk; Tue, 25 Jul 2006 00:30:12 -0700 To: Satya References: <200607241106.34456.frans.englich@telia.com> <87odveu63d.fsf@penguin.cs.ucla.edu> From: Paul Eggert Date: Tue, 25 Jul 2006 00:30:12 -0700 In-Reply-To: (satyakiran@gmail.com's message of "Mon, 24 Jul 2006 16:13:46 -0500") Message-ID: <87slkqgn0b.fsf@penguin.cs.ucla.edu> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Frans Englich , bug-bison@gnu.org Subject: Re: Fwd: %token QUOTE "\"" X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 07:30:22 -0000 Satya writes: > The problem is this: > In file parse-gram.y we have a rule for string_as_id: Sorry, I'm still lost. Can you give a self-contained test case that shows the problem from the user's point of view? The test case should be independent of the implementation. Thanks. From MAILER-DAEMON Tue Jul 25 04:27:38 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G5IGQ-0002bb-Qr for mharc-bug-bison@gnu.org; Tue, 25 Jul 2006 04:27:38 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G5IGO-0002bB-O9 for bug-bison@gnu.org; Tue, 25 Jul 2006 04:27:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G5IGM-0002aT-7O for bug-bison@gnu.org; Tue, 25 Jul 2006 04:27:35 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G5IGM-0002aP-2Y for bug-bison@gnu.org; Tue, 25 Jul 2006 04:27:34 -0400 Received: from [212.247.154.129] (helo=swip.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G5IHc-00044E-T4 for bug-bison@gnu.org; Tue, 25 Jul 2006 04:28:53 -0400 X-T2-Posting-ID: 2yF4ydxc0UI9xI7FHZPfog== X-Cloudmark-Score: 0.000000 [] Received: from 83.72.134.122.ip.tele2adsl.dk ([83.72.134.122] verified) by mailfe05.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 140949521; Tue, 25 Jul 2006 10:27:28 +0200 From: Frans Englich To: Paul Eggert Date: Tue, 25 Jul 2006 08:41:26 +0000 User-Agent: KMail/1.8.50 References: <200607241106.34456.frans.englich@telia.com> <87slkqgn0b.fsf@penguin.cs.ucla.edu> In-Reply-To: <87slkqgn0b.fsf@penguin.cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607250841.26536.frans.englich@telia.com> Cc: bug-bison@gnu.org, Satya Subject: Re: Fwd: %token QUOTE "\"" X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 08:27:37 -0000 On Tuesday 25 July 2006 07:30, Paul Eggert wrote: > Satya writes: > > The problem is this: > > In file parse-gram.y we have a rule for string_as_id: > > Sorry, I'm still lost. In the generated parser, my static const char *const yytname[] has this entry: "\"\\\"\"" Which was generated by: %token QUOTE "\"" I would like the entry to read: "\"\"\"" (or "'\"'", since """ isn't very readable) Just insert '%token QUOTE "\"' in a grammar of yours, and it will expose the problem, I think. Cheers, Frans From MAILER-DAEMON Sat Jul 29 16:33:54 2006 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1G6vVS-0001By-Cl for mharc-bug-bison@gnu.org; Sat, 29 Jul 2006 16:33:54 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G6vVR-0001Bo-I0 for bug-bison@gnu.org; Sat, 29 Jul 2006 16:33:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G6vVP-0001BE-BA for bug-bison@gnu.org; Sat, 29 Jul 2006 16:33:52 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6vVP-0001BB-62 for bug-bison@gnu.org; Sat, 29 Jul 2006 16:33:51 -0400 Received: from [212.247.154.225] (helo=swip.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G6vXg-0001eS-Qv for bug-bison@gnu.org; Sat, 29 Jul 2006 16:36:13 -0400 X-T2-Posting-ID: 2yF4ydxc0UI9xI7FHZPfog== X-Cloudmark-Score: 0.000000 [] Received: from 83.72.134.122.ip.tele2adsl.dk ([83.72.134.122] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 5.0.8) with ESMTP id 242663031; Sat, 29 Jul 2006 22:33:48 +0200 From: Frans Englich To: bug-bison@gnu.org Date: Sat, 29 Jul 2006 20:47:57 +0000 User-Agent: KMail/1.8.50 References: <200607241106.34456.frans.englich@telia.com> <87slkqgn0b.fsf@penguin.cs.ucla.edu> <200607250841.26536.frans.englich@telia.com> In-Reply-To: <200607250841.26536.frans.englich@telia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607292047.57762.frans.englich@telia.com> Cc: Paul Eggert , Satya Subject: Re: Fwd: %token QUOTE "\"" X-BeenThere: bug-bison@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for Bison, the GNU parser generator" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jul 2006 20:33:53 -0000 On Tuesday 25 July 2006 08:41, Frans Englich wrote: > On Tuesday 25 July 2006 07:30, Paul Eggert wrote: > > Satya writes: > > > The problem is this: > > > In file parse-gram.y we have a rule for string_as_id: > > > > Sorry, I'm still lost. > > In the generated parser, my static const char *const yytname[] has this > entry: > > "\"\\\"\"" > > Which was generated by: > > %token QUOTE "\"" > > I would like the entry to read: > > "\"\"\"" > > (or "'\"'", since """ isn't very readable) > > Just insert '%token QUOTE "\"' in a grammar of yours, and it will expose > the problem, I think. The Bison manual actually discuss this, see "Directive: %token-table". Might be interesting when implementing a fix. (Is there a reason why the documentation hasn't been updated for Bison 2.2? http://www.gnu.org/software/bison/manual/html_mono/bison.html mentions 2.1.) Cheers, Frans