jeff@uop.edu (Jeff Ferguson) (09/22/88)
I have just pulled a copy of MAZEWAR off of this newsgroup. When I tried to compile it (using MAKE), I got the following: user.c: 137: clearok: argument mismatch "user.c", line 137: syntax error at or near symbol ) *** Error code 1 Stop. When I get it worked out I will post a fix. -- Jeff Ferguson.
jeff@uop.edu (Jeff Ferguson) (09/23/88)
In article <1683@uop.edu>, jeff@uop.edu (Jeff Ferguson) writes: > > I have just pulled a copy of MAZEWAR off of this newsgroup. > When I tried to compile it (using MAKE), I got the following: > > user.c: 137: clearok: argument mismatch > "user.c", line 137: syntax error at or near symbol ) > *** Error code 1 > > Stop. > > When I get it worked out I will post a fix. I'm back with my fix! Line 137 in user.c needs to read . . . clearok(stdscr, TRUE); There are two arguments to CLEAROK (as seen in /usr/include/curses.h). The second is a boolean flag that tells the function whether you REALLY want it to clear the screen or not. I suppose I should make the TRUE value a variable so that it can be changed if needed . . . but, hey -- if you don't like it, sue me! Everything compiled fine! Thanks, -- Jeff.
tif@cpe.UUCP (09/27/88)
Written 3:46 am Sep 23, 1988 by gryphon.UUCP!oleg in cpe:comp.src.gam.b >System I am using has a kernel problem that does not currently allow to have >a named pipe opened for both read and write. What good is a pipe that can't be opened for both read and write? >However, the README mentioned something about a BSD/sockets version of >MAZEWAR. Is there such a thing in Public Domain? It said he got his idea from a similar game (PD) that used sockets. I don't know what game he is referring to, he didn't give a name. Actually, I posted cause I had to ask that question :-) Paul Chamberlain Computer Product Engineering, Tandy Corp. {convex,killer}!ninja!cpe!tif
oleg@gryphon.CTS.COM (Oleg Kiselev) (09/30/88)
In article <12600002@cpe> tif@cpe.UUCP writes: > >>System I am using has a kernel problem that does not currently allow to have >>a named pipe opened for both read and write. >What good is a pipe that can't be opened for both read and write? There are certain synchronization problems associated with bi-directional pipes that are not trivial. The deficiency will be fixed at some point. Mean while I'd like to play that game! -- .signature quote leased to Richard Sexton Oleg Kiselev ARPA: lcc.oleg@seas.ucla.edu, oleg@gryphon.cts.com (213)337-5230 UUCP:...!ucla-cs!lcc!oleg
jbrown@jato.Jpl.Nasa.Gov (Jordan Brown) (10/01/88)
In article <7409@gryphon.CTS.COM> oleg@gryphon.CTS.COM (Oleg Kiselev) writes: >In article <12600002@cpe> tif@cpe.UUCP writes: >> >>>System I am using has a kernel problem that does not currently allow to have >>>a named pipe opened for both read and write. >>What good is a pipe that can't be opened for both read and write? > >There are certain synchronization problems associated with bi-directional >pipes that are not trivial. The deficiency will be fixed at some point. >Mean while I'd like to play that game! The exact problem you are having is that your kernel does not allow opening the pipe for read/write. That is, you are not allowed to open(pipe,2). Mazewar does this so that the parent (the keyboard process) can kick the kid (the screen process) when you hit ^L. The fix (which I haven't tried) is to change that open(...,2) to an open(...,1). (This code is in user.c in the routine init_pipes.) Note that the child process closes the pipe and reopens it for read, so this change won't hurt it. (My information on your kernel comes from one of your kernel people, and what he says fails agrees with what the program does.)
oleg@gryphon.CTS.COM (Oleg Kiselev) (10/01/88)
In article <239@jato.Jpl.Nasa.Gov> jbrown@jato.UUCP (Jordan Brown) writes: >The exact problem you are having is that your kernel does not allow >opening the pipe for read/write. That is, you are not allowed to >open(pipe,2). I had neglected to say that POSIX had explicitly prohibited R/W pipes. And our kernel is being POSIX-taylored. >Mazewar does this so that the parent (the keyboard >process) can kick the kid (the screen process) when you hit ^L. The >fix (which I haven't tried) is to change that open(...,2) to an >open(...,1). (This code is in user.c in the routine init_pipes.) Note >that the child process closes the pipe and reopens it for read, so this >change won't hurt it. I had not had time to look at that code at all -- I saw the bi-directional pipe and assumed that there was more communication going on... My mistake. Should have been more careful -- I had run into this problem before with other software, but I was getting payed for solving it then! :-) I will see if just opening the pipe for write only will work. I was under impression that I will need to open a second pipe for reading -- and did not have any time to try it... And, like, keep those jokes flowing in, eh? -- .signature quote leased to Richard Sexton Oleg Kiselev ARPA: lcc.oleg@seas.ucla.edu, oleg@gryphon.cts.com (213)337-5230 UUCP:...!ucla-cs!lcc!oleg
tif@cpe.UUCP (10/04/88)
Written 4:28 am Sep 30, 1988 by gryphon.UUCP!oleg in cpe:comp.src.gam.b >In article <12600002@cpe> tif@cpe.UUCP writes: >>What good is a pipe that can't be opened for both read and write? >There are certain synchronization problems associated with bi-directional Ohhhhh, bi-directional. I thought ... never mind. Paul Chamberlain Computer Product Engineering, Tandy Corp. {convex,killer}!ninja!cpe!tif