headers
Fabian Kruse | 5 Mar 13:45

Von Beatrice habe ich diesen Link erhalten

_______________________________________________
Bug-ddd mailing list
Bug-ddd <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-ddd
Permalink | Reply | 0 comments |
headers
Juan Manuel Guerrero | 7 Mar 21:56
Picon
Picon

gl_HEADER_UNISTD question

On my OPEN SuSE 10 system I have tried to compile today's cvs sources.
There are installed:
automake (GNU automake) 1.9.6
Written by Tom Tromey <tromey <at> redhat.com>.

autoconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.

ltmain.sh (GNU libtool) 1.5.20 (1.1220.2.287 2005/08/31 18:54:15)

When the bootstrap script is runned it produces the gl_HEADER_UNISTD
entry in the m4/gnulib.m4 file. For some reason this macro is not
expanded in the configure script. This produces, later when configuring,
the following output:
[snip]
./configure: line 15015: gl_HEADER_UNISTD: command not found
[snip]

The produced distribution (bison-2.1b.tar.bz2) later dies due to the
not expanded macro when I try to configure und compile it on msdos/djgpp,
but that is another story.

The cvs sources I have downloaded two or three days ago did not
exhibit this issue. Can some one explain to me what is happening?
If some more information is requiered, please contact me.

Regards,
Juan M. Guerrero
Permalink | Reply | 0 comments |
headers
Paul Eggert | 8 Mar 02:46
Favicon

Re: gl_HEADER_UNISTD question

Juan Manuel Guerrero <juan.guerrero <at> gmx.de> writes:

> When the bootstrap script is runned it produces the gl_HEADER_UNISTD
> entry in the m4/gnulib.m4 file. For some reason this macro is not
> expanded in the configure script.

That's a bug in gnulib.  I installed this patch:

2006-03-07  Paul Eggert  <eggert <at> cs.ucla.edu>

	* m4/unistd_h.m4 (gl_HEADER_UNISTD): Rename, to match modules file.
	Problem reported by Juan Manuel Guerrero.

--- m4/unistd_h.m4	7 Mar 2006 13:33:04 -0000	1.1
+++ m4/unistd_h.m4	8 Mar 2006 01:45:07 -0000
@@ -1,4 +1,4 @@
-# unistd_h.m4 serial 1
+# unistd_h.m4 serial 2
 dnl Copyright (C) 2006 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -6,7 +6,7 @@ dnl with or without modifications, as lo

 dnl Written by Simon Josefsson

-AC_DEFUN([gl_UNISTD],
+AC_DEFUN([gl_HEADER_UNISTD],
 [
   dnl Prerequisites of lib/unistd.h.
   AC_CHECK_HEADERS([unistd.h], [
Permalink | Reply | 0 comments |
headers
Paul Eggert | 8 Mar 07:25
Favicon

Bison FAQ C++ entry is obsolete?

twlevo <twlevo <at> xs4all.nl> writes:

> yyrhs and yys shadows a parameter gcc warning there.
> ./configure --enable-gcc-warnings
> make
> make maintainer-check

Thanks.  This should be fixed in the current CVS.

> few protofiles need update, 

Sorry, what's a "protofile"?

> Q5 in the FAQ about c++ is possibly quite outdated now.

Yes, quite possibly it is.  Thanks.  I'll CC: this to bug-bison,
where the C++ experts can tell me what's wrong with Q5.

For the record, here's Q5's current contents.  How can it be improved?

Q5.  Will Bison ever have C++ support?

A5.  Yes, it's in the works.  Things are very chaotic right now, but
     what little information floats around is posted to the bug-bison
     mailing list.  If you're interested in testing C++ support when
     it becomes available, please consider subscribing to the list,
     especially if you are willing to beta test other releases as
     well.
Permalink | Reply | 0 comments |
headers
Simon Josefsson | 8 Mar 10:44

Re: gl_HEADER_UNISTD question

Paul Eggert <eggert <at> CS.UCLA.EDU> writes:

> Juan Manuel Guerrero <juan.guerrero <at> gmx.de> writes:
>
>> When the bootstrap script is runned it produces the gl_HEADER_UNISTD
>> entry in the m4/gnulib.m4 file. For some reason this macro is not
>> expanded in the configure script.
>
> That's a bug in gnulib.  I installed this patch:

Thanks!

> 2006-03-07  Paul Eggert  <eggert <at> cs.ucla.edu>
>
> 	* m4/unistd_h.m4 (gl_HEADER_UNISTD): Rename, to match modules file.
> 	Problem reported by Juan Manuel Guerrero.
>
> --- m4/unistd_h.m4	7 Mar 2006 13:33:04 -0000	1.1
> +++ m4/unistd_h.m4	8 Mar 2006 01:45:07 -0000
> @@ -1,4 +1,4 @@
> -# unistd_h.m4 serial 1
> +# unistd_h.m4 serial 2
>  dnl Copyright (C) 2006 Free Software Foundation, Inc.
>  dnl This file is free software; the Free Software Foundation
>  dnl gives unlimited permission to copy and/or distribute it,
> @@ -6,7 +6,7 @@ dnl with or without modifications, as lo
>  
>  dnl Written by Simon Josefsson
>  
> -AC_DEFUN([gl_UNISTD],
> +AC_DEFUN([gl_HEADER_UNISTD],
>  [
>    dnl Prerequisites of lib/unistd.h.
>    AC_CHECK_HEADERS([unistd.h], [
Permalink | Reply | 0 comments |
headers
Hans Aberg | 8 Mar 21:03
Picon
Picon

EBNF

Waite, Goos, "Compiler Construction", Appendix A, p. 383, gives some  
EBNF to BNF translation rules. I rewrite in local notation, suitable  
for implementation in Bison:
   1.  a(b)c := axc, x: b.
   2.  a[b]c := ac | a(b)c.
   3.  au+ c := axc, x: u | xu.
   4.  au* c := a[u+]c.
   5.  a || t := a(ta)*.
where a, b, c are arbitrary RHS rules, x a unique non-terminal, u a  
single or parenthesized grammar symbol, and t a terminal.

Let's adapt this further for the Bison language grammar:

First rewrite these rules further, making the implicit (hidden) non- 
terminals explicit, letting e stand for the empty production:
   2'.  a[b]c := axc, x: e | b.
   3'.  au+ c := axc, x: u | xu.
   4'.  au* c := axc, x: e | xu.
   5'.  a || t c := axc, x: e | xta.

Then attach the extra actions, denoted by A, B:
   1. a(b)Ac := axc, x: bA.
   2. a[b]ABc := axc, x: eA | bB.
   3. au+ ABc := axc, x: uA | xuB.
   4. au* ABc := axc, x: eA | xuB.
   5. a || t AB := axc, x: eA | xtaB.

In the Bison language grammar, A, B will have the form {...}, and the  
e will be omitted. The $k values used in the actions A, B, can be  
inferred from these translation rules.

Waite, Goos [loc. cit.], sec. 5.1.4, p. 109 ff., gives an EBNF  
grammar for EBNF notation. If I translate it into a Bison like  
grammar (expanded into BNF) with the extra actions needed attached,  
using the abbreviations:
   E   expression
   PL  primary-list
   P   primary
   U   unit
   A   atom
   N   non-terminal
   T   terminal
   AC  action
   O   empty
I get something like:
   E:  PL | E "||" T AC AC.
   PL: P | PL "|" P.
   P:  O | U | U "+" AC AC | U "*" AC AC | "[" E "]" AC AC.
   U:  A | "(" E ")" AC.
   A:  N | T | AC.
   O:  .
Modulo that I do not see exactly how the empty production O should be  
integrated into this grammar, as well as the Bison optional mid-rule  
actions, and typos. But this should be enough to display the EBNF  
precedences.

   Hans Aberg
Permalink | Reply | 0 comments |
headers
Paul Eggert | 8 Mar 20:27
Favicon

Re: Bison Copyright (C) 2006 Free Software Foundation, Inc.

twlevo <twlevo <at> xs4all.nl> writes:

> noticed 2006 is notyet in all files in the copyright headers,
> see `grep -L 2006 *' in all files in all subdirs.

As a rule I don't update the copyright dates until the files actually
change in contents.  The GNU Coding Standards say it's OK to put 2006
in every file, but it's not necessary if you don't publish the changed
file in 2006.
Permalink | Reply | 0 comments |
headers
Paul Eggert | 12 Mar 08:51
Favicon

Re: Bison GNU GPL Version 3 gplv3.fsf.org

twlevo <at> xs4all.nl writes:

> the special copyright issues in GNU Bison parser generator software
> are reason to mention the upcoming new GPLv3 http://gplv3.fsf.org

That's an interesting argument, but I'm afraid that two lines don't
suffice to explain it.  I'm not an expert in the GPLv3 so I don't
understand the special connection between the GPLv3 and the Bison
copyright issues.
Permalink | Reply | 0 comments |
headers
Paul Eggert | 14 Mar 07:28
Favicon

discrepancies between bison and bison-runtime textual domains

We're about to release a new version of Bison, and I'm looking into a
problem with the Bison bootstrap procedure: it's not retrieving the
latest Bison translations from www.iro.umontreal.ca.  Apparently early
this month the Translation Project revamped how translations are
presented.

First, I'd like to get Bison's bootstrap procedure working again.
Second, I noticed some possible glitches in the new translation scheme,
which I thought I'd mention.

========================================

First, how should Bison get the latest translations from the
Translation Project?

The current Bison bootstrap procedure operates first by retrieving
<http://www.iro.umontreal.ca/translation/maint/bison/>, and then by
retrieving all the .po files that this catalog refers to.  The newest
translation currently listed, for example, is
<http://www.iro.umontreal.ca/translation/maint/bison/fr.po>, dated
2005-06-14 14:27:36 UTC, about 9 months ago.

However, I now notice that the web page
<http://www.iro.umontreal.ca/translation/registry.cgi?domain=bison>
contains a quite different list of translations, which are newer.
For example, the oldest translation in that index is
<http://www.iro.umontreal.ca/translation/teams/PO/zh_TW/bison-2.1.zh_TW.po>,
dated 2006-03-04 21:21:26 UTC, only 10 days ago.

>From the time stamps I suppose that this new list is now definitive,
and that the old list should be ignored.  Is this correct?

However, this raises the question: why are there two lists of
translations, one of which is obsolete?  Shouldn't the latter be
removed?  And yet if I look at the parent
<http://www.iro.umontreal.ca/translation/maint/> of the "old"
directory, I see that some projects have been updated quite recently,
e.g., mailutils was updated three days ago.  So I'm a bit puzzled as
to which is the "canonical" source of translations for Bison.

========================================

Second, the "new" translations for Bison seem to have some odd
discrepancies.

<http://www.iro.umontreal.ca/translation/registry.cgi?domain=bison> and
<http://www.iro.umontreal.ca/translation/registry.cgi?domain=bison-runtime>
have some apparent glitches and/or gotchas.  I thought I'd
double-check to make sure these discrepancies are intended.

Here they are:

* 'bison-runtime' has 'zh_CN' and 'sl' translations, but 'bison' does not.

* In the 'bison' domain, zh_TW is the only language that lacks a 2.1a version.

* In the 'bison-runtime' domain, zh_CN is the only language that lacks a
2.1a version.

* It looks like someone regenerated all bison/*.po and
bison-runtime/*.po translations at about 2006-03-07 09:52:40 UTC.
However, there are two exceptions: bison/zh_TW.po is dated 2006-03-04
21:21:26 UTC, and bison-runtime/zh_CN.po is dated 2005-12-03 19:43:04.
Permalink | Reply | 0 comments |
headers
Michi Henning | 24 Mar 04:09
Favicon

Bison 2.1 generates bad code

I've just upgraded to Bison 2.1 and found that it generates bad code.
(The same grammar works fine with Bison 1.875b.)

The generated code contains:

/*----------.
| yyparse.  |
`----------*/

#ifdef YYPARSE_PARAM
# if defined (__STDC__) || defined (__cplusplus)
int yyparse (void *YYPARSE_PARAM)
# else
int yyparse (YYPARSE_PARAM)
  void *YYPARSE_PARAM;
# endif
#else /* ! YYPARSE_PARAM */
#if defined (__STDC__) || defined (__cplusplus)
int
yyparse (void)
#else
int
yyparse ()
    ;
#endif
#endif
{

Note the final semicolon on the 4th-last line. It causes a syntax error 
because a semicolon immediately follows the function
header, before the opening brace.

With Bison 1.875b, that semicolon wasn't generated.

Cheers,

Michi.
Permalink | Reply | 1 comment |

Gmane