Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!think!ames!ptsfa!ihnp4!ihlpm!nevets
From: nevets@ihlpm.ATT.COM (Steven R Ringwood)
Newsgroups: comp.sources.bugs
Subject: Re: Help needed for Logo on Unix
Message-ID: <1271@ihlpm.ATT.COM>
Date: Mon, 20-Jul-87 16:57:33 EDT
Article-I.D.: ihlpm.1271
Posted: Mon Jul 20 16:57:33 1987
Date-Received: Wed, 22-Jul-87 01:47:22 EDT
References: <1740@encore.UUCP> <330@rabbit1.UUCP> <1649@sfsup.UUCP>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 66
Summary: where to define YYDEBUG

In article <1649@sfsup.UUCP>, mpl@sfsup.UUCP (M.P.Lindner) writes:
> The complaints of yacc are normal and OK.  It is merely saying there are
> conflicts in the grammar.  It does resolve them, though.  The reason for
> the messages is that the grammar writer should know how many conflicts
> there are, and know that he got what he expected.
> 
> As for the #if problem, I ran accross that, too.  You need to have a
> 
> #define YYDEBUG 0
> 
> somewhere.  Yacc includes lines of the form
> 
> #if YYDEBUG
> 
> which conditionally compiles code if YYDEBUG evaluates to a non-zero expression.
> However, since YYDEBUG is never #defined, the preprocessor sees an undefined
> symbol name where it expects a numeric expression.
> 
> Mike Lindner
> ...!ihnp4!attunix!mpl

There was a note about making sure YYDEBUG is defined or lines
of the form "#if YYDEBUG" will cause problems.
If you make the following change to logo.h, it will make sure
that YYDEBUG is defined to a known value.
This fixed the problem for me.

**** WAS ****

#ifdef DEBUG
#define YYDEBUG
#define JFREE jfree
#else
#define JFREE free
#endif

**** CHANGED ****

#ifdef DEBUG
#define YYDEBUG 1
#define JFREE jfree
#else
#define YYDEBUG 0
#define JFREE free
#endif

============================================================

Also, i was having problems with parsing which turned out to be a
problem in yylex1().
It defines a local variable c of type char, but the function
getchar returns a value of type FAST (int).
This is a common problem and is solved by changing the local
variable c to type FAST.
The behavior that results from this error was typing something
to logo that used a new function, off went logo into never-never
land because the EOF was not seen.

Other than these two small problems the logo looks good.
I wish i could play with turtles, but the machine i am on
does not support them, oh well.
Hopefully someone will port it to the AMIGA, then i can use it there.

					Steve Ringwood
					ihlpm!nevets