Re: maint: doc: fix documentation of YYERROR

On 4 Apr 2012, at 14:42, Hans Aberg wrote: > On 4 Apr 2012, at 12:33, Akim Demaille wrote: > >> It is installed in maint, it will show in master when I merge. > > FYI, all tests passed using gcc 4.7.0 on OS X 10.7.3. The command 'make install-pdf' is broken; it works from doc/, though. Hans

Re: [PATCH 5/5] style: don't use std::endl

> On 8 May 2018, at 17:02, Akim Demaille wrote: > > Don't use std::endl, it flushes uselessly, and is considered bad > style. Flushing is good with debugging and error reporting, though.

Re: [PATCH 5/5] style: don't use std::endl

> On 9 May 2018, at 08:18, Akim Demaille wrote: > >> Le 8 mai 2018 à 18:03, Hans Åberg a écrit : >> >> >>> On 8 May 2018, at 17:02, Akim Demaille wrote: >>> >>> Don't use std::endl, it flushes uselessly, and is considered bad >

Re: [PATCH 5/5] style: don't use std::endl

> On 9 May 2018, at 08:18, Akim Demaille wrote: > >> Le 8 mai 2018 à 18:03, Hans Åberg a écrit : >> >> >>> On 8 May 2018, at 17:02, Akim Demaille wrote: >>> >>> Don't use std::endl, it flushes uselessly, and is considered bad >

Re: [PATCH 5/5] style: don't use std::endl

> On 10 May 2018, at 14:58, Akim Demaille wrote: > >> Le 10 mai 2018 à 14:01, Hans Åberg a écrit : >> >>> On 9 May 2018, at 08:18, Akim Demaille wrote: >>> >>>> Le 8 mai 2018 à 18:03, Hans Åberg a écrit : >>>> >>>>

Re: Preparing Bison 3.0.5

> On 12 May 2018, at 14:15, Akim Demaille wrote: > > I would like to cut a maintenance release soon. Some annoying > bugs have been fixed. I don’t want to go now into more severe > surgery (such as the variant issues). But is there anything > _not too ambitious_ that should make it into 3.0.5

Re: Preparing Bison 3.0.5

> On 12 May 2018, at 19:40, Akim Demaille wrote: > >> Le 12 mai 2018 à 18:29, Hans Åberg a écrit : >> >>> On 12 May 2018, at 14:15, Akim Demaille wrote: >>> =20 >>> I would like to cut a maintenance release soon. Some annoying >>> bugs

Re: bison-3.0.5 released [stable]

> On 29 May 2018, at 09:00, Akim Demaille wrote: > >> Le 28 mai 2018 à 21:28, Hans Åberg a écrit : >> >>> >>> On 28 May 2018, at 19:28, Akim Demaille wrote: >>> >>>> Le 28 mai 2018 à 10:40, Hans Åberg a écrit : >>

Re: RFC: move bison (not the generated parsers) to C99

> On 26 Jul 2018, at 20:24, Akim Demaille wrote: > > I believe that now we can depend on C99, at least on > these particular features. Paul Eggert confirmed (private > emails) that it’s safe nowadays. If someone disagrees, please > voice it now. Make sure it compiles with C11, as it replaces

Re: [PATCH 6/7] rule actions cannot be typed

> On 5 Aug 2018, at 16:09, Akim Demaille wrote: > > Make sure that we cannot apply a type to the (main) action of a rule. It might be retained, in case one wants to display it for clarity, say in a long grammar.

Re: [PATCH 6/7] rule actions cannot be typed

> On 5 Aug 2018, at 16:09, Akim Demaille wrote: > > Make sure that we cannot apply a type to the (main) action of a rule. It might be retained, in case one wants to display it for clarity, say in a long grammar.

Re: [PATCH 6/7] rule actions cannot be typed

> On 11 Aug 2018, at 18:02, Akim Demaille wrote: > > > >> Le 5 août 2018 à 21:54, Hans Åberg a écrit : >> >> >>> On 5 Aug 2018, at 16:09, Akim Demaille wrote: >>> >>> Make sure that we cannot apply a type to the (main) action of

Re: FYI: master: doc: -fcaret is enabled by default

> On 11 Aug 2018, at 18:27, Akim Demaille wrote: > >doc: -fcaret is enabled by default This type of reporting will not mark the relevant part properly if Unicode tokens "..." are used.

Re: RFC: documentation for typed mid-rule actions

> On 12 Aug 2018, at 11:33, Akim Demaille wrote: > > I would also like to enforce consistency in Bison which uses > both midrule and mid-rule. I am in favor of ‘midrule' > (shorter, consistent with our move to lookahead instead of > look-ahead, more consistent between code and doc as there is

Re: RFC: documentation for typed mid-rule actions

> On 13 Aug 2018, at 09:15, Akim Demaille wrote: > >> Le 12 août 2018 à 17:57, Hans Åberg a écrit : >> >> >>> On 12 Aug 2018, at 11:33, Akim Demaille wrote: >>> >>> I would also like to enforce consistency in Bison which uses >&g

Re: FYI: c++: avoid GCC 8 warnings

> On 15 Aug 2018, at 19:38, Akim Demaille wrote: > > The problem is with locations that don't have a constructor, such as > Span (in calc.cc) which is POD. What is this file. I haven't seen the issue with GCC8, but perhaps the warning is not on. > It is POD on purpose: so that we can >

Re: FYI: c++: avoid GCC 8 warnings

> On 15 Aug 2018, at 19:38, Akim Demaille wrote: > >The problem is with locations that don't have a constructor, such as >Span (in calc.cc) which is POD. What is this file. I haven't seen the issue with GCC8, but perhaps the warning is not on. > It is POD on purpose: so that we can

Re: FYI: c++: avoid GCC 8 warnings

> On 16 Aug 2018, at 06:56, Akim Demaille wrote: > >> Le 15 août 2018 à 23:26, Hans Åberg a écrit : >> >> >>> On 15 Aug 2018, at 19:38, Akim Demaille wrote: >>> >>> The problem is with locations that don't have a constructor, such

Re: tests: disable GCC7 warnings for some tests

> On 2 Sep 2018, at 18:21, Akim Demaille wrote: > > I’m surprised we still have warnings in the test suite, > I believed I had checked GCC7 with Bison 3.1. I think I may have used the Clang 6.0.0 on MacOS [1], and did not get any 'make'check' warnings, or at least all passed that were not skipp

Re: RFC: lalr1.cc: support move semantics

> On 12 Sep 2018, at 07:06, Akim Demaille wrote: > > Here is my updated proposal. > > commit 4ba0a5eac0953e308128af23324103f9589dc37e > Author: Akim Demaille > Date: Sun Aug 12 18:05:47 2018 +0200 > >lalr1.cc: support move semantics > >Modern C++ (i.e., C++11 and later) introduced

Re: RFC: lalr1.cc: support move semantics

> On 12 Sep 2018, at 23:15, Frank Heckenbach wrote: > > Hans Åberg wrote: > >>> Modern C++ (i.e., C++11 and later) introduced "move only" types: types >>> such >>> as std::unique_ptr that can never be duplicated. They must never be >

Re: RFC: lalr1.cc: support move semantics

> On 12 Sep 2018, at 23:46, Frank Heckenbach wrote: > > Hans Åberg wrote: > >>>>> Modern C++ (i.e., C++11 and later) introduced "move only" types: types >>>>> such >>>>> as std::unique_ptr that can never be duplicated.

Re: RFC: lalr1.cc: support move semantics

> On 12 Sep 2018, at 23:46, Frank Heckenbach wrote: > > Hans Åberg wrote: > >>>>> Modern C++ (i.e., C++11 and later) introduced "move only" types: types >>>>> such >>>>> as std::unique_ptr that can never be duplicated. They

Re: RFC: lalr1.cc: support move semantics

> On 13 Sep 2018, at 06:51, Akim Demaille wrote: > > > >> Le 12 sept. 2018 à 23:46, Frank Heckenbach a écrit >> : >> >> Hans Åberg wrote: >> >>>>>> Modern C++ (i.e., C++11 and later) introduced "move only" types: typ

Re: C++ preferences

> On 13 Sep 2018, at 07:00, Akim Demaille wrote: > > I recently had to work on some piece of software with coroutines, > and known what variables are immutable was really reassuring. A C++ Simula library implemented coroutines using threads. So coroutines maybe are not a must. >> But if ther

Re: C++ preferences (was: RFC: lalr1.cc: support move semantics)

> On 12 Sep 2018, at 23:45, Frank Heckenbach wrote: > > But if there was a more concise syntax, I'd like it. I had > fantasized about a new keyword ("let") or a new syntax (":="), but > if "const" with implied "auto" can simply work, that would be great. > But we're not designing C++ here, I kn

Re: C++ preferences

> On 13 Sep 2018, at 18:53, Akim Demaille wrote: > >> Le 13 sept. 2018 à 11:12, Hans Åberg a écrit : >> >> >>> On 13 Sep 2018, at 07:00, Akim Demaille wrote: >>> >>> I recently had to work on some piece of software with coroutines, &g

Re: C++ preferences

> On 13 Sep 2018, at 21:30, Akim Demaille wrote: > >> Le 13 sept. 2018 à 20:56, Hans Åberg a écrit : >> >>> And the model is really different, >>> interruptions are controlled with coroutines, while threads are >>> preemptive. These two models a

Re: C++ preferences

> On 13 Sep 2018, at 19:00, Akim Demaille wrote: > > > >> Le 13 sept. 2018 à 11:16, Hans Åberg a écrit : >> >> >>> On 12 Sep 2018, at 23:45, Frank Heckenbach wrote: >>> >>> But if there was a more concise syntax, I'd like

Re: C++ preferences

> On 13 Sep 2018, at 21:30, Akim Demaille wrote: > >> Le 13 sept. 2018 à 20:56, Hans Åberg a écrit : >> >>> And the model is really different, >>> interruptions are controlled with coroutines, while threads are >>> preemptive. These two models a

Re: RFC: api.value.automove

> On 19 Sep 2018, at 08:56, Akim Demaille wrote: > > - should we not use YY_MOVE and just use std::move instead? In which > case the parser _must_ be compiled in C++11+. LilyPond uses a .yy file and has not yet migrated to C+++11, I think, though they are working on it.

Re: RFC: c++: provide control over the stack.hh file name

> On 24 Sep 2018, at 22:36, Akim Demaille wrote: > > It was really stupid to generate stack.hh: it’s absolutely useless > except in the parser itself. > > It’s different in the case of location.hh and position.hh. I have > several parsers that generate ASTs tagged with source locations, > usi

Re: RFC: c++: provide control over the stack.hh file name

as >> deque, as suggested by Hans Åberg) I used: >> >> %define api.stack.include deque >> %define api.stack.container {std::deque} >> >> Of course, this can be changed (if you want to include this patch at >> all — I don't care either way). > >

Re: RFC: c++: provide control over the stack.hh file name

> On 28 Sep 2018, at 12:11, Akim Demaille wrote: > >> Le 28 sept. 2018 à 10:35, Hans Åberg a écrit : >> >>> On 28 Sep 2018, at 07:06, Akim Demaille wrote: >>> >>> Do you think it’s useful? We used to use deques in the generated >>>

Re: RFC: c++: provide control over the stack.hh file name

> On 24 Sep 2018, at 22:36, Akim Demaille wrote: > > In the case of stack.hh, I think we don’t care. In fact, I expect > people to ‘%define api.stack.file none’ to not generate this file. > But in the case of location.hh/position.hh, it might be important > to generate them in foo/ast while t

Re: RFC: c++: provide control over the stack.hh file name

> On 28 Sep 2018, at 13:39, Akim Demaille wrote: > >> Le 28 sept. 2018 à 12:46, Hans Åberg a écrit : >> >>> On 24 Sep 2018, at 22:36, Akim Demaille wrote: >>> >>> In the case of stack.hh, I think we don’t care. In fact, I expect >>> p

Re: RFC: c++: provide control over the stack.hh file name

> On 28 Sep 2018, at 13:55, Frank Heckenbach wrote: > > Hans Åberg wrote: > >>> On 28 Sep 2018, at 12:11, Akim Demaille wrote: >>> >>> I know, that's why we chose deques initially. >>> But in reality, given >>> that we have t

Re: RFC: c++: provide control over the stack.hh file name

> On 28 Sep 2018, at 14:40, Frank Heckenbach wrote: > > Hans Åberg wrote: > >>> FTR, Akim, I don't care much for deque either; I use it in some >>> other places in my code where it makes sense, but I don't see a big >>> point using it in

Re: RFC: c++: provide control over the stack.hh file name

> On 28 Sep 2018, at 13:38, Akim Demaille wrote: > >> Wasn’t there std::vector in the beginning of the millennium? > > What is your question? Sure, C++ had deque and vector at the > same time. And Bison started with deque, and we moved to vector, > in 2013: It seems that in 2002, it was vec

Re: RFC: c++: provide control over the stack.hh file name

> On 29 Sep 2018, at 16:14, Akim Demaille wrote: > >> Le 28 sept. 2018 à 15:04, Hans Åberg a écrit : >> >> >>> On 28 Sep 2018, at 13:38, Akim Demaille wrote: >>> >>>> Wasn’t there std::vector in the beginning of the millennium? &g

Re: RFC: c++: provide control over the stack.hh file name

> On 30 Sep 2018, at 17:47, Paul Eggert wrote: > > Akim Demaille wrote: >>So offer the user a means to (i) decide what the name of the output >>file should be, and (ii) not generate this file at all (its content >>will be inline where the parser is defined). > > Another idea would

Re: RFC: c++: provide control over the stack.hh file name

> On 29 Sep 2018, at 16:14, Akim Demaille wrote: > >> Le 28 sept. 2018 à 15:04, Hans Åberg a écrit : >> >>> On 28 Sep 2018, at 13:38, Akim Demaille wrote: >>> >>>> Wasn’t there std::vector in the beginning of the millennium? >>> &

Re: [PATCH 0/8] provide more control over C++ file names

> On 6 Oct 2018, at 18:03, Akim Demaille wrote: > > I think I have finally reached a point where I have implemented > everything I had on my mind about the names of the auxiliary files in > C++. If I had known earlier what a burden it is, I guess I would have > hesitated more... But I really

Re: RFC: generate the default semantic action

> On 14 Oct 2018, at 12:23, Akim Demaille wrote: > > This patch is prompted by C++, but I believe it’s a real improvement > even for the other languages. However, it does mean that the default > action is now made twice in C for instance. I would very much like > to disable the pre-initializa

Re: RFC: generate the default semantic action

> On 14 Oct 2018, at 12:23, Akim Demaille wrote: > > This patch is prompted by C++, but I believe it’s a real improvement > even for the other languages. However, it does mean that the default > action is now made twice in C for instance. I would very much like > to disable the pre-initializa

Re: RFC: generate the default semantic action

> On 14 Oct 2018, at 16:54, Akim Demaille wrote: > > Le 14 oct. 2018 à 16:43, Akim Demaille a écrit : > >> Yes, I read that too, and found it extremely ambiguous. > > And Steve Johnson’s paper is just the same. > > https://www.epaperpress.com/lexandyacc/download/yacc.pdf > > By default, th

Re: RFC: generate the default semantic action

> On 14 Oct 2018, at 18:49, Akim Demaille wrote: > >> Le 14 oct. 2018 à 18:13, Hans Åberg a écrit : >> >> POSIX probably got it from there through copy-and-paste, then. > > Right. > >> So rules with empty RHS do not have any default value. What happen

Re: yacc.c: clarify the computation of yystate

> On 24 Oct 2018, at 02:39, Paul Eggert wrote: > > On 10/22/18 8:52 AM, Akim Demaille wrote: >> + const int yylhs = yyr1[yyrule] - YYNTOKENS; > > I used to work with someone who liked to declare C local variables 'register > const': 'register' so that he wasn't tempted to take the va

Re: doc: spell check

> On 26 Oct 2018, at 19:04, Akim Demaille wrote: > > Copyright (C) 1992, 1998-1999, 2003-2005, 2008-2015, 2018 Free Software > @@ -61,3 +62,6 @@ GNU General Public License for more details. I am told it should be the years with releases, and there is a discrepancy with [1]. Some years, it may

Re: doc: spell check

> On 27 Oct 2018, at 08:00, Akim Demaille wrote: > > I’m just running ‘update-copyright’ > when needed. What's this program?

Re: doc: spell check

> On 27 Oct 2018, at 09:58, Akim Demaille wrote: > >> Le 27 oct. 2018 à 09:45, Hans Åberg a écrit : >> >>> On 27 Oct 2018, at 08:00, Akim Demaille wrote: >>> >>> I’m just running ‘update-copyright’ >>> when needed. >> >&g

Re: new pacification suggestion?

> On 20 Nov 2018, at 21:32, Paul Eggert wrote: > > On 11/20/18 12:01 PM, Akim Demaille wrote: >> -if (false) >> +if ((false)) > > This goes too far. If clang is warning about this sort of thing, then we > should disable that clang warning. Again, compilers should be our servants, > n

Re: clearly deprecate %name-prefix

> On 2 Jan 2019, at 19:25, Akim Demaille wrote: > >* doc/bison.texi: Document that %name-prefix is replaced by %define >api.prefix. The formulation in the manual, sec. 3.8, is a bit confusing, a casual reading might be read as though the extra %define being a part of a syntax descript

Re: clearly deprecate %name-prefix

> On 3 Jan 2019, at 08:48, Akim Demaille wrote: > >> Le 2 janv. 2019 à 20:44, Hans Åberg a écrit : >> >> >>> On 2 Jan 2019, at 19:25, Akim Demaille wrote: >>> >>> * doc/bison.texi: Document that %name-prefix is replaced by %define &g

Re: Bison 3.3.1 released [stable]

> On 27 Jan 2019, at 16:43, Akim Demaille wrote: > > In Bison 3.3, the new option --update replaces deprecated features with > their modern spelling, but also applies fixes such as eliminating duplicate > directives, etc. This is nice feature. You might add info about along with the warnings w

Re: Bison 3.3.1 released [stable]

> On 27 Jan 2019, at 16:43, Akim Demaille wrote: > > In Bison 3.3, the new option --update replaces deprecated features with > their modern spelling, but also applies fixes such as eliminating duplicate > directives, etc. It didn't capture %debug.

Re: graph: prefer *.gv to *.dot (was: bison info doc - precedence in recursive parsing)

> On 19 Feb 2019, at 19:35, Akim Demaille wrote: > >> Le 17 févr. 2019 à 16:19, Akim Demaille a écrit : >> >>> Le 10 févr. 2019 à 15:20, Hans Åberg a écrit : >>> >>>> On 10 Feb 2019, at 11:07, Akim Demaille wrote: >>>> >&g

Re: [PATCH 0/4] Fix caret errors

> On 21 Apr 2019, at 09:41, Akim Demaille wrote: > > So what shall we do? > > 1. Should we stick to treating tabs as magical characters wrt column >numbers? Doing so gives consistent locations for people who mix >tabs and spaces. But a. they need to also tabs of 8 spaces, and >b

Re: [PATCH 0/4] Fix caret errors

> On 22 Apr 2019, at 07:29, Akim Demaille wrote: > >> The only safe way is to replace the visible characters in the quoted string >> with spaces, and then use an initial portion of that. Then you can count >> characters as you like, probably tabs as 1. > > What do you mean by "the only safe

Re: [PATCH 0/4] Fix caret errors

> On 22 Apr 2019, at 15:57, Akim Demaille wrote: > >> Le 22 avr. 2019 à 10:19, Hans Åberg a écrit : >> >>> On 22 Apr 2019, at 07:29, Akim Demaille wrote: >>> >>>> The only safe way is to replace the visible characters in the quoted >>

Re: [PATCH 0/4] Fix caret errors

> On 22 Apr 2019, at 15:57, Akim Demaille wrote: > > I assume that people use a fixed width font, or disable > caret diagnostics. What are you using to computer Unicode character width? — In C++17, std::wstring_convert has been deprecated with no replacement, so one must find something else.

Re: [PATCH 0/4] Fix caret errors

> On 23 Apr 2019, at 22:16, Akim Demaille wrote: > >> Le 23 avr. 2019 à 22:03, Hans Åberg a écrit : >> >>> On 22 Apr 2019, at 15:57, Akim Demaille wrote: >>> >>> I assume that people use a fixed width font, or disable >>> caret diag

Re: [PATCH 0/4] Fix caret errors

> On 22 Apr 2019, at 15:57, Akim Demaille wrote: > > Well, then they fixed that in 10.14(.4). BTW, what debugger are you using on MacOS?

Re: [PATCH 0/4] Fix caret errors

> On 24 Apr 2019, at 10:49, Akim Demaille wrote: > >> Le 24 avr. 2019 à 10:22, Hans Åberg a écrit : >> >>> On 22 Apr 2019, at 15:57, Akim Demaille wrote: >>> >>> Well, then they fixed that in 10.14(.4). >> >> BTW, what debugger ar

Re: diagnostics: prefer "…" to "..." if the locale supports it

> On 11 Oct 2019, at 22:14, Paul Eggert wrote: > >> diagnostics: prefer "…" to "..." if the locale supports it > > Is this really a win? I normally used fixed-width fonts, and on my platform a > string like "ABC…DEF" is all-too-easily confused with "ABC_DEF" if there are > no underscores

Re: diagnostics: prefer "…" to "..." if the locale supports it

> On 12 Oct 2019, at 08:22, Paul Eggert wrote: > > On 10/11/19 10:35 PM, Akim Demaille wrote: >>> For what it's worth, the Wikipedia manual of >>> style >>> says, "Wikipedia's style for an ellipsis is three unspaced dots (...)

Re: C++: finish propagating the unsigned->signed conversion in locations

> On 29 Oct 2019, at 21:30, Akim Demaille wrote: > > + In C++, line numbers and columns are now represented as 'int' not > + 'unsigned', so that integer overflow on positions is easily checkable via > + 'gcc -fsanitize=undefined' and the like. This affects the API for > + positions. There

Re: glr.cc: disable warnings from Clang on macOS

> On 8 Dec 2019, at 17:01, Akim Demaille wrote: > >$ cat test.cc >#include >#include > >ptrdiff_t half_max_capacity = PTRDIFF_MAX; >$ clang++-mp-9.0 -pedantic -std=c++98 /tmp/test.cc -c In C++, the header is cstddef, and from C++11, there is cstdint,

Re: glr.cc: disable warnings from Clang on macOS

> On 9 Dec 2019, at 07:15, Akim Demaille wrote: > >> Le 8 déc. 2019 à 18:04, Hans Åberg a écrit : >> >> >>> On 8 Dec 2019, at 17:01, Akim Demaille wrote: >>> >>> $ cat test.cc >>> #include >>>

Re: [PATCH 3/5] c++: improvements on symbol kinds

> On 11 Apr 2020, at 08:47, Akim Demaille wrote: > > Instead of > >/// (Internal) symbol kind. >enum symbol_kind_type >{ > YYNTOKENS = 5, ///< Number of tokens. ... > generate > >/// Symbol kinds. >struct symbol_kind >{ > enum symbol_kind_type > { >

Re: [PATCH 3/5] c++: improvements on symbol kinds

> On 15 Apr 2020, at 06:54, Akim Demaille wrote: > > Hi Hans, Hello, >> Le 14 avr. 2020 à 22:27, Hans Åberg a écrit : >> >> I use symbol table lookups of the form: >> std::optional> x = >> mli::symbol_table.find(yylval.text); >> >>

Re: [PATCH 3/5] c++: improvements on symbol kinds

> On 15 Apr 2020, at 17:45, Akim Demaille wrote: > >> Le 15 avr. 2020 à 10:56, Hans Åberg a écrit : >> >>> I don't plan to break compatibility here. I'm providing better names. >>> In your case, instead of token_type it should be token_ki

Re: [PATCH 3/5] c++: improvements on symbol kinds

> On 15 Apr 2020, at 18:25, Akim Demaille wrote: > >> Le 15 avr. 2020 à 18:15, Hans Åberg a écrit : >>>>> In retrospect, it would have been better to have it named "token_type", >>>>> and "stack_symbol_type" would have been "

Re: [PATCH 3/5] c++: improvements on symbol kinds

> On 16 Apr 2020, at 06:51, Akim Demaille wrote: > >> Le 15 avr. 2020 à 18:42, Hans Åberg a écrit : >> >>> On 15 Apr 2020, at 18:25, Akim Demaille wrote: >>> >>> And token_type denotes the type which is a triple: token_kind_type, >>>

Re: FTR:

> On 29 Apr 2020, at 19:06, Paul Eggert wrote: > > On 4/28/20 10:58 PM, Akim Demaille wrote: >> I think >> the cure is worse than the disease, as some "great" leader loves to >> put it... > > I know this is irrelevant but I tried to chase down the first use of the > phrase > "cure is worse th

Re: [PATCH 3/3] cex: prefer → to ::=

> On 12 Jul 2020, at 08:19, Akim Demaille wrote: > >> Unfortunately the literal `→` is output as `↦`. So we need to use >> @arrow. > > As a matter of fact, @arrow works in PDF, but not with makeinfo. So > I install this. TeXinfo Unicode support is dismal, so for systematic use, one will hav

Re: [PATCH 1/4] style: add missing copyright headers

Though by the nature of examples, you may not want to add a copyright notice on them: As special cases of something more general, they may not be sufficiently creatively unique to be copyrightable, and in addition, you may want people to use them without a worry of copyrighting. > On 18 Dec 20

Re: [PATCH 1/4] style: add missing copyright headers

> On 20 Dec 2020, at 11:15, Akim Demaille wrote: > > Hi Hans, > > Long time no see! I have to focus some difficult code to write. :-) >> Le 19 déc. 2020 à 11:06, Hans Åberg a écrit : >> >> Though by the nature of examples, you may not want to add a copyrig

Re: A lovely comment

My first computer was a SWTPC 6800 at 980 KHz! > On 13 Jan 2021, at 06:45, Akim Demaille wrote: > > I meant to share with you a comment I just found in reduce.c. > > /*---. > | Another way to do this would be with a set for each pr

Re: A lovely comment

> On 23 Jan 2021, at 00:36, Paul Eggert wrote: > > On 1/13/21 1:28 AM, Hans Åberg wrote: >> My first computer was a SWTPC 6800 at 980 KHz! > > Hah, the first computer I used was a GE 225 codesigned by Steven Spielberg's > father. It took 36 µs to add two intege

Re: [PATCH 5/9] build: reject C++ compilers that don't support std::vector::data

> On 12 Aug 2021, at 10:18, Akim Demaille wrote: > > GCC 4.2 on macOS claims to support C++98, but does not feature it. > > input.cc: In member function 'void state_stack::yycompressStack()': > input.cc:1774: error: 'class std::vector std::allocator >' has no member named 'data' The member 'd

Re: [PATCH 5/9] build: reject C++ compilers that don't support std::vector::data

> On 13 Aug 2021, at 08:11, Akim Demaille wrote: > >> Le 12 août 2021 à 10:40, Hans Åberg a écrit : >> >>> On 12 Aug 2021, at 10:18, Akim Demaille wrote: >>> >>> GCC 4.2 on macOS claims to support C++98, but does not feature it. >>&g

Re: [PATCH 5/9] build: reject C++ compilers that don't support std::vector::data

> On 17 Aug 2021, at 08:49, Akim Demaille wrote: > > Hi Hans, > >> Le 13 août 2021 à 09:52, Hans Åberg a écrit : >> >>> On 13 Aug 2021, at 08:11, Akim Demaille wrote: >>> >>>> Le 12 août 2021 à 10:40, Hans Åberg a écrit

Re: [PATCH 5/9] build: reject C++ compilers that don't support std::vector::data

> On 17 Aug 2021, at 08:49, Akim Demaille wrote: > > Hi Hans, > >> Le 13 août 2021 à 09:52, Hans Åberg a écrit : >> >>> On 13 Aug 2021, at 08:11, Akim Demaille wrote: >>> >>>> Le 12 août 2021 à 10:40, Hans Åberg a écrit

Re: [PATCH 5/9] build: reject C++ compilers that don't support std::vector::data

> On 19 Aug 2021, at 08:10, Akim Demaille wrote: > >> Le 17 août 2021 à 15:46, Hans Åberg a écrit : >> >>> On 17 Aug 2021, at 08:49, Akim Demaille wrote: >>> >>> You need to read my answer, and the page it pointed you to. >> >> I ch

Re: [PATCH 00/14] glr2.cc: fix linking conflicts

> On 13 Sep 2021, at 07:29, Akim Demaille wrote: > > Hi Tom, > >> Le 12 sept. 2021 à 20:50, Tom Shields a écrit : >> >> Akim, >> >> The Ox attribute grammar evaluator generator compiles, links, and passes its >> regression tests under macOS Big Sur (v11.5.2) using this version of Bison >>

Re: [PATCH 00/14] glr2.cc: fix linking conflicts

> On 13 Sep 2021, at 07:29, Akim Demaille wrote: > > Hi Tom, > >> Le 12 sept. 2021 à 20:50, Tom Shields a écrit : >> >> Akim, >> >> The Ox attribute grammar evaluator generator compiles, links, and passes its >> regression tests under macOS Big Sur (v11.5.2) using this version of Bison >>

Re: [PATCH 00/14] glr2.cc: fix linking conflicts

> On 13 Sep 2021, at 16:19, Thomas Shields > wrote: > > Thanks for the note. :-) > I should have mentioned that the version of Ox I was reporting against is > 1.10 (under development, I’m the only developer). Great! > I’m in the process of “upgrading” the Ox source from C to C++, allowing

Re: [PATCH 00/14] glr2.cc: fix linking conflicts

> On 13 Sep 2021, at 17:37, Tom Shields wrote: > > I tried building the Ox 1.6 distributed release as follows: > > ./configure --enable-maintainer-mode BISON=bison-3.8.1.21 > > Note: this uses the Apple Xcode C compiler. > > I get fails on these Ox test cases: bison-3.x-calc, bison-3.x-calc-

Re: gnulib: update

> On 31 Jul 2022, at 11:04, Akim Demaille wrote: > > We are still unable to complete distcheck successfully. I found it useless, because it makes the sources read only, and then force compiles sources that are set to not compile: lexer, parser, PDF, or whatever. So if one has set it so that

Re: gnulib: update

> On 31 Jul 2022, at 11:23, Akim Demaille wrote: > > Hans, Hi Akim, >> Le 31 juil. 2022 à 11:17, Hans Åberg a écrit : >> >> >>> On 31 Jul 2022, at 11:04, Akim Demaille wrote: >>> >>> We are still unable to complete distcheck success

Re: gnulib: update

> On 31 Jul 2022, at 11:23, Akim Demaille wrote: > > Hans, > >> Le 31 juil. 2022 à 11:17, Hans Åberg a écrit : >> >> >>> On 31 Jul 2022, at 11:04, Akim Demaille wrote: >>> >>> We are still unable to complete distcheck successfully