QUESTION: is bison recursive?
Anyone know if bison is recursive? Meaning, does the bison build call bison? The reason I'm asking is because I'm going through the bison 3.0 makefile and I don't see where bison is actually being called. Sean ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: QUESTION: is bison recursive?
I found the implicit rule in the Makefile. I believe it's calling a bison in the tests subfolder. Thanks for your help Tadej and Hans On Sun, 7/27/14, Tadej Borovšak wrote: Subject: Re: QUESTION: is bison recursive? To: help-bison@gnu.org Date: Sunday, July 27, 2014, 9:12 PM Dne 27.07.2014 (ned) ob 20:29 +0200 je Hans Aberg napisal(a): > On 27 Jul 2014, at 02:35, sean nakasone wrote: > > > Anyone know if bison is recursive? Meaning, does the bison build call bison? > > Yes, the file src/parse-gram.y is used to make the Bison parser. > > > The reason I'm asking is because I'm going through the bison 3.0 makefile and I don't see where bison is actually being called. > > A grep on the sources shows > Makefile.in: src/parse-gram.y > but I’m not sure how exactly its called. Perhaps Akim, which I think implemented it, can tell. If I'm not mistaken, make has built-in rule for *.y -> *.c conversion. This is probably why no explicit rule is to be found in build system. Cheers, Tadej -- Tadej Borovšak tadej.borov...@gmail.com tadeb...@gmail.com blog.borovsak.si ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: QUESTION: is bison recursive?
thanks Valentin, i wasnt aware of the -p option. Sent from my iPhone > On Jul 27, 2014, at 11:29 PM, Valentin Tolmer > wrote: > > Hello, > > From a make -p (to display implicit rules), I get > %.c: %.y >$(YACC.y) $< >mv -f y.tab.c $@ > > In most systems, yacc is aliased to bison when installed. > > Cheers, > > > >> On Mon, Jul 28, 2014 at 9:12 AM, Tadej Borovšak wrote: >> >> Dne 27.07.2014 (ned) ob 20:29 +0200 je Hans Aberg napisal(a): >>>> On 27 Jul 2014, at 02:35, sean nakasone wrote: >>>> >>>> Anyone know if bison is recursive? Meaning, does the bison build call >> bison? >>> >>> Yes, the file src/parse-gram.y is used to make the Bison parser. >>> >>>> The reason I'm asking is because I'm going through the bison 3.0 >> makefile and I don't see where bison is actually being called. >>> >>> A grep on the sources shows >>> Makefile.in: src/parse-gram.y >>> but I’m not sure how exactly its called. Perhaps Akim, which I think >> implemented it, can tell. >> >> If I'm not mistaken, make has built-in rule for *.y -> *.c conversion. >> This is probably why no explicit rule is to be found in build system. >> >> Cheers, >> Tadej >> >> -- >> Tadej Borovšak >> tadej.borov...@gmail.com >> tadeb...@gmail.com >> blog.borovsak.si >> >> >> ___ >> help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison > > > > > -- > Valentin Tolmer > ___ > help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: Bison for windows ?
In addition to cygwin, you can use mingw. If you are trying to build bison, I would recommend mingw. I tried building bison under cygwin and just had too many issues. Building bison with mingw still had a few issues but I was able to figure it out. Let me know if you have questions. On Thu, 9/18/14, Alfonso Urdaneta wrote: Subject: Re: Bison for windows ? To: help-bison@gnu.org Date: Thursday, September 18, 2014, 11:26 AM On 9/18/14, 1:30 PM, John H. Lindsay wrote: > I'm looking for Bison for Windows (any version), but unless I am missing > something or misunderstanding something, all I seem to see is the > development version for Unix (Linux ?). Any comments or pointers > would be helpful. Hi John, I've had success using bison under cygwin in the past. Best of luck, Alfonso. ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
QUESTION: what does LR(0) mean? and what's behind the name LR0.c ?
Hi, I'm going through the bison code, and I'm curious as to the name of the source code file LR0.c . Seems like this file creates the states. After they are created, the first state is at state 0. Is this why it's called LR0.c ? Could it have been named something like generate-states.c ? I'm not picky about names, but I just want to make sure I'm not missing some important concept. ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
QUESTION: alias
Hi, In the bison source code, the symbol structure has an alias attribute which is a *symbol. Is this alias used solely for associating a token type name to a literal string constant? i.e. %token arrow "=>" Is the alias used in other situations? Thanks, Sean ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
QUESTION: trying to speed up "make install"
Hi, everytime I run "make install", it does this... installing ast.gmo as /usr/local/share/locale/ast/LC_MESSAGES/bison-runtime.mo installing da.gmo as /usr/local/share/locale/da/LC_MESSAGES/bison-runtime.mo installing de.gmo as /usr/local/share/locale/de/LC_MESSAGES/bison-runtime.mo installing el.gmo as /usr/local/share/locale/el/LC_MESSAGES/bison-runtime.mo installing eo.gmo as /usr/local/share/locale/eo/LC_MESSAGES/bison-runtime.mo installing es.gmo as /usr/local/share/locale/es/LC_MESSAGES/bison-runtime.mo installing et.gmo as /usr/local/share/locale/et/LC_MESSAGES/bison-runtime.mo ... Is this for multilanguage support? I only need english, anyway I can speed this up? Thanks, Sean ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
QUESTION: what is \c, \pre, \post in ielr.c ?
Hi, in ielr.c , there's comments that refer to things like: \post, \pre, \c . What do these mean? Here's an example: /** * \pre: * - \c ritem_sees_lookahead_set was computed by * \c ielr_compute_ritem_sees_lookahead_set. * \post: * - Each of \c *edgesp and \c *edge_countsp is a new array of size * \c ::ngotos. * - (*edgesp)[i] points to a \c goto_number array of size * (*edge_countsp)[i]+1. * - In such a \c goto_number array, the last element is \c ::END_NODE. * - All remaining elements are the indices of the gotos to which there is an * internal follow edge from goto \c i. * - There is an internal follow edge from goto \c i to goto \c j iff both: * - The from states of gotos \c i and \c j are the same. * - The transition nonterminal for goto \c i appears as the first RHS * symbol of at least one production for which both: * - The LHS is the transition symbol of goto \c j. * - All other RHS symbols are nullable nonterminals. * - In other words, the follows of goto \c i include the follows of * goto \c j and it's an internal edge because the from states are the * same. */ static void ielr_compute_internal_follow_edges (bitset ritem_sees_lookahead_set, goto_number ***edgesp, int **edge_countsp) ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: gcc --coverage and copying Bison generated files
perhaps lookup VPATH Sent from my iPhone > On Nov 26, 2014, at 6:03 PM, Daiki Ueno wrote: > > Hello, > > Sorry for that this is not really related to Bison (but GCC or LCOV), > but perhaps a common question that anyone might know the solution. > > In gettext we have the following directory structure: > > gettext-runtime/ >intl/ > Makefile > plural.y > plural.c # <-- generated from plural.y > ... > > gettext-tools/ >intl/ > Makefile > > In order for gettext-runtime and gettext-tools to be built separately, > gettext-tools/intl/Makefile refers to the source code in > gettext-runtime/intl/ instead of copying the object files. > > So gettext-tools/intl/Makefile looks like: > > srcdir = ../../gettext-runtime/intl > > plural.lo: $(srcdir)/plural.c > $(AM_V_CC)$(LIBTOOL) $(AM_V_lt) --tag=CC --mode=compile \ >$(COMPILE) $(srcdir)/plural.c > > This works for normal compilation. However, when compiling with the > --coverage option of GCC, the generated .gcno file embeds relative file > name annotated with #line directive in plural.c. That confuses LCOV: > > genhtml: ERROR: cannot read /tmp/...snip.../gettext-tools/intl/plural.c > > http://hydra.nixos.org/build/17564911/log/tail-reload > > Is there any easy way to tell GCC the correct source file location? Or > should we copy all the source files? > > Thanks in advance, > -- > Daiki Ueno > > ___ > help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
set_goto_map() has unintentional ++ operator
in lalr.c the ++ at the end of the following line doesn't have a purpose goto_number k = temp_map[TRANSITION_SYMBOL(sp, i) - ntokens]++; it can be misleading. Sent from my iPhone ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
QUESTION: what technique used in pack_tables() ?
Hi Folks, anyone know what technique is used in pack_tables() ? This is in tables.c. Is the goal to find the order of something that uses the least amount of space? There's a comment "Use the greatest possible negative infinites". What does this mean? ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: set_goto_map() has unintentional ++ operator
Hi Akim, I didn't test it, nor did I run it in a debugger.. so there must be
something I'm not seeing.
The placement of the ++ makes it a post increment, so it's incremented after
the statement, so it should not affect the value of k.
It's incrementing values in temp_map, but temp_map is deallocated after the for
loop, so that's why I thought it wasn't doing anything.
for (s = 0; s < nstates; ++s)
{
transitions *sp = states[s]->transitions;
int i;
for (i = sp->num - 1; i >= 0 && TRANSITION_IS_GOTO (sp, i); --i)
{
goto_number k = temp_map[TRANSITION_SYMBOL (sp, i) - ntokens]++;
from_state[k] = s;
to_state[k] = sp->states[i]->number;
}
}
free (temp_map);
I appreciate your efforts and follow up.
On Mon, 12/29/14, Akim Demaille wrote:
Subject: Re: set_goto_map() has unintentional ++ operator
To: "Sean Nakasone"
Cc: "Bison Help"
Date: Monday, December 29, 2014, 5:29 AM
> Le
21 déc. 2014 à 21:51, Sean Nakasone
a écrit :
>
> in
lalr.c
>
> the ++ at
the end of the following line doesn't have a purpose
>
> goto_number k =
temp_map[TRANSITION_SYMBOL(sp, i) - ntokens]++;
>
> it can be
misleading.
hi Sean,
Well, this piece of code is
old, and it does not seem immediate
(to me)
that the ++ is useless :)
from_state = xcalloc (ngotos, sizeof
*from_state);
to_state = xcalloc (ngotos,
sizeof *to_state);
for
(s = 0; s < nstates; ++s)
{
transitions *sp =
states[s]->transitions;
int
i;
for (i = sp->num - 1; i >=
0 && TRANSITION_IS_GOTO (sp, i); --i)
{
goto_number k = temp_map[TRANSITION_SYMBOL (sp, i) -
ntokens]++;
from_state[k] =
s;
to_state[k] =
sp->states[i]->number;
}
}
free (temp_map);
FTR, byacc (beach and bison are forks of a
common ancestor) reads:
from_state = NEW2(ngotos, Value_t);
to_state = NEW2(ngotos, Value_t);
for (sp = first_shift; sp; sp =
sp->next)
{
state1 = sp->number;
for (i =
sp->nshifts - 1; i >= 0; i--)
{
state2 = sp->shift[i];
symbol =
accessing_symbol[state2];
if (ISTOKEN(symbol))
break;
k = temp_map[symbol]++;
from_state[k] = state1;
to_state[k] = state2;
}
}
FREE(temp_map +
ntokens);
it has the same
++.
What
makes you think it is useless? If I remove it, some tests
fail
(they hang), or I can even get a
SEGV.
$ cat input.y
%%
start: end end {} ;
end:
{ } ;
$ ./_build/35s/tests/bison
input.y
./_build/35s/tests/bison: line 28:
87593 Segmentation fault: 11 $PREBISON
"$abs_top_builddir/src/bison"
${1+"$@"}
___
help-bison@gnu.org
https://lists.gnu.org/mailman/listinfo/help-bison
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: set_goto_map() has unintentional ++ operator
oops! you're right. sorry for the trouble.
Sent from my iPhone
> On Dec 29, 2014, at 12:06 PM, Hans Aberg wrote:
>
>
>>> On 29 Dec 2014, at 22:40, sean nakasone wrote:
>>
>> The placement of the ++ makes it a post increment, so it's incremented after
>> the statement, so it should not affect the value of k.
>>
>> It's incrementing values in temp_map, but temp_map is deallocated after the
>> for loop, so that's why I thought it wasn't doing anything.
>>
>> for (s = 0; s < nstates; ++s)
>> {
>> transitions *sp = states[s]->transitions;
>> int i;
>> for (i = sp->num - 1; i >= 0 && TRANSITION_IS_GOTO (sp, i); --i)
>> {
>> goto_number k = temp_map[TRANSITION_SYMBOL (sp, i) - ntokens]++;
>> from_state[k] = s;
>> to_state[k] = sp->states[i]->number;
>> }
>> }
>>
>> free (temp_map);
>
> It loops through the inner loop several times though, so the next time, the
> value has changed.
>
>
>
> ___
> help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: set_goto_map() has unintentional ++ operator
i wasnt reading the code thoroughly... i apologize.
how do run the test suite?
Sent from my iPhone
> On Dec 30, 2014, at 2:43 AM, Akim Demaille wrote:
>
>
>> Le 29 déc. 2014 à 22:40, sean nakasone a écrit :
>>
>> Hi Akim, I didn't test it, nor did I run it in a debugger.. so there must
>> be something I'm not seeing.
>>
>> The placement of the ++ makes it a post increment, so it's incremented after
>> the statement, so it should not affect the value of k.
>
> This, I agree. But what makes you think the following
> iterations don't rely on this?
>
> Well, at least the test suite believes it :)
>
>>
>> It's incrementing values in temp_map, but temp_map is deallocated after the
>> for loop, so that's why I thought it wasn't doing anything.
>>
>> for (s = 0; s < nstates; ++s)
>> {
>> transitions *sp = states[s]->transitions;
>> int i;
>> for (i = sp->num - 1; i >= 0 && TRANSITION_IS_GOTO (sp, i); --i)
>> {
>> goto_number k = temp_map[TRANSITION_SYMBOL (sp, i) - ntokens]++;
>> from_state[k] = s;
>> to_state[k] = sp->states[i]->number;
>> }
>> }
>>
>> free (temp_map);
>>
>>
>>
>> I appreciate your efforts and follow up.
>>
>>
>>
>> ----
>> On Mon, 12/29/14, Akim Demaille wrote:
>>
>> Subject: Re: set_goto_map() has unintentional ++ operator
>> To: "Sean Nakasone"
>> Cc: "Bison Help"
>> Date: Monday, December 29, 2014, 5:29 AM
>>
>>
>>> Le
>> 21 déc. 2014 à 21:51, Sean Nakasone
>> a écrit :
>>>
>>> in
>> lalr.c
>>>
>>> the ++ at
>> the end of the following line doesn't have a purpose
>>>
>>> goto_number k =
>> temp_map[TRANSITION_SYMBOL(sp, i) - ntokens]++;
>>>
>>> it can be
>> misleading.
>>
>> hi Sean,
>>
>> Well, this piece of code is
>> old, and it does not seem immediate
>> (to me)
>> that the ++ is useless :)
>>
>> from_state = xcalloc (ngotos, sizeof
>> *from_state);
>> to_state = xcalloc (ngotos,
>> sizeof *to_state);
>>
>> for
>> (s = 0; s < nstates; ++s)
>>{
>> transitions *sp =
>> states[s]->transitions;
>> int
>> i;
>> for (i = sp->num - 1; i >=
>> 0 && TRANSITION_IS_GOTO (sp, i); --i)
>>{
>>
>> goto_number k = temp_map[TRANSITION_SYMBOL (sp, i) -
>> ntokens]++;
>> from_state[k] =
>> s;
>> to_state[k] =
>> sp->states[i]->number;
>>
>> }
>>}
>>
>> free (temp_map);
>>
>> FTR, byacc (beach and bison are forks of a
>> common ancestor) reads:
>>
>>
>> from_state = NEW2(ngotos, Value_t);
>>
>> to_state = NEW2(ngotos, Value_t);
>>
>>for (sp = first_shift; sp; sp =
>> sp->next)
>>{
>>
>> state1 = sp->number;
>>for (i =
>> sp->nshifts - 1; i >= 0; i--)
>>
>> {
>>state2 = sp->shift[i];
>>symbol =
>> accessing_symbol[state2];
>>
>>if (ISTOKEN(symbol))
>>break;
>>
>>k = temp_map[symbol]++;
>>from_state[k] = state1;
>>to_state[k] = state2;
>>}
>>}
>>
>>FREE(temp_map +
>> ntokens);
>>
>> it has the same
>> ++.
>>
>>
>> What
>> makes you think it is useless? If I remove it, some tests
>> fail
>> (they hang), or I can even get a
>> SEGV.
>>
>> $ cat input.y
>> %%
>> start: end end {} ;
>> end:
>> { } ;
>> $ ./_build/35s/tests/bison
>> input.y
>> ./_build/35s/tests/bison: line 28:
>> 87593 Segmentation fault: 11 $PREBISON
>> "$abs_top_builddir/src/bison"
>> ${1+"$@"}
>>
>>
>>
>> ___
>> help-bison@gnu.org
>> https://lists.gnu.org/mailman/listinfo/help-bison
>>
>> ___
>> help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
>
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
QUESTION: obstack, size of new chunk?
Hi, lib/obstack.c has a function, _obstack_newchunk(). there's a formula used to calculate a variable new_size new_size = (obj_size + length) + (obj_size >> 3) + h->alignment_mask + 100; i understand obj_size + length, but what's the other stuff for? thanks, Sean Sent from my iPhone ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: QUESTION: trying to speed up "make install"
thanks for your reply. make install is too slow for me since i was running it after many incremental changes. i've since been using make src/bison.exe; cp src/bison.exe /usr/local/bin which is working well for my incremental changes. Sent from my iPhone > On Jan 4, 2015, at 9:58 AM, Akim Demaille wrote: > > >> Le 3 nov. 2014 à 05:56, sean nakasone a écrit : >> >> Hi, everytime I run "make install", it does this... >> >> installing ast.gmo as >> /usr/local/share/locale/ast/LC_MESSAGES/bison-runtime.mo >> installing da.gmo as /usr/local/share/locale/da/LC_MESSAGES/bison-runtime.mo >> installing de.gmo as /usr/local/share/locale/de/LC_MESSAGES/bison-runtime.mo >> installing el.gmo as /usr/local/share/locale/el/LC_MESSAGES/bison-runtime.mo >> installing eo.gmo as /usr/local/share/locale/eo/LC_MESSAGES/bison-runtime.mo >> installing es.gmo as /usr/local/share/locale/es/LC_MESSAGES/bison-runtime.mo >> installing et.gmo as /usr/local/share/locale/et/LC_MESSAGES/bison-runtime.mo >> ... >> >> Is this for multilanguage support? >> >> I only need english, anyway I can speed this up? > > I don't know, you'll have to read the Makefiles. But really, > you need to speed up "make install"??? You think it's slow? ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
