headers
Joel E. Denny | 2 Aug 08:45

Re: use git-version-gen (was: Re: bison.1 in version control?)

On Sun, 20 Jul 2008, Joel E. Denny wrote:

> > m4 uses this additional trick, to turn on gnits mode for major releases but use 
> > the more relaxed gnu mode for development:

> Sure.  I've seen one place where this change might help with Bison.  
> During development between releases, I don't like that "make dist" should 
> force me to name the next release in NEWS by using the name of the current 
> state of the code.  That is, I feel that it would be best if unofficial 
> tarballs are not forced to have bogus NEWS entries.

I pushed the patch below for this.

> > > >  AC_DEFINE([PACKAGE_COPYRIGHT_YEAR], [2008],
> > > >            [The copyright year for this package])
> > 
> > This could almost be considered redundant information with the gnulib module 
> > version-etc.
> 
> I'll look into that.

I'm not sure yet what to do with this.  That copyright year is hard-coded 
in gnulib/lib/version-etc.c, but doc/yacc.1.in also needs to depend on it.  
Seems like configure ought to substitute it instead.  Also, it's not clear 
to me that Bison's copyright year should be whatever gnulib was last 
updated to have.  Maybe the copyright year should come from the latest 
change shown by git log?  I need to think about it more, but suggestions 
are welcome.

From a1e50014a0ba37b3de9900754be8c04f57d18c9a Mon Sep 17 00:00:00 2001
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joel E. Denny | 2 Aug 21:28

Re: use git-version-gen (was: Re: bison.1 in version control?)

On Sun, 20 Jul 2008, Joel E. Denny wrote:

> > > > I had to hack bootstrap to remove the "GNUmakefile" entry that gnulib adds 
> > > > to .gitignore.  It would be better to patch gnulib to add "/GNUmakefile" 
> > > > instead.
> > 
> > Personally, I don't bother with anchored .gitignore entries.  But if you really 
> > want all of bison's entries to be anchored, I'd raise the issue with Bruno; 
> > he's pretty good about patching gnulib-tool to meet user demands.
> 
> I'll do that.

He fixed it, so I pushed the following.  Thanks.

From 445b74704f530a8ce77efe7ced935f0189480041 Mon Sep 17 00:00:00 2001
From: Joel E. Denny <jdenny <at> ces.clemson.edu>
Date: Sat, 2 Aug 2008 15:18:21 -0400
Subject: [PATCH] Update for recent .gitignore fix in Gnulib.

* bootstrap: Back out 2008-07-18 hack now that gnulib-tool creates
anchored .gitignore entries.

diff --git a/bootstrap b/bootstrap
index c3c7748..f92d1cc 100755
--- a/bootstrap
+++ b/bootstrap
@@ -614,12 +614,6 @@ if test -f $mam_template; then
   done
 fi
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Blake | 5 Aug 14:27
Gravatar

Re: outdated m4sugar


According to Akim Demaille on 7/24/2008 9:35 AM:
|
| But I guess that in the case of Bison, most of the cost is really in
| the "runtime" part, not the "load it all" part.  Yet it would be
| interesting to make a try.  I'll see if I can try that.

I think a big part of the "runtime" cost of bison would be the fact that
much of older m4sugar is quadratic rather than linear on m4 1.4.x (in
particular, these heavy hitters: m4_join, m4_foreach, m4_map, m4_shiftn,
m4_append).  For autoconf 2.63, all but m4_append have been made linear on
m4 1.4.x (you need m4 1.6 to make m4_append linear), and m4_append_uniq
has been augmented by the addition of m4_set_* which can be used in a
similar manner but in linear time.  All the more incentive for me to
continue work on porting newer m4sugar to bison.  In fact, I'm hoping that
some of the grammars in tests/torture.at are made tractable on larger
input sizes while completing in less time and memory once you switch to
linear algorithms in m4sugar.

--
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net
Permalink | Reply | 0 comments |
headers
Kevin O'Gorman | 7 Aug 19:31

C++ example does not make from scratch

Re: bison-2.3, fresh download from gnu.org mirror.

The example calc++ obscures the procedure for making it because the
distribution includes and uses the bison and flex outputs rather than
generating them from the input files.

I checked this by doing ./configure, make, and make in examples/calc++,
all under script(1), and the resulting typescript contained no, zero, nada
occurrences of invoking bison or flex.

It would be much more helpful if it built from scratch, so that us normal
users could see the commands that are used to make it on our configuration.
As it is, I had to guess (often wrong) about what was the original input
and what was generated.

I'm gonna guess you just have to put a few more things in your 'make clean'
so that the derivative files are not distributed.

++ kevin

 Kevin O'Gorman, Ph.D.  (805) 756-2986(work)  mailto:kogorman <at> pacbell.net
Home Page: http://www.csc.calpoly.edu/~kogorman
Permalink | Reply | 1 comment |
headers
Eric Blake | 14 Aug 15:11
Gravatar

Re: m4_map


[adding bug-bison]

According to Eric Blake on 8/7/2008 2:01 PM:
| On Oct 16 2007, Eric Blake <ebb9 <at> byu.net> writes:
|
|> Here's the patch for these macros, along with m4_apply, and semantics
changes
|> to m4_map{,_sep} to make it reliably distinguish between an empty list of
|> arguments to apply, vs. a list containing a macro application with 0
| arguments,
|> vs. a list containing an argument list that contains an empty argument.
|>
|> (m4_map): Change semantics to allow calling macro without
|> arguments.
|> (m4_map_sep): Likewise.  Also change semantics to quote separator,
|> to match m4_join and m4_append.
|
| I'm starting to have regrets about this semantic change to m4_map_sep.
At the
| time I made it, I did not know of any use of m4_map_sep in the wild
(autoconf
| certainly did not use it, neither did libtool).  But I overlooked bison,
which
| makes heavy use of m4_map_sep.

In addition to the issue of whether the separator is quoted, I've finally
pin-pointed the other m4_map regression that is breaking bison, were I to
use the current autoconf m4sugar instead of bison's.  Bison has a number
of places that invoke macro($@) with a (possibly empty) list of arguments,
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ralf Wildenhues | 14 Aug 20:43
Picon
Picon

Re: m4_map

* Eric Blake wrote on Thu, Aug 14, 2008 at 03:11:44PM CEST:
>
> So, to solve things, I'm thinking of the following change:
>
> m4_map, m4_map_sep no longer invoke func on an empty argument sublist.
> This means "m4_map([func], [[]])" goes back to being a no-op, while
> "m4_map([func], [[], [[1]])" now invokes only "func([1])", instead of two
> invocations.  Additionally, m4_map_sep behaves like m4_join, where the
> separator is omitted if the func call is omitted, so that
> "m4_map_sep([m4_dquote], [-], [[[1]], [], [[]]])" results in "[1]-[]",
> rather than "[1]--[]".  For all cases bison is worried about, this makes
> m4_map go back to its pre-2.62 behavior.
>
> Meanwhile, I will add two new functions m4_mapall and m4_mapall_sep,
> similar to the paradigm of m4_joinall, where the empty sublist implies an
> invocation of func with zero arguments, so that the 2.62 semantics of
> "m4_map_sep([func], [sep], [list])" are now available as
> "m4_mapall_sep([func], [[sep]], [list])".

As far as I have understood the problem space (which is quite a bit from
fully, mind you), your proposal makes sense to me, if the bison
developers don't have issues with it.  I understand correctly that
except for Autoconf and Bison, practically nobody uses these macros
yet?

Cheers,
Ralf
Permalink | Reply | 3 comments |
headers
Eric Blake | 15 Aug 15:29
Gravatar

Re: m4_map


According to Ralf Wildenhues on 8/14/2008 12:43 PM:
> * Eric Blake wrote on Thu, Aug 14, 2008 at 03:11:44PM CEST:
>> So, to solve things, I'm thinking of the following change:
>>
>> m4_map, m4_map_sep no longer invoke func on an empty argument sublist.
>>
>> Meanwhile, I will add two new functions m4_mapall and m4_mapall_sep,
> 
> As far as I have understood the problem space (which is quite a bit from
> fully, mind you), your proposal makes sense to me, if the bison
> developers don't have issues with it.

Here's the patch that I'm playing with on the autoconf side.  I've already
verified that with this patch, autoconf's m4sugar.m4 was able to pass the
bison testsuite with two minor tweaks (bison still has one use of m4_fst
that autoconf no longer supplies, and bison needs to be taught how to find
m4sugar/foreach.m4 for linear rather than quadratic scaling when run atop
m4 1.4.x).  I'll follow up to the bison list with two patches to finish
the re-sync with autoconf's m4sugar improvements.

>  I understand correctly that
> except for Autoconf and Bison, practically nobody uses these macros
> yet?

Yes, that seems to be the case.  And even Autoconf's one existing usage
(besides the testsuite) in m4_version_unletter did not need any tweaking
for the fixed semantics.

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Akim Demaille | 25 Aug 13:21
Picon
Picon
Picon
Gravatar

Re: C++ example does not make from scratch


Le 7 août 08 à 19:31, Kevin O'Gorman a écrit :

> Re: bison-2.3, fresh download from gnu.org mirror.

Hi,

> The example calc++ obscures the procedure for making it because the
> distribution includes and uses the bison and flex outputs rather than
> generating them from the input files.

It is so because, for instance, it is not required from the
user to have flex installed.  It is true that the bison's
output files could not be shipped.

> It would be much more helpful if it built from scratch, so that us  
> normal
> users could see the commands that are used to make it on our  
> configuration.
> As it is, I had to guess (often wrong) about what was the original  
> input
> and what was generated.

Please have a look at examples/calc++/Makefile.am, it should
contain what you are looking for.  Unless you mean that the
doc should contain just a plain sequence of program calls?
Permalink | Reply | 0 comments |
headers
Georg Sauthoff | 31 Aug 21:27
Picon
Picon

C++ template lalr1.cc: one use of location instead of location_type

Hi,

I noticed, that in the C++ parser template class lalr1.cc is one usage
of 'location' hardcoded instead of the user configurable type-synonym
'location_type'.

This is a problem if you want to use your custom location-class to track
source locations. E.g. if you want to extend yy::location.

E.g.:

%locations
%define "location_type" "Loc"

And then it is quite possible that you have to define the macro
YYLLOC_DEFAULT, to get '@$' default computations right according to user
defined semantics.

But since in lalr1.cc there is this definition

location yyerror_range[2];

this is not enough - you have to patch the generated C++-parser file.

There are two possible fixes:
1. just replace 'location' with 'location_type', like in the rest of the
   lalr1.cc.
2. do 1. and extend yy::location with a virtual method which does this
   computation (-> user can over-load this function if needed when
   extending yy::location)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane