Closed guncha closed 12 years ago
Well, I guess it's a bad way to fix the problem. There must be a reason why EOF happened. Probably I should check for feof and ferror.
Any ideas why EOF happens?
Yeah, well, the proper way would be to check for an error condition before fread, though in this case it will almost always evaluate to true. I'm not sure about the first EOF (some read operation during init?), but every subsequent one happens when you try to read ENOUGH_DATA_FOR_INPUT_PARSING bytes from /dev/tty when there's only one or two bytes available. Then again, the fact that it worked for you before on Linux could indicate that this is a BSD specific thing.
I see, I'll dig libc manuals for BSD and OS X and see what I can do.. Thanks for the report.
Nothing on the net or on the man pages as far as I can see. My guess is that reading from /dev/tty is special in freebsd and returns EOF from time to time. I'll have to install freebsd in a virtual machine to check that theory out. So, it will take some time.
P.S. And let's hope that behaviour in freebsd and mac is identical.
I just realized, that if you need to run test suite on OSX, let me know and I'll help you out.
I wish I had any test suite :)
I think you can take a look at libtermkey http://www.leonerd.org.uk/code/libtermkey/ It works on OSX and its license is the same as termbox: MIT.
Sure, I will, when I have spare time for that, but I don't have a mac, I can't test it. Thanks for the link, actually I talked once with the author of that library.
I can test it on my mac in my spare time. I am looking forward to testing a new version. Please keep up the good work!
Ok, I'll take a look at the code tomorrow then.
So, I've found a free freebsd shell (was too lazy to make a virtual machine setup). And it turns out indeed, on all OSes non-blocking /dev/tty read sets EOF. But on linux it doesn't stop the following fread calls, however on BSD descendant OSes it does. So, now I check for EOF condition after each read and do clearerr in that case.
Sorry it took so long to apply.
Please check, it should work now.
Hi, I've just run the sample app "keyboard" and confirmed it works as expected. Thanks for a fix!
I forgot to tell you I needed to modify Makefile:
--- Makefile.orig 2012-03-04 01:08:21.000000000 +0900 +++ Makefile 2012-03-05 23:59:40.000000000 +0900 @@ -3,7 +3,7 @@ libdir=$(prefix)/lib includedir=$(prefix)/include
-CFLAGS=-std=c99 -D_POSIX_SOURCE -Wall -Wextra -Wno-unused -O2 +CFLAGS=-std=c99 -D_POSIX_SOURCE -D_DARWIN_C_SOURCE -Wall -Wextra -Wno-unused -O2
SRC=termbox.c term.c input.c ringbuffer.c utf8.c OBJ=$(subst .c,.o,$(SRC))
We need _DARWIN_C_SOURCE is defined because SIGWINCH is defined in OS X /usr/include/sys/signal.h like below:
Thanks for the hint, I'll add that to CMakeLists.txt. Btw, cmake is a system I use to build termbox. But frankly it doesn't matter. The library is so small that you should simply take the source code and add it directly to your app.
Oh, I didn't know about cmake. I just ran only $ make
Just now I tried with commit f03725ffd5ac140ddd6eaa8793354ff086e1b5ed $ make clean $ cmake . $ make and it compiles OK. So I think no need to change CMakeLists.txt. Thank you.
Interesting, because I asked friend of mine to test what defines cmake adds on mac. And it doesn't add anything at all. :) But good to know. Also a small hint, in cmake the preferred way to build things is out-of-source. E.g.
mkdir build
cd build
cmake ..
make
That way build directory is kept away from the source code and if something went wrong you can just delete it and here you have clean source directory again.
Oh, thanks for info. It's nice to learn a new thing :-) I tried that with a clean checkout and confirmed it compiles OK.
Ok, I'm closing it then. It seems working.
Hi,
I ran into some other problems, this time the wait_fill_event() function would hang on a keypress. Window resize worked fine. I traced the problem to fread() in termbox.c on line 428. It would always return 0 and control would jump back to while(1), going on forever. Turns out, some previous operation on *in descriptor had caused an EOF error and therefor all subsequent freads fail. Placing clearerr(in) before fread() solved the problem for me.
G.