lubich@ethz.UUCP (Hannes Lubich) (07/01/87)
I have tried to compile the logo sources posted to the net recently.
This is the result up to now on my MicroVaxII, running Ultrix32m V 1.0:
yacc logo.y
Setup...
cpres ...
cempty ...
cpfir ...
stagen ...
output ...
go2out ...
hideprod ...
summary ...
conflicts: 19 shift/reduce, 80 reduce/reduce
callopt ...
others ...
conflicts: 19 shift/reduce, 80 reduce/reduce
*** Error code 2
fatal error: cannot find parser yypars.c, line 650
Stop.
Since I'm not that familiar with yacc I would like to ask if somebody
else got the same experience and (maybe) found a solution already.
Thanks
--Hannes
PS: According to the MANIFEST there are no files missing.
--
~ UUCP/Usenet : {known world}!seismo!mcvax!cernvax!ethz!lubich
~ CSNET : lubich%ifi.ethz.chunet@relay.cs.net
~ ARPA : lubich%ifi.ethz.chunet@csnet-relay.arpa
The usual disclaimer : No, it wasn't me, somebody must have used my account.pierson@encore.UUCP (Dan Pierson) (07/10/87)
Trying to yacc logo.y produces:
conflicts: 19 shift/reduce, 80 reduce/reduce
Bison produces the same thing, though the diagnostics seem better.
Does anyone know what the problem is?
dan
{talcott,linus,necis,decvax,ihnp4}!encore!pierson
--
dan
{talcott,linus,necis,decvax,ihnp4}!encore!piersondml@rabbit1.UUCP (David Langdon) (07/14/87)
in article <1740@encore.UUCP>, pierson@encore.UUCP (Dan Pierson) says: > Keywords: yacc, help, the meaning of life > Summary: I'm having yacc problems too. > > Trying to yacc logo.y produces: > > conflicts: 19 shift/reduce, 80 reduce/reduce > > Bison produces the same thing, though the diagnostics seem better. > > Does anyone know what the problem is? > > dan > I am experiencing the same problems, in addition to the cc failing on the y.tab.c result with errors in preprocessor ifdef's?????? Help please (note that if I run y.tab.c through the preprocessor 1st, save the output and then cc the output, it works OK??). -- David Langdon Rabbit Software Corp. (215) 647-0440 7 Great Valley Parkway East Malvern PA 19355 ...!ihnp4!{cbmvax,cuuxb}!hutch!dml ...!psuvax1!burdvax!hutch!dml
mpl@sfsup.UUCP (M.P.Lindner) (07/17/87)
In article <330@rabbit1.UUCP>, dml@rabbit1.UUCP writes: > in article <1740@encore.UUCP>, pierson@encore.UUCP (Dan Pierson) says: > > Trying to yacc logo.y produces: > > > > conflicts: 19 shift/reduce, 80 reduce/reduce > > > > Bison produces the same thing, though the diagnostics seem better. > > > > Does anyone know what the problem is? > > I am experiencing the same problems, in addition to the cc failing on the > y.tab.c result with errors in preprocessor ifdef's?????? > > Help please (note that if I run y.tab.c through the preprocessor 1st, save the > output and then cc the output, it works OK??). 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
gregg@a.cs.okstate.edu (Gregg Wonderly) (07/18/87)
in article <330@rabbit1.UUCP>, dml@rabbit1.UUCP (David Langdon) says: > in article <1740@encore.UUCP>, pierson@encore.UUCP (Dan Pierson) says: >> Keywords: yacc, help, the meaning of life >> Summary: I'm having yacc problems too. >> >> Trying to yacc logo.y produces: >> >> conflicts: 19 shift/reduce, 80 reduce/reduce >> dan >> > > I am experiencing the same problems, in addition to the cc failing on the > y.tab.c result with errors in preprocessor ifdef's?????? > > Help please (note that if I run y.tab.c through the preprocessor 1st, save the > output and then cc the output, it works OK??). > Earlier I answered a similar question by saying that logo.y was botched in transmission. I have since gotten another copy, and it too exibits the same problems. My guess is that we must have a broken cpp. Run /lib/cpp on the y.tab.c and let the output go to your screen. Cpp seems to get mad while it is in the middle of passing over a rather large array initialization. I don't have time to look into this, but rather have resolved to do what you did. Someone else undoubtedly knows what is wrong with cpp. ----- Gregg Wonderly Department of Computing and Information Sciences Oklahoma State University UUCP: {cbosgd, ihnp4, rutgers, seismo, uiucdcs}!okstate!gregg ARPA: gregg@A.CS.OKSTATE.EDU
nevets@ihlpm.ATT.COM (Steven R Ringwood) (07/20/87)
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
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/21/87)
In article <1649@sfsup.UUCP> mpl@sfsup.UUCP (M.P.Lindner) writes: >However, since YYDEBUG is never #defined, the preprocessor sees an undefined >symbol name where it expects a numeric expression. Which therefore evaluates as 0. If someone's C preprocessor handles this differently, he should get it fixed.
mpl@sfsup.UUCP (M.P.Lindner) (07/23/87)
In article <1271@ihlpm.ATT.COM>, nevets@ihlpm.ATT.COM (Steven R Ringwood) writes: > 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. Right you are, Steve. This was my solution as well, but since I didn't keep track of what I did to fix it and was too lazy to do diffs against the original source, my posting was a little sketchy. > 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. Well, right again. I had missed this one (since I didn't run across the deviant behavior), but it looks like there are several places where an unexpected EOF could cause an infinite loop. I made the following changes to logo.y: $ diff OLDlogo.y logo.y 41c41 < char charib =0; --- > int charib =0; 662c662 < char c; --- > int c; 695c695 < while (!index(" \t\n[](){}\";",(c = getchar()))) { --- > while ((c = getchar()) != EOF && !strchr(" \t\n[](){}\";",c)) { 707c707,708 < while (( (c=getchar())>='a' && c<='z' ) --- > while ( (c = getchar()) != EOF && ( > (c >='a' && c<='z' ) 709c710 < || (c=='.') || (c=='_') ) { --- > || (c=='.') || (c=='_')) ) { 740c741 < while ((c=getchar()) && (c != '\n')) ; --- > while ((c=getchar()) != EOF && (c != '\n')) ; 784c785,786 < c=getchar(); --- > if ((c=getchar()) == EOF) > break; apparently the code expected 0 on EOF. Note that I also changed index() to strchr() (since I'm on a System V machine). I also changed charib to be an int everywhere it is defined (3 files affected by this - use grep to find them - I'm lazy again). Anyway, that about does it for me. I'm quite happy with logo. I have I*M Logo (you know, the "I" word, "Big Blue", etc) for my AT&T (yay) PC and I like that, although I don't use it much. I was looking for a good free logo for UNIX(R) for a while (UNIX is a registered trademark of AT&T). Happy turtles! Mike Lindner ...!ihnp4!attunix!mpl
dupre@spitfire.UUCP (Frank Dupre) (07/24/87)
Does anyone have any experience using UNIX LOGO Release 4 with an
ATARI 135XE or 800 as the graphics terminal. Apparently one
needs a "special terminal program." Does anyone own this puppy and
can I get a copy.
-thanx
* (uucp) {...}!rochester!rocksanne!xrxns!dupre
* (XNS) Frank Dupre:LSBG-EGP/CAD:Xerox
* (Ma Bell) (703) 729-8000 Ex# 5487
* (Intelnet) 8*437-5487
* (US Post) Xerox Corporation - XICTMD
P.O. Box 2000
Leesburg, VA. 22075