Hi, there's this there
> On 9 Jul 2020, at 06:51, Akim Demaille wrote:
>
>> Le 8 juil. 2020 à 22:14, Akim Demaille a écrit :
>>
>> That reminds me of a paper I read long ago, someone proposing
>> "heisentokens": having the scanner return multiple tokens concurrently,
>> for the different scann
Hi,
> On 7 Jul 2020, at 10:55, John P. Hartmann wrote:
>
> On 7/7/20 05:35, Akim Demaille wrote:
>> I believe you need to read again the documentation of /
>> 'r/s'
>
> It is not as simple as that. As I don't speak BASIC, let me rephrase this
> problem in FORTRAN IV which is also "blank agnos
This is elegant to me. I think it can be put to work, but am not sure.
for_construct :
TOKEN_FOR optional_whitespace
identifier TOKEN_EQ number optional_whitespace
TOKEN_TO optional_whitespace
number
{
/* nodes with values at indexes $3, $5, $9 */
}
> On
Just realized bison-announce is not listed in
//www.gnu.org/software/bison/
Together with the other *classic* lists.
Maybe someone would want to tell the webmaster?
E.g. consider appending something such as
"Release candidates are announced previously on bison-announce, for packagers,
distro ma
Cheers,
> On 6 May 2019, at 14:23, uxio prego wrote:
>
> Maybe related?
>
> /usr/local$ find . | grep -i bison | grep -i lib
> ./Cellar/bison/3.1/lib
> ./Cellar/bison/3.1/lib/liby.a
> [...]
>
> I miss the dynamic version but
>
> 🤷♀️
>
> Cheers,
&g
Sent from my iPhone
> On 6 May 2019, at 14:50, Hans Åberg wrote:
>
>
>> On 6 May 2019, at 11:28, r0ller wrote:
>>
>> Hi All,
>>
>> Is it possible in *any* way to get the left hand side symbol in an action of
>> a rule? Say, I have:
>>
>> A : B C
>> {
>>std:cout<<"left hand side symbo
I thought they mean the [non terminal] **symbol**,
instead of the actual object?
Regards,
> On 6 May 2019, at 14:27, Giacinto Cifelli wrote:
>
> Hi,
>
> you refer to the left-hand side with $$. Provided it has a 'printable'
> type (int, char *, string), it should output.
>
> BR,
> Giacinto
>
Maybe related?
/usr/local$ find . | grep -i bison | grep -i lib
./Cellar/bison/3.1/lib
./Cellar/bison/3.1/lib/liby.a
[...]
I miss the dynamic version but
🤷♀️
Cheers,
Sent from my iPhone
> On 6 May 2019, at 02:37, Joao Pedro Abreu De Souza wrote:
>
> Hi folks. My friend Nicholas and I are t
fully
>>> declarative and your rules are "pure". That's not the case of Flex/Bison:
>>> you must define rules with actions. Yet you should keep your action simple
>>> and move complex processing into functions.
>> Uxio said:
>>
>>> Le 17
>
>> On 17.02.19 13:22, workbe...@gmx.at wrote:
>>> So my Bison and Flex code is out of date ?
>>>
>>>
>>> On 17.02.19 13:04, Uxio Prego wrote:
>>>> Hi,
>>>> review your Makefile, it has errors. Read the Make docs,
>>&g
Hi,
review your Makefile, it has errors. Read the Make docs,
the basic use is:
TARGET: DEPENDENCIES
ACTIONS_THAT_USE_DEPENDENCIES_TO_UPDATE_TARGET
You might want to try emulating Yacc if the booking you
are using is enough old and in case current Bison could
not be able to really foll
Hey,
can’t remember any such graphviz failure, even with graphs
so large, their output isn't actually useful, unless for navigating
with e.g. xdot.
I however have only used -Tpng, never -Tpdf. Also no -O, but I
guess that’s simply and works the same for all cases.
> On 4 Feb 2019, at 21:50, Hans
Hi Simon,
> On 27 Dec 2018, at 04:29, Simon Richter wrote:
>
> [...]
>
> [...] Setting up a CI
> system that pulls "experimental" Bison into a chroot and test-compiles a
> project there is doable with medium effort, but we'd have to actively
> convince people to do that, and package maintainers
Hi, that's unimportant detail. It's just future 3.3 however
for whatever reason not yet properly identified.
Cheers,
> On 27 Dec 2018, at 11:15, Wouter Beek wrote:
>
> Hi Akim,
>
> On more thing I noticed:
>
> ```
> $ bison --version
> bison (GNU Bison) 3.2.1.139-5fb0d-dirty
> Written by Robe
> On 26 Dec 2018, at 20:10, Uxio Prego wrote:
>
> When I changed from the `master` branch to the
> `v3.2.4` tag some docs got apparently moved from
> `src/whatever.extension` to `src/whatever.extension~`...
> don't understand why...
In my case just moving the extraneou
> On 26 Dec 2018, at 19:11, Wouter Beek wrote:
>
> Dear Akim,
>
> Thanks for looking into my issue!
>
>> I ran the same sequence, and it worked as expected. I would need more
>> information, such as more the complete logs of "make". You do have flex,
>> right?
>
> [...]
>
> Here are th
> On 26 Dec 2018, at 19:03, Uxio Prego wrote:
>
> To whomever might concern,
>
> I followed OP's steps while on macOS and only was able to
> finish bootstrap once dirtied several `md5sum` occurrences
> replacing by `md5`, in `/PATH/TO/BISON/gnulib/gnulib-tool`.
I&
To whomever might concern,
I followed OP's steps while on macOS and only was able to
finish bootstrap once dirtied several `md5sum` occurrences
replacing by `md5`, in `/PATH/TO/BISON/gnulib/gnulib-tool`.
I've found that `md5sum` is part of GNU Coreutils, which I
previously had selected via Homebr
> On 21 Dec 2018, at 10:22, Hans Åberg wrote:
>
>> On 21 Dec 2018, at 10:00, Uxio Prego wrote:
>>
>>> A threaded parser aside, I found threading difficult to debug in general,
>>> so good with a way to turn it off.
>>
>> Not sure what do y
> On 15 Dec 2018, at 20:52, Hans Åberg wrote:
>
>> On 15 Dec 2018, at 19:31, Uxio Prego wrote:
>>
>> [...]
>
> The Bison generated parser is platform independent, so it can distributed,
> and if you do that, you can move to latest Bison as quickly as pos
> On 15 Dec 2018, at 18:44, Hans Åberg wrote:
>
>
>> On 15 Dec 2018, at 17:02, Uxio Prego wrote:
>>
>>> Bison installs in /usr/local/ direct from the sources in [1], and works
>>> fine will their inhouse version of clang. Bison also needs m4 which
> On 15 Dec 2018, at 17:02, Uxio Prego wrote:
>
>> On 15 Dec 2018, at 15:20, Hans Åberg wrote:
>>
>>> On 15 Dec 2018, at 11:05, Uxio Prego wrote:
>>>
>>> Fortunately other projects such as Homebrew allow a
>>> straightforward selecti
> On 15 Dec 2018, at 13:49, Akim Demaille wrote:
>
>> Le 15 déc. 2018 à 11:05, Uxio Prego a écrit :
>>
>> Does anybody know when Bison 3 is going to be added to
>> macOS?
>
> I was unaware that Bison was shipped as part of macOS. [...]
$ /usr/bin/b
> On 15 Dec 2018, at 15:20, Hans Åberg wrote:
>
>
>> On 15 Dec 2018, at 11:05, Uxio Prego wrote:
>>
>> Does anybody know when Bison 3 is going to be added to
>> macOS?
>>
>> Fortunately other projects such as Homebrew allow a
>> straightfo
> On 15 Dec 2018, at 13:49, Akim Demaille wrote:
>
>> Le 15 déc. 2018 à 11:05, Uxio Prego a écrit :
>>
>> Does anybody know when Bison 3 is going to be added to
>> macOS?
>
> $ git log COPYING | head -5
> commit f16b08196c780556cbf50691e2944960aebc46
Does anybody know when Bison 3 is going to be added to
macOS?
Fortunately other projects such as Homebrew allow a
straightforward selection of a cutting edge alternative Bison
under `/usr/local/`, however isn't it a bit sad to add Homebrew
as a dependency to some other software if it would be adde
Well... for flex 2.6.4 goes away when replacing `%option noyywrap` for
a real `int _wrap(void) { return 1; }`. So that’s an easy workaround
if those warnings where blockers. But I think the `%option` should prevent
such thing from popping up.
> On 25 Nov 2018, at 17:39, Uxio Prego wr
So the problem was in an upper scope, a label never jumped to.
Please forgive me this little off-topic: I'm having the same alert in
https://github.com/westes/flex/blob/98018e3f58d79e082216d406866942841d4bdf8a/src/flex.skl#L1394
didn't report there yet. For no particular reason other I maybe wante
> On 20 Nov 2018, at 20: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,
>
Yet another small comment,
> Begin forwarded message:
>
> From:
> Subject:
> Date:
> To:
>
>
>
>> On 15 Nov 2018, at 21:35, Uxio Prego wrote:
>>
>> Hi, my usage is yielding me a block like this:
>>
>> ...
>
> If I'm not mi
> On 15 Nov 2018, at 21:35, Uxio Prego wrote:
>
> Hi, my usage is yielding me a block like this:
>
> ...
If I'm not mistaken, this is happening exactly the same in either Bison
2.3 and 3.1, and according
https://stackoverflow.com/a/14186528/1737973
the compiler would
Hi, my usage is yielding me a block like this:
-
/*---.
| yyerrorlab -- error raised explicitly by YYERROR. |
`---*/
yyerrorlab:
/* Pacify compilers like GCC when the user code never invok
Alright, but
> On 8 Nov 2018, at 23:37, Hans Åberg wrote:
>
>> On 8 Nov 2018, at 22:34, Uxio Prego wrote:
>>
>>> [...]
>>
>> The example and explanation are worth a thousand words,
>> thank you very much. So I use a simple grammar like that, and
&
> For fixity overloads (same name but different fixity), one can have the
> overloads used in C/C++: prefix and postfix (as in ++), or prefix and infix
> (as in -), but not infix and postfix. This requires extra processing, keeping
> track of the token that was before; Bison cannot do that, so t
> You cannot use Bison to resolve dynamically your precedence if
> you have a free set of levels. But if you have a fixed number
> of level, say 10, [...]
Fixed number seems perfectly enough to me.
> you could define ten tokens for each level,
> map each operator to the corresponding level, stori
at right?
> On 8 Nov 2018, at 14:48, Hans Åberg wrote:
>
>
>> On 2 Nov 2018, at 17:53, Uxio Prego wrote:
>>
>> More specifically, I'm curious to know if Bison can modify precedences
>> at parsing time according user sentences, now referring as user not the
&
d doc, and executing it in a later stage after
some semantic analysis out of Bison.
However, if Bison could react to some rule reconfiguring the way it sorts
precedences, I would find that rather interesting.
Thank you very much,
> Begin forwarded message:
>
> From: Uxio Prego
> S
Hi,
if there is anything new to comment in this question:
https://stackoverflow.com/questions/31503059/custom-operators-in-bison-yacc
I would love to read it.
Thank you very much,
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
lly yet,
for it to remove the _line_ preprocessor directives.
Also I haven't figured out yet how to configure that Make target as
a build step before the program target itself.
> On 6 Oct 2018, at 10:47, Hans Åberg wrote:
>
>
>> On 5 Oct 2018, at 21:29, Uxio Prego wrote:
>
Hi,
if you happen to use GNU Bison from Apple Xcode, I got a
question for you:
How would you detect Xcode from GNU Make?
I would want to run `sed 's/#line/\/\/#line/'` on the generated parser
in order for it not to show as assembly during debugging. I think
Xcode has some kind of non honoring to
6, Hans Åberg () escribió:
>
>
> > On 1 Sep 2018, at 19:22, Uxio Prego wrote:
> >
> > For a couple miscellaneous reasons I have seldom used custom
> > installs of (then) newer GCC versions to `/usr/local/`.
> >
> > If I ever need a newer or more canonical Clan
t;> On 1 Sep 2018, at 15:52, Uxio Prego wrote:
>>
>> Oh, sorry. Code written by me in the action of a production rule
>> was causing my problem.
>
> So issue resolved! Note however that you use the Apple inhouse Clang. If you
> so like, you might download the real o
Oh, sorry. Code written by me in the action of a production rule
was causing my problem.
Cancel my notice. Deepest apologies.
> On 1 Sep 2018, at 11:54, akim wrote:
>
> Le 2018-08-30 07:47, uxio prego a écrit :
>
> Hi!
>
>> Dear maintainer,
>> I bet you alread
of this will be enough compliant with your etiquette
(which I'm not familiar with), and in any case you already have (if
that helps) an open source not reduced example.
Thank you. Truly best cheers and regards!
> On 1 Sep 2018, at 11:54, akim wrote:
>
> Le 2018-08-30 07:47,
Dear maintainer,
I bet you already know that Bison... 2.7 up to... 3.1 I think?
Can output a PREFIX.tab.c doc so that when compiled by
LLVM 9 a security warning (see `man 3 printf`) gets
emitted.
I don't know much about LLVM, but I think they claim to be
GCC compatible. Does Bison in any way claim
45 matches
Mail list logo
