>>> "Paul" == Paul Hilfinger <[EMAIL PROTECTED]> writes:
> In fact, this issue did get discussed when the GLR skeleton got
> introduced, and the language (or lack of it) is, AIR, deliberate on
> the part of the lead maintainers at the time. On consideration, I
> would prefer that the same ter
>>> "Sylvain" == Sylvain Schmitz <[EMAIL PROTECTED]> writes:
> Paul Hilfinger wrote:
>> In fact, this issue did get discussed when the GLR skeleton got
>> introduced, and the language (or lack of it) is, AIR, deliberate on
>> the part of the lead maintainers at the time. On consideration, I
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> +static char const *yytname_gettext_helper[] =
> +{
> + ]b4_gettext_list([b4_tname])[
> +};
While we are at it, wouldn't it be better to get rid of the quotes
that are kept with "clear" names? E.g.:
% tc =(echo '1 +')
/tmp/zshVQFZgE:2.
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> Can you please explain why the token names should be translated? It's
> possible that this should be an option, rather than being an
> unconditional translation.
Token can be given a human readable string. INT can be integer, which
is t
>>> "Jan" == Jan Nieuwenhuizen <[EMAIL PROTECTED]> writes:
> It it were, we have two type of syntax error:
> syntax error: unexpected STRING: foo, expected ...
> and
> syntax error: unexpected \book, expected ...
That could be made using %printer. The only problem is that we woul
>>> "Hans" == Hans Aberg <[EMAIL PROTECTED]> writes:
> At 10:05 +0200 2005/04/18, Akim Demaille wrote:
>> That could be made using %printer. The only problem is that we would
>> like to output into a string, whereas %printer is made for streams :(
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> subpipe.c:103: warning: variable `from_in_fd' might be clobbered by
>> `longjmp' or `vfork'
> I take it that it's OK to put information into an array rather than a
> variable that might be put into a register?
Wouldn't
(void)
>>> "Jeannot" == Jeannot Langlois <[EMAIL PROTECTED]> writes:
I don't know if the patch was installed, but in case it is not yet...
> diff -r -u tests/testsuite tests/testsuite
> --- tests/testsuite 2005-05-22 03:02:00.0 -0400
> +++ tests/testsuite 2005-05-28 17:19:06.0 -0400
Le 9 juil. 05 à 09:17, Paul Eggert a écrit :
I installed this:
2005-07-09 Paul Eggert <[EMAIL PROTECTED]>
* data/yacc.c (yyparse): In the initial action, set
yylsp[0] and yyvsp[0] rather than yylloc and yylval.
This avoids the use of undefined variables if the initial
action
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>> And this value is not used, it is copied. A tool such as Valgrind
>> makes the difference.
> Sorry, I don't quite follow this point.
> We didn't find the problem with valgrind. The problem was found
> because GCC 4 is smart enough t
>>> "Paul" == Paul Hilfinger <[EMAIL PROTECTED]> writes:
> This is actually Akim's code rather than mine, so I'm a tad uncertain as
> to the "correct" fix. The problem, at least, is clear: when entering
> the error-recovery code as a result of YYERROR, yyerror_range[1] is
> uninitialized. I
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> OK, so it's impossible in general to shut off those messages with
> /*CONSTCOND*/. Then let's not bother to try.
You see me surprised! You and I are militants of killing the
warnings, so I do understand Nicolas' point, in particular in
g
>>> "Nicolas" == Nicolas Joly <[EMAIL PROTECTED]> writes:
> It seems that lint programs have no standards, just common
> practices ...
Time for a new project... Autolint! (ta da!) :)
>>> "Oleg" == Oleg Smolsky <[EMAIL PROTECTED]> writes:
> I think I have a couple of issues to report :) Given the following
> command:
> bison -d -S lalr1.cc -o generated/SomeParser.cpp SomeParser.y
> I get two files created in my generated/ directory (which is fine):
> SomeParser.cpp
> So
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> As I recall, that patch came in after the feature freeze for 2.1.
> 2.2 is intended to be just a bugfix release (though one new feature,
> %require, has been added, as we're pretty sure it won't break old
> grammars).
> So I'd say this
I fixed it. Paul, you'll certainly want to have a peek at it. Maybe
you won't like the double semantics I gave to output_parser_name etc.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
* src/scan-skel.l: Output the base name parts of the parser and
h
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> Akim Demaille <[EMAIL PROTECTED]> writes:
>> I fixed it. Paul, you'll certainly want to have a peek at it. Maybe
>> you won't like the double semantics I gave to output_parser_nam
What's about the compatibility with older versions? :)
Please, see the NEWS and the calc++ example in the documentation.
This was reported in
http://lists.gnu.org/archive/html/bison-patches/2005-09/msg00050.html
and
http://lists.gnu.org/archive/html/bison-patches/2005-09/msg00037.html
and fixed in
http://lists.gnu.org/archive/html/bison-patches/2005-09/msg00030.html
Thanks!
>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes:
> I prefer that the clean-up *not* happen automatically for either
> YYABORT or YYERROR -- as in GLR parsing. This would allow for a
> simple consistent rule: if the user's semantic action executes,
> then the user's semantic action is re
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> That last message talks about the fix, but its patch is about
> something else entirely (which confused me at the time, and now I see
> it's confusing you too :-).
> Here's where the fix actually is:
> http://lists.gnu.org/archive/
>>> "Peter" == Peter Klein <[EMAIL PROTECTED]> writes:
Hi Peter,
> OpenBSD3.4
> ==
> (installed on an Sun Ultra Sparc 5/270MHZ)
>with gcc 2.95.3
[...]
> /usr/include/g++/stl_uninitialized.h:169: Internal compiler error in
> `emit_move_insn_1', at expr.c
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> "Joel E. Denny" <[EMAIL PROTECTED]> writes:
>> However, I just noticed the current YYUSE definition doesn't allow the
>> argument to be a struct instance. Paul, Akim, is this intentional?
> Yes and no. If we could easily implement it w
How about this:
/* Suppress unused-variable warnings by "using" E. */
static int yyunused;
#define YYUSE(e) yyunused = (int*) &(e) && yyunused
No unused variables (as long as YYUSE is used somewhere)
YYUSE(yyunused) :)
I might be slightly off topic, but I have not seen any problem
reported with casts to void in the case of C++. So we should probably
look for a pure C solution, and let __cplusplus do the rest. But you
may already have realized that already, I didn't follow the thread
close enough...
>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes:
> Personally, I don't ever use lint (although it's looking kind of
> interesting). But if bison has to deal with this because people want it,
> then I believe the loss of functionality incurred by previous YYUSE
> definitions is worse
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> Why can't we simply rewrite the code so that it doesn't declare
> unused variables?
Because you don't know whether yyerror, for instance, will use the
location, or the %parse-param. But some users need them there.
>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes:
> On Wed, 7 Dec 2005, Akim Demaille wrote:
>>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
>>
>> > Why can't we simply rewrite the code so that it
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> I installed the following patch, which I hope fixes the YYUSE problems
> discussed in the "%destructor feedback" thread.
> 2005-12-09 Paul Eggert <[EMAIL PROTECTED]>
> Cleanups so that Bison-generated parsers have less lint.
>
>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes:
> On Wed, 7 Dec 2005, Akim Demaille wrote:
>>>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes:
>>
>> > On Wed, 7 Dec 2005, Akim Demaille wrote:
>> >
I'd like to see 2.2 out in January if we can, so I'd like to close
this file. Do we agree that:
- we desire a warning about typed $n not used in the actions. A
simple macro that ignores its argument suffice to avoid the
complaints.
- we desire that in all the skeletons no $n is ever freed
l, AFAICS that's already the behavior in glr.c, isn't it?
Otherwise I missed the bit of code that is wrong.
I installed the following.
Index: ChangeLog
from Akim Demaille <[EMAIL PROTECTED]>
YYACCEPT, YYERROR, and YYABORT, as user actions, should not
destroy t
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> These two patches are still pending in this area.
> http://lists.gnu.org/archive/html/bison-patches/2005-12/msg00048.html
> http://lists.gnu.org/archive/html/bison-patches/2005-12/msg00049.html
> The former is more important. I'd like
>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes:
>> They were still badly formatted by the way :)
> I'm clueless.
> I just tried exporting the second patch from the email I received back
> through the mailing list. I found that applying it perfectly reproduced
> my original code.
Le 22 déc. 05 à 19:49, Joel E. Denny a écrit :
Would it be worthwhile to warn about unmentioned typed $$ as well?
Yes, you are right.
I noticed you're not defining any sort of public YYUSE. Leaving it
up to
the user is fine with me. Is this your long term plan, or have you
just
not de
Le 22 déc. 05 à 19:49, Joel E. Denny a écrit :
Would it be worthwhile to warn about unmentioned typed $$ as well?
The correct handling of $$ is troublesome when there are midrule
actions. I tried to see how this could be implemented peacefully
in bison, but I gave up: there's a lot of code d
Le 27 déc. 05 à 18:46, Akim Demaille a écrit :
Le 22 déc. 05 à 19:49, Joel E. Denny a écrit :
Would it be worthwhile to warn about unmentioned typed $$ as well?
The correct handling of $$ is troublesome when there are midrule
actions.
More generally, what exactly do we want in case of
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> twlevo asked the following question:
I did not see the question, where was it posted?
> Is ]b4_pre_prologue[ different in yacc mode?
Yes, it is. This is discussed below
http://lists.gnu.org/archive/html/bison-patches/2005-12/msg0.h
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> twlevo <[EMAIL PROTECTED]> writes:
>> parse-gram.y line 238 that ';' rule is needed.
> Yes, it's needed, but that part of the grammer is messy, and that is
> why the comment talks about a "horror". Ideally a declaration would
> end wi
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> That patch broke Bison bootstrapping, since it breaks the calc++ example.
> To reproduce the problem, check out a fresh version of Bison from CVS,
> run ./bootstrap, ./configure, make.
> Here are the symptoms:
> make[4]: Entering direc
>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes:
> The following seems misleading to me because it seems to imply that
> the 0 actually has some significance even though the parser
> discards $$. You did something similar in your test case patch:
> {
> $$ = 0;
> YYABORT;
>
3, 4, and
> 6.
Same here: I would have liked the first algorithm, but the current
implementation (rules are in a linked list of symbols, not even of
rules) makes it hard to consult the previous (mid-)rules. So I
installed the following which finishes to implementation the smaller
version
>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes:
>> Index: ChangeLog
>> from Akim Demaille <[EMAIL PROTECTED]>
>>
>> * src/reader.c (grammar_midrule_action): If $$ is set in a
>> mid-rule, move the `used' bit
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
> Same here: I would have liked the first algorithm, but the current
> implementation (rules are in a linked list of symbols, not even of
> rules) makes it hard to consult the previous (mid-)rules. So
Le 4 janv. 06 à 20:29, Joel E. Denny a écrit :
On Wed, 4 Jan 2006, Frank Heckenbach wrote:
Joel E. Denny wrote:
Yikes. Specifying a meaningless type is ugly.
Indeed, it looks ugly. OTOH, this seems a rather uncommon situation
(using $-n is already ugly, IMHO -- is it POSIX conformant
act
>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes:
> On Wed, 4 Jan 2006, Akim Demaille wrote:
>> Le 4 janv. 06 à 20:29, Joel E. Denny a écrit :
>>
>> > I don't see $3 as simply a waste of characters. I see it as
>>
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> Akim Demaille <[EMAIL PROTECTED]> writes:
>> Paul, in English you'd write mid-rule action, right?
> Yes.
>> And in code? mid_rule, midrule?
> Either would be fine. Current
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> twlevo <[EMAIL PROTECTED]> writes:
>> GLR test 110 and 111 fail with g++ 3.4.2 but not with g++ 3.3.3
>> (it looks like Yet Another Compiler Compilation version issue)
> Thanks, I just now discovered that it also fails with GCC 4.0.2. I
retrieving revision 1.1412
diff -u -r1.1412 ChangeLog
--- ChangeLog 19 Jan 2006 06:48:52 - 1.1412
+++ ChangeLog 19 Jan 2006 12:45:46 -0000
@@ -1,3 +1,8 @@
+2006-01-19 Akim Demaille <[EMAIL PROTECTED]>
+
+ * tests/calc.at (_AT_DATA_CALC_Y): Initialize the whole initial
+
>>> "ファンタジスタ" == ファンタジスタ <[EMAIL PROTECTED]> writes:
> To whom it may concern,
> I do not see whether this is the big deal or not,
> but if this evidence below is helpful to improve bison software community,
> I am happy.
> Machine architecture is SUN ULTRA-5.
> See also attached 'testsui
Thanks, but the current version of Bison is 2.1. And in 2.1, both are
ints, so I don't see the need for this patch. Unless you have a
modified version of Bison using size_t or something?
${datarootdir}
localedir = $(datadir)/locale
gettextsrcdir = $(datadir)/gettext/po
datarootdir is not defined. ISTR that this is one of the tasks of the
current CVS Autoconf. Am I supposed to use a recent CVS Autoconf?
~/src/bison % autoconf --version nostromo Err
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> It could well be your Autoconf/Automake versions. I am using Autoconf
> 2.59 (Debian stable) and Automake 1.9.6 (which I installed).
OK, thanks. Using ./configure AUTOCONF=/usr/bin/autoconf2.50
AUTOMAKE=/usr/bin/automake-1.9 made it work
>>> "Hans" == Hans Aberg <[EMAIL PROTECTED]> writes:
> You and Akim need to figure out what you want with the compile C as C+
> + option that now exists.
As far as I'm concerned it's clear: as long as the user sticks to PODs
and does not expect C++ magic, then it should work. But as soon as
th
Le 20 févr. 06 à 20:08, Hans Aberg a écrit :
(I don't remember why it's like this,
Because it has always been so, and you, according to you earlier
comment about "an effort is made sure it compiles under C++", which
I gather can only refer to your own checks, is giving support to
it. Pa
One can disable the dynamic stack, and use it with non-POD's, which
I suspect some do.
What evidence do you have to sustain this claim? Based on the
message I've seen, I believe the opposite. People, like me
years ago, know that you can have C code manipulate C++ structures
properly as long
Le 22 févr. 06 à 01:57, Joel E. Denny a écrit :
On Wed, 22 Feb 2006, Hans Aberg wrote:
On 21 Feb 2006, at 19:34, Joel E. Denny wrote:
If this usage is fine, then I wonder how "lalr1.cc" supports non-
POD types
more than "yacc.c". A footnote in the same section says that
`pseudo-unions' ma
Le 21 févr. 06 à 19:34, Joel E. Denny a écrit :
On Tue, 21 Feb 2006, Akim Demaille wrote:
People, like me
years ago, know that you can have C code manipulate C++ structures
properly as long as they are PODs. Trying to use non PODs in
yacc.c is not supported, that's the role of lal
Le 25 févr. 06 à 07:05, Hans Aberg a écrit :
On 24 Feb 2006, at 22:24, Akim Demaille wrote:
Le 23 févr. 06 à 21:34, Hans Aberg a écrit :
In summary, if one does not need a dynamic polymorphic variable
in the extra-parser computations, then a discriminating union
will be useful. But it
Le 23 févr. 06 à 21:34, Hans Aberg a écrit :
In summary, if one does not need a dynamic polymorphic variable in
the extra-parser computations, then a discriminating union will be
useful. But it does not serve as a replacement in the case a
dynamic polymorphic variable is needed.
There is
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> Waldek Hebisch <[EMAIL PROTECTED]> writes:
>> bison-2.1 fails to detect stack overflow in GLR parser.
> * data/glr.c (yyexpandGLRStack): Catch an off-by-one error that
> led to a segmentation fault in GNU Pascal. Problem repor
Le 10 mai 06 à 22:00, Bruno Haible a écrit :
hi Bruno,
/* Begin user sect3 */
#define yywrap(n) 1
#define YY_SKIP_YYWRAP
That's weird, yywrap is not expected to take arguments. There is a
problem in the Bison distro, agreed, but the
slate is also named 'token'.
Thanks, I have changed that.
2006-05-11 Akim Demaille <[EMAIL PROTECTED]>
* data/lalr1.cc (yytranslate_): Rename token as t to avoid clashes
with the member "to
problem with the file extexi in the
examples dircectory in the latest CVS head.
This awk script generates an error with awk on Mac OS X Tiger
(darwin 8.4.6).
Included with this mail is a diff against the CVS head that fixes
this.
Thanks for the report, I installed your patch.
Index: ChangeL
Le 11 mai 06 à 09:25, Paul Eggert a écrit :
You're correct for C89. For C99 it is valid, since C99 macro calls
can have empty arguments. (This is pretty weird, but that's what the
committee decided.)
Wow. My love for committees is ever increasing.
I vaguely recall mentioning this to W.L.
Le 11 mai 06 à 18:57, Paul Eggert a écrit :
Akim Demaille <[EMAIL PROTECTED]> writes:
So, what is our attitude? If we start worrying about such bugs,
we might as well document it in the FAQ. Or we can have configure
issue a warning stating that
W.L. Estes doesn't
>>> "Joel" == Joel E Denny <[EMAIL PROTECTED]> writes:
> Akim, I believe the const in b4_yysymprint_generate was your
> commit. Do you want to require users to typedef YYSTYPE, or should
> we remove the const?
Yes, eventually I would like to move away from using macros.
OK. I've suggested splitting the autotest test suite before.
Let's look at that idea again sometime later (one file per test, and
source them for execution from the main test suite script), it's bound
to give both execution time improvements and portability improvements.
Using functions should
>>> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
>> OK. I've suggested splitting the autotest test suite before.
>> Let's look at that idea again sometime later (one file per test, and
>> source them for execution from the main test
>>> "Michael" == Michael Piefel <[EMAIL PROTECTED]> writes:
> I’m the German translator for Bison. Two weeks ago, I got a new
> translation to do for Bison 2.3. Imagine my surprise when I looked at
> the file and found a line reading ‘Project-Id-Version: bison 1.875d’ and
> another ‘PO-Revisio
>>> "Anthony" == Anthony Heading <[EMAIL PROTECTED]> 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? Fo
>>> "Anthony" == Anthony Heading <[EMAIL PROTECTED]> 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
>&g
n 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
I face this problem:
./bootstrap: aclocal --force -I m4 ...
configure.ac:106: warning: AM_MKINSTALLDIRS is m4_require'd but not m4_defun'd
m4/po_gl.m4:208: AM_PO_SUBDIRS is expanded from...
m4/gettext_gl.m4:347: AM_GNU_GETTEXT is expanded from...
m4/gnulib.m4:68: GNULIB_AUTOCONF_SNIPPET is expand
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> "Sander Brandenburg" <[EMAIL PROTECTED]> writes:
>> Below is a fix for the memory leaks. I'm only not sure the way I solve it is
>> good practice, because keeping track of what needs to be deleted looks
>> rather cumbersome.
> Thanks fo
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
IMHO, there are bits of *.c that should be factored in macros.
> Index: data/glr.cc
> ===
> RCS file: /cvsroot/bison/bison/data/glr.cc,v
> retrieving revision 1.24
> diff -p
I have another one :( Sorry for not looking deeper, I was just trying
to roll a tarball.
~/src/bison % ./bootstrap nostromo 14:14
./bootstrap: Bootstrapping from checked-out bison sources...
./bootstrap: getting translations into po for bison...
14:14:26 URL
I see this when configuring bison:
checking whether g++ builds executables that work... yes
checking for Java virtual machine... rm: conftest.dSYM: is a directory
java
rm: conftest.dSYM: is a directory
checking for Java compiler... javac -source 1.3
checking for Java virtual machine... rm: confte
Le 6 nov. 07 à 17:02, Wilson Snyder a écrit :
The only difference is line 893:
sequenceExpr: yFIRST_MATCH '(' ')'{ $$=$1; }
versus the bad version:
sequenceExpr: yFIRST_MATCH '(' sequenceExpr ')' { $$=$1; }
While the rule is recursive, it doesn't seem significantly different
Akim:
I see this when configuring bison:
checking whether g++ builds executables that work... yes
checking for Java virtual machine... rm: conftest.dSYM: is a directory
java
rm: conftest.dSYM: is a directory
checking for Java compiler... javac -source 1.3
checking for Java virtual machine... rm:
Le 12 nov. 07 à 12:15, Hans Aberg a écrit :
On 12 Nov 2007, at 11:36, Akim Demaille wrote:
I did have a problem when installing XCode 3.0,
I experienced the problem (in connection with Fink) when updating
the Xcode that came with the Mac OS X 10.4.0 installation DVD (don't
know
I have not tracked this down yet, maybe someone will
find easily what's going on.
[EMAIL PROTECTED] ~/src/bison $ grep b4_ examples/calc++/calc++-
parser.cc 21:56:23
#line 1 "[Bison:b4_percent_define_default]"
#line 1 "[Bison:b4_percent_define_default]"
I guess it's a # that is not q
Le 17 avr. 08 à 19:29, Alessandro Vincenzi a écrit :
Hi,
I'm an italian university student in computer science. I'm using
bison in a
project and i've found a typing error in the documentation at
section 2.4.2:
%preg -> %prec
in the uminus rule.
I know, it has no importance. Just for cor
Le 22 avr. 08 à 14:45, Eric Blake a écrit :
Really, the problem is
that there is no way to determine whether $1 is safe to expand,
short of
expanding $1; thus, if it was not safe, you've already screwed up the
state of the m4 parsing.
I always felt m4 lacks an "eval" macro. Not the one for
Le 23 avr. 08 à 02:54, Noah Misch a écrit :
--- autoconf/lib/m4sugar/m4sugar.m4.~1.136.~ 2008-04-22
16:19:27.0 -0400
+++ autoconf/lib/m4sugar/m4sugar.m4 2008-04-22 20:50:59.643031187
-0400
@@ -709,9 +709,9 @@
# Exploit that extra () will group unquoted commas and the following
# whit
>>> "EB" == Eric Blake <[EMAIL PROTECTED]> writes:
> It is probably also technically possible to change autom4te to always
> trace m4_changequote, and use that knowledge that quotes have changed and
> adjust its trace parsing of intermediate traced macros accordingly.
> However, there are auto
Le 10 juil. 08 à 22:43, Eric Blake a écrit :
Hi Eric,
Right now, the latest bison sources are incompatible with the latest
m4
sources. When I built bison with the latest m4.git (will become m4
1.6),
Yay!
the
change from LIFO to FIFO m4wrap (done in order to make m4 obey POSIX)
I have
I would love 1.6 to show the location of the openings
that are not closed instead of the location of... the
end of file :( Something to speed up the understanding
of errors like the following.
m4debug:/Users/akim/src/urbi/2.0/kernel/bison/_build/i386-apple-
darwin9.4.0/../../data/c++-skel.m4:2
Le 11 juil. 08 à 13:59, Eric Blake a écrit :
| ** The error message when end of file is encountered now uses the
| file and line where the dangling construct started, rather than
| `NONE:0:'.
At any rate, I'd be more interested in seeing the same results with
the
latest stable release, m4 1
Le 12 juil. 08 à 03:38, Eric Blake a écrit :
It looks like bison generally tries to avoid generated files in
version
control (for example, configure or Makefile.in). Any reason that
doc/bison.1 is an exception to this rule?
It was because at the beginning it was written by hand,
and later,
Le 22 juil. 08 à 16:27, <[EMAIL PROTECTED]> a écrit :
-Oorspronkelijk bericht-
Van: Akim Demaille [mailto:[EMAIL PROTECTED]
Le 22 juil. 08 à 11:24, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> a écrit :
When compiling the bison output based on skeleton yacc.c Microsoft
>>> "EB" == Eric Blake <[EMAIL PROTECTED]> writes:
> According to Akim Demaille on 7/11/2008 2:38 AM:
>>
>>> the
>>> change from LIFO to FIFO m4wrap (done in order to make m4 obey POSIX)
>>
>> I have not understood why they m
>>> "EB" == Eric Blake <[EMAIL PROTECTED]> writes:
>> The non-use of frozen files is probably just the result of laziness:
>> it's too hard to set up and use. If we had autom4te instead of m4
>> directly, we would probably use frozen files. I have no idea what
>> the speed-up would be though
Le 29 juil. 08 à 17:49, Gaag, M van der - SPLXM a écrit :
Hello GNU/Bison team,
Hi,
Compiling the xxx-parser.tab.cc under Unbreakable Linux (basically
RedHat with GCC 4.1.1) gives me the error operator<< not found in the
ostream library on statement debug_stream() << ( * yyvaluep ) as it
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 be
This is fixed in more recent versions of Bison, the latest one being
2.3. Thanks!
Le 24 oct. 08 à 02:26, Jim Michaels a écrit :
in version 2.1, the output you get from doing a
%locations
I don't know if it is supposed to do only C++ output or not, but
under C output it produces the following uncompilable C code, which
appears to be a direct M4 macro.
That's really weir
Le 4 nov. 08 à 15:45, Sergei Steshenko a écrit :
You have probably also read
http://lists.gnu.org/archive/html/bug-bison/2008-11/msg1.html
thread.
Since too many things are broken by bison 2.4 I suggest to
recall/remove/blacklist this release. I.e. the release doesn't feel
production-wor
Le 4 nov. 08 à 19:08, Juergen Daubert a écrit :
On Tue, Nov 04, 2008 at 09:59:53AM -0500, Joel E. Denny wrote:
On Tue, 4 Nov 2008, Juergen Daubert wrote:
tried to build libIDL 0.8.11 [1] with bison 2.4 and got the
following
error message, while building with 2.3 just works fine:
$> make
b
Le 4 nov. 08 à 20:47, Joel E. Denny a écrit :
On Mon, 3 Nov 2008, Sergei Steshenko wrote:
And bison-2.3a does _not_ break the build, i.e. the
'treelang' broken by
bison-2.4, bison-2.3b is not broken by bison-2.3a, but the
Either you did something wrong or something else strange is happening
1 - 100 of 1207 matches
Mail list logo
