On Tuesday 02 June 2009 22.27:11 Kynn Jones wrote:
> Hi. I'm working with Bison (and Flex) for the first time, and it's rough
> going.
good luck ... we have all been there:-)
Not sure I would have started with the locations though.
This topic comes up from time to time, so it might be worth sea
On Sunday 05 August 2007 15:18, Laurence Finston wrote:
> On Sun, 5 Aug 2007, Hans Aberg wrote:
> > When I tried it, it worked:
> > $ bison parser.y++
> > parser.y++: conflicts: 455 shift/reduce, 1 reduce/reduce
I got the same.
>
> I never upload non-working versions. If I have a similar question
On Tuesday 29 May 2007 13:23, Bunny Joy wrote:
> flex version 2.5.4
consider to upgrade to 2.5.33
> bison (GNU Bison) 1.35
consider to upgrade to v2.2 or later
>
> # flex -olexa.yy.c ch1-05.l
> # bison -obisa.tab.c ch1-05.y
> # gcc -o ex bisa.tab.c lexa.yy.c -ll
which version of gcc ?
Try to disab
On Friday 02 March 2007 15:23, Edsko de Vries wrote:
> > do you have a link or can you send me the scanner file alone ?
> Sure. phc is hosted by Google code; the scanner is at
> http://phc.googlecode.com/svn/phc/trunk/src/generated_src/php_scanner.lex
but when you compare with
http://pl1gcc.cvs.s
On Friday 02 March 2007 15:15, Edsko de Vries wrote:
> On Fri, Mar 02, 2007 at 03:02:43PM +0100, [EMAIL PROTECTED] wrote:
> > On Friday 02 March 2007 14:54, Edsko de Vries wrote:
> > > If you have a
> > > good solution for that, I'd be very interested to hear it!
> >
> > look at pl1gcc.sourceforge.
On Friday 02 March 2007 15:04, Edsko de Vries wrote:
> If we insert a NOP instead for blank lines, then the comment gets
> associated with the NOP, and we get exactly what the user wrote.
>
> Incidentally, the same problem also arises with Henrik's location
> tracking solution.
no as pointed out e
On Friday 02 March 2007 14:54, Edsko de Vries wrote:
> If you have a
> good solution for that, I'd be very interested to hear it!
look at pl1gcc.sourceforge.net
in the scanner you 'just' have to do all the bean counting yourself, and you
have to come up with a prober structure to keep the locatio
On Friday 02 March 2007 14:50, Tim Van Holder wrote:
> To me this seems like the same problem as preserving comments in a
> parse-process-generate system (which is a pain in the ass).
not really a problem.
If using the location tracking feature, it would be trivial to add some fields
to keep trac
On Friday 02 March 2007 13:39, Edsko de Vries wrote:
> On Fri, Mar 02, 2007 at 01:17:04PM +0100, [EMAIL PROTECTED] wrote:
> > On Friday 02 March 2007 13:01, Edsko de Vries wrote:
> > > Well, no, that's the point. Blank lines should be recorded as NOPs
> > > where possible, so that we know where the
On Friday 02 March 2007 13:01, Edsko de Vries wrote:
> Well, no, that's the point. Blank lines should be recorded as NOPs where
> possible, so that we know where they are and unparse them.
Can you reveal some details regarding what you are trying to do ?
Henrik
On Friday 02 March 2007 12:30, Edsko de Vries wrote:
> Hi,
>
> Is there any way I can make Bison ignore tokens when it can't deal with
> them? I'll try to explain. For every completely blank line in the input,
> my leexer generates a NOP token. In some situations the parser can deal
> with this NOP
On Wednesday 01 November 2006 00:44, Joel E. Denny wrote:
> On Fri, 27 Oct 2006, Joel E. Denny wrote:
> > I think I'm seeing it your way at least as far as these mid-rule warnings
> > are concerned. Looking at it from another angle, while it's probably ok
> > to warn about potentially dangerous us
On Friday 27 October 2006 00:12, you wrote:
> On Thu, 26 Oct 2006 [EMAIL PROTECTED] wrote:
> > > in semantic actions at any level in the parse tree. Bison would have
> > > to check every possible expansion of every possible RHS symbol. That
> > > implementation seems like more work than I want to
On Thursday 26 October 2006 22:55, Joel E. Denny wrote:
> On Thu, 26 Oct 2006 [EMAIL PROTECTED] wrote:
> > > That is, do you believe this warning is too much trouble to be
> > > worthwhile?
> >
> > The warning would be ok, if it was only true.
>
> It's true inasmuch as we specifically intended to w
On Thursday 26 October 2006 21:35, Joel E. Denny wrote:
> On Thu, 26 Oct 2006 [EMAIL PROTECTED] wrote:
> > On Thursday 26 October 2006 20:45, Joel E. Denny wrote:
> > > On Thu, 26 Oct 2006 [EMAIL PROTECTED] wrote:
> > > > On Thursday 26 October 2006 02:27, Joel E. Denny wrote:
> > >
> > > That's ni
On Thursday 26 October 2006 20:45, Joel E. Denny wrote:
> On Thu, 26 Oct 2006 [EMAIL PROTECTED] wrote:
> > On Thursday 26 October 2006 02:27, Joel E. Denny wrote:
> That's nice. I'm wondering why the grammar doesn't use $-1 and drop the
> mid-rule entirely, but I haven't test this. I'm thinking
On Thursday 26 October 2006 10:41, Akim Demaille wrote:
> >>> "Hans" == Hans Aberg <[EMAIL PROTECTED]> writes:
>
> [Just passing by, no time for more :( ]
>
> > It was before I recalling you showing up on the list. Probably Bug-
> > Bison. Perhaps Akim or Paul can inform the truth about $0.
>
> I
On Thursday 26 October 2006 02:27, Joel E. Denny wrote:
> > Line 873 contains: | procoptionlist ',' {$$=$1;} procoption {$$=$1;}
> > $3 refers to the embedded action after the comma.
>
> In the last semantic action above, write:
>
> USE($3)
>
> > My grammar set a number of attributes in an alloc
On Wednesday 25 October 2006 23:35, Hans Aberg wrote:
> >> be guaranteed, in view of that Bison is switching to other types of
> >> containers than an underlying array.
> > but should the container still support the $0 notation ?
that did not come out right, should have read
...but surely the new c
On Wednesday 25 October 2006 21:22, Hans Aberg wrote:
> On 25 Oct 2006, at 17:05, [EMAIL PROTECTED] wrote:
> > My grammar set a number of attributes in an allocated structure
> > using $0 to
> > reference the structure on the stack. The full rules are as follow
> > procoption:
> > MAIN { if
Hi Bison list,
using bison version 2.2.
Message from bison:
pl1-parser.y:873.17-63: warning: unused value: $3
This warning I find a bit confusing...
Line 873 contains: |procoptionlist ',' {$$=$1;} procoption {$$=$1;}
$3 refers to the embedded action after the comma.
My grammar set a number
>
> Attached an input file.
sorry I meant the flex grammar file..
Henrik
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
On Monday 04 September 2006 09:57, Anouar LACHHEB wrote:
> Hi
>
> I created a parser using Bison v 2.1 calling a scanner written using Flex v
> 2.5.4a.
> Below is a part of my parser code:
what does the flex scanner input look like ?
Henrik
___
help-bi
On Tuesday 04 July 2006 18:42, RichAnderson wrote:
> I have never been able to find an EBCDIC port of bison 2+. That's is why I
> am attempting it.
Good luck.
If you need help with some testing, please drop me a note.
>
> The last version that I successfully ported was 1.875
Henrik
_
On Monday 03 July 2006 20:45, RichAnderson wrote:
> I am attempting to port Bison 2.0 to a machine which uses the EBCDIC
> character set. This version of bison wants to use itself to rebuild
> parse-gram.y. This assumes that the existing version is the correct code
> set. I can't use 1.875
is the
On Thursday 09 March 2006 09.36, Spikx wrote:
> Hello,
>
> I recently began to learn the basic principles of parsers, context free
> grammar and espcially bison, because I need it for a project. But I
> wondered if the use of bison would be suitable at all in my case.
imo, the question is can you w
On Tuesday 21 February 2006 08.27, Akim Demaille wrote:
> Le 20 févr. 06 à 15:07, Akim Demaille a écrit :
> > Don't use YYPRINT, see %printer in the recent docs.
> Err, on second thought, it is not yet documented :) For instance
> %printer { fprintf (stderr, "%d", $$); } integer [etc...]
> @$ is a
Howcome, when you have enabled %location, the yylocationp parameter in
yysymprint is not passed to YYPRINT ?
static void
yysymprint (yyoutput, yytype, yyvaluep, yylocationp)
FILE *yyoutput;
int yytype;
YYSTYPE *yyvaluep;
YYLTYPE *yylocationp; <=== It is there
# ifdef YYPRINT
On Monday 16 January 2006 16.46, Steve Murphy wrote:
> On Mon, 2006-01-16 at 08:56 +, Evan Lavelle wrote:
> > Henrik Sorensen wrote:
> > > For the pl1 problem, I cheated a bit with flex, and when certain
> > > conditions are met I simply save all the token met, an
On Friday 13 January 2006 13.10, Steve Murphy wrote:
> Hello--
>
> Been playing with bison/flex for years; think they're great.
indeed !
>
> There are few interoperability issues between them, however.
well, that's of course a point of view, but IMO they really serve two
different purposes.
>
> On
look in the output file for all of the 'go to state 118', this will give you
the hints were the grammar are conflicting.
hope this helps
Henrik
On Sunday 12 June 2005 15.04, Frans Englich wrote:
> Hi,
>
> In my grammar I have 2 shift/reduce conflicts. I could find those by
> staring at my gramma
On Thursday 14 April 2005 03.08, hz kto wrote:
> I was wondering are there any tools out there that allow to view bison
> parse tree in graphics some sort of pseudo graphics
I recently discovered a tool: ebnf2ps by Peter Thiemann.
www.informatik.uni-freiburg.de/~thiemann/haskell/ebnf2ps
it can ta
or is '.' in your grammar ?
Henrik
>
> -Soumitra.
>
> --- Henrik Sorensen <[EMAIL PROTECTED]> wrote:
> > can you tell a bit more about what your grammar
> > tries to achieve ?
> > from your very brief description, it sounds like you
> &g
can you tell a bit more about what your grammar tries to achieve ?
from your very brief description, it sounds like you can do this:
1+3.YYID(7)
but what would this mean ?
Henrik
On Sunday 27 March 2005 21.37, Soumitra Kumar wrote:
> %token YYID
> %%
> expression : hier_id
>
> | me
On Wednesday 02 March 2005 19.50, Hans Aberg wrote:
> Please keep the cc to help-bison so that others may help.
could you restate your problem ?
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
On Tuesday 01 March 2005 19.02, Soumitra Kumar wrote:
> Henrik,
> So, if I get the following output (rule no after a
> lookahead symbol), finding the ambiguous rules is
> trivial.
well, in the output file you can search for all the states that have a goto
your state 10.
_
Your grammar is ambigious.
It can be seen if you make the following transformation, factoring out the
null transition of opt_select, and you will see the shift/reduce conflict:
%token YYID YYDOT
%%
identifier : hier_id;
hier_id : simple_id
| hier_id YYDOT simple_id
| hier_id opt_select YYDOT simp
37 matches
Mail list logo
