I was able to use Bison in combination with MS Visual C++ by using
DJGPP:
http://www.delorie.com/djgpp/
I considered using Cygwin, but it seemed easier to use DJGPP so I never looked
into Cygwin further.
Laurence Finston
Original-Nachricht
> Datum: Fri, 13 Nov 2009 16:22
I always just pick one (`int', but it doesn't really matter). You don't have
to set `$$' to a value in a rule.
Laurence Finston
Original-Nachricht
> Datum: Mon, 12 Oct 2009 15:05:15 -0400
> Von: Rodrigo Dominguez
> An: help-bison@gnu.org
> Be
On Mon, 8 Dec 2008, Luca wrote:
> Laurence Finston ha scritto:
> > On Fri, 5 Dec 2008, Benny Hardage wrote:
> >
> >
> > > %union
> > > {
> > > int intVal;
> > > bool boolVal;
> > > char* s
' for everything else. `void*' as `YYSTYPE' would do the trick,
but I find it convenient to have semantic values of the other types
without having to use casts.
Laurence Finston
On Fri, 5 Dec 2008, Benny Hardage wrote:
> Hello,
>
> I'm receiving the following errors wh
On Mon, 1 Dec 2008, sgaurelius wrote:
>
> I found out how to do this. I have one other problem though. When I debug, it
> doesn;t go where it should go. I mean, if I have a rule L_BRKT expr R_BRKT,
> in the parser.cc there is a switch statement and this rule is one case of
> it. When I set a br
On Fri, 28 Nov 2008, Samuel Tardieu wrote:
> I wrote "this C++ code". It means that you must compile it with g++ (otherwise
> it is valid C code), as well as link it with g++ (without deriving too much,
> let me just say that g++ called in link mode does a bit more than linking --
> it takes car
ide of a namespace or a class, it should be possible
to link
with the object file in which they are defined without the linker having to
do anything special. However, it's been a long time since I read
anything about this subject and this may be naive.
Laurence
On Fri, 28 Nov 2008, Sa
n I had
> manipulating the expression without bison. now with bison, if I want to the
> same thing, i have to make it from the start. I will try to do it just with
> bison, but if it gets too complicated, I might use my old function to find
> dimensions and then do whatever I want wi
you might have to convert strings to
numbers in your parser rules, which isn't very difficult.
There are probably other approaches, but these are the ones that occur to
me off the top of my head. However, I can't think of any reason why I
would want to keep the strings.
Laurence Fins
w off the top of my head.
With respect to Bison, it is absolutely no problem to generate a C parser
and include C++ code in the actions and link it with C++ code. This is
mostly how I use Bison and I've never had any problem with it.
Laurence Finston
___
ing on the [EMAIL PROTECTED]' list,
unless someone on this one has an idea. Flex, of course, has its own
mailing list or lists.
Laurence Finston
On Wed, 15 Oct 2008, Jim Michaels wrote:
> well, I used C versions of everything like you said to do, and made them .cpp
> files.
> I ha
e' again with the correct prefix argument. However, if this
doesn't work on the first try, I think it would
probably be safest to install a fresh version in the new location.
One way of making a fresh version would be to call `make dist' in the old
location and copy the `bison
m I'm working on now and it works fine.
Scanning character-by-character, as discussed before, should solve the
problem if your scanner is somehow missing an `EOF' and then blocking.
I can't think of any reason why it would be a problem.
Laurence Finston
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
On Mon, 13 Oct 2008, Jim Michaels wrote:
> fgets & fgetc stops when it reaches a ^z character (eof character) ^d on
> unix. the batch mode flex does not I think do this, because it uses fread.
> however, it might if you open the file in text mode instead of binary.
> If you happen to want to
do not know what happens when fstream
> is used, whether it is read as text or binary, and whether fstream's seek is
> 64-bit or not.
I'll think about this when I've had a chance. The easiest way to cope
with this is by reading a character at a time. I've written a couple of
scanners by hand that do this. If the problem lies with Flex, it's not
hard to write a scanner by hand.
Laurence Finston
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
son. It works
just fine to generate a C parser with C++ code in the actions and compile
with a C++ compiler.
Laurence Finston
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
ou want to. And checking for errors is always good (unless you check
so much that your program never gets around to doing any useful work).
Laurence Finston
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
On Mon, 11 Aug 2008, kogorman wrote:
> Laurence Finston wrote:
>
> Nope, I grep for yyerrok on all files in the directory, and see only my own
> code and
> things directly generated from it. I do not see a #define or other
> definiton.
> Did you do this from the code I
n', for example, returns a `FILE*' and I don't know of
any function from the C++ STL that does the same thing and returns
a stream object instead. One might even have a reason to use
file descriptors. Generating C++ parser or generating a C
parser that contains C++ code i
ex(YYSTYPE* lvalp, yyscan_t parameter);
int
yywrap(void);
int
yyerror(void* v, char const* s);
For what it's worth, I don't see any particular advantage in generating a
C++ parser instead of a C parser, but that's just my opinion and I haven't
kept up with developments with re
h.gnu.org/viewvc/metaexchange/scantest/?root=metaexchange
The code for one is in `dbcrprsr.w' and the other in `parser.w'. Both
functions are called in `main.web'.
I haven't touched this code in a long time, but it worked the last time I
did.
Laurence Finston
___
ted your
posting because "Windows Internationalization" sounded like it could be
spam to me.
Laurence Finston
On Wed, 9 Jul 2008, Luca wrote:
> Hello!
>
> I have written a compiler for a pascal-like language, using flex and bison.
> The compiler is built under
On Tue, 13 May 2008, Frans Englich wrote:
> On Saturday 10 May 2008 21:00:50 Laurence Finston wrote:
> I agree, I don't think this is caused by wrong recursion. I can't change my
> grammar, and I can't discard tokens based on the test expression because it
> cannot
I don't remember the
details. On the other hand, that's an indication that it works properly.
I'll probably be off-line until Tuesday, so if you have any questions,
don't be surprised if I don't answer right away. I will do so as soon as
I can, but I don't hav
On Fri, 29 Feb 2008, Ilyes Gouta wrote:
>
> > fexpr: /* Empty */
> > {
> > /* Action for empty case */
> > };
> >
> > fexpr: expr
> > {
> > /* Action for `expr' case */
> > };
>
> I wasn't aware the one could duplicate a rule so that it has two
> possible bodies. But it's alright, th
te arguments, based on the presence
or absence of the `assignments' and/or `expr', and, if present, their
values.
I'm not sure about your `block'. It may make sense from the point of
view of a formal grammar, but in practice, it means parsing the same
input multiple times. Have
On Wed, 20 Feb 2008, Bob Rossi wrote:
> Hi Laruence,
>
> Sorry for the extremely long delay.
No need to apologize.
> I'm trying out your suggestion now.
> Whenver I put a struct in the parse param like so,
> %parse-param { struct gdbmi_pdata *gdbmi_pdata }
> I get a compiler warning,
> ../.
On Mon, 24 Dec 2007, Ilyes Gouta wrote:
> Thank you, Laurence and Evan, for your extensive explanations!
You're welcome.
It occurred to me that another reason why
GCC creates a syntax tree or whatever it's called (I know virtually
nothing about the theory of compilers) is that GCC has mul
y, it would probably be a good idea for you to choose more
descriptive subjects. The subject "newbie" made me think this was spam
and I very nearly deleted it. "[help-bison]" is not added automatically.
Laurence Finston
On Thu, 13 Dec 2007, James Long wrote:
> I'
pop out at me yet.
> ___
These are very old versions of Bison. I recommend that you update. The
one on my system is 2.3. I believe it's the current official release.
Laurence Finston
__
On Sun, 21 Oct 2007, [EMAIL PROTECTED] wrote:
> Ilyes Gouta wrote:
>
> > Hmm.. So bison is able to read from data buffers instead of a FILE*.
> > How can I achieve that?
>
> I don't remember off-hand. It's documented in the manual, or you can look
> in my source code. It involves `yyin'.
>
S
Having
worked with Visual Studio and other Microsoft products, I am not
surprised that you reported this. If it were me, I would go through
that header and see what other macros it defines.
I would prefer that Bison not use preprocessor macros, but rather `const
ints
On Sun, 14 Oct 2007, Laurence Finston wrote:
> point p;
> p := (1, 2, 3);
>
> When `p' is read, the rule "variable: tag suffix"' is eventually
> reduced.
I meant the `p' in the second line. The
On Sun, 14 Oct 2007, Ilyes Gouta wrote:
> Well the problem is that the generic token IDENTIFIER can refer to a
> variable which can hold an integer as well as a float (depending on
> its type). This is the source of my worries. How can I have a separate
> set of rules for ints and floats knowing t
On Sat, 13 Oct 2007, Claudio Saavedra wrote:
>
> El s??b, 13-10-2007 a las 11:06 +0200, [EMAIL PROTECTED] escribi??:
> > It's a typical homework assignment for people
> > studying computer science.
>
> Hm, and maybe he is actually doing such a homework? :-)
More's the pity if he were. That's
On Mon, 24 Sep 2007, [EMAIL PROTECTED] wrote:
> Thanks, Laurence,
You're welcome.
>
> I'll take a look and see if this route is the one for me. In terms
> of building from the source, I'm just trying to be consistent (grab
> the tar/zip file, untar/unzip, and build on each platform).
> Binarie
On Wed, 8 Aug 2007, Hans Aberg wrote:
> On 8 Aug 2007, at 14:20, Laurence Finston wrote:
>
> The Bison from the CVS works fine, too. :-)
>
That's a good idea, thanks. I didn't think of doing that. As long as I
had to install it locally, I might as well keep up with the
I've now determined that using a more recent version of Bison helps. I
was using 1.875. I added a rule that caused Bison to abort and then tried
it with 2.1, which succeeded. I ran both versions using input that didn't
cause 1.875 to fail and the number of shift/reduce conflicts differed.
I'
The important point is that `yyparse' is just a function and the file
of C code that contains it is just an ordinary "compilation unit". The
same rules of scoping and linkage apply to them as to other functions and
compilation units.
Laurence Finston
___
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 never upload non-working versions. If I have a similar question
again, I'll upload examples to an ftp server. Sorry for the
inconvenience this ti
On Sat, 4 Aug 2007, Hans Aberg wrote:
> Since the files are rather large, did you considering provide a URL instead.
The relevant source code is here:
http://cvs.savannah.gnu.org/viewvc/3dldf/3dldf/Group/CWEB/
(a subdirectory of the CVS repository for GNU 3DLDF)
It contains the files `parser.ou
next rule to be reduced.
However, there's nothing to stop you from maintaining one or more
references to it in other data structures, to which you will have access
in the actions. I would have thought that your tree would be such a data
structure.
If you need to have access to your ojbects as r
you may not
need them. I've described this technique in previous postings
to this mailing list. Hans Aberg has also published an article
on a similar but more general technique.
Laurence Finston
http://www.gnu.org/software/3dldf/LDF.html
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
On Fri, 22 Jul 2005, Atul Kulkarni wrote:
> Well I would not really worry about them but one variant of Bison Yacc
> just does not generate output "c" code for this grammar. That's what
> worries me.
>
It may be that Bison fails if the number of conflicts
is different from the value specified usi
On Fri, 22 Jul 2005, Atul Kulkarni wrote:
> I am facing a problem with the Grammar i am feeding to the Bison. It
> throws 2 shift reduce conflicts. Please help with this I am not able
> to resolve them.
If shifting is the correct behavior, my advice is to not worry about it.
Laurenc
r
casting in the action and pass a 'void*' to the function.
Laurence Finston
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
ng a second parser function
using Bison, say 'zzparse()', and calling it in one or more of the actions
in your A parser.
Laurence Finston
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
s technique,
nested loops are a snap to implement, but not the ultimate in efficiency.
Incidentally, I've used a similar technique for macros.
Laurence Finston
http://www.gnu.org/software/3dldf/LDF.html
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
On Wed, 8 Jun 2005, Laurence Finston wrote:
> If you only ever delete objects by means of their corresponding
> 'Object_Type::object' pointers, than it would be safe to use simple
> pointers to 'Foo*'.
Sorry, I meant "si
On Tue, 7 Jun 2005, hz kto wrote:
>
>
> If I have a list like this wouldn't I run into the problem when,
> a parent node deletes some child nodes, then when I come across
> this child in the list, I will crash since it has been deleted already?
That was the point of the following remark:
> > Dep
On Tue, 7 Jun 2005, Michel Rosien wrote:
> Thanks for the reply
You're welcome.
>
> > If it's not possible, and you only call 'yyparse()' once,
> > then I think you might as well use a globally or statically declared
> > pointer to point to the object referenced by your parameter.
>
> This is wh
ove, in case you feel like looking this up.
> Is it hard to incorporate destructor functionality from 2.0 into 1.25? What
> kind
> of changes would that require?
Why not just upgrade to 2.0? However, the approach outlined above is
not compatible with the use of '%destructor'.
Laurence Finston
http://www.gnu.org/software/3dldf/LDF.html
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
. It might also turn
out to be advantageous to use a pointer to a pointer.
Laurence Finston
http://www.gnu.org/software/3dldf/LDF.html
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
onsider writing your own version of 'yylex()'. It's not that hard, and you
might find it easier to implement the queueing of the requests from your
numerous clients.
In the approach I've outlined, you wouldn't need to save and restore anyt
> statement_list: statement_list statement
This should be
statement_list:: /* Empty */
| statement_list statement
Please excuse my sloppiness.
Laurence
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-b
Hello,
This message doesn't seem to have made it to the list. At any rate, it
doesn't appear in the archive. If it did get through before, I apologize
for the duplication.
Laurence Finston
-- Forwarded message --
Date: Sat, 04 Jun 2005 00:37:50 +0200
From: Lauren
would be easier and safer to just spawn a thread for each
client
and call 'yyparse()' in that thread.
I don't see any reason for using processes, unless your system
doesn't support threads.
Laurence Finston
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
> With unions, one wants to avoid dynamic allocations. Each dynamic
> allocation takes several tens, sometimes, hundreds of cycles.
If pointers are used, then memory needs to be allocated for the objects they
point to, whether the pointers are in a `struct' or a `union'. It needn't be
allocated
From: Hans Aberg
--
--
> This discussion is very confusing, because it mixes two topics:
> Extending C++, and what is appropriate for Bison.
This is just my opinion, but I don't think adding type information to `union'
On Thu, 24 Mar 2005, Hans Aberg wrote:
> It would not be the old union, but a new union with new required
> semantics, that is clear.
My point was that `union' is an element of the C and C++ languages,
whereas your new `Union' class would not be. I think this is important,
others may not.
> >Th
On Wed, 23 Mar 2005, Hans Aberg wrote:
> At 14:16 +0100 2005/03/23, Laurence Finston wrote:
> >Add it where?
> Just add a field, invisible to the user, with the type information.
I meant "in C++ or in Bison?"
> Dynamic allocations must have such a field with the
Hans Aberg wrote:
> With unions, the problem is, if con-/de-structors are non-trivial, that it
> is impossible to know which ones to apply and when.
Stroustrup, _The C++ Programming Language_, Special Edition, 2000,
p. 257, Section 10.4.12:
"Consequently, a union may not have members with constr
On Tue, 22 Mar 2005, Laurence Finston wrote:
> @=%type path_primary@>@/
> [...] in the rule
> `path_primary: SUBPATH numeric_list OF path_primary',
> `$4' can only be a `Path*', cast to `void*'.
This isn't true. The semantic value of a symbol of type
`p
On Sun, 20 Mar 2005, DYP wrote:
> My %union is declared in the following way [...]
>
> %union{
> float fconst;
> int type;
> astNode* node;
> string* name;
> nodeList* list;
>}
>
If you don't mind an unsolicited suggestion,
On Mon, 21 Mar 2005, Hans Aberg wrote:
> They should be OK in C++, as pointers do not have non-trival
> con-/de-structors. The compiler needs to see a declaration of the
> name as a type, though, before it sees the pointer.
If I remember correctly, it has to do with the size of the objects not
be
n letter
extension: extension digit
Laurence Finston
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
se these are types that can't be included in
`unions'. I don't remember the rule off-hand --- it has something to do
with constructors and/or destructors. I don't know whether this
programming error would cause this particular compiler error to be
signalled, though, and I
> I prefer Qt to STL - not only because I know it better, but also because of
> the documentation. I haven't found an adequate documentation for STL yet,
> sorry :-)
I suggested using STL strings and lists because you said you were having
problems. To my way of thinking, Stroustrup's _The C++ Pr
On Fri, 11 Mar 2005, Frank Heckenbach wrote:
> Laurence Finston wrote:
>
> > I've found that I prefer using Flex and Bison separately rather than
> > together. If you're just starting out learning Bison, I think you
> > might find it easier to write your
ype
> Anyone can help me with this please? Any ideas? Any suggestions ?
>
Apparently, you need to declare types for the symbols used on the
right-hand side of your rule for `program'.
Laurence Finston
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
n't see an error message about an undefined reference to `yylex()'.
Since you have an undefined reference to `yyparse()', I would check two
things first:
1. Is `yyparse()' declared in a header file included by all compilation
units containing a call to it?
2. Is the object fil
ation,
my code is available at
http://savannah.gnu.org/cgi-bin/viewcvs/3dldf/3dldf/Group/CWEB/
I define `struct Thread_Info_Type' in the file `pspglb.web'.
Otherwise, I recommend David Butenhof's book
_Programming with POSIX Threads_.
Laurence
y, if it's not empty, it contains one or more tokens, and
`yylex()' immediately pops the top token from the stack and returns it to
`yyparse()'. You could use another data member of the parameter to
indicate whether you've reach
73 matches
Mail list logo
